Re: UNH Plugfest 5

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

Bob,

First on behalf of the entire team thanks
for the great job.

As for the two issues:

"Robert D. Russell" <rdr@io.iol.unh.edu>
wrote on 16/01/2003 01:28:21:

> Julian:
> 
> Two more questions arose at the plugfest today, 15-Jan-2003.
> 
> 1.  A question arose as to the proper target response during
the following
>     CHAP authentication exchange.
> 
>     Assume that:
>         I->T:   CHAP_A=5
>         T->I:   CHAP_A=5 CHAP_I=<i>
CHAP_C=<c>
>     worked correctly.  The Initiator now sends:
>         I->T:   CHAP_N=<n> CHAP_R=<r>
CHAP_I=<i> CHAP_C=<c>
>     Further assume that the values CHAP_N=<n> and
CHAP_R=<r> are
>     correct, so that the initiator is successfully authenticated
by the
>     target and the target will allow it access to the target's
resources.
> 
>     The problem arises because the target does not want
to be
>     authenticated by the initiator, for whatever reason
-- perhaps it has
>     no CHAP_N value to return for this initiator, or it
has no secret
>     to use in calculating a value to return for CHAP_R,
or whatever.
>     If the initiator had not sent the CHAP_I and CHAP_C
keys, both
>     sides would have been happy and the login would proceed.
 But the
>     initiator did send those keys and the target does not
want to see
>     them.  So, what should happen?
> 
>     There appear to be at least the following 4 possibilities.
> 
>     a.  The target replies: CHAP_I=Reject CHAP_C=Reject
>         This does not appear to be correct because
the target is
>         expected to reply to the pair of keys
CHAP_I, CHAP_C with
>         different keys (i.e., CHAP_N and CHAP_R),
not the same keys.
>         Furthermore, the target already sent CHAP_I
and CHAP_C
>         earlier in the exchange, so this would
be sending the same
>         key twice.  Certainly the initiator
is not expecting to
>         receive CHAP_I and CHAP_C again.
> 
>     b.  The target replies: CHAP_N=Reject CHAP_R=Reject
>         This does not appear to be correct because
these are not
>         replies to offers of CHAP_N and CHAP_R,
but to offers of
>         different keys (i.e., CHAP_I and CHAP_C).
 However, they
>         could be considered "replies"
of sorts to the initiator's
>         "offer" of CHAP_N and CHAP_R,
but that is stretching things.
> 
>     c.  The target replies with a login reject, but
it is not
>         clear what status code to use in this
login reject pdu:
>             0x0200  is not accurate,
because it is not an initiator
>                    
error.
>             0x0201  is not accurate,
because the initiator WAS
>                    
successfully authenticated.
>             0x0202  is also not
accurate because the initiator
>                    
IS allowed access to the given target.
>             0x0300  is not accurate,
because it is not a target
>                    
error.
>             A new access code could
be invented "The target will not
>                    
authenticate itself".
> 
>         However, in this present situation, a
login reject is probably
>         not what the target wants to send, because
it is willing to
>         allow this initiator to proceed without
target authentication,
>         and thus the target does not want to terminate
the login exchange.
> 
>     d.  The target replies with no keys, and if the
initiator offered
>         a transition out of security negotiation
phase (i.e. T=1 and
>         NSG=1 or NSG=3) then the target accepts
the transition.  If the
>         initiator does not like going on without
having the target
>         authentication, it can always just close
the connection upon
>         receiving this reply.  If the initiator
did not offer a
>         transition out of security negotiation
phase, the target can
>         only reply with T=0 and NSG=0, and will
continue doing this for
>         all subsequent login requests until either
the initiator offers
>         a transition or drops the connection.
> 
>     Solution d appears to be the most flexible, because
the decision to
>     ask for target authentication was made by the initiator,
and solution
>     d leaves it up to the initiator to decide whether or
not it will
>     proceed when the target refuses to provide this authentication.
> 
>     In any case, there appears to be a need for some clarification
>     in the standard to cover this situation.
> 
> 

C is the behaviour we intended. As it does not look
like another error response is warranted i will update
the code explanation to read:

The initiator could not be successfully authenticated,
or target
authentication is not supported.

and make 11.1.4 read:

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 either
answer with a Login reject with "Authentication
Failure" or reply
with:

CHAP_N=<N> CHAP_R=<R>

Obviously a carefully designed initiator
should be prepared to handle case d  although this is not the cannonical
target behavior.

> 2.  The question arose with regard to how an initiator maps a
scsi
>     "bus reset" onto iscsi (this may be a legacy
situation).  Some vendor
>     initiators are simply doing a session logout, but other
vendors claim
>     this is not sufficient, and that to correctly emulate
a "bus reset"
>     the initiator needs to do a task management function
TARGET WARM
>     RESET, or, since that is optional to implement, when
it is not
>     implemented then the initiator needs to issue a task
management
>     function LOGICAL UNIT RESET for all active LUNs in that
session.
> 
>     Can/should there be a "note to implementers"
on this in the standard,
>     so that a consistent result will be obtained in this
situation?
>
Rob Elliot has already commented on that and I can
add little to his comments. Resets where intended as "big hammer"
commands - and I assume that this is what happened on the old parallel
bus SCSI devices. I doubt this will be appropriate for a networked device.
 
> Thank you for your consideration.
> 
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774