iSCSI inband auth: Rough Consensus + Direction

["Ofer Biran" <BIRAN@il.ibm.com>]

David,

Your guidelines are generally reasonable, I have the following
comments:

1.
I think we overlooked one aspect which is the convenience of human
readable passwords in various scenarios. SRP is OK for them, but
so is CHAP above encrypted IPsec - so a better approach might be
a text that only (but aggressively) disqualifies CHAP + weak secret
+ no-IPsec-encryption.

2.
The first part of the CHAP reflection prevention is already covered
in iSCSI 10.5 (CHAP):

"If the initiator authentication fails, the target MUST answer with a
Login reject with "Authentication Failure" status. Otherwise, if the
initiator required target authentication, the target MUST reply with
        CHAP_N=<N> CHAP_R=<R>    "

So based on the above and the guidelines, here is a suggested CHAP
text for iSCSI "7.2 In-band Initiator-Target Authentication". I
believe it's also simpler and more concrete on what implementations
must and must not do:

-------------------------------------------------------------------
Compliant iSCSI implementation MUST implement the CHAP authentication
method [RFC1994] (see Section 10.5).

When CHAP is performed over non-encrypted channel, it is vulnerable to
an off-line dictionary attack. Implementations MUST support use of up
to 128 bits random CHAP secrets, including the means to generate such
secrets and to accept them from an external generation source.
Implementations MUST NOT provide secret generation (or expansion) means
other than random generation.

If CHAP is used with secret weaker than 96 random bits, than IPsec
encryption (according to the implementation requirements in "7.3.2
Confidentiality") MUST be used to protect the connection. Moreover,
in this case IKE authentication with group pre-shared keys MUST NOT be
used. When CHAP is used with secret less then 96 bits, compliant
implementation MUST NOT continue with the login unless it can verify
that IPsec encryption is being used to protect the connection.

Initiators MUST NOT reuse the CHAP challenge sent by the Responder for
the other direction of a bi-directional authentication.  Responders
MUST check for this condition and close the iSCSI TCP connection if it
occurs.
-------------------------------------------------------------------

 Regards,
   Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253