Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h0T31jI29869
	for ips-outgoing; Tue, 28 Jan 2003 22:01:45 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from io.iol.unh.edu (io.iol.unh.edu [132.177.123.82])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0T0u6W24443
	for <ips@ece.cmu.edu>; Tue, 28 Jan 2003 19:56:06 -0500 (EST)
Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1])
	by io.iol.unh.edu (8.12.7/8.12.7) with ESMTP id h0T0rFet018324;
	Tue, 28 Jan 2003 19:53:15 -0500
Received: from localhost (rdr@localhost)
	by io.iol.unh.edu (8.12.7/8.12.7/Submit) with ESMTP id h0T0rFEK018321;
	Tue, 28 Jan 2003 19:53:15 -0500
Date: Tue, 28 Jan 2003 19:53:15 -0500 (EST)
From: "Robert D. Russell" <rdr@io.iol.unh.edu>
To: Steve Senum <ssenum@cisco.com>
cc: Julian Satran <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence
In-Reply-To: <3E36A7B0.98D52B8D@cisco.com>
Message-ID: <Pine.LNX.4.53.0301281934250.16805@io.iol.unh.edu>
References: <OFD2C5EF7D.5B1E5618-ONC2256CBB.007E891C-C2256CBB.007F2810@telaviv.ibm.com>
 <Pine.LNX.4.53.0301280944220.25583@io.iol.unh.edu> <3E36A7B0.98D52B8D@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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.

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.

Bob Russell