draft-ietf-nfsv4-rpc-tls-08.txt   draft-ietf-nfsv4-rpc-tls-09.txt 
Network File System Version 4 T. Myklebust Network File System Version 4 T. Myklebust
Internet-Draft Hammerspace Internet-Draft Hammerspace
Updates: 5531 (if approved) C. Lever, Ed. Updates: 5531 (if approved) C. Lever, Ed.
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: 21 December 2020 19 June 2020 Expires: 22 March 2021 18 September 2020
Towards Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-08 draft-ietf-nfsv4-rpc-tls-09
Abstract Abstract
This document describes a mechanism that, through the use of This document describes a mechanism that, through the use of
opportunistic Transport Layer Security (TLS), enables encryption of opportunistic Transport Layer Security (TLS), enables encryption of
in-transit Remote Procedure Call (RPC) transactions while Remote Procedure Call (RPC) transactions while they are in-transit.
interoperating with ONC RPC implementations that do not support this The proposed mechanism interoperates with ONC RPC implementations
mechanism. This document updates RFC 5531. that do not support it. This document updates RFC 5531.
Note Note
Discussion of this draft takes place on the NFSv4 working group Discussion of this draft takes place on the NFSv4 working group
mailing list (nfsv4@ietf.org), which is archived at mailing list (nfsv4@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group
information can be found at https://datatracker.ietf.org/wg/nfsv4/ information can be found at https://datatracker.ietf.org/wg/nfsv4/
about/. about/.
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 December 2020. This Internet-Draft will expire on 22 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 6
4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6
4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8
5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Base Transport Considerations . . . . . . . . . . . . . . 9 5.1. Base Transport Considerations . . . . . . . . . . . . . . 9
5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 9 5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 10
5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10
5.1.3. Protected Operation on Other Transports . . . . . . . 11 5.1.3. Protected Operation on Other Transports . . . . . . . 11
5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 11 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 12
5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 11 5.2.1. X.509 Certificates Using PKIX Trust . . . . . . . . . 12
5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 12 5.2.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 14
5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 13 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 13
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14
6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 14 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 15
6.3. Linux NFS server and client . . . . . . . . . . . . . . . 14 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 15
6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 15 6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Limitations of an Opportunistic Approach . . . . . . . . 15 7.1. The Limitations of Opportunistic Security . . . . . . . . 16
7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 16 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 17
7.1.2. Privacy Leakage Before Session Establishment . . . . 16 7.1.2. Privacy Leakage Before Session Establishment . . . . 17
7.2. TLS Identity Management on Clients . . . . . . . . . . . 16 7.2. TLS Identity Management on Clients . . . . . . . . . . . 18
7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 17 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 18
7.4. Best Security Policy Practices . . . . . . . . . . . . . 18 7.4. Best Security Policy Practices . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 18 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 19
8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 18 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. Object Identifier for PKIX Extended Key Usage . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Known Weaknesses of the AUTH_SYS Authentication Appendix A. Known Weaknesses of the AUTH_SYS Authentication
Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 21 Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
In 2014 the IETF published a document entitled "Pervasive Monitoring In 2014 the IETF published a document entitled "Pervasive Monitoring
Is an Attack" [RFC7258], which recognized that unauthorized Is an Attack" [RFC7258], which recognized that unauthorized
observation of network traffic had become widespread and was a observation of network traffic had become widespread and was a
subversive threat to all who make use of the Internet at large. It subversive threat to all who make use of the Internet at large. It
strongly recommended that newly defined Internet protocols should strongly recommended that newly defined Internet protocols should
make a genuine effort to mitigate monitoring attacks. Typically this make a genuine effort to mitigate monitoring attacks. Typically this
mitigation is done by encrypting data in transit. mitigation includes encrypting data in transit.
The Remote Procedure Call version 2 protocol has been a Proposed The Remote Procedure Call version 2 protocol has been a Proposed
Standard for three decades (see [RFC5531] and its antecedents). Over Standard for three decades (see [RFC5531] and its antecedents). Over
twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in- twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in-
transit encryption mechanism for RPC [RFC2203]. However, experience transit encryption mechanism for RPC [RFC2203]. However, experience
has shown that RPCSEC GSS with in-transit encryption can be has shown that RPCSEC GSS with in-transit encryption can be
challenging to use in practice: challenging to use in practice:
* Parts of each RPC header remain in clear-text, constituting a * Parts of each RPC header remain in clear-text, constituting a loss
significant security exposure. of metadata confidentiality.
* Offloading the GSS privacy service is not practical in large * Offloading the GSS privacy service is not practical in large
multi-user deployments since each message is encrypted using a key multi-user deployments since each message is encrypted using a key
based on the issuing RPC user. based on the issuing RPC user.
However strong GSS-provided confidentiality is, it cannot provide any However strong GSS-provided confidentiality is, it cannot provide any
security if the challenges of using it result in choosing not to security if the challenges of using it result in choosing not to
deploy it at all. deploy it at all.
Moreover, the use of AUTH_SYS remains common despite the adverse Moreover, the use of AUTH_SYS remains common despite the adverse
effects that acceptance of UIDs and GIDs from unauthenticated clients effects that acceptance of UIDs and GIDs from unauthenticated clients
brings with it. Continued use is in part because: brings with it. Continued use is in part because:
* Per-client deployment and administrative costs are not scalable. * Per-client deployment and administrative costs for the only well-
Administrators must provide keying material for each RPC client, defined alternative to AUTH_SYS are expensive at scale. For
including transient clients. instance, administrators must provide keying material for each RPC
client, including transient clients.
* Host identity management and user identity management must be * GSS host identity management and user identity management must be
enforced in the same security realm. In certain environments, enforced in the same security realm. In certain environments,
different authorities might be responsible for provisioning client different authorities might be responsible for provisioning client
systems versus provisioning new users. systems versus provisioning new users.
The alternative described in the current document is to employ a In view of the challenges with the currently available mechanisms for
transport layer security mechanism that can protect the authenticating and protecting the confidentiality of RPC
confidentiality of each RPC connection transparently to RPC and transactions, this document specifies a transport-layer security
upper-layer protocols. The Transport Layer Security protocol mechanism that complements the existing ones. The Transport Layer
[RFC8446] (TLS) is a well-established Internet building block that Security [RFC8446] (TLS) and Datagram Transport Layer Security
protects many standard Internet protocols such as the Hypertext [I-D.ietf-tls-dtls13] (DTLS) protocols are a well-established
Transport Protocol (HTTP) [RFC2818]. Internet building blocks that protect many standard Internet
protocols such as the Hypertext Transport Protocol (HTTP) [RFC2818].
Encrypting at the RPC transport layer accords several significant Encrypting at the RPC transport layer accords several significant
benefits: benefits:
Encryption By Default: Transport encryption can be enabled without Encryption By Default: Transport encryption can be enabled without
additional administrative tasks such as identifying client systems additional administrative tasks such as identifying client systems
to a trust authority, generating additional keying material, or to a trust authority and providing each with keying material.
provisioning a secure network tunnel.
Encryption Offload: Hardware support for the GSS privacy service has Encryption Offload: Hardware support for the GSS privacy service has
not appeared in the marketplace. However, the use of a well- not appeared in the marketplace. However, the use of a well-
established transport encryption mechanism that is employed by established transport encryption mechanism that is employed by
other ubiquitous network protocols makes it more likely that other ubiquitous network protocols makes it more likely that
encryption offload for RPC is practicable. encryption offload for RPC is practicable.
Securing AUTH_SYS: Most critically, transport encryption can Securing AUTH_SYS: Most critically, transport encryption can
significantly reduce several security issues inherent in the significantly reduce several security issues inherent in the
current widespread use of AUTH_SYS (i.e., acceptance of UIDs and current widespread use of AUTH_SYS (i.e., acceptance of UIDs and
GIDs generated by an unauthenticated client). GIDs generated by an unauthenticated client).
Decoupled User and Host Identities: TLS can be used to authenticate Decoupled User and Host Identities: TLS can be used to authenticate
peer hosts while other security mechanisms can handle user peer hosts while other security mechanisms can handle user
authentication. authentication.
The current document specifies the implementation of RPC on an Compatibility: The imposition of encryption at the transport layer
encrypted transport in a manner that is transparent to upper-layer protects any upper-layer protocol that employs RPC, without
protocols based on RPC. The imposition of encryption at the alteration of the upper-layer protocol.
transport layer protects any upper-layer protocol that employs RPC,
without alteration of that protocol.
Further, Section 7 of the current document defines policies in line Further, Section 7 of the current document defines policies in line
with [RFC7435] which enable RPC-over-TLS to be deployed with [RFC7435] which enable RPC-over-TLS to be deployed
opportunistically in environments that contain RPC implementations opportunistically in environments that contain RPC implementations
that do not support TLS. However, specifications for RPC-based that do not support TLS. However, specifications for RPC-based
upper-layer protocols should choose to require even stricter policies upper-layer protocols should choose to require even stricter policies
that guarantee encryption and host authentication is used for all RPC that guarantee encryption and host authentication is used for all RPC
transactions. Enforcing the use of RPC-over-TLS is of particular transactions to mitigate against pervasive monitoring attacks
[RFC7258]. Enforcing the use of RPC-over-TLS is of particular
importance for existing upper-layer protocols whose security importance for existing upper-layer protocols whose security
infrastructure is weak. infrastructure is weak.
The protocol specification in the current document assumes that The protocol specification in the current document assumes that
support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available support for ONC RPC [RFC5531], TLS [RFC8446], PKIX [RFC5280], DNSSEC/
in an RPC implementation where TLS support is to be added. DANE [RFC6698], and optionally RPCSEC_GSS [RFC2203] is available
within the platform where RPC-over-TLS support is to be added.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
skipping to change at page 6, line 4 skipping to change at page 6, line 10
RPC documentation historically refers to the authentication of a RPC documentation historically refers to the authentication of a
connecting host as "machine authentication" or "host authentication". connecting host as "machine authentication" or "host authentication".
TLS documentation refers to the same as "peer authentication". In TLS documentation refers to the same as "peer authentication". In
the current document there is little distinction between these terms. the current document there is little distinction between these terms.
The term "user authentication" in the current document refers The term "user authentication" in the current document refers
specifically to the RPC caller's credential, provided in the "cred" specifically to the RPC caller's credential, provided in the "cred"
and "verf" fields in each RPC Call. and "verf" fields in each RPC Call.
4. RPC-Over-TLS in Operation 4. RPC-Over-TLS in Operation
4.1. Discovering Server-side TLS Support 4.1. Discovering Server-side TLS Support
The mechanism described in the current document interoperates fully The mechanism described in the current document interoperates fully
with RPC implementations that do not support RPC-over-TLS. Policy with RPC implementations that do not support RPC-over-TLS. When an
settings on the RPC-over-TLS-enabled peer determine whether RPC RPC-over-TLS-enabled peer encounters a peer that does not support
operation continues without the use of TLS or RPC operation is not RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer
permitted. determine whether RPC operation continues without the use of TLS, or
RPC operation is not permitted.
To achieve this interoperability, we introduce a new RPC To achieve this interoperability, we introduce a new RPC
authentication flavor called AUTH_TLS. The AUTH_TLS authentication authentication flavor called AUTH_TLS. The AUTH_TLS authentication
flavor signals that the client wants to initiate TLS negotiation if flavor signals that the client wants to initiate TLS negotiation if
the server supports it. Except for the modifications described in the server supports it. Except for the modifications described in
this section, the RPC protocol is unaware of security encapsulation this section, the RPC protocol is unaware of security encapsulation
at the transport layer. The value of AUTH_TLS is defined in at the transport layer. The value of AUTH_TLS is defined in
Section 8.1. Section 8.1.
An RPC client begins its communication with an RPC server by An RPC client begins its communication with an RPC server by
selecting a transport and destination port. The choice of transport selecting a transport and destination port. The choice of transport
and port is typically based on the RPC program that is to be used. and port is typically based on the RPC program that is to be used.
The RPC client might query the RPC server's rpcbind service to make The RPC client might query the RPC server's RPCBIND service to make
this selection. In all cases, an RPC server MUST listen on the same this selection (The RPCBIND service is described in [RFC1833]). The
ports for (D)TLS-protected RPC programs as the ports used when (D)TLS mechanism described in the current document does not support RPC
is not available. transports other than TCP and UDP. In all cases, an RPC server MUST
listen on the same ports for (D)TLS-protected RPC programs as the
ports used when (D)TLS is not available.
To protect RPC traffic to a TCP port, the RPC client opens a TCP To protect RPC traffic to a TCP port, the RPC client opens a TCP
connection to that port and sends a NULL RPC procedure with an connection to that port and sends a NULL RPC procedure with an
auth_flavor of AUTH_TLS on that connection. To protect RPC traffic auth_flavor of AUTH_TLS on that connection. To protect RPC traffic
to a UDP port, the RPC client sends a UDP datagram to that port to a UDP port, the RPC client sends a UDP datagram to that port
containing a NULL RPC procedure with an auth_flavor of AUTH_TLS. The containing a NULL RPC procedure with an auth_flavor of AUTH_TLS. The
mechanism described in the current document does not support RPC client constructs this RPC procedure as follows:
transports other than TCP and UDP.
The length of the opaque data constituting the credential sent in the * The length of the opaque data constituting the credential sent in
RPC Call message MUST be zero. The verifier accompanying the the RPC Call message MUST be zero.
credential MUST be an AUTH_NONE verifier of length zero.
The flavor value of the verifier in the RPC Reply message received * The verifier accompanying the credential MUST be an AUTH_NONE
from the server MUST be AUTH_NONE. The length of the verifier's body verifier of length zero.
field is eight. The bytes of the verifier's body field encode the
ASCII characters "STARTTLS" as a fixed-length opaque.
If the RPC server replies with a reply_stat of MSG_ACCEPTED and an * The flavor value of the verifier in the RPC Reply message received
AUTH_NONE verifier containing the "STARTTLS" token, the client SHOULD from the server MUST be AUTH_NONE.
proceed with TLS session establishment, even if the Reply's
accept_stat is not SUCCESS. If the AUTH_TLS probe was done via TCP, * The length of the verifier's body field is eight.
the RPC client MUST send the "ClientHello" message on the same
connection. If the AUTH_TLS probe was done via UDP, the RPC client * The bytes of the verifier's body field encode the ASCII characters
MUST send the "ClientHello" message to the same UDP destination port. "STARTTLS" as a fixed-length opaque.
The RPC server signals its corresponding support for RPC-over-TLS by
replying with a reply_stat of MSG_ACCEPTED and an AUTH_NONE verifier
containing the "STARTTLS" token. The client SHOULD proceed with TLS
session establishment, even if the Reply's accept_stat is not
SUCCESS. If the AUTH_TLS probe was done via TCP, the RPC client MUST
send the "ClientHello" message on the same connection. If the
AUTH_TLS probe was done via UDP, the RPC client MUST send the
"ClientHello" message to the same UDP destination port.
Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its
verifier flavor is not AUTH_NONE, or if its verifier does not contain verifier flavor is not AUTH_NONE, or if its verifier does not contain
the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello" the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello"
message. RPC operation can continue, however it will be without any message. RPC operation may continue, depending on local policy, but
confidentiality, integrity or authentication protection from (D)TLS. without confidentiality, integrity, or peer authentication protection
from (D)TLS.
If, after a successful RPC AUTH_TLS probe, the subsequent (D)TLS If, after a successful RPC AUTH_TLS probe, the subsequent (D)TLS
handshake should fail for any reason, the RPC client reports this handshake should fail for any reason, the RPC client reports this
failure to the upper-layer application the same way it reports an failure to the upper-layer application the same way it reports an
AUTH_ERROR rejection from the RPC server. AUTH_ERROR rejection from the RPC server.
If an RPC client uses the AUTH_TLS authentication flavor on any If an RPC client uses the AUTH_TLS authentication flavor on any
procedure other than the NULL procedure, or an RPC client sends an procedure other than the NULL procedure, or an RPC client sends an
RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server
MUST reject that RPC Call by setting the reply_stat field to MUST reject that RPC Call by returning a reply_stat of MSG_DENIED
MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat with a reject_stat of AUTH_ERROR and an auth_stat of AUTH_BADCRED.
field to AUTH_BADCRED.
Once the TLS session handshake is complete, the RPC client and server Once the TLS session handshake is complete, the RPC client and server
have established a secure channel for communicating. A successful have established a secure channel for exchanging RPC transactions. A
AUTH_TLS probe on one particular port/transport tuple never implies successful AUTH_TLS probe on one particular port/transport tuple does
RPC-over-TLS is available on that same server using a different port/ not imply that RPC-over-TLS is available on that same server using a
transport tuple. different port/transport tuple, nor does it imply that RPC-over-TLS
will be available in the future using the successfully probed port.
4.2. Authentication 4.2. Authentication
Both RPC and TLS have peer and user authentication, with some overlap There is some overlap between the authentication capabilities of RPC
in capability between RPC and TLS. The goal of interoperability with and TLS. The goal of interoperability with implementations that do
implementations that do not support TLS requires limiting the not support TLS requires limiting the combinations that are allowed
combinations that are allowed and precisely specifying the role that and precisely specifying the role that each layer plays.
each layer plays.
Each RPC server that supports RPC-over-TLS MUST possess a unique Each RPC server that supports RPC-over-TLS MUST possess a unique
global identity (e.g., a certificate that is signed by a well-known global identity (e.g., a certificate that is signed by a well-known
trust anchor). Such an RPC server MUST request a TLS peer identity trust anchor). Such an RPC server MUST request a TLS peer identity
from each client upon first contact. There are two different modes from each client upon first contact. There are two different modes
of client deployment: of client deployment:
Server-only Host Authentication Server-only Host Authentication
In this type of deployment, the client can authenticate the server In this type of deployment, the client can authenticate the server
host using the presented server peer TLS identity, but the server host using the presented server peer TLS identity, but the server
skipping to change at page 8, line 14 skipping to change at page 8, line 31
TLS handshake, both peers authenticate using the presented TLS TLS handshake, both peers authenticate using the presented TLS
identities. If authentication of either peer fails, or if identities. If authentication of either peer fails, or if
authorization based on those identities blocks access to the authorization based on those identities blocks access to the
server, the peers MUST reject the association. server, the peers MUST reject the association.
In either of these modes, RPC user authentication is not affected by In either of these modes, RPC user authentication is not affected by
the use of transport layer security. When a client presents a TLS the use of transport layer security. When a client presents a TLS
peer identity to an RPC server, the protocol extension described in peer identity to an RPC server, the protocol extension described in
the current document provides no way for the server to know whether the current document provides no way for the server to know whether
that identity represents one RPC user on that client, or is shared that identity represents one RPC user on that client, or is shared
amongst many RPC users. Therefore, a server implementation must not amongst many RPC users. Therefore, a server implementation cannot
utilize the remote TLS peer identity for RPC user authentication. utilize the remote TLS peer identity to authenticate RPC users.
4.2.1. Using TLS with RPCSEC GSS 4.2.1. Using TLS with RPCSEC GSS
To use GSS, an RPC server has to possess a GSS service principal. On To use GSS, an RPC server has to possess a GSS service principal. On
a TLS session, GSS mutual (peer) authentication occurs as usual, but a TLS session, GSS mutual (peer) authentication occurs as usual, but
only after a TLS session has been established for communication. only after a TLS session has been established for communication.
Authentication of GSS users is unchanged by the use of TLS. Authentication of RPCSEC GSS users is unchanged by the use of TLS.
RPCSEC GSS can also perform per-request integrity or confidentiality RPCSEC GSS can also perform per-request integrity or confidentiality
protection. When operating over a TLS session, these GSS services protection. When operating over a TLS session, these GSS services
become redundant. An RPC implementation capable of concurrently become largely redundant. An RPC implementation capable of
using TLS and RPCSEC GSS can use GSS channel binding, as defined in concurrently using TLS and RPCSEC GSS MUST use GSS-API channel
[RFC5056], to determine when an underlying transport provides a binding, as defined in [RFC5056], to determine when an underlying
sufficient degree of confidentiality. Channel bindings for the TLS transport provides a sufficient degree of confidentiality. RPC-over-
channel type are defined in [RFC5929]. TLS implementations MUST provide the "tls-exporter" channel binding
type, as defined in [I-D.ietf-kitten-tls-channel-bindings-for-tls13].
5. TLS Requirements 5. TLS Requirements
When peers negotiate a TLS session that is to transport RPC, the When peers negotiate a TLS session that is to transport RPC, the
following restrictions apply: following restrictions apply:
* Implementations MUST NOT negotiate TLS versions prior to v1.3 (for * Implementations MUST NOT negotiate TLS versions prior to v1.3 (for
TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively). TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively).
Support for mandatory-to-implement ciphersuites for the negotiated Support for mandatory-to-implement ciphersuites for the negotiated
TLS version is REQUIRED. TLS version is REQUIRED.
* Implementations MUST support certificate-based mutual * Implementations MUST support certificate-based mutual
authentication. Support for TLS-PSK mutual authentication authentication. Support for PSK mutual authentication is
[RFC4279] is OPTIONAL. See Section 4.2 for further details. OPTIONAL; see Section 5.2.2 for further details.
* Negotiation of a ciphersuite providing confidentiality as well as * Negotiation of a ciphersuite providing confidentiality as well as
integrity protection is REQUIRED. Support for and negotiation of integrity protection is REQUIRED. Support for and negotiation of
compression is OPTIONAL. compression is OPTIONAL.
Client implementations MUST include the Client implementations MUST include the
"application_layer_protocol_negotiation(16)" extension [RFC7301] in "application_layer_protocol_negotiation(16)" extension [RFC7301] in
their "ClientHello" message and MUST include the protocol identifier their "ClientHello" message and MUST include the protocol identifier
defined in Section 8.2 in that message's ProtocolNameList value. defined in Section 8.2 in that message's ProtocolNameList value.
Similary, in response to the "ClientHello" message, server Similarly, in response to the "ClientHello" message, server
implementations MUST include the implementations MUST include the
"application_layer_protocol_negotiation(16)" extension [RFC7301] in "application_layer_protocol_negotiation(16)" extension [RFC7301] in
their "ServerHello" message and MUST include only the protocol their "ServerHello" message and MUST include only the protocol
identifier defined in Section 8.2 in that message's ProtocolNameList identifier defined in Section 8.2 in that message's ProtocolNameList
value. value.
If the server responds incorrectly (for instance, if the If the server responds incorrectly (for instance, if the
"ServerHello" message does not conform to the above requirements), "ServerHello" message does not conform to the above requirements),
the client MUST NOT establish a TLS session for use with RPC on this the client MUST NOT establish a TLS session for use with RPC on this
connection. See [RFC7301] for further details about how to form connection. See [RFC7301] for further details about how to form
skipping to change at page 9, line 36 skipping to change at page 10, line 10
and a destination port number. The use of TLS or DTLS does not and a destination port number. The use of TLS or DTLS does not
change that association. Thus it is frequently -- though not always change that association. Thus it is frequently -- though not always
-- the case that a single TLS session carries traffic for only one -- the case that a single TLS session carries traffic for only one
RPC program. RPC program.
5.1.1. Protected Operation on TCP 5.1.1. Protected Operation on TCP
The use of the Transport Layer Security (TLS) protocol [RFC8446] The use of the Transport Layer Security (TLS) protocol [RFC8446]
protects RPC on TCP connections. Typically, once an RPC client protects RPC on TCP connections. Typically, once an RPC client
completes the TCP handshake, it uses the mechanism described in completes the TCP handshake, it uses the mechanism described in
Section 4.1 to discover RPC-over-TLS support for that connection. If Section 4.1 to discover RPC-over-TLS support for that connection.
spurious traffic appears on a TCP connection between the initial Until an AUTH_TLS probe is done on a connection, the RPC server
clear-text AUTH_TLS probe and the TLS session handshake, receivers treats all traffic as RPC messages. If spurious traffic appears on a
MUST discard that data without response and then SHOULD drop the TCP connection between the initial clear-text AUTH_TLS probe and the
connection. TLS session handshake, receivers MUST discard that data without
response and then SHOULD drop the connection.
The protocol convention specified in the current document assumes The protocol convention specified in the current document assumes
there can be no more than one concurrent TLS session per TCP there can be no more than one concurrent TLS session per TCP
connection. This is true of current generations of TLS, but might be connection. This is true of current generations of TLS, but might be
different in a future version of TLS. different in a future version of TLS.
Once a TLS session is established on a TCP connection, no further Once a TLS session is established on a TCP connection, no further
clear-text communication can occur on that connection until the clear-text communication can occur on that connection until the
session is terminated. The use of TLS does not alter RPC record session is terminated. The use of TLS does not alter RPC record
framing used on TCP transports. framing used on TCP transports.
Furthermore, if an RPC server responds with PROG_UNAVAIL to an RPC Furthermore, if an RPC server responds with PROG_UNAVAIL to an RPC
Call within an established TLS session, that does not imply that RPC Call within an established TLS session, that does not imply that RPC
server will subsequently reject the same RPC program on a different server will subsequently reject the same RPC program on a different
TCP connection. TCP connection.
Reverse-direction operation occurs only on connected transports such Reverse-direction operation occurs only on connected transports such
as TCP (see Section 2 of [RFC8166]). To protect reverse-direction as TCP (see Section 2 of [RFC8167]). To protect reverse-direction
RPC operations, the RPC server does not establish a separate TLS RPC operations, the RPC server does not establish a separate TLS
session on the TCP connection, but instead uses the existing TLS session on the TCP connection, but instead uses the existing TLS
session on that connection to protect these operations. session on that connection to protect these operations.
When operation is complete, an RPC peer terminates a TLS session by When operation is complete, an RPC peer terminates a TLS session by
sending a TLS Closure Alert and may then close the TCP connection. sending a TLS Closure Alert. It may then close the TCP connection.
5.1.2. Protected Operation on UDP 5.1.2. Protected Operation on UDP
RFC Editor: In the following section, please replace TBD with the RFC Editor: In the following section, please replace TBD with the
connection_id extension number that is to be assigned in connection_id extension number that is to be assigned in
[I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's [I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's
Note before this document is published. Note before this document is published.
RPC over UDP is protected using the Datagram Transport Layer Security RPC over UDP is protected using the Datagram Transport Layer Security
(DTLS) protocol [I-D.ietf-tls-dtls13]. (DTLS) protocol [I-D.ietf-tls-dtls13].
Using DTLS does not introduce reliable or in-order semantics to RPC Using DTLS does not introduce reliable or in-order semantics to RPC
on UDP. Each RPC message MUST fit in a single DTLS record. DTLS on UDP. The use of DTLS record replay protection is REQUIRED when
encapsulation has overhead, which reduces the effective Path MTU transporting RPC traffic.
(PMTU) and thus the maximum RPC payload size. The use of DTLS record
replay protection is REQUIRED when transporting RPC traffic. Each RPC message MUST fit in a single DTLS record. DTLS
encapsulation has overhead, which reduces the Packetization Layer
Path MTU (PLPMTU) and thus the maximum RPC payload size. A possible
PLPMTU discovery mechanism is offered in [RFC8899].
As soon as a client initializes a UDP socket for use with an RPC As soon as a client initializes a UDP socket for use with an RPC
server, it uses the mechanism described in Section 4.1 to discover server, it uses the mechanism described in Section 4.1 to discover
DTLS support for an RPC program on a particular port. It then DTLS support for an RPC program on a particular port. It then
negotiates a DTLS session. negotiates a DTLS session.
The current document does not specify a mechanism that enables a
server to distinguish between DTLS traffic and unprotected RPC
traffic directed to the same port. To make this distinction, each
peer matches ingress datagrams that appear to be DTLS traffic to
existing DTLS session state. A peer treats any datagram that fails
the matching process as an RPC message.
Multi-homed RPC clients and servers may send protected RPC messages Multi-homed RPC clients and servers may send protected RPC messages
via network interfaces that were not involved in the handshake that via network interfaces that were not involved in the handshake that
established the DTLS session. Therefore, when protecting RPC established the DTLS session. Therefore, when protecting RPC
traffic, each DTLS handshake MUST include the "connection_id(TBD)" traffic, each DTLS handshake MUST include the "connection_id(TBD)"
extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC- extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC-
on-DTLS peer endpoints MUST provide a ConnectionID with a non-zero over-DTLS peer endpoints MUST provide a ConnectionID with a non-zero
length. Endpoints implementing RPC programs that expect a length. Endpoints implementing RPC programs that expect a
significant number of concurrent clients should employ ConnectionIDs significant number of concurrent clients SHOULD employ ConnectionIDs
of at least 4 bytes in length. of at least 4 bytes in length.
Sending a TLS Closure Alert terminates a DTLS session. Subsequent Sending a TLS Closure Alert terminates a DTLS session. Because
RPC messages exchanged between the RPC client and server are no neither DTLS nor UDP provide in-order delivery, after session closure
longer protected until a new DTLS session is established. there can be ambiguity as to whether a datagram should be interpreted
as DTLS protected or not. Therefore receivers MUST discard datagrams
exchanged using the same 5-tuple that just terminated the DTLS
session for 60 seconds.
5.1.3. Protected Operation on Other Transports 5.1.3. Protected Operation on Other Transports
Transports that provide intrinsic TLS-level security (e.g., QUIC) Transports that provide intrinsic TLS-level security (e.g., QUIC)
need to be addressed separately from the current document. In such need to be addressed separately from the current document. In such
cases, the use of TLS is not opportunistic as it can be for TCP or cases, the use of TLS is not opportunistic as it can be for TCP or
UDP. UDP.
RPC-over-RDMA can make use of transport layer security below the RDMA RPC-over-RDMA can make use of transport layer security below the RDMA
transport layer [RFC8166]. The exact mechanism is not within the transport layer [RFC8166]. The exact mechanism is not within the
scope of the current document. Because there might not be other scope of the current document. Because there might not be other
provisions to exchange client and server certificates, authentication provisions to exchange client and server certificates, authentication
material exchange needs to be provided by facilities within a future material exchange needs to be provided by facilities within a future
version of the RPC-over-RDMA transport protocol. version of the RPC-over-RDMA transport protocol.
5.2. TLS Peer Authentication 5.2. TLS Peer Authentication
TLS can perform peer authentication using any of the following TLS can perform peer authentication using any of the following
mechanisms: mechanisms.
5.2.1. X.509 Certificates Using PKIX trust
Implementations are REQUIRED to support this mechanism. In this
mode, the tuple (serial number of the presented certificate; Issuer)
uniquely identifies the RPC peer.
X.509 certificates are specified in [X.509] and extended in 5.2.1. X.509 Certificates Using PKIX Trust
[RFC5280].
* Implementations MUST allow the configuration of a list of trusted X.509 certificates are specified in [X.509]. [RFC5280] provides a
Certification Authorities for authorizing incoming connections. profile of Internet PKI X.509 public key infrastructure. RPC-over-
TLS implementations are REQUIRED to support the PKIX mechanism
described in [RFC5280].
* Certificate validation MUST include the verification rules as per The rules and guidelines defined in [RFC6125] apply to RPC-over-TLS
[RFC5280]. certificates with the following considerations:
* Implementations SHOULD indicate their trusted Certification * Support for the DNS-ID identifier type [RFC6125] is REQUIRED in
Authorities (CAs). RPC-over-TLS client and server implementations. Certification
authorities that issue such certificates MUST support the DNS-ID
identifier type.
* Peer validation always includes a check on whether the locally * DNS domain names in RPC-over-TLS certificates MUST NOT contain the
configured expected DNS name or IP address of the server that is wildcard character '*' within the identifier.
contacted matches its presented certificate. DNS names and IP
addresses can be contained in the Common Name (CN) or
subjectAltName entries. For verification, only one of these
entries is to be considered. The following precedence applies:
for DNS name validation, subjectAltName:DNS has precedence over
CN; for IP address validation, subjectAltName:iPAddress has
precedence over CN. Implementors of this specification are
advised to read Section 6 of [RFC6125] for more details on DNS
name validation.
* For services accessed by their network identifiers (netids) and When validating a server certificate, an RPC-over-TLS client
universal network addresses (uaddr), the iPAddress subjectAltName implementation takes the following into account:
SHOULD be present in the certificate and must exactly match the
address represented by the universal network address.
* Implementations MAY allow the configuration of a set of additional * Certificate validation MUST include the verification rules as per
properties of the certificate to check for a peer's authorization Section 6 of [RFC5280] and Section 6 of [RFC6125].
to communicate (e.g., a set of allowed values in
subjectAltName:URI or a set of allowed X.509v3 Certificate
Policies).
* When the configured trust base changes (e.g., removal of a CA from * Server certificate validation MUST include a check on whether the
the list of trusted CAs; issuance of a new CRL for a given CA), locally configured expected DNS-ID or iPAddress subjectAltName of
implementations MAY renegotiate the TLS session to reassess the the server that is contacted matches its presented certificate.
connecting peer's continued authorization.
Authenticating a connecting entity does not mean the RPC server * For RPC services accessed by their network identifiers (netids)
necessarily wants to communicate with that client. For example, if and universal network addresses (uaddr), the iPAddress
the Issuer is not in a trusted set of Issuers, the RPC server may subjectAltName MUST be present in the certificate and MUST exactly
decline to perform RPC transactions with this client. match the address represented by the universal network address.
Implementations that want to support a wide variety of trust models
should expose as many details of the presented certificate to the
administrator as possible so that the administrator can implement the
trust model. As a suggestion, at least the following parameters of
the X.509 client certificate SHOULD be exposed:
* Originating IP address An RPC client's domain name and IP address are often assigned
dynamically, thus RPC servers cannot rely on those to verify client
certificates. Therefore, when an RPC-over-TLS client presents a
certificate to an RPC-over-TLS server, the server takes the following
into account:
* Certificate Fingerprint * The server MUST use a procedure conformant to Section 6 of
[RFC5280]) to validate the client certificate's certification
path.
* Issuer * The tuple (serial number of the presented certificate; Issuer)
uniquely identifies the RPC client. The meaning and syntax of
these fields is defined in Section 4 of [RFC5280]).
* Subject RPC-over-TLS implementations MAY allow the configuration of a set of
additional properties of the certificate to check for a peer's
authorization to communicate (e.g., a set of allowed values in
subjectAltName:URI, a set of allowed X.509v3 Certificate Policies, or
a set of extended key usages).
* all X.509v3 Extended Key Usage When the configured trust base changes (e.g., removal of a CA from
the list of trusted CAs; issuance of a new CRL for a given CA),
implementations SHOULD reevaluate the certificate originally
presented in the context of the new configuration and terminate the
TLS session if the certificate is no longer trustworthy.
* all X.509v3 Subject Alternative Name 5.2.1.1. Extended Key Usage Values
* all X.509v3 Certificate Policies Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509
certificate extension. This extension, which may appear in end-
entity certificates, indicates one or more purposes for which the
certified public key may be used in addition to or in place of the
basic purposes indicated in the key usage extension.
5.2.2. X.509 Certificates Using Fingerprints The current document defines two new KeyPurposeId values: one that
identifies the RPC-over-TLS peer as an RPC client, and one that
identifies the RPC-over-TLS peer as an RPC server. Additional
KeyPurposeId values related to RPC-over-TLS may be specified in
subsequent Standards Track documents.
This mechanism is OPTIONAL to implement. In this mode, the The inclusion of the RPC server value (id-kp-rpcTLSServer) indicates
fingerprint of a certificate uniquely identifies the RPC peer. that the certificate has been issued for allowing the holder to
process RPC transactions. Such a certificate is a Resource
Certificate and therefore MUST conform to the constraints specified
in [RFC6487].
A "fingerprint" is typically defined as a cryptographic digest of the The inclusion of the RPC client value (id-kp-rpcTLSClient) indicates
Distinguished Encoding Rules (DER) form [X.690] of an X.509v3 that the certificate has been issued for allowing the holder to
certificate [X.509]. Implementations SHOULD allow the configuration request RPC transactions.
of a list of trusted certificates that is indexed by fingerprint.
5.2.3. Pre-Shared Keys 5.2.2. Pre-Shared Keys
This mechanism is OPTIONAL to implement. In this mode, the RPC peer This mechanism is OPTIONAL to implement. In this mode, the RPC peer
is uniquely identified by keying material that has been shared out- can be uniquely identified by keying material that has been shared
of-band or by a previous TLS-protected connection (see Section 2.2 of out-of-band (see Section 2.2 of [RFC8446]). At least the following
[RFC8446]). At least the following parameters of the TLS connection parameter of the TLS connection SHOULD be exposed at the RPC layer:
SHOULD be exposed:
* Originating IP address
* TLS Identifier
5.2.4. Token Binding
This mechanism is OPTIONAL to implement. In this mode, a token
uniquely identifies the RPC peer.
Versions of TLS after TLS 1.2 contain a token binding mechanism that * PSK Identifier
is more secure than using certificates. This mechanism is detailed
in [RFC8471].
6. Implementation Status 6. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
skipping to change at page 14, line 44 skipping to change at page 15, line 27
Licensing: Proprietary Licensing: Proprietary
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
6.3. Linux NFS server and client 6.3. Linux NFS server and client
Organization: The Linux Foundation Organization: The Linux Foundation
URL: https://www.kernel.org URL: https://www.kernel.org
Maturity: Prototype software based on early versions of the current Maturity: Not complete.
document.
Coverage: The bulk of this specification has yet to be implemented. Coverage: The bulk of this specification has yet to be implemented.
The use of DTLS functionality is not planned. The use of DTLS functionality is not planned.
Licensing: GPLv2 Licensing: GPLv2
Implementation experience: No comments from the implementor. Implementation experience: A Linux in-kernel prototype is underway,
but implementation delays have resulted from the
challenges of handling a TLS handshake in a kernel
environment. Those issues stem from the architecture of
TLS and the kernel, not from the design of the RPC-over-
TLS protocol.
6.4. FreeBSD NFS server and client 6.4. FreeBSD NFS server and client
Organization: The FreeBSD Project Organization: The FreeBSD Project
URL: https://www.freebsd.org URL: https://www.freebsd.org
Maturity: Prototype software based on early versions of the current Maturity: Prototype software based on early versions of the current
document. document.
skipping to change at page 15, line 29 skipping to change at page 16, line 17
Implementation experience: Implementers have read and commented on Implementation experience: Implementers have read and commented on
the current document. the current document.
7. Security Considerations 7. Security Considerations
One purpose of the mechanism described in the current document is to One purpose of the mechanism described in the current document is to
protect RPC-based applications against threats to the confidentiality protect RPC-based applications against threats to the confidentiality
of RPC transactions and RPC user identities. A taxonomy of these of RPC transactions and RPC user identities. A taxonomy of these
threats appears in Section 5 of [RFC6973]. Also, Section 6 of threats appears in Section 5 of [RFC6973]. Also, Section 6 of
[RFC7525] contains a detailed discussion of technologies used in [RFC7525] contains a detailed discussion of technologies used in
conjunction with TLS. Implementers should familiarize themselves conjunction with TLS. Section 8 of [RFC5280] covers important
with these materials. considerations about handling certificate material securely.
Implementers should familiarize themselves with these materials.
7.1. Limitations of an Opportunistic Approach Once a TLS session is established, the RPC payload carried on TLS
version 1.3 is forward-secure. However, implementers need to be
aware that replay attacks can occur during session establishment.
Remedies for such attacks are discussed in detail in Section 8 of
[RFC8446]. Further, the current document does not provide a profile
that defines the use of 0-RTT data (see Appendix E.5 of [RFC8446]).
Therefore, RPC-over-TLS implementations MUST NOT use 0-RTT data.
7.1. The Limitations of Opportunistic Security
Readers can find the definition of Opportunistic Security in
[RFC7435]. A discussion of its underlying principals appears in
Section 3 of that document.
The purpose of using an explicitly opportunistic approach is to The purpose of using an explicitly opportunistic approach is to
enable interoperation with implementations that do not support RPC- enable interoperation with implementations that do not support RPC-
over-TLS. A range of options is allowed by this approach, from "no over-TLS. A range of options is allowed by this approach, from "no
peer authentication or encryption" to "server-only authentication peer authentication or encryption" to "server-only authentication
with encryption" to "mutual authentication with encryption". The with encryption" to "mutual authentication with encryption". The
actual security level may indeed be selected based on policy and actual security level may indeed be selected based on policy and
without user intervention. without user intervention.
In environments where interoperability is a priority, the security In environments where interoperability is a priority, the security
skipping to change at page 16, line 10 skipping to change at page 17, line 15
In all other cases, the adoption, implementation, and deployment of In all other cases, the adoption, implementation, and deployment of
RPC-based upper-layer protocols that enforce the use of TLS RPC-based upper-layer protocols that enforce the use of TLS
authentication and encryption (when similar RPCSEC GSS services are authentication and encryption (when similar RPCSEC GSS services are
not in use) is strongly encouraged. not in use) is strongly encouraged.
7.1.1. STRIPTLS Attacks 7.1.1. STRIPTLS Attacks
A classic form of attack on network protocols that initiate an A classic form of attack on network protocols that initiate an
association in plain-text to discover support for TLS is a man-in- association in plain-text to discover support for TLS is a man-in-
the-middle that alters the plain-text handshake to make it appear as the-middle that alters the plain-text handshake to make it appear as
though TLS support is not available on one or both peers. Clients though TLS support is not available on one or both peers. Client
implementers can choose from the following to mitigate STRIPTLS implementers can choose from the following to mitigate STRIPTLS
attacks: attacks:
* A TLSA record [RFC6698] can alert clients that TLS is expected to * A TLSA record [RFC6698] can alert clients that TLS is expected to
work, and provide a binding of hostname to X.509 identity. If TLS work, and provide a binding of hostname to X.509 identity. If TLS
cannot be negotiated or authentication fails, the client cannot be negotiated or authentication fails, the client
disconnects and reports the problem. disconnects and reports the problem.
* Client security policy can require that a TLS session is * Client security policy can require that a TLS session is
established on every connection. If an attacker spoofs the established on every connection. If an attacker spoofs the
handshake, the client disconnects and reports the problem. If handshake, the client disconnects and reports the problem. This
TLSA records are not available, this approach is strongly policy prevents an attacker from causing the client to silently
encouraged. fall back to plaintext. If TLSA records are not available, this
approach is strongly encouraged.
7.1.2. Privacy Leakage Before Session Establishment 7.1.2. Privacy Leakage Before Session Establishment
As mentioned earlier, communication between an RPC client and server As mentioned earlier, communication between an RPC client and server
appears in the clear on the network prior to the establishment of a appears in the clear on the network prior to the establishment of a
TLS session. This clear-text information usually includes transport TLS session. This clear-text information usually includes transport
connection handshake exchanges, the RPC NULL procedure probing connection handshake exchanges, the RPC NULL procedure probing
support for TLS, and the initial parts of TLS session establishment. support for TLS, and the initial parts of TLS session establishment.
Appendix C of [RFC8446] discusses precautions that can mitigate Appendix C of [RFC8446] discusses precautions that can mitigate
exposure during the exchange of connnection handshake information and exposure during the exchange of connection handshake information and
TLS certificate material that might enable attackers to track the RPC TLS certificate material that might enable attackers to track the RPC
client. client.
Any RPC traffic that appears on the network before a TLS session has Any RPC traffic that appears on the network before a TLS session has
been established is vulnerable to monitoring or undetected been established is vulnerable to monitoring or undetected
modification. A secure client implementation limits or prevents any modification. A secure client implementation limits or prevents any
RPC exchanges that are not protected. RPC exchanges that are not protected.
The exception to this edict is the initial RPC NULL procedure that The exception to this edict is the initial RPC NULL procedure that
acts as a STARTTLS message, which cannot be protected. This RPC NULL acts as a STARTTLS message, which cannot be protected. This RPC NULL
procedure contains no arguments or results, and the AUTH_TLS procedure contains no arguments or results, and the AUTH_TLS
authentication flavor it uses does not contain user information. authentication flavor it uses does not contain user information, so
there is negligible privacy impact from this exception.
7.2. TLS Identity Management on Clients 7.2. TLS Identity Management on Clients
The goal of the RPC-over-TLS protocol extension is to hide the The goal of the RPC-over-TLS protocol extension is to hide the
content of RPC requests while they are in transit. The RPC-over-TLS content of RPC requests while they are in transit. The RPC-over-TLS
protocol by itself cannot protect against exposure of a user's RPC protocol by itself cannot protect against exposure of a user's RPC
requests to other users on the same client. requests to other users on the same client.
Moreover, client implementations are free to transmit RPC requests Moreover, client implementations are free to transmit RPC requests
for more than one RPC user using the same TLS session. Depending on for more than one RPC user using the same TLS session. Depending on
the details of the client RPC implementation, this means that the the details of the client RPC implementation, this means that the
client's TLS identity material is potentially visible to every RPC client's TLS credentials are potentially visible to every RPC user
user that shares a TLS session. Privileged users may also be able to that shares a TLS session. Privileged users may also be able to
access this TLS identity. access this TLS identity.
As a result, client implementations need to carefully segregate TLS As a result, client implementations need to carefully segregate TLS
identity material so that local access to it is restricted to only credentials so that local access to it is restricted to only the
the local users that are authorized to perform operations on the local users that are authorized to perform operations on the remote
remote RPC server. RPC server.
7.3. Security Considerations for AUTH_SYS on TLS 7.3. Security Considerations for AUTH_SYS on TLS
Using a TLS-protected transport when the AUTH_SYS authentication Using a TLS-protected transport when the AUTH_SYS authentication
flavor is in use addresses several longstanding weaknesses in flavor is in use addresses several longstanding weaknesses in
AUTH_SYS (as detailed in Appendix A). TLS augments AUTH_SYS by AUTH_SYS (as detailed in Appendix A). TLS augments AUTH_SYS by
providing both integrity protection and confidentiality that AUTH_SYS providing both integrity protection and confidentiality that AUTH_SYS
lacks. TLS protects data payloads, RPC headers, and user identities lacks. TLS protects data payloads, RPC headers, and user identities
against monitoring and alteration while in transit. against monitoring and alteration while in transit.
TLS guards against in-transit insertion and deletion of RPC messages, TLS guards against in-transit insertion and deletion of RPC messages,
thus ensuring the integrity of the message stream between RPC client thus ensuring the integrity of the message stream between RPC client
and server. DTLS does not provide full message stream protection, and server. DTLS does not provide full message stream protection,
but it does enable receivers to reject non-participant messages. In but it does enable receivers to reject non-participant messages. In
particular, transport layer encryption plus peer authentication particular, transport layer encryption plus peer authentication
protects receiving XDR decoders from deserializing untrusted data, a protects receiving XDR decoders from deserializing untrusted data, a
common coding vulnerability. common coding vulnerability. However, these decoders would still be
exposed to untrusted input in the case of the compromise of a trusted
peer or Certificate Authority.
The use of TLS enables strong authentication of the communicating RPC The use of TLS enables strong authentication of the communicating RPC
peers, providing a degree of non-repudiation. When AUTH_SYS is used peers, providing a degree of non-repudiation. When AUTH_SYS is used
with TLS, but the RPC client is unauthenticated, the RPC server still with TLS, but the RPC client is unauthenticated, the RPC server still
acts on RPC requests for which there is no trustworthy acts on RPC requests for which there is no trustworthy
authentication. In-transit traffic is protected, but the RPC client authentication. In-transit traffic is protected, but the RPC client
itself can still misrepresent user identity without server detection. itself can still misrepresent user identity without server detection.
TLS without authentication is an improvement from AUTH_SYS without TLS without authentication is an improvement from AUTH_SYS without
encryption, but it leaves a critical security exposure. encryption, but it leaves a critical security exposure.
In light of the above, it is RECOMMENDED that when AUTH_SYS is used, In light of the above, when AUTH_SYS is used, the use of a TLS mutual
every RPC client should present host authentication material to RPC authentication mechanism is RECOMMENDED to prove that the RPC client
servers to prove that the client is a known one. The server can then is known to the RPC server. The server can then determine whether
determine whether the UIDs and GIDs in AUTH_SYS requests from that the UIDs and GIDs in AUTH_SYS requests from that client can be
client can be accepted. accepted, based on the authenticated identity of the client.
The use of TLS does not enable RPC clients to detect compromise that The use of TLS does not enable RPC clients to detect compromise that
leads to the impersonation of RPC users. Also, there continues to be leads to the impersonation of RPC users. Also, there continues to be
a requirement that the mapping of 32-bit user and group ID values to a requirement that the mapping of 32-bit user and group ID values to
user identities is the same on both the RPC client and server. user identities is the same on both the RPC client and server.
7.4. Best Security Policy Practices 7.4. Best Security Policy Practices
RPC-over-TLS implementations and deployments are strongly encouraged RPC-over-TLS implementations and deployments are strongly encouraged
to adhere to the following policies to achieve the strongest possible to adhere to the following policies to achieve the strongest possible
security with RPC-over-TLS. security with RPC-over-TLS.
* When using AUTH_NULL or AUTH_SYS, both peers are required to have * When using AUTH_NULL or AUTH_SYS, both peers are RECOMMENDED to
DNS TLSA records and certificate material, and a policy that have DNSSEC TLSA records, keys with which to perform mutual peer
requires mutual peer authentication and rejection of a connection authentication using one of the methods described in Section 5.2,
when host authentication fails. and a security policy that requires mutual peer authentication and
rejection of a connection when host authentication fails.
* RCPSEC_GSS provides integrity and privacy services which are * RPCSEC GSS provides integrity and privacy services which are
redundant when TLS is in use. These services should be disabled largely redundant when TLS is in use. These services SHOULD be
in that case. disabled in that case.
8. IANA Considerations 8. IANA Considerations
RFC Editor: In the following subsections, please replace RFC-TBD with RFC Editor: In the following subsections, please replace RFC-TBD with
the RFC number assigned to this document. And, please remove this the RFC number assigned to this document. And, please remove this
Editor's Note before this document is published. Editor's Note before this document is published.
8.1. RPC Authentication Flavor 8.1. RPC Authentication Flavor
Following Appendix B of [RFC5531], the authors request a single new Following Appendix B of [RFC5531], the authors request a single new
skipping to change at page 19, line 4 skipping to change at page 20, line 16
Reference: RFC-TBD Reference: RFC-TBD
8.2. ALPN Identifier for SUNRPC 8.2. ALPN Identifier for SUNRPC
Following Section 6 of [RFC7301], the authors request the allocation Following Section 6 of [RFC7301], the authors request the allocation
of the following value in the "Application-Layer Protocol Negotiation of the following value in the "Application-Layer Protocol Negotiation
(ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC
when used over TLS. when used over TLS.
Protocol: SunRPC Protocol: SunRPC
Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc")
Reference: RFC-TBD Reference: RFC-TBD
8.3. Object Identifier for PKIX Extended Key Usage
RFC Editor: In the following subsection, please replace XXX and YYY
with the IANA numbers assigned to these new entries. And, please
remove this Editor's Note before this document is published.
Per the Specification Required policy as defined in Section 4.6 of
[RFC8126], the authors request the reservation of the following new
values:
* The RPC-over-TLS ASN.1 module in the "SMI Security for PKIX
Extended Key Purpose" registry (1.3.6.1.5.5.7.3) (see
Section 5.2.1.1 and Appendix B.
* The RPC-over-TLS client certificate extended key usage
(1.3.6.1.5.5.7.3.XXX). The description of this new entry should
be "id-kp-rpcTLSClient".
* The RPC-over-TLS server certificate extended key usage
(1.3.6.1.5.5.7.3.YYY). The description of this new entry should
be "id-kp-rpcTLSServer".
IANA should use the current document (RFC-TBD) as the reference for
the new entries.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-kitten-tls-channel-bindings-for-tls13]
Whited, S., "Channel Bindings for TLS 1.3", Work in
Progress, Internet-Draft, draft-ietf-kitten-tls-channel-
bindings-for-tls13-00, 11 June 2020,
<https://tools.ietf.org/html/draft-ietf-kitten-tls-
channel-bindings-for-tls13-00>.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", Work in Progress, Internet- Identifiers for DTLS 1.2", Work in Progress, Internet-
Draft, draft-ietf-tls-dtls-connection-id-07, 21 October Draft, draft-ietf-tls-dtls-connection-id-07, 21 October
2019, <https://tools.ietf.org/html/draft-ietf-tls-dtls- 2019, <https://tools.ietf.org/html/draft-ietf-tls-dtls-
connection-id-07>. connection-id-07>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-38, 29 May 2020, dtls13-38, 29 May 2020,
<https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>. <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>. <https://www.rfc-editor.org/info/rfc5056>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/info/rfc5531>. May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May X.509 PKIX Resource Certificates", RFC 6487,
2014, <https://www.rfc-editor.org/info/rfc7258>. DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[X.509] International Telephone and Telegraph Consultative [X.509] International Telephone and Telegraph Consultative
Committee, "ITU-T X.509 - Information technology - The Committee, "ITU-T X.509 - Information technology - The
Directory: Public-key and attribute certificate Directory: Public-key and attribute certificate
frameworks.", ISO/IEC 9594-8, CCITT Recommendation X.509, frameworks.", ISO/IEC 9594-8, CCITT Recommendation X.509,
October 2019. October 2019.
[X.690] International Telephone and Telegraph Consultative
Committee, "ITU-T X.690 - Information technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ISO/IEC 8825-1, CCITT
Recommendation X.690, August 2015.
9.2. Informative References 9.2. Informative References
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, DOI 10.17487/RFC1833, August 1995,
<https://www.rfc-editor.org/info/rfc1833>.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, DOI 10.17487/RFC2203, September Specification", RFC 2203, DOI 10.17487/RFC2203, September
1997, <https://www.rfc-editor.org/info/rfc2203>. 1997, <https://www.rfc-editor.org/info/rfc2203>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
Memory Access Transport for Remote Procedure Call Version Memory Access Transport for Remote Procedure Call Version
1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
<https://www.rfc-editor.org/info/rfc8166>. <https://www.rfc-editor.org/info/rfc8166>.
[RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, [RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC-
"The Token Binding Protocol Version 1.0", RFC 8471, over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167,
DOI 10.17487/RFC8471, October 2018, June 2017, <https://www.rfc-editor.org/info/rfc8167>.
<https://www.rfc-editor.org/info/rfc8471>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor
The ONC RPC protocol, as specified in [RFC5531], provides several The ONC RPC protocol, as specified in [RFC5531], provides several
modes of security, traditionally referred to as "authentication modes of security, traditionally referred to as "authentication
flavors". Some of these flavors provide much more than an flavors". Some of these flavors provide much more than an
authentication service. We refer to these as authentication flavors, authentication service. We refer to these as authentication flavors,
security flavors, or simply, flavors. One of the earliest and most security flavors, or simply, flavors. One of the earliest and most
basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of
[RFC5531] specifies AUTH_SYS. [RFC5531] specifies AUTH_SYS.
skipping to change at page 22, line 48 skipping to change at page 24, line 48
1. It does not protect the confidentiality or integrity of RPC 1. It does not protect the confidentiality or integrity of RPC
requests, users, or payloads, relying instead on "external" requests, users, or payloads, relying instead on "external"
security. security.
2. It does not provide authentication of RPC peer machines, other 2. It does not provide authentication of RPC peer machines, other
than inclusion of an unprotected domain name. than inclusion of an unprotected domain name.
3. The use of 32-bit unsigned integers as user and group identifiers 3. The use of 32-bit unsigned integers as user and group identifiers
is problematic because these data types are not cryptographically is problematic because these data types are not cryptographically
signed or otherwise verified by any authority. signed or otherwise verified by any authority. In addition, the
mapping of these integers to users and groups has to be
consistent amongst a server and its cohort of clients.
4. Because the user and group ID fields are not integrity-protected, 4. Because the user and group ID fields are not integrity-protected,
AUTH_SYS does not provide non-repudiation. AUTH_SYS does not provide non-repudiation.
Appendix B. ASN.1 Module
RFC Editor: In the following section, please replace XXX and YYY with
the IANA numbers assigned to these new entries. And, please remove
this Editor's Note before this document is published.
<CODE BEGINS>
-- OID Arc
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) kp(3) }
-- Extended Key Usage Values
id-kp-rpcTLSClient OBJECT IDENTIFIER ::= { id-kp XXX }
id-kp-rpcTLSServer OBJECT IDENTIFIER ::= { id-kp YYY }
<CODE ENDS>
Acknowledgments Acknowledgments
Special mention goes to Charles Fisher, author of "Encrypting NFSv4 Special mention goes to Charles Fisher, author of "Encrypting NFSv4
with Stunnel TLS" (https://www.linuxjournal.com/content/encrypting- with Stunnel TLS" (https://www.linuxjournal.com/content/encrypting-
nfsv4-stunnel-tls). His article inspired the mechanism described in nfsv4-stunnel-tls). His article inspired the mechanism described in
the current document. the current document.
Many thanks to Tigran Mkrtchyan and Rick Macklem for their work on Many thanks to Tigran Mkrtchyan and Rick Macklem for their work on
prototype implementations and feedback on the current document. prototype implementations and feedback on the current document.
Thanks to Derrell Piper for numerous suggestions that improved both Thanks to Derrell Piper for numerous suggestions that improved both
this simple mechanism and the current document's security-related this simple mechanism and the current document's security-related
discussion. discussion.
Many thanks to Transport Area Director Magnus Westerlund for his Many thanks to Transport Area Director Magnus Westerlund for his
sharp questions and careful reading of the final revisions of the sharp questions and careful reading of the final revisions of the
current document. The text of Section 5.1.2 is mostly his current document. The text of Section 5.1.2 is mostly his
contribution. contribution. Also, thanks to Benjamin Kaduk for his expert guidance
on the use of PKIX and TLS. In addition, the authors thank the other
members of the IESG for their astute review comments. These
contributors made this a significantly better document.
The authors are additionally grateful to Bill Baker, David Black, The authors are additionally grateful to Bill Baker, David Black,
Alan DeKok, Lars Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg Alan DeKok, Lars Eggert, Olga Kornievskaia, Greg Marsden, Alex
Marsden, Alex McDonald, Justin Mazzola Paluska, Tom Talpey, and McDonald, Justin Mazzola Paluska, Tom Talpey, Martin Thomson, and
Martin Thomson for their input and support of this work. Nico Williams, for their input and support of this work.
Finally, special thanks to NFSV4 Working Group Chair and document Finally, special thanks to NFSV4 Working Group Chair and document
shepherd David Noveck, NFSV4 Working Group Chairs Spencer Shepler and shepherd David Noveck, NFSV4 Working Group Chairs Spencer Shepler and
Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for
their guidance and oversight. their guidance and oversight.
Authors' Addresses Authors' Addresses
Trond Myklebust Trond Myklebust
Hammerspace Inc Hammerspace Inc
 End of changes. 96 change blocks. 
259 lines changed or deleted 356 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/