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

[Chuck Lever <[e-mail]>]

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

UDP will use DTLS.

My hesitance is that STARTTLS is part of the TLS protocol, and we're
not specifying that here, we're only using it. Surely TLS has a proper
mechanism for managing this situation.

I would like to see a recent RFC that covers your case. RFC 6614 appears
to require TLS negotiation to occur immediately after the underlying
transport connection is established, and never later. Is that what you
want?


> 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

--
Chuck Lever