Summary

  • draft-cel-nfsv4-rpc-tls-othername-04, dated 5 September 2026, proposes carrying one RPC user identity in an X.509 subjectAltName otherName. It is an individual Internet-Draft, not an RFC, IETF consensus or deployment report.
  • An enforcing server replaces AUTH_NONE or AUTH_SYS header identity with the validated certificate identity. If mapping or authorization fails, it denies the request and must not fall back to the header.
  • A non-supporting or disabled server ignores the same field and follows ordinary RPC credential policy. The client cannot distinguish those cases, so certificate issuance is not proof that the restriction ran.

Imagine a certificate issued for a service account called backup. On one storage node, every eligible RPC call is executed as that account even if the request header claims another UID. On the next node, the certificate authenticates the TLS peer, its unfamiliar identity field is ignored, and the server considers the UID in the request as usual.

The certificate has not changed. The meaning of access has.

That is the important mechanism in revision 04 of the RPC identity-squashing draft. RFC 9289 brought TLS confidentiality, integrity and peer authentication to RPC but left RPC user authentication alone. The draft tries to join those layers for clients or services that should operate as one user: put the intended RPC identity in the client certificate, validate it when the TLS session begins, then use it instead of weaker per-request header assertions.

The proposal defines three ways to name that user. RPCAuthSys carries numeric UID and GIDs. GSSExportedName carries a mechanism-specific exported principal such as the form described for Kerberos by RFC 4121. NFSv4Principal carries the user@domain representation used by RFC 8881, leaving the server to resolve it through its owner mapping.

The forms are not interchangeable decoration. Numeric identities require consistent user and group databases. A GSS exported name depends on a mechanism the server fully supports. An NFSv4 principal depends on local domain and owner mapping. The draft therefore requires the server to examine every relevant otherName and reject a certificate if more than one identity-squashing form is present. Two possible answers are treated as ambiguity, not resilience.

The restriction exists only where code executes it

On an enforcing server, the sequence is strict. First validate the X.509 certificate under RFC 5280 and RPC-with-TLS rules. Then parse exactly one recognized identity. Derive a local RPC user. Check whether this authenticated peer may use that identity—through certificate-subject ACLs, UID and group rules, domain patterns or GSS policy. Bind the result to this TLS session.

For every AUTH_NONE or AUTH_SYS request on that session, the server ignores the credential in the RFC 5531 RPC header and executes under the derived user. RPCSEC_GSS is deliberately outside the squash: RFC 2203 already gives that request a security context that proved its own identity.

Failure is also explicit. If the certificate identity is malformed, unmappable or unauthorized, the server returns AUTH_TOOWEAK for non-NULL AUTH_NONE/AUTH_SYS procedures. It must not quietly fall back to the header identity. Such a fallback would restore the access the certificate was supposed to withhold.

But this rule cannot bind software that does not implement it. The certificate profile uses a non-critical SAN and an otherName type identifier. A conforming older application can recognize the SAN extension while not recognizing this internal type. The draft expects that server to ignore the unfamiliar entry and process requests under its normal header-credential policy. A server with the feature installed but disabled behaves the same way, and the client cannot tell which it reached.

That is not a cryptographic defect. It is a compatibility choice. Marking the whole SAN critical could make unrelated names unusable and cause older systems to reject the certificate, while the draft wants mixed deployments to interoperate. The cost is that the certificate is a request for least privilege, not a portable guarantee of least privilege.

One credential, two authorization surfaces

The operational mistake would be to inventory certificates and conclude that the control is deployed. The true inventory is a join: certificate profile × trust anchor × serving node version × enforcement setting × policy scope × mapping data × RPC flavor × session.

The draft says policy scope can be whole-server, per-export or another local unit. A binary “supports identity squashing” flag is therefore insufficient. One daemon can enforce the rule for one export and use ordinary AUTH_SYS handling for another. A load balancer or anycast service can move successive sessions across nodes with different answers.

Issuance and revocation have similar limits. A certificate carrying the field grants user-level access where it is honored, so validity periods and CRL or OCSP propagation matter. Separate trust anchors are recommended for identity-squashing certificates and certificates used only for TLS peer authentication. Yet a fresh revocation response still does not show that the field was parsed, and a correct parser does not show that the local UID or group mapping was authorized.

Revision 04 records a contributor-reported FreeBSD implementation of the user@domain form as complete. The same section says the listing is not IETF endorsement, has not been independently verified and is not a catalogue; it reports no implementation experience. RFC 7942 explains why such running-code disclosures help standards work, but a disclosure is not fleet evidence.

This is where the distinction in Heng Lu’s reality-layer note matters. The signed field, the server decision and the resource effect are related, but none substitutes for the next. Running-code primacy means the decisive fact is what each serving binary did. A minimum initial specification can define the interoperable floor without pretending that publication has installed it.

The useful audit question is therefore not “Does the certificate contain the identity?” It is “Which node proved that it used that identity for this session and refused the header alternative?”

Sources