idnits 2.17.1 draft-cel-nfsv4-rpc-tls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5531, but the abstract doesn't seem to mention this, which it should. 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 (November 12, 2018) is 1992 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) ** 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 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 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: May 16, 2019 November 12, 2018 8 Remote Procedure Call Version 2 Encryption By Default 9 draft-cel-nfsv4-rpc-tls-00 11 Abstract 13 This document proposes a mechanism that makes it possible to enable 14 in-transit encryption of Remote Procedure Call traffic with little 15 administrative overhead and full compatibility with implementations 16 that do not support it. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 16, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. RPC on TLS in Operation . . . . . . . . . . . . . . . . . . . 4 55 3.1. Discovering Server-side TLS Support . . . . . . . . . . . 4 56 3.2. Streams and Datagrams . . . . . . . . . . . . . . . . . . 5 57 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 6.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 In 2014, the IETF published [RFC7258] which recognized that 69 unauthorized observation of network traffic had become widespread, 70 and was a subversive threat to all who make use of the Internet at 71 large. It strongly recommended that newly defined Internet protocols 72 make a real effort to mitigate monitoring attacks. Typically this 73 mitigation is done by encrypting data in transit. 75 The Remote Procedure Call version 2 protocol has been around for more 76 than a decade [RFC5531]. Support for in-transit encryption of RPC 77 was introduced with RPCSEC GSS [RFC7861]. However, experience has 78 shown that RPCSEC GSS is challenging to deploy, especially in 79 environments where: 81 o Per-host administrative or deployment costs must be kept to a 82 minimum, 84 o Parts of the RPC header that remain in clear-text are a security 85 exposure, 87 o Host CPU resources are at a premium, or 89 o Host identity management is carried out in a security domain that 90 is distinct from user identity management. 92 However strong a privacy service is, it is not effective if it cannot 93 be deployed in typical environments. 95 An alternative approach is to employ a transport layer security 96 mechanism that can protect the privacy of each RPC connection 97 transparently to RPC and Upper Layer protocols. The Transport Layer 98 Security protocol [RFC8446] (TLS) is a well-established Internet 99 building block that protects many common Internet protocols such as 100 https [RFC2818]. 102 Encrypting at the RPC transport layer enables several significant 103 benefits. 105 Encryption By Default 106 With the use of pre-shared keys, in-transit encryption can be 107 enabled immediately after installation without additional 108 administrative actions such as identifying the host system to a 109 trust authority, generating additional key material, or 110 provisioning a secure network tunnel. 112 Protection of Existing Protocols 113 The imposition of encryption at the transport layer protects any 114 Upper Layer protocol that employs RPC without alteration of that 115 protocol. RPC transport layer encryption can protect recent 116 versions of NFS such as NFS version 4.2 [RFC7862] and indeed 117 legacy NFS versions such as NFS version 3 [RFC1813] and NFS side- 118 band protocols such as the MNT protocol [RFC1813]. 120 Decoupled User and Host Identities 121 RPCSEC GSS provides a framework for cryptographically protecting 122 user and host identities, but assumes that both are managed by the 123 same security authority. 125 Encryption Offload 126 The use of a well-established transport encryption mechanism that 127 is also employed by other very common network protocols makes it 128 possible to use hardware encryption implementations so that the 129 host CPU is not burdened with the work of encrypting and 130 decrypting large RPC arguments and results. 132 This document adopts the terminology introduced in Section 3 of 133 [RFC6973], and assumes a working knowledge of the Remote Procedure 134 Call (RPC) version 2 protocol [RFC5531] and the Transport Layer 135 Security (TLS) version 1.3 protocol [RFC8446]. 137 2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] [RFC8174] 142 when, and only when, they appear in all capitals, as shown here. 144 3. RPC on TLS in Operation 146 3.1. Discovering Server-side TLS Support 148 The mechanism described in this document interoperates fully with 149 implementations that do not support it. Encryption (TLS) is 150 automatically disabled in these cases. To achieve this, we introduce 151 a new authentication flavor called AUTH_TLS. 153 155 enum auth_flavor { 156 AUTH_NONE = 0, 157 AUTH_SYS = 1, 158 AUTH_SHORT = 2, 159 AUTH_DH = 3, 160 AUTH_KERB = 4, 161 AUTH_RSA = 5, 162 RPCSEC_GSS = 6, 163 AUTH_TLS = 7, 165 /* and more to be defined */ 166 }; 168 170 This new flavor is used to signal that the client wants to initiate 171 TLS security negotiation if the server supports it. The length of 172 the opaque data constituting the credential MUST be zero. The 173 verifier accompanying the credential MUST be an AUTH_NONE verifier of 174 length zero. The flavor value of the verifier received in the reply 175 message from the server MUST be AUTH_NONE. The bytes of the 176 verifier's string encode the fixed ASCII characters "STARTTLS". 178 When an RPC client is ready to initiate TLS negotiation, it sends a 179 NULL RPC request with an auth_flavor of AUTH_TLS. The server can 180 respond in one of three ways: 182 o If the server does not recognise the AUTH_TLS authentication 183 flavor, it responds with a reject_stat of AUTH_ERROR. The client 184 then knows that this server does not support TLS. 186 o If the server accepts the NULL RPC procedure, but fails to return 187 an AUTH_NONE verifier containing the string "STARTTLS", the client 188 knows that this server does not support TLS. 190 o If the server accepts the NULL RPC procedure, and returns an 191 AUTH_NONE verifier containing the string "STARTTLS", the client 192 MAY proceed with TLS security negotiation. 194 If a client attempts to use AUTH_TLS for anything other than the NULL 195 RPC procedure, the server responds with a reject_stat of AUTH_ERROR. 197 Once TLS security negotiation is complete, the client and server will 198 have established a secure channel for communicating and can proceed 199 to use standard security flavours within that channel, presumably 200 after negotiating down the irrelevant RPCSEC_GSS privacy and 201 integrity services and applying channel binding. 203 If TLS negotiation fails for any reason (for example the server 204 rejects the certificate presented by the client), the RPC client 205 reports this failure to the calling application the same way it would 206 report an AUTH_ERROR rejection from the server. 208 3.2. Streams and Datagrams 210 RPC commonly operates on stream transports and datagram transports. 211 When operating on a stream transport, using TLS [RFC8446] is 212 appropriate. On a datagram transport, RPC should use DTLS [RFC6347]. 214 RPC-over-RDMA [RFC8166] may make use of transport layer security 215 below the RDMA transport layer. 217 3.3. Authentication 219 Both RPC and TLS have their own in-built forms of host and user 220 authentication. Each have their strengths and weaknesses. We 221 believe the combination of host authentication via TLS and user 222 authentication via RPC provides optimal security, efficiency, and 223 flexibility, although many combinations are possible. 225 TLS Encryption-only with AUTH_SYS: A pre-shared key enables TLS 226 encryption. The RPC client uses AUTH_SYS to identify users with 227 the guarantee that the UID and GID values cannot be observed or 228 altered in transit. 230 TLS Encryption-only with RPCSEC GSS Kerberos: A pre-shared key 231 enables TLS encryption in encryption-only mode. The RPC client 232 uses Kerberos to identify the client host and its users, and does 233 not need to additionally require costly GSS integrity or privacy 234 services. 236 TLS per-client certificate with AUTH_SYS: During TLS negotiation, 237 the client identifies itself to the server with a unique 238 certificate. The server can use this identity to perform 239 additional authorization of the client's requests. 241 TLS per-user certificate with AUTH_NONE: Each user establishes her 242 own TLS context with the server, identified by a unique 243 certficate. There is no need for any additional information at 244 the RPC layer, so the RPC client can use the simplest 245 authentication flavor for RPC transactions. 247 4. Security Considerations 249 One purpose of the mechanism described in this document is to protect 250 RPC-based applications against threats to the privacy of RPC 251 transactions and RPC user identities. A taxonomy of these threats 252 appears in Section 5 of [RFC6973]. In addition, Section 6 of 253 [RFC7525] contains a detailed discussion of technologies used in 254 conjunction with TLS. Implementers should familiarize themselves 255 with these materials. 257 The NFS version 4 protocol permits more than one user to use an NFS 258 client at the same time [RFC7862]. Typically that NFS client will 259 conserve connection resources by routing RPC transactions from all of 260 its users over a few or a single connection. In circumstances where 261 the users on that NFS client belong to multiple distinct security 262 domains, it may be necessary to establish separate TLS-protected 263 connections that do not share the same encryption parameters. 265 5. IANA Considerations 267 This document does not require actions by IANA. 269 6. References 271 6.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 279 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 280 May 2009, . 282 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 283 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 284 January 2012, . 286 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 287 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 288 2014, . 290 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 291 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 292 November 2016, . 294 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 295 Memory Access Transport for Remote Procedure Call Version 296 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 297 . 299 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 300 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 301 May 2017, . 303 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 304 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 305 . 307 6.2. Informative References 309 [LJNL] Fisher, C., "Encrypting NFSv4 with Stunnel TLS", August 310 2018, . 313 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 314 Version 3 Protocol Specification", RFC 1813, 315 DOI 10.17487/RFC1813, June 1995, 316 . 318 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 319 DOI 10.17487/RFC2818, May 2000, 320 . 322 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 323 Morris, J., Hansen, M., and R. Smith, "Privacy 324 Considerations for Internet Protocols", RFC 6973, 325 DOI 10.17487/RFC6973, July 2013, 326 . 328 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 329 "Recommendations for Secure Use of Transport Layer 330 Security (TLS) and Datagram Transport Layer Security 331 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 332 2015, . 334 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 335 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 336 November 2016, . 338 Acknowledgments 340 Special mention goes to Charles Fisher, author of "Encrypting NFSv4 341 with Stunnel TLS" [LJNL]. His article inspired the mechanism 342 described in this document. 344 The authors wish to thank Bill Baker, David Black, Benjamin Kaduk 345 Greg Marsden, David Noveck, and Justin Mazzola Paluska for their 346 input and support of this work. 348 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 349 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 350 Working Group Secretary Thomas Haynes for their guidance and 351 oversight. 353 Authors' Addresses 355 Trond Myklebust 356 Hammerspace Inc 357 4300 El Camino Real Ste 105 358 Los Altos, CA 94022 359 United States of America 361 Email: trond.myklebust@hammerspace.com 363 Charles Lever (editor) 364 Oracle Corporation 365 1015 Granger Avenue 366 Ann Arbor, MI 48104 367 United States of America 369 Email: chuck.lever@oracle.com