Subject: iSCSI inband auth: Rough Consensus + Direction

From: [email-masked]
Date: Fri, 24 May 2002 20:26:38 -0400

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 28 May 2002 12:33:38 -0700 (PDT)

> (4) SRP remains in the draft as a "MAY implement" method.

Sounds good.

> the "SHOULD" for strong CHAP secrets to a "MUST".

I like this idea of requirements. I would though like to suggest that we
make the points on whatever list we come up with as MUST or SHOULDs, and
leave out the MUST use ESP requirement. That way we have a good-faith
effort, and if an admin is dead-set on doing something stupid, well, it is
their stupidity to do (and their data to loose).

> and suggest revisions/extensions to the above list.

I think that's an excelent list.

I would be happy with the above list. The one place I have some concern is
the disallowing any secret with more than 16+ bits of leading 0's. On the
one hand if I ever HAVE to enter such a key (say I have to make things
work with a stupidly-configured device administered by someone who has
no interest in correcting the problem), I would like to be able to. On
the other hand, if all initiators and targets had this test, there would
be no way for said stupid problem to arise.

Perhaps permit more than 16+ bits of leading 0's only if the administrator
acknowleges s/he realizes this CHAP secret is insecure. Like how some OSs
will complain in the chpass program if your password doesn't have numbers
& letters, but will accept it if you type it in again.

Oh, we've tried hard to maintain compatability with RADIUS servers. Do
they all support 96-bit secrets?

Thoughts?

Take care,

Bill