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 h0SFsZk19861 for ips-outgoing; Tue, 28 Jan 2003 10:54:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0SFsVW19856 for ; Tue, 28 Jan 2003 10:54:31 -0500 (EST) Received: from cisco.com (dhcp-64-101-211-211.cisco.com [64.101.211.211]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0SFsLB6004144; Tue, 28 Jan 2003 07:54:21 -0800 (PST) Message-ID: <3E36A7B0.98D52B8D@cisco.com> Date: Tue, 28 Jan 2003 09:54:24 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Robert D. Russell" CC: Julian Satran , ips@ece.cmu.edu Subject: Re: iSCSI: keys/parameter dependence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob Russell, I think allowing keys to be distributed over several PDUs breaks the curent CHAP authentication sequence. Consider: I->T: CHAP_A= T->I: CHAP_A= CHAP_I= CHAP_C= I->T: CHAP_N= CHAP_R= OR I->T: CHAP_N= CHAP_R= CHAP_I= CHAP_C= The target does not know how many keys to expect, so it would not know when the step is complete. I don't really see the point of allowing this anyway, as the user can already spread keys out over several PDUs with the C (Continue) bit. I would however like to the see the key ordering issue clarified in the final edit, if possible. Regards, Steve Senum "Robert D. Russell" wrote: > > Julian: > > > I agree that the wording for 1 that you suggest is better than the current > > text and If I will have a chance I will do it (during the last correction > > pass of the RFC editor - called 48 Hours). For your second point things > > are more complex and we will probably have to live with the current text. > > No problem -- sorry we didn't discover it sooner. > > Although this will probably not get into the draft, > could you confirm (or not) my interpretation of what > a "step" is in the context of an authentication exchange, > and also could you confirm (or not) my interpretation of > how these keys can be distributed over several pdus > (as in the examples I cited)? Your confirmation would > be extremely useful to us in constructing > conformance and interoperability tests. > > Thanks again, > Bob Russell > > > > > > > > > "Robert D. Russell" > > 27/01/03 21:43 > > > > To > > Julian Satran/Haifa/IBM@IBMIL, "" > > cc > > > > Subject > > RE: iSCSI: keys/parameter dependence > > > > > > > > > > > > > > Julian: > > > > A request for clarification on some wording in the current standard > > (draft 20). > > > > 1. In section 5 on page 50, in the 4th paragraph (the one starting: > > "For the keys that require negotiation ...") > > the second sentence says: > > "The other party (the accepting party) makes a selection > > based on the value or list of values proposed and includes > > the selected value in a key=value in the data part of the > > following Login or Text Response or Request." > > > > The problem is with the word "following". A very long discussion > > on the mailing list last June, under the thread > > "iSCSI: keys/parameter dependence" > > made it clear that the reply key=value to an offer does not have > > to be given in the immediately following response pdu, but can be > > delayed until some later time before the end of the negotiation > > stage. In other words, responses can be saved up and "batched" > > in a later response pdu. > > > > Therefore, I believe this intent would be better conveyed if the > > words: > > "in the data part of the following Login or Text Response or > > Request" > > in the current text on page 50 quoted above were changed to: > > "in the data part of one of the following Login or Text > > ^^^^^^ > > Responses or Requests" > > ^ ^ > > > > > > 2. There is a similar problem with some wording in section 8.2, in > > the fourth paragraph (the one starting with "Section 11 ..."). > > The discussion in this paragraph talks about "steps", and > > "exact steps", without defining what a "step" is, and I believe > > this may need some clarification. > > > > Looking at section 11.1.4, the first step is taken by the initiator > > when it sends: > > CHAP_A= > > to the target. > > The second step is taken by the target when it answers with a > > Login reject or with: > > CHAP_A= CHAP_I= CHAP_C= > > > > > > It is my understanding that in the second step, these 3 keys could > > be sent by the target in any order, for example: > > CHAP_C= CHAP_I= CHAP_A= > > and further, that they could be sent in separate pdus -- that > > is, the target could send > > CHAP_C= > > in one Login Response pdu, > > CHAP_A= > > in the next Login Response pdu, and finally > > CHAP_I= > > in the final Login Response pdu. All these pdus would belong > > to the same step, and the step would not be completed until > > all the keys had been received, regardless of the number of > > pdus that had to be exchanged to achieve this. > > > > Is this the correct interpretation of a "step"? > > > > And are the example exchanges shown above correct > > implementations of the first and second "steps"? > > > > Perhaps it would be clearer if the word "step" were actually > > used in section 11.1.4. For example, it could say: > > > > "For CHAP {RFC1994], in the first step, the initiator > > sends: > > CHAP_A=" > > > > "In the second step, the target MUST answer with .. " > > > > "In the third step, the initiator MUST continue with ..." > > > > I believe it is already clear from the wording in section 8.2 > > that a new step cannot be started until the previous step is > > completed. > > > > > > Thank you for your consideration. > > > > Bob Russell > > InterOperability Lab > > University of New Hampshire > > rdr@iol.unh.edu > > 603-862-3774 > > > >