iSCSI: 7.2.1 CHAP Considerations (12-98)

["Julian Satran" <Julian_Satran@il.ibm.com>]

Sounds reasonable - julo

Julo

Ofer Biran 06/29/2002 11:15 PM

To:        Julian Satran/Haifa/IBM@IBMIL         cc:                 From:        Ofer Biran/Haifa/IBM@IBMIL         Subject:        Re: [PRIVATE] Re: iSCSI: 7.2.1 CHAP Considerations (12-98)

Julian,

I suggest to change to the version that was more acceptable by Steve, i.e.

Change:

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

to:

A compliant implementation SHOULD NOT continue with the login step
in which it should send a CHAP response (CHAP_R - Section 10.5
Challenge Handshake Authentication Protocol (CHAP)) unless it can
verify that either the CHAP secret is at least 96 bits, or that
IPsec encryption is being used to protect the connection.


Regards,
   Ofer


Ofer Biran
Storage and Systems Technology   
IBM Research Lab in Haifa   
biran@il.ibm.com  972-4-8296253
---------------------- Forwarded by Ofer Biran/Haifa/IBM on 29/06/2002 21:25 ---------------------------

Please respond to Steve Senum <ssenum@cisco.com>

To:        Ofer Biran/Haifa/IBM@IBMIL
cc:        Julian Satran/Haifa/IBM@IBMIL
Subject:        Re: [PRIVATE] Re: iSCSI: 7.2.1 CHAP Considerations (12-98)



Ofer,

I understand the conditions for moving to mandatory CHAP
for iSCSI.  I have concerns though over trying to
add new requirements (implied or otherwise) on a protocol
that has been around for as long as CHAP has.

In any case, I do think your revised wording is better:

> A compliant implementation SHOULD NOT continue with the login step
> in which it should send a CHAP response (CHAP_R - Section 10.5
> Challenge Handshake Authentication Protocol (CHAP)) unless it can
> verify that either the CHAP secret is at least 96 bits, or that
> IPsec encryption is being used to protect the connection.

Regards,
Steve Senum

Ofer Biran wrote:
>
> Steve,
>
> One of the clear conditions for moving to mandatory CHAP was that
> CHAP with weak secret is not acceptable on non-encrypted channel and
> this should be enforced with teeth.  We don't have to enforce the
> implementation
> to know the length - we can simply mandate IPsec encryption if it doesn't
> know,
> i.e. change the implementation instruction paragraph from:
>
> When CHAP is used with secret shorter than 96 bits,  a compliant
> implementation SHOULD NOT continue with the login step in which it
> should send a CHAP response (CHAP_R - Section 10.5 Challenge Hand-
> shake Authentication Protocol (CHAP)) unless it can verify that IPsec
> encryption is being used to protect the connection.
>
> to:
>
> A compliant implementation SHOULD NOT continue with the login step
> in which it should send a CHAP response (CHAP_R - Section 10.5
> Challenge Handshake Authentication Protocol (CHAP)) unless it can
> verify that either the CHAP secret is at least 96 bits, or that
> IPsec encryption is being used to protect the connection.
>
> Regards,
>    Ofer
>
> Ofer Biran
> Storage and Systems Technology
> IBM Research Lab in Haifa
> biran@il.ibm.com  972-4-8296253
>
> Steve Senum <ssenum@cisco.com> on 17/06/2002 18:55:52
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> To:    Ofer Biran/Haifa/IBM@IBMIL
> cc:
> Subject:    Re: [PRIVATE] Re: iSCSI: 7.2.1 CHAP Considerations (12-98)
>
> Ofer,
>
> I don't think is it possible for a baseline RADIUS server
> to generate a CHAP response, though some implementation
> specific extensions might allow for this.
>
> I believe TACACS+ (Cisco's own authentication protocol)
> can do this, but not provide the CHAP secret length.
>
> I think the iSCSI specification should be very
> conservative about trying to impose requirements on
> external services like authentication and how users
> administer them.  Even if justified by security concerns,
> I don't think we should assume it is always possible
> to get direct access to the CHAP secret, or even its length.
> All we can really do here is encourage users and developers
> to move in the right direction.
>
> Regards,
> Steve Senum
>
> Ofer Biran wrote:
> >
> > Steve,
> >
> > For the sake of security I believe  it would be justified to require
> > such external application to have API to report the length.
> > What did trouble me is whether the existing Radius gives such
> > response computing service for targets (in the case of
> > CHAP+target authentication) ?
> >
> >   Regards,
> >     Ofer
> >
> > Ofer Biran
> > Storage and Systems Technology
> > IBM Research Lab in Haifa
> > biran@il.ibm.com  972-4-8296253
> >
> > Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 15/06/2002 23:47:29
> >
> > Please respond to Steve Senum <ssenum@cisco.com>
> >
> > Sent by:    owner-ips@ece.cmu.edu
> >
> > To:    ietf-ips <ips@ece.cmu.edu>
> > cc:
> > Subject:    Re: iSCSI: 7.2.1 CHAP Considerations (12-98)
> >
> > Ofer Biran wrote:
> > >
> > > On initiator-only authentication this puts the responsibility
> > > only on the initiator implementation who surely knows the
> > > secret and its length.
> > >
> >
> > While I believe the above is true in general,
> > I think there might be situations where the
> > the initiator could pass the challenge to another
> > application (or system) to compute the reply,
> > and thus not have direct access to the CHAP secret.
> >
> > Regards,
> > Steve Senum