Subject: iSCSI: 7.2.1 CHAP Considerations (12-98)

From: Steve Senum <[email-masked]>
Date: Wed, 12 Jun 2002 13:32:58 -0500

I have a concern over the wording of the
following text from section 7.2.1 (12-98 version):

    When CHAP is used with secret shorter than 96 bits,
    a compliant implementation MUST NOT continue with
    the login unless it can verify that IPsec encryption
    is being used to protect the connection.

I know the above is attempt to "put some teeth" into
the requirements to make the use of CHAP secure,
but I believe there are common cases where the
length of the CHAP secret cannot be verified, such
as when a RADIUS server is being used.

Regards,
Steve Senum

---

From: [email-masked]
Date: Wed, 12 Jun 2002 19:26:07 -0400

Yes, my intent was to modify the draft text to include the
"essential condition" described below.  --David

> -----Original Message-----
> From: Steve Senum [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 6:14 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98)
> 
> 
> David,
> 
> What you state would be better, but that is
> not what the current text (as of 12-98) says.
> 
> Steve Senum
> 
> [email-masked] wrote:
> > 
> > I think the essential condition here is that the
> > "do not continue if secret is shorter than 96 bits"
> > criteria should apply only to implementations that
> > know and use the secret (i.e., generators of CHAP
> > responses, and recipients of those responses that
> > do their own verification as opposed to outsourcing
> > that verification to something like a RADIUS server).
> > 
> > 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
> > [email-masked]         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Steve Senum [mailto:[email-masked]]
> > > Sent: Wednesday, June 12, 2002 3:58 PM
> > > To: Julian Satran
> > > Cc: ietf-ips
> > > Subject: Re: iSCSI: 7.2.1 CHAP Considerations (12-98)
> > >
> > >
> > > Julian,
> > >
> > > In the case where an iSCSI Target is authenticating
> > > an iSCSI Initiator, the Target sends a CHAP
> > > challenge and identifier, and the Initiator sends
> > > back a CHAP response and username.
> > >
> > > In the case were the Target is using the RADIUS
> > > protocol, these four pieces of information are
> > > sent by the Target to a RADIUS server, which
> > > simply gives an accept or reject reply.  The target
> > > never has access to the CHAP secret (which is good),
> > > hence no check can be made on its length.
> > >
> > > Regards,
> > > Steve Senum
> > >
> > > Julian Satran wrote:
> > > >
> > > > can you elaborate? Julo
> > > >
> > > >   Steve Senum <[email-masked]>
> > > >   Sent by: [email-masked]         To:        ietf-ips
> > > >                                  <[email-masked]>
> > > >   06/12/2002 09:32 PM                    cc:
> > > >   Please respond to Steve Senum          Subject:
> > > iSCSI: 7.2.1 CHAP
> > > >                                  Considerations (12-98)
> > > >
> > > >
> > > >

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 13 Jun 2002 19:03:38 +0300

Steve,

Ofer already suggested 2 - I just forgot - so that is fine.

As for the 96 bits - that is a semantic issue - if you know that the 96 
bits you generate are not random (e.g., extend a weak password) then the 
length is not enough.
It is not supposed to check randomness - that is an administration part 
that is specified earlier.

Julo

Steve Senum <[email-masked]>
06/13/2002 06:12 PM
Please respond to Steve Senum

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     ietf-ips <[email-masked]>
        Subject:        Re: iSCSI: 7.2.1 CHAP Considerations (12-98)

Julian,

Better, but I would suggest:

 If an initiator or target generates or verifies a CHAP secret that has 
less
 than 96 random bits then IPsec encryption (according to the 
implementation
 requirements in Section 7.3.2 Confidentiality) MUST be used to protect 
the
 connection. Moreover, in this case IKE authentication with group 
pre-shared
 keys SHOULD NOT be used unless it is not essential to protect group 
members
 against off-line dictionary attacks by other members, and an 
implementation
 MUST NOT continue with the login unless it can verify that IPsec 
encryption
 is being used to protect the connection.

I want to more strongly tie the last requirement to the initial condition.

Further comments on this text:

1. I would suggest changing "96 random bits" to "96 bits".
I don't think it is practical to verify the number of random bits
in a single secret.

2. I would suggest changing the final "MUST NOT" to a "SHOULD NOT".
As with IKE pre-shared keys, the need to protect against off-line
dictionary attacks is ultimately a local deployment consideration.

Regards,
Steve Senum

Julian Satran wrote:
> 
> The text I would suggest in 7.2.1 is:
> 
> If an initiator or target generates or verifies a CHAP secret that has 
less
> than 96 random bits then IPsec encryption (according to the 
implementation
> requirements in Section 7.3.2 Confidentiality) MUST be used to protect 
the
> connection. Moreover, in this case IKE authenti-cation with group 
pre-shared
> keys SHOULD NOT be used unless it is not essential to protect group 
members
> against off-line dictionary attacks by other members. When CHAP is used 
with
> secret shorter than 96 bits, a compliant implementation MUST NOT 
continue with
> the login unless it can verify that IPsec encryption is being used to 
protect
> the connection.
> Julo