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

From: "Ofer Biran" <[email-masked]>
Date: Wed, 22 May 2002 06:07:23 +0300

David,

Just two comments (being on trip it went to the list  too fast for
me):

1.
"If the CHAP shared secret is weaker than 96 bits of cryptographic
randomness..."
All this par. actually tell you what to do when you disobey the
SHOULD in the par. above... ("the CHAP shared secret SHOULD
represent a cryptographically random quantity...") maybe it's OK
(because there are MUSTs here) but it's a bit unusual. This makes
it look like we accept this alternative way, so maybe that SHOULD
can go away (i.e., either 96/random or these IPsec conditions).

2.
"In order to provide mutual authentication and protect against rogue
Targets, CHAP authentication SHOULD be done in both directions..."
Mutual authentication is optional to use for all authentication
methods, and I don't see any reason to enforce it only in CHAP. This
is a change, it is not related to the CHAP problems discussed, and
I would not put it in suddenly now.

  Regards,
     Ofer

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

---

From: "Merhar, Milan" <[email-masked]>
Date: Wed, 22 May 2002 10:14:33 -0400

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: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2002 5:50 PM
> To: [email-masked]
> 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
> [email-masked]         Cell: +1 (978) 394-7754
> ---------------------------------------------------
>

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 22 May 2002 09:02:33 -0700

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: [email-masked]

[email-masked]@ece.cmu.edu on 05/21/2002 02:49:39 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:

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

Thanks,
--David

Proposed text:

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,...)

    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.

---

From: [email-masked]
Date: Wed, 22 May 2002 16:28:55 -0400

Responding to Ofer's concerns, let me know if I get any of the
paraphrasing wrong.

[Ofer Biran 1]: Since requirements for what to do when secrets
	weaker than 96 bits of randomness are used, is the SHOULD for
	96+ bits of necessary?

Good question.  It'll help when an external RADIUS server is used
to verify CHAP authentication.  It also scopes the "MUST use
ESP" requirement to apply only when the SHOULD is ignored.

[Ofer Biran 2]: Mutual authentication is being introduced as a
	SHOULD requirement very late in the process.  The requirement
	should be removed; mutual authentication should remain OPTIONAL.

I believer Ofer is correct about this.  I believe the important aspect
is to be sure to include Paul Koning's example and associated text
about how to prevent reflection attacks on CHAP if/when it used for
mutual authentication.  In the absence of strong interest in imposing
this requirement, I think we should return to the previous situation.

Thanks,
--David

---

From: [email-masked]
Date: Wed, 22 May 2002 17:06:37 -0400

John,

> customer actions not just implementation.

To some extent, this is unavoidable, and we're already there
implicitly, as use of a low-entropy pre-shared key with IKE will
doubtless make IKE vulnerable in all sorts of undesirable ways.
For that matter, even SRP is only secure if the customer uses
it correctly (e.g., if Alice doesn't keep her password secret,
and Bob knows it, SRP will not protect Alice from Bob).

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

I don't think so.  One can expect an IPsec implementation to
report the security policy and mechanisms (contents of the SPD,
and probably the SAD) that it is currently enforcing through
a suitably secured management interface.  How to get access to
and use that interface would be up to the implementer combining
IPsec and iSCSI.

> can do is document on the packaging/directions, what should or should not

Please propose new wording.

Thanks,
--David

---

From: [email-masked]
Date: Wed, 22 May 2002 18:11:03 -0400

> > [Paul Koning 1]: 96 bits of entropy requirement is not testable, and
> > 	should be removed for that reason, ditto the dependence of the
> > 	"MUST use ESP" and related requirements on this level of entropy.
> > 
> > In practice, many cryptographic protocols depend on high entropy;
> > both IKE and SRP almost certainly break in some ways if their nonces
> > aren't random.
> 
> That is not true.
> 
> What happens if the nonces are poor is that the resulting protocol may
> be vulnerable to certain attacks.  But it does not "break" the
> protocol; the protocol will very definitely produce a valid outcome
> even if the nonces are not as strong as they ought to be.

Paul and I are in violent agreement, and I've been caught using sloppy
language.  The security properties of protocols that use nonces depend
on the randomness of the nonces, and hence using nonces with insufficient
randomness can create security vulnerabilities in those protocols.  In
the extreme case where the attacker knows the nonces, I would suggest that
some of these protocols are so vulnerable as to be broken - not that
they won't work, but in the sense that they don't provide the expected
security.  The fact that the requirement for randomness is untestable
doesn't make it unimportant.

[... snip ...]

> > In essence, the position
> > being taken here is that CHAP with a weak secret (e.g., password) is
> > sufficiently weak that one shouldn't fool oneself into thinking that
> > it provides any real protection unless something else (ESP encryption)
> > is done.  That would be a fair topic for discussion.
> 
> I do NOT find that an acceptable position.
> 
> Whether a certain combination of mechanisms provides sufficient
> protection is something for the customer to decide, NOT the standard.
> I have no objection against giving information, guidance, or warnings,
> to aid in that decision making process.  But a requirement that says
> "you must use IPsec whether it has any value in your installation or
> not" is not acceptable.

I understand Paul's point, but I think it's overstated - the "MUST"
applies only when the customer chooses (1) to use CHAP authentication
and (2) ignores the "SHOULD" for strong secrets and uses weak ones.  If
the resulting "MUST use" is unacceptable, perhaps the customer should go 
back and revisit those choices (especially the latter) to understand
their consequences and the consequences of making alternative choices.

I also want to caution that Paul's "whether it has any value in your
installation or not" point is a matter of degree, not a hard-and-fast
principle.  For example, current IETF policy does not allow new
standards-track protocols to use clear-text passwords even though
there are installations in which those provide adequate security,
and does not entertain standardization of protocols that don't have
adequate security measures for use on the public Internet.  OTOH, these
these sorts of policies are usually reflected in "MUST implement"
requirements, so I do understand and acknowledge Paul's concern with
the "MUST use" language for IPsec - please see a separate message from
me asking about a possible alternative.

Thanks,
--David

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 22 May 2002 17:28:34 -0700

David,
Do you also mean that we can tell if a group preshared key was used?  How
do we do that?

.
.
.
John L. Hufferd

[email-masked]@ece.cmu.edu on 05/22/2002 02:06:37 PM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    [email-masked]
Subject:    RE: iSCSI Inband authentication (SRP/CHAP) - proposed
       resolution

John,

Thanks,
--David

---

From: "Merhar, Milan" <[email-masked]>
Date: Thu, 23 May 2002 09:05:49 -0400

I have also spoken to a few people with far more IPsec experience than I.
>From the dazed expressions and dropped jaws, the sense I get is that 
dynamic switching to more relaxed SAs is, how shall I put this, not typical 
behavior?  Legal, yes. Interoperably implementable, probably.  Ugly, not a
doubt.
 
I too would be far happier if we separated out the decision-bits again, 
and let the end users decide
    a) to allow their iSCSI implementations to authenticate each other
securely,
    b) to provide privacy and/or enhanced integrity to the data sessions
as independent options.
 
It's bad enough to be appearing to legislate user behavior with a 
"SHALL USE", but worse if it appears to be an arbitrary mandate 
from above.  I think the appropriate course here is to put in the 
strong wording re selection of CHAP secrets, referencing the 
available literature re potential exploits of dictionary keys.  
Separately, recommend IPsec use for session privacy, 
integrity, and identification verification, where appropriate 
to the user's needs.
 
Just my opinion....
 
- milan

 -----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Wednesday, May 22, 2002 6:59 PM
To: [email-masked]
Cc: Merhar, Milan; [email-masked]
Subject: RE: iSCSI Inband authentication (SRP/CHAP) - proposed resolution

On Wed, 22 May 2002 [email-masked] wrote: 

> Responding to Milan's concern, let me know if I get any of the 
> paraphrasing wrong: 
> 
> [Milan Merhar]: It looks like the requirement for ESP to protect a CHAP 
>       exchange with a weak secret requires the entire resulting iSCSI 
>       session to be encrypted and use ESP integrity. 
> 
> Close enough; I think it's just that connection and only integrity. 
> The encryption can probably be removed by negotiating a new SA that 
> doesn't encrypt and deleting the old one, but that still requires 
> ESP integrity.  Just deleting the SA doesn't work reliably because 
> it could easily result in black-holing packets.  IKE has no way to 
> check whether the other side will accept unprotected packets for 
> this TCP connection, and if it won't, then deletion of the SA 
> results in the packets being discarded. 

Could we have a more complete example of this (SA changing in mid-stride)? 
>From talking with some IPsec implementers, it can be done. We just will 
need to note a number of details to make sure we have it right. 

One thing that will be needed is for us to be able to set policy on a 
per-socket basis, and for us to be able to examine the policy in place on 
a socket. That way a target can verify that a login is covered by 
sufficiently-secure policy, and the initiator (and target) can adjust 
policy (to relax it). 

There is of course the question of what to do if the other side doesn't 
want to relax policy. :-) 

A few other implementation notes. 1) some IPsec implementations will 
continue using an older SA (the with-privacy one) for a while. 2) we need 
to have the initiator make sure it's using strong policy when it does the 
CHAP phase - otherwise if it is logging back into a target and happens to 
use a port number that it used before, the old (weaker) SA might still be 
there. 

I would prefer the key randomness be a MUST, so we can avoid this. While 
rather doable, it will add more to the implementation complexity. 

Take care, 

Bill

---

From: [email-masked]
Date: Thu, 23 May 2002 12:06:18 -0400

John,

> Do you also mean that we can tell if a group preshared key 
> was used?  How do we do that?

Preshared key, yes, via the same sort of secured management
interface that reports the IKE identity that authenticated and
how it authenticated.  OTOH, one can't tell in general whether
it's a group or pairwise pre-shared key, because that falls
into the area you've identified as "customer actions" - I'd
use the phrase "good security policy and practices", but it's
the same issue.

There are instances in which it's possible to tell that a key
is pre-shared among a group (e.g., if the same pre-shared key is
bound to multiple IKE identities, and those IKE identities
are in use simultaneously with the same counterparty), but
in full generality determining whether a pre-shared key is
only pairwise shared or shared among a larger group is the
same sort of problem as determining whether Alice kept her
password secret from Bob - if Bob knows Alice's password
and logs in as Alice, it's very hard to figure out that this
happened, especially if he does so from a system Alice uses
regularly.

Thanks,
--David

> From: John Hufferd [mailto:[email-masked]]
> Sent: Wednesday, May 22, 2002 8:29 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Thu, 23 May 2002 12:39:06 -0400

Milan,

> I have also spoken to a few people with far more IPsec experience
> than I.  From the dazed expressions and dropped jaws, the sense I
> get is that dynamic switching to more relaxed SAs is, how shall I
> put this, not typical behavior?  Legal, yes. Interoperably
> implementable, probably.  Ugly, not a doubt.

FWIW, that was intended ... the "MUST use" IPsec ESP requirement is
supposed to make the consequences of ignoring the SHOULD for machine-
generated CHAP secrets so ugly/objectionable/etc. that it provides a
powerful incentive to "do the right thing" and implement/use machine-
generated CHAP secrets.  Keep in mind that the "MUST use" *only applies*
when the SHOULD for machine-generated strong CHAP secrets is ignored.
Thanks for the backhanded confirmation that the requirement appears
to have the intended/desired effect ;-).
 
>    b) to provide privacy and/or enhanced integrity to the data sessions

I think that's the intent.  If CHAP is used with machine-generated
strong secrets, the two aspects are independent.  If CHAP is used with
weak secrets such as passwords or hashes of passwords, see above.

> from above.

As noted above, the intended target of that language is implementers
who choose not to pay attention to the SHOULD.

> I think the appropriate course here is to put in the 

Noted, thanks.  At the risk of opening a serious Pandora's box,
one of the underlying concerns in this area is that it's an
ill-kept secret that many implementers are in the process of
ignoring or sidestepping the "MUST implement" ESP and IKE
requirements.  It would be bad if they likewise ignored or
sidestepped a MUST or SHOULD on appropriate generation/selection
of CHAP secrets, hence the proposal for serious negative
consequences of using weak secrets in order to put teeth into
the requirement to use strong CHAP secrets.

Important reminder: In the proposed language, if the implementation
supports strong CHAP secrets and takes all reasonable measures to
cause their use, the "MUST use" IPsec ESP requirement does not apply.

"all reasonable measures" is the best that can be done due to the
requirement to accept externally generated CHAP secrets - while these
can be checked for sufficient length, there's no way to check them for
sufficient entropy/randomness (e.g., there's no way to tell whether
96 bits that appear random were generated from electrical noise and
really are random vs. generated by hashing (e.g., SHA-1) 0xdeadbeef,
in which case they contain very little randomness).

If anyone's reaction is "but the proposed text doesn't say that",
please propose alternate text (e.g., concrete testable requirements
for "all reasonable measures" - it might be possible to put MUSTs
against those requirements in place of the "MUST use" IPsec ESP
requirement).

Thanks,
--David