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

From: Chuck Lever <[email-masked]>
Date: Fri, 4 Jan 2019 10:52:48 -0500

> On Nov 19, 2018, at 5:33 PM, McDonald, Alex <[email-masked]> wrote:
> 
> 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?

I've been studying RFC 8471 to understand what would be needed to support
TLS token binding with RPC. It appears there are two components:

 - The TLS handshake is extended to indicate support for token binding
   and negotiate the supported version

 - The upper layer protocol (RPC, in our case) is required to send a Token
   Binding message as the first message

We would need to provide a mechanism for encapsulating this message in
the RPC protocol similar to what RFC 8473 does for HTTPS. Potentially,
RPCSEC GSS could provide a mechanism for transporting this message.

It appears to me that there is a natural boundary between what we have
already described in draft-cel-nfsv4-rpc-tls and support for TLS Token
Binding, such that Token Binding could be handled by a separate document.
That would allow the quick completion of rpc-tls to enable encryption by
default using self-signed certificates, with support for Token Binding
to appear later.

Thoughts, comments... Am I on the wrong track?

> -----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-
> 
>> 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: David Noveck <[email-masked]>
Date: Fri, 4 Jan 2019 11:25:18 -0500

> RPCSEC GSS could provide a mechanism for transporting this message.

As I understand things, one of the potential goals here is to satisfactorily
authenticate the client so that AUTH_SYS can reasonably used.  For that use
case, I'm not sure how depending on RPCSEC GSS would fit in.

> Binding, such that Token Binding could be handled by a separate document.

That makes sense.

> That would allow the quick completion

Since this is the IETF, let's just say "quicker completion".

> of rpc-tls to enable encryption by

It depens on how much later.  I don't see how it would be necessary to get
through the RFC process, including that rigorous search for split
infinitives, cycles
of discussion of RFC2119 terms before starting the follow-up work on token
binding.   Once rpc-tls is accepted as a working group document, the group
would
be in a position to make plans for the follow-on  work that seems to be
warranted.

> Thoughts, comments...

If work on client autehentication is to be punted, then the document will
need to reflect that.
In particular, if you, as a server, are prepared to accept an
unauthenticatted client's user
identifications, then your security is pretty much non-existent, despite
the fact that
enryption prevents eavesdropping.  In that case, it probably best to say
nothing about use
of AUTH_SYS.

> Am I on the wrong track?

No.

On Fri, Jan 4, 2019 at 10:53 AM Chuck Lever <[email-masked]> wrote:

> > 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?
>
> >> 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://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls
> >> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-01
> >>
> >> Abstract:
> > 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
>