RE: iSCSI: U=<user> in Authentication

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

David,
I said that the code is not hard, however, the GUI will have to span the
users normal Password handling system (since I am sure that a good GUI
would want to check it out), and it needs to know where the iSCSI Initiator
Node Names are stored etc.  Again not hard, just a little bit more then
most folks thought about.  Again, I do not think the GUI part is important,
every vendor will do it better then every other vendor.

What I don't understand is why not have the target copy the string from the
TargetName=<value> string to the U=<user> string.  That has got to be the
simplest thing to do.  Why have both strings transferred and then have to
explain to every one why the Target cant just do the simple string copy you
mentioned.  Not doing that seem kind of dull.

.
.
.
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


Black_David@emc.com on 09/20/2001 04:48:33 PM

To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: U=<user> in Authentication



> 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
>
>
>