[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    SRP IPR Update Presentation

    Here is the entire text of the Update presentation I
    gave on SRP Intellectual Property Rights.  I'm also
    about to post the letter to the list and recommend
    that it be read in its entirety as opposed to relying
    on the summary excerpts in this presentation.
    SRP Intellectual Property Rights Update
    David Black, IP Storage WG co-chair
    February 7, 2002
    Huntington Beach, CA
    -- Note Well
    All statements related to the activities of the IETF and addressed to the
    IETF are subject to all provisions of Section 10 of RFC 2026, which grants
    to the IETF and its participants certain licenses and rights in such
    Such statements include verbal statements in IETF meetings, as well as
    written and electronic communications made at any time or place, which are
    addressed to:
    - the IETF plenary session.
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB, or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself, any working group
    or design
      team list, or any other list functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function.
    Statements made outside of an IETF meeting, mailing list or other function,
    that are clearly not intended to be input to an IETF activity, group, or
    function are not subject to these provisions.
    -- Disclaimer
    I am NOT a lawyer
    This is NOT legal advice
    If you need legal advice ...
    You need to talk to a lawyer
    If actions or decisions based on information in this presentation have legal
    Those consequences are YOUR responsibility
    The IETF and yours truly disclaim all responsibility
    -- IETF Policy: Intellectual Property and Contributions
    RFC 2026, Section 10.3.1, Clause 6:
    6. The contributor represents that he has disclosed the existence of any
    proprietary or intellectual property rights in the contribution that are
    reasonably and personally known to the contributor.  The contributor does
    not represent that he personally knows of all potentially pertinent
    proprietary and intellectual property rights owned or claimed by the
    organization he represents (if any) or third parties.
    This is an obligation to disclose.
    Includes things you should know.
    How to disclose:
    -- IETF Policy: Intellectual Property Rights Claims (I)
    RFC 2026, Section 10.3.2, Clause (A):
     (A)  Where any patents, patent applications, or other proprietary rights
    are known, or claimed, with respect to any specification on the standards
    track, and brought to the attention of the IESG, the IESG shall not advance
    the specification without including in the document a note indicating the
    existence of such rights, or claimed rights.
    If rights are known or claimed, the RFC will say that the IETF has been
    As of the date the RFC is published
    Nothing specific about the claim(s)
    -- IETF Policy: Intellectual Property Rights Claims (II)
    RFC 2026, Section 10.3.2, Clause (B):
     (B)  The IESG disclaims any responsibility for identifying the existence of
    or for evaluating the applicability of any claimed copyrights, patents,
    patent applications, or other rights in the fulfilling of the its
    obligations under (A), and will take no position on the validity or scope of
    any such rights.
    No IETF obligation to identify claims.
    The IETF takes no positions on validity or scope.
    -- IETF Policy: Intellectual Property Rights Claims (III)
    RFC 2026, Section 10.3.2, Clause (C):
    (C)  Where the IESG knows of rights, or claimed rights under (A), the IETF
    Executive Director shall attempt to obtain from the claimant of such rights,
    a written assurance that upon approval by the IESG of the relevant Internet
    standards track specification(s), any party will be able to obtain the right
    to implement, use and distribute the technology or works when implementing,
    using or distributing technology based upon the specific specification(s)
    under openly specified, reasonable, non-discriminatory terms.
    Attempt to obtain promise, response not required.
    Promises are recorded at: .
    -- SRP and iSCSI Context
    iSCSI currently REQUIRES SRP
    SRP = Secure Remote Password, RFC 2945
    Rumors of patent claims covering SRP
    Goal: Avoid basing decisions on rumors
    Make information available to reduce uncertainty
    Non-goal (still): Determine SRP requirement now
    Insufficient time for technical/legal analysis of new information by WG
    -- Stanford
    Has filed for a patent on SRP
    No-cost licenses are available
    Explicitly references RFC 2945
    Unidirectional license, not reciprocal
    -- Lucent: EKE Patents
    In December at the Salt Lake City mtg., Elizabeth Rodriguez, speaking as a
    Lucent employee said:
    - Lucent is researching whether the EKE patents (US 5,241,599 and US
      or any other Lucent patents are essential to SRP implementation.  
    - If patent(s) is/are found that is/are determined to be necessary to SRP
      implementation, Lucent will license the Intellectual Property under normal
      Lucent licensing practices.
    Lucent has subsequently changed their position(s)
    Details on next slide
    -- Lucent: EKE patents (II)
    This morning (Feb. 7), a Lucent employee speaking on behalf of Lucent told
    me that:
    - Lucent will not proceed with research on the EKE patents.
    - Lucent will not take a public position on whether the EKE patents apply to
    - Lucent takes the position that SRP implementers are responsible for their
      technical and legal analysis.
    - Lucent will license the EKE patents under normal Lucent licensing
    Caveat: This is based on my understanding of the (oral) conversation.
    -- Phoenix: SPEKE patent
    A Letter was received yesterday (Feb. 6) from David Jablon, CTO of Phoenix,
    regarding the SPEKE patent:
    US 6,226,383 (2001): Cryptographic methods for remote authentication
    Paragraphs relevant to SRP on next 3 slides
    Entire text of the letter will be posted to the mailing list shortly (if in
    doubt, read that).
    -- Phoenix: SPEKE letter text (I)
    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: SPEKE letter text (II)
    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.
    Note: RFC 2945 specifies SRP.
    -- Phoenix: SPEKE letter text (III)
    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
    -- Next Steps
    Clarification questions: Ok to ask here
    Technical questions/discussion: IPS mailing list
    NOTE: cryptographic and legal expertise are needed to understand these
    - Request (1): Please obtain expertise before posting
    - Request (2): Please wait for text of this talk to be posted to the list
      (will happen in next day or so)
    SRP requirements level: Minneapolis IETF meeting
    - There will be no further postponements of this issue!!


Last updated: Mon Feb 11 01:18:02 2002
8720 messages in chronological order