Subject: Re: iSCSI Login Questions

From: "Julian Satran" <[email-masked]>
Date: Thu, 26 Jul 2001 11:02:19 +0300

Yes that is (in 07)  a legitmate sequence.  Julo

Steve Senum <[email-masked]> on 26-07-2001 00:25:19

Please respond to Steve Senum <[email-masked]>

To:   ietf-ips <[email-masked]>
cc:
Subject:  Re: iSCSI Login Questions

Julian,

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
I-> Text     SecurityContextComplete=yes
T-> Text     SecurityContextComplete=yes

Sequence 3:

I-> Login
I-> Login-PR
I-> Text     SecurityContextComplete=yes
T-> Text     SecurityContextComplete=yes

Thanks,
Steve Senum

---

From: Steve Senum <[email-masked]>
Date: Thu, 26 Jul 2001 18:35:41 -0500

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

---

From: "Dev - Platys" <[email-masked]>
Date: Thu, 26 Jul 2001 18:58:42 -0700

Steve,

I've closely following the thread and after going through the interactions,
I think I've to clear my doubts and present my opinion. If I am NOT on right
track, please set me straight.

I agree that the current login sequence is highly flexible and compliance
testing between initiator and targets will become a real issue.
As said else where in this discussion we should give thoughts to reducing
the number of handshakes for a login with and without authentication.

I would also think that the initiator has implied that authmethod is none by
not including it. Hence the following sequence is OK. I think if the order
of the key=value pair of authentication namely authmethod (if not present
assumed no authentication), SecurityCompleteContext=Yes be specified to be
ahead of the other parameters. It will be helpful but not a necessity
though.

 I-> Login    SecurityContextComplete=yes + additional parameters.
 T-> Login-FR SecurityContextComplete=yes + additional parameters

I think the side that requires authentication will give an error. If it is a
target then login response will be an error code
of authentication failure and if it is the initiator it can decide not to
connect to the target by logging off the connection.

BTW, Which one of the sequences are you suggesting? I guess you are for
sequence 2) below.

1) I -> Login - AuthMethod=None
T -> Login PR - SecurityContextComplete = Yes (May send a final response
with error if the target requires authentication)
I -> Text FR -  SecurityContextComplete = Yes + additional parameters
T -> Target Final Response - SecurityContextComplete = Yes + additional
parameters

2) I -> Login - AuthMethod=None
T -> Login PR - SecurityContextComplete = Yes (May send a final response
with error if the target requires authentication)
I -> Text PR -  SecurityContextComplete = Yes
T -> Text PR - SecurityContextComplete = Yes
I -> Text FR - Parameters for negotiation
T -> Target Final Response - Negotiated parameters

thanks & regards

Deva

I-> Login
I-> Login-PR

Regards,
Steve Senum

---

From: Steve Senum <[email-masked]>
Date: Fri, 27 Jul 2001 10:55:37 -0500

Deva,

I think I might have lead you down the wrong track,
at least with respect to what problem I was
trying to discuss in my last message to Julian.

See my reply to Julian on this thread.

BTW, I would prefer to keep Operational Parameters
Negotiation start after the final handshake message
(sequence 2 below).

Steve Senum