idnits 2.17.1 draft-cel-nfsv4-rpc-tls-pseudoflavors-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 December 2021) is 851 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Standards Track 27 December 2021 5 Expires: 30 June 2022 7 Pseudo-flavors for Remote Procedure Calls with Transport Layer Security 8 draft-cel-nfsv4-rpc-tls-pseudoflavors-02 10 Abstract 12 Recent innovations in Remote Procedure Call (RPC) transport layer 13 security enable broad deployment of encryption and mutual peer 14 authentication when exchanging RPC messages. These security 15 mechanisms can protect peers who continue to use the AUTH_SYS RPC 16 auth flavor, which is not cryptographically secure, on open networks. 17 This document introduces RPC auth pseudo-flavors that an RPC service 18 can use to indicate transport layer security requirements for 19 accessing that service, and a mechanism the service can use to 20 enforce those requirements. 22 Note 24 This note is to be removed before publishing as an RFC. 26 Discussion of this draft occurs on the NFSv4 working group mailing 27 list (nfsv4@ietf.org), archived at 28 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group 29 information is available at https://datatracker.ietf.org/wg/nfsv4/ 30 about/. 32 Submit suggestions and changes as pull requests at 33 https://github.com/chucklever/i-d-rpc-tls-pseudoflavors. 34 Instructions are on that page. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 30 June 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 72 3. RPC Auth Pseudo-flavors for Transport Layer Security . . . . 4 73 3.1. Definitions of New Pseudo-flavors . . . . . . . . . . . . 5 74 4. Channel Binding . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. TLS Channel Binding . . . . . . . . . . . . . . . . . . . 6 76 4.2. SSHv2 Channel Binding . . . . . . . . . . . . . . . . . . 7 77 4.3. Channel Binding for RDMA Transports . . . . . . . . . . . 7 78 5. NFS Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Network File System Versions 2 and 3 . . . . . . . . . . 7 80 5.2. Network File System Version 4 . . . . . . . . . . . . . . 8 81 5.2.1. NFSv4 State Protection . . . . . . . . . . . . . . . 8 82 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 8.1. New RPC Auth Flavors . . . . . . . . . . . . . . . . . . 11 86 8.2. Pseudo-flavors for Secure AUTH_NONE . . . . . . . . . . . 11 87 8.3. Pseudo-flavors for Secure AUTH_SYS . . . . . . . . . . . 12 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 90 9.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 Each RPC transaction may be associated with a user and a set of 97 groups. That transaction's RPC auth flavor determines how the user 98 and groups are identified and whether they are authenticated. Peers 99 that host applications and RPC services may also be identified and 100 authenicated in each RPC transaction, again depending on that 101 transaction's RPC auth flavor [RFC5531]. 103 Not all flavors provide peer and user identification and 104 authentication. For example, the traditional RPC auth flavor 105 AUTH_NONE identifies no user or group and provides no authentication 106 of users or peers. The traditional RPC auth flavor AUTH_SYS provides 107 identification of peers, users, and groups, but does not provide 108 authentication of any of these. 110 Moreover, unlike some GSS security services, these RPC auth flavors 111 provide no confidentiality or integrity checking services. Therefore 112 AUTH_NONE and AUTH_SYS are considered insecure. 114 Mutual peer authentication and encryption provided at the transport 115 layer can make the use of AUTH_NONE and AUTH_SYS more secure. An RPC 116 service might want to indicate to its clients that it will not allow 117 access via AUTH_NONE or AUTH_SYS unless transport layer security 118 services are in place. To do that, this document specifies several 119 pseudo-flavors that upper layers such as NFS [RFC8881] can use to 120 enforce stronger security when unauthenticated RPC auth flavors are 121 in use. 123 The author expects that, in addition to RPC-with-TLS 124 [I-D.ietf-nfsv4-rpc-tls], other novel RPC transports will eventually 125 appear that provide similar security features. These transports can 126 benefit from the pseudo-flavors defined in this document, or this 127 approach can be extended if new transport security features require 128 it. 130 1.1. Terminology 132 This document adopts the terminology introduced in Section 3 of 133 [RFC6973] and assumes a working knowledge of the Remote Procedure 134 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 135 Security (TLS) protocol [RFC8446]. 137 This document adheres to the convention that a "client" is a network 138 host that actively initiates an association, and a "server" is a 139 network host that passively accepts an association request. 141 For the purposes of this document, an Upper-Layer Protocol is an RPC 142 Program and Version tuple comprised of a set of procedure calls 143 defining a single API. One example of a ULP is the Network File 144 System Version 4.0 [RFC7530]. 146 An "RPC auth flavor" is a set of protocol elements that can identify 147 a network peer and a user and possibly authenticate either or both. 148 Section 13.4.2 of [RFC5531] explains the differences between RPC auth 149 flavors and pseudo-flavors. 151 RPC documentation historically refers to the authentication of a host 152 as "machine authentication" or "host authentication". TLS 153 documentation refers to the same as "peer authentication". The 154 current document uses only "peer authentication". 156 The term "user authentication" in the current document refers 157 specifically to the RPC caller's credential provided in the "cred" 158 and "verf" fields in each RPC Call. 160 This document uses the term "insecure RPC auth flavor" (or "insecure 161 flavor" for short) to refer to a class of RPC auth flavors which 162 provide no user or peer authentication. Two prime examples of an 163 insecure RPC auth flavor are AUTH_NONE and AUTH_SYS. 165 2. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in 170 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 3. RPC Auth Pseudo-flavors for Transport Layer Security 175 Section 4 of [I-D.ietf-nfsv4-rpc-tls] introduces a special RPC auth 176 flavor known as AUTH_TLS. This RPC auth flavor is used only in a 177 NULL procedure that probes the presence of support for RPC-with-TLS, 178 and acts as a STARTTLS barrier. 180 This auth flavor does not carry the identity of the peer or a user. 181 RPC clients do not use this RPC auth flavor to authenticate users in 182 RPC Calls for non-NULL RPC procedures. 184 Once transport layer security has been established between two RPC 185 peers, an RPC client can use insecure flavors when forming RPC Calls 186 with knowledge that the RPC server is known and trusted, and without 187 concern that the communication can be altered or monitored. 189 In some cases an RPC service might want to restrict access to only 190 clients that have authenticated, or perhaps only when encryption 191 protects communication. The pseudo-flavors defined below enable RPC- 192 based services to indicate and enforce access restrictions of this 193 type. 195 3.1. Definitions of New Pseudo-flavors 197 This document specifies several pseudo-flavors that servers may 198 advertise to clients via mechanisms not defined here. Using the RPC 199 auth flavor registry instantiated in [RFC5531] gives us leeway to 200 introduce a narrow basic set of pseudoflavors in this document and 201 then expand them, via additional documents, as needs arise. 203 RPC clients continue to use AUTH_NONE (0) or AUTH_SYS (1) in 204 individual transactions while the network transport service provides 205 cryptographically secure authentication or encryption, as follows: 207 * The new pseudo-flavor AUTH_NONE_MPA indicates that the client may 208 use the AUTH_NONE RPC auth flavor only if both peers have mutually 209 authenticated. Encryption of traffic between these peers is not 210 required. 212 * The new pseudo-flavor AUTH_NONE_ENC indicates that the client may 213 use the AUTH_NONE RPC auth flavor only if traffic between these 214 peers is encrypted. Mutual peer authentication is not required. 216 * The new pseudo-flavor AUTH_NONE_MPA_ENC indicates that the client 217 may use the AUTH_NONE RPC auth flavor only if both peers have 218 mutually authenticated and traffic between these peers is 219 encrypted. 221 * The new pseudo-flavor AUTH_SYS_MPA indicates that the client may 222 use the AUTH_SYS RPC auth flavor only if both peers have mutually 223 authenticated. Encryption of traffic between these peers is not 224 required. 226 * The new pseudo-flavor AUTH_SYS_ENC indicates that the client may 227 use the AUTH_SYS RPC auth flavor only if traffic between these 228 peers is encrypted. Mutual peer authentication is not required. 230 * The new pseudo-flavor AUTH_SYS_MPA_ENC indicates that the client 231 may use the AUTH_SYS RPC auth flavor only if both peers have 232 mutually authenticated and traffic between these peers is 233 encrypted. 235 Because the RPC layer is not aware of pseudo-flavors, the Upper-Layer 236 Protocol is responsible for ensuring that appropriate transport layer 237 security is in place when clients use AUTH_SYS or AUTH_NONE. The 238 next section explains how server implementations enforce the use of 239 transport layer security. 241 4. Channel Binding 243 Certain aspects of transport layer security are not new. A 244 deployment might choose to run NFS on a virtual private network 245 established via an ssh tunnel or over IPsec, for example. The 246 Generic Security Service Application Program Interface (GSS-API) 247 specification [RFC2743] recognized the use of security provided by 248 transport services underlying GSS with the introduction of channel 249 binding. [RFC5056] further describes channel binding as a concept 250 that... 252 ...allows applications to establish that the two end-points of a 253 secure channel at one network layer are the same as at a higher 254 layer by binding authentication at the higher layer to the channel 255 at the lower layer. This allows applications to delegate session 256 protection to lower layers, which has various performance 257 benefits. 259 We are particularly interested in ensuring that the mutual 260 authentication done during a TLS handshake (most recently specified 261 in [RFC8446]) on a transport service that handles RPC traffic can be 262 recognized and used by Upper-Layer Protocols for securely 263 authenticating the communicating RPC peers. 265 Section 7 of [RFC5929] identifies a set of API characteristics that 266 RPC and its underlying transport provide to such protocols. 268 4.1. TLS Channel Binding 270 [RFC5929] defines several TLS channel binding types that Upper-Layer 271 Protocol implementations can use to determine whether appropriate 272 security is in place to protect RPC transactions that continue to use 273 insecure RPC auth flavors such as AUTH_SYS. 275 When used with a Certificate handshake message, the 'tls-server-end- 276 point' channel binding type as defined in Section 4 of [RFC5929] 277 serves as authentication for securing pseudo-flavors that require 278 mutual peer authentication. 280 RPC-with-TLS requires the use of TLS session encryption 281 [I-D.ietf-nfsv4-rpc-tls]. The presence of TLS under an RPC transport 282 is enough to secure pseudo-flavors that require encryption. A peer 283 can use channel binding to determine whether peer authentication has 284 also occurred and whether that authentication was mutual or server- 285 only. 287 Moreover, in the particular case of TLS, when a handshake fails, both 288 peers are made aware of the failure reason via the Finished message. 289 The failure reason can then be reported to the Upper-Layer Protocol 290 so the local administrator can take specific corrective action. 292 For instance, an RPC server's local security policy might require 293 that the RPC client's IP address or hostname match its certificates 294 Subject Alt Name (SAN). This is not always possible if the client's 295 IP address and hostname are assigned dynamically. When such a server 296 causes a handshake failure, administrators can be made aware that the 297 server's SAN policy restricted a client's access, and corrective 298 action can then be taken. 300 4.2. SSHv2 Channel Binding 302 When RPC traverses an SSHv2 tunnel established between an RPC server 303 and an RPC client, the 'tls-unique' channel binding type as defined 304 in Section 3 of [RFC5929] can be used to authenticate peer endpoints 305 and provide appropriate confidentiality. 307 4.3. Channel Binding for RDMA Transports 309 As of this writing, RPC-over-RDMA [RFC8166] does not provide a 310 transport layer security service. However, Section 5 of [RFC5056] 311 suggests a mechanism by which channel binding can protect RDDP 312 [RFC5040], the protocol that handles remote direct data placement for 313 the iWARP family of protocols. The transport layer underlying RDDP 314 might use IPsec [RFC6071], TLS [RFC8446], or Encapsulating Security 315 Payload (ESP) [RFC4303]. 317 5. NFS Examples 319 This section presents examples of how a commonly-used Upper-Layer 320 Protocol (NFS) can make use of these pseudo-flavors. 322 5.1. Network File System Versions 2 and 3 324 NFSv3 clients use the MNT procedure, defined in Appendix I of 325 [RFC1813], to discover which RPC auth flavors may be used to access a 326 particular shared NFSv3 filesystem. 328 To require NFSv3 clients to employ underlying transport security when 329 using AUTH_NONE or AUTH_SYS, the NFS server includes one or more of 330 the new pseudo-flavors defined in Section 8 in the auth_flavors list 331 that is part of a MNT response. 333 When determining whether a filehandle-bearing operation is 334 authorized, an NFSv3 server uses channel binding to ensure that 335 appropriate transport layer security is in place before processing an 336 incoming NFS request that uses an insecure RPC auth flavor. If that 337 request is not authorized, the NFSv3 server can respond with an 338 nfs_stat of NFS3ERR_STALE. 340 The usage of the MNT procedure as described in [RFC1094] is the same 341 with the exception that an NFSv2 server responds with NFSERR_STALE 342 instead of NFS3ERR_STALE. 344 5.2. Network File System Version 4 346 NFSv4 clients use the SECINFO or SECINFO_NO_NAME procedures, as 347 defined in [RFC8881], to discover which RPC auth flavors may be used 348 to access a particular shared NFSv4 filesystem. 350 To require NFSv4 clients to employ underlying transport security when 351 using AUTH_NONE or AUTH_SYS, the NFS server includes one or more of 352 the new pseudo-flavors defined in Section 8 in the SECINFO4resok list 353 that is part of a SECINFO or SECINFO_NO_NAME response. 355 When determining whether a filehandle-bearing operation is 356 authorized, an NFSv4 server uses channel binding to ensure that 357 appropriate transport layer security is in place before processing an 358 incoming NFSv4 COMPOUND that uses an insecure RPC auth flavor. If 359 that request is not authorized, the NFSv4 server terminates the 360 COMPOUND with a status code of NFS4ERR_WRONGSEC. 362 5.2.1. NFSv4 State Protection 364 Note: This section updates RFC 8881. 366 | An alternate approach might place the updates described in this 367 | section in rfc5661bis. 369 Section 2.4.3 of [RFC8881] explains how an NFSv4 server determines 370 when an NFSv4 client is authorized to create a new lease or replace a 371 previous one. This mechanism prevents clients from maliciously or 372 unintentionally wiping open and lock state for another client. 373 Section 2.10.8.3 of that document further specifies how the server 374 responds to unauthorized state changes. 376 When used with a Certificate handshake message, the 'tls-server-end- 377 point' channel binding type as defined in Section 4 of [RFC5929] can 378 provide protection similar to SP4_MACH_CRED. 380 This document modifies the text of the first bullet in Section 2.4.3 381 of [RFC8881] to include the use of transport layer security as 382 follows: 384 * The principal that created the client ID for the client owner is 385 the same as the principal that is sending the EXCHANGE_ID 386 operation. Note that if the client ID was created with 387 SP4_MACH_CRED state protection (Section 18.35), either: 389 - The principal MUST be based on RPCSEC_GSS authentication, the 390 RPCSEC_GSS service used MUST be integrity or privacy, and the 391 same GSS mechanism and principal MUST be used as that used when 392 the client ID was created. Or, 394 - The principal MUST be based on AUTH_SYS, and the server MUST 395 use channel binding to verify the identity of the client peer 396 when performing any of the operations specified in the 397 spa_mach_ops bitmaps. Or, 399 - The principal MUST be based on AUTH_NONE, and the server MUST 400 use channel binding to verify the identity of the client peer 401 when performing any of the operations specified in the 402 spa_mach_ops bitmaps. 404 Subsequent discussion of SP4_MACH_CRED in [RFC8881] in Sections 405 2.10.5.1, 2.10.8.3, and 2.10.11.3 would need similar adjustments. 407 Further, NFSv4 server implementations may implement a security policy 408 that restricts the set of clients or security flavors that can 409 establish a lease via SETCLIENTID or EXCHANGE_ID. However, [RFC8881] 410 does not allow EXCHANGE_ID or CREATE_SESSION to return 411 NFS4ERR_WRONGSEC, and [RFC7530] does not allow SETCLIENTID to return 412 NFS4ERR_WRONGSEC. 414 NFSv4.1-based protocols might be updated to allow EXCHANGE_ID or 415 CREATE_SESSION to return NFS4ERR_WRONG_CRED. However, that solution 416 would be challenging for NFSv4.0, which does not have a definition 417 for NFS4ERR_WRONG_CRED. 419 | More discussion is necessary to determine the exact mechanism 420 | to handle this case in both protocols and to determine which 421 | documents need to specify that mechanism. 423 6. Implementation Status 425 | This section is to be removed before publishing this document 426 | as an RFC. 428 This section records the status of known implementations of the 429 protocol defined by this specification at the time of posting of this 430 Internet-Draft, and is based on a proposal described in [RFC7942]. 431 The description of implementations in this section is intended to 432 assist the IETF in its decision processes in progressing drafts to 433 RFCs. 435 Please note that the listing of any individual implementation here 436 does not imply endorsement by the IETF. Furthermore, no effort has 437 been spent to verify the information presented here that was supplied 438 by IETF contributors. This is not intended as, and must not be 439 construed to be, a catalog of available implementations or their 440 features. Readers are advised to note that other implementations may 441 exist. 443 There are currently no known implementations of the new RPC pseudo- 444 flavors requested by this document. 446 7. Security Considerations 448 Discussion of shortcomings peculiar to the AUTH_SYS RPC auth flavor 449 appears in the final paragraph of Appendix A of [RFC5531] and in 450 Appendix A of [I-D.ietf-nfsv4-rpc-tls]. 452 When implementing or deploying transport layer security to protect an 453 upper-level RPC protocol: 455 * RPC clients that support transport layer security SHOULD use it 456 whenever possible. Typically the only reason not to is when 457 performance is important and reasonable security can be provided 458 in some other way. 460 * RPC clients that support transport layer security and have the 461 ability to authenticate SHOULD do so. The only reason not to 462 authenticate is when authentication and encryption can only be 463 enabled together, performance is paramount, and there are other 464 available mechanisms that can provide peer authentication 465 securely. 467 The pseudo-flavors defined in this document enable RPC servers to 468 indicate required levels of security so that RPC clients can make 469 informed and autonomous decisions that balance performance and 470 scalability against security needs. 472 Important security considerations specific to the use of channel 473 binding are discussed throughout [RFC5056] and in Section 10 of 474 [RFC5929]. 476 8. IANA Considerations 478 | RFC Editor: In the following subsections, please replace RFC- 479 | TBD with the RFC number assigned to this document. 480 | Furthermore, please remove this Editor's Note before this 481 | document is published. 483 8.1. New RPC Auth Flavors 485 Following Appendix B of [RFC5531], this document requests several new 486 entries in the RPC Authentication Flavor Numbers 487 (https://www.iana.org/assignments/rpc-authentication-numbers/rpc- 488 authentication-numbers.xhtml) registry. The purpose of these new 489 flavors is to indicate the use of transport layer encryption or 490 mutual peer authentication with insecure RPC auth flavors. All new 491 flavors described in the sections below are pseudo-flavors. 493 8.2. Pseudo-flavors for Secure AUTH_NONE 495 The fields in the new entries are assigned as follows: 497 +===================+==============+=====+================+=========+ 498 | Identifier String | Flavor Name |Value| Description |Reference| 499 +===================+==============+=====+================+=========+ 500 | AUTH_NONE_MPA | NONE_MPA | TBD | AUTH_NONE with | RFC_TBD| 501 | | | | mutual peer | | 502 | | | | authentication | | 503 +-------------------+--------------+-----+----------------+---------+ 504 | AUTH_NONE_ENC | NONE_ENC | TBD | AUTH_NONE with | RFC_TBD| 505 | | | |transport layer | | 506 | | | | encryption | | 507 +-------------------+--------------+-----+----------------+---------+ 508 | AUTH_NONE_MPA_ENC | NONE_MPA_ENC | TBD | AUTH_NONE with | RFC_TBD| 509 | | | | peer | | 510 | | | | authentication | | 511 | | | | and encryption | | 512 +-------------------+--------------+-----+----------------+---------+ 514 Table 1 516 Please allocate the numeric values from the range 400000-409999. 518 8.3. Pseudo-flavors for Secure AUTH_SYS 520 The fields in the new entries are assigned as follows: 522 +==================+=============+=====+================+===========+ 523 |Identifier String | Flavor Name |Value| Description | Reference | 524 +==================+=============+=====+================+===========+ 525 |AUTH_SYS_MPA | SYS_MPA | TBD | AUTH_SYS with | RFC_TBD | 526 | | | | mutual peer | | 527 | | | | authentication | | 528 +------------------+-------------+-----+----------------+-----------+ 529 |AUTH_SYS_ENC | SYS_ENC | TBD | AUTH_SYS with | RFC_TBD | 530 | | | |transport layer | | 531 | | | | encryption | | 532 +------------------+-------------+-----+----------------+-----------+ 533 |AUTH_SYS_MPA_ENC | SYS_MPA_ENC | TBD | AUTH_SYS with | RFC_TBD | 534 | | | | peer | | 535 | | | | authentication | | 536 | | | | and encryption | | 537 +------------------+-------------+-----+----------------+-----------+ 539 Table 2 541 Please allocate the numeric values from the range 410000-419999. 543 9. References 545 9.1. Normative References 547 [I-D.ietf-nfsv4-rpc-tls] 548 Myklebust, T. and C. Lever, "Towards Remote Procedure Call 549 Encryption By Default", Work in Progress, Internet-Draft, 550 draft-ietf-nfsv4-rpc-tls-11, 23 November 2020, 551 . 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, 556 DOI 10.17487/RFC2119, March 1997, 557 . 559 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 560 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 561 May 2009, . 563 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 564 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 565 . 567 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 568 Code: The Implementation Status Section", BCP 205, 569 RFC 7942, DOI 10.17487/RFC7942, July 2016, 570 . 572 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 573 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 574 May 2017, . 576 [RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 577 Version 4 Minor Version 1 Protocol", RFC 8881, 578 DOI 10.17487/RFC8881, August 2020, 579 . 581 9.2. Informative References 583 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 584 specification", RFC 1094, DOI 10.17487/RFC1094, March 585 1989, . 587 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 588 Version 3 Protocol Specification", RFC 1813, 589 DOI 10.17487/RFC1813, June 1995, 590 . 592 [RFC2743] Linn, J., "Generic Security Service Application Program 593 Interface Version 2, Update 1", RFC 2743, 594 DOI 10.17487/RFC2743, January 2000, 595 . 597 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 598 RFC 4303, DOI 10.17487/RFC4303, December 2005, 599 . 601 [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. 602 Garcia, "A Remote Direct Memory Access Protocol 603 Specification", RFC 5040, DOI 10.17487/RFC5040, October 604 2007, . 606 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 607 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 608 . 610 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 611 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 612 DOI 10.17487/RFC6071, February 2011, 613 . 615 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 616 Morris, J., Hansen, M., and R. Smith, "Privacy 617 Considerations for Internet Protocols", RFC 6973, 618 DOI 10.17487/RFC6973, July 2013, 619 . 621 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 622 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 623 March 2015, . 625 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 626 Memory Access Transport for Remote Procedure Call Version 627 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 628 . 630 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 631 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 632 . 634 Acknowledgments 636 David Noveck is responsible for the basic architecture of this 637 proposal. The author is also grateful to Bill Baker, Rick Macklem, 638 Greg Marsden, and Martin Thomson for their input and support. 640 Special thanks to Transport Area Directors Martin Duke and 641 Zaheduzzaman Sarker, NFSV4 Working Group Chairs David Noveck and 642 Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for 643 their guidance and oversight. 645 Author's Address 647 Charles Lever 648 Oracle Corporation 649 United States of America 651 Email: chuck.lever@oracle.com