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

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Mon, 25 Mar 2019 09:53:51 +0100 (CET)

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" <[email-masked]>
> To: "Chuck Lever" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> 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 <[email-masked]> wrote:
> 
>>
>> > On Nov 19, 2018, at 5:33 PM, McDonald, Alex <[email-masked]> 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 <[email-masked]> On Behalf Of Chuck Lever
>> > Sent: Monday, November 19, 2018 15:56
>> > To: NFSv4 <[email-masked]>
>> > Subject: [nfsv4] Fwd: New Version Notification for
>> draft-cel-nfsv4-rpc-tls-01.txt
>> >
>> >
>> > Hi-
>> >
>> >> Begin forwarded message:
>> >>
>> >> From: [email-masked]
>> >> 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" <[email-masked]>, "Charles
>> >> Lever" <[email-masked]>, "Chuck Lever"
>> >> <[email-masked]>
>> >>
>> >>
>> >> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Mon, 25 Mar 2019 09:44:32 -0400

> On Mar 25, 2019, at 4:53 AM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> 
> 
> Hi Chuck,
> 
> 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

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Mon, 25 Mar 2019 21:44:26 +0100 (CET)

----- Original Message -----
> From: "Chuck Lever" <[email-masked]>
> To: "Tigran Mkrtchyan" <[email-masked]>
> Sent: Monday, March 25, 2019 2:44:32 PM

> 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.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 26 Mar 2019 09:56:10 -0400

> On Mar 25, 2019, at 4:44 PM, Mkrtchyan, Tigran <[email-masked]> wrote:
> 
> 
> 

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?

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Tue, 26 Mar 2019 16:05:16 +0100 (CET)

----- Original Message -----
> Sent: Tuesday, March 26, 2019 2:56:10 PM

> transport connection is established, and never later. Is that what you

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.

Tigran.

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 26 Mar 2019 12:19:35 -0400

> 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...

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Mar 2019 17:33:41 +0100

> have too either as a part of this document or a separate document.

Also note that STARTTLS is somewhat less secure than running TLS directly. See for example Section 6 of RFC3207:

   A man-in-the-middle attack can be launched by deleting the "250
   STARTTLS" response from the server.  This would cause the client not
   to try to start a TLS session.  Another man-in-the-middle attack is
   to allow the server to announce its STARTTLS capability, but to alter
   the client's request to start TLS and the server's response.
   ...

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Mar 2019 17:35:27 +0100

>    the client's request to start TLS and the server's response.

And RFC8314 recommends (for mail) that "implicit TLS" should be used instead of STARTTLS.

Lars

---

From: Chuck Lever <[email-masked]>
Date: Tue, 26 Mar 2019 13:52:07 -0400

> On Mar 26, 2019, at 12:35 PM, Lars Eggert <[email-masked]> wrote:
> 

Perhaps that is what we should require for RPC on TLS;
that is, "STARTTLS MUST NOT be used"?

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Tue, 26 Mar 2019 17:58:36 +0000

> Sent: Tuesday, March 26, 2019 1:52 PM
> To: Lars Eggert <[email-masked]>
> Cc: NFSv4 <[email-masked]>

It's a fine requirement, but there may need to be a justification for the MUST.

It's important to note that such a requirement means you'll need to allocate
a new port number for such connections. This would apply to any upper
layer using the new RPC flavor, which in turn might impact the portmapper.
Note, it may also have implications on the proposed negotiation. If TLS is
a "done deal", negotiating the auth flavor may be moot.

Tom.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Mar 2019 14:05:04 -0500

> mechanism for managing this situation.

As others have covered, this is a matter for the application that is trying
to use the opportunistic TLS.

> transport connection is established, and never later. Is that what you

Since STARTTLS for NFS doesn't exist other than this draft (right?), you
have a pretty clean slate to work from and should be able to set tight
bounds on usage, disallowing a lot of the potential complications.

So, requiring at most one STARTTLS, and for that to be the first RPC (or
othr traffic) after the transport connection is established, seems
simplest.  STARTTLS when TLS is already active can be rejected, and
STARTTLS after non-TLS RPCs have occurred as well.  That would be my
recommendation, at least (having not really read the draft,at least
recently).

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Tue, 26 Mar 2019 15:24:15 -0400

> On Mar 26, 2019, at 3:05 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Thanks, after this explanation and reading the wiki page that Olga sent,
I think I understand what text needs to be added.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 28 Mar 2019 15:42:37 -0400

> On Mar 26, 2019, at 1:58 PM, Tom Talpey <[email-masked]> wrote:
> 

We could create a new netid for this purpose.

Advertise an RPC program with this new netid, and no STARTTLS would
be needed. The client simply connects and begins TLS negotiation.

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Fri, 29 Mar 2019 00:35:31 +0000

> From: Chuck Lever <[email-masked]>
> Sent: Thursday, March 28, 2019 3:43 PM
> To: Tom Talpey <[email-masked]>
> Cc: Lars Eggert <[email-masked]>; NFSv4 <[email-masked]>
> >>>> Also note that STARTTLS is somewhat less secure than running TLS
> directly.
> >> See for example Section 6 of RFC3207:
> >>>>

But, the current draft proposes using a new AUTH_TLS exchange, which
if successful allows the client to perform a STARTTLS. If you define a netid
and/or port number, the client would simply start in TLS, prior to even
sending its first RPC.

Would that not simply make the whole draft unnecessary?

Tom.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 28 Mar 2019 22:20:27 -0400

> Would that not simply make the whole draft unnecessary?

Anything advertised by the portmapper is as vulnerable to man in the
middle attacks as the current proposal. If your attacker can intercept
connections to the NFS server, then they can do the exact same thing
to the portmapper. Furthermore, using the portmapper doesn't pass
Tigran's requirement for fast discovery because it may require the
setup of a second TCP connection (unless you are using UDP) and it
definitely requires an extra RPC call.

The proposal just to use a different well known port would work,
however it messes up pNFS for us because the MDS would have to
advertise both ports to the client if it wants to ensure that the
client can connect.

Cheers
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 28 Mar 2019 23:54:21 -0400

> advertise both ports to the client if it wants to ensure that the

BTW: The netid proposal does resolve the issue of quick NFSv4.x
migration/replication/referral connections and for pNFS. Assuming your
fs_locations or LAYOUTGET call to the main NFSv4 server is already TLS
protected, then there are no issues with man in the middle. One
downside is that you would presumably then have to define netids for
all protocols that you need to support RPC/TLS.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 29 Mar 2019 10:17:52 -0400

> On Mar 28, 2019, at 8:35 PM, Tom Talpey <[email-masked]> wrote:
> 

No. The current revision places a number of restrictions on how TLS
is used, and that is needed in any case. But, the draft could define
new netids and reserve a new port number for making portmapper requests
using TLS.

Anyway, this is a strawman. I wanted to bring it up to ensure we are
happy with using STARTTLS.

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Fri, 29 Mar 2019 15:47:14 +0000

> Sent: Friday, March 29, 2019 10:18 AM

Ok. I definitely feel that STARTTLS, or some form of dynamic TLS enablement,
is important here. For one thing, not all transports support TLS, for example RDMA.
By the same token, servers may not support TLS-only services on new ports, or
new portmappers, and allocating new ports for existing RPC services is just
as problematic.

I do agree that MITM protection is critical if STARTTLS is to be used. Perhaps
the RPC AUTH exchange could address this protection, by extending the
AUTH_TLS exchange. This may require messages to be sent both before and
after establishing TLS. The SMB3 protocol, for example, uses something it
calls VALIDATE_NEGOTIATE for a similar purpose.

I look forward to the next draft.

Tom.