Network File System Version 4 R. Macklem Internet-Draft FreeBSD Intended status: Standards Track C. Lever, Ed. Expires: 1 February 2026 Oracle 31 July 2025 Remote Procedure Call Identity Squashing via x.509 Certificate Fields draft-cel-nfsv4-rpc-tls-othername-00 Abstract This document extends RPC-with-TLS, as described in [RFC9289], 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://chucklever.github.io/i-d-rpc-tls-othername/#go.draft-cel- nfsv4-rpc-tls-othername.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc- tls-othername/. Discussion of this document takes place on the nfsv4 Working Group mailing list (mailto:nfsv4@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nfsv4/. Subscribe at https://www.ietf.org/mailman/listinfo/nfsv4/. Source for this draft and an issue tracker can be found at https://github.com/chucklever/i-d-rpc-tls-othername. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Macklem & Lever Expires 1 February 2026 [Page 1] Internet-Draft SunRPC x.509 Identity Squashing July 2025 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 February 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.3. Summary of Proposed Solution . . . . . . . . . . . . . . 4 1.4. Open Questions . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. x.509 Certificate SubjectAltName Field . . . . . . . . . . . 4 3.1. AUTH_SYS Identities . . . . . . . . . . . . . . . . . . . 4 3.1.1. otherName OID for AUTH_SYS . . . . . . . . . . . . . 5 3.1.2. Format of the otherName Value . . . . . . . . . . . . 5 3.2. Kerberos V5 Principals . . . . . . . . . . . . . . . . . 5 3.2.1. otherName OID for AUTH_SYS . . . . . . . . . . . . . 5 3.2.2. Format of the otherName Value . . . . . . . . . . . . 5 3.3. NFSv4 User @ Domain String Identities . . . . . . . . . . 5 3.3.1. otherName OID for String Identities . . . . . . . . . 5 3.3.2. Format of the otherName Value . . . . . . . . . . . . 5 4. Extending This Mechanism . . . . . . . . . . . . . . . . . . 5 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 5.1. FreeBSD NFS Server and Client . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Macklem & Lever Expires 1 February 2026 [Page 2] Internet-Draft SunRPC x.509 Identity Squashing July 2025 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 1.1. Background The Remote Procedure Call version 2 protocol (RPC, for short) has been a Proposed Standard for three decades (see [RFC5531] and its antecedents). Several important upper layer protocols, such as the family of Network File System protocols (most recently described in [RFC8881] are based on RPC. In 2022, the IETF published [RFC9289], which specifies a mechanism by which RPC transactions can be cryptographically protected during transit. This protection includes maintaining confidentiality and integrity, and the authentication of the communicating peers. 1.2. Problem Statement Section 4.2 of [RFC9289] 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 host address or fully qualified DNS name. The lack of a well known fixed IP host address or fully qualified DNS name weakens the verification checks that may be done on the client's X.509 certificate by the server. As such, this extension allows the client to be restricted to a single user entity on the server, limiting the scope of risk associated with allowing access to the server. When a service is running in a dedicated VM or container, it often runs as a single assigned user identity. Handling this user identity using Kerberos is problematic, since Kerberos TGTs typically expire in a matter of hours and the service is typically a long running task. This extension allows the client to specify the single assigned user identity to the server in a manner that will not expire for a significant period of time. Macklem & Lever Expires 1 February 2026 [Page 3] Internet-Draft SunRPC x.509 Identity Squashing July 2025 When an RPC server replaces incoming RPC user identities with a single user identity, for brevity we refer to this as "identity squashing". 1.3. Summary of Proposed Solution In the interest of enabling the independent creation of interoperating implementations of RPC identity squashing, this document proposes the use of the x.509 SubjectAltName otherName field to carry a RPC user identity. For these user squashing instructions, this document establishes a fixed object identifier carried in the "type-id" part of the otherName field, and specifies the format of the "value" part of the otherName field when "type-id" carries the new object identifier. The document also provides normative guidance on how the "value" is to be interpreted by RPC servers. 1.4. Open Questions * Should this be an NFS-only feature, or should it be an RPC-layer feature? * Standardizing a fixed OID is necessary for interoperability, but are we required to allocate that OID from a particular arc? 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. x.509 Certificate SubjectAltName Field As specified in Section 4.2.1.6 of [RFC5280]: 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. This document specifies new uses of the otherName field to carry an RPC user identity. The receiving system (an RPC server) then converts all RPC users (as carried in the RPC header credential and verifier fields) to the user identity specified in the certificate. 3.1. AUTH_SYS Identities Macklem & Lever Expires 1 February 2026 [Page 4] Internet-Draft SunRPC x.509 Identity Squashing July 2025 3.1.1. otherName OID for AUTH_SYS | State the Object Identifier to be used to indicate this form of | RPC user identity 3.1.2. Format of the otherName Value | This will be a set of 32-bit integers that specify a numeric | UID, and a counted list of 32-bit integers that specify numeric | GIDs. 3.2. Kerberos V5 Principals 3.2.1. otherName OID for AUTH_SYS | State the Object Identifier to be used to indicate this form of | RPC user identity 3.2.2. Format of the otherName Value The otherName value contains a principal name as described in Section 4 of [RFC2743]. 3.3. NFSv4 User @ Domain String Identities 3.3.1. otherName OID for String Identities | State the Object Identifier to be used to indicate this form of | RPC user identity 3.3.2. Format of the otherName Value | Follow recommendations of draft-ietf-nfsv4- | internationalization-latest to form an internationalized | "user@domain" string similar to NFSv4 ID map strings. 4. 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 (SSIDs) [SSID]. This section describes how standards action can extend the mechanism specified in this document to accommodate new forms of user identity. | Provide the base level of general requirements that we will | have to meet in this document as instructions to future | authors. I'm not sure yet exactly what those are. Macklem & Lever Expires 1 February 2026 [Page 5] Internet-Draft SunRPC x.509 Identity Squashing July 2025 5. Implementation Status | This section is to be removed before publishing this document | as an RFC. 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 [RFC7942]. 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. 5.1. FreeBSD NFS Server and Client Organization: FreeBSD URL: https://www.freebsd.org (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 6. Security Considerations 7. IANA Considerations | Insert request for allocations of a SubjectAltName : otherName | object identifiers 8. References 8.1. Normative References Macklem & Lever Expires 1 February 2026 [Page 6] Internet-Draft SunRPC x.509 Identity Squashing July 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9289] Myklebust, T. and C. Lever, Ed., "Towards Remote Procedure Call Encryption by Default", RFC 9289, DOI 10.17487/RFC9289, September 2022, . 8.2. Informative References [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, . [RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 8881, DOI 10.17487/RFC8881, August 2020, . [SSID] Microsoft, "Security Identifiers", n.d., . Replace this with a reference to an MS standards doc Macklem & Lever Expires 1 February 2026 [Page 7] Internet-Draft SunRPC x.509 Identity Squashing July 2025 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. Authors' Addresses Rick Macklem FreeBSD Project Canada Email: rmacklem@uoguelph.ca Chuck Lever (editor) Oracle Corporation United States of America Email: chuck.lever@oracle.com Macklem & Lever Expires 1 February 2026 [Page 8]