draft-ietf-nfsv4-rpc-tls-03.txt   draft-ietf-nfsv4-rpc-tls-04.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: March 24, 2020 September 21, 2019 Expires: May 20, 2020 November 17, 2019
Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-03 draft-ietf-nfsv4-rpc-tls-04
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 March 24, 2020. This Internet-Draft will expire on May 20, 2020.
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 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 . . . . . . . . . 9 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 11 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . 12 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 13
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. Multiple User Identity Realms . . . . . . . . . . . . . . 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
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . 19 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 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.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
This document specifies the use of RPC on a TLS-protected transport This document specifies the use of RPC on a TLS-protected transport
in a fashion that is transparent to upper layer protocols based on in a fashion that is transparent to upper layer protocols based on
RPC. It provides policies in line with [RFC7435] that enable RPC-on- RPC. It provides policies in line with [RFC7435] that enable RPC-on-
TLS to be deployed opportunistically in environments with RPC TLS to be deployed opportunistically in environments with RPC
implementations that do not support TLS. Specifications for RPC- implementations that do not support TLS. Specifications for RPC-
based upper layer protocols are free to require stricter policies to based upper layer protocols are free to require stricter policies to
guarantee that TLS with encryption or TLS with host authentication guarantee that TLS with encryption or TLS with host authentication
and encryption is used for every connection. and encryption is used for every connection.
Note that the protocol specification in this document assumes that
support for RPC, TLS, PKI, GSS-API, and/or DNSSEC is already
available in an implementation where RPC-on-TLS 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
skipping to change at page 7, line 46 skipping to change at page 7, line 49
server peer. In this situation, the client can authenticate the server peer. In this situation, the client can authenticate the
server host using the presented server peer TLS identity, but the server host using the presented server peer TLS identity, but the
server cannot authenticate the client. server cannot authenticate the client.
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 client
association SHOULD be rejected. association MUST be rejected.
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. Once a TLS session is
established, the server MUST NOT utilize the client peer's TLS established, the server MUST NOT substitute RPC_AUTH_TLS, or the
identity for the purpose of authorizing individual RPC requests. remote identity used for TLS peer authentication, for existing forms
of per-request RPC user authentication specified by [RFC5531].
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,
these services become redundant. A TLS-capable RPC implementation these services become redundant. A TLS-capable RPC implementation
uses GSS channel binding for detecting when GSS integrity or privacy uses GSS channel binding for detecting when GSS integrity or privacy
is unnecessary and can therefore be avoided. See Section 2.5 of is unnecessary and can therefore be avoided. See Section 2.5 of
[RFC7861] for details. [RFC7861] for details.
skipping to change at page 10, line 45 skipping to change at page 10, line 51
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 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
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 20 skipping to change at page 11, line 27
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, an RPC peer
is uniquely identified by the fingerprint of the presented 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-256 or newer as
algorithm for the fingerprint. To prevent attacks based on hash the hash algorithm for the fingerprint.
collisions, support for a more contemporary hash function, such as
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 peer This mechanism is OPTIONAL to implement. In this mode, an RPC peer
is uniquely identified by key material that has been shared out-of- is uniquely identified by key material that has been shared out-of-
band or by a previous TLS-protected connection (see [RFC8446] band or by a previous TLS-protected connection (see [RFC8446]
Section 2.2). At least the following parameters of the TLS Section 2.2). At least the following parameters of the TLS
connection should be exposed: 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 peer This mechanism is OPTIONAL to implement. In this mode, an RPC peer
is uniquely identified by a token. is uniquely identified by a token.
skipping to change at page 13, line 26 skipping to change at page 13, line 33
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.
7.1. Limitations of an Opportunistic Approach 7.1. Limitations of an Opportunistic Approach
A range of options is allowed by the opportunistic approach described The purpose of using an explicitly opportunistic approach is to
in this document, from "no peer authentication or encryption" to enable interoperation with implementations that do not support RPC-
"server-only authentication with encryption" to "mutual over-TLS. A range of options is allowed by this approach, from "no
authentication with encryption". The security level may indeed be peer authentication or encryption" to "server-only authentication
selected without user intervention based on a policy. with encryption" to "mutual authentication with encryption". The
Implementations must take care to accurately represent to all RPC actual security level may indeed be selected based on a policy and
consumers the level of security that is actually in effect. without user intervention.
In cases where interoperability is a priority, the security benefits
of TLS are partially or entirely waived. Implementations of the
mechanism described in this document must take care to accurately
represent to all RPC consumers the level of security that is actually
in effect. In addition, implementations are REQUIRED to provide an
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:
skipping to change at page 15, line 5 skipping to change at page 15, line 13
RPC clients present authentication material necessary for RPC servers RPC clients present authentication material necessary for RPC servers
they contact to have a degree of trust that the clients are acting they contact to have a degree of trust that the clients are acting
responsibly. responsibly.
The use of TLS does not enable detection of compromise on RPC clients The use of TLS does not enable detection of compromise on RPC clients
that leads to impersonation of RPC users. In addition, there that leads to impersonation of RPC users. In addition, there
continues to be a requirement that the mapping of 32-bit user and continues to be a requirement that the mapping of 32-bit user and
group ID values to user identities is the same on both the RPC client group ID values to user identities is the same on both the RPC client
and server. and server.
7.4. Best Security Policy Practices
To achieve the strongest possible security with RPC-over-TLS, RPC-
over-TLS implementations and deployments are strongly encouraged to
adhere to these policies:
When using AUTH_NULL or AUTH_SYS:
Both peers are required to have DNS TLSA records and certificate
material; a policy that requires mutual peer authentication and
rejection of a connection when host authentication fails.
When using RPCSEC_GSS:
GSS/Kerberos provides adequate host authentication already; a
policy that requires GSS mutual authentication and rejection of a
connection when host authentication fails. GSS integrity and
privacy services should be disabled in favor of TLS encryption
without peer authentication.
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 19, line 24 skipping to change at page 20, line 5
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 resulting feedback to this document.
Thanks to Derrell Piper for numerous suggestions that improved both
the security of this simple mechanism and the security-related
discussion in 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, 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 Spencer Shepler and Brian
Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their
guidance and oversight. guidance and oversight.
 End of changes. 19 change blocks. 
26 lines changed or deleted 61 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/