idnits 2.17.1 draft-ietf-nfsv4-rpc-tls-08.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 (19 June 2020) is 1378 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) == 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-38 ** 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 (==), 4 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: 21 December 2020 19 June 2020 8 Towards Remote Procedure Call Encryption By Default 9 draft-ietf-nfsv4-rpc-tls-08 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 Note 21 Discussion of this draft takes place on the NFSv4 working group 22 mailing list (nfsv4@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group 24 information can be found at https://datatracker.ietf.org/wg/nfsv4/ 25 about/. 27 This note is to be removed before publishing as an RFC. 29 The source for this draft is maintained in GitHub. Suggested changes 30 should be submitted as pull requests at 31 https://github.com/chucklever/i-d-rpc-tls. Instructions are on that 32 page as well. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 21 December 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 70 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6 71 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 72 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 73 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. Base Transport Considerations . . . . . . . . . . . . . . 9 75 5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 9 76 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10 77 5.1.3. Protected Operation on Other Transports . . . . . . . 11 78 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 11 79 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 11 80 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 12 81 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 13 82 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 13 83 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 84 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 14 86 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 14 87 6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 15 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 7.1. Limitations of an Opportunistic Approach . . . . . . . . 15 90 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 16 91 7.1.2. Privacy Leakage Before Session Establishment . . . . 16 92 7.2. TLS Identity Management on Clients . . . . . . . . . . . 16 93 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 17 94 7.4. Best Security Policy Practices . . . . . . . . . . . . . 18 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 18 97 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 18 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 100 9.2. Informative References . . . . . . . . . . . . . . . . . 20 101 Appendix A. Known Weaknesses of the AUTH_SYS Authentication 102 Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 106 1. Introduction 108 In 2014 the IETF published a document entitled "Pervasive Monitoring 109 Is an Attack" [RFC7258], which recognized that unauthorized 110 observation of network traffic had become widespread and was a 111 subversive threat to all who make use of the Internet at large. It 112 strongly recommended that newly defined Internet protocols should 113 make a genuine effort to mitigate monitoring attacks. Typically this 114 mitigation is done by encrypting data in transit. 116 The Remote Procedure Call version 2 protocol has been a Proposed 117 Standard for three decades (see [RFC5531] and its antecedents). Over 118 twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in- 119 transit encryption mechanism for RPC [RFC2203]. However, experience 120 has shown that RPCSEC GSS with in-transit encryption can be 121 challenging to use in practice: 123 * Parts of each RPC header remain in clear-text, constituting a 124 significant security exposure. 126 * Offloading the GSS privacy service is not practical in large 127 multi-user deployments since each message is encrypted using a key 128 based on the issuing RPC user. 130 However strong GSS-provided confidentiality is, it cannot provide any 131 security if the challenges of using it result in choosing not to 132 deploy it at all. 134 Moreover, the use of AUTH_SYS remains common despite the adverse 135 effects that acceptance of UIDs and GIDs from unauthenticated clients 136 brings with it. Continued use is in part because: 138 * Per-client deployment and administrative costs are not scalable. 139 Administrators must provide keying material for each RPC client, 140 including transient clients. 142 * Host identity management and user identity management must be 143 enforced in the same security realm. In certain environments, 144 different authorities might be responsible for provisioning client 145 systems versus provisioning new users. 147 The alternative described in the current document is to employ a 148 transport layer security mechanism that can protect the 149 confidentiality of each RPC connection transparently to RPC and 150 upper-layer protocols. The Transport Layer Security protocol 151 [RFC8446] (TLS) is a well-established Internet building block that 152 protects many standard Internet protocols such as the Hypertext 153 Transport Protocol (HTTP) [RFC2818]. 155 Encrypting at the RPC transport layer accords several significant 156 benefits: 158 Encryption By Default: Transport encryption can be enabled without 159 additional administrative tasks such as identifying client systems 160 to a trust authority, generating additional keying material, or 161 provisioning a secure network tunnel. 163 Encryption Offload: Hardware support for the GSS privacy service has 164 not appeared in the marketplace. However, the use of a well- 165 established transport encryption mechanism that is employed by 166 other ubiquitous network protocols makes it more likely that 167 encryption offload for RPC is practicable. 169 Securing AUTH_SYS: Most critically, transport encryption can 170 significantly reduce several security issues inherent in the 171 current widespread use of AUTH_SYS (i.e., acceptance of UIDs and 172 GIDs generated by an unauthenticated client). 174 Decoupled User and Host Identities: TLS can be used to authenticate 175 peer hosts while other security mechanisms can handle user 176 authentication. 178 The current document specifies the implementation of RPC on an 179 encrypted transport in a manner that is transparent to upper-layer 180 protocols based on RPC. The imposition of encryption at the 181 transport layer protects any upper-layer protocol that employs RPC, 182 without alteration of that protocol. 184 Further, Section 7 of the current document defines policies in line 185 with [RFC7435] which enable RPC-over-TLS to be deployed 186 opportunistically in environments that contain RPC implementations 187 that do not support TLS. However, specifications for RPC-based 188 upper-layer protocols should choose to require even stricter policies 189 that guarantee encryption and host authentication is used for all RPC 190 transactions. Enforcing the use of RPC-over-TLS is of particular 191 importance for existing upper-layer protocols whose security 192 infrastructure is weak. 194 The protocol specification in the current document assumes that 195 support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available 196 in an RPC implementation where TLS support is to be added. 198 2. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in 203 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 204 capitals, as shown here. 206 3. Terminology 208 This document adopts the terminology introduced in Section 3 of 209 [RFC6973] and assumes a working knowledge of the Remote Procedure 210 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 211 Security (TLS) version 1.3 protocol [RFC8446]. 213 Note also that the NFS community long ago adopted the use of the term 214 "privacy" from documents such as [RFC2203]. In the current document, 215 the authors use the term "privacy" only when referring specifically 216 to the historic GSS privacy service defined in [RFC2203]. Otherwise, 217 the authors use the term "confidentiality", following the practices 218 of contemporary security communities. 220 We adhere to the convention that a "client" is a network host that 221 actively initiates an association, and a "server" is a network host 222 that passively accepts an association request. 224 RPC documentation historically refers to the authentication of a 225 connecting host as "machine authentication" or "host authentication". 226 TLS documentation refers to the same as "peer authentication". In 227 the current document there is little distinction between these terms. 229 The term "user authentication" in the current document refers 230 specifically to the RPC caller's credential, provided in the "cred" 231 and "verf" fields in each RPC Call. 233 4. RPC-Over-TLS in Operation 234 4.1. Discovering Server-side TLS Support 236 The mechanism described in the current document interoperates fully 237 with RPC implementations that do not support RPC-over-TLS. Policy 238 settings on the RPC-over-TLS-enabled peer determine whether RPC 239 operation continues without the use of TLS or RPC operation is not 240 permitted. 242 To achieve this interoperability, we introduce a new RPC 243 authentication flavor called AUTH_TLS. The AUTH_TLS authentication 244 flavor signals that the client wants to initiate TLS negotiation if 245 the server supports it. Except for the modifications described in 246 this section, the RPC protocol is unaware of security encapsulation 247 at the transport layer. The value of AUTH_TLS is defined in 248 Section 8.1. 250 An RPC client begins its communication with an RPC server by 251 selecting a transport and destination port. The choice of transport 252 and port is typically based on the RPC program that is to be used. 253 The RPC client might query the RPC server's rpcbind service to make 254 this selection. In all cases, an RPC server MUST listen on the same 255 ports for (D)TLS-protected RPC programs as the ports used when (D)TLS 256 is not available. 258 To protect RPC traffic to a TCP port, the RPC client opens a TCP 259 connection to that port and sends a NULL RPC procedure with an 260 auth_flavor of AUTH_TLS on that connection. To protect RPC traffic 261 to a UDP port, the RPC client sends a UDP datagram to that port 262 containing a NULL RPC procedure with an auth_flavor of AUTH_TLS. The 263 mechanism described in the current document does not support RPC 264 transports other than TCP and UDP. 266 The length of the opaque data constituting the credential sent in the 267 RPC Call message MUST be zero. The verifier accompanying the 268 credential MUST be an AUTH_NONE verifier of length zero. 270 The flavor value of the verifier in the RPC Reply message received 271 from the server MUST be AUTH_NONE. The length of the verifier's body 272 field is eight. The bytes of the verifier's body field encode the 273 ASCII characters "STARTTLS" as a fixed-length opaque. 275 If the RPC server replies with a reply_stat of MSG_ACCEPTED and an 276 AUTH_NONE verifier containing the "STARTTLS" token, the client SHOULD 277 proceed with TLS session establishment, even if the Reply's 278 accept_stat is not SUCCESS. If the AUTH_TLS probe was done via TCP, 279 the RPC client MUST send the "ClientHello" message on the same 280 connection. If the AUTH_TLS probe was done via UDP, the RPC client 281 MUST send the "ClientHello" message to the same UDP destination port. 283 Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its 284 verifier flavor is not AUTH_NONE, or if its verifier does not contain 285 the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello" 286 message. RPC operation can continue, however it will be without any 287 confidentiality, integrity or authentication protection from (D)TLS. 289 If, after a successful RPC AUTH_TLS probe, the subsequent (D)TLS 290 handshake should fail for any reason, the RPC client reports this 291 failure to the upper-layer application the same way it reports an 292 AUTH_ERROR rejection from the RPC server. 294 If an RPC client uses the AUTH_TLS authentication flavor on any 295 procedure other than the NULL procedure, or an RPC client sends an 296 RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server 297 MUST reject that RPC Call by setting the reply_stat field to 298 MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat 299 field to AUTH_BADCRED. 301 Once the TLS session handshake is complete, the RPC client and server 302 have established a secure channel for communicating. A successful 303 AUTH_TLS probe on one particular port/transport tuple never implies 304 RPC-over-TLS is available on that same server using a different port/ 305 transport tuple. 307 4.2. Authentication 309 Both RPC and TLS have peer and user authentication, with some overlap 310 in capability between RPC and TLS. The goal of interoperability with 311 implementations that do not support TLS requires limiting the 312 combinations that are allowed and precisely specifying the role that 313 each layer plays. 315 Each RPC server that supports RPC-over-TLS MUST possess a unique 316 global identity (e.g., a certificate that is signed by a well-known 317 trust anchor). Such an RPC server MUST request a TLS peer identity 318 from each client upon first contact. There are two different modes 319 of client deployment: 321 Server-only Host Authentication 322 In this type of deployment, the client can authenticate the server 323 host using the presented server peer TLS identity, but the server 324 cannot authenticate the client. In this situation, RPC-over-TLS 325 clients are anonymous. They present no globally unique identifier 326 to the server peer. 328 Mutual Host Authentication 329 In this type of deployment, the client possesses an identity (e.g. 330 a certificate) that is backed by a trusted entity. As part of the 331 TLS handshake, both peers authenticate using the presented TLS 332 identities. If authentication of either peer fails, or if 333 authorization based on those identities blocks access to the 334 server, the peers MUST reject the association. 336 In either of these modes, RPC user authentication is not affected by 337 the use of transport layer security. When a client presents a TLS 338 peer identity to an RPC server, the protocol extension described in 339 the current document provides no way for the server to know whether 340 that identity represents one RPC user on that client, or is shared 341 amongst many RPC users. Therefore, a server implementation must not 342 utilize the remote TLS peer identity for RPC user authentication. 344 4.2.1. Using TLS with RPCSEC GSS 346 To use GSS, an RPC server has to possess a GSS service principal. On 347 a TLS session, GSS mutual (peer) authentication occurs as usual, but 348 only after a TLS session has been established for communication. 349 Authentication of GSS users is unchanged by the use of TLS. 351 RPCSEC GSS can also perform per-request integrity or confidentiality 352 protection. When operating over a TLS session, these GSS services 353 become redundant. An RPC implementation capable of concurrently 354 using TLS and RPCSEC GSS can use GSS channel binding, as defined in 355 [RFC5056], to determine when an underlying transport provides a 356 sufficient degree of confidentiality. Channel bindings for the TLS 357 channel type are defined in [RFC5929]. 359 5. TLS Requirements 361 When peers negotiate a TLS session that is to transport RPC, the 362 following restrictions apply: 364 * Implementations MUST NOT negotiate TLS versions prior to v1.3 (for 365 TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively). 366 Support for mandatory-to-implement ciphersuites for the negotiated 367 TLS version is REQUIRED. 369 * Implementations MUST support certificate-based mutual 370 authentication. Support for TLS-PSK mutual authentication 371 [RFC4279] is OPTIONAL. See Section 4.2 for further details. 373 * Negotiation of a ciphersuite providing confidentiality as well as 374 integrity protection is REQUIRED. Support for and negotiation of 375 compression is OPTIONAL. 377 Client implementations MUST include the 378 "application_layer_protocol_negotiation(16)" extension [RFC7301] in 379 their "ClientHello" message and MUST include the protocol identifier 380 defined in Section 8.2 in that message's ProtocolNameList value. 382 Similary, in response to the "ClientHello" message, server 383 implementations MUST include the 384 "application_layer_protocol_negotiation(16)" extension [RFC7301] in 385 their "ServerHello" message and MUST include only the protocol 386 identifier defined in Section 8.2 in that message's ProtocolNameList 387 value. 389 If the server responds incorrectly (for instance, if the 390 "ServerHello" message does not conform to the above requirements), 391 the client MUST NOT establish a TLS session for use with RPC on this 392 connection. See [RFC7301] for further details about how to form 393 these messages properly. 395 5.1. Base Transport Considerations 397 There is traditionally a strong association between an RPC program 398 and a destination port number. The use of TLS or DTLS does not 399 change that association. Thus it is frequently -- though not always 400 -- the case that a single TLS session carries traffic for only one 401 RPC program. 403 5.1.1. Protected Operation on TCP 405 The use of the Transport Layer Security (TLS) protocol [RFC8446] 406 protects RPC on TCP connections. Typically, once an RPC client 407 completes the TCP handshake, it uses the mechanism described in 408 Section 4.1 to discover RPC-over-TLS support for that connection. If 409 spurious traffic appears on a TCP connection between the initial 410 clear-text AUTH_TLS probe and the TLS session handshake, receivers 411 MUST discard that data without response and then SHOULD drop the 412 connection. 414 The protocol convention specified in the current document assumes 415 there can be no more than one concurrent TLS session per TCP 416 connection. This is true of current generations of TLS, but might be 417 different in a future version of TLS. 419 Once a TLS session is established on a TCP connection, no further 420 clear-text communication can occur on that connection until the 421 session is terminated. The use of TLS does not alter RPC record 422 framing used on TCP transports. 424 Furthermore, if an RPC server responds with PROG_UNAVAIL to an RPC 425 Call within an established TLS session, that does not imply that RPC 426 server will subsequently reject the same RPC program on a different 427 TCP connection. 429 Reverse-direction operation occurs only on connected transports such 430 as TCP (see Section 2 of [RFC8166]). To protect reverse-direction 431 RPC operations, the RPC server does not establish a separate TLS 432 session on the TCP connection, but instead uses the existing TLS 433 session on that connection to protect these operations. 435 When operation is complete, an RPC peer terminates a TLS session by 436 sending a TLS Closure Alert and may then close the TCP connection. 438 5.1.2. Protected Operation on UDP 440 RFC Editor: In the following section, please replace TBD with the 441 connection_id extension number that is to be assigned in 442 [I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's 443 Note before this document is published. 445 RPC over UDP is protected using the Datagram Transport Layer Security 446 (DTLS) protocol [I-D.ietf-tls-dtls13]. 448 Using DTLS does not introduce reliable or in-order semantics to RPC 449 on UDP. Each RPC message MUST fit in a single DTLS record. DTLS 450 encapsulation has overhead, which reduces the effective Path MTU 451 (PMTU) and thus the maximum RPC payload size. The use of DTLS record 452 replay protection is REQUIRED when transporting RPC traffic. 454 As soon as a client initializes a UDP socket for use with an RPC 455 server, it uses the mechanism described in Section 4.1 to discover 456 DTLS support for an RPC program on a particular port. It then 457 negotiates a DTLS session. 459 Multi-homed RPC clients and servers may send protected RPC messages 460 via network interfaces that were not involved in the handshake that 461 established the DTLS session. Therefore, when protecting RPC 462 traffic, each DTLS handshake MUST include the "connection_id(TBD)" 463 extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC- 464 on-DTLS peer endpoints MUST provide a ConnectionID with a non-zero 465 length. Endpoints implementing RPC programs that expect a 466 significant number of concurrent clients should employ ConnectionIDs 467 of at least 4 bytes in length. 469 Sending a TLS Closure Alert terminates a DTLS session. Subsequent 470 RPC messages exchanged between the RPC client and server are no 471 longer protected until a new DTLS session is established. 473 5.1.3. Protected Operation on Other Transports 475 Transports that provide intrinsic TLS-level security (e.g., QUIC) 476 need to be addressed separately from the current document. In such 477 cases, the use of TLS is not opportunistic as it can be for TCP or 478 UDP. 480 RPC-over-RDMA can make use of transport layer security below the RDMA 481 transport layer [RFC8166]. The exact mechanism is not within the 482 scope of the current document. Because there might not be other 483 provisions to exchange client and server certificates, authentication 484 material exchange needs to be provided by facilities within a future 485 version of the RPC-over-RDMA transport protocol. 487 5.2. TLS Peer Authentication 489 TLS can perform peer authentication using any of the following 490 mechanisms: 492 5.2.1. X.509 Certificates Using PKIX trust 494 Implementations are REQUIRED to support this mechanism. In this 495 mode, the tuple (serial number of the presented certificate; Issuer) 496 uniquely identifies the RPC peer. 498 X.509 certificates are specified in [X.509] and extended in 499 [RFC5280]. 501 * Implementations MUST allow the configuration of a list of trusted 502 Certification Authorities for authorizing incoming connections. 504 * Certificate validation MUST include the verification rules as per 505 [RFC5280]. 507 * Implementations SHOULD indicate their trusted Certification 508 Authorities (CAs). 510 * Peer validation always includes a check on whether the locally 511 configured expected DNS name or IP address of the server that is 512 contacted matches its presented certificate. DNS names and IP 513 addresses can be contained in the Common Name (CN) or 514 subjectAltName entries. For verification, only one of these 515 entries is to be considered. The following precedence applies: 516 for DNS name validation, subjectAltName:DNS has precedence over 517 CN; for IP address validation, subjectAltName:iPAddress has 518 precedence over CN. Implementors of this specification are 519 advised to read Section 6 of [RFC6125] for more details on DNS 520 name validation. 522 * For services accessed by their network identifiers (netids) and 523 universal network addresses (uaddr), the iPAddress subjectAltName 524 SHOULD be present in the certificate and must exactly match the 525 address represented by the universal network address. 527 * Implementations MAY allow the configuration of a set of additional 528 properties of the certificate to check for a peer's authorization 529 to communicate (e.g., a set of allowed values in 530 subjectAltName:URI or a set of allowed X.509v3 Certificate 531 Policies). 533 * When the configured trust base changes (e.g., removal of a CA from 534 the list of trusted CAs; issuance of a new CRL for a given CA), 535 implementations MAY renegotiate the TLS session to reassess the 536 connecting peer's continued authorization. 538 Authenticating a connecting entity does not mean the RPC server 539 necessarily wants to communicate with that client. For example, if 540 the Issuer is not in a trusted set of Issuers, the RPC server may 541 decline to perform RPC transactions with this client. 542 Implementations that want to support a wide variety of trust models 543 should expose as many details of the presented certificate to the 544 administrator as possible so that the administrator can implement the 545 trust model. As a suggestion, at least the following parameters of 546 the X.509 client certificate SHOULD be exposed: 548 * Originating IP address 550 * Certificate Fingerprint 552 * Issuer 554 * Subject 556 * all X.509v3 Extended Key Usage 558 * all X.509v3 Subject Alternative Name 560 * all X.509v3 Certificate Policies 562 5.2.2. X.509 Certificates Using Fingerprints 564 This mechanism is OPTIONAL to implement. In this mode, the 565 fingerprint of a certificate uniquely identifies the RPC peer. 567 A "fingerprint" is typically defined as a cryptographic digest of the 568 Distinguished Encoding Rules (DER) form [X.690] of an X.509v3 569 certificate [X.509]. Implementations SHOULD allow the configuration 570 of a list of trusted certificates that is indexed by fingerprint. 572 5.2.3. Pre-Shared Keys 574 This mechanism is OPTIONAL to implement. In this mode, the RPC peer 575 is uniquely identified by keying material that has been shared out- 576 of-band or by a previous TLS-protected connection (see Section 2.2 of 577 [RFC8446]). At least the following parameters of the TLS connection 578 SHOULD be exposed: 580 * Originating IP address 582 * TLS Identifier 584 5.2.4. Token Binding 586 This mechanism is OPTIONAL to implement. In this mode, a token 587 uniquely identifies the RPC peer. 589 Versions of TLS after TLS 1.2 contain a token binding mechanism that 590 is more secure than using certificates. This mechanism is detailed 591 in [RFC8471]. 593 6. Implementation Status 595 This section is to be removed before publishing as an RFC. 597 This section records the status of known implementations of the 598 protocol defined by this specification at the time of posting of this 599 Internet-Draft, and is based on a proposal described in [RFC7942]. 600 The description of implementations in this section is intended to 601 assist the IETF in its decision processes in progressing drafts to 602 RFCs. 604 Please note that the listing of any individual implementation here 605 does not imply endorsement by the IETF. Furthermore, no effort has 606 been spent to verify the information presented here that was supplied 607 by IETF contributors. This is not intended as, and must not be 608 construed to be, a catalog of available implementations or their 609 features. Readers are advised to note that other implementations may 610 exist. 612 6.1. DESY NFS server 614 Organization: DESY 616 URL: https://desy.de 618 Maturity: Implementation will be based on mature versions of the 619 current document. 621 Coverage: The bulk of this specification is implemented including 622 DTLS. 624 Licensing: LGPL 626 Implementation experience: The implementer has read and commented on 627 the current document. 629 6.2. Hammerspace NFS server 631 Organization: Hammerspace 633 URL: https://hammerspace.com 635 Maturity: Prototype software based on early versions of the current 636 document. 638 Coverage: The bulk of this specification is implemented. The use of 639 DTLS functionality is not implemented. 641 Licensing: Proprietary 643 Implementation experience: No comments from implementors. 645 6.3. Linux NFS server and client 647 Organization: The Linux Foundation 649 URL: https://www.kernel.org 651 Maturity: Prototype software based on early versions of the current 652 document. 654 Coverage: The bulk of this specification has yet to be implemented. 655 The use of DTLS functionality is not planned. 657 Licensing: GPLv2 659 Implementation experience: No comments from the implementor. 661 6.4. FreeBSD NFS server and client 663 Organization: The FreeBSD Project 665 URL: https://www.freebsd.org 667 Maturity: Prototype software based on early versions of the current 668 document. 670 Coverage: The bulk of this specification is implemented. The use of 671 DTLS functionality is not planned. 673 Licensing: BSD 675 Implementation experience: Implementers have read and commented on 676 the current document. 678 7. Security Considerations 680 One purpose of the mechanism described in the current document is to 681 protect RPC-based applications against threats to the confidentiality 682 of RPC transactions and RPC user identities. A taxonomy of these 683 threats appears in Section 5 of [RFC6973]. Also, Section 6 of 684 [RFC7525] contains a detailed discussion of technologies used in 685 conjunction with TLS. Implementers should familiarize themselves 686 with these materials. 688 7.1. Limitations of an Opportunistic Approach 690 The purpose of using an explicitly opportunistic approach is to 691 enable interoperation with implementations that do not support RPC- 692 over-TLS. A range of options is allowed by this approach, from "no 693 peer authentication or encryption" to "server-only authentication 694 with encryption" to "mutual authentication with encryption". The 695 actual security level may indeed be selected based on policy and 696 without user intervention. 698 In environments where interoperability is a priority, the security 699 benefits of TLS are partially or entirely waived. Implementations of 700 the mechanism described in the current document must take care to 701 accurately represent to all RPC consumers the level of security that 702 is actually in effect, and are REQUIRED to provide an audit log of 703 RPC-over-TLS security mode selection. 705 In all other cases, the adoption, implementation, and deployment of 706 RPC-based upper-layer protocols that enforce the use of TLS 707 authentication and encryption (when similar RPCSEC GSS services are 708 not in use) is strongly encouraged. 710 7.1.1. STRIPTLS Attacks 712 A classic form of attack on network protocols that initiate an 713 association in plain-text to discover support for TLS is a man-in- 714 the-middle that alters the plain-text handshake to make it appear as 715 though TLS support is not available on one or both peers. Clients 716 implementers can choose from the following to mitigate STRIPTLS 717 attacks: 719 * A TLSA record [RFC6698] can alert clients that TLS is expected to 720 work, and provide a binding of hostname to X.509 identity. If TLS 721 cannot be negotiated or authentication fails, the client 722 disconnects and reports the problem. 724 * Client security policy can require that a TLS session is 725 established on every connection. If an attacker spoofs the 726 handshake, the client disconnects and reports the problem. If 727 TLSA records are not available, this approach is strongly 728 encouraged. 730 7.1.2. Privacy Leakage Before Session Establishment 732 As mentioned earlier, communication between an RPC client and server 733 appears in the clear on the network prior to the establishment of a 734 TLS session. This clear-text information usually includes transport 735 connection handshake exchanges, the RPC NULL procedure probing 736 support for TLS, and the initial parts of TLS session establishment. 737 Appendix C of [RFC8446] discusses precautions that can mitigate 738 exposure during the exchange of connnection handshake information and 739 TLS certificate material that might enable attackers to track the RPC 740 client. 742 Any RPC traffic that appears on the network before a TLS session has 743 been established is vulnerable to monitoring or undetected 744 modification. A secure client implementation limits or prevents any 745 RPC exchanges that are not protected. 747 The exception to this edict is the initial RPC NULL procedure that 748 acts as a STARTTLS message, which cannot be protected. This RPC NULL 749 procedure contains no arguments or results, and the AUTH_TLS 750 authentication flavor it uses does not contain user information. 752 7.2. TLS Identity Management on Clients 754 The goal of the RPC-over-TLS protocol extension is to hide the 755 content of RPC requests while they are in transit. The RPC-over-TLS 756 protocol by itself cannot protect against exposure of a user's RPC 757 requests to other users on the same client. 759 Moreover, client implementations are free to transmit RPC requests 760 for more than one RPC user using the same TLS session. Depending on 761 the details of the client RPC implementation, this means that the 762 client's TLS identity material is potentially visible to every RPC 763 user that shares a TLS session. Privileged users may also be able to 764 access this TLS identity. 766 As a result, client implementations need to carefully segregate TLS 767 identity material so that local access to it is restricted to only 768 the local users that are authorized to perform operations on the 769 remote RPC server. 771 7.3. Security Considerations for AUTH_SYS on TLS 773 Using a TLS-protected transport when the AUTH_SYS authentication 774 flavor is in use addresses several longstanding weaknesses in 775 AUTH_SYS (as detailed in Appendix A). TLS augments AUTH_SYS by 776 providing both integrity protection and confidentiality that AUTH_SYS 777 lacks. TLS protects data payloads, RPC headers, and user identities 778 against monitoring and alteration while in transit. 780 TLS guards against in-transit insertion and deletion of RPC messages, 781 thus ensuring the integrity of the message stream between RPC client 782 and server. DTLS does not provide full message stream protection, 783 but it does enable receivers to reject non-participant messages. In 784 particular, transport layer encryption plus peer authentication 785 protects receiving XDR decoders from deserializing untrusted data, a 786 common coding vulnerability. 788 The use of TLS enables strong authentication of the communicating RPC 789 peers, providing a degree of non-repudiation. When AUTH_SYS is used 790 with TLS, but the RPC client is unauthenticated, the RPC server still 791 acts on RPC requests for which there is no trustworthy 792 authentication. In-transit traffic is protected, but the RPC client 793 itself can still misrepresent user identity without server detection. 794 TLS without authentication is an improvement from AUTH_SYS without 795 encryption, but it leaves a critical security exposure. 797 In light of the above, it is RECOMMENDED that when AUTH_SYS is used, 798 every RPC client should present host authentication material to RPC 799 servers to prove that the client is a known one. The server can then 800 determine whether the UIDs and GIDs in AUTH_SYS requests from that 801 client can be accepted. 803 The use of TLS does not enable RPC clients to detect compromise that 804 leads to the impersonation of RPC users. Also, there continues to be 805 a requirement that the mapping of 32-bit user and group ID values to 806 user identities is the same on both the RPC client and server. 808 7.4. Best Security Policy Practices 810 RPC-over-TLS implementations and deployments are strongly encouraged 811 to adhere to the following policies to achieve the strongest possible 812 security with RPC-over-TLS. 814 * When using AUTH_NULL or AUTH_SYS, both peers are required to have 815 DNS TLSA records and certificate material, and a policy that 816 requires mutual peer authentication and rejection of a connection 817 when host authentication fails. 819 * RCPSEC_GSS provides integrity and privacy services which are 820 redundant when TLS is in use. These services should be disabled 821 in that case. 823 8. IANA Considerations 825 RFC Editor: In the following subsections, please replace RFC-TBD with 826 the RFC number assigned to this document. And, please remove this 827 Editor's Note before this document is published. 829 8.1. RPC Authentication Flavor 831 Following Appendix B of [RFC5531], the authors request a single new 832 entry in the RPC Authentication Flavor Numbers registry. The purpose 833 of the new authentication flavor is to signal the use of TLS with 834 RPC. This new flavor is not a pseudo-flavor. 836 The fields in the new entry are assigned as follows: 838 Identifier String: AUTH_TLS 840 Flavor Name: TLS 842 Value: 7 844 Description: Indicates support for RPC-over-TLS. 846 Reference: RFC-TBD 848 8.2. ALPN Identifier for SUNRPC 850 Following Section 6 of [RFC7301], the authors request the allocation 851 of the following value in the "Application-Layer Protocol Negotiation 852 (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC 853 when used over TLS. 855 Protocol: SunRPC 856 Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 858 Reference: RFC-TBD 860 9. References 862 9.1. Normative References 864 [I-D.ietf-tls-dtls-connection-id] 865 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 866 Identifiers for DTLS 1.2", Work in Progress, Internet- 867 Draft, draft-ietf-tls-dtls-connection-id-07, 21 October 868 2019, . 871 [I-D.ietf-tls-dtls13] 872 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 873 Datagram Transport Layer Security (DTLS) Protocol Version 874 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 875 dtls13-38, 29 May 2020, 876 . 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997, 881 . 883 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 884 Ciphersuites for Transport Layer Security (TLS)", 885 RFC 4279, DOI 10.17487/RFC4279, December 2005, 886 . 888 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 889 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 890 . 892 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 893 Housley, R., and W. Polk, "Internet X.509 Public Key 894 Infrastructure Certificate and Certificate Revocation List 895 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 896 . 898 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 899 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 900 May 2009, . 902 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 903 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 904 . 906 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 907 Verification of Domain-Based Application Service Identity 908 within Internet Public Key Infrastructure Using X.509 909 (PKIX) Certificates in the Context of Transport Layer 910 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 911 2011, . 913 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 914 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 915 2014, . 917 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 918 "Transport Layer Security (TLS) Application-Layer Protocol 919 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 920 July 2014, . 922 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 923 Code: The Implementation Status Section", BCP 205, 924 RFC 7942, DOI 10.17487/RFC7942, July 2016, 925 . 927 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 928 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 929 May 2017, . 931 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 932 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 933 . 935 [X.509] International Telephone and Telegraph Consultative 936 Committee, "ITU-T X.509 - Information technology - The 937 Directory: Public-key and attribute certificate 938 frameworks.", ISO/IEC 9594-8, CCITT Recommendation X.509, 939 October 2019. 941 [X.690] International Telephone and Telegraph Consultative 942 Committee, "ITU-T X.690 - Information technology - ASN.1 943 encoding rules: Specification of Basic Encoding Rules 944 (BER), Canonical Encoding Rules (CER) and Distinguished 945 Encoding Rules (DER)", ISO/IEC 8825-1, CCITT 946 Recommendation X.690, August 2015. 948 9.2. Informative References 950 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 951 Specification", RFC 2203, DOI 10.17487/RFC2203, September 952 1997, . 954 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 955 DOI 10.17487/RFC2818, May 2000, 956 . 958 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 959 of Named Entities (DANE) Transport Layer Security (TLS) 960 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 961 2012, . 963 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 964 Morris, J., Hansen, M., and R. Smith, "Privacy 965 Considerations for Internet Protocols", RFC 6973, 966 DOI 10.17487/RFC6973, July 2013, 967 . 969 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 970 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 971 December 2014, . 973 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 974 "Recommendations for Secure Use of Transport Layer 975 Security (TLS) and Datagram Transport Layer Security 976 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 977 2015, . 979 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 980 Memory Access Transport for Remote Procedure Call Version 981 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 982 . 984 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 985 "The Token Binding Protocol Version 1.0", RFC 8471, 986 DOI 10.17487/RFC8471, October 2018, 987 . 989 Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor 991 The ONC RPC protocol, as specified in [RFC5531], provides several 992 modes of security, traditionally referred to as "authentication 993 flavors". Some of these flavors provide much more than an 994 authentication service. We refer to these as authentication flavors, 995 security flavors, or simply, flavors. One of the earliest and most 996 basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of 997 [RFC5531] specifies AUTH_SYS. 999 AUTH_SYS assumes that the RPC client and server both use POSIX-style 1000 user and group identifiers (each user and group can be distinctly 1001 represented as a 32-bit unsigned integer). It also assumes that the 1002 client and server both use the same mapping of user and group to an 1003 integer. One user ID, one primary group ID, and up to 16 1004 supplemental group IDs are associated with each RPC request. The 1005 combination of these identifies the entity on the client that is 1006 making the request. 1008 A string identifies peers (hosts) in each RPC request. [RFC5531] 1009 does not specify any requirements for this string other than that is 1010 no longer than 255 octets. It does not have to be the same from 1011 request to request. Also, it does not have to match the DNS hostname 1012 of the sending host. For these reasons, even though most 1013 implementations fill in their hostname in this field, receivers 1014 typically ignore its content. 1016 Appendix A of [RFC5531] contains a brief explanation of security 1017 considerations: 1019 | It should be noted that use of this flavor of authentication does 1020 | not guarantee any security for the users or providers of a 1021 | service, in itself. The authentication provided by this scheme 1022 | can be considered legitimate only when applications using this 1023 | scheme and the network can be secured externally, and privileged 1024 | transport addresses are used for the communicating end-points (an 1025 | example of this is the use of privileged TCP/UDP ports in UNIX 1026 | systems -- note that not all systems enforce privileged transport 1027 | address mechanisms). 1029 It should be clear, therefore, that AUTH_SYS by itself (i.e., without 1030 strong client authentication) offers little to no communication 1031 security: 1033 1. It does not protect the confidentiality or integrity of RPC 1034 requests, users, or payloads, relying instead on "external" 1035 security. 1037 2. It does not provide authentication of RPC peer machines, other 1038 than inclusion of an unprotected domain name. 1040 3. The use of 32-bit unsigned integers as user and group identifiers 1041 is problematic because these data types are not cryptographically 1042 signed or otherwise verified by any authority. 1044 4. Because the user and group ID fields are not integrity-protected, 1045 AUTH_SYS does not provide non-repudiation. 1047 Acknowledgments 1049 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 1050 with Stunnel TLS" (https://www.linuxjournal.com/content/encrypting- 1051 nfsv4-stunnel-tls). His article inspired the mechanism described in 1052 the current document. 1054 Many thanks to Tigran Mkrtchyan and Rick Macklem for their work on 1055 prototype implementations and feedback on the current document. 1057 Thanks to Derrell Piper for numerous suggestions that improved both 1058 this simple mechanism and the current document's security-related 1059 discussion. 1061 Many thanks to Transport Area Director Magnus Westerlund for his 1062 sharp questions and careful reading of the final revisions of the 1063 current document. The text of Section 5.1.2 is mostly his 1064 contribution. 1066 The authors are additionally grateful to Bill Baker, David Black, 1067 Alan DeKok, Lars Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg 1068 Marsden, Alex McDonald, Justin Mazzola Paluska, Tom Talpey, and 1069 Martin Thomson for their input and support of this work. 1071 Finally, special thanks to NFSV4 Working Group Chair and document 1072 shepherd David Noveck, NFSV4 Working Group Chairs Spencer Shepler and 1073 Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for 1074 their guidance and oversight. 1076 Authors' Addresses 1078 Trond Myklebust 1079 Hammerspace Inc 1080 4300 El Camino Real Ste 105 1081 Los Altos, CA 94022 1082 United States of America 1084 Email: trond.myklebust@hammerspace.com 1086 Charles Lever (editor) 1087 Oracle Corporation 1088 United States of America 1090 Email: chuck.lever@oracle.com