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

[Chuck Lever <[e-mail]>]

> On Nov 19, 2018, at 5:33 PM, McDonald, Alex <[e-mail]> 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 <[e-mail]> On Behalf Of Chuck Lever
> Sent: Monday, November 19, 2018 15:56
> To: NFSv4 <[e-mail]>
> Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> 
> 
> Hi-
> 
>> Begin forwarded message:
>> 
>> From: [e-mail]
>> 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" <[e-mail]>, "Charles 
>> Lever" <[e-mail]>, "Chuck Lever" 
>> <[e-mail]>
>> 
>> 
>> 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