Subject: Re: iSCSI: SecurityContextComplete without operational parameters

From: "Julian Satran" <[email-masked]>
Date: Thu, 26 Jul 2001 09:34:27 +0300

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" <[email-masked]> on 25-07-2001 21:07:26

Please respond to "Robert D. Russell" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
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
[email-masked]
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" <[email-masked]> on 24-07-2001 20:35:18
>
> Please respond to "Eddy Quicksall" <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>
> 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" <[email-masked]> on 24-07-2001 15:55:05
> >
> > Please respond to "Eddy Quicksall" <[email-masked]>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL
> > cc:   [email-masked]
> > 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?
> >
> >
> > [email-masked]
> >
> >
> >
> >
> >
>
>
>

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 26 Jul 2001 16:57:32 -0400

Julian:

As a further simplification to the login process, I believe the
InitiatorName and TargetName keys should both be required in the
login command sent by the initiator.

According to draft 7 page 158 and 159, these keys already
"MUST be provided by the initiator of the TCP connection to the remote
endpoint before the end of the login phase", and given that there is
now a separate session type for discovery, I don't see any benefit in
allowing the initiator to postpone sending these keys beyond the login
command itself, and I do see lots of simplification possible if they
are required on the login.  (Could you please give me a situation for
"normal" logins where there is a benefit to not having these keys in
the login? Does that benefit outweigh the simplifications I am suggesting
here?)

This change simplifies the wording just quoted, which becomes
"MUST be provided on the login command".

It also eliminates the phrase "Some targets MAY require this key before
authenticating." that is currently in the description of the 13 TargetName
key on page 158 of draft 7.

It also eliminates the phrase "the iSCSI Initiator Name MUST be sent
before the target is required to disclose its LUs." in section 4.1 on
page 99 of draft 7.

It also eliminates the phrase "If the iSCSI Target Name is going to be used
in determining the security mode or it is implicit part of authentication,
then the iSCSI Target Name MUST be sent in the login command for the first
connection of a session to identify the storage endpoint of the session."
in section 4.1 on page 99 of draft 7.

It also eliminates the phrase "If the iSCSI Target Name is going to be used
only for access control, it can be sent after the Security Context Complete
is achieved." in section 4.1 on page 99 of draft 7.

It also eliminates the need for status code 0x0002 in the login response
(page 73 of draft 7).

It is also my belief that coding for the login phase is simplified by this
requirement, due to the following:

  In draft 7 a target MAY need to check the login to see if it contains the
  TargetName in order to set the status code in the login response,
  and if it is missing, may need to go into a "wait for TargetName"
  state before proceeding with security checking.

  In the new version a target MUST check the login to see if it contains
  the TargetName (and InitiatorName) keys and can immediately reject
  the connection if they are missing -- no new target state is needed.

  The wording quoted above from section 4.1 talks about how these keys
  "may" be used by the target.  The problems that I see with this current
  wording is there is no way for the initiator to know in advance how the
  target will use the information (so it doesn't know exactly when in the
  login sequence to send them), and there is no way for the target to
  inform the initiator about this in advance -- the initiator must simply
  try something and hope it works.  If it doesn't, in most cases the
  connection will be rejected with "parameters missing".  Of course,
  in the case when the TargetName is missing on the login, the partial login
  response has a special code to inform the initiator of the problem --
  but suppose the target also needs the InitiatorName?  How does the
  target inform the initiator of that?  There currently does not seem to
  be a way, so after responding to the login partial response with the
  TargetName the initiator will still find the connection dropped anyway.

  I believe as a result of this complexity, most initiators will simply
  send both the TargetName and InitiatorName keys on the login command
  anyway (is there a good reason not to?), and so requiring that they
  MUST be on the login is not a hardship and will bring about the
  simplifications I just mentioned.

Thanks for your consideration,

Bob Russell
InterOperability Lab

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 26 Jul 2001 18:27:38 -0400

> 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 strongly agree with the thrust of Bob's suggestion here, but maybe
not the details.

Personally, I find the `SecurityContextComplete=' thing a bit of an
irritant.  It doesn't not add any additional information to either
end, it only reconfirms that both ends are in sync.  Every security
handshake has an architected protocol where the completion is
unambiguous to both ends, assuming the handshake has been properly
implemented.  As such, the context complete message is something that
the endpoints must check, but it's a really odd condition if you
receive it when you're not expecting it.  The exception cases are
either not getting the `ContextComplete' when you expect it, or
getting `ContextComplete' prematurely.  Either alternative indicates
an implementation bug.  Getting it prematurely is somewhat terrifying
to contemplate :^)

That said I think the login process should have little or NO branching
complexity to it.  Put another way, a state machine processing login
would be a single spine, with the only branching being for failure.

The FCP `negotiation' (AKA PRLI) is the right way to go.  That is,
EVERY parameter included in the request, and in the response.

I also agree that having a strong demarcation between security
exchange and operational parameter exchange is the right thing to do.
To be fair, I believe that this demarcation is the intent of the spec
even if it might not be well explained.

If you wanted to apply the single spine principle to security and
operational phases, you could stipulate that EVERY login have a
security exchange, even if it leads to no security.  Personally,
having a single branch in the login state machine (security ->
operational or just operational) probably wouldn't make a big
difference one way or the other.

A key question here is what's our target round trip time?  I think a
70 MS RTT is a generous target, in which case, I don't see a really
compelling reason to try an optimize for a single round-trip exchange
in the no security case.  However, maybe y'all think 1 S RTT is the
target, in which case having the possibility of one round-trip login
is a big improvement over a two-round trip login.  Of course, that one
round-trip wouldn't get you security.

Steph

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 26 Jul 2001 16:56:23 -0400

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