]> FreeBSD Project

Canada rmacklem@uoguelph.ca

Oracle Corporation

United States of America chuck.lever@oracle.com

Web and Internet Transport Network File System Version 4 x.509 SubjectAltName otherName NFS SunRPC This document extends RPC-with-TLS, as described in , 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). Several important upper layer protocols, such as the family of Network File System protocols (most recently described in are based on RPC. In 2022, the IETF published , 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.

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 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. 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 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.

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?

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.

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.

AUTH_SYS Identities

otherName OID for AUTH_SYS

Format of the otherName Value

Kerberos V5 Principals

otherName OID for AUTH_SYS

Format of the otherName Value The otherName value contains a principal name as described in .

NFSv4 User @ Domain String Identities

otherName OID for String Identities

Format of the otherName Value

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) . This section describes how standards action can extend the mechanism specified in this document to accommodate new forms of user identity.

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

IANA Considerations

References Normative References 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] 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. Informative References Microsoft n.d. Replace this with a reference to an MS standards doc 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.

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.