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 h0GGBjF12524 for ips-outgoing; Thu, 16 Jan 2003 11:11:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0GGBeW12512 for ; Thu, 16 Jan 2003 11:11:40 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0GGBWeP035568 for ; Thu, 16 Jan 2003 11:11:33 -0500 Received: from d03nm037.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0GGBWaV005650 for ; Thu, 16 Jan 2003 09:11:32 -0700 Subject: Re: UNH Plugfest 5 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Russell Lewis Date: Thu, 16 Jan 2003 09:10:56 -0700 X-MIMETrack: Serialize by Router on D03NM037/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 01/16/2003 09:11:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk 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" | | | | | | 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