Re: iSCSI: SecurityContextComplete without operational parameters

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

Julian:

> I DO UNDERSTAND both the complexity of writing and implementing a protocol.

I do not doubt this, and apologize for anything I said that would lead
you, or anyone else, to infer otherwise.


Let me make my request again in different words:

I believe the login process would be considerably simplified if it
were cleanly separated into two distinct subphases: the security
negotiation subphase, and the operational parameter subphase, with
a REQUIRED demarcation line (i.e., the SecurityContextComplete=yes
handshake) between them.

I also believe the following will simplify the login process further
(I hasten to add that these are not all my ideas -- most if not all have
been mentioned by several other people in e-mails posted over the past
several months -- I am attempting here to simply bring them all together
and to supply additional justification for them):

- if every login for a "normal" session (as opposed to discovery, etc.)
  must always start in the security subphase,

- if before or during the security subphase operational parameters MUST NOT
  be offered or negotiated,

- if this subphase MUST be terminate with an exchange of messages
  each containing only the key SecurityContextComplete=yes (plus
  perhaps informational keys, such as TargetName=, InitiatorName=, etc.,
  but no other security keys and no operational keys).  This exchange
  can be initiated by either the target or the initiator, and is
  completed by the response from the other party, at which time both
  parties put the negotiated security measures into effect.
  Only after this can operational parameters be sent by either side.

If this is done:

- we can eliminate the sentence in section 4.2 page 101
  of draft 7 "When establishing the security context, any
  operational parameters sent before establishing a secure context
  MUST be discarded by both the target and the initiator."

- The beginning of section 4.3 page 102 of draft 7 can be simplified
   by eliminating the phrase: "- starting with the Login command if the
   initiator does not offer any security/integrity option"

- The beginning of section 4.3 page 102 of draft 7 can be simplified
   by replacing the whole paragraph:
     "An operational parameter negotiation on a connection SHOULD not
     start before the security/integrity negotiation if such a negotiation
     exists.  Operational parameters negotiated inadvertently before the
     security/integrity negotiation MAY be reset after the security/
     integrity negotiation at the explicit request of the initiator or
     target"
  with the simpler:
	 "Operational parameter negotiation on a connection MUST not start
	 start before the security/integrity negotiation has completed
	 successfully."

- the newly added key 35 OpParmReset on page 167 and 168 of draft 7
  is entirely eliminated.

I also strongly support:
- the suggestion from Steve Senum that the initiator be required to
  send the AuthMethod, HeaderDigest and DataDigest keys on every login
  for a "normal" (as opposed to "discovery", etc.) session.
- with the simplification suggested by Rod Harrison that if the initiator
  supports no security then the login command should contain only
  SecurityContextComplete=yes.
Together these would ensure my first point above, namely that every login
always starts in the security subphase.

I would ask if there is any justification for NOT doing what Steve
and Rod are suggesting?

I will also suggest a further simplification in a follow up e-mail,
but this one is already long enough.

Thank you for your consideration.

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


On Thu, 26 Jul 2001, Julian Satran wrote:

> Robert,
> 
> I DO UNDERSTAND both the complexity of writing and implementing a protocol.
> I do also understand that as long as we require negotiations to be atomic
> with regard to a complete sequence
> buffering and keeping temporary values must be implemented anyhow and
> adding restrictions does not simplify the task - as any restriction in the
> protocol adds a test.
> 
> What I really do not understand is your apparent belief that by making the
> language of your statements "stronger" your will make your arguments more
> convincing.
> 
> Julo
> 
> "Robert D. Russell" <rdr@mars.iol.unh.edu> on 25-07-2001 21:07:26
> 
> Please respond to "Robert D. Russell" <rdr@mars.iol.unh.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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 
> 
>