Re: iSCSI: SRP status

[David Jablon <dpj@theworld.com>]

David,

Here are a few points to add to this summary of recent
events regarding SRP.

The first is simply that the just-posted policy letter from
Phoenix legal was presented and discussed in Minneapolis.
While I won't attempt to summarize that discussion here,
I have relayed the concerns expressed back to Phoenix.

A second point is a delicate one, related to larger IETF
policy in general. Concern was expressed at the meeting that
the WG appears to be changing the content (if not the
requirements too) of a proposed standard, based on
unconfirmed rumor.

The fact that a patent holder has refused to confirm or deny
such rumors, or provide a license policy statement, is
surely a concern.  But this concern may mask a pernicious
problem.  Such WG behavior allows anyone to start
unresolvable rumors of potential patent coverage in order to
steer a group in arbitrary directions.  Unfortunately, IETF
policy and tradition make open discussion of the legitimacy
of such rumors very difficult.

Concern was expressed at the meeting about security
dangers inherent in designing a new method, such as some
kind of mutually-authenticating variant of CHAP.  Even
beyond the security concerns, it may be impossible for the
group to determine that a newly proposed method is patent-
free.  The standard practices of using evidence of
surviving years of cryptographic review to establish
security, or commercial use to establish unencumbrance,
both may not work for methods still-to-be described.

The draft-jablon-speke-00.txt presented to the WG on this
list and at the meeting specifically describes methods that
provide the benefits of SRP, but are less structurally
related to EKE.  It describes methods that have survived
5 years of public scrutiny, that achieve higher goals than
the just-proposed alternatives, and that have been
commercially deployed without licensing another
organization's patents.

In presenting this information, I am clearly staying within
the guidelines of longstanding written IETF policy, but
clearly coming up against IETF tradition in talking as
openly as possible about such sensitive issues.

I hope that the group will carefully consider these methods,
in addition to any soon-to-be proposed variants of CHAP
or Diffie-Hellman, as they review their security and
functionality objectives.

Furthermore, in light of the repeated attempts to get
another company to clarify or simplify it's license
position, I would hope that any group or individual with
concern about the Phoenix position will make their concerns
known to the company, or to me personally, and I'll do my
best to get an acceptable response.

-- David Jablon


At 05:24 PM 3/25/02 -0500, Black_David@emc.com wrote:
>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
>black_david@emc.com         Cell: +1 (978) 394-7754
>---------------------------------------------------