Re: iSCSI: CHAP

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

We have gone through the text again and found that it is not explicit enough about how a target can initiate a security selection.

As a consequence we propose the following minor clarifications to 10.1:

The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected.

The authentication method proposal may be made by either the initia-tor or the target. However the initiator MUST make the first step specific to the selected authentication method as soon as it is selected. It follows that if the target makes the authentication method proposal the initiator sends the first keys(s) of the exchange together with its authentication method selection.

The authentication exchange authenticates the initiator to the tar-get, and optionally, the target to the initiator.  Authentication is not mandatory to use but MUST be supported by the target and initia-tor.

The initiator and target MUST implement CHAP. All other authentica-tion methods are OPTIONAL to implement.

Proprietary algorithms MAY also be negotiated for authentication methods. Whenever a proprietary algorithm is offered, "None" or "CHAP" MUST be listed as an option in order to guarantee interopera-bility.

Proprietary authentication methods MUST be named using of the follow-ing two formats:

Z-reversed.vendor.dns_name.do_something=
Z<#><IANA-registered-string>=

Authentication methods named using the Z- format a are used for ven-dor-specific purposes (unregistered). Authentication methods named using the Z# format must be registered with IANA and MUST be described by an informational RFC.

For all the vendor-specific registered or unregistered authentica-tion methods, the methods specific keys MUST conform to the format specified in Section 4.1 Text Format for standard-label.
 
For unregistered authentication methods, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the proper digest names.

The part of digest-name following Z- and Z# MUST conform to the for-mat for standard-label specified in Section 4.1 Text Format.

Support for vendor-specific authentication methods, whether regis-tered or not is OPTIONAL.

The following subsections define the specific exchanges for each of the standardized authentication methods. As mentioned earlier the first step is always done by the initiator.

Please not also that 7 contains already the following:

Section 10 iSCSI Security Keys and Authentication Methods defines several authentication methods and the exact steps that must be fol-lowed in each of them, including the keys and their allowed values in each step. Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection. Whenever an iSCSI target gets a response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status (these statuses are not intended for cryptographi-cally incorrect value, e.g., the CHAP response, for which "Authenti-cation Failure" status MUST be specified). The importance of this rule can be illustrated in CHAP with target authentication ( Section 10.1.4 Challenge Handshake Authentication Protocol (CHAP)) where the initiator would have been able to con!
duct a reflection attack by omitting his response key (CHAP_R), using the same CHAP challenge as the target and reflecting the target's response back to the target. In CHAP this is prevented since the target must answer the missing CHAP_R key with a Login reject with the "Missing Parameter" status.

Togther they should make clear that your hypothetical example is not correct in step 3a - where the initiator MUST have made the first CHAP specific step with CHAP_A=4,5,7 together with the AuthMethod=CHAP.

Thanks,
Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> Sent by: owner-ips@ece.cmu.edu 08/03/2002 05:43 PM

To:        ips@ece.cmu.edu         cc:                 Subject:        iSCSI: CHAP

Julian:

Section 10.5 is written in terms of initiator and target, rather
than originator and responder as in section 7.2.1.  I believe this
is intentional (i.e., that section 10.5 is NOT supposed to be
written in terms of originator and responder).

Because the use of CHAP in Appendix C is illustrated only with
the initiator offering the AuthMethod key, I would like to verify
that the following is a correct security negotiation sequence
when it is the target, not the initiator, that first offers the
AuthMethod key (this scenario ignores the other keys that may be
required, such as InitiatorName, TargetName, etc., and assumes
they are sent as required):

1.  I-> Login (CSG,NSG=0,1 T=1) no AuthMethod key
2.  T-> Login-PR (CSG,NSG=0,0 T=0) AuthMethod=CHAP,SRP
3a. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP
4a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=4,5,7
5a. I-> Login (CSG,NSG=0,0 T=0) CHAP_A=5
6a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_I=<i1> CHAP_C=<c1>
7a. I-> Login (CSG,NSG=0,1 T=1) CHAP_N=<n1> CHAP_R=<r1>
8a. T-> Login-FR (CSG,NSG=0,1 T=1) no keys
and security negotiation phase is now completed successfully

In particular, the first challenge, in step 6 above, always has to
be from the Target to the Initiator.  Is this correct?

Is it possible or preferable or required to collapse steps 3 through
6 above into just 2 steps?

3b. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP CHAP_A=4,5,7
4b. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=5 CHAP_I=<i1> CHAP_C=<c1>
and then the next step would be 7.

This would have the effect of having the target offer the security
method (CHAP,SRP) but the initiator offering the algorithm (4,5,7).
Is this allowed?


As written above, Step 7a does not perform target authentication.
To do so, this step would be rewritten as:

7b. I-> Login (CSG,NSG=0,0 T=0) CHAP_N=<n1> CHAP_R=<r1> CHAP_I=<i1> CHAP_C=<c2>

in which case the continuation would then be:

8b. T-> Login-FR (CSG,NSG=0,1 T=1) CHAP_N=<n2> CHAP_R=<r2>

One final question -- although the target can force authentication as
shown above, and thereby gets to challenge the initiator, there appears
to be no way the target can force the initiator to challenge it.
In other words, if the initiator sends 7a above (no target challenge),
and the target wanted to see 7b, there is nothing the target can do
except send back a Login-Reject.  Correct?

If this is correct, what Status code should be in the Login-Reject?
It cannot be 0201 Authentication Failure, because the initiator may
have been successfully authenticated.  Is the correct response Status
0202 Authorization Failure or Status 0200 Miscellaneous iSCSI initiator
error or does it matter?

Thank you.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774