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

Chuck Lever <> Wed, 17 October 2012 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B7D621F86A4; Wed, 17 Oct 2012 12:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zzwjndKh3xMY; Wed, 17 Oct 2012 12:47:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55DE121F85F4; Wed, 17 Oct 2012 12:47:36 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9HJlYdK023772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Oct 2012 19:47:35 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id q9HJlXdF014258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 19:47:34 GMT
Received: from ( []) by ( with ESMTP id q9HJlWlb010317; Wed, 17 Oct 2012 14:47:32 -0500
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Oct 2012 12:47:32 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_EE73F5ED-5EA4-44A9-9A0A-D73E31476743"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Chuck Lever <>
In-Reply-To: <>
Date: Wed, 17 Oct 2012 15:47:31 -0400
Message-Id: <>
References: <>
To: Charlie Kaufman <>
X-Mailer: Apple Mail (2.1499)
X-Source-IP: []
X-Mailman-Approved-At: Wed, 17 Oct 2012 13:25:28 -0700
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-nfsv4-federated-fs-protocol-13
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Oct 2012 19:47:37 -0000

On Oct 17, 2012, at 12:59 PM, Charlie Kaufman <> 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