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

[Trond Myklebust <[e-mail]>]

On Mon, 15 Apr 2019 at 18:14, Chuck Lever <[e-mail]> wrote:
>
>
>
> > Begin forwarded message:
> >
> > From: [e-mail]
> > Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
> > Date: April 15, 2019 at 1:48:18 PM EDT
> > To: <[e-mail]>
> > Cc: [e-mail]
> > Reply-To: [e-mail]
> >
> >
> > 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)

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

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?

Cheers
  Trond