Last Call Review of draft-ietf-nfsv4-federated-fs-protocol-
review-ietf-nfsv4-federated-fs-protocol-secdir-lc-kaufman-2012-10-18-00

Request Review of draft-ietf-nfsv4-federated-fs-protocol
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-22
Requested 2012-10-11
Other Reviews Genart Last Call review of -13 by Peter Yee (diff)
Genart Telechat review of -14 by Peter Yee (diff)
Tsvdir Early review of - by David Black (diff)
Review State Completed
Reviewer Charlie Kaufman
Review review-ietf-nfsv4-federated-fs-protocol-secdir-lc-kaufman-2012-10-18
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg03600.html
Review result Ready
Draft last updated 2012-10-18
Review completed: 2012-10-18

Review
review-ietf-nfsv4-federated-fs-protocol-secdir-lc-kaufman-2012-10-18






I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document
 editors and WG chairs should treat these comments just like any other last call comments.




 




This standards track document essentially defines an LDAP schema and associated semantics for storing federated NFS server metadata. Standardizing this schema and associated semantics will facilitate construction of federations of NFS file
 servers where the servers come from different vendors. This LDAP database (at least by my reading) appears to be designed to be accessed by the various NFS servers and not by NFS clients. NFS clients will continue to get redirections directly from the NFS
 servers. By centralizing and standardizing the metadata, it should be possible when adding or removing servers for file system branches or replicas to make the update in one place instead of in vendor-specific ways on each existing federated server.




 




The Security Considerations section correctly points out the potential damage from someone making unauthorized updates to the LDAP database or successfully impersonating the LDAP database to the various NFS servers. The information is not
 secret, however, and the document calls for the information to be readable without authentication of the client. The document recommends that this information be served from a dedicated LDAP database, and recommends accessing it over TLS. Some would argue
 that the spec should require that the access MUST be over some cryptographically strong protocol (i.e., if not TLS, then IPsec, SSH, or some such).




 




Within my limited understanding of NFS (and related file service protocols), this all seems entirely reasonable.




 




                --Charlie