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

From: "Julian Satran" <[email-masked]>
Date: Thu, 13 Jun 2002 16:28:10 +0300

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

Ofer Biran/Haifa/IBM@IBMIL
Sent by: [email-masked]
06/13/2002 11:53 AM
Please respond to Ofer Biran

        To:     [email-masked]
        cc:     [email-masked], [email-masked]
        Subject:        RE: iSCSI: 7.2.1 CHAP Considerations (12-98)

How about:

  When CHAP is used with secret shorter than 96 bits,
  a compliant implementation MUST NOT continue with
  the login step in which it should send a CHAP response
  (CHAP_R - see 10.5) unless it can verify that IPsec
  encryption is being used to protect the connection.

On initiator-only authentication this puts the responsibility
only on the initiator implementation who surely knows the
secret and its length.

  Regards,
     Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

[email-masked]@ece.cmu.edu on 13/06/2002 02:26:07

Please respond to [email-masked]

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    RE: iSCSI: 7.2.1 CHAP Considerations (12-98)

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)
> > > >
> > > >
> > > >
> > > > 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: Steve Senum <[email-masked]>
Date: Thu, 13 Jun 2002 10:12:41 -0500

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:
> 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
>

---

From: Paul Koning <[email-masked]>
Date: Thu, 13 Jun 2002 12:37:46 -0400

> I don't think it is practical to verify the number of random bits

That's certainly true.
 
> dictionary attacks is ultimately a local deployment consideration.

I agree.

    paul