|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Login authentication SRP/CHAPBill, You seem intent on having a working solution that fills a specific set of requirements. As the ideas you put forward are beyond a simple controversial technical item but not "fleshed out" enough for simple mortals to read, I think that the group (list) could benefit from you having all your ideas about requirements and how they should be implemented completely fleshed out in a submitted draft that we can read and judge. Thanks, Julo "Bill Strahm" <bill@sanera.net> Sent by: owner-ips@ece.cmu.edu 23-10-01 19:55 Please respond to "Bill Strahm" To: "Lee, CJ" <CJ_Lee@adaptec.com> cc: "IPS Reflector \(E-mail\)" <ips@ece.cmu.edu>, Ofer Biran/Haifa/IBM@IBMIL Subject: RE: iSCSI: Login authentication SRP/CHAP So you are perfectly willing to specify a MUST implement algorithm that can't be used (what happens if the user password is not available on the target) to clutter up the implementation space ??? I would rather that A SINGLE usable algorithm is labeled MUST implement (if you must in fact specify a MUST implement at all) and the others are left as SHOULD implment. You are right a clear text Username-> Password-> challenge response works great with a secure link (heck I do it every day with SSH) The idea is usable... Again if the problem is that no one will implmement IPsec/use IPsec, then the problem seems to be with IPsec, lets either make it usable, or pick another security protocol that is deployable. If the problem is to see how secure we can be by requiring as many unusable/unimplementable security algorithms as possible, well I guess we as vendors can just decide to implement the protocol, and the algorithms that make sense to us, and don't worry about interoperability... Bill -----Original Message----- From: Lee, CJ [mailto:CJ_Lee@adaptec.com] Sent: Tuesday, October 23, 2001 10:42 AM To: 'Bill Strahm' Cc: IPS Reflector (E-mail); Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP Personally, I'd think that we ought to select a mandatory to implement authentication protocol base on how secure it is rather than how convenient it is. Especially under the MUST to implement but optional to use nature of both the login authentication and IPSec. One could argue the clear text PAP could server equally well the very purpose of login authentication when running on top of an encrypted IPSec link. CJ Lee Adaptec, Inc. -----Original Message----- From: Bill Strahm [mailto:bill@sanera.net] Sent: Tuesday, October 23, 2001 8:33 AM To: Ofer Biran Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute <kirsten.leute@stanford.edu> on 23/10/2001 00:18:00 Please respond to Kirsten Leute <kirsten.leute@stanford.edu> To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct. For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP Thanks in advance, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" <bill@sanera.net> Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" <ips@ece.cmu.edu>, John Hufferd/San Jose/IBM@IBMUS, <owner-ips@ece.cmu.edu> Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com
Home Last updated: Fri Oct 26 13:17:36 2001 7407 messages in chronological order |