--- 1/draft-ietf-nfsv4-rfc3530bis-19.txt 2012-09-25 18:13:55.193342493 +0200 +++ 2/draft-ietf-nfsv4-rfc3530bis-20.txt 2012-09-25 18:13:55.733426590 +0200 @@ -1,19 +1,19 @@ NFSv4 T. Haynes, Ed. Internet-Draft NetApp Intended status: Standards Track D. Noveck, Ed. -Expires: March 7, 2013 EMC - September 03, 2012 +Expires: March 29, 2013 EMC + September 25, 2012 Network File System (NFS) Version 4 Protocol - draft-ietf-nfsv4-rfc3530bis-19.txt + draft-ietf-nfsv4-rfc3530bis-20.txt Abstract The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, @@ -38,21 +38,21 @@ 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 http://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 March 7, 2013. + This Internet-Draft will expire on March 29, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -9945,48 +9945,50 @@ | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_STALE_STATEID | | COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | - | | NFS4ERR_BADXDR, NFS4ERR_FHEXPIRED, | - | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, | - | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | - | | NFS4ERR_RESOURCE, NFS4ERR_ROFS, | - | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | - | | NFS4ERR_SYMLINK | + | | NFS4ERR_BADXDR, NFS4ERR_DELAY, | + | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | + | | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, | + | | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, | + | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | + | | NFS4ERR_STALE, NFS4ERR_SYMLINK | | CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, | | | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, | | | NFS4ERR_BADTYPE, NFS4ERR_BADXDR, | | | NFS4ERR_DELAY, NFS4ERR_DQUOT, | | | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, | | | NFS4ERR_PERM, NFS4ERR_RESOURCE, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_STALE | - | DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_NOTSUPP, | - | | NFS4ERR_LEASE_MOVED, NFS4ERR_RESOURCE, | - | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID | - | DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BAD_STATEID, | - | | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, | - | | NFS4ERR_INVAL, NFS4ERR_LEASE_MOVED, | - | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | - | | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, | + | DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DELAY, | + | | NFS4ERR_NOTSUPP, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | - | | NFS4ERR_STALE, NFS4ERR_STALE_STATEID | + | | NFS4ERR_STALE_CLIENTID | + | DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BAD_STATEID, | + | | NFS4ERR_BADXDR, NFS4ERR_DELAY, | + | | NFS4ERR_EXPIRED, NFS4ERR_INVAL, | + | | NFS4ERR_LEASE_MOVED, NFS4ERR_MOVED, | + | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | + | | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, | + | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | + | | NFS4ERR_STALE_STATEID | | GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | GETFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_STALE | @@ -10025,32 +10027,33 @@ | | NFS4ERR_DELAY, NFS4ERR_DENIED, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCK_RANGE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_STALE, NFS4ERR_STALE_CLIENTID | | LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, | | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | - | | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, | - | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | - | | NFS4ERR_INVAL, NFS4ERR_ISDIR, | - | | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCK_RANGE, | - | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | - | | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, | - | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | - | | NFS4ERR_STALE_STATEID | + | | NFS4ERR_BADXDR, NFS4ERR_DELAY, | + | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | + | | NFS4ERR_GRACE, NFS4ERR_INVAL, | + | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | + | | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, | + | | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, | + | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | + | | NFS4ERR_STALE, NFS4ERR_STALE_STATEID | | LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | - | | NFS4ERR_BADXDR, NFS4ERR_FHEXPIRED, | - | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | + | | NFS4ERR_BADXDR, NFS4ERR_DELAY, | + | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | + | | NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_STALE, NFS4ERR_SYMLINK, | | | NFS4ERR_WRONGSEC | | LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | @@ -10304,22 +10307,24 @@ | NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU | | NFS4ERR_BAD_SEQID | CLOSE, LOCK, LOCKU, OPEN, | | | OPEN_CONFIRM, OPEN_DOWNGRADE | | NFS4ERR_BAD_STATEID | CB_RECALL, CLOSE, DELEGRETURN, LOCK, | | | LOCKU, OPEN, OPEN_CONFIRM, | | | OPEN_DOWNGRADE, READ, SETATTR, WRITE | | NFS4ERR_CB_PATH_DOWN | RENEW | | NFS4ERR_CLID_INUSE | SETCLIENTID, SETCLIENTID_CONFIRM | | NFS4ERR_DEADLOCK | LOCK | | NFS4ERR_DELAY | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, | - | | CREATE, GETATTR, LINK, LOCK, LOCKT, | - | | LOOKUPP, NVERIFY, OPEN, OPENATTR, | + | | COMMIT, CREATE, DELEGPURGE, | + | | DELEGRETURN, GETATTR, LINK, LOCK, | + | | LOCKT, LOCKU, LOOKUP, LOOKUPP, | + | | NVERIFY, OPEN, OPENATTR, | | | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, | | | PUTROOTFH, READ, READDIR, READLINK, | | | REMOVE, RENAME, SECINFO, SETATTR, | | | SETCLIENTID, SETCLIENTID_CONFIRM, | | | VERIFY, WRITE | | NFS4ERR_DENIED | LOCK, LOCKT | | NFS4ERR_DQUOT | CREATE, LINK, OPEN, OPENATTR, RENAME, | | | SETATTR, WRITE | | NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME | | NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, | @@ -14535,26 +14540,33 @@ implement and simple to deploy and use, it is certainly not a safe model. Thus, NFSv4 mandates that implementations support a security model that uses end to end authentication, where an end-user on a client mutually authenticates (via cryptographic schemes that do not expose passwords or keys in the clear on the network) to a principal on an NFS server. Consideration should also be given to the integrity and privacy of NFS requests and responses. The issues of end to end mutual authentication, integrity, and privacy are discussed as part of Section 3. - Note that while NFSv4 mandates an end to end mutual authentication - model, the "classic" model of machine authentication via IP address - checking and AUTH_SYS identification can still be supported with the - caveat that the AUTH_SYS flavor is neither MANDATORY nor RECOMMENDED - by this specification, and so interoperability via AUTH_SYS is not - assured. + 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 LDAP ([41]), this means employing a security + service that uses authentication and data integrity. Kerberos and + TLS ([42]) 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 @@ -14580,21 +14592,21 @@ 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 match the previous use of these operations. See Section 9.1.1 for further discussion. 18. IANA Considerations - This section uses terms that are defined in [41]. + This section uses terms that are defined in [43]. 18.1. Named Attribute Definitions IANA will create a registry called the "NFSv4 Named Attribute Definitions Registry". The NFSv4 protocol supports the association of a file with zero or more named attributes. The name space identifiers for these attributes are defined as string names. The protocol does not define the specific assignment of the name space for these file attributes. @@ -14603,22 +14615,22 @@ 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 be used, the assignment in registry will clearly state the applicable limits. All assignments to the registry are made on a First Come First Served - basis, per section 4.1 of [41]. The policy for each assignment is - Specification Required, per section 4.1 of [41]. + basis, per section 4.1 of [43]. The policy for each assignment is + Specification Required, per section 4.1 of [43]. 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 a handle string that long. IANA should reject any assignment request with a named attribute that exceeds 128 UTF-8 characters. To give 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. @@ -14798,21 +14810,27 @@ [38] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [39] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation for WebNFS", RFC 2755, January 2000. [40] The Open Group, "Section 'unlink()' of System Interfaces of The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, HTML Version (www.opengroup.org), ISBN 1931624232", 2004. - [41] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + [41] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): + The Protocol", RFC 4511, June 2006. + + [42] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.2", RFC 5246, August 2008. + + [43] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Appendix A. Acknowledgments A bis is certainly built on the shoulders of the first attempt. Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Carl Beame, Mike Eisler, and David Noveck are responsible for a great deal of the effort in this work. Rob Thurlow clarified how a client should contact a new server if a