Re: ISCSI: User authentication vs. Machine Authentication for iSCSI

["John Hufferd" <hufferd@us.ibm.com>]

Bill,
You are correct, in my opinion, on the problem statement, but not  on the
solution.

The IKE stuff will Get a system identified, and perhaps ensure that a
encrypted connection is put in place.  This then give the Source and Target
the Freedom to exchange stuff that would otherwise be in the clear, such as
iSCSI Node Names etc.  But after the iSCSI session is established, it is
between an OS and a target.  The OS, is the thing that actually owns the
resource, it only loans the resources, in some manor, to applications.

I was having a similar problem to what you stated, at the Irvine meeting,
and kept digging and objecting (off-stage) until I got the following more
acceptable response.

Environment 1: (Use of IKE with complete Certificates processing ( or
pre-Shared password), with ESP equal to something other then Null)
1. We use IKE to get a mutually authenticated and Encrypted communication
link.  This means that the Target knows that (at the IKE/TCP Layer) there
is, at the other end, an authorized thing.  (What or who that thing is,
relative to iSCSI is not really known).  This secure link can be
established either via Certificates or via a pre-Shared password.
2. An iSCSI Login can now be done, over a secure link, so the iSCSI
Initiator Name, and iSCSI Target Name etc can be exchanged securely.
Please note, just because you passed the IKE certificate gate does not mean
you are the iSCSI Initiator that you claim to be.  Therefore, a password,
for example, that is associated with the iSCSI Initiator Name can now be
used to perform an iSCSI validation of the Initiator.  (Please note, this
could, instead of a password,  be a Kerberos type Validation etc.)
3. David, and perhaps other used the words "User" or "Application" name to
address what was being addressed in 2 above.  But there was more to this
then just assuming that the iSCSI Initiator Name was the User name.  Since
folks may actually want to use existing infrastructure, to handle the
password management and authentication process, they will need to assign
what I might call an "Alias for the iSCSI Initiator" which can actually be
saved in the existing infrastructure user authentication repository.  The
point that was made to me, is that iSCSI Initiator Name (iqn, or eui) will
not "fit" into things that contain "User Names" so we need to have a
corresponding "User Name" that we can actually authenticate using, for
example Microsoft Active Directory etc. Hence the need for a "Alias for the
iSCSI initiator.  (I really hate this, and wish there was something else we
could do.)

Environment 2: (Use of IKE with Asymmetrical authentication,  and ESP equal
to something other then Null.  This example was pushed by Mark Bakke.)
1. We use IKE to get a mutually authenticated Encrypted communication link,
but this is done by giving the Initiators a "Dummy" (self signed?)
Certificate and that this is used to permit the Initiator side to assure
that it is talking to the correct target but gives no such assurance to the
Target that it is talking to an approprate Initiator.  However, it does
setup a secure (encrypted) connection.  (Note: a similar thing can be done
with pre-shared Keys, where the Initiator systems are all given the same
pre-shared password.)
2. The iSCSI Login can now occur, as in Environment-1 above.  In this mode
the only time the Initiator has any real authentication, by the target is
in this iSCSI stage.
Note: Mark pointed out that this was the way Web servers worked.
3. Chap can  be used in this environment since the Link is already secure
and encrypted, and sending the password in what otherwise would have been
in the clear, is protected by the link encryption.

Environment 3: (no use of IKE)
1. No authenticated private Link is established via IKE, so -- in many
environments, a Chap type solution is just not secure enough, therefore the
recommendation will be to use SRP, since that will add some hashing etc. to
protect the password.

The problem I have with all the above, is that their needs to  be some
method that the target can use ensure that the "USERNAME" that has the
password associated with it, is actually the approprate iSCSI Initiator
NAME.

If we do not ensure, at the target, that the "USERNAME" is THE username to
be associated with the iSCSI Target Name, then all the IKE and CHAP or SRP
stuff does is permits us to know that the initiator side is one of some set
of systems that are authorized to contact the physical Device know as the
iSCSI Target Node.  Now remember there could be more then one iSCSI Target
Names (SCSI Target) within the same iSCSI Target Node.  It is even possible
that the different SCSI Targets may want to have different LUNs attached to
each of them.  Further, I expect that many of us wanted to associate
certain LUNs with certain iSCSI Initiators, as we do today with Fibre
Channel.  However, if we do that, then we must have a hard lock between
"username" (aka "Alias for the iSCSI initiator") and iSCSI Initiator Name.

It is not clear that we have thought through all the ramifications of this
dependance on "USERIDs/USERNAMEs" (aka "Alias for the iSCSI initiator").
Did any of us understand that we needed a binding association database, on
the targets, to keep associations between iSCSI Initiator Names and
"USERIDs/USERNAMEs"?  If so, I bet there were not many.

I would like to know if their is a better approach to what I call the
second stage authentication, without requiring yet another name for the
iSCSI Initiator Node.



.
.
.
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: hufferd@us.ibm.com


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/29/2001 08:40:54 AM

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
cc:
Subject:  ISCSI: User authentication vs. Machine Authentication for iSCSI



I have been fighting with this problem since I left LA.

I am not aware of any usage scenarios today where block devices are owned
by
the user rather than the machine.  I will conceed that in many instances
the
first thing the system does is assign the resource to a use (tape, scanner,
etc.) but the machine still owns the resource and can in fact remove it out
from under the user...

I am not to certain how I could build a trusted iSCSI environment where one
user would have no knowledge about what was happening with other users in a
malicious environment (especially where a system was participating in the
exposure of resourses).  Examples of this include things like co-located
Web
hosting where a single user scans process memory looking for 1Kbit of
random
data, and when finding it attempts to determine if that is the private key
of a user sharing the resource.

The reason I am bringing this up, is I am not sure trying to define
security
above the machine level makes any sense for iSCSI.  Aren't most SCSI
devices
owned by the Operating System not the User and partitioned out by the
Operating System to the users ?  If this is the case many of our
authentication methods simplify to simple IKE identities.

Bill