draft-ietf-nfsv4-rpc-tls-09.txt   draft-ietf-nfsv4-rpc-tls-10.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: 22 March 2021 18 September 2020 Expires: 4 May 2021 31 October 2020
Towards Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-09 draft-ietf-nfsv4-rpc-tls-10
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
Remote Procedure Call (RPC) transactions while they are in-transit. Remote Procedure Call (RPC) transactions while they are in-transit.
The proposed mechanism interoperates with ONC RPC implementations The proposed mechanism interoperates with ONC RPC implementations
that do not support it. This document updates RFC 5531. that do not support it. This document updates RFC 5531.
Note Note
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 22 March 2021. This Internet-Draft will expire on 4 May 2021.
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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 6 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5
4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 9 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Base Transport Considerations . . . . . . . . . . . . . . 9 5.1. Base Transport Considerations . . . . . . . . . . . . . . 9
5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 10 5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 10
5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10
5.1.3. Protected Operation on Other Transports . . . . . . . 11 5.1.3. Protected Operation on Other Transports . . . . . . . 11
5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 12 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 12
5.2.1. X.509 Certificates Using PKIX Trust . . . . . . . . . 12 5.2.1. X.509 Certificates Using PKIX Trust . . . . . . . . . 12
5.2.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 14 5.2.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 14
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14
6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 15 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 6 skipping to change at page 3, line 6
7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 17 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 17
7.1.2. Privacy Leakage Before Session Establishment . . . . 17 7.1.2. Privacy Leakage Before Session Establishment . . . . 17
7.2. TLS Identity Management on Clients . . . . . . . . . . . 18 7.2. TLS Identity Management on Clients . . . . . . . . . . . 18
7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 18 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 18
7.4. Best Security Policy Practices . . . . . . . . . . . . . 19 7.4. Best Security Policy Practices . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 19 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 19
8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 20 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 20
8.3. Object Identifier for PKIX Extended Key Usage . . . . . . 20 8.3. Object Identifier for PKIX Extended Key Usage . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Known Weaknesses of the AUTH_SYS Authentication Appendix A. Known Weaknesses of the AUTH_SYS Authentication
Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 23 Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
In 2014 the IETF published a document entitled "Pervasive Monitoring In 2014 the IETF published a document entitled "Pervasive Monitoring
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Moreover, the use of AUTH_SYS remains common despite the adverse Moreover, the use of AUTH_SYS remains common despite the adverse
effects that acceptance of UIDs and GIDs from unauthenticated clients effects that acceptance of UIDs and GIDs from unauthenticated clients
brings with it. Continued use is in part because: brings with it. Continued use is in part because:
* Per-client deployment and administrative costs for the only well- * Per-client deployment and administrative costs for the only well-
defined alternative to AUTH_SYS are expensive at scale. For defined alternative to AUTH_SYS are expensive at scale. For
instance, administrators must provide keying material for each RPC instance, administrators must provide keying material for each RPC
client, including transient clients. client, including transient clients.
* GSS host identity management and user identity management must be * GSS host identity management and user identity management must
enforced in the same security realm. In certain environments, typically be enforced in the same security realm. However, cloud
different authorities might be responsible for provisioning client providers, for instance, might prefer to remain authoritative for
systems versus provisioning new users. host identity but allow tenants to manage user identities within
their private networks.
In view of the challenges with the currently available mechanisms for In view of the challenges with the currently available mechanisms for
authenticating and protecting the confidentiality of RPC authenticating and protecting the confidentiality of RPC
transactions, this document specifies a transport-layer security transactions, this document specifies a transport-layer security
mechanism that complements the existing ones. The Transport Layer mechanism that complements the existing ones. The Transport Layer
Security [RFC8446] (TLS) and Datagram Transport Layer Security Security [RFC8446] (TLS) and Datagram Transport Layer Security
[I-D.ietf-tls-dtls13] (DTLS) protocols are a well-established [I-D.ietf-tls-dtls13] (DTLS) protocols are a well-established
Internet building blocks that protect many standard Internet Internet building blocks that protect many standard Internet
protocols such as the Hypertext Transport Protocol (HTTP) [RFC2818]. protocols such as the Hypertext Transport Protocol (HTTP) [RFC2818].
skipping to change at page 9, line 15 skipping to change at page 9, line 5
5. TLS Requirements 5. TLS Requirements
When peers negotiate a TLS session that is to transport RPC, the When peers negotiate a TLS session that is to transport RPC, the
following restrictions apply: following restrictions apply:
* Implementations MUST NOT negotiate TLS versions prior to v1.3 (for * Implementations MUST NOT negotiate TLS versions prior to v1.3 (for
TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively). TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively).
Support for mandatory-to-implement ciphersuites for the negotiated Support for mandatory-to-implement ciphersuites for the negotiated
TLS version is REQUIRED. TLS version is REQUIRED.
* Implementations MUST conform to the recommendations for TLS usage
specified in BCP 195 [RFC7525]. Although RFC 7525 permits the use
of TLS v1.2, the requirement to use TLS v1.3 or later for RPC-
over-TLS takes precedence. Further, because TLS v1.3 ciphers are
qualitatively different than cipher suites in previous versions of
TLS and RFC 7525 predates TLS v1.3, the cipher suite
recommendations in RFC 7525 do not apply to RPC-over-(D)TLS. A
strict TLS mode for RPC-over-TLS that protects against STRIPTLS
attacks is discussed in detail in Section 7.1.1.
* Implementations MUST support certificate-based mutual * Implementations MUST support certificate-based mutual
authentication. Support for PSK mutual authentication is authentication. Support for PSK mutual authentication is
OPTIONAL; see Section 5.2.2 for further details. OPTIONAL; see Section 5.2.2 for further details.
* Negotiation of a ciphersuite providing confidentiality as well as * 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.
Client implementations MUST include the Client implementations MUST include the
"application_layer_protocol_negotiation(16)" extension [RFC7301] in "application_layer_protocol_negotiation(16)" extension [RFC7301] in
skipping to change at page 10, line 10 skipping to change at page 10, line 10
and a destination port number. The use of TLS or DTLS does not and a destination port number. The use of TLS or DTLS does not
change that association. Thus it is frequently -- though not always change that association. Thus it is frequently -- though not always
-- the case that a single TLS session carries traffic for only one -- the case that a single TLS session carries traffic for only one
RPC program. RPC program.
5.1.1. Protected Operation on TCP 5.1.1. Protected Operation on TCP
The use of the Transport Layer Security (TLS) protocol [RFC8446] The use of the Transport Layer Security (TLS) protocol [RFC8446]
protects RPC on TCP connections. Typically, once an RPC client protects RPC on TCP connections. Typically, once an RPC client
completes the TCP handshake, it uses the mechanism described in completes the TCP handshake, it uses the mechanism described in
Section 4.1 to discover RPC-over-TLS support for that connection. Section 4.1 to discover RPC-over-TLS support for that RPC program on
Until an AUTH_TLS probe is done on a connection, the RPC server that connection. Until an AUTH_TLS probe is done on a connection,
treats all traffic as RPC messages. If spurious traffic appears on a the RPC server treats all traffic as RPC messages. If spurious
TCP connection between the initial clear-text AUTH_TLS probe and the traffic appears on a TCP connection between the initial clear-text
TLS session handshake, receivers MUST discard that data without AUTH_TLS probe and the TLS session handshake, receivers MUST discard
response and then SHOULD drop the connection. that data without response and then SHOULD drop the connection.
The protocol convention specified in the current document assumes The protocol convention specified in the current document assumes
there can be no more than one concurrent TLS session per TCP there can be no more than one concurrent TLS session per TCP
connection. This is true of current generations of TLS, but might be connection. This is true of current generations of TLS, but might be
different in a future version of TLS. different in a future version of TLS.
Once a TLS session is established on a TCP connection, no further Once a TLS session is established on a TCP connection, no further
clear-text communication can occur on that connection until the clear-text communication can occur on that connection until the
session is terminated. The use of TLS does not alter RPC record session is terminated. The use of TLS does not alter RPC record
framing used on TCP transports. framing used on TCP transports.
skipping to change at page 10, line 48 skipping to change at page 10, line 48
When operation is complete, an RPC peer terminates a TLS session by When operation is complete, an RPC peer terminates a TLS session by
sending a TLS Closure Alert. It may then close the TCP connection. sending a TLS Closure Alert. It may then close the TCP connection.
5.1.2. Protected Operation on UDP 5.1.2. Protected Operation on UDP
RFC Editor: In the following section, please replace TBD with the RFC Editor: In the following section, please replace TBD with the
connection_id extension number that is to be assigned in connection_id extension number that is to be assigned in
[I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's [I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's
Note before this document is published. Note before this document is published.
RPC over UDP is protected using the Datagram Transport Layer Security The use of the Datagram Transport Layer Security (DTLS) protocol
(DTLS) protocol [I-D.ietf-tls-dtls13]. [I-D.ietf-tls-dtls13] protects RPC carried in UDP datagrams. As soon
as a client initializes a UDP socket for use with an RPC service, it
uses the mechanism described in Section 4.1 to discover RPC-over-DTLS
support for that RPC program on that port. If spurious traffic
appears on a 5-tuple between the initial clear-text AUTH_TLS probe
and the DTLS association handshake, receivers MUST discard that
traffic without response.
Using DTLS does not introduce reliable or in-order semantics to RPC Using DTLS does not introduce reliable or in-order semantics to RPC
on UDP. The use of DTLS record replay protection is REQUIRED when on UDP. The use of DTLS record replay protection is REQUIRED when
transporting RPC traffic. transporting RPC traffic.
Each RPC message MUST fit in a single DTLS record. DTLS Each RPC message MUST fit in a single DTLS record. DTLS
encapsulation has overhead, which reduces the Packetization Layer encapsulation has overhead, which reduces the Packetization Layer
Path MTU (PLPMTU) and thus the maximum RPC payload size. A possible Path MTU (PLPMTU) and thus the maximum RPC payload size. A possible
PLPMTU discovery mechanism is offered in [RFC8899]. PLPMTU discovery mechanism is offered in [RFC8899].
As soon as a client initializes a UDP socket for use with an RPC
server, it uses the mechanism described in Section 4.1 to discover
DTLS support for an RPC program on a particular port. It then
negotiates a DTLS session.
The current document does not specify a mechanism that enables a The current document does not specify a mechanism that enables a
server to distinguish between DTLS traffic and unprotected RPC server to distinguish between DTLS traffic and unprotected RPC
traffic directed to the same port. To make this distinction, each traffic directed to the same port. To make this distinction, each
peer matches ingress datagrams that appear to be DTLS traffic to peer matches ingress datagrams that appear to be DTLS traffic to
existing DTLS session state. A peer treats any datagram that fails existing DTLS session state. A peer treats any datagram that fails
the matching process as an RPC message. the matching process as an RPC message.
Multi-homed RPC clients and servers may send protected RPC messages Multi-homed RPC clients and servers may send protected RPC messages
via network interfaces that were not involved in the handshake that via network interfaces that were not involved in the handshake that
established the DTLS session. Therefore, when protecting RPC established the DTLS session. Therefore, when protecting RPC
skipping to change at page 11, line 41 skipping to change at page 11, line 39
over-DTLS peer endpoints MUST provide a ConnectionID with a non-zero over-DTLS peer endpoints MUST provide a ConnectionID with a non-zero
length. Endpoints implementing RPC programs that expect a length. Endpoints implementing RPC programs that expect a
significant number of concurrent clients SHOULD employ ConnectionIDs significant number of concurrent clients SHOULD employ ConnectionIDs
of at least 4 bytes in length. of at least 4 bytes in length.
Sending a TLS Closure Alert terminates a DTLS session. Because Sending a TLS Closure Alert terminates a DTLS session. Because
neither DTLS nor UDP provide in-order delivery, after session closure neither DTLS nor UDP provide in-order delivery, after session closure
there can be ambiguity as to whether a datagram should be interpreted there can be ambiguity as to whether a datagram should be interpreted
as DTLS protected or not. Therefore receivers MUST discard datagrams as DTLS protected or not. Therefore receivers MUST discard datagrams
exchanged using the same 5-tuple that just terminated the DTLS exchanged using the same 5-tuple that just terminated the DTLS
session for 60 seconds. session for a sufficient length of time to ensure that
retransmissions have ceased and packets already in the network have
been delivered. In the absence of more specific data, a period of 60
seconds is expected to suffice.
5.1.3. Protected Operation on Other Transports 5.1.3. Protected Operation on Other Transports
Transports that provide intrinsic TLS-level security (e.g., QUIC) Transports that provide intrinsic TLS-level security (e.g., QUIC)
need to be addressed separately from the current document. In such need to be addressed separately from the current document. In such
cases, the use of TLS is not opportunistic as it can be for TCP or cases, the use of TLS is not opportunistic as it can be for TCP or
UDP. UDP.
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
skipping to change at page 13, line 35 skipping to change at page 13, line 41
5.2.1.1. Extended Key Usage Values 5.2.1.1. Extended Key Usage Values
Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509 Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509
certificate extension. This extension, which may appear in end- certificate extension. This extension, which may appear in end-
entity certificates, indicates one or more purposes for which the entity certificates, indicates one or more purposes for which the
certified public key may be used in addition to or in place of the certified public key may be used in addition to or in place of the
basic purposes indicated in the key usage extension. basic purposes indicated in the key usage extension.
The current document defines two new KeyPurposeId values: one that The current document defines two new KeyPurposeId values: one that
identifies the RPC-over-TLS peer as an RPC client, and one that identifies the RPC-over-TLS peer as an RPC client, and one that
identifies the RPC-over-TLS peer as an RPC server. Additional identifies the RPC-over-TLS peer as an RPC server.
KeyPurposeId values related to RPC-over-TLS may be specified in
subsequent Standards Track documents.
The inclusion of the RPC server value (id-kp-rpcTLSServer) indicates The inclusion of the RPC server value (id-kp-rpcTLSServer) indicates
that the certificate has been issued for allowing the holder to that the certificate has been issued for allowing the holder to
process RPC transactions. Such a certificate is a Resource process RPC transactions.
Certificate and therefore MUST conform to the constraints specified
in [RFC6487].
The inclusion of the RPC client value (id-kp-rpcTLSClient) indicates The inclusion of the RPC client value (id-kp-rpcTLSClient) indicates
that the certificate has been issued for allowing the holder to that the certificate has been issued for allowing the holder to
request RPC transactions. request RPC transactions.
5.2.2. Pre-Shared Keys 5.2.2. Pre-Shared Keys
This mechanism is OPTIONAL to implement. In this mode, the RPC peer This mechanism is OPTIONAL to implement. In this mode, the RPC peer
can be uniquely identified by keying material that has been shared can be uniquely identified by keying material that has been shared
out-of-band (see Section 2.2 of [RFC8446]). At least the following out-of-band (see Section 2.2 of [RFC8446]). At least the following
skipping to change at page 17, line 22 skipping to change at page 17, line 22
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. Client though TLS support is not available on one or both peers. Client
implementers can choose from the following to mitigate STRIPTLS implementers can choose from the following to mitigate STRIPTLS
attacks: attacks:
* A TLSA record [RFC6698] can alert clients that TLS is expected to * A TLSA record [RFC6698] can alert clients that TLS is expected to
work, and provide a binding of hostname to X.509 identity. If TLS work, and provide a binding of hostname to X.509 identity. If TLS
cannot be negotiated or authentication fails, the client cannot be negotiated or authentication fails, the client
disconnects and reports the problem. disconnects and reports the problem. When an opportunistic
security policy is in place, a client SHOULD check for the
existence of a TLSA record for the target server before initiating
an RPC-over-TLS association.
* Client security policy can require that a TLS session is * Client security policy can require that a TLS session is
established on every connection. If an attacker spoofs the established on every connection. If an attacker spoofs the
handshake, the client disconnects and reports the problem. This handshake, the client disconnects and reports the problem. This
policy prevents an attacker from causing the client to silently policy prevents an attacker from causing the client to silently
fall back to plaintext. If TLSA records are not available, this fall back to plaintext. If TLSA records are not available, this
approach is strongly encouraged. approach is strongly encouraged.
7.1.2. Privacy Leakage Before Session Establishment 7.1.2. Privacy Leakage Before Session Establishment
As mentioned earlier, communication between an RPC client and server As mentioned earlier, communication between an RPC client and server
appears in the clear on the network prior to the establishment of a appears in the clear on the network prior to the establishment of a
TLS session. This clear-text information usually includes transport TLS session. This clear-text information usually includes transport
connection handshake exchanges, the RPC NULL procedure probing connection handshake exchanges, the RPC NULL procedure probing
support for TLS, and the initial parts of TLS session establishment. support for TLS, and the initial parts of TLS session establishment.
Appendix C of [RFC8446] discusses precautions that can mitigate Appendix C of [RFC8446] discusses precautions that can mitigate
exposure during the exchange of connection handshake information and exposure during the exchange of connection handshake information and
TLS certificate material that might enable attackers to track the RPC TLS certificate material that might enable attackers to track the RPC
client. client. Note that when PSK authentication is used, the PSK
identifier is exposed during the TLS handshake, and can be used to
track the RPC client.
Any RPC traffic that appears on the network before a TLS session has Any RPC traffic that appears on the network before a TLS session has
been established is vulnerable to monitoring or undetected been established is vulnerable to monitoring or undetected
modification. A secure client implementation limits or prevents any modification. A secure client implementation limits or prevents any
RPC exchanges that are not protected. RPC exchanges that are not protected.
The exception to this edict is the initial RPC NULL procedure that The exception to this edict is the initial RPC NULL procedure that
acts as a STARTTLS message, which cannot be protected. This RPC NULL acts as a STARTTLS message, which cannot be protected. This RPC NULL
procedure contains no arguments or results, and the AUTH_TLS procedure contains no arguments or results, and the AUTH_TLS
authentication flavor it uses does not contain user information, so authentication flavor it uses does not contain user information, so
skipping to change at page 19, line 48 skipping to change at page 20, line 4
8.1. RPC Authentication Flavor 8.1. RPC Authentication Flavor
Following Appendix B of [RFC5531], the authors request a single new Following Appendix B of [RFC5531], the authors request a single new
entry in the RPC Authentication Flavor Numbers registry. The purpose entry in the RPC Authentication Flavor Numbers registry. The purpose
of the new authentication flavor is to signal the use of TLS with of the new authentication flavor is to signal the use of TLS with
RPC. This new flavor is not a pseudo-flavor. RPC. This new flavor is not a pseudo-flavor.
The fields in the new entry are assigned as follows: The fields in the new entry are assigned as follows:
Identifier String: AUTH_TLS Identifier String: AUTH_TLS
Flavor Name: TLS Flavor Name: TLS
Value: 7 Value: 7 (to be confirmed by IANA)
Description: Indicates support for RPC-over-TLS. Description: Indicates support for RPC-over-TLS.
Reference: RFC-TBD Reference: RFC-TBD
8.2. ALPN Identifier for SUNRPC 8.2. ALPN Identifier for SUNRPC
Following Section 6 of [RFC7301], the authors request the allocation Following Section 6 of [RFC7301], the authors request the allocation
of the following value in the "Application-Layer Protocol Negotiation of the following value in the "Application-Layer Protocol Negotiation
(ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC
when used over TLS. when used over TLS.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
May 2009, <https://www.rfc-editor.org/info/rfc5531>. May 2009, <https://www.rfc-editor.org/info/rfc5531>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 23, line 24 skipping to change at page 23, line 24
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
Memory Access Transport for Remote Procedure Call Version Memory Access Transport for Remote Procedure Call Version
1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
<https://www.rfc-editor.org/info/rfc8166>. <https://www.rfc-editor.org/info/rfc8166>.
[RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC- [RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC-
over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167, over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167,
June 2017, <https://www.rfc-editor.org/info/rfc8167>. June 2017, <https://www.rfc-editor.org/info/rfc8167>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
 End of changes. 21 change blocks. 
45 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/