draft-ietf-nfsv4-rpc-tls-04.txt   draft-ietf-nfsv4-rpc-tls-05.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: May 20, 2020 November 17, 2019 Expires: July 13, 2020 January 10, 2020
Towards Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-04 draft-ietf-nfsv4-rpc-tls-05
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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 20, 2020. This Internet-Draft will expire on July 13, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5
4.1. Discovering Server-side TLS Support . . . . . . . . . . . 5 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . 8 5.1. Base Transport Considerations . . . . . . . . . . . . . . 8
5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8 5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8
5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 9 5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 9
5.1.3. Operation on Other Transports . . . . . . . . . . . . 9 5.1.3. Operation on Other Transports . . . . . . . . . . . . 9
5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 9 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 9
5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 10 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 9
5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 11 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 11
5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 11 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 11
5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 11
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 12 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 12
6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 12 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 12
6.3. Linux NFS server and client . . . . . . . . . . . . . . . 13 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Limitations of an Opportunistic Approach . . . . . . . . 13 7.1. Limitations of an Opportunistic Approach . . . . . . . . 13
7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 13 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 13
7.2. Multiple User Identity Realms . . . . . . . . . . . . . . 14 7.2. TLS Identity Management on Clients . . . . . . . . . . . 14
7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 14 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 14
7.4. Best Security Policy Practices . . . . . . . . . . . . . 15 7.4. Best Security Policy Practices . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Known Weaknesses of the AUTH_SYS Authentication Appendix A. Known Weaknesses of the AUTH_SYS Authentication
Flavor . . . . . . . . . . . . . . . . . . . . . . . 18 Flavor . . . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
In 2014 the IETF published [RFC7258] which recognized that In 2014 the IETF published [RFC7258], which recognized that
unauthorized observation of network traffic had become widespread and unauthorized observation of network traffic had become widespread and
was a subversive threat to all who make use of the Internet at large. was a subversive threat to all who make use of the Internet at large.
It strongly recommended that newly defined Internet protocols make a It strongly recommended that newly defined Internet protocols should
real 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 antecedants). Standard for three decades (see [RFC5531] and its antecedents). Over
Eisler et al. first introduced an in-transit encryption mechanism for twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in-
RPC with RPCSEC GSS over twenty years ago [RFC2203]. However, transit encryption mechanism for RPC [RFC2203]. However, experience
experience has shown that RPCSEC GSS can be difficult to deploy: has shown that RPCSEC GSS with in-transit encryption can be
challenging to use in practice:
o Per-client deployment and administrative costs are not scalable. o Parts of each RPC header remain in clear-text, constituting a
Keying material must be provided for each RPC client, including significant security exposure.
transient clients.
o Parts of each RPC header remain in clear-text, and can constitute o Offloading GSS privacy is not practical in large multi-user
a significant security exposure. deployments since each message is encrypted using a key based on
the issuing RPC user.
However strong a privacy service is, it cannot provide any security
if the challenges of using it result in choosing not to deploy it at
all.
Moreover, the use of AUTH_SYS remains common despite the adverse
effects that acceptance of UIDs and GIDs from unauthenticated clients
brings with it. Continued use is in part because:
o Per-client deployment and administrative costs are not scalable.
Administrators must provide keying material for each RPC client,
including transient clients.
o Host identity management and user identity management must be o Host identity management and user identity management must be
carried out 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.
o On-host cryptographic manipulation of data payloads can exact a The alternative described in the current document is to employ a
significant CPU and memory bandwidth cost on RPC peers. Offloadng transport layer security mechanism that can protect the privacy of
does not appear to be practical using GSS privacy since each each RPC connection transparently to RPC and upper-layer protocols.
message is encrypted using its own key based on the issuing RPC
user.
However strong a privacy service is, it cannot provide any security
if the challenges of using it result in it not being used at all.
An alternative approach is to employ a transport layer security The Transport Layer Security protocol [RFC8446] (TLS) is a well-
mechanism that can protect the privacy of each RPC connection established Internet building block that protects many standard
transparently to RPC and Upper Layer protocols. The Transport Layer Internet protocols such as the Hypertext Transport Protocol (HTTP)
Security protocol [RFC8446] (TLS) is a well-established Internet [RFC2818].
building block that protects many common Internet protocols such as
the Hypertext Transport Protocol (http) [RFC2818].
Encrypting at the RPC transport layer enables several significant Encrypting at the RPC transport layer accords several significant
benefits. benefits:
Encryption By Default Encryption By Default: Transport encryption can be enabled without
In-transit encryption by itself may be enabled without additional additional administrative tasks such as identifying client systems
administrative actions such as identifying client systems to a to a trust authority, generating additional keying material, or
trust authority, generating additional key material, or
provisioning a secure network tunnel. provisioning a secure network tunnel.
Protection of Existing Protocols Encryption Offload: Hardware support for GSS privacy has not
The imposition of encryption at the transport layer protects any appeared in the marketplace. However, the use of a well-
Upper Layer protocol that employs RPC, without alteration of that established transport encryption mechanism that is employed by
protocol. RPC transport layer encryption can protect recent other ubiquitous network protocols makes it more likely that
versions of NFS such as NFS version 4.2 [RFC7862] and indeed encryption offload for RPC is practicable.
legacy NFS versions such as NFS version 3 [RFC1813], and NFS side-
band protocols such as the MNT protocol [RFC1813].
Decoupled User and Host Identities Securing AUTH_SYS: Most critically, transport encryption can
TLS can be used to authenticate peer hosts while other security significantly reduce several security issues inherent in the
mechanisms can handle user authentictation. Cryptographic current widespread use of AUTH_SYS (i.e., acceptance of UIDs and
authentication of hosts can be provided while still using simpler GIDs generated by an unauthenticated client).
user authentication flavors such as AUTH_SYS.
Encryption Offload Decoupled User and Host Identities: TLS can be used to authenticate
Whereas hardware support for GSS privacy has not appeared in the peer hosts while other security mechanisms can handle user
marketplace, the use of a well-established transport encryption authentication.
mechanism that is also employed by other very common network
protocols makes it likely that a hardware encryption
implementation will be available to offload encryption and
decryption.
Securing AUTH_SYS The current document specifies the implementation of RPC on an
Most critically, several security issues inherent in the current encrypted transport in a fashion that is transparent to upper-layer
widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs protocols based on RPC. The imposition of encryption at the
generated by an unauthenticated client) can be significantly transport layer protects any upper-layer protocol that employs RPC,
ameliorated. without alteration of that protocol.
This document specifies the use of RPC on a TLS-protected transport Further, the current document defines policies in line with [RFC7435]
in a fashion that is transparent to upper layer protocols based on which enable RPC-on-TLS to be deployed opportunistically in
RPC. It provides policies in line with [RFC7435] that enable RPC-on- environments with RPC implementations that do not support TLS.
TLS to be deployed opportunistically in environments with RPC Specifications for RPC-based upper-layer protocols are free to
implementations that do not support TLS. Specifications for RPC- require stricter policies to guarantee that encryption or host
based upper layer protocols are free to require stricter policies to authentication is in use on every connection.
guarantee that TLS with encryption or TLS with host authentication
and encryption is used for every connection.
Note that the protocol specification in this document assumes that The protocol specification in the current document assumes that
support for RPC, TLS, PKI, GSS-API, and/or DNSSEC is already support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available
available in an implementation where RPC-on-TLS 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 uses the term "privacy" where other Note also that the NFS community uses the term "privacy" where other
Internet communities use "confidentiality". In this document the two Internet communities use "confidentiality". In the current document
terms are synonymous. the two terms are synonymous.
We adhere to the convention that a "client" is a network host that We adhere to the convention that a "client" is a network host that
actively initiates an association, and a "server" is a network host actively initiates an association, and a "server" is a network host
that passively accepts an association request. that passively accepts an association request.
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
this document there is little distinction between these terms. the current document there is little distinction between these terms.
The term "user authentication" in this document refers specifically The term "user authentication" in this document refers specifically
to the RPC caller's credential, provided in the "cred" and "verf" to the RPC caller's credential, provided in the "cred" and "verf"
fields in each RPC Call. 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 this document interoperates fully with RPC The mechanism described in this document interoperates fully with RPC
implementations that do not support TLS. The use of TLS is implementations that do not support TLS. The use of TLS is
automatically disabled in these cases. automatically disabled in these cases.
To achieve this, we introduce a new RPC authentication flavor called To achieve this, we introduce a new RPC authentication flavor called
AUTH_TLS. This new flavor is used to signal that the client wants to AUTH_TLS. This new flavor signals that the client wants to initiate
initiate TLS negotiation if the server supports it. Except for the TLS negotiation if the server supports it. Except for the
modifications described in this section, the RPC protocol is largely modifications described in this section, the RPC protocol is unaware
unaware of security encapsulation. of security encapsulation.
<CODE BEGINS> <CODE BEGINS>
enum auth_flavor { enum auth_flavor {
AUTH_NONE = 0, AUTH_NONE = 0,
AUTH_SYS = 1, AUTH_SYS = 1,
AUTH_SHORT = 2, AUTH_SHORT = 2,
AUTH_DH = 3, AUTH_DH = 3,
AUTH_KERB = 4, AUTH_KERB = 4,
AUTH_RSA = 5, AUTH_RSA = 5,
skipping to change at page 6, line 38 skipping to change at page 6, line 36
The flavor value of the verifier received in the reply message from The flavor value of the verifier received in the reply message from
the server MUST be AUTH_NONE. The bytes of the verifier's string the server MUST be AUTH_NONE. The bytes of the verifier's string
encode the fixed ASCII characters "STARTTLS". encode the fixed ASCII characters "STARTTLS".
When an RPC client is ready to begin sending traffic to a server, it When an RPC client is ready to begin sending traffic to a server, it
starts with a NULL RPC request with an auth_flavor of AUTH_TLS. The starts with a NULL RPC request with an auth_flavor of AUTH_TLS. The
NULL request is made to the same port as if TLS were not in use. NULL request is made to the same port as if TLS were not in use.
The RPC server can respond in one of three ways: The RPC server can respond in one of three ways:
o If the RPC server does not recognise the AUTH_TLS authentication o If the RPC server does not recognize the AUTH_TLS authentication
flavor, it responds with a reject_stat of AUTH_ERROR. The RPC flavor, it responds with a reject_stat of AUTH_ERROR. The RPC
client then knows that this server does not support TLS. client then knows that this server does not support TLS.
o If the RPC server accepts the NULL RPC procedure, but fails to o If the RPC server accepts the NULL RPC procedure but fails to
return an AUTH_NONE verifier containing the string "STARTTLS", the return an AUTH_NONE verifier containing the string "STARTTLS", the
RPC client knows that this server does not support TLS. RPC client knows that this server does not support TLS.
o If the RPC server accepts the NULL RPC procedure, and returns an o If the RPC server accepts the NULL RPC procedure and returns an
AUTH_NONE verifier containing the string "STARTTLS", the RPC AUTH_NONE verifier containing the string "STARTTLS", the RPC
client SHOULD send a STARTTLS. client SHOULD send a STARTTLS.
Once the TLS handshake is complete, the RPC client and server will Once the TLS handshake is complete, the RPC client and server have
have established a secure channel for communicating. The client MUST established a secure channel for communicating. The client MUST
switch to a security flavor other than AUTH_TLS within that channel, switch to a security flavor other than AUTH_TLS within that channel,
presumably after negotiating down redundant RPCSEC_GSS privacy and presumably after negotiating down redundant RPCSEC_GSS privacy and
integrity services and applying channel binding [RFC7861]. integrity services and applying channel binding [RFC7861].
If TLS negotiation fails for any reason -- say, the RPC server If TLS negotiation fails for any reason, the RPC client reports this
rejects the certificate presented by the RPC client, or the RPC failure to the upper-layer application the same way it would report
client fails to authenticate the RPC server -- the RPC client reports
this failure to the calling application the same way it would report
an AUTH_ERROR rejection from the RPC server. an AUTH_ERROR rejection from the RPC server.
If an RPC client attempts to use AUTH_TLS for anything other than the If an RPC client attempts to use AUTH_TLS for anything other than the
NULL RPC procedure, the RPC server MUST respond with a reject_stat of NULL RPC procedure, the RPC server MUST respond with a reject_stat of
AUTH_ERROR. If the client sends a STARTTLS after it has sent other AUTH_ERROR. If the client sends a STARTTLS after it has sent other
non-encrypted RPC traffic or after a TLS session has already been non-encrypted RPC traffic or after a TLS session already in place,
negotiated, the server MUST silently discard it. the server MUST silently discard it.
4.2. Authentication 4.2. Authentication
Both RPC and TLS have their own variants of authentication, and there Both RPC and TLS have peer and user authentication, with some overlap
is some overlap in capability. The goal of interoperability with in capability between RPC and TLS. The goal of interoperability with
implementations that do not support TLS requires that we limit the implementations that do not support TLS requires limiting the
combinations that are allowed and precisely specify 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. We also want to handle TLS such that an RPC
implementation can make the use of TLS invisible to existing RPC implementation can make the use of TLS invisible to existing RPC
consumer applications. 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, RPC-over-TLS clients are essentially In this type of deployment, the client can authenticate the server
anonymous; i.e., they present no globally unique identifier to the host using the presented server peer TLS identity, but the server
server peer. In this situation, the client can authenticate the cannot authenticate the client. In this situation, RPC-over-TLS
server host using the presented server peer TLS identity, but the clients are anonymous. They present no globally unique identifier
server cannot authenticate the client. to the server peer.
Mutual Host Authentication Mutual Host Authentication
In this type of deployment, the client possesses a unique global In this type of deployment, the client possesses a unique global
identity (e.g., a certificate). As part of the TLS handshake, identity (e.g., a certificate). As part of the TLS handshake,
both peers authenticate using the presented TLS identities. If both peers authenticate using the presented TLS identities. If
authentication of either peer fails, or if authorization based on authentication of either peer fails, or if authorization based on
those identities blocks access to the server, the client those identities blocks access to the server, the peers MUST
association MUST be rejected. 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. Once a TLS session is the use of transport layer security. When a client presents a TLS
established, the server MUST NOT substitute RPC_AUTH_TLS, or the peer identity to an RPC server, the protocol extension described in
remote identity used for TLS peer authentication, for existing forms the current document provides no way for the server to know whether
of per-request RPC user authentication specified by [RFC5531]. that identity represents one RPC user on that client, or is shared
amongst many RPC users. Therefore, a server implementation must not
utilize the remote TLS peer identity for RPC user authentication.
4.2.1. Using TLS with RPCSEC GSS 4.2.1. Using TLS with RPCSEC GSS
RPCSEC GSS can provide per-request integrity or privacy (also known RPCSEC GSS can provide per-request integrity or privacy (also known
as confidentiality) services. When operating over a TLS session, as confidentiality) services. When operating over a TLS session, the
these services become redundant. A TLS-capable RPC implementation GSS services become redundant. A TLS-capable RPC implementation uses
uses GSS channel binding for detecting when GSS integrity or privacy GSS channel binding to determine when GSS integrity or privacy is
is unnecessary and can therefore be avoided. See Section 2.5 of unnecessary. See Section 2.5 of [RFC7861] for details.
[RFC7861] for details.
When employing GSS above TLS, a GSS service principal is still When using GSS on a TLS session, the RPC server is still required to
required on the server, and mutual GSS authentication of server and possess a GSS service principal. GSS mutual authentication still
client still occurs after the TLS session is established. occurs after a TLS session has been established.
5. TLS Requirements 5. TLS Requirements
When a TLS session is negotiated for the purpose of transporting RPC, When peers negotiate a TLS session that is to transport RPC, the
the following restrictions apply: following restrictions apply:
o Implementations MUST NOT negotiate TLS versions prior to v1.3 o Implementations MUST NOT negotiate TLS versions prior to v1.3
[RFC8446]. Support for mandatory-to-implement ciphersuites for [RFC8446]. Support for mandatory-to-implement ciphersuites for
the negotiated TLS version is REQUIRED. the negotiated TLS version is REQUIRED.
o Implementations MUST support certificate-based mutual o 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 for confidentiality as well o Negotiation of a ciphersuite providing confidentiality as well as
as integrity protection is REQUIRED. Support for and negotiation integrity protection is REQUIRED. Support for and negotiation of
of compression is OPTIONAL. compression is OPTIONAL.
5.1. Base Transport Considerations 5.1. Base Transport Considerations
5.1.1. Operation on TCP 5.1.1. Operation on TCP
RPC over TCP is protected by using TLS [RFC8446]. As soon as a The use of TLS [RFC8446] protects RPC on TCP connections. As soon as
client completes the TCP handshake, it uses the mechanism described a client completes the TCP handshake, it uses the mechanism described
in Section 4.1 to discover TLS support and then negotiate a TLS in [RFC8446]. to discover TLS support and then negotiate a TLS
session. session.
After the TLS session is established, all traffic on the connection After establishing a TLS session, an RPC server MUST reject with a
is encapsulated and protected until the TLS session is terminated. reject_stat of AUTH_ERROR any subsequent RPC requests over the
This includes reverse-direction operations (i.e., RPC requests connection that are outside of a TLS session. Likewise, an RPC
initiated on the server-end of the connection). An RPC client client MUST silently discard any subsequent RPC replies over the
receiving a reverse-direction operation on a connection outside of an connection that are outside of a TLS session.
This restriction includes reverse-direction operations (i.e., RPC
calls initiated on the server-end of the connection). An RPC client
receiving a reverse-direction call on a connection outside of an
existing TLS session MUST reject the request with a reject_stat of existing TLS session MUST reject the request with a reject_stat of
AUTH_ERROR. AUTH_ERROR.
An RPC peer terminates a TLS session by sending a TLS closure alert, An RPC peer terminates a TLS session by sending a TLS closure alert,
or by closing the underlying TCP socket. After TLS session or by closing the underlying TCP socket.
termination, a recipient MUST reject any subsequent RPC requests over
the same connection with a reject_stat of AUTH_ERROR.
5.1.2. Operation on UDP 5.1.2. Operation on UDP
RPC over UDP is protected using DTLS [RFC6347]. As soon as a client RPC over UDP is protected using DTLS [RFC6347]. As soon as a client
initializes a socket for use with an unfamiliar server, it uses the initializes a socket for use with an unfamiliar server, it uses the
mechanism described in Section 4.1 to discover DTLS support and then mechanism described in Section 4.1 to discover DTLS support and then
negotiate a DTLS session. Connected operation is RECOMMENDED. negotiate a DTLS session. Connected operation is RECOMMENDED.
Using a DTLS transport does not introduce reliable or in-order Using a DTLS transport does not introduce reliable or in-order
semantics to RPC on UDP. Also, DTLS does not support fragmentation semantics to RPC on UDP. Also, DTLS does not support fragmentation
of RPC messages. One RPC message fits in a single DTLS datagram. of RPC messages. Each RPC message MUST fit in a single DTLS
DTLS encapsulation has overhead which reduces the effective Path MTU datagram. DTLS encapsulation has overhead, which reduces the
(PMTU) and thus the maximum RPC payload size. effective Path MTU (PMTU) and thus the maximum RPC payload size.
DTLS does not detect STARTTLS replay. A DTLS session can be DTLS does not detect STARTTLS replay. Sending a TLS closure alert
terminated by sending a TLS closure alert. Subsequent RPC messages terminates a DTLS session. Subsequent RPC messages passing between
passing between the client and server will no longer be protected the client and server are no longer protected until a new TLS session
until a new TLS session is established. is established.
5.1.3. Operation on Other Transports 5.1.3. Operation on Other Transports
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 this document. Because there might not be provisions to scope of this document. Because there might not be other provisions
exchange client and server certificates, authentication material to exchange client and server certificates, authentication material
could be provided by facilites within a future RPC-over-RDMA exchange would need to be provided by facilities within a future RPC-
transport. over-RDMA transport.
Transports that provide intrinsic TLS-level security (e.g., QUIC) Transports that provide intrinsic TLS-level security (e.g., QUIC)
would need to be accommodated separately from the current document. would need to be addressed separately from the current document. In
In such cases, use of TLS might not be opportunitic as it is for TCP such cases, the use of TLS would not be opportunistic as it is for
or UDP. TCP or UDP.
5.2. TLS Peer Authentication 5.2. TLS Peer Authentication
Peer authentication can be performed by TLS using any of the TLS can perform peer authentication using any of the following
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, an RPC peer is uniquely identified by the tuple (serial number mode, the tuple (serial number of the presented certificate; Issuer)
of presented certificate;Issuer). uniquely identifies the RPC peer.
o Implementations MUST allow the configuration of a list of trusted o Implementations MUST allow the configuration of a list of trusted
Certification Authorities for incoming connections. Certification Authorities for incoming connections.
o Certificate validation MUST include the verification rules as per o Certificate validation MUST include the verification rules as per
[RFC5280]. [RFC5280].
o Implementations SHOULD indicate their trusted Certification o Implementations SHOULD indicate their trusted Certification
Authorities (CAs). Authorities (CAs).
skipping to change at page 10, line 49 skipping to change at page 10, line 43
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 trust model can be implemented administrator as possible so that the administrator can implement the
by the administrator. As a suggestion, at least the following trust model. As a suggestion, at least the following parameters of
parameters of the X.509 client certificate SHOULD be exposed: the X.509 client certificate SHOULD be exposed:
o Originating IP address o Originating IP address
o Certificate Fingerprint o Certificate Fingerprint
o Issuer o Issuer
o Subject o Subject
o all X509v3 Extended Key Usage o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies o all X509v3 Certificate Policies
5.2.2. X.509 Certificates Using Fingerprints 5.2.2. X.509 Certificates Using Fingerprints
skipping to change at page 11, line 21 skipping to change at page 11, line 14
o Subject o Subject
o all X509v3 Extended Key Usage o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies o all X509v3 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, an RPC peer This mechanism is OPTIONAL to implement. In this mode, the
is uniquely identified by the fingerprint of the presented fingerprint of the presented certificate uniquely identifies the RPC
certificate. peer.
Implementations SHOULD allow the configuration of a list of trusted Implementations SHOULD allow the configuration of a list of trusted
certificates, identified via fingerprint of the DER encoded certificates, identified via fingerprint of the DER-encoded
certificate octets. Implementations MUST support SHA-256 or newer as certificate octets. Implementations MUST support SHA-256
the hash algorithm for the fingerprint. [FIPS.180-4] or stronger as the hash algorithm for the fingerprint.
5.2.3. Pre-Shared Keys 5.2.3. Pre-Shared Keys
This mechanism is OPTIONAL to implement. In this mode, an RPC peer This mechanism is OPTIONAL to implement. In this mode, the RPC peer
is uniquely identified by key material that has been shared out-of- is uniquely identified by keying material that has been shared out-
band or by a previous TLS-protected connection (see [RFC8446] of-band or by a previous TLS-protected connection (see Section 2.2 of
Section 2.2). At least the following parameters of the TLS [RFC8446]). At least the following parameters of the TLS connection
connection SHOULD be exposed: SHOULD be exposed:
o Originating IP address o Originating IP address
o TLS Identifier o TLS Identifier
5.2.4. Token Binding 5.2.4. Token Binding
This mechanism is OPTIONAL to implement. In this mode, an RPC peer This mechanism is OPTIONAL to implement. In this mode, a token
is uniquely identified by a token. uniquely identifies the RPC peer.
Versions of TLS subsequent to TLS 1.2 feature a token binding Versions of TLS after TLS 1.2 contain a token binding mechanism that
mechanism which is nominally more secure than using certificates. is more secure than using certificates. This mechanism is detailed
This is discussed in further detail in [RFC8471]. in [RFC8471].
6. Implementation Status 6. Implementation Status
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.
skipping to change at page 13, line 14 skipping to change at page 13, line 5
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 this Maturity: Prototype software based on early versions of this
document. document.
Coverage: The bulk of this specification is implemented. The use of Coverage: The bulk of this specification has yet to be implemented.
DTLS functionality is not implemented. The use of DTLS functionality is not planned.
Licensing: GPLv2 Licensing: GPLv2
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
7. Security Considerations 7. Security Considerations
One purpose of the mechanism described in this document is to protect One purpose of the mechanism described in the current document is to
RPC-based applications against threats to the privacy of RPC protect RPC-based applications against threats to the privacy of RPC
transactions and RPC user identities. A taxonomy of these threats transactions and RPC user identities. A taxonomy of these threats
appears in Section 5 of [RFC6973]. In addition, Section 6 of appears in Section 5 of [RFC6973]. Also, Section 6 of [RFC7525]
[RFC7525] contains a detailed discussion of technologies used in contains a detailed discussion of technologies used in conjunction
conjunction with TLS. Implementers should familiarize themselves with TLS. Implementers should familiarize themselves with these
with these materials. materials.
7.1. Limitations of an Opportunistic Approach 7.1. Limitations of an Opportunistic Approach
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 a policy and actual security level may indeed be selected based on policy and
without user intervention. without user intervention.
In cases where interoperability is a priority, the security benefits In cases where interoperability is a priority, the security benefits
of TLS are partially or entirely waived. Implementations of the of TLS are partially or entirely waived. Implementations of the
mechanism described in this document must take care to accurately mechanism described in the current document must take care to
represent to all RPC consumers the level of security that is actually accurately represent to all RPC consumers the level of security that
in effect. In addition, implementations are REQUIRED to provide an is actually in effect. Implementations are REQUIRED to provide an
audit log of RPC-over-TLS security mode selection. audit log of RPC-over-TLS security mode selection.
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 o A TLSA record [RFC6698] can alert clients that TLS is expected to
work, and provides a binding of hostname to x.509 identity. If work, and provide a binding of hostname to x.509 identity. If TLS
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 be configured to require that a TLS o Client security policy can require that a TLS session is
session is established on every connection. If an attacker spoofs established on every connection. If an attacker spoofs the
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.2. Multiple User Identity Realms 7.2. TLS Identity Management on Clients
To maintain the privacy of RPC users on a single client belonging to The goal of the RPC-on-TLS protocol extension is to hide the content
multiple distinct security realms, the client MUST establish an of RPC requests while they are in transit. The RPC-on-TLS protocol
independent TLS session for each user identity domain, each using a by itself cannot protect against exposure of a user's RPC requests to
distinct globally unique identity. The purpose of this separation is other users on the same client.
to prevent even privileged users in each security realm from
monitoring RPC traffic emitted on behalf of users in other security Moreover, client implementations are free to transmit RPC requests
realms on the same peer. for more than one RPC user using the same TLS session. Depending on
the details of the client RPC implementation, this means that the
client's TLS identity material is potentially visible to every RPC
user that shares a TLS session. Privileged users may also be able to
access this TLS identity.
As a result, client implementations need to carefully segregate TLS
identity material so that local access to it is restricted to only
the local users that are authorized to perform operations on the
remote RPC server.
7.3. Security Considerations for AUTH_SYS on TLS 7.3. Security Considerations for AUTH_SYS on TLS
The use of a TLS-protected transport when the AUTH_SYS authentication Using a TLS-protected transport when the AUTH_SYS authentication
flavor is in use addresses a number of longstanding weaknesses (as flavor is in use addresses several longstanding weaknesses (as
detailed in Appendix A). TLS augments AUTH_SYS by providing both detailed in Appendix A). TLS augments AUTH_SYS by providing both
integrity protection and a privacy service that AUTH_SYS lacks. This integrity protection and a privacy service that AUTH_SYS lacks. TLS
protects data payloads, RPC headers, and user identities against protects data payloads, RPC headers, and user identities against
monitoring or alteration while in transit. TLS guards against the monitoring and alteration while in transit. TLS guards against the
insertion or deletion of messages, thus also ensuring the integrity insertion or deletion of messages, thus also ensuring the integrity
of the message stream between RPC client and server. of the message stream between RPC client and server. Lastly,
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 is with TLS, but the RPC client is unauthenticated, the RPC server still
still acting 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.
This is an improvement from AUTH_SYS without encryption, but it TLS without authentication is an improvement from AUTH_SYS without
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, it is RECOMMENDED that when AUTH_SYS is used,
RPC clients present authentication material necessary for RPC servers every RPC client should present host authentication material to RPC
they contact to have a degree of trust that the clients are acting servers to prove that the client is a known one. The server can then
responsibly. determine whether the UIDs and GIDs in AUTH_SYS requests from that
client can be accepted.
The use of TLS does not enable detection of compromise on RPC clients The use of TLS does not enable RPC clients to detect compromise that
that leads to impersonation of RPC users. In addition, there leads to the impersonation of RPC users. Also, there continues to be
continues to be a requirement that the mapping of 32-bit user and a requirement that the mapping of 32-bit user and group ID values to
group ID values to user identities is the same on both the RPC client user identities is the same on both the RPC client and server.
and server.
7.4. Best Security Policy Practices 7.4. Best Security Policy Practices
To achieve the strongest possible security with RPC-over-TLS, RPC- RPC-over-TLS implementations and deployments are strongly encouraged
over-TLS implementations and deployments are strongly encouraged to to adhere to the following policies to achieve the strongest possible
adhere to these policies: security with RPC-over-TLS.
When using AUTH_NULL or AUTH_SYS: o When using AUTH_NULL or AUTH_SYS, both peers are required to have
Both peers are required to have DNS TLSA records and certificate DNS TLSA records and certificate material, and a policy that
material; a policy that requires mutual peer authentication and requires mutual peer authentication and rejection of a connection
rejection of a connection when host authentication fails. when host authentication fails.
When using RPCSEC_GSS: o When using RPCSEC_GSS, GSS/Kerberos provides adequate host
GSS/Kerberos provides adequate host authentication already; a authentication and a policy that requires GSS mutual
policy that requires GSS mutual authentication and rejection of a authentication and rejection of a connection when host
connection when host authentication fails. GSS integrity and authentication fails. GSS integrity and privacy services,
privacy services should be disabled in favor of TLS encryption therefore, can be disabled in favor of TLS encryption with peer
without peer authentication. authentication.
8. IANA Considerations 8. IANA Considerations
In accordance with Section 6 of [RFC7301], the authors request that Following Section 6 of [RFC7301], the authors request the allocation
IANA allocate the following value in the "Application-Layer Protocol of the following value in the "Application-Layer Protocol Negotiation
Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC
identifies SunRPC when used over TLS. when used over TLS.
Protocol: Protocol:
SunRPC SunRPC
Identification Sequence: Identification Sequence:
0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc")
Reference: Reference:
RFC-TBD RFC-TBD
skipping to change at page 16, line 4 skipping to change at page 16, line 6
Protocol: Protocol:
SunRPC SunRPC
Identification Sequence: Identification Sequence:
0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc")
Reference: Reference:
RFC-TBD RFC-TBD
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS.180-4]
National Institute of Standards and Technology, "Secure
Hash Standard, Federal Information Processing Standards
Publication FIPS PUB 180-4", FIPS PUB 180-4, August 2015.
[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 17, line 20 skipping to change at page 17, line 24
[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>.
9.2. Informative References 9.2. Informative References
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813,
DOI 10.17487/RFC1813, June 1995,
<https://www.rfc-editor.org/info/rfc1813>.
[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>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>.
[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>.
skipping to change at page 18, line 11 skipping to change at page 18, line 5
[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>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR)
Description", RFC 7863, DOI 10.17487/RFC7863, November
2016, <https://www.rfc-editor.org/info/rfc7863>.
[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 9.3. URIs
[1] https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls [1] 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 modes The ONC RPC protocol, as specified in [RFC5531], provides several
of security, traditionally referred to as "authentication flavors", modes of security, traditionally referred to as "authentication
though some of these flavors provide much more than an authentication flavors". Some of these flavors provide much more than an
service. We will refer to these as authentication flavors, security authentication service. We refer to these as authentication flavors,
flavors, or simply, flavors. One of the earliest and most basic security flavors, or simply, flavors. One of the earliest and most
flavor is AUTH_SYS, also known as AUTH_UNIX. AUTH_SYS is currently basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of
specified in Appendix A of [RFC5531]. [RFC5531] specifies AUTH_SYS.
AUTH_SYS assumes that both the RPC client and server use POSIX-style AUTH_SYS assumes that the RPC client and server both use POSIX-style
user and group identifiers (each user and group can be distinctly user and group identifiers (each user and group can be distinctly
represented as a 32-bit unsigned integer), and that both client and represented as a 32-bit unsigned integer). It also assumes that the
server use the same mapping of user and group to integer. One user client and server both use the same mapping of user and group to an
ID, one main group ID, and up to 16 supplemental group IDs are integer. One user ID, one primary group ID, and up to 16
associated with each RPC request. The combination of these identify supplemental group IDs are associated with each RPC request. The
the entity on the client that is making the request. combination of these identifies the entity on the client that is
making the request.
Peers are identified by a string in each RPC request. RFC 5531 does A string identifies peers (hosts) in each RPC request. [RFC5531]
not specify any requirements for this string other than that is no does not specify any requirements for this string other than that is
longer than 255 octets. It does not have to be the same from request no longer than 255 octets. It does not have to be the same from
to request, nor does it have to match the name of the sending host. request to request. Also, it does not have to match the DNS hostname
For these reasons, though most implementations do fill in their of the sending host. For these reasons, even though most
hostname in this field, receivers typically ignore its content. implementations fill in their hostname in this field, receivers
typically ignore its content.
RFC 5531 Appendix A 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 offers little It should be clear, therefore, that AUTH_SYS by itself offers little
to no communication security: to no communication security:
1. It does not protect the privacy or integrity of RPC requests, 1. It does not protect the privacy or integrity of RPC requests,
users, or payloads, relying instead on "external" security. users, or payloads, relying instead on "external" security.
2. It also does not provide actual authentication of RPC peer 2. It does not provide authentication of RPC peer machines, other
machines, other than 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 simple data types are not signed or is problematic because these data types are not cryptographically
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 offer 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" [1]. His article inspired the mechanism described with Stunnel TLS" [1]. His article inspired the mechanism described
in this document. in this document.
Many thanks to Tigran Mkrtchyan for his work on the DESY prototype Many thanks to Tigran Mkrtchyan for his work on the DESY prototype
and resulting feedback to this document. and his 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
the security of this simple mechanism and the security-related this simple mechanism and the current document's security-related
discussion in this document. discussion.
The authors are grateful to Bill Baker, David Black, Alan DeKok, Lars The authors are grateful to Bill Baker, David Black, Alan DeKok, Lars
Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg Marsden, Alex Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg Marsden, Alex
McDonald, David Noveck, Justin Mazzola Paluska, Tom Talpey, and McDonald, David Noveck, Justin Mazzola Paluska, Tom Talpey, and
Martin Thomson for their input and support of this work. Martin Thomson for their input and support of this work.
Lastly, special thanks go to Transport Area Director Magnus Lastly, special thanks go to Transport Area Director Magnus
Westerlund, NFSV4 Working Group Chairs Spencer Shepler and Brian Westerlund, NFSV4 Working Group Chairs David Noveck, Spencer Shepler,
Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes
guidance and oversight. for 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
 End of changes. 95 change blocks. 
285 lines changed or deleted 278 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/