Re: [secdir] secdir review of draft-ietf-nfsv4-federated-fs-protocol-13

[Chuck Lever <[e-mail]>]

On Oct 17, 2012, at 12:59 PM, Charlie Kaufman <[e-mail]> wrote:

> 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).

When authoring the Security Considerations section, we discussed "MAY use" versus "MUST use" privacy-protecting transport layer security.  Some FedFS deployments do not require heavyweight privacy protection because they exist in environments where threats are well-understood and controlled.  For example, when the NSDB service is exposed only to file servers via a private network, public key security for a file server's junction resolution queries is overkill.

We felt that spelling out possible threats and then allowing deployment without TLS, but recommending its use when possible, was sufficient.  We agree, however, that this is a gray area, and welcome suggestions for improving the text.

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

Thanks for your review!

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com