idnits 2.17.1 draft-ietf-nfsv4-rpc-tls-02.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2019) is 1820 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 786 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 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: October 27, 2019 April 25, 2019 8 Remote Procedure Call Encryption By Default 9 draft-ietf-nfsv4-rpc-tls-02 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 October 27, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 69 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 5 70 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 71 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 72 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Base Transport Considerations . . . . . . . . . . . . . . 8 74 5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8 75 5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 9 76 5.1.3. Operation on an RDMA Transport . . . . . . . . . . . 9 77 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 9 78 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 9 79 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 11 80 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 11 81 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 11 82 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 83 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 12 84 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 12 85 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 12 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7.1. Limitations of an Opportunistic Approach . . . . . . . . 13 88 7.2. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . . . 13 89 7.3. Implications for AUTH_SYS . . . . . . . . . . . . . . . . 13 90 7.4. Multiple User Identity Realms . . . . . . . . . . . . . . 14 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 98 1. Introduction 100 In 2014 the IETF published [RFC7258] which recognized that 101 unauthorized observation of network traffic had become widespread and 102 was a subversive threat to all who make use of the Internet at large. 103 It strongly recommended that newly defined Internet protocols make a 104 real effort to mitigate monitoring attacks. Typically this 105 mitigation is done by encrypting data in transit. 107 The Remote Procedure Call version 2 protocol has been a Proposed 108 Standard for three decades (see [RFC5531] and its antecedants). 109 Eisler et al. first introduced an in-transit encryption mechanism for 110 RPC with RPCSEC GSS over twenty years ago [RFC2203]. However, 111 experience has shown that RPCSEC GSS can be difficult to deploy: 113 o Per-client deployment and administrative costs are not scalable. 114 Keying material must be provided for each RPC client, including 115 transient clients. 117 o Parts of each RPC header remain in clear-text, and can constitute 118 a significant security exposure. 120 o Host identity management and user identity management must be 121 carried out in the same security realm. In certain environments, 122 different authorities might be responsible for provisioning client 123 systems versus provisioning new users. 125 o On-host cryptographic manipulation of data payloads can exact a 126 significant CPU and memory bandwidth cost on RPC peers. Offloadng 127 does not appear to be practical using GSS privacy since each 128 message is encrypted using its own key based on the issuing RPC 129 user. 131 However strong a privacy service is, it cannot provide any security 132 if the challenges of using it result in it not being used at all. 134 An alternative approach is to employ a transport layer security 135 mechanism that can protect the privacy of each RPC connection 136 transparently to RPC and Upper Layer protocols. The Transport Layer 137 Security protocol [RFC8446] (TLS) is a well-established Internet 138 building block that protects many common Internet protocols such as 139 the Hypertext Transport Protocol (http) [RFC2818]. 141 Encrypting at the RPC transport layer enables several significant 142 benefits. 144 Encryption By Default 145 In-transit encryption by itself may be enabled without additional 146 administrative actions such as identifying client systems to a 147 trust authority, generating additional key material, or 148 provisioning a secure network tunnel. 150 Protection of Existing Protocols 151 The imposition of encryption at the transport layer protects any 152 Upper Layer protocol that employs RPC, without alteration of that 153 protocol. RPC transport layer encryption can protect recent 154 versions of NFS such as NFS version 4.2 [RFC7862] and indeed 155 legacy NFS versions such as NFS version 3 [RFC1813], and NFS side- 156 band protocols such as the MNT protocol [RFC1813]. 158 Decoupled User and Host Identities 159 TLS can be used to authenticate peer hosts while other security 160 mechanisms can handle user authentictation. Cryptographic 161 authentication of hosts can be provided while still using simpler 162 user authentication flavors such as AUTH_SYS. 164 Encryption Offload 165 Whereas hardware support for GSS privacy has not appeared in the 166 marketplace, the use of a well-established transport encryption 167 mechanism that is also employed by other very common network 168 protocols makes it likely that a hardware encryption 169 implementation will be available to offload encryption and 170 decryption. A single key protects all messages associated with 171 one TLS session. 173 Securing AUTH_SYS 174 Most critically, several security issues inherent in the current 175 widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs 176 generated by an unauthenticated client) can be significantly 177 ameliorated. 179 This document proposes the use of TLS to introduce an opportunistic 180 security approach, as defined by [RFC7435], to RPC. As long as there 181 is still a significant fleet of RPC deployments that lack support for 182 TLS, an opportunistic approach can help eliminate the challenges that 183 prevent the broad use of encryption with RPC (and its most popular 184 consumer, NFS) until a more thorough approach can be provided. 186 2. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 3. Terminology 196 This document adopts the terminology introduced in Section 3 of 197 [RFC6973] and assumes a working knowledge of the Remote Procedure 198 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 199 Security (TLS) version 1.3 protocol [RFC8446]. 201 Note also that the NFS community uses the term "privacy" where other 202 Internet communities use "confidentiality". In this document the two 203 terms are synonymous. 205 We cleave to the convention that a "client" is a network host that 206 actively initiates an association, and a "server" is a network host 207 that passively accepts an association request. 209 RPC documentation historically refers to the authentication of a 210 connecting host as "machine authentication" or "host authentication". 211 TLS documentation refers to the same as "peer authentication". In 212 this document there is little distinction between these terms. 214 The term "user authentication" in this document refers specifically 215 to the RPC caller's credential, provided in the "cred" and "verf" 216 fields in each RPC Call. 218 4. RPC-Over-TLS in Operation 220 4.1. Discovering Server-side TLS Support 222 The mechanism described in this document interoperates fully with RPC 223 implementations that do not support TLS. The use of TLS is 224 automatically disabled in these cases. 226 To achieve this, we introduce a new RPC authentication flavor called 227 AUTH_TLS. This new flavor is used to signal that the client wants to 228 initiate TLS negotiation if the server supports it. Except for the 229 modifications described in this section, the RPC protocol is largely 230 unaware of security encapsulation. 232 234 enum auth_flavor { 235 AUTH_NONE = 0, 236 AUTH_SYS = 1, 237 AUTH_SHORT = 2, 238 AUTH_DH = 3, 239 AUTH_KERB = 4, 240 AUTH_RSA = 5, 241 RPCSEC_GSS = 6, 242 AUTH_TLS = 7, 244 /* and more to be defined */ 245 }; 247 249 The length of the opaque data constituting the credential sent in the 250 call message MUST be zero. The verifier accompanying the credential 251 MUST be an AUTH_NONE verifier of length zero. 253 The flavor value of the verifier received in the reply message from 254 the server MUST be AUTH_NONE. The bytes of the verifier's string 255 encode the fixed ASCII characters "STARTTLS". 257 When an RPC client is ready to begin sending traffic to a server, it 258 starts with a NULL RPC request with an auth_flavor of AUTH_TLS. The 259 NULL request is made to the same port as if TLS were not in use. 261 The RPC server can respond in one of three ways: 263 o If the RPC server does not recognise the AUTH_TLS authentication 264 flavor, it responds with a reject_stat of AUTH_ERROR. The RPC 265 client then knows that this server does not support TLS. 267 o If the RPC server accepts the NULL RPC procedure, but fails to 268 return an AUTH_NONE verifier containing the string "STARTTLS", the 269 RPC client knows that this server does not support TLS. 271 o If the RPC server accepts the NULL RPC procedure, and returns an 272 AUTH_NONE verifier containing the string "STARTTLS", the RPC 273 client SHOULD send a STARTTLS. 275 Once the TLS handshake is complete, the RPC client and server will 276 have established a secure channel for communicating. The client MUST 277 switch to a security flavor other than AUTH_TLS within that channel, 278 presumably after negotiating down redundant RPCSEC_GSS privacy and 279 integrity services and applying channel binding [RFC7861]. 281 If TLS negotiation fails for any reason -- say, the RPC server 282 rejects the certificate presented by the RPC client, or the RPC 283 client fails to authenticate the RPC server -- the RPC client reports 284 this failure to the calling application the same way it would report 285 an AUTH_ERROR rejection from the RPC server. 287 If an RPC client attempts to use AUTH_TLS for anything other than the 288 NULL RPC procedure, the RPC server MUST respond with a reject_stat of 289 AUTH_ERROR. If the client sends a STARTTLS after it has sent other 290 non-encrypted RPC traffic or after a TLS session has already been 291 negotiated, the server MUST silently discard it. 293 4.2. Authentication 295 Both RPC and TLS have their own variants of authentication, and there 296 is some overlap in capability. The goal of interoperability with 297 implementations that do not support TLS requires that we limit the 298 combinations that are allowed and precisely specify the role that 299 each layer plays. We also want to handle TLS such that an RPC 300 implementation can make the use of TLS invisible to existing RPC 301 consumer applications. 303 Depending on its configuration, an RPC server MAY request a TLS peer 304 identity from each client upon first contact. This permits two 305 different modes of deployment: 307 Server-only Host Authentication 308 A server possesses a unique global identity (e.g., a certificate 309 that is signed by a well-known trust anchor) while its clients are 310 anonymous (i.e., present no identifier). In this situation, the 311 client SHOULD authenticate the server host using the presented TLS 312 identity, but the server cannot authenticate clients. 314 Mutual Host Authentication 315 In this type of deployment, both the server and its clients 316 possess unique identities (e.g., certificates). As part of the 317 TLS handshake, both peers SHOULD authenticate using the presented 318 TLS identities. Should authentication of either peer fail, or 319 should authorization based on those identities block access to the 320 server, the client association MAY be rejected. 322 In either of these modes, RPC user authentication is not affected by 323 the use of transport layer security. Once a TLS session is 324 established, the server MUST NOT utilize the client peer's TLS 325 identity for the purpose of authorizing individual RPC requests. 327 4.2.1. Using TLS with RPCSEC GSS 329 RPCSEC GSS can provide per-request integrity or privacy (also known 330 as confidentiality) services. When operating over a TLS session, 331 these services become redundant. Each RPC implementation is 332 responsible for using channel binding for detecting when GSS 333 integrity or privacy is unnecessary and can therefore be disabled. 334 See Section 2.5 of [RFC7861] for details. 336 Note that a GSS service principal is still required on the server, 337 and mutual GSS authentication of server and client still occurs after 338 the TLS session is established. 340 5. TLS Requirements 342 When a TLS session is negotiated for the purpose of transporting RPC, 343 the following restrictions apply: 345 o Implementations MUST NOT negotiate TLS versions prior to v1.3 346 [RFC8446]. Support for mandatory-to-implement ciphersuites for 347 the negotiated TLS version is REQUIRED. 349 o Implementations MUST support certificate-based mutual 350 authentication. Support for TLS-PSK mutual authentication 351 [RFC4279] is OPTIONAL. See Section 4.2 for further details. 353 o Negotiation of a ciphersuite providing for confidentiality as well 354 as integrity protection is REQUIRED. Support for and negotiation 355 of compression is OPTIONAL. 357 5.1. Base Transport Considerations 359 5.1.1. Operation on TCP 361 RPC over TCP is protected by using TLS [RFC8446]. As soon as a 362 client completes the TCP handshake, it uses the mechanism described 363 in Section 4.1 to discover TLS support and then negotiate a TLS 364 session. 366 After the TLS session is established, all traffic on the connection 367 is encapsulated and protected until the TLS session is terminated. 368 This includes reverse-direction operations (i.e., RPC requests 369 initiated on the server-end of the connection). A reverse-direction 370 operation sent on a connection outside of its existing TLS session 371 MUST fail with a reject_stat of AUTH_ERROR. 373 An RPC peer terminates a TLS session by sending a TLS closure alert, 374 or by closing the underlying TCP socket. After TLS session 375 termination, any subsequent RPC request over the same connection MUST 376 fail with a reject_stat of AUTH_ERROR. 378 5.1.2. Operation on UDP 380 RPC over UDP is protected using DTLS [RFC6347]. As soon as a client 381 initializes a socket for use with an unfamiliar server, it uses the 382 mechanism described in Section 4.1 to discover DTLS support and then 383 negotiate a DTLS session. Connected operation is RECOMMENDED. 385 Using a DTLS transport does not introduce reliable or in-order 386 semantics to RPC on UDP. Also, DTLS does not support fragmentation 387 of RPC messages. One RPC message fits in a single DTLS datagram. 388 DTLS encapsulation has overhead which reduces the effective Path MTU 389 (PMTU) and thus the maximum RPC payload size. 391 DTLS does not detect STARTTLS replay. A DTLS session can be 392 terminated by sending a TLS closure alert. Subsequent RPC messages 393 passing between the client and server will no longer be protected 394 until a new TLS session is established. 396 5.1.3. Operation on an RDMA Transport 398 RPC-over-RDMA can make use of Transport Layer Security below the RDMA 399 transport layer [RFC8166]. The exact mechanism is not within the 400 scope of this document. 402 5.2. TLS Peer Authentication 404 Peer authentication can be performed by TLS using any of the 405 following mechanisms: 407 5.2.1. X.509 Certificates Using PKIX trust 409 Implementations are REQUIRED to support this mechanism. In this 410 mode, an RPC peer is uniquely identified by the tuple (serial number 411 of presented certificate;Issuer). 413 o Implementations MUST allow the configuration of a list of trusted 414 Certification Authorities for incoming connections. 416 o Certificate validation MUST include the verification rules as per 417 [RFC5280]. 419 o Implementations SHOULD indicate their trusted Certification 420 Authorities (CAs). 422 o Peer validation always includes a check on whether the locally 423 configured expected DNS name or IP address of the server that is 424 contacted matches its presented certificate. DNS names and IP 425 addresses can be contained in the Common Name (CN) or 426 subjectAltName entries. For verification, only one of these 427 entries is to be considered. The following precedence applies: 428 for DNS name validation, subjectAltName:DNS has precedence over 429 CN; for IP address validation, subjectAltName:iPAddr has 430 precedence over CN. Implementors of this specification are 431 advised to read Section 6 of [RFC6125] for more details on DNS 432 name validation. 434 o Implementations MAY allow the configuration of a set of additional 435 properties of the certificate to check for a peer's authorization 436 to communicate (e.g., a set of allowed values in 437 subjectAltName:URI or a set of allowed X509v3 Certificate 438 Policies). 440 o When the configured trust base changes (e.g., removal of a CA from 441 the list of trusted CAs; issuance of a new CRL for a given CA), 442 implementations MAY renegotiate the TLS session to reassess the 443 connecting peer's continued authorization. 445 Authenticating a connecting entity does not mean the RPC server 446 necessarily wants to communicate with that client. For example, if 447 the Issuer is not in a trusted set of Issuers, the RPC server may 448 decline to perform RPC transactions with this client. 449 Implementations that want to support a wide variety of trust models 450 should expose as many details of the presented certificate to the 451 administrator as possible so that the trust model can be implemented 452 by the administrator. As a suggestion, at least the following 453 parameters of the X.509 client certificate should be exposed: 455 o Originating IP address 457 o Certificate Fingerprint 459 o Issuer 461 o Subject 463 o all X509v3 Extended Key Usage 465 o all X509v3 Subject Alternative Name 467 o all X509v3 Certificate Policies 469 5.2.2. X.509 Certificates Using Fingerprints 471 This mechanism is OPTIONAL to implement. In this mode, an RPC peer 472 is uniquely identified by the fingerprint of the presented 473 certificate. 475 Implementations SHOULD allow the configuration of a list of trusted 476 certificates, identified via fingerprint of the DER encoded 477 certificate octets. Implementations MUST support SHA-1 as the hash 478 algorithm for the fingerprint. To prevent attacks based on hash 479 collisions, support for a more contemporary hash function, such as 480 SHA-256, is RECOMMENDED. 482 5.2.3. Pre-Shared Keys 484 This mechanism is OPTIONAL to implement. In this mode, an RPC peer 485 is uniquely identified by key material that has been shared out-of- 486 band or by a previous TLS-protected connection (see [RFC8446] 487 Section 2.2). At least the following parameters of the TLS 488 connection should be exposed: 490 o Originating IP address 492 o TLS Identifier 494 5.2.4. Token Binding 496 This mechanism is OPTIONAL to implement. In this mode, an RPC peer 497 is uniquely identified by a token. 499 Versions of TLS subsequent to TLS 1.2 feature a token binding 500 mechanism which is nominally more secure than using certificates. 501 This is discussed in further detail in [RFC8471]. 503 6. Implementation Status 505 This section records the status of known implementations of the 506 protocol defined by this specification at the time of posting of this 507 Internet-Draft, and is based on a proposal described in [RFC7942]. 508 The description of implementations in this section is intended to 509 assist the IETF in its decision processes in progressing drafts to 510 RFCs. 512 Please note that the listing of any individual implementation here 513 does not imply endorsement by the IETF. Furthermore, no effort has 514 been spent to verify the information presented here that was supplied 515 by IETF contributors. This is not intended as, and must not be 516 construed to be, a catalog of available implementations or their 517 features. Readers are advised to note that other implementations may 518 exist. 520 6.1. DESY NFS server 522 Organization: DESY 524 URL: https://desy.de 526 Maturity: Prototype software based on early versions of this 527 document. 529 Coverage: The bulk of this specification is implemented. The use of 530 DTLS functionality is not implemented. 532 Licensing: Freely distributable with acknowledgment. 534 Implementation experience: No comments from implementors. 536 6.2. Hammerspace NFS server 538 Organization: Hammerspace 540 URL: https://hammerspace.com 542 Maturity: Prototype software based on early versions of this 543 document. 545 Coverage: The bulk of this specification is implemented. The use of 546 DTLS functionality is not implemented. 548 Licensing: Proprietary 550 Implementation experience: No comments from implementors. 552 6.3. Linux NFS server and client 554 Organization: The Linux Foundation 556 URL: https://www.kernel.org 558 Maturity: Prototype software based on early versions of this 559 document. 561 Coverage: The bulk of this specification is implemented. The use of 562 DTLS functionality is not implemented. 564 Licensing: GPLv2 565 Implementation experience: No comments from implementors. 567 7. Security Considerations 569 One purpose of the mechanism described in this document is to protect 570 RPC-based applications against threats to the privacy of RPC 571 transactions and RPC user identities. A taxonomy of these threats 572 appears in Section 5 of [RFC6973]. In addition, Section 6 of 573 [RFC7525] contains a detailed discussion of technologies used in 574 conjunction with TLS. Implementers should familiarize themselves 575 with these materials. 577 7.1. Limitations of an Opportunistic Approach 579 A range of options is allowed by the opportunistic approach described 580 in this document, from "no peer authentication or encryption" to 581 "server-only authentication with encryption" to "mutual 582 authentication with encryption". The security level may indeed be 583 selected without user intervention based on a policy. 584 Implementations must take care to accurately represent to all RPC 585 consumers the level of security that is actually in effect. 587 7.2. STRIPTLS Attacks 589 A classic form of attack on network protocols that initiate an 590 association in plain-text to discover support for TLS is a man-in- 591 the-middle that alters the plain-text handshake to make it appear as 592 though TLS support is not available on one or both peers. Clients 593 implementers can choose from the following to mitigate STRIPTLS 594 attacks: 596 o Client security policy can be configured to require that a TLS 597 session is established on every connection. If an attacker spoofs 598 the handshake, the client disconnects and reports the problem. 599 This approach is RECOMMENDED. 601 o A TLSA record [RFC6698] can alert clients that TLS is expected to 602 work, and provides a binding of hostname to x.509 identity. If 603 TLS cannot be negotiated or authentication fails, the client 604 disconnects and reports the problem. 606 7.3. Implications for AUTH_SYS 608 Ever since the IETF NFSV4 Working Group took over the maintenance of 609 the NFSv4 family of protocols (currently specified in [RFC7530], 610 [RFC5661], and [RFC7863], among others), it has encouraged the use of 611 RPCSEC GSS rather than AUTH_SYS. For various reasons, AUTH_SYS 612 continues to be the primary authentication mechanism deployed by NFS 613 administrators. As a result, NFS security remains in an 614 unsatisfactory state. 616 A deeper purpose of this document is to attempt to address some of 617 the shortcomings of AUTH_SYS so that, where it has been impractical 618 to deploy RPCSEC GSS, better NFSv4 security can nevertheless be 619 achieved. 621 When AUTH_SYS is used with TLS and no client certificate is 622 available, the RPC server is still acting on RPC requests for which 623 there is no trustworthy authentication. In-transit traffic is 624 protected, but the client itself can still misrepresent user identity 625 without detection. This is an improvement from AUTH_SYS without 626 encryption, but it leaves a critical security exposure. 628 Therefore, the RECOMMENDED deployment mode is that clients have 629 certificate material configured and used so that servers can have a 630 degree of trust that clients are acting responsibly. 632 7.4. Multiple User Identity Realms 634 In circumstances where the RPC users on a single client belong to 635 multiple distinct security realms, the client MUST establish an 636 independent TLS session for each user identity realm. 638 8. IANA Considerations 640 In accordance with Section 6 of [RFC7301], the authors request that 641 IANA allocate the following value in the "Application-Layer Protocol 642 Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string 643 identifies SunRPC when used over TLS. 645 Protocol: 646 SunRPC 648 Identification Sequence: 649 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 651 Reference: 652 RFC-TBD 654 9. References 656 9.1. Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, 660 DOI 10.17487/RFC2119, March 1997, 661 . 663 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 664 Ciphersuites for Transport Layer Security (TLS)", 665 RFC 4279, DOI 10.17487/RFC4279, December 2005, 666 . 668 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 669 Housley, R., and W. Polk, "Internet X.509 Public Key 670 Infrastructure Certificate and Certificate Revocation List 671 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 672 . 674 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 675 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 676 May 2009, . 678 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 679 Verification of Domain-Based Application Service Identity 680 within Internet Public Key Infrastructure Using X.509 681 (PKIX) Certificates in the Context of Transport Layer 682 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 683 2011, . 685 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 686 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 687 January 2012, . 689 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 690 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 691 2014, . 693 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 694 "Transport Layer Security (TLS) Application-Layer Protocol 695 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 696 July 2014, . 698 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 699 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 700 November 2016, . 702 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 703 Code: The Implementation Status Section", BCP 205, 704 RFC 7942, DOI 10.17487/RFC7942, July 2016, 705 . 707 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 708 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 709 May 2017, . 711 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 712 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 713 . 715 9.2. Informative References 717 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 718 Version 3 Protocol Specification", RFC 1813, 719 DOI 10.17487/RFC1813, June 1995, 720 . 722 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 723 Specification", RFC 2203, DOI 10.17487/RFC2203, September 724 1997, . 726 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 727 DOI 10.17487/RFC2818, May 2000, 728 . 730 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 731 "Network File System (NFS) Version 4 Minor Version 1 732 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 733 . 735 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 736 of Named Entities (DANE) Transport Layer Security (TLS) 737 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 738 2012, . 740 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 741 Morris, J., Hansen, M., and R. Smith, "Privacy 742 Considerations for Internet Protocols", RFC 6973, 743 DOI 10.17487/RFC6973, July 2013, 744 . 746 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 747 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 748 December 2014, . 750 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 751 "Recommendations for Secure Use of Transport Layer 752 Security (TLS) and Datagram Transport Layer Security 753 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 754 2015, . 756 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 757 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 758 March 2015, . 760 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 761 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 762 November 2016, . 764 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 765 Version 2 External Data Representation Standard (XDR) 766 Description", RFC 7863, DOI 10.17487/RFC7863, November 767 2016, . 769 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 770 Memory Access Transport for Remote Procedure Call Version 771 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 772 . 774 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 775 "The Token Binding Protocol Version 1.0", RFC 8471, 776 DOI 10.17487/RFC8471, October 2018, 777 . 779 9.3. URIs 781 [1] https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls 783 Acknowledgments 785 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 786 with Stunnel TLS" [1]. His article inspired the mechanism described 787 in this document. 789 Many thanks to Tigran Mkrtchyan for his work on the DESY prototype 790 and resulting feedback to this document. 792 The authors are grateful to Bill Baker, David Black, Alan DeKok, Lars 793 Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg Marsden, Alex 794 McDonald, David Noveck, Justin Mazzola Paluska, Tom Talpey, and 795 Martin Thomson for their input and support of this work. 797 Lastly, special thanks go to Transport Area Director Magnus 798 Westerlund, NFSV4 Working Group Chairs Spencer Shepler and Brian 799 Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their 800 guidance and oversight. 802 Authors' Addresses 804 Trond Myklebust 805 Hammerspace Inc 806 4300 El Camino Real Ste 105 807 Los Altos, CA 94022 808 United States of America 810 Email: trond.myklebust@hammerspace.com 812 Charles Lever (editor) 813 Oracle Corporation 814 United States of America 816 Email: chuck.lever@oracle.com