Section 15.2. The value of callback_ident is supplied by the client during SETCLIENTID. The server must use the client-supplied callback_ident during the CB_COMPOUND to allow the client to properly identify the server. Illegal operation codes are handled in the same way as they are handled for the COMPOUND procedure.
Section 10.4.3 for a full description of how the client and server are to interact with the use of CB_GETATTR. If the filehandle specified is not one for which the client holds an OPEN_DELEGATE_WRITE delegation, an NFS4ERR_BADHANDLE error is returned.
Section 15.2.4 for more details. The status field of CB_ILLEGAL4res MUST be set to NFS4ERR_OP_ILLEGAL.
Section 3. When an NFSv4 mandated security model is used and a security principal or an NFSv4 name in user@dns_domain form needs to be translated to or from a local representation as described in Section 5.9, the translation SHOULD be done in a secure manner that preserves the integrity of the translation. For communication with a name service such as the Lightweight Directory Access Protocol (LDAP) ([RFC4511]), this means employing a security service that uses authentication and data integrity. Kerberos and Transport Layer Security (TLS) ([RFC5246]) are examples of such a security service. Note that being REQUIRED to implement does not mean REQUIRED to use; AUTH_SYS can be used by NFSv4 clients and servers. However, AUTH_SYS is merely an OPTIONAL security flavor in NFSv4, and so interoperability via AUTH_SYS is not assured. For reasons of reduced administration overhead, better performance, and/or reduction of CPU utilization, users of NFSv4 implementations may choose to not use security mechanisms that enable integrity protection on each remote procedure call and response. The use of mechanisms without integrity leaves the customer vulnerable to an attacker in between the NFS client and server that modifies the RPC request and/or the response. While implementations are free to provide the option to use weaker security mechanisms, there are two operations in particular that warrant the implementation overriding user choices.
The first such operation is SECINFO. It is recommended that the client issue the SECINFO call such that it is protected with a security flavor that has integrity protection, such as RPCSEC_GSS with a security triple that uses either rpc_gss_svc_integrity or rpc_gss_svc_privacy (rpc_gss_svc_privacy includes integrity protection) service. Without integrity protection encapsulating SECINFO and therefore its results, an attacker in the middle could modify results such that the client might select a weaker algorithm in the set allowed by the server, making the client and/or server vulnerable to further attacks. The second operation that SHOULD use integrity protection is any GETATTR for the fs_locations attribute. The attack has two steps. First, the attacker modifies the unprotected results of some operation to return NFS4ERR_MOVED. Second, when the client follows up with a GETATTR for the fs_locations attribute, the attacker modifies the results to cause the client to migrate its traffic to a server controlled by the attacker. Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are responsible for the release of client state, it is imperative that the principal used for these operations is checked against and matches with the previous use of these operations. See Section 9.1.1 for further discussion. Unicode in the form of UTF-8 is used for file component names (i.e., both directory and file components), as well as the owner and owner_group attributes; other character sets may also be allowed for file component names. String processing (e.g., Unicode normalization) raises security concerns for string comparison. See Sections 5.9 and 12 for further discussion, and see [RFC6943] for related identifier comparison security considerations. File component names are identifiers with respect to the identifier comparison discussion in [RFC6943] because they are used to identify the objects to which ACLs are applied; see Section 6.
RFC5226]. RFC3530] and [RFC5661]. This section introduces no new changes, but it does recap the intent. The NFSv4 protocol supports the association of a file with zero or more named attributes. The namespace identifiers for these attributes are defined as string names. The protocol does not define the specific assignment of the namespace for these file attributes. The IANA registry promotes interoperability where common interests exist. While application developers are allowed to define and use attributes as needed, they are encouraged to register the attributes with IANA. Such registered named attributes are presumed to apply to all minor versions of NFSv4, including those defined subsequently to the registration. Where the named attribute is intended to be limited with regard to the minor versions for which they are not to be used, the assignment in the registry will clearly state the applicable limits. The registry is to be maintained using the Specification Required policy as defined in Section 4.1 of [RFC5226]. Under the NFSv4 specification, the name of a named attribute can in theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 clients and servers will be unable to handle a string that long. IANA should reject any assignment request with a named attribute that exceeds 128 UTF-8 characters. To give the IESG the flexibility to set up bases of assignment of Experimental Use and Standards Action, the prefixes of "EXPE" and "STDS" are Reserved. The zero-length named attribute name is Reserved. The prefix "PRIV" is allocated for Private Use. A site that wants to make use of unregistered named attributes without risk of conflicting with an assignment in IANA's registry should use the prefix "PRIV" in all of its named attributes.
Because some NFSv4 clients and servers have case-insensitive semantics, the fifteen additional lowercase and mixed-case permutations of each of "EXPE", "PRIV", and "STDS" are Reserved (e.g., "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA must not allow two assignments that would conflict if both named attributes were converted to a common case. The registry of named attributes is a list of assignments, each containing three fields for each assignment. 1. A US-ASCII string name that is the actual name of the attribute. This name must be unique. This string name can be 1 to 128 UTF-8 characters long. 2. A reference to the specification of the named attribute. The reference can consume up to 256 bytes (or more, if IANA permits). 3. The point of contact of the registrant. The point of contact can consume up to 256 bytes (or more, if IANA permits). RFC 3530, IANA has o replaced all references to RFC 3530 in the Network Identifier (r_netid) registry with references to this document. o replaced the reference to the nfs registration's reference to RFC 3530 in the GSSAPI/Kerberos/SASL Service names registry with a reference to this document.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997, <http://www.rfc-editor.org/info/rfc2203>. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003, <http://www.rfc-editor.org/info/rfc3490>. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003, <http://www.rfc-editor.org/info/rfc3492>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February 2009, <http://www.rfc-editor.org/info/rfc5403>. [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", RFC 5665, January 2010, <http://www.rfc-editor.org/info/rfc5665>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>. [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos", BCP 179, RFC 6649, July 2012, <http://www.rfc-editor.org/info/rfc6649>. [RFC7531] Haynes, T., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description", RFC 7531, March 2015, <http://www.rfc-editor.org/info/rfc7531>. [SPECIALCASING] The Unicode Consortium, "SpecialCasing-7.0.0.txt", Unicode Character Database, March 2014, <http://www.unicode.org/ Public/UCD/latest/ucd/SpecialCasing.txt>. [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 7.0.0", (Mountain View, CA: The Unicode Consortium, 2014 ISBN 978-1-936213-09-2), June 2014, <http://www.unicode.org/versions/latest/>. [openg_symlink] The Open Group, "Section 3.372 of Chapter 3 of Base Definitions of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[Chet] Juszczak, C., "Improving the Performance and Correctness of an NFS Server", USENIX Conference Proceedings, June 1990. [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking 2(2), pp. 122-136, April 1994. [IESG_ERRATA] IESG, "IESG Processing of RFC Errata for the IETF Stream", July 2008. [MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol Specification", MS-SMB 43.0, May 2014. [P1003.1e] Institute of Electrical and Electronics Engineers, Inc., "IEEE Draft P1003.1e", 1997. [RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989, <http://www.rfc-editor.org/info/rfc1094>. [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>. [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995, <http://www.rfc-editor.org/info/rfc1833>. [RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996, <http://www.rfc-editor.org/info/rfc2054>. [RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996, <http://www.rfc-editor.org/info/rfc2055>. [RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997, <http://www.rfc-editor.org/info/rfc2224>. [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999, <http://www.rfc-editor.org/info/rfc2623>.
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, June 1999, <http://www.rfc-editor.org/info/rfc2624>. [RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation for WebNFS", RFC 2755, January 2000, <http://www.rfc-editor.org/info/rfc2755>. [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000, <http://www.rfc-editor.org/info/rfc3010>. [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002, <http://www.rfc-editor.org/info/rfc3232>. [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003, <http://www.rfc-editor.org/info/rfc3530>. [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005, <http://www.rfc-editor.org/info/rfc4121>. [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005, <http://www.rfc-editor.org/info/rfc4178>. [RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006, <http://www.rfc-editor.org/info/rfc4506>. [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006, <http://www.rfc-editor.org/info/rfc4511>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>. [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>. [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>. [fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [fsync] The Open Group, "Section 'fsync()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [getpwnam] The Open Group, "Section 'getpwnam()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [read_api] The Open Group, "Section 'read()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [readdir_api] The Open Group, "Section 'readdir()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [stat] The Open Group, "Section 'stat()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>.
[unlink] The Open Group, "Section 'unlink()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [write_api] The Open Group, "Section 'write()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition (HTML Version), ISBN 1937218287, April 2013, <http://www.opengroup.org/>. [xnfs] The Open Group, "Protocols for Interworking: XNFS, Version 3W, ISBN 1-85912-184-5", February 1998.
Section 12 and contributed numerous useful suggestions, without which the necessary revision of that section for this document would not have been possible. Peter Staubach read almost all of the earlier draft versions of Section 12, leading to the published result, and his numerous comments were always useful and contributed substantially to improving the quality of the final result. Peter Saint-Andre was gracious enough to read the most recent draft version of Section 12 and provided some key insight as to the concerns of the Internationalization community. James Lentini graciously read the rewrite of Section 8, and his comments were vital in improving the quality of that effort. Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Myklebust were faithful attendants of the biweekly triage meeting and accepted many an action item. Bruce Fields was a good sounding board for both the third edge condition and courtesy locks in general. He was also the leading advocate of stamping out backport issues from [RFC5661]. Marcel Telka was a champion of straightening out the difference between a lock-owner and an open-owner. He has also been diligent in reviewing the final document. Benjamin Kaduk reminded us that DES is dead, and Nico Williams helped us close the lid on the coffin. Elwyn Davies provided a very thorough and engaging Gen-ART review; thanks!