draft-ietf-nfsv4-rpc-tls-07.txt   draft-ietf-nfsv4-rpc-tls-08.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: November 1, 2020 April 30, 2020 Expires: 21 December 2020 19 June 2020
Towards Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-07 draft-ietf-nfsv4-rpc-tls-08
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 in-transit Remote Procedure Call (RPC) transactions while
interoperating with ONC RPC implementations that do not support this interoperating with ONC RPC implementations that do not support this
mechanism. This document updates RFC 5531. mechanism. This document updates RFC 5531.
Note
Discussion of this draft takes place on the NFSv4 working group
mailing list (nfsv4@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group
information can be found at https://datatracker.ietf.org/wg/nfsv4/
about/.
This note is to be removed before publishing as an RFC.
The source for this draft is maintained in GitHub. Suggested changes
should be submitted as pull requests at
https://github.com/chucklever/i-d-rpc-tls. Instructions are on that
page as well.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 1, 2020.
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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . 9
5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 9 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10
5.1.3. Protected Operation on Other Transports . . . . . . . 10 5.1.3. Protected Operation on Other Transports . . . . . . . 11
5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 11 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 11
5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 11 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 11
5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 12 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 12
5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 12 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 13
5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 13 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 13
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 13 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14
6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 14 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 14
6.3. Linux NFS server and client . . . . . . . . . . . . . . . 14 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 14
6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 14 6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Limitations of an Opportunistic Approach . . . . . . . . 15 7.1. Limitations of an Opportunistic Approach . . . . . . . . 15
7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 15 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 16
7.1.2. Privacy Leakage Before Session Establishment . . . . 16 7.1.2. Privacy Leakage Before Session Establishment . . . . 16
7.2. TLS Identity Management on Clients . . . . . . . . . . . 16 7.2. TLS Identity Management on Clients . . . . . . . . . . . 16
7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 17 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 17
7.4. Best Security Policy Practices . . . . . . . . . . . . . 17 7.4. Best Security Policy Practices . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 18 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 18
8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 18 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 20
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Known Weaknesses of the AUTH_SYS Authentication Appendix A. Known Weaknesses of the AUTH_SYS Authentication
Flavor . . . . . . . . . . . . . . . . . . . . . . . 21 Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
RFC Editor: Please remove this Editor's Note and the following In 2014 the IETF published a document entitled "Pervasive Monitoring
paragraph before this document is published. Is an Attack" [RFC7258], which recognized that unauthorized
observation of network traffic had become widespread and was a
The source for this draft is maintained in GitHub. Suggested changes subversive threat to all who make use of the Internet at large. It
should be submitted as pull requests at strongly recommended that newly defined Internet protocols should
https://github.com/chucklever/i-d-rpc-tls [1]. Instructions are on
that page as well. Editorial changes can be managed in GitHub, but
any substantive change should be discussed on the nfsv4@ietf.org
mailing list.
In 2014 the IETF published [RFC7258], which recognized that
unauthorized observation of network traffic had become widespread and
was a subversive threat to all who make use of the Internet at large.
It 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 is done by 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:
o Parts of each RPC header remain in clear-text, constituting a * Parts of each RPC header remain in clear-text, constituting a
significant security exposure. significant security exposure.
o 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:
o Per-client deployment and administrative costs are not scalable. * Per-client deployment and administrative costs are not scalable.
Administrators must provide keying material for each RPC client, Administrators must provide keying material for each RPC client,
including transient clients. including transient clients.
o Host identity management and user identity management must be * 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 The alternative described in the current document is to employ a
transport layer security mechanism that can protect the transport layer security mechanism that can protect the
confidentiality of each RPC connection transparently to RPC and confidentiality of each RPC connection transparently to RPC and
upper-layer protocols. The Transport Layer Security protocol upper-layer protocols. The Transport Layer Security protocol
[RFC8446] (TLS) is a well-established Internet building block that [RFC8446] (TLS) is a well-established Internet building block that
protects many standard Internet protocols such as the Hypertext protects many standard Internet protocols such as the Hypertext
skipping to change at page 4, line 45 skipping to change at page 4, line 48
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 The current document specifies the implementation of RPC on an
encrypted transport in a manner that is transparent to upper-layer encrypted transport in a manner that is transparent to upper-layer
protocols based on RPC. The imposition of encryption at the protocols based on RPC. The imposition of encryption at the
transport layer protects any upper-layer protocol that employs RPC, transport layer protects any upper-layer protocol that employs RPC,
without alteration of that protocol. 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-on-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-on-TLS is of particular transactions. 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 RPC, TLS, PKI, GSS-API, and DNSSEC is already available
in an RPC implementation where TLS support is to be added. in an RPC implementation where 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 BCP "OPTIONAL" in this document are to be interpreted as described in
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
This document adopts the terminology introduced in Section 3 of This document adopts the terminology introduced in Section 3 of
[RFC6973] and assumes a working knowledge of the Remote Procedure [RFC6973] and assumes a working knowledge of the Remote Procedure
Call (RPC) version 2 protocol [RFC5531] and the Transport Layer Call (RPC) version 2 protocol [RFC5531] and the Transport Layer
Security (TLS) version 1.3 protocol [RFC8446]. Security (TLS) version 1.3 protocol [RFC8446].
Note also that the NFS community long ago adopted the use of the term Note also that the NFS community long ago adopted the use of the term
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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 TLS. Policy settings on with RPC implementations that do not support RPC-over-TLS. Policy
the RPC-on-TLS-enabled peer determine whether RPC operation continues settings on the RPC-over-TLS-enabled peer determine whether RPC
without the use of TLS or RPC operation is not permitted. operation continues without the use of TLS or RPC operation is not
permitted.
To achieve this, we introduce a new RPC authentication flavor called To achieve this interoperability, we introduce a new RPC
AUTH_TLS. This new flavor signals that the client wants to initiate authentication flavor called AUTH_TLS. The AUTH_TLS authentication
TLS negotiation if the server supports it. Except for the flavor signals that the client wants to initiate TLS negotiation if
modifications described in this section, the RPC protocol is unaware the server supports it. Except for the modifications described in
of security encapsulation at the transport layer. this section, the RPC protocol is unaware of security encapsulation
at the transport layer. The value of AUTH_TLS is defined in
Section 8.1.
When an RPC client is ready to begin a TLS session, it sends a NULL An RPC client begins its communication with an RPC server by
RPC procedure with an auth_flavor of AUTH_TLS. The value of AUTH_TLS selecting a transport and destination port. The choice of transport
is defined in Section 8.1. The NULL request is made to the same port and port is typically based on the RPC program that is to be used.
as if TLS were not in use. 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
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
connection to that port and sends a NULL RPC procedure with an
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
containing a NULL RPC procedure with an auth_flavor of AUTH_TLS. The
mechanism described in the current document does not support RPC
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 the
RPC Call message MUST be zero. The verifier accompanying the RPC Call message MUST be zero. The verifier accompanying the
credential MUST be an AUTH_NONE verifier of length zero. credential MUST be an AUTH_NONE verifier of length zero.
The flavor value of the verifier in the RPC Reply message received The flavor value of the verifier in the RPC Reply message received
from the server MUST be AUTH_NONE. The length of the verifier's body from the server MUST be AUTH_NONE. The length of the verifier's body
field is eight. The bytes of the verifier's body field encode the field is eight. The bytes of the verifier's body field encode the
ASCII characters "STARTTLS" as a fixed-length opaque. ASCII characters "STARTTLS" as a fixed-length opaque.
If the RPC server replies with a reply_stat of MSG_ACCEPTED and an If the RPC server replies with a reply_stat of MSG_ACCEPTED and an
AUTH_NONE verifier containing the "STARTTLS" token, the RPC client AUTH_NONE verifier containing the "STARTTLS" token, the client SHOULD
follows with a "ClientHello" message. The client MAY proceed with proceed with TLS session establishment, even if the Reply's
TLS session establishment even if the Reply's accept_stat is not accept_stat is not SUCCESS. If the AUTH_TLS probe was done via TCP,
SUCCESS (for example, if the accept_stat is PROG_UNAVAIL). Once the the RPC client MUST send the "ClientHello" message on the same
TLS handshake is complete, the RPC client and server have established connection. If the AUTH_TLS probe was done via UDP, the RPC client
a secure channel for communicating. MUST send the "ClientHello" message to the same UDP destination port.
If the Reply's reply_stat is MSG_ACCEPTED but the verifier does not Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its
contain the "STARTTLS" token, or if the Reply's reply_stat is verifier flavor is not AUTH_NONE, or if its verifier does not contain
MSG_DENIED, the RPC client MUST NOT send a "ClientHello" message. the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello"
RPC operation can continue, however it will be without any message. RPC operation can continue, however it will be without any
confidentiality, integrity or authentication protection from (D)TLS. confidentiality, integrity or authentication protection from (D)TLS.
If, after a successful RPC AUTH_TLS probe, the subsequent 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 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 setting the reply_stat field to
MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
field to AUTH_BADCRED. field to AUTH_BADCRED.
Once the TLS session handshake is complete, the RPC client and server
have established a secure channel for communicating. A successful
AUTH_TLS probe on one particular port/transport tuple never implies
RPC-over-TLS is available on that same server using a different port/
transport tuple.
4.2. Authentication 4.2. Authentication
Both RPC and TLS have peer and user authentication, with some overlap Both RPC and TLS have peer and user authentication, with some overlap
in capability between RPC and TLS. The goal of interoperability with in capability between RPC and TLS. The goal of interoperability with
implementations that do not support TLS requires limiting the implementations that do not support TLS requires limiting the
combinations that are allowed and precisely specifying the role that combinations that are allowed and precisely specifying the role that
each layer plays. We also want to handle TLS such that an RPC each layer plays.
implementation can make the use of TLS invisible to existing RPC
consumer applications.
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 25 skipping to change at page 8, line 37
using TLS and RPCSEC GSS can use GSS channel binding, as defined in using TLS and RPCSEC GSS can use GSS channel binding, as defined in
[RFC5056], to determine when an underlying transport provides a [RFC5056], to determine when an underlying transport provides a
sufficient degree of confidentiality. Channel bindings for the TLS sufficient degree of confidentiality. Channel bindings for the TLS
channel type are defined in [RFC5929]. channel type are defined in [RFC5929].
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:
o 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.
o Implementations MUST support certificate-based mutual * Implementations MUST support certificate-based mutual
authentication. Support for TLS-PSK mutual authentication authentication. Support for TLS-PSK mutual authentication
[RFC4279] is OPTIONAL. See Section 4.2 for further details. [RFC4279] is OPTIONAL. See Section 4.2 for further details.
o 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 Similary, 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, the client MUST NOT establish a If the server responds incorrectly (for instance, if the
TLS session for use with RPC on this connection. See [RFC7301] for "ServerHello" message does not conform to the above requirements),
further details about how to form these messages properly. the client MUST NOT establish a TLS session for use with RPC on this
connection. See [RFC7301] for further details about how to form
these messages properly.
5.1. Base Transport Considerations 5.1. Base Transport Considerations
There is traditionally a strong association between an RPC program There is traditionally a strong association between an RPC program
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-on-TLS support for that connection. If Section 4.1 to discover RPC-over-TLS support for that connection. If
spurious traffic appears on a TCP connection between the initial spurious traffic appears on a TCP connection between the initial
clear-text AUTH_TLS probe and the TLS session handshake, receivers clear-text AUTH_TLS probe and the TLS session handshake, receivers
MUST discard that data without response and then SHOULD drop the MUST discard that data without response and then SHOULD drop the
connection. 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.
Backchannel operation occurs only on connected transports such as Reverse-direction operation occurs only on connected transports such
TCP. To protect backchannel operations, an RPC server uses the as TCP (see Section 2 of [RFC8166]). To protect reverse-direction
existing TLS session on that connection to send backchannel RPC operations, the RPC server does not establish a separate TLS
operations. The server does not attempt to establish a TLS session session on the TCP connection, but instead uses the existing TLS
on a TCP connection for backchannel operation. 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 and 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. Each RPC message MUST fit in a single DTLS record. DTLS
encapsulation has overhead, which reduces the effective Path MTU encapsulation has overhead, which reduces the effective Path MTU
(PMTU) and thus the maximum RPC payload size. The use of DTLS record (PMTU) and thus the maximum RPC payload size. The use of DTLS record
skipping to change at page 11, line 16 skipping to change at page 11, line 30
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 5.2.1. X.509 Certificates Using PKIX trust
Implementations are REQUIRED to support this mechanism. In this Implementations are REQUIRED to support this mechanism. In this
mode, the tuple (serial number of the presented certificate; Issuer) mode, the tuple (serial number of the presented certificate; Issuer)
uniquely identifies the RPC peer. uniquely identifies the RPC peer.
o Implementations MUST allow the configuration of a list of trusted X.509 certificates are specified in [X.509] and extended in
Certification Authorities for incoming connections. [RFC5280].
o Certificate validation MUST include the verification rules as per * Implementations MUST allow the configuration of a list of trusted
Certification Authorities for authorizing incoming connections.
* Certificate validation MUST include the verification rules as per
[RFC5280]. [RFC5280].
o Implementations SHOULD indicate their trusted Certification * Implementations SHOULD indicate their trusted Certification
Authorities (CAs). Authorities (CAs).
o Peer validation always includes a check on whether the locally * Peer validation always includes a check on whether the locally
configured expected DNS name or IP address of the server that is configured expected DNS name or IP address of the server that is
contacted matches its presented certificate. DNS names and IP contacted matches its presented certificate. DNS names and IP
addresses can be contained in the Common Name (CN) or addresses can be contained in the Common Name (CN) or
subjectAltName entries. For verification, only one of these subjectAltName entries. For verification, only one of these
entries is to be considered. The following precedence applies: entries is to be considered. The following precedence applies:
for DNS name validation, subjectAltName:DNS has precedence over for DNS name validation, subjectAltName:DNS has precedence over
CN; for IP address validation, subjectAltName:iPAddress has CN; for IP address validation, subjectAltName:iPAddress has
precedence over CN. Implementors of this specification are precedence over CN. Implementors of this specification are
advised to read Section 6 of [RFC6125] for more details on DNS advised to read Section 6 of [RFC6125] for more details on DNS
name validation. name validation.
o For services accessed by their network identifiers (netids) and * For services accessed by their network identifiers (netids) and
universal network addresses (uaddr), the iPAddress subjectAltName universal network addresses (uaddr), the iPAddress subjectAltName
SHOULD be present in the certificate and must exactly match the SHOULD be present in the certificate and must exactly match the
address represented by universal address. address represented by the universal network address.
o Implementations MAY allow the configuration of a set of additional * Implementations MAY allow the configuration of a set of additional
properties of the certificate to check for a peer's authorization properties of the certificate to check for a peer's authorization
to communicate (e.g., a set of allowed values in to communicate (e.g., a set of allowed values in
subjectAltName:URI or a set of allowed X509v3 Certificate subjectAltName:URI or a set of allowed X.509v3 Certificate
Policies). Policies).
o When the configured trust base changes (e.g., removal of a CA from * 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), the list of trusted CAs; issuance of a new CRL for a given CA),
implementations MAY renegotiate the TLS session to reassess the implementations MAY renegotiate the TLS session to reassess the
connecting peer's continued authorization. connecting peer's continued authorization.
Authenticating a connecting entity does not mean the RPC server Authenticating a connecting entity does not mean the RPC server
necessarily wants to communicate with that client. For example, if necessarily wants to communicate with that client. For example, if
the Issuer is not in a trusted set of Issuers, the RPC server may the Issuer is not in a trusted set of Issuers, the RPC server may
decline to perform RPC transactions with this client. decline to perform RPC transactions with this client.
Implementations that want to support a wide variety of trust models Implementations that want to support a wide variety of trust models
should expose as many details of the presented certificate to the should expose as many details of the presented certificate to the
administrator as possible so that the administrator can implement the administrator as possible so that the administrator can implement the
trust model. As a suggestion, at least the following parameters of trust model. As a suggestion, at least the following parameters of
the X.509 client certificate SHOULD be exposed: the X.509 client certificate SHOULD be exposed:
o Originating IP address * Originating IP address
o Certificate Fingerprint * Certificate Fingerprint
o Issuer * Issuer
o Subject * Subject
o all X509v3 Extended Key Usage * all X.509v3 Extended Key Usage
o all X509v3 Subject Alternative Name * all X.509v3 Subject Alternative Name
o all X509v3 Certificate Policies * all X.509v3 Certificate Policies
5.2.2. X.509 Certificates Using Fingerprints 5.2.2. X.509 Certificates Using Fingerprints
This mechanism is OPTIONAL to implement. In this mode, the This mechanism is OPTIONAL to implement. In this mode, the
fingerprint of the presented certificate uniquely identifies the RPC fingerprint of a certificate uniquely identifies the RPC peer.
peer.
Implementations SHOULD allow the configuration of a list of trusted A "fingerprint" is typically defined as a cryptographic digest of the
certificates, identified via fingerprint of the DER-encoded Distinguished Encoding Rules (DER) form [X.690] of an X.509v3
certificate octets. Implementations MUST support SHA-256 certificate [X.509]. Implementations SHOULD allow the configuration
[FIPS.180-4] or stronger as the hash algorithm for the fingerprint. of a list of trusted certificates that is indexed by fingerprint.
5.2.3. Pre-Shared Keys 5.2.3. 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- is uniquely identified by keying material that has been shared out-
of-band or by a previous TLS-protected connection (see Section 2.2 of of-band or by a previous TLS-protected connection (see Section 2.2 of
[RFC8446]). At least the following parameters of the TLS connection [RFC8446]). At least the following parameters of the TLS connection
SHOULD be exposed: SHOULD be exposed:
o Originating IP address * Originating IP address
o TLS Identifier * TLS Identifier
5.2.4. Token Binding 5.2.4. Token Binding
This mechanism is OPTIONAL to implement. In this mode, a token This mechanism is OPTIONAL to implement. In this mode, a token
uniquely identifies the RPC peer. uniquely identifies the RPC peer.
Versions of TLS after TLS 1.2 contain a token binding mechanism that Versions of TLS after TLS 1.2 contain a token binding mechanism that
is more secure than using certificates. This mechanism is detailed is more secure than using certificates. This mechanism is detailed
in [RFC8471]. in [RFC8471].
6. Implementation Status 6. Implementation Status
RFC Editor: Please remove this section and the reference to RFC 7942 This section is to be removed before publishing as an RFC.
before this document is published.
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
RFCs. RFCs.
Please note that the listing of any individual implementation here Please note that the listing of any individual implementation here
does not imply endorsement by the IETF. Furthermore, no effort has does not imply endorsement by the IETF. Furthermore, no effort has
been spent to verify the information presented here that was supplied been spent to verify the information presented here that was supplied
by IETF contributors. This is not intended as, and must not be by IETF contributors. This is not intended as, and must not be
construed to be, a catalog of available implementations or their construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
6.1. DESY NFS server 6.1. DESY NFS server
Organization: DESY Organization: DESY
URL: https://desy.de [2] URL: https://desy.de
Maturity: Implementation will be based on mature versions of the Maturity: Implementation will be based on mature versions of the
current document. current document.
Coverage: The bulk of this specification is implemented including Coverage: The bulk of this specification is implemented including
DTLS. DTLS.
Licensing: LGPL Licensing: LGPL
Implementation experience: The implementer has read and commented on Implementation experience: The implementer has read and commented on
the current document. the current document.
6.2. Hammerspace NFS server 6.2. Hammerspace NFS server
Organization: Hammerspace Organization: Hammerspace
URL: https://hammerspace.com [3] URL: https://hammerspace.com
Maturity: Prototype software based on early versions of the current Maturity: Prototype software based on early versions of the current
document. document.
Coverage: The bulk of this specification is implemented. The use of Coverage: The bulk of this specification is implemented. The use of
DTLS functionality is not implemented. DTLS functionality is not implemented.
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 [4] URL: https://www.kernel.org
Maturity: Prototype software based on early versions of the current Maturity: Prototype software based on early versions of the current
document. 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: No comments from the implementor.
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 [5] 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.
Coverage: The bulk of this specification is implemented. The use of Coverage: The bulk of this specification is implemented. The use of
DTLS functionality is not planned. DTLS functionality is not planned.
Licensing: BSD Licensing: BSD
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
skipping to change at page 15, line 46 skipping to change at page 16, line 14
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. Clients
implementers can choose from the following to mitigate STRIPTLS implementers can choose from the following to mitigate STRIPTLS
attacks: attacks:
o 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.
o 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. If
TLSA records are not available, this approach is strongly TLSA records are not available, this approach is strongly
encouraged. 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
skipping to change at page 16, line 32 skipping to change at page 16, line 49
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.
7.2. TLS Identity Management on Clients 7.2. TLS Identity Management on Clients
The goal of the RPC-on-TLS protocol extension is to hide the content The goal of the RPC-over-TLS protocol extension is to hide the
of RPC requests while they are in transit. The RPC-on-TLS protocol content of RPC requests while they are in transit. The RPC-over-TLS
by itself cannot protect against exposure of a user's RPC requests to protocol by itself cannot protect against exposure of a user's RPC
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 identity material is potentially visible to every RPC
user that shares a TLS session. Privileged users may also be able to user 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 identity material so that local access to it is restricted to only
the local users that are authorized to perform operations on the the local users that are authorized to perform operations on the
remote RPC server. remote 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 (as flavor is in use addresses several longstanding weaknesses in
detailed in Appendix A). TLS augments AUTH_SYS by providing both AUTH_SYS (as detailed in Appendix A). TLS augments AUTH_SYS by
integrity protection and confidentiality that AUTH_SYS lacks. TLS providing both integrity protection and confidentiality that AUTH_SYS
protects data payloads, RPC headers, and user identities against lacks. TLS protects data payloads, RPC headers, and user identities
monitoring and alteration while in transit. TLS guards against the against monitoring and alteration while in transit.
insertion or deletion of messages, thus also ensuring the integrity
of the message stream between RPC client and server. Lastly, TLS guards against in-transit insertion and deletion of RPC messages,
transport layer encryption plus peer authentication protects thus ensuring the integrity of the message stream between RPC client
receiving XDR decoders from deserializing untrusted data, a common and server. DTLS does not provide full message stream protection,
coding vulnerability. but it does enable receivers to reject non-participant messages. In
particular, transport layer encryption plus peer authentication
protects receiving XDR decoders from deserializing untrusted data, a
common coding vulnerability.
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.
skipping to change at page 17, line 45 skipping to change at page 18, line 11
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.
o When using AUTH_NULL or AUTH_SYS, both peers are required to have * When using AUTH_NULL or AUTH_SYS, both peers are required to have
DNS TLSA records and certificate material, and a policy that DNS TLSA records and certificate material, and a policy that
requires mutual peer authentication and rejection of a connection requires mutual peer authentication and rejection of a connection
when host authentication fails. when host authentication fails.
o When using RPCSEC_GSS, GSS/Kerberos provides adequate host * RCPSEC_GSS provides integrity and privacy services which are
authentication and a policy that requires GSS mutual redundant when TLS is in use. These services should be disabled
authentication and rejection of a connection when host in that case.
authentication fails. GSS integrity and privacy services,
therefore, can be disabled in favor of TLS encryption with peer
authentication.
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 18, line 29 skipping to change at page 18, line 41
RPC. This new flavor is not a pseudo-flavor. RPC. This new flavor is not a pseudo-flavor.
The fields in the new entry are assigned as follows: The fields in the new entry are assigned as follows:
Identifier String: AUTH_TLS Identifier String: AUTH_TLS
Flavor Name: TLS Flavor Name: TLS
Value: 7 Value: 7
Description: Signals the use of TLS to protect RPC messages on Description: Indicates support for RPC-over-TLS.
socket-based transports
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.
skipping to change at page 18, line 42 skipping to change at page 19, line 4
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
9. References 9. References
9.1. Normative References
[FIPS.180-4] 9.1. Normative References
National Institute of Standards and Technology, "Secure
Hash Standard, Federal Information Processing Standards
Publication FIPS PUB 180-4", FIPS PUB 180-4, August 2015.
[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", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", Work in Progress, Internet-
id-07 (work in progress), October 2019. Draft, draft-ietf-tls-dtls-connection-id-07, 21 October
2019, <https://tools.ietf.org/html/draft-ietf-tls-dtls-
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", draft-ietf-tls-dtls13-37 (work in progress), March 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
2020. dtls13-38, 29 May 2020,
<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 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>. <https://www.rfc-editor.org/info/rfc4279>.
skipping to change at page 20, line 34 skipping to change at page 20, line 38
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[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
Committee, "ITU-T X.509 - Information technology - The
Directory: Public-key and attribute certificate
frameworks.", ISO/IEC 9594-8, CCITT Recommendation X.509,
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
[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>.
skipping to change at page 21, line 31 skipping to change at page 21, line 44
[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, [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges,
"The Token Binding Protocol Version 1.0", RFC 8471, "The Token Binding Protocol Version 1.0", RFC 8471,
DOI 10.17487/RFC8471, October 2018, DOI 10.17487/RFC8471, October 2018,
<https://www.rfc-editor.org/info/rfc8471>. <https://www.rfc-editor.org/info/rfc8471>.
9.3. URIs
[1] https://github.com/chucklever/i-d-rpc-tls
[2] https://desy.de
[3] https://hammerspace.com
[4] https://www.kernel.org
[5] https://www.freebsd.org
[6] https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls
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 27 skipping to change at page 22, line 25
does not specify any requirements for this string other than that is does not specify any requirements for this string other than that is
no longer than 255 octets. It does not have to be the same from no longer than 255 octets. It does not have to be the same from
request to request. Also, it does not have to match the DNS hostname request to request. Also, it does not have to match the DNS hostname
of the sending host. For these reasons, even though most of the sending host. For these reasons, even though most
implementations fill in their hostname in this field, receivers implementations fill in their hostname in this field, receivers
typically ignore its content. typically ignore its content.
Appendix A of [RFC5531] contains a brief explanation of security Appendix A of [RFC5531] contains a brief explanation of security
considerations: considerations:
It should be noted that use of this flavor of authentication does | It should be noted that use of this flavor of authentication does
not guarantee any security for the users or providers of a | not guarantee any security for the users or providers of a
service, in itself. The authentication provided by this scheme | service, in itself. The authentication provided by this scheme
can be considered legitimate only when applications using this | can be considered legitimate only when applications using this
scheme and the network can be secured externally, and privileged | scheme and the network can be secured externally, and privileged
transport addresses are used for the communicating end-points (an | transport addresses are used for the communicating end-points (an
example of this is the use of privileged TCP/UDP ports in UNIX | example of this is the use of privileged TCP/UDP ports in UNIX
systems -- note that not all systems enforce privileged transport | systems -- note that not all systems enforce privileged transport
address mechanisms). | address mechanisms).
It should be clear, therefore, that AUTH_SYS by itself (i.e., without It should be clear, therefore, that AUTH_SYS by itself (i.e., without
strong client authentication) offers little to no communication strong client authentication) offers little to no communication
security: security:
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
skipping to change at page 23, line 11 skipping to change at page 23, line 8
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.
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.
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" [6]. His article inspired the mechanism described with Stunnel TLS" (https://www.linuxjournal.com/content/encrypting-
in the current document. nfsv4-stunnel-tls). His article inspired the mechanism described in
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
skipping to change at page 23, line 41 skipping to change at page 23, line 39
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
4300 El Camino Real Ste 105 4300 El Camino Real Ste 105
Los Altos, CA 94022 Los Altos, CA 94022
United States of America United States of America
Email: trond.myklebust@hammerspace.com Email: trond.myklebust@hammerspace.com
Charles Lever (editor) Charles Lever (editor)
Oracle Corporation Oracle Corporation
United States of America United States of America
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 84 change blocks. 
181 lines changed or deleted 201 lines changed or added

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