Skip to content

TLS Peer Identities

Jump to bottom
Chuck Lever edited this page Mar 23, 2022 · 2 revisions

Key requirements for NVMe-TLS

NVMe-TLS is defined only for TLS 1.3, and uses only PSKs with cipher suites TLS_AES_128_GCM_SHA256 {13h, 01h} and TLS_AES_256_GCM_SHA384 {13h, 02h}. The TLS key material is derived from either pre-provisioned PSKs to form a so-called retained key or from a generated key negotiated via a previous DH-HMAC-CHAP authentication.

The TLS identity is generated from the associated NVMe endpoint identifications (NQNs):

NVMe0<G|R>0<1|2>

resulting in a total of 4 possible TLS identification tuples:

  • SHA-256 Generated key
  • SHA-256 Retained key
  • SHA-384 Generated key
  • SHA-384 Retained key

Key requirements for RPC-with-TLS

The RPC-with-TLS specification requires the use of TLSv1.3 or newer. Host identity requirements are specified in Section 5.2 of draft-ietf-nfsv4-rpc-tls. RPC-with-TLS implementations are required to support PKIX as described in RFC5280.

Implementations may also support pre-shared keys, but that is not required.

RPC-with-TLS certificates may carry additional information.

  • The "sunrpc" ALPN identifier
  • An extended key usage value that indicates whether the peer acts as an RPC client or server
  • A SubjectAltName that matches the IP address or DNS hostname of the peer
  • A SubjectAltName that contains an RPC user ID to which the server squashes all RPC requests from this peer

RPC-with-TLS servers may operate in one of the following modes (or a mixture that depends on local security policy settings):

  • The RPC server does not require client peers to provide an identity, or if they do, does not authenticate it
  • The RPC server requires client peers to provide an identity, and it authenticates the identity before allowing the peer to issue RPC requests

RPC-with-TLS clients must always authenticate servers they connect to, and verify the chain of trust presented in the server's authentication material.

Clone this wiki locally