Subject: Re: iSCSI: SecurityContextComplete without operational parameters

From: "Jim Hafner" <[email-masked]>
Date: Wed, 25 Jul 2001 11:22:09 -0700

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" <[email-masked]>@ece.cmu.edu on 07-25-2001
11:07:26 AM

Sent by:  [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: Wed, 25 Jul 2001 15:47:32 -0400

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

---

From: "Barry Reinhold" <[email-masked]>
Date: Wed, 25 Jul 2001 17:27:42 -0400

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: [email-masked] [mailto:[email-masked]]On Behalf Of
>Robert D. Russell
>Sent: Wednesday, July 25, 2001 3:48 PM
>To: Jim Hafner
>Cc: [email-masked]