SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: SRP vs DH-CHAP




    I agree that we should reconsider SRP as a MUST implement.  Julo
    ----- Forwarded by Julian Satran/Haifa/IBM on 04-04-02 13:48 -----
    "Mallikarjun C." <cbm@rose.hp.com>
    Sent by: owner-ips@ece.cmu.edu

    03-04-02 03:26
    Please respond to "Mallikarjun C."

           
            To:        <ips@ece.cmu.edu>
            cc:        
            Subject:        iSCSI: SRP vs DH-CHAP

           


    All:

    As we all know, there is an effort underway to DH-enhance the
    CHAP protocol, or perhaps invent a new authentication mechanism
    as "MUST implement" in lieu of SRP.  I have a couple of comments
    in this regard.

    - Given that Lucent's new clarification came after Minneapolis, let's
      consider the possibility that several/most WG participants are now
      favorably inclined to go with SRP as the "MUST implement".  Can
      folks with continuing concerns on SRP please speak up? [ This is *not*
      a legal advice; but HP's lawyers do not see any issues for Hewlett-Packard
      in the area of SRP. ]

    - I find the statement that IESG would send back the iSCSI draft if
      it thinks that a sufficient analysis hadn't been done on DH-CHAP
      to be surprising to say the least.  If SRP meets the needs (more on this
      in the next bullet) and SRP has an IPR situation that's deemed
      acceptable from IETF's perspective (let's recall that SRP is a
      standards track RFC), why would IESG return the iSCSI spec back?
      [ To provide the context for this question, consider that EMC is in
        a similar situation with iSCSI - http://www.ietf.org/ietf/IPR/EMC-IPS
      - using generally the same language as we had seen with Lucent. ]

    - A procedural question in this regard is the seeming lack of
      documented requirements for the authentication mechanism.  I
      don't really see a list of requirements stated in the security draft,
      even though there's general text that discusses some issues.  (BTW,
      the iSCSI requirements draft (rightly) does not go to the depth we're
      seeking here). I am equally to blame for this, but I was under the
      impression that we had a list of *documented* requirements to
      evaluate candidates - and we chose SRP.  I was somewhat surprised
      to see that we now seem to be defining/weakening requirements afresh
      in some of the recent email threads I had seen.  I admit that I am not
      a security expert, but I am personally not _yet_ clear on the requirements....
    --
    Mallikarjun


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

     


    ----- Forwarded by Julian Satran/Haifa/IBM on 04-04-02 13:48 -----
    John Hufferd/San Jose/IBM@IBMUS
    Sent by: owner-ips@ece.cmu.edu

    31-03-02 00:44
    Please respond to John Hufferd

           
            To:        ips@ece.cmu.edu
            cc:        
            Subject:        iSCSI:SRP

           


    Folks,
    With the new statement from Lucent, we are now back to the point were we
    were previously when we agreed to make SRP Must implement.

    I propose that we go to the position we had before all this flap developed
    about patent statement, and declare SRP MUST implement (as we did before),
    and get that out of the way of our last call.

    The code is available from Stanford's web site, and the Patent issue is now
    just like others within the IETF.

    I know there are some folks that are attempting to wrap additional security
    around Chap, and that may be a good thing -- but we do not need to hold up
    Last call as folks check out other options.  Remember, it is always the
    quickly produced "fixes" at the last moment, that have a higher probability
    of having a problem.

    Again, lets make SRP Must implement, and Chap at least May implement,
    declare the proposed additional Chap security as May Implement, and move
    on.

    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com




Home

Last updated: Fri Apr 05 11:18:34 2002
9524 messages in chronological order