Security Considerations

["VonStamwitz, Paul" <paulv@corp.adaptec.com>]

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?