Subject: RE: iSCSI: U=<user> in Authentication

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 19 Sep 2001 10:12:37 -0700

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: [email-masked]
+------------------------------------------+

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 6:22 PM
To: Julian Satran; Ofer_Biran/Haifa/IBM%IBMUS; [email-masked];
[email-masked]
Cc: [email-masked]
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: [email-masked]

---

From: Steve Senum <[email-masked]>
Date: Wed, 19 Sep 2001 17:27:08 -0500

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