]> Oracle Corporation

United States of America chuck.lever@oracle.com

Transport Network File System Version 4 Recent innovations in Remote Procedure Call (RPC) transport layer security enable broad deployment of encryption and mutual peer authentication when exchanging RPC messages. These security mechanisms can protect peers who continue to use the AUTH_SYS RPC auth flavor, which is not cryptographically secure, on open networks. This document introduces RPC auth pseudo-flavors that an RPC service can use to indicate transport layer security requirements for accessing that service, and a mechanism the service can use to enforce those requirements. Note This note is to be removed before publishing as an RFC. Discussion of this draft occurs on the NFSv4 working group mailing list, archived at . Working Group information is available at . Submit suggestions and changes as pull requests at . Instructions are on that page.

Introduction Each RPC transaction may be associated with a user and a set of groups. That transaction's RPC auth flavor determines how the user and groups are identified and whether they are authenticated. Peers that host applications and RPC services may also be identified and authenicated in each RPC transaction, again depending on that transaction's RPC auth flavor . Not all flavors provide peer and user identification and authentication. For example, the traditional RPC auth flavor AUTH_NONE identifies no user or group and provides no authentication of users or peers. The traditional RPC auth flavor AUTH_SYS provides identification of peers, users, and groups, but does not provide authentication of any of these. Moreover, unlike some GSS security services, these RPC auth flavors provide no confidentiality or integrity checking services. Therefore AUTH_NONE and AUTH_SYS are considered insecure. Mutual peer authentication and encryption provided at the transport layer can make the use of AUTH_NONE and AUTH_SYS more secure. An RPC service might want to indicate to its clients that it will not allow access via AUTH_NONE or AUTH_SYS unless transport layer security services are in place. To do that, this document specifies several pseudo-flavors that upper layers such as NFS can use to enforce stronger security when unauthenticated RPC auth flavors are in use. The author expects that, in addition to RPC-with-TLS , other novel RPC transports will eventually appear that provide similar security features. These transports can benefit from the pseudo-flavors defined in this document, or this approach can be extended if new transport security features require it.

Terminology This document adopts the terminology introduced in Section 3 of and assumes a working knowledge of the Remote Procedure Call (RPC) version 2 protocol and the Transport Layer Security (TLS) protocol . This document adheres to the convention that a "client" is a network host that actively initiates an association, and a "server" is a network host that passively accepts an association request. For the purposes of this document, an Upper-Layer Protocol is an RPC Program and Version tuple comprised of a set of procedure calls defining a single API. One example of a ULP is the Network File System Version 4.0 . An "RPC auth flavor" is a set of protocol elements that can identify a network peer and a user and possibly authenticate either or both. explains the differences between RPC auth flavors and pseudo-flavors. RPC documentation historically refers to the authentication of a host as "machine authentication" or "host authentication". TLS documentation refers to the same as "peer authentication". The current document uses only "peer authentication". The term "user authentication" in the current document refers specifically to the RPC caller's credential provided in the "cred" and "verf" fields in each RPC Call. This document uses the term "insecure RPC auth flavor" (or "insecure flavor" for short) to refer to a class of RPC auth flavors which provide no user or peer authentication. Two prime examples of an insecure RPC auth flavor are AUTH_NONE and AUTH_SYS.

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.

RPC Auth Pseudo-flavors for Transport Layer Security introduces a special RPC auth flavor known as AUTH_TLS. This RPC auth flavor is used only in a NULL procedure that probes the presence of support for RPC-with-TLS, and acts as a STARTTLS barrier. This auth flavor does not carry the identity of the peer or a user. RPC clients do not use this RPC auth flavor to authenticate users in RPC Calls for non-NULL RPC procedures. Once transport layer security has been established between two RPC peers, an RPC client can use insecure flavors when forming RPC Calls with knowledge that the RPC server is known and trusted, and without concern that the communication can be altered or monitored. In some cases an RPC service might want to restrict access to only clients that have authenticated, or perhaps only when encryption protects communication. The pseudo-flavors defined below enable RPC-based services to indicate and enforce access restrictions of this type.

Definitions of New Pseudo-flavors This document specifies several pseudo-flavors that servers may advertise to clients via mechanisms not defined here. Using the RPC auth flavor registry instantiated in gives us leeway to introduce a narrow basic set of pseudoflavors in this document and then expand them, via additional documents, as needs arise. RPC clients continue to use AUTH_NONE (0) or AUTH_SYS (1) in individual transactions while the network transport service provides cryptographically secure authentication or encryption, as follows:

• The new pseudo-flavor AUTH_NONE_MPA indicates that the client may use the AUTH_NONE RPC auth flavor only if both peers have mutually authenticated. Encryption of traffic between these peers is not required.
• The new pseudo-flavor AUTH_NONE_ENC indicates that the client may use the AUTH_NONE RPC auth flavor only if traffic between these peers is encrypted. Mutual peer authentication is not required.
• The new pseudo-flavor AUTH_NONE_MPA_ENC indicates that the client may use the AUTH_NONE RPC auth flavor only if both peers have mutually authenticated and traffic between these peers is encrypted.
• The new pseudo-flavor AUTH_SYS_MPA indicates that the client may use the AUTH_SYS RPC auth flavor only if both peers have mutually authenticated. Encryption of traffic between these peers is not required.
• The new pseudo-flavor AUTH_SYS_ENC indicates that the client may use the AUTH_SYS RPC auth flavor only if traffic between these peers is encrypted. Mutual peer authentication is not required.
• The new pseudo-flavor AUTH_SYS_MPA_ENC indicates that the client may use the AUTH_SYS RPC auth flavor only if both peers have mutually authenticated and traffic between these peers is encrypted.

Because the RPC layer is not aware of pseudo-flavors, the Upper-Layer Protocol is responsible for ensuring that appropriate transport layer security is in place when clients use AUTH_SYS or AUTH_NONE. The next section explains how server implementations enforce the use of transport layer security.

Channel Binding Certain aspects of transport layer security are not new. A deployment might choose to run NFS on a virtual private network established via an ssh tunnel or over IPsec, for example. The Generic Security Service Application Program Interface (GSS-API) specification recognized the use of security provided by transport services underlying GSS with the introduction of channel binding. further describes channel binding as a concept that...

• ...allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

We are particularly interested in ensuring that the mutual authentication done during a TLS handshake (most recently specified in ) on a transport service that handles RPC traffic can be recognized and used by Upper-Layer Protocols for securely authenticating the communicating RPC peers. identifies a set of API characteristics that RPC and its underlying transport provide to such protocols.

TLS Channel Binding defines several TLS channel binding types that Upper-Layer Protocol implementations can use to determine whether appropriate security is in place to protect RPC transactions that continue to use insecure RPC auth flavors such as AUTH_SYS. When used with a Certificate handshake message, the 'tls-server-end-point' channel binding type as defined in serves as authentication for securing pseudo-flavors that require mutual peer authentication. RPC-with-TLS requires the use of TLS session encryption . The presence of TLS under an RPC transport is enough to secure pseudo-flavors that require encryption. A peer can use channel binding to determine whether peer authentication has also occurred and whether that authentication was mutual or server-only. Moreover, in the particular case of TLS, when a handshake fails, both peers are made aware of the failure reason via the Finished message. The failure reason can then be reported to the Upper-Layer Protocol so the local administrator can take specific corrective action. For instance, an RPC server's local security policy might require that the RPC client's IP address or hostname match its certificates Subject Alt Name (SAN). This is not always possible if the client's IP address and hostname are assigned dynamically. When such a server causes a handshake failure, administrators can be made aware that the server's SAN policy restricted a client's access, and corrective action can then be taken.

SSHv2 Channel Binding When RPC traverses an SSHv2 tunnel established between an RPC server and an RPC client, the 'tls-unique' channel binding type as defined in can be used to authenticate peer endpoints and provide appropriate confidentiality.

Channel Binding for RDMA Transports As of this writing, RPC-over-RDMA does not provide a transport layer security service. However, suggests a mechanism by which channel binding can protect RDDP , the protocol that handles remote direct data placement for the iWARP family of protocols. The transport layer underlying RDDP might use IPsec , TLS , or Encapsulating Security Payload (ESP) .

NFS Examples This section presents examples of how a commonly-used Upper-Layer Protocol (NFS) can make use of these pseudo-flavors.

Network File System Versions 2 and 3 NFSv3 clients use the MNT procedure, defined in , to discover which RPC auth flavors may be used to access a particular shared NFSv3 filesystem. To require NFSv3 clients to employ underlying transport security when using AUTH_NONE or AUTH_SYS, the NFS server includes one or more of the new pseudo-flavors defined in in the auth_flavors list that is part of a MNT response. When determining whether a filehandle-bearing operation is authorized, an NFSv3 server uses channel binding to ensure that appropriate transport layer security is in place before processing an incoming NFS request that uses an insecure RPC auth flavor. If that request is not authorized, the NFSv3 server can respond with an nfs_stat of NFS3ERR_STALE. The usage of the MNT procedure as described in is the same with the exception that an NFSv2 server responds with NFSERR_STALE instead of NFS3ERR_STALE.

Network File System Version 4 NFSv4 clients use the SECINFO or SECINFO_NO_NAME procedures, as defined in , to discover which RPC auth flavors may be used to access a particular shared NFSv4 filesystem. To require NFSv4 clients to employ underlying transport security when using AUTH_NONE or AUTH_SYS, the NFS server includes one or more of the new pseudo-flavors defined in in the SECINFO4resok list that is part of a SECINFO or SECINFO_NO_NAME response. When determining whether a filehandle-bearing operation is authorized, an NFSv4 server uses channel binding to ensure that appropriate transport layer security is in place before processing an incoming NFSv4 COMPOUND that uses an insecure RPC auth flavor. If that request is not authorized, the NFSv4 server terminates the COMPOUND with a status code of NFS4ERR_WRONGSEC.

NFSv4 State Protection Note: This section updates RFC 8881. explains how an NFSv4 server determines when an NFSv4 client is authorized to create a new lease or replace a previous one. This mechanism prevents clients from maliciously or unintentionally wiping open and lock state for another client. Section 2.10.8.3 of that document further specifies how the server responds to unauthorized state changes. When used with a Certificate handshake message, the 'tls-server-end-point' channel binding type as defined in can provide protection similar to SP4_MACH_CRED. This document modifies the text of the first bullet in to include the use of transport layer security as follows:

• The principal that created the client ID for the client owner is the same as the principal that is sending the EXCHANGE_ID operation. Note that if the client ID was created with SP4_MACH_CRED state protection (Section 18.35), either:
  • The principal MUST be based on RPCSEC_GSS authentication, the RPCSEC_GSS service used MUST be integrity or privacy, and the same GSS mechanism and principal MUST be used as that used when the client ID was created. Or,
  • The principal MUST be based on AUTH_SYS, and the server MUST use channel binding to verify the identity of the client peer when performing any of the operations specified in the spa_mach_ops bitmaps. Or,
  • The principal MUST be based on AUTH_NONE, and the server MUST use channel binding to verify the identity of the client peer when performing any of the operations specified in the spa_mach_ops bitmaps.

Subsequent discussion of SP4_MACH_CRED in in Sections 2.10.5.1, 2.10.8.3, and 2.10.11.3 would need similar adjustments. Further, NFSv4 server implementations may implement a security policy that restricts the set of clients or security flavors that can establish a lease via SETCLIENTID or EXCHANGE_ID. However, does not allow EXCHANGE_ID or CREATE_SESSION to return NFS4ERR_WRONGSEC, and does not allow SETCLIENTID to return NFS4ERR_WRONGSEC. NFSv4.1-based protocols might be updated to allow EXCHANGE_ID or CREATE_SESSION to return NFS4ERR_WRONG_CRED. However, that solution would be challenging for NFSv4.0, which does not have a definition for NFS4ERR_WRONG_CRED.

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. There are currently no known implementations of the new RPC pseudo-flavors requested by this document.

Security Considerations Discussion of shortcomings peculiar to the AUTH_SYS RPC auth flavor appears in the final paragraph of and in . When implementing or deploying transport layer security to protect an upper-level RPC protocol:

• RPC clients that support transport layer security SHOULD use it whenever possible. Typically the only reason not to is when performance is important and reasonable security can be provided in some other way.
• RPC clients that support transport layer security and have the ability to authenticate SHOULD do so. The only reason not to authenticate is when authentication and encryption can only be enabled together, performance is paramount, and there are other available mechanisms that can provide peer authentication securely.

The pseudo-flavors defined in this document enable RPC servers to indicate required levels of security so that RPC clients can make informed and autonomous decisions that balance performance and scalability against security needs. Important security considerations specific to the use of channel binding are discussed throughout and in .

IANA Considerations

New RPC Auth Flavors Following Appendix B of , this document requests several new entries in the RPC Authentication Flavor Numbers registry. The purpose of these new flavors is to indicate the use of transport layer encryption or mutual peer authentication with insecure RPC auth flavors. All new flavors described in the sections below are pseudo-flavors.

Pseudo-flavors for Secure AUTH_NONE The fields in the new entries are assigned as follows:

Identifier String	Flavor Name	Value	Description	Reference
AUTH_NONE_MPA	NONE_MPA	TBD	AUTH_NONE with mutual peer authentication	RFC_TBD
AUTH_NONE_ENC	NONE_ENC	TBD	AUTH_NONE with transport layer encryption	RFC_TBD
AUTH_NONE_MPA_ENC	NONE_MPA_ENC	TBD	AUTH_NONE with peer authentication and encryption	RFC_TBD

Please allocate the numeric values from the range 400000-409999.

Pseudo-flavors for Secure AUTH_SYS The fields in the new entries are assigned as follows:

Identifier String	Flavor Name	Value	Description	Reference
AUTH_SYS_MPA	SYS_MPA	TBD	AUTH_SYS with mutual peer authentication	RFC_TBD
AUTH_SYS_ENC	SYS_ENC	TBD	AUTH_SYS with transport layer encryption	RFC_TBD
AUTH_SYS_MPA_ENC	SYS_MPA_ENC	TBD	AUTH_SYS with peer authentication and encryption	RFC_TBD

Please allocate the numeric values from the range 410000-419999.

References Normative References Hammerspace Inc Oracle Corporation 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 ONC RPC implementations that do not support it. This document updates RFC 5531. 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. 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 document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [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 This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol. This memo obsoletes [STANDARDS-TRACK] The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits. This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies a protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA). This protocol is referred to as the RPC-over- RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666. This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. [STANDARDS-TRACK] Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap." The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.

Acknowledgments David Noveck is responsible for the basic architecture of this proposal. The author is also grateful to Bill Baker, Rick Macklem, Greg Marsden, and Martin Thomson for their input and support. Special thanks to Transport Area Directors Martin Duke and Zaheduzzaman Sarker, NFSV4 Working Group Chairs David Noveck and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their guidance and oversight.