Subject: RE: iSCSI: Login Proposal

From: "Wheat, Stephen R" <[email-masked]>
Date: Tue, 21 Aug 2001 17:13:21 -0700

We're so close!!  See comments (***) below,
Stephen

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 4:56 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal

Hi Stephen,

I think the assumption is that <something> is usually
preferred over <none>.
*** But we have the option to specify deterministic behavior,
*** over accepting assumptions.

Even if an option is required to be implemented
though (like crc-32c), an Initiator or Target
could be configured to not allow it (including <none>).
However, in such cases, it would be easy to get
into a situation where the Initiator and Target
will never agree and no connection is possible.

I think the offering party (usually the Initiator)
need to be allowed to control the preference.
*** yes, yes, yes, yes, so let it be possible to put <none> first.
*** We get determinism and flexibility.

Steve Senum

"Wheat, Stephen R" wrote:
> 
> 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:[email-masked]]
> 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:[email-masked]]
> > 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

---

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 08:36:11 +0100

Steve,

The reason why it was decided to do this was two fold:

If the initiator does not want to negotiate security then it must not have
any security parameters in the login command.  Therefore
SecurityContextComplete=yes is unnecessary.

If the initiator does want to enter into security as per your example, then
it MUST not send SecurityContextComplete=yes as its security context is not
yet built: Page 101 of 0.7 states that

QUOTE
-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: 
            
UNQUOTE

My understanding is that its security context is not yet built until it has
received the security parameter replies from (in your example) the
initiator.

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal

Matthew/Marjorie/Bob:

I: AuthMethod:none

2. In the following:

    b)

Regards,
Steve Senum

---

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 09:24:21 +0100

Hi Steve,

I forgot to answer your latter two questions in my earlier email!

Comments within:-

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal

Matthew/Marjorie/Bob:

I: AuthMethod:none

2. In the following:

    b)

MATTHEW: So I was maintaining flexibility here.  If an initiator prefers not
to negotiate security then why force it? Also, the login is faster if
neither side want to negotiate security.  I think the majority of people
would go for flexibility and provided that the procedure caters for all four
scenarios of either side wanting/not wanting security then the flexibility
should be present.  In other words, as long as the flexibility does not
cause interoperability problems and allows everyone to do what they want to
do then the flexibility should be there. I agree that the typical case would
be to include authentication but some people will always want to skip it.

MATTHEW: yes.  In deriving the proposal we came to the conclusion that the
partial login response is unnecessary so we removed it.  Also, some
implementers have said that this makes the implementation easier as they
will always return a text response unless login is completed (successfully
or otherwise).

Regards,
Steve Senum

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 22 Aug 2001 13:58:33 +0300

none first is definitely legal (although it may invite the question "who's
first" :-))  Julo

"Wheat, Stephen R" <[email-masked]>@ece.cmu.edu on 22-08-2001
03:13:21

Please respond to "Wheat, Stephen R" <[email-masked]>

Sent by:  [email-masked]

To:   "'Steve Senum'" <[email-masked]>, ietf-ips <[email-masked]>
cc:
Subject:  RE: iSCSI: Login Proposal

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 4:56 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal

Hi Stephen,

Steve Senum

clean-up
target
but
the
the
clarified,
list
that
sender's

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 22 Aug 2001 10:47:27 -0700

I'm thinking a little differently regarding which party has priority in
chosing security parameters - while it *may* be the initiators data, this
can't be established until the initiator is authenticated.  Since the target
is the "server" side, I think the burden is on the target to ensure that
this is the intended initiator.  Therefore, the target must dictate the
authentication method used, since it has the security responsibility and the
"contact point" for potentially malicious entities.  Consider the example
where an initiator was previously authenticated using Kerberos, the session
was ended, and a new session is requested by what appears to be the same
initiator, but the authmethod requested is now "none".  Looks pretty
suspicious to me.  It seems to me like the target has the responsibility of
maintaining a consistent authmethod with all initiators that access it,
therefore the target MUST force the minimum level authorization it requires
or reject the login request.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> From: Rod Harrison [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 4:58 AM
> To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> 	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
>

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Wed, 22 Aug 2001 11:01:54 -0700

Marjorie,

I agree with your premise that the target must be allowed to not just let
anyone in.

But why isn't this already covered by the ability of the sys admin to
configure the target to only agree to certain offerings?  Quoting from
1.2.4, with my
emphasis,
   "The responding party answers with the first value from the list it
supports and
    is **allowed** to use for the specific initiator."

For some network interfaces,
the sys admin could rely upon physical security and other means inherent to
the
environment.  In such cases, the admin could configure the target to follow
the
initiator's preferences, including "none".

For other network interfaces where the environment is not inherently
trusted,
the sysadmin would be motivated to not allow the target to
connect without any authentication; so they'd set it up to not accept
"none", even
though the initiator may prefer "none".

Yes?

Stephen

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 10:47 AM
To: 'Rod Harrison'; ietf-ips
Subject: RE: iSCSI: Login Proposal

Marjorie Krueger

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Wed, 22 Aug 2001 16:48:39 -0700

Matthew,

At the risk of violating IETF protocol, I have a new question on the Login
Proposal and a comment on Steve's earlier question.  Please let me know if I
should really have segregated these into two messages.

My question is: Does the Login Proposal propose Restart Login Command no
longer be implemented?  If so, ok fine.  If not, then where can I find the
logic of Restart and having it overlaid with Login versus having a message
type of its own?  E.g., CoalesceCIDs:

	CID 1 is in effect, but Initiator wants to restart it

	I->T  Login CID2
      T->I .... full login process, yadda, yadda
	I->T ....
	T->I  Login CID2 accepted

	I->T CoalesceCIDs CID1 to CID2

	Target verifies CID1 and CID2 are equivalent in all aspects,
		authentication, security, etc.  If so, Target Logs out CID1,
		moves all CID1 state to CID2, and closes TCP connection
associated with CID1.
		The target then replies with success.  Both parties then
mutually rename CID2
		to be CID1.
		If CID1 and CID2 are not equivalent, target logs out CID2
with coalesce failure.

Frankly, I don't know why we really would want Restart semantics, versus
just logging it out.  And as such, I'd prefer removing Restart Login from
the spec.

----------------------

Regarding your answer to Steve's second question...

Given the near consensus on the ability to have <none> listed first, second,
..., last, or not at all, it would appear that we could require an initiator
to include all auth and digest methods it supports AND is willing to have
selected by the target, in preferential order.

In this case, all required flexibility exists, and several protocol
scenarios are removed, thus simplifying the process.  Yes, this is at the
cost of an extra message exchange, but only in what both you and Steve
thought were rare cases.  Is the potential saving of that message exchange
worth the additional scenarios?  I think not.

Stephen

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 1:24 AM
To: 'Steve Senum'; ietf-ips
Subject: RE: iSCSI: Login Proposal

Hi Steve,

Comments within:-

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal

Matthew/Marjorie/Bob:

I: AuthMethod:none

2. In the following:

    b)

Regards,
Steve Senum

---

From: [email-masked]
Date: Fri, 24 Aug 2001 09:06:05 -0400

> Does this mean that we are not considering the login code sent out by
> Matthew as a proposal?

I'm not sure.  The revised text that Julian sent out is in accordance
with the direction set in the London meeting.  I would suggest that the
right thing is for Matthew and team to update their proposal to be based
on the new text from Julian and submit the result as an Internet-Draft
so that we can track changes to their proposal.  The biggest virtue
of an internet draft is that it provides a stable point of reference
for a multi-week discussion on the list, which may be necessary for
login.  Ok?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------