SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: DH-CHAP (correction)



    
    A correction to my previous post:
    
    "...should not cause the WG to change for something technically deficient."
    
    The "technically deficient" phrase is an error - what I wanted to say is -
    technically inferior due the deficiency mentioned.
    
      Regards,
        Ofer
    
    
    Ofer Biran
    Storage and Systems Technology
    IBM Research Lab in Haifa
    biran@il.ibm.com  972-4-8296253
    
    
    ---------------------- Forwarded by Ofer Biran/Haifa/IBM on 13/04/2002
    23:31 ---------------------------
    
    Ofer Biran/Haifa/IBM@IBMIL@ece.cmu.edu on 13/04/2002 17:44:56
    
    Please respond to Ofer Biran/Haifa/IBM@IBMIL
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    David Jablon <dpj@theworld.com>
    cc:    David Black <Black_David@emc.com>, <ips@ece.cmu.edu>,
           <ElizabethRodriguez@ieee.org>, <Elizabeth.G.Rodriguez@123mail.net>
    Subject:    Re: iSCSI: DH-CHAP
    
    
    
    
    David,
    
    Being that 'participant' I'd like to clarify that my comments (that
    were not that private as the security team was copied) were on an
    earlier rough draft David Black posted to the security team just few days
    before posting to the general IPS list, and apart from that I'm not aware
    of '[closed] design process' on the security team for DH-CHAP.
    
    My main comment was about active impersonation + off line dictionary
    attack and a misleading text (in my view) that ignored this attack. The
    final version now clearly describes it both in the overview and section 6.
    
    I also commented that getting a password can cause much more damage
    than connection hijack after login phase, and this is also mentioned in
    section 6.5.
    
    So one has to admit that the draft states fairly and clearly the main
    DH-CHAP deficiency - vulnerability to active dictionary attack.
    
    Now - the WG should decide whether the 'IP issue' of SRP is a good enough
    reason to replace it with another mandatory method, introducing this
    deficiency. SRP was originally chosen over CHAP due to the risk of an
    attacker obtaining the password. DH-CHAP only makes that attack 'networkly'
    more difficult, but still possible. As I understand it, the IP situation
    of SRP (free license of the actual patent, 'reasonable and
    non-discriminatory' IETF statements for the patents that were brought up as
    'might be related'), according to the IETF policy, should not cause the WG
    to change for something technically deficient.
    
    I currently vote for putting DH-CHAP as another MAY method (it does provide
    valuable resilience over CHAP in certain environments, and the draft seems
    in a pretty good shape), unless somebody convince me that I misunderstood
    the
    SRP IP situation and/or the IETF policy.
    
    
       Regards,
         Ofer
    
    
    Ofer Biran
    Storage and Systems Technology
    IBM Research Lab in Haifa
    biran@il.ibm.com  972-4-8296253
    
    
    
    
    
    


Home

Last updated: Mon Apr 15 01:18:24 2002
9663 messages in chronological order