Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0GHkl117992 for ips-outgoing; Thu, 16 Jan 2003 12:46:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.corp.emc.com (mxic1.isus.emc.com [168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0GHkhW17988 for ; Thu, 16 Jan 2003 12:46:43 -0500 (EST) Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 12:46:24 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C78E@corpmx14.us.dg.com> From: Black_David@emc.com To: russelll@us.ibm.com, ips@ece.cmu.edu Subject: RE: UNH Plugfest 5 Date: Thu, 16 Jan 2003 12:45:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > 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" | > | | | | du> | > | | Sent by: | > | | owner-ips@ece.cmu| > | | .edu | > | | | > | | | > | | 01/15/03 04:28 PM| > | | | > |---------+----------------------------> > > >------------------------------------------------------------- > -----------------------------------------------------------------| > | > | > | To: Julian Satran , > "" | > | 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= CHAP_C= > worked correctly. The Initiator now sends: > I->T: CHAP_N= CHAP_R= CHAP_I= CHAP_C= > Further assume that the values CHAP_N= and CHAP_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 > > >