Re: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

Benjamin Kaduk <kaduk@MIT.EDU> Sat, 23 January 2016 18:08 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92001A21C7; Sat, 23 Jan 2016 10:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDEgGKMAvYuD; Sat, 23 Jan 2016 10:08:49 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5731A21C4; Sat, 23 Jan 2016 10:08:48 -0800 (PST)
X-AuditID: 12074424-f79216d00000156e-a3-56a3c1affdd6
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id B8.B0.05486.FA1C3A65; Sat, 23 Jan 2016 13:08:47 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u0NI8kQv022221; Sat, 23 Jan 2016 13:08:46 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0NI8f3p024686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jan 2016 13:08:44 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u0NI8f9L015587; Sat, 23 Jan 2016 13:08:41 -0500 (EST)
Date: Sat, 23 Jan 2016 13:08:40 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <56A397CB.7060606@cs.tcd.ie>
Message-ID: <alpine.GSO.1.10.1601231258390.26829@multics.mit.edu>
References: <20160121141530.8170.25186.idtracker@ietfa.amsl.com> <166532A7-FDCC-4021-8314-8CCD2DB36703@primarydata.com> <56A397CB.7060606@cs.tcd.ie>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0V1/cHGYQcsMCYv5N48yW8z4M5HZ 4ta57cwWs98/YrWYvvcau8XR7RMYHdg81nZfZfNYsuQnk8f8uXIBzFFcNimpOZllqUX6dglc GfcnvWIq2CxYcat/HVsD4wfeLkZODgkBE4ljF9pZIGwxiQv31rN1MXJxCAksZpJo2HKVGSQh JLCRUeLNCz2IxCEmiRn/JzBCOA2MEp/bF7CBVLEIaEu8ergObBSbgIrEzDcbweIiAvoSezef YwdpYBZYxShxc1srWJGwQJbEsomzgVZwcHAKaEq0nU8HCfMKOEpMevqCHWLzFEaJpj0pILao gI7E6v1TWCBqBCVOznwCZjMLaEksn76NZQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYn J+blpRbpmuvlZpbopaaUbmIEh7aLyg7G5kNKhxgFOBiVeHg9Ji4KE2JNLCuuzD3EKMnBpCTK q1ezOEyILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO/MnUA53pTEyqrUonyYlDQHi5I4766OuWFC AumJJanZqakFqUUwWRkODiUJ3m0HgBoFi1LTUyvSMnNKENJMHJwgw3mAhvOD1PAWFyTmFmem Q+RPMSpKifMmgSQEQBIZpXlwveDUs5tJ9RWjONArwrwPQap4gGkLrvsV0GAmoMF/NcEGlyQi pKQaGH3esC2vb93VOU3l2stH05MEDnzslmD6ax/GEWS3umlefz3fJo2AspXpXqz5Hovvhync PPQkqHzGivu8up6fY59p7N1rOWVThFv42f/XmQxs/NhyuLcsF7yh8/l9/tGwx/a3mhZGOQo+ cvd/GHXrgk/n1EXxBv+Oa+xQedMQfOp8bPLTuitt05VYijMSDbWYi4oTAc+XahIYAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/tKNUWhRnL7Yt3lLgUcXC1pkCn6Y>
Cc: nfsv4-chairs@ietf.org, The IESG <iesg@ietf.org>, nfsv4@ietf.org, draft-ietf-nfsv4-minorversion2@ietf.org
Subject: Re: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 23 Jan 2016 18:08:51 -0000

On Sat, 23 Jan 2016, Stephen Farrell wrote:

>
> >> - 4.10: thanks for providing all that!
> >>
> >> - 4.10: possibly dumb question: does this (or NFSv4) support
> >> what a user would perceive as an encrypting file system
> >> where the keys are held-by/derived from something on the
> >> user's machine? If so, and if the two servers involved use
> >> keys known at the user's machine and not by the NFS
> >> infrastructure then I'm not sure how this can work. IOW, if
> >> there's a decryption and then a re-encryption required in a
> >> server-server copy and if that needs any keying material
> >> from the client then could that ever work? Note that I'm not
> >> talking about securing the file during the server-server
> >> copy but de-crypting before sending and then re-encrypting
> >> before storing.
> >
> > Petty sure that Kerberos provides for this.
>
> Really? I'd be surprised. That probably means I didn't ask
> the question well though:-)
>
> Does NFS have any support for an encrypted file system such
> that the long term keys protecting those files can be stored
> e.g. on a usb dongle that the user keeps?
>
> If so, then I doubt server-server copy can work in such cases
> and that probably would need to be documented. If not, then...
> not:-)

I don't know that there is much that has been said about a ~"client-side
encrypted network filesystem", i.e., it is not really clear that NFSv4
supports such a scheme at all.  In particular, the scheme would need to
specify whether the encryption key depends only on the client/user or also
on the remote server holding the encrypted data; in the latter case,
decryption/re-encryption would be needed, and I don't think the NFSv4
server-to-server copy scheme makes a provision for passing around such key
material.

In short, assuming that I am understanding the question correctly (an
encrypted filesystem built on top of NFSv4 where the data encryption is
done on the NFS client), I don't think Kerberos magically makes this work.

I don't know whether enough people are (interested in) doing this sort of
thing to make it worth adding a note that server-side copy is potentially
incompatible with it.

-Ben