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

["Merhar, Milan" <mmerhar@pirus.com>]

Just to make sure I understand the requirement; if CHAP is used in today's
conventional way with a human-generated password, iSCSI login MUST be
protected using ESP encryption (and integrity.) That seems to be a
reasonable solution, given the goal of protecting the login secret. 

But, since the IPsec SA must be in place before iSCSI login to give this
protection, and because each iSCSI session begins with a login, that
indicates that the full-featured portion of these iSCSI sessions MUST also
be protected by the same ESP encryption (and integrity) negotiated to
protect the login.

In other words, if you use CHAP without a strong key (and has already been
pointed out, there is no way of verifying key strength during use) use of
IPsec ESP encryption has been mandated as a MUST USE for the entire iSCSI
session.  (Or, as one associate put it, we're not mandating crypto across a
few handshake frames, but across all data as well.)

If I'm reading this incorrectly, please correct me.

- milan

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, May 21, 2002 5:50 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI Inband authentication (SRP/CHAP) - proposed resolution
> Importance: High
> 
> 
> 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
> ---------------------------------------------------
>