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



    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:marjorie_krueger@hp.com]
    Sent: Wednesday, August 22, 2001 10:47 AM
    To: 'Rod Harrison'; ietf-ips
    Subject: RE: iSCSI: Login Proposal
    
    
    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: marjorie_krueger@hp.com 
    
    > -----Original Message-----
    > From: Rod Harrison [mailto:rod.harrison@windriver.com]
    > Sent: Wednesday, August 22, 2001 4:58 AM
    > To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
    > Subject: RE: iSCSI: Login Proposal
    > 
    > 
    > 
    > 	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
    > 
     
    
    


Home

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