iSCSI inband auth: Rough Consensus + Direction

[Black_David@emc.com]

Based on the email on the list since the proposed resolution
text was announced, I think there is rough consensus on the
following points:

(1) CHAP w/strong secrets is acceptable in principle as
	the "MUST implement" authentication method.
(2) No change should be made to the requirements for
	bi-directional authentication that existed previously
	- the SHOULD for bidirectional use of CHAP (if
	CHAP is used) is not appropriate.
(3) Add Paul Koning's example and related text on
	preventing reflection attacks on bi-directional
	CHAP.
(4) SRP remains in the draft as a "MAY implement" method.

That's progress, but what we don't have rough consensus on
is the practical details of requiring CHAP w/strong secrets,
specifically the latter portion of "SHOULD use strong secrets
w/CHAP, otherwise MUST use ESP encryption to protect weak
secrets".  I believe the problems in this area are caused by
a lack of details on what an implementer has to do to satisfy
the "SHOULD" in order to avoid getting whacked with the "MUST".
The proposed resolution text leaves open the possibility
that misbehavior by a user (e.g., failure to RTFM and/or
follow instructions given by a setup tool) could cause the
implementer/vendor to become responsible for the MUST -
that was definitely not the intent of the proposal,
and I think John Hufferd made this point.

I suggest that the direction to finish closing this issue
is to draw up a list of measures that the draft declares
to be sufficient to satisfy the SHOULD (i.e., the draft
contains text saying that if an implementation does <X>,
<Y>, ..., and <F>, the implementation has satisified
"SHOULD use strong secrets" requirement and hence the
"MUST use ESP encryption" requirement does not apply, where
<X> and the like are under control of the implementer).
This is importnat regardless of whether we change
the "SHOULD" for strong CHAP secrets to a "MUST".

Here's a very quick start at what the contents of such
a list could be:

- Secrets must be 96 bits in size
- Provide means to generate secrets from real randomness, and
	accept externally generated secrets.  Do not provide means
	to generate a smaller secret or one with less randomness.
- Do not provide any means (e.g., GUI, CLI or other external
	interface) to expand a smaller secret to 96+ bits or accept
	external input of a smaller secret.
- Disallow any secret with 16+ bits of leading 0's?  (helps defend
	against accidentally truncating to 64 or 32 bits)
- Documentation and configuration tools must warn users about
	the danger of secrets based on insufficient randomness.

None of the above items are set in stone.  Please comment
and suggest revisions/extensions to the above list.

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