NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99
Chair(s):
Brent Callaghan <brent@eng.sun.com>
Brian Pawlowski <beepy@netapp.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Vern Paxson <vern@aciri.org>
Mailing Lists:
General Discussion:nfsv4-wg@sunroof.eng.sun.com
To Subscribe: nfsv4-wg-request@sunroof.eng.sun.com
Archive: http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive
Description of Working Group:
The objective of this working group is to advance the state of NFS technology by producing a specification for NFS version 4 which will be submitted as an Internet standards track RFC. The first phase of the working group activity will produce a requirements document describing the limitations and deficiencies of NFS version 3, potential solutions for addressing these, and a cost/benefit analysis of the different solutions. Input for the development of this document will include experiences with other distributed file systems such as DCE/DFS and Coda. Following the publication of this document, the charter of the working group will be reassessed; however, it is anticipated that NFS version 4 will emphasize the following core features:
o Improved access and good performance on the Internet.
The protocol will be designed to perform well where latency is high and bandwidth is low, to adapt to the presence of congestion, to scale to very large numbers of clients per server, and to transit firewalls easily.
o Strong security with negotiation built into the protocol.
The protocol may build on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. The permission model needs to scale beyond the current flat integer UID space.
Additionally NFS version 4 will provide a mechanism to allow clients and servers to negotiate security and require clients and servers to support a minimal set of security schemes.
o Better cross-platform interoperability.
The protocol will feature a filesystem model that provides a useful, common set of features that does not unduly favor one filesystem or operating system over another.
o Designed for protocol extensions.
The protocol will be designed to accept standard extensions that do not compromise backward compatibility.
Goals and Milestones:
Jul 98 |
|
Issue strawman Internet-Draft for v4 |
Aug 98 |
|
Submit Initial Internet-Draft of requirements document |
Sep 98 |
|
Submit Final Internet-Draft of requirements document |
Oct 98 |
|
AD reassesses WG charter |
Dec 98 |
|
Submit v4 Internet-Draft sufficient to begin prototype implementations |
Mar 99 |
|
Begin Interoperability testing of prototype implementations |
Apr 99 |
|
Submit NFS version 4 to IESG for consideration as a Proposed Standard. |
Sep 99 |
|
Conduct final Interoperability tests |
Oct 99 |
|
Submit NFS version 4 to IESG for consideration as a Draft Standard. |
Internet-Drafts:
Request For Comments:
RFC |
Status |
Title |
RFC2623 |
PS |
NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 |
RFC2624 |
NFS Version 4 Design Considerations | |
Minutes, NFS version 4 (nfsv4) WG, Oslo IETF, reported by Brent Callaghan (edited by Spencer Shepler).
The NFSv4 WG met for one 2 hour session at the Oslo IETF, with approximately 35 attendees. The topics covered were the current status of the working group's documents and future schedule, brief discussion of security related issues and straw polls on various choices, discussions of recent caching proposal and where potential ACL proposals should progress.
Brent Callaghan opened the meeting with an overview of the agenda and introduction of Spencer Shepler to cover document related topics.
First item discussed was the release of RFC 2624 "NFS Version 4 Design Considerations". Spencer continued with a brief overview of the major updates to the most recent version of the NFSv4 protocol draft. The updated sections were meant to include consensus from the WG alias, to address internal document inconsistencies, and general left over work items. The file handle section was updated to include alias consensus. The file attributes section of the document was reformatted for an easier read. OPENATTR and PUTPUBFH procedure definitions were added to the document along with cleanup of the CREATE procedure's definition.
Next, Spencer presented his schedule for draft updates. Updates to the NFSv4 protocol draft are targeted for submission on the following dates:
- August 27th
- October 22nd
- December (mid to late) (this draft ready for proposed standard)
These dates are an attempt to match up Brent's proposed milestones changes and the dates for the NFSv4 bakeoff (Oct 19-21). (Note: see the following for Brent's email on the milestone changes http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1447.html). The December submission is targeted as the version used to move to proposed standard.
Spencer briefly mentioned the Oct 19-21 dates that have currently been chosen for the NFSv4 bake-off. Hotel meeting space is on hold in Santa Clara, CA. Spencer will send additional bake-off details to the WG in the near future.
Spencer was scheduled to cover implementation experiences with file sharing/locking but he had not made enough progress before the Oslo meeting to make a presentation worthwhile for those in attendance.
Mike Eisler then followed with a discussion of various NFSv4 security related topics. Mike reviewed past consensus along with polling the meeting attendees on particular topics to gauge direction or potential consensus. Mike first reviewed some of the decisions that had been made at the San Jose meeting. NFSv4 to use ONCRPC and RPCSEC_GSS the security framework. At San Jose, there was some controversy in specifying Kerberos V5 as a mandatory to implement security mechanism. There was interest in specifying Mike's LIPKEY mechanism as mandatory to implement. Suggestions were made in San Jose to use IPSEC and/or TLS. Mike pointed out that IPSEC does not provide support for multiple users per connection and no one has stepped forward with a TLS proposal for NFS.
Mike moved on to say that he had updated his LIPKEY draft with comments and corrections (draft-ietf-cat-lipkey-01.txt). Mike presented this material to the CAT WG where it was well received. The CAT WG will be moving the draft forward.
Mike then raised the security related issues on his discussion list. The first was the recent UID/GID discussion. Recent discussion has been related to the cost of translating UID to proposed string representation. Also mapping 32bit uid to a 128 bit UUID is also costly. Mike also discussed the topic of proxy NFS servers and how they would affect the security model. Two models were suggested as a means to start appropriate discussions of proxy servers.
Model 1: Client is unaware that NFS server is a proxy
- client authenticates to the proxy only
- this model does not provide end-to-end authentication
- trivially implemented by the NFS server exporting its mounted file systems
Model 2: Client is aware that the NFS server is a proxy
Mike then proceeded with various straw polls:
Should nfs v4 use TLS for security ...
- in addition to rpcsec_gss?
- 1 Yes
- instead of rpcsec_gss?
- 0 Yes
- is anyone willing to sign up to design it?
- 0 Yes
Should nfs v4 specify kerberos v5 as mandatory to implement?
- 8 Yes
- 4 No
Should nfs v4 specify lipkey as mandatory to implement?
- 4 Yes
- 4 No
One person said No to both, in protest of IETF policy requiring mandatory to implement security in protocols.
Is the nfs v2/v3 32 bit uid/gid model broken in that it is uncontrolled?
- 8 Yes
- 0 No
(Note that uncontrolled and "not collision proof" were defined as equivalent to avoid balkanization of the poll based on subtle semantic differences.)
- allows too few identifiers?
- 1 Yes
- If so, should we fix nfs v4?
- 6 Yes
- If so should we use
- strings of form user@dns_domain?
- 5 Yes
- UUIDs? 1 Yes
- something else?
- 6 Yes
- two or more of the above?
- 0 Yes
- all of the above?
- 0 Yes
Next on the agenda was Dave Noveck. Dave covered two main items: a discussion of his recent caching proposal and ongoing work to form a proposal for ACL support. Dave pointed out that the current draft protocol does not present any caching discussion. The requirements that Dave presented for caching are that it must not break share reservations or locking, reduce the amount of contact with the server and file locking should not present a large performance hit. With this proposal, Dave's goal was not to provide cache consistency. Some of the reasons not to do full cache consistency are there are restrictions on callback use due to firewall issues, what will it provide because sharing without reservations or locks is difficult, and there are issues or read-write atomicity, attribute consistency, name space consistency and global serializability that seem out of scope of NFSv4. The current proposal focuses on opportunistic delegation in that the 'control' of the file is delegated to the client on OPEN. This approach uses callbacks and if callbacks are not available based on network topology then the server denies the delegation request. Some open questions revolve around what Dave calls cacheability control. What semantics are required for a file system to be cacheable? Need a way to tell if two file handles designate the same object. Need wcc_info.
At this point, Dave moved on to discuss the work he has done in researching various ACL solutions. Dave has done this to understand the variations to see if a common solution can be built for a ACL proposal for NFSv4. He has looked at various Unix solutions which are somewhat like Posix drafts, NT ACLs, and DCE ACLs. The Posix ACL model is very Unixy. There are differences between drafts 13 and 15 which seem to be the two most common starting points for Unix implementations. There is a mask entry and owning user and owning group. The model of evaluation is accumulation vs. all-at-once requirements. NT ACLs are significantly different. SIDs are used vs user and group. Order of ACL entries significant vs. order insensitive. Different permission bits from the Posix model. NT ACLs use an accumulation model and has various types of entries such as denial entries which make the entries order dependent. Posix draft 13 is closer to being a subset of NT ACLs.
Dave sees four options. Choose the NT model. It is larger (not quite a superset) and the SID issue would have to be dealt with. Second option is to choose the Posix model and if so which one would be used. Option three would be to combine the two in some way, if possible. Finally, a union of the two ACL 'languages' could be created. The final option present the problems that an ACL could be created that neither client or server could properly interpret, some server may have significant difficulty with the union, and there is a major problem with user-mode NFS servers.
Other various issues with the various ACL solutions were presented. ID mapping is problematic since SIDs are like user/group but there is a single name space for SIDs. Permission bits are more plentiful in the NT model and mapping the NT bits to Posix may not be possible. NT has denial entries while Unix generally does not.
Based on the options presented there was not a clear consensus on what direction to undertake. While ACL support seemed to be strong requirement for NFSv4, a clear solution or direction has not presented itself.
After Dave's presentation, Brian Pawlowski lead an open discussion of the various topics of the day. A brief summary of some of that discussion. For caching it seems that the data should be consistent at release of a lock or share reservation. There was some disagreement whether callbacks should mandatory to implement in relation to Dave's caching proposal (should the client be able to count on server's support of delegations). There was general agreement that the UID/GID mechanism in NFSv2/v3 is broken.
Agenda
NFS Version 4 Security Update
Stuff I'm Working On (ACL's Et Cetera)