You will have to talk to an attorney if you want legal advice. A google search for SRP SPEKE patent results in numerous hits, none of which clearly state anything:
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09292.html anonymous wrote : | iSCSI: SRP status | | * To: [EMAIL PROTECTED] | * Subject: iSCSI: SRP status | * From: [EMAIL PROTECTED] | * Date: Mon, 25 Mar 2002 17:24:45 -0500 | * Content-Type: text/plain;charset="iso-8859-1" | * Importance: high | * Sender: [EMAIL PROTECTED] | | It's been an "interesting" week on this topic. This is an attempt to (coherently) summarize the current situation in which the WG finds itself and what is being done. This message is a mixture of technical and procedural material - technical queries and follow-ups should be sent to the list, but I would ask that procedural queries and follow-ups be sent directly to me to avoid procedural discussions on the list. I promise to post the | (inevitable) clarifications. | | -- Disclaimer | | - I am NOT a lawyer. | - This message does NOT contain legal advice. | - If you need legal advice, you need to talk to a lawyer. | - If actions or decisions based on information in this message | have legal consequences, those consequences are YOUR | responsibility. | - The IETF and yours truly disclaim all responsibility | | On the subject of Intellectual Property Rights, the attention of all IETF participants is directed to Section 10 of RFC 2026. | | -- Patents | | While the IETF disclaims responsibility for performing patent searches (see Section 10 of RFC 2026), the following patents have been identified to the IPS WG as being of concern with respect to SRP: | | (1) An SRP patent application filed by Stanford University [The SRP patent] | (2) US 6226383 held by Phoenix [The SPEKE patent) | (3) US 5241599 and US 5440635, held by Lucent [The EKE patents] | | -- Enquiries and Responses | | Enquiries have been made of the above patent holders, who have responded as follows: | | (1) Stanford has a license to their pending SRP patent available on the web | at http://otl.stanford.edu/pdf/97006.pdf. There is no cost to obtain | the license. No payments are due to Stanford under the license and | the license does not contain any reciprocal grant of rights back to | Stanford. | (2) Phoenix has written to the IETF to say that the SPEKE patent may apply | to SRP and has committed to make licenses available on reasonable | and non-discriminatory terms. The Phoenix letter containing these | statements will be sent to the list shortly and will also appear in | the Intellectual Property Rights Notices area of the IETF web site in | the near future. | (3) After initially promising to do so, Lucent has decided not to make any | statement about applicability of the EKE patents to SRP. Lucent has | orally pledged to license the EKE patents in accordance with normal | Lucent licensing practices, but these practices do not involve | "reasonable and non-discriminatory" terms. | | These responses have been summarized in this message for brevity and clarity. | For more details on (1), see the license at the URL above. For (2), see the forthcoming message and/or the IETF web site. For (3), see the text on this topic contained in the message at: | http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08716.html . | | -- IETF Standards Process | | The IETF standards process places some emphasis on commitments to reasonable and non-discriminatory licensing terms (see Section 10 of RFC 2026). Commitments to license on openly specified, reasonable and non-discriminatory terms are neither strictly necessary nor sufficient for the IESG to approve use of technology that is covered by patents, but the absence of such commitments makes IESG approval both less likely to occur and more difficult to obtain. | | In all cases, it is up to the WG to determine the best technical solutions to the problems it is solving, and to make the case to the IESG that the nature of the problem and available technology justifies the use of technology covered by patents. The IESG will analyze each individual case on its own merits. This position was reaffirmed by the IESG during the IESG plenary last Thursday evening. | | -- iSCSI | | The IPS WG considered this situation at its meeting last week and determined that rough consensus no longer exists for a "MUST implement" | requirement for SRP in iSCSI. As things currently stand, that requirement will be weakened to "MAY" and the WG is obligated to designate some other inband authentication protocol as "MUST implement" for interoperability. | | Based on my discussions with some of the Transport and Security Area Directors, an approach based on using CHAP instead of SRP appears to be acceptable, but the WG should consider whether to adopt a version of CHAP enhanced by adding a Diffie-Hellman key exchange that would make the protocol resist passive attacks (e.g., packet sniffer captures CHAP traffic, adversary tries the dictionary of passwords off-line). The WG is *not* being instructed to adopt this approach; the request is simply to consider it. | | In no particular order of priority and/or importance, the following activities are underway to deal with the SRP situation: | - The iSCSI security design team has been asked to take another look | at authentication mechanisms. | - Work is underway with cryptographers to consider how to add a DH | exchange and/or mutual authentication to CHAP (the latter because | SRP is capable of mutual authentication). | - A requirements discussion for the above two bullets will take place | on this list in the near future. The reason for delaying this | discussion is to gather information on the consequences of | requirements decisions, rather than hold a discussion in the abstract. | - Lucent continues to be approached with requests to be more cooperative. | Lucent's actions (or lack thereof) are the primary cause of this | delay to iSCSI. | | iSCSI progress has been delayed by this situation. We were originally hoping to start a WG Last Call on the next (-12) version of iSCSI within the next week or so. That is not possible with this technical issue open - a Mock WG Last Call will be conducted on the next version of the iSCSI draft with the goal of reaching closure on most of its text, but the actual WG Last Call will have to await resolution of this issue. I am hopeful that this resolution can be achieved in the next month or two. | | Thanks, | --David (IP Storage WG co-chair) | | --------------------------------------------------- | David L. Black, Senior Technologist | EMC Corporation, 42 South St., Hopkinton, MA 01748 | +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 | [EMAIL PROTECTED] Cell: +1 (978) 394-7754 | --------------------------------------------------- | http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08715.html anonymous wrote : | Full Text of Phoenix letter | | * To: [EMAIL PROTECTED] | * Subject: Full Text of Phoenix letter | * From: [EMAIL PROTECTED] | * Date: Sat, 9 Feb 2002 02:43:12 -0500 | * Content-Type: text/plain;charset="iso-8859-1" | * Sender: [EMAIL PROTECTED] | | To: IETF IP Storage Working Group | Subject: Phoenix Patents and RFC 2945 | | February 6, 2002 | | | Dear working group members, | | Regarding the inquiry by working group co-chair David Black into the nature | of U.S. patent 6,226,383 and its relation to SRP and RFC 2945, this letter | presents a status update on Phoenix's plans to provide an appropriate | response for the working group. This letter also presents a general summary | of our licensing practices and products in the field of password-based | cryptography, which I hope will assist you in the planning process. | | Phoenix owns patent 6,226,383 which describes the SPEKE methods for | zero-knowledge password authentication. An investigation into exactly how | this patent relates to RFC 2945 is now underway within the company. While | providing guarantees and assurances for use of technology developed by other | organizations has not been a traditional priority for Phoenix, there is now | recognition of the need for this working group and others to have clarity in | this matter, and a position statement will be provided very soon. | | Phoenix Technologies, in part through the acquisition of Integrity Sciences, | has developed the SPEKE family of zero-knowledge password methods, providing | both licenses and implementations. These protocols have been cited and | studied in numerous research papers over the past several years. In | particular, the BSPEKE protocol can provide a plug-and-play upgrade for SRP. | An Internet Draft discussing these issues is also being prepared. These | methods are comparable to the best of any similar methods, and they are | easily shown to be unencumbered by the other patents in this field. | | It would seem a shame for a new standards effort to avoid zero-knowledge | password techniques as a purely cost-savings measure, given the choices | available. The need for convenient, strong, and inexpensive security | built-in to the infrastructure of Internet applications is as great today as | ever. The SPEKE techniques represent a generational improvement in personal | authentication, providing strong security with minimal effort. These | methods provide the best choices in this field, with the cleanest | implementations, optimal security, best alignment with standards, and | easiest license agreements for commercial deployment of zero-knowledge | password techniques. | | A statement regarding licensing of the SPEKE patent in the context of the | IEEE 1363 standard is on file with the IEEE, and Phoenix is also committed | to providing an updated statement in this same time frame that conforms to | both IEEE and IETF policies assuring reasonable and non-discriminatory | terms. But more importantly, as a leading provider to the PC industry, | Phoenix will stand behind its technology. Phoenix has a 20-year history of | broadly licensing products to this industry, and has helped to pioneer many | widely used standards and technologies that are built-in to the systems that | we all take for granted. Our history of cooperation with many of the | leading companies in the industry makes Phoenix naturally suited to gently | encouraging the adoption of this new class of strong and convenient security | techniques. | | Sincerely, | | | David Jablon | CTO, Phoenix Technologies | http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt http://www.ietf.org/ietf/IPR/WU-SRP anonymous wrote : | Received April 26, 2000 | Kirsten Leute <[EMAIL PROTECTED]> | | Stanford University has a U.S. patent pending for the Secure Remote Password (SRP) authentication and key-exchange system. To encourage widespread use of strong cryptographic authentication technologies, Stanford University is granting royalty-free licenses for SRP when used in its implicit server authenticating mode, such as implementations based on RFC 2945. Details will soon be available at (http://otl.stanford.edu/industry/resources/rts.html). | | Stanford University will also offer non-exclusive licenses in a nondiscriminatory manner for use of SRP in its bi-directional authenticating mode (SRP-Z) under reasonable terms and conditions. | | Please contact me with any questions regarding the licensing of SRP. | | Sincerely, | | Kirsten Leute | Associate | (650) 725-9407 | Fax: (650) 725-7295 | [EMAIL PROTECTED] | | ====================================================================================== | Received December 22, 2000 | From: Thomas Wu <[EMAIL PROTECTED]> | | The SRP Authentication and Key Exchange System, as specified in RFC 2945, is available royalty-free worldwide for commercial and non-commercial use. | | Extended variants of SRP, such as those based on SRP-Z, may require a license, which Stanford will grant on a non-exclusive basis, under reasonable and non-discriminatory terms. | | For questions about SRP, please contact me or visit http://otl.stanford.edu/ | | Tom Wu | [EMAIL PROTECTED] | http://www.ietf.org/ietf/IPR/LUCENT-SRP anonymous wrote : | Received March 28, 2002 | From: "Carter, William Robert (Bill)" <[EMAIL PROTECTED]> | | | It has come to our attention that misunderstandings may exist concerning Lucent's willingness to license patents that are essential to the Secure Remote Password specification ("SRP") from Stanford University which has been submitted to the IETF and has been approved by the IETF as a standards track RFC, namely RFC 2945. | | To avoid any further misunderstandings, going forward we would like to state the following: | | Lucent has not conducted and has no current plans to conduct a search of its patent portfolio with respect to SRP. In addition, Lucent has not studied and has no current plans to study its patents with respect to SRP. | | However, in the event that any Lucent patents are determined to be essential to the implementation of SRP as an IETF standards track specification, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license to those patents on reasonable and non-discriminatory terms. | | We sincerely regret any misunderstandings, and hope that the foregoing statement will alleviate concerns about Lucent's commitment to licensing its patents in connection with SRP. | | Thank you, | | Bill Carter | Intellectual Property Manager | Lucent Technologies | 908-582-2156 | [EMAIL PROTECTED] | =================================================== | | Received November 30, 2001 | From: "Carter, William Robert (Bill)" <[EMAIL PROTECTED]> | | | As you are aware, RFC 2945 was neither submitted or proposed by Lucent. | Therefore, Lucent's general patent statement to IETF in 1999 does not cover RFC 2945. | | Lucent may have patent claims that are essential to RFC 2945. But that would have to be verified by a careful review of our patent portfolio. Such a search has not been conducted. Because of the present strain on our resources, it is unlikely that a search will be conducted. However, if the IETF has particular concerns about one or two patents that could impact RFC 2945, we would welcome your identification of those patents and your comments on those issues so that we could review the particular patents in light of RFC 2945. | | Sincerely, | | Bill Carter | Intellectual Property Manager | Lucent Technologies | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3849445#3849445 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3849445 ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
