Re: iSCSI inband auth: Rough Consensus + Direction

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 24 May 2002 Black_David@emc.com wrote:

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

Sounds good.

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

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

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

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