RE: iSCSI: SecurityContextComplete without operational parameters

["Barry Reinhold" <bbrtrebia@mediaone.net>]

I am in favor if this, and a new crack at the documentation of it. The
current text is getting overloaded - this does not need to be a complex
process given what we are trying to accomplish.

>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Robert D. Russell
>Sent: Wednesday, July 25, 2001 3:48 PM
>To: Jim Hafner
>Cc: ips@ece.cmu.edu
>Subject: Re: iSCSI: SecurityContextComplete without operational
>parameters
>
>
>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
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>>
>>
>