draft-ietf-nfsv4-rpc-tls-05.txt   draft-ietf-nfsv4-rpc-tls-06.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: July 13, 2020 January 10, 2020 Expires: August 6, 2020 February 3, 2020
Towards Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-05 draft-ietf-nfsv4-rpc-tls-06
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 July 13, 2020. This Internet-Draft will expire on August 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/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 33 skipping to change at page 2, line 33
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5
4.1. Discovering Server-side TLS Support . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 10
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
6.4. FreeBSD 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 . . . . . . . . 14
7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 13 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 14
7.2. TLS Identity Management on Clients . . . . . . . . . . . 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 . . . . . . . 15
7.4. Best Security Policy Practices . . . . . . . . . . . . . 15 7.4. Best Security Policy Practices . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Known Weaknesses of the AUTH_SYS Authentication Appendix A. Known Weaknesses of the AUTH_SYS Authentication
Flavor . . . . . . . . . . . . . . . . . . . . . . . 18 Flavor . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
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 should It strongly recommended that newly defined Internet protocols should
make a genuine effort to mitigate monitoring attacks. Typically this make a genuine effort to mitigate monitoring attacks. Typically this
mitigation is done by encrypting data in transit. mitigation is done by encrypting data in transit.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
/* and more to be defined */ /* and more to be defined */
}; };
<CODE ENDS> <CODE ENDS>
The length of the opaque data constituting the credential sent in the The length of the opaque data constituting the credential sent in the
call message MUST be zero. The verifier accompanying the credential call message MUST be zero. The verifier accompanying the credential
MUST be an AUTH_NONE verifier of length zero. MUST be an AUTH_NONE verifier of length zero.
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 length of the verifier's body
encode the fixed ASCII characters "STARTTLS". field is eight. The bytes of the verifier's body field encode the
ASCII characters "STARTTLS" as a fixed-length opaque.
When an RPC client is ready to begin sending traffic to a server, it When an RPC client is ready to begin sending encrypted traffic to a
starts with a NULL RPC request with an auth_flavor of AUTH_TLS. The server, it starts with a NULL RPC request with an auth_flavor of
NULL request is made to the same port as if TLS were not in use. AUTH_TLS. The 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 recognize 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 "STARTTLS" token in
RPC client knows that this server does not support TLS. the NULL Reply, the 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 "STARTTLS" token in the NULL
client SHOULD send a STARTTLS. Reply, the RPC client immediately initiates a TLS session. This
NULL Reply signals that the RPC server is prepared for the client
to begin TLS session negotiation.
Once the TLS handshake is complete, the RPC client and server have Once the TLS handshake is complete, the RPC client and server 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, the RPC client reports this If TLS negotiation fails for any reason, the RPC client reports this
failure to the upper-layer application the same way it would report failure to the upper-layer 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.
non-encrypted RPC traffic or after a TLS session already in place,
the server MUST silently discard it.
4.2. Authentication 4.2. Authentication
Both RPC and TLS have peer and user authentication, with some overlap Both RPC and TLS have peer and user authentication, with some overlap
in capability between RPC and TLS. The goal of interoperability with in capability between RPC and TLS. The goal of interoperability with
implementations that do not support TLS requires limiting the implementations that do not support TLS requires limiting the
combinations that are allowed and precisely specifying the role that combinations that are allowed and precisely specifying the role that
each layer plays. We also want to handle TLS such that an RPC each layer plays. 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.
skipping to change at page 8, line 38 skipping to change at page 8, line 42
[RFC4279] is OPTIONAL. See Section 4.2 for further details. [RFC4279] is OPTIONAL. See Section 4.2 for further details.
o Negotiation of a ciphersuite providing confidentiality as well as o Negotiation of a ciphersuite providing confidentiality as well as
integrity protection is REQUIRED. Support for and negotiation of integrity protection is REQUIRED. Support for and negotiation of
compression is OPTIONAL. compression is OPTIONAL.
5.1. Base Transport Considerations 5.1. Base Transport Considerations
5.1.1. Operation on TCP 5.1.1. Operation on TCP
The use of TLS [RFC8446] protects RPC on TCP connections. As soon as The use of TLS [RFC8446] protects RPC on TCP connections. Typically,
a client completes the TCP handshake, it uses the mechanism described once a client completes the TCP handshake and performs RPC service
in [RFC8446]. to discover TLS support and then negotiate a TLS discovery via NULL RPC operations, it uses the mechanism described in
session. Section 4.1 to discover TLS support. It can then negotiate a TLS
session on that connection.
After establishing a TLS session, an RPC server MUST reject with a After establishing a TLS session, an RPC server MUST reject with a
reject_stat of AUTH_ERROR any subsequent RPC requests over the reject_stat of AUTH_ERROR any subsequent RPC requests over a TLS-
connection that are outside of a TLS session. Likewise, an RPC protected connection that are outside of a TLS session. Likewise, an
client MUST silently discard any subsequent RPC replies over the RPC client MUST silently discard any subsequent RPC replies over the
connection that are outside of a TLS session. connection that are outside of a TLS session.
This restriction includes reverse-direction operations (i.e., RPC This restriction includes reverse-direction RPC operations (i.e., RPC
calls initiated on the server-end of the connection). An RPC client calls initiated on the server-end of the connection). An RPC client
receiving a reverse-direction call on a connection outside of an 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. or by closing the TLS-protected TCP connection.
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
skipping to change at page 12, line 19 skipping to change at page 12, line 32
construed to be, a catalog of available implementations or their construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
6.1. DESY NFS server 6.1. DESY NFS server
Organization: DESY Organization: DESY
URL: https://desy.de URL: https://desy.de
Maturity: Prototype software based on early versions of this Maturity: Implementation will be based on mature versions of the
document. current document.
Coverage: The bulk of this specification is implemented. The use of Coverage: The implementation is under way. The use of DTLS
DTLS functionality is not implemented. functionality is not implemented.
Licensing: LGPL Licensing: LGPL
Implementation experience: No comments from implementors. Implementation experience: The implementer has read and commented on
the current document.
6.2. Hammerspace NFS server 6.2. Hammerspace NFS server
Organization: Hammerspace Organization: Hammerspace
URL: https://hammerspace.com URL: https://hammerspace.com
Maturity: Prototype software based on early versions of this Maturity: Prototype software based on early versions of this
document. document.
skipping to change at page 13, line 10 skipping to change at page 13, line 26
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 has yet to be implemented. Coverage: The bulk of this specification has yet to be implemented.
The use of DTLS functionality is not planned. The use of DTLS functionality is not planned.
Licensing: GPLv2 Licensing: GPLv2
Implementation experience: No comments from implementors. Implementation experience: No comments from the implementor.
6.4. FreeBSD NFS server and client
Organization: The FreeBSD Project
URL: https://www.freebsd.org
Maturity: Prototype software based on early versions of this
document.
Coverage: The bulk of this specification is implemented. The use of
DTLS functionality is not planned.
Licensing: BSD
Implementation experience: Implementers have read and commented on
this document.
7. Security Considerations 7. Security Considerations
One purpose of the mechanism described in the current document is to One purpose of the mechanism described in the current document is to
protect RPC-based applications against threats to the 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]. Also, Section 6 of [RFC7525] appears in Section 5 of [RFC6973]. Also, Section 6 of [RFC7525]
contains a detailed discussion of technologies used in conjunction contains a detailed discussion of technologies used in conjunction
with TLS. Implementers should familiarize themselves with these with TLS. Implementers should familiarize themselves with these
materials. materials.
skipping to change at page 19, line 41 skipping to change at page 20, line 33
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 his feedback on the current 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
this simple mechanism and the current document's security-related this simple mechanism and the current document's security-related
discussion. 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, Justin Mazzola Paluska, Tom Talpey, and Martin Thomson for
Martin Thomson for their input and support of this work. their input and support of this work.
Lastly, special thanks go to Transport Area Director Magnus Lastly, special thanks to document shepherd David Noveck, Transport
Westerlund, NFSV4 Working Group Chairs David Noveck, Spencer Shepler, Area Director Magnus Westerlund, NFSV4 Working Group Chairs Spencer
and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes Shepler and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas
for their guidance and oversight. Haynes 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. 25 change blocks. 
49 lines changed or deleted 71 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/