SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Last Call process



    > Excerpt of message (sent 4 April 2002) by Black_David@emc.com:
    > > > I'm pretty unhappy about this.  What I see is that, at the last
    > > > minute, a new protocol is introduced (DH-CHAP), and we're suddenly
    > > > being told that iSCSI has been made dependent on that new protocol.
    > > 
    > > It has not been made dependent; the WG has been instructed to consider
    > > DH-CHAP, but has *not* been instructed to use it.  For example, if the
    > > DH-CHAP proposal falls apart on technical grounds shortly after the
    > > Internet-Draft appears, that'll be the end of our consideration of it.
    > 
    > Is "consideration" valid if we only consider draft 00?  Or, if
    > technical issues are found in draft 00, are we then obliged to
    > consider up to draft N, for some N > 0?
    
    Fair consideration is required, and to some extent this falls into
    the "I know it when I see it" category.  If I rephrase the second
    question to ask about "arbitrary N > 0", instead of "some N > 0",
    the answer is definitely "no".  If DH-CHAP doesn't work or is a
    non-starter for some other reason and we're looking at interminable
    revisions and consumption of time to fix DH-CHAP, it's out.  
    For a worked example of this, look back at our consideration of COWS,
    although I would anticipate dealing with DH-CHAP in a shorter period
    of time (a few weeks at most is what I have in mind).
    
    > > > Why isn't that a decision for the WG to make?
    > > 
    > > Because the IESG has made that decision.  If the WG wants to get into a
    > > process fight with the IESG over who gets to make that decision, the
    > > resulting delays will dwarf anything that could result from
    consideration
    > > of DH-CHAP.  I would not advise this course of action.
    > 
    > When and where did the IESG make that decision?  Is there some message
    > from the IESG that documents the decision?  Is there a BCP that
    > describes the decision?
    
    As with much AD/IESG guidance, this is the result of communication
    between the AD(s) and WG chair(s).  If you want a formal statement
    of instruction, I can try to get one, but it'll take at least a month
    to do so, and somehow I don't think the WG wants to wait for that month ...
    
    > > The IPR issue has not been 100% resolved.  Please re-read:
    > > 
    > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09466.html
    > 
    > Ok, so that says that there isn't a commitment for a free license, if
    > a license from Phoenix and/or Lucent should turn out to be required.
    > In what way does that not resolve the IPR issue?  Pat Thaler quoted
    > the IPR section of the RFC process; it does not mention free
    > licensing, only non-discriminatory licensing.
    
    And I have subsequently pointed out both Section 6.1.2 of RFC 2026
    and Section 6.4.5 of RFC 3160.  All three are relevant to this topic.
    
    <HINT> If folks would quit wasting list bandwidth on these process
    issues, I'd have more cycles to go work on the DH-CHAP I-D. </HINT>
    
    The following questions from Paul are good and germane (and definitely
    NOT a waste of list bandwidth):
    
    > I'm not sure I precisely know the security properties that DH+CHAP
    > aims for.  Obviously, a superset of what classic CHAP has.  Is the
    > goal to match SRP, or to deliver a subset of what SRP provides?  
    
    CHAP + prevent a passive eavesdropper from collecting information
    sufficient to mount an off-line dictionary attack.
    
    > What I'm struggling with is this: what set of properties of SRP, and
    > properties of DH-CHAP might we observe when the draft comes out that
    > would cause us to pick DH-CHAP over SRP when we do the
    > "consideration"?  I don't see a plausible scenario right now that
    > would produce that outcome.  That's one reason why I'm not happy with
    > what we're going through right now; it has a bit of a "rock fetching"
    > feel to it rather than what it should be, a technical analysis.
    
    DH-CHAP cannot possibly match the security properties of SRP in
    full generality - DH-CHAP is fundamentally vulnerable to an
    active attack that yields the CHAP information required to mount
    an off-line dictionary attack, whereas SRP is immune to this sort
    of thing.  If one wants to run a dictionary against SRP, one has to
    perform an SRP exchange complete with its exponentiations for each
    attempt, knowing full well that the other side is liable to log this
    unusual activity (massive numbers of failed authentications)
    and get suspicious.
    
    The question facing the WG is to consider the ways
    in which DH-CHAP falls short of SRP and to make the case for
    whether they justify or fail to justify the use of SRP given its
    status as potentially encumbered technology.
    
    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 04 17:18:22 2002
9506 messages in chronological order