Subject: Re: iSCSI Login Questions

From: "Julian Satran" <[email-masked]>
Date: Tue, 24 Jul 2001 10:56:52 +0300

Eddy,

This might make implementations independent of the value semantics (depend
only on the option being offered) although none is special.

But I am open to other opinions.

In the meantime I'll make the text read:

      The SecurityContextComplete handshake MUST be performed if any of
      negotiating parties has offered a security/integrity item and
      regardless of the value or list offered (even if it is not selected).

 thanks,
 Julo

"Eddy Quicksall" <[email-masked]> on 23-07-2001 21:44:04

Please respond to "Eddy Quicksall" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI Login Questions

One other question that came up at UNH was the following:

If an initiator says "AuthMethod=none<0> DataDigest=none<0>
HeaderDigest=none" in the initial login, does that mean the parties have to
use the SecurityContextComplete handshake?

Does the scope of "even if it is not selected" below include the above?

Eddy

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 23, 2001 1:50 AM
Subject: Re: iSCSI Login Questions

>
> Qin,
>
> The question Steve raised was if the example is correct and the example
is
> correct.
>
> In the example the initiator clearly indicates that it is not offering
> any Authentication method ( "none") and it might as well conclude the
> security phase.
> It does not need any additional exchange.
>
> The target can reject the login.
>
> The fact that it is no such case  included in examples does not make it
> incorrect.
>
> As for the SecurityContextComplete Steve has chose a strictly literal
> interpretation of the relevant paragraph from 4.2:
>
>       The SecurityContextComplete handshake MUST be performed if any of
>       negotiating parties has offered a security/integrity item (even if
it
>       is not selected).
>
> Julo
>
>
>
>
> Qin Tao <[email-masked]> on 23-07-2001 05:34:33
>
> Please respond to Qin Tao <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> Subject:  Re: iSCSI Login Questions
>
>
>
>
> Hi, Julian:
>
> I don't think "SecurityContextComplete=yes" should be used in the Login
> Command together with security parameters(as in Cases 1&3).
>
> Draft 07,Clause 4.1 says:
>
> "-Every party in the security negotiation indicates that it has
>  completed building its security context (has all the required
>                                ^^^^^^^^^^^^^^^^^
>  information) by sending the key=value pair:
>  ^^^^^^^^^^^
>       SecurityContextComplete=yes"
>
> When Login Command is sending out, the initiator has no idea how the
> target would response, how  could it "has all the required information"?
> In Case 1, the initiator limits the response from target by providing
only
> one option for each parameter, so that it has a good guess of the
> response. However, "a text response including only
> SecurityContextComplete=yes concludes the security sub-phase" (page 101
in
> draft 7). The initiator still needs to send SecurityContextComplete=yes
> in the next Text Command and wait for a Text Response with
> SecurityContextComplete=yes only to end the security sub-phase. It is
> meaningless to include the SecurityContextComplete=yes so early in the
> Login Command.
>
> If both Cases 2 and 3 are correct, sending "SecurityContextComplete=yes"
> becomes optional and loses its value to be used. I also checked the
"Login
> Phase Examples" in Appendix A and I did not find any example with
> "SecurityContextComplete=yes" in Login Command. Could you please give
more
> explanations on this issue?
>
> Thanks.
> Qin
>
>
>
>
> On Sat, 21 Jul 2001, Julian Satran wrote:
>
> >
> > Steve,
> >
> > All are correct.
> >
> > Julo
> >
> > Steve Senum <[email-masked]> on 20-07-2001 21:13:47
> >
> > Please respond to Steve Senum <[email-masked]>
> >
> > To:   [email-masked]
> > cc:
> > Subject:  Re: iSCSI Login Questions
> >
> >
> >
> >
> > Julian,
> >
> > Thanks for the reply.
> >
> > I have a few of more cases I would like to be sure of.
> > Please comment on whether you think the given sequence
> > is valid.
> >
> >
> > Case 1:
> >
> > I-> Login    AuthMethod=none
> >              HeaderDigest=crc-32C
> >              DataDigest=crc-32C
> >              SecurityContextComplete=yes
> > T-> Login-PR AuthMethod=none
> >              HeaderDigest=crc-32C
> >              DataDigest=crc-32C
> >              SecurityContextComplete=yes
> >
> >
> > Case 2:
> >
> > I-> Login    AuthMethod=none
> >              HeaderDigest=crc-32C,none
> >              DataDigest=crc-32C,none
> > T-> Login-PR AuthMethod=none
> >              HeaderDigest=crc-32C
> >              DataDigest=crc-32C
> >              SecurityContextComplete=yes
> > I-> Text     SecurityContextComplete=yes
> > T-> Text     SecurityContextComplete=yes
> >
> >
> > Case 3:
> >
> > I-> Login    AuthMethod=none
> >              HeaderDigest=crc-32C,none
> >              DataDigest=crc-32C,none
> >              SecurityContextComplete=yes
> > T-> Login-PR AuthMethod=none
> >              HeaderDigest=crc-32C
> >              DataDigest=crc-32C
> >              SecurityContextComplete=yes
> >
> >
> > Thanks,
> > Steve Senum
> >
> >
> >
> >
>
>
>
>
>

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 27 Jul 2001 18:52:16 +0300

Steve - please refer to my proposal for a 2 phase login?  If that fails the
we can go back to the current discussion.

Thanks,
Julo

Steve Senum <[email-masked]> on 27-07-2001 18:23:03

To:   [email-masked]
cc:

Julian,

I don't think I was clear in my last message.
My concern is not with the details of the
handshake.  I think those are clearly specified
in the current draft.

My concern is under what conditions the handshake
is done.

By my current (perhaps wrong) understanding of
draft -07, if AuthMethod, HeaderDigest, or DataDigest
is offered in the opening login cmd/login rsp,
then the handshake is a MUST.
If AuthMethod, HeaderDigest and DataDigest
are all not offered, then the handshake is a MAY.

It is the second part (the MAY) of this I am having
trouble with.  I believe it needs to be either
a MUST (handshake all the time), or a MUST NOT
(handshake not allowed if AuthMethod, HeaderDigest
or DataDigest all not offered).

Regards,
Steve Senum

Julian Satran wrote:
>
> Steve,
>
> The sequence was meant to end always with an I,T handshake. If T starts
it
> then we have a T,I,T exchange
> This is what I suggest for the my new proposal too. Phase transition
starts
> always after a complete "instruction" (request response).
>
> Julo
>
> Steve Senum <[email-masked]> on 27-07-2001 02:35:41
>
> Julian:
> If the sequences mentioned below are all valid,
> plus the trivial sequence:
>
> I-> Login
> I-> Login-PR
>
> where these are all followed by Operational
> Parameter negotiation, I have a concern.
>
> Since either side is allowed to initiate
> the SecurityContextComplete=yes handshake,
> I would think that either Initiator or Target
> would transition to the next phase too soon
> if one side thought the handshake was needed,
> and the other side didn't.
>
> The only way I see to keep this from happening
> is either:
>
> 1. Don't allow the SecurityContextComplete=yes handshake
> unless AuthMethod, HeaderDigest, or DataDigest keys
> have been offered.
>
> 2. Always require the SecurityContextComplete=yes handshake.
>
> Regards,
> Steve Senum
>
> Julian Satran wrote:
> >
> > Yes that is (in 07)  a legitmate sequence.  Julo
> >
> > Steve Senum <[email-masked]> on 26-07-2001 00:25:19
> >
> > To:   ietf-ips <[email-masked]>
> > cc:
> > Is it valid (under draft -07) to offer the
> > SecurityContextComplete key without the AuthMethod,
> > HeaderDigest or DataDigest keys having been offered?
> >
> > In other words, are the following sequences valid?
> >
> > Sequence 1:
> >
> > I-> Login    SecurityContextComplete=yes
> > T-> Login-PR SecurityContextComplete=yes
> >
> > Sequence 2:
> >
> > I-> Login
> > T-> Login-PR SecurityContextComplete=yes
> > Sequence 3:
> > I-> Login
> > I-> Login-PR