Security for the NFSv4 Protocols

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¶

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.¶

  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.¶

• 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.¶

  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.¶

  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").¶

• 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.¶

• 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.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.¶

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

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.¶

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¶

    {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¶

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

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 */

6.4. ACL-based Authorization Model

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;

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;

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

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

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).¶

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.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).¶
• 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.¶

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

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.¶

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.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.¶

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.¶

  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.¶

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.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,¶

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.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.¶

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.¶

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.¶

• 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]¶

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.¶

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

/*
 * 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;
};

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.¶

• 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.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.2. Security Considerations Scope

15.3. Major New Recommendations

15.4. Data Security Threats

[TBD in -01]¶

15.5. Authentication-based threats

15.6. Disruption and Denial-of-Service Attacks

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]¶

17.1. Dummy Section AUTHFA-acl-ace

17.2. Dummy Section AUTHFA-acl-aclsupport

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.¶

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,¶

• 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.¶

• ¶

• ¶