SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: CHAP and SRP comparison



    
    While CHAP is one-way authentication, it can effectively be run twice
    (challenged from either side) as is shown in the examples in the appendix -
    right?
    
    Paul
    
    +--------------------------+----------------------------+
    + Paul Congdon             + Email: paul_congdon@hp.com +
    + Hewlett Packard Company  + Mail Stop:  5662           +
    + HP ProCurve Networking   + Phone:  (916) 785-5753     +
    + 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
    + Roseville, CA   95747    + Mobile: (916) 765-4056     +
    +--------------------------+----------------------------+
    
    > -----Original Message-----
    > From: Mark Bakke [mailto:mbakke@cisco.com]
    > Sent: Tuesday, September 04, 2001 7:00 AM
    > To: Black_David@emc.com
    > Cc: ips@ece.cmu.edu
    > Subject: Re: iSCSI: CHAP and SRP comparison
    > 
    > 
    > David-
    > 
    > Thanks.  Those were the details that I'd seen somewhere but
    > forgotten.
    > 
    > The way to help with the second issue is to store the passwords
    > on a RADIUS server instead of on the target itself.  This is
    > what most users of CHAP would do; if passwords are stored directly
    > on the target, SRP would be a better choice.
    > 
    > --
    > Mark
    > 
    > Black_David@emc.com wrote:
    > > 
    > > Quick CHAP comparison to SRP:
    > > 
    > > - CHAP is vulnerable to an off-line dictionary attack in which
    > >         the attacker captures the traffic and tries passwords
    > >         from a dictionary.  SRP is not.
    > > - CHAP requires that the password be available as a password
    > >         on the Target.  SRP requires only a password verifier
    > >         from which the password is not readily recoverable.
    > > - CHAP is one-way authentication, SRP is bidirectional
    > >         because the Target demonstrates that it knows the verifier.
    > > 
    > > IPsec can take care of the first issue by providing an
    > > encrypted channel (attacker has to break the IPsec encryption
    > > key before mounting the dictionary attack against CHAP), and
    > > the third issue by having IKE handle the authentication
    > > in the other direction.  It doesn't help with the second issue,
    > > which is more of an administration issue than a protocol
    > > vulnerability.
    > > 
    > > --David
    > > 
    > > > -----Original Message-----
    > > > From: Mark Bakke [mailto:mbakke@cisco.com]
    > > > Sent: Friday, August 31, 2001 1:49 PM
    > > > To: John Hufferd
    > > > Cc: Bill Strahm; Ips@Ece. Cmu. Edu
    > > > Subject: Re: ISCSI: User authentication vs. Machine 
    > Authentication for
    > > > iSCSI
    > > >
    > > >
    > > > John-
    > > >
    > > > Just wanted to point out that CHAP does not send passwords
    > > > in the clear; it hashes them.  The reason that SRP was chosen
    > > > as the MUST over CHAP is that in a non-IPsec environment,
    > > > the CHAP exchange is not as robust as SRP's exchange, and is
    > > > more vulnerable to some types of attacks (I can't remember
    > > > which ones off-hand).  IPsec provides an authenticated
    > > > environment in which to do the CHAP exchange, which takes
    > > > care of these potential problems.
    > > >
    > > > --
    > > > Mark
    > > >
    > > > John Hufferd wrote:
    > > > > 3. Chap can  be used in this environment since the Link is
    > > > already secure
    > > > > and encrypted, and sending the password in what otherwise
    > > > would have been
    > > > > in the clear, is protected by the link encryption.
    > > >
    > > > --
    > > > Mark A. Bakke
    > > > Cisco Systems
    > > > mbakke@cisco.com
    > > > 763.398.1054
    > > >
    > 
    > -- 
    > Mark A. Bakke
    > Cisco Systems
    > mbakke@cisco.com
    > 763.398.1054
    > 
    


Home

Last updated: Tue Sep 04 19:17:07 2001
6339 messages in chronological order