Painless Security

When I started working on computer security, one of the most common complaints was that it is hard to get good performance with security enabled. You don’t hear that as much today: computers are much faster and hardware acceleration is widely available. However there are some cases where performance and security are still at odds. The NFS community wants to use Remote Direct Memory Access it order to improve performance. Current NFS implementations end up needing to copy NFS data multiple times especially in the receiver. By using RDMA and by offloading TCP to the network interface controller, significant performance advantages can be gained.
However, on the surface this appears to be incompatible with NFS security. The problem is that in order to construct the security data and perform encryption you typically have to copy the data or to perform the same sorts of CPU interactions that are involved in copying. This can be handled by hardware acceleration in some protocols. However NFS uses GSS-API for security. Few if any hardware devices support accelerated handling for GSS-API. Also, efficient hardware operations have not been a requirement for the design of gss-API tokens.

IPsec seems like a good fit for RDMA security. Packets can be decrypted before they are passed to the TCP layer. There is one huge problem. The sort of infrastructure you need to authenticate IPsec is not what you typically use to authenticate NFS. IPsec authentication tends to be per-host not per-user. IPsec doesn’t have a good way to work well with Kerberos. (There are a couple of mechanisms but they have non-ideal components.) One solution would be to have separate authentication at the NFS layer and the IPsec layer. That is very problematic because it increases the cost. Also, the authentications can become mismatched and that decreases security. A huge cost is that two security infrastructures are harder to use than one.

The solution is channel binding. You generate a cryptographic name for the IPsec association. Then, you exchange an integrity protected version of this name over the GSS-API channel. Both ends of the channel confirm that the cryptographic name actually corresponds to the IPsec association. One nice thing about this is that the IPsec-level authentication doesn’t matter. It is important that both ends are the same, but it is not important to tie them to any real-world subjects. The down side of this approach is that it does require more complex interactions between the two layers. The advantage is that it actually provides security that is relatively easy to use.

Channel binding was designed for the NFS usage situation. However as Nico discusses, it can also be applied to other situations such as the web.

Unfortunately the NFS specs being presented for approval side step the problem of security that performs well completely. I think that’s going to be a long discussion.

This entry was posted on Wednesday, October 17th, 2007 at 11:59 pm by hartmans and is filed under Standards. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.