RE: iSCSI: U=<user> in Authentication

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

I agree with Paul on this Key Name issue.  We should not leave our keywords
up to a separate organization and process.  I can imagine that in the
future, we might want to permit a new Authentication routine.  It might
have Keywords that are duplicates of other, perhaps non security keywords,
which are part of the base iSCSI protocol.  Though I understand that we can
get the parsing done correctly, I see a lot of possible human confusion,
and communication problems with the straight insertion of other RFC
keywords into iSCSI.

.
.
.
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>@ece.cmu.edu on
09/20/2001 10:10:24 AM

Sent by:  owner-ips@ece.cmu.edu


To:   Ofer Biran/Haifa/IBM@IBMIL, "CONGDON,PAUL (HP-Roseville,ex1)"
      <paul_congdon@hp.com>
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: U=<user> in Authentication




Ofer and Steve,

The fact that the keys are authentication method specific is exactly the
problem.  The difficulty with parsing non-unique keys is that you must tell
your parser what context it is operating under.  I can conceive of how this
can be done, it's not that hard, but it seems like unnecessary complexity.
It could get worse if key names overlap outside of authentication phase.

I agree that aligning with the names used in the relevant RFCs has some
merit.  Perhaps we could satisfy both needs by using names such as:

Srp-U, Srp-N, Srp-g, Srp-s, Srp-A, Srp-B, Srp-M, Srp-HM
Chap-N, Chap-I, Chap-C, Chap-R, Chap-A

Paul

-----Original Message-----
From: Ofer Biran [mailto:BIRAN@il.ibm.com]
Sent: Thursday, September 20, 2001 5:28 AM
To: CONGDON,PAUL (HP-Roseville,ex1)
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: U=<user> in Authentication



Paul,

The implementers are sent to the relevant RFC for the definition of each
authentication method, so the clearest way in my opinion was to use the
exact keys
as appeared in the RFCs (with a simple statement e.g. -
"Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]"   ).

I don't think, as Steve doesn't, that there is a real parsing problem since
these
keys are authentication method's specific (and you know where you are at
that point).

   Regards,
     Ofer


Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253


"CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>@ece.cmu.edu on
19/09/2001 20:12:37

Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL,
      Ofer_Biran/Haifa/IBM <Ofer_Biran/Haifa/IBM@us.ibm.com>,
      mbakke@cisco.com, jtseng@NishanSystems.com
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: U=<user> in Authentication




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