Re: iSCSI Inband authentication (SRP/CHAP) - proposed resolution

["John Hufferd" <hufferd@us.ibm.com>]

David,
The problem I am having with the proposal is, that I think we are mandating
customer actions not just implementation.

We are saying that if Chap passwords are used then they must do or must not
do something else which is legal with IPsec.

Since the IPsec process is really disjoint from the iSCSI Login, there is
no real way that we can tell what the customer did with IPsec, and IKE.

So some how I think the wordage needs to be adjusted to reflect this
implementation vrs customer interaction, since I think the only thing we
can do is document on the packaging/directions, what should or should not
be done.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Black_David@emc.com@ece.cmu.edu on 05/21/2002 02:49:39 PM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    iSCSI Inband authentication (SRP/CHAP) - proposed resolution



Since DH-CHAP has been excluded from iSCSI, I can now function as a WG
co-chair on this security topic.  On a conference call today that included
both IPS WG co-chairs, our Area Director (Allison Mankin), the authors
of both the iSCSI and IPS Security drafts, along with additional
security experts and contributors, the group came up with the following
proposed resolution to the open iSCSI requirements issues in inband
authentication:

- CHAP MUST be implemented.  Support for strong machine-generated CHAP
 secrets (96+ bits of cryptographic randomness) MUST be implemented,
 and CHAP secrets of at least that strength SHOULD be used.
 Generation of secrets MAY be external to the iSCSI implementation.
- If weaker CHAP secrets (e.g., passwords, hashes of passwords) are
 used, ESP encryption (and integrity) MUST be used to protect them,
 and group pre-shared keys MUST NOT be used for IKE authentication
 (pairwise pre-shared keys MAY be used).
- Pick up some text from the DH-CHAP draft that helps prevent reflection
 attacks on CHAP in iSCSI (with credit/thanks to Paul Koning).
- SRP remains in the iSCSI draft as a MAY implement mechanism.

The overall rationale behind this is to strongly encourage (SHOULD) use
of strong secrets with CHAP (first bullet) and to put in place serious
requirements (MUST) for use of IPsec (ESP) to protect CHAP if weaker
secrets are used (second bullet) to encourage those who need such
encouragement.  This is not the best possible solution, but it's a
pragmatic approach that solves the problems at hand and should get
the iSCSI draft into WG Last Call in the very near future.

The proposed text with the details and specific requirements (for the
iSCSI and IPS drafts) follows.  Comments to the list by noon Eastern
Daylight Time (US) this Friday (May 24), please.  After that time, the
text will go into the iSCSI and IPS Security drafts, and there will be
further opportunity to comment during WG Last Call for these drafts.

Thanks,
--David

Proposed text:

CHAP MUST be implemented for iSCSI login authentication. In order
to provide protection against offline dictionary attacks, the CHAP
shared secret SHOULD represent a cryptographically random quantity
with at least 96 bits of randomness. Implementations MUST support
use of such random CHAP secrets including the means to generate
secrets and to accept input of secrets of up to 128 bits generated
externally (e.g., by other implementations). An implementation MAY
meet the generation requirement by supplying a program that runs on
some other system to create CHAP secrets that are then entered into
the implementation via a configuration interface.  Hexadecimal
format MUST be supported for output of generated CHAP secrets
(e.g., for use in other implementations) and input of CHAP secrets
generated externally.

If the CHAP shared secret is weaker than 96 bits of cryptographic
randomness (e.g., the secret is a password or is derived from a password),
then IPsec ESP with non-null transform (e.g., 3DES, 128 bit AES) MUST be
used to protect the iSCSI login authentication, and IKE authentication
with group pre-shared keys MUST NOT be used.  In addition, DES SHOULD NOT
be used as the ESP transform.  Group pre-shared keys MUST NOT be used in
this situation because they enable any member of the group to masquerade
as any other and collect CHAP exchanges as raw material for an off-line
dictionary attack on the CHAP shared secret(s).  Pairwise pre-shared keys
MAY be used.  These requirements for IPsec usage to protect weak CHAP
secrets
(e.g., passwords) are intended to be severe.  The off-line dictionary
attack
makes CHAP fundamentally insecure when used with passwords or similarly
weak secrets; cryptographic randomness sufficient to thwart a brute-force
attack is necessary to provide sufficient security.

In order to provide mutual authentication and protect against rogue
Targets, CHAP authentication SHOULD be done in both directions. Although
this is not equivalent to a single, interlocked mutual authentication, an
appropriate level of security can be obtained by observing the following
requirements:

(1) A Responder MUST NOT send its CHAP response if the Initiator has not
    successfully authenticated.  For example, the following exchange:

          I->R     CHAP_A(A1,A2,...)
          R->I     CHAP_A, CHAP_C, CHAP_I
          I->R     CHAP_A, CHAP_C, CHAP_I

    MUST result in the Responder (Target) closing the iSCSI TCP
    connection because the Initiator has failed to authenticate (there
    is no CHAP_R in the third message).

(2) Initiators MUST NOT reuse the CHAP challenge sent by the Responder for
    the other direction of a bi-directional authentication.  Responders
    MUST check for this condition and close the iSCSI TCP connection if it
    occurs.

These requirements prevent reflection attacks in which the Initiator uses
the same CHAP challenge as the Target and reflects the Target's response
back to the Target, thereby authenticating the Initiator without requiring
the Initiator to know the CHAP secret.

NOTE: Credit to Paul Koning for the example and contributions to the text
 on this topic.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------