Re: iSCSI: SRP status

["Mallikarjun C." <cbm@rose.hp.com>]

FWIW, I share Julian's concerns.  I am concerned that attempts to 
invent a new mechanism will be time-taking, and essentially will leave
us all less knowledgeable about any potential patent overlaps than 
even what we know about SRP today.  I also recall hearing similar 
sentiments expressed at the Minneapolis meeting.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, March 26, 2002 10:52 PM
Subject: Re: iSCSI: SRP status


> David,
> 
> As one of the authors of the discussed draft I would like to thank you for 
> your efforts both in clarifying the position of you company and to clearly 
> pointing out that it is both unwise to act on rumors and to "invent on the 
> spot" an authentication method.  Following the later path we can end 
> having an unproven method and there no guarantee that it is not encumbered 
> by patents - both of which can happen regardless of the expertise and 
> intentions of the participants in the effort.
> 
> Regards,
> Julo
> 
> 
> 
> 
> David Jablon <dpj@theworld.com>
> Sent by: owner-ips@ece.cmu.edu
> 26-03-02 23:37
> Please respond to David Jablon
> 
>  
>         To:     Black_David@emc.com
>         cc:     ips@ece.cmu.edu
>         Subject:        Re: iSCSI: SRP status
> 
>  
> 
> 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
> >--------------------------------------------------- 
> 
> 
> 
>