Subject: iSCSI: rejecting AuthMethod

From: "Tony Battersby" <[email-masked]>
Date: Thu, 21 Nov 2002 17:03:55 -0500

Draft 19 Section 5.3.2 iSCSI Security Negotiation: The target MUST reply
with the first option in the list it supports and is allowed to use for the
specific initiator unless it does not support any in which case it MUST
answer with "Reject" (see Section 5.2 Text Mode Negotiation).

Draft 19 Section 5.2.1 List Negotiations: If an acceptor does not support,
does not understand, or is not allowed to use any of the proposed options
with a specific originator, it may use the constant "Reject" or terminate
the negotiation.

I am considering the case where the target is configured not to accept a
connection without authentication, and the target does not support any of
the authentication methods offered by the initiator.  Since the initiator is
not allowed to send the AuthMethod key a second time, the login attempt must
fail.  I assume that the target should return a Login Response with
Authentication Failure status in this case.  The first quote above implies
that the target's Login Response should in addition contain the
"AuthMethod=Reject" key.  Is this really the intended meaning?  In the
general case it is not necessary to return any keys with a Login Response
that has a nonzero Status-Class, so I do not see why this case should be any
different.  For consistency, I recommend changing the text to something like
"...in which case it MUST answer with "Reject" (see Section 5.2 Text Mode
Negotiation) or terminate the negotiation."

Incidently, the names of the Login Response status codes in section 10.13.5
have inconsistent capitalization (e.g. "Target Moved Temporarily" vs. "Can't
include in session").

Anthony J. Battersby
Cybernetics

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 22 Nov 2002 14:19:14 +0200

Tony,

The intent (based on vivid requests on the list) was to provide as much 
information as possible about any failure instead of "terse" termination.
Reject is thus required. Whether you do it in one stage or two depends on 
implementation and exchange.

As for the capitalization - I will do it is a bit late for changes now but 
I'll keep it on the list.

Julo

"Tony Battersby" <[email-masked]>
Sent by: [email-masked]
22/11/02 00:03
Please respond to tonyb
 
        To:     <[email-masked]>
        cc: 
        Subject:        iSCSI: rejecting AuthMethod

Draft 19 Section 5.3.2 iSCSI Security Negotiation: The target MUST reply
with the first option in the list it supports and is allowed to use for 
the
specific initiator unless it does not support any in which case it MUST
answer with "Reject" (see Section 5.2 Text Mode Negotiation).

I am considering the case where the target is configured not to accept a
connection without authentication, and the target does not support any of
the authentication methods offered by the initiator.  Since the initiator 
is
not allowed to send the AuthMethod key a second time, the login attempt 
must
fail.  I assume that the target should return a Login Response with
Authentication Failure status in this case.  The first quote above implies
that the target's Login Response should in addition contain the
"AuthMethod=Reject" key.  Is this really the intended meaning?  In the
general case it is not necessary to return any keys with a Login Response
that has a nonzero Status-Class, so I do not see why this case should be 
any
different.  For consistency, I recommend changing the text to something 
like
"...in which case it MUST answer with "Reject" (see Section 5.2 Text Mode
Negotiation) or terminate the negotiation."

Incidently, the names of the Login Response status codes in section 
10.13.5
have inconsistent capitalization (e.g. "Target Moved Temporarily" vs. 
"Can't
include in session").

Anthony J. Battersby
Cybernetics