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

["Mkrtchyan, Tigran" <[e-mail]>]

----- Original Message -----
> From: "Chuck Lever" <[e-mail]>
> To: "Tigran Mkrtchyan" <[e-mail]>
> Cc: "NFSv4" <[e-mail]>
> Sent: Monday, March 25, 2019 2:44:32 PM
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

>> On Mar 25, 2019, at 4:53 AM, Mkrtchyan, Tigran <[e-mail]> 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?

Looks like LDAP have that case clearly specified rfc2830:

2.3:

...

   If the Start TLS extended request was not successful, the resultCode
   will be one of:

   operationsError  (operations sequencing incorrect; e.g. TLS already
                    established)

3.1:

...

   The client MAY send the Start TLS extended request at any time after
   establishing an LDAP association, except that in the following cases
   the client MUST NOT send a Start TLS extended request:

     - if TLS is currently established on the connection, or

You may adopt a similar wording to rpc-over-tls. However, what about UDP and
retransmits?

Tigran.
> 
> 
>> It would be nice if spec will
>> explicitly define this situation.
>> 
>> Thanks,
>>   Tigran.
>> 
>> ----- Original Message -----
>>> From: "Dave Noveck" <[e-mail]>
>>> To: "Chuck Lever" <[e-mail]>
>>> Cc: "NFSv4" <[e-mail]>
>>> 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 <[e-mail]> wrote:
>>> 
>>>> 
>>>>> 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
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> nfsv4 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever