Re: iSCSI: keys/parameter dependence

[Steve Senum <ssenum@cisco.com>]

Bob Russell,

I think allowing keys to be distributed over several PDUs
breaks the curent CHAP authentication sequence.  Consider:

    I->T: CHAP_A=<A1,A2...>

    T->I: CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>

    I->T: CHAP_N=<N> CHAP_R=<R>
    OR
    I->T: CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<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" <rdr@io.iol.unh.edu>
> > 27/01/03 21:43
> >
> > To
> > Julian Satran/Haifa/IBM@IBMIL, "" <ips@ece.cmu.edu>
> > 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=<A1,A2...>
> >     to the target.
> >     The second step is taken by the target when it answers with a
> >     Login reject or with:
> >         CHAP_A=<A> CHAP_I=<I> CHAP_C=<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=<C> CHAP_I=<I> CHAP_A=<A>
> >     and further, that they could be sent in separate pdus -- that
> >     is, the target could send
> >         CHAP_C=<C>
> >     in one Login Response pdu,
> >         CHAP_A=<A>
> >     in the next Login Response pdu, and finally
> >         CHAP_I=<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=<A1,A2...>"
> >
> >         "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
> >
> >