draft-ietf-nfsv4-rpc-tls-00.txt   draft-ietf-nfsv4-rpc-tls-01.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: September 26, 2019 March 25, 2019 Expires: October 17, 2019 April 15, 2019
Remote Procedure Call Encryption By Default Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-00 draft-ietf-nfsv4-rpc-tls-01
Abstract Abstract
This document describes a mechanism that enables encryption of in- This document describes a mechanism that opportunistically enables
transit Remote Procedure Call (RPC) transactions with minimal encryption of in-transit Remote Procedure Call (RPC) transactions
administrative overhead and full interoperation with ONC RPC with minimal administrative overhead and full interoperation with ONC
implementations that do not support this mechanism. This document RPC implementations that do not support this mechanism. This
updates RFC 5531. document updates RFC 5531.
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 September 26, 2019. This Internet-Draft will expire on October 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 4 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. RPC Authentication . . . . . . . . . . . . . . . . . . . 6 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Server-only Host Authentication . . . . . . . . . . . 6 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 7
4.2.2. Mutual Host Authentication . . . . . . . . . . . . . 7 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Advanced Forms of RPC Authentication . . . . . . . . 7
5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Connection Types . . . . . . . . . . . . . . . . . . . . 8 5.1. Connection Types . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8 5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8
5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 8 5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 8
5.1.3. Operation on an RDMA Transport . . . . . . . . . . . 8 5.1.3. Operation on an RDMA Transport . . . . . . . . . . . 9
5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 8 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 9
5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 8 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 9
5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 10 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 10
5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 10 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 10
5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 10 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 11
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
6.1. Linux NFS server and client . . . . . . . . . . . . . . . 11 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 11
6.2. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 11 6.2. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Implications for AUTH_SYS . . . . . . . . . . . . . . . . 12 7.1. Implications for AUTH_SYS . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.2. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 make a
real effort to mitigate monitoring attacks. Typically this real 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 antecedants).
Eisler et al. first introduced an in-transit encryption mechanism for Eisler et al. first introduced an in-transit encryption mechanism for
RPC with RPCSEC GSS over twenty years ago [RFC2203]. However, RPC with RPCSEC GSS over twenty years ago [RFC2203]. However,
experience has shown that RPCSEC GSS is difficult to deploy: experience has shown that RPCSEC GSS can be difficult to deploy:
o Per-client deployment and administrative costs are not scalable. o Per-client deployment and administrative costs are not scalable.
Keying material must be provided for each RPC client, including Keying material must be provided for each RPC client, including
transient clients. transient clients.
o Parts of the RPC header remain in clear-text, and can constitute a o Parts of each RPC header remain in clear-text, and can constitute
significant security exposure. a significant security exposure.
o On-host cryptographic manipulation of data payloads can exact a
significant CPU cost on both clients and the server.
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, carried out 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.
However strong a privacy service is, it can not provide any security o On-host cryptographic manipulation of data payloads can exact a
if the difficulties of deploying and using it result in it not being significant CPU and memory bandwidth cost on RPC peers. Offloadng
used at all. does not appear to be practical using GSS privacy since each
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 An alternative approach is to employ a transport layer security
mechanism that can protect the privacy of each RPC connection mechanism that can protect the privacy of each RPC connection
transparently to RPC and Upper Layer protocols. The Transport Layer transparently to RPC and Upper Layer protocols. The Transport Layer
Security protocol [RFC8446] (TLS) is a well-established Internet Security protocol [RFC8446] (TLS) is a well-established Internet
building block that protects many common Internet protocols such as building block that protects many common Internet protocols such as
the Hypertext Transport Protocol (http) [RFC2818]. the Hypertext Transport Protocol (http) [RFC2818].
Encrypting at the RPC transport layer enables several significant Encrypting at the RPC transport layer enables several significant
benefits. benefits.
Encryption By Default Encryption By Default
In-transit encryption can be enabled without additional In-transit encryption by itself may be enabled without additional
administrative actions such as identifying the host system to a administrative actions such as identifying client systems to a
trust authority, generating additional key material, or trust authority, generating additional key material, or
provisioning a secure network tunnel. provisioning a secure network tunnel.
Protection of Existing Protocols Protection of Existing Protocols
The imposition of encryption at the transport layer protects any The imposition of encryption at the transport layer protects any
Upper Layer protocol that employs RPC, without alteration of that Upper Layer protocol that employs RPC, without alteration of that
protocol. RPC transport layer encryption can protect recent protocol. RPC transport layer encryption can protect recent
versions of NFS such as NFS version 4.2 [RFC7862] and indeed versions of NFS such as NFS version 4.2 [RFC7862] and indeed
legacy NFS versions such as NFS version 3 [RFC1813] and NFS side- legacy NFS versions such as NFS version 3 [RFC1813], and NFS side-
band protocols such as the MNT protocol [RFC1813]. band protocols such as the MNT protocol [RFC1813].
Decoupled User and Host Identities Decoupled User and Host Identities
TLS can be used to authenticate hosts using certificates while TLS can be used to authenticate peer hosts while other security
other security mechanisms can handle user authentictation. mechanisms can handle user authentictation. Cryptographic
authentication of hosts can be provided while still using simpler
user authentication flavors such as AUTH_SYS.
Encryption Offload Encryption Offload
The use of a well-established transport encryption mechanism that Whereas hardware support for GSS privacy has not appeared in the
is also employed by other very common network protocols makes it marketplace, the use of a well-established transport encryption
likely that a hardware encryption implementation will be available mechanism that is also employed by other very common network
to offload encryption and decryption. protocols makes it likely that a hardware encryption
implementation will be available to offload encryption and
decryption. A single key protects all messages associated with
one TLS session.
Securing AUTH_SYS
Most critically, several security issues inherent in the current
widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs
generated by an unauthenticated client) can be significantly
ameliorated.
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 this document the two
terms are synonymous. terms are synonymous.
4. RPC-Over-TLS in Operation We cleave to the convention that a "client" is a network host that
actively initiates an association, and a "server" is a network host
that passively accepts an association request.
In this section we cleave to the convention that a "client" is the RPC documentation historically refers to the authentication of a
peer host that actively initiates a connection, and a "server" is the connecting host as "machine authentication". TLS documentation
peer host that passively accepts a connection request. refers to the same as "peer authentication". In this document there
is little distinction.
The term "user authentication" in this document refers specifically
to RPC users; i.e., the process owner of the application which is
using RPC.
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 is used to signal that the client wants to
initiate TLS negotiation if the server supports it. Except for the initiate TLS negotiation if the server supports it. Except for the
skipping to change at page 6, line 11 skipping to change at page 6, line 28
o If the RPC server does not recognise the AUTH_TLS authentication o If the RPC server does not recognise 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 proceed with TLS negotiation. client SHOULD send a STARTTLS.
If an RPC client attempts to use AUTH_TLS for anything other than the
NULL RPC procedure, the RPC server responds with a reject_stat of
AUTH_ERROR. In addition, a client MUST NOT attempt a TLS handshake
after the initial exchange.
Once the TLS handshake is complete, the RPC client and server will Once the TLS handshake is complete, the RPC client and server will
have established a secure channel for communicating and can proceed have established a secure channel for communicating. The client MUST
to use standard security flavors within that channel, presumably switch to a security flavor other than AUTH_TLS within that channel,
after negotiating down the irrelevant 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 -- say, the RPC server
rejects the certificate presented by the RPC client, or the RPC rejects the certificate presented by the RPC client, or the RPC
client fails to authenticate the RPC server -- the RPC client reports client fails to authenticate the RPC server -- the RPC client reports
this failure to the calling application the same way it would report 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.
4.2. RPC Authentication 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
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
negotiated, the server MUST silently discard it.
4.2. Authentication
Both RPC and TLS have their own variants of authentication, and there Both RPC and TLS have their own variants of authentication, and there
is some overlap in capability. The goal of interoperability with is some overlap in capability. The goal of interoperability with
implementations that do not support TLS requires that we limit the implementations that do not support TLS requires that we limit the
combinations that are allowed and precisely specify the role that combinations that are allowed and precisely specify 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.
Toward these ends, there are two deployment modes. Depending on its configuration, an RPC server MAY request a TLS
identity from each client upon first contact. This permits two
4.2.1. Server-only Host Authentication different modes of deployment:
In a basic deployment, a server possesses a unique global identity
(e.g., a certificate that is self-signed or signed by a well-known
trust anchor) while its clients are anonymous (i.e., present no
identifier). In this situation, the client SHOULD authenticate the
server host using the presented TLS identity, but the server cannot
authenticate connecting clients. Here, a TLS session is established
and the RPC requests in transit carry user and group identities
according to the conventions of the RPC protocol.
4.2.2. Mutual Host Authentication Server-only Host Authentication
A server possesses a unique global identity (e.g., a certificate
that is signed by a well-known trust anchor) while its clients are
anonymous (i.e., present no identifier). In this situation, the
client SHOULD authenticate the server host using the presented TLS
identity, but the server cannot authenticate clients.
In this type of deployment, both the server and its clients possess Mutual Host Authentication
unique identities (e.g., certificates). As part of the TLS In this type of deployment, both the server and its clients
handshake, both peer hosts SHOULD authenticate using the presented possess unique identities (e.g., certificates). As part of the
TLS identities. Should authentication of either peer fail, or should TLS handshake, both peers SHOULD authenticate using the presented
authorization based on those identities block access to the server, TLS identities. Should authentication of either peer fail, or
the connection MAY be rejected. However, once a TLS session is should authorization based on those identities block access to the
established, the server MUST NOT utilize TLS identity for the purpose server, the client association MAY be rejected.
of authorizing RPC requests.
In some cases, a client might choose to present a certificate that In either of these modes, RPC user authentication is not affected by
represents a user rather than one that is bound to the client host. the use of transport layer security. Once a TLS session is
As above, the server MUST NOT utilize this identity for the purpose established, the server MUST NOT utilize the client peer's TLS
of authorizing RPC requests. The TLS identities of the peer hosts identity for the purpose of authorizing individual RPC requests.
are fully independent of RPC user identities.
4.2.3. Advanced Forms of RPC Authentication 4.2.1. Using TLS with RPCSEC GSS
RPCSEC GSS can provide integrity or privacy (also known as RPCSEC GSS can provide per-request integrity or privacy (also known
confidentiality) services. When operating over a TLS session, these as confidentiality) services. When operating over a TLS session,
services become redundant. Each RPC implementation is responsible these services become redundant. Each RPC implementation is
for using channel binding for detecting when GSS integrity or privacy responsible for using channel binding for detecting when GSS
is unnecessary and can therefore be disabled. See Section 2.5 of integrity or privacy is unnecessary and can therefore be disabled.
[RFC7861] for details. See Section 2.5 of [RFC7861] for details.
Note that a GSS service principal is still required on the server, Note that a GSS service principal is still required on the server,
and mutual GSS authentication of server and client still occurs after and mutual GSS authentication of server and client still occurs after
the TLS session is established. the TLS session is established.
5. TLS Requirements 5. TLS Requirements
When a TLS session is negotiated for the purpose of transporting RPC, When a TLS session is negotiated for the purpose of transporting RPC,
the following restrictions apply: the following restrictions apply:
skipping to change at page 8, line 14 skipping to change at page 8, line 31
5.1. Connection Types 5.1. Connection Types
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 RPC over TCP is protected by using TLS [RFC8446]. As soon as a
client completes the TCP handshake, it uses the mechanism described client completes the TCP handshake, it uses the mechanism described
in Section 4.1 to discover TLS support and then negotiate a TLS in Section 4.1 to discover TLS support and then negotiate a TLS
session. session.
An RPC client terminates a TLS session by sending a TLS closure
alert, or by closing the underlying TCP socket. After TLS session
termination, any subsequent RPC request over the same socket MUST
fail 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. One RPC message fits in a single DTLS datagram.
DTLS encapsulation has overhead which reduces the effective Path MTU DTLS encapsulation has overhead which reduces the effective Path MTU
(PMTU) and thus the maximum RPC payload size. (PMTU) and thus the maximum RPC payload size.
DTLS does not detect STARTTLS replay. A DTLS session can be
terminated by sending a TLS closure alert. Subsequent RPC messages
passing between the client and server will no longer be protected
until a new TLS session is established.
5.1.3. Operation on an RDMA Transport 5.1.3. Operation on an RDMA Transport
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. scope of this document.
5.2. TLS Peer Authentication 5.2. TLS Peer Authentication
Peer authentication can be performed by TLS using any of the Peer authentication can be performed by TLS using any of the
following mechanisms: following 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 client is uniquely identified by the tuple (serial mode, an RPC peer is uniquely identified by the tuple (serial number
number of presented client certificate;Issuer). of presented certificate;Issuer).
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 9, line 28 skipping to change at page 10, line 5
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 X509v3 Certificate
Policies). Policies).
o When the configured trust base changes (e.g., removal of a CA from o 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.
Having identified 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 trust model can be implemented
by the administrator. As a suggestion, at least the following by the administrator. As a suggestion, at least the following
parameters of the X.509 client certificate should be exposed: parameters of the X.509 client certificate should be exposed:
o Originating IP address o Originating IP address
skipping to change at page 10, line 7 skipping to change at page 10, line 31
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 client This mechanism is OPTIONAL to implement. In this mode, an RPC peer
is uniquely identified by the fingerprint of the presented client is uniquely identified by the fingerprint of the presented
certificate. certificate.
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-1 as the hash certificate octets. Implementations MUST support SHA-1 as the hash
algorithm for the fingerprint. To prevent attacks based on hash algorithm for the fingerprint. To prevent attacks based on hash
collisions, support for a more contemporary hash function, such as collisions, support for a more contemporary hash function, such as
SHA-256, is RECOMMENDED. SHA-256, is RECOMMENDED.
5.2.3. Pre-Shared Keys 5.2.3. Pre-Shared Keys
This mechanism is OPTIONAL to implement. In this mode, an RPC client This mechanism is OPTIONAL to implement. In this mode, an RPC peer
is uniquely identified by its TLS identifier. At least the following is uniquely identified by key material that has been shared out-of-
parameters of the TLS connection should be exposed: band or by a previous TLS-protected connection (see [RFC8446]
Section 2.2). At least the following parameters of the TLS
connection 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 client This mechanism is OPTIONAL to implement. In this mode, an RPC peer
is uniquely identified by a token. is uniquely identified by a token.
Versions of TLS subsequent to TLS 1.2 feature a token binding Versions of TLS subsequent to TLS 1.2 feature a token binding
mechanism which is nominally more secure than using certificates. mechanism which is nominally more secure than using certificates.
This is discussed in further detail in [RFC8471]. This is discussed in further detail 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
skipping to change at page 11, line 48 skipping to change at page 12, line 25
One purpose of the mechanism described in this document is to protect One purpose of the mechanism described in this document is to protect
RPC-based applications against threats to the privacy of RPC 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]. In addition, Section 6 of
[RFC7525] contains a detailed discussion of technologies used in [RFC7525] contains a detailed discussion of technologies used in
conjunction with TLS. Implementers should familiarize themselves conjunction with TLS. Implementers should familiarize themselves
with these materials. with these materials.
The NFS version 4 protocol permits more than one user to use an NFS The NFS version 4 protocol permits more than one user to use an NFS
client at the same time [RFC7862]. Typically that NFS client will client at the same time [RFC7862]. Typically that NFS client
conserve connection resources by routing RPC transactions from all of implementation conserves connection resources by routing RPC
its users over a few or a single connection. In circumstances where transactions from all of its users over a small number of
the users on that NFS client belong to multiple distinct security connections. In circumstances where the users on that NFS client
domains, the client MUST establish independent TLS sessions for each belong to multiple distinct security domains, the client MUST
distinct security domain. establish independent TLS sessions for each distinct security domain.
7.1. Implications for AUTH_SYS 7.1. Implications for AUTH_SYS
Ever since the IETF NFSV4 Working Group took over the maintenance of Ever since the IETF NFSV4 Working Group took over the maintenance of
the NFSv4 family of protocols (currently specified in [RFC7530], the NFSv4 family of protocols (currently specified in [RFC7530],
[RFC5661], and [RFC7863], among others), it has encouraged the use of [RFC5661], and [RFC7863], among others), it has encouraged the use of
RPCSEC GSS over AUTH_SYS. For various reasons, unfortunately RPCSEC GSS rather than AUTH_SYS. For various reasons, AUTH_SYS
AUTH_SYS continues to be the primary authentication mechanism continues to be the primary authentication mechanism deployed by NFS
deployed by NFS administrators. As a result, NFS security remains in administrators. As a result, NFS security remains in an
an unsatisfactory state. unsatisfactory state.
A deeper purpose of this document is to attempt to address some of A deeper purpose of this document is to attempt to address some of
the shortcomings of AUTH_SYS so that, where it has been impractical the shortcomings of AUTH_SYS so that, where it has been impractical
to deploy RPCSEC GSS, better NFSv4 security can nevertheless be to deploy RPCSEC GSS, better NFSv4 security can nevertheless be
achieved. achieved.
When AUTH_SYS is used with TLS and no client certificate is When AUTH_SYS is used with TLS and no client certificate is
available, the RPC server is still acting on RPC requests for which available, the RPC server is still acting on RPC requests for which
there is no trustworthy authentication. In-transit traffic is there is no trustworthy authentication. In-transit traffic is
protected, but the client itself can still misrepresent user identity protected, but the client itself can still misrepresent user identity
without detection. This is an improvement from AUTH_SYS without without detection. This is an improvement from AUTH_SYS without
encryption, but it leaves a critical security exposure. encryption, but it leaves a critical security exposure.
Therefore, the RECOMMENDED deployment mode is that clients have Therefore, the RECOMMENDED deployment mode is that clients have
certificate material configured and used so that servers can have a certificate material configured and used so that servers can have a
degree of trust that clients are acting responsibly. degree of trust that clients are acting responsibly.
7.2. STRIPTLS Attacks
A classic form of attack on network protocols that initiate an
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
though TLS support is not available on one or both peers. Clients
implementers can choose from the following to mitigate STRIPTLS
attacks:
o Clients can be configured to require TLS encryption. If an
attacker spoofs the handshake, the client disconnects and reports
the problem.
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
TLS cannot be negotiated or authentication fails, the client
disconnects and reports the problem.
8. IANA Considerations 8. IANA Considerations
In accordance with Section 6 of [RFC7301], the authors request that In accordance with Section 6 of [RFC7301], the authors request that
IANA allocate the following value in the "Application-Layer Protocol IANA allocate the following value in the "Application-Layer Protocol
Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string
identifies SunRPC when used over TLS. identifies SunRPC when used over TLS.
Protocol: Protocol:
SunRPC SunRPC
skipping to change at page 14, line 38 skipping to change at page 15, line 33
[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., [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>. <https://www.rfc-editor.org/info/rfc5661>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
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>.
[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
skipping to change at page 15, line 34 skipping to change at page 16, line 34
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
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
and resulting feedback to this document.
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, Greg Marsden, Alex McDonald, Tigran Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg Marsden, Alex
Mkrtchyan, David Noveck, Justin Mazzola Paluska, and Tom Talpey for McDonald, David Noveck, Justin Mazzola Paluska, Tom Talpey, and
their input and support of this work. Martin Thomson for their input and support of this work.
Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 Lastly, special thanks go to Transport Area Director Magnus
Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Westerlund, NFSV4 Working Group Chairs Spencer Shepler and Brian
Working Group Secretary Thomas Haynes for their guidance and Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their
oversight. 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. 45 change blocks. 
116 lines changed or deleted 170 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/