Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

----- Original Message -----
> From: "Trond Myklebust" <trondmy@gmail.com>
> To: "Chuck Lever" <chuck.lever@oracle.com>
> Cc: "NFSv4" <nfsv4@ietf.org>
> Sent: Tuesday, April 16, 2019 2:37:54 PM
> Subject: Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

> On Mon, 15 Apr 2019 at 18:14, Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>>
>>
>> > Begin forwarded message:
>> >
>> > From: internet-drafts@ietf.org
>> > Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
>> > Date: April 15, 2019 at 1:48:18 PM EDT
>> > To: <i-d-announce@ietf.org>
>> > Cc: nfsv4@ietf.org
>> > Reply-To: nfsv4@ietf.org
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> > This draft is a work item of the Network File System Version 4 WG of the IETF.
>> >
>> >        Title           : Remote Procedure Call Encryption By Default
>> >        Authors         : Trond Myklebust
>> >                          Charles Lever
>> >       Filename        : draft-ietf-nfsv4-rpc-tls-01.txt
>> >       Pages           : 17
>> >       Date            : 2019-04-15
>> >
>> > Abstract:
>> >   This document describes a mechanism that opportunistically enables
>> >   encryption of in-transit Remote Procedure Call (RPC) transactions
>> >   with minimal administrative overhead and full interoperation with ONC
>> >   RPC implementations that do not support this mechanism.  This
>> >   document updates RFC 5531.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
>> >
>> > There are also htmlized versions available at:
>> > https://tools.ietf.org/html/draft-ietf-nfsv4-rpc-tls-01
>> > https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-01
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpc-tls-01
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>>
>> Does this document need to say anything specific about reverse-direction
>> RPC operations? (i.e., NFSv4.1 callbacks on the same communication channel)
> 

I don't think so. You just describe RPC related behavior. All NFS4 protocol
specific recommendation probably should go into to a different document.

> We might perhaps note that if the server uses a TLS protected channel
> to send back channel RPC calls, then those calls are automatically
> authenticated by virtue of the server certificate used to set up TLS.
> i.e. the client may just want to accept all back channel RPC calls,
> including those using AUTH_NULL or AUTH_SYS authentication.
> 
> There is the question of the NFSv4 back channel, which is server initiated.

The same here, a different document that talks about what NFS client should do,
what server should do, implication on pNFS (same security..), migration and so on.

> If we want servers to be able to use that as a replacement
> for RPCSEC_GSS, then we'd need to specify a certificate for the client
> to present to the server. Ditto for NLM, if we want to go even further
> back in time...
> Do we care?
> 
> A more general question that this raises is: Do we consider TLS as
> part of the authentication mechanism, and if so, what is its role?
> IOW: if the client does present a certificate when it sets up the TLS
> channel, then should that suffice to prevent an attacker from setting
> up a new TCP connection to the same server, and spoofing the identity
> of that client without possessing the original client certificate?
> If we do want that ability, then we should also look at consequences
> for the NFSv4 state model and perhaps add a SP4_TLS mode to the state
> protection negotiation in EXCHANGE_ID (as we already do for SSV).

The same way as rfc1831 enforces unix security - up to service specific doc.
Even RPCSEC_GSS doesn't require gss context per user. TLS session per user
might be a challenging task.  

> 
> There is also the issue of trunking. Do we want to allow NFS clients
> to use TLS authentication as a way to identify multi-homed servers?

This is an interesting one. What about migration? Require 'Subject
Alternative Name'?  Is this different from kerberos based trunking?

Regards,
   Tigran.

> 
> Cheers
>  Trond
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4