]> FreeBSD Project

Canada rmacklem@uoguelph.ca

United States of America cel-ietf@chucklever.net

Web and Internet Transport Network File System Version 4 x.509 SubjectAltName otherName NFS SunRPC This document extends RPC-with-TLS so that a client's x.509 certificate may carry instructions to the RPC server to execute all RPC transactions from that client as a single user identity. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the nfsv4 Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

Background The Remote Procedure Call version 2 protocol (RPC, for short) has been a Proposed Standard for three decades (see and its antecedents). Upper layer protocols such as the Network File System family () are based on RPC. In 2022, the IETF published , which specifies a mechanism by which RPC transactions can be cryptographically protected during transit. RFC 9289 provides confidentiality and integrity of RPC traffic and authenticates the communicating peers.

Problem Statement states that:

• RPC user authentication is not affected by the use of transport layer security. When a client presents a TLS peer identity to an RPC server, the protocol extension described in the current document provides no way for the server to know whether that identity represents one RPC user on that client or is shared amongst many RPC users. Therefore, a server implementation cannot utilize the remote TLS peer identity to authenticate RPC users.

Mobile devices such as laptops are typically used by a single user and do not have a fixed, well-known IP address or fully qualified DNS name. Without either, the server has fewer verification checks available on the client's X.509 certificate. This extension allows a server to restrict access from such a client to a single user identity, limiting exposure if that certificate is compromised. When a service runs in a dedicated VM or container, it often runs as a single assigned user identity. Kerberos is poorly suited here: TGTs expire in hours, yet the service may run for much longer. This extension lets the client convey that identity in the certificate, which does not expire on the same short cycle as a TGT. When an RPC server replaces incoming RPC user identities with a single user identity, for brevity we refer to this as "identity squashing".

Summary of Proposed Solution To enable interoperable implementations of RPC identity squashing, this document specifies the use of the x.509 SubjectAltName otherName field to carry an RPC user identity. The document defines an object identifier for the otherName "type-id" field, the corresponding "value" field format, and normative guidance on how RPC servers interpret that value.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

x.509 Certificate SubjectAltName Field As specified in :

• The subjectAltName MAY carry additional name types through the use of the otherName field. The format and semantics of the name are indicated through the OBJECT IDENTIFIER in the type-id field. The name itself is conveyed as value field in otherName.

A SubjectAltName extension MAY contain multiple entries of different types (e.g., dNSName, iPAddress, otherName). When processing a certificate for identity squashing purposes, the server examines only the otherName entries with type-id values defined in this document. Other SubjectAltName entries are used for their normal purposes (such as hostname verification for TLS). This document specifies new uses of the otherName field to carry an RPC user identity. The receiving system (an RPC server) then replaces the RPC user, as carried in the RPC header credential and verifier fields in each RPC request within the TLS session, with the user identity specified in the certificate used to authenticate that session.

Server Processing of otherName Fields When an RPC server receives a client certificate containing a SubjectAltName extension, it MUST process the otherName fields as follows:

1. The server MUST examine all otherName entries in the SubjectAltName extension.
2. If the server finds an otherName with a type-id that matches one of the identity squashing OIDs defined in this document (id-on-rpcAuthSys, id-on-gssExportedName, or id-on-nfsv4Principal), it MUST extract and validate the identity information from that otherName.
3. If multiple identity squashing otherName fields are present in the same SubjectAltName extension, the server MUST reject the certificate to avoid ambiguity. See for details.
4. If the server encounters otherName entries with type-id values it does not recognize, it MUST ignore those entries and continue processing.
5. Other types of SubjectAltName entries (dNSName, iPAddress, etc.) are processed independently and do not affect identity squashing behavior.

The server performs identity squashing only if it successfully validates an identity squashing otherName field and authorizes its use for the authenticated TLS peer.

Server Processing This section provides a non-normative example of how an RPC server implementation might process identity squashing otherName fields. Implementers are free to use alternative approaches. A typical server processing flow might include these steps:

1. During TLS session establishment, extract and validate the client's X.509 certificate according to and .
2. If the certificate contains a SubjectAltName extension, examine each otherName entry to determine if any contain identity squashing type-id values (id-on-rpcAuthSys, id-on-gssExportedName, or id-on-nfsv4Principal).
3. If exactly one identity squashing otherName is found, extract and parse the identity information according to the ASN.1 definition for that type-id. If parsing fails, reject the certificate.
4. Perform authorization checks to determine whether the authenticated TLS peer is permitted to use the specified identity. This might involve:
   • Consulting an access control list mapping certificate subjects to allowed user identities
   • Verifying that the requested UID/GID values are within acceptable ranges
   • Validating that the user@domain string matches expected domain patterns
   • Checking that the GSS-API mechanism is trusted and the principal is authorized
5. If authorization succeeds, associate the extracted identity with the TLS session state.
6. For each incoming RPC request on this TLS session, replace the credential information in the RPC header with the identity extracted from the certificate. The original credential information in the RPC header is ignored.
7. Process the RPC request using the squashed identity for all authorization and access control decisions.

Parsing and validating the certificate once at TLS session establishment and caching the result avoids per-request overhead.

Interoperability with Non-Supporting Servers RPC servers that do not implement this specification will not recognize the otherName OIDs defined in this document. Such servers MUST ignore unrecognized otherName entries per . These servers will process RPC requests using the credential information contained in the RPC header, subject to their normal authentication and authorization policies.

AUTH_SYS Identities

otherName OID for AUTH_SYS The otherName OID for AUTH_SYS identities is id-on-rpcAuthSys, defined in .

Format of the otherName Value The otherName value for AUTH_SYS identities contains an RPCAuthSys structure as defined in . This structure consists of a 32-bit unsigned integer specifying a numeric UID, and a sequence of 32-bit unsigned integers specifying numeric GIDs. The use of these integers is further explained in .

GSS-API Principals

otherName OID for GSS-API Principals The otherName OID for GSS-API exported names is id-on-gssExportedName, defined in .

Format of the otherName Value The otherName value contains a GSSExportedName structure as defined in , consisting of a GSS-API mechanism OID and a mechanism-specific exported name value as described in .

NFSv4 User @ Domain String Identities

otherName OID for String Identities The otherName OID for NFSv4 user@domain principals is id-on-nfsv4Principal, defined in .

Format of the otherName Value The otherName value contains an NFSv4Principal structure as defined in , consisting of a UTF-8 encoded user name, the literal "@" character, and a UTF-8 encoded domain name, as described in .

Extending This Mechanism It is possible that in the future, RPC servers might implement other forms of RPC user identity, such as Windows Security Identifiers. This section describes how standards action can extend the mechanism specified in this document to accommodate new forms of user identity. Documents that extend this mechanism using Standards Action MUST satisfy the following requirements:

• New identity types MUST define an ASN.1 module.
• New identity types MUST request an IANA OID allocation.
• New identity types SHOULD provide security considerations specific to that identity type.
• New identity types SHOULD provide examples and test vectors.

Client Certificate Generation This section provides non-normative guidance for Certificate Authorities and administrators who generate client certificates containing identity squashing otherName fields.

Choosing an Identity Format The choice of which identity format to use depends on the deployment environment:

RPCAuthSys

Appropriate for environments where numeric UIDs and GIDs are the primary form of user identity, such as traditional UNIX/Linux systems. This format is compact but requires that UID/GID mappings be consistent between the certificate and the server's user database.

GSSExportedName

Suitable for environments using GSS-API mechanisms like Kerberos. This format fits naturally into existing GSS-API deployments but requires that servers support the specific mechanism indicated by the nameType OID.

NFSv4Principal

Recommended for heterogeneous environments or when human-readable identities are preferred. The user@domain format is familiar to administrators and supports internationalization, but requires that servers perform name-to-UID mapping similar to NFSv4 identity mapping.

Populating Identity Fields When generating certificates, consider these guidelines:

UID/GID values

Ensure that the numeric values in RPCAuthSys correspond to valid entries in the server's user database. Avoid using privileged UIDs (such as 0 for root) unless there is a specific operational requirement and strong authorization controls are in place.

GSS-API exported names

The nameValue field should contain a properly formatted exported name token as defined by the specific GSS-API mechanism. For Kerberos, this follows the format specified in . Consult the mechanism specification for proper encoding.

User@domain strings

Both the user and domain components should be UTF-8 encoded. Domain names should typically match the DNS domain under which the server operates. International domain names should be encoded in UTF-8, not in Punycode (ACE) form.

Certificate Validity Period Certificates containing identity squashing otherName fields grant access to server resources under a specific user identity. Administrators should consider appropriate validity periods based on their security requirements. Shorter validity periods reduce the window of exposure if a certificate is compromised, but may increase operational overhead for certificate renewal. Administrators should also factor in how quickly certificate revocation (CRL or OCSP) propagates in their environment, since that affects how long a compromised certificate remains usable after revocation.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

FreeBSD NFS Server and Client

Organization:

FreeBSD

URL:

https://www.freebsd.org

Maturity:

Complete.

Coverage:

The mechanism to represent user@domain strings has been implemented using an OID from the FreeBSD arc.

Licensing:

BSD 3-clause

Implementation experience:

None to report

Security Considerations

General Security Considerations The security considerations in apply to this specification, including the discussion of certificate validation, trust anchors, and TLS session establishment.

Identity Squashing and Authorization This specification enables a client to request that all RPC operations within a TLS session be executed under a single user identity specified in the client's X.509 certificate. This "identity squashing" mechanism has several security implications:

Trust in the Certificate Authority Servers MUST limit which Certificate Authorities (CAs) they trust to issue certificates carrying the otherName extensions defined in this document. A compromised or malicious CA could issue certificates that grant access to server resources under arbitrary user identities. Servers SHOULD maintain separate trust anchors for identity squashing certificates and certificates used solely for TLS peer authentication, giving administrators direct control over which CAs may assert user identities.

Authorization Decisions The presence of an otherName field specifying a user identity does not by itself grant any authorization. Servers MUST perform their normal authorization checks to determine whether the requested identity is permitted for the authenticated TLS peer. For example, a server might maintain an access control list mapping certificate subjects or distinguished names to the set of user identities they are permitted to assume. Only if such authorization succeeds should the server execute RPC operations under the specified identity.

Name Canonicalization

NFSv4 Principals When processing NFSv4Principal otherName values, servers MUST apply the same name canonicalization and domain validation procedures described in . In particular:

• Domain names SHOULD be validated against expected domain suffixes
• Internationalized domain names MUST be properly normalized
• Case-sensitivity rules for usernames and domains MUST be consistently applied

GSS-API Exported Names When processing GSSExportedName otherName values, servers MUST verify that:

• The mechanism OID in the nameType field corresponds to a GSS-API mechanism the server supports and trusts
• The nameValue field conforms to the exported name format defined by that specific GSS-API mechanism
• The mechanism-specific name validation and canonicalization procedures are followed

Servers SHOULD NOT accept exported names from GSS-API mechanisms they do not fully support, as improper name handling could lead to authorization bypass vulnerabilities.

AUTH_SYS Credentials When processing RPCAuthSys otherName values, servers MUST:

• Validate that the UID and GIDs fall within acceptable ranges for the local system's user database
• Verify that the UID corresponds to a valid user account
• Confirm that the GIDs represent valid groups and that the user is authorized to be a member of those groups

Servers SHOULD reject certificates containing UID 0 (root) or other privileged UIDs unless there is an explicit and well-justified operational requirement, and additional strong authorization controls are in place.

Session Binding All RPC operations within a TLS session containing an identity squashing otherName execute under the same user identity. Servers MUST ensure that session state cannot be hijacked or transferred between different TLS sessions, as this could allow an attacker to gain the privileges associated with the squashed identity.

Revocation Servers SHOULD support certificate revocation checking (via CRL, OCSP, or similar mechanisms) for certificates containing identity squashing otherName fields. Since these certificates grant user-level access to server resources, timely revocation is critical when a certificate is compromised or a user's access should be terminated.

Privacy Considerations The otherName fields defined in this specification reveal user identity information in the client's X.509 certificate. This information is transmitted during the TLS handshake and may be visible to network observers if the handshake is not properly protected. While TLS 1.3 encrypts most of the handshake including certificates, earlier TLS versions may expose this information. Deployments concerned about privacy SHOULD use TLS 1.3 or later.

Multiple Identity Formats Implementations MUST NOT allow multiple identity squashing otherName fields to be present simultaneously in the same SubjectAltName extension. If multiple such fields are present (e.g., both RPCAuthSys and NFSv4Principal), the server MUST reject the certificate to avoid ambiguity about which identity should be used.

IANA Considerations

SMI Security for PKIX Module Identifier IANA is requested to assign an object identifier for the ASN.1 module specified in this document in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):

Decimal	Description	References
TBD1	id-mod-rpc-tls-identity-squashing	RFC-TBD

SMI Security for PKIX Other Name Forms IANA is requested to assign three object identifiers for the otherName types specified in this document in the "SMI Security for PKIX Other Name Forms" registry (1.3.6.1.5.5.7.8):

Decimal	Description	References
TBD2	id-on-rpcAuthSys	RFC-TBD
TBD3	id-on-gssExportedName	RFC-TBD
TBD4	id-on-nfsv4Principal	RFC-TBD

These otherName identifiers are used in the SubjectAltName extension of X.509 certificates to carry RPC user identity information for the purpose of identity squashing as described in this document. "RFC-TBD" is to be replaced with the actual RFC number when this document is published.

References Normative References This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK] This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in transit. The proposed mechanism interoperates with Open Network Computing (ONC) RPC implementations that do not support it. This document updates RFC 5531. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This memo obsoletes [STANDARDS-TRACK] Informative References This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism. RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

ASN.1 Module The following ASN.1 module normatively specifies the structure of the new otherName values described in this document. This specification uses the ASN.1 definitions from with the 2002 ASN.1 notation used in that document. updates normative documents using older ASN.1 notation.

RPC TLS Identity Squashing Module

Certificate Examples This appendix provides examples of X.509 certificates containing the otherName extensions defined in this document. These examples are provided in both human-readable notation and hexadecimal DER encoding to assist implementers in verifying their implementations.

NFSv4 Principal Example This example shows a certificate for user "alice" at domain "nfs.example.com": DER encoding (hexadecimal): Note: XX represents the TBD value for id-on-nfsv4Principal.

GSS-API Exported Name Example This example shows a certificate containing a Kerberos V5 principal for "bob@EXAMPLE.COM": DER encoding (hexadecimal): Note: YY represents the TBD value for id-on-gssExportedName. The nameValue field contains the GSS-API exported name token format as defined by the Kerberos V5 mechanism. The first four bytes (04 01 00 0B) are the token ID and length fields defined in .

RPC AUTH_SYS Example This example shows a certificate containing UID 1000 and GIDs 1000, 10, and 100: DER encoding (hexadecimal): Note: ZZ represents the TBD value for id-on-rpcAuthSys. Breaking down the encoding: - 02 02 03 E8: INTEGER 1000 (UID) - 30 0A: SEQUENCE OF (GIDs) - 02 02 03 E8: INTEGER 1000 - 02 01 0A: INTEGER 10 - 02 01 64: INTEGER 100

Complete Certificate Example This example shows a minimal self-signed certificate containing an NFSv4Principal otherName. Line breaks and whitespace have been added for readability: The SubjectAltName extension in this certificate is encoded at the position indicated by the bytes following the Extended Key Usage extension.

Internationalized Domain Name Example This example shows an NFSv4Principal with internationalized characters: DER encoding (hexadecimal): Note: The UTF-8 encoding of the Chinese characters "用户" is E7 94 A8 E6 88 B7, and the Japanese text "例え" is E4 BE 8B E3 81 88.

Test Vectors This section provides test vectors for validating implementations. Each test case includes the input values, expected ASN.1 structure, and expected DER encoding.

Valid NFSv4Principal Test Cases Test Case 1: Simple ASCII user and domain Input:

• principal: "bob@example.org"

Expected DER encoding: Test Case 2: User with numbers and domain with subdomain Input:

• principal: "user123@nfs.lab.example.com"

Expected DER encoding:

Valid RPCAuthSys Test Cases Test Case 1: Single user, single group Input:

• uid: 1000
• gids: { 1000 }

Expected DER encoding: Test Case 2: User with empty group list Input:

• uid: 500
• gids: (empty)

Expected DER encoding: Test Case 3: User with maximum 32-bit UID and multiple groups Input:

• uid: 4294967295
• gids: { 1, 10, 100, 1000 }

Expected DER encoding:

Invalid Test Cases These test cases should be rejected by conforming implementations: Test Case 1: NFSv4Principal with missing '@' separator Input (malformed):

• principal: "aliceexample.com" (no '@' character present)

Expected result: Rejection by server (invalid principal string format) Test Case 2: RPCAuthSys with UID exceeding 32-bit range Input (malformed):

• uid: 4294967296 (2^32)
• gids: { 1000 }

Expected result: Encoding failure or rejection Test Case 3: Certificate with multiple identity squashing otherNames Input (malformed): SubjectAltName containing both: - id-on-nfsv4Principal with user "alice@example.com" - id-on-rpcAuthSys with uid 1000 Expected result: Certificate rejection per Security Considerations

Acknowledgments The authors are grateful to Jeff Layton, Greg Marsden, and Martin Thomson for their input and support. Special thanks to Area Director Gorry Fairhurst, NFSV4 Working Group Chairs Brian Pawlowski and Christopher Inacio, and NFSV4 Working Group Secretary Thomas Haynes for their guidance and oversight.