Subject: Re: iSCSI: CHAP

From: "Julian Satran" <[email-masked]>
Date: Sun, 4 Aug 2002 11:38:15 +0300

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 conduct 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" <[email-masked]>
Sent by: [email-masked]
08/03/2002 05:43 PM

        To:     [email-masked]
        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
[email-masked]
603-862-3774