SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Security Considerations



    
    In keeping with the "Guidelines for Writing RFC Text on Security
    Considerations" by E. Rescorla and B. Korver, the following is my pass at
    describing the kind of security threats our protocol could encounter. It
    does not yet include specific mechanisms that address these threats.
    
    Julian, I am sorry for the tardiness. I tried to format this in such a way
    that you could easily cut and place into your document as you see fit. I
    hope this is useful. I spoke with Luciano today, and he said he would be
    sending his contributions to you today as well. It is my belief that he will
    provide the detailed mechanisms by modifying the document directly.
    
    Unfortunately, I will be off-site and will not be able to join the
    conference call tomorrow.
    
    Paul von Stamwitz
    
    ------------------------
    Security Considerations
    
    Historically, native storage systems have not had to consider security due
    to the fact that their environments offered minimal security risks. That is,
    these environments consisted of storage devices either directly attached to
    hosts or connected via a subnet distinctly separate from the communications
    network. The use of storage protocols, such as SCSI, over IP networks
    requires that security concerns be addressed.
    
    First, a threat model needs to be developed which describes the kind of
    attacks that can be made on the protocol. It needs to be determined which of
    these attacks are out of scope and why. Then, mechanisms need to be applied
    to the protocol to protect against those attacks that are in-scope.
    
    Threat Model
    
    Attacks fall into three main areas; passive, active, and denial of service.
    
    Passive Attacks
    
    In general, data transfers will be made through a switched fabric, making
    sniffing difficult. Also, the nature of the data (block transfers), even if
    sniffed, would not necessarily be readily understandable to the attacker.
    That being said, a determined attacker could, by capturing of content and
    analyzing traffic over time, could replicate enough of a drive to make the
    captured data meaningful. Certain storage operations which are mostly
    uni-directional, such as writing to a tape or reading from a CD-ROM, are
    even more susceptible to passive attacks since the listener will be able to
    replicate most if not all of the operation.
    
    Passive attacks by traffic analysis alone is deemed out of scope since it is
    unlikely that the listener will be able to guess any pertinent information
    without knowing the content of the messages. It is also out of scope to
    detect passive attacks. The protocol must be able to prevent passive attacks
    by masking the contents of messages through some form of encryption.
    
    Finally, it is assumed that a strong authentication mechanism will be
    neccessary. Therefore, any long-lived passwords or private keys must never
    be sent in the clear. 
    
    Active Attacks
    
    Whereas passive attacks involve SNIFFING, active attacks will generally
    involve SPOOFING. If an attacker can successfully masquerade as a client, he
    will have total read/write access to those storage resources assigned to
    that client. Spoofing as a server is more difficult, since many operations
    involve client reads of some expected or otherwise understandable data.
    
    Most likely, many of the sessions will be long-lived. This feature has a
    dual effect of making these sessions more vulnerable to attack (hijacking
    TCP connections, crytographic attacks), while at the same time providing
    mechanisms to detect attacks. An attempt to open a session while one is
    already active can be treated as a possible attack. Both the transport and
    session layer protocols will have sequencing that would need to be adhered
    to be the attacker to avoid generating errors that could also be treated as
    a possible attack. 
    
    Message modification can be a significant threat to an environment reliant
    on the integrity of the data. Message replay, insertion, or deletion will
    generally produce errors (such as data overruns/underruns) that can be
    recovered successfully, they can have the effect of reducing performance,
    and as such can act as a denial of service. It is possible that an attacker
    can modify a message in such a way the the session becomes out of sync,
    resulting in a tear down of the session.
    
    Security Model
    
    No Security
    
    This mode does not authenticate nor encrypt data. This mode should only be
    used in environments where there is minimal security risk and little chance
    for configuration errors.
    
    End-to-End Authentication
    
    This mode protects against an unauthorized access to storage resources
    either through an active attack (SPOOFING) or configuration errors. 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. For example, this mode can be used when IPsec is used in
    security gateways.
    
    Encryption
    
    This mode provides for the end-to-end encryption (e.g. IPsec). It addition
    to authenticating the client, it provides end-to-end data integritya and
    protects against man-in-the-middle attacks, eavesdropping, message
    insertion, deletion, and modification.
    
    Other Considerations
    
    Due to long-lived sessions, is there a need for periodic authentication
    after the session is established? For example, should the client be
    challenged during key-alive exchanges in addition to login?
    
    Due to long-lived sessions with encryption, is there a higher level of
    vulnerability to crytographic attacks?
    
    
    


Home

Last updated: Tue Sep 04 01:08:11 2001
6315 messages in chronological order