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

From: Chuck Lever <[email-masked]>
Date: Mon, 19 Nov 2018 10:55:41 -0500

Hi-

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> Date: November 19, 2018 at 10:52:07 AM EST
> To: "Trond Myklebust" <[email-masked]>, "Charles Lever" <[email-masked]>, "Chuck Lever" <[email-masked]>
> 
> 
> A new version of I-D, draft-cel-nfsv4-rpc-tls-01.txt
> has been successfully submitted by Charles Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpc-tls
> Revision:	01
> Title:		Remote Procedure Call Encryption By Default
> Document date:	2018-11-19
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpc-tls-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls/
> Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-01
> 
> Abstract:
>   This document describes a mechanism that enables encryption of in-
>   transit Remote Procedure Call (RPC) transactions with little
>   administrative overhead and full interoperation with RPC
>   implementations that do not support this mechanism.  This document
>   updates RFC 5531.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

Minor changes in revision 01:
- Correct a legal issue reported by idnits
- Clarify terminology throughout document
- Add editor's note in Section 4.3 "Authentication"
- Wordsmithing throughout

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.

--
Chuck Lever

---

From: Rob Thurlow <[email-masked]>
Date: Mon, 19 Nov 2018 14:05:18 -0700

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?

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

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

> revision as draft-ietf-nfsv4-rpc-tls-00.

Yes, this looks like a good start to me.

Rob T

---

From: Chuck Lever <[email-masked]>
Date: Mon, 19 Nov 2018 16:21:55 -0500

Hi Rob-

> On Nov 19, 2018, at 4:05 PM, Rob Thurlow <[email-masked]> wrote:
> 

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.

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

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

> Yes, this looks like a good start to me.

Thanks for the review!

--
Chuck Lever

---

From: "McDonald, Alex" <[email-masked]>
Date: Mon, 19 Nov 2018 22:33:09 +0000

Hi Chuck

Apologies for top posting, blame MS

I was interested in the comment "We believe the combination of host authentication via TLS and user authentication via RPC provides optimal security, efficiency, and flexibility,". There's been a huge amount of negative press for TLS client auth, but there's been a push for TLS token binding as a basis for better client/server authentication. Does the proposal need to consider work in this area?

-----Original Message-----
From: nfsv4 <[email-masked]> On Behalf Of Chuck Lever
Sent: Monday, November 19, 2018 15:56
To: NFSv4 <[email-masked]>
Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

Hi-

> To: "Trond Myklebust" <[email-masked]>, "Charles 
> Lever" <[email-masked]>, "Chuck Lever" 
> <[email-masked]>
>
>
> A new version of I-D, draft-cel-nfsv4-rpc-tls-01.txt has been 
> successfully submitted by Charles Lever and posted to the IETF 
> repository.
>
> 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.
>
> The IETF Secretariat

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.

--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Mon, 19 Nov 2018 17:45:42 -0500

> On Nov 19, 2018, at 5:33 PM, McDonald, Alex <[email-masked]> wrote:
> 
> Hi Chuck
> 

In revision 01 I added an editors note in Section 4.3. My intention
was to call out issues just like this. IMO we need to think carefully
about this area and select what is the current best practice for
host authentication via TLS.

On the other hand, there is some desire to leverage existing deployed
PKI to manage host authentication. We'll have to strike a balance.

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Mon, 19 Nov 2018 21:53:55 -0500

> revision as draft-ietf-nfsv4-rpc-tls-00.

I think it's likely that the WG will be interested, but there's
a process for adding new work items that the chairs and ADs need
to go through. I'd suggest you simply take comments and develop
your draft in the usual way, and let the process take its course.

---

From: David Noveck <[email-masked]>
Date: Mon, 19 Nov 2018 22:06:01 -0500

> but there's
> to go through

One way to prompt that process would be to request that the draft be
made into a working group item.

> develop your draft in the usual way,

The way we have been developing drafts has been to request, at some point
in the process, that the i
draft be made into a working group item.   When there are  steps that are
necessary for the chairs and
ADs need to take to allow that to happen, the working group has generally
been unaware of them.

---

From: David Noveck <[email-masked]>
Date: Tue, 20 Nov 2018 06:40:40 -0500

I think you have made a good start on dealing with this important issue.  I
will send out a review of this draft after Thanksgiving.

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

I certainly think it is.

On Mon, Nov 19, 2018 at 10:55 AM Chuck Lever <[email-masked]> wrote:

> Lever" <[email-masked]>, "Chuck Lever" <[email-masked]>
> >
> >
> > Status:
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls/
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-01
> >
> > Abstract:
> submission

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Tue, 20 Nov 2018 21:27:14 +0100 (CET)

Hi Chuck et al.,

Thanks for pushing this forward!

One of the option that I would consider is an implicit TLS support on a
different port number without RPC NULL call handshake. Such
functionality will allow to simplify server implementation, where security
information have to be pushed down to server's internals to validate
desired security flavor, a-la sec=tls. In your proposal, after STARTTLS
client changes auth flavor to AUTH_SYS and sych validation will required
more internal changes to existing implementations. In addition, with the help
of stunnel, as was suggested in the this activity triggering article, old
clients will be able to talk `implicit TLS` servers (and wise versa).

Regards,
   Tigran.

----- Original Message -----
> From: "Chuck Lever" <[email-masked]>
> To: "NFSv4" <[email-masked]>
> Sent: Monday, November 19, 2018 4:55:41 PM

>> To: "Trond Myklebust" <[email-masked]>, "Charles Lever"
>> <[email-masked]>, "Chuck Lever" <[email-masked]>
>> 
>>