RE: iSCSI: Login Proposal

["Rod Harrison" <rod.harrison@windriver.com>]

	I think we should view this as the order indicates the
initiators preference and the target SHOULD pick the first
item from the list it supports. Note that SHOULD allows the
target to do something other than pick the first item it
supports if it has a good reason to do so, e.g. If it would
otherwise terminate the session. The initiator can always
terminate the session if it doesn't like what the target
chooses.

	So, to extend your example, as an initiator if I didn't
want to do CHAP at all I would send ...

AuthMethod=none

	if I preferred not to do CHAP but I could tolerate it I
would send ...

AuthMethod=none,CHAP

	and if I would prefer CHAP I would send ...

AuthMethod=CHAP,none

	I expect this to be under the control of the sys admin
through some kind of config at the initiator side. I think a
good guide to keep in mind with all this is that it is the
initiator's data, and so it seems reasonable to let the
initiator control connection security and integrity.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Wheat, Stephen R
Sent: Tuesday, August 21, 2001 11:30 PM
To: 'Steve Senum'; ietf-ips
Subject: RE: iSCSI: Login Proposal


Yup, I thought I had seen it, but couldn't find it; thanks.
And am now
embarrassed that I couldn't find it, when it was indeed
documented in two
places.  I'll save related comments for when we go through
the spec clean-up
phase.

So, the second paragraph you cite from both p22 and p100
imply that a target
could avoid selecting "none".  Thus, the initiator could
prefer "none", but
the target still select another initiator-offered value,
hence avoiding the
situation you propose, where "none" is always selected.

Yes?

Otherwise, how would a target and initiator be able to
select "none", in the
presence of the ability to mutually do at least one method?

Aren't there times where either could do all protocols, but
both would
*prefer* to do "none"??

Perhaps my question then is to get Para5 of 1.2.4 on p22
slightly clarified,
so as to avoid your conclusion.  I.e., the initiator should
be allowed to
prefer "none" over something else, yet have the target be
capable of not
selecting "none".

Again, I agree with you that the new-and-improved-login
proposal would be
even better with a requirement to have the initiator include
its security
parameters, even if they consist of only "none".

Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 2:31 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Hi Stephen,

The current draft (-07) does actually answer your
question, though it is somewhat buried:

On page 22:

        In "list" negotiation, the offering party sends for
each key a list
        of values (which may include "none") in its order of
preference.

        The responding party answers with the first value
from the list it
        supports and is allowed to use for the specific
initiator.

And on page 100:

          -The initiator sends a text command with an
ordered list of the
           options it supports for each subject
(authentication algorithm,
           iSCSI parameters and so on). The options are
listed in the
           initiator's order of preference.

           -The target MUST reply with the first option in
the list it
           supports and is allowed for the specific
initiator....

Even so, I don't see the value in:

AuthMethod=none,CHAP

Since every implementation must support "none", "CHAP"
will never get picked.

In the interest of keeping login processing as simple as
possible, I would simply require the initiator to offer
what it can support (if anything).  The target can then
pick a compatiable method, or reject the connection.

Steve Senum

"Wheat, Stephen R" wrote:
>
> Good questions, Steve.
>
> Question 2 caused me to ponder the concept of key-value
preferences.
I.e.,
> I suspect that the concept in the proposed login spec was
to address that
> the initiator may prefer to not have any security digests,
but might be
able
> to negotiate them if the target insisted.
>
> I cannot find anywhere in the I-D that states that a
recipient MUST
consider
> key=v1,v2,v3 as the sender having preference of v1 over
v2, and v2 over
v3.
> Thus, I second Q2, but only if key values are to be
interpreted in
> preferential order.  Thus, an initiator could send
> "DataDigest=none,crc32-c,SPKM", and the target's response
MUST honor the
> preference order.
>
> So, Q4 is: should the values in a key-value list be
consider the sender's
> preference order that the receiver must honor?
>
> Stephen
>
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 1:14 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
>
> Matthew/Marjorie/Bob:
>
> Some questions on your login proposal:
>
> 1. Why the following restriction?
>
>     SecurityContextComplete=yes MUST NOT be present
>     in the login command.
>
> I don't see the benefit in not allowing something like:
>
> I: AuthMethod:none
>    HeaderDigest:crc-32c,none
>    DataDigest:crc-32c,none
>    SecurityContextComplete=yes
> T: AuthMethod:none
>    HeaderDigest:crc-32c
>    DataDigest:crc-32c
>    SecurityContextComlete=yes
>
> 2. In the following:
>
>     If the login command does not contain security
parameters
>     the target MUST perform one of the two actions below:
>
>     a) If the target requires security negotiation
>        to be performed, then it MUST enter the security
>        phase and MUST send a text response containing
>        one or more security parameters and F=0.
>
>     b)
>
> Is this really needed?  Why not simply require the
> initiator to offer security parameters if it supports
them?
> I would hope authentication would become the typical case
> for login.
>
> 3. Is there only one Login Reponse then (just asking)?
>
> Regards,
> Steve Senum