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

From: [email-masked]
Date: Wed, 22 May 2002 16:36:13 -0400

Responding to Paul Koning's concerns:

[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.  I agree that there's no good way to test the entropy
of a generator of randomness, but I believe we need some way to
discriminate between weak and strong CHAP secrets in the requirements
language, as the alternatives to not doing this may include "SHOULD
use" or "MUST use" ESP encryption with CHAP in all cases, which I
suspect folks will find far less palatable.  Also, we have this issue
elsewhere in that inadequate entropy in their nonces almost certainly
breaks IKE, SRP, and Kerberos in various ways.

[Paul Koning 2]: A "MUST use" for ESP with weak CHAP secrets should
	be avoided.

Part of the motivation for this is definitely to provide an incentive
to use strong secrets with CHAP.  Given that the "MUST use" applies only
when a SHOULD is ignored, I don't think it's that objectionable, and
there was an example of a similar "MUST use" involving SIP mentioned
on the call whose details I don't have to hand.  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.

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

---

From: Paul Koning <[email-masked]>
Date: Wed, 22 May 2002 17:32:56 -0400

Excerpt of message (sent 22 May 2002) by [email-masked]:
> 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.

There may be some elements in a protocol where certain values should
be avoided, for example the value 0 for a or b in D-H is probably not
a good value.  But that's a different issue.

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

Part of the issue here is that IPsec is expensive, both in
implementation resources and in management complexity.  So the mandate
isn't just a minor annoyance, it has very substantial impact.

Apart from that, as I pointed out, the proposed requirement is not
testable, so what good is it?  If there is no way to tell whether a
particular implementation conforms to this proposed requirement or
not, then clearly the requirement is not useful.  (Perhaps that means
I should just shut up, since the proposed text wouldn't affect my
implementation anyway...  but from a point of view of standards
quality I don't want to let untestable "requirements" go
unchallenged.)

     paul