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

[Olga Kornievskaia <[e-mail]>]

On Tue, Mar 26, 2019 at 11:05 AM Mkrtchyan, Tigran
<[e-mail]> wrote:
>
>
>
> ----- Original Message -----
> > From: "Chuck Lever" <[e-mail]>
> > To: "Tigran Mkrtchyan" <[e-mail]>
> > Cc: "NFSv4" <[e-mail]>
> > Sent: Tuesday, March 26, 2019 2:56:10 PM
> > Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
>
> >> 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?
>
> I have my doubts, that STARTTLS is a part of TLS protocol. Anyway, what I want to
> see is a clear statement about what server is suppoed to do if it sees multiple
> STARTTLS requests on the same connection. Our current implementation will just
> ignore the second request if TLS is already enabled.
>

To add to Tigran's comments...

STARTTLS is not a part of the TLS RFC. Other protocols that use TLS
have RFCs for STARTTLS for that protocol which I think NFS needs to
have too either as a part of this document or a separate document.

Taken from a wiki (https://en.wikipedia.org/wiki/Opportunistic_TLS)
The STARTTLS command for IMAP and POP3 is defined in RFC 2595, for
SMTP in RFC 3207, for XMPP in RFC 6120 and for NNTP in RFC 4642...

> Tigran.
>
>
> >
> >
> >> 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
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4