[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
NFSv4                                                     D. Noveck, Ed.
Internet-Draft                                                    NetApp
Updates: 8881, 7530 (if approved)                         30 August 2021
Intended status: Standards Track
Expires: 3 March 2022


                    Security for the NFSv4 Protocols
                    draft-dnoveck-nfsv4-security-01

Abstract

   This document describes the core security features of the NFSv4
   family of protocols, applying to all minor versions.  The discussion
   includes the use of security features provided at the RPC transport
   level.

   This preliminary version of the document, is intended, in large part,
   to result in working group discussion regarding NFSv4 security issues
   and identify issues on which the working group needs to work on
   achieving consensus.

   When published as an RFC, it will supersede the description of
   security appearing in existing minor version specification documents
   such as RFC 7530 and RFC 8881.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 March 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Noveck                    Expires 3 March 2022                  [Page 1]


Internet-Draft               Nfsv4 Security                  August 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Keyword Definitions . . . . . . . . . . . . . . . . . . .   6
     2.2.  Special Considerations  . . . . . . . . . . . . . . . . .   6
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Handling of Multiple Minor Versions . . . . . . . . . . .   7
     3.2.  Handling of Minor-version-specific features . . . . . . .   8
     3.3.  Transport-based Security Features . . . . . . . . . . . .  10
     3.4.  Issues Yet to be Fully Decided  . . . . . . . . . . . . .  11
   4.  Structure of Access Control Lists . . . . . . . . . . . . . .  13
     4.1.  Access Control Entries  . . . . . . . . . . . . . . . . .  14
     4.2.  ACE Type  . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.  Authorization in General  . . . . . . . . . . . . . . . . . .  15
   6.  User-based File Access Authorization  . . . . . . . . . . . .  16
     6.1.  Handling of Multiple Parallel File Access Authorization
           Models  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.2.  Attributes for User-based File Access Authorization . . .  19
     6.3.  Posix Authorization Model . . . . . . . . . . . . . . . .  19
       6.3.1.  Attribute 33: mode  . . . . . . . . . . . . . . . . .  19
       6.3.2.  V4.1 Attribute 74: mode_set_masked  . . . . . . . . .  20
     6.4.  ACL-based Authorization Model . . . . . . . . . . . . . .  21
       6.4.1.  Processing Access Control Entries . . . . . . . . . .  21
       6.4.2.  ACE Access Mask . . . . . . . . . . . . . . . . . . .  23
       6.4.3.  Details Regarding Mask Bits . . . . . . . . . . . . .  23
       6.4.4.  ACE4_DELETE vs. ACE4_DELETE_CHILD . . . . . . . . . .  30



Noveck                    Expires 3 March 2022                  [Page 2]


Internet-Draft               Nfsv4 Security                  August 2021


       6.4.5.  ACE flag  . . . . . . . . . . . . . . . . . . . . . .  30
       6.4.6.  Details Regarding ACE Flag Bits . . . . . . . . . . .  31
       6.4.7.  ACE Who . . . . . . . . . . . . . . . . . . . . . . .  32
       6.4.8.  Automatic Inheritance Features  . . . . . . . . . . .  34
     6.5.  V4.1 Attribute 58: dacl . . . . . . . . . . . . . . . . .  36
     6.6.  V4.1 Attribute 59: sacl . . . . . . . . . . . . . . . . .  37
   7.  Common Considerations for Both File access Models . . . . . .  37
     7.1.  Server Considerations . . . . . . . . . . . . . . . . . .  37
     7.2.  Client Considerations . . . . . . . . . . . . . . . . . .  38
   8.  Combining Authorization Models  . . . . . . . . . . . . . . .  39
     8.1.  Combined Authorization Models for V4.0  . . . . . . . . .  39
     8.2.  Combined Authorization Model for V4.1 and Beyond  . . . .  39
       8.2.1.  Computing a Mode Attribute from an ACL  . . . . . . .  40
       8.2.2.  Alternatives in Computing Mode Bits . . . . . . . . .  41
       8.2.3.  Setting Multiple ACL Attributes . . . . . . . . . . .  41
       8.2.4.  Setting Mode and not ACL  . . . . . . . . . . . . . .  42
       8.2.5.  Setting ACL and Not Mode  . . . . . . . . . . . . . .  43
       8.2.6.  Setting Both ACL and Mode . . . . . . . . . . . . . .  43
       8.2.7.  Retrieving the Mode and/or ACL Attributes . . . . . .  43
       8.2.8.  Creating New Objects  . . . . . . . . . . . . . . . .  43
       8.2.9.  Use of Inherited ACL When Creating Objects  . . . . .  45
     8.3.  Combined Authorization Models for V4.2  . . . . . . . . .  45
   9.  Labelled NFS Authorization Model  . . . . . . . . . . . . . .  45
   10. State Modification Authorization  . . . . . . . . . . . . . .  46
   11. Other Uses of Access Control Lists  . . . . . . . . . . . . .  47
   12. Identification and Authentication . . . . . . . . . . . . . .  47
     12.1.  Identification vs. Authentication  . . . . . . . . . . .  47
     12.2.  Items to be Identified . . . . . . . . . . . . . . . . .  47
     12.3.  Authentication Provided by specific RPC Flavors  . . . .  49
     12.4.  Authentication Provided by the RPC Transport . . . . . .  49
   13. Security of Data in Flight  . . . . . . . . . . . . . . . . .  49
     13.1.  Data Security Provided by the Flavor-associated
            Services . . . . . . . . . . . . . . . . . . . . . . . .  49
     13.2.  Data Security Provided by the RPC Transport  . . . . . .  50
   14. Security Negotiation  . . . . . . . . . . . . . . . . . . . .  50
     14.1.  Flavors and Pseudo-flavors . . . . . . . . . . . . . . .  50
     14.2.  Negotiation of Security Flavors and Mechanisms . . . . .  52
     14.3.  Negotiation of RPC Transports and Characteristics  . . .  52
     14.4.  Overall Interpretation of SECINFO Response Arrays  . . .  53
     14.5.  SECINFO  . . . . . . . . . . . . . . . . . . . . . . . .  54
       14.5.4.  SECINFO IMPLEMENTATION (general) . . . . . . . . . .  56
         14.5.4.1.  SECINFO IMPLEMENTATION (for v4.0)  . . . . . . .  57
         14.5.4.2.  SECINFO IMPLEMENTATION (for v4.1 and v4.2) . . .  57
     14.6.  Future Security Needs  . . . . . . . . . . . . . . . . .  58
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  59
     15.1.  Changes in Security Considerations . . . . . . . . . . .  59
       15.1.1.  Wider View of Threats  . . . . . . . . . . . . . . .  59
       15.1.2.  Transport-layer Security Facilities  . . . . . . . .  60



Noveck                    Expires 3 March 2022                  [Page 3]


Internet-Draft               Nfsv4 Security                  August 2021


       15.1.3.  Compatibility and Maturity Issues  . . . . . . . . .  60
       15.1.4.  Discussion of AUTHSYS  . . . . . . . . . . . . . . .  61
     15.2.  Security Considerations Scope  . . . . . . . . . . . . .  62
       15.2.1.  Discussion of Potential Classification of
               Environments  . . . . . . . . . . . . . . . . . . . .  62
       15.2.2.  Discussion of Environments . . . . . . . . . . . . .  62
     15.3.  Major New Recommendations  . . . . . . . . . . . . . . .  63
       15.3.1.  Recommendations Regarding Security of Data in
               Flight  . . . . . . . . . . . . . . . . . . . . . . .  63
       15.3.2.  Recommendations Regarding Client Peer
               Authentication  . . . . . . . . . . . . . . . . . . .  63
       15.3.3.  Issues Regarding Valid Reasons to Bypass
               Recommendations . . . . . . . . . . . . . . . . . . .  64
     15.4.  Data Security Threats  . . . . . . . . . . . . . . . . .  64
     15.5.  Authentication-based threats . . . . . . . . . . . . . .  64
       15.5.1.  Attacks based on the use of AUTH_SYS . . . . . . . .  64
       15.5.2.  Attacks on Name/Userid Mapping Facilities  . . . . .  64
     15.6.  Disruption and Denial-of-Service Attacks . . . . . . . .  65
       15.6.1.  Attacks Based on the Disruption of Client-Server
               Shared State  . . . . . . . . . . . . . . . . . . . .  65
       15.6.2.  Attacks Based on Forcing the Misuse of Server
               Resources . . . . . . . . . . . . . . . . . . . . . .  65
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  65
     16.1.  New Authstat Values  . . . . . . . . . . . . . . . . . .  65
     16.2.  New Authentication Pseudo-Flavors  . . . . . . . . . . .  65
   17. Dummy Sections  . . . . . . . . . . . . . . . . . . . . . . .  66
     17.1.  Dummy Section AUTHFA-acl-ace . . . . . . . . . . . . . .  66
     17.2.  Dummy Section AUTHFA-acl-aclsupport  . . . . . . . . . .  66
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  66
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  66
     18.2.  Informative References . . . . . . . . . . . . . . . . .  67
   Appendix A.  Changes Made . . . . . . . . . . . . . . . . . . . .  67
     A.1.  Motivating Changes  . . . . . . . . . . . . . . . . . . .  67
     A.2.  Other Changes . . . . . . . . . . . . . . . . . . . . . .  68
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  70

1.  Overview

   This document presents a new approach to security for the NFSv4
   protocols, which, although building on previous treatments of these
   issues, diverges substantially from them in a number of respects.

   A new treatment is necessary because:

   *  Previous treatments paid insufficient attention to security issues
      regarding data in flight.





Noveck                    Expires 3 March 2022                  [Page 4]


Internet-Draft               Nfsv4 Security                  August 2021


   *  The presentation of AUTH_SYS as an "'OPTIONAL' means of
      authentication" obscured the severe security problems that come
      with its use.

   *  The security considerations sections of existing minor version
      specifications contain no threat analyses and focus on particular
      security issues in a way that obscures, rather than clarifying,
      the security issues that need to be addressed.

   *  The availability of RPC-with-TLS (described in [12]) provides
      facilities that NFSv4 clients and servers will need to use to
      provide security for data in flight and mitigate the lack of
      authentication when AUTH_SYS is used.

   The first version of this preliminary document contained many notes
   with headers in brackets, requesting comments regarding confusing or
   otherwise dubious passages in existing documents and other choices
   that needed to made.  Comments and working group discussion of these
   issues will be important in arriving at an adequate RFC candidate.
   In this version, those specific have been removed and changes to
   address these issues are listed in Appendix A.2 while a few issues
   that probably require further discussion to arrive at consensus are
   discussed in Section 3.4.

   In order to make further progress on these difficult issues,
   including many whose resolution will probably involve compatibility
   issues with existing implementations, the author has tried his best
   to resolve these issues, even though there is no assurance that the
   resolution adopted by consensus will match the author's curret best
   efforts.  To provide a possible resolution that might be the basis of
   discussion while not foreclosing other possibilities, the following
   annotations will be used:

   *  A paragraph headed "[Previous Treatment]:", indicates text that is
      provided for context but which the author believes, should not
      appear in the eventual RFC.

   *  A paragraph headed "[Author Aside]:", provides the author's
      comments about possible changes and will probable not appear in
      the eventual RFC.

   *  A paragraph headed "[Consensus Needed]:", provides the author's
      preferred tratment of the matter and should only appear in the
      eventual RFC.







Noveck                    Expires 3 March 2022                  [Page 5]


Internet-Draft               Nfsv4 Security                  August 2021


   To deal with situations in which one of the above annotations would
   apply to all paragraphs of a section, that annotation may be used on
   the lead paragraph of the section with the paragraph text, "Applies
   to entire section."

2.  Requirements Language

2.1.  Keyword Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as specified in BCP 14 [1] [5] when,
   and only when, they appear in all capitals, as shown here.

2.2.  Special Considerations

   Because this document needs to revise previous treatments of its
   subject, it will need to cite previous treatments of issues that now
   need to be dealt with in a different way.  This will take the form of
   quotations from documents whose treatment of the subject is being
   obsoleted, most often direct but sometimes indirect as well.

   Such treatments in quotations will involve use of these BCP14-defined
   terms in two noteworthy ways:

   *  The term may have been used inappropriately (i.e not in accord
      with [1]), as has been the case for the "RECOMMENDED" attributes,
      which are in fact OPTIONAL.

      In such cases, the surrounding text will make clear that the
      quoted text has no normative effect.

      Some specific issues relating to this case are described below
      Section 6.2.

   *  The term may been used in accord with [1], although the resulting
      normative statement is now felt to be inappropriate.

      In such cases, the surrounding text will need to make clear that
      the text quoted is no longer to be considered normative, often by
      providing new text that conflicts with the quoted, previously
      normative, text.

      An important instance of this situation is the description of
      AUTH_SYS as an "OPTIONAL" means of authentication.  For detailed
      discussion of this case, see Sections 12 and 15.1.4





Noveck                    Expires 3 March 2022                  [Page 6]


Internet-Draft               Nfsv4 Security                  August 2021


3.  Introduction

   Because the basic approach to security issues is so similar for all
   minor versions, this document applies to all NFSv4 minor versions.
   The details of this transition are discussed in Sections 3.1 and 3.2

   This document is able to take a new approach to security issues
   because of the work that has been done to provide security features
   at the transport level, rather than providing security features only
   by making choices with regard to the authentication flavor and
   associated mechanisms and services.  The effect of this shift is
   summarized in Section 3.3.

3.1.  Handling of Multiple Minor Versions

   In some cases, there are differences between minor versions in that
   there are security-related features, not present in all minor
   versions.

   To deal with this issue, this document will focus on a few major
   areas listed below which are common to all minor versions.

   *  File access authorization (discussed in Section 6) is the same in
      all minor versions together with the identification/
      authentication infrastructure supporting it (discussed in
      Section 12) provided by RPC and applying to all of NFS.

      An exception is made regarding labelled NFS, an optional feature
      within NFSv4.2, described in [10].  This is discussed as a
      version-specific feature in this document in Section 9

   *  Features to secure data in-flight, all provided by RPC, together
      with the negotiation infrastructure to support them are common to
      all NFSv4 minor versions, are discussed in Section 14

      However, the use of SECINFO_NONAME, together with changes needed
      for transport level encryption, paralleling those proposed here
      for SECINFO, is treated as a version-specific feature and, while
      mentioned here, will be fully documented in new v4.1 specification
      documents.

   *  The Protection of state data from unauthorized modification is
      discussed in Section 10) is the same in all minor versions
      together with the identification/ authentication infrastructure
      supporting it (discussed in Section 12) provided by secure
      transports such as RPC-over-TLS.





Noveck                    Expires 3 March 2022                  [Page 7]


Internet-Draft               Nfsv4 Security                  August 2021


      It should be noted that state protection based on RPCSEC_GSS is
      treated as a version-specific feature and will continue to be
      described by [8] or its successors.  Also, it needs to be noted
      that the use of state protection is not discussed in [6].

3.2.  Handling of Minor-version-specific features

   There are a number of areas in which security features differ among
   minor versions, as discussed below.  In some cases, a new feature
   requires specific security support while in others one version will
   have a new feature related to enhancing the security infrastructure.

   How such features are dealt with in this document depends on the
   specific feature.

   *  In addition to SECINFO, whose enhanced description appears in this
      document, NFSv4.1 added a new SECINFO_NONAME operation, useful for
      pNFS file as well as having some non-pNFS uses.

      While the enhanced description of SECINFO mentions SECINFO_NONAME,
      this is handled as one of a number of cases in which the
      description has to indicate that different actions need to be
      taken for different minor versions.

      The definitive description of SECINFO_NONAME, now appearing in
      RFC8881 needs to be modified to match the description of SECINFO
      appearing in this document.  It is expected that this will be done
      as part of the rfc5661bis process.

      The security implications of the security negotiation facilities
      as a whole will be addressed in the security considerations
      section of this document.

   *  The pNFS optional feature added in NFSv4.1 has its own security
      needs which parallel closely those of non-pNFS access.  As a
      result, these needs and the means to satisfy them are not
      discussed in this document.

      The definitive description of pNFS security will remain in RFC8881
      and its successors (i.e. the rfc5661bis document suite).  However,
      because pNFS security relies heavily on the infrastructure
      discussed here, it is anticipated that the new treatment of pNFS
      security will deal with many matters by referencing the overall
      NFS security document.

      The security considerations section of rfc5661bis will deal with
      pNFS security issues.




Noveck                    Expires 3 March 2022                  [Page 8]


Internet-Draft               Nfsv4 Security                  August 2021


   *  In addition to the state protection facilities described in this
      document, NFS has another set of such facilities that are not
      usable in NFSv4.0.

      While this document will discuss the security implications of
      protection against state modification, it will not discuss the
      details of the v4.1-specific features to accomplish it.

   *  The additional v4.1 acl attributes, sacl and dacl, are mentioned
      in this document, but do not affect the treatment of security,
      since the acl entries, whether in the acl attribute or separated
      into sacl and dacl attributes continue to have the same effect.

   *  Nfsv4.1 introduced detailed description of methods of co-
      ordinating the values of the authorization-related attributes mode
      and acl.  this is in contrast to Nfsv4.0, which while expecting
      such coordination to be provide somehow, did not provide any
      details, allowing a number of different approaches to meet the
      goal of providing appropriate co-ordination.

      This document will provide separate sections describing each of
      the approaches, together with a common section describing the
      goals of providing co-ordination when both are supported.

      As a result, this document will override the treatment within
      RFC8881 and this material will be removed in the rfc5661bis
      document suite and replaced by a reference to the treatment in the
      NFSv4 security RFC.

      Similarly, this document will supersede the corresponding
      treatment in RFC7530 as well.  As a result, v4.0 server
      implementers reading any successor document will be aware of the
      possibility of the v4.1 approach even though it is clear that this
      is only one of the possible approaches to this issue.  V4.1 client
      implementers will be made aware of the goals and that there is
      little that can be relied upon with regard to v4.0 servers'
      attempts to address those goals.

   *  The protocol extension defined in [13], now part of NFSv4.2, is
      also related to the issue of co-ordination of acl and mode
      attributes and will be discussed in that context.

      Nevertheless, the description in [13] will remain definitive.

   *  The the v4.1 attribute set-mode-masked attribute is mentioned
      together with the other attributes implementing the POSIX
      authorization model.




Noveck                    Expires 3 March 2022                  [Page 9]


Internet-Draft               Nfsv4 Security                  August 2021


      Because this attribute. while related to security, does not
      substantively modify the security properties of the protocol, the
      full description of this attribute, will continue to be the
      province of the v4.1 specification proper.

   *  There is a brief description of the v4.2 Labelled NFS feature in
      Section 9.  Part of that description discusses the limitations in
      the description of that feature within [10].

      Because of some limitations in the description, it is not possible
      to provide an appropriate security considerations section for that
      feature in this document.

      As a result, the responsibility to provide an appropriate Security
      Considerations section remains, unrealized for now, with the
      NFSv4.2 specification document.

3.3.  Transport-based Security Features

   There are a number of security-related facilities that can be
   provided at the transport layer eliminating the need for or or
   proving support to processing done as part of RPC proper.

   These will initially be provided by RPC-over-TLS but similar
   facilities might be provided on new versions of existing transports
   or new RPC transports.

   *  The transport might provide encryption of requests and replies,
      eliminating the need for privacy and integrity services to be
      negotiated later and applied on a per-request basis.

      While clients might choose to establish connections with such
      encryption, servers can establish policies allowing access to
      certain pieces of the namespace using such transports, or limiting
      access to those providing privacy, allowing the use of either
      transport-based encryption or privacy services provided by
      RPCSEC_GSS.

   *  The transport might provide mutual authentication of the client
      and server peers as part of the establishment of the connection
      This authentication is distinct from the the mutual authentication
      of the client user and server peer, implemented within the
      GSSSEC_RPC framework.

      This form of authentication is of particular importance when the
      when the server allows the use of the flavors AUTH_SYS and
      AUTH_NONE, which have no provision for the authentication of the
      user requesting the operation.



Noveck                    Expires 3 March 2022                 [Page 10]


Internet-Draft               Nfsv4 Security                  August 2021


      While clients might choose to establish connections with such peer
      authentication, servers can establish policies a limiting access
      to certain pieces of the namespace without such peer
      authentication or only allowing it using RPCSEC_GSS.

   To enable server policies to be effectively communicated to clients,
   the security negotiation framework now allows connection
   characteristics to be specified using pseudo-flavors.  See Section 14
   for details.

3.4.  Issues Yet to be Fully Decided

   {author Aside]: Applies to entire section.

   For a number of reasons, it is necessary for the treatment of certain
   aspects to change, even though we strive in this new treatment for
   compatibility.  In some cases, this is because the existing treatment
   is unclear, is inconsistent, or uses keywords defined in RFC2119 in
   an inappropriate way.  See Appendix A.2 for a detailed list.

   Because the existing specifications, at least notionally, represent a
   working group consensus, it important to verify that there is a
   working group consensus to adopt the modified treatment and the list
   of changes together with notes in ealier versions of this document
   should prompt discussion that will confirm the modified treatment or
   indicate another approach should be adopted.  In most such cases, the
   author believes that the changes already made deserve to be confirmed
   by the working group.

   There are, however, a number of complex cases in which the author has
   done the best he could but is unsure about the resolution to be
   adopted, principally because of uncertinty about compatibility issues
   with existing v4.0 and v4.1 implementations.  These difficult cases
   are discussed below.

   There is considerable confusion/uncertainty about what sets of ACE
   types a server may validly support.

   *  It had been stated in Section 17.2 that "Servers that support
      either the ALLOW or DENY ACE type SHOULD support both ALLOW and
      DENY ACE types" but it is not made clear why this recommendation
      is made or what might be valid reasons to disregard it (as
      provided by the definition of "SHOULD").








Noveck                    Expires 3 March 2022                 [Page 11]


Internet-Draft               Nfsv4 Security                  August 2021


   *  There appears to be a need, when the mode attribute is set, to be
      prepared to return an equivalent acl, it appears that supporting
      ALLOW without DENY is not viable, since a mode that only allowed
      "others" to read a file cannot be represented by an ACL with only
      ALLOW entries.

      This would justify a statement like the one quoted above using
      MUST but is clearly inconsistent with the SHOULD above.

   *  While it is possible to tie these together, the structure of the
      aclsupport attribute is inconsistent with this.

   *  In any case, we would need to provide guidance to the client as to
      dealing with servers that support ALLOW or DENY but not both.

   The current text, while not using RFC2119 keywords, indicates why it
   is desirable to implement both of these or neither.  The client is
   only to use the acl-based authorization model if both ALLOW and DENY
   ACEs are supported.

   There are inconsistent discussions leading to confusion about dealing
   with acls that cannot be enforced.

   *  Section xxx of the previous version of this I-D dealt with this
      issue by indicating that the acl presented by the client is to be
      revised into one which can be enforced.

      The treatment in this section manifests an extraordinary degree of
      solicitude about hypothesized server implementations that do not
      support the NFSv4 ACL model but support a diferent authorization
      model which is finer-grained than that provided by mode but not as
      rich as that of the NFSv4 ACL model.  The difficulties that the
      consequent uncertainty would create for clients and applications
      is essentially ignored.

      Somewhat implausibly, the section speculates about file systems
      whose inability to support the NFSv4 ACL model derives from an
      inability to treat differently writes that extend the file and
      those that don't.

      There is a discussion of possible complications that derive from
      of use of NFSv4 ACLs in a multiprotocol environment, in which the
      use of the term "modules" obscures the necessary distinction
      between matters relating to NFSv4 are dealt with in this document,
      while those for other protocols have to be considered out of
      scope.





Noveck                    Expires 3 March 2022                 [Page 12]


Internet-Draft               Nfsv4 Security                  August 2021


   *  In Section 17.2, it is stated that "a servers SHOULD reject acls
      it cannot enforce"

      It is not clear what the harm jutifying the use of "SHOULD" might
      be and what the valid reasons to do otherise might be.

   The possibility of making the handling of co-ordination of modes and
   acls case minor-version-independent need be considered.


   Although not dealt with in the current document, there are a number
   of similar issues which will need to be addressed in a future version
   of this I-D.

   *  The requirents regarding support for LIPKEY, etc.

   *  The specific detail for Kerberos support are currently different
      and the possibility of bringing them into aligment needs to be
      seriously considered.

4.  Structure of Access Control Lists

   Access Control Lists consisting of multiple Access Control Elements,
   while originally designed to support a more flexible authorization
   model, have multiple uses within NFSv4, with the use of each element
   depending on its type, as defined in Section 4.2

   *  They may be used to provide a more flexible authorization model as
      described in Section 6.4.  This involves use of Access Control
      Entries of the ALLOW and DENY types.

   *  They may be used to provide the security-related services
      described in Section 11.  This involves use of Access Control
      Entries of the AUDIT and ALARM types.

   Subsections of this section define the structure of ACLs and discuss
   ACL-related matters that apply to multiple types of ACL use,
   including the definitions of the acl and aclsupport attributes.

   Matters that relate to only a single one of these use classes,
   including the defiition of the v4.1-specific attributes dacl and sacl
   are discussed in subsections of Sections 6.4 or 11.









Noveck                    Expires 3 March 2022                 [Page 13]


Internet-Draft               Nfsv4 Security                  August 2021


4.1.  Access Control Entries

   The attributes acl, sacl (v4.1 only) and dacl (v4.1 only) each
   contain an array of Access Control Entries (ACEs) that are associated
   with the file system object.  The client can set and get these
   attributes attribute, the server is responsible for using the ACL-
   related attributes to perform access control.  The client can use the
   OPEN or ACCESS operations to check access without modifying or
   explicitly reading data or metadata.

   The NFS ACE structure is defined as follows:

   typedef uint32_t        acetype4;

   typedef uint32_t aceflag4;

   typedef uint32_t        acemask4;

   struct nfsace4 {
           acetype4        type;
           aceflag4        flag;
           acemask4        access_mask;
           utf8str_mixed   who;
   };

4.2.  ACE Type

   The constants used for the type field (acetype4) are as follows:

   const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
   const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
   const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
   const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

   All four are permitted in the acl attribute.  For v4.1 and beyond,
   only the ALLOWED and DENIED types may be used in the dacl attribute,
   and only the AUDIT and ALARM types.x used in the sacl attribute.














Noveck                    Expires 3 March 2022                 [Page 14]


Internet-Draft               Nfsv4 Security                  August 2021


   +==============================+==============+====================+
   | Value                        | Abbreviation | Description        |
   +==============================+==============+====================+
   | ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW        | Explicitly grants  |
   |                              |              | the ability to     |
   |                              |              | perform the action |
   |                              |              | specfied in        |
   |                              |              | acemask4 to the    |
   |                              |              | file or directory. |
   +------------------------------+--------------+--------------------+
   | ACE4_ACCESS_DENIED_ACE_TYPE  | DENY         | Explicitly denies  |
   |                              |              | the ability to     |
   |                              |              | perform the action |
   |                              |              | specfied in        |
   |                              |              | acemask4 to the    |
   |                              |              | file or directory. |
   +------------------------------+--------------+--------------------+
   | ACE4_SYSTEM_AUDIT_ACE_TYPE   | AUDIT        | Log (in a system-  |
   |                              |              | dependent way) any |
   |                              |              | attempt to         |
   |                              |              | perform, for the   |
   |                              |              | file or directory, |
   |                              |              | any of the actions |
   |                              |              | specified in       |
   |                              |              | acemask4.          |
   +------------------------------+--------------+--------------------+
   | ACE4_SYSTEM_ALARM_ACE_TYPE   | ALARM        | Generate an alarm  |
   |                              |              | (in a system-      |
   |                              |              | dependent way) any |
   |                              |              | attempt to         |
   |                              |              | perform, for the   |
   |                              |              | file or directory, |
   |                              |              | any of the actions |
   |                              |              | specified in       |
   |                              |              | acemask4.          |
   +------------------------------+--------------+--------------------+

                                 Table 1

   The "Abbreviation" column denotes how the types will be referred to
   throughout the rest of this document.

5.  Authorization in General

   There are three distinct methods of checking whether NFSv4 requests
   are authorized:





Noveck                    Expires 3 March 2022                 [Page 15]


Internet-Draft               Nfsv4 Security                  August 2021


   *  The most important method of authorization is used to effect user-
      based file access control, as described in Section 6.

      This requires the identification of the user making the request.
      Because of the central role of such access control in providing
      NFSv4 security, server implementations SHOULD NOT use such
      identifications when they are not authenticated.  In this context,
      valid reasons to do otherwise are limited to the compatibility and
      maturity issues discussed in Section 15.1.3

   *  NFSv4.2, via the labelled NFS feature, provides an additional
      potential requirement for request authorization.

      For reasons made clear in Section 9, there is no realistic
      possibility of the server using the data defined by existing
      specifications of this feature to effect request authorization.
      While it is possible for clients to provide this authorization,
      the lack of detailed specifications makes it impossible to
      determine the nature of the identification used and whether it can
      appropriately be described as "authentication".

   *  Since undesired changes to server-mintained locking state (and,
      for NFSv4.1, session state) can result in denial of service
      attacks (see Section 15.6), server implementations SHOULD take
      steps to prevent unauthorized state changes.  This can be done by
      implementing the state authorization restrictions discussed in
      Section 10

6.  User-based File Access Authorization

6.1.  Handling of Multiple Parallel File Access Authorization Models

   ACLs and modes represent two well-established models for specifying
   user-based file access permissions.  NFSv4 provides support for
   either or both depending on the attributes supported by the server:

   *  When the attributes mode, owner, owner group are all supported,
      the posix-based authorization model, described in Section 6.3 can
      be used.

   *  [Consensus Needed (Item #1a)]: When the acl (or dacl) attribute is
      supported together with both of the ACE types ALLOW and DENY, the
      acl based authorization model, described in Section 6.4 can be
      used as long as the attributes owner and owner group are also
      supported.






Noveck                    Expires 3 March 2022                 [Page 16]


Internet-Draft               Nfsv4 Security                  August 2021


   While formally recommended (essentially OPTIONAL) attributes, it
   appears that the owner and owner_group attributes need to be
   available to support any file access authorization model.  As a
   result, this document will not discuss the possibility of servers
   that do not support both of these attributes and clients have no need
   to support such servers.

   When both authorization models can be used, there are difficulties
   that can arise because the ACL-based model provides finer-grained
   access control than the POSIX model.  The ways of dealing with these
   difficulties appear later in this section while more detail on the
   appropriate handling of this situation, which might depend on the
   minor version used, appears in Section 8.

   The following describe NFSv4's handling in supporting multiple
   authorization models for file access.

   *  If a server supports the mode attribute, it should provide the
      appropriate POSIX semantics to clients that only set and retrieve
      the mode attribute.

   *  If a server supports ACL attributes, it should provide ACL
      semantics as described in this document to clients that only set
      and retrieve those attributes.

   *  On servers that support the mode attribute, if ACL attributes have
      never been set on an object, via inheritance or explicitly, the
      behavior should be the behavior mandated by POSIX.

   *  On servers that support the mode attribute, if the ACL attributes
      have been previously set on an object, either explicitly or via
      inheritance:

      -  [Previous Treatment]: Setting only the mode attribute should
         effectively control the traditional UNIX-like permissions of
         read, write, and execute on owner, owner_group, and other.

         [Author Aside]: It isn't really clear what the above paragraph
         means, especially as it governs the handling of aces
         designating specific users and groups which are not the owner
         and have no overlap with the owning










Noveck                    Expires 3 March 2022                 [Page 17]


Internet-Draft               Nfsv4 Security                  August 2021


         {Consenses Needed (Item #3)]: Setting only the mode attribute,
         should result in the access of the file being controlled just
         it would be if the existing acl did not exist, when decisions
         as to reading writing and executing the file.  The ALLOW and
         DENY aces in the ACL should reflect the modified security
         although there is no need to modify AUDIT and ALARM aces or
         mask bits not affected by the mode bits, such as SYNCHRONIZE.

      -  [Previou Treatment]: Setting only the mode attribute should
         provide reasonable security.  For example, setting a mode of
         000 should be enough to ensure that future OPEN operations for
         OPEN4_SHARE_ACCESS_READ or OPEN4_SHARE_ACCESS_WRITE by any
         principal fail, regardless of a previously existing or
         inherited ACL.

         [Author Aside]: We need some replacement for the subjective
         first sentence.  While the specific example give is
         unexceptionable, it raises question about other case in which
         what constitutes "reasonable semantics.  While that question is
         subject to dispute, the author believes consenses item #3 deals
         with the matter adequately.

   *  NFSv4.1 describes specfic semantic requirements relating to the
      interaction of mode and ACL attributes, which do contract the
      goals listed above.  As a result, the handling provided by servers
      of different minor version might well be different, as discussed
      below.

   In regard to the interaction of the mode and ACL attributes:

   *  As discussed in Section 8.1, the specific semantic requirements
      specified for v4.1 could be adopted by v4.0, although some
      modification might be necessary to deal with the absence of the
      mode_set_masked attribute.

      V4.0 clients would have to be able to interact with servers that
      different approaches to these goals.

   *  V4.1 servers have specific rules for handling these issues as
      discussed in Section 8.2.  However, despite this, the rules are,
      in many places, fairly loosely drawn and allow a range of server
      behaviors.

   *  To deal with issues related to the perceived overuse of modes
      derived from the umask in vitiating needed acl inheritance, a V4.2
      extension was provided, allowing the separation of the
      application-specifed mode from the umask.  This is discussed in
      Section 8.3



Noveck                    Expires 3 March 2022                 [Page 18]


Internet-Draft               Nfsv4 Security                  August 2021


6.2.  Attributes for User-based File Access Authorization

   NFSv4.1 provides for multiple authentication models, controlled by
   the support for particular recommended attributes implemented by the
   server, as discussed below:

   *  Consensus Needed (Item #2)]: The attributes owner, owning_group,
      and mode enable use of a POSIX-based authorization model, as
      described in Section 6.3.  When all of these attributes are
      supported, this authorization model can be implemented.

      Consensus Needed (Item #2)]:When none of these attributes or only
      a proper subset of them are supported, this authorization model is
      unavailable.

   *  [Consensus Needed (Item #1b)]: The acl attribute (or the attribute
      dacl in v4.1) can provide an ACL-based authorization model as
      described in Section 6.4 as long as support for ALLOW and DENY
      ACEs is provided.

      Consensus Needed (Items #1b,2)]: When some of these ACE types are
      not supported or the owner or owning_group attribute is not
      supported, this authorization model is unavailable.

6.3.  Posix Authorization Model

6.3.1.  Attribute 33: mode

   The NFSv4.1 mode attribute is based on the UNIX mode bits.  The
   following bits are defined:

   const MODE4_SUID = 0x800;  /* set user id on execution */
   const MODE4_SGID = 0x400;  /* set group id on execution */
   const MODE4_SVTX = 0x200;  /* save text even after use */
   const MODE4_RUSR = 0x100;  /* read permission: owner */
   const MODE4_WUSR = 0x080;  /* write permission: owner */
   const MODE4_XUSR = 0x040;  /* execute permission: owner */
   const MODE4_RGRP = 0x020;  /* read permission: group */
   const MODE4_WGRP = 0x010;  /* write permission: group */
   const MODE4_XGRP = 0x008;  /* execute permission: group */
   const MODE4_ROTH = 0x004;  /* read permission: other */
   const MODE4_WOTH = 0x002;  /* write permission: other */
   const MODE4_XOTH = 0x001;  /* execute permission: other */

   Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal
   identified by the owner attribute.  Bits MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP apply to principals belonging to the group identified in
   the owner_group attribute but who are not identified by the owner



Noveck                    Expires 3 March 2022                 [Page 19]


Internet-Draft               Nfsv4 Security                  August 2021


   attribute.  Bits MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH apply to any
   principal that does not match that in the owner attribute and does
   not belong to a group matching that of the owner_group attribute.
   These nine bits are used in providing authorization information.

   The bits MODE4_SUID, MODE4_SGID, and MODE4_SVTX do not provide
   authorization information and do not affect server behavior.
   Instead, they are acted on by the client just as they would be for
   corresponding mode bits obtained from local file systems.

   Bits within a mode other than those specified above are not defined
   by this protocol.  A server MUST NOT return bits other than those
   defined above in a GETATTR or READDIR operation, and it MUST return
   NFS4ERR_INVAL if bits other than those defined above are set in a
   SETATTR, CREATE, OPEN, VERIFY, or NVERIFY operation.

6.3.2.  V4.1 Attribute 74: mode_set_masked

   The mode_set_masked attribute is a write-only attribute that allows
   individual bits in the mode attribute to be set or reset, without
   changing others.  It allows, for example, the bits MODE4_SUID,
   MODE4_SGID, and MODE4_SVTX to be modified while leaving unmodified
   any of the nine low-order mode bits devoted to permissions.

   In instances such that none of the nine low-order bits are subject to
   modification, then neither the acl nor the dacl attribute should be
   automatically modified as discussed in Sections 8.2.4 and 8.2.6.

   The mode_set_masked attribute consists of two words, each in the form
   of a mode4.  The first consists of the value to be applied to the
   current mode value and the second is a mask.  Only bits set to one in
   the mask word are changed (set or reset) in the file's mode.  All
   other bits in the mode remain unchanged.  Bits in the first word that
   correspond to bits that are zero in the mask are ignored, except that
   undefined bits are checked for validity and can result in
   NFS4ERR_INVAL as described below.

   The mode_set_masked attribute is only valid in a SETATTR operation.
   If it is used in a CREATE or OPEN operation, the server MUST return
   NFS4ERR_INVAL.

   Bits not defined as valid in the mode attribute are not valid in
   either word of the mode_set_masked attribute.  The server MUST return
   NFS4ERR_INVAL if any such bits are set to one in a SETATTR.  If the
   mode and mode_set_masked attributes are both specified in the same
   SETATTR, the server MUST also return NFS4ERR_INVAL.





Noveck                    Expires 3 March 2022                 [Page 20]


Internet-Draft               Nfsv4 Security                  August 2021


6.4.  ACL-based Authorization Model

6.4.1.  Processing Access Control Entries

   To determine if a request succeeds, the server processes each nfsace4
   entry of type ALLOW or DENY in turn as ordered in the array.  Only
   ACEs that have a "who" that matches the requester are considered.  An
   ACE is considered to match a given requester if at least one of the
   following is true:

   *  The "who' designates a specific user which is the user making the
      request.

   *  The "who" specifies "OWNER@" and the user making the request is
      the owner of the file.

   *  The "who" designates a specific group and the user making the
      request is a member of that group.

   *  The "who" specifies "GROUP@" and the user making the request is a
      member of the group owning the file.

   *  The "who" specifies "EVERYONE@".

   *  The "who" specifies "INTERACTIVE@", "NETWORK@", "DIALUP@",
      "BATCH@", or "SERVICE@" and the requester, in the judgment of the
      server, feels that designation appropriately describes the
      requester.

   *  The "who" specifies "ANONYMOUS@" or "AUTHENTICATED@" and the
      requestor's authentication status matches the who, using the
      definitions in Section 6.4.7

   Each ACE is processed until all of the bits of the requester's access
   have been ALLOWED.  Once a bit (see below) has been ALLOWED by an
   ACCESS_ALLOWED_ACE, it is no longer considered in the processing of
   later ACEs.  If an ACCESS_DENIED_ACE is encountered where the
   requester's access still has unALLOWED bits in common with the
   "access_mask" of the ACE, the request is denied.  When the ACL is
   fully processed, if there are bits in the requester's mask that have
   not been ALLOWED or DENIED, access is denied.

   Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE types do
   not affect a requester's access, and instead are for triggering
   events as a result of a requester's access attempt.  AUDIT and ALARM
   ACEs are processed only after processing ALLOW and DENY ACEs if any
   exist.




Noveck                    Expires 3 March 2022                 [Page 21]


Internet-Draft               Nfsv4 Security                  August 2021


   [Previous Treatment]: The NFSv4.1 ACL model is quite rich.  Some
   server platforms may provide access-control functionality that goes
   beyond the UNIX-style mode attribute, but that is not as rich as the
   NFS ACL model.  So that users can take advantage of this more limited
   functionality, the server may support the acl attributes by mapping
   between its ACL model and the NFSv4.1 ACL model.  Servers must ensure
   that the ACL they actually store or enforce is at least as strict as
   the NFSv4 ACL that was set.  It is tempting to accomplish this by
   rejecting any ACL that falls outside the small set that can be
   represented accurately.  However, such an approach can render ACLs
   unusable without special client-side knowledge of the server's
   mapping, which defeats the purpose of having a common NFSv4 ACL
   protocol.  Therefore, servers should accept every ACL that they can
   without compromising security.  To help accomplish this, servers may
   make a special exception, in the case of unsupported permission bits,
   to the rule that bits not ALLOWED or DENIED by an ACL must be denied.
   For example, a UNIX-style server might choose to silently allow read
   attribute permissions even though an ACL does not explicitly allow
   those permissions.  (An ACL that explicitly denies permission to read
   attributes should still be rejected.)

   [Author Aside]: While the NFSv4.1 provides that many might not need
   or use, it is the one that the working group adopted by the working
   group, and I have to assume that alternatives, such as the withdrawn
   POSIX ACL proposal were considered but not adopted.  The phrase
   "unsupported permission bits" with no definition of the bit whose
   support might be dispemsed with implies that the server is free to
   support whatever subset of these bits it chooses.  As a result,
   clients would not be able to rely on a functioning server
   implementation of theis OPTIONAL> IF there are specfic compatibility
   issues that make it necessary to allow non-support of specfic mask
   bits, then these need to be limited and the client needs guidance
   about determining the set of unsupported mask bits.

   [Previous Treatment]: The situation is complicated by the fact that a
   server may have multiple modules that enforce ACLs.  For example, the
   enforcement for NFSv4.1 access may be different from, but not weaker
   than, the enforcement for local access, and both may be different
   from the enforcement for access through other protocols such as SMB
   (Server Message Block).  So it may be useful for a server to accept
   an ACL even if not all of its modules are able to support it.


   The guiding principle with regard to NFSv4 access is that the server
   must not accept ACLs that appear to make access to the file more
   restrictive than it really is.





Noveck                    Expires 3 March 2022                 [Page 22]


Internet-Draft               Nfsv4 Security                  August 2021


6.4.2.  ACE Access Mask

   The bitmask constants used for the access mask field are as follows:

   const ACE4_READ_DATA            = 0x00000001;
   const ACE4_LIST_DIRECTORY       = 0x00000001;
   const ACE4_WRITE_DATA           = 0x00000002;
   const ACE4_ADD_FILE             = 0x00000002;
   const ACE4_APPEND_DATA          = 0x00000004;
   const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
   const ACE4_READ_NAMED_ATTRS     = 0x00000008;
   const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
   const ACE4_EXECUTE              = 0x00000020;
   const ACE4_DELETE_CHILD         = 0x00000040;
   const ACE4_READ_ATTRIBUTES      = 0x00000080;
   const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
   const ACE4_WRITE_RETENTION      = 0x00000200;
   const ACE4_WRITE_RETENTION_HOLD = 0x00000400;

   const ACE4_DELETE               = 0x00010000;
   const ACE4_READ_ACL             = 0x00020000;
   const ACE4_WRITE_ACL            = 0x00040000;
   const ACE4_WRITE_OWNER          = 0x00080000;
   const ACE4_SYNCHRONIZE          = 0x00100000;

   Note that some masks have coincident values, for example,
   ACE4_READ_DATA and ACE4_LIST_DIRECTORY.  The mask entries
   ACE4_LIST_DIRECTORY, ACE4_ADD_FILE, and ACE4_ADD_SUBDIRECTORY are
   intended to be used with directory objects, while ACE4_READ_DATA,
   ACE4_WRITE_DATA, and ACE4_APPEND_DATA are intended to be used with
   non-directory objects.

6.4.3.  Details Regarding Mask Bits

   ACE4_READ_DATA

      Operation(s) affected:
         READ

         OPEN

      Discussion:
         Permission to read the data of the file.

         Servers SHOULD allow a user the ability to read the data of the
         file when only the ACE4_EXECUTE access mask bit is allowed.

   ACE4_LIST_DIRECTORY



Noveck                    Expires 3 March 2022                 [Page 23]


Internet-Draft               Nfsv4 Security                  August 2021


      Operation(s) affected:
         READDIR

      Discussion:
         Permission to list the contents of a directory.

   ACE4_WRITE_DATA

      Operation(s) affected:
         WRITE

         OPEN

         SETATTR of size

      Discussion:
         Permission to modify a file's data.

   ACE4_ADD_FILE

      Operation(s) affected:
         CREATE

         LINK

         OPEN

         RENAME

      Discussion:
         Permission to add a new file in a directory.  The CREATE
         operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
         NF4CHR, NF4SOCK, or NF4FIFO.  (NF4DIR is not listed because it
         is covered by ACE4_ADD_SUBDIRECTORY.)  OPEN is affected when
         used to create a regular file.  LINK and RENAME are always
         affected.

   ACE4_APPEND_DATA

      Operation(s) affected:
         WRITE

         OPEN

         SETATTR of size






Noveck                    Expires 3 March 2022                 [Page 24]


Internet-Draft               Nfsv4 Security                  August 2021


      Discussion:
         The ability to modify a file's data, but only starting at EOF.
         This allows for the specification of append-only files, by
         allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to the
         same user or group.  If a file has an ACL such as the one
         described above and a WRITE request is made for somewhere other
         than EOF, the server SHOULD return NFS4ERR_ACCESS.

   ACE4_ADD_SUBDIRECTORY

      Operation(s) affected:
         CREATE

         RENAME

      Discussion:
         Permission to create a subdirectory in a directory.  The CREATE
         operation is affected when nfs_ftype4 is NF4DIR.  The RENAME
         operation is always affected.

   ACE4_READ_NAMED_ATTRS

      Operation(s) affected:
         OPENATTR

      Discussion:
         Permission to read the named attributes of a file or to look up
         the named attribute directory.  OPENATTR is affected when it is
         not used to create a named attribute directory.  This is when
         1) createdir is TRUE, but a named attribute directory already
         exists, or 2) createdir is FALSE.

   ACE4_WRITE_NAMED_ATTRS

      Operation(s) affected:
         OPENATTR

      Discussion:
         Permission to write the named attributes of a file or to create
         a named attribute directory.  OPENATTR is affected when it is
         used to create a named attribute directory.  This is when
         createdir is TRUE and no named attribute directory exists.  The
         ability to check whether or not a named attribute directory
         exists depends on the ability to look it up; therefore, users
         also need the ACE4_READ_NAMED_ATTRS permission in order to
         create a named attribute directory.

   ACE4_EXECUTE



Noveck                    Expires 3 March 2022                 [Page 25]


Internet-Draft               Nfsv4 Security                  August 2021


      Operation(s) affected:
         READ

         OPEN

         REMOVE

         RENAME

         LINK

         CREATE

      Discussion:
         Permission to execute a file.

         Servers SHOULD allow a user the ability to read the data of the
         file when only the ACE4_EXECUTE access mask bit is allowed.
         This is because there is no way to execute a file without
         reading the contents.  Though a server may treat ACE4_EXECUTE
         and ACE4_READ_DATA bits identically when deciding to permit a
         READ operation, it SHOULD still allow the two bits to be set
         independently in ACLs, and MUST distinguish between them when
         replying to ACCESS operations.  In particular, servers SHOULD
         NOT silently turn on one of the two bits when the other is set,
         as that would make it impossible for the client to correctly
         enforce the distinction between read and execute permissions.

         As an example, following a SETATTR of the following ACL:

            nfsuser:ACE4_EXECUTE:ALLOW

         A subsequent GETATTR of ACL for that file SHOULD return:

            nfsuser:ACE4_EXECUTE:ALLOW

         Rather than:

            nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW

   ACE4_EXECUTE

      Operation(s) affected:
         LOOKUP

      Discussion:
         Permission to traverse/search a directory.




Noveck                    Expires 3 March 2022                 [Page 26]


Internet-Draft               Nfsv4 Security                  August 2021


   ACE4_DELETE_CHILD

      Operation(s) affected:
         REMOVE

         RENAME

      Discussion:
         Permission to delete a file or directory within a directory.
         See Section 6.4.4 for information on ACE4_DELETE and
         ACE4_DELETE_CHILD interact.

   ACE4_READ_ATTRIBUTES

      Operation(s) affected:
         GETATTR of file system object attributes

         VERIFY

         NVERIFY

         READDIR

      Discussion:
         The ability to read basic attributes (non-ACLs) of a file.  On
         a UNIX system, basic attributes can be thought of as the stat-
         level attributes.  Allowing this access mask bit would mean
         that the entity can execute "ls -l" and stat.  If a READDIR
         operation requests attributes, this mask must be allowed for
         the READDIR to succeed.

   ACE4_WRITE_ATTRIBUTES

      Operation(s) affected:
         SETATTR of time_access_set, time_backup,

         time_create, time_modify_set, mimetype, hidden, system

      Discussion:
         Permission to change the times associated with a file or
         directory to an arbitrary value.  Also permission to change the
         mimetype, hidden, and system attributes.  A user having
         ACE4_WRITE_DATA or ACE4_WRITE_ATTRIBUTES will be allowed to set
         the times associated with a file to the current server time.

   ACE4_WRITE_RETENTION





Noveck                    Expires 3 March 2022                 [Page 27]


Internet-Draft               Nfsv4 Security                  August 2021


      Operation(s) affected:
         SETATTR of retention_set, retentevt_set.

      Discussion:
         Permission to modify the durations of event and non-event-based
         retention.  Also permission to enable event and non-event-based
         retention.  A server MAY behave such that setting
         ACE4_WRITE_ATTRIBUTES allows ACE4_WRITE_RETENTION.

   ACE4_WRITE_RETENTION_HOLD

      Operation(s) affected:
         SETATTR of retention_hold.

      Discussion:
         Permission to modify the administration retention holds.  A
         server MAY map ACE4_WRITE_ATTRIBUTES to
         ACE_WRITE_RETENTION_HOLD.

   ACE4_DELETE

      Operation(s) affected:
         REMOVE

      Discussion:
         Permission to delete the file or directory.  See Section 6.4.4
         for information on ACE4_DELETE and ACE4_DELETE_CHILD interact.

   ACE4_READ_ACL

      Operation(s) affected:
         GETATTR of acl, dacl, or sacl

         NVERIFY

         VERIFY

      Discussion:
         Permission to read the ACL.

   ACE4_WRITE_ACL

      Operation(s) affected:
         SETATTR of acl and mode

      Discussion:
         Permission to write the acl and mode attributes.




Noveck                    Expires 3 March 2022                 [Page 28]


Internet-Draft               Nfsv4 Security                  August 2021


   ACE4_WRITE_OWNER

      Operation(s) affected:
         SETATTR of owner and owner_group

      Discussion:
         Permission to write the owner and owner_group attributes.  On
         UNIX systems, this is the ability to execute chown() and
         chgrp().

   ACE4_SYNCHRONIZE

      Operation(s) affected:
         NONE

      Discussion:
         Permission to use the file object as a synchronization
         primitive for interprocess communication.  This permission is
         not enforced or interpreted by the NFSv4.1 server on behalf of
         the client.

         Typically, the ACE4_SYNCHRONIZE permission is only meaningful
         on local file systems, i.e., file systems not accessed via
         NFSv4.1.  The reason that the permission bit exists is that
         some operating environments, such as Windows, use
         ACE4_SYNCHRONIZE.

         For example, if a client copies a file that has
         ACE4_SYNCHRONIZE set from a local file system to an NFSv4.1
         server, and then later copies the file from the NFSv4.1 server
         to a local file system, it is likely that if ACE4_SYNCHRONIZE
         was set in the original file, the client will want it set in
         the second copy.  The first copy will not have the permission
         set unless the NFSv4.1 server has the means to set the
         ACE4_SYNCHRONIZE bit.  The second copy will not have the
         permission set unless the NFSv4.1 server has the means to
         retrieve the ACE4_SYNCHRONIZE bit.

   Server implementations need not provide the granularity of control
   that is implied by this list of masks.  For example, POSIX-based
   systems might not distinguish ACE4_APPEND_DATA (the ability to append
   to a file) from ACE4_WRITE_DATA (the ability to modify existing
   contents); both masks would be tied to a single "write" permission
   bit.  When such a server returns attributes to the client that
   contain such masks, it would show ACE4_APPEND_DATA and
   ACE4_WRITE_DATA if and only if the the write permission bit is
   enabled.




Noveck                    Expires 3 March 2022                 [Page 29]


Internet-Draft               Nfsv4 Security                  August 2021


   If a server receives a SETATTR request that it cannot accurately
   implement, it should err in the direction of more restricted access,
   except in the previously discussed cases of execute and read.  For
   example, suppose a server cannot distinguish overwriting data from
   appending new data, as described in the previous paragraph.  If a
   client submits an ALLOW ACE where ACE4_APPEND_DATA is set but
   ACE4_WRITE_DATA is not (or vice versa), the server should either turn
   off ACE4_APPEND_DATA or reject the request with NFS4ERR_ATTRNOTSUPP.

6.4.4.  ACE4_DELETE vs. ACE4_DELETE_CHILD

   Two access mask bits govern the ability to delete a directory entry:
   ACE4_DELETE on the object itself (the "target") and ACE4_DELETE_CHILD
   on the containing directory (the "parent").

   Many systems also take the "sticky bit" (MODE4_SVTX) on a directory
   to allow unlink only to a user that owns either the target or the
   parent; on some such systems the decision also depends on whether the
   target is writable.

   Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the
   target, or ACE4_DELETE_CHILD is permitted on the parent.  (Note that
   this is true even if the parent or target explicitly denies one of
   these permissions.)

   If the ACLs in question neither explicitly ALLOW nor DENY either of
   the above, and if MODE4_SVTX is not set on the parent, then the
   server SHOULD allow the removal if and only if ACE4_ADD_FILE is
   permitted.  In the case where MODE4_SVTX is set, the server may also
   require the remover to own either the parent or the target, or may
   require the target to be writable.

   This allows servers to support something close to traditional UNIX-
   like semantics, with ACE4_ADD_FILE taking the place of the write bit.

6.4.5.  ACE flag

   The bitmask constants used for the flag field are as follows:

   const ACE4_FILE_INHERIT_ACE             = 0x00000001;
   const ACE4_DIRECTORY_INHERIT_ACE        = 0x00000002;
   const ACE4_NO_PROPAGATE_INHERIT_ACE     = 0x00000004;
   const ACE4_INHERIT_ONLY_ACE             = 0x00000008;
   const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
   const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
   const ACE4_IDENTIFIER_GROUP             = 0x00000040;
   const ACE4_INHERITED_ACE                = 0x00000080;




Noveck                    Expires 3 March 2022                 [Page 30]


Internet-Draft               Nfsv4 Security                  August 2021


   A server need not support any of these flags.  If the server supports
   flags that are similar to, but not exactly the same as, these flags,
   the implementation may define a mapping between the protocol-defined
   flags and the implementation-defined flags.

   For example, suppose a client tries to set an ACE with
   ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE.  If the
   server does not support any form of ACL inheritance, the server
   should reject the request with NFS4ERR_ATTRNOTSUPP.  If the server
   supports a single "inherit ACE" flag that applies to both files and
   directories, the server may reject the request (i.e., requiring the
   client to set both the file and directory inheritance flags).  The
   server may also accept the request and silently turn on the
   ACE4_DIRECTORY_INHERIT_ACE flag.

6.4.6.  Details Regarding ACE Flag Bits

   ACE4_FILE_INHERIT_ACE
      Any non-directory file in any sub-directory will get this ACE
      inherited.

   ACE4_DIRECTORY_INHERIT_ACE
      Can be placed on a directory and indicates that this ACE should be
      added to each new directory created.

      If this flag is set in an ACE in an ACL attribute to be set on a
      non-directory file system object, the operation attempting to set
      the ACL SHOULD fail with NFS4ERR_ATTRNOTSUPP.

   ACE4_NO_PROPAGATE_INHERIT_ACE
      Can be placed on a directory.  This flag tells the server that
      inheritance of this ACE should stop at newly created child
      directories.

   ACE4_INHERIT_ONLY_ACE
      Can be placed on a directory but does not apply to the directory;
      ALLOW and DENY ACEs with this bit set do not affect access to the
      directory, and AUDIT and ALARM ACEs with this bit set do not
      trigger log or alarm events.  Such ACEs only take effect once they
      are applied (with this bit cleared) to newly created files and
      directories as specified by the ACE4_FILE_INHERIT_ACE and
      ACE4_DIRECTORY_INHERIT_ACE flags.

      If this flag is present on an ACE, but neither
      ACE4_DIRECTORY_INHERIT_ACE nor ACE4_FILE_INHERIT_ACE is present,
      then an operation attempting to set such an attribute SHOULD fail
      with NFS4ERR_ATTRNOTSUPP.




Noveck                    Expires 3 March 2022                 [Page 31]


Internet-Draft               Nfsv4 Security                  August 2021


   ACE4_SUCCESSFUL_ACCESS_ACE_FLAG and ACE4_FAILED_ACCESS_ACE_FLAG
      The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
      ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits may be set only on
      ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
      (ALARM) ACE types.  If during the processing of the file's ACL,
      the server encounters an AUDIT or ALARM ACE that matches the
      principal attempting the OPEN, the server notes that fact, and the
      presence, if any, of the SUCCESS and FAILED flags encountered in
      the AUDIT or ALARM ACE.  Once the server completes the ACL
      processing, it then notes if the operation succeeded or failed.
      If the operation succeeded, and if the SUCCESS flag was set for a
      matching AUDIT or ALARM ACE, then the appropriate AUDIT or ALARM
      event occurs.  If the operation failed, and if the FAILED flag was
      set for the matching AUDIT or ALARM ACE, then the appropriate
      AUDIT or ALARM event occurs.  Either or both of the SUCCESS or
      FAILED can be set, but if neither is set, the AUDIT or ALARM ACE
      is not useful.

      The previously described processing applies to ACCESS operations
      even when they return NFS4_OK.  For the purposes of AUDIT and
      ALARM, we consider an ACCESS operation to be a "failure" if it
      fails to return a bit that was requested and supported.

   ACE4_IDENTIFIER_GROUP
      Indicates that the "who" refers to a GROUP as defined under UNIX
      or a GROUP ACCOUNT as defined under Windows.  Clients and servers
      MUST ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who
      value equal to one of the special identifiers outlined in
      Section 6.4.7.

   ACE4_INHERITED_ACE
      Indicates that this ACE is inherited from a parent directory.  A
      server that supports automatic inheritance will place this flag on
      any ACEs inherited from the parent directory when creating a new
      object.  Client applications will use this to perform automatic
      inheritance.  Clients and servers MUST clear this bit in the acl
      attribute; it may only be used in the dacl and sacl attributes.

6.4.7.  ACE Who

   The "who" field of an ACE is an identifier that specifies the
   principal or principals to whom the ACE applies.  It may refer to a
   user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying
   which.

   There are several special identifiers that need to be understood
   universally, rather than in the context of a particular DNS domain.
   Some of these identifiers cannot be understood when an NFS client



Noveck                    Expires 3 March 2022                 [Page 32]


Internet-Draft               Nfsv4 Security                  August 2021


   accesses the server, but have meaning when a local process accesses
   the file.  The ability to display and modify these permissions is
   permitted over NFS, even if none of the access methods on the server
   understands the identifiers.

   +===============+==================================================+
   | Who           | Description                                      |
   +===============+==================================================+
   | OWNER         | The owner of the file.                           |
   +---------------+--------------------------------------------------+
   | GROUP         | The group associated with the file.              |
   +---------------+--------------------------------------------------+
   | EVERYONE      | The world, including the owner and owning group. |
   +---------------+--------------------------------------------------+
   | INTERACTIVE   | Accessed from an interactive terminal.           |
   +---------------+--------------------------------------------------+
   | NETWORK       | Accessed via the network.                        |
   +---------------+--------------------------------------------------+
   | DIALUP        | Accessed as a dialup user to the server.         |
   +---------------+--------------------------------------------------+
   | BATCH         | Accessed from a batch job.                       |
   +---------------+--------------------------------------------------+
   | ANONYMOUS     | Accessed without any authentication.             |
   +---------------+--------------------------------------------------+
   | AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS).  |
   +---------------+--------------------------------------------------+
   | SERVICE       | Access from a system service.                    |
   +---------------+--------------------------------------------------+

                                 Table 2

   To avoid conflict, these special identifiers are distinguished by an
   appended "@" and should appear in the form "xxxx@" (with no domain
   name after the "@"), for example, ANONYMOUS@.

   The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these
   special identifiers.  When encoding entries with these special
   identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.

   [working group input needed]: I don't understand what might be valid
   reasons to ignore this.  Would "MUST" be appropriate here?

   It is important to note that "EVERYONE@" is not equivalent to the
   UNIX "other" entity.  This is because, by definition, UNIX "other"
   does not include the owner or owning group of a file.  "EVERYONE@"
   means literally everyone, including the owner or owning group.





Noveck                    Expires 3 March 2022                 [Page 33]


Internet-Draft               Nfsv4 Security                  August 2021


   [working group input needed]: Some of these require that changes be
   made as discussed below:

   *  For "INTERACTIVE", "NETWORK", "DIALUP", "BATCH", and "SERVICE" it
      needs to be specified that server's ability to make these
      distinctions is limited, making their use where security is an
      issue quite problematic.

   *  For "ANONYMOUS", clearly requests using AUTH_NONE fit but what
      else?

      Request by nobody and by users root-squashed to nobody are
      probably OK, although you could argue about the case of a user
      "nobody" authenticated by RPCSEC_GSS>

      ON a more contentious note, I would argue that users
      "authenticated" using AUTH_SYS, in the clear, without client-peer
      authentication fit here, but we need to get to consensus on this
      point.

   *  Issues regarding "AUTHENTICATED" will be the mirror image of those
      for "ANONYMOUS".

6.4.8.  Automatic Inheritance Features

   The acl attribute consists only of an array of ACEs, but the sacl
   (Section 6.6) and dacl (Section 6.5) attributes also include an
   additional flag field.

   struct nfsacl41 {
           aclflag4        na41_flag;
           nfsace4         na41_aces<>;
   };

   The flag field applies to the entire sacl or dacl; three flag values
   are defined:

   const ACL4_AUTO_INHERIT         = 0x00000001;
   const ACL4_PROTECTED            = 0x00000002;
   const ACL4_DEFAULTED            = 0x00000004;

   and all other bits must be cleared.  The ACE4_INHERITED_ACE flag may
   be set in the ACEs of the sacl or dacl (whereas it must always be
   cleared in the acl).

   Together these features allow a server to support automatic
   inheritance, which we now explain in more detail.




Noveck                    Expires 3 March 2022                 [Page 34]


Internet-Draft               Nfsv4 Security                  August 2021


   Inheritable ACEs are normally inherited by child objects only at the
   time that the child objects are created; later modifications to
   inheritable ACEs do not result in modifications to inherited ACEs on
   descendants.

   However, the dacl and sacl provide an OPTIONAL mechanism that allows
   a client application to propagate changes to inheritable ACEs to an
   entire directory hierarchy.

   A server that supports this feature performs inheritance at object
   creation time in the normal way, and SHOULD set the
   ACE4_INHERITED_ACE flag on any inherited ACEs as they are added to
   the new object.

   A client application such as an ACL editor may then propagate changes
   to inheritable ACEs on a directory by recursively traversing that
   directory's descendants and modifying each ACL encountered to remove
   any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the
   new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set).  It
   uses the existing ACE inheritance flags in the obvious way to decide
   which ACEs to propagate.  (Note that it may encounter further
   inheritable ACEs when descending the directory hierarchy and that
   those will also need to be taken into account when propagating
   inheritable ACEs to further descendants.)

   The reach of this propagation may be limited in two ways: first,
   automatic inheritance is not performed from any directory ACL that
   has the ACL4_AUTO_INHERIT flag cleared; and second, automatic
   inheritance stops wherever an ACL with the ACL4_PROTECTED flag is
   set, preventing modification of that ACL and also (if the ACL is set
   on a directory) of the ACL on any of the object's descendants.

   This propagation is performed independently for the sacl and the dacl
   attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may
   be independently set for the sacl and the dacl, and propagation of
   one type of acl may continue down a hierarchy even where propagation
   of the other acl has stopped.

   New objects should be created with a dacl and a sacl that both have
   the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to
   the same value as that on, respectively, the sacl or dacl of the
   parent object.

   Both the dacl and sacl attributes are Recommended, and a server may
   support one without supporting the other.






Noveck                    Expires 3 March 2022                 [Page 35]


Internet-Draft               Nfsv4 Security                  August 2021


   A server that supports both the old acl attribute and one or both of
   the new dacl or sacl attributes must do so in such a way as to keep
   all three attributes consistent with each other.  Thus, the ACEs
   reported in the acl attribute should be the union of the ACEs
   reported in the dacl and sacl attributes, except that the
   ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl.
   And of course a client that queries only the acl will be unable to
   determine the values of the sacl or dacl flag fields.

   When a client performs a SETATTR for the acl attribute, the server
   SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the
   dacl.  By using the acl attribute, as opposed to the dacl or sacl
   attributes, the client signals that it may not understand automatic
   inheritance, and thus cannot be trusted to set an ACL for which
   automatic inheritance would make sense.

   When a client application queries an ACL, modifies it, and sets it
   again, it should leave any ACEs marked with ACE4_INHERITED_ACE
   unchanged, in their original order, at the end of the ACL.  If the
   application is unable to do this, it should set the ACL4_PROTECTED
   flag.  This behavior is not enforced by servers, but violations of
   this rule may lead to unexpected results when applications perform
   automatic inheritance.

   If a server also supports the mode attribute, it SHOULD set the mode
   in such a way that leaves inherited ACEs unchanged, in their original
   order, at the end of the ACL.  If it is unable to do so, it SHOULD
   set the ACL4_PROTECTED flag on the file's dacl.

   Finally, in the case where the request that creates a new file or
   directory does not also set permissions for that file or directory,
   and there are also no ACEs to inherit from the parent's directory,
   then the server's choice of ACL for the new object is implementation-
   dependent.  In this case, the server SHOULD set the ACL4_DEFAULTED
   flag on the ACL it chooses for the new object.  An application
   performing automatic inheritance takes the ACL4_DEFAULTED flag as a
   sign that the ACL should be completely replaced by one generated
   using the automatic inheritance rules.

6.5.  V4.1 Attribute 58: dacl

   The dacl attribute is like the acl attribute, but dacl allows only
   ALLOW and DENY ACEs.  The dacl attribute supports automatic
   inheritance (see Section 6.4.8).







Noveck                    Expires 3 March 2022                 [Page 36]


Internet-Draft               Nfsv4 Security                  August 2021


6.6.  V4.1 Attribute 59: sacl

   The sacl attribute is like the acl attribute, but sacl allows only
   AUDIT and ALARM ACEs.  The sacl attribute supports automatic
   inheritance (see Section 6.4.8).

7.  Common Considerations for Both File access Models

   [Important structural change to be noted]: This section is derived
   from Section 6.3 of 8881, entitled "Common Methods.  However, its
   content is different because it has been rewritten to deal with
   issues common to both file access models, which now appears to have
   not been the original intention.  Nevertheless, the following changes
   have been made:

   *  The section "Server Considerations" has been revised to deal with
      both the mode and acl attributes, since the points being made
      apply, in almost all cases, to both attributes.

   *  The section "Client Considerations" has been heavily revised,
      since what had been there did not make any sense to me.

   *  The section "Computing a Mode Attribute from an ACL" has been
      moved to Section 8.2.1 since it deals with the co-ordination of
      the posix and acl authorization models.

7.1.  Server Considerations

   The server uses the mode attribute or the acl attribute applying the
   algorithm described in Section 17.1 to determine whether an ACL
   allows access to an object.

   However, these attributes might not be the sole determiner of access.
   For example:

   *  In the case of a file system exported as read-only, the server
      will deny write access even though an object's file access
      attributes would grant it.

   *  Server implementations MAY grant ACE4_WRITE_ACL and ACE4_READ_ACL
      permissions to prevent a situation from arising in which there is
      no valid way to ever modify the ACL.

   *  All servers will allow a user the ability to read the data of the
      file when only the execute permission is granted (e.g., if the ACL
      denies the user the ACE4_READ_DATA access and allows the user
      ACE4_EXECUTE, the server will allow the user to read the data of
      the file).



Noveck                    Expires 3 March 2022                 [Page 37]


Internet-Draft               Nfsv4 Security                  August 2021


   *  Many servers implement owner-override semantics in which the owner
      of the object is allowed to override accesses that are denied by
      the ACL.  This may be helpful, for example, to allow users
      continued access to open files on which the permissions have
      changed.

   *  Many servers provide for the existence of a "superuser" that has
      privileges beyond an ordinary user.  The superuser may be able to
      read or write data or metadata in ways that would not be permitted
      by the ACL or mode attributes.

   *  A retention attribute might also block access otherwise allowed by
      ACLs (see Section 5.13 of [8]).

7.2.  Client Considerations

   Clients SHOULD NOT do their own access checks based on their
   interpretation of the ACL, but rather use the OPEN and ACCESS
   operations to do access checks.  This allows the client to act on the
   results of having the server determine whether or not access should
   be granted based on its interpretation of the ACL.

   [Working group discussion needed]: With regard to the use of "SHOULD
   NOT" in the paragraph above, it is not clear what might be valid
   reasons to bypass this recommendation.  Perhaps "MUST NOT" or "should
   not" would be more appropriate.

   Clients must be aware of situations in which an object's ACL will
   define a certain access even though the server will not enforce it.
   In general, but especially in these situations, the client needs to
   do its part in the enforcement of access as defined by the ACL.

   [Working group input needed]: Despite what is said later, the only
   such case I know of is the use of READ and EXECUTE where the client,
   but not the server, has any means of distinguishing these.  don't
   know of any others.  If there were, how could ACCESS or OPEN be used
   to verify access?

   To do this, the client MAY send the appropriate ACCESS operation
   prior to servicing the request of the user or application in order to
   determine whether the user or application should be granted the
   access requested.

   For examples in which the ACL may define accesses that the server
   doesn't enforce, see Section 7.1.






Noveck                    Expires 3 March 2022                 [Page 38]


Internet-Draft               Nfsv4 Security                  August 2021


   [Working group discussion needed]: The sentence above is clearly
   wrong since that section is about enforcement the server does do.
   Sigh!

8.  Combining Authorization Models

   [To be checked]: The section on computing mode from ACL in RFC3530 is
   quite similar to that in RFC8881.  If they are essentially identical,
   Section 8.2.1 could be moved out of Section 8.2 and apply to all
   minor versions :-).  In addition, there may be additional material
   that could be generalized in this way.

8.1.  Combined Authorization Models for V4.0

   V4.0 servers that support both the mode and acl attributes, like
   servers for other minor versions, have to appropriately co-ordinate
   the values.  Because much of the material in Section 8.2 does not
   apply to v4.0, the server is relatively free about how it does this.
   Nevertheless, that material is one useful approach and v4.0
   implementers may want to consult it, even though the requirements in
   it do not apply and the recommendations have no normative force.

   One likely source of a need for different treatment is the absence of
   a set_mode_masked attribute in v4.0.

   Clients need to be aware that the v4.1 handling may nor may not be
   adopted by the server and that the client needs to adapt accordingly.

8.2.  Combined Authorization Model for V4.1 and Beyond

   *  On servers that support both the mode and the acl or dacl
      attributes, the server must keep the two consistent with each
      other.  The value of the mode attribute (with the exception of the
      three high-order bits described in Section 6.3.1) must be
      determined entirely by the value of the ACL, so that use of the
      mode is never required for anything other than setting the three
      high-order bits.  See Sections 8.2.4 through 8.2.6 for detailed
      requirements.

   *  When a mode attribute is set on an object, the ACL attributes may
      need to be modified in order to not conflict with the new mode.
      In such cases, it is desirable that the ACL keep as much
      information as possible.  This includes information about
      inheritance, AUDIT and ALARM ACEs, and permissions granted and
      denied that do not conflict with the new mode.






Noveck                    Expires 3 March 2022                 [Page 39]


Internet-Draft               Nfsv4 Security                  August 2021


   The server that supports both mode and ACL must take care to
   synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the
   ACEs that have respective who fields of "OWNER@", "GROUP@", and
   "EVERYONE@".  This way, the client can see if semantically equivalent
   access permissions exist whether the client asks for the owner,
   owner_group, and mode attributes or for just the ACL.

   In this section, much depends on the method in specified
   Section 8.2.1.  Many requirements refer to this section.  It should
   be noted that the methods have behaviors specified with "SHOULD" and
   that alternate approaches are discussed in Section 8.2.2.  This is
   intentional, to avoid invalidating existing implementations that
   compute the mode according to the withdrawn POSIX ACL draft (1003.1e
   draft 17), rather than by actual permissions on owner, group, and
   other.

   [Working group discussion needed]: Given the mixture of RFC2219
   terms, I think all of them in Section 8 need review.  Further, given
   the effort that has gone into Section 8, to accommodate these
   implementations of a draft that was withdrawn decades ago.  The idea
   of trying to make mode and acl match is undercut when there are
   different valid ways of computing the mode.  There shouldn't be.  To
   specify one way to do this is necessary to accomplish the goal here
   and to do so would not "invalidate" anything.  Rather, it would
   establish, correctly, that such implementations are not
   implementations of the NFSv4 ACL model, but of the withdrawn POSIX
   ACL draft.

8.2.1.  Computing a Mode Attribute from an ACL

   The following method can be used to calculate the MODE4_R*, MODE4_W*,
   and MODE4_X* bits of a mode attribute, based upon an ACL.

   [Working group discussion needed]: "can be used" says essentially "do
   whatever you choose" and would make Section 8 essentially pointless.
   Would prefer "is to be used", "MUST", or "SHOULD" if valid reasons to
   do otherwise can be found.

   First, for each of the special identifiers OWNER@, GROUP@, and
   EVERYONE@, evaluate the ACL in order, considering only ALLOW and DENY
   ACEs for the identifier EVERYONE@ and for the identifier under
   consideration.  The result of the evaluation will be an NFSv4 ACL
   mask showing exactly which bits are permitted to that identifier.

   Then translate the calculated mask for OWNER@, GROUP@, and EVERYONE@
   into mode bits for, respectively, the user, group, and other, as
   follows:




Noveck                    Expires 3 March 2022                 [Page 40]


Internet-Draft               Nfsv4 Security                  August 2021


   1.  Set the read bit (MODE4_RUSR, MODE4_RGRP, or MODE4_ROTH) if and
       only if ACE4_READ_DATA is set in the corresponding mask.

   2.  Set the write bit (MODE4_WUSR, MODE4_WGRP, or MODE4_WOTH) if and
       only if ACE4_WRITE_DATA and ACE4_APPEND_DATA are both set in the
       corresponding mask.

   3.  Set the execute bit (MODE4_XUSR, MODE4_XGRP, or MODE4_XOTH), if
       and only if ACE4_EXECUTE is set in the corresponding mask.

8.2.2.  Alternatives in Computing Mode Bits

   Some server implementations also add bits permitted to named users
   and groups to the group bits (MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP).

   Implementations are discouraged from doing this, because it has been
   found to cause confusion for users who see members of a file's group
   denied access that the mode bits appear to allow.  (The presence of
   DENY ACEs may also lead to such behavior, but DENY ACEs are expected
   to be more rarely used.)

   [Working group decision needed]; the text does not seem to really
   discourage this practice and makes no reference to the need to
   standardize behavior or any impediment to doing so.  "SHOULD NOT"
   needs to be considered if valid reasons to do otherwise can be found.

   The same user confusion seen when fetching the mode also results if
   setting the mode does not effectively control permissions for the
   owner, group, and other users; this motivates some of the
   requirements that follow.

8.2.3.  Setting Multiple ACL Attributes

   In the case where a server supports the sacl or dacl attribute, in
   addition to the acl attribute, the server MUST fail a request to set
   the acl attribute simultaneously with a dacl or sacl attribute.  The
   error to be given is NFS4ERR_ATTRNOTSUPP.













Noveck                    Expires 3 March 2022                 [Page 41]


Internet-Draft               Nfsv4 Security                  August 2021


8.2.4.  Setting Mode and not ACL

   When any of the nine low-order mode bits are subject to change,
   either because the mode attribute was set or because the
   mode_set_masked attribute was set and the mask included one or more
   bits from the nine low-order mode bits, and no ACL attribute is
   explicitly set, the acl and dacl attributes must be modified in
   accordance with the updated value of those bits.  This must happen
   even if the value of the low-order bits is the same after the mode is
   set as before.

   Note that any AUDIT or ALARM ACEs (hence any ACEs in the sacl
   attribute) are unaffected by changes to the mode.

   In cases in which the permissions bits are subject to change, the acl
   and dacl attributes MUST be modified such that the mode computed via
   the method in Section 8.2.1 yields the low-order nine bits (MODE4_R*,
   MODE4_W*, MODE4_X*) of the mode attribute as modified by the
   attribute change.  The ACL attributes SHOULD also be modified such
   that:

   1.  If MODE4_RGRP is not set, entities explicitly listed in the ACL
       other than OWNER@ and EVERYONE@ SHOULD NOT be granted
       ACE4_READ_DATA.

   2.  If MODE4_WGRP is not set, entities explicitly listed in the ACL
       other than OWNER@ and EVERYONE@ SHOULD NOT be granted
       ACE4_WRITE_DATA or ACE4_APPEND_DATA.

   3.  If MODE4_XGRP is not set, entities explicitly listed in the ACL
       other than OWNER@ and EVERYONE@ SHOULD NOT be granted
       ACE4_EXECUTE.

   Access mask bits other than those listed above, appearing in ALLOW
   ACEs, MAY also be disabled.

   Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect
   the permissions of the ACL itself, nor do ACEs of the type AUDIT and
   ALARM.  As such, it is desirable to leave these ACEs unmodified when
   modifying the ACL attributes.

   Also note that the requirement may be met by discarding the acl and
   dacl, in favor of an ACL that represents the mode and only the mode.
   This is permitted, but it is preferable for a server to preserve as
   much of the ACL as possible without violating the above requirements.
   Discarding the ACL makes it effectively impossible for a file created
   with a mode attribute to inherit an ACL (see Section 8.2.8).




Noveck                    Expires 3 March 2022                 [Page 42]


Internet-Draft               Nfsv4 Security                  August 2021


8.2.5.  Setting ACL and Not Mode

   When setting the acl or dacl and not setting the mode or
   mode_set_masked attributes, the permission bits of the mode need to
   be derived from the ACL.  In this case, the ACL attribute SHOULD be
   set as given.  The nine low-order bits of the mode attribute
   (MODE4_R*, MODE4_W*, MODE4_X*) MUST be modified to match the result
   of the method in Section 8.2.1.  The three high-order bits of the
   mode (MODE4_SUID, MODE4_SGID, MODE4_SVTX) SHOULD remain unchanged.

8.2.6.  Setting Both ACL and Mode

   When setting both the mode (includes use of either the mode attribute
   or the mode_set_masked attribute) and the acl or dacl attributes in
   the same operation, the attributes MUST be applied in this order:
   mode (or mode_set_masked), then ACL.  The mode-related attribute is
   set as given, then the ACL attribute is set as given, possibly
   changing the final mode, as described above in Section 8.2.5.

8.2.7.  Retrieving the Mode and/or ACL Attributes

   Some server implementations may provide for the existence of "objects
   without ACLs", meaning that all permissions are granted and denied
   according to the mode attribute and that no ACL attribute is stored
   for that object.  If an ACL attribute is requested of such a server,
   the server SHOULD return an ACL that does not conflict with the mode;
   that is to say, the ACL returned SHOULD represent the nine low-order
   bits of the mode attribute (MODE4_R*, MODE4_W*, MODE4_X*) as
   described in Section 8.2.1.

   For other server implementations, the ACL attribute is always present
   for every object.  Such servers SHOULD store at least the three high-
   order bits of the mode attribute (MODE4_SUID, MODE4_SGID,
   MODE4_SVTX).  The server SHOULD return a mode attribute if one is
   requested, and the low-order nine bits of the mode (MODE4_R*,
   MODE4_W*, MODE4_X*) MUST match the result of applying the method in
   Section 8.2.1 to the ACL attribute.

8.2.8.  Creating New Objects

   If a server supports any ACL attributes, it may use the ACL
   attributes on the parent directory to compute an initial ACL
   attribute for a newly created object.  This will be referred to as
   the inherited ACL within this section.  The act of adding one or more
   ACEs to the inherited ACL that are based upon ACEs in the parent
   directory's ACL will be referred to as inheriting an ACE within this
   section.




Noveck                    Expires 3 March 2022                 [Page 43]


Internet-Draft               Nfsv4 Security                  August 2021


   Implementors should standardize the behavior of CREATE and OPEN
   depending on the presence or absence of the mode and ACL attributes
   by following the directions below:

   1.  If just the mode is given in the call:

       In this case, inheritance SHOULD take place, but the mode MUST be
       applied to the inherited ACL as described in Section 8.2.4,
       thereby modifying the ACL.

   2.  If just the ACL is given in the call:

       In this case, inheritance SHOULD NOT take place, and the ACL as
       defined in the CREATE or OPEN will be set without modification,
       and the mode modified as in Section 8.2.5.

   3.  If both mode and ACL are given in the call:

       In this case, inheritance SHOULD NOT take place, and both
       attributes will be set as described in Section 8.2.6.

   4.  If neither mode nor ACL is given in the call:

       In the case where an object is being created without any initial
       attributes at all, e.g., an OPEN operation with an opentype4 of
       OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD
       NOT take place (note that EXCLUSIVE4_1 is a better choice of
       createmode4, since it does permit initial attributes).  Instead,
       the server SHOULD set permissions to deny all access to the newly
       created object.  It is expected that the appropriate client will
       set the desired attributes in a subsequent SETATTR operation, and
       the server SHOULD allow that operation to succeed, regardless of
       what permissions the object is created with.  For example, an
       empty ACL denies all permissions, but the server should allow the
       owner's SETATTR to succeed even though WRITE_ACL is implicitly
       denied.

       In other cases, inheritance SHOULD take place, and no
       modifications to the ACL will happen.  The mode attribute, if
       supported, MUST be as computed in Section 8.2.1, with the
       MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear.  If no
       inheritable ACEs exist on the parent directory, the rules for
       creating acl, dacl, or sacl attributes are implementation
       defined.  If either the dacl or sacl attribute is supported, then
       the ACL4_DEFAULTED flag SHOULD be set on the newly created
       attributes.





Noveck                    Expires 3 March 2022                 [Page 44]


Internet-Draft               Nfsv4 Security                  August 2021


8.2.9.  Use of Inherited ACL When Creating Objects

   If the object being created is not a directory, the inherited ACL
   SHOULD NOT inherit ACEs from the parent directory ACL unless the
   ACE4_FILE_INHERIT_ACE flag is set.

   If the object being created is a directory, the inherited ACL should
   inherit all inheritable ACEs from the parent directory, that is,
   those that have the ACE4_FILE_INHERIT_ACE or
   ACE4_DIRECTORY_INHERIT_ACE flag set.  If the inheritable ACE has
   ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear,
   the inherited ACE on the newly created directory MUST have the
   ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being
   affected by ACEs meant for non-directories.

   When a new directory is created, the server MAY split any inherited
   ACE that is both inheritable and effective (in other words, that has
   neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set),
   into two ACEs, one with no inheritance flags and one with
   ACE4_INHERIT_ONLY_ACE set.  (In the case of a dacl or sacl attribute,
   both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.)
   This makes it simpler to modify the effective permissions on the
   directory without modifying the ACE that is to be inherited to the
   new directory's children.

8.3.  Combined Authorization Models for V4.2

   The v4.1 server implementation requirements described in Section 8.2
   apply to v4.2 as well and v4.2 clients can assume that the server
   follows them.

   V4.2 contains an OPTIONAL extension, defined in [13], which is
   intended to reduce the interference of modes, restricted by the umask
   mechanism, with the acl inheritance mechanism.  The extension allows
   the client to specify the umask separately from the mask attribute.

9.  Labelled NFS Authorization Model

   The labelled NFS feature of NFSv4.2 is designed to support Mandatory
   Access control.

   The attribute sec_label enables an authorization model focused on
   Mandatory Access Control and is described in Section 9.








Noveck                    Expires 3 March 2022                 [Page 45]


Internet-Draft               Nfsv4 Security                  August 2021


   Not much can be said about this feature because the specification, in
   the interest of flexibility, has left important features undefined in
   order to allow future extension.  As a result, we have something that
   is a framework to allow Mandatory Access Control rather than one to
   provide it.  In particular,

   *  The sec_label attribute, which provides the objects label has no
      existing specification.

   *  There is no specification of the of the format of the subject
      label or way to authenticate them.

   *  As a result, all authorization takes place on the client, and the
      server simply accepts the client's determination.

   This arrangements shares important similarities with AUTH_SYS.  As
   such it makes sense:

   *  To require/recommend that an encrypted connection be used.

   *  To require/recommend that client and server peers mutually
      authenticate as part of connection establishment.

   *  That work be devoted to providing a replacement without the above
      issues.

10.  State Modification Authorization

   Modification of locking and session state data should not be done by
   a client other than the one that created the lock.  For this form of
   authorization, the server needs to identify and authenticate client
   peers rather than client users.

   Such authentication is not directly provided by any RPC
   authentication flavor.  However, RPC-based transports, when suitably
   configured, can provide this authenication.

   NFSv4.1 defines a number of ways to provide appropriate authorization
   facilities.  These will not be discussed in detail here but the
   following points should be noted:

   *  NFSv4.1 defines the MACHCRED mechanism which uses the RPCSEC_GSS
      infrastrucure to provide authentication of the clients peer.
      However, this is of no value when AUTH_SYS is being used.

   *  NFSv4.1 also defines the SSV mechanism which uses the RPCSEC_GSS
      infrastructure to enable it to be reliably determined whether two
      different client connections are connected to the same client.  It



Noveck                    Expires 3 March 2022                 [Page 46]


Internet-Draft               Nfsv4 Security                  August 2021


      is unclear whether the word "authentication" is appropriate in
      this case.  As with MACHCRED, this is of no value when AUTH_SYS is
      being used.

   *  Because of the lack of support for AUTH_SYS and for NFSv4.0, it is
      quite desirable for clients to use and for servers to require the
      use of client-peer authentication as part of connection
      establishment.

   When unauthenticated clients are allowed, their state is exposed to
   unwanted modification as part of disruption or denial-of-service
   attacks.  As a result, the potential burdens of such attacks are felt
   principally by clients who choose not to provide such authentication.

11.  Other Uses of Access Control Lists

12.  Identification and Authentication

   Various objects and subjects need to be identified for a protocol to
   function.  For it to be secure, many of these need to be
   authenticated so that incorrect identification is not the basis for
   attacks.

12.1.  Identification vs. Authentication

   It is necessary to be clear about this distinction which has been
   obscured in the past, by the use of the term "RPC Authentication
   Flavor" in connection with situation in which identification without
   authentication occurred or in which there was neither identification
   nor authentication involved.  As a result, we will use the term "RPC
   Flavors" instead

12.2.  Items to be Identified

   Some identifier are not security-relevant and can used be used
   without authentication, given that, in the authorization decision,
   the object acted upon needs only to be properly identified

   *  File names are of this type.

      Unlike the case for some other protocols, confusion of names that
      result from internationalization issues, while an annoyance, are
      not relevant to security.  If the confusion between LATIN CAPITAL
      LETTER O and CYRILLIC CAPITAL LETTER O, results in the wrong file
      being accessed, the mechanisms described in Section 6 prevent in
      appropriate access being granted.





Noveck                    Expires 3 March 2022                 [Page 47]


Internet-Draft               Nfsv4 Security                  August 2021


      Despite the above, it is desirable if file names togeter with
      similar are not transferred in the clear as the information
      exposed may give atackers useful information helpful in planning
      and executing atacks.

   *  The case of file handles is similar.

   Identifier that refer to state shared between client and server can
   be the basis of disruption attacks since clients and server
   necessaily assume that neither side will change the state corpus
   without appropriate notice.

   While these identifiers do not need to be authenticated, they are
   associated with higher-level entities for which change of the state
   represented by those entities is subject to peer authentication.

   *  Unexpected closure of stateids or changes in state sequence values
      can disrupt client access as no clients have provision to deal
      with this source of interference.

      While encryption may make it more difficult to execute such
      attacks attackers can often guess stateid's since server generally
      not randomize them.

   *  Similarly, modification to v4.1 session state information can
      result in confusion if an attacker changes the slot sequence by
      assuing spurious requests.  Even if the request is rejected, the
      slot sequence is changed and clients may a difficult time getting
      back in sync with the server.

      While encryption may make it more difficult to execute such
      attacks attackers can often guess slot id's and obtain sessinid's
      since server generally do not randomize them.


   it is necessary that modification of the higher-levell entities be
   restricted to the client that created them.

   *  For v4.0, the relevant entity is the clientid.

   *  for v4.1, the releant entity is the sessionid.

   Identifiers describing the issuer of the request, whether in numeric
   or string form always require authentication.







Noveck                    Expires 3 March 2022                 [Page 48]


Internet-Draft               Nfsv4 Security                  August 2021


12.3.  Authentication Provided by specific RPC Flavors

   Different flavors differ quite consderably, as discussed below;

   *  When AUTH_NONE is used, the user making the request is neither
      authenticated nor identified to the server.

      Also, the server is not authenticated to the client and has no way
      to determine whether the server it is communicating with is an
      imposter.

   *  When AUTH_SYS is used, the user making is the request identified
      but there no authentication of that identification.

      As in the previous case, the server is not authenticated to the
      client and has no way to determine whether the server it is
      communicating with is an imposter.

   *  When RPCSEC_GSS is used, the user making the request is
      authenticated as is the server peer responding.

12.4.  Authentication Provided by the RPC Transport

   Different transports differ quite consderably, as discussed below.
   In contrast to the case of RPC flavors, any authentication happens
   once, at connection establishment, rather than on each RPC request.
   As a result, it is the client and server peers, rather than
   individual users that is authenticated.

   *  For most transports, such as TCP and RPC-over-RDMA version 1,
      there is no provision for peer authentication.

      As a result use of AUTH_SYS together with such transports is
      inherently problematic.

   *  Some transports provide for the possibility of mutual peer
      authentication.

13.  Security of Data in Flight

13.1.  Data Security Provided by the Flavor-associated Services

   The only flavor providing these facilities is RPCSEC_GSS.  When this
   flavor is used, data security can be negotiated between client and
   server as described in Section 14.2.  However, when data security is
   provided at the transport level, as described in Section 13.2, the
   negotiation of privacy and integrity support is unnecessary,




Noveck                    Expires 3 March 2022                 [Page 49]


Internet-Draft               Nfsv4 Security                  August 2021


   Other flavors, such as AUTH_SYS and AUTH_NONE have no such data
   security facilities.  When these flavor are used, the only data
   security is provided by the transport.

13.2.  Data Security Provided by the RPC Transport

   Some transports provide data security for all transactions performed
   on them, eliminating the need for that security to be provided or
   negotiated by the selection of particular flavors, mechanism, or
   services.

14.  Security Negotiation

   As previously in NFSv4, we use the term "negotiation" to characterize
   the process of the server providing a set of options and the client
   selecting one.

   The use of SECINFO, possibly with SECINFO_NONAME, remains the primary
   means by which the security parameters are determined.  The addition
   of transports to flavors in providing security has resulted in the
   following changes:

   *  Transport-related security choices are typically decided at
      connection-establishment so there needs to be provision for
      negotiation at this point.

   *  Despite the above, because the choices of flavor and transport
      affect one another, SECINFO has been extended by the addition of
      pseudo-flavors, while retaining the existing XDR, to allow
      negotiation of transport choices and accompanying connection
      establishment options, in addition to selection of flavors and
      accompanying services.  This allows server policies for such
      matters to be different for different portions of the namespace.

14.1.  Flavors and Pseudo-flavors

   The flavor field of the secinfo4 items returned by SECINFO and
   SECINO_NONAME have always allowed pseudo flavors to be included.
   However, previous treatments of these operations have not provided
   information about how responses containing such pseudo-flavors are to
   be interpreted.

   Those pseudo-flavors now provide a means of extending the negotiation
   process so it is capable of providing for the negotiation of the use
   particular RPC transports and security-related options for the
   connections established using those transports.





Noveck                    Expires 3 March 2022                 [Page 50]


Internet-Draft               Nfsv4 Security                  August 2021


   The flavors AUTH_NONE, AUTH_SYS and RPCSEC_GSS continue to indicate
   the acceptability of the corresponding method of user authentication,
   user identification, or user non-identification, when used with a
   particular RPC transport.

   The flavor AUTH_TLS, which is not used as part of issuing requests is
   not included in this list and is treated as a connetion-type--
   specifying pseudo-flavor.

   secinfo4s for the flavor RPCSEC_GSS contains additional information
   describing the specific secrity lgorithm to be used and the ancillary
   services to be provided (e.g. integrity, privacy) when these services
   are not provided by the trnsport.

   Such flavors are referred to as "flavor-specifying flavors"

   The classification below organizes the flavors and pseudo-flavors
   used in security negotiation while Section 14.4 describes how the set
   of secinfos in a response can be used by the client to select
   acceptble combinations of security flavor, security mechanism,
   security services, security-related transports, and security-related
   connection chractertics.

   *  The pseudo-flavors designating a security-relevant transport type,
      together with AUTH-TLS, nominally a flavor but used as a pseudo-
      flavor in connection with SECINFO.

      Such pseudo-flavors are referred to as "transport- specifying
      flavors".

   *  The pseudo-flavors designating restrictions on acceptble
      connnection characteristics include XPCH_ENCRYPT, XPCH_PEERAUTH,
      and XPCH_SECURE.

      Such pseudo-flavors are referred to as "transport-restriction
      flavors".

   *  The pseudo-flavors combining a flavor designation together with a
      restriction conerninng the connections it is relevant to include
      AUTHXP_CLIENTPEER, AUTHXP_ENCRYPT, AUTHXP_SECURE.

      Such pseudo-flavors are referred as tranport-hybridized flavors.

   *  The special pseudo-flavors, XPBREAK and XPCURRENT

      Such pseudo-flavors are referred to connection-organizing flavors.





Noveck                    Expires 3 March 2022                 [Page 51]


Internet-Draft               Nfsv4 Security                  August 2021


14.2.  Negotiation of Security Flavors and Mechanisms

   For the current connection, this proceeds as it has previously, when
   security-relevant transports were not available.  Flavor entties,
   including those including mechanism information are listed in order
   of server preference and apply, by default, to the current
   connection, which normally is favored by the server.

   When other transport-identifying pseudo-flavors appear before the
   flavor entries, then the server is indicating that these transport
   types, with the server preference following the ordering of the
   entries.  In this case, any flavor entries that follow a transport
   entry specify that flavor is usable with the transport types denoted
   by that transport entry.


14.3.  Negotiation of RPC Transports and Characteristics

   First we define some necessary terminology.

   *  A transport type specifies one of a small set of RPC transport
      types such as TCP or RDMA.  Each such transport type has an
      associated pseudoflavor.  There are also pseudo-flavors that
      specify a set of transport types such as XPT_ALL.

   *  Connection characteristics are designations of security-relevant
      characteristics or sets of characteristics that connections might
      have.

      There are pseudo-flavors associated with connection
      characteristics such as CONCH_CPAUTH, denoting client-peer
      authentication and CONCH_ENCRYPT, denoting the presence of an
      encrypted channel.  The pseudo-flavor CONCH_SECURE denotes the
      presence of peer mutual authentication together with the use of an
      encrypted channel.

   *  The combination of a transport type with a set of connection
      chracteristics is considered a connection type..while many
      connection types are designated by a combination of a flavor
      designating a transport with on designating a set of connection
      chacteristics, ther are pseudo flavor that designate a connection
      type directly.

      For example, the flavor AUTH_TLS is equivalent to XP_TCP combined
      with CONCH_ENCRYPT, while the pseudo-flavor XP_TCP_SECURE
      equivalent to XP_TCP comnined with CONCH_SECURE.





Noveck                    Expires 3 March 2022                 [Page 52]


Internet-Draft               Nfsv4 Security                  August 2021


   *  A flavor specification designates a specific flavor, or, in the
      case of RPCSEC_GSS, a flavor combined with additional mechanism
      and service information.

   *  A flavor assigment denote the assiciation of a specific flavor
      specification with a connection type.

   A secinfo response will designate a set of valid flavor assigments
   with an implied server ordering derived from the order that the
   entries appear in.

   In interpreting the response array the client is to maintain sets of
   designated transport typtes, connection characteristics and
   connection types specified indidually (i.e. without separately
   specifying transport types and connection characteristics).  When a
   flavor soecfication is encuntered, that flavor is considered valid
   when used with all curently active connection types, defined by the
   unionof the individually specified connection types and the cartesian
   product of the current transport types and current connection types.

   The presumed ordering of these assigments is as follows:

   *  When one of the connection types was specified directly by a
      connection type, the positionof that specification is compared to
      that of either the other individually-specified connection type or
      the earlier of the transport-type specification and the connection
      characteristics specification.

   *  in other cases, the position of the transport type specifications
      are considered first withe the position of the connection
      characteristics considered if necessary.

   *  If neithe of the above resolve issue, the positionof the flavor
      specification is considered.

   *  The type of the current connection is considered to be specified
      first, implicitly.

   *  There are provisions, described in Section 14.4 to modify this
      ordering, as may be necessary, for example, when the current
      connection, while acceptsble is of lower server preference.

14.4.  Overall Interpretation of SECINFO Response Arrays

   [TBD in -01]






Noveck                    Expires 3 March 2022                 [Page 53]


Internet-Draft               Nfsv4 Security                  August 2021


14.5.  SECINFO

   The description in the sub-sections below, while it adheres to the
   XDR appearing [6], [7], [8], [9] and [11].  will supersede the
   descriptions in [7] and [8].

   This is necessary to adapt the security negotiation process to the
   presence of transport-level security services such as encryption and
   peer authentication.

   Sumilar changes are necessary in the parallel SECINFO_NONAME
   operation introduced in NFSv4.1.  These are expected to be done as
   part of the rfc5661bis effort.

14.5.1.  SECINFO ARGUMENTS

   struct SECINFO4args {
           /* CURRENT_FH: directory */
           component4      name;
   };


                                  Figure 1

14.5.2.  SECINFO RESULTS


























Noveck                    Expires 3 March 2022                 [Page 54]


Internet-Draft               Nfsv4 Security                  August 2021


   /*
    * From RFC 2203
    */
   enum rpc_gss_svc_t {
           RPC_GSS_SVC_NONE        = 1,
           RPC_GSS_SVC_INTEGRITY   = 2,
           RPC_GSS_SVC_PRIVACY     = 3
   };

   struct rpcsec_gss_info {
           sec_oid4        oid;
           qop4            qop;
           rpc_gss_svc_t   service;
   };

   /* RPCSEC_GSS has a value of '6' - See RFC 2203 */
   union secinfo4 switch (uint32_t flavor) {
    case RPCSEC_GSS:
            rpcsec_gss_info        flavor_info;
    default:
            void;
   };

   typedef secinfo4 SECINFO4resok<>;

   union SECINFO4res switch (nfsstat4 status) {
    case NFS4_OK:
           /* CURRENTFH: consumed */
            SECINFO4resok resok4;
    default:
            void;
   };


                                  Figure 2

14.5.3.  SECINFO DESCRIPTION

   The SECINFO operation is used by the client determine the appropriate
   RPC authentication flavors, security mechanisms and encrypting
   transports to access a specific directory filehandle, file name pair.
   SECINFO should apply the same access approach used for LOOKUP when
   evaluating the name.  In consequence, if the requester does not have
   the appropriate access to LOOKUP the name, then SECINFO will behave
   the same way and return NFS4ERR_ACCESS.






Noveck                    Expires 3 March 2022                 [Page 55]


Internet-Draft               Nfsv4 Security                  August 2021


   The result will contain an array that represents the security flavor,
   security mechanisms and transports available, with an order
   corresponding to the server's preferences, the most preferred being
   first in the array.  The client is free to pick whatever security
   flavors, mechanisms and transports it both desires and supports, or
   to pick in the server's preference order the first one it supports.
   The array entries are represented by the secinfo4 structure.  The
   field 'flavor' will contain one of the following sorts of values:

   *  a value of AUTH_NONE, AUTH_SYS (as defined in RFC 5531 [4]).

   *  AUTH_TLS as described in ...

   *  A pseudo-flavor defined in Section 16.2

   *  RPCSEC_GSS (as defined in RFC 2203 [2]).

   *  Any other security flavor or pseudo-flavor registered with IANA.

   For the flavors other than RPCSEC_GSS, no additional security
   information is returned.  For a return value of RPCSEC_GSS, a
   security triple is returned that contains the mechanism object
   identifier (OID, as defined in RFC 2743 [3]), the quality of
   protection (as defined in RFC 2743 [3]), and the service type (as
   defined in RFC 2203 [2]).  It is possible for SECINFO to return
   multiple entries with flavor equal to RPCSEC_GSS with different
   security triple values.

   On success, the current filehandle is consumed, so that, if the
   operation following SECINFO tries to use the current filehandle, that
   operation will fail with the status NFS4ERR_NOFILEHANDLE.

   If the name has a length of zero, or if the name does not obey the
   UTF-8 definition in cirsumstanes in which UTF-8 names are required,
   the error NFS4ERR_INVAL will be returned.

   See Sections 14.2 through 14.4 for additional information on the use
   of SECINFO.

14.5.4.  SECINFO IMPLEMENTATION (general)

   The SECINFO operation is expected to be used by the NFS client when
   the error value of NFS4ERR_WRONGSEC is returned from another NFS
   operation.  This signifies to the client that the server's security
   policy is different from what the client is currently using.  At this
   point, the client is expected to obtain a list of possible security
   flavors and choose what best suits its policies.




Noveck                    Expires 3 March 2022                 [Page 56]


Internet-Draft               Nfsv4 Security                  August 2021


14.5.4.1.  SECINFO IMPLEMENTATION (for v4.0)

   [TBD in -01]

14.5.4.2.  SECINFO IMPLEMENTATION (for v4.1 and v4.2)

   As mentioned, the server's security policies will determine when a
   client request receives NFS4ERR_WRONGSEC.

   See Table 14 of [8] for a list of operations that can return
   NFS4ERR_WRONGSEC. in the case of v4.2, there might be extensions
   alloed to return NFS4ERR_WRONGSEC.  In addition, when READDIR returns
   attributes, the rdattr_error (Section 5.8.1.12 of [8]) can contain
   NFS4ERR_WRONGSEC.

   Note that CREATE and REMOVE MUST NOT return NFS4ERR_WRONGSEC.  The
   rationale for CREATE is that unless the target name exists, it cannot
   have a separate security policy from the parent directory, and the
   security policy of the parent was checked when its filehandle was
   injected into the COMPOUND request's operations stream (for similar
   reasons, an OPEN operation that creates the target MUST NOT return
   NFS4ERR_WRONGSEC).  If the target name exists, while it might have a
   separate security policy, that is irrelevant because CREATE MUST
   return NFS4ERR_EXIST.  The rationale for REMOVE is that while that
   target might have a separate security policy, the target is going to
   be removed, and so the security policy of the parent trumps that of
   the object being removed.  RENAME and LINK MAY return
   NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error applies only to the
   saved filehandle (see Section 2.6.3.1.2 of [8]).  Any
   NFS4ERR_WRONGSEC error on the current filehandle used by LINK and
   RENAME MUST be returned by the PUTFH, PUTPUBFH, PUTROOTFH, or
   RESTOREFH operation that injected the current filehandle.

   With the exception of LINK and RENAME, the set of operations that can
   return NFS4ERR_WRONGSEC represents the point at which the client can
   inject a filehandle into the "current filehandle" at the server.  The
   filehandle is either provided by the client (PUTFH, PUTPUBFH,
   PUTROOTFH), generated as a result of a name-to-filehandle translation
   (LOOKUP and OPEN), or generated from the saved filehandle via
   RESTOREFH.  As oSection 2.6.3.1.1.1 of [8] states, a put filehandle
   operation followed by SAVEFH MUST NOT return NFS4ERR_WRONGSEC.  Thus,
   the RESTOREFH operation, under certain conditions (see
   Section 2.6.3.1.1 of [8]), is permitted to return NFS4ERR_WRONGSEC so
   that security policies can be honored.

   The READDIR operation will not directly return the NFS4ERR_WRONGSEC
   error.  However, if the READDIR request included a request for
   attributes, it is possible that the READDIR request's security triple



Noveck                    Expires 3 March 2022                 [Page 57]


Internet-Draft               Nfsv4 Security                  August 2021


   did not match that of a directory entry.  If this is the case and the
   client has requested the rdattr_error attribute, the server will
   return the NFS4ERR_WRONGSEC error in rdattr_error for the entry.

   To resolve an error return of NFS4ERR_WRONGSEC, the client does the
   following:

   *  For LOOKUP and OPEN, the client will use SECINFO with the same
      current filehandle and name as provided in the original LOOKUP or
      OPEN to enumerate the available security triples.

   *  For the rdattr_error, the client will use SECINFO with the same
      current filehandle as provided in the original READDIR.  The name
      passed to SECINFO will be that of the directory entry (as returned
      from READDIR) that had the NFS4ERR_WRONGSEC error in the
      rdattr_error attribute.

   *  For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the
      client will use SECINFO_NO_NAME { style =
      SECINFO_STYLE4_CURRENT_FH }. The client will prefix the
      SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or
      PUTROOTFH operation that provides the filehandle originally
      provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH
      operation.

      NOTE: In NFSv4.0, the client was required to use SECINFO, and had
      to reconstruct the parent of the original filehandle and the
      component name of the original filehandle.  The introduction in
      NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction.

   *  For LOOKUPP, the client will use SECINFO_NO_NAME { style =
      SECINFO_STYLE4_PARENT } and provide the filehandle that equals the
      filehandle originally provided to LOOKUPP.

14.6.  Future Security Needs

   [To be fleashed out in -01]: This section is basically an outline for
   now, to be filled out laater based on Working Group input,
   particularly from Chuck lever who suggested this section and has
   ideas about many of the items in it.

   *  Security for data-at-rest, most probably based on facilities
      defined within SAN.

   *  Support for content signing.

   *  Revision/extension of labelled NFS to provide true
      interoperability and server-based authorization.



Noveck                    Expires 3 March 2022                 [Page 58]


Internet-Draft               Nfsv4 Security                  August 2021


   *  Work to provide more security for RDMA-based transports.  This
      would include the peer authentication infrastructure now being
      developed as part of RPC-over-RDMA version 2.  In addition, there
      is a need for an RPC-based transport that provides for encyption,
      which might be provided in number of ways.

15.  Security Considerations

15.1.  Changes in Security Considerations

   Beyond the needed inclusion of a threat analysis and the fact that
   all minor versions are dealt with together, there are a number of
   substantive changes in the approach to NFSv4 security presented in
   RFCs 7530 and 8881 and that appearing in this document.

   This document will not seek to speculate how the previous treatment,
   now viewed as incorrect, came to be written, approved, and published.
   However, it will, for the benefit of those familiar with the previous
   treatment of these matters, draw attention to the important changes
   listed here.

   *  There is a vastly expanded range of threats being considered as
      described in Section 15.1.1

   *  New facilities available at the RPC transport level can be used to
      deal with security issues, as described in Section 15.1.2

15.1.1.  Wider View of Threats

   Although the absence of a threat analysis in previous treatments
   makes comparison most difficult, the security-related features
   described in previous specifications and the associated discussion in
   their security considerations sections makes it clear that earlier
   specifications took a quite narrow view of threats to be protected
   against.

   One aspect of that narrow view that merits special attention is the
   handling of AUTH_SYS, at that time in the clear, with no client peer
   authentication.

   With regard to specific threats, there is no mention in existing
   security consideration sections of:

   *  Denial-of-service attacks.

   *  Client-impersonation attacks.

   *  Server-impersonation attacks.



Noveck                    Expires 3 March 2022                 [Page 59]


Internet-Draft               Nfsv4 Security                  August 2021


   The handling of data security in-flight is even more troubling.

   *  Although there was considerable work in the protocol to allow use
      of encryption to be negotiated when using RPCSEC_GSS.  The
      existing security considerations do not mention the potential need
      for encryption at all.

      It is not clear why this was omitted but it is a pattern that
      cannnot repeated in this document.

   *  The case of negotiation of integrity services is similar and uses
      the same negotiation infrastructure.

      In this case, use of integrity is recommended but not to prevent
      the corruption of user data being read or written.

      The use of integrity services is recommended in connetion with
      issuing SECINFO (and for NFSv4.1, SECINFO_NONAME).  The presence
      of this recommendation in the associated security considerations
      sections has the unfortunate effect of suggesting that the
      protection of user data is of relatively low impotance.

15.1.2.  Transport-layer Security Facilities

   Such transport-level RPC facilitites as RPC-over-TLS provide
   important ways of proving better security for all the NFSv4 minor
   versions.

   In particular:

   *  The presence of encryption by default will deal with security
      issue regarding data-in-flight, for both RPCSEC_GSS and AUTH_SYS.

   *  Peer authentication provided by the server eliminates the
      possibility of a server-impersonation attack, even when using
      AUTH_SYS.

   *  When mutual authentication is part of connection establishment,
      there is a possibility, where an appropriate trust relationship
      exisrts of treating the userid's presented in AUTH_SYS, as
      effectively authenticated, based on the authetication of the
      client peer.

15.1.3.  Compatibility and Maturity Issues

   Given the need to drastically change the NFSv4 security approach from
   that specified previously, it is necessary for us to be mindful of:




Noveck                    Expires 3 March 2022                 [Page 60]


Internet-Draft               Nfsv4 Security                  August 2021


   *  The difficulty that might be faced in adapting to the newer
      guidance because the delays involved in designing, developing, and
      testing new transport- level security facilities such as RPC-over-
      TLS.

   *  The difficulty in discarding or substantially modifying previous
      existing deployments and practices, developed on the basis of
      previous normative guidance.

   For these reasons, we will not use the term "MUST NOT" in some
   situations in which the use of that term might have been justified
   earlier.  In such cases, previous guidance together with the passsage
   of time may have created a situation in which the considerations
   mentioned above in this section may be valid reasons to defer, for a
   limited time, correction of the current sitution making the term
   "SHOULD NOT" appropriate, since the difficulties cited would
   constitute a valid reason to not allow what hsd been recommended
   against.

15.1.4.  Discussion of AUTHSYS

   An important change concerns the treatment of AUTH_SYS which is now
   divided into two subcases given the possible availabillity of support
   from the transport layer.

   When such support is not available, AUTH_SYS SHOULD NOT be used,
   since it makes the following attacks quite easy to execute:

   *  The absence of authentication of the server to the client allow
      server impersonation in which an imposter server can obtain data
      to be written by the user and supply corrupted data to read
      requests.

   *  The absence of authentication of the client user to the server
      allow server impersonation in which an imposter client can issue
      requests and have them executed as a user designated by imposter
      client, vitiating the server's authorization policy.

      With no authentication of the client peer, common approaches, such
      as using the source IP address can be easily defeated, allowing
      unauthenticated execution of requests made by the pseudo clients

   *  The absence of any support to protect data-in-flight when AUTH_SYS
      is used result in further serious security weaknesses.







Noveck                    Expires 3 March 2022                 [Page 61]


Internet-Draft               Nfsv4 Security                  August 2021


   In connection with the use of the term "SHOULD NOT" above, it is
   understood that the "valid reasons" to use this form of access
   reflect the Compatibility and Maturity Issue discussed above in
   Section 15.1.3 and that it is expected that, over time, these will
   become less applicable.

15.2.  Security Considerations Scope

15.2.1.  Discussion of Potential Classification of Environments

   [Working group discussion needed]: For now, we will not consider
   different security policies for different sorts of environments.
   This is because,

   *  Doing so would add considrable complexity to this document.

   *  The additional complexity would undecut our main goal here, which
      is to discuss secure use on the internet, which remain an
      important NFSv4 goal.

   *  The ubiquity of internet acess makes it hard to treat corporate
      network separately from the internet per se.

   *  While small networks might be sufficiently isolated to make it
      reasonable use NFSv4 without serious attention to security issues,
      the complexity of characterizing the necessary isolation makes it
      impractical to deal with such cases in this document.

15.2.2.  Discussion of Environments

   Although the security goal for Nfsv4 has been and remains "secure use
   on the internet", much use of NFSv4 occurs on more restricted IP
   networks with NFS access from outside the owning organization
   prevented by firewalls.

   This security considerations section will not deal separately with
   such environments since the threats that need to be discussed are
   essentially the same, despite the assumption by many that the
   restricted network access would eliminate the possibility of attacks
   originating inside the network by attackers who have some legitimate
   Nfsv4 access within it.

   In organizations of significant size, this sort of assumption of
   trusted access is usually not valid and this document will not deal
   with them explicitly.  In any case, there is little point in doing
   so, since, if everyone can be trusted, there can be no attackers,
   rendering threat analysis superfluous.




Noveck                    Expires 3 March 2022                 [Page 62]


Internet-Draft               Nfsv4 Security                  August 2021


   This does not mean that NFSv4 use cannot, as a practical matter, be
   made secure through means outside the scope of this document
   including strict administrative controls on all software running
   within it, frequent polygraph tests, and threats of prosecution.
   However, this document is not prepared to discuss the details of such
   policies, their implementation, or legal issues associated with them
   and treats such matters as out-of-scope.

   Nfsv4 can be used in very restrictive IP network environments where
   outside access is quite restricted and there is sufficient trust to
   allow, for example, every node to have the same root password.  The
   case of a simple network only accessible by a single user is similar.
   In such networks, many thing thats this document says "SHOULD NOT" be
   done are unexceptionable but the responsibility for making that
   determination is one for those creating such networks to take on.
   This document will not deal further with NFSv4 use on such networks.

15.3.  Major New Recommendations

15.3.1.  Recommendations Regarding Security of Data in Flight

   We RECOMMEND that requesters always issue requests with data security
   (i.e. with protection from disclosure or modification in flight)
   whether provided at the RPC request level or by the RPC transport,
   irrespective of the responder's requirements.

   We RECOMMEND that implementers provide servers the ability to
   configure policies in which requests without data security will be
   rejected as having insufficient security.

   We RECOMMEND that servers use such policies over either their entire
   local namespace or for all file systems except those clearly designed
   for the general dissemination of non-sensitive data.

15.3.2.  Recommendations Regarding Client Peer Authentication

   We RECOMMEND that clients provide authentication material whenever a
   connection is established with a server capable of using it to
   provide client peer authentication.

   We RECOMMEND that implementers provide servers the ability to
   configure policies in which attempts to establish connections without
   client peer authentication will be rejected.

   We RECOMMEND that servers adopt such policies whenever requests not
   using RPCSEC_GSS are allowed to be executed.





Noveck                    Expires 3 March 2022                 [Page 63]


Internet-Draft               Nfsv4 Security                  August 2021


15.3.3.  Issues Regarding Valid Reasons to Bypass Recommendations

   Clearly, the maturity and compatibility issues mentioned in
   Section 15.1.3 are valid reasons to nypass the above recommenations,
   as loong as thse issues continue to exist.

   [Working group discussion needed}: The question the working group
   needs to address is whether other valid reasons exist.

   [Working group discussion needed}: In particular, some members of the
   group might feel that the performance cost of encrypted transports
   constitutes, in itself, a valid reason to ignore the above
   recommendations.

   [Working group discussion needed}: I cannot agree and feel that
   accepting that as a valid reason would undercut Nfsv4 security
   improvement, and probably would not be acceptable to the security
   directorate.  However, I do want to work out an a generally
   acceptable compromise.  I propose something along the following
   lines:

      The transport-based encryption facilities are designed to be
      compatible with facilities to offload the work of encryption and
      decryption.  When such facilities are not available, at a
      reasonable cost, to NFSv4 servers and clients anticipating heavy
      use of NFSv4, then the lack of such facilities can be considered a
      valid reason to bypass the above recommendations, as long as that
      situation continues.

15.4.  Data Security Threats

   [TBD in -01]

15.5.  Authentication-based threats

15.5.1.  Attacks based on the use of AUTH_SYS

   [TBD in -01]

15.5.2.  Attacks on Name/Userid Mapping Facilities

   [TBD in -01]









Noveck                    Expires 3 March 2022                 [Page 64]


Internet-Draft               Nfsv4 Security                  August 2021


15.6.  Disruption and Denial-of-Service Attacks

15.6.1.  Attacks Based on the Disruption of Client-Server Shared State

   [TBD in -01]

15.6.2.  Attacks Based on Forcing the Misuse of Server Resources

   [TBD in -01]

16.  IANA Considerations

   Because of the shift from implementing security-related services only
   in connection with RPCSEC_GSS to one in which transport-level
   security has a prominent role, a number if new values need to be
   assigned.

   These include new authstat values to guide selection of a Transports
   aceptable to both client and server, presented in Section 16.1 and
   new pseudo-flavors to be used in the process of security negotion,
   presented in Section 16.2.

16.1.  New Authstat Values

   The following new authstat values are necessary to enable a server to
   indicate that the server's policy does not allows requests to be made
   on the current connection because of security issues associated with
   the rpc transport.  In the event they are received, the client needs
   to establish a new connection.

   *  The value XP_CRYPT indicates that the server will not support
      access using unencrypted connections while the current connection
      is not encrypted.

   *  The value XP_CPAUTH indicates that the server will not support
      access using connections for which the client peer has not
      authenticated itelf as part of connection while the current
      connection has not been set up in that way.

16.2.  New Authentication Pseudo-Flavors

   The following new pseudo-flavors are made available to allow their
   return as part of the response to SECINFO operation described in
   Section 14.5 and for similar operations.

   [TBD in -01]





Noveck                    Expires 3 March 2022                 [Page 65]


Internet-Draft               Nfsv4 Security                  August 2021


17.  Dummy Sections

17.1.  Dummy Section AUTHFA-acl-ace

17.2.  Dummy Section AUTHFA-acl-aclsupport

18.  References

18.1.  Normative References

   [1]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [2]        Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
              Specification", RFC 2203, DOI 10.17487/RFC2203, September
              1997, <https://www.rfc-editor.org/info/rfc2203>.

   [3]        Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743,
              DOI 10.17487/RFC2743, January 2000,
              <https://www.rfc-editor.org/info/rfc2743>.

   [4]        Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
              May 2009, <https://www.rfc-editor.org/info/rfc5531>.

   [5]        Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [6]        Haynes, T., Ed. and D. Noveck, Ed., "Network File System
              (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
              March 2015, <https://www.rfc-editor.org/info/rfc7530>.

   [7]        Haynes, T., Ed. and D. Noveck, Ed., "Network File System
              (NFS) Version 4 External Data Representation Standard
              (XDR) Description", RFC 7531, DOI 10.17487/RFC7531, March
              2015, <https://www.rfc-editor.org/info/rfc7531>.

   [8]        Noveck, D., Ed. and C. Lever, "Network File System (NFS)
              Version 4 Minor Version 1 Protocol", RFC 8881,
              DOI 10.17487/RFC8881, August 2020,
              <https://www.rfc-editor.org/info/rfc8881>.






Noveck                    Expires 3 March 2022                 [Page 66]


Internet-Draft               Nfsv4 Security                  August 2021


   [9]        Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              External Data Representation Standard (XDR) Description",
              RFC 5662, DOI 10.17487/RFC5662, January 2010,
              <https://www.rfc-editor.org/info/rfc5662>.

   [10]       Haynes, T., "Network File System (NFS) Version 4 Minor
              Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
              November 2016, <https://www.rfc-editor.org/info/rfc7862>.

   [11]       Haynes, T., "Network File System (NFS) Version 4 Minor
              Version 2 External Data Representation Standard (XDR)
              Description", RFC 7863, DOI 10.17487/RFC7863, November
              2016, <https://www.rfc-editor.org/info/rfc7863>.

   [12]       Myklebust, T. and C. Lever, "Towards Remote Procedure Call
              Encryption By Default", Work in Progress, Internet-Draft,
              draft-ietf-nfsv4-rpc-tls-11, 23 November 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-
              rpc-tls-11>.

18.2.  Informative References

   [13]       Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
              and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
              Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
              October 2017, <https://www.rfc-editor.org/info/rfc8257>.

Appendix A.  Changes Made

   This section summarizes the substantive changes between the treatment
   of security in previous minor version specification documents (i.e.
   RFCs 7530 and 8881) and the new treatment applying to NFSv4 as a
   whole.

   This is expected to be helpful to implementers familiar with previous
   specifications but also has an important role in verifying the
   working group consensus for these changes and in guiding the search
   for potential compatibility issues.

A.1.  Motivating Changes

   A number of changes reflect the basic motivation for a new treatment
   of NFSv4 security.  These include the ability to obtain privacy and
   integrity services from the RPC transport rather than as a service
   ancillary to a specific authentication flavor.





Noveck                    Expires 3 March 2022                 [Page 67]


Internet-Draft               Nfsv4 Security                  August 2021


   This motivated a major reorganization of the treatment of security
   together with a needed emphasis on the security of data in flight.
   In addition, the security negotiation framework for NFSv4 has been
   significantly enhanced to support the combined negotiation of
   authentication-related services and transport characteristics.

   Despite these major changes there are not expected to be
   compatibility issues between peers supporting secure transport
   characteristics and those without such support.

   Another such change was in the treatment of AUTH_SYS, previously
   described, inaccurately, as an "OPTIONAL means of authentication"
   with the unfortunate use of the RFC2119 keyword obscuring the
   negative consequences of the typical use of AUTH_SYS (in the clear;
   without client-peer authentication) for security by enabling the
   execution of unauthenticated requests.

   The new treatment avoids the inappropriate use of term
   "authentication" for all activities triggered by the use of RPC
   authentication flavors and clearly distinguishes those flavors
   providing authentication from those procinding identification only or
   neither identification nor authentication.

A.2.  Other Changes

   The need to make the major changes discussed in Appendix A.1 has
   meant that much text dealing with security has needed to be
   significantly revised or rewritten.  As a result of the process, may
   issues involving unclear, inconsistent, or otherwise inappropriate
   text were uncovered and needed to be dealt with.

   While the author believes such changes are necessary, the fact that
   we are changing a document adopted by consensus requires the working
   group to be clear about the acceptability of the changes.  This
   applies to both the troublesome issues discussed in Section 3.4 and
   to the other changes included below.

   Because of concurrent re-organizations, the ordering of the list
   follows the text of the current version which may differ considrably
   from that in earlier versions of the I-D.

   *  In order to deal better with the fact that ACLs have multiple uses
      some signifcant structural changes have been made.

      Section 4, a new top-level section describes the the structure of
      ACLs,





Noveck                    Expires 3 March 2022                 [Page 68]


Internet-Draft               Nfsv4 Security                  August 2021


   *  In Section 6.1, makes clear that owner and owner group are
      essentially REQUIRED attributes.

   *  Also in Section 6.1, there is added clarity in the discussion of
      support for multiple authorization approaches by eliminating use
      of the subjective term "reasonable semantics".

      In connection with this clarification, we mave switched from
      describing the needed co-ordination between modes and acls as
      "goals" to describing them as "requirements" to give clients some
      basis for expecting interoperability in handling these issues.

      As a result of this shift to a prescriptive framework applying to
      all minor versions it becomes possible to treat all minor versions
      together.  In earlier versions of this document, it had been
      assumed that v4.0 was free to ignore the relevant prescriptions
      first put forth in RFC 5661 and only needed to address the "goals"
      for this co-ordination.



Appendix B.  Acknowledgments

   The author wishes to thank Tom Haynes for his helpful suggestion to
   deal with security for all NFSv4 minor versions in the same document.

   The author wishes to draw people's attention to Nico Williams' remark
   that NFSv4 security was not so bad, except that there was no
   provision for authentication of the client peer.  This perceptive
   remark, which now seems like common sense, did not seem so when made,
   but it has served as a beacon for those putting NFSv4 security on a
   firmer footing.  Our gratitude is appropriate.

   The author wishes to acknowledge the important role of the authors of
   RPC-with-TLS, Chuck Lever and Trond Myklebust, in moving the NFS
   security agenda forward and thank them for all their efforts to
   improve NFS security.

   The author wishes to thank Chuck Lever for his many helpful comments
   about nfsv4 security issues, his explanation of many unclear points,
   and and much important guidance he provided that is reflected in this
   document.

   The author wishes to thank Rick Macklem for his role in clarifying
   possible server policies regarding RPC-over-TLS and bringing possible
   approaches to the attention of the working group.





Noveck                    Expires 3 March 2022                 [Page 69]


Internet-Draft               Nfsv4 Security                  August 2021


Author's Address

   David Noveck (editor)
   NetApp
   1601 Trapelo Road, Suite 16
   Waltham, MA 02451
   United States of America

   Phone: +1-781-572-8038
   Email: davenoveck@gmail.com









































Noveck                    Expires 3 March 2022                 [Page 70]