SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: CHAP and SRP comparison



    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
    > 
    


Home

Last updated: Tue Sep 04 10:17:10 2001
6323 messages in chronological order