iSCSI: DH-CHAP initial comments

[Paul Koning <ni1d@arrl.net>]

I have a few initial comments on the DH-CHAP draft.

Section 9 raises the open issue of chosing the D-H group(s), which is
also open for SRP.  It seems to me the same solution can be applied to
both, which is to adopt the groups already adopted (and verified to
have the right mathematical properties) for IKE.  In particular,
"Group 1" would serve, and, if people insist on a bigger one, "Group
2".  I don't see a strong reason to include any of the larger groups
which have been proposed in the context of IKE and AES.

This could be done by removing the N and g keys from SRP and DHCHAP,
and replacing them by a single "group ID" key whose value is that of
the group ID taken from RFC 2409.

Section 6.4 discusses reflection attacks, but it doesn't read like a
completely accurate description of the attack.  The issue is not what
correctly operating initiators should do -- it is certainly true that
they must not reuse someone else's challenge.  The issue is what
happens if a rogue initiator sends back a challenge to the target that
is in fact a copy of the target's challenge.

The existing text in 10.5 could use some tightening to make sure this
case is covered.  Specifically, it should say that a target MUST
reject an attempt by an initiator to send a CHAP_C (or DHCHAP_C) which
is not accompanied by or preceded by a valid CHAP_R (DHCHAP_R) for the
challenge sent by the target.  With the current wording, it's pretty
clear that an initiator message that contains both a CHAP_R and a
CHAP_C is first checked for valid initiator authentication.  What
isn't so clear is that this exchange:

      I->R     CHAP_A(A1,A2,...)
      R->I     CHAP_A, CHAP_C, CHAP_I
      I->R     CHAP_A, CHAP_C, CHAP_I

is invalid because there is no CHAP_R in the third message. It is
implicit because only two possibilities are listed for the third
message, but a straightforward parsing algorithm might very well
accept the illegal exchange I showed as valid if it wasn't
specifically checked for, and it's worth calling out this case
explicitly so it's clear that the target MUST check for it.

     paul