Re: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

[Chuck Lever <[e-mail]>]

Hi Rob-


> On Nov 19, 2018, at 4:05 PM, Rob Thurlow <[e-mail]> wrote:
> 
> Hi Chuck, some feedback on this nice, short draft:
> 
> On 11/19/18 08:55 AM, Chuck Lever wrote:
> 
> > URL: https://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpc-tls-01.txt
> 
> > However, experience has shown that RPCSEC GSS is challenging to
> > deploy, especially in environments where:
> > ...
> >  o  Host identity management is carried out in a security domain that
> >     is distinct from user identity management.
> 
> I don't think I understand this sub-bullet; do you have
> an example that would clarify?

In a cloud environment, the provider needs to manage the
provision of new hosts. Therefore the provider needs to be
responsible for provisioning per-host authentication material.

The tenant might want to use Kerberos to authenticate her
user base. The tenant can provision a Kerberos realm and KDC.
However, Kerberos forces the use of a model where host and
user identity are both handled by the KDC.

The cloud provider would need administrative access to the
tenant's KDC when provisioning new hosts for the tenant--even
hosts that provide a network service that the tenant's users
never log into.

One scenario I envision is that a tenant can set up Kerberos
for user authentication, while a provider-run PKI can be used
to identify the tenant's hosts.


> > 4.2.  Streams and Datagrams
> >
> >  RPC commonly operates on stream transports and datagram transports.
> >  When operating on a stream transport, using TLS [RFC8446] is
> >  appropriate.  On a datagram transport, RPC can use DTLS [RFC6347].
> 
> Do we point to DTLS anywhere else in our NFS documents?  I'm
> wondering if we want to support datagram service this way.

The NFSv4 documents restrict the use of datagram RPC transports.

However, this document describes a generic RPC-over-TLS mechanism
which could be used for other upper layer protocols that are
permitted to operate on datagram transports.

Maybe I don't understand your comment.


> > 4.3.  Authentication
> 
> Good start here, but I expect that in practice this will
> result in a step down from the state-of-the-art we know -
> RPCSEC_GSS w/krb5p - to TLS + AUTH_SYS, and that this is
> OK because many deployments do not represent multi-user
> clients whose traffic will be multiplexed across one
> single connection.  As I hear the request, this is most
> interesting for NFS traffic inside a server room, with a
> very limited set of user identities in play, and/or with
> non-traditional clients.  We should make some effort to
> describe the interesting use cases to show that we're not
> eviscerating authentication norms for no reason.

The editor's note at the end of this section is meant to flag
this area as needing significantly more discussion. It's not
an area I have much expertise in, so I need some help teasing
out the issues and learning the current state of the TLS art.

I'm also happy to take contributed text.


>> The immediate question I have is whether members of WG feel this
>> topic and document are important enough to promote rpc-tls-01 to
>> Working Group document status. If yes, I can submit the next
>> revision as draft-ietf-nfsv4-rpc-tls-00.
> 
> Yes, this looks like a good start to me.
> 
> Rob T

Thanks for the review!


--
Chuck Lever