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

From: Chuck Lever <[email-masked]>
Date: Mon, 11 Feb 2019 16:46:11 -0500

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-02.txt
> Date: February 11, 2019 at 4:32:11 PM 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-02.txt
> has been successfully submitted by Charles Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpc-tls
> Revision:	02
> Title:		Remote Procedure Call Encryption By Default
> Document date:	2019-02-11
> Group:		Individual Submission
> Pages:		11
> URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpc-tls-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls/
> Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-rpc-tls-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-02
> 
> Abstract:
>   This document describes a mechanism that enables encryption of in-
>   transit Remote Procedure Call (RPC) transactions with minimal
>   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

It's been a while since I updated draft-cel-nfsv4-rpc-tls, but we're
still working on it. This new revision has the following changes:

- Decided to continue the document as a personal draft for now, rather
than requesting promotion to Working Group document. There remain
some substantial protocol design and text organization decisions to
make.

- Refocused the discussion of TLS authentication in Section 4.3. Clients
are not required to present a certificate. TLS authentication mechanisms
are supplemental to RPC authentication for the moment.

- Integrated some of Dave Noveck's review comments from November 26, 2018.
A discussion of the remaining weaknesses of AUTH_SYS on TLS has been
introduced in the Security Considerations section. After some thought, I
find that I do not agree with Dave's opinion that the Title/Abstract does
not match the mission and text of the document.

- Added text requesting a TLS Application Layer Protocol Negotiation ID
assignment for SunRPC. Does this enable the use of TLS without the RPC
extension described in Section 4.1 ?

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Tue, 12 Feb 2019 21:14:47 +0100 (CET)

Hi Chuck,

good to know that idea is still alive. In the mean time we have updated
out RPC implementation to support RPC over TLS and do have working prototype
of AUTH_TLS. We still need some tweaks to API to make it easy to use as well.
Do you have a client/server code to check interoperability?

Thanks,
   Tigran.

----- Original Message -----
> From: "Chuck Lever" <[email-masked]>
> To: "NFSv4" <[email-masked]>
> Sent: Monday, February 11, 2019 10:46:11 PM
> Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-02.txt

>> To: "Trond Myklebust" <[email-masked]>, "Charles Lever"
>> <[email-masked]>, "Chuck Lever" <[email-masked]>
>> 
>> 
>> URL:
>> https://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpc-tls-02.txt
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Wed, 13 Feb 2019 09:40:36 -0500

Hi Tigran!

> On Feb 12, 2019, at 3:14 PM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> Hi Chuck,
> 

Trond is working on a prototype implementation (likely in the Linux
kernel). We hope to have something for the next NFS bake-a-thon --
Ann Arbor in May.

We've also discussed an implementation in libtirpc, but there are
no solid plans there.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Mon, 25 Feb 2019 12:25:51 -0500

Hi Tigran-

Was it you that suggested that the clients should simply
try STARTTLS when connecting, instead of using AUTH_TLS
negotiation? I'm curious if you tried this idea.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Mon, 25 Feb 2019 21:37:12 +0100 (CET)

----- Original Message -----
> To: "Tigran Mkrtchyan" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> Sent: Monday, February 25, 2019 6:25:51 PM
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-02.txt

Hi Chuck,

One option which will make life much easier is when server just enforces TLS rightaway
without any start TLS command, like a regular TLS enabled web server (well, for me it
just a line to enable SSL on the socket). That option now available with our server.
However, I didn't test in the mixed setup with stunnel on the client side. In addition,
I have implemented AUTH_TLS option as well, though, I don't like the implementation.
This is due to our server design, where RPC layer, where AUTH_TLS is handled, is decoupled
from the  network transport. As a result I have to add a backdoor to allow RPC layer
to re-configure connections.

I am planning to come to Bakeathon in Ann Arbor where we can run some tests together.

Regards,
   Tigran.

P.S.: I can build a simple NFS server that will offer both options, if you interested.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 25 Feb 2019 15:40:22 -0500

> On Feb 25, 2019, at 3:37 PM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> 
> 

The interesting question is whether we need the AUTH_TLS mechanism for
compatibility with RPC implementations that do not support TLS at all.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Mon, 25 Feb 2019 22:42:46 +0100 (CET)

----- Original Message -----
> Sent: Monday, February 25, 2019 9:40:22 PM

> compatibility with RPC implementations that do not support TLS at all.

I see AUTH_TLS (STARTTLS) only as an option to share the same tcp port for TLS
and non TLS servers. On a one hand we have more complex RPC code, on an other
hand smooth client migration (no extra port number and auto ).

Tigran.