|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: U=<user> in AuthenticationOK, we'll add SRP_ and CHAP_ prefixes to their keys. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 20/09/2001 21:12:12 Please respond to John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Amy N Congdon/Austin/IBM@IBMUS, PAUL__" <paul____congdon@hp.com/OU=San Jose/O=IBM/@boulder.ibm.com (HP-Roseville,ex1)"@westrelay02.boulder.ibm.com Subject: RE: iSCSI: U=<user> in Authentication 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 +------------------------------------------+
Home Last updated: Mon Sep 24 09:17:30 2001 6689 messages in chronological order |