Skip to main content

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 revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-22
Requested 2012-10-11
Authors James Lentini , Renu Tewari , Chuck Lever
I-D last updated 2012-10-18
Completed reviews Genart Last Call review of -13 by Peter E. Yee (diff)
Genart Telechat review of -14 by Peter E. Yee (diff)
Tsvdir Early review of -?? by David L. Black
Secdir Last Call review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Request Last Call review on draft-ietf-nfsv4-federated-fs-protocol by Security Area Directorate Assigned
Result Ready
Completed 2012-10-18
review-ietf-nfsv4-federated-fs-protocol-secdir-lc-kaufman-2012-10-18-00

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