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

    Re: iSCSI: SRP status

    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 Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard MS 5668 
    Roseville CA 95747
    ----- Original Message ----- 
    From: "Julian Satran" <>
    To: <>
    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 <>
    > Sent by:
    > 26-03-02 23:37
    > Please respond to David Jablon
    >         To:
    >         cc:
    >         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, 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 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:
    > > . 
    > >
    > >-- 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
    > >         Cell: +1 (978) 394-7754
    > >--------------------------------------------------- 


Last updated: Wed Mar 27 16:18:12 2002
9353 messages in chronological order