idnits 2.17.1 draft-dnoveck-nfsv4-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8881, but the abstract doesn't seem to directly say this. It does mention RFC8881 though, so this could be OK. -- The draft header indicates that this document updates RFC7530, but the abstract doesn't seem to directly say this. It does mention RFC7530 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 723 has weird spacing: '...r_mixed who;...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 July 2021) is 1021 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 D. Noveck, Ed. 3 Internet-Draft NetApp 4 Updates: 8881, 7530 (if approved) 11 July 2021 5 Intended status: Standards Track 6 Expires: 12 January 2022 8 Security for the NFSv4 Protocols 9 draft-dnoveck-nfsv4-security-00 11 Abstract 13 This document describes the core security features of the NFSv4 14 family of protocols, applying to all minor versions. The discussion 15 includes the use of security features provided at the RPC transport 16 level. 18 This prelimimary version of the document, is intended, in large part, 19 to result in working group discussion regarding NFSv4 security issues 20 and ientify issues on which the working group needs to work on 21 achieving consensus. 23 When published as an RFC, it will supersede the description of 24 security appearing in existing minor version specification documents 25 such as RFC 7530 and RFC 8881. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 12 January 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 5 75 2.2. Special Considerations . . . . . . . . . . . . . . . . . 5 76 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Handling of Multiple Minor Versions . . . . . . . . . . . 6 78 3.2. Handling of Minor-version-specific features . . . . . . . 7 79 3.3. Transport-based Security Features . . . . . . . . . . . . 9 80 4. Authorization in General . . . . . . . . . . . . . . . . . . 10 81 5. User-based File Access Authorization . . . . . . . . . . . . 11 82 5.1. Handling of Multiple Parallel File Access Authorization 83 Models . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.2. Attributes for User-based File Access Authorization . . . 13 85 5.3. Posix Authorization Model . . . . . . . . . . . . . . . . 14 86 5.3.1. Attribute 33: mode . . . . . . . . . . . . . . . . . 14 87 5.3.2. V4.1 Attribute 74: mode_set_masked . . . . . . . . . 15 88 5.4. ACL-based Authorization Model . . . . . . . . . . . . . . 15 89 5.4.1. Access control Entries . . . . . . . . . . . . . . . 15 90 5.4.2. ACE Type . . . . . . . . . . . . . . . . . . . . . . 17 91 5.4.3. ACE Access Mask . . . . . . . . . . . . . . . . . . . 19 92 5.4.4. Details Regarding Mask Bits . . . . . . . . . . . . . 20 93 5.4.5. ACE4_DELETE vs. ACE4_DELETE_CHILD . . . . . . . . . . 27 94 5.4.6. ACE flag . . . . . . . . . . . . . . . . . . . . . . 27 95 5.4.7. Details Regardign ACE Flag Bits . . . . . . . . . . . 28 96 5.4.8. ACE Who . . . . . . . . . . . . . . . . . . . . . . . 29 97 5.4.9. Automatic Inheritance Features . . . . . . . . . . . 31 98 5.5. Attribute 12: acl . . . . . . . . . . . . . . . . . . . . 33 99 5.6. Attribute 13: aclsupport . . . . . . . . . . . . . . . . 34 100 5.7. V4.1 Attribute 58: dacl . . . . . . . . . . . . . . . . . 34 101 5.8. V4.1 Attribute 59: sacl . . . . . . . . . . . . . . . . . 35 102 6. Common Considerations for Both File access Models . . . . . . 35 103 6.1. Server Considerations . . . . . . . . . . . . . . . . . . 35 104 6.2. Client Considerations . . . . . . . . . . . . . . . . . . 36 105 7. Combining Authorization Models . . . . . . . . . . . . . . . 37 106 7.1. Combined Authorization Models for V4.0 . . . . . . . . . 37 107 7.2. Combined Authorization Model for V4.1 and Beyond . . . . 37 108 7.2.1. Computing a Mode Attribute from an ACL . . . . . . . 38 109 7.2.2. Alternatives in Computing Mode Bits . . . . . . . . . 39 110 7.2.3. Setting Multiple ACL Attributes . . . . . . . . . . . 39 111 7.2.4. Setting Mode and not ACL . . . . . . . . . . . . . . 40 112 7.2.5. Setting ACL and Not Mode . . . . . . . . . . . . . . 41 113 7.2.6. Setting Both ACL and Mode . . . . . . . . . . . . . . 41 114 7.2.7. Retrieving the Mode and/or ACL Attributes . . . . . . 41 115 7.2.8. Creating New Objects . . . . . . . . . . . . . . . . 41 116 7.2.9. Use of Inherited ACL When Creating Objects . . . . . 43 117 7.3. Combined Authorization Models for V4.2 . . . . . . . . . 43 118 8. Labelled NFS Authorization Model . . . . . . . . . . . . . . 43 119 9. State Modification Authorization . . . . . . . . . . . . . . 44 120 10. Identification and Authentication . . . . . . . . . . . . . . 45 121 10.1. Identification vs. Authentication . . . . . . . . . . . 45 122 10.2. Items to be Identified . . . . . . . . . . . . . . . . . 45 123 10.3. Authentication Provided by specfic RPC Flavors . . . . . 47 124 10.4. Authentication Provided by the RPC Transport . . . . . . 47 125 11. Security of Data in Flight . . . . . . . . . . . . . . . . . 47 126 11.1. Data Security Provided by the Flavor-associated 127 Services . . . . . . . . . . . . . . . . . . . . . . . . 47 128 11.2. Data Security Provided by the RPC Transport . . . . . . 48 129 12. Security Negotiation . . . . . . . . . . . . . . . . . . . . 48 130 12.1. Flavors and Pseudo-flavors . . . . . . . . . . . . . . . 48 131 12.2. Negotiation of Security Flavors and Mechanisms . . . . . 50 132 12.3. Negotiation of RPC Transports and Characteristics . . . 50 133 12.4. Overall Interpretation of SECINFO Response Arrays . . . 51 134 12.5. SECINFO . . . . . . . . . . . . . . . . . . . . . . . . 52 135 12.5.4. SECINFO IMPLEMENTATION (general) . . . . . . . . . . 54 136 12.5.4.1. SECINFO IMPLEMENTATION (for v4.0) . . . . . . . 55 137 12.5.4.2. SECINFO IMPLEMENTATION (for v4.1 and v4.2) . . . 55 138 12.6. Future Security Needs . . . . . . . . . . . . . . . . . 56 139 13. Security Considerations . . . . . . . . . . . . . . . . . . . 57 140 13.1. Changes in Security Considerations . . . . . . . . . . . 57 141 13.1.1. Wider View of Threats . . . . . . . . . . . . . . . 57 142 13.1.2. Transport-layer Security Facilities . . . . . . . . 58 143 13.1.3. Compatibility and Maturity Issues . . . . . . . . . 58 144 13.1.4. Discussion of AUTHSYS . . . . . . . . . . . . . . . 59 146 13.2. Security Considerations Scope . . . . . . . . . . . . . 60 147 13.2.1. Discussion of Potental Classification of 148 Environmets . . . . . . . . . . . . . . . . . . . . . 60 149 13.2.2. Discussion of Environments . . . . . . . . . . . . . 60 150 13.3. Major New Recommendations . . . . . . . . . . . . . . . 61 151 13.3.1. Recommendations Regarding Security of Data in 152 Flight . . . . . . . . . . . . . . . . . . . . . . . 61 153 13.3.2. Recommendations Regarding Client Peer 154 Authentication . . . . . . . . . . . . . . . . . . . 61 155 13.3.3. Issues Regarding Valid Reasons to Bypass 156 Recommendations . . . . . . . . . . . . . . . . . . . 62 157 13.4. Data Security Threats . . . . . . . . . . . . . . . . . 62 158 13.5. Authentication-based threats . . . . . . . . . . . . . . 62 159 13.5.1. Attacks based on the use of AUTH_SYS . . . . . . . . 62 160 13.5.2. Attacks on Name/Userid Mapping Facilities . . . . . 62 161 13.6. Disruption and Denial-of-Service Attacks . . . . . . . . 63 162 13.6.1. Attacks Based on the Disruption of Client-Server 163 Shared State . . . . . . . . . . . . . . . . . . . . 63 164 13.6.2. Attacks Based on Forcing the Misuse of Server 165 Resources . . . . . . . . . . . . . . . . . . . . . . 63 166 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 167 14.1. New Authstat Values . . . . . . . . . . . . . . . . . . 63 168 14.2. New Authentication Pseudo-Flavors . . . . . . . . . . . 63 169 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 170 15.1. Normative References . . . . . . . . . . . . . . . . . . 64 171 15.2. Informative References . . . . . . . . . . . . . . . . . 65 172 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 65 173 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 65 175 1. Overview 177 This document presents a new approach to security for the NFSv4 178 protocols, which, although building on previous treatments of these 179 issues, diverges substantially from them in a number of respects. 181 A new treatment is necessary because: 183 * Previous treatments paid insufficient attention to security issues 184 regarding data in flight. 186 * The presentation of AUTH_SYS as an "'OPTIONAL' means of 187 authentication" obscured the severe security problems that come 188 with its use. 190 * The security considerations sections of existing minor version 191 specifications contain no threat analyses and focus on particular 192 security issues in a way that obscures, rather than clarifying, 193 the security issues that need to be addressed. 195 * The availabilty of RPC-with-TLS (described in [12]) provides 196 facilities that NFSv4 clients and servers will need to use to 197 provide security for data in flight and mitigate the lack of 198 authentication when AUTH_SYS is used. 200 This preliminary document contains many notes with headers in 201 brackets, requesting comments regarding confusing or otherwise 202 dubious passages in existing documents and other choices that need to 203 made. Comments and working group discussion of those notes will be 204 important in arriving at an adequate RFC cadidate. 206 2. Requirements Language 208 2.1. Keyword Definitions 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as specified in BCP 14 [1] [5] when, 213 and only when, they appear in all capitals, as shown here. 215 2.2. Special Considerations 217 Because this document needs to revise previous treatments of its 218 subject, it will need to cite previous treatments of issues that now 219 need to be dealt with in a different way. This will take the form of 220 quotations from documents whose treatment of the subject is being 221 obsoleted, most often direct but sometimes indirect as well. 223 Such treatments in quotations will involve use of these BCP14-defined 224 terms in two noteworthy ways: 226 * The term may have been used inappropriately (i.e not in accord 227 with [1]), as has been the case for the "RECOMMENDED" attributes, 228 which are in fact OPTIONAL. 230 In such cases, the surrounding text will make clear that the 231 quoted text has no normative effect. 233 Some specific issues relating to this case are described below 234 Section 5.2. 236 * The term may been used in accord with [1], although the resulting 237 normative statement is now felt to be inappropriate. 239 In such cases, the surrounding text will need to make clear that 240 the text quoted is no longer to be considered normative, often by 241 providing new text that conficts with the quoted, previously 242 nomative, text. 244 An important instance of this situation is the description of 245 AUTH_SYS as an "OPTIONAL" means of authentication. For detailed 246 discussion of this case, see Sections 10 and 13.1.4 248 3. Introduction 250 Because the basic approach to security issues is so similar for all 251 minor versions, this document applies to all NFSv4 minor versions. 252 The details of this transition are discused in Sections 3.1 and 3.2 254 This document is able to take a new approach to security issues 255 because of the work that has been done to provide security features 256 at the transort level, rather than providing security features only 257 by making choices with regard to the authentication flavor and 258 associated mechanisms and services. The effect of this shift is 259 summarized in Section 3.3. 261 3.1. Handling of Multiple Minor Versions 263 In some cases, there are differences between minor versions in that 264 there are security-related features, not present in all minor 265 versions. 267 To deal with this issue, this document will focus on a few major 268 areas listed below which are common to all minor versions. 270 * File access authorization (discussed in Section 5) is the same in 271 all minor versions togther with the identification/ authentication 272 infrastructure supporting it (discussed in Section 10) provided by 273 RPC and applying to all of NFS. 275 An exception is made regarding labelled NFS, an optional feature 276 within NFSv4.2, described in [10]. This is discussed as a 277 version-specific feature in this document in Section 8 279 * Features to secure data in-flight, all provided by RPC, together 280 with the negotation infrastructure to support them are common to 281 all NFSv4 minor versions, are discussed in Section 12 283 However, the use of SECINFO_NONAME, together with changes needed 284 for transport level encryption, paralleling those proposed here 285 for SECINFO, is treated as a version-specfic feature and, while 286 mentioned here, will be fully documented in new v4.1 specification 287 documents. 289 * The Protection of state data from unauthorized modification is 290 discussed in Section 9) is the same in all minor versions togther 291 with the identification/ authentication infrastructure supporting 292 it (discussed in Section 10) provided by secure transports such as 293 RPC-over-TLS. 295 It should be noted that state protection based on RPCSEC_GSS is 296 treated as a version-specific feature and will continue to be 297 described by [8] or its successors. Also, it needs to be noted 298 that the use of state protection is not discussed in [6]. 300 3.2. Handling of Minor-version-specific features 302 There are a number of areas in which security features differ among 303 minor versions, as discussed below. In some cases, a new feature 304 requires specific security support while in others one version will 305 have a new feature related to enhancing the security infrastructure. 307 How such features are dealt with in this document depends on the 308 specific feature. 310 [Working group discussion advisable]: There's a lot of opportnities 311 to make mistakes. I'd prefer to find out sooner rather than later. 313 * In addition to SECINFO, whose enhanced description appears in this 314 document, NFSv4.1 added a new SECINFO_NONAME operation, useful for 315 pNFS file as well as having some non-pNFS uses. 317 While the enhanced description of SECINFO mentions SECINFO_NONAME, 318 this is handled as one of a number of cases in which the 319 description has to indicate that different actions need to be 320 taken for different minor versions. 322 The definitive description of SECINFO_NONAME, now appearing in 323 RFC8881 needs to be modified to match the description of SECINFO 324 appearing in this document. It is expected that this will be done 325 as part of the rfc5661bis process. 327 The security implications of the security negotiation facilities 328 as a whole will be addressed in the security considerations 329 section of this document. 331 * The pNFS optional feature added in NFSv4.1 has its own security 332 needs which parallel closely those of non-pNFS access. As a 333 result, these needs and the means to satisfy them are not 334 discussed in this document. 336 The definitive description of pNFS security will remain in RFC8881 337 and its successors (i.e. the rfc5661bis document suite). However, 338 because pNFS sucurity relies heavily on the infrastructure 339 discussed here, it is anticipated that the new treatment of pNFS 340 security will deal with many matters by referencing the overall 341 NFS security document. 343 The security considerations section of rfc5661bis will deal with 344 pNFS security issues. 346 * In addition to the state protection facilities described in this 347 document, NFS has another set of such facilities that are not 348 usable in NFSv4.0. 350 While this document will discuss the security implications of 351 protection against state modification, it will not discuss the 352 details of the v4.1-specfic features to accomplicsh it. 354 * The additional v4.1 acl attributes, sacl and dacl, are mentioned 355 in this document, but do not affect the treatment of security, 356 since the acl entries, whether in the acl attribute or separated 357 into sacl and dacl attributes continue to have the same effect. 359 * Nfsv4.1 introduced detailed description of methods of co- 360 ordinating the values of the authorization-related attributes mode 361 and acl. this is in contrast to Nfsv4.0, which while expecting 362 such co-ordination to be provide somehow, did not provide any 363 detils, allowing a number of different approaches to meat the goal 364 of providing appopriate co-ordination. 366 This document will provide separate sections describing each of 367 the approaches, together with a common section describing the 368 goals of providing co-ordination when both are supported. 370 As a result, this document will override the treatment within 371 RFC8881 and this material will be removed in the rfc5661bis 372 document suite and replaced by a reference to the treatment in the 373 NFSv4 security RFC. 375 Simiarly, this doument will supersede the corresponding treatment 376 in RFC7530 as well. As a result, v4.0 server implementers reading 377 any successor document will be aware of the possibility of the 378 v4.1 approach even though it is clear that this only one of the 379 possible approaches to this issue. V4.1 client implementers will 380 be made aware of the goals and that there is little that can be 381 relied upon with regard to v4.0 servers' attempts to address those 382 goals. 384 * The protocol extension defined in [13], now part of NFSv4.2, is 385 also related to the issue of co-ordination of acl and mode 386 attributes and will be discussed in that context. 388 Nevertheless, the description in [13] will remain definitive. 390 * The the v4.1 attribute set-mode-masked attribute is mentioned 391 together with the other attributes implementing the POSIX 392 authorization model. 394 Because this attribute. while related to security, does not 395 substantively modify the security properties of the protocol, the 396 full description of this attribute, will continue to be the 397 province of the v4.1 specification proper. 399 * There is a brief description of the v4.2 Labelled NFS feature in 400 Section 8. Part of that description discusses the limitations in 401 the desciption of that feature within [10]. 403 Because of some limitations in the desription, it is not possible 404 to provide an appropriate security considerations section for that 405 feature in this document. 407 As a result, the responsibility to provide an apprpriate Security 408 Considerations section remains, unrealized for now, with the 409 NFSv4.2 specification document. 411 3.3. Transport-based Security Features 413 There are a number of security-related facilities that can be 414 provided at the transport layer eliminating the need for or or 415 proving support to processing done as part of RPC proper. 417 These will initially be provided by RPC-over-TLS but similar 418 facilties might be provided on new versions of existing transports or 419 new RPC transports. 421 * The transport might provide encryption of requests and replies, 422 eliminating the need for privacy and integrity services to be 423 negotiated later and applied on a per-request basis. 425 While clients might chooose to establish connections with such 426 encryption, servers can establish policies allowing access to 427 certain pieces of the namespace using such transports, or limiting 428 access to those providing privacy, allowing the use of either 429 transport-based encryption or privacy servicies provided by 430 RPCSEC_GSS. 432 * The transport might provide mutual authentication of the client 433 and server peers as part of the establishment of the connection 434 This authentication is distinct from the the mutual authentication 435 of the client user and server peer, implemented within the 436 GSSSEC_RPC framework. 438 This form of authentication is of particular importance when the 439 when the server allows the use of the flavors AUTH_SYS and 440 AUTH_NONE, which have no provision for the authentication of the 441 user requesting the operation. 443 While clients might chooose to establish connections with such 444 peer authentication, servers can establish policies a limiting 445 access to certain pieces of the namespace without such peer 446 authentication or only allowing it using RPCSEC_GSS. 448 To enable server policies to be effectively communicated to clients, 449 the seurity negotiation framework now allows connection chacteristics 450 to be specified using pseudo-flavors. See Section 12 for details. 452 4. Authorization in General 454 There are three distinct methods of checking whether NFSv4 requests 455 are authorized: 457 * The most important method of authorization is used to effect user- 458 based file access control, as described in Section 5. 460 This requires the identification of the user making the request. 461 Because of the central role of such access control in providing 462 NFSv4 security, server implementations SHOULD NOT use such 463 identifications when they are not authenticated. In this context, 464 valid reasons to do otherwise are limited to the compatibility and 465 maturity issues discussed in Section 13.1.3 467 * NFSv4.2, via the labelled NFS feature, provides an additional 468 potential requirement for request authorization. 470 For reasons made clear in Section 8, there is no realistic 471 possibility of the server using the data defined by existing 472 specifications of this feature to effect request authorization. 473 While it is possible for clients to provide this authorization, 474 the lack of detailed specfication makes it impossible to determine 475 the nature of the identification used and whether it can be 476 described as "authentication". 478 * Since undesired changes to server-mintained locking state (and, 479 for NFSv4.1, session state) can result in denial of service 480 attacks (see Section 13.6), server implementations SHOULD take 481 steps to prevent unauthorized state changes. This can be done by 482 implementing the state authorization restrictions discussed in 483 Section 9 485 5. User-based File Access Authorization 487 5.1. Handling of Multiple Parallel File Access Authorization Models 489 ACLs and modes represent two well-established models for specifying 490 user-based file access permissions. NFSv4 provides support for 491 either or both depending on the attributes supported by the server: 493 * When the attributes mode, owner, owner group are all supported, 494 the posix-based authorization model, described in Section 5.3 can 495 be used. 497 * When the acl (or dacl) attribute is supported, the acl based 498 authorization model, described in Section 5.4 can be used. 500 [Working group discussion needed]: Existing specifications neither 501 require that owner and owner group be supported nor provide useful 502 guidance about how clients might deal with servers that support 503 the acl attribute but do not support owner or owner_group (e.g how 504 such a server might deal with acl containing "OWNER@" or 505 "GROUP@"). In addition, the use of acl's to generate a 506 corresponding mode seems poinless in the absence of the owner and 507 owner-group attributes. 509 [Working group decision needed]: It apppears that, despite what 510 RFC7530 and RFC8881 say, owner and owner_group are essentially 511 REQUIRED attributes, but while our successor RFC will update both 512 RFC7530 and RFC8881, that document may not be the place to rectify 513 that mistake. I'm thinking of something like the following: 515 While formally Recommended (essentialy OPTIONAL) attributes, it 516 appears that the owner and owner_group attributes need to be 517 available to support any file access authorization model. As a 518 result, this document will not discuss th possibility of 519 attributes that do not support either of these attributes. 521 * When both authorization models can be used, there are difficulties 522 that can arise because the ACL-base model provides finer-grained 523 access control than the POSIX model. Some goals for dealing with 524 these difficulties appear later in this section while more detail 525 on the appropriate handlin of this situation, which may depend on 526 the minor version used, appears in Section 7. 528 The following lists the goals of NFSv4 in supporting multiple 529 authorization models for file access. 531 * If a server supports the mode attribute, it should provide the 532 appropriate POSIX semantics to clients that only set and retrieve 533 the mode attribute. 535 [WG Discussion might be needed]: The above substitutes for the 536 requirement that the server provide "reasonable semantics". Are 537 there suggestions for other approaches to this passage? 539 * If a server supports ACL attributes, it should provide reasonable 540 semantics to clients that only set and retrieve those attributes. 542 [WG Discussion might be needed]: Similarly we need a replacement 543 for "reasonable semantics". I'm supposing "the semantics 544 described in this document" is a reasonable replacement. 546 * On servers that support the mode attribute, if ACL attributes have 547 never been set on an object, via inheritance or explicitly, the 548 behavior should be the behavior mandated by POSIX. 550 * On servers that support the mode attribute, if the ACL attributes 551 have been previously set on an object, either explicitly or via 552 inheritance: 554 - Setting only the mode attribute should effectively control the 555 traditional UNIX-like permissions of read, write, and execute 556 on owner, owner_group, and other. 558 [Working group discussion needed]: It isn't really clear what 559 the above paragraph means, especially as it governs the 560 handling of aces designating specific users and groups which 561 are not the owner and have no overlap with the owning 563 While it would be possible to substitute a three-ace acl with 564 one ace for each of owner, group and others, I'm not sure that 565 is what is intened. In particular, I'm unsure why would need a 566 second bullet item if we had a clear statement to that effect. 568 It is particularly important to resolve this now, since this is 569 part of the goals that apply to all minor versions. 571 - Setting only the mode attribute should provide reasonable 572 security. For example, setting a mode of 000 should be enough 573 to ensure that future OPEN operations for 574 OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any 575 principal fail, regardless of a previously existing or 576 inherited ACL. 578 [Working group discussion needed]: We need some replacement for 579 the subjective first sentence. While the specfic example give 580 is unexceptionable, it raises question about other case in 581 which what constitutes "reasonable semantics" might subect to 582 dispute. 584 * NFSv4.1 describes specfic semantic requirements relating to the 585 interaction of mode and ACL attributes, which do contract the 586 goals listed above. As a result, the handling provided by servers 587 of different minor version might well be different, as discussed 588 below. 590 In regard to the interaction of the mode and ACL attributes: 592 * As discussed in Section 7.1, the specfic semanric requirements 593 specified for v4.1 could be adopted by v4.0, although some 594 modification might be necessary to deal with the absence of the 595 mode_set_masked attribute. 597 V4.0 clients would have to be able to interact with servers that 598 different approaches to these goals. 600 * V4.1 servers have specfic rules for handling these issues as 601 discussed in Section 7.2. However, despite this, the rules are, 602 in many places, fairly loosely drawn and allow a range of server 603 behaviors. 605 * To deal with issues related to the perceived overuse of modes 606 derived from the umask in vitiating needed acl inheritance, a V4.2 607 extension was provided, allowing the separation of the 608 application-specfed mode from the umask. This is discussed in 609 Section 7.3 611 5.2. Attributes for User-based File Access Authorization 613 NFSv4.1 provides for multiple authentication models, controlled by 614 the support for particular Recommended attributes implemented by the 615 server, as discussed below: 617 * The attributes owner, owning_group, and mode enable use of a 618 POSIX-based authorization model, as described in Section 5.3. 619 When all of these attributes are supported, this authorization 620 model can be implemented. When none of these attributes or only a 621 proper subset of them are supported, this attribute model is 622 unavailable. 624 * The acl attribute (or the attributes sacl and dacl in v4.1) 625 provide an ACL-based authorization model as described in 626 Section 5.4. 628 5.3. Posix Authorization Model 630 5.3.1. Attribute 33: mode 632 The NFSv4.1 mode attribute is based on the UNIX mode bits. The 633 following bits are defined: 635 const MODE4_SUID = 0x800; /* set user id on execution */ 636 const MODE4_SGID = 0x400; /* set group id on execution */ 637 const MODE4_SVTX = 0x200; /* save text even after use */ 638 const MODE4_RUSR = 0x100; /* read permission: owner */ 639 const MODE4_WUSR = 0x080; /* write permission: owner */ 640 const MODE4_XUSR = 0x040; /* execute permission: owner */ 641 const MODE4_RGRP = 0x020; /* read permission: group */ 642 const MODE4_WGRP = 0x010; /* write permission: group */ 643 const MODE4_XGRP = 0x008; /* execute permission: group */ 644 const MODE4_ROTH = 0x004; /* read permission: other */ 645 const MODE4_WOTH = 0x002; /* write permission: other */ 646 const MODE4_XOTH = 0x001; /* execute permission: other */ 648 Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal 649 identified in the owner attribute. Bits MODE4_RGRP, MODE4_WGRP, and 650 MODE4_XGRP apply to principals identified in the owner_group 651 attribute but who are not identified in the owner attribute. Bits 652 MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH apply to any principal that 653 does not match that in the owner attribute and does not have a group 654 matching that of the owner_group attribute. 656 Bits within a mode other than those specified above are not defined 657 by this protocol. A server MUST NOT return bits other than those 658 defined above in a GETATTR or READDIR operation, and it MUST return 659 NFS4ERR_INVAL if bits other than those defined above are set in a 660 SETATTR, CREATE, OPEN, VERIFY, or NVERIFY operation. 662 [Working group input needed]: It is my impression that the three 663 high-order bits do not affect server behavior. Is this so? If it 664 is, should that be stated explicitly? I there a need to more clearly 665 define what the client does with these or is this somehow out of 666 scope. 668 5.3.2. V4.1 Attribute 74: mode_set_masked 670 The mode_set_masked attribute is a write-only attribute that allows 671 individual bits in the mode attribute to be set or reset, without 672 changing others. It allows, for example, the bits MODE4_SUID, 673 MODE4_SGID, and MODE4_SVTX to be modified while leaving unmodified 674 any of the nine low-order mode bits devoted to permissions. 676 In instances such that none of the nine low-order bits are subject to 677 modification, then neither the acl nor the dacl attribute should be 678 automatically modified as discussed in Sections 7.2.4 and 7.2.6. 680 The mode_set_masked attribute consists of two words, each in the form 681 of a mode4. The first consists of the value to be applied to the 682 current mode value and the second is a mask. Only bits set to one in 683 the mask word are changed (set or reset) in the file's mode. All 684 other bits in the mode remain unchanged. Bits in the first word that 685 correspond to bits that are zero in the mask are ignored, except that 686 undefined bits are checked for validity and can result in 687 NFS4ERR_INVAL as described below. 689 The mode_set_masked attribute is only valid in a SETATTR operation. 690 If it is used in a CREATE or OPEN operation, the server MUST return 691 NFS4ERR_INVAL. 693 Bits not defined as valid in the mode attribute are not valid in 694 either word of the mode_set_masked attribute. The server MUST return 695 NFS4ERR_INVAL if any such bits are set to one in a SETATTR. If the 696 mode and mode_set_masked attributes are both specified in the same 697 SETATTR, the server MUST also return NFS4ERR_INVAL. 699 5.4. ACL-based Authorization Model 701 5.4.1. Access control Entries 703 The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each 704 contain an array of Access Control Entries (ACEs) that are associated 705 with the file system object. The client can set and get these 706 attributes attribute, the server is responsible for using the ACL- 707 related attributes to perform access control. The client can use the 708 OPEN or ACCESS operations to check access without modifying or 709 expliitly reading data or metadata. 711 The NFS ACE structure is defined as follows: 713 typedef uint32_t acetype4; 715 typedef uint32_t aceflag4; 717 typedef uint32_t acemask4; 719 struct nfsace4 { 720 acetype4 type; 721 aceflag4 flag; 722 acemask4 access_mask; 723 utf8str_mixed who; 724 }; 726 To determine if a request succeeds, the server processes each nfsace4 727 entry in turnn as ordered in the array. Only ACEs that have a "who" 728 that matches the requester are considered. An ACE is consider to 729 match a given requester if at least one of the following is true: 731 * The "who' designates a specific user which is the specfic user 732 making the request. 734 * The "who" specfies "OWNER@" and the user making the request is the 735 owner of the file. 737 * The "who" designates a specific group and which is the specfic 738 user making the request is a member of that group. 740 * The "who" specfies "GROUP@" and the user making the request is a 741 member of the group owning the file. 743 * The "who" specfies "EVRYONE@". 745 * The "who" specfies "INTERACTIVE@", "NETWORK@", "DIALUP@", 746 "BATCH@", or "SERVICE@" and the requester, in the judgement of the 747 server, feels that designation appropriately describes the 748 requester. 750 * The "who" specifies "ANONYMOUS@" or "AUTHENTICATED@" and the 751 requestores authenication status matches the who, using the 752 definitions in Section 5.4.8 754 Each ACE is processed until all of the bits of the requester's access 755 have been ALLOWED. Once a bit (see below) has been ALLOWED by an 756 ACCESS_ALLOWED_ACE, it is no longer considered in the processing of 757 later ACEs. If an ACCESS_DENIED_ACE is encountered where the 758 requester's access still has unALLOWED bits in common with the 759 "access_mask" of the ACE, the request is denied. When the ACL is 760 fully processed, if there are bits in the requester's mask that have 761 not been ALLOWED or DENIED, access is denied. 763 Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do 764 not affect a requester's access, and instead are for triggering 765 events as a result of a requester's access attempt. Therefore, AUDIT 766 and ALARM ACEs are processed only after processing ALLOW and DENY 767 ACEs. 769 The NFSv4.1 ACL model is quite rich. Some server platforms may 770 provide access-control functionality that goes beyond the UNIX-style 771 mode attribute, but that is not as rich as the NFS ACL model. So 772 that users can take advantage of this more limited functionality, the 773 server may support the acl attributes by mapping between its ACL 774 model and the NFSv4.1 ACL model. Servers must ensure that the ACL 775 they actually store or enforce is at least as strict as the NFSv4 ACL 776 that was set. It is tempting to accomplish this by rejecting any ACL 777 that falls outside the small set that can be represented accurately. 778 However, such an approach can render ACLs unusable without special 779 client-side knowledge of the server's mapping, which defeats the 780 purpose of having a common NFSv4 ACL protocol. Therefore, servers 781 should accept every ACL that they can without compromising security. 782 To help accomplish this, servers may make a special exception, in the 783 case of unsupported permission bits, to the rule that bits not 784 ALLOWED or DENIED by an ACL must be denied. For example, a UNIX- 785 style server might choose to silently allow read attribute 786 permissions even though an ACL does not explicitly allow those 787 permissions. (An ACL that explicitly denies permission to read 788 attributes should still be rejected.) 790 The situation is complicated by the fact that a server may have 791 multiple modules that enforce ACLs. For example, the enforcement for 792 NFSv4.1 access may be different from, but not weaker than, the 793 enforcement for local access, and both may be different from the 794 enforcement for access through other protocols such as SMB (Server 795 Message Block). So it may be useful for a server to accept an ACL 796 even if not all of its modules are able to support it. 798 The guiding principle with regard to NFSv4 access is that the server 799 must not accept ACLs that appear to make access to the file more 800 restrictive than it really is. 802 5.4.2. ACE Type 804 The constants used for the type field (acetype4) are as follows: 806 const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; 807 const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; 808 const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; 809 const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; 811 Only the ALLOWED and DENIED bits may be used in the dacl attribute, 812 and only the AUDIT and ALARM bits may be used in the sacl attribute. 813 All four are permitted in the acl attribute. 815 +==============================+==============+=====================+ 816 | Value | Abbreviation | Description | 817 +==============================+==============+=====================+ 818 | ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW | Explicitly grants | 819 | | | the access | 820 | | | defined in | 821 | | | acemask4 to the | 822 | | | file or | 823 | | | directory. | 824 +------------------------------+--------------+---------------------+ 825 | ACE4_ACCESS_DENIED_ACE_TYPE | DENY | Explicitly denies | 826 | | | the access | 827 | | | defined in | 828 | | | acemask4 to the | 829 | | | file or | 830 | | | directory. | 831 +------------------------------+--------------+---------------------+ 832 | ACE4_SYSTEM_AUDIT_ACE_TYPE | AUDIT | Log (in a system- | 833 | | | dependent way) | 834 | | | any access | 835 | | | attempt to a file | 836 | | | or directory that | 837 | | | uses any of the | 838 | | | access methods | 839 | | | specified in | 840 | | | acemask4. | 841 +------------------------------+--------------+---------------------+ 842 | ACE4_SYSTEM_ALARM_ACE_TYPE | ALARM | Generate an alarm | 843 | | | (in a system- | 844 | | | dependent way) | 845 | | | when any access | 846 | | | attempt is made | 847 | | | to a file or | 848 | | | directory for the | 849 | | | access methods | 850 | | | specified in | 851 | | | acemask4. | 852 +------------------------------+--------------+---------------------+ 854 Table 1 856 The "Abbreviation" column denotes how the types will be referred to 857 throughout the rest of this section. 859 5.4.3. ACE Access Mask 861 The bitmask constants used for the access mask field are as follows: 863 const ACE4_READ_DATA = 0x00000001; 864 const ACE4_LIST_DIRECTORY = 0x00000001; 865 const ACE4_WRITE_DATA = 0x00000002; 866 const ACE4_ADD_FILE = 0x00000002; 867 const ACE4_APPEND_DATA = 0x00000004; 868 const ACE4_ADD_SUBDIRECTORY = 0x00000004; 869 const ACE4_READ_NAMED_ATTRS = 0x00000008; 870 const ACE4_WRITE_NAMED_ATTRS = 0x00000010; 871 const ACE4_EXECUTE = 0x00000020; 872 const ACE4_DELETE_CHILD = 0x00000040; 873 const ACE4_READ_ATTRIBUTES = 0x00000080; 874 const ACE4_WRITE_ATTRIBUTES = 0x00000100; 875 const ACE4_WRITE_RETENTION = 0x00000200; 876 const ACE4_WRITE_RETENTION_HOLD = 0x00000400; 878 const ACE4_DELETE = 0x00010000; 879 const ACE4_READ_ACL = 0x00020000; 880 const ACE4_WRITE_ACL = 0x00040000; 881 const ACE4_WRITE_OWNER = 0x00080000; 882 const ACE4_SYNCHRONIZE = 0x00100000; 884 Note that some masks have coincident values, for example, 885 ACE4_READ_DATA and ACE4_LIST_DIRECTORY. The mask entries 886 ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are 887 intended to be used with directory objects, while ACE4_READ_DATA, 888 ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with 889 non-directory objects. 891 5.4.4. Details Regarding Mask Bits 893 ACE4_READ_DATA 895 Operation(s) affected: 896 READ 898 OPEN 900 Discussion: 901 Permission to read the data of the file. 903 Servers SHOULD allow a user the ability to read the data of the 904 file when only the ACE4_EXECUTE access mask bit is allowed. 906 ACE4_LIST_DIRECTORY 908 Operation(s) affected: 909 READDIR 911 Discussion: 912 Permission to list the contents of a directory. 914 ACE4_WRITE_DATA 916 Operation(s) affected: 917 WRITE 919 OPEN 921 SETATTR of size 923 Discussion: 924 Permission to modify a file's data. 926 ACE4_ADD_FILE 928 Operation(s) affected: 929 CREATE 931 LINK 933 OPEN 935 RENAME 937 Discussion: 938 Permission to add a new file in a directory. The CREATE 939 operation is affected when nfs_ftype4 is NF4LNK, NF4BLK, 940 NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not listed because it 941 is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected when 942 used to create a regular file. LINK and RENAME are always 943 affected. 945 ACE4_APPEND_DATA 947 Operation(s) affected: 948 WRITE 950 OPEN 952 SETATTR of size 954 Discussion: 955 The ability to modify a file's data, but only starting at EOF. 956 This allows for the specfication of append-only files, by 957 allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the 958 same user or group. If a file has an ACL such as the one 959 described above and a WRITE request is made for somewhere other 960 than EOF, the server SHOULD return NFS4ERR_ACCESS. 962 ACE4_ADD_SUBDIRECTORY 964 Operation(s) affected: 965 CREATE 967 RENAME 969 Discussion: 970 Permission to create a subdirectory in a directory. The CREATE 971 operation is affected when nfs_ftype4 is NF4DIR. The RENAME 972 operation is always affected. 974 ACE4_READ_NAMED_ATTRS 976 Operation(s) affected: 977 OPENATTR 979 Discussion: 980 Permission to read the named attributes of a file or to look up 981 the named attribute directory. OPENATTR is affected when it is 982 not used to create a named attribute directory. This is when 983 1) createdir is TRUE, but a named attribute directory already 984 exists, or 2) createdir is FALSE. 986 ACE4_WRITE_NAMED_ATTRS 988 Operation(s) affected: 989 OPENATTR 991 Discussion: 992 Permission to write the named attributes of a file or to create 993 a named attribute directory. OPENATTR is affected when it is 994 used to create a named attribute directory. This is when 995 createdir is TRUE and no named attribute directory exists. The 996 ability to check whether or not a named attribute directory 997 exists depends on the ability to look it up; therefore, users 998 also need the ACE4_READ_NAMED_ATTRS permission in order to 999 create a named attribute directory. 1001 ACE4_EXECUTE 1002 Operation(s) affected: 1003 READ 1005 OPEN 1007 REMOVE 1009 RENAME 1011 LINK 1013 CREATE 1015 Discussion: 1016 Permission to execute a file. 1018 Servers SHOULD allow a user the ability to read the data of the 1019 file when only the ACE4_EXECUTE access mask bit is allowed. 1020 This is because there is no way to execute a file without 1021 reading the contents. Though a server may treat ACE4_EXECUTE 1022 and ACE4_READ_DATA bits identically when deciding to permit a 1023 READ operation, it SHOULD still allow the two bits to be set 1024 independently in ACLs, and MUST distinguish between them when 1025 replying to ACCESS operations. In particular, servers SHOULD 1026 NOT silently turn on one of the two bits when the other is set, 1027 as that would make it impossible for the client to correctly 1028 enforce the distinction between read and execute permissions. 1030 As an example, following a SETATTR of the following ACL: 1032 nfsuser:ACE4_EXECUTE:ALLOW 1034 A subsequent GETATTR of ACL for that file SHOULD return: 1036 nfsuser:ACE4_EXECUTE:ALLOW 1038 Rather than: 1040 nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW 1042 ACE4_EXECUTE 1044 Operation(s) affected: 1045 LOOKUP 1047 Discussion: 1048 Permission to traverse/search a directory. 1050 ACE4_DELETE_CHILD 1052 Operation(s) affected: 1053 REMOVE 1055 RENAME 1057 Discussion: 1058 Permission to delete a file or directory within a directory. 1059 See Section 5.4.5 for information on ACE4_DELETE and 1060 ACE4_DELETE_CHILD interact. 1062 ACE4_READ_ATTRIBUTES 1064 Operation(s) affected: 1065 GETATTR of file system object attributes 1067 VERIFY 1069 NVERIFY 1071 READDIR 1073 Discussion: 1074 The ability to read basic attributes (non-ACLs) of a file. On 1075 a UNIX system, basic attributes can be thought of as the stat- 1076 level attributes. Allowing this access mask bit would mean 1077 that the entity can execute "ls -l" and stat. If a READDIR 1078 operation requests attributes, this mask must be allowed for 1079 the READDIR to succeed. 1081 ACE4_WRITE_ATTRIBUTES 1083 Operation(s) affected: 1084 SETATTR of time_access_set, time_backup, 1086 time_create, time_modify_set, mimetype, hidden, system 1088 Discussion: 1089 Permission to change the times associated with a file or 1090 directory to an arbitrary value. Also permission to change the 1091 mimetype, hidden, and system attributes. A user having 1092 ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set 1093 the times associated with a file to the current server time. 1095 ACE4_WRITE_RETENTION 1096 Operation(s) affected: 1097 SETATTR of retention_set, retentevt_set. 1099 Discussion: 1100 Permission to modify the durations of event and non-event-based 1101 retention. Also permission to enable event and non-event-based 1102 retention. A server MAY behave such that setting 1103 ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION. 1105 ACE4_WRITE_RETENTION_HOLD 1107 Operation(s) affected: 1108 SETATTR of retention_hold. 1110 Discussion: 1111 Permission to modify the administration retention holds. A 1112 server MAY map ACE4_WRITE_ATTRIBUTES to 1113 ACE_WRITE_RETENTION_HOLD. 1115 ACE4_DELETE 1117 Operation(s) affected: 1118 REMOVE 1120 Discussion: 1121 Permission to delete the filexs or directory. See 1122 Section 5.4.5 for information on ACE4_DELETE and 1123 ACE4_DELETE_CHILD interact. 1125 ACE4_READ_ACL 1127 Operation(s) affected: 1128 GETATTR of acl, dacl, or sacl 1130 NVERIFY 1132 VERIFY 1134 Discussion: 1135 Permission to read the ACL. 1137 ACE4_WRITE_ACL 1139 Operation(s) affected: 1140 SETATTR of acl and mode 1142 Discussion: 1143 Permission to write the acl and mode attributes. 1145 ACE4_WRITE_OWNER 1147 Operation(s) affected: 1148 SETATTR of owner and owner_group 1150 Discussion: 1151 Permission to write the owner and owner_group attributes. On 1152 UNIX systems, this is the ability to execute chown() and 1153 chgrp(). 1155 ACE4_SYNCHRONIZE 1157 Operation(s) affected: 1158 NONE 1160 Discussion: 1161 Permission to use the file object as a synchronization 1162 primitive for interprocess communication. This permission is 1163 not enforced or interpreted by the NFSv4.1 server on behalf of 1164 the client. 1166 Typically, the ACE4_SYNCHRONIZE permission is only meaningful 1167 on local file systems, i.e., file systems not accessed via 1168 NFSv4.1. The reason that the permission bit exists is that 1169 some operating environments, such as Windows, use 1170 ACE4_SYNCHRONIZE. 1172 For example, if a client copies a file that has 1173 ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1 1174 server, and then later copies the file from the NFSv4.1 server 1175 to a local file system, it is likely that if ACE4_SYNCHRONIZE 1176 was set in the original file, the client will want it set in 1177 the second copy. The first copy will not have the permission 1178 set unless the NFSv4.1 server has the means to set the 1179 ACE4_SYNCHRONIZE bit. The second copy will not have the 1180 permission set unless the NFSv4.1 server has the means to 1181 retrieve the ACE4_SYNCHRONIZE bit. 1183 Server implementations need not provide the granularity of control 1184 that is implied by this list of masks. For example, POSIX-based 1185 systems might not distinguish ACE4_APPEND_DATA (the ability to append 1186 to a file) from ACE4_WRITE_DATA (the ability to modify existing 1187 contents); both masks would be tied to a single "write" permission 1188 bit. When such a server returns attributes to the client that 1189 contain such masks, it would show ACE4_APPEND_DATA and 1190 ACE4_WRITE_DATA if and only if the the write permission bit is 1191 enabled. 1193 If a server receives a SETATTR request that it cannot accurately 1194 implement, it should err in the direction of more restricted access, 1195 except in the previously discussed cases of execute and read. For 1196 example, suppose a server cannot distinguish overwriting data from 1197 appending new data, as described in the previous paragraph. If a 1198 client submits an ALLOW ACE where ACE4_APPEND_DATA is set but 1199 ACE4_WRITE_DATA is not (or vice versa), the server should either turn 1200 off ACE4_APPEND_DATA or reject the request with NFS4ERR_ATTRNOTSUPP. 1202 5.4.5. ACE4_DELETE vs. ACE4_DELETE_CHILD 1204 Two access mask bits govern the ability to delete a directory entry: 1205 ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD 1206 on the containing directory (the "parent"). 1208 Many systems also take the "sticky bit" (MODE4_SVTX) on a directory 1209 to allow unlink only to a user that owns either the target or the 1210 parent; on some such systems the decision also depends on whether the 1211 target is writable. 1213 Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the 1214 target, or ACE4_DELETE_CHILD is permitted on the parent. (Note that 1215 this is true even if the parent or target explicitly denies one of 1216 these permissions.) 1218 If the ACLs in question neither explicitly ALLOW nor DENY either of 1219 the above, and if MODE4_SVTX is not set on the parent, then the 1220 server SHOULD allow the removal if and only if ACE4_ADD_FILE is 1221 permitted. In the case where MODE4_SVTX is set, the server may also 1222 require the remover to own either the parent or the target, or may 1223 require the target to be writable. 1225 This allows servers to support something close to traditional UNIX- 1226 like semantics, with ACE4_ADD_FILE taking the place of the write bit. 1228 5.4.6. ACE flag 1230 The bitmask constants used for the flag field are as follows: 1232 const ACE4_FILE_INHERIT_ACE = 0x00000001; 1233 const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; 1234 const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; 1235 const ACE4_INHERIT_ONLY_ACE = 0x00000008; 1236 const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; 1237 const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; 1238 const ACE4_IDENTIFIER_GROUP = 0x00000040; 1239 const ACE4_INHERITED_ACE = 0x00000080; 1240 A server need not support any of these flags. If the server supports 1241 flags that are similar to, but not exactly the same as, these flags, 1242 the implementation may define a mapping between the protocol-defined 1243 flags and the implementation-defined flags. 1245 For example, suppose a client tries to set an ACE with 1246 ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE. If the 1247 server does not support any form of ACL inheritance, the server 1248 should reject the request with NFS4ERR_ATTRNOTSUPP. If the server 1249 supports a single "inherit ACE" flag that applies to both files and 1250 directories, the server may reject the request (i.e., requiring the 1251 client to set both the file and directory inheritance flags). The 1252 server may also accept the request and silently turn on the 1253 ACE4_DIRECTORY_INHERIT_ACE flag. 1255 5.4.7. Details Regardign ACE Flag Bits 1257 ACE4_FILE_INHERIT_ACE 1258 Any non-directory file in any sub-directory will get this ACE 1259 inherited. 1261 ACE4_DIRECTORY_INHERIT_ACE 1262 Can be placed on a directory and indicates that this ACE should be 1263 added to each new directory created. 1265 If this flag is set in an ACE in an ACL attribute to be set on a 1266 non-directory file system object, the operation attempting to set 1267 the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP. 1269 ACE4_NO_PROPAGATE_INHERIT_ACE 1270 Can be placed on a directory. This flag tells the server that 1271 inheritance of this ACE should stop at newly created child 1272 directories. 1274 ACE4_INHERIT_ONLY_ACE 1275 Can be placed on a directory but does not apply to the directory; 1276 ALLOW and DENY ACEs with this bit set do not affect access to the 1277 directory, and AUDIT and ALARM ACEs with this bit set do not 1278 trigger log or alarm events. Such ACEs only take effect once they 1279 are applied (with this bit cleared) to newly created files and 1280 directories as specified by the ACE4_FILE_INHERIT_ACE and 1281 ACE4_DIRECTORY_INHERIT_ACE flags. 1283 If this flag is present on an ACE, but neither 1284 ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present, 1285 then an operation attempting to set such an attribute SHOULD fail 1286 with NFS4ERR_ATTRNOTSUPP. 1288 ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG 1289 The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and 1290 ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on 1291 ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE 1292 (ALARM) ACE types. If during the processing of the file's ACL, 1293 the server encounters an AUDIT or ALARM ACE that matches the 1294 principal attempting the OPEN, the server notes that fact, and the 1295 presence, if any, of the SUCCESS and FAILED flags encountered in 1296 the AUDIT or ALARM ACE. Once the server completes the ACL 1297 processing, it then notes if the operation succeeded or failed. 1298 If the operation succeeded, and if the SUCCESS flag was set for a 1299 matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM 1300 event occurs. If the operation failed, and if the FAILED flag was 1301 set for the matching AUDIT or ALARM ACE, then the appropriate 1302 AUDIT or ALARM event occurs. Either or both of the SUCCESS or 1303 FAILED can be set, but if neither is set, the AUDIT or ALARM ACE 1304 is not useful. 1306 The previously described processing applies to ACCESS operations 1307 even when they return NFS4_OK. For the purposes of AUDIT and 1308 ALARM, we consider an ACCESS operation to be a "failure" if it 1309 fails to return a bit that was requested and supported. 1311 ACE4_IDENTIFIER_GROUP 1312 Indicates that the "who" refers to a GROUP as defined under UNIX 1313 or a GROUP ACCOUNT as defined under Windows. Clients and servers 1314 MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who 1315 value equal to one of the special identifiers outlined in 1316 Section 5.4.8. 1318 ACE4_INHERITED_ACE 1319 Indicates that this ACE is inherited from a parent directory. A 1320 server that supports automatic inheritance will place this flag on 1321 any ACEs inherited from the parent directory when creating a new 1322 object. Client applications will use this to perform automatic 1323 inheritance. Clients and servers MUST clear this bit in the acl 1324 attribute; it may only be used in the dacl and sacl attributes. 1326 5.4.8. ACE Who 1328 The "who" field of an ACE is an identifier that specifies the 1329 principal or principals to whom the ACE applies. It may refer to a 1330 user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying 1331 which. 1333 There are several special identifiers that need to be understood 1334 universally, rather than in the context of a particular DNS domain. 1335 Some of these identifiers cannot be understood when an NFS client 1336 accesses the server, but have meaning when a local process accesses 1337 the file. The ability to display and modify these permissions is 1338 permitted over NFS, even if none of the access methods on the server 1339 understands the identifiers. 1341 +===============+==================================================+ 1342 | Who | Description | 1343 +===============+==================================================+ 1344 | OWNER | The owner of the file. | 1345 +---------------+--------------------------------------------------+ 1346 | GROUP | The group associated with the file. | 1347 +---------------+--------------------------------------------------+ 1348 | EVERYONE | The world, including the owner and owning group. | 1349 +---------------+--------------------------------------------------+ 1350 | INTERACTIVE | Accessed from an interactive terminal. | 1351 +---------------+--------------------------------------------------+ 1352 | NETWORK | Accessed via the network. | 1353 +---------------+--------------------------------------------------+ 1354 | DIALUP | Accessed as a dialup user to the server. | 1355 +---------------+--------------------------------------------------+ 1356 | BATCH | Accessed from a batch job. | 1357 +---------------+--------------------------------------------------+ 1358 | ANONYMOUS | Accessed without any authentication. | 1359 +---------------+--------------------------------------------------+ 1360 | AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS). | 1361 +---------------+--------------------------------------------------+ 1362 | SERVICE | Access from a system service. | 1363 +---------------+--------------------------------------------------+ 1365 Table 2 1367 To avoid conflict, these special identifiers are distinguished by an 1368 appended "@" and should appear in the form "xxxx@" (with no domain 1369 name after the "@"), for example, ANONYMOUS@. 1371 The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these 1372 special identifiers. When encoding entries with these special 1373 identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero. 1375 [working group input needed]: I don't understand what might be valid 1376 reasons to ignore this. Would "MUST" be appropriate here? 1378 It is important to note that "EVERYONE@" is not equivalent to the 1379 UNIX "other" entity. This is because, by definition, UNIX "other" 1380 does not include the owner or owning group of a file. "EVERYONE@" 1381 means literally everyone, including the owner or owning group. 1383 [working group input needed]: Some of these require that changes be 1384 made as discussed below: 1386 * For "INTERACTIVE", "NETWORK", "DIALUP", "BATCH", and "SERVICE" it 1387 needs to be specified that server's ability to make these 1388 distinctions is limited, making teir use where secrity is an issue 1389 quite problemtic. 1391 * For "ANONYMOUS", clearly requests using AUTH_NONE fit but what 1392 else? 1394 Request by nobody and by users root-squashed to nobody are 1395 probably OK, although you could argue about the case of a user 1396 "nobody" authenticated by ROCSEC_GSS> 1398 ON a more contentious note, I would argue that users 1399 "authenticated" using AUTH_SYS, in the clear, without client-peer 1400 authentication fit here, but we need to get to consensus on this 1401 point. 1403 * Issues regarding "AUTHENTICATED" will be the mirror image of those 1404 for "ANONYMOUS". 1406 5.4.9. Automatic Inheritance Features 1408 The acl attribute consists only of an array of ACEs, but the sacl 1409 (Section 5.8) and dacl (Section 5.7) attributes also include an 1410 additional flag field. 1412 struct nfsacl41 { 1413 aclflag4 na41_flag; 1414 nfsace4 na41_aces<>; 1415 }; 1417 The flag field applies to the entire sacl or dacl; three flag values 1418 are defined: 1420 const ACL4_AUTO_INHERIT = 0x00000001; 1421 const ACL4_PROTECTED = 0x00000002; 1422 const ACL4_DEFAULTED = 0x00000004; 1424 and all other bits must be cleared. The ACE4_INHERITED_ACE flag may 1425 be set in the ACEs of the sacl or dacl (whereas it must always be 1426 cleared in the acl). 1428 Together these features allow a server to support automatic 1429 inheritance, which we now explain in more detail. 1431 Inheritable ACEs are normally inherited by child objects only at the 1432 time that the child objects are created; later modifications to 1433 inheritable ACEs do not result in modifications to inherited ACEs on 1434 descendants. 1436 However, the dacl and sacl provide an OPTIONAL mechanism that allows 1437 a client application to propagate changes to inheritable ACEs to an 1438 entire directory hierarchy. 1440 A server that supports this feature performs inheritance at object 1441 creation time in the normal way, and SHOULD set the 1442 ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to 1443 the new object. 1445 A client application such as an ACL editor may then propagate changes 1446 to inheritable ACEs on a directory by recursively traversing that 1447 directory's descendants and modifying each ACL encountered to remove 1448 any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the 1449 new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It 1450 uses the existing ACE inheritance flags in the obvious way to decide 1451 which ACEs to propagate. (Note that it may encounter further 1452 inheritable ACEs when descending the directory hierarchy and that 1453 those will also need to be taken into account when propagating 1454 inheritable ACEs to further descendants.) 1456 The reach of this propagation may be limited in two ways: first, 1457 automatic inheritance is not performed from any directory ACL that 1458 has the ACL4_AUTO_INHERIT flag cleared; and second, automatic 1459 inheritance stops wherever an ACL with the ACL4_PROTECTED flag is 1460 set, preventing modification of that ACL and also (if the ACL is set 1461 on a directory) of the ACL on any of the object's descendants. 1463 This propagation is performed independently for the sacl and the dacl 1464 attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may 1465 be independently set for the sacl and the dacl, and propagation of 1466 one type of acl may continue down a hierarchy even where propagation 1467 of the other acl has stopped. 1469 New objects should be created with a dacl and a sacl that both have 1470 the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to 1471 the same value as that on, respectively, the sacl or dacl of the 1472 parent object. 1474 Both the dacl and sacl attributes are Recommended, and a server may 1475 support one without supporting the other. 1477 A server that supports both the old acl attribute and one or both of 1478 the new dacl or sacl attributes must do so in such a way as to keep 1479 all three attributes consistent with each other. Thus, the ACEs 1480 reported in the acl attribute should be the union of the ACEs 1481 reported in the dacl and sacl attributes, except that the 1482 ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl. 1483 And of course a client that queries only the acl will be unable to 1484 determine the values of the sacl or dacl flag fields. 1486 When a client performs a SETATTR for the acl attribute, the server 1487 SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the 1488 dacl. By using the acl attribute, as opposed to the dacl or sacl 1489 attributes, the client signals that it may not understand automatic 1490 inheritance, and thus cannot be trusted to set an ACL for which 1491 automatic inheritance would make sense. 1493 When a client application queries an ACL, modifies it, and sets it 1494 again, it should leave any ACEs marked with ACE4_INHERITED_ACE 1495 unchanged, in their original order, at the end of the ACL. If the 1496 application is unable to do this, it should set the ACL4_PROTECTED 1497 flag. This behavior is not enforced by servers, but violations of 1498 this rule may lead to unexpected results when applications perform 1499 automatic inheritance. 1501 If a server also supports the mode attribute, it SHOULD set the mode 1502 in such a way that leaves inherited ACEs unchanged, in their original 1503 order, at the end of the ACL. If it is unable to do so, it SHOULD 1504 set the ACL4_PROTECTED flag on the file's dacl. 1506 Finally, in the case where the request that creates a new file or 1507 directory does not also set permissions for that file or directory, 1508 and there are also no ACEs to inherit from the parent's directory, 1509 then the server's choice of ACL for the new object is implementation- 1510 dependent. In this case, the server SHOULD set the ACL4_DEFAULTED 1511 flag on the ACL it chooses for the new object. An application 1512 performing automatic inheritance takes the ACL4_DEFAULTED flag as a 1513 sign that the ACL should be completely replaced by one generated 1514 using the automatic inheritance rules. 1516 5.5. Attribute 12: acl 1518 The acl attribute, as opposed to the sacl and dacl attributes, 1519 consists only of an ACE array and does not support automatic 1520 inheritance. 1522 The acl attribute is recommende and there is no requirement that a 1523 server support. However, when the dacl attribute is supported, it is 1524 a good idea to provide support for the acl attributes as well, in 1525 order to accommodate clients that have not been upgraded to use the 1526 dacl attribute. 1528 5.6. Attribute 13: aclsupport 1530 A server need not support all of the above ACE types. This attribute 1531 indicates which ACE types are supported for the current file system. 1532 The bitmask constants used to represent the above definitions within 1533 the aclsupport attribute are as follows: 1535 const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; 1536 const ACL4_SUPPORT_DENY_ACL = 0x00000002; 1537 const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; 1538 const ACL4_SUPPORT_ALARM_ACL = 0x00000008; 1540 Servers that support either the ALLOW or DENY ACE type SHOULD support 1541 both ALLOW and DENY ACE types. 1543 [Working group input needed]: What are the valid reasons not do this? 1545 Clients should not attempt to set an ACE unless the server claims 1546 support for that ACE type. If the server receives a request to set 1547 an ACE that it cannot store, it MUST reject the request with 1548 NFS4ERR_ATTRNOTSUPP. If the server receives a request to set an ACE 1549 that it can store but cannot enforce, the server SHOULD reject the 1550 request with NFS4ERR_ATTRNOTSUPP. 1552 [Working group input needed]: I might be mistaken but this might 1553 contradict material in Section 5.4.1 1555 Support for any of the ACL attributes is OPTIONAL, although 1556 Recommended. However, a server that supports either of the new ACL 1557 attributes (dacl or sacl) MUST allow use of the new ACL attributes to 1558 access all of the ACE types that it supports. In other words, if 1559 such a server supports ALLOW or DENY ACEs, then it MUST support the 1560 dacl attribute, and if it supports AUDIT or ALARM ACEs, then it MUST 1561 support the sacl attribute. 1563 5.7. V4.1 Attribute 58: dacl 1565 The dacl attribute is like the acl attribute, but dacl allows only 1566 ALLOW and DENY ACEs. The dacl attribute supports automatic 1567 inheritance (see Section 5.4.9). 1569 5.8. V4.1 Attribute 59: sacl 1571 The sacl attribute is like the acl attribute, but sacl allows only 1572 AUDIT and ALARM ACEs. The sacl attribute supports automatic 1573 inheritance (see Section 5.4.9). 1575 6. Common Considerations for Both File access Models 1577 [Important structural change to be noted]: This section is derived 1578 from Section 6.3 of 8881, entitled "Common Methods. However, its 1579 content is different because it has been rewritten to deal with 1580 issues common to both file access models, which now appears to have 1581 not been the original intention. Nevertheless, the following changes 1582 have been made: 1584 * The section "Server Considerations" has been revised to deal with 1585 both the mode and acl attributes, since the points being made 1586 apply, in almost all cases, to both attributes. 1588 * The section "Client Considerations" has been heavily revised, 1589 since what had been there did not make any sense to me. 1591 * The section "Computing a Mode Attribute from an ACL" has been 1592 moved to Section 7.2.1 since it deals with the co-ordination of 1593 the posix and acl authorization models. 1595 6.1. Server Considerations 1597 The server uses the mode attribute or the acl attibute applying the 1598 algorithm described in Section 5.4.1 to determine whether an ACL 1599 allows access to an object. 1601 However, these attributes might not be the sole determiner of access. 1602 For example: 1604 * In the case of a file system exported as read-only, the server 1605 will deny write access even though an object's file access 1606 attributes would grant it. 1608 * Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL 1609 permissions to prevent a situation from arising in which there is 1610 no valid way to ever modify the ACL. 1612 * All servers will allow a user the ability to read the data of the 1613 file when only the execute permission is granted (e.g., if the ACL 1614 denies the user the ACE4_READ_DATA access and allows the user 1615 ACE4_EXECUTE, the server will allow the user to read the data of 1616 the file). 1618 * Many servers implement owner-override semantics in which the owner 1619 of the object is allowed to override accesses that are denied by 1620 the ACL. This may be helpful, for example, to allow users 1621 continued access to open files on which the permissions have 1622 changed. 1624 * Many servers provide for the existence of a "superuser" that has 1625 privileges beyond an ordinary user. The superuser may be able to 1626 read or write data or metadata in ways that would not be permitted 1627 by the ACL or mode attributes. 1629 * A retention attribute might also block access otherwise allowed by 1630 ACLs (see Section 5.13 of [8]). 1632 6.2. Client Considerations 1634 Clients SHOULD NOT do their own access checks based on their 1635 interpretation of the ACL, but rather use the OPEN and ACCESS 1636 operations to do access checks. This allows the client to act on the 1637 results of having the server determine whether or not access should 1638 be granted based on its interpretation of the ACL. 1640 [Working group discussion needed]: With regard to the use of "SHOULD 1641 NOT" in the paragraph above, it is not clear what might be valid 1642 reasons to bypass this recommendation. Perhaps "MUST NOT" or "should 1643 not" would be more appropriate. 1645 Clients must be aware of situations in which an object's ACL will 1646 define a certain access even though the server will not enforce it. 1647 In general, but especially in these situations, the client needs to 1648 do its part in the enforcement of access as defined by the ACL. 1650 [Working group input needed]: Despite what is said later, the only 1651 such case I know of is the use of READ and EXECUTE where the client, 1652 but not the server, has any means of distinguishing these. don't 1653 know of any others. If there were, houw could ACESS or OPEN be used 1654 to verify access? 1656 To do this, the client MAY send the appropriate ACCESS operation 1657 prior to servicing the request of the user or application in order to 1658 determine whether the user or application should be granted the 1659 access requested. 1661 For examples in which the ACL may define accesses that the server 1662 doesn't enforce, see Section 6.1. 1664 [Working group discussion needed]: The sentence above is clearly 1665 wrong since that section is about enforcement the server does do. 1666 Sigh! 1668 7. Combining Authorization Models 1670 [To be checked]: The section on computing mode from ACL in RFC3530 is 1671 quite similar to that in RFC8881. If they are essentially identical, 1672 Section 7.2.1 could be moved out of Section 7.2 and apply to all 1673 minor versions :-). In addition, there may be additional material 1674 that could be generalized in this way. 1676 7.1. Combined Authorization Models for V4.0 1678 V4.0 servers that support both the mode and acl attributes, like 1679 servers for other minor versions, have to appropriately co-ordinate 1680 the values. Because much of the material in Section 7.2 does not 1681 apply to v4.0, the server is relatively free about how it does this. 1682 Nevertheless, that materal is one useful approach and v4.0 1683 implementers may want to consult it, even though the requirements in 1684 it do not apply and threcommendations have no normative force. 1686 One likely source of a need for different treatment is the absence of 1687 a set_mode_masked attribute in v4.0. 1689 Clients need to be aware that the v4.1 handling may nor may not be 1690 adopted by the server and that the client needs to adapt accordingly. 1692 7.2. Combined Authorization Model for V4.1 and Beyond 1694 * On servers that support both the mode and the acl or dacl 1695 attributes, the server must keep the two consistent with each 1696 other. The value of the mode attribute (with the exception of the 1697 three high-order bits described in Section 5.3.1) must be 1698 determined entirely by the value of the ACL, so that use of the 1699 mode is never required for anything other than setting the three 1700 high-order bits. See Sections 7.2.4 through 7.2.6 for detailed 1701 requirements. 1703 * When a mode attribute is set on an object, the ACL attributes may 1704 need to be modified in order to not conflict with the new mode. 1705 In such cases, it is desirable that the ACL keep as much 1706 information as possible. This includes information about 1707 inheritance, AUDIT and ALARM ACEs, and permissions granted and 1708 denied that do not conflict with the new mode. 1710 The server that supports both mode and ACL must take care to 1711 synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the 1712 ACEs that have respective who fields of "OWNER@", "GROUP@", and 1713 "EVERYONE@". This way, the client can see if semantically equivalent 1714 access permissions exist whether the client asks for the owner, 1715 owner_group, and mode attributes or for just the ACL. 1717 In this section, much depends on the method in specified 1718 Section 7.2.1. Many requirements refer to this section. It should 1719 be noted that the methods have behaviors specified with "SHOULD" and 1720 that alternate approaches are discussed in Section 7.2.2. This is 1721 intentional, to avoid invalidating existing implementations that 1722 compute the mode according to the withdrawn POSIX ACL draft (1003.1e 1723 draft 17), rather than by actual permissions on owner, group, and 1724 other. 1726 [Working group discussion needed]: Given the mixture of RFC2219 1727 terms, I think all of them in Section 7 need review. Further, given 1728 the effort that has gone into Section 7, to accommodate these 1729 implementations of a draft that was withdrawn decades ago. The idea 1730 of trying to make mode and acl match is undercut when there are 1731 different valid ways of computing the mode. There shouldn't be. To 1732 specify one way to do this is necessary to accomplish the goal here 1733 and to do so would not "invalidate" anything. Rather, it would 1734 establish, correctly, that such implementations are not 1735 implementations of the NFSv4 ACL model, but of the withdrawn POSIX 1736 ACL draft. 1738 7.2.1. Computing a Mode Attribute from an ACL 1740 The following method can be used to calculate the MODE4_R*, MODE4_W*, 1741 and MODE4_X* bits of a mode attribute, based upon an ACL. 1743 [Working group discussion needed]: "can be used" says essentially "do 1744 whatever you choose" and would make Section 7 essentially pointless. 1745 Would prefer "is to be used", "MUST", or "SHOULD" if valid reasons to 1746 do otherwise can be found. 1748 First, for each of the special identifiers OWNER@, GROUP@, and 1749 EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY 1750 ACEs for the identifier EVERYONE@ and for the identifier under 1751 consideration. The result of the evaluation will be an NFSv4 ACL 1752 mask showing exactly which bits are permitted to that identifier. 1754 Then translate the calculated mask for OWNER@, GROUP@, and EVERYONE@ 1755 into mode bits for, respectively, the user, group, and other, as 1756 follows: 1758 1. Set the read bit (MODE4_RUSR, MODE4_RGRP, or MODE4_ROTH) if and 1759 only if ACE4_READ_DATA is set in the corresponding mask. 1761 2. Set the write bit (MODE4_WUSR, MODE4_WGRP, or MODE4_WOTH) if and 1762 only if ACE4_WRITE_DATA and ACE4_APPEND_DATA are both set in the 1763 corresponding mask. 1765 3. Set the execute bit (MODE4_XUSR, MODE4_XGRP, or MODE4_XOTH), if 1766 and only if ACE4_EXECUTE is set in the corresponding mask. 1768 7.2.2. Alternatives in Computing Mode Bits 1770 Some server implementations also add bits permitted to named users 1771 and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and 1772 MODE4_XGRP). 1774 Implementations are discouraged from doing this, because it has been 1775 found to cause confusion for users who see members of a file's group 1776 denied access that the mode bits appear to allow. (The presence of 1777 DENY ACEs may also lead to such behavior, but DENY ACEs are expected 1778 to be more rarely used.) 1780 [Working group decision needed]; the text does not seem to really 1781 discourage this practice and makes no reference to the need to 1782 standardize behavior or any impediement to doing so. "SHOULD NOT" 1783 needs to be considered if valid reasons to do otherwise can be found. 1785 The same user confusion seen when fetching the mode also results if 1786 setting the mode does not effectively control permissions for the 1787 owner, group, and other users; this motivates some of the 1788 requirements that follow. 1790 7.2.3. Setting Multiple ACL Attributes 1792 In the case where a server supports the sacl or dacl attribute, in 1793 addition to the acl attribute, the server MUST fail a request to set 1794 the acl attribute simultaneously with a dacl or sacl attribute. The 1795 error to be given is NFS4ERR_ATTRNOTSUPP. 1797 7.2.4. Setting Mode and not ACL 1799 When any of the nine low-order mode bits are subject to change, 1800 either because the mode attribute was set or because the 1801 mode_set_masked attribute was set and the mask included one or more 1802 bits from the nine low-order mode bits, and no ACL attribute is 1803 explicitly set, the acl and dacl attributes must be modified in 1804 accordance with the updated value of those bits. This must happen 1805 even if the value of the low-order bits is the same after the mode is 1806 set as before. 1808 Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl 1809 attribute) are unaffected by changes to the mode. 1811 In cases in which the permissions bits are subject to change, the acl 1812 and dacl attributes MUST be modified such that the mode computed via 1813 the method in Section 7.2.1 yields the low-order nine bits (MODE4_R*, 1814 MODE4_W*, MODE4_X*) of the mode attribute as modified by the 1815 attribute change. The ACL attributes SHOULD also be modified such 1816 that: 1818 1. If MODE4_RGRP is not set, entities explicitly listed in the ACL 1819 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 1820 ACE4_READ_DATA. 1822 2. If MODE4_WGRP is not set, entities explicitly listed in the ACL 1823 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 1824 ACE4_WRITE_DATA or ACE4_APPEND_DATA. 1826 3. If MODE4_XGRP is not set, entities explicitly listed in the ACL 1827 other than OWNER@ and EVERYONE@ SHOULD NOT be granted 1828 ACE4_EXECUTE. 1830 Access mask bits other than those listed above, appearing in ALLOW 1831 ACEs, MAY also be disabled. 1833 Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect 1834 the permissions of the ACL itself, nor do ACEs of the type AUDIT and 1835 ALARM. As such, it is desirable to leave these ACEs unmodified when 1836 modifying the ACL attributes. 1838 Also note that the requirement may be met by discarding the acl and 1839 dacl, in favor of an ACL that represents the mode and only the mode. 1840 This is permitted, but it is preferable for a server to preserve as 1841 much of the ACL as possible without violating the above requirements. 1842 Discarding the ACL makes it effectively impossible for a file created 1843 with a mode attribute to inherit an ACL (see Section 7.2.8). 1845 7.2.5. Setting ACL and Not Mode 1847 When setting the acl or dacl and not setting the mode or 1848 mode_set_masked attributes, the permission bits of the mode need to 1849 be derived from the ACL. In this case, the ACL attribute SHOULD be 1850 set as given. The nine low-order bits of the mode attribute 1851 (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result 1852 of the method in Section 7.2.1. The three high-order bits of the 1853 mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged. 1855 7.2.6. Setting Both ACL and Mode 1857 When setting both the mode (includes use of either the mode attribute 1858 or the mode_set_masked attribute) and the acl or dacl attributes in 1859 the same operation, the attributes MUST be applied in this order: 1860 mode (or mode_set_masked), then ACL. The mode-related attribute is 1861 set as given, then the ACL attribute is set as given, possibly 1862 changing the final mode, as described above in Section 7.2.5. 1864 7.2.7. Retrieving the Mode and/or ACL Attributes 1866 Some server implementations may provide for the existence of "objects 1867 without ACLs", meaning that all permissions are granted and denied 1868 according to the mode attribute and that no ACL attribute is stored 1869 for that object. If an ACL attribute is requested of such a server, 1870 the server SHOULD return an ACL that does not conflict with the mode; 1871 that is to say, the ACL returned SHOULD represent the nine low-order 1872 bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as 1873 described in Section 7.2.1. 1875 For other server implementations, the ACL attribute is always present 1876 for every object. Such servers SHOULD store at least the three high- 1877 order bits of the mode attribute (MODE4_SUID, MODE4_SGID, 1878 MODE4_SVTX). The server SHOULD return a mode attribute if one is 1879 requested, and the low-order nine bits of the mode (MODE4_R*, 1880 MODE4_W*, MODE4_X*) MUST match the result of applying the method in 1881 Section 7.2.1 to the ACL attribute. 1883 7.2.8. Creating New Objects 1885 If a server supports any ACL attributes, it may use the ACL 1886 attributes on the parent directory to compute an initial ACL 1887 attribute for a newly created object. This will be referred to as 1888 the inherited ACL within this section. The act of adding one or more 1889 ACEs to the inherited ACL that are based upon ACEs in the parent 1890 directory's ACL will be referred to as inheriting an ACE within this 1891 section. 1893 Implementors should standardize the behavior of CREATE and OPEN 1894 depending on the presence or absence of the mode and ACL attributes 1895 by following the directions below: 1897 1. If just the mode is given in the call: 1899 In this case, inheritance SHOULD take place, but the mode MUST be 1900 applied to the inherited ACL as described in Section 7.2.4, 1901 thereby modifying the ACL. 1903 2. If just the ACL is given in the call: 1905 In this case, inheritance SHOULD NOT take place, and the ACL as 1906 defined in the CREATE or OPEN will be set without modification, 1907 and the mode modified as in Section 7.2.5. 1909 3. If both mode and ACL are given in the call: 1911 In this case, inheritance SHOULD NOT take place, and both 1912 attributes will be set as described in Section 7.2.6. 1914 4. If neither mode nor ACL is given in the call: 1916 In the case where an object is being created without any initial 1917 attributes at all, e.g., an OPEN operation with an opentype4 of 1918 OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD 1919 NOT take place (note that EXCLUSIVE4_1 is a better choice of 1920 createmode4, since it does permit initial attributes). Instead, 1921 the server SHOULD set permissions to deny all access to the newly 1922 created object. It is expected that the appropriate client will 1923 set the desired attributes in a subsequent SETATTR operation, and 1924 the server SHOULD allow that operation to succeed, regardless of 1925 what permissions the object is created with. For example, an 1926 empty ACL denies all permissions, but the server should allow the 1927 owner's SETATTR to succeed even though WRITE_ACL is implicitly 1928 denied. 1930 In other cases, inheritance SHOULD take place, and no 1931 modifications to the ACL will happen. The mode attribute, if 1932 supported, MUST be as computed in Section 7.2.1, with the 1933 MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no 1934 inheritable ACEs exist on the parent directory, the rules for 1935 creating acl, dacl, or sacl attributes are implementation 1936 defined. If either the dacl or sacl attribute is supported, then 1937 the ACL4_DEFAULTED flag SHOULD be set on the newly created 1938 attributes. 1940 7.2.9. Use of Inherited ACL When Creating Objects 1942 If the object being created is not a directory, the inherited ACL 1943 SHOULD NOT inherit ACEs from the parent directory ACL unless the 1944 ACE4_FILE_INHERIT_ACE flag is set. 1946 If the object being created is a directory, the inherited ACL should 1947 inherit all inheritable ACEs from the parent directory, that is, 1948 those that have the ACE4_FILE_INHERIT_ACE or 1949 ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has 1950 ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear, 1951 the inherited ACE on the newly created directory MUST have the 1952 ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being 1953 affected by ACEs meant for non-directories. 1955 When a new directory is created, the server MAY split any inherited 1956 ACE that is both inheritable and effective (in other words, that has 1957 neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set), 1958 into two ACEs, one with no inheritance flags and one with 1959 ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute, 1960 both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.) 1961 This makes it simpler to modify the effective permissions on the 1962 directory without modifying the ACE that is to be inherited to the 1963 new directory's children. 1965 7.3. Combined Authorization Models for V4.2 1967 The v4.1 server implementation requirements described in Section 7.2 1968 apply to v4.2 as well and v4.2 clients can assume that the server 1969 follows them. 1971 V4.2 contains an OPTIONAL extension, defined in [13], which is 1972 intended to reduce the interference of modes, restricted by the umask 1973 mechanism, with the acl inheritance mechanism. The extension allows 1974 the client to specify the umask separately from the mask attribute. 1976 8. Labelled NFS Authorization Model 1978 The labelled NFS feature of NFSv4.2 is designed to support Mandatory 1979 Access control. 1981 The attribute sec_label enables an authorization model focused on 1982 Mandatory Access Control and is described in Section 8. 1984 Not much can be said about this feature because the specification, in 1985 the intrest of fexibility has left important features undefined in 1986 order to alllow future. As a result, we have something that is a 1987 framework to allow Mandatory Acces Control rather than one to provide 1988 it. In particular, 1990 * The sec_label attribute, which provides the objects label has no 1991 existing specfication. 1993 * There is no specfication of the of the format of the subject label 1994 or way to authenticate them. 1996 * As a result, all authorization takes place on the client, and the 1997 server simply accepts the client's determination. 1999 This arrangements shares important similarities with AUTH_SYS. As 2000 such it makes sense: 2002 * To require/recommend that an encrypted connection be used. 2004 * To require/recommend that client and server peers mutually 2005 authenticate as part of connection establishment. 2007 * That work be devoted to providing a replacement without the above 2008 issues. 2010 9. State Modification Authorization 2012 Modification of locking and session state data should not be done by 2013 a client other than the one that created the lock. For this form of 2014 authorization, the server needs to identify and authenticate client 2015 peers rather than client users. 2017 Such authentication is not directly provided by any RPC 2018 authentication flavor. However, RPC-based transport, when sitable 2019 configured. can provide this authenication. 2021 NFSv4.1 defines a number of ways to provide appropriate authorization 2022 facilities. These will not be discussed in detail her but the 2023 follwing points should be noted: 2025 * NFSv4.1 defines the MACHCRED mechanism which uses the RPCSEC_GSS 2026 indrastrucure to provide authentication of the clients peer. 2027 However, this is of no value when AUTH_SYS is being used. 2029 * NFSv4.1 also defines the SSV mechanism which uses the RPCSEC_GSS 2030 infrastructure to enable it to be reliably determined whether two 2031 different client connections are connected to the same client. It 2032 is unclear whether the word "authentication" is appropriate in 2033 this case. As with MACHCRED, this is of no value when AUTH_SYS is 2034 being used. 2036 * Because of the lack of support for AUTH_SYS and for NFSv4.0, it is 2037 quite desirable for clients to use and for servers to require the 2038 use of client-peer authentication as part of connection 2039 establishment. 2041 When unauthenticated clients are allowed, their state is expsed to 2042 unwanted modification as part of disruptuion or denial-of-service 2043 attcks. as a resul the potential burdens of such attacks are felt 2044 principally by client not to provide such authentication. 2046 10. Identification and Authentication 2048 Various objects and subjects need to be identified for a protocol to 2049 function. For it to be secure, many of these need to be 2050 authenticated so that incorrect idenifification is not the basis for 2051 attacks. 2053 10.1. Identification vs. Authentication 2055 It is necessary to be clear about this distinction which has been 2056 obscured in the past, by the use of the term "RPC Authentification 2057 Flavor" in connection with situation in which identification without 2058 authentication occrred or in which there was neither identification 2059 nor authentication involved. As a result, we will use the term "RPC 2060 Flavors" instead 2062 10.2. Items to be Identified 2064 Some identifier are not security-relevant and can used be used 2065 without authentication, given that, in the authorization decision, 2066 the object acted upon needs only to be properly identified 2068 * File names are of this type. 2070 Unlike the case for some other protocols, confusion of names that 2071 result frominternationalization issue, while an annoyance are not 2072 relevant to security. If the confusion between LATIN CAPITAL 2073 LETTER O and CYRILLIC CAPITAL LETTER O, results in the wrong file 2074 being accessed, the mechanisms dscribed in Section 5 prevent in 2075 appropriate access being granted. 2077 Despite the above, it is desirable if file names togeter with 2078 similar are not transferred in the clear as the information 2079 exposed may give atackers useful information helpful in planning 2080 and executing atacks. 2082 * The case of file handles is similar. 2084 Identifier that refer to state shared between client and server can 2085 be the basis of disruption attacks since clients and server 2086 necessaily assume that neither side will change the state corpus 2087 without appropriate notice. 2089 While these identifiers do not need to be authenticated, they are 2090 associated with higher-level entities for which change of the state 2091 represented by those entities is subject to peer authentication. 2093 * Unexpected closure of stateids or changes in state sequence values 2094 can disrupt client access as no clients have provision to deal 2095 with this source of interference. 2097 While encryption may make it more difficult to execute such 2098 attacks attackers can often guess stateid's since server generally 2099 not randomize them. 2101 * Similarly, modification to v4.1 session state information can 2102 result in confusion if an attacker changes the slot sequence by 2103 assuing spurious requests. Even if the request is rejected, the 2104 slot sequence is changed and clients may a difficult time getting 2105 back in sync with the server. 2107 While encryption may make it more difficult to execute such 2108 attacks attackers can often guess slot id's and obtain sessinid's 2109 since server generally do not randomize them. 2111 it is necessary that modification of the higher-levell entities be 2112 restricted to the client that created them. 2114 * For v4.0, the relevant entity is the clientid. 2116 * for v4.1, the releant entity is the sessionid. 2118 Identifiers describing the issuer of the request, whether in numeric 2119 or string form always require authentication. 2121 10.3. Authentication Provided by specfic RPC Flavors 2123 Different flavors differ quite consderably, as discussed below; 2125 * When AUTH_NONE is used, the user making the request is neither 2126 authenticated nor identified to the server. 2128 Also, the server is not authenticated to the client and has no way 2129 to determine whether the server it is communicating with is an 2130 imposter. 2132 * When AUTH_SYS is used, the user making is the request identified 2133 but there no authentication of that identification. 2135 As in the previous case, the server is not authenticated to the 2136 client and has no way to determine whether the server it is 2137 communicating with is an imposter. 2139 * When RPCSEC_GSS is used, the user making the request is 2140 authenticated as is the server peer responding. 2142 10.4. Authentication Provided by the RPC Transport 2144 Different transports differ quite consderably, as discussed below. 2145 In contrast to the case of RPC flavors, any authentication happens 2146 once, at connection establishment, rather than on each RPC request. 2147 As a result, it is the client and server peers, rather than 2148 individual users that is authenticated. 2150 * For most transports, such as TCP and RPC-over-RDMA version 1, 2151 there is no provision for peer authentication. 2153 As a result use of AUTH_SYS together with such transports is 2154 inherently problematic. 2156 * Some transports provide for the possibility of mutual peer 2157 authentication. 2159 11. Security of Data in Flight 2161 11.1. Data Security Provided by the Flavor-associated Services 2163 The only flavor providing these facilities is RPCSEC_GSS. When this 2164 flavor is used, data security can be negotiated between client and 2165 server as described in Section 12.2. However, when data security is 2166 provided at the transport level, as described in Section 11.2, the 2167 negotiation of privacy and integrity support is unnecessary, 2168 Other flavors, such as AUTH_SYS and AUTH_NONE have no such data 2169 security facilities. When these flavor are used, the only data 2170 security is provided by the transport. 2172 11.2. Data Security Provided by the RPC Transport 2174 Some transports provide data security for all transactions performed 2175 on them, eliminating the need for that security to be provided or 2176 negotiated by the selection of particular flavors, mechanism, or 2177 services. 2179 12. Security Negotiation 2181 As previously in NFSv4, we use the term "negotiation" to characterize 2182 the process of the server providing a set of options and the client 2183 selecting one. 2185 The use of SECINFO, possibly with SECINFO_NONAME, remains the primary 2186 means by which the security parameters are determined. The addition 2187 of transports to flavors in providing security has resulted in the 2188 following changes: 2190 * Transport-related security choices are typically decided at 2191 connection-establishment so there needs to be provision for 2192 negotiation at this point. 2194 * Despite the above, because the choices of flavor and transport 2195 affect one another, SECINFO has been extended by the addition of 2196 pseudo-flavors, while retaining the existing XDR, to allow 2197 negotiation of transport choices and accompanying connection 2198 establishment options, in addition to selection of flavors and 2199 accompanying services. This allows server policies for such 2200 matters to be different for different portions of the namespace. 2202 12.1. Flavors and Pseudo-flavors 2204 The flavor field of the secinfo4 items returned by SECINFO and 2205 SECINO_NONAME have always allowed pseudo flavors to be included. 2206 However, previous treatments of these operations have not provided 2207 information about how responses containing such pseudo-flavors are to 2208 be interpreted. 2210 Those pseudo-flavors now provide a means of extending the negotiation 2211 process so it is capable of providing for the negotiation of the use 2212 particular RPC transports and security-related options for the 2213 connections established using those transports. 2215 The flavors AUTH_NONE, AUTH_SYS and RPCSEC_GSS continue to indicate 2216 the acceptability of the corresponding method of user authentication, 2217 user identification, or user non-identification, when used with a 2218 particular RPC transport. 2220 The flavor AUTH_TLS, which is not used as part of issuing requests is 2221 not included in this list and is treated as a connetion-type-- 2222 specifying pseudo-flavor. 2224 secinfo4s for the flavor RPCSEC_GSS contains additional information 2225 describing the specific secrity lgorithm to be used and the ancillary 2226 services to be provided (e.g. integrity, privacy) when these services 2227 are not provided by the trnsport. 2229 Such flavors are referred to as "flavor-specifying flavors" 2231 The classification below organizes the flavors and pseudo-flavors 2232 used in security negotiation while Section 12.4 describes how the set 2233 of secinfos in a response can be used by the client to select 2234 acceptble combinations of security flavor, security mechanism, 2235 security services, security-related transports, and security-related 2236 connection chractertics. 2238 * The pseudo-flavors designating a security-relevant transport type, 2239 together with AUTH-TLS, nominally a flavor but used as a pseudo- 2240 flavor in connection with SECINFO. 2242 Such pseudo-flavors are referred to as "transport- specifying 2243 flavors". 2245 * The pseudo-flavors designating restrictions on acceptble 2246 connnection characteristics include XPCH_ENCRYPT, XPCH_PEERAUTH, 2247 and XPCH_SECURE. 2249 Such pseudo-flavors are referred to as "transport-restriction 2250 flavors". 2252 * The pseudo-flavors combining a flavor designation together with a 2253 restriction conerninng the connections it is relevant to include 2254 AUTHXP_CLIENTPEER, AUTHXP_ENCRYPT, AUTHXP_SECURE. 2256 Such pseudo-flavors are referred as tranport-hybridized flavors. 2258 * The special pseudo-flavors, XPBREAK and XPCURRENT 2260 Such pseudo-flavors are referred to connection-organizing flavors. 2262 12.2. Negotiation of Security Flavors and Mechanisms 2264 For the current connection, this proceeds as it has previously, when 2265 security-relevant transports were not available. Flavor entties, 2266 including those including mechanism information are listed in order 2267 of server preference and apply, by default, to the current 2268 connection, which normally is favored by the server. 2270 When other transport-identifying pseudo-flavors appear before the 2271 flavor entries, then the server is indicating that these transport 2272 types, with the server preference following the ordering of the 2273 entries. In this case, any flavor entries that follow a transport 2274 entry specify that flavor is usable with the transport types denoted 2275 by that transport entry. 2277 12.3. Negotiation of RPC Transports and Characteristics 2279 First we define some necessary terminology. 2281 * A transport type specifies one of a small set of RPC transport 2282 types such as TCP or RDMA. Each such transport type has an 2283 associated pseudoflavor. There are also pseudo-flavors that 2284 specify a set of transport types such as XPT_ALL. 2286 * Connection characteristics are designations of security-relevant 2287 characteristics or sets of characteristics that connections might 2288 have. 2290 There are pseudo-flavors associated with connection 2291 characteristics such as CONCH_CPAUTH, denoting client-peer 2292 authentication and CONCH_ENCRYPT, denoting the presence of an 2293 encrypted channel. The pseudo-flavor CONCH_SECURE denotes the 2294 presence of peer mutual authentication together with the use of an 2295 encrypted channel. 2297 * The combination of a transport type with a set of connection 2298 chracteristics is considered a connection type..while many 2299 connection types are designated by a combination of a flavor 2300 designating a transport with on designating a set of connection 2301 chacteristics, ther are pseudo flavor that designate a connection 2302 type directly. 2304 For example, the flavor AUTH_TLS is equivalent to XP_TCP combined 2305 with CONCH_ENCRYPT, while the pseudo-flavor XP_TCP_SECURE 2306 equivalent to XP_TCP comnined with CONCH_SECURE. 2308 * A flavor specification designates a specific flavor, or, in the 2309 case of RPCSEC_GSS, a flavor combined with additional mechanism 2310 and service information. 2312 * A flavor assigment denote the assiciation of a specfic flavor 2313 specification with a connection type. 2315 A secinfo response will designate a set of valid flavor assigments 2316 with an implied server ordering derived from the order that the 2317 entries appear in. 2319 In interpreting the response array the client is to maintain sets of 2320 designated transport typtes, connection characteristics and 2321 connection types specfied indidually (i.e. without separately 2322 specifying transport types and connection characteristics). When a 2323 flavor soecfication is encuntered, that flavor is considered valid 2324 when used with all curently active connection types, defined by the 2325 unionof the individually specified connection types and the cartesian 2326 product of the current transport types and current connection types. 2328 The presumed ordering of these assigments is as follows: 2330 * When one of the connection types was specified directly by a 2331 connection type, the positionof that specification is compared to 2332 that of either the other individually-specified connection type or 2333 the earlier of the transport-type specfication and the connection 2334 characteristics specification. 2336 * in other cases, the position of the transport type specifications 2337 are considered first withe the position of the connection 2338 characteristics considered if necessary. 2340 * If neithe of the above resolve issue, the positionof the flavor 2341 specification is considered. 2343 * The type of the current connection is considered to be specified 2344 first, implicitly. 2346 * There are provisions, described in Section 12.4 to modify this 2347 ordering, as may be necessary, for example, when the current 2348 connection, while acceptsble is of lower server preference. 2350 12.4. Overall Interpretation of SECINFO Response Arrays 2352 [TBD in -01] 2354 12.5. SECINFO 2356 The description in the sub-sections below, while it adheres to the 2357 XDR appearing [6], [7], [8], [9] and [11]. will supersede the 2358 descriptions in [7] and [8]. 2360 This is necessary to adapt the security negotiation process to the 2361 presence of transport-level security services such as encryption and 2362 peer authentication. 2364 Sumilar changes are necessary in the parallel SECINFO_NONAME 2365 operation introduced in NFSv4.1. These are expected to be done as 2366 part of the rfc5661bis effort. 2368 12.5.1. SECINFO ARGUMENTS 2370 struct SECINFO4args { 2371 /* CURRENT_FH: directory */ 2372 component4 name; 2373 }; 2375 Figure 1 2377 12.5.2. SECINFO RESULTS 2378 /* 2379 * From RFC 2203 2380 */ 2381 enum rpc_gss_svc_t { 2382 RPC_GSS_SVC_NONE = 1, 2383 RPC_GSS_SVC_INTEGRITY = 2, 2384 RPC_GSS_SVC_PRIVACY = 3 2385 }; 2387 struct rpcsec_gss_info { 2388 sec_oid4 oid; 2389 qop4 qop; 2390 rpc_gss_svc_t service; 2391 }; 2393 /* RPCSEC_GSS has a value of '6' - See RFC 2203 */ 2394 union secinfo4 switch (uint32_t flavor) { 2395 case RPCSEC_GSS: 2396 rpcsec_gss_info flavor_info; 2397 default: 2398 void; 2399 }; 2401 typedef secinfo4 SECINFO4resok<>; 2403 union SECINFO4res switch (nfsstat4 status) { 2404 case NFS4_OK: 2405 /* CURRENTFH: consumed */ 2406 SECINFO4resok resok4; 2407 default: 2408 void; 2409 }; 2411 Figure 2 2413 12.5.3. SECINFO DESCRIPTION 2415 The SECINFO operation is used by the client determine the appropriate 2416 RPC authentication flavors, security mechanisms and encrypting 2417 transports to access a specific directory filehandle, file name pair. 2418 SECINFO should apply the same access approach used for LOOKUP when 2419 evaluating the name. In consequence, if the requester does not have 2420 the appropriate access to LOOKUP the name, then SECINFO will behave 2421 the same way and return NFS4ERR_ACCESS. 2423 The result will contain an array that represents the security flavor, 2424 security mechanisms and transports available, with an order 2425 corresponding to the server's preferences, the most preferred being 2426 first in the array. The client is free to pick whatever security 2427 flavors, mechanisms and transports it both desires and supports, or 2428 to pick in the server's preference order the first one it supports. 2429 The array entries are represented by the secinfo4 structure. The 2430 field 'flavor' will contain one of the following sorts of values: 2432 * a value of AUTH_NONE, AUTH_SYS (as defined in RFC 5531 [4]). 2434 * AUTH_TLS as described in ... 2436 * A pseudo-flavor defined in Section 14.2 2438 * RPCSEC_GSS (as defined in RFC 2203 [2]). 2440 * Any other security flavor or pseudo-flavor registered with IANA. 2442 For the flavors other than RPCSEC_GSS, no additional security 2443 information is returned. For a return value of RPCSEC_GSS, a 2444 security triple is returned that contains the mechanism object 2445 identifier (OID, as defined in RFC 2743 [3]), the quality of 2446 protection (as defined in RFC 2743 [3]), and the service type (as 2447 defined in RFC 2203 [2]). It is possible for SECINFO to return 2448 multiple entries with flavor equal to RPCSEC_GSS with different 2449 security triple values. 2451 On success, the current filehandle is consumed, so that, if the 2452 operation following SECINFO tries to use the current filehandle, that 2453 operation will fail with the status NFS4ERR_NOFILEHANDLE. 2455 If the name has a length of zero, or if the name does not obey the 2456 UTF-8 definition in cirsumstanes in which UTF-8 names are required, 2457 the error NFS4ERR_INVAL will be returned. 2459 See Sections 12.2 through 12.4 for additional information on the use 2460 of SECINFO. 2462 12.5.4. SECINFO IMPLEMENTATION (general) 2464 The SECINFO operation is expected to be used by the NFS client when 2465 the error value of NFS4ERR_WRONGSEC is returned from another NFS 2466 operation. This signifies to the client that the server's security 2467 policy is different from what the client is currently using. At this 2468 point, the client is expected to obtain a list of possible security 2469 flavors and choose what best suits its policies. 2471 12.5.4.1. SECINFO IMPLEMENTATION (for v4.0) 2473 [TBD in -01] 2475 12.5.4.2. SECINFO IMPLEMENTATION (for v4.1 and v4.2) 2477 As mentioned, the server's security policies will determine when a 2478 client request receives NFS4ERR_WRONGSEC. 2480 See Table 14 of [8] for a list of operations that can return 2481 NFS4ERR_WRONGSEC. in the case of v4.2, there might be extensions 2482 alloed to return NFS4ERR_WRONGSEC. In addition, when READDIR returns 2483 attributes, the rdattr_error (Section 5.8.1.12 of [8]) can contain 2484 NFS4ERR_WRONGSEC. 2486 Note that CREATE and REMOVE MUST NOT return NFS4ERR_WRONGSEC. The 2487 rationale for CREATE is that unless the target name exists, it cannot 2488 have a separate security policy from the parent directory, and the 2489 security policy of the parent was checked when its filehandle was 2490 injected into the COMPOUND request's operations stream (for similar 2491 reasons, an OPEN operation that creates the target MUST NOT return 2492 NFS4ERR_WRONGSEC). If the target name exists, while it might have a 2493 separate security policy, that is irrelevant because CREATE MUST 2494 return NFS4ERR_EXIST. The rationale for REMOVE is that while that 2495 target might have a separate security policy, the target is going to 2496 be removed, and so the security policy of the parent trumps that of 2497 the object being removed. RENAME and LINK MAY return 2498 NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error applies only to the 2499 saved filehandle (see Section 2.6.3.1.2 of [8]). Any 2500 NFS4ERR_WRONGSEC error on the current filehandle used by LINK and 2501 RENAME MUST be returned by the PUTFH, PUTPUBFH, PUTROOTFH, or 2502 RESTOREFH operation that injected the current filehandle. 2504 With the exception of LINK and RENAME, the set of operations that can 2505 return NFS4ERR_WRONGSEC represents the point at which the client can 2506 inject a filehandle into the "current filehandle" at the server. The 2507 filehandle is either provided by the client (PUTFH, PUTPUBFH, 2508 PUTROOTFH), generated as a result of a name-to-filehandle translation 2509 (LOOKUP and OPEN), or generated from the saved filehandle via 2510 RESTOREFH. As oSection 2.6.3.1.1.1 of [8] states, a put filehandle 2511 operation followed by SAVEFH MUST NOT return NFS4ERR_WRONGSEC. Thus, 2512 the RESTOREFH operation, under certain conditions (see 2513 Section 2.6.3.1.1 of [8]), is permitted to return NFS4ERR_WRONGSEC so 2514 that security policies can be honored. 2516 The READDIR operation will not directly return the NFS4ERR_WRONGSEC 2517 error. However, if the READDIR request included a request for 2518 attributes, it is possible that the READDIR request's security triple 2519 did not match that of a directory entry. If this is the case and the 2520 client has requested the rdattr_error attribute, the server will 2521 return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. 2523 To resolve an error return of NFS4ERR_WRONGSEC, the client does the 2524 following: 2526 * For LOOKUP and OPEN, the client will use SECINFO with the same 2527 current filehandle and name as provided in the original LOOKUP or 2528 OPEN to enumerate the available security triples. 2530 * For the rdattr_error, the client will use SECINFO with the same 2531 current filehandle as provided in the original READDIR. The name 2532 passed to SECINFO will be that of the directory entry (as returned 2533 from READDIR) that had the NFS4ERR_WRONGSEC error in the 2534 rdattr_error attribute. 2536 * For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the 2537 client will use SECINFO_NO_NAME { style = 2538 SECINFO_STYLE4_CURRENT_FH }. The client will prefix the 2539 SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or 2540 PUTROOTFH operation that provides the filehandle originally 2541 provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH 2542 operation. 2544 NOTE: In NFSv4.0, the client was required to use SECINFO, and had 2545 to reconstruct the parent of the original filehandle and the 2546 component name of the original filehandle. The introduction in 2547 NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction. 2549 * For LOOKUPP, the client will use SECINFO_NO_NAME { style = 2550 SECINFO_STYLE4_PARENT } and provide the filehandle that equals the 2551 filehandle originally provided to LOOKUPP. 2553 12.6. Future Security Needs 2555 [To be fleashed out in -01]: This section is basically an outline for 2556 now, to be filled out laater based on Working Group input, 2557 particularly from Chuck lever who suggested this section and has 2558 ideas about many of the items in it. 2560 * Security for data-at-rest, most probably based on facilities 2561 defined within SAN. 2563 * Support for content signing. 2565 * Revision/extension of labelled NFS to provide true 2566 interoperability and server-based authorization. 2568 * Work to provide more security for RDMA-based transports. This 2569 would include the peer authentication infrastructure now being 2570 developed as part of RPC-over-RDMA version 2. In addition, there 2571 is a need for an RPC-based transport that provides for encyption, 2572 which might be provided in number of ways. 2574 13. Security Considerations 2576 13.1. Changes in Security Considerations 2578 Beyond the needed inclusion of a threat analysis and the fact that 2579 all minor versions are dealt with together, there are a number of 2580 substantive changes in the approach to NFSv4 security presented in 2581 RFCs 7530 and 8881 and that appearing in this document. 2583 This document will not seek to speculate how the previous treatment, 2584 now viewed as incorrect, came to be written, approved, and published. 2585 However, it will, for the benefit of those familiar with the previous 2586 treatment of these matters, draw attention to the important changes 2587 listed here. 2589 * There is a vastly expanded range of threats being considered as 2590 described in Section 13.1.1 2592 * New facilities available at the RPC transport level can be used to 2593 deal with security issues, as described in Section 13.1.2 2595 13.1.1. Wider View of Threats 2597 Although the absence of a threat analysis in previous treatments 2598 makes comparison most difficult, the security-related features 2599 described in previous specifications and the associated discussion in 2600 their security considerations sections makes it clear that earlier 2601 specifications took a quite narrow view of threats to be protected 2602 against. 2604 One aspect of that narrow view that merits special attention is the 2605 handling of AUTH_SYS, at that time in the clear, with no client peer 2606 authentication. 2608 With regard to specific threats, there is no mention in existing 2609 security consideration sections of: 2611 * Denial-of-service attacks. 2613 * Client-impersonation attacks. 2615 * Server-impersonation attacks. 2617 The handling of data security in-flight is even more troubling. 2619 * Although there was considerable work in the protocol to allow use 2620 of encryption to be negotiated when using RPCSEC_GSS. The 2621 existing security considerations do not mention the potential need 2622 for encryption at all. 2624 It is not clear why this was omitted but it is a pattern that 2625 cannnot repeated in this document. 2627 * The case of negotiation of integrity services is similar and uses 2628 the same negotiation infrastructure. 2630 In this case, use of integrity is recommended but not to prevent 2631 the corruption of user data being read or written. 2633 The use of integrity services is recommended in connetion with 2634 issuing SECINFO (and for NFSv4.1, SECINFO_NONAME). The presence 2635 of this recommendation in the associated security considerations 2636 sections has the unfortunate effect of suggesting that the 2637 protection of user data is of relatively low impotance. 2639 13.1.2. Transport-layer Security Facilities 2641 Such transport-level RPC facilitites as RPC-over-TLS provide 2642 important ways of proving better security for all the NFSv4 minor 2643 versions. 2645 In particular: 2647 * The presence of encryption by default will deal with security 2648 issue regarding data-in-flight, for both RPCSEC_GSS and AUTH_SYS. 2650 * Peer authentication provided by the server eliminates the 2651 possibility of a server-impersonation attack, even when using 2652 AUTH_SYS. 2654 * When mutual authentication is part of connection establishment, 2655 there is a possibility, where an appropriate trust relationship 2656 exisrts of treating the userid's presented in AUTH_SYS, as 2657 effectively authenticated, based on the authetication of the 2658 client peer. 2660 13.1.3. Compatibility and Maturity Issues 2662 Given the need to drastically change the NFSv4 security approach from 2663 that specified previously, it is necessary for us to be mindful of: 2665 * The difficulty that might be faced in adapting to the newer 2666 guidance because the delays involved in designing, developing, and 2667 testing new transport- level security facilities such as RPC-over- 2668 TLS. 2670 * The difficulty in discarding or substantially modifying previous 2671 existing deployments and practices, developed on the basis of 2672 previous normative guidance. 2674 For these reasons, we will not use the term "MUST NOT" in some 2675 situations in which the use of that term might have been justified 2676 earlier. In such cases, previous guidance together with the passsage 2677 of time may have created a situation in which the considerations 2678 mentioned above in this section may be valid reasons to defer, for a 2679 limited time, correction of the current sitution making the term 2680 "SHOULD NOT" appropriate, since the difficulties cited would 2681 constitute a valid reason to not allow what hsd been recommended 2682 against. 2684 13.1.4. Discussion of AUTHSYS 2686 An important change concerns the treatment of AUTH_SYS which is now 2687 divided into two subcases given the possible availabillity of support 2688 from the transport layer. 2690 When such support is not available, AUTH_SYS SHOULD NOT be used, 2691 since it makes the following attacks quite easy to execute: 2693 * The absence of authentication of the server to the client allow 2694 server impersonation in which an imposter server can obtain data 2695 to be written by the user and supply corrupted data to read 2696 requests. 2698 * The absence of authentication of the client user to the server 2699 allow server impersonation in which an imposter client can issue 2700 requests and have them executed as a user designated by imposter 2701 client, vitiating the server's authorization policy. 2703 With no authentication of the client peer, common approaches, such 2704 as using the source IP address can be easily defeated, allowing 2705 unauthenticated execution of requests made by the pseudo clients 2707 * The absence of any support to protect data-in-flight when AUTH_SYS 2708 is used result in further serious security weaknesses. 2710 In connection with the use of the term "SHOULD NOT" above, it is 2711 understood that the "valid reasons" to use this form of access 2712 reflect the Compatibility and Maturity Issue discussed above in 2713 Section 13.1.3 and that it is expected that, over time, these will 2714 become less applicable. 2716 13.2. Security Considerations Scope 2718 13.2.1. Discussion of Potental Classification of Environmets 2720 [Working group discussion needed]: For now, we will not consider 2721 different security policies for different sorts of environments. 2722 This is because of: 2724 * Doing so would add considrable complexity to this document. 2726 * The additional complexity would undecut our main goal here, which 2727 is to discuss secure us on the internet, which remain an important 2728 NFSv4 goal. 2730 * The ubiquity of internet acess makes it hard to treat corporate 2731 network separately from the internet per se. 2733 * While small networks might be sufficiently isolated to make it 2734 reasonable use NFSv4 without serious attention to security issues, 2735 the complexity of characterizing the necessary isolation makes it 2736 impractical to deal with such cases in this document. 2738 13.2.2. Discussion of Environments 2740 Although the security goal for Nfsv4 has been and remains "secure use 2741 on the internet", much use of NFSv4 occurs on more restricted IP 2742 networks with NFS access from outside the owning organization 2743 prevented by firewalls. 2745 This security considerations section will not deal separately with 2746 such environments since the threats that need to be discussed are 2747 essentially the same, despite the assumption by many that the 2748 restricted network access would eliminate the possibility of attacks 2749 originating inside the network by attackers who have some legitimate 2750 Nfsv4 access within it. 2752 In organizations of significant size, this sort of assumption of 2753 trusted access is usually not valid and this document will not deal 2754 with them explicitly. In any case, there is little point in doing 2755 so, since, if everyone can be trusted, there can be no attackers, 2756 rendering threat analysis superfluous. 2758 This does not mean that NFSv4 use cannot, as a practical matter, be 2759 made secure through means outside the scope of this document 2760 including strict administrative controls on all software running 2761 within it, frequent polygraph tests, and threats of prosecution. 2762 However, this document is not prepared to discuss the details of such 2763 policies, their implementation, or legal issues associated with them 2764 and treats such matters as out-of-scope. 2766 Nfsv4 can be used in very restrictive IP network environments where 2767 outside access is quite restricted and there is sufficient trust to 2768 allow, for example, every node to have the same root password. The 2769 case of a simple network only accessible by a single user is similar. 2770 In such networks, many thing thats this document says "SHOULD NOT" be 2771 done are unexceptionable but the responsibility for making that 2772 determination is one for those creating such networks to take on. 2773 This document will not deal further with NFSv4 use on such networks. 2775 13.3. Major New Recommendations 2777 13.3.1. Recommendations Regarding Security of Data in Flight 2779 We RECOMMEND that requesters always issue requests with data security 2780 (i.e. with protection from disclosure or modification in flight) 2781 whether provided at the RPC request level or by the RPC transport, 2782 irrespective of the responder's requirements. 2784 We RECOMMEND that implementers provide servers the ability to 2785 configure policies in which requests without data security will be 2786 rejected as having insufficient security. 2788 We RECOMMEND that servers use such policies over either their entire 2789 local namespace or for all file systems except those clearly designed 2790 for the general dissemination of non-sensitive data. 2792 13.3.2. Recommendations Regarding Client Peer Authentication 2794 We RECOMMEND that clients provide authentication material whenever a 2795 connection is established with a server capable of using it to 2796 provide client peer authentication. 2798 We RECOMMEND that implementers provide servers the ability to 2799 configure policies in which attempts to establish connections without 2800 client peer authentication will be rejected. 2802 We RECOMMEND that servers adopt such policies whenever requests not 2803 using RPCSEC_GSS are allowed to be executed. 2805 13.3.3. Issues Regarding Valid Reasons to Bypass Recommendations 2807 Clearly, the maturity and compatibility issues mentioned in 2808 Section 13.1.3 are valid reasons to nypass the above recommenations, 2809 as loong as thse issues continue to exist. 2811 [Working group discussion needed}: The question the working group 2812 needs to address is whether other valid reasons exist. 2814 [Working group discussion needed}: In particular, some members of the 2815 group might feel that the performance cost of encrypted transports 2816 constitutes, in itself, a valid reason to ignore the above 2817 recommendations. 2819 [Working group discussion needed}: I cannot agree and feel that 2820 accepting that as a valid reason would undercut Nfsv4 security 2821 improvement, and probably would not be acceptable to the security 2822 directorate. However, I do want to work out an a generally 2823 acceptable compromise. I propose something along the following 2824 lines: 2826 The transport-based encryption facilities are designed to be 2827 compatible with facilities to offload the work of encryption and 2828 decryption. When such facilities are not available, at a 2829 reasonable cost, to NFSv4 servers and clients anticipating heavy 2830 use of NFSv4, then the lack of such facilities can be considered a 2831 valid reason to bypass the above recommendations, as long as that 2832 situation continues. 2834 13.4. Data Security Threats 2836 [TBD in -01] 2838 13.5. Authentication-based threats 2840 13.5.1. Attacks based on the use of AUTH_SYS 2842 [TBD in -01] 2844 13.5.2. Attacks on Name/Userid Mapping Facilities 2846 [TBD in -01] 2848 13.6. Disruption and Denial-of-Service Attacks 2850 13.6.1. Attacks Based on the Disruption of Client-Server Shared State 2852 [TBD in -01] 2854 13.6.2. Attacks Based on Forcing the Misuse of Server Resources 2856 [TBD in -01] 2858 14. IANA Considerations 2860 Because of the shift from implementing security-related services only 2861 in connection with RPCSEC_GSS to one in which transport-level 2862 security has a prominent role, a number if new values need to be 2863 assigned. 2865 These include new authstat values to guide selection of a Transports 2866 aceptable to both client and server, presented in Section 14.1 and 2867 new pseudo-flavors to be used in the process of security negotion, 2868 presented in Section 14.2. 2870 14.1. New Authstat Values 2872 The following new authstat values are necessary to enable a server to 2873 indicte that the server's policy does not allows requests to be made 2874 on the current connection because of security issues associated with 2875 the rpc transport. In the event they are received, the client need 2876 to establish a new connection. 2878 * The value XP_CRYPT indicates that the server will not support 2879 access using unencrypted connections while the current connection 2880 is not encrypted. 2882 * The value XP_CPAUTH indicates that the server will not support 2883 access using connections for which the client peer has not 2884 authenticad itelf as part of connection while the current 2885 connection has not been set up in that way. 2887 14.2. New Authentication Pseudo-Flavors 2889 The following new pseudo-flavors are made available to allow their 2890 return as part of the response to SECINFO operation described in 2891 Section 12.5 and for similar operations. 2893 [TBD in -01] 2895 15. References 2896 15.1. Normative References 2898 [1] Bradner, S., "Key words for use in RFCs to Indicate 2899 Requirement Levels", BCP 14, RFC 2119, 2900 DOI 10.17487/RFC2119, March 1997, 2901 . 2903 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 2904 Specification", RFC 2203, DOI 10.17487/RFC2203, September 2905 1997, . 2907 [3] Linn, J., "Generic Security Service Application Program 2908 Interface Version 2, Update 1", RFC 2743, 2909 DOI 10.17487/RFC2743, January 2000, 2910 . 2912 [4] Thurlow, R., "RPC: Remote Procedure Call Protocol 2913 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 2914 May 2009, . 2916 [5] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2917 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2918 May 2017, . 2920 [6] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 2921 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 2922 March 2015, . 2924 [7] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 2925 (NFS) Version 4 External Data Representation Standard 2926 (XDR) Description", RFC 7531, DOI 10.17487/RFC7531, March 2927 2015, . 2929 [8] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 2930 Version 4 Minor Version 1 Protocol", RFC 8881, 2931 DOI 10.17487/RFC8881, August 2020, 2932 . 2934 [9] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 2935 "Network File System (NFS) Version 4 Minor Version 1 2936 External Data Representation Standard (XDR) Description", 2937 RFC 5662, DOI 10.17487/RFC5662, January 2010, 2938 . 2940 [10] Haynes, T., "Network File System (NFS) Version 4 Minor 2941 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 2942 November 2016, . 2944 [11] Haynes, T., "Network File System (NFS) Version 4 Minor 2945 Version 2 External Data Representation Standard (XDR) 2946 Description", RFC 7863, DOI 10.17487/RFC7863, November 2947 2016, . 2949 [12] Myklebust, T. and C. Lever, "Towards Remote Procedure Call 2950 Encryption By Default", Work in Progress, Internet-Draft, 2951 draft-ietf-nfsv4-rpc-tls-11, 23 November 2020, 2952 . 2955 15.2. Informative References 2957 [13] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 2958 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 2959 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 2960 October 2017, . 2962 Appendix A. Acknowledgments 2964 The author wishes to thanl tom haynes for his helpful suggestion to 2965 deal with security for all NFSv4 minor versions in the same document. 2967 The author wishes to draw people's attention to Nico Williams' remark 2968 that NFSv4 security was not so bad, except that there was no 2969 provision for authentication of the client peer. This perceptive 2970 remark, which now seems like common sense, did not seem so when made, 2971 but it has served as a beacon for those putting NFSv4 security on a 2972 firmer footing. Our gratitude is appropriate. 2974 The author wishes to acknowledge the important role of the authors of 2975 RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS 2976 security agenda forward and thank them for all their efforts to 2977 improve NFS security. 2979 The author wishes to thank Chuck Lever for his many helpful comments 2980 about nfsv4 security issues, his explanation of many unclear points, 2981 and and much important guidance he provided that is reflected in this 2982 document. 2984 The author wishes to thank Rick Macklem for his role in clarifying 2985 possible server policies regarding RPC-over-TLS and bringing possible 2986 approaches to the attention of the working group. 2988 Author's Address 2989 David Noveck (editor) 2990 NetApp 2991 1601 Trapelo Road, Suite 16 2992 Waltham, MA 02451 2993 United States of America 2995 Phone: +1-781-572-8038 2996 Email: davenoveck@gmail.com