SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI - Change - Login/Text commands with the binary stage code



    
    Bill,
    This IPSec is not enough, you need to ensure that the initiator you are
    connected too, is who it claims to be in the eui, or iqn iSCSI Initiator
    Names.  It could lie and get at LUNs that he is not authorized to get at.
    Subsequent iSCSI Authentication must be done to prevent this masquerade.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com
    
    
    "Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/30/2001 11:49:01 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
    Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
          code
    
    
    
    Ok,
    
    I am confused here (or maybe it is just a lag effect for me)
    
    I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
    So basically the process is this
    
    1) Administrator makes several entries into a Security Policy Database
    2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
    3) The IPsec packet filter detects this packet, realized there isn't a
    security association for it, and asks the Security Policy Database what to
    do about it
    4) The security Policy Database may determine that an IPsec SA needs to be
    established so tells IKE to negotiate with the remote peer
    5) An IKE negotiation proceeds until either it succeeds or fails
    6) If it fails, packets are dropped
    7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
    filters
    8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
    negotiated.
    
    Now under this scenario there is no need for iSCSI to negotiate security at
    all.  I DO now see the need to include an iSCSI Login phase that includes
    passing user identities across so targets and initiators can identify
    themselves, but this is over a secure link (see the above discussion) so I
    can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
    will secure it for me...
    
    Bill
    Sanera Systems Inc.
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Julian Satran
    Sent: Wednesday, August 29, 2001 2:40 PM
    To: ips@ece.cmu.edu
    Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
    code
    
    
    
    Steve,
    
    Implement and use are different terms. An administrator might set it up not
    to use security under specific conditions.
    
    Julo
    
    Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28
    
    Please respond to Steve Senum <ssenum@cisco.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ietf-ips <ips@ece.cmu.edu>
    cc:
    Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
          code
    
    
    
    Julian,
    
    In the following section:
    
       If the initiator decides to forego the SecurityNegotiation stage it
       issues the Login with the CNxSG set to LoginOperationalNegotiation in
       the current stage and the target may replay with a Login Response
       indicating that it is unwilling to accept the connection without
       SecurityNegotiation and terminate the connection.
    
    This seems contrary to the requirement to implement
    authentication (at least AuthMethod=SRP).  I realize
    this could also be a configuration issue, but I wonder
    if the spec should at least strongly recommend starting
    with phase SecurityNegotiation, or better yet, make it
    a SHOULD?
    
    Regards,
    Steve Senum
    
    
    
    
    
    
    
    


Home

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