idnits 2.17.1 draft-ietf-nfsv4-rpc-tls-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5531, updated by this document, for RFC5378 checks: 2003-05-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 30, 2020) is 1456 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 958 -- Looks like a reference, but probably isn't: '2' on line 960 -- Looks like a reference, but probably isn't: '3' on line 962 -- Looks like a reference, but probably isn't: '4' on line 964 -- Looks like a reference, but probably isn't: '5' on line 966 -- Looks like a reference, but probably isn't: '6' on line 1031 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-37 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 T. Myklebust 3 Internet-Draft Hammerspace 4 Updates: 5531 (if approved) C. Lever, Ed. 5 Intended status: Standards Track Oracle 6 Expires: November 1, 2020 April 30, 2020 8 Towards Remote Procedure Call Encryption By Default 9 draft-ietf-nfsv4-rpc-tls-07 11 Abstract 13 This document describes a mechanism that, through the use of 14 opportunistic Transport Layer Security (TLS), enables encryption of 15 in-transit Remote Procedure Call (RPC) transactions while 16 interoperating with ONC RPC implementations that do not support this 17 mechanism. This document updates RFC 5531. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 1, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 57 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6 58 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 59 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 60 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Base Transport Considerations . . . . . . . . . . . . . . 9 62 5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 9 63 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 9 64 5.1.3. Protected Operation on Other Transports . . . . . . . 10 65 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 11 66 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 11 67 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 12 68 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 12 69 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 13 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 71 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 13 72 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 14 73 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 14 74 6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7.1. Limitations of an Opportunistic Approach . . . . . . . . 15 77 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 15 78 7.1.2. Privacy Leakage Before Session Establishment . . . . 16 79 7.2. TLS Identity Management on Clients . . . . . . . . . . . 16 80 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 17 81 7.4. Best Security Policy Practices . . . . . . . . . . . . . 17 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 18 84 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 18 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 9.2. Informative References . . . . . . . . . . . . . . . . . 20 88 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 Appendix A. Known Weaknesses of the AUTH_SYS Authentication 90 Flavor . . . . . . . . . . . . . . . . . . . . . . . 21 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 RFC Editor: Please remove this Editor's Note and the following 97 paragraph before this document is published. 99 The source for this draft is maintained in GitHub. Suggested changes 100 should be submitted as pull requests at 101 https://github.com/chucklever/i-d-rpc-tls [1]. Instructions are on 102 that page as well. Editorial changes can be managed in GitHub, but 103 any substantive change should be discussed on the nfsv4@ietf.org 104 mailing list. 106 In 2014 the IETF published [RFC7258], which recognized that 107 unauthorized observation of network traffic had become widespread and 108 was a subversive threat to all who make use of the Internet at large. 109 It strongly recommended that newly defined Internet protocols should 110 make a genuine effort to mitigate monitoring attacks. Typically this 111 mitigation is done by encrypting data in transit. 113 The Remote Procedure Call version 2 protocol has been a Proposed 114 Standard for three decades (see [RFC5531] and its antecedents). Over 115 twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in- 116 transit encryption mechanism for RPC [RFC2203]. However, experience 117 has shown that RPCSEC GSS with in-transit encryption can be 118 challenging to use in practice: 120 o Parts of each RPC header remain in clear-text, constituting a 121 significant security exposure. 123 o Offloading the GSS privacy service is not practical in large 124 multi-user deployments since each message is encrypted using a key 125 based on the issuing RPC user. 127 However strong GSS-provided confidentiality is, it cannot provide any 128 security if the challenges of using it result in choosing not to 129 deploy it at all. 131 Moreover, the use of AUTH_SYS remains common despite the adverse 132 effects that acceptance of UIDs and GIDs from unauthenticated clients 133 brings with it. Continued use is in part because: 135 o Per-client deployment and administrative costs are not scalable. 136 Administrators must provide keying material for each RPC client, 137 including transient clients. 139 o Host identity management and user identity management must be 140 enforced in the same security realm. In certain environments, 141 different authorities might be responsible for provisioning client 142 systems versus provisioning new users. 144 The alternative described in the current document is to employ a 145 transport layer security mechanism that can protect the 146 confidentiality of each RPC connection transparently to RPC and 147 upper-layer protocols. The Transport Layer Security protocol 148 [RFC8446] (TLS) is a well-established Internet building block that 149 protects many standard Internet protocols such as the Hypertext 150 Transport Protocol (HTTP) [RFC2818]. 152 Encrypting at the RPC transport layer accords several significant 153 benefits: 155 Encryption By Default: Transport encryption can be enabled without 156 additional administrative tasks such as identifying client systems 157 to a trust authority, generating additional keying material, or 158 provisioning a secure network tunnel. 160 Encryption Offload: Hardware support for the GSS privacy service has 161 not appeared in the marketplace. However, the use of a well- 162 established transport encryption mechanism that is employed by 163 other ubiquitous network protocols makes it more likely that 164 encryption offload for RPC is practicable. 166 Securing AUTH_SYS: Most critically, transport encryption can 167 significantly reduce several security issues inherent in the 168 current widespread use of AUTH_SYS (i.e., acceptance of UIDs and 169 GIDs generated by an unauthenticated client). 171 Decoupled User and Host Identities: TLS can be used to authenticate 172 peer hosts while other security mechanisms can handle user 173 authentication. 175 The current document specifies the implementation of RPC on an 176 encrypted transport in a manner that is transparent to upper-layer 177 protocols based on RPC. The imposition of encryption at the 178 transport layer protects any upper-layer protocol that employs RPC, 179 without alteration of that protocol. 181 Further, Section 7 of the current document defines policies in line 182 with [RFC7435] which enable RPC-on-TLS to be deployed 183 opportunistically in environments that contain RPC implementations 184 that do not support TLS. However, specifications for RPC-based 185 upper-layer protocols should choose to require even stricter policies 186 that guarantee encryption and host authentication is used for all RPC 187 transactions. Enforcing the use of RPC-on-TLS is of particular 188 importance for existing upper-layer protocols whose security 189 infrastructure is weak. 191 The protocol specification in the current document assumes that 192 support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available 193 in an RPC implementation where TLS support is to be added. 195 2. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 3. Terminology 205 This document adopts the terminology introduced in Section 3 of 206 [RFC6973] and assumes a working knowledge of the Remote Procedure 207 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 208 Security (TLS) version 1.3 protocol [RFC8446]. 210 Note also that the NFS community long ago adopted the use of the term 211 "privacy" from documents such as [RFC2203]. In the current document, 212 the authors use the term "privacy" only when referring specifically 213 to the historic GSS privacy service defined in [RFC2203]. Otherwise, 214 the authors use the term "confidentiality", following the practices 215 of contemporary security communities. 217 We adhere to the convention that a "client" is a network host that 218 actively initiates an association, and a "server" is a network host 219 that passively accepts an association request. 221 RPC documentation historically refers to the authentication of a 222 connecting host as "machine authentication" or "host authentication". 223 TLS documentation refers to the same as "peer authentication". In 224 the current document there is little distinction between these terms. 226 The term "user authentication" in the current document refers 227 specifically to the RPC caller's credential, provided in the "cred" 228 and "verf" fields in each RPC Call. 230 4. RPC-Over-TLS in Operation 231 4.1. Discovering Server-side TLS Support 233 The mechanism described in the current document interoperates fully 234 with RPC implementations that do not support TLS. Policy settings on 235 the RPC-on-TLS-enabled peer determine whether RPC operation continues 236 without the use of TLS or RPC operation is not permitted. 238 To achieve this, we introduce a new RPC authentication flavor called 239 AUTH_TLS. This new flavor signals that the client wants to initiate 240 TLS negotiation if the server supports it. Except for the 241 modifications described in this section, the RPC protocol is unaware 242 of security encapsulation at the transport layer. 244 When an RPC client is ready to begin a TLS session, it sends a NULL 245 RPC procedure with an auth_flavor of AUTH_TLS. The value of AUTH_TLS 246 is defined in Section 8.1. The NULL request is made to the same port 247 as if TLS were not in use. 249 The length of the opaque data constituting the credential sent in the 250 RPC Call message MUST be zero. The verifier accompanying the 251 credential MUST be an AUTH_NONE verifier of length zero. 253 The flavor value of the verifier in the RPC Reply message received 254 from the server MUST be AUTH_NONE. The length of the verifier's body 255 field is eight. The bytes of the verifier's body field encode the 256 ASCII characters "STARTTLS" as a fixed-length opaque. 258 If the RPC server replies with a reply_stat of MSG_ACCEPTED and an 259 AUTH_NONE verifier containing the "STARTTLS" token, the RPC client 260 follows with a "ClientHello" message. The client MAY proceed with 261 TLS session establishment even if the Reply's accept_stat is not 262 SUCCESS (for example, if the accept_stat is PROG_UNAVAIL). Once the 263 TLS handshake is complete, the RPC client and server have established 264 a secure channel for communicating. 266 If the Reply's reply_stat is MSG_ACCEPTED but the verifier does not 267 contain the "STARTTLS" token, or if the Reply's reply_stat is 268 MSG_DENIED, the RPC client MUST NOT send a "ClientHello" message. 269 RPC operation can continue, however it will be without any 270 confidentiality, integrity or authentication protection from (D)TLS. 272 If, after a successful RPC AUTH_TLS probe, the subsequent TLS 273 handshake should fail for any reason, the RPC client reports this 274 failure to the upper-layer application the same way it reports an 275 AUTH_ERROR rejection from the RPC server. 277 If an RPC client uses the AUTH_TLS authentication flavor on any 278 procedure other than the NULL procedure, or an RPC client sends an 279 RPC AUTH_TLS probe within an existing TLS session, the RPC server 280 MUST reject that RPC Call by setting the reply_stat field to 281 MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat 282 field to AUTH_BADCRED. 284 4.2. Authentication 286 Both RPC and TLS have peer and user authentication, with some overlap 287 in capability between RPC and TLS. The goal of interoperability with 288 implementations that do not support TLS requires limiting the 289 combinations that are allowed and precisely specifying the role that 290 each layer plays. We also want to handle TLS such that an RPC 291 implementation can make the use of TLS invisible to existing RPC 292 consumer applications. 294 Each RPC server that supports RPC-over-TLS MUST possess a unique 295 global identity (e.g., a certificate that is signed by a well-known 296 trust anchor). Such an RPC server MUST request a TLS peer identity 297 from each client upon first contact. There are two different modes 298 of client deployment: 300 Server-only Host Authentication 301 In this type of deployment, the client can authenticate the server 302 host using the presented server peer TLS identity, but the server 303 cannot authenticate the client. In this situation, RPC-over-TLS 304 clients are anonymous. They present no globally unique identifier 305 to the server peer. 307 Mutual Host Authentication 308 In this type of deployment, the client possesses an identity (e.g. 309 a certificate) that is backed by a trusted entity. As part of the 310 TLS handshake, both peers authenticate using the presented TLS 311 identities. If authentication of either peer fails, or if 312 authorization based on those identities blocks access to the 313 server, the peers MUST reject the association. 315 In either of these modes, RPC user authentication is not affected by 316 the use of transport layer security. When a client presents a TLS 317 peer identity to an RPC server, the protocol extension described in 318 the current document provides no way for the server to know whether 319 that identity represents one RPC user on that client, or is shared 320 amongst many RPC users. Therefore, a server implementation must not 321 utilize the remote TLS peer identity for RPC user authentication. 323 4.2.1. Using TLS with RPCSEC GSS 325 To use GSS, an RPC server has to possess a GSS service principal. On 326 a TLS session, GSS mutual (peer) authentication occurs as usual, but 327 only after a TLS session has been established for communication. 328 Authentication of GSS users is unchanged by the use of TLS. 330 RPCSEC GSS can also perform per-request integrity or confidentiality 331 protection. When operating over a TLS session, these GSS services 332 become redundant. An RPC implementation capable of concurrently 333 using TLS and RPCSEC GSS can use GSS channel binding, as defined in 334 [RFC5056], to determine when an underlying transport provides a 335 sufficient degree of confidentiality. Channel bindings for the TLS 336 channel type are defined in [RFC5929]. 338 5. TLS Requirements 340 When peers negotiate a TLS session that is to transport RPC, the 341 following restrictions apply: 343 o Implementations MUST NOT negotiate TLS versions prior to v1.3 (for 344 TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively). 345 Support for mandatory-to-implement ciphersuites for the negotiated 346 TLS version is REQUIRED. 348 o Implementations MUST support certificate-based mutual 349 authentication. Support for TLS-PSK mutual authentication 350 [RFC4279] is OPTIONAL. See Section 4.2 for further details. 352 o Negotiation of a ciphersuite providing confidentiality as well as 353 integrity protection is REQUIRED. Support for and negotiation of 354 compression is OPTIONAL. 356 Client implementations MUST include the 357 "application_layer_protocol_negotiation(16)" extension [RFC7301] in 358 their "ClientHello" message and MUST include the protocol identifier 359 defined in Section 8.2 in that message's ProtocolNameList value. 361 Similary, in response to the "ClientHello" message, server 362 implementations MUST include the 363 "application_layer_protocol_negotiation(16)" extension [RFC7301] in 364 their "ServerHello" message and MUST include only the protocol 365 identifier defined in Section 8.2 in that message's ProtocolNameList 366 value. 368 If the server responds incorrectly, the client MUST NOT establish a 369 TLS session for use with RPC on this connection. See [RFC7301] for 370 further details about how to form these messages properly. 372 5.1. Base Transport Considerations 374 There is traditionally a strong association between an RPC program 375 and a destination port number. The use of TLS or DTLS does not 376 change that association. Thus it is frequently -- though not always 377 -- the case that a single TLS session carries traffic for only one 378 RPC program. 380 5.1.1. Protected Operation on TCP 382 The use of the Transport Layer Security (TLS) protocol [RFC8446] 383 protects RPC on TCP connections. Typically, once an RPC client 384 completes the TCP handshake, it uses the mechanism described in 385 Section 4.1 to discover RPC-on-TLS support for that connection. If 386 spurious traffic appears on a TCP connection between the initial 387 clear-text AUTH_TLS probe and the TLS session handshake, receivers 388 MUST discard that data without response and then SHOULD drop the 389 connection. 391 The protocol convention specified in the current document assumes 392 there can be no more than one concurrent TLS session per TCP 393 connection. This is true of current generations of TLS, but might be 394 different in a future version of TLS. 396 Once a TLS session is established on a TCP connection, no further 397 clear-text communication can occur on that connection until the 398 session is terminated. The use of TLS does not alter RPC record 399 framing used on TCP transports. 401 Furthermore, if an RPC server responds with PROG_UNAVAIL to an RPC 402 Call within an established TLS session, that does not imply that RPC 403 server will subsequently reject the same RPC program on a different 404 TCP connection. 406 Backchannel operation occurs only on connected transports such as 407 TCP. To protect backchannel operations, an RPC server uses the 408 existing TLS session on that connection to send backchannel 409 operations. The server does not attempt to establish a TLS session 410 on a TCP connection for backchannel operation. 412 When operation is complete, an RPC peer terminates a TLS session by 413 sending a TLS Closure Alert and may then close the TCP connection. 415 5.1.2. Protected Operation on UDP 417 RFC Editor: In the following section, please replace TBD with the 418 connection_id extension number that is to be assigned in 420 [I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's 421 Note before this document is published. 423 RPC over UDP is protected using the Datagram Transport Layer Security 424 (DTLS) protocol [I-D.ietf-tls-dtls13]. 426 Using DTLS does not introduce reliable or in-order semantics to RPC 427 on UDP. Each RPC message MUST fit in a single DTLS record. DTLS 428 encapsulation has overhead, which reduces the effective Path MTU 429 (PMTU) and thus the maximum RPC payload size. The use of DTLS record 430 replay protection is REQUIRED when transporting RPC traffic. 432 As soon as a client initializes a UDP socket for use with an RPC 433 server, it uses the mechanism described in Section 4.1 to discover 434 DTLS support for an RPC program on a particular port. It then 435 negotiates a DTLS session. 437 Multi-homed RPC clients and servers may send protected RPC messages 438 via network interfaces that were not involved in the handshake that 439 established the DTLS session. Therefore, when protecting RPC 440 traffic, each DTLS handshake MUST include the "connection_id(TBD)" 441 extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC- 442 on-DTLS peer endpoints MUST provide a ConnectionID with a non-zero 443 length. Endpoints implementing RPC programs that expect a 444 significant number of concurrent clients should employ ConnectionIDs 445 of at least 4 bytes in length. 447 Sending a TLS Closure Alert terminates a DTLS session. Subsequent 448 RPC messages exchanged between the RPC client and server are no 449 longer protected until a new DTLS session is established. 451 5.1.3. Protected Operation on Other Transports 453 Transports that provide intrinsic TLS-level security (e.g., QUIC) 454 need to be addressed separately from the current document. In such 455 cases, the use of TLS is not opportunistic as it can be for TCP or 456 UDP. 458 RPC-over-RDMA can make use of transport layer security below the RDMA 459 transport layer [RFC8166]. The exact mechanism is not within the 460 scope of the current document. Because there might not be other 461 provisions to exchange client and server certificates, authentication 462 material exchange needs to be provided by facilities within a future 463 version of the RPC-over-RDMA transport protocol. 465 5.2. TLS Peer Authentication 467 TLS can perform peer authentication using any of the following 468 mechanisms: 470 5.2.1. X.509 Certificates Using PKIX trust 472 Implementations are REQUIRED to support this mechanism. In this 473 mode, the tuple (serial number of the presented certificate; Issuer) 474 uniquely identifies the RPC peer. 476 o Implementations MUST allow the configuration of a list of trusted 477 Certification Authorities for incoming connections. 479 o Certificate validation MUST include the verification rules as per 480 [RFC5280]. 482 o Implementations SHOULD indicate their trusted Certification 483 Authorities (CAs). 485 o Peer validation always includes a check on whether the locally 486 configured expected DNS name or IP address of the server that is 487 contacted matches its presented certificate. DNS names and IP 488 addresses can be contained in the Common Name (CN) or 489 subjectAltName entries. For verification, only one of these 490 entries is to be considered. The following precedence applies: 491 for DNS name validation, subjectAltName:DNS has precedence over 492 CN; for IP address validation, subjectAltName:iPAddress has 493 precedence over CN. Implementors of this specification are 494 advised to read Section 6 of [RFC6125] for more details on DNS 495 name validation. 497 o For services accessed by their network identifiers (netids) and 498 universal network addresses (uaddr), the iPAddress subjectAltName 499 SHOULD be present in the certificate and must exactly match the 500 address represented by universal address. 502 o Implementations MAY allow the configuration of a set of additional 503 properties of the certificate to check for a peer's authorization 504 to communicate (e.g., a set of allowed values in 505 subjectAltName:URI or a set of allowed X509v3 Certificate 506 Policies). 508 o When the configured trust base changes (e.g., removal of a CA from 509 the list of trusted CAs; issuance of a new CRL for a given CA), 510 implementations MAY renegotiate the TLS session to reassess the 511 connecting peer's continued authorization. 513 Authenticating a connecting entity does not mean the RPC server 514 necessarily wants to communicate with that client. For example, if 515 the Issuer is not in a trusted set of Issuers, the RPC server may 516 decline to perform RPC transactions with this client. 517 Implementations that want to support a wide variety of trust models 518 should expose as many details of the presented certificate to the 519 administrator as possible so that the administrator can implement the 520 trust model. As a suggestion, at least the following parameters of 521 the X.509 client certificate SHOULD be exposed: 523 o Originating IP address 525 o Certificate Fingerprint 527 o Issuer 529 o Subject 531 o all X509v3 Extended Key Usage 533 o all X509v3 Subject Alternative Name 535 o all X509v3 Certificate Policies 537 5.2.2. X.509 Certificates Using Fingerprints 539 This mechanism is OPTIONAL to implement. In this mode, the 540 fingerprint of the presented certificate uniquely identifies the RPC 541 peer. 543 Implementations SHOULD allow the configuration of a list of trusted 544 certificates, identified via fingerprint of the DER-encoded 545 certificate octets. Implementations MUST support SHA-256 546 [FIPS.180-4] or stronger as the hash algorithm for the fingerprint. 548 5.2.3. Pre-Shared Keys 550 This mechanism is OPTIONAL to implement. In this mode, the RPC peer 551 is uniquely identified by keying material that has been shared out- 552 of-band or by a previous TLS-protected connection (see Section 2.2 of 553 [RFC8446]). At least the following parameters of the TLS connection 554 SHOULD be exposed: 556 o Originating IP address 558 o TLS Identifier 560 5.2.4. Token Binding 562 This mechanism is OPTIONAL to implement. In this mode, a token 563 uniquely identifies the RPC peer. 565 Versions of TLS after TLS 1.2 contain a token binding mechanism that 566 is more secure than using certificates. This mechanism is detailed 567 in [RFC8471]. 569 6. Implementation Status 571 RFC Editor: Please remove this section and the reference to RFC 7942 572 before this document is published. 574 This section records the status of known implementations of the 575 protocol defined by this specification at the time of posting of this 576 Internet-Draft, and is based on a proposal described in [RFC7942]. 577 The description of implementations in this section is intended to 578 assist the IETF in its decision processes in progressing drafts to 579 RFCs. 581 Please note that the listing of any individual implementation here 582 does not imply endorsement by the IETF. Furthermore, no effort has 583 been spent to verify the information presented here that was supplied 584 by IETF contributors. This is not intended as, and must not be 585 construed to be, a catalog of available implementations or their 586 features. Readers are advised to note that other implementations may 587 exist. 589 6.1. DESY NFS server 591 Organization: DESY 593 URL: https://desy.de [2] 595 Maturity: Implementation will be based on mature versions of the 596 current document. 598 Coverage: The bulk of this specification is implemented including 599 DTLS. 601 Licensing: LGPL 603 Implementation experience: The implementer has read and commented on 604 the current document. 606 6.2. Hammerspace NFS server 608 Organization: Hammerspace 610 URL: https://hammerspace.com [3] 612 Maturity: Prototype software based on early versions of the current 613 document. 615 Coverage: The bulk of this specification is implemented. The use of 616 DTLS functionality is not implemented. 618 Licensing: Proprietary 620 Implementation experience: No comments from implementors. 622 6.3. Linux NFS server and client 624 Organization: The Linux Foundation 626 URL: https://www.kernel.org [4] 628 Maturity: Prototype software based on early versions of the current 629 document. 631 Coverage: The bulk of this specification has yet to be implemented. 632 The use of DTLS functionality is not planned. 634 Licensing: GPLv2 636 Implementation experience: No comments from the implementor. 638 6.4. FreeBSD NFS server and client 640 Organization: The FreeBSD Project 642 URL: https://www.freebsd.org [5] 644 Maturity: Prototype software based on early versions of the current 645 document. 647 Coverage: The bulk of this specification is implemented. The use of 648 DTLS functionality is not planned. 650 Licensing: BSD 652 Implementation experience: Implementers have read and commented on 653 the current document. 655 7. Security Considerations 657 One purpose of the mechanism described in the current document is to 658 protect RPC-based applications against threats to the confidentiality 659 of RPC transactions and RPC user identities. A taxonomy of these 660 threats appears in Section 5 of [RFC6973]. Also, Section 6 of 661 [RFC7525] contains a detailed discussion of technologies used in 662 conjunction with TLS. Implementers should familiarize themselves 663 with these materials. 665 7.1. Limitations of an Opportunistic Approach 667 The purpose of using an explicitly opportunistic approach is to 668 enable interoperation with implementations that do not support RPC- 669 over-TLS. A range of options is allowed by this approach, from "no 670 peer authentication or encryption" to "server-only authentication 671 with encryption" to "mutual authentication with encryption". The 672 actual security level may indeed be selected based on policy and 673 without user intervention. 675 In environments where interoperability is a priority, the security 676 benefits of TLS are partially or entirely waived. Implementations of 677 the mechanism described in the current document must take care to 678 accurately represent to all RPC consumers the level of security that 679 is actually in effect, and are REQUIRED to provide an audit log of 680 RPC-over-TLS security mode selection. 682 In all other cases, the adoption, implementation, and deployment of 683 RPC-based upper-layer protocols that enforce the use of TLS 684 authentication and encryption (when similar RPCSEC GSS services are 685 not in use) is strongly encouraged. 687 7.1.1. STRIPTLS Attacks 689 A classic form of attack on network protocols that initiate an 690 association in plain-text to discover support for TLS is a man-in- 691 the-middle that alters the plain-text handshake to make it appear as 692 though TLS support is not available on one or both peers. Clients 693 implementers can choose from the following to mitigate STRIPTLS 694 attacks: 696 o A TLSA record [RFC6698] can alert clients that TLS is expected to 697 work, and provide a binding of hostname to x.509 identity. If TLS 698 cannot be negotiated or authentication fails, the client 699 disconnects and reports the problem. 701 o Client security policy can require that a TLS session is 702 established on every connection. If an attacker spoofs the 703 handshake, the client disconnects and reports the problem. If 704 TLSA records are not available, this approach is strongly 705 encouraged. 707 7.1.2. Privacy Leakage Before Session Establishment 709 As mentioned earlier, communication between an RPC client and server 710 appears in the clear on the network prior to the establishment of a 711 TLS session. This clear-text information usually includes transport 712 connection handshake exchanges, the RPC NULL procedure probing 713 support for TLS, and the initial parts of TLS session establishment. 714 Appendix C of [RFC8446] discusses precautions that can mitigate 715 exposure during the exchange of connnection handshake information and 716 TLS certificate material that might enable attackers to track the RPC 717 client. 719 Any RPC traffic that appears on the network before a TLS session has 720 been established is vulnerable to monitoring or undetected 721 modification. A secure client implementation limits or prevents any 722 RPC exchanges that are not protected. 724 The exception to this edict is the initial RPC NULL procedure that 725 acts as a STARTTLS message, which cannot be protected. This RPC NULL 726 procedure contains no arguments or results, and the AUTH_TLS 727 authentication flavor it uses does not contain user information. 729 7.2. TLS Identity Management on Clients 731 The goal of the RPC-on-TLS protocol extension is to hide the content 732 of RPC requests while they are in transit. The RPC-on-TLS protocol 733 by itself cannot protect against exposure of a user's RPC requests to 734 other users on the same client. 736 Moreover, client implementations are free to transmit RPC requests 737 for more than one RPC user using the same TLS session. Depending on 738 the details of the client RPC implementation, this means that the 739 client's TLS identity material is potentially visible to every RPC 740 user that shares a TLS session. Privileged users may also be able to 741 access this TLS identity. 743 As a result, client implementations need to carefully segregate TLS 744 identity material so that local access to it is restricted to only 745 the local users that are authorized to perform operations on the 746 remote RPC server. 748 7.3. Security Considerations for AUTH_SYS on TLS 750 Using a TLS-protected transport when the AUTH_SYS authentication 751 flavor is in use addresses several longstanding weaknesses (as 752 detailed in Appendix A). TLS augments AUTH_SYS by providing both 753 integrity protection and confidentiality that AUTH_SYS lacks. TLS 754 protects data payloads, RPC headers, and user identities against 755 monitoring and alteration while in transit. TLS guards against the 756 insertion or deletion of messages, thus also ensuring the integrity 757 of the message stream between RPC client and server. Lastly, 758 transport layer encryption plus peer authentication protects 759 receiving XDR decoders from deserializing untrusted data, a common 760 coding vulnerability. 762 The use of TLS enables strong authentication of the communicating RPC 763 peers, providing a degree of non-repudiation. When AUTH_SYS is used 764 with TLS, but the RPC client is unauthenticated, the RPC server still 765 acts on RPC requests for which there is no trustworthy 766 authentication. In-transit traffic is protected, but the RPC client 767 itself can still misrepresent user identity without server detection. 768 TLS without authentication is an improvement from AUTH_SYS without 769 encryption, but it leaves a critical security exposure. 771 In light of the above, it is RECOMMENDED that when AUTH_SYS is used, 772 every RPC client should present host authentication material to RPC 773 servers to prove that the client is a known one. The server can then 774 determine whether the UIDs and GIDs in AUTH_SYS requests from that 775 client can be accepted. 777 The use of TLS does not enable RPC clients to detect compromise that 778 leads to the impersonation of RPC users. Also, there continues to be 779 a requirement that the mapping of 32-bit user and group ID values to 780 user identities is the same on both the RPC client and server. 782 7.4. Best Security Policy Practices 784 RPC-over-TLS implementations and deployments are strongly encouraged 785 to adhere to the following policies to achieve the strongest possible 786 security with RPC-over-TLS. 788 o When using AUTH_NULL or AUTH_SYS, both peers are required to have 789 DNS TLSA records and certificate material, and a policy that 790 requires mutual peer authentication and rejection of a connection 791 when host authentication fails. 793 o When using RPCSEC_GSS, GSS/Kerberos provides adequate host 794 authentication and a policy that requires GSS mutual 795 authentication and rejection of a connection when host 796 authentication fails. GSS integrity and privacy services, 797 therefore, can be disabled in favor of TLS encryption with peer 798 authentication. 800 8. IANA Considerations 802 RFC Editor: In the following subsections, please replace RFC-TBD with 803 the RFC number assigned to this document. And, please remove this 804 Editor's Note before this document is published. 806 8.1. RPC Authentication Flavor 808 Following Appendix B of [RFC5531], the authors request a single new 809 entry in the RPC Authentication Flavor Numbers registry. The purpose 810 of the new authentication flavor is to signal the use of TLS with 811 RPC. This new flavor is not a pseudo-flavor. 813 The fields in the new entry are assigned as follows: 815 Identifier String: AUTH_TLS 817 Flavor Name: TLS 819 Value: 7 821 Description: Signals the use of TLS to protect RPC messages on 822 socket-based transports 824 Reference: RFC-TBD 826 8.2. ALPN Identifier for SUNRPC 828 Following Section 6 of [RFC7301], the authors request the allocation 829 of the following value in the "Application-Layer Protocol Negotiation 830 (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC 831 when used over TLS. 833 Protocol: SunRPC 835 Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 837 Reference: RFC-TBD 839 9. References 840 9.1. Normative References 842 [FIPS.180-4] 843 National Institute of Standards and Technology, "Secure 844 Hash Standard, Federal Information Processing Standards 845 Publication FIPS PUB 180-4", FIPS PUB 180-4, August 2015. 847 [I-D.ietf-tls-dtls-connection-id] 848 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 849 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 850 id-07 (work in progress), October 2019. 852 [I-D.ietf-tls-dtls13] 853 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 854 Datagram Transport Layer Security (DTLS) Protocol Version 855 1.3", draft-ietf-tls-dtls13-37 (work in progress), March 856 2020. 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, 860 DOI 10.17487/RFC2119, March 1997, 861 . 863 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 864 Ciphersuites for Transport Layer Security (TLS)", 865 RFC 4279, DOI 10.17487/RFC4279, December 2005, 866 . 868 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 869 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 870 . 872 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 873 Housley, R., and W. Polk, "Internet X.509 Public Key 874 Infrastructure Certificate and Certificate Revocation List 875 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 876 . 878 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 879 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 880 May 2009, . 882 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 883 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 884 . 886 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 887 Verification of Domain-Based Application Service Identity 888 within Internet Public Key Infrastructure Using X.509 889 (PKIX) Certificates in the Context of Transport Layer 890 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 891 2011, . 893 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 894 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 895 2014, . 897 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 898 "Transport Layer Security (TLS) Application-Layer Protocol 899 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 900 July 2014, . 902 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 903 Code: The Implementation Status Section", BCP 205, 904 RFC 7942, DOI 10.17487/RFC7942, July 2016, 905 . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 912 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 913 . 915 9.2. Informative References 917 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 918 Specification", RFC 2203, DOI 10.17487/RFC2203, September 919 1997, . 921 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 922 DOI 10.17487/RFC2818, May 2000, 923 . 925 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 926 of Named Entities (DANE) Transport Layer Security (TLS) 927 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 928 2012, . 930 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 931 Morris, J., Hansen, M., and R. Smith, "Privacy 932 Considerations for Internet Protocols", RFC 6973, 933 DOI 10.17487/RFC6973, July 2013, 934 . 936 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 937 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 938 December 2014, . 940 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 941 "Recommendations for Secure Use of Transport Layer 942 Security (TLS) and Datagram Transport Layer Security 943 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 944 2015, . 946 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 947 Memory Access Transport for Remote Procedure Call Version 948 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 949 . 951 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 952 "The Token Binding Protocol Version 1.0", RFC 8471, 953 DOI 10.17487/RFC8471, October 2018, 954 . 956 9.3. URIs 958 [1] https://github.com/chucklever/i-d-rpc-tls 960 [2] https://desy.de 962 [3] https://hammerspace.com 964 [4] https://www.kernel.org 966 [5] https://www.freebsd.org 968 [6] https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls 970 Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor 972 The ONC RPC protocol, as specified in [RFC5531], provides several 973 modes of security, traditionally referred to as "authentication 974 flavors". Some of these flavors provide much more than an 975 authentication service. We refer to these as authentication flavors, 976 security flavors, or simply, flavors. One of the earliest and most 977 basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of 978 [RFC5531] specifies AUTH_SYS. 980 AUTH_SYS assumes that the RPC client and server both use POSIX-style 981 user and group identifiers (each user and group can be distinctly 982 represented as a 32-bit unsigned integer). It also assumes that the 983 client and server both use the same mapping of user and group to an 984 integer. One user ID, one primary group ID, and up to 16 985 supplemental group IDs are associated with each RPC request. The 986 combination of these identifies the entity on the client that is 987 making the request. 989 A string identifies peers (hosts) in each RPC request. [RFC5531] 990 does not specify any requirements for this string other than that is 991 no longer than 255 octets. It does not have to be the same from 992 request to request. Also, it does not have to match the DNS hostname 993 of the sending host. For these reasons, even though most 994 implementations fill in their hostname in this field, receivers 995 typically ignore its content. 997 Appendix A of [RFC5531] contains a brief explanation of security 998 considerations: 1000 It should be noted that use of this flavor of authentication does 1001 not guarantee any security for the users or providers of a 1002 service, in itself. The authentication provided by this scheme 1003 can be considered legitimate only when applications using this 1004 scheme and the network can be secured externally, and privileged 1005 transport addresses are used for the communicating end-points (an 1006 example of this is the use of privileged TCP/UDP ports in UNIX 1007 systems -- note that not all systems enforce privileged transport 1008 address mechanisms). 1010 It should be clear, therefore, that AUTH_SYS by itself (i.e., without 1011 strong client authentication) offers little to no communication 1012 security: 1014 1. It does not protect the confidentiality or integrity of RPC 1015 requests, users, or payloads, relying instead on "external" 1016 security. 1018 2. It does not provide authentication of RPC peer machines, other 1019 than inclusion of an unprotected domain name. 1021 3. The use of 32-bit unsigned integers as user and group identifiers 1022 is problematic because these data types are not cryptographically 1023 signed or otherwise verified by any authority. 1025 4. Because the user and group ID fields are not integrity-protected, 1026 AUTH_SYS does not provide non-repudiation. 1028 Acknowledgments 1030 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 1031 with Stunnel TLS" [6]. His article inspired the mechanism described 1032 in the current document. 1034 Many thanks to Tigran Mkrtchyan and Rick Macklem for their work on 1035 prototype implementations and feedback on the current document. 1037 Thanks to Derrell Piper for numerous suggestions that improved both 1038 this simple mechanism and the current document's security-related 1039 discussion. 1041 Many thanks to Transport Area Director Magnus Westerlund for his 1042 sharp questions and careful reading of the final revisions of the 1043 current document. The text of Section 5.1.2 is mostly his 1044 contribution. 1046 The authors are additionally grateful to Bill Baker, David Black, 1047 Alan DeKok, Lars Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg 1048 Marsden, Alex McDonald, Justin Mazzola Paluska, Tom Talpey, and 1049 Martin Thomson for their input and support of this work. 1051 Finally, special thanks to NFSV4 Working Group Chair and document 1052 shepherd David Noveck, NFSV4 Working Group Chairs Spencer Shepler and 1053 Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for 1054 their guidance and oversight. 1056 Authors' Addresses 1058 Trond Myklebust 1059 Hammerspace Inc 1060 4300 El Camino Real Ste 105 1061 Los Altos, CA 94022 1062 United States of America 1064 Email: trond.myklebust@hammerspace.com 1066 Charles Lever (editor) 1067 Oracle Corporation 1068 United States of America 1070 Email: chuck.lever@oracle.com