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

[Black_David@emc.com]

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