SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    


Home

Last updated: Tue Sep 04 01:03:57 2001
6315 messages in chronological order