Message-ID: <1BEBA5E8600DD4119A50009027AF54A00ECB3D45@axcs04.cos.agilent.com>
From: kevin_lemay@agilent.com
To: ssenum@cisco.com, rdr@io.iol.unh.edu, Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: keys/parameter dependence
Date: Thu, 30 Jan 2003 14:05:24 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I have to agree with Steve.

Will someone explain to me the "value add" of sending the keys in multiple PDUs? Or in some other other than shown?

I sure don't see any value and see a bunch of interop problems if we allow it.

Kevin Lemay


-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Thursday, January 30, 2003 12:46 PM
To: Robert D. Russell; Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence


Bob Russell and Julian:

"Robert D. Russell" wrote:
> 
> Steve:
> 
> > 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.
> 
> Not exactly.  As soon as it receives both CHAP_N=<N> and CHAP_R=<R>,
> regardless of whether it has CHAP_I=<I> or CHAP_C=<C>,
> the target can immediately authenticate the initiator.
> If that fails, it can immediately send a Login reject.
> If that authentication succeeds, then the target sees what it has.
> If it has both CHAP_I and CHAP_C then it replies with CHAP_N and CHAP_R.
> If it has only one of CHAP_I and CHAP_C, but not both, it replies with
> an empty login response and waits for a login request containing the
> missing CHAP_I or CHAP_C.
> If it has neither CHAP_I nor CHAP_C, then it looks at the T bit.
> If the T bit is 1, the initiator is requesting a transition out
> of security negotiation phase with this pdu, which means it is
> not intending to send either CHAP_I or CHAP_C in the future.
> In this case, the target accepts the transition and the security
> negotiation stage is finished.
> On the other hand, if the T bit is 0, the initiator MAY (or MAY NOT)
> intend to send the CHAP_I or CHAP_C in later pdus, so the target
> replies with a Login response containing no keys, and waits to
> receive further information from the initiator.

Okay, I forgot about the T bit in my last message.  But this only
works because the "step" in question is also a possible termination
point in the negotiation.  If you were to insert a variable number of
keys in the middle of this sequence, it would not work.

> 
> Although this seems like a lot of combinatorics, it really isn't,
> because the end of the security stage is always and only indicated
> by the initiator sending the T bit = 1 and the target replying with
> the T bit = 1.  Presence or absence of the CHAP keys just cause "step"
> transitions within the security negotiation stage.
> 
> I believe the "step" in question is really 2 steps:
> the step that ends when the target receives CHAP_N and CHAP_R,
> at which point it completes its initiator authentication,
> and the step that follows that one, which ends when the target
> receives the T bit = 1, at which point, if it has received
> CHAP_I and CHAP_C then it replies with CHAP_N and CHAP_R,
> and if it has not received CHAP_I and CHAP_C, then it replies
> with no keys.  In both cases, it accepts the transition out
> of security negotiation by replying with T bit = 1.

I think an implementation must be careful how they handle this,
as not to weaken the effect of the following text from section
section 8.2, "In-band Initiator-Target Authentication":

   Section 11 iSCSI Security Text Keys and Authentication Methods
   defines several authentication methods and the exact steps that must
   be followed in each of them, including the iSCSI-text-keys and their
   allowed values in each step. Whenever an iSCSI initiator gets a
   response whose keys, or their values, are not according to the step
   definition, it MUST abort the connection. Whenever an iSCSI target
   gets a response whose keys, or their values, are not according to
   the step definition, it MUST answer with a Login reject with the
   "Initiator Error" or "Missing Parameter" status. These statuses are
   not intended for cryptographically incorrect values such as the CHAP
   response, for which "Authentication Failure" status MUST be
   specified. The importance of this rule can be illustrated in CHAP
   with target authentication (see Section 11.1.4 Challenge Handshake
   Authentication Protocol (CHAP)) where the initiator would have been
   able to conduct a reflection attack by omitting his response key
   (CHAP_R) using the same CHAP challenge as the target and reflecting
   the target's response back to the target. In CHAP, this is prevented
   because the target must answer the missing CHAP_R key with a Login
   reject with the "Missing Parameter" status.

I think allowing multiple login messages per "step" adds complexity
without any gain.

Regards,
Steve Senum