Towards Remote Procedure Call Encryption by Default

Opportunistic TLS was adopted (per RFC 7435) to enable gradual rollout alongside non-TLS implementations. The design explicitly acknowledges that upper-layer protocols for sensitive data SHOULD mandate stricter policies (required encryption and mutual authentication) rather than relying solely on opportunistic operation.

tls, security

Transport-layer encryption was chosen over expanding RPCSEC_GSS privacy because RPCSEC_GSS leaves parts of the RPC header in cleartext (metadata confidentiality loss), cannot be offloaded at scale (per-user keying), and its deployment complexity has historically led to non-deployment — making a weaker but widely deployed alternative preferable.

tls, security, crypto

For DTLS on UDP, the current document defines no mechanism for a server to distinguish DTLS traffic from unprotected RPC traffic on the same port; each peer matches ingress datagrams to existing DTLS session state, and any datagram failing the match is treated as a plain RPC message.

tls, udp

RPC-with-TLS fully interoperates with RPC implementations that do not support TLS: when a TLS-capable peer encounters one without TLS support, local policy determines whether to continue without TLS or terminate. The AUTH_TLS mechanism is designed so that a legacy server simply returns an error, not a STARTTLS token.

tls, security

After a DTLS session terminates, receivers MUST discard datagrams on the same 5-tuple for a sufficient time (expected to be at least 60 seconds) to ensure retransmissions have ceased and in-flight packets have been delivered.

tls, udp

An RPC server MUST listen on the same ports for (D)TLS-protected RPC programs as the ports used when (D)TLS is not available. No separate TLS-specific port is introduced.

tls, security

Certificate validation by RPC-with-TLS clients MUST include verification rules per RFC 5280 Section 6 and RFC 6125 Section 6, including checking that the expected DNS-ID or iPAddress subjectAltName of the contacted server matches its presented certificate.

tls, pkix, security

Client implementations MUST include the application_layer_protocol_negotiation(16) extension in their ClientHello and MUST include the 'sunrpc' protocol identifier. Server implementations MUST include the same extension in their ServerHello with only the 'sunrpc' identifier.

tls, security

Each RPC message MUST fit in a single DTLS record when transported over UDP. DTLS encapsulation overhead reduces PLPMTU and thus the maximum RPC payload size.

tls, udp

For protected operation on UDP, DTLS record replay protection is REQUIRED. Additionally, each DTLS handshake MUST include the connection_id(54) extension with a nonzero-length ConnectionID to support multihomed peers.

tls, udp, security

If an RPC client uses the AUTH_TLS flavor on any procedure other than NULL, or sends an AUTH_TLS probe within an existing (D)TLS session, the RPC server MUST reject the call with MSG_DENIED, reject_stat AUTH_ERROR, auth_stat AUTH_BADCRED.

tls, security

If the server's reply_stat is not MSG_ACCEPTED, its verifier flavor is not AUTH_NONE, or its verifier does not contain the 'STARTTLS' token, the RPC client MUST NOT send a ClientHello message.

tls, security

If the ServerHello message does not conform to the ALPN requirements (e.g., missing or incorrect protocol identifier), the client MUST NOT establish a TLS session for use with RPC on that connection.

tls, security

Implementations MUST NOT negotiate TLS versions prior to 1.3 (for both TLS and DTLS). Support for mandatory-to-implement cipher suites for the negotiated TLS version is REQUIRED, and cipher suites MUST provide both confidentiality and integrity protection.

tls, crypto, security

RPC-with-TLS implementations are REQUIRED to support PKIX certificate-based mutual authentication per RFC 5280. DNS-ID identifier type support is REQUIRED in both clients and servers; DNS domain names in certificates MUST NOT contain the wildcard character '*'.

tls, pkix, security

RPC-with-TLS implementations concurrent with RPCSEC_GSS MUST use GSS-API channel binding (RFC 5056) to determine when the transport provides sufficient confidentiality, and MUST provide the 'tls-exporter' channel binding type as defined in RFC 9266.

tls, security, crypto

RPC-with-TLS implementations MUST NOT use 0-RTT data (as defined in RFC 8446 Appendix E.5), because the current document provides no profile for its safe use, and replay attacks are possible during session establishment.

tls, security

Before TLS session establishment, communication appears in cleartext: transport handshake, NULL AUTH_TLS probe, and initial TLS handshake are visible. If PSK is used, the PSK identifier is exposed during the handshake and can track the RPC client. A secure client limits unprotected RPC exchanges.

tls, privacy, security

RPC-with-TLS does not protect against exposure of a user's RPC requests to other users on the same client. Multiple RPC users may share a single TLS session, making TLS credentials potentially visible to all users sharing that session; client implementations must carefully segregate TLS credentials.

tls, privacy, security

AUTH_TLS is a new RPC authentication flavor (value 7) that signals a client's desire to initiate TLS negotiation. It is used exclusively on the NULL RPC procedure to probe for server-side RPC-with-TLS support before a TLS handshake begins.

tls, security

Two modes of host authentication are defined: Server-Only Host Authentication (client is anonymous, cannot be authenticated by server) and Mutual Host Authentication (both peers authenticate via TLS; if either fails, peers MUST reject the association).

tls, security

Two new X.509 Extended Key Usage OIDs are defined: id-kp-rpcTLSClient (1.3.6.1.5.5.7.3.33) identifies a certificate issued for requesting RPC transactions, and id-kp-rpcTLSServer (1.3.6.1.5.5.7.3.34) identifies a certificate issued for processing RPC transactions.

tls, pkix, security

A new entry AUTH_TLS (value 7, description: 'Indicates support for RPC-with-TLS') has been added to the IANA 'RPC Authentication Flavor Numbers' registry.

registry, tls, security

The string 'sunrpc' (0x73 0x75 0x6e 0x72 0x70 0x63) has been registered in the IANA 'TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs' registry to identify SunRPC over TLS.

registry, tls

Two new KeyPurposeId values have been registered in the IANA 'SMI Security for PKIX Extended Key Purpose' registry: decimal 33 (id-kp-rpcTLSClient) and decimal 34 (id-kp-rpcTLSServer).

registry, pkix, tls

RPC-with-TLS implementations operating in opportunistic mode are REQUIRED to provide an audit log of RPC-with-TLS security mode selection, and must accurately represent to all RPC consumers the level of security actually in effect.

tls, security

STRIPTLS attacks: the initial AUTH_TLS probe is in cleartext, allowing an on-path attacker to suppress TLS support signaling. Mitigation options include checking DANE TLSA records before initiating RPC-with-TLS, or enforcing a policy that requires TLS on every connection and rejects fallback to cleartext.

tls, security, dns

When AUTH_SYS is used with RPC-with-TLS, mutual TLS authentication is RECOMMENDED. Without it, the server acts on RPC requests for which there is no trustworthy authentication of the client; a client can still misrepresent user identity without server detection.

tls, security

RPC-with-TLS negotiation: (1) client sends NULL RPC with AUTH_TLS credential; (2) if server replies with MSG_ACCEPTED and 'STARTTLS' verifier, client proceeds to TLS ClientHello on the same connection/port; (3) on handshake success, all subsequent traffic is TLS-protected; on failure, the failure is reported as AUTH_ERROR.

tls, security

The AUTH_TLS STARTTLS probe is a NULL RPC procedure call where the credential opaque data length MUST be zero, the verifier is AUTH_NONE with length zero, and the server's reply verifier body is exactly 8 bytes encoding the ASCII string 'STARTTLS' as a fixed-length opaque field.

tls, security