draft-ietf-nfsv4-rpc-tls-10.txt   draft-ietf-nfsv4-rpc-tls-11.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: 4 May 2021 31 October 2020 Expires: 27 May 2021 23 November 2020
Towards Remote Procedure Call Encryption By Default Towards Remote Procedure Call Encryption By Default
draft-ietf-nfsv4-rpc-tls-10 draft-ietf-nfsv4-rpc-tls-11
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 4 May 2021. This Internet-Draft will expire on 27 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
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 * GSS host identity management and user identity management
typically be enforced in the same security realm. However, cloud typically must be enforced in the same security realm. However,
providers, for instance, might prefer to remain authoritative for cloud providers, for instance, might prefer to remain
host identity but allow tenants to manage user identities within authoritative for host identity but allow tenants to manage user
their private networks. 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 8, line 13 skipping to change at page 8, line 13
of client deployment: of client deployment:
Server-only Host Authentication Server-only Host Authentication
In this type of deployment, the client can authenticate the server In this type of deployment, 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. In this situation, RPC-over-TLS cannot authenticate the client. In this situation, RPC-over-TLS
clients are anonymous. They present no globally unique identifier clients are anonymous. They present no globally unique identifier
to the server peer. to the server peer.
Mutual Host Authentication Mutual Host Authentication
In this type of deployment, the client possesses an identity (e.g. In this type of deployment, the client possesses an identity that
a certificate) that is backed by a trusted entity. As part of the is backed by a trusted entity (e.g. a pre-shared key or a
certificate validated with a certification path). As part of the
TLS handshake, both peers authenticate using the presented TLS TLS handshake, both peers authenticate using the presented TLS
identities. If authentication of either peer fails, or if identities. If authentication of either peer fails, or if
authorization based on those identities blocks access to the authorization based on those identities blocks access to the
server, the peers MUST reject the association. server, the peers MUST reject the association. Further
explanation appears in Section 5.2.
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. When a client presents a TLS the use of transport layer security. When a client presents a TLS
peer identity to an RPC server, the protocol extension described in peer identity to an RPC server, the protocol extension described in
the current document provides no way for the server to know whether the current document provides no way for the server to know whether
that identity represents one RPC user on that client, or is shared that identity represents one RPC user on that client, or is shared
amongst many RPC users. Therefore, a server implementation cannot amongst many RPC users. Therefore, a server implementation cannot
utilize the remote TLS peer identity to authenticate RPC users. utilize the remote TLS peer identity to authenticate RPC users.
4.2.1. Using TLS with RPCSEC GSS 4.2.1. Using TLS with RPCSEC GSS
skipping to change at page 9, line 20 skipping to change at page 9, line 25
TLS and RFC 7525 predates TLS v1.3, the cipher suite TLS and RFC 7525 predates TLS v1.3, the cipher suite
recommendations in RFC 7525 do not apply to RPC-over-(D)TLS. A recommendations in RFC 7525 do not apply to RPC-over-(D)TLS. A
strict TLS mode for RPC-over-TLS that protects against STRIPTLS strict TLS mode for RPC-over-TLS that protects against STRIPTLS
attacks is discussed in detail in Section 7.1.1. 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.
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
their "ClientHello" message and MUST include the protocol identifier their "ClientHello" message and MUST include the protocol identifier
defined in Section 8.2 in that message's ProtocolNameList value. defined in Section 8.2 in that message's ProtocolNameList value.
Similarly, in response to the "ClientHello" message, server Similarly, in response to the "ClientHello" message, server
implementations MUST include the implementations MUST include the
"application_layer_protocol_negotiation(16)" extension [RFC7301] in "application_layer_protocol_negotiation(16)" extension [RFC7301] in
their "ServerHello" message and MUST include only the protocol their "ServerHello" message and MUST include only the protocol
skipping to change at page 12, line 27 skipping to change at page 12, line 27
5.2.1. X.509 Certificates Using PKIX Trust 5.2.1. X.509 Certificates Using PKIX Trust
X.509 certificates are specified in [X.509]. [RFC5280] provides a X.509 certificates are specified in [X.509]. [RFC5280] provides a
profile of Internet PKI X.509 public key infrastructure. RPC-over- profile of Internet PKI X.509 public key infrastructure. RPC-over-
TLS implementations are REQUIRED to support the PKIX mechanism TLS implementations are REQUIRED to support the PKIX mechanism
described in [RFC5280]. described in [RFC5280].
The rules and guidelines defined in [RFC6125] apply to RPC-over-TLS The rules and guidelines defined in [RFC6125] apply to RPC-over-TLS
certificates with the following considerations: certificates with the following considerations:
* Support for the DNS-ID identifier type [RFC6125] is REQUIRED in * The DNS-ID identifier type is a subjectAltName extension that
RPC-over-TLS client and server implementations. Certification contains a dNSName, as defined in Section 4.2.1.6 of [RFC5280].
authorities that issue such certificates MUST support the DNS-ID Support for the DNS-ID identifier type is REQUIRED in RPC-over-TLS
identifier type. client and server implementations. Certification authorities that
issue such certificates MUST support the DNS-ID identifier type.
* DNS domain names in RPC-over-TLS certificates MUST NOT contain the * To specify the identity of an RPC peer as a domain name, the
wildcard character '*' within the identifier. certificate MUST contain a subjectAltName extension that contains
a dNSName. DNS domain names in RPC-over-TLS certificates MUST NOT
contain the wildcard character '*' within the identifier.
* To specify the identity of an RPC peer as a network identifier
(netid) or a universal network address (uaddr), the certificate
MUST contain a subjectAltName extension that contains an
iPAddress.
When validating a server certificate, an RPC-over-TLS client When validating a server certificate, an RPC-over-TLS client
implementation takes the following into account: implementation takes the following into account:
* Certificate validation MUST include the verification rules as per * Certificate validation MUST include the verification rules as per
Section 6 of [RFC5280] and Section 6 of [RFC6125]. Section 6 of [RFC5280] and Section 6 of [RFC6125].
* Server certificate validation MUST include a check on whether the * Server certificate validation MUST include a check on whether the
locally configured expected DNS-ID or iPAddress subjectAltName of locally configured expected DNS-ID or iPAddress subjectAltName of
the server that is contacted matches its presented certificate. the server that is contacted matches its presented certificate.
skipping to change at page 13, line 25 skipping to change at page 13, line 30
* The tuple (serial number of the presented certificate; Issuer) * The tuple (serial number of the presented certificate; Issuer)
uniquely identifies the RPC client. The meaning and syntax of uniquely identifies the RPC client. The meaning and syntax of
these fields is defined in Section 4 of [RFC5280]). these fields is defined in Section 4 of [RFC5280]).
RPC-over-TLS implementations MAY allow the configuration of a set of RPC-over-TLS implementations MAY allow the configuration of a set of
additional properties of the certificate to check for a peer's additional properties of the certificate to check for a peer's
authorization to communicate (e.g., a set of allowed values in authorization to communicate (e.g., a set of allowed values in
subjectAltName:URI, a set of allowed X.509v3 Certificate Policies, or subjectAltName:URI, a set of allowed X.509v3 Certificate Policies, or
a set of extended key usages). a set of extended key usages).
When the configured trust base changes (e.g., removal of a CA from When the configured set of trust anchors changes (e.g., removal of a
the list of trusted CAs; issuance of a new CRL for a given CA), CA from the list of trusted CAs; issuance of a new CRL for a given
implementations SHOULD reevaluate the certificate originally CA), implementations SHOULD reevaluate the certificate originally
presented in the context of the new configuration and terminate the presented in the context of the new configuration and terminate the
TLS session if the certificate is no longer trustworthy. TLS session if the certificate is no longer trustworthy.
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.
skipping to change at page 14, line 9 skipping to change at page 14, line 13
process RPC transactions. process RPC transactions.
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]). The PSK Identifier
parameter of the TLS connection SHOULD be exposed at the RPC layer: SHOULD be exposed at the RPC layer.
* PSK Identifier
6. Implementation Status 6. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
 End of changes. 11 change blocks. 
26 lines changed or deleted 33 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/