SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI:SRP



    
    As I stated in Minneapolis, SRP is the best solution and now it has a clear
    IP framework.
    We should go back to where we started and make SRP MUST implement and get on
    with last call.
    
    I would question the need to complete some "alternatives" analysis given the
    IP clarifications.
    
    As I also stated in the plenary, using "open source community likes it" is
    not an "official IETF criteria" for making technical decisions (at least I
    can not get anyone to write it down anywhere).  The IP language in RFC 2026
    provides the official framework for dealing with IP issues.  Best as I can
    tell, we have met all of the RFC 2026 criteria regarding use of SRP.
    
    Howard
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Thursday, April 04, 2002 10:15 AM
    To: Bill Strahm
    Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu
    Subject: Re: iSCSI:SRP
    
    
    
    Bill,
    At the IETF Plenary meeting in Minneapolis, David, I and some others pushed
    the IPR issue.  They said that the Workgroup should define the correct
    technical solution, and not take the IPR stuff as a significant issue, (as
    long as the Reasonable and Non- discriminatory stuff is part of the
    considerations).  We are at that point now that we have Lucent's new
    Statements.   The IPR stuff should only be an overt issue when their are no
    responsible statements issued by the IPR holders.  Since we can not tell if
    the claims are valid, or even apply, or if there is some other IPR issue
    that will come out in the future, we should be picking the best technology,
    to which we can get consensus.
    
    Now, I personally believe, as you mentioned in your note, that the right
    way to do this is to have the SRP as a SHOULD implement.  But at
    Minneapolis I brought that up and was shot down by the AD, and he told us
    that IPR could not be a valid reason for using the SHOULD word.  "SHOULD"
    we were told should be used for technical reasons.  That is, the following
    statement in RFC2119, is being interpreted as being focused on the
    technical:
    
    "SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course."
    
     Therefore, if it is possible that there is a technical reason that a
    vendor could not or does not implement a feature, which would otherwise be
    a MUST, then the use of SHOULD is acceptable.  If anyone has a technical
    reason that SRP may not, or should not be implemented on some vendors
    offerings, then SHOULD could be OK.
    
    I could also accept a MUST for CHAP, because of its wide spread install
    base.  But I think we should probably have a MAY with DH+CHAP, even if it
    is political, in the MAY position I do not believe it can hurt us, and if
    it ends up well, it can be a good thing.
    
    Again if we have a technical reason for SRP to be a SHOULD instead of a
    Must, we can factor that in.
    
    Without that technical reason for SRP being a SHOULD, I believe, that
    because of its stronger security features we should make SRP a MUST.  And
    since I still think that CHAP is useful, my above arguments lead me to SRP
    MUST, CHAP MUST and DH-Chap as MAY.
    
    It is possible, in the real world that if a vendor, has a problem with
    Licensing SRP, that  vendor's product will put an * in their ads and their
    product boxes, with marketing words, which state that their product is
    iSCSI is compatible with RFC # 123456*, and then they will put in a few
    words at the bottom of the package that read as "* except for SRP".   In
    that case we still need to interoperate and that will mean that Chap is
    required  -- Hence my position on Must implement for Chap.
    
    There is one other worry I have about Chap and DH-Chap.  Though we were
    only asked to "consider" DH-Chap, I think the implication was to consider
    it to solve the MUST problem.  Now that David thinks he has a working
    DH-Chap proposal, I am afraid that the ADs will see the proposal as a valid
    way to get a stronger Chap, and not let plain Chap be the only MUST.  If
    that happens we will be stuck with an unproven DH-CHAP as the only MUST.
    And that worries me a lot.
    
    OK, this was a round about way of saying, SRP as MUST implement since we
    know that is Strong, therefore we can not be compelled to take DH-CHAP as a
    MUST.  Then CHAP as a MUST or SHOULD ensures interoperability with all the
    systems that currently exploit CHAP and want to require it also for iSCSI
    (and with the "*" implementations).  And DH-Chap as MAY, to give us ongoing
    additional protection for CHAP implementations that exploit it.
    
    I used SHOULD as an option for CHAP (above), since if there is another
    technical superior technique (SRP), a vendor may feel that his products
    only sells into the more secure environments, and that CHAP would lower the
    products total security, and therefore, have a valid technical reason to
    not implement CHAP.  (Unfortunately, I can not make exactly the same case
    for SRP, since it is technically superior to CHAP).
    
    Marjorie objects to having CHAP as a (second) MUST, and you, Bill, object
    to SRP as a MUST.  We really need to come to closure, so let me offer some
    options:
    
    1. SRP MUST, CHAP MUST, DH-CHAP MAY
    2. SRP SHOULD, CHAP MUST, DH-CHAP MAY (need technical reason for the SRP
    not being MUST)
    3. SRP MUST, CHAP SHOULD, DH-CHAP MAY (for those folks that do not want two
    MUSTs)
    4. SRP MUST, CHAP MAY, DH-CHAP MAY
    5. SRP MAY, CHAP MUST, DH-CHAP MAY (we must feel comfortable that it will
    not morph into option 5)
    6. SRP MAY, CHAP MAY, DH-CHAP MUST  (this one worries me the most)
    
    I can support 1, 2, 3, or 4.  and favor 4 since that is close to were we
    were before, the Lucent issue bit us, and now that it is settled, we can go
    back to the previous agreement (plus DH-CHAP). My second choice would be 1,
    and my third choice is 3.  However, if we have a technical reason for SRP
    being SHOULD, number 2 would jump to the top of my favorite list.
    
    Perhaps some of you folks could vote on your top 3.  (I say top 3 since we
    may be able to find a choice that is acceptable by most folks even if not
    on the top of most folks' list.)
    
    
    
    .
    .
    .
    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
    
    
    Bill Strahm <bill@strahm.net> on 04/03/2002 11:10:29 AM
    
    To:    John Hufferd/San Jose/IBM@IBMUS
    cc:    Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu
    Subject:    Re: iSCSI:SRP
    
    
    
    I am confused John,
    
    The reason we are looking at things beyond SRP is that there MAY be IPR
    issues
    with SRP.  Because of that the WG will consider algorithms that MAY NOT
    have
    IPR issues such as CHAP.
    
    I am not a fan of SRP from many reasons, but I will say that it is
    considerably
    stronger than CHAP.  For that reason, if I MUST implement it, why should I
    also
    include a weaker algorithm, I all ready have to play the price to licence
    SRP.
    
    I would argue that CHAP should me the sole MUST implement, because it is
    open
    and free, from there we can have SRP as a SHOULD and don't mention CHAP+DH
    at
    all because it will have all of the problems that SRP has, until it is
    vetted.
    
    Bill
    On Wed, Apr 03, 2002 at 09:37:53AM -0800, John Hufferd wrote:
    >
    > David,
    > I think we need to lower our exposure here.  I suggest SRP as Must
    > Implement, Chap (as it is today) as Must implement, and a pointer to the
    > new draft your are making for DH+Chap, as a MAY implement.
    >
    > They asked us to "consider" DH+Chap but it was not a hard requirement,
    you
    > told us that they would accept Chap, but wanted us to consider a way to
    > make it more secure.  I think the work that has been done, is clearly
    > considering it, and with the combination of SRP and current Chap clearly
    > meets requirements.  If DH+Chap end up with some problems we will not be
    > impacted.  And if DH+Chap works, I think it will attract a lot of
    > attention, and many folks will use it.  I can even accept DH+Chap as a
    > SHOULD implement, as long as it does not hold us up and it looks
    > reasonable.  That would at least give us an out if we find an important
    > technical hold, etc.
    >
    > So, SRP MUST, Chap today as MUST, and DH+CHAP as MAY or if necessary,
    > SHOULD --   But we need to put this to bed, right away.
    >
    > .
    > .
    > .
    > 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
    >
    >
    > Black_David@emc.com@ece.cmu.edu on 04/03/2002 07:45:12 AM
    >
    > Sent by:    owner-ips@ece.cmu.edu
    >
    >
    > To:    marjorie_krueger@hp.com
    > cc:    ips@ece.cmu.edu
    > Subject:    RE: iSCSI:SRP
    >
    >
    >
    > Marjorie,
    >
    > > I don't see your reasoning here David, please explain.  As Mallikarjun
    > says,
    > > it's up to this WG to decide what the authentication reqmts are for
    iSCSI
    > > and choose a protocol.  Why would the IESG second guess that?
    >
    > See Section 6.1.2 of RFC 2026 where the IESG is responsible for
    "technical
    > quality" of RFCs, and the discussion of this in my response to
    Mallikarjun.
    > If I replace the word "authentication" with "confidentiality", in the
    > above text, I observe that we've been through a worked example of the
    IESG
    > exerting its authority to set security requirements.
    >
    > > If that's the case, perhaps there's an unknown, unbounded list of
    > > authentication protocols that we haven't considered that the IESG will
    > > make us go back and consider?
    >
    > I don't believe so - my understanding is that consideration of
    > DH-strengthened CHAP will be sufficient.  For example, I see little need
    > to investigate the notion of a signed CHAP challenge that was lurking
    > in one of Ted Ts'o's posts - if the signing keys are available, one of
    > the SPKM methods should be used instead.
    >
    > > It's my understanding that DH-strenghthened CHAP is only "proposed",
    not
    > > currently standard (not even a draft)?  So I can't believe the IESG
    will
    > > make us go consider requiring a draft in our proposed standard, that's
    > > against their own stated rules?
    >
    > Internet-Draft coming soon, I hope, after expert review of the proposal's
    > cryptographic soundness.  FWIW, I agree with Paul Koning's concerns:
    >
    > > I'm definitely not the world's greatest fan of SRP, but I much prefer
    > > a requirement for an existing RFC (even if not yet widely implemented)
    > > over a diversion towards a not yet defined, not yet analyzed, new
    > > protocol with unknown security properties.
    >
    > IMHO, DH-strengthened CHAP will fly only if it is a sufficiently
    > straightforward combination of DH and CHAP that reasonable confidence
    > can be obtained in it without the need for the years of public scrutiny
    > that are required for major new security mechanisms/protocols.  From
    > a procedural standpoint, that has to be the case in order to advance
    > the definition through this WG as opposed to one in the Security Area.
    >
    > At the moment, I'm taking much of the responsibility for writing up
    > DH-CHAP because somebody has to do it.  Please keep in mind that the
    > last time I wrote this class of thing up (SRP key generation for ESP,
    > last summer), the WG decided not to pursue it.  So don't assume that the
    > "fix is in" because I'm one of the WG chairs, but please take seriously
    > the responsibility to give the proposal a fair hearing when it appears.
    >
    > I'd really like to get the DH-CHAP Internet-Draft out this week, but
    > that's starting to look dicey; it will appear by the end of next week,
    > come h*** or high water.  I'm not 100% thrilled about this situation,
    > but I am certain that a procedural battle with the IESG is not the
    > best way out of it.
    >
    > Thanks,
    > --David
    > ---------------------------------------------------
    > 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
    > ---------------------------------------------------
    >
    >
    >
    
    
    


Home

Last updated: Thu Apr 11 08:18:35 2002
9593 messages in chronological order