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

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 22 May 2002) by Black_David@emc.com:
> 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.

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.

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

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