draft-ietf-nfsv4-rpc-tls-01.txt   draft-ietf-nfsv4-rpc-tls-02.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: October 17, 2019 April 15, 2019 Expires: October 27, 2019 April 25, 2019
Remote Procedure Call Encryption By Default Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-01 draft-ietf-nfsv4-rpc-tls-02
Abstract Abstract
This document describes a mechanism that opportunistically enables This document describes a mechanism that, through the use of
encryption of in-transit Remote Procedure Call (RPC) transactions opportunistic Transport Layer Security (TLS), enables encryption of
with minimal administrative overhead and full interoperation with ONC in-transit Remote Procedure Call (RPC) transactions while
RPC implementations that do not support this mechanism. This interoperating with ONC RPC implementations that do not support this
document updates RFC 5531. mechanism. This 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 October 17, 2019. This Internet-Draft will expire on October 27, 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 23 skipping to change at page 2, line 23
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 7 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8
5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Connection Types . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 8 5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 9
5.1.3. Operation on an RDMA Transport . . . . . . . . . . . 9 5.1.3. Operation on an RDMA Transport . . . . . . . . . . . 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 . . . . . . . . . 9
5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 10 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 11
5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 11
6.1. Linux NFS server and client . . . . . . . . . . . . . . . 11 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 12
6.2. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 11 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 12
7.1. Implications for AUTH_SYS . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Limitations of an Opportunistic Approach . . . . . . . . 13
7.2. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . . . 13 7.2. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.3. Implications for AUTH_SYS . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Multiple User Identity Realms . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 4, line 38 skipping to change at page 4, line 40
implementation will be available to offload encryption and implementation will be available to offload encryption and
decryption. A single key protects all messages associated with decryption. A single key protects all messages associated with
one TLS session. one TLS session.
Securing AUTH_SYS Securing AUTH_SYS
Most critically, several security issues inherent in the current Most critically, several security issues inherent in the current
widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs
generated by an unauthenticated client) can be significantly generated by an unauthenticated client) can be significantly
ameliorated. ameliorated.
This document proposes the use of TLS to introduce an opportunistic
security approach, as defined by [RFC7435], to RPC. As long as there
is still a significant fleet of RPC deployments that lack support for
TLS, an opportunistic approach can help eliminate the challenges that
prevent the broad use of encryption with RPC (and its most popular
consumer, NFS) until a more thorough approach can be provided.
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 5, line 14 skipping to change at page 5, line 23
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.
We cleave to the convention that a "client" is a network host that We cleave 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". TLS documentation connecting host as "machine authentication" or "host authentication".
refers to the same as "peer authentication". In this document there TLS documentation refers to the same as "peer authentication". In
is little distinction. this 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 RPC users; i.e., the process owner of the application which is to the RPC caller's credential, provided in the "cred" and "verf"
using RPC. 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
skipping to change at page 7, line 15 skipping to change at page 7, line 27
4.2. Authentication 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.
Depending on its configuration, an RPC server MAY request a TLS Depending on its configuration, an RPC server MAY request a TLS peer
identity from each client upon first contact. This permits two identity from each client upon first contact. This permits two
different modes of deployment: different modes of deployment:
Server-only Host Authentication Server-only Host Authentication
A server possesses a unique global identity (e.g., a certificate A server possesses a unique global identity (e.g., a certificate
that is signed by a well-known trust anchor) while its clients are that is signed by a well-known trust anchor) while its clients are
anonymous (i.e., present no identifier). In this situation, the anonymous (i.e., present no identifier). In this situation, the
client SHOULD authenticate the server host using the presented TLS client SHOULD authenticate the server host using the presented TLS
identity, but the server cannot authenticate clients. identity, but the server cannot authenticate clients.
skipping to change at page 8, line 22 skipping to change at page 8, line 35
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 for confidentiality as well
as integrity protection is REQUIRED. Support for and negotiation as integrity protection is REQUIRED. Support for and negotiation
of compression is OPTIONAL. of compression is OPTIONAL.
5.1. Connection Types 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 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 After the TLS session is established, all traffic on the connection
alert, or by closing the underlying TCP socket. After TLS session is encapsulated and protected until the TLS session is terminated.
termination, any subsequent RPC request over the same socket MUST This includes reverse-direction operations (i.e., RPC requests
initiated on the server-end of the connection). A reverse-direction
operation sent on a connection outside of its existing TLS session
MUST fail with a reject_stat of AUTH_ERROR.
An RPC peer 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 connection MUST
fail with a reject_stat of AUTH_ERROR. 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
skipping to change at page 11, line 31 skipping to change at page 12, line 7
RFCs. RFCs.
Please note that the listing of any individual implementation here Please note that the listing of any individual implementation here
does not imply endorsement by the IETF. Furthermore, no effort has does not imply endorsement by the IETF. Furthermore, no effort has
been spent to verify the information presented here that was supplied been spent to verify the information presented here that was supplied
by IETF contributors. This is not intended as, and must not be by IETF contributors. This is not intended as, and must not be
construed to be, a catalog of available implementations or their construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
6.1. Linux NFS server and client 6.1. DESY NFS server
Organization: The Linux Foundation Organization: DESY
URL: https://www.kernel.org URL: https://desy.de
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 is implemented. The use of
DTLS functionality is not implemented. DTLS functionality is not implemented.
Licensing: GPLv2 Licensing: Freely distributable with acknowledgment.
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
6.2. DESY NFS server 6.2. Hammerspace NFS server
Organization: DESY Organization: Hammerspace
URL: https://hammerspace.com
URL: https://desy.de
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 is implemented. The use of
DTLS functionality is not implemented. DTLS functionality is not implemented.
Licensing: Freely distributable with acknowledgment. Licensing: Proprietary
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
6.3. Linux NFS server and client
Organization: The Linux Foundation
URL: https://www.kernel.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 implemented.
Licensing: GPLv2
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 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 7.1. Limitations of an Opportunistic Approach
client at the same time [RFC7862]. Typically that NFS client
implementation conserves connection resources by routing RPC
transactions from all of its users over a small number of
connections. In circumstances where the users on that NFS client
belong to multiple distinct security domains, the client MUST
establish independent TLS sessions for each distinct security domain.
7.1. Implications for AUTH_SYS A range of options is allowed by the opportunistic approach described
in this document, from "no peer authentication or encryption" to
"server-only authentication with encryption" to "mutual
authentication with encryption". The security level may indeed be
selected without user intervention based on a policy.
Implementations must take care to accurately represent to all RPC
consumers the level of security that is actually in effect.
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 Client security policy can be configured to require that a TLS
session is established on every connection. If an attacker spoofs
the handshake, the client disconnects and reports the problem.
This approach is RECOMMENDED.
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.
7.3. 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 rather than AUTH_SYS. For various reasons, AUTH_SYS RPCSEC GSS rather than AUTH_SYS. For various reasons, AUTH_SYS
continues to be the primary authentication mechanism deployed by NFS continues to be the primary authentication mechanism deployed by NFS
administrators. As a result, NFS security remains in an administrators. As a result, NFS security remains in 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
skipping to change at page 13, line 11 skipping to change at page 14, line 23
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 7.4. Multiple User Identity Realms
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 In circumstances where the RPC users on a single client belong to
work, and provides a binding of hostname to x.509 identity. If multiple distinct security realms, the client MUST establish an
TLS cannot be negotiated or authentication fails, the client independent TLS session for each user identity realm.
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 15, line 44 skipping to change at page 16, line 44
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>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/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 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>. March 2015, <https://www.rfc-editor.org/info/rfc7530>.
 End of changes. 31 change blocks. 
66 lines changed or deleted 112 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/