Subject: iSCSI login phasing

From: "Julian Satran" <[email-masked]>
Date: Fri, 27 Jul 2001 09:13:31 +0300

Dear colleagues,

As some of you have complained about difficulty in implementing the login
phase I thought it might be worthwhile to consider a slight departure from
the current description.

The current text assumes that negotiations are forming one tree and the
"login machine" has to parse the tree.
A leaf node will completely define a state and some pathes may get you to
error.

I was driven to this design by the need to keep the parsing tree minimal
(under the assumption that any split in subtrees
will result is some parameters needing to appear in several subtrees).

However - after the noisy (mostly UPPERCASE) debate - I came to realize
that few if any have done the generalized mapping I started with, and
implemented a parser,  and ad-hoc, man-glued, engines have to have smaller
trees for the next plugfest (although by then some bright undergraduate
student may take onto himself to give us  an open-source yacc definition of
the login phase!).

I looked at the 2 phases and the number of key=values that they share are
probably limited today at initiator and target names (some
organizations/configurations want them for authentication while some others
will object to them being revealed in the "open phase") and as such we may
want to slit the login in 2, completely bracketed, phases each of them
optional but not both:

   a security phase that if present must start with the login command and
   is bracketed by the pairs SecurityPhase=start and ended by
   SecurityPhase=end (on both initiator and target)
   an operational-parameter-negotiation phase that must follow security
   phase (if there is a security phase) and is bracketed by the pairs
   OperationalPhase=start and OperationalPhase=end (on both initiator and
   target)

Some additional rules will apply:

   No request/response will span phases
   The phase closing handshake can start on both sides but if started at
   target will be followed by an "full initiator target handshake" - i.e a
   new phase or the "curtain close" end always with the target having the
   last word.
   keys will be clearly segregated and only a few (like names) should be
   allowed in both.

Comments?

Julo

---

From: "Dev - Platys" <[email-masked]>
Date: Fri, 27 Jul 2001 08:30:14 -0700

Julian,

So this proposal allows the operational parameters to be issued during login
request itself if it there is no authentication ?

i.e.

I ->FR Login -> Operational Parameters = Start key1=x, key2 =x, Operational
Parameters = End
T ->FR Login -> Operation Parameters = Start key=x, key2=x, key3=x

In the above case, since no authentication is involved thre is no security
phase start end.

Also the keywords SecurityPhase=Start and SecurityPhase=end mandatory so to
be used even during non authentication phases.

Thanks

Deva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
Sent: Thursday, July 26, 2001 11:14 PM
To: [email-masked]
Subject: iSCSI login phasing

Dear colleagues,

Comments?

Julo

---

From: Steve Senum <[email-masked]>
Date: Fri, 27 Jul 2001 11:19:19 -0500

Julian,

Questions on your proposal.

1. Is the Initiator then required to start
   with either a SecurityPhase=start or an
   OperationalPhase=start on the initial
   login command?

2. If the Initiator started with
   OperationalPhase=start, does the target
   have any way to force a SecurityPhase=start?

Steve Senum

---

From: "Robert D. Russell" <[email-masked]>
Date: Fri, 27 Jul 2001 14:42:37 -0400

All:

Attached are 2 ASCII text files.  Once contains a state diagram
for the iSCSI Initiator login phase, the other a state diagram
for the iSCSI Target login phase.

The Initiator state machine has only 6 states with 10 allowed
transitions, and the Target state machine has only 5 states
with 7 allowed transitions.  Both diagrams have the form of
a single "spine" with minimal branching.  Error/failure
transitions are not shown, since they always result in
closing the connection during login (on the target side
a reject message may be sent first).

Both of these diagrams are based on draft 7 with simplifications
suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall,
Stephen Bailey, Barry Reinhold, myself and others.

These include:

1. Every login is split into 2 distinct subphases (security and
   operational) with a required demarcation line between them.

1. Every login starts in the security subphase and must contain
   at least the keys: TargetName, InitiatorName, HeaderDigest,
   DataDigest, AuthMethod, and optionally SessionType=Normal.

2. No operational parameters can be negotiated before or during
   the security subphase (informational parameters, like
   TargetName, although listed in Appendix D, do not require
   negotiation and are not considered "operational" here).

3. The security subphase ends with a required 2- or 3-way handshake of
   Text and Text Response PDUs containing only the
   SecurityContextComplete=yes key and ending with a message from
   the target to the initiator.  The negotiated security functions
   become effective only at the successful conclusion of this handshake.

4. The operational subphase always begins immediately after the
   handshake had been completed.  No security parameters can be
   negotiated during or after the operational subphase.

5. The operational subphase ends with a Login Response with F=1 from
   the target to the initiator, at which time both target and
   initiator are in Full Feature Phase (the final state in both
   diagrams).

Comments please.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: Steve Senum <[email-masked]>
Date: Fri, 27 Jul 2001 17:48:13 -0500

Julian,

I like the intent of your proposal, with
explict keys to mark the beginning of the phases.

I still think we could achieve most of this
with the existing handshake protocols
(SecurityContextComplete for the SecurityPhase
phase, F=1 bits for the OperationalPhase).
We just need to define exactly when the
SecurityPhase is (and is not) entered.
I still vote for going through the SecurityPhase
all the time.

But, your proposal is a bit more precise on these points,
and a more complete solution.

Regards,
Steve Senum

---

From: Steve Senum <[email-masked]>
Date: Fri, 27 Jul 2001 17:57:37 -0500

Bob,

I like your overall approach, but at this point,
I would favor Julian's proposal.  If the WG
wanted to minimize the changes though, I think
your approach should be looked at some more.

Comment:

I am a bit confused by your iSCSI Target state diagram.
I would think you should be able to go from T1 to
either T2 or T4, depending on what the login command
contained.  Something like login command with
SecurityContextComplete=yes goes to T4, else goes to T2.
Also, I would not expect to see T3 (Leave Security) as
a state.

Regards,
Steve Senum

"Robert D. Russell" wrote:
>   --------------------------------------------------------------------------------
>                Name: i_states
>    i_states    Type: Plain Text (TEXT/PLAIN)
>            Encoding: BASE64
> 
>                Name: t_states
>    t_states    Type: Plain Text (TEXT/PLAIN)
>            Encoding: BASE64

---

From: "Robert D. Russell" <[email-masked]>
Date: Mon, 30 Jul 2001 11:23:26 -0400

> SecurityContextComplete=yes goes to T4, else goes to T2.

I was assuming that the SecurityContextComplete=yes key
could not appear in the same list as other keys, and
therefore could not be in the login command because these
were required to carry the 3 security keys HeaderDigest=,
DataDigest=, and AuthMethod=.

> Also, I would not expect to see T3 (Leave Security) as

This state is needed for the case when it is the target,
not the initiator, that is the first one to send the
SecurityContextComplete=yes key (on the Z3 transition).
The target must now wait for the initiator to reply
with SecurityContextComplete=yes, and then send
SecurityContextComplete=yes again because, as described
in one of Julian's recent e-mails, the handshake
must always end with the Target sending this key to the
Initiator.

There is another assumption in this diagram, which I believe
is true for all the security negotiation dialogues proposed
for iSCSI, but I would like verification of this from others,
and that is that once one side sends SecurityContextComplete=yes,
the other side will in fact also be finished and will send
the same key back (assuming successful negotiation).
This is certainly true for all the examples shown in draft 7,
but, of course, these are only examples and do not exhaust
all the possibilities.  If there are situations where
the other side needs to continue the negotiation, then 2 more
transitions would be needed: one from state T3 back to itself,
labeled with conditions and actions similar to transition Z3,
and one from state T3 back to state T2, labeled with
conditions and actions similar to transition Z2.
Adding these transitions makes the target diagram more similar
to the initiator diagram for the two states Negotiate Security
and Leave Security.

Bob