-
Notifications
You must be signed in to change notification settings - Fork 17
Design Materials
As the components of ktls-utils are developed, their design can be discussed and documented here on this wiki.
Initially we envision the use of kernel keyrings for two purposes:
-
Administrative interfaces such as mount.nfs will prime a special kernel keyring (via add_key(2)) with x.509 certificates or pre-shared keys that enable ktls-utils to authenticate the communicating peers. When a handshake is needed, ktls-utils user agents search this keyring for appropriate authentication material.
-
A second kernel keyring can be used to pass handshake requests to ktls-utils using the request_key mechanism or something similar. The kernel passes a socket that needs to be instantiated for use with KTLS, and the ktls-utils user agent performs a TLS handshake on that socket and returns it to the kernel.
-
These mechanisms must maintain the authentication material separately and securely for each network namespace.
-
The user agents must support both initial session establishment and re-keying, both of which are handled via the TLS handshake protocol.
-
It might be possible to share session key material between kernel TLS sessions. Investigation is needed to demonstrate feasibility and benefit.
One long-term requirement is support for NFSROOT using TLS, and the block equivalent of hosting the root filesystem on an NVMe device using TCP with TLS. This usage scenario is impossible to implement with a user agent that is stored on the root filesystem. Once the ktls-utils infrastructure described here is established, some or all of the handshake implementation will have to be moved into the kernel to support protected root filesystems properly.