RE: iSCSI Login Questions

["Dev - Platys" <deva@platys.com>]

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

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 <ssenum@cisco.com> on 26-07-2001 00:25:19
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> To:   ietf-ips <ips@ece.cmu.edu>
> 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