RE: UNH Plugfest 5

[Black_David@emc.com]

> Is there a reason not to allow different AuthMethods for Target and
> Initator? 

Yes, it's way too late to add this sort of functionality.  CHAP allows
Initiator-only and Initiator/Target authentication. If you want to
add additional negotiation flexibility, write it up as a separate
Internet-Draft.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Russell Lewis [mailto:russelll@us.ibm.com]
> Sent: Thursday, January 16, 2003 11:11 AM
> To: ips@ece.cmu.edu
> Subject: Re: UNH Plugfest 5
> 
> 
> 
> 
> 
> 
> Is there a reason not to allow different AuthMethods for Target and
> Initator?  Either add new text messages TargetAuthMethod &
> InitiatorAuthMethod, or perhaps allow initiators to encode 
> combinations in
> an AuthMethod:
> 
>       AuthMethod=CHAP/CHAP,CHAP/None,None/None,CHAP,None
> 
>       // CHAP/CHAP - means both are authenticated with CHAP
>       // CHAP/None - means that the Initiator is authenticated but the
> Target is not
>       // None/None - means that neither is authenticated
>       // CHAP - backwards compatibility
>       // None - backwards compatibility
> 
> 
> 
> 
> 
> |---------+---------------------------->
> |         |           "Robert D.       |
> |         |           Russell"         |
> |         |           <rdr@io.iol.unh.e|
> |         |           du>              |
> |         |           Sent by:         |
> |         |           owner-ips@ece.cmu|
> |         |           .edu             |
> |         |                            |
> |         |                            |
> |         |           01/15/03 04:28 PM|
> |         |                            |
> |---------+---------------------------->
>   
> >-------------------------------------------------------------
> -----------------------------------------------------------------|
>   |                                                           
>                                                                    |
>   |       To:       Julian Satran <Julian_Satran@il.ibm.com>, 
> "" <ips@ece.cmu.edu>                                               |
>   |       cc:                                                 
>                                                                    |
>   |       Subject:  Re: UNH Plugfest 5                        
>                                                                    |
>   |                                                           
>                                                                    |
>   |                                                           
>                                                                    |
>   
> >-------------------------------------------------------------
> -----------------------------------------------------------------|
> 
> 
> 
> 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.
> 
> 
> 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 implementors" on this in 
> the standard,
>     so that a consistent result will be obtained in this situation?
> 
> Thank you for your consideration.
> 
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
> 
> 
>