|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Login Proposalnone first is definitely legal (although it may invite the question "who's first" :-)) Julo "Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 22-08-2001 03:13:21 Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com> Sent by: owner-ips@ece.cmu.edu To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu> cc: Subject: RE: iSCSI: Login Proposal We're so close!! See comments (***) below, Stephen -----Original Message----- From: Steve Senum [mailto:ssenum@cisco.com] 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: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
Home Last updated: Tue Sep 04 01:03:57 2001 6315 messages in chronological order |