idnits 2.17.1 draft-ietf-nfsv4-rpc-tls-00.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 (March 25, 2019) is 1857 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 690 ** 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: September 26, 2019 March 25, 2019 8 Remote Procedure Call Encryption By Default 9 draft-ietf-nfsv4-rpc-tls-00 11 Abstract 13 This document describes a mechanism that enables encryption of in- 14 transit Remote Procedure Call (RPC) transactions with minimal 15 administrative overhead and full interoperation with ONC RPC 16 implementations that do not support this mechanism. This document 17 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 September 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 4 69 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 5 70 4.2. RPC Authentication . . . . . . . . . . . . . . . . . . . 6 71 4.2.1. Server-only Host Authentication . . . . . . . . . . . 6 72 4.2.2. Mutual Host Authentication . . . . . . . . . . . . . 7 73 4.2.3. Advanced Forms of RPC Authentication . . . . . . . . 7 74 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Connection Types . . . . . . . . . . . . . . . . . . . . 8 76 5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8 77 5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 8 78 5.1.3. Operation on an RDMA Transport . . . . . . . . . . . 8 79 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 8 80 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 8 81 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 10 82 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 10 83 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 10 84 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 85 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 11 86 6.2. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 11 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 7.1. Implications for AUTH_SYS . . . . . . . . . . . . . . . . 12 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 9.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 In 2014 the IETF published [RFC7258] which recognized that 99 unauthorized observation of network traffic had become widespread and 100 was a subversive threat to all who make use of the Internet at large. 101 It strongly recommended that newly defined Internet protocols make a 102 real effort to mitigate monitoring attacks. Typically this 103 mitigation is done by encrypting data in transit. 105 The Remote Procedure Call version 2 protocol has been a Proposed 106 Standard for three decades (see [RFC5531] and its antecedants). 107 Eisler et al. first introduced an in-transit encryption mechanism for 108 RPC with RPCSEC GSS over twenty years ago [RFC2203]. However, 109 experience has shown that RPCSEC GSS is difficult to deploy: 111 o Per-client deployment and administrative costs are not scalable. 112 Keying material must be provided for each RPC client, including 113 transient clients. 115 o Parts of the RPC header remain in clear-text, and can constitute a 116 significant security exposure. 118 o On-host cryptographic manipulation of data payloads can exact a 119 significant CPU cost on both clients and the server. 121 o Host identity management and user identity management must be 122 carried out in the same security realm. In certain environments, 123 different authorities might be responsible for provisioning client 124 systems versus provisioning new users. 126 However strong a privacy service is, it can not provide any security 127 if the difficulties of deploying and using it result in it not being 128 used at all. 130 An alternative approach is to employ a transport layer security 131 mechanism that can protect the privacy of each RPC connection 132 transparently to RPC and Upper Layer protocols. The Transport Layer 133 Security protocol [RFC8446] (TLS) is a well-established Internet 134 building block that protects many common Internet protocols such as 135 the Hypertext Transport Protocol (http) [RFC2818]. 137 Encrypting at the RPC transport layer enables several significant 138 benefits. 140 Encryption By Default 141 In-transit encryption can be enabled without additional 142 administrative actions such as identifying the host system to a 143 trust authority, generating additional key material, or 144 provisioning a secure network tunnel. 146 Protection of Existing Protocols 147 The imposition of encryption at the transport layer protects any 148 Upper Layer protocol that employs RPC, without alteration of that 149 protocol. RPC transport layer encryption can protect recent 150 versions of NFS such as NFS version 4.2 [RFC7862] and indeed 151 legacy NFS versions such as NFS version 3 [RFC1813] and NFS side- 152 band protocols such as the MNT protocol [RFC1813]. 154 Decoupled User and Host Identities 155 TLS can be used to authenticate hosts using certificates while 156 other security mechanisms can handle user authentictation. 158 Encryption Offload 159 The use of a well-established transport encryption mechanism that 160 is also employed by other very common network protocols makes it 161 likely that a hardware encryption implementation will be available 162 to offload encryption and decryption. 164 2. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 3. Terminology 174 This document adopts the terminology introduced in Section 3 of 175 [RFC6973] and assumes a working knowledge of the Remote Procedure 176 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 177 Security (TLS) version 1.3 protocol [RFC8446]. 179 Note also that the NFS community uses the term "privacy" where other 180 Internet communities use "confidentiality". In this document the two 181 terms are synonymous. 183 4. RPC-Over-TLS in Operation 185 In this section we cleave to the convention that a "client" is the 186 peer host that actively initiates a connection, and a "server" is the 187 peer host that passively accepts a connection request. 189 4.1. Discovering Server-side TLS Support 191 The mechanism described in this document interoperates fully with RPC 192 implementations that do not support TLS. The use of TLS is 193 automatically disabled in these cases. 195 To achieve this, we introduce a new RPC authentication flavor called 196 AUTH_TLS. This new flavor is used to signal that the client wants to 197 initiate TLS negotiation if the server supports it. Except for the 198 modifications described in this section, the RPC protocol is largely 199 unaware of security encapsulation. 201 203 enum auth_flavor { 204 AUTH_NONE = 0, 205 AUTH_SYS = 1, 206 AUTH_SHORT = 2, 207 AUTH_DH = 3, 208 AUTH_KERB = 4, 209 AUTH_RSA = 5, 210 RPCSEC_GSS = 6, 211 AUTH_TLS = 7, 213 /* and more to be defined */ 214 }; 216 218 The length of the opaque data constituting the credential sent in the 219 call message MUST be zero. The verifier accompanying the credential 220 MUST be an AUTH_NONE verifier of length zero. 222 The flavor value of the verifier received in the reply message from 223 the server MUST be AUTH_NONE. The bytes of the verifier's string 224 encode the fixed ASCII characters "STARTTLS". 226 When an RPC client is ready to begin sending traffic to a server, it 227 starts with a NULL RPC request with an auth_flavor of AUTH_TLS. The 228 NULL request is made to the same port as if TLS were not in use. 230 The RPC server can respond in one of three ways: 232 o If the RPC server does not recognise the AUTH_TLS authentication 233 flavor, it responds with a reject_stat of AUTH_ERROR. The RPC 234 client then knows that this server does not support TLS. 236 o If the RPC server accepts the NULL RPC procedure, but fails to 237 return an AUTH_NONE verifier containing the string "STARTTLS", the 238 RPC client knows that this server does not support TLS. 240 o If the RPC server accepts the NULL RPC procedure, and returns an 241 AUTH_NONE verifier containing the string "STARTTLS", the RPC 242 client SHOULD proceed with TLS negotiation. 244 If an RPC client attempts to use AUTH_TLS for anything other than the 245 NULL RPC procedure, the RPC server responds with a reject_stat of 246 AUTH_ERROR. In addition, a client MUST NOT attempt a TLS handshake 247 after the initial exchange. 249 Once the TLS handshake is complete, the RPC client and server will 250 have established a secure channel for communicating and can proceed 251 to use standard security flavors within that channel, presumably 252 after negotiating down the irrelevant RPCSEC_GSS privacy and 253 integrity services and applying channel binding [RFC7861]. 255 If TLS negotiation fails for any reason -- say, the RPC server 256 rejects the certificate presented by the RPC client, or the RPC 257 client fails to authenticate the RPC server -- the RPC client reports 258 this failure to the calling application the same way it would report 259 an AUTH_ERROR rejection from the RPC server. 261 4.2. RPC Authentication 263 Both RPC and TLS have their own variants of authentication, and there 264 is some overlap in capability. The goal of interoperability with 265 implementations that do not support TLS requires that we limit the 266 combinations that are allowed and precisely specify the role that 267 each layer plays. We also want to handle TLS such that an RPC 268 implementation can make the use of TLS invisible to existing RPC 269 consumer applications. 271 Toward these ends, there are two deployment modes. 273 4.2.1. Server-only Host Authentication 275 In a basic deployment, a server possesses a unique global identity 276 (e.g., a certificate that is self-signed or signed by a well-known 277 trust anchor) while its clients are anonymous (i.e., present no 278 identifier). In this situation, the client SHOULD authenticate the 279 server host using the presented TLS identity, but the server cannot 280 authenticate connecting clients. Here, a TLS session is established 281 and the RPC requests in transit carry user and group identities 282 according to the conventions of the RPC protocol. 284 4.2.2. Mutual Host Authentication 286 In this type of deployment, both the server and its clients possess 287 unique identities (e.g., certificates). As part of the TLS 288 handshake, both peer hosts SHOULD authenticate using the presented 289 TLS identities. Should authentication of either peer fail, or should 290 authorization based on those identities block access to the server, 291 the connection MAY be rejected. However, once a TLS session is 292 established, the server MUST NOT utilize TLS identity for the purpose 293 of authorizing RPC requests. 295 In some cases, a client might choose to present a certificate that 296 represents a user rather than one that is bound to the client host. 297 As above, the server MUST NOT utilize this identity for the purpose 298 of authorizing RPC requests. The TLS identities of the peer hosts 299 are fully independent of RPC user identities. 301 4.2.3. Advanced Forms of RPC Authentication 303 RPCSEC GSS can provide integrity or privacy (also known as 304 confidentiality) services. When operating over a TLS session, these 305 services become redundant. Each RPC implementation is responsible 306 for using channel binding for detecting when GSS integrity or privacy 307 is unnecessary and can therefore be disabled. See Section 2.5 of 308 [RFC7861] for details. 310 Note that a GSS service principal is still required on the server, 311 and mutual GSS authentication of server and client still occurs after 312 the TLS session is established. 314 5. TLS Requirements 316 When a TLS session is negotiated for the purpose of transporting RPC, 317 the following restrictions apply: 319 o Implementations MUST NOT negotiate TLS versions prior to v1.3 320 [RFC8446]. Support for mandatory-to-implement ciphersuites for 321 the negotiated TLS version is REQUIRED. 323 o Implementations MUST support certificate-based mutual 324 authentication. Support for TLS-PSK mutual authentication 325 [RFC4279] is OPTIONAL. See Section 4.2 for further details. 327 o Negotiation of a ciphersuite providing for confidentiality as well 328 as integrity protection is REQUIRED. Support for and negotiation 329 of compression is OPTIONAL. 331 5.1. Connection Types 333 5.1.1. Operation on TCP 335 RPC over TCP is protected by using TLS [RFC8446]. As soon as a 336 client completes the TCP handshake, it uses the mechanism described 337 in Section 4.1 to discover TLS support and then negotiate a TLS 338 session. 340 5.1.2. Operation on UDP 342 RPC over UDP is protected using DTLS [RFC6347]. As soon as a client 343 initializes a socket for use with an unfamiliar server, it uses the 344 mechanism described in Section 4.1 to discover DTLS support and then 345 negotiate a DTLS session. Connected operation is RECOMMENDED. 347 Using a DTLS transport does not introduce reliable or in-order 348 semantics to RPC on UDP. Also, DTLS does not support fragmentation 349 of RPC messages. One RPC message fits in a single DTLS datagram. 350 DTLS encapsulation has overhead which reduces the effective Path MTU 351 (PMTU) and thus the maximum RPC payload size. 353 5.1.3. Operation on an RDMA Transport 355 RPC-over-RDMA can make use of Transport Layer Security below the RDMA 356 transport layer [RFC8166]. The exact mechanism is not within the 357 scope of this document. 359 5.2. TLS Peer Authentication 361 Peer authentication can be performed by TLS using any of the 362 following mechanisms: 364 5.2.1. X.509 Certificates Using PKIX trust 366 Implementations are REQUIRED to support this mechanism. In this 367 mode, an RPC client is uniquely identified by the tuple (serial 368 number of presented client certificate;Issuer). 370 o Implementations MUST allow the configuration of a list of trusted 371 Certification Authorities for incoming connections. 373 o Certificate validation MUST include the verification rules as per 374 [RFC5280]. 376 o Implementations SHOULD indicate their trusted Certification 377 Authorities (CAs). 379 o Peer validation always includes a check on whether the locally 380 configured expected DNS name or IP address of the server that is 381 contacted matches its presented certificate. DNS names and IP 382 addresses can be contained in the Common Name (CN) or 383 subjectAltName entries. For verification, only one of these 384 entries is to be considered. The following precedence applies: 385 for DNS name validation, subjectAltName:DNS has precedence over 386 CN; for IP address validation, subjectAltName:iPAddr has 387 precedence over CN. Implementors of this specification are 388 advised to read Section 6 of [RFC6125] for more details on DNS 389 name validation. 391 o Implementations MAY allow the configuration of a set of additional 392 properties of the certificate to check for a peer's authorization 393 to communicate (e.g., a set of allowed values in 394 subjectAltName:URI or a set of allowed X509v3 Certificate 395 Policies). 397 o When the configured trust base changes (e.g., removal of a CA from 398 the list of trusted CAs; issuance of a new CRL for a given CA), 399 implementations MAY renegotiate the TLS session to reassess the 400 connecting peer's continued authorization. 402 Having identified a connecting entity does not mean the RPC server 403 necessarily wants to communicate with that client. For example, if 404 the Issuer is not in a trusted set of Issuers, the RPC server may 405 decline to perform RPC transactions with this client. 406 Implementations that want to support a wide variety of trust models 407 should expose as many details of the presented certificate to the 408 administrator as possible so that the trust model can be implemented 409 by the administrator. As a suggestion, at least the following 410 parameters of the X.509 client certificate should be exposed: 412 o Originating IP address 414 o Certificate Fingerprint 416 o Issuer 418 o Subject 420 o all X509v3 Extended Key Usage 422 o all X509v3 Subject Alternative Name 424 o all X509v3 Certificate Policies 426 5.2.2. X.509 Certificates Using Fingerprints 428 This mechanism is OPTIONAL to implement. In this mode, an RPC client 429 is uniquely identified by the fingerprint of the presented client 430 certificate. 432 Implementations SHOULD allow the configuration of a list of trusted 433 certificates, identified via fingerprint of the DER encoded 434 certificate octets. Implementations MUST support SHA-1 as the hash 435 algorithm for the fingerprint. To prevent attacks based on hash 436 collisions, support for a more contemporary hash function, such as 437 SHA-256, is RECOMMENDED. 439 5.2.3. Pre-Shared Keys 441 This mechanism is OPTIONAL to implement. In this mode, an RPC client 442 is uniquely identified by its TLS identifier. At least the following 443 parameters of the TLS connection should be exposed: 445 o Originating IP address 447 o TLS Identifier 449 5.2.4. Token Binding 451 This mechanism is OPTIONAL to implement. In this mode, an RPC client 452 is uniquely identified by a token. 454 Versions of TLS subsequent to TLS 1.2 feature a token binding 455 mechanism which is nominally more secure than using certificates. 456 This is discussed in further detail in [RFC8471]. 458 6. Implementation Status 460 This section records the status of known implementations of the 461 protocol defined by this specification at the time of posting of this 462 Internet-Draft, and is based on a proposal described in [RFC7942]. 463 The description of implementations in this section is intended to 464 assist the IETF in its decision processes in progressing drafts to 465 RFCs. 467 Please note that the listing of any individual implementation here 468 does not imply endorsement by the IETF. Furthermore, no effort has 469 been spent to verify the information presented here that was supplied 470 by IETF contributors. This is not intended as, and must not be 471 construed to be, a catalog of available implementations or their 472 features. Readers are advised to note that other implementations may 473 exist. 475 6.1. Linux NFS server and client 477 Organization: The Linux Foundation 479 URL: https://www.kernel.org 481 Maturity: Prototype software based on early versions of this 482 document. 484 Coverage: The bulk of this specification is implemented. The use of 485 DTLS functionality is not implemented. 487 Licensing: GPLv2 489 Implementation experience: No comments from implementors. 491 6.2. DESY NFS server 493 Organization: DESY 495 URL: https://desy.de 497 Maturity: Prototype software based on early versions of this 498 document. 500 Coverage: The bulk of this specification is implemented. The use of 501 DTLS functionality is not implemented. 503 Licensing: Freely distributable with acknowledgment. 505 Implementation experience: No comments from implementors. 507 7. Security Considerations 509 One purpose of the mechanism described in this document is to protect 510 RPC-based applications against threats to the privacy of RPC 511 transactions and RPC user identities. A taxonomy of these threats 512 appears in Section 5 of [RFC6973]. In addition, Section 6 of 513 [RFC7525] contains a detailed discussion of technologies used in 514 conjunction with TLS. Implementers should familiarize themselves 515 with these materials. 517 The NFS version 4 protocol permits more than one user to use an NFS 518 client at the same time [RFC7862]. Typically that NFS client will 519 conserve connection resources by routing RPC transactions from all of 520 its users over a few or a single connection. In circumstances where 521 the users on that NFS client belong to multiple distinct security 522 domains, the client MUST establish independent TLS sessions for each 523 distinct security domain. 525 7.1. Implications for AUTH_SYS 527 Ever since the IETF NFSV4 Working Group took over the maintenance of 528 the NFSv4 family of protocols (currently specified in [RFC7530], 529 [RFC5661], and [RFC7863], among others), it has encouraged the use of 530 RPCSEC GSS over AUTH_SYS. For various reasons, unfortunately 531 AUTH_SYS continues to be the primary authentication mechanism 532 deployed by NFS administrators. As a result, NFS security remains in 533 an unsatisfactory state. 535 A deeper purpose of this document is to attempt to address some of 536 the shortcomings of AUTH_SYS so that, where it has been impractical 537 to deploy RPCSEC GSS, better NFSv4 security can nevertheless be 538 achieved. 540 When AUTH_SYS is used with TLS and no client certificate is 541 available, the RPC server is still acting on RPC requests for which 542 there is no trustworthy authentication. In-transit traffic is 543 protected, but the client itself can still misrepresent user identity 544 without detection. This is an improvement from AUTH_SYS without 545 encryption, but it leaves a critical security exposure. 547 Therefore, the RECOMMENDED deployment mode is that clients have 548 certificate material configured and used so that servers can have a 549 degree of trust that clients are acting responsibly. 551 8. IANA Considerations 553 In accordance with Section 6 of [RFC7301], the authors request that 554 IANA allocate the following value in the "Application-Layer Protocol 555 Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string 556 identifies SunRPC when used over TLS. 558 Protocol: 559 SunRPC 561 Identification Sequence: 562 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 564 Reference: 565 RFC-TBD 567 9. References 569 9.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 577 Ciphersuites for Transport Layer Security (TLS)", 578 RFC 4279, DOI 10.17487/RFC4279, December 2005, 579 . 581 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 582 Housley, R., and W. Polk, "Internet X.509 Public Key 583 Infrastructure Certificate and Certificate Revocation List 584 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 585 . 587 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 588 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 589 May 2009, . 591 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 592 Verification of Domain-Based Application Service Identity 593 within Internet Public Key Infrastructure Using X.509 594 (PKIX) Certificates in the Context of Transport Layer 595 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 596 2011, . 598 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 599 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 600 January 2012, . 602 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 603 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 604 2014, . 606 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 607 "Transport Layer Security (TLS) Application-Layer Protocol 608 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 609 July 2014, . 611 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 612 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 613 November 2016, . 615 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 616 Code: The Implementation Status Section", BCP 205, 617 RFC 7942, DOI 10.17487/RFC7942, July 2016, 618 . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 625 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 626 . 628 9.2. Informative References 630 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 631 Version 3 Protocol Specification", RFC 1813, 632 DOI 10.17487/RFC1813, June 1995, 633 . 635 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 636 Specification", RFC 2203, DOI 10.17487/RFC2203, September 637 1997, . 639 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 640 DOI 10.17487/RFC2818, May 2000, 641 . 643 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 644 "Network File System (NFS) Version 4 Minor Version 1 645 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 646 . 648 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 649 Morris, J., Hansen, M., and R. Smith, "Privacy 650 Considerations for Internet Protocols", RFC 6973, 651 DOI 10.17487/RFC6973, July 2013, 652 . 654 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 655 "Recommendations for Secure Use of Transport Layer 656 Security (TLS) and Datagram Transport Layer Security 657 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 658 2015, . 660 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 661 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 662 March 2015, . 664 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 665 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 666 November 2016, . 668 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 669 Version 2 External Data Representation Standard (XDR) 670 Description", RFC 7863, DOI 10.17487/RFC7863, November 671 2016, . 673 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 674 Memory Access Transport for Remote Procedure Call Version 675 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 676 . 678 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 679 "The Token Binding Protocol Version 1.0", RFC 8471, 680 DOI 10.17487/RFC8471, October 2018, 681 . 683 9.3. URIs 685 [1] https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls 687 Acknowledgments 689 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 690 with Stunnel TLS" [1]. His article inspired the mechanism described 691 in this document. 693 The authors are grateful to Bill Baker, David Black, Alan DeKok, Lars 694 Eggert, Benjamin Kaduk, Greg Marsden, Alex McDonald, Tigran 695 Mkrtchyan, David Noveck, Justin Mazzola Paluska, and Tom Talpey for 696 their input and support of this work. 698 Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 699 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 700 Working Group Secretary Thomas Haynes for their guidance and 701 oversight. 703 Authors' Addresses 705 Trond Myklebust 706 Hammerspace Inc 707 4300 El Camino Real Ste 105 708 Los Altos, CA 94022 709 United States of America 711 Email: trond.myklebust@hammerspace.com 712 Charles Lever (editor) 713 Oracle Corporation 714 United States of America 716 Email: chuck.lever@oracle.com