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

    iSCSI: SRP status

    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
    	- 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  There is no cost to
    	the license.  No payments are due to Stanford under the license and
    	the license does not contain any reciprocal grant of rights back to
    (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
    	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
    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: . 
    -- 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
    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
    - 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.
    --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         Cell: +1 (978) 394-7754


Last updated: Tue Mar 26 13:18:16 2002
9305 messages in chronological order