Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI

From: "John Hufferd" <[email-masked]>
Date: Thu, 30 Aug 2001 09:43:19 -0700

Comments in line below.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Stephen Bailey <[email-masked]>@ece.cmu.edu on 08/30/2001 06:50:23
AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: ISCSI: User authentication vs. Machine Authentication for iSC
      SI

> I believe this is the "iSCSI Name" (formerly WWUI).

I guess I was unclear.  I consider the iSCSI name to BE the `user
name' in this discussion.

I was not suggesting that we introduce any additional identities.  I
was only suggesting it might be a mistake to slavishly equate identity
with OS instance.  I don't THINK we're in any risk of doing that.
Somebody please shout if they think we are, or if they think we should
be.

/*Huf**
The new Name (UserID) is exactly what was implied at the meeting in Irvine.
The reason that came in was that it was stated that the iSCSI
Initiator Node Name would not Fit into the installation's normal
Authorization
process (which today is used to Authenticate USERS), such as the
Microsoft Active Directory.
**Huf*/

If a user process wants to initiate its own iSCSI connection to a
target, there are two options:
  1) the host OS gives the process ITS identity (& credentials)
  2) the user process uses its own unique identity (obtained through
     some mechanism we're not describing or discussing, e.g. from the
     storage domain administrator).

1) would be the case if you were using SCSI passthru to an iSCSI
driver.  In this situation, it's still really the OS that's doing the
interaction as a proxy for the user.  The OS can ensure (or not) that
its identity isn't being abused.  The OS could also give its identity
to a user-mode iSCSI sockets client through a securable interface.
The OS should never completely freely give away its identity (e.g. to
an untrusted user process), unless it doesn't care how it's used.

/*Huff**
A number of us, I am sure, think this is a very poor direction for an
implementation. But you are correct. If an OS passes off its identity
to a User Process, a User Process could masquerade as a valid OS and
send its own stuff via a normal TCP/IP Sockets. Since this application
would not be able to use the iSCSI HW HBAs, that most Servers will be
dependent upon to provide the approprate performance and lower the
TCP/IP processing overhead, I believe that this approach will probably
not be an important issue for legitimate applications.
**Huff*/

2) would be the case if jane helpful-programmer (or joe script-kiddy)
wrote a user-mode iSCSI initiator using sockets for whatever purpose.

/*Huff**
This is one of the problems we must protect from. Since an OS (iSCSI
Initiator Node Name can be validated, we must make sure that the
Authorization approach prevents this from happening.  As I stated
above I can not believe that a user mode application (other then in
development) that had to add all its own PDU structures etc.
would be a valid application (especially since it could NOT use any
iSCSI offload HW that might be in place.)
So I believe we must consider such a potential application as
probably a rouge application and do nothing to help this, and work
to prevent it.
**Huff*/

Perhaps I'm covering old ground that was already worked out at the
interim meeting.  If so, I apologize.

/*Huff**
This is just a direction (thread) that got started, based on a
misunderstanding
of what was meant when the concept of UserID came up as part of
authentication during the Irvine meeting.
The important issue is, can we make the iSCSI Initiator Node Name be used
as the UserID.  A separate UserID is only needed if you use an
existing Authentication infrastructure that does not permit the
use of the eui or iqn type names.  This is where we need to focus
and see if we fully understand the problems and the impacts of
such approaches.
**Huff*/

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 30 Aug 2001 15:13:33 -0400

> The new Name (UserID) is exactly what was implied at the meeting in

Oh.  How horrible.

> implementation.

Agreed.  I just wanted to walk the space a little bit.  My point is
that while traditional SCSI passthru does confer control privs (and is
protected as such), it doesn't need to.  Specifically, a client using
SCSI passthru is not actually given the identity of the host OS, per
se.

> probably a rouge application and do nothing to help this, and work

I understand what you're saying, but I'm not sure it confers much
architectural direction.  There already must be a concept of identity
which is independent of anything bound to a particular system (e.g. IP
address, hardware network port etc.), so there's no way to exclude
that.

> The important issue is, can we make the iSCSI Initiator Node Name be
> used as the UserID.

Agreed.  Are there minutes to the meeting?

Thanks,
  Steph

---

From: Mark Bakke <[email-masked]>
Date: Thu, 30 Aug 2001 15:07:35 -0500

> > The new Name (UserID) is exactly what was implied at the meeting in

Ideally, you're right.  For instance, if iSCSI was using AuthMethod=CHAP,
then it would be great if the CHAP username (N) specified was identical
to the InitiatorName.

In the draft, that's not how it is.  The user names for CHAP and SRP
(I'm not sure about the others) are specified separately from the
InitiatorName, so there's currently nothing in the protocol to prevent
them from being different.

In practise, there might be times when having them be different
makes the "fit in" better with whatever administration scheme is
out there.  For instance, if my desktop was assigned some iSCSI
storage, and my username and password were kept on a RADIUS server
somewhere, for use by file servers, web servers, and iSCSI servers
or devices, my user name is likely to be a non-globally-unique
string, probably "mbakke".  However, that's not likely to be
my InitiatorName.  To make them the same, I would either have to
change my InitiatorName on my desktop to "mbakke", to fit in with
my login on all of our web and file servers, or the admin would
have to create a new login for my iSCSI stuff on the RADIUS server,
and maintain two of them.  Changing my login on everything to
match an iSCSI name is likely not an option.

Another possible place this could happen is if I am obtaining
iSCSI "services" from more than one administratively-separate
environment.  Each of these environments may prefer to assign
me a user name for login that matches their own internal scheme.
I may have some control over this, but in the end, it has to be
unique within the service-provider's scheme.  This is very
similar to setting up a user-name for your ISP at home; you
may request a particular name, but if the ISP already has one,
you have to pick again.

The point is that if one had two of these environments providing
services, they may each need a separate user name.

Of course, the latter example could be solved by having the
admins accept the initiator name that's already on my iSCSI
client as the user name; these are supposed to be unique
anyway.  The only trouble then is the same as before; if I am
getting more than just iSCSI services from this provider, they
would then have to maintain two user names for me.

A third reason this might happen is that some centralized
password authenticated services such as RADIUS may have
length restrictions on their user names that are shorter than
what is allowed in an iSCSI initiator name.

Anyway, implementations have the most flexibility the way
these protocols (SRP, CHAP) are currently documented.  I think
that we could recommend that the iSCSI initiator name be the
same wherever possible, but I don't see how we can require it.

> > The important issue is, can we make the iSCSI Initiator Node Name be

Again, I think that the best we can do is recommend that they
be the same, but I don't think we can take the step of requiring
it.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 30 Aug 2001 20:33:34 -0400

> out there.

Oh, right.

Impedance-matching existing authentication architectures is fast
becoming the oldest profession.  There is no really good solution,
because people keep hacking together patchwork because there is no
really good solution.  Look no further than authentication for
commercial databases if you want a good cry.

Thanks for putting me in the picture.

Steph