iSCSI: Kerb auth issue 2 - name use in kerberos

[Bill Studenmund <wrstuden@wasabisystems.com>]

Sorry this took so long. The issues took some hashing out to come up with
this EMail.

One of the things that came up in doing the Kerberos implementation is
that name handling in Kerberos is different than say in CHAP. i.e. CHAPN
vs principal name behavior.

For CHAP, the initiator has its own CHAP name and secret, and in the auth
mib it has listed the CHAP name and secrets the target should provide if
we're doing mutual. The target has its own CHAP name & secret that it
offers if the initiator requests mutual, and a list of initiator CHAP
names & secrets it will accept for the initiator to authenticate itself.

Another way to get at the difference I'm talking about is the name in the
first part of a CHAP authentication (CHAPN) is a name that has everything
to do with the initiator and nothing to do with the target.

For Kerberos, things are a bit different. The initiator's credentials are
in its credential cache. For a single-sign-on situation, the credentials
are those of the user sitting at the console. In a server-type situation,
the credentials are initialized from a keytab file. The name the initiator
needs to authenticate is the name of the principal it should get a ticket
for.

i.e. the name involved has everything to do with the target, not the
initiator.

We have two options. We can either require the credential be something
determinable, like "iscsi/<target_name>" ("iscsi/iqn.xxxx-yy.com.foobar"),
or we can use the name in the auth mib entry refered to by
iscsiIntrAuthorization.

I would suggest a hybrid of the two. If iscsiIntrAuthorization has a null
name, when we authenticate with kerberos to that target, we use
"iscsi/taget_name". If there is a non-null name, we use it.

Do folks think they understand the question? And if so, does that make
sense?

For the target, the semantics of what the principal names in the
iscsiTgtAuthroization mib entries are fine, though I might suggest that a
blank principal name there would likewise mean we authorize
"iscsi/<initiator_name>".

Thoughts?

Take care,

Bill