idnits 2.17.1 draft-ietf-nfsv4-rpc-tls-09.txt: -(1056): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5531, updated by this document, for RFC5378 checks: 2003-05-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 September 2020) is 1308 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-kitten-tls-channel-bindings-for-tls13-00 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-07 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 T. Myklebust 3 Internet-Draft Hammerspace 4 Updates: 5531 (if approved) C. Lever, Ed. 5 Intended status: Standards Track Oracle 6 Expires: 22 March 2021 18 September 2020 8 Towards Remote Procedure Call Encryption By Default 9 draft-ietf-nfsv4-rpc-tls-09 11 Abstract 13 This document describes a mechanism that, through the use of 14 opportunistic Transport Layer Security (TLS), enables encryption of 15 Remote Procedure Call (RPC) transactions while they are in-transit. 16 The proposed mechanism interoperates with ONC RPC implementations 17 that do not support it. This document updates RFC 5531. 19 Note 21 Discussion of this draft takes place on the NFSv4 working group 22 mailing list (nfsv4@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group 24 information can be found at https://datatracker.ietf.org/wg/nfsv4/ 25 about/. 27 This note is to be removed before publishing as an RFC. 29 The source for this draft is maintained in GitHub. Suggested changes 30 should be submitted as pull requests at 31 https://github.com/chucklever/i-d-rpc-tls. Instructions are on that 32 page as well. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 22 March 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 6 70 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6 71 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 72 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 73 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Base Transport Considerations . . . . . . . . . . . . . . 9 75 5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 10 76 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10 77 5.1.3. Protected Operation on Other Transports . . . . . . . 11 78 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 12 79 5.2.1. X.509 Certificates Using PKIX Trust . . . . . . . . . 12 80 5.2.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 14 81 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 82 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14 83 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 15 84 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 15 85 6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 7.1. The Limitations of Opportunistic Security . . . . . . . . 16 88 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 17 89 7.1.2. Privacy Leakage Before Session Establishment . . . . 17 90 7.2. TLS Identity Management on Clients . . . . . . . . . . . 18 91 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 18 92 7.4. Best Security Policy Practices . . . . . . . . . . . . . 19 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 19 95 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 20 96 8.3. Object Identifier for PKIX Extended Key Usage . . . . . . 20 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 99 9.2. Informative References . . . . . . . . . . . . . . . . . 22 100 Appendix A. Known Weaknesses of the AUTH_SYS Authentication 101 Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 103 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 106 1. Introduction 108 In 2014 the IETF published a document entitled "Pervasive Monitoring 109 Is an Attack" [RFC7258], which recognized that unauthorized 110 observation of network traffic had become widespread and was a 111 subversive threat to all who make use of the Internet at large. It 112 strongly recommended that newly defined Internet protocols should 113 make a genuine effort to mitigate monitoring attacks. Typically this 114 mitigation includes encrypting data in transit. 116 The Remote Procedure Call version 2 protocol has been a Proposed 117 Standard for three decades (see [RFC5531] and its antecedents). Over 118 twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in- 119 transit encryption mechanism for RPC [RFC2203]. However, experience 120 has shown that RPCSEC GSS with in-transit encryption can be 121 challenging to use in practice: 123 * Parts of each RPC header remain in clear-text, constituting a loss 124 of metadata confidentiality. 126 * Offloading the GSS privacy service is not practical in large 127 multi-user deployments since each message is encrypted using a key 128 based on the issuing RPC user. 130 However strong GSS-provided confidentiality is, it cannot provide any 131 security if the challenges of using it result in choosing not to 132 deploy it at all. 134 Moreover, the use of AUTH_SYS remains common despite the adverse 135 effects that acceptance of UIDs and GIDs from unauthenticated clients 136 brings with it. Continued use is in part because: 138 * Per-client deployment and administrative costs for the only well- 139 defined alternative to AUTH_SYS are expensive at scale. For 140 instance, administrators must provide keying material for each RPC 141 client, including transient clients. 143 * GSS host identity management and user identity management must be 144 enforced in the same security realm. In certain environments, 145 different authorities might be responsible for provisioning client 146 systems versus provisioning new users. 148 In view of the challenges with the currently available mechanisms for 149 authenticating and protecting the confidentiality of RPC 150 transactions, this document specifies a transport-layer security 151 mechanism that complements the existing ones. The Transport Layer 152 Security [RFC8446] (TLS) and Datagram Transport Layer Security 153 [I-D.ietf-tls-dtls13] (DTLS) protocols are a well-established 154 Internet building blocks that protect many standard Internet 155 protocols such as the Hypertext Transport Protocol (HTTP) [RFC2818]. 157 Encrypting at the RPC transport layer accords several significant 158 benefits: 160 Encryption By Default: Transport encryption can be enabled without 161 additional administrative tasks such as identifying client systems 162 to a trust authority and providing each with keying material. 164 Encryption Offload: Hardware support for the GSS privacy service has 165 not appeared in the marketplace. However, the use of a well- 166 established transport encryption mechanism that is employed by 167 other ubiquitous network protocols makes it more likely that 168 encryption offload for RPC is practicable. 170 Securing AUTH_SYS: Most critically, transport encryption can 171 significantly reduce several security issues inherent in the 172 current widespread use of AUTH_SYS (i.e., acceptance of UIDs and 173 GIDs generated by an unauthenticated client). 175 Decoupled User and Host Identities: TLS can be used to authenticate 176 peer hosts while other security mechanisms can handle user 177 authentication. 179 Compatibility: The imposition of encryption at the transport layer 180 protects any upper-layer protocol that employs RPC, without 181 alteration of the upper-layer protocol. 183 Further, Section 7 of the current document defines policies in line 184 with [RFC7435] which enable RPC-over-TLS to be deployed 185 opportunistically in environments that contain RPC implementations 186 that do not support TLS. However, specifications for RPC-based 187 upper-layer protocols should choose to require even stricter policies 188 that guarantee encryption and host authentication is used for all RPC 189 transactions to mitigate against pervasive monitoring attacks 190 [RFC7258]. Enforcing the use of RPC-over-TLS is of particular 191 importance for existing upper-layer protocols whose security 192 infrastructure is weak. 194 The protocol specification in the current document assumes that 195 support for ONC RPC [RFC5531], TLS [RFC8446], PKIX [RFC5280], DNSSEC/ 196 DANE [RFC6698], and optionally RPCSEC_GSS [RFC2203] is available 197 within the platform where RPC-over-TLS support is to be added. 199 2. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in 204 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 3. Terminology 209 This document adopts the terminology introduced in Section 3 of 210 [RFC6973] and assumes a working knowledge of the Remote Procedure 211 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 212 Security (TLS) version 1.3 protocol [RFC8446]. 214 Note also that the NFS community long ago adopted the use of the term 215 "privacy" from documents such as [RFC2203]. In the current document, 216 the authors use the term "privacy" only when referring specifically 217 to the historic GSS privacy service defined in [RFC2203]. Otherwise, 218 the authors use the term "confidentiality", following the practices 219 of contemporary security communities. 221 We adhere to the convention that a "client" is a network host that 222 actively initiates an association, and a "server" is a network host 223 that passively accepts an association request. 225 RPC documentation historically refers to the authentication of a 226 connecting host as "machine authentication" or "host authentication". 227 TLS documentation refers to the same as "peer authentication". In 228 the current document there is little distinction between these terms. 230 The term "user authentication" in the current document refers 231 specifically to the RPC caller's credential, provided in the "cred" 232 and "verf" fields in each RPC Call. 234 4. RPC-Over-TLS in Operation 236 4.1. Discovering Server-side TLS Support 238 The mechanism described in the current document interoperates fully 239 with RPC implementations that do not support RPC-over-TLS. When an 240 RPC-over-TLS-enabled peer encounters a peer that does not support 241 RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer 242 determine whether RPC operation continues without the use of TLS, or 243 RPC operation is not permitted. 245 To achieve this interoperability, we introduce a new RPC 246 authentication flavor called AUTH_TLS. The AUTH_TLS authentication 247 flavor signals that the client wants to initiate TLS negotiation if 248 the server supports it. Except for the modifications described in 249 this section, the RPC protocol is unaware of security encapsulation 250 at the transport layer. The value of AUTH_TLS is defined in 251 Section 8.1. 253 An RPC client begins its communication with an RPC server by 254 selecting a transport and destination port. The choice of transport 255 and port is typically based on the RPC program that is to be used. 256 The RPC client might query the RPC server's RPCBIND service to make 257 this selection (The RPCBIND service is described in [RFC1833]). The 258 mechanism described in the current document does not support RPC 259 transports other than TCP and UDP. In all cases, an RPC server MUST 260 listen on the same ports for (D)TLS-protected RPC programs as the 261 ports used when (D)TLS is not available. 263 To protect RPC traffic to a TCP port, the RPC client opens a TCP 264 connection to that port and sends a NULL RPC procedure with an 265 auth_flavor of AUTH_TLS on that connection. To protect RPC traffic 266 to a UDP port, the RPC client sends a UDP datagram to that port 267 containing a NULL RPC procedure with an auth_flavor of AUTH_TLS. The 268 client constructs this RPC procedure as follows: 270 * The length of the opaque data constituting the credential sent in 271 the RPC Call message MUST be zero. 273 * The verifier accompanying the credential MUST be an AUTH_NONE 274 verifier of length zero. 276 * The flavor value of the verifier in the RPC Reply message received 277 from the server MUST be AUTH_NONE. 279 * The length of the verifier's body field is eight. 281 * The bytes of the verifier's body field encode the ASCII characters 282 "STARTTLS" as a fixed-length opaque. 284 The RPC server signals its corresponding support for RPC-over-TLS by 285 replying with a reply_stat of MSG_ACCEPTED and an AUTH_NONE verifier 286 containing the "STARTTLS" token. The client SHOULD proceed with TLS 287 session establishment, even if the Reply's accept_stat is not 288 SUCCESS. If the AUTH_TLS probe was done via TCP, the RPC client MUST 289 send the "ClientHello" message on the same connection. If the 290 AUTH_TLS probe was done via UDP, the RPC client MUST send the 291 "ClientHello" message to the same UDP destination port. 293 Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its 294 verifier flavor is not AUTH_NONE, or if its verifier does not contain 295 the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello" 296 message. RPC operation may continue, depending on local policy, but 297 without confidentiality, integrity, or peer authentication protection 298 from (D)TLS. 300 If, after a successful RPC AUTH_TLS probe, the subsequent (D)TLS 301 handshake should fail for any reason, the RPC client reports this 302 failure to the upper-layer application the same way it reports an 303 AUTH_ERROR rejection from the RPC server. 305 If an RPC client uses the AUTH_TLS authentication flavor on any 306 procedure other than the NULL procedure, or an RPC client sends an 307 RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server 308 MUST reject that RPC Call by returning a reply_stat of MSG_DENIED 309 with a reject_stat of AUTH_ERROR and an auth_stat of AUTH_BADCRED. 311 Once the TLS session handshake is complete, the RPC client and server 312 have established a secure channel for exchanging RPC transactions. A 313 successful AUTH_TLS probe on one particular port/transport tuple does 314 not imply that RPC-over-TLS is available on that same server using a 315 different port/transport tuple, nor does it imply that RPC-over-TLS 316 will be available in the future using the successfully probed port. 318 4.2. Authentication 320 There is some overlap between the authentication capabilities of RPC 321 and TLS. The goal of interoperability with implementations that do 322 not support TLS requires limiting the combinations that are allowed 323 and precisely specifying the role that each layer plays. 325 Each RPC server that supports RPC-over-TLS MUST possess a unique 326 global identity (e.g., a certificate that is signed by a well-known 327 trust anchor). Such an RPC server MUST request a TLS peer identity 328 from each client upon first contact. There are two different modes 329 of client deployment: 331 Server-only Host Authentication 332 In this type of deployment, the client can authenticate the server 333 host using the presented server peer TLS identity, but the server 334 cannot authenticate the client. In this situation, RPC-over-TLS 335 clients are anonymous. They present no globally unique identifier 336 to the server peer. 338 Mutual Host Authentication 339 In this type of deployment, the client possesses an identity (e.g. 340 a certificate) that is backed by a trusted entity. As part of the 341 TLS handshake, both peers authenticate using the presented TLS 342 identities. If authentication of either peer fails, or if 343 authorization based on those identities blocks access to the 344 server, the peers MUST reject the association. 346 In either of these modes, RPC user authentication is not affected by 347 the use of transport layer security. When a client presents a TLS 348 peer identity to an RPC server, the protocol extension described in 349 the current document provides no way for the server to know whether 350 that identity represents one RPC user on that client, or is shared 351 amongst many RPC users. Therefore, a server implementation cannot 352 utilize the remote TLS peer identity to authenticate RPC users. 354 4.2.1. Using TLS with RPCSEC GSS 356 To use GSS, an RPC server has to possess a GSS service principal. On 357 a TLS session, GSS mutual (peer) authentication occurs as usual, but 358 only after a TLS session has been established for communication. 359 Authentication of RPCSEC GSS users is unchanged by the use of TLS. 361 RPCSEC GSS can also perform per-request integrity or confidentiality 362 protection. When operating over a TLS session, these GSS services 363 become largely redundant. An RPC implementation capable of 364 concurrently using TLS and RPCSEC GSS MUST use GSS-API channel 365 binding, as defined in [RFC5056], to determine when an underlying 366 transport provides a sufficient degree of confidentiality. RPC-over- 367 TLS implementations MUST provide the "tls-exporter" channel binding 368 type, as defined in [I-D.ietf-kitten-tls-channel-bindings-for-tls13]. 370 5. TLS Requirements 372 When peers negotiate a TLS session that is to transport RPC, the 373 following restrictions apply: 375 * Implementations MUST NOT negotiate TLS versions prior to v1.3 (for 376 TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively). 377 Support for mandatory-to-implement ciphersuites for the negotiated 378 TLS version is REQUIRED. 380 * Implementations MUST support certificate-based mutual 381 authentication. Support for PSK mutual authentication is 382 OPTIONAL; see Section 5.2.2 for further details. 384 * Negotiation of a ciphersuite providing confidentiality as well as 385 integrity protection is REQUIRED. Support for and negotiation of 386 compression is OPTIONAL. 388 Client implementations MUST include the 389 "application_layer_protocol_negotiation(16)" extension [RFC7301] in 390 their "ClientHello" message and MUST include the protocol identifier 391 defined in Section 8.2 in that message's ProtocolNameList value. 393 Similarly, in response to the "ClientHello" message, server 394 implementations MUST include the 395 "application_layer_protocol_negotiation(16)" extension [RFC7301] in 396 their "ServerHello" message and MUST include only the protocol 397 identifier defined in Section 8.2 in that message's ProtocolNameList 398 value. 400 If the server responds incorrectly (for instance, if the 401 "ServerHello" message does not conform to the above requirements), 402 the client MUST NOT establish a TLS session for use with RPC on this 403 connection. See [RFC7301] for further details about how to form 404 these messages properly. 406 5.1. Base Transport Considerations 408 There is traditionally a strong association between an RPC program 409 and a destination port number. The use of TLS or DTLS does not 410 change that association. Thus it is frequently -- though not always 411 -- the case that a single TLS session carries traffic for only one 412 RPC program. 414 5.1.1. Protected Operation on TCP 416 The use of the Transport Layer Security (TLS) protocol [RFC8446] 417 protects RPC on TCP connections. Typically, once an RPC client 418 completes the TCP handshake, it uses the mechanism described in 419 Section 4.1 to discover RPC-over-TLS support for that connection. 420 Until an AUTH_TLS probe is done on a connection, the RPC server 421 treats all traffic as RPC messages. If spurious traffic appears on a 422 TCP connection between the initial clear-text AUTH_TLS probe and the 423 TLS session handshake, receivers MUST discard that data without 424 response and then SHOULD drop the connection. 426 The protocol convention specified in the current document assumes 427 there can be no more than one concurrent TLS session per TCP 428 connection. This is true of current generations of TLS, but might be 429 different in a future version of TLS. 431 Once a TLS session is established on a TCP connection, no further 432 clear-text communication can occur on that connection until the 433 session is terminated. The use of TLS does not alter RPC record 434 framing used on TCP transports. 436 Furthermore, if an RPC server responds with PROG_UNAVAIL to an RPC 437 Call within an established TLS session, that does not imply that RPC 438 server will subsequently reject the same RPC program on a different 439 TCP connection. 441 Reverse-direction operation occurs only on connected transports such 442 as TCP (see Section 2 of [RFC8167]). To protect reverse-direction 443 RPC operations, the RPC server does not establish a separate TLS 444 session on the TCP connection, but instead uses the existing TLS 445 session on that connection to protect these operations. 447 When operation is complete, an RPC peer terminates a TLS session by 448 sending a TLS Closure Alert. It may then close the TCP connection. 450 5.1.2. Protected Operation on UDP 452 RFC Editor: In the following section, please replace TBD with the 453 connection_id extension number that is to be assigned in 454 [I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's 455 Note before this document is published. 457 RPC over UDP is protected using the Datagram Transport Layer Security 458 (DTLS) protocol [I-D.ietf-tls-dtls13]. 460 Using DTLS does not introduce reliable or in-order semantics to RPC 461 on UDP. The use of DTLS record replay protection is REQUIRED when 462 transporting RPC traffic. 464 Each RPC message MUST fit in a single DTLS record. DTLS 465 encapsulation has overhead, which reduces the Packetization Layer 466 Path MTU (PLPMTU) and thus the maximum RPC payload size. A possible 467 PLPMTU discovery mechanism is offered in [RFC8899]. 469 As soon as a client initializes a UDP socket for use with an RPC 470 server, it uses the mechanism described in Section 4.1 to discover 471 DTLS support for an RPC program on a particular port. It then 472 negotiates a DTLS session. 474 The current document does not specify a mechanism that enables a 475 server to distinguish between DTLS traffic and unprotected RPC 476 traffic directed to the same port. To make this distinction, each 477 peer matches ingress datagrams that appear to be DTLS traffic to 478 existing DTLS session state. A peer treats any datagram that fails 479 the matching process as an RPC message. 481 Multi-homed RPC clients and servers may send protected RPC messages 482 via network interfaces that were not involved in the handshake that 483 established the DTLS session. Therefore, when protecting RPC 484 traffic, each DTLS handshake MUST include the "connection_id(TBD)" 485 extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC- 486 over-DTLS peer endpoints MUST provide a ConnectionID with a non-zero 487 length. Endpoints implementing RPC programs that expect a 488 significant number of concurrent clients SHOULD employ ConnectionIDs 489 of at least 4 bytes in length. 491 Sending a TLS Closure Alert terminates a DTLS session. Because 492 neither DTLS nor UDP provide in-order delivery, after session closure 493 there can be ambiguity as to whether a datagram should be interpreted 494 as DTLS protected or not. Therefore receivers MUST discard datagrams 495 exchanged using the same 5-tuple that just terminated the DTLS 496 session for 60 seconds. 498 5.1.3. Protected Operation on Other Transports 500 Transports that provide intrinsic TLS-level security (e.g., QUIC) 501 need to be addressed separately from the current document. In such 502 cases, the use of TLS is not opportunistic as it can be for TCP or 503 UDP. 505 RPC-over-RDMA can make use of transport layer security below the RDMA 506 transport layer [RFC8166]. The exact mechanism is not within the 507 scope of the current document. Because there might not be other 508 provisions to exchange client and server certificates, authentication 509 material exchange needs to be provided by facilities within a future 510 version of the RPC-over-RDMA transport protocol. 512 5.2. TLS Peer Authentication 514 TLS can perform peer authentication using any of the following 515 mechanisms. 517 5.2.1. X.509 Certificates Using PKIX Trust 519 X.509 certificates are specified in [X.509]. [RFC5280] provides a 520 profile of Internet PKI X.509 public key infrastructure. RPC-over- 521 TLS implementations are REQUIRED to support the PKIX mechanism 522 described in [RFC5280]. 524 The rules and guidelines defined in [RFC6125] apply to RPC-over-TLS 525 certificates with the following considerations: 527 * Support for the DNS-ID identifier type [RFC6125] is REQUIRED in 528 RPC-over-TLS client and server implementations. Certification 529 authorities that issue such certificates MUST support the DNS-ID 530 identifier type. 532 * DNS domain names in RPC-over-TLS certificates MUST NOT contain the 533 wildcard character '*' within the identifier. 535 When validating a server certificate, an RPC-over-TLS client 536 implementation takes the following into account: 538 * Certificate validation MUST include the verification rules as per 539 Section 6 of [RFC5280] and Section 6 of [RFC6125]. 541 * Server certificate validation MUST include a check on whether the 542 locally configured expected DNS-ID or iPAddress subjectAltName of 543 the server that is contacted matches its presented certificate. 545 * For RPC services accessed by their network identifiers (netids) 546 and universal network addresses (uaddr), the iPAddress 547 subjectAltName MUST be present in the certificate and MUST exactly 548 match the address represented by the universal network address. 550 An RPC client's domain name and IP address are often assigned 551 dynamically, thus RPC servers cannot rely on those to verify client 552 certificates. Therefore, when an RPC-over-TLS client presents a 553 certificate to an RPC-over-TLS server, the server takes the following 554 into account: 556 * The server MUST use a procedure conformant to Section 6 of 557 [RFC5280]) to validate the client certificate's certification 558 path. 560 * The tuple (serial number of the presented certificate; Issuer) 561 uniquely identifies the RPC client. The meaning and syntax of 562 these fields is defined in Section 4 of [RFC5280]). 564 RPC-over-TLS implementations MAY allow the configuration of a set of 565 additional properties of the certificate to check for a peer's 566 authorization to communicate (e.g., a set of allowed values in 567 subjectAltName:URI, a set of allowed X.509v3 Certificate Policies, or 568 a set of extended key usages). 570 When the configured trust base changes (e.g., removal of a CA from 571 the list of trusted CAs; issuance of a new CRL for a given CA), 572 implementations SHOULD reevaluate the certificate originally 573 presented in the context of the new configuration and terminate the 574 TLS session if the certificate is no longer trustworthy. 576 5.2.1.1. Extended Key Usage Values 578 Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509 579 certificate extension. This extension, which may appear in end- 580 entity certificates, indicates one or more purposes for which the 581 certified public key may be used in addition to or in place of the 582 basic purposes indicated in the key usage extension. 584 The current document defines two new KeyPurposeId values: one that 585 identifies the RPC-over-TLS peer as an RPC client, and one that 586 identifies the RPC-over-TLS peer as an RPC server. Additional 587 KeyPurposeId values related to RPC-over-TLS may be specified in 588 subsequent Standards Track documents. 590 The inclusion of the RPC server value (id-kp-rpcTLSServer) indicates 591 that the certificate has been issued for allowing the holder to 592 process RPC transactions. Such a certificate is a Resource 593 Certificate and therefore MUST conform to the constraints specified 594 in [RFC6487]. 596 The inclusion of the RPC client value (id-kp-rpcTLSClient) indicates 597 that the certificate has been issued for allowing the holder to 598 request RPC transactions. 600 5.2.2. Pre-Shared Keys 602 This mechanism is OPTIONAL to implement. In this mode, the RPC peer 603 can be uniquely identified by keying material that has been shared 604 out-of-band (see Section 2.2 of [RFC8446]). At least the following 605 parameter of the TLS connection SHOULD be exposed at the RPC layer: 607 * PSK Identifier 609 6. Implementation Status 611 This section is to be removed before publishing as an RFC. 613 This section records the status of known implementations of the 614 protocol defined by this specification at the time of posting of this 615 Internet-Draft, and is based on a proposal described in [RFC7942]. 616 The description of implementations in this section is intended to 617 assist the IETF in its decision processes in progressing drafts to 618 RFCs. 620 Please note that the listing of any individual implementation here 621 does not imply endorsement by the IETF. Furthermore, no effort has 622 been spent to verify the information presented here that was supplied 623 by IETF contributors. This is not intended as, and must not be 624 construed to be, a catalog of available implementations or their 625 features. Readers are advised to note that other implementations may 626 exist. 628 6.1. DESY NFS server 630 Organization: DESY 632 URL: https://desy.de 634 Maturity: Implementation will be based on mature versions of the 635 current document. 637 Coverage: The bulk of this specification is implemented including 638 DTLS. 640 Licensing: LGPL 642 Implementation experience: The implementer has read and commented on 643 the current document. 645 6.2. Hammerspace NFS server 647 Organization: Hammerspace 649 URL: https://hammerspace.com 651 Maturity: Prototype software based on early versions of the current 652 document. 654 Coverage: The bulk of this specification is implemented. The use of 655 DTLS functionality is not implemented. 657 Licensing: Proprietary 659 Implementation experience: No comments from implementors. 661 6.3. Linux NFS server and client 663 Organization: The Linux Foundation 665 URL: https://www.kernel.org 667 Maturity: Not complete. 669 Coverage: The bulk of this specification has yet to be implemented. 670 The use of DTLS functionality is not planned. 672 Licensing: GPLv2 674 Implementation experience: A Linux in-kernel prototype is underway, 675 but implementation delays have resulted from the 676 challenges of handling a TLS handshake in a kernel 677 environment. Those issues stem from the architecture of 678 TLS and the kernel, not from the design of the RPC-over- 679 TLS protocol. 681 6.4. FreeBSD NFS server and client 683 Organization: The FreeBSD Project 685 URL: https://www.freebsd.org 687 Maturity: Prototype software based on early versions of the current 688 document. 690 Coverage: The bulk of this specification is implemented. The use of 691 DTLS functionality is not planned. 693 Licensing: BSD 695 Implementation experience: Implementers have read and commented on 696 the current document. 698 7. Security Considerations 700 One purpose of the mechanism described in the current document is to 701 protect RPC-based applications against threats to the confidentiality 702 of RPC transactions and RPC user identities. A taxonomy of these 703 threats appears in Section 5 of [RFC6973]. Also, Section 6 of 704 [RFC7525] contains a detailed discussion of technologies used in 705 conjunction with TLS. Section 8 of [RFC5280] covers important 706 considerations about handling certificate material securely. 707 Implementers should familiarize themselves with these materials. 709 Once a TLS session is established, the RPC payload carried on TLS 710 version 1.3 is forward-secure. However, implementers need to be 711 aware that replay attacks can occur during session establishment. 712 Remedies for such attacks are discussed in detail in Section 8 of 713 [RFC8446]. Further, the current document does not provide a profile 714 that defines the use of 0-RTT data (see Appendix E.5 of [RFC8446]). 715 Therefore, RPC-over-TLS implementations MUST NOT use 0-RTT data. 717 7.1. The Limitations of Opportunistic Security 719 Readers can find the definition of Opportunistic Security in 720 [RFC7435]. A discussion of its underlying principals appears in 721 Section 3 of that document. 723 The purpose of using an explicitly opportunistic approach is to 724 enable interoperation with implementations that do not support RPC- 725 over-TLS. A range of options is allowed by this approach, from "no 726 peer authentication or encryption" to "server-only authentication 727 with encryption" to "mutual authentication with encryption". The 728 actual security level may indeed be selected based on policy and 729 without user intervention. 731 In environments where interoperability is a priority, the security 732 benefits of TLS are partially or entirely waived. Implementations of 733 the mechanism described in the current document must take care to 734 accurately represent to all RPC consumers the level of security that 735 is actually in effect, and are REQUIRED to provide an audit log of 736 RPC-over-TLS security mode selection. 738 In all other cases, the adoption, implementation, and deployment of 739 RPC-based upper-layer protocols that enforce the use of TLS 740 authentication and encryption (when similar RPCSEC GSS services are 741 not in use) is strongly encouraged. 743 7.1.1. STRIPTLS Attacks 745 A classic form of attack on network protocols that initiate an 746 association in plain-text to discover support for TLS is a man-in- 747 the-middle that alters the plain-text handshake to make it appear as 748 though TLS support is not available on one or both peers. Client 749 implementers can choose from the following to mitigate STRIPTLS 750 attacks: 752 * A TLSA record [RFC6698] can alert clients that TLS is expected to 753 work, and provide a binding of hostname to X.509 identity. If TLS 754 cannot be negotiated or authentication fails, the client 755 disconnects and reports the problem. 757 * Client security policy can require that a TLS session is 758 established on every connection. If an attacker spoofs the 759 handshake, the client disconnects and reports the problem. This 760 policy prevents an attacker from causing the client to silently 761 fall back to plaintext. If TLSA records are not available, this 762 approach is strongly encouraged. 764 7.1.2. Privacy Leakage Before Session Establishment 766 As mentioned earlier, communication between an RPC client and server 767 appears in the clear on the network prior to the establishment of a 768 TLS session. This clear-text information usually includes transport 769 connection handshake exchanges, the RPC NULL procedure probing 770 support for TLS, and the initial parts of TLS session establishment. 771 Appendix C of [RFC8446] discusses precautions that can mitigate 772 exposure during the exchange of connection handshake information and 773 TLS certificate material that might enable attackers to track the RPC 774 client. 776 Any RPC traffic that appears on the network before a TLS session has 777 been established is vulnerable to monitoring or undetected 778 modification. A secure client implementation limits or prevents any 779 RPC exchanges that are not protected. 781 The exception to this edict is the initial RPC NULL procedure that 782 acts as a STARTTLS message, which cannot be protected. This RPC NULL 783 procedure contains no arguments or results, and the AUTH_TLS 784 authentication flavor it uses does not contain user information, so 785 there is negligible privacy impact from this exception. 787 7.2. TLS Identity Management on Clients 789 The goal of the RPC-over-TLS protocol extension is to hide the 790 content of RPC requests while they are in transit. The RPC-over-TLS 791 protocol by itself cannot protect against exposure of a user's RPC 792 requests to other users on the same client. 794 Moreover, client implementations are free to transmit RPC requests 795 for more than one RPC user using the same TLS session. Depending on 796 the details of the client RPC implementation, this means that the 797 client's TLS credentials are potentially visible to every RPC user 798 that shares a TLS session. Privileged users may also be able to 799 access this TLS identity. 801 As a result, client implementations need to carefully segregate TLS 802 credentials so that local access to it is restricted to only the 803 local users that are authorized to perform operations on the remote 804 RPC server. 806 7.3. Security Considerations for AUTH_SYS on TLS 808 Using a TLS-protected transport when the AUTH_SYS authentication 809 flavor is in use addresses several longstanding weaknesses in 810 AUTH_SYS (as detailed in Appendix A). TLS augments AUTH_SYS by 811 providing both integrity protection and confidentiality that AUTH_SYS 812 lacks. TLS protects data payloads, RPC headers, and user identities 813 against monitoring and alteration while in transit. 815 TLS guards against in-transit insertion and deletion of RPC messages, 816 thus ensuring the integrity of the message stream between RPC client 817 and server. DTLS does not provide full message stream protection, 818 but it does enable receivers to reject non-participant messages. In 819 particular, transport layer encryption plus peer authentication 820 protects receiving XDR decoders from deserializing untrusted data, a 821 common coding vulnerability. However, these decoders would still be 822 exposed to untrusted input in the case of the compromise of a trusted 823 peer or Certificate Authority. 825 The use of TLS enables strong authentication of the communicating RPC 826 peers, providing a degree of non-repudiation. When AUTH_SYS is used 827 with TLS, but the RPC client is unauthenticated, the RPC server still 828 acts on RPC requests for which there is no trustworthy 829 authentication. In-transit traffic is protected, but the RPC client 830 itself can still misrepresent user identity without server detection. 831 TLS without authentication is an improvement from AUTH_SYS without 832 encryption, but it leaves a critical security exposure. 834 In light of the above, when AUTH_SYS is used, the use of a TLS mutual 835 authentication mechanism is RECOMMENDED to prove that the RPC client 836 is known to the RPC server. The server can then determine whether 837 the UIDs and GIDs in AUTH_SYS requests from that client can be 838 accepted, based on the authenticated identity of the client. 840 The use of TLS does not enable RPC clients to detect compromise that 841 leads to the impersonation of RPC users. Also, there continues to be 842 a requirement that the mapping of 32-bit user and group ID values to 843 user identities is the same on both the RPC client and server. 845 7.4. Best Security Policy Practices 847 RPC-over-TLS implementations and deployments are strongly encouraged 848 to adhere to the following policies to achieve the strongest possible 849 security with RPC-over-TLS. 851 * When using AUTH_NULL or AUTH_SYS, both peers are RECOMMENDED to 852 have DNSSEC TLSA records, keys with which to perform mutual peer 853 authentication using one of the methods described in Section 5.2, 854 and a security policy that requires mutual peer authentication and 855 rejection of a connection when host authentication fails. 857 * RPCSEC GSS provides integrity and privacy services which are 858 largely redundant when TLS is in use. These services SHOULD be 859 disabled in that case. 861 8. IANA Considerations 863 RFC Editor: In the following subsections, please replace RFC-TBD with 864 the RFC number assigned to this document. And, please remove this 865 Editor's Note before this document is published. 867 8.1. RPC Authentication Flavor 869 Following Appendix B of [RFC5531], the authors request a single new 870 entry in the RPC Authentication Flavor Numbers registry. The purpose 871 of the new authentication flavor is to signal the use of TLS with 872 RPC. This new flavor is not a pseudo-flavor. 874 The fields in the new entry are assigned as follows: 876 Identifier String: AUTH_TLS 878 Flavor Name: TLS 880 Value: 7 881 Description: Indicates support for RPC-over-TLS. 883 Reference: RFC-TBD 885 8.2. ALPN Identifier for SUNRPC 887 Following Section 6 of [RFC7301], the authors request the allocation 888 of the following value in the "Application-Layer Protocol Negotiation 889 (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC 890 when used over TLS. 892 Protocol: SunRPC 894 Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 896 Reference: RFC-TBD 898 8.3. Object Identifier for PKIX Extended Key Usage 900 RFC Editor: In the following subsection, please replace XXX and YYY 901 with the IANA numbers assigned to these new entries. And, please 902 remove this Editor's Note before this document is published. 904 Per the Specification Required policy as defined in Section 4.6 of 905 [RFC8126], the authors request the reservation of the following new 906 values: 908 * The RPC-over-TLS ASN.1 module in the "SMI Security for PKIX 909 Extended Key Purpose" registry (1.3.6.1.5.5.7.3) (see 910 Section 5.2.1.1 and Appendix B. 912 * The RPC-over-TLS client certificate extended key usage 913 (1.3.6.1.5.5.7.3.XXX). The description of this new entry should 914 be "id-kp-rpcTLSClient". 916 * The RPC-over-TLS server certificate extended key usage 917 (1.3.6.1.5.5.7.3.YYY). The description of this new entry should 918 be "id-kp-rpcTLSServer". 920 IANA should use the current document (RFC-TBD) as the reference for 921 the new entries. 923 9. References 925 9.1. Normative References 927 [I-D.ietf-kitten-tls-channel-bindings-for-tls13] 928 Whited, S., "Channel Bindings for TLS 1.3", Work in 929 Progress, Internet-Draft, draft-ietf-kitten-tls-channel- 930 bindings-for-tls13-00, 11 June 2020, 931 . 934 [I-D.ietf-tls-dtls-connection-id] 935 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 936 Identifiers for DTLS 1.2", Work in Progress, Internet- 937 Draft, draft-ietf-tls-dtls-connection-id-07, 21 October 938 2019, . 941 [I-D.ietf-tls-dtls13] 942 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 943 Datagram Transport Layer Security (DTLS) Protocol Version 944 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 945 dtls13-38, 29 May 2020, 946 . 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, 950 DOI 10.17487/RFC2119, March 1997, 951 . 953 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 954 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 955 . 957 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 958 Housley, R., and W. Polk, "Internet X.509 Public Key 959 Infrastructure Certificate and Certificate Revocation List 960 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 961 . 963 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 964 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 965 May 2009, . 967 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 968 Verification of Domain-Based Application Service Identity 969 within Internet Public Key Infrastructure Using X.509 970 (PKIX) Certificates in the Context of Transport Layer 971 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 972 2011, . 974 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 975 X.509 PKIX Resource Certificates", RFC 6487, 976 DOI 10.17487/RFC6487, February 2012, 977 . 979 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 980 "Transport Layer Security (TLS) Application-Layer Protocol 981 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 982 July 2014, . 984 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 985 Code: The Implementation Status Section", BCP 205, 986 RFC 7942, DOI 10.17487/RFC7942, July 2016, 987 . 989 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 990 Writing an IANA Considerations Section in RFCs", BCP 26, 991 RFC 8126, DOI 10.17487/RFC8126, June 2017, 992 . 994 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 995 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 996 May 2017, . 998 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 999 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1000 . 1002 [X.509] International Telephone and Telegraph Consultative 1003 Committee, "ITU-T X.509 - Information technology - The 1004 Directory: Public-key and attribute certificate 1005 frameworks.", ISO/IEC 9594-8, CCITT Recommendation X.509, 1006 October 2019. 1008 9.2. Informative References 1010 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 1011 RFC 1833, DOI 10.17487/RFC1833, August 1995, 1012 . 1014 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1015 Specification", RFC 2203, DOI 10.17487/RFC2203, September 1016 1997, . 1018 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1019 DOI 10.17487/RFC2818, May 2000, 1020 . 1022 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1023 of Named Entities (DANE) Transport Layer Security (TLS) 1024 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1025 2012, . 1027 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1028 Morris, J., Hansen, M., and R. Smith, "Privacy 1029 Considerations for Internet Protocols", RFC 6973, 1030 DOI 10.17487/RFC6973, July 2013, 1031 . 1033 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1034 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1035 2014, . 1037 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1038 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1039 December 2014, . 1041 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1042 "Recommendations for Secure Use of Transport Layer 1043 Security (TLS) and Datagram Transport Layer Security 1044 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1045 2015, . 1047 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 1048 Memory Access Transport for Remote Procedure Call Version 1049 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 1050 . 1052 [RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC- 1053 over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167, 1054 June 2017, . 1056 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 1057 Völker, "Packetization Layer Path MTU Discovery for 1058 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 1059 September 2020, . 1061 Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor 1063 The ONC RPC protocol, as specified in [RFC5531], provides several 1064 modes of security, traditionally referred to as "authentication 1065 flavors". Some of these flavors provide much more than an 1066 authentication service. We refer to these as authentication flavors, 1067 security flavors, or simply, flavors. One of the earliest and most 1068 basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of 1069 [RFC5531] specifies AUTH_SYS. 1071 AUTH_SYS assumes that the RPC client and server both use POSIX-style 1072 user and group identifiers (each user and group can be distinctly 1073 represented as a 32-bit unsigned integer). It also assumes that the 1074 client and server both use the same mapping of user and group to an 1075 integer. One user ID, one primary group ID, and up to 16 1076 supplemental group IDs are associated with each RPC request. The 1077 combination of these identifies the entity on the client that is 1078 making the request. 1080 A string identifies peers (hosts) in each RPC request. [RFC5531] 1081 does not specify any requirements for this string other than that is 1082 no longer than 255 octets. It does not have to be the same from 1083 request to request. Also, it does not have to match the DNS hostname 1084 of the sending host. For these reasons, even though most 1085 implementations fill in their hostname in this field, receivers 1086 typically ignore its content. 1088 Appendix A of [RFC5531] contains a brief explanation of security 1089 considerations: 1091 | It should be noted that use of this flavor of authentication does 1092 | not guarantee any security for the users or providers of a 1093 | service, in itself. The authentication provided by this scheme 1094 | can be considered legitimate only when applications using this 1095 | scheme and the network can be secured externally, and privileged 1096 | transport addresses are used for the communicating end-points (an 1097 | example of this is the use of privileged TCP/UDP ports in UNIX 1098 | systems -- note that not all systems enforce privileged transport 1099 | address mechanisms). 1101 It should be clear, therefore, that AUTH_SYS by itself (i.e., without 1102 strong client authentication) offers little to no communication 1103 security: 1105 1. It does not protect the confidentiality or integrity of RPC 1106 requests, users, or payloads, relying instead on "external" 1107 security. 1109 2. It does not provide authentication of RPC peer machines, other 1110 than inclusion of an unprotected domain name. 1112 3. The use of 32-bit unsigned integers as user and group identifiers 1113 is problematic because these data types are not cryptographically 1114 signed or otherwise verified by any authority. In addition, the 1115 mapping of these integers to users and groups has to be 1116 consistent amongst a server and its cohort of clients. 1118 4. Because the user and group ID fields are not integrity-protected, 1119 AUTH_SYS does not provide non-repudiation. 1121 Appendix B. ASN.1 Module 1123 RFC Editor: In the following section, please replace XXX and YYY with 1124 the IANA numbers assigned to these new entries. And, please remove 1125 this Editor's Note before this document is published. 1127 1128 -- OID Arc 1130 id-kp OBJECT IDENTIFIER ::= 1131 { iso(1) identified-organization(3) dod(6) internet(1) 1132 security(5) mechanisms(5) pkix(7) kp(3) } 1134 -- Extended Key Usage Values 1136 id-kp-rpcTLSClient OBJECT IDENTIFIER ::= { id-kp XXX } 1137 id-kp-rpcTLSServer OBJECT IDENTIFIER ::= { id-kp YYY } 1138 1140 Acknowledgments 1142 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 1143 with Stunnel TLS" (https://www.linuxjournal.com/content/encrypting- 1144 nfsv4-stunnel-tls). His article inspired the mechanism described in 1145 the current document. 1147 Many thanks to Tigran Mkrtchyan and Rick Macklem for their work on 1148 prototype implementations and feedback on the current document. 1150 Thanks to Derrell Piper for numerous suggestions that improved both 1151 this simple mechanism and the current document's security-related 1152 discussion. 1154 Many thanks to Transport Area Director Magnus Westerlund for his 1155 sharp questions and careful reading of the final revisions of the 1156 current document. The text of Section 5.1.2 is mostly his 1157 contribution. Also, thanks to Benjamin Kaduk for his expert guidance 1158 on the use of PKIX and TLS. In addition, the authors thank the other 1159 members of the IESG for their astute review comments. These 1160 contributors made this a significantly better document. 1162 The authors are additionally grateful to Bill Baker, David Black, 1163 Alan DeKok, Lars Eggert, Olga Kornievskaia, Greg Marsden, Alex 1164 McDonald, Justin Mazzola Paluska, Tom Talpey, Martin Thomson, and 1165 Nico Williams, for their input and support of this work. 1167 Finally, special thanks to NFSV4 Working Group Chair and document 1168 shepherd David Noveck, NFSV4 Working Group Chairs Spencer Shepler and 1169 Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for 1170 their guidance and oversight. 1172 Authors' Addresses 1174 Trond Myklebust 1175 Hammerspace Inc 1176 4300 El Camino Real Ste 105 1177 Los Altos, CA 94022 1178 United States of America 1180 Email: trond.myklebust@hammerspace.com 1182 Charles Lever (editor) 1183 Oracle Corporation 1184 United States of America 1186 Email: chuck.lever@oracle.com