SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: security model



    We are now working on the on integrating the security model in the iSCSI draft.
    Some remarks considering your model:
    
    The data privacy (number 5) should be solved in a higher level, i.e., the block
    should be encrypted or digested by some hash before it is sent to the target.
    This issue is not in the scope of the transfer protocol.
    
    Number 2 should be expanded to initiator and target masquerading. If the enemy
    masquerades as the target, he can get all our secrets...
    
    Furthermore, the security considerations are affected by the performance
    consideration, i.e., the computation power and the transfer rate. Thus, in
    high-speed network, compromise should be made (it is not feasible or very
    expensive to totally secure the data in 1G). The security model should adjust
    itself to the nature of the iSCSI features. It should enable partial security
    (only command, only headers, digestion of data etc.)
    
    We are now in an intensive work to integrate the security issue in the next
    draft. The login chapter will enable to establish a flexible and negotiable
    security/authentication model for the iSCSI session.
    
    Any ideas, comments and solution regarding security, let me know,
    
    Reagrds,
    
    Yaron
    
    
    
    
    Dave Nagle wrote:
    
    > From: Banu Ozden & Mike Reiter
    >
    > We suggest the attached extensions to the security model proposed in
    > the iSCSI draft (Section 6).
    >
    > The existing iSCSI security model covers "communication security"
    > between an initiator and a target. It does not address "data
    > security".  Data security provides protection against possible attacks
    > to the data stored at the target. These include threats like
    > unauthorized disclosure of data at the target to administrators or
    > other clients of the target, and unauthorized modification of data at
    > the target.
    >
    > Our main motivation is to enhance the security model for storage
    > outsourcing environments where the Storage Service Provider (SSP)
    > personnel is not necessarily trusted or where the sharing of target
    > between different customers of the SSP raises a security concern.
    >
    > We are working on a security architecture for storage outsourcing.
    > We would like to know whether there is interest on including data
    > security considerations to iSCSI in addition to communication
    > security.
    >
    > Banu Ozden & Mike Reiter
    >
    > Bell Labs
    > 600 Mountain Ave.
    > Murray Hill, NJ 07974
    > http://www.bell-labs.com/who/ozden
    > http://www.bell-labs.com/who/reiter
    >
    > _______________________________________________________________
    > Threat Model
    >
    > T1. Disclosure of message contents to an eavesdropper intercepting
    >     communication between an initiator and a target.
    >
    > T2. An attacker masquerading as the initiator to a target or the target
    >     to an initiator. This includes an attacker manipulating communication
    >     between an initiator and a target, e.g., to introduce false messages,
    >     modify passing messages, or delete messages.
    >
    > T3. Disclosure of data to personnel maintaining the target or to other
    >     customers of the target.
    >
    > T4. The modification of data by the target or other customers of the
    >     target.
    >
    > Security Model
    >
    > 1. No Security (same as described in the iSCSI draft)
    >
    >      This mode does not authenticate nor does it encrypt data. This mode
    >      should be used in environments where there is minimal security risk
    >      and little chance for configuration errors.
    >
    > 2. Entity Authentication (referred to as End-to-End Authentication in the
    >    iSCSI draft)
    >
    >      The initiator's and/or target's identity is authenticated.
    >      Once the client is authenticated, all messages are
    >      sent and received in the clear.  This mode should only be used when
    >      there is minimal risk to man-in-the-middle attacks,
    >      eavesdropping, message insertion, deletion, and modification.
    >
    > 3. Message Integrity (new)
    >
    >      This mode protects against T2 types of threats. It provides
    >      communication integrity.
    >
    > 4. Message Integrity Combined with Encryption (referred to as Encryption in
    >    the iSCSI draft)
    >
    >      This mode protects against threats T1 and T2. Thus, it provides
    >      communication integrity and communication privacy. It protects against
    >      man-in-the-middle attacks, eavesdropping, message insertion, deletion,
    >      and modification.
    >
    > 5. Data Privacy (new)
    >
    >      This mode protects against T3 types of threats. The initiator
    >      encrypts/decrypts data. The target stores encrypted data.
    >
    > 6. Data Privacy with Data Integrity
    >
    >      This mode protects against threats T3 and T4.
    >
    > 7. Some combinations of the above security options
    >
    >    For example, data privacy with message authentication (5 & 3)
    >    protects against threats T1, T2 and  T3.
    
    

    • References:


Home

Last updated: Tue Sep 04 01:07:35 2001
6315 messages in chronological order