Re: iSCSI: SecurityContextComplete without operational parameters

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Jim:

We already have the classification of keys into security
(given in Appendix A) and operational (given in Appendix D),
although a few of the keys in Appendix D (TargetAddress, TargetName,
TargetAlias, InitiatorName, InitiatorAlias) are really
informational parameters (a third category) since they cannot
be negotiated.

The problem is the way these are negotiated during login.
The simplification most people want is to ALWAYS start a login
with a security negotiation subphase that involves NO operational
parameter negotiation (the informational parameters are ok).
This phase ALWAYS ends with an exchange
of messages (a "handshake") containing the key
SecurityContextComplete=yes and no other security keys and no
operational keys.
Only after this exchange should any operational parameters be
negotiated in additional messages.

If no security is wanted, a login command with F=0 can start the
handshake by offering SecurityContextComplete=yes (along with
the TargetName= and InitiatorName= keys, which should ALWAYS be
required on the login command), and the target can respond
with a login response with F=0 and containing only
SecurityContextComplete=yes.
Then and only then can operational parameters be negotiated.

If neither security nor operational parameters need to be negotiated,
the login command is as above but with F=1, and the target response
as above but with F=1.  At that point, both sides are in full feature
phase.

It is simple and unambiguous.

Bob



On Wed, 25 Jul 2001, Jim Hafner wrote:

> 
> 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 
> 
>