Re: iSCSI login phasing

["Julian Satran" <Julian_Satran@il.ibm.com>]

If the initiator is willing to do security but would rather not offer
anything it will start with a
SecurityPhase - without any offering.

If it starts with OperationalPhase it indicate it is not willing/capable of
doing security.
The target can only accept or reject.

Julo

Steve Senum <ssenum@cisco.com> on 27-07-2001 19:19:19

Please respond to Steve Senum <ssenum@cisco.com>

To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI login phasing




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

Julian Satran wrote:
>
> 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