[nfsv4] Fwd: Stephen Farrell's No Objection on draft-ietf-nfsv4-federated-fs-protocol-14: (with COMMENT)

Chuck Lever <chuck.lever@oracle.com> Wed, 28 November 2012 23:18 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6921F8986 for <nfsv4@ietfa.amsl.com>; Wed, 28 Nov 2012 15:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub95hGN+lEl5 for <nfsv4@ietfa.amsl.com>; Wed, 28 Nov 2012 15:18:23 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D011F21F897B for <nfsv4@ietf.org>; Wed, 28 Nov 2012 15:18:23 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qASNILL1013071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Nov 2012 23:18:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qASNIKHI005056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2012 23:18:21 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qASNIKEE001423; Wed, 28 Nov 2012 17:18:20 -0600
Received: from [172.20.10.3] (/108.115.7.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Nov 2012 15:18:20 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Chuck Lever <chuck.lever@oracle.com>
Date: Wed, 28 Nov 2012 18:18:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <724A6781-D8A3-4AA9-8E9B-E12279DBF41C@oracle.com>
References: <20121128094917.25354.35650.idtracker@ietfa.amsl.com>
To: NFSv4 on Linux mailing list <nfsv4@ietf.org>
X-Mailer: Apple Mail (2.1499)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andy Adamson <William.Adamson@netapp.com>, Robert Thurlow <Robert.Thurlow@oracle.com>
Subject: [nfsv4] Fwd: Stephen Farrell's No Objection on draft-ietf-nfsv4-federated-fs-protocol-14: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 23:18:24 -0000

Begin forwarded message:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - section 6: *use* of TLS is RECOMMENDED which is fine, but
> you don't say that implementation of TLS is a MUST.  I think
> it'd be good to be explicit about that. (LDAP is a bit oddly
> structured, maybe in a way to leave wiggle room to say you
> conform here even though you don't support LDAP/TLS.)

Here is the first paragraph of section 6 of the NSDB document:

>    Both the NFSv4 and LDAPv3 protocols provide security mechanisms.
>    When used in conjunction with the federated filesystem protocols
>    described in this document, the use of these mechanisms is
>    RECOMMENDED.  Specifically, the use of RPCSEC_GSS [RFC2203], which is
>    built on the GSS-API [RFC2743], is RECOMMENDED on all NFS connections
>    between a file-access client and fileserver.  The "Security
>    Considerations" sections of the NFSv4.0 [3530bis] and NFSv4.1
>    [RFC5661] specifications contain special considerations for the
>    handling of GETATTR operations for the fs_locations and
>    fs_locations_info attributes.  For all LDAP connections established
>    by the federated filesystem protocols, the use of TLS [RFC5246], as
>    described in [RFC4513], is RECOMMENDED.


Looking back at the private e-mail thread at the end of July 2012 that culminates here:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg11248.html

I don't see that we excluded on purpose a requirement to implement (but not use) TLS for NSDB connections.  Should we add a requirement to implement?

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