Re: iSCSI: U=<user> in Authentication

[Steve Senum <ssenum@cisco.com>]

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