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

[Black_David@emc.com]

Milan,

> I have also spoken to a few people with far more IPsec experience
> than I.  From the dazed expressions and dropped jaws, the sense I
> get is that dynamic switching to more relaxed SAs is, how shall I
> put this, not typical behavior?  Legal, yes. Interoperably
> implementable, probably.  Ugly, not a doubt.

FWIW, that was intended ... the "MUST use" IPsec ESP requirement is
supposed to make the consequences of ignoring the SHOULD for machine-
generated CHAP secrets so ugly/objectionable/etc. that it provides a
powerful incentive to "do the right thing" and implement/use machine-
generated CHAP secrets.  Keep in mind that the "MUST use" *only applies*
when the SHOULD for machine-generated strong CHAP secrets is ignored.
Thanks for the backhanded confirmation that the requirement appears
to have the intended/desired effect ;-).
 
> I too would be far happier if we separated out the decision-bits again, 
> and let the end users decide
>    a) to allow their iSCSI implementations to authenticate each other
>		securely,
>    b) to provide privacy and/or enhanced integrity to the data sessions
>	as independent options.

I think that's the intent.  If CHAP is used with machine-generated
strong secrets, the two aspects are independent.  If CHAP is used with
weak secrets such as passwords or hashes of passwords, see above.

> It's bad enough to be appearing to legislate user behavior with a 
> "SHALL USE", but worse if it appears to be an arbitrary mandate 
> from above.

As noted above, the intended target of that language is implementers
who choose not to pay attention to the SHOULD.

> I think the appropriate course here is to put in the 
> strong wording re selection of CHAP secrets, referencing the 
> available literature re potential exploits of dictionary keys.  
> Separately, recommend IPsec use for session privacy, 
> integrity, and identification verification, where appropriate 
> to the user's needs.

Noted, thanks.  At the risk of opening a serious Pandora's box,
one of the underlying concerns in this area is that it's an
ill-kept secret that many implementers are in the process of
ignoring or sidestepping the "MUST implement" ESP and IKE
requirements.  It would be bad if they likewise ignored or
sidestepped a MUST or SHOULD on appropriate generation/selection
of CHAP secrets, hence the proposal for serious negative
consequences of using weak secrets in order to put teeth into
the requirement to use strong CHAP secrets.

Important reminder: In the proposed language, if the implementation
supports strong CHAP secrets and takes all reasonable measures to
cause their use, the "MUST use" IPsec ESP requirement does not apply.

"all reasonable measures" is the best that can be done due to the
requirement to accept externally generated CHAP secrets - while these
can be checked for sufficient length, there's no way to check them for
sufficient entropy/randomness (e.g., there's no way to tell whether
96 bits that appear random were generated from electrical noise and
really are random vs. generated by hashing (e.g., SHA-1) 0xdeadbeef,
in which case they contain very little randomness).

If anyone's reaction is "but the proposed text doesn't say that",
please propose alternate text (e.g., concrete testable requirements
for "all reasonable measures" - it might be possible to put MUSTs
against those requirements in place of the "MUST use" IPsec ESP
requirement).

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