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

> On Mar 25, 2019, at 4:53 AM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
> 
> 
> 
> 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?

I don't have a ready answer, but seems to me your TLS library
might have an opinion. Can a web browser be made to generate
a second STARTTLS to see what the behavior is like?

Is there any guidance in RFC 8446 or its antecedants?

> 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

--
Chuck Lever