Re: iSCSI: SecurityContextComplete without operational parameters

["Jim Hafner" <hafner@almaden.ibm.com>]

Rob,

It sounds to me like another way to interpret what you're suggesting is to
have two classes of Keys: Login keys (security + names, etc) and Text
message keys (operational).

Is that a valid separation?

Jim Hafner


"Robert D. Russell" <rdr@mars.iol.unh.edu>@ece.cmu.edu on 07-25-2001
11:07:26 AM

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: SecurityContextComplete without operational parameters



Julian:

I think this exchange between you and Eddy illustrates the fundamental
problem with login that everyone at the plugfest realized:
the login process is too complex, we need to simplify it.

Eddy was asking for a simplification -- that operational parameters
NOT be sent with SCC=yes.  The change you made does not do that,
and the response you gave below "If not you should be able to
handle them as you should be able to handle any set of parameters
on the same PDU." illustrates to me that you do not understand the
problem, which is that login is too complex "to handle any set of
parameters on the same PDU".  The combinations and misinterpretations
of these combinations are horrendous.  It needs to be simplified,
and that is what Eddy is asking -- do NOT allow these arbitrary
combinations.

In the rewording you added the phrase "that need to be protected" in
two places.  Please remove that phrase from both places,
because it defeats the whole purpose of the change and introduces more
ambiguity -- who decides what needs to be protected and what
doesn't?  Suppose the target decides one thing and the initiator the
other?  Where is the defined list of parameters that "need" to be
protected and those that do not "need" to be protected.  etc.

A big simplification is one requested a long time back by
Barry Reinhold and recently reiterated in a new request by
Rod Harrison of Wind River, which I strongly support, to mandate
that the login PDU MUST only contain security parameters -- no
operational parameters.  Then the login MUST ALWAYS start with
the security subphase, and MUST end with a handshake of messages
that contained ONLY SecurityContextComplete from both target and
initiator.  Only then would the operational parameter negotiation
start.  I would also add to this recommendation that for normal
logins (as opposed to discovery logins) the login MUST ALWAYS
contain the TargetName and InitiatorName keys too.  Furthermore,
if the SessionType parameter is offered, it MUST be offered on
the login.

These changes would also clean up the wording in the standard, because:

1. By prohibiting any operational parameter negotiation before the
   security subphase was completed, there would be no need for the
   new OpParmReset key (there is no way they could have changed).

2. By prohibiting any operational parameter negotiation before the
   security subphase was completed, there would be no need for the
   wording in 4.3 that talks about "Operational parameters negotiated
   inadvertently before the security/integrity negotiation"
   (a standard really shouldn't be allowing "inadvertent" things to
   happen).

3. The discussion in 4.1 about the TargetName and InitiatorName would
   be considerably simplified, since there would be no need for
   phrases like "If the iSCSI Target Name is going to be used in
   determining the security mode or it is implicit part of
   authentication," because it should just ALWAYS be sent.
   Phrases like the one just quoted cause enormous interoperability
   problems, because they introduce ambiguity that different
   implementers can resolve in different ways (who determines if
   the TargetName is going to be used? How? Who determines if it is
   implicit? How? etc.)

I believe these suggestions, most of which have been made before,
would simplify the login process.  This is done by placing restrictions
on what can be done when.  It may involve the exchange of a few
extra PDUs (ie. the text commands containing only
SecurityContectComplete=yes), but logins are not part of the critical
fast path and are not under tight time constraints -- it is more
important that they be correct, unambiguous and easily interoperable
than that they be superfast.

Thank you,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774


On Wed, 25 Jul 2001, Julian Satran wrote:

> Eddy,
>
> I understood what you are asking but I don't necessarily agree.
Operational
> parameters are problematic if you want them exchanged in a secure
> environment. If not you should be able to handle them as you should be
able
> to handle
> any set of parameters on the same PDU. The need to keep them and perhaps
> reset them is part of the negotiation process.
>
> Julo
>
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 24-07-2001 20:35:18
>
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: SecurityContextComplete without operational
parameters
>
>
>
>
> What I was actually asking for is that the target would not send any
> operational parameters in the same PDU as the SecurityContextComplete.
> Rationalization given below.
>
> Eddy
>
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Tuesday, July 24, 2001 10:08 AM
> Subject: Re: iSCSI: SecurityContextComplete without operational
parameters
>
>
> > the new text will read:
> >
> >       If the initiator has been the last to complete the handshake it
> MUST
> >       NOT start sending operational parameters that need to be
protected
> >       within the same text command; a text response including only
> >       SecurityContextComplete=yes concludes the security sub-phase.
Only
> >       the following PDU exchange is protected by digests (if any).
> >
> > If the target has been the last to complete the handshake, the
initiator
> > can start the operational parameter negotiation with the next text
> command;
> > the security negotiation sub-phase ends with the target text response.
> > However, the target handshake concluding response MUST NOT include
> > operational parameters that need to be protected. Only the following
PDU
> > exchange is protected by digests (if any).
> >
> > Julo
> >
> > "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 15:55:05
> >
> > Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL
> > cc:   ips@ece.cmu.edu
> > Subject:  iSCSI: SecurityContextComplete without operational parameters
> >
> >
> >
> >
> > In section "4.2 iSCSI Security and Integrity Negotiation", it would be
> best
> > if the target is required to send SecurityContextComplete=yes without
any
> > new operational parameters within the same PDU.
> >
> > It makes coding cleaner because the initiator can have a simple
> > send/receive
> > loop that pops out when security is complete. If operational parameters
> are
> > allowed with SecurityContextComplete=yes, the initiator's security
module
> > must also have operational parameter code or it must set flags, leave
> > information in buffers, etc that all create messy code.
> >
> > The spec says:
> >
> >            If the initiator has been the last to complete the handshake
> it
> >            MUST NOT start sending operational parameters within the
same
> >            text command.
> >
> > How about if we say the same thing for the target? There shouldn't be
any
> > harm because I suspect everyone is doing that anyway.
> >
> > Comments?
> >
> >
> > Eddy_Quicksall@iVivity.com
> >
> >
> >
> >
> >
>
>
>