SRP IPR Update Presentation

[Black_David@emc.com]

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.

Thanks,
--David

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
statements.
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
consequences
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: www.ietf.org/ipr.html

-- 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
notified.
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: www.ietf.org/ipr.html .

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

-- Stanford

Has filed for a patent on SRP
No-cost licenses are available
http://otl.stanford.edu/pdf/97006.pdf
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
5,440,635)
  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
SRP.
- Lucent takes the position that SRP implementers are responsible for their
own
  technical and legal analysis.
- Lucent will license the EKE patents under normal Lucent licensing
practices.

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
techniques.

-- Next Steps

Clarification questions: Ok to ask here
Technical questions/discussion: IPS mailing list
NOTE: cryptographic and legal expertise are needed to understand these
patents
- 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!!