[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
Last updated: Tue Sep 04 01:08:11 2001
6315 messages in chronological order