Re: iSCSI: CHAP and SRP comparison

[Steve Senum <ssenum@cisco.com>]

Paul,

For CHAP:

1. Target authenticates Initiator only is allowed.
2. Target and Initiator authenticate each other is allowed.
3. Initiator authenticates Target only is not allowed.

Regards,
Steve Senum

"CONGDON,PAUL (HP-Roseville,ex1)" wrote:
> 
> 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
> >