idnits 2.17.1 draft-ietf-nfsv4-rpc-tls-03.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 (September 21, 2019) is 1678 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 863 == Unused Reference: 'RFC5661' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC7530' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC7863' is defined on line 787, but no explicit reference was found in the text ** 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 (~~), 4 warnings (==), 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: March 24, 2020 September 21, 2019 8 Remote Procedure Call Encryption By Default 9 draft-ietf-nfsv4-rpc-tls-03 11 Abstract 13 This document describes a mechanism that, through the use of 14 opportunistic Transport Layer Security (TLS), enables encryption of 15 in-transit Remote Procedure Call (RPC) transactions while 16 interoperating with ONC RPC implementations that do not support this 17 mechanism. This document updates RFC 5531. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 24, 2020. 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 . . . . . . . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 69 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 5 70 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 71 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 72 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Base Transport Considerations . . . . . . . . . . . . . . 8 74 5.1.1. Operation on TCP . . . . . . . . . . . . . . . . . . 8 75 5.1.2. Operation on UDP . . . . . . . . . . . . . . . . . . 9 76 5.1.3. Operation on Other Transports . . . . . . . . . . . . 9 77 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 9 78 5.2.1. X.509 Certificates Using PKIX trust . . . . . . . . . 9 79 5.2.2. X.509 Certificates Using Fingerprints . . . . . . . . 11 80 5.2.3. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 11 81 5.2.4. Token Binding . . . . . . . . . . . . . . . . . . . . 11 82 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 83 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 12 84 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 12 85 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 12 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7.1. Limitations of an Opportunistic Approach . . . . . . . . 13 88 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 13 89 7.2. Multiple User Identity Realms . . . . . . . . . . . . . . 14 90 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 14 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 9.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Appendix A. Known Weaknesses of the AUTH_SYS Authentication 96 Flavor . . . . . . . . . . . . . . . . . . . . . . . 18 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 In 2014 the IETF published [RFC7258] which recognized that 103 unauthorized observation of network traffic had become widespread and 104 was a subversive threat to all who make use of the Internet at large. 105 It strongly recommended that newly defined Internet protocols make a 106 real effort to mitigate monitoring attacks. Typically this 107 mitigation is done by encrypting data in transit. 109 The Remote Procedure Call version 2 protocol has been a Proposed 110 Standard for three decades (see [RFC5531] and its antecedants). 111 Eisler et al. first introduced an in-transit encryption mechanism for 112 RPC with RPCSEC GSS over twenty years ago [RFC2203]. However, 113 experience has shown that RPCSEC GSS can be difficult to deploy: 115 o Per-client deployment and administrative costs are not scalable. 116 Keying material must be provided for each RPC client, including 117 transient clients. 119 o Parts of each RPC header remain in clear-text, and can constitute 120 a significant security exposure. 122 o Host identity management and user identity management must be 123 carried out in the same security realm. In certain environments, 124 different authorities might be responsible for provisioning client 125 systems versus provisioning new users. 127 o On-host cryptographic manipulation of data payloads can exact a 128 significant CPU and memory bandwidth cost on RPC peers. Offloadng 129 does not appear to be practical using GSS privacy since each 130 message is encrypted using its own key based on the issuing RPC 131 user. 133 However strong a privacy service is, it cannot provide any security 134 if the challenges of using it result in it not being used at all. 136 An alternative approach is to employ a transport layer security 137 mechanism that can protect the privacy of each RPC connection 138 transparently to RPC and Upper Layer protocols. The Transport Layer 139 Security protocol [RFC8446] (TLS) is a well-established Internet 140 building block that protects many common Internet protocols such as 141 the Hypertext Transport Protocol (http) [RFC2818]. 143 Encrypting at the RPC transport layer enables several significant 144 benefits. 146 Encryption By Default 147 In-transit encryption by itself may be enabled without additional 148 administrative actions such as identifying client systems to a 149 trust authority, generating additional key material, or 150 provisioning a secure network tunnel. 152 Protection of Existing Protocols 153 The imposition of encryption at the transport layer protects any 154 Upper Layer protocol that employs RPC, without alteration of that 155 protocol. RPC transport layer encryption can protect recent 156 versions of NFS such as NFS version 4.2 [RFC7862] and indeed 157 legacy NFS versions such as NFS version 3 [RFC1813], and NFS side- 158 band protocols such as the MNT protocol [RFC1813]. 160 Decoupled User and Host Identities 161 TLS can be used to authenticate peer hosts while other security 162 mechanisms can handle user authentictation. Cryptographic 163 authentication of hosts can be provided while still using simpler 164 user authentication flavors such as AUTH_SYS. 166 Encryption Offload 167 Whereas hardware support for GSS privacy has not appeared in the 168 marketplace, the use of a well-established transport encryption 169 mechanism that is also employed by other very common network 170 protocols makes it likely that a hardware encryption 171 implementation will be available to offload encryption and 172 decryption. 174 Securing AUTH_SYS 175 Most critically, several security issues inherent in the current 176 widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs 177 generated by an unauthenticated client) can be significantly 178 ameliorated. 180 This document specifies the use of RPC on a TLS-protected transport 181 in a fashion that is transparent to upper layer protocols based on 182 RPC. It provides policies in line with [RFC7435] that enable RPC-on- 183 TLS to be deployed opportunistically in environments with RPC 184 implementations that do not support TLS. Specifications for RPC- 185 based upper layer protocols are free to require stricter policies to 186 guarantee that TLS with encryption or TLS with host authentication 187 and encryption is used for every connection. 189 2. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 3. Terminology 199 This document adopts the terminology introduced in Section 3 of 200 [RFC6973] and assumes a working knowledge of the Remote Procedure 201 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 202 Security (TLS) version 1.3 protocol [RFC8446]. 204 Note also that the NFS community uses the term "privacy" where other 205 Internet communities use "confidentiality". In this document the two 206 terms are synonymous. 208 We adhere to the convention that a "client" is a network host that 209 actively initiates an association, and a "server" is a network host 210 that passively accepts an association request. 212 RPC documentation historically refers to the authentication of a 213 connecting host as "machine authentication" or "host authentication". 214 TLS documentation refers to the same as "peer authentication". In 215 this document there is little distinction between these terms. 217 The term "user authentication" in this document refers specifically 218 to the RPC caller's credential, provided in the "cred" and "verf" 219 fields in each RPC Call. 221 4. RPC-Over-TLS in Operation 223 4.1. Discovering Server-side TLS Support 225 The mechanism described in this document interoperates fully with RPC 226 implementations that do not support TLS. The use of TLS is 227 automatically disabled in these cases. 229 To achieve this, we introduce a new RPC authentication flavor called 230 AUTH_TLS. This new flavor is used to signal that the client wants to 231 initiate TLS negotiation if the server supports it. Except for the 232 modifications described in this section, the RPC protocol is largely 233 unaware of security encapsulation. 235 237 enum auth_flavor { 238 AUTH_NONE = 0, 239 AUTH_SYS = 1, 240 AUTH_SHORT = 2, 241 AUTH_DH = 3, 242 AUTH_KERB = 4, 243 AUTH_RSA = 5, 244 RPCSEC_GSS = 6, 245 AUTH_TLS = 7, 247 /* and more to be defined */ 248 }; 250 252 The length of the opaque data constituting the credential sent in the 253 call message MUST be zero. The verifier accompanying the credential 254 MUST be an AUTH_NONE verifier of length zero. 256 The flavor value of the verifier received in the reply message from 257 the server MUST be AUTH_NONE. The bytes of the verifier's string 258 encode the fixed ASCII characters "STARTTLS". 260 When an RPC client is ready to begin sending traffic to a server, it 261 starts with a NULL RPC request with an auth_flavor of AUTH_TLS. The 262 NULL request is made to the same port as if TLS were not in use. 264 The RPC server can respond in one of three ways: 266 o If the RPC server does not recognise the AUTH_TLS authentication 267 flavor, it responds with a reject_stat of AUTH_ERROR. The RPC 268 client then knows that this server does not support TLS. 270 o If the RPC server accepts the NULL RPC procedure, but fails to 271 return an AUTH_NONE verifier containing the string "STARTTLS", the 272 RPC client knows that this server does not support TLS. 274 o If the RPC server accepts the NULL RPC procedure, and returns an 275 AUTH_NONE verifier containing the string "STARTTLS", the RPC 276 client SHOULD send a STARTTLS. 278 Once the TLS handshake is complete, the RPC client and server will 279 have established a secure channel for communicating. The client MUST 280 switch to a security flavor other than AUTH_TLS within that channel, 281 presumably after negotiating down redundant RPCSEC_GSS privacy and 282 integrity services and applying channel binding [RFC7861]. 284 If TLS negotiation fails for any reason -- say, the RPC server 285 rejects the certificate presented by the RPC client, or the RPC 286 client fails to authenticate the RPC server -- the RPC client reports 287 this failure to the calling application the same way it would report 288 an AUTH_ERROR rejection from the RPC server. 290 If an RPC client attempts to use AUTH_TLS for anything other than the 291 NULL RPC procedure, the RPC server MUST respond with a reject_stat of 292 AUTH_ERROR. If the client sends a STARTTLS after it has sent other 293 non-encrypted RPC traffic or after a TLS session has already been 294 negotiated, the server MUST silently discard it. 296 4.2. Authentication 298 Both RPC and TLS have their own variants of authentication, and there 299 is some overlap in capability. The goal of interoperability with 300 implementations that do not support TLS requires that we limit the 301 combinations that are allowed and precisely specify the role that 302 each layer plays. We also want to handle TLS such that an RPC 303 implementation can make the use of TLS invisible to existing RPC 304 consumer applications. 306 Each RPC server that supports RPC-over-TLS MUST possess a unique 307 global identity (e.g., a certificate that is signed by a well-known 308 trust anchor). Such an RPC server MUST request a TLS peer identity 309 from each client upon first contact. There are two different modes 310 of client deployment: 312 Server-only Host Authentication 313 In this type of deployment, RPC-over-TLS clients are essentially 314 anonymous; i.e., they present no globally unique identifier to the 315 server peer. In this situation, the client can authenticate the 316 server host using the presented server peer TLS identity, but the 317 server cannot authenticate the client. 319 Mutual Host Authentication 320 In this type of deployment, the client possesses a unique global 321 identity (e.g., a certificate). As part of the TLS handshake, 322 both peers authenticate using the presented TLS identities. If 323 authentication of either peer fails, or if authorization based on 324 those identities blocks access to the server, the client 325 association SHOULD be rejected. 327 In either of these modes, RPC user authentication is not affected by 328 the use of transport layer security. Once a TLS session is 329 established, the server MUST NOT utilize the client peer's TLS 330 identity for the purpose of authorizing individual RPC requests. 332 4.2.1. Using TLS with RPCSEC GSS 334 RPCSEC GSS can provide per-request integrity or privacy (also known 335 as confidentiality) services. When operating over a TLS session, 336 these services become redundant. A TLS-capable RPC implementation 337 uses GSS channel binding for detecting when GSS integrity or privacy 338 is unnecessary and can therefore be avoided. See Section 2.5 of 339 [RFC7861] for details. 341 When employing GSS above TLS, a GSS service principal is still 342 required on the server, and mutual GSS authentication of server and 343 client still occurs after the TLS session is established. 345 5. TLS Requirements 347 When a TLS session is negotiated for the purpose of transporting RPC, 348 the following restrictions apply: 350 o Implementations MUST NOT negotiate TLS versions prior to v1.3 351 [RFC8446]. Support for mandatory-to-implement ciphersuites for 352 the negotiated TLS version is REQUIRED. 354 o Implementations MUST support certificate-based mutual 355 authentication. Support for TLS-PSK mutual authentication 356 [RFC4279] is OPTIONAL. See Section 4.2 for further details. 358 o Negotiation of a ciphersuite providing for confidentiality as well 359 as integrity protection is REQUIRED. Support for and negotiation 360 of compression is OPTIONAL. 362 5.1. Base Transport Considerations 364 5.1.1. Operation on TCP 366 RPC over TCP is protected by using TLS [RFC8446]. As soon as a 367 client completes the TCP handshake, it uses the mechanism described 368 in Section 4.1 to discover TLS support and then negotiate a TLS 369 session. 371 After the TLS session is established, all traffic on the connection 372 is encapsulated and protected until the TLS session is terminated. 373 This includes reverse-direction operations (i.e., RPC requests 374 initiated on the server-end of the connection). An RPC client 375 receiving a reverse-direction operation on a connection outside of an 376 existing TLS session MUST reject the request with a reject_stat of 377 AUTH_ERROR. 379 An RPC peer terminates a TLS session by sending a TLS closure alert, 380 or by closing the underlying TCP socket. After TLS session 381 termination, a recipient MUST reject any subsequent RPC requests over 382 the same connection with a reject_stat of AUTH_ERROR. 384 5.1.2. Operation on UDP 386 RPC over UDP is protected using DTLS [RFC6347]. As soon as a client 387 initializes a socket for use with an unfamiliar server, it uses the 388 mechanism described in Section 4.1 to discover DTLS support and then 389 negotiate a DTLS session. Connected operation is RECOMMENDED. 391 Using a DTLS transport does not introduce reliable or in-order 392 semantics to RPC on UDP. Also, DTLS does not support fragmentation 393 of RPC messages. One RPC message fits in a single DTLS datagram. 394 DTLS encapsulation has overhead which reduces the effective Path MTU 395 (PMTU) and thus the maximum RPC payload size. 397 DTLS does not detect STARTTLS replay. A DTLS session can be 398 terminated by sending a TLS closure alert. Subsequent RPC messages 399 passing between the client and server will no longer be protected 400 until a new TLS session is established. 402 5.1.3. Operation on Other Transports 404 RPC-over-RDMA can make use of Transport Layer Security below the RDMA 405 transport layer [RFC8166]. The exact mechanism is not within the 406 scope of this document. Because there might not be provisions to 407 exchange client and server certificates, authentication material 408 could be provided by facilites within a future RPC-over-RDMA 409 transport. 411 Transports that provide intrinsic TLS-level security (e.g., QUIC) 412 would need to be accommodated separately from the current document. 413 In such cases, use of TLS might not be opportunitic as it is for TCP 414 or UDP. 416 5.2. TLS Peer Authentication 418 Peer authentication can be performed by TLS using any of the 419 following mechanisms: 421 5.2.1. X.509 Certificates Using PKIX trust 423 Implementations are REQUIRED to support this mechanism. In this 424 mode, an RPC peer is uniquely identified by the tuple (serial number 425 of presented certificate;Issuer). 427 o Implementations MUST allow the configuration of a list of trusted 428 Certification Authorities for incoming connections. 430 o Certificate validation MUST include the verification rules as per 431 [RFC5280]. 433 o Implementations SHOULD indicate their trusted Certification 434 Authorities (CAs). 436 o Peer validation always includes a check on whether the locally 437 configured expected DNS name or IP address of the server that is 438 contacted matches its presented certificate. DNS names and IP 439 addresses can be contained in the Common Name (CN) or 440 subjectAltName entries. For verification, only one of these 441 entries is to be considered. The following precedence applies: 442 for DNS name validation, subjectAltName:DNS has precedence over 443 CN; for IP address validation, subjectAltName:iPAddr has 444 precedence over CN. Implementors of this specification are 445 advised to read Section 6 of [RFC6125] for more details on DNS 446 name validation. 448 o Implementations MAY allow the configuration of a set of additional 449 properties of the certificate to check for a peer's authorization 450 to communicate (e.g., a set of allowed values in 451 subjectAltName:URI or a set of allowed X509v3 Certificate 452 Policies). 454 o When the configured trust base changes (e.g., removal of a CA from 455 the list of trusted CAs; issuance of a new CRL for a given CA), 456 implementations MAY renegotiate the TLS session to reassess the 457 connecting peer's continued authorization. 459 Authenticating a connecting entity does not mean the RPC server 460 necessarily wants to communicate with that client. For example, if 461 the Issuer is not in a trusted set of Issuers, the RPC server may 462 decline to perform RPC transactions with this client. 463 Implementations that want to support a wide variety of trust models 464 should expose as many details of the presented certificate to the 465 administrator as possible so that the trust model can be implemented 466 by the administrator. As a suggestion, at least the following 467 parameters of the X.509 client certificate should be exposed: 469 o Originating IP address 471 o Certificate Fingerprint 473 o Issuer 474 o Subject 476 o all X509v3 Extended Key Usage 478 o all X509v3 Subject Alternative Name 480 o all X509v3 Certificate Policies 482 5.2.2. X.509 Certificates Using Fingerprints 484 This mechanism is OPTIONAL to implement. In this mode, an RPC peer 485 is uniquely identified by the fingerprint of the presented 486 certificate. 488 Implementations SHOULD allow the configuration of a list of trusted 489 certificates, identified via fingerprint of the DER encoded 490 certificate octets. Implementations MUST support SHA-1 as the hash 491 algorithm for the fingerprint. To prevent attacks based on hash 492 collisions, support for a more contemporary hash function, such as 493 SHA-256, is RECOMMENDED. 495 5.2.3. Pre-Shared Keys 497 This mechanism is OPTIONAL to implement. In this mode, an RPC peer 498 is uniquely identified by key material that has been shared out-of- 499 band or by a previous TLS-protected connection (see [RFC8446] 500 Section 2.2). At least the following parameters of the TLS 501 connection should be exposed: 503 o Originating IP address 505 o TLS Identifier 507 5.2.4. Token Binding 509 This mechanism is OPTIONAL to implement. In this mode, an RPC peer 510 is uniquely identified by a token. 512 Versions of TLS subsequent to TLS 1.2 feature a token binding 513 mechanism which is nominally more secure than using certificates. 514 This is discussed in further detail in [RFC8471]. 516 6. Implementation Status 518 This section records the status of known implementations of the 519 protocol defined by this specification at the time of posting of this 520 Internet-Draft, and is based on a proposal described in [RFC7942]. 521 The description of implementations in this section is intended to 522 assist the IETF in its decision processes in progressing drafts to 523 RFCs. 525 Please note that the listing of any individual implementation here 526 does not imply endorsement by the IETF. Furthermore, no effort has 527 been spent to verify the information presented here that was supplied 528 by IETF contributors. This is not intended as, and must not be 529 construed to be, a catalog of available implementations or their 530 features. Readers are advised to note that other implementations may 531 exist. 533 6.1. DESY NFS server 535 Organization: DESY 537 URL: https://desy.de 539 Maturity: Prototype software based on early versions of this 540 document. 542 Coverage: The bulk of this specification is implemented. The use of 543 DTLS functionality is not implemented. 545 Licensing: LGPL 547 Implementation experience: No comments from implementors. 549 6.2. Hammerspace NFS server 551 Organization: Hammerspace 553 URL: https://hammerspace.com 555 Maturity: Prototype software based on early versions of this 556 document. 558 Coverage: The bulk of this specification is implemented. The use of 559 DTLS functionality is not implemented. 561 Licensing: Proprietary 563 Implementation experience: No comments from implementors. 565 6.3. Linux NFS server and client 567 Organization: The Linux Foundation 569 URL: https://www.kernel.org 570 Maturity: Prototype software based on early versions of this 571 document. 573 Coverage: The bulk of this specification is implemented. The use of 574 DTLS functionality is not implemented. 576 Licensing: GPLv2 578 Implementation experience: No comments from implementors. 580 7. Security Considerations 582 One purpose of the mechanism described in this document is to protect 583 RPC-based applications against threats to the privacy of RPC 584 transactions and RPC user identities. A taxonomy of these threats 585 appears in Section 5 of [RFC6973]. In addition, Section 6 of 586 [RFC7525] contains a detailed discussion of technologies used in 587 conjunction with TLS. Implementers should familiarize themselves 588 with these materials. 590 7.1. Limitations of an Opportunistic Approach 592 A range of options is allowed by the opportunistic approach described 593 in this document, from "no peer authentication or encryption" to 594 "server-only authentication with encryption" to "mutual 595 authentication with encryption". The security level may indeed be 596 selected without user intervention based on a policy. 597 Implementations must take care to accurately represent to all RPC 598 consumers the level of security that is actually in effect. 600 7.1.1. STRIPTLS Attacks 602 A classic form of attack on network protocols that initiate an 603 association in plain-text to discover support for TLS is a man-in- 604 the-middle that alters the plain-text handshake to make it appear as 605 though TLS support is not available on one or both peers. Clients 606 implementers can choose from the following to mitigate STRIPTLS 607 attacks: 609 o A TLSA record [RFC6698] can alert clients that TLS is expected to 610 work, and provides a binding of hostname to x.509 identity. If 611 TLS cannot be negotiated or authentication fails, the client 612 disconnects and reports the problem. 614 o Client security policy can be configured to require that a TLS 615 session is established on every connection. If an attacker spoofs 616 the handshake, the client disconnects and reports the problem. If 617 TLSA records are not available, this approach is strongly 618 encouraged. 620 7.2. Multiple User Identity Realms 622 To maintain the privacy of RPC users on a single client belonging to 623 multiple distinct security realms, the client MUST establish an 624 independent TLS session for each user identity domain, each using a 625 distinct globally unique identity. The purpose of this separation is 626 to prevent even privileged users in each security realm from 627 monitoring RPC traffic emitted on behalf of users in other security 628 realms on the same peer. 630 7.3. Security Considerations for AUTH_SYS on TLS 632 The use of a TLS-protected transport when the AUTH_SYS authentication 633 flavor is in use addresses a number of longstanding weaknesses (as 634 detailed in Appendix A). TLS augments AUTH_SYS by providing both 635 integrity protection and a privacy service that AUTH_SYS lacks. This 636 protects data payloads, RPC headers, and user identities against 637 monitoring or alteration while in transit. TLS guards against the 638 insertion or deletion of messages, thus also ensuring the integrity 639 of the message stream between RPC client and server. 641 The use of TLS enables strong authentication of the communicating RPC 642 peers, providing a degree of non-repudiation. When AUTH_SYS is used 643 with TLS but the RPC client is unauthenticated, the RPC server is 644 still acting on RPC requests for which there is no trustworthy 645 authentication. In-transit traffic is protected, but the RPC client 646 itself can still misrepresent user identity without server detection. 647 This is an improvement from AUTH_SYS without encryption, but it 648 leaves a critical security exposure. 650 In light of the above, it is RECOMMENDED that when AUTH_SYS is used, 651 RPC clients present authentication material necessary for RPC servers 652 they contact to have a degree of trust that the clients are acting 653 responsibly. 655 The use of TLS does not enable detection of compromise on RPC clients 656 that leads to impersonation of RPC users. In addition, there 657 continues to be a requirement that the mapping of 32-bit user and 658 group ID values to user identities is the same on both the RPC client 659 and server. 661 8. IANA Considerations 663 In accordance with Section 6 of [RFC7301], the authors request that 664 IANA allocate the following value in the "Application-Layer Protocol 665 Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string 666 identifies SunRPC when used over TLS. 668 Protocol: 669 SunRPC 671 Identification Sequence: 672 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") 674 Reference: 675 RFC-TBD 677 9. References 679 9.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 687 Ciphersuites for Transport Layer Security (TLS)", 688 RFC 4279, DOI 10.17487/RFC4279, December 2005, 689 . 691 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 692 Housley, R., and W. Polk, "Internet X.509 Public Key 693 Infrastructure Certificate and Certificate Revocation List 694 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 695 . 697 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 698 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 699 May 2009, . 701 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 702 Verification of Domain-Based Application Service Identity 703 within Internet Public Key Infrastructure Using X.509 704 (PKIX) Certificates in the Context of Transport Layer 705 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 706 2011, . 708 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 709 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 710 January 2012, . 712 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 713 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 714 2014, . 716 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 717 "Transport Layer Security (TLS) Application-Layer Protocol 718 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 719 July 2014, . 721 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 722 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 723 November 2016, . 725 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 726 Code: The Implementation Status Section", BCP 205, 727 RFC 7942, DOI 10.17487/RFC7942, July 2016, 728 . 730 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 731 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 732 May 2017, . 734 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 735 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 736 . 738 9.2. Informative References 740 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 741 Version 3 Protocol Specification", RFC 1813, 742 DOI 10.17487/RFC1813, June 1995, 743 . 745 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 746 Specification", RFC 2203, DOI 10.17487/RFC2203, September 747 1997, . 749 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 750 DOI 10.17487/RFC2818, May 2000, 751 . 753 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 754 "Network File System (NFS) Version 4 Minor Version 1 755 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 756 . 758 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 759 of Named Entities (DANE) Transport Layer Security (TLS) 760 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 761 2012, . 763 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 764 Morris, J., Hansen, M., and R. Smith, "Privacy 765 Considerations for Internet Protocols", RFC 6973, 766 DOI 10.17487/RFC6973, July 2013, 767 . 769 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 770 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 771 December 2014, . 773 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 774 "Recommendations for Secure Use of Transport Layer 775 Security (TLS) and Datagram Transport Layer Security 776 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 777 2015, . 779 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 780 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 781 March 2015, . 783 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 784 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 785 November 2016, . 787 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 788 Version 2 External Data Representation Standard (XDR) 789 Description", RFC 7863, DOI 10.17487/RFC7863, November 790 2016, . 792 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 793 Memory Access Transport for Remote Procedure Call Version 794 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 795 . 797 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 798 "The Token Binding Protocol Version 1.0", RFC 8471, 799 DOI 10.17487/RFC8471, October 2018, 800 . 802 9.3. URIs 804 [1] https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls 806 Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor 808 The ONC RPC protocol as specified in [RFC5531] provides several modes 809 of security, traditionally referred to as "authentication flavors", 810 though some of these flavors provide much more than an authentication 811 service. We will refer to these as authentication flavors, security 812 flavors, or simply, flavors. One of the earliest and most basic 813 flavor is AUTH_SYS, also known as AUTH_UNIX. AUTH_SYS is currently 814 specified in Appendix A of [RFC5531]. 816 AUTH_SYS assumes that both the RPC client and server use POSIX-style 817 user and group identifiers (each user and group can be distinctly 818 represented as a 32-bit unsigned integer), and that both client and 819 server use the same mapping of user and group to integer. One user 820 ID, one main group ID, and up to 16 supplemental group IDs are 821 associated with each RPC request. The combination of these identify 822 the entity on the client that is making the request. 824 Peers are identified by a string in each RPC request. RFC 5531 does 825 not specify any requirements for this string other than that is no 826 longer than 255 octets. It does not have to be the same from request 827 to request, nor does it have to match the name of the sending host. 828 For these reasons, though most implementations do fill in their 829 hostname in this field, receivers typically ignore its content. 831 RFC 5531 Appendix A contains a brief explanation of security 832 considerations: 834 It should be noted that use of this flavor of authentication does 835 not guarantee any security for the users or providers of a 836 service, in itself. The authentication provided by this scheme 837 can be considered legitimate only when applications using this 838 scheme and the network can be secured externally, and privileged 839 transport addresses are used for the communicating end-points (an 840 example of this is the use of privileged TCP/UDP ports in UNIX 841 systems -- note that not all systems enforce privileged transport 842 address mechanisms). 844 It should be clear, therefore, that AUTH_SYS by itself offers little 845 to no communication security: 847 1. It does not protect the privacy or integrity of RPC requests, 848 users, or payloads, relying instead on "external" security. 850 2. It also does not provide actual authentication of RPC peer 851 machines, other than an unprotected domain name. 853 3. The use of 32-bit unsigned integers as user and group identifiers 854 is problematic because these simple data types are not signed or 855 otherwise verified by any authority. 857 4. Because the user and group ID fields are not integrity-protected, 858 AUTH_SYS does not offer non-repudiation. 860 Acknowledgments 862 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 863 with Stunnel TLS" [1]. His article inspired the mechanism described 864 in this document. 866 Many thanks to Tigran Mkrtchyan for his work on the DESY prototype 867 and resulting feedback to this document. 869 The authors are grateful to Bill Baker, David Black, Alan DeKok, Lars 870 Eggert, Benjamin Kaduk, Olga Kornievskaia, Greg Marsden, Alex 871 McDonald, David Noveck, Justin Mazzola Paluska, Tom Talpey, and 872 Martin Thomson for their input and support of this work. 874 Lastly, special thanks go to Transport Area Director Magnus 875 Westerlund, NFSV4 Working Group Chairs Spencer Shepler and Brian 876 Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their 877 guidance and oversight. 879 Authors' Addresses 881 Trond Myklebust 882 Hammerspace Inc 883 4300 El Camino Real Ste 105 884 Los Altos, CA 94022 885 United States of America 887 Email: trond.myklebust@hammerspace.com 889 Charles Lever (editor) 890 Oracle Corporation 891 United States of America 893 Email: chuck.lever@oracle.com