idnits 2.17.00 (12 Aug 2021) /tmp/idnits38148/draft-dnoveck-nfsv4-security-needs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 January 2021) is 478 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-nfsv4-rpcrdma-version-two-03 == Outdated reference: A later version (-03) exists of draft-dnoveck-nfsv4-rfc5661bis-00 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 D. Noveck 3 Internet-Draft NetApp 4 Intended status: Informational C. Lever, Ed. 5 Expires: 25 July 2021 Oracle 6 21 January 2021 8 Security Needs for the NFSv4 Protocols 9 draft-dnoveck-nfsv4-security-needs-02 11 Abstract 13 This document discusses the inadequate approach to security within 14 the family of NFSv4 protocol specifications and proposes steps to 15 correct the situation. Because the security architecture is similar 16 for all NFSv4 minor versions, we recommend a single new standards- 17 track document to encapsulate NFSv4 security fundamentals, and 18 propose the introduction of several additional security-related 19 documents. 21 Note 23 Discussion of this draft takes place on the NFSv4 working group 24 mailing list (nfsv4@ietf.org), which is archived at 25 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group 26 information can be found at https://datatracker.ietf.org/wg/nfsv4/ 27 about/. 29 This note is to be removed before publishing as an RFC. 31 The source for this draft is maintained in GitHub. Suggested changes 32 should be submitted as pull requests at 33 https://github.com/chucklever/i-d-security-needs. Instructions are 34 on that page as well. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 25 July 2021. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 72 2.2. Requirements Language as Used in This Document . . . . . 4 73 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Use of this Document . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Current Use of this Document . . . . . . . . . . . . . . 6 76 3.2. Future Use of this Document . . . . . . . . . . . . . . . 7 77 4. Situation to be Addressed . . . . . . . . . . . . . . . . . . 8 78 4.1. NFSv4 Use Environments to be Addressed . . . . . . . . . 8 79 4.2. Emergence and Correction of Security Issues . . . . . . . 9 80 5. Major Problems to Address . . . . . . . . . . . . . . . . . . 12 81 5.1. Problems with Security Presentation/Organization . . . . 12 82 5.1.1. Problems with Presentation of Security 83 Architecture . . . . . . . . . . . . . . . . . . . . 13 84 5.1.2. Problems with Security Evaluation . . . . . . . . . . 15 85 5.2. The Treatment of AUTH_SYS . . . . . . . . . . . . . . . . 15 86 5.2.1. Current AUTH_SYS Security Policies . . . . . . . . . 16 87 5.2.2. Working Group Actions . . . . . . . . . . . . . . . . 18 88 5.3. Problems with Confidentiality . . . . . . . . . . . . . . 20 89 5.4. File Access Control . . . . . . . . . . . . . . . . . . . 22 90 5.4.1. File Content Integrity and Provenance . . . . . . . . 23 91 6. Framework for Correcting Problems . . . . . . . . . . . . . . 23 92 6.1. Correcting Problems with Regard to Threat Analyses . . . 24 93 6.2. Correcting Problems with Regard to Use of Normative 94 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 7. Opportunities for Improvement Provided by Recent Work within 96 the RPC Layer . . . . . . . . . . . . . . . . . . . . . . 26 97 7.1. Opportunities for Improvement in Encryption . . . . . . . 26 98 7.2. Opportunities for Improvement in Authentication . . . . . 27 99 7.3. Opportunities for Improvement when Using RDMA 100 Transports . . . . . . . . . . . . . . . . . . . . . . . 27 101 8. Issues that Need to be Addressed . . . . . . . . . . . . . . 28 102 8.1. Threat Analysis Goals . . . . . . . . . . . . . . . . . . 28 103 8.1.1. Background . . . . . . . . . . . . . . . . . . . . . 28 104 8.1.2. Issues to be Addressed . . . . . . . . . . . . . . . 30 105 8.2. NFSv4 Extension Policies . . . . . . . . . . . . . . . . 30 106 8.2.1. Background . . . . . . . . . . . . . . . . . . . . . 30 107 8.2.2. Addressing Extension Issues . . . . . . . . . . . . . 31 108 8.3. TLS Encryption Policies . . . . . . . . . . . . . . . . . 32 109 8.3.1. Background . . . . . . . . . . . . . . . . . . . . . 32 110 8.3.2. Issues to Address . . . . . . . . . . . . . . . . . . 33 111 8.4. Handling of AUTH_SYS . . . . . . . . . . . . . . . . . . 36 112 8.4.1. Historical Background . . . . . . . . . . . . . . . . 36 113 8.4.2. Background for Existing AUTH_SYS in NFSv4 . . . . . . 37 114 8.4.3. Core Issue to Resolve for AUTH_SYS . . . . . . . . . 38 115 8.4.4. Need to Better Document and Explain Issues with 116 AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . 38 117 8.4.5. Issues to Address for Existing Use of AUTH_SYS . . . 40 118 8.4.6. Issues to Resolve for Revised Approach to AUTH_SYS . 43 119 8.5. Handling of State Protection . . . . . . . . . . . . . . 47 120 8.5.1. Background . . . . . . . . . . . . . . . . . . . . . 47 121 8.5.2. Issues to be Addressed . . . . . . . . . . . . . . . 48 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 123 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 124 10.1. Security Considerations Section for Eventual NFSv4-wide 125 Standards-track Security Document . . . . . . . . . . . 50 126 10.2. Security Considerations Section for Eventual 127 Rfc5661bis . . . . . . . . . . . . . . . . . . . . . . . 50 128 10.3. Security Considerations Section for Potential Revised RPC 129 Specification Document . . . . . . . . . . . . . . . . . 51 130 10.4. Security Considerations Section for Potential 131 Standards-track Document Dealing with AUTH_SYS . . . . . 52 132 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 133 11.1. Normative References . . . . . . . . . . . . . . . . . . 52 134 11.2. Informative References . . . . . . . . . . . . . . . . . 53 135 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 138 1. Introduction 140 This document proposes specification changes that modernize NFSv4 141 security. These changes are necessary because the original goal for 142 the NFSv4 protocol, to enable secure file exchange on the open 143 internet [RFC2624], has not been effectively realized. Moreover, 144 existing approaches to NFSv4 security do not meet the security needs 145 of many contemporary restricted-access environments. 147 Restricting physical access to the network on which a client and 148 server interact is a common NFSv4 deployment technique. This 149 restriction limits access to users associated with a particular 150 organization but does not eliminate the need for protocol support 151 that enables completely secure operation. Section 4.1 contains a 152 taxonomy of specific environments and their corresponding security 153 needs. 155 As an example, the use of transport-layer security, including the 156 encryption of network traffic and the use of client host 157 authentication, can improve security when AUTH_SYS [RFC5531] is in 158 use, replacing the security approaches specified in [RFC7530] and 159 [RFC8881]. For a discussion of issues connected to shifting the 160 security approach of mature protocols, see Section 4.2. 162 The current document serves as a resource for the nfsv4 working group 163 as it updates current standards-track documents and proposes new 164 standards-track documents to address security issues within the NFSv4 165 protocol. For further details on the expected use of this document, 166 see Section 3. 168 2. Terminology 170 2.1. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 2.2. Requirements Language as Used in This Document 180 The current document is Informational. Therefore it cannot make 181 normative statements using the keywords defined in Section 2.1. 183 However, in discussing the treatment of security within the set of 184 NFSv4 specifications, there are occasions in which the current 185 document includes quotations from existing standards-track documents 186 that use these keywords. In such cases, the definitions within 187 BCP 14 [RFC2119] [RFC8174] are to be adhered to when the terms appear 188 in all-capitals. 190 The current document also uses these keywords when exploring future 191 standards-track documents. Although these terms do not have a 192 normative effect in this setting, their meaning remains the same. 193 These statements can differ from and may contradict existing 194 normative statements for one or more of the following reasons: 196 * Earlier standards-track documents did not handle a security issue 197 appropriately. 199 * The community did not recognize a security issue when a standards- 200 track document was initially approved. 202 * An actual or potential security feature was not available at the 203 time standards-track documents were written and approved. 205 Changes in normative statements applying to implementations of a 206 particular NFSv4 minor version require special care to avoid creating 207 later difficulties. Problems might arise because: 209 * Implementers might choose to leave unimplemented changes that are 210 not mandatory-to-implement. 212 * A client implementation assumes that a particular server behavior 213 is foreclosed (e.g., by a "MUST NOT" or "SHOULD NOT"), but a 214 future change allows that behavior. 216 2.3. Glossary 218 More complete definitions to be filled in later. The security 219 definitions are based on [RFC3552] and [RFC4949]. 221 Authentication Flavor 222 As defined in Section 8.2 of [RFC5531]. 224 Confidentiality 225 Data is kept secret from unintended listeners. RPCSEC_GSS 226 sometimes uses the term "privacy" to mean the same thing. As 227 defined in Section 2.1.1 of [RFC3552]. 229 Host authentication 230 The remote endpoint in the communication is the one we intended. 231 Also referred to as "peer authentication". As defined in 232 Section 2.1.3 of [RFC3552]. 234 Identity 235 A local trusted label for an object or resource, such as a network 236 address or a UID. 238 Integrity 239 Data that is received (or read) is the same data that was sent (or 240 written). As defined in Section 2.1.2 of [RFC3552]. 242 Non-repudiation 243 Demonstration to a third party (or the same parties at a later 244 time) that both a sender's identity is certain and the data 245 received from that sender is the same as the data that was sent. 246 As defined in Section 2.2 of [RFC3552]. 248 Trust 249 As defined in Section 4 of [RFC4949]. 251 User authentication 252 Establish the truth that a user is who (s)he claims to be. As 253 discussed in Section 4.1 of [RFC3552]. 255 3. Use of this Document 257 3.1. Current Use of this Document 259 This document is a means to facilitate discussion of the specific 260 inadequacies that need to be addressed within a new approach to NFSv4 261 security that we believe is required. For each specfic inadequacy, 262 as discussion proceeds, the treatment is expected evolve downward in 263 the following list to enable the working group to formulate text for 264 new standards-track documents to address the problem: 266 * The statement that a specific inadequacy exists and needs to be 267 dealt with. 269 * A listing of potential ways to deal with a specific inadequacy. 271 * A proposal by the authors that a specfic adequacy is best dealt 272 with a particular way, possibly accompanied by a list of other 273 reasonable aproaches. 275 * A statement that the working is expected to address a specfic 276 inadequacy in a particular way. 278 * A statement that the working is addressing a specfic inadequacy in 279 a particular way. 281 While it is expected that, if the working group concurs, this 282 document will be adopted as a working group document, that transition 283 is not expected to affect the document's pattern of use. When 284 deciding on that issue the working group will not be considering the 285 specific propoals to address inadequacies, which can be addressed 286 later. The working group will be considering whether there are 287 serous inadequacies requiring new documents and whether such a 288 document will be helpful in addressing them. 290 The working group discussion anticipated, expected to be documented 291 in future versions of this document, will guide the writing of a 292 number of expected standards-track documents: 294 * A new standards-track document discussing security for all NFSv4 295 minor versions, updating [RFC7530] and [RFC8881]. It is intended 296 that this document be referred to by rfc5661bis when it is ready 297 for publication but it should be able to be published, on its own, 298 before that, since it would update [RFC8881]. 300 * To address NFSv4.1-specific security issues, new text will be 301 needed in an anticipated rfc5661bis, updating [RFC8881]. 303 draft-dnoveck-nfsv4-rfc5661bis [I-D.dnoveck-nfsv4-rfc5661bis] is 304 anticipated to be a precursor document whose drafting will be 305 affected. 307 In addition, the working group discussion anticipated might guide the 308 writing of a number of potential working group documents: 310 * A new standards-track document discussing AUTH_SYS, including 311 discussion of the potential use of client-host authentication. 313 * A new standards-track document updating [RFC5531], focusing on a 314 more complete and accurate treatment of AUTH_SYS. 316 3.2. Future Use of this Document 318 The pattern of use discussed above is expected to continue until the 319 decisions to be made are finalized. While the documents whose 320 drafting is to be guided, will be farly far into development, it is 321 not necessary for the working group to wait for publication of those 322 documents (or even WGLC) before scheduling WGLC for this one. 324 The question of possible publication of this document as an 325 informational RFC remains open. It should probably be discussed 326 shortly before WGLC. Given this uncertainty, if there is to be a 327 milestone associated with this document, the target should be WGLC. 329 4. Situation to be Addressed 331 4.1. NFSv4 Use Environments to be Addressed 333 We will consider a range of network environments and how the type of 334 environment affects the need for the features being introduced to 335 provide for secure operation. 337 1. Within a data center local area network, there may well be 338 sufficient administrative controls over the software running on 339 machines with physical access to the network as to make 340 additional security features within NFS unnecessary. 342 If such a network is physically isolated or has all access to it 343 controlled using an appropriately configured firewall, it may be 344 acceptable, from a security point of view, to use AUTH_SYS 345 without client host authentication, and without encryption, 346 assuming all attackers have been excluded from access. 348 Although such networks typically do have firewalls, they are 349 generally configured to allow significant access, including NFSv4 350 access, to traffic originating outside the data center, although 351 not outside the owning organization. In such cases, we 352 effectively have a within-organization network, dealt with in 353 item 2 below. 355 2. Within a network devoted to a single organization or a single 356 site within an organization. Such networks often have associated 357 firewalls configured to exclude access from outside the 358 organization, and restrict it inside the organization. 360 It had until recently been assumed that, by excluding access to 361 those outside the organization, it could be assumed that 362 attackers would also be excluded. However, this approach ignores 363 the possibility of insider threats. Since we feel these threats 364 cannot be ignored, the security of NFSv4 needs to be upgraded to 365 prevent attacks by insiders, making the security needs in this 366 case more like those on the internet. 368 3. Use on the internet is the most challenging. While secure use on 369 the internet was a goal of NFSv4 and steps were taken to achieve 370 that goal, the approach required a number of steps, including a 371 significant performance penalty and a significantly different 372 approach to systems administration. Given that those 373 administering such systems were unwilling to adapt in this way, 374 we now need to meet the goal of secure use on the internet in a 375 new way. 377 Secure use on the internet requires not only protection of user 378 data in-flight from unauthorized disclosure or modification, as 379 in case 2 above, but also effort to deal with the possibility of 380 extensive external monitoring and denial-of-service attacks. 382 4. Use of NFSv4 to access data located in the cloud poses many of 383 issues discussed in item 3 above. However, in general, the cloud 384 service provider is responsible for protecting multiple tenants 385 from one another, often involving use of tenant-specific 386 credentials. If the distribution of such credentials is quite 387 tightly limited, we can have a situation like that in item 1. 388 However, if those credentials are available to a larger group, 389 then the situation become like that in item 2, with insider 390 threats being a point of concern. 392 5. The use of NFSv4 within cloud-located data centers presents 393 different issues. If access to the NFSv4 service is suitably 394 restricted, the situation is quite close to that described in 395 case 1, with the physical location of the data center irrelevant. 396 However, if there means of external access that are not tightly 397 restricted, the situation becomes like that of case 2 above, with 398 the possibility of insider threats requiring a security model 399 with many similarities to that needed for the environments 400 described in item 3. 402 As will be discussed below, NFSv4 security, as currently defined, has 403 significant security issues in many of the above environments, 404 although not in all. No special provisions will be made for the more 405 restricted environments, except where necessary to avoid 406 incompatibilities when interacting with existing implementations. 408 By focusing on a single set of requirements for all of these 409 environments, there will necessarily be occasions in which some 410 security-related work is required that is not, strictly speaking, 411 needed for the particular environment in which it is used. However, 412 we have endeavored to keep the required effort small, eliminating 413 requirements for major administrative changes or compute-intensive 414 additions to the processing path. 416 4.2. Emergence and Correction of Security Issues 418 The fact that serious security issues exist in many of the 419 environment discussed above has made it necessary to consider taking 420 the drastic step of modifying security-related recommendations for 421 existing protocols. This situation seems to call for an explanation 422 and we will attempt to provide one. 424 One possible form this might take would be to explain why [RFC7530] 425 and [RFC5661] made erroneous choices, with accompanying commentary 426 explaining the choices that should have been made instead. 428 Such an explanation does not appear to be possible, since it would 429 not have been possible for the authors and approvers of these 430 documents to reach the conclusions we have adopted without an 431 implausible level of foresight on their part. This is so even though 432 we would not adopt the choices made in [RFC7530] and [RFC5661] today. 433 Knowing what was known then, we might well have made the same 434 choices, although it is hard not to fault the lack of attention, in 435 the relevant documents, to the security consequences of the decisions 436 made. 438 Although we will call attention in sections below to things which 439 might have been done differently, this does indicate that we believe 440 that the authors and approvers of these documents, could have arrived 441 at conclusions similar to the ones we expect to choose now. Our 442 choices are so different from the ones made previously because they 443 take into account the needs of NFSv4 today and take advantage of 444 security facilities not available earlier. 446 In order to better understand this divergence, we have to look at the 447 history of NFS and take note of the context in which assumptions were 448 established with regard to security or changes in security guidance 449 occurred. In understanding this history and the choices of 450 RFC2119-defined keywords, the constraints on the working group need 451 to be understood, as described in Section 6.2 453 * The basic assumptions about security for NFS were established over 454 thirty years ago. At that time, it was generally taken for 455 granted that a co-operating set of UNIX kernels would provide a 456 uniform infrastructure to govern internode sharing within a 457 network. Within this framework, security concerns focused on 458 issues related to the appropriateness of granting or withholding 459 of privileges by UNIX kernels and there was little concern for 460 network security as understood today. As a result, NFS 461 administrators came to take for granted the use of AUTH_SYS making 462 it difficult to restrict its use, despite the security weaknesses 463 we perceive in it today. The assumptions underlying AUTH_SYS fit 464 so well with the way UNIX systems were managed in general led to 465 the use of AUTH_SYS becoming so well-entrenched that concrete 466 steps to eliminate it or to substantially restrict its use were 467 never seriously considered. 469 * When NFSv4 was developed, around twenty years ago, serious steps 470 were taken to improve the security situation by requiring the 471 implementation of RPCSEC_GSS. This included support for 472 encryption, necessary to support use on the internet. AUTH_SYS 473 was retained as an additional optional means of authentication, 474 which would have allowed implementations to drop support at a 475 later point, although, as things developed, that became less and 476 less likely as use of AUTH_SYS remained quite common. 478 While it is possible to interpret the treatment of the matter in 479 [RFC3530] as implying that these two (i.e. RPCSEC_GSS and 480 AUTH_SYS) were equivalent and to find fault with that implication, 481 it is not clear how different choices would have led to a better 482 result. In particular, attempts to deprecate AUTH_SYS (e.g. by 483 using the phrase "SHOULD NOT") would have been problematic in that 484 they might have retarded adoption of NFSv4 rather than enhancing 485 adoption of RPCSEC_GSS. 487 * When NFSv4.1 was developed, there appeared to be no reason to 488 change the security decisions made for NFSv4.0. Although it might 489 have been possible to change the status of AUTH_SYS in NFSv4.1, 490 there was no reason to tie the session architecture to changes in 491 security that many implementers would have been unwilling to make. 493 The only significant security-related extension was the provision 494 made for state protection, which required the server to protect 495 clients from one another, apart from the users on whose behalf 496 requests were being made. 498 * In the ten years since [RFC5661] was published, there was no way 499 to address new security needs without creating an essentially new 500 protocol, on the order of NFSv4.1, and there was little interest 501 in doing that. Within the framework established by [RFC8178], 502 there was provision for the addition of OPTIONAL features, while 503 addressing lingering security issues for existing minor versions 504 did not fit in that framework. 506 With the above history in mind, we will look at why NFSv4 security 507 needs are different today and take advantage of some options that 508 were not available on earlier occasions in which NFSv4 security 509 decisions were made. 511 * We have the option of providing better security for AUTH_SYS use 512 by implementing client host authentication. 514 * We have the option of providing confidentiality and integrity even 515 when RPCSEC_GSS is not used. 517 * We have the option of providing confidentiality and integrity 518 universally, without special configuration effort or interfering 519 with performance by requiring non-offloadable encryption/ 520 decryption on the client and server. 522 * We have the option of providing state protection (to prevent 523 clients interfering with one another) without the special 524 implementation work specified in [RFC8881]. 526 These options have been made available by the work at the RPC layer 527 described in Section 7 while the specifics of having NFSv4 take 528 advantage of these options are described in Section 8. 530 Providing a new security approach for multiple existing protocols is 531 potentially disruptive and due care will need to be taken to avoid 532 damaging implementation incompatibilities. However, as will be 533 discussed below, the existing situation, in which serious security 534 inadequacies need to be addressed, requires that significant changes 535 be made. It is our expectation that the situation will be resolved 536 by the eventual publication of a standards-track document updating 537 [RFC7530] and [RFC8881] and much of this document will concern itself 538 with determining how the needed changes can resolve existing security 539 issues without undue disruption. 541 5. Major Problems to Address 543 The problems to be addressed concern the way that security 544 information has been conveyed in earlier specifications (discussed in 545 Section 5.1) as well as two sets of substantive security weaknesses 546 discussed in Sections 5.2 and 5.3. 548 Although the inadequacies in the presentation of security issues have 549 contributed to prolongation of the substantive weaknesses and will be 550 discussed in the latter two sections, there is no reason to believe 551 that correction of the presentation problems, will, by itself, 552 improve the security situation, since the substantive problems still 553 need to be addressed. Nevertheless, correction of the presentation 554 issues is necessary so that the proposed solutions to the substantive 555 security issues receive the proper attention and analysis, both now 556 in connection with the changes to be proposed, and also going 557 forward, as needs change. 559 5.1. Problems with Security Presentation/Organization 561 While attention has previously focused on the deficiencies of the 562 Security Considerations sections (e.g. Lack of a threat analysis), 563 this is not the only presentation issue that needs to be addressed. 565 Problems with the overall presentation of NFSv4 security, 566 particularly the discussion of the security architecture will be 567 dealt with in Section 5.1.1. 569 Problems with the evaluation of NFSv4 security including the lack of 570 a threat analysis and the contents of the Security considerations 571 sections will be dealt with in Section 5.1.2. 573 5.1.1. Problems with Presentation of Security Architecture 575 The presentation of the NFSv4 security architecture (for both minor 576 versions) focuses on the work done to make RPCSEC_GSS usable in view 577 of the basic architectural decisions made in going from NFSv3 to 578 NFSv4. These include the use of NFS4ERR_WRONGSEC and SECINFO to 579 allow the server namespace to be carved into regions with the use of 580 particular security flavors and services (associated with particular 581 quality-of- protection values) required in each one. 583 Unfortunately, features added later in the NFSv4.0 development cycle 584 were not integrated into the description of the security 585 architecture. A list of such noteworthy features follows. 587 Another consequence of the approach taken to writing Security 588 Considerations sections has been that these sections may have not 589 appropriately highlighted the security implications of new features 590 being added to the protocols. 592 * The addition of callbacks to NFS was not accompanied by an 593 explanation of how security for callbacks was to be dealt with, It 594 was never made clear whether the existing mandate to provide 595 support for RPCSEC_GSS applied to reverse-direction operation. 596 The fact that there is no reverse-direction complement to 597 NFS4ERR_WRONGSEC and SECINFO means that there is no way that the 598 client, as a responder, could force use of another flavor if it 599 did not provide support for RPCSEC_GSS authentication, in the role 600 of a responder. 602 The fact that callbacks are normally issued by the server itself 603 and not on behalf a specific user, means that the typical function 604 of RPCSEC_GSS authentication is not relevant to the application. 605 However, if RPCSEC_GSS is used in the forward direction, then the 606 mutual authentication of client and server should be adequate to 607 provide authentication of the server to the client, although the 608 possibility that an attacker might inject a spurious callback to 609 the reverse-direction request stream remains a concern. 611 In any case, the absence of mention of reverse-direction 612 authentication in a description of the NFSv4 security approach is 613 troubling. The lack of mention in the Security Considerations 614 section is noteworthy because this creates a large set of requests 615 and responses for which there is no available facility to mandate 616 encryption, and that lack could be exploited by monitoring 617 attacks. 619 * The addition of pNFS to NFSv4.1 [RFC5661] required that there be a 620 means of providing that the proper quality of protection by 621 provided by the a pNFS data server implementing the files mapping 622 type. Given that SECINFO is namespace-oriented, it was necessary 623 to define SECINFO_NONAME, implementable by the data server, to 624 provide this functionality. 626 This security-related change, while explained adequately in 627 [RFC8881], is not mentioned in the description of the security 628 architecture or the Security Considerations section. As this 629 feature does create new threats, it should have been mentioned in 630 the Security Considerations section. Also, this change while 631 compatible with the existing NFSv4 security architecture, does 632 represent a considerable change to it. It seems to call for 633 special mention in a standards-track document devoted to NFSv4 634 security issues. It makes sense to include it in an introductory 635 section providing an overview of the NFSv4 security architecture. 637 * The implementation of sessions in NFSv4.1 [RFC5661] created a 638 requirement to protect clients from one another, even when they 639 were making requests on behalf of the same user. Although 640 adequate means of dealing with this issue were described in 641 [RFC5661], they were OPTIONAL features and implementation has been 642 very limited. 644 In this case, the additional exposure makes the absence of mention 645 of the issue in the Security Considerations section troublesome, 646 although its role in the limited implementation of the 647 corresponding security features is hard to evaluate at this point. 648 In any case, this was a major architectural change to the security 649 architecture which requires more attention. Over the years, there 650 has been considerable discussion on the NFSv4 mailing list of the 651 lack of authentication of the client, as opposed to the client 652 users on whose behalf it is acting, although no work has been 653 undertaken to make this a basic element of NFSv4 security. 654 Despite the delay, the issue now seems on its way to effective 655 resolution, using the work done in [I-D.ietf-nfsv4-rpc-tls], as 656 described in Section 8.5. 658 As we have seen, the description of the security architecture of 659 NFSv4 is quite limited and a new security document will have some 660 gaps to fill. 662 5.1.2. Problems with Security Evaluation 664 The principal difficulty in the overall approach to security taken in 665 the Security Considerations section of [RFC7530] and [RFC8881] 666 concerns the absence of a threat analysis within these documents. 667 The absence of such an analysis has meant that: 669 * There was no occasion to determine whether the security 670 improvements made relative to earlier versions of NFS were 671 adequate to realize any particular reasonable interpretation of 672 the goal of "secure use on the internet", which goal was never 673 clearly defined. 675 * In the absence of a clear goal or a means of testing whether that 676 goal had been met, a choice of security facilities was made based 677 on their likely availability. The prevalent assumption that 678 security against network-based attacks was not important in most 679 NFS environments made it difficult to consider improvements, or to 680 forthrightly discuss existing security weaknesses and make plans 681 to address them. 683 5.2. The Treatment of AUTH_SYS 685 Sections 7 and 8.2 of [RFC5531] introduce the RPC auth_flavor 686 enumerator and a pair of opaque fields (the credential and the 687 verifier fields). These fields carry material in each RPC message 688 that can identify and authenticate the RPC client and the user who 689 initiated the RPC transaction. The enumerator field determines the 690 structure and content of the credential and verifier. 692 The simpler auth_flavors (e.g., AUTH_SYS) merely identify the 693 requesting user and sending host. These flavors do not provide any 694 cryptographic proof of identity. Therefore they do not provide true 695 authentication of the conveyed user and host identities. 697 The RPCSEC_GSS credential and verifier can both identify and 698 authenticate the requesting user. They can additionally provide 699 message integrity and confidentiality. 701 [RFC3530], [RFC7530], and [RFC8881] state that implementation of 702 RPCSEC_GSS is REQUIRED. However, they do not also mandate its use, 703 exposing an opportunity for attackers to issue unauthenticated 704 requests targeting NFSv4 servers in which RPCSEC_GSS is not the only 705 form of authentication available. 707 Among the RPC auth_flavors that can present unauthenticated requests 708 to a server, AUTH_SYS is the most significant of these for many 709 reasons: 711 * Because the AUTH_SYS flavor is simple to implement and administer, 712 existing NFSv4 servers and client implementations make it almost 713 universally available. 715 * Unlike the AUTH_NONE flavor, whose name gives a fair warning that 716 requests are unauthenticated, [RFC5531] describes AUTH_SYS as a 717 means of authentication without addressing the question of what is 718 being authenticated and by whom. 720 * The substance of server and client implementations is not 721 described in standards-track documents, leaving much to 722 implementers' choice. 724 * There is no clear and complete description of the security 725 consequences of deploying AUTH_SYS RPC services. 727 * Even [RFC5531] designates AUTH_SYS as "insecure, all NFSv4 minor 728 versions continue to allow its use. 730 The everyday use of AUTH_SYS arises from NFS's early history and 731 development as part of the RPC authentication function and NFSv2 732 [RFC1094] and NFSv3 [RFC1813]. That approach, in which security was 733 made the responsibility of large multi-user clients trusted by 734 servers, might have made sense when it was initially developed, but 735 has become less relevant to NFSv4 security needs over time. 737 The designers of the NFSv4 protocol made RPCSEC_GSS mandatory-to- 738 implement. AUTH_SYS was left in place as an alternative without 739 considering the corresponding consequences for security. [RFC5531], 740 [RFC7530], and [RFC8881] mention several common practices that 741 servers have typically used to determine whether AUTH_SYS requests 742 should be accepted, but without explicit dicussion of their obvious 743 security weaknesses. 745 5.2.1. Current AUTH_SYS Security Policies 747 Current NFSv4 client and server implementations commonly provide the 748 following security policies. These policies attempt to improve the 749 security offered by AUTH_SYS. Because these policies are not 750 specified or discussed within standards-track documents, they have 751 not been subject to threat analysis. There is an opportunity to 752 describe and analyze security policies for AUTH_SYS and other 753 authentication flavors used with NFSv4 in an NFSv4-wide standards- 754 track security document. 756 Network Address-based Access Control 757 A typical server policy, which first appeared with implementations 758 of earlier versions of NFS, is to limit the acceptance of AUTH_SYS 759 requests to requests from known clients, as determined by the 760 client's network address. 762 The Security Considerations section of [RFC7530] does not address 763 the possibility of address spoofing, although it does state that 764 this is "certainly not a safe model", most likely alluding to this 765 possibility. The text does not follow up to call into question 766 the use of AUTH_SYS as an OPTIONAL security flavor (stated earlier 767 in the form "MAY be implemented"). Instead, it is used as 768 justification for the mandatory nature of RPCSEC_GSS 769 implementation; the lack of security when only AUTH_SYS is in use 770 is not mentioned further. 772 Network Port-based Access Control 773 Another frequently-used server-side security policy is to restrict 774 the use of AUTH_SYS based on the associated client source port, 775 assuming that this ensures that the client's kernel (or a 776 privileged user space agent) has vetted the request. That 777 assumption has, over time, become dubious. 779 Appendix A of [RFC5531] refers to this practice as follows: 781 "It should be noted that use of this flavor of authentication does 782 not guarantee any security for the users or providers of a 783 service, in itself. The authentication provided by this scheme 784 can be considered legitimate only when applications using this 785 scheme and the network can be secured externally, and privileged 786 transport addresses are used for the communicating end-points (an 787 example of this is the use of privileged TCP/UDP ports in UNIX 788 systems -- note that not all systems enforce privileged transport 789 address mechanisms)." 791 Identity Squashing 792 NFS servers can implement a security policy that executes all 793 AUTH_SYS requests as a suitably unprivileged user ID, such as the 794 anonymous user. An alternate policy treats only requests from a 795 particular privileged user ID (e.g., root) this way. 797 Squashing does not prevent an attacker from masquerading as 798 another user but only limits the range of user identities that can 799 be assumed without difficulty. 801 5.2.2. Working Group Actions 803 The Security Considerations section of [RFC5531] states that AUTH_SYS 804 is "known to be insecure" and further states "AUTH_SYS SHOULD NOT be 805 used for services that permit clients to modify data." Nevertheless, 806 AUTH_SYS has been commonly used by NFSv4 clients modifying data since 807 NFSv4 was first implemented, while the security consequences have 808 never been addressed. 810 Given the security difficulties that use of AUTH_SYS gives rise to, 811 the NFS community faces a choice between a few alternatives: 813 * Take steps to eliminate or otherwise minimize the use of AUTH_SYS 814 as a valid authentication flavor, either for NFSv4 as a whole or 815 for minor versions based on NFSv4.1, whose description was 816 published as a Proposed Standard after the publication of 817 [RFC5531], which stated that AUTH_SYS was "known to be insecure". 819 Given the many clients using AUTH_SYS, such steps might take the 820 form of recommendations, with the difficulty of switching 821 authentication models considered a valid reason to continue to use 822 AUTH_SYS as long as one is aware of the security consequences. 824 Regardless of the working group's choice of normative terms, it is 825 crucial that new NFSv4 standards clearly explain the security 826 consequences of using AUTH_SYS. 828 * Revise AUTH_SYS to enable secure implementation of an 829 authentication model in which authenticated client hosts 830 determine, within appropriate limits, the user IDs used for each 831 request sent. 833 To do this, servers would authenticate client hosts issuing 834 AUTH_SYS requests, taking advantage of the authentication provided 835 by [I-D.ietf-nfsv4-rpc-tls] as described in Section 7.2. A more 836 detailed discussion of issues to be addressed in establishing the 837 rules for this form of authentication appears in Section 8.4.6. 839 * Continue to pursue alternative RPC security mechanisms that are 840 simple to deploy and not costly to run. One such mechanism is 841 RPC-over-TLS, which should be available in time to include in 842 security documents published together with rfc5661bis. However, 843 we can easily imagine mechanisms based on other open federated 844 authentication standards that can be made available within NFSv4 845 via subsequent extensions. 847 The nfsv4 working group should consider all of these alternatives. 849 The first of these is unlikely to be feasible; otherwise, the NFS 850 community might have already attempted such a step. The use of 851 AUTH_SYS has continued even though alternatives are available, and 852 there is no reason to expect that the use of the words "SHOULD NOT" 853 or "MUST NOT" would prevent implementers from continuing to support 854 it or administrators depending on such support, despite the negative 855 effect on the security of NFSv4 implementations 857 Because of the current predominant role of AUTH_SYS in existing NFSv4 858 implementations, providing better security while remaining within the 859 AUTH_SYS framework will also be difficult because of the issues 860 discussed earlier in Section 6.2. Nevertheless, we feel it needs to 861 be attempted as a new security framework cannot address AUTH_SYS 862 without clearly discussing its security weaknesses. Once that is 863 done, we need to take advantage of strong client host authentication 864 to provide a modicum of security while allowing administrators to 865 delegate credential-checking to trusted clients, as they are now 866 accustomed to doing. 868 This approach is far from ideal. It requires a trust relationship 869 between clients and servers. Adopting it provides a reasonable 870 approach to support NFSv4 in the near-term while allowing the 871 development of a better alternative (e.g., a new authentication 872 flavor) to proceed in parallel. Concerning our immediate need for 873 better NFSv4 security, the obvious alternatives might not be 874 realizable: 876 * Given the weaknesses of AUTH_SYS and the need to present a threat 877 analysis, we cannot commend AUTH_SYS without client host 878 authentication as OPTIONAL to use, either explicitly or by 879 implication. 881 * Recommending that AUTH_SYS without client host authentication not 882 be used, with RPCSEC_GSS as the only alternative, will not be 883 effective and would limit adoption of a better, although far-from- 884 ideal, alternative. 886 Therefore, the authors propose that upcoming NFSv4 standards-track 887 documents mandate or recommend that, when AUTH_SYS is in use, a form 888 of strong host authentication is always deployed along with it. 889 Ultimately this is a matter for working group decision, however. For 890 a further discussion of related issues, see Section 8.4.3. Although 891 the rest of this document assumes the authors' preference is 892 selected, Section 8.4.3 explains the changes to an eventual 893 standards-track document required if the working group concludes that 894 different choices are necessary. 896 5.3. Problems with Confidentiality 898 Confidentiality is currently provided within NFSv4 by the use of 899 RPCSEC_GSS, with the server charged with enforcing any administrator- 900 specified needs to use these facilities on appropriate portions of 901 the server namespace. Requirements for the use of integrity 902 protection are handled similarly. This approach is capable of 903 providing confidentiality when accessing certain directories or file 904 systems, assuming that files that require such protection can be 905 isolated in certain regions of the server namespace. 907 An important difficulty with regard to this approach to 908 confidentiality is that there is significant non-encrypted data sent 909 on NFSv4 connections which can allow extensive data to be gathered on 910 the part of those engaged in monitoring attacks 912 * Certain parts of RPC requests and response are not encrypted and 913 can be the basis of traffic analysis. Fortunately, the structure 914 of NFSv4 requests limits the data exposed since the requested 915 operation is always COMPOUND (or CB_COMPOUND). Nevertheless, the 916 size of requests and information determinable from those allows 917 patterns of reading and writing data by specific clients to be 918 inferred. 920 * Because the focus of this approach is on areas of the server 921 namespace, there is no way to force use of encryption on requests 922 used to set up connections and sessions. 924 * Similarly, there is no provision for negotiating/enforcing the use 925 of integrity or encryption on reverse-direction requests. 927 Despite the availability of encryption in NFSv4, it is very rarely 928 used, which makes its formal sufficiency essentially irrelevant. In 929 understanding why confidentiality is not more generally used, we need 930 look at the issues below in order to understand how to address the 931 problem going forward. 933 * The cost is such that its use has a noticeable effect on 934 performance, given that the design (by requiring different keys 935 for different users) makes it difficult or impossible for the work 936 of encryption to be offloaded. 938 It is likely that, given increasing network speeds, this factor is 939 more important today than it was when this approach was settled 940 upon. 942 * In many environments it might not be possible to isolate files 943 needing such protection in a way consistent with the way file 944 protections are normally managed. As a result, encryption would 945 be present for all files or for none, with none being chosen most 946 often because of performance concerns. 948 * Implementation of confidentiality requirements may face 949 difficulties due to uncertainty about whether client encryption 950 support is available. For example, [RFC7530] specifies that 951 privacy support is required (although only for krb5), while 952 [RFC8881] says only that clients "SHOULD" support privacy. The 953 document give no guidance regarding what might be considered valid 954 reasons to not support privacy, leaving servers without any 955 reliable way of demanding confidentiality on certain portions of 956 the server namespace. 958 * The concurrent use of AUTH_SYS might have a similar inhibiting 959 effect. While it is possible, within the protocol, to force a 960 transition to use of RPCSEC_GSS with privacy, RPCSEC GSS access 961 might not be possible in many cases (e. g. the proper id mapping 962 facilities might not have been configured). 964 * The current Security Considerations sections for the NFSv4 965 protocols may have contributed to the continuation of the problem 966 by not drawing sufficient attention to the security issues 967 involved in allowing access without encryption. 969 Looking at the relevant Security Considerations sections, we find the 970 following: 972 * Although the cost of performing encryption is mentioned as a 973 reason not to perform it, there is no discussion of the security 974 consequences of not performing it. 976 * Similarly, there is no discussion of the use of integrity services 977 in preventing modification of user data in flight and the data 978 corruption that attackers could cause when these services are not 979 used. 981 * There are a number of references to integrity protection for 982 various sort of operations but none connected with the protection 983 of user data, possibly suggesting to the reader that this issue is 984 not important. Ironically, while the operations used to obtain 985 security requirements for a given portion of the namespace are 986 among these mentioned, an attacker could not use these to obtain 987 transmission in the clear but would instead cause denial-of- 988 service, as would happen the bogus security parameters were 989 rejected. 991 All of the issues discussed above may have contributed to the lack of 992 use of encryption with NFSv4, but the issues of poor performance due 993 to the a non-offloadable nature of encryption appears to have had a 994 critical role in creating an unsatisfactory situation for a protocol 995 where high performance is often of critical importance. 997 Once the choice was made to limit encryption to specific file systems 998 or directories, there was commonly a perceived need to avoid the cost 999 of encryption and the difficulties that approach to the matter led to 1000 were exacerbated by the lack within the Security Considerations 1001 sections of information about the damage thus done. Because there 1002 was insufficient attention to these issues, effective action to 1003 address them was delayed, until the problem could no longer be 1004 ignored. 1006 Given these weaknesses with regard to encryption, those needing to 1007 use NFSv4 outside local area networks often implemented NFSv4 over 1008 secure tunnels. As this work proceeded, it served as an inspiration 1009 for the work done in [I-D.ietf-nfsv4-rpc-tls] that provided the 1010 opportunity to provide encryption uniformly and potentially with high 1011 performance. An overview of steps necessary to address these issues 1012 appears in Section 7.1. 1014 5.4. File Access Control 1016 Originally, the NFS protocol provided only a basic form of access 1017 control in the form of permission bits (also known as mode bits). 1019 NFSv4 introduced a rich access control list mechanism which 1020 supplements mode bit-based access control [RFC7530]. This is 1021 referred to as a Discretionary Access Control (DAC) mechanism, where 1022 access to the file's content is at the discretion of the file's owner 1023 and is based on identity of the requesting user. A more complete 1024 definition of DAC is available in Section 4 of [RFC4949]. 1026 The NFSv4.2 protocol provides a basis for supporting Mandatory Access 1027 Control (MAC) in the form of Security Labels, as described in 1028 Section 9 of [RFC7862]. Mandatory Access Control is generally 1029 mandated from a central authority that constrains access to file 1030 content based on broad trust categories. Because this usage 1031 overloads the abbreviation MAC, which can also refer to Message 1032 Authentication Codes and Media Access Control, we avoid using the 1033 abbreviation unless the meaning is clear. A more detailed definition 1034 of MAC is available in Section 4 of [RFC4949]. 1036 Both of these file access authorization mechanisms need a threat 1037 analysis and a discussion of exposures due to missing access control 1038 facilities. However, without documentation of access semantics in 1039 the case of Security Labels, any threat analysis might not be 1040 complete. 1042 5.4.1. File Content Integrity and Provenance 1044 Ever since RPC has supported an integrity-protected mode of transport 1045 (via RPCSEC_GSS integrity pseudoflavors), NFS has been able to 1046 provide a strong guarantee that NFS messages in transit on a network 1047 are immutable. 1049 Recent work in block storage has extended the immutability of file 1050 content from application to storage and back (for example, SCSI 1051 commands related to Protection Information, as defined by the T10 1052 technical committee). This provides a guarantee that what an 1053 application reads at time T+1 is what an application wrote at time T. 1054 The NFS protocol can and should enable this stronger form of 1055 integrity guarantee. 1057 Provenance is a deeper guarantee. It additionally identifies the 1058 author of a file's content, and guarantees that content is exactly 1059 what the author originally provided. An NFS client might use 1060 verifiable provenance to gate access to a critical executable or 1061 other resources contained in files stored on an NFS server. 1063 Lastly, some systems provide a policy-based access control mechanism 1064 based on whether file data content passes various integrity checks. 1066 These capabilities require the storage and transit of additional 1067 metadata associated with each file, which is currently not a part of 1068 the NFSv4 protocol. Security Considerations sections should explain 1069 how data is put at risk when these capabilities are not present. 1071 6. Framework for Correcting Problems 1073 This section addresses the fundamental issues of the organization and 1074 presentation of a new security framework. The complementary issues 1075 involved in making substantive improvements in NFSv4 security will be 1076 dealt with in Section 7. 1078 6.1. Correcting Problems with Regard to Threat Analyses 1080 Of prime importance is the inclusion of appropriate threat analyses, 1081 even apart from the requirement (in BCP 72 [RFC3552]) that such 1082 analyses appear in Security Considerations sections. As we have 1083 already seen, without such an analysis, there is no way to determine 1084 whether any security changes adopted are adequate to address NFSv4's 1085 security difficulties. In the case of NFSv4, because of its 1086 complicated history and the conflict between the status of AUTH_SYS 1087 as specified by the NFSv4 specification documents ([RFC7530], 1088 [RFC8881]) and that in [RFC5531], there might be multiple analyses, 1089 located in different places: 1091 * Because the security needs of the various minor versions are so 1092 similar, the bulk of the analysis could appear in an NFSv4-wide 1093 standards-track document updating [RFC7530] and [RFC8881]. 1095 * The case of a threat analysis for AUTH_SYS raises a special set of 1096 issues. Currently, AUTH_SYS is discussed and declared "insecure" 1097 within [RFC5531] with no threat analysis appearing within the 1098 document. A new threat analysis could appear in the NFSv4-wide 1099 security document referred to above but the fact that AUTH_SYS 1100 might be considered as part of RPC rather than of NFSv4, might 1101 dictate otherwise. Such an analysis might appear in a document 1102 updating [RFC5531], or in a new document devoted to that specific 1103 purpose. Whichever choice is made, there will be a need for a 1104 document updating [RFC5531]. 1106 The appropriate location of a threat analysis for AUTH_SYS as 1107 currently used depends on the question of whether to consider 1108 AUTH_SYS as part of RPC, as it formally is, or to transfer 1109 responsibility to NFSv4, since it was deprecated as insecure in 1110 [RFC5531], while at the same time embedded as a heavily used optional 1111 feature for all minor versions of NFSv4, including a new protocol, 1112 NFSv4.1 published as a Proposed Standard subsequently, in [RFC5661]. 1114 Also relevant to the question of the appropriate location for this 1115 threat analysis is the question of whether there might be a need for 1116 a revised treatment of AUTH_SYS including client host authentication. 1117 The possible existence of such a revised treatment, together with 1118 issues related to a threat analysis necessary for its inclusion is 1119 discussed in Section 8.4.4. 1121 6.2. Correcting Problems with Regard to Use of Normative Terms 1123 Another important issue concerns the potential need for adjustment of 1124 inappropriate use of terms defined by [RFC2119], particularly any 1125 suggestion that use of AUTH_SYS may be validly used without important 1126 security consequences, as suggested by the current understanding that 1127 its use is optional. 1129 However, as desirable as such clarifications might be, it is 1130 necessary that we be realistic about what such changes can 1131 accomplish, even if the particular issues cited in Section 2.2 are 1132 properly attended to. Documents can be written to define certain 1133 implementations as non-conformant, but the ability of any such 1134 designation to affect implementer behavior is strongly affected by 1135 circumstances, particularly when the term is a hard one to pin down 1136 such as "SHOULD" or "SHOULD NOT". 1138 The ability of such term choices to affect implementer behavior is at 1139 its maximum when a new protocol is defined. In this case, the 1140 specification document formalizes a contract between implementations, 1141 so that the consequence of not following these terms is a lack of 1142 interoperability rather the fact that one's implementation may be, 1143 formally speaking, non-conformant. In the case of a protocol such as 1144 NFSv4,intended to build and extend the work of earlier NFS versions, 1145 the ability of the IETF to affect implementer choices is 1146 significantly reduced, as interoperability with the existing protocol 1147 and the existing infrastructure to support it will be of greater 1148 importance to implementers. Further, it needs to be recognized that 1149 when these terms are used to constrain security-related behavior 1150 rather than interoperability per se, their effect on implementer 1151 choice is likely to be similarly reduced. 1153 Although [RFC2119] provides definitions of "SHOULD" and "SHOULD NOT", 1154 it is difficult to determine the proper interpretation unless it is 1155 clear what the "valid reasons" that might supersede the 1156 recommendation or the expected consequences of doing so. For this 1157 reason, when these terms are used in proposed text, we will make such 1158 matters explicit, where they are not otherwise clear, as suggested by 1159 Section 7 of [RFC2119]. 1161 7. Opportunities for Improvement Provided by Recent Work within the RPC 1162 Layer 1164 The work done to provide TLS support for RPC (in 1165 [I-D.ietf-nfsv4-rpc-tls]) presents an important opportunity to 1166 address the substantive security problems described in Sections 5.2 1167 and 5.3. While there will be a need to specify appropriate policies 1168 for its use by NFSv4 as a ULP (see Sections 8.3.2 and 8.4.6 for 1169 details), the following opportunities present themselves and are 1170 likely to be taken advantage of: 1172 * The use of transport-level encryption is a good way of dealing 1173 with the inadequacies discussed in Section 5.3. The use of a 1174 single key per connection makes offloaded implementations possible 1175 allowing use for all requests including those currently not 1176 encrypted. This is discussed in more detail in Section 7.1 1178 * Authentication of the client host, as provided by the 1179 authentication material presented at connection initialization 1180 might be used to authenticate the client host, to avoid acceptance 1181 of AUTH_SYS requests from unauthenticated clients. This is 1182 discussed in more detail in Section 7.2 1184 Although [I-D.ietf-nfsv4-rpc-tls]) does not provide support for RDMA 1185 transports, parallel services to provide encryption and 1186 authentication are expected to be available, as discussed in 1187 Section 7.3. 1189 7.1. Opportunities for Improvement in Encryption 1191 [I-D.ietf-nfsv4-rpc-tls] provides the ability to encrypt all traffic 1192 on the connection used between an NFSv4 client and server. This 1193 requires that that both the client and server provide support for 1194 RPC-over-TLS. Appropriate requirements/recommendations are discussed 1195 in Section 8.3.2. 1197 Because this facility is based on an opportunistic use of TLS, there 1198 is a need for ULP-defined policies to deal with situations in which 1199 the server rejected the request for a TLS connection. These matters 1200 are discussed in Section 8.3.2 as well, as is the policy that servers 1201 are to adopt when dealing with a connection on which RPC-over-TLS is 1202 not requested. 1204 Because this new form of encryption is being added to an existing 1205 protocol, all of these policies are more complicated than would be 1206 the case for a new protocol, since there might be a need to 1207 accommodate earlier implementations, which might not have had time to 1208 be enhanced, while providing the ability to take advantage of 1209 whatever confidentiality support that might be present for a given 1210 client and server. 1212 7.2. Opportunities for Improvement in Authentication 1214 When establishing a connection, as provided for by 1215 [I-D.ietf-nfsv4-rpc-tls], authentication material is provided by the 1216 client and could be used to authenticate the client host to the 1217 server. 1219 By using this authentication material to authenticate the client 1220 host, it would be possible to correct some of the issues discussed in 1221 Section 5.2. This would involve clearly specifying how that material 1222 is to be used, in contrast to the situation for the existing 1223 AUTH_SYS, for which current documentation (in Appendix A of 1224 [RFC5531]) is quite limited. Any such respecification would need to 1225 be acceptable to those used to using AUTH_SYS while avoiding the 1226 security issues that make its further use, in the old form, 1227 inadvisable. 1229 This could allow the following improvements: 1231 * This would avoid dependence on the use of source request IP 1232 address, which is insecure, given the possibility of address 1233 spoofing. 1235 * Authentication material could be separately defined for user and 1236 kernel-mode clients to avoid dependence on the outdated privileged 1237 port mechanism. 1239 * More options could be provided to allow limitation of the user ids 1240 upon behalf of which requests are made, to address the limitations 1241 of "root squashing". 1243 The details of how the authentication material could be used are 1244 discussed Section 8.4.6. 1246 7.3. Opportunities for Improvement when Using RDMA Transports 1248 As noted above, [I-D.ietf-nfsv4-rpc-tls]) is not supported on RDMA 1249 transports, making it necessary to provide appropriate support for 1250 encryption and client host authentication in other ways. 1252 * Often RNICs used to implement RDMA transports will often implement 1253 encryption to secure inter-RNIC traffic. When, as is often the 1254 case, the inter-RNIC protocols are not standardized, the judgment 1255 as to the adequacy of the encryption is out-of-scope, from our 1256 point of view. However, the client and server could be configured 1257 to take advantage of this encryption, when it is judged 1258 appropriate to do so by those responsible. In addition, the 1259 transport characteristics mechanism defined in 1260 [I-D.ietf-nfsv4-rpcrdma-version-two] could allow those configuring 1261 the client and server to make independent judgments on encryption 1262 adequacy, with RPCSEC_GSS integrity and encryption only 1263 superseded, when both agree. (See Section 8.3.2 for details). 1265 * Authentication material to support client host authentication can 1266 be provided by using the transport properties mechanism provided 1267 for in [I-D.ietf-nfsv4-rpcrdma-version-two]. 1269 It should be noted that our need to normatively reference 1270 [I-D.ietf-nfsv4-rpcrdma-version-two] would affect the schedule of a 1271 standards-track document dealing with NFSv4 security. Given that the 1272 current milestone for requesting publication is December 2020, this 1273 not expected to pose an obstacle. 1275 8. Issues that Need to be Addressed 1277 These sections discuss the issues that need to be addressed by new 1278 standards-track documents including both issues of the presentation/ 1279 evaluation of NFSv4 (discussed in Section 5.1) and the substantive 1280 security weaknesses discussed in Sections 5.2 and 5.3. For each 1281 issue there is a section providing background followed by information 1282 suggesting how the issue would be addressed or issues that would need 1283 to be resolved before the issue could be addressed. 1285 8.1. Threat Analysis Goals 1287 8.1.1. Background 1289 For reasons that remain unclear, none of the specification documents 1290 for the existing NFSv4 minor versions contain a threat analysis. As 1291 a result, for the reasons discussed in Section 5.1, we need to 1292 provide an appropriate threat analysis for all NFSv4 minor versions. 1293 Because of the high degree of overlap between pairs of NFSv4 minor 1294 versions, most of the analysis will be common to all versions. 1295 However, there are some areas where features in later minor versions 1296 have significant security implications: 1298 * In NFSv4.1 [RFC5661], SECINFO_NO_NAME was added, in large part 1299 because it would be necessary to allow the data server, when the 1300 pNFS file mapping type is used, to communicate to the client that 1301 either integrity or encryption would be required when access to 1302 file data was provided through the data server (as opposed to the 1303 metadata server). 1305 The use of TLS-based encryption, which we expect to be recommended 1306 (see Section 8.3.2, may limit the need for this feature, but it 1307 will remain REQUIRED, when file-based pNFS is implemented. 1309 * NFSv4.1 [RFC5661] facilities were added to protect locking and 1310 session-related state from modification by other servers (i.e. 1311 SP4_MACHCRED and SP4_SSV). 1313 These features have had very limited implementation work, so it 1314 would be desirable to provide alternative means to achieve the 1315 goal, as described in Section 8.5. 1317 While the bulk of the threat analysis would be minor-version- 1318 independent, differences between minor version will have to be noted, 1319 as will differences that reflect uses of the facilities discussed in 1320 Section 7. 1322 Beyond the lack of NFsv4 threat analyses, there is a further problem 1323 in that there is no threat analysis dealing with the AUTH_SYS case in 1324 the existing RPC specification [RFC5531]. In this case, the gap is 1325 easier to understand since RPC deals with security on a per-flavor 1326 basis and declares AUTH_SYS as "insecure". It may well be that the 1327 authors, the working group and the IESG thought this was adequate, 1328 and it would have been if this had resulted in its not being used 1329 subsequently. As things happened however, AUTH_SYS continued to be 1330 used extensively, including for NFsv4, so that there still remains a 1331 gap in this regard. 1333 The following facts are relevant to the continued use of AUTH_SYS 1334 despite its security problems: 1336 * It was stated that AUTH_SYS "SHOULD NOT" be used for services 1337 capable of modifying data. Given that its further use was still 1338 anticipated, in some circumstances, a security analysis would 1339 still be required. In addition, use within the purview of the 1340 "SHOULD NOT" would make such analysis even more important, since 1341 that recommendation would allow use presumably based on balancing 1342 of possible benefits and corresponding problems. Without an 1343 understanding of the security problems (i.e. the substance behind 1344 the designation of AUTH_SYS as insecure), such balancing would not 1345 be possible. 1347 * Despite the recommendation that AUTH_SYS not be used for services, 1348 such as NFSv4, that are capable of modifying data, NFSv4 was 1349 specified allowing such use with very limited attention to the 1350 security issues that uses of AUTH_SYS gives rise to. As a result, 1351 there remains a needs for an appropriate threat analysis including 1352 for AUTH_SYS, since no matter what the working group decides to do 1353 in this area, use of AUTH_SYS, in connection with all NFS 1354 protocols (and possible other ONCRPC protocols) will continue for 1355 some time. 1357 * The reason stated for considering AUTH_SYS insecure, the lack of a 1358 verifier, while worthwhile to note, does not touch the substance 1359 of the problem, that unauthenticated requests are accepted and 1360 potentially acted upon. The difficulty is further compounded by 1361 the fact that the client validation checks made by actual 1362 implementations are not fully described within RFC (They are 1363 described above in Section 5.2). 1365 8.1.2. Issues to be Addressed 1367 It is expected that a threat analysis dealing with all NFSv4 minor 1368 will be dealt with in new standards-track document dealing with NFSv4 1369 security. Because this document will address security for all minor 1370 versions, it will update [RFC7530], [RFC8881], and [RFC7862]. 1372 There will, in addition, be a need for a threat analysis dealing with 1373 AUTH_SYS, which might or might not appear in the NFSv4-wide security 1374 document for reasons explained in Section 6.1. The question of where 1375 this best be done is discussed in Section 8.4.4. 1377 8.2. NFSv4 Extension Policies 1379 8.2.1. Background 1381 The basic framework for the extension of NFSv4 was established by 1382 [RFC8178]. Given that the anticipated standards-track document 1383 dealing with NFSv4 security will, in a sense, extend NFSv4, there 1384 might be some uncertainty about whether the changes anticipated are 1385 in line with that extension framework and whether there might be a 1386 need for that document to update [RFC8178]. 1388 The following questions need to be addressed: 1390 * Whether the changes in policies anticipated here, with regard to 1391 encryption and use of AUTH_SYS, are consistent with [RFC8178]. 1393 * How the use of new security-related facilities provided at the RPC 1394 level relates to the extension framework established by [RFC8178]. 1396 * How further extensions might relate to use of such new RPC-level 1397 facilities. 1399 * How to deal with and document extensions that provide new 1400 security-related features. 1402 8.2.2. Addressing Extension Issues 1404 We anticipate that the material would be in a section entitled, 1405 "NFSv4 Security Changes and the Existing NFSv4 Extension Model" 1407 The following introductory material seems appropriate: 1409 * The security-related changes recommended in this document are 1410 outside the scope of the extension model presented in [RFC8178]. 1411 However, they do not contradict it and there is no need for this 1412 document to update that one. 1414 * Normally, changes requiring coordinated work on the client and 1415 server are signaled using a new minor version. In that case, the 1416 new minor version is essentially treated as a new protocol and 1417 there is no need to update [RFC8178] or specifications for 1418 existing minor versions. 1420 The following paragraphs discuss the core issues: 1422 * That approach is not possible in this case since the basic need is 1423 to change the handling of existing minor versions to improve 1424 security. This create the possibility of interoperability issues 1425 since there is neither a new minor version nor a means of 1426 distinguishing a consistent set of OPTIONAL features supported by 1427 the server and known to the client. 1429 * In order to limit the possibility of interoperability issues, the 1430 security changes are made in the form of recommendations, but, 1431 because there exist implementations built before these 1432 recommendations were in effect, clients and server have to be 1433 aware of the possibility that these recommendations might not be 1434 followed. As a result, the effect of these recommendations, made 1435 to limit security issues, is, from an interoperability point of 1436 view, similar to those that might arise from OPTIONAL features. 1437 With regard to the NFSv4 extension framework, 1439 - The use of the new RPC-level facilities does not raise any 1440 extension issues, since the existing specification do not limit 1441 the transport used, except to require reliable and in-order 1442 delivery. For this reason, these facilities can be used 1443 without updating the existing minor version specifications. 1445 Use of these facilities does not raise additional 1446 interoperability issues since [I-D.ietf-nfsv4-rpc-tls], by 1447 using the opportunistic TLS model, provided for 1448 interoperability between those that do and do not support these 1449 extensions. 1451 - The policies to use these facilities, made the responsibility 1452 of the ULP by [I-D.ietf-nfsv4-rpc-tls] are significant 1453 additions to existing minor versions, requiring that the new 1454 standards-track document dealing with NFSv4 security update 1455 [RFC7530] and [RFC8881]. 1457 These changes do not raise interoperability issues since the 1458 policies apply to all uses of these transport-level facilities 1459 for NFSV4. That addresses the case in which client and server 1460 both provide support while other cases are dealt with as 1461 indicated in the previous bullet. 1463 - The new recommendations regarding use of existing features 1464 (e.g. encryption, AUTH_SYS) often contradict existing guidance 1465 and so also require that new standards-track document dealing 1466 with NFSv4 security update [RFC7530] and [RFC8881]. 1468 These change do potentially raise interoperability issues which 1469 need to be dealt with by giving sufficient scope, within the 1470 framework of new recommendations, to accommodate existing 1471 behavior. As a result, from an interoperability standpoint, 1472 these changes are compatible with the previous designation of 1473 OPTIONAL use, even though the security consequences make it 1474 necessary that the use of these previously OPTIONAL facilities 1475 (e.g. transferring data in the clear, use of AUTH_SYS without 1476 client host authentication) be something to be warned against. 1478 8.3. TLS Encryption Policies 1480 8.3.1. Background 1482 As discussed in Section 5.3, NFSv4 as currently defined, has serious 1483 problems providing the appropriate level of confidentiality for its 1484 transmissions. Providing encryption at the transport layer, whether 1485 as described in Section 7.1 or otherwise, can be expected to resolve 1486 this issue by providing encryption in a potentially offloadable way, 1487 making use of RPC-level privacy and integrity services unnecessary. 1489 If we were defining a new protocol, such transport-level encryption 1490 could be REQUIRED without difficulty. However, given that we are 1491 upgrading the security for an existing protocol, it might not be 1492 possible to designate this encryption as "REQUIRED", since this might 1493 give rise to extensive interoperability problems between new and old 1494 implementations. In any case, existing implementers of the existing 1495 protocol would not have the same interest in specification compliance 1496 as in the corresponding situation with a new protocol, leading to a 1497 situation in which one group of implementations essentially ignored 1498 the issue of specification-compliance with regard to the latest 1499 protocol specifications. 1501 We need to be aware that, 1503 * In implementation of a new protocol, any requirements on the 1504 client the server such as we have been discussing act 1505 synergistically to marginalize non-compliant implementations. 1506 Since non-compliant server will not interoperate with a compliant 1507 client and vice versa. 1509 * The corresponding case of a requirement providing for a security 1510 upgrade, as in this case, is different. Implementers, and those 1511 charged with allocating resources to their work will naturally 1512 focus on improvement/maintenance of the working protocol and limit 1513 the effort devoted to being the first to do an implementation that 1514 would not be used until others do their part. In such cases, if 1515 there are parties who are not convinced of the necessity for the 1516 upgrade, it takes strong input from users/customers to ensure that 1517 the needed upgrade is given sufficient attention. 1519 * In some cases, a new protocol containing an important security 1520 upgrade can result in a situation more like the latter case than 1521 the former. 1523 As we consider how to discuss the need for encryption in 1524 Section 8.3.2, we will be mindful of the above. Since it not 1525 possible to mandate the use of encryption, we will make it 1526 RECOMMENDED. However, in discussing the valid reasons that 1527 encryption might not be provided, we will try to restrict them to the 1528 degree we can reasonably do so. Further, we will try to clearly 1529 state the security consequences which implementers and those 1530 configuring clients and server need to be aware of when choosing to 1531 not provide the RECOMMENDED encryption. 1533 8.3.2. Issues to Address 1535 There is a need to recommend the implementation and use of 1536 appropriate encryption by the server and client, as is done, for 1537 example, by the following paragraphs. 1539 * Data sent over connections used to connect an NFSv4 client and 1540 server SHOULD be encrypted, whether this uses TLS encryption, as 1541 described in [I-D.ietf-nfsv4-rpc-tls] (to be used for TCP 1542 connections) or another form of encryption. For example, 1543 [I-D.ietf-nfsv4-rpc-tls] does not address encryption for RPC-over- 1544 RDMA ([RFC8166], [I-D.ietf-nfsv4-rpcrdma-version-two]) but RNICs 1545 used to implement RDMA transports will often implement encryption 1546 to secure inter-RNIC traffic. 1548 * Valid reasons for not implementing the encryption recommendation 1549 include insufficient time and resources to code, test, and deploy 1550 an appropriate implementation. Implementers and those deploying 1551 NFSv4 servers and clients and those deploying NFSv4 services need 1552 to remain aware of the consequences of not providing encryption. 1553 These consequences are of concern regardless of the validity of 1554 the reasons for not doing so, which may be expected to become more 1555 restricted as time goes on. 1557 * Given that it is necessary for both the client and the server to 1558 provide implementations capable of transport-level encryption, 1559 those deploying NFSv4 implementations need to be aware of possible 1560 steps to provide remediation, the difficulties involved in 1561 providing it and the consequences of not doing do. 1563 * The lack of encryption for the connection as a whole can be 1564 addressed by encryption of individual requests using the 1565 facilities within RPCSEC_GSS specified in [RFC7530] and [RFC8881] 1566 as providing "privacy". When doing so, the following complicating 1567 issues need to be taken account of: 1569 - Such facilities are not likely to be offloadable and often will 1570 reduce performance dramatically. 1572 - Support for confidentiality via encryption is not required by 1573 [RFC8881] but only recommended, saying it "SHOULD be 1574 supported". Unfortunately, the document does not specify what 1575 might be valid reasons not to provide such support. Also, 1576 although [RFC2119] states the one choosing not to follow such a 1577 recommendation should be aware of the consequences, given the 1578 general reticence of NFSv4 specification Security 1579 Considerations sections about such matters, it is not clear 1580 that implementers have been able to properly consider the issue 1581 in the past. In any case, implementations without such support 1582 probably exist, making encryption unavailable for some existing 1583 client-server pairs. 1585 * When encryption is not provided, or, because of its effect on 1586 performance, not used, all of the user data read or written is 1587 transmitted in the clear, subject to interception or modification 1588 in flight. While this is clearly unacceptable for use on the 1589 internet, it should not be assumed that it is acceptable in more 1590 restricted environments. 1592 * Where this problem exists, it will often be necessary to restrict 1593 such traffic to specific network segments, and make it impossible, 1594 via administrative measures, to limit access to such network 1595 segments or monitor them extensively. 1597 Although, as indicated in [I-D.ietf-nfsv4-rpc-tls], that there should 1598 be no need to negotiate security flavors to be used to provide 1599 integrity and confidentiality, the exact effect on existing clients 1600 and servers needs to be made clearer. 1602 The text below is a suggested way of doing this. 1604 * Although the pseudo-flavors created to indicate use of integrity 1605 or encryption continue to be a part of NFSv4, when transport-level 1606 encryption is provided, their use is unnecessary, although server 1607 responses to SECINFO and SECINFO_NONAME may continue to include 1608 them. 1610 * When TLS is used to provide encryption, as specified in 1611 [I-D.ietf-nfsv4-rpc-tls], the client and server will, as indicated 1612 by that document, be aware that encryption, is present. In the 1613 case of RPC-over-RDMA, when the RNICs provide encryption 1614 transparently, the server and client have the opportunity to each 1615 make their own judgment about the adequacy of the encryption 1616 provided and communicate this to their peer as a transport 1617 property as provided for by [I-D.ietf-nfsv4-rpcrdma-version-two]). 1618 In either case, the client and server will only act, as described 1619 below, on knowledge about the existence of encryption shared by 1620 both parties: 1622 - The server treats all requests as being made requesting 1623 encryption, even if a different pseudo-flavor is used. As a 1624 result, the server will never return, NFS4ERR_WRONGSEC because 1625 of a quality-of-protection issue, despite a possible mismatch 1626 between the pseudo-flavor specified in SECINFO response and the 1627 one actually used. 1629 The server will still return NFS4ERR_WRONGSEC when an 1630 inappropriate security flavor or oid is used and clients need 1631 to be prepared to use SECINFO to determine the security to be 1632 used. 1634 - The client is free to ignore the quality-of-protection issues 1635 in a SECINFO response, making use of authentication-only 1636 variant of RPCSEC_GSS most efficient. 1638 - Although use of integrity or privacy pseudo-flavors is 1639 unnecessary on an encrypted channel, the server still needs to 1640 accept such requests. 1642 - Within NFSv4.1 [RFC8881], support for SECINFO_NONAME is still 1643 REQUIRED when pNFS is supported, even if the server only 1644 accepts connection on which encryption is used, making 1645 generation of NFS4ERR_WRONGSEC on a connection to the metadata 1646 server impossible. 1648 8.4. Handling of AUTH_SYS 1650 8.4.1. Historical Background 1652 During the development of NFSv2 [RFC1094], little attention was 1653 directed to network security and no attention was directed to the 1654 possibility that a machine on the network might represent itself as a 1655 client, with the ability to make requests on behalf of non-existent 1656 client processes it identified by user id. During this time, NFS 1657 clients were multi-user machines and it made sense to many for the 1658 client kernel to have the same responsibilities to verify user 1659 credentials and keep track of process user ids as it had successfully 1660 been doing with local file systems. This was the origin of AUTH_UNIX 1661 (later renamed AUTH_SYS) which was based on a model of co-operating 1662 UNIX kernels and provided no protection against an attacker with 1663 kernel privileges. Despite the later name change, actual 1664 implementations were strongly focused on UNIX, deriving the necessary 1665 implementation requirements from shared code and from informal inter- 1666 developer communications, rather than standards documents. As a 1667 result, as discussed in Section 5.2, when it was necessary to discuss 1668 the security of AUTH_SYS in connection with RPC (in [RFC5531], there 1669 was insufficient information on which to base a threat analysis, 1670 although it was correctly concluded that the result of use was a lack 1671 of security. 1673 With regard to the following aspects of AUTH_SYS, this UNIX 1674 orientation was significant. In many cases as the computing 1675 environment changed, it was not possible to change the details to 1676 keep up with evolving needs. 1678 * As the assumption of kernel trustworthiness became increasingly 1679 unviable as a basis for security, no action was taken to address 1680 the issue. While the check for a privileged port retained some 1681 residual value, it was used to exclude requests issued by non- 1682 kernel clients as inherently untrustworthy. The more significant 1683 and difficult problem of distinguishing trustworthy and 1684 untrustworthy kerenel-level access was never addressed, leaving 1685 AUTH_SYS of little value as a means of authentication, despite its 1686 continuing use. 1688 * AUTH_SYS was focused on the use of the non-hierarchical 32-bit 1689 user id space typical of UNIX. Although later attempts were made 1690 to generalize this within NFSv4, the fact that this approach is 1691 embedded in many server filesystems meant that this aspect of 1692 AUTH_SYS, does not seriously obstruct access to such servers. 1694 * The particular user id of zero (denoting "root" in UNIX) was often 1695 treated specially, by treating the request as issued by the 1696 predefined user id "nobody". While this was undoubtedly helpful 1697 when first defined, it is now the case that other non-root users 1698 might have significant privileges and that the ability of an 1699 attacker to assume any chosen user id allows much important 1700 information to be obtained and corrupted. 1702 Later, with the development of NFSv3 [RFC1813], some of these 1703 assumptions started to seem less justifiable and alternate 1704 authentication models were developed. However, because AUTH_SYS was 1705 so suited to the Unix environment, making NFS administration so 1706 similar to local file system administration, its use remained 1707 predominant despite its obvious weaknesses from the security 1708 standpoint. 1710 8.4.2. Background for Existing AUTH_SYS in NFSv4 1712 When NFSv4 was first defined (in [RFC3530]), RPCSEC_GSS was added as 1713 a mandatory-to-implement means of authentication which was optional 1714 to use, presumably under the assumption that other optional-to- 1715 implement authentication flavors, such as AUTH_SYS would be used by 1716 some clients 1718 The continued use of AUTH_SYS is troubling and hard to explain if one 1719 is focused on network security, but the following possibilities are 1720 worthy of note: 1722 * It might well have been felt that the problems with AUTH_SYS, 1723 although troubling, did not really apply to the most common use 1724 case for NFS, on local area networks. 1726 * The familiarity of AUTH_SYS to Unix administrators, and general 1727 consistency with existing UNIX methods of system administration 1728 may have made it difficult to contemplate its abrupt removal in 1729 NFSv4.0, with the expectation that doing so might have 1730 substantially impeded NFSv4 adoption. 1732 Regardless of why this happened, the important fact is that it did 1733 happen, despite the serious security problems that it gave rise to. 1734 Later subsections of Section 8.4 will discuss ways to address the 1735 resulting situation. 1737 8.4.3. Core Issue to Resolve for AUTH_SYS 1739 Given the serious security weaknesses described in Section 5.2, there 1740 is clearly a need to discourage its further use in its existing form, 1741 since the difficulties with it will not be eliminated by the adoption 1742 of encryption of NFSv4 connections alone 1744 There are two basic forms that such an effort might take: 1746 * Seek to discourage the use of AUTH_SYS in the expectation that it 1747 will be eventually replaced by RPCSEC_GSS or a new security 1748 flavor. 1750 * Seek to eliminate or mitigate its security problems and to 1751 discourage the use AUTH_SYS variants that have not addressed the 1752 underlying problem, in favor of a revised approach to AUTH_SYS 1753 with better security, based on client host authentication. 1755 While the authors are strongly of the opinion that the second choice 1756 is more likely to be successful, and this document reflects that 1757 view, there is no intention to foreclose the first option, should the 1758 working group choose it. If that option is chosen, then the material 1759 in Section 8.4.6 becomes irrelevant and can be ignored while much of 1760 that in Section 8.4.5 can be simply modified to expand its scope, as 1761 described below in that section. 1763 8.4.4. Need to Better Document and Explain Issues with AUTH_SYS 1765 As described in Section 8.1 there is a need for an appropriate threat 1766 analysis for NFSv4. For a number of reasons, issues with AUTH_SYS 1767 that would make it difficult to refer to in an NFSv4-wide security 1768 document without some additional work preparatory work: 1770 * Unlike the case of RPCSEC_GSS, there is no discussion of possible 1771 security threats. 1773 * There is no complete documentation how AUTH_SYS is to be used. 1775 * The reason for deciding that AUTH_SYS is "insecure", while 1776 probably valid, adds considerable confusion since it makes it 1777 harder to address the issue complained of. 1779 Under other circumstances, it might have been possible to dispense 1780 with further analysis of AUTH_SYS because of the following facts: 1782 * AUTH_SYS is declared "insecure", which might be considered as 1783 making a further security analysis beside the point. 1785 * There are a number of statements with [RFC5531] limiting the use 1786 of AUTH_SYS, which might lead a reader to conclude that it was, in 1787 essence, a historical artifact. 1789 Despite the above, we will need a more complete of treatment of 1790 AUTH_SYS security for a number of reasons. 1792 * Despite the recognition of its insecurity and restrictions on its 1793 use, AUTH_SYS has been at least on a par with RPCSEC_GSS in terms 1794 of NFSv4 use, for over a decade following. 1796 * Given that the ongoing security issues with AUTH_SYS might give 1797 rise to efforts to address them, an accurate understanding of 1798 these issues is even more important, regardless of how the working 1799 group chooses to resolve the issue discussed in Section 8.4.3. 1801 If the decision is made to improve the security characteristics of 1802 AUTH_SYS, it is important to understand existing security issues 1803 and how they might be best addressed. 1805 If the decision is made to eliminate the use of AUTH_SYS, an 1806 adequate understanding of the security issues that made that 1807 decision necessary would seem to be required. In that context, 1808 the current statement in [RFC5531], regarding the insecurity of 1809 AUTH_SYS needs to be clarified. 1811 * It is likely that attempts to eliminate or restrict use of 1812 AUTH_SYS will take the form of a recommendation that it not be 1813 used or only be used in certain ways or under certain 1814 circumstances. Such recommendations normally require that the 1815 user be made aware of the consequences of doing something other 1816 than what is recommended. In this case that would be either to 1817 use AUTH_SYS or to use it without client host authentication. 1819 An important question is where such a treatment should appear. In 1820 deciding this question, the important question is whether, at this 1821 point, it is best addressed as a feature associated with NFSv4 or 1822 with RPC. 1824 * While structurally, AUTH_SYS, presented as one of security 1825 supported security flavors associated with RPC would seem to 1826 require treatment within the framework of RPC, its recent 1827 treatment raises questions about continuing to deal with it solely 1828 within this framework. This is not due solely because of the 1829 attempt (in [RFC5531]) to discourage its use, as was done for 1830 AUTH_DH. In that case it remains appropriate to discuss it as 1831 part of RPC, without a threat analysis, since there is no 1832 continuing use justifying another course. 1834 * The continued use of AUTH_SYS by all NFSv4 minor versions might 1835 well be considered to justify a transfer of responsibility to 1836 NFSv4, with the authentication flavor being mentioned, in RPC 1837 specifications, only as a historical artifact. 1839 The potential continued use of AUTH_SYS with client-host 1840 authentication strengthens the NFSv4 connection. Since 1841 [I-D.ietf-nfsv4-rpc-tls] assigns the specification of policies 1842 related to authentication to the ULP, it seems that AUTH_SYS needs 1843 to be discussed by NFSv4 documents in a manner more substantial 1844 than simply listed as another authentication flavor. 1846 * AUTH_SYS, both with and without client host authentication could 1847 be discussed in its own document, including an appropriate threat 1848 analysis. 1850 That document could be referenced by a new document updating or 1851 obsoleting [RFC5531]. This would provide an opportunity to 1852 address existing text which was essentially ignored by NFSv4. 1854 That document could also be referenced by a new standards-track 1855 document dealing with NFSv4 security. The threat analysis would 1856 provide a basis for the whatever approach the working group 1857 decides to take with regard to the discussion of AUTH_SYS with 1858 client-host authentication. See Section 8.4.6 for further 1859 details. 1861 The last of these is most likely to be adopted regardless of how the 1862 working group decides the issue described in Section 8.4.3. However, 1863 if the working group decides to strongly discourage the use of 1864 AUTH_SYS even with client-host authentication, the first is a 1865 possibility that should be considered. 1867 8.4.5. Issues to Address for Existing Use of AUTH_SYS 1869 This section presents material that might be included in a standards- 1870 track document in an effort to suitably discourage use of AUTH_SYS in 1871 its current (insecure) form. 1873 While it is sometimes the case that such a task can be accomplished 1874 by substituting one of the terms defined in [RFC2119] by another, 1875 that is not the case here While the designation of AUTH_SYS as 1876 optional (to implement) with [RFC7530] and [RFC8881] using the 1877 language "MAY be implemented", is wrong and probably needs to be 1878 fixed, the situation is more complex than generally recognized. It 1879 should be kept in mind that these terms are, in many cases, ignored 1880 or followed while ignoring the underlying intent. As a result, such 1881 changes, without supporting explanations might not be effective in 1882 changing implementer behavior. 1884 To summarize the confusing situation with AUTH_SYS and NFS and the 1885 role of the RPC specification, [RFC5531]. 1887 * At the time of publication of [RFC5531], AUTH_SYS was extensively 1888 used by NFSv2 [RFC1094], NFSv3 [RFC1813], and NFSv4.0 [RFC3530]. 1890 * The Security Considerations Section of [RFC5531], states "AUTH_SYS 1891 SHOULD NOT be used for services that permit clients to modify 1892 data", which all versions of NFS clearly are. 1894 * Section 10 of [RFC5531] states "Implementors MAY include AUTH_SYS 1895 in their implementations to support existing applications." 1896 Although this statement was probably intended to authorize 1897 continued use of AUTH_SYS, the contradiction between this 1898 statement and the Security Consideration section is not noted so 1899 there is no way to determine how this contradiction is to be 1900 resolved or precisely what "an application" is. 1902 * The case of NFsv4.1, later defined in [RFC5661], is different 1903 since, being a separate protocol, with additional vulnerabilities 1904 when AUTH_SYS is used, it would presumably not be an "existing 1905 application". 1907 * Turning from [RFC5531] to [RFC8881] and [RFC7530], we find 1908 AUTH_SYS described as an OPTIONAL means of authentication, with 1909 its security weaknesses not being discussed or treated as a 1910 significant concern. 1912 While there may well be sufficient loopholes within [RFC5531] to 1913 avoid an outright contradiction of the rules established there, it is 1914 certainly troubling that the security implications of implementing 1915 and using AUTH_SYS are not properly recommended against. 1917 While we may need to adjust the normative language, the effect of 1918 doing so is limited for reasons that have already been discussed. As 1919 a result, we need to put substantial emphasis on clearly stating the 1920 consequences of doing what "SHOULD NOT" (or "should not") be done, as 1921 is suggested by [RFC2119], at least for the former case. 1923 The following text is one way to present the situation: 1925 * The use of AUTH_SYS, as described (incompletely) in Appendix A of 1926 [RFC5531] is quite detrimental to security and so SHOULD NOT be 1927 used. 1929 * This is so because it involves accepting requests from clients on 1930 behalf of specific users without authentication of the clients 1931 themselves. In essence, the task of authentication is delegated 1932 to NFSv4 client implementations, with the server accepting such 1933 authentication decisions. Normally, such an arrangement would 1934 require the establishment of a trust relationship between client 1935 and server. 1937 * Typically, when using AUTH_SYS, use of a privileged port 1938 represents the client kernel's judgment (by granting root access) 1939 that the client proper is to be trusted but there is no good 1940 reason to trust the client kernels in this regard. 1942 * Although [RFC8881] and [RFC7530] previously treated implementation 1943 of AUTH_SYS as optional, it appears that this treatment was in 1944 error in that it focused on the relevant interoperability 1945 constraints without attention to the security consequences of use 1946 (discussed in Section 7 of [RFC2119]). While use of AUTH_SYS was 1947 not characterized using any of the keywords defined in [RFC2119], 1948 it was reasonable for implementers to assume this was valid given 1949 the lack of attention to network security issues and the fact that 1950 there would be no point in implementing support for AUTH_SYS in 1951 servers if it could not be used. 1953 * Although, as a result of these previous approaches to AUTH_SYS 1954 without client host authentication, it might be used extensively 1955 despite the security issues that cause us to specify that it 1956 "SHOULD NOT" be used are sufficient to justify this shift. 1957 However, due to the difficulty of making such a shift, the need to 1958 maintain continuity of support is a valid reason to continue to 1959 use it in this way, as long as this decision is made with 1960 awareness of the security consequences: 1962 - That it is possible for an attacker to impersonate a trusted 1963 client by using its IP address in source IP address of packet 1964 sent, enabling to send its own requests to read or modify data, 1965 as any particular user. 1967 - That compromising any client whose AUTH_SYS requests are 1968 accepted allows it to create a connection from which its 1969 unauthenticated requests will be executed by the server. 1971 - That it is possible for attackers to work around "root 1972 squashing" since it can assume any identity it intends to, 1973 other than that of root. 1975 8.4.6. Issues to Resolve for Revised Approach to AUTH_SYS 1977 The availability of client-host authentication makes possible a 1978 revised approach to AUTH_SYS addressing some of its security 1979 vulnerabilities. A revised approach to AUTH_SYS might provide: 1981 1. The ability to prevent, using client host-authentication, another 1982 machine masquerading as the expected client. 1984 The authentication features described in 1985 [I-D.ietf-nfsv4-rpc-tls], would be assure that you could identify 1986 trusted client machines, eliminating a major security issue with 1987 AUTH_SYS. On the other hand, it is not clear whether servers 1988 would be wise to trust clients to this degree, especially if the 1989 items below (#2 and #3) are not satisfactorily dealt with. 1991 2. It would be possible to include, as part of the client 1992 authentication material, information known only to the client and 1993 the server. The secret value would be chosen by the client, and 1994 saved so it is usable by later client instances. If this were 1995 done, it would prevent any process with root privileges on a 1996 trusted machine from impersonating the trusted client. If this 1997 were not done, then any compromise of a single trusted client 1998 would compromise any server which trusted it to present AUTH_SYS 1999 requests. 2001 To make this approach viable, servers would have to maintain, in 2002 persistent storage, a record of the secret value assigned to each 2003 authenticated client. When an authenticated client connected 2004 with a different value it would indicate that a root process on 2005 the client-host was attempting to impersonate the NFSv4 client. 2007 3. The power granted to the authenticated client-host, to make a 2008 request on behalf of user or group has troubling consequences. 2009 Although most implementations have the ability to exclude 2010 requests from the root user, that may not, as has been noted 2011 previously, be sufficient to satisfactorily deal with the 2012 problem, since many deployments contain security-critical files 2013 that can be accessed and modified but users other than root. 2015 It would be desirable to exclude a wider range of users such as 2016 all users within a given group (or alternatively include only 2017 users within a given group). However, neither of these is viable 2018 since servers receiving AUTH_SYS requests typically have no 2019 knowledge of what users belong to what groups, relying on the 2020 AUTH_SYS client to provide this information within the request. 2022 Given this lack of knowledge on the part of the servers, any 2023 restrictions on the ability of AUTH_SYS requests to access or 2024 modify files designate a set of protected files in some way. 2025 Since designating a list of files is complicated and hard to 2026 maintain, it might be possible to describe the files whose access 2027 and/or modification by means of an ACL. When a request is made 2028 to access a file, that request is suppressed (i.e. treated as a 2029 request by "nobody") iff it would be allowed to access by the 2030 designated ACL and similarly in the case of modifying requests. 2032 How to address the question of the potential use of AUTH_SYS with 2033 client-host authentication would depend on the working group's 2034 judgement about how likely such an arrangement would be likely to be 2035 in providing security when AUTH_SYS is used. This in turn would 2036 depend on the working group's judgment as to whether solutions for #2 2037 and #3 could be defined and effectively deployed, as well as the 2038 results of the threat analysis 2040 We assume that AUTH_SYS with client-host authentication needs to be 2041 considered inferior to RPCSEC_GSS but sufficiently superior to 2042 AUTH_SYS without client authentication to make it desirable to 2043 encourage its use, given that it is impossible to eliminate use of 2044 AUTH_SYS, even with a "MUST NOT". A number of potential 2045 introductions to the topic, of varying tone are explored below: 2047 * If the working group wants to focus on the improvement relative to 2048 AUTH_SYS without client-host authentication, the following 2049 paragraphs might be an appropriate introduction: 2051 When AUTH_SYS is used with client-host authentication, then the 2052 server, by allowing use of AUTH_SYS for that specific client, is 2053 essentially delegating the user authentication task to that client 2054 who is trusted by the server to perform that task locally, just as 2055 typically done when authenticating users for the purpose of local 2056 file access, even though the scope of damage that could be enabled 2057 by any false authentication is likely to be much wider in this 2058 case. 2060 By accepting AUTH_SYS requests from a particular client, a server 2061 is relying on the security of the client for the security of all 2062 data stored on the server. This is in contrast to RPCSC_GSS, in 2063 which authentication is provided for each request issued. Because 2064 of this, the use of AUTH_SYS should only be allowed from client 2065 hosts that can reasonably be trusted. 2067 * If the working group wants to adopt a more cautionary tone 2068 regarding use of AUTH_SYS with client-host authentication, the 2069 following paragraphs might be an appropriate introduction: 2071 By accepting AUTH_SYS requests from a particular client, a server 2072 is relying on the security of the client for the security of all 2073 data stored on the server. This is in contrast to RPCSC_GSS, in 2074 which authentication is provided for each request issued. Because 2075 of this, the use of AUTH_SYS should only be allowed from client 2076 hosts that can reasonably be trusted and whose internal security 2077 is sufficiently robust that the additional risk to server data can 2078 be considered reasonable. 2080 * If the working group wants to focus more on encouraging use of 2081 RPCSEC_GSS, then on improving the security of those choosing to 2082 use AUTH_SYS, a paragraph like the following might be appropriate. 2084 While the use of AUTH_SYS with client-host authentication 2085 eliminates some of the major security issues that arise from use 2086 of AUTH_SYS, it is still inferior, from a security point of view, 2087 to RPCSEC_GSS. As a result, its use should be limited to 2088 situations in which, use of RPCSEC_GSS is not a practical 2089 possibility. 2091 The following paragraph might be added if item #2 is not successfully 2092 addressed: 2094 * It should be noted that any security weaknesses in the client host 2095 kernel which might allow an attacker to execute in privileged 2096 mode, are likely to allow that that attacker to present AUTH_SYS 2097 requests to the server and have them executed without any 2098 authentication beyond verifying that they were issued by a trusted 2099 host. 2101 The following paragraph might be added if item #2 is successfully 2102 addressed: 2104 * In order to assure that it is not possible for a process running 2105 as root to successfully masquerade as a previously active kernel- 2106 based client on that machine, user-level clients even privileged 2107 ones, will present distinct authentication material from a kernel- 2108 based client and from each other. Servers SHOULD maintain, 2109 persistently, sufficient information so to be able to detect a 2110 situation in which process with root privileges on a trusted 2111 server masquerades as a client previously recognized on that and 2112 judged secure. 2114 The following paragraph might be added if item #3 is not successfully 2115 addressed: 2117 * There is no standardized way the server can effectively limit the 2118 range of client user identities and group memberships assumed by 2119 AUTH_SYS requests except for the commonly implemented practice of 2120 "root squashing". 2122 The following paragraph might be added if item #3 is successfully 2123 addressed: 2125 * Server SHOULD provide a means by which specific sets of sensitive 2126 files are made inaccessible or unmodifiable by use of AUTH_SYS 2127 requests, in order to limit the damage that could occur in the 2128 event that a client compromise allows unauthenticated requests to 2129 be generated and acted upon. One desirable way of providing such 2130 a facility would be to allow an ACL to be associated with each 2131 authenticated client host (e.g. by designating a file whose ACL is 2132 to be used). If this is done any request whose user together with 2133 a group set would allow it to be accepted by the specified ACL 2134 would be rejected. 2136 The following closing paragraphs are proposed for an eventual 2137 introduction to AUTH_SYS, as revised. In these paragraphs, material 2138 to be added only if a particular item above is addressed or not 2139 addressed will appear in brackets with the prefix "if-#x:" or "if- 2140 not-#x:". 2142 * The ability to make AUTH_SYS requests of a server SHOULD be 2143 limited to those cases in which the client host making those 2144 requests can be trusted to appropriately verify a user's 2145 credentials (e.g. passwords) before issuing RPC requests on that 2146 user's behalf. [if-#3: This limitation should be applied even when 2147 the set of users or owning groups is restricted to specially 2148 protect files deemed sensitive.] [if-not-#3: When not so limited, 2149 requests purportedly from any user except possibly root, can be 2150 synthesized and acted upon, without effective authentication.] 2152 * For that reason, accepting AUTH_SYS requests from a large set of 2153 client hosts is a practice to be avoided, with individual hosts 2154 included where their security has been verified. The only 2155 possible exception is where a set of policies is in place which 2156 effectively limits the kernel software allowed to run on those 2157 hosts to ensure that those hosts appropriately providing user 2158 authentication [if-not-#2: and capable of excluding untrusted code 2159 from masquerading as an NFSv4 server by assuming root privileges.] 2161 8.5. Handling of State Protection 2163 8.5.1. Background 2165 The inclusion of state management within NFSv4 created new security 2166 issues in which the objects requiring protection were not files 2167 associated with particular users but locks, opens, and delegations, 2168 associated with particular clients. 2170 In NFSv4.0, some protection could be provided when RPCSEC_GSS was 2171 used by limiting modification of state objects to users having access 2172 to the associated file. Nevertheless, the fundamental issue remained 2173 unresolved. 2175 When sessions were introduced into NFSv4 (in NFSv4.1) there were 2176 additional vulnerabilities that needed to be protected against. 2177 There needed to be protection to prevent a session established by one 2178 client being bound to a connection established by another client, 2179 leading to the following possibilities: 2181 * The existing session could be destroyed. 2183 * The associated clientid could be destroyed. 2185 * The existing session slots could be used resulting in the 2186 legitimate owner of the session having his requests rejected 2187 because his slot sequence values had been rendered invalid because 2188 of the interloper's requests using the same slots. 2190 Facilities were defined in [RFC5661] to allow such client-based 2191 protection to be implemented: SP4_MACHCRED and SP4_SSV but 2192 implementation has been quite limited. Client-host authentication 2193 makes it possible to apply such protection more generally, as 2194 described below. 2196 8.5.2. Issues to be Addressed 2198 While transport-level encryption would make it harder for attackers 2199 to mount attacks based on these vulnerabilities, the authentication 2200 material provided when a TLS connection is established could enable 2201 the vulnerabilities discussed above to be eliminated without the work 2202 of implementing SP4_MACHCRED or SP4_SSV, and irrespective of whether 2203 the client is using AUTH_SYS or RPCSEC_GSS. 2205 If one has a TLS connection including suitable authentication 2206 material, then the server is in a position to reject attempts to bind 2207 to sessions established under this connection by other connections 2208 that are not TLS connections with client-host authentication or are 2209 not established by the same client, unless SP4_MACHCRED or SP4_SSV is 2210 in effect. This would make state protection available to those using 2211 SP4_NONE, i.e. the vast majority, whether they used RPCSEC_GSS or 2212 AUTH_SYS with client-host authentication. 2214 The fact that this is an NFSv4.1-only security feature would make it 2215 difficult to fully it address solely in the NFSv4-wide security 2216 document which will be written. The following proposal is intended 2217 to allow the security document to be published before proceeding to 2218 publish the anticipated rfc5661bis: 2220 * In the anticipated standards-track NFSv4 security document, it can 2221 be stated that when SP4_NONE is specified and the client owning 2222 the session is authenticated, then the session is protected from 2223 being bound-to or destroyed by an unauthenticated client or a 2224 different authenticated client, then the effect is the same as if 2225 SP4_MACHCRED or SP4_SSV were used by the owning client and a non- 2226 matching client was found. Since the new standards-track document 2227 would update [RFC8881], that provides adequate notice of this 2228 change 2230 * Later, when rfc5661bis is ready to be published, there would an 2231 opportunity to provide introductory material explaining the 2232 various ways clients can be authenticated for the purpose of state 2233 protection, including use of SP4_MACHCRED or SP4_SSV and 2234 authentication as part of use of RPC-TLS. This would allow 2235 defining the circumstances under which one connection can access/ 2236 modify state owned by an another client in terms of whether the 2237 connections involved are part of the same client. References to 2238 such abstract relationships would replace most current mentions of 2239 SP4_NONE, SP4_MACHCRED, and SP4_SSV in [RFC8881]. 2241 It should be noted that this use of client-host authentication 2242 provides applicable protection even when AUTH_SYS is used. This is 2243 so however the issues discussed in Section 8.4.6 are addressed, and 2244 independent of the decision made regarding the choice discussed in 2245 Section 8.4.3 unless it is decided that AUTH_SYS MUST NOT be used. 2246 Issues regarding the impersonation of a large set of users are not 2247 relevant because user ids are not referenced. Furthermore, the 2248 possibility of a privileged user-level client implementing a denial- 2249 of-service attach (if issue #2 in Section 8.4.6 is not addressed), is 2250 not of concern since such a privileged process would find it far 2251 easier to deny service directly on the client host. 2253 9. IANA Considerations 2255 The current document does not require any actions by IANA. 2257 10. Security Considerations 2259 The convention of requiring a Security Considerations Section within 2260 an I-D encounters difficulties when applied to a document dealing 2261 solely with security, making it most unclear what such a section 2262 might contain for such documents. 2264 In addition, the nature of this particular document poses further 2265 issues regarding the possible content of a Security Consideration 2266 Section: 2268 * This document does not define a protocol or protocol feature that 2269 can be implemented, making it unclear how a threat analysis could 2270 be performed whose security considerations would be described. 2272 * Despite this document's informational nature, it does attempt to 2273 address security issues for an existing set of protocols 2275 In light of the above, this section will summarize the security- 2276 related message of earlier sections and will, in subsections, discuss 2277 the appropriate contents of Security Considerations Sections for a 2278 eventual standards-track documents to be written 2280 The message of this document with regard to security issues can be 2281 summarized as follows 2283 * The current security approach for the NFSv4 protocols has some 2284 significant weaknesses, requiring a major reworking of the 2285 security approach. 2287 * This reworking can be accomplished without change to the NFS 2288 protocols per se, by taking advantage of recent security 2289 improvements defined within the RPC layer. 2291 * A threat analysis, not provided in previous NFSv4 specification 2292 documents, will be the provided within a new standards-track 2293 document addressing security for all minor versions of NFSv4. 2295 * Because there is no threat analysis of AUTH_SYS in existence, one 2296 needs to be provided, preferably in a new standard-track document 2297 dealing with AUTH_SYS. This is despite the designation of 2298 AUTH_SYS (in [RFC5531] as "insecure", which was never, at least in 2299 the case of NFSv4, acted upon. Such a document is needed to 2300 clarify the security weaknesses of AUTH_SYS and the degree such 2301 weakness could be rectified by the implementation of TLS-based 2302 encryption and/or client host authentication. 2304 10.1. Security Considerations Section for Eventual NFSv4-wide 2305 Standards-track Security Document 2307 Although it is clear that such a document would need to include a 2308 threat analysis, as provided for by [RFC3552]. However, the length 2309 of such an analysis might well be so large that it cannot be 2310 reasonably contained within a Security Considerations Section. In 2311 that case, the Security Considerations Section will summarize the 2312 results of the threat analysis, referring to those parts that appear 2313 in other sections of the document. 2315 10.2. Security Considerations Section for Eventual Rfc5661bis 2317 This section would have to refer to the Security Considerations 2318 section of the new NFSv4-wide secrity document. In addition, to deal 2319 with NFSv4.1-specific security issues (i.e. pNFS and state 2320 protection), there would be additional material, most likely within 2321 the Security Considerations section or a subsection thereof. 2323 10.3. Security Considerations Section for Potential Revised RPC 2324 Specification Document 2326 The general form of this section in [RFC5531] in which references are 2327 made to documents for each security flavor, seem appropriate. 2328 However, the following changes are likely to be required: 2330 * The treatment of AUTH_SYS might need to reference a new document 2331 describing AUTH_SYS, rather than the incomplete description in 2332 Appendix A, which needs to be removed. 2334 In addition, the last two sentences of the initial paragraph of 2335 section 14 need to be reworked to respond to the fact that while, 2336 there was no clear violation of them, this insecure authentication 2337 flavor was used by NFSv4 for over a decade subsequently. Although 2338 the following attempt at loophole removal might not survive the 2339 editing and review process, the issues it raises are worth 2340 considering. 2342 - As discussed in the referenced document, the use of AUTH_SYS in 2343 the clear without client host-authentication introduces 2344 significant security vulnerabilities in that it allows 2345 unauthenticated requests to be created by an unauthenticated 2346 client. This make its use highly inappropriate for any RPC 2347 service, particularly those that allow clients to modify data. 2349 - Similarly, in specifications of standards-track RPC services, 2350 it is inappropriate to make such use REQUIRED or RECOMMENDED. 2351 Where such use is allowed at all (whether by "MAY" or "SHOULD 2352 NOT" is used), viable non-disruptive alternatives need to 2353 provided and the associated Security Consideration sections 2354 need to clearly explain the security consequences of use. 2356 * The case of AUTH_DH is similar to that of AUTH_SYS in that there 2357 is a simple declaration of insecurity. However, there is a 2358 document referenced and there is no indication that the loopholes 2359 in the treatment were bypassed in this case, as they were for 2360 AUTH_SYS. Still, it might worth revising the final two sentences 2361 as were done with AUTH_SYS. 2363 * Given that the final paragraph of the Security Considerations 2364 section was drafted without consideration of reverse direction 2365 operation and without consideration the possibility that either 2366 TLs encryption or client host authentication might be available 2367 (and potentially REQUIRED), redrafting it to be more appropriate 2368 for the environment made possible by [I-D.ietf-nfsv4-rpc-tls] is 2369 likely. 2371 The following replacement text is suggested to deal with these 2372 issues: 2374 - Standards-track RPC services need to mandate server and client 2375 support for RPCSEC_GSS when used in the forward direction. The 2376 treatment of authentication for reverse-direction operation 2377 needs to provide for authentication of the identity of the 2378 requester (i.e. on the server) to the responder (i.e. on the 2379 client). When reverse direction requests are not made on 2380 behalf of a specific user, the mutual authentication provided 2381 by RPC-TLS can be relied on but authentication of users on 2382 reverse-direction requests will need to use RPCSEC_GSS. 2384 - For either direction of operation, when user identities must be 2385 authenticated, such services need to mandate support for an 2386 authentication pseudo-flavor. In situations in which it is 2387 possible/allowed for RPC services to be used without TLS 2388 encryption there is also a need to mandate pseudo-flavors with 2389 additional appropriate levels of security, depending on the 2390 need for authentication only, integrity (a.k.a. non- 2391 repudiation), or encryption to provide data confidentiality. 2393 10.4. Security Considerations Section for Potential Standards-track 2394 Document Dealing with AUTH_SYS 2396 As mentioned above, a prime goal of a general threat analysis for 2397 AUTH_SYS would be to clarify the degree to which the security 2398 weaknesses of AUTH_SYS can be successfully addressed using transport- 2399 level security facilities. Those pieces of the threat analysis might 2400 well appear outside the Security Consideration section proper. 2402 The Security Considerations would need to summarize these and provide 2403 a basis for ULPs that allow AUTH_SYS to specify the appropriate 2404 conditions for use and the consequences of not enforcing these. 2406 11. References 2408 11.1. Normative References 2410 [I-D.ietf-nfsv4-rpc-tls] 2411 Myklebust, T. and C. Lever, "Towards Remote Procedure Call 2412 Encryption By Default", Work in Progress, Internet-Draft, 2413 draft-ietf-nfsv4-rpc-tls-11, 23 November 2020, 2414 . 2416 [I-D.ietf-nfsv4-rpcrdma-version-two] 2417 Lever, C. and D. Noveck, "RPC-over-RDMA Version 2 2418 Protocol", Work in Progress, Internet-Draft, draft-ietf- 2419 nfsv4-rpcrdma-version-two-03, 10 August 2020, 2420 . 2423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2424 Requirement Levels", BCP 14, RFC 2119, 2425 DOI 10.17487/RFC2119, March 1997, 2426 . 2428 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2429 Text on Security Considerations", BCP 72, RFC 3552, 2430 DOI 10.17487/RFC3552, July 2003, 2431 . 2433 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 2434 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 2435 May 2009, . 2437 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 2438 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 2439 March 2015, . 2441 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 2442 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 2443 November 2016, . 2445 [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct 2446 Memory Access Transport for Remote Procedure Call Version 2447 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, 2448 . 2450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2452 May 2017, . 2454 [RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 2455 Version 4 Minor Version 1 Protocol", RFC 8881, 2456 DOI 10.17487/RFC8881, August 2020, 2457 . 2459 11.2. Informative References 2461 [I-D.dnoveck-nfsv4-rfc5661bis] 2462 Noveck, D., "Network File System (NFS) Version 4 Minor 2463 Version 1 Protocol", Work in Progress, Internet-Draft, 2464 draft-dnoveck-nfsv4-rfc5661bis-00, 31 December 2020, 2465 . 2468 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 2469 specification", RFC 1094, DOI 10.17487/RFC1094, March 2470 1989, . 2472 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 2473 Version 3 Protocol Specification", RFC 1813, 2474 DOI 10.17487/RFC1813, June 1995, 2475 . 2477 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", 2478 RFC 2624, DOI 10.17487/RFC2624, June 1999, 2479 . 2481 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 2482 Beame, C., Eisler, M., and D. Noveck, "Network File System 2483 (NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530, 2484 April 2003, . 2486 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2487 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 2488 . 2490 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 2491 "Network File System (NFS) Version 4 Minor Version 1 2492 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 2493 . 2495 [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor 2496 Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, 2497 . 2499 Acknowledgements 2501 The authors would like to thank all who contributed to 2502 [I-D.ietf-nfsv4-rpc-tls] for their important work providing security 2503 at the RPC layer, enabling us to break the NFSv4 security logjam. 2505 The authors would like to thank Tom Haynes (of Hammerspace) for 2506 introducing the idea of dealing with security for all minor versions 2507 in a single document. 2509 Authors' Addresses 2510 David Noveck 2511 NetApp 2512 1601 Trapelo Road 2513 Waltham, MA 02451 2514 United States of America 2516 Phone: +1 781 572 8038 2517 Email: davenoveck@gmail.com 2519 Charles Lever (editor) 2520 Oracle Corporation 2521 United States of America 2523 Email: chuck.lever@oracle.com