RE: iSCSI: U=<user> in Authentication

[Black_David@emc.com]

> You would certainly want the end-user or administrator to have the
> capability of not entering the UserID if it is the same as 
> the iSCSI Node Name.

Sounds like a simple checkbox in a management GUI, or a switch on
a command line or ...

> I just think it would be useful and simpler, to include in our
> documentation a statement that says that the Default for U=<user> or N
> =<name> etc., if not entered, is the iSCSI Initiator Node Name.

I disagree - all the authentication parameters need to be present,
and management tools are quite capable of doing a string copy.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Thursday, September 20, 2001 2:45 PM
> To: CONGDON,PAUL (HP-Roseville,ex1)
> Cc: ietf-ips; 'Steve Senum'
> Subject: RE: iSCSI: U=<user> in Authentication
> 
> 
> 
> Paul, Steve,
> I understand your point, however, with duplication you often 
> cause hard to
> detect errors.  Often I have looked at two similar strings 
> and have had
> difficulty in seeing minor differences in them.  When 
> administrators, or
> end-users are the ones that are attempting to enter what 
> maybe very long
> strings (in the case of iSCSI Initiator Node Names), you can 
> imagine the
> finger checks maybe an important problem.
> 
> Also if you think through the process of how a UserID is 
> obtained, by the
> Initiator, you see that it is the end-user/administrator that 
> must enter
> the value.
> 
> You would certainly want the end-user or administrator to have the
> capability of not entering the UserID if it is the same as 
> the iSCSI Node
> Name.  In this case, a good implementation (if the UserID is 
> not entered)
> will include code to find and replicate the iSCSI Initiator 
> Node Name as a
> UserID.  Again, this is not a hard problem, just another 
> thing to handle.
> 
> I just think it would be useful and simpler, to include in our
> documentation a statement that says that the Default for U=<user> or N
> =<name> etc., if not entered, is the iSCSI Initiator Node 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
> 
> 
> "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com> on 09/20/2001
> 10:13:57 AM
> 
> To:   "'Steve Senum'" <ssenum@cisco.com>, John Hufferd/San 
> Jose/IBM@IBMUS
> cc:   ietf-ips <ips@ece.cmu.edu>
> Subject:  RE: iSCSI: U=<user> in Authentication
> 
> 
> 
> 
> I agree with Steve here.  The most likely deployment will be to use
> InitiatorName as UserID whenever possible, but it doesn't 
> seem necessary to
> force that or allow the option to omit a name in one phase or another.
> 
> Paul
> 
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Thursday, September 20, 2001 9:38 AM
> To: John Hufferd
> Cc: ietf-ips
> Subject: Re: iSCSI: U=<user> in Authentication
> 
> 
> 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
> 
> 
>