Re: iSCSI: U=<user> in Authentication

[Steve Senum <ssenum@cisco.com>]

John,

My opinion on this is:

What you are calling the UserID (i.e., U=<name>
for SRP, N=<name> for CHAP), could be the same
as the iSCSI Initiator Name, but it should not
be required to be so.

I see the N=<name> within CHAP (or U=<name> for SRP)
being used for authentication, the process of verifying the
Initiator is who it claims to be.  I also see it as
an integral part of the chosen AuthMethod.

I see the InitiatorName=<name> being used for
authorization, the process of verifying what
resources the Initiator can access.

There are two reasons I can think of that
the two names would be different:

1. The particular AuthMethod, or the implementation
of some third party authentication server, might
restrict what form a name can take that is not
compatible with iSCSI naming.

2. A group of Initiators might be configured to
use the same name for authentication purposes,
simply because they are being managed as a group
for authentication purposes.

Steve Senum

John Hufferd wrote:
> 
> OK then Steve, and others  I would be interested in your answers to the
> following questions:
> 
> If the UserID is exactly the same as the iSCSI Initiator Name, why would it
> be entered again?
> 
> If the UserID is different, why was the iSCSI initiator Name required?  It
> is only used as:
> 1. A unique string that can ensure that the full Session identification is
> unique, The UserID can do that.
> 2. As an Authentication String.   The UserID can do that.
> 
> If the same users wants access to different storage from different systems,
> that user can have a unique UserID for each system.
> 
> If the User wants the same storage access from different systems, serially,
> then that user can use the same UserID on each system.
> 
> So is the UserID a substitute for iSCSI Initiator Name?
> 
> .
> .
> .
> 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
> 
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 09/19/2001 03:27:08 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI: U=<user> in Authentication
> 
> I don't think it should be possible to omit
> the usernames for AuthMethods SRP and CHAP.
> 
> On the SRP and CHAP key names, I am mostly netural,
> though I would prefer ChapId instead of ChapID.
> Since they are AuthMethod specific though, I don't
> really see the need to change them.
> 
> Steve Senum
> 
> "CONGDON,PAUL (HP-Roseville,ex1)" wrote:
> >
> > I agree that more clarification regarding how to associate SCSI Names
> with
> > user identities should be provided.  I'm not sure if I agree that it
> should
> > be possible to omit the names entirely - however.  This would provide
> > another optional way to approach the exchange (may provide or may not)
> which
> > adds complexity to this portion of the code, more test cases, more
> > unnecessary options, etc..  As you've mentioned it may also be different
> > depending upon the authentication method in use. There is certainly room
> for
> > improvement here.
> >
> > I have a bit of a gripe about the key=value pairs during authentication
> > phase in general.  First of all, the key names are not very descriptive,
> > which defeats the purpose of using Text keys in the first place (in my
> > opinion).  Secondly and more importantly, there are key values that are
> not
> > unique and depend upon what authentication method is in progress in order
> to
> > decode/parse them.  For example, A=5 in CHAP for algorithm selection is
> > completely different that A=2345 in SRP.  Also N=initiatorName in CHAP is
> > totally different than N=5678 in SRP.   It would be much easier if the
> text
> > command parser didn't have to consider what authentication method was
> > running and that all key values were unique.  Thus I propose making the
> > following name changes to CHAP and SRP key values.  I'm not too concerned
> > about the exact key names used, just that they are somewhat descriptive
> and
> > unique.
> >
> > CHAP Key Values
> >
> > Old         New
> > ---         --------
> > A           ChapAlgorithm
> > I           ChapID
> > N           ChapUser
> > C           ChapChallenge
> > R           ChapResponse
> >
> > SRP Key Values
> >
> > Old             New
> > ---             ---
> > U               SrpUser
> > N               SrpSafePrime
> > g               SrpGenerator
> > s               SrpSalt
> > A               SrpPubKeyA
> > B               SrpPubKeyB
> > M               SrpSessionKey
> > HM              SrpKeyProof
> >
> > Paul
> >
> > +------------------------------------------+
> > Paul Congdon
> > HP ProCurve Networking
> > Hewlett Packard Company
> > 8000 Foothills Blvd - M/S 5662
> > Roseville, CA   95747
> > phone: 916-785-5753
> > email: paul_congdon@hp.com
> > +------------------------------------------+
> >
> > -----Original Message-----
> > From: John Hufferd [mailto:hufferd@us.ibm.com]
> > Sent: Tuesday, September 18, 2001 6:22 PM
> > To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; mbakke@cisco.com;
> > jtseng@NishanSystems.com
> > Cc: ips@ece.cmu.edu
> > Subject: iSCSI: U=<user> in Authentication
> >
> > Folks,
> > I think we should indicate in the Security section of the document how
> the
> > security Authentication process might validate that the iSCSI Initiator
> > Name sent in the Initial Login, has something approprate to do with the
> > "user" being authenticated.  (Otherwise, you could authenticate a user
> and
> > that user could claim/use any iSCSI Initiator Name in the InitiatorName
> > key=value pair.
> >
> > It is kind of obvious how to relate the U=<user> to the approprate iSCSI
> > Initiator Name (in the case of SRP), and little less obvious with Chap,
> > though I think it would be the N=<N> parameter.  However, it is really
> not
> > obvious when using Kerberos, and SPKM.
> >
> > It also should be possible for the initiator not to send another UserID,
> if
> > the Security Data Base the customer uses can support the iSCSI Initiator
> > Name as a UserID.  That is, it should be possible for the U=<user>
> > parameter not to be sent,and have that  imply  the value of <user> is the
> > iSCSI Initiator Node Name entered previously as a value in the
> InitiaorName
> > key=value pair. Same way with the N=<N> in Chap.
> >
> > However, it is not clear, how you do similar things with Kerberos, and
> > SPKM.
> >
> > What do you folks think about this, and how should we document it?
> >
> > .
> > .
> > .
> > 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