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

Hi Chuck,

By working on our implementation we got a following questions:

what should server do when a client requests startTLS twice? Fail
with an auth error or just ignore? It would be nice if spec will
explicitly define this situation.

Thanks,
   Tigran. 

----- Original Message -----
> From: "Dave Noveck" <davenoveck@gmail.com>
> To: "Chuck Lever" <chuck.lever@oracle.com>
> Cc: "NFSv4" <nfsv4@ietf.org>
> Sent: Friday, January 4, 2019 5:25:18 PM
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

>> 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.
> 
> 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.
> 
>> 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 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
>> default using self-signed certificates, with support for Token Binding
>> to appear later.
> 
> 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 <chuck.lever@oracle.com> wrote:
> 
>>
>> > On Nov 19, 2018, at 5:33 PM, McDonald, Alex <alexmc@netapp.com> 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 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever
>> > Sent: Monday, November 19, 2018 15:56
>> > To: NFSv4 <nfsv4@ietf.org>
>> > Subject: [nfsv4] Fwd: New Version Notification for
>> draft-cel-nfsv4-rpc-tls-01.txt
>> >
>> >
>> > Hi-
>> >
>> >> Begin forwarded message:
>> >>
>> >> From: internet-drafts@ietf.org
>> >> 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" <trond.myklebust@hammerspace.com>, "Charles
>> >> Lever" <chuck.lever@oracle.com>, "Chuck Lever"
>> >> <chuck.lever@oracle.com>
>> >>
>> >>
>> >> 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
>>
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4