Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[Chuck Lever <[e-mail]>]

> On Apr 9, 2020, at 6:51 PM, Trond Myklebust <[e-mail]> wrote:
> 
> On Thu, 2020-04-09 at 18:01 -0400, Chuck Lever wrote:
>>> On Apr 9, 2020, at 5:42 PM, Trond Myklebust <[e-mail]>
>>> wrote:
>>> 
>>> On Thu, 2020-04-09 at 17:02 -0400, Chuck Lever wrote:
>>>>> On Apr 9, 2020, at 4:53 PM, David Noveck <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>>> Therefore with RPC-on-TLS we do not allow multiple RPC
>>>>>> programs
>>>>>> to share
>>>>>> a TLS session. And we do not allow multiple RPC-on-TLS
>>>>>> sessions
>>>>>> per TCP
>>>>>> connection.
>>>>> 
>>>>> That was my impression reading the document.  However, as you
>>>>> point
>>>>> out, the
>>>>> document never clearly atated that. 
>>>>> 
>>>>>> For DTLS, the STARTTLS probe has to be done for each RPC
>>>>>> program
>>>>>> on each
>>>>>> server. Only that one RPC program can use the established
>>>>>> DTLS
>>>>>> session.
>>>>> 
>>>>> OK with me.
>>>>> 
>>>>>> This means RPC-on-TLS robs us of some TCP connection sharing
>>>>>> opportunities.
>>>>> 
>>>>> I'm unaware of any actual use of these opportunities, in the
>>>>> absence of RPC-TLS .  If there
>>>>> is little use of these, than the deprivation of sharing
>>>>> opportunities is purely formal.
>>>> 
>>>> The particular use case is that both the Linux and Solaris NFSv3
>>>> implementations use the same connection for NFS and NFSACL
>>>> traffic,
>>>> which are two distinct RPC programs.
>>>> 
>>>> It's an ongoing concern for NFS clients that use privileged
>>>> source
>>>> ports to conserve the number of connections they make to a
>>>> particular server.
>>>> 
>>>> Not a problem for NFSv4, or NFS with Kerberos which can use an
>>>> ephemeral source port without any consequences. We could probably
>>>> even stipulate in an NFS-on-TLS or NFS security document that an
>>>> NFS server should not require a privileged source port, but
>>>> that's
>>>> a rat hole.
>>> 
>>> That's only OK if you can trust the client itself to enforce user
>>> identities. The main reason for requiring the privileged port is to
>>> ensure that the server is either talking to the kernel on the
>>> client,
>>> or that it is talking to a privileged process. You don't normally
>>> want
>>> to trust an unprivileged RPC client not to lie to you about
>>> AUTH_SYS
>>> credentials...
>>> I can't see that TLS changes that trust model unless the client
>>> also
>>> authenticates to the server to prove it is running a trusted RPC
>>> program.
>> 
>> So, does that mean in cases where TLS host authentication is used,
>> the server MAY ignore the client's source port?
> 
> I'm saying that if I were the sysadmin, then the case where the client
> identifies itself strongly is the only one where I would relax the
> requirement on the source port.
> 
>>>>>> Is there consensus on this, or should these design points be
>>>>>> revisited? 
>>>>> 
>>>>> I'd prefer not but we need to give working group members who
>>>>> feel
>>>>> differently, the
>>>>> opportunity to raise their concerns.
>>>> 
>>>> +1
>>> 
>>> That proposal essentially bans the backchannel on NFSv4.x (which
>>> uses a
>>> program number assigned by the client), so it is not acceptable.
>> 
>> As Dave said, what I described is what is already implied by or
>> stated
>> in rpc-tls. It's possible that either rpc-tls or my understanding is
>> not correct.
>> 
> 
> I'm saying if that is how the protocol currently reads, then we've made
> a mistake, and we need to correct it.
> 
> I don't see any reason why we need to add RPC layer restrictions when
> we're effectively just adding a new underlying transport protocol. RPC
> already has its own mechanisms for rejecting unsupported programs and
> program versions.
> 
> What we might want to stipulate is that _if_ the server rejects your
> program on the established channel, then that does not automatically
> imply that it would also reject it on a different connection. However,
> I'd first like to understand why it is desirable to treat TLS/DTLS
> differently from ordinary TCP/UDP in that situation.
> 
>> I am open to alternative proposals or corrections to my
>> understanding.
>> But do note that the situation has to be clarified as part of our
>> response to the AD review.
>> 
>> 
>>> Furthermore, as already pointed out, there are use cases for other
>>> side-band protocols that share the same connection to the server as
>>> the
>>> main protocol.
>>> 
>>>>> if there is no objection, why don't you include
>>>>> explicit langusge about your non-sharing model in the next
>>>>> revision
>>>>> and the
>>>>> working group discssion of the chamges in that document will
>>>>> serve
>>>>> as the basis
>>>>> for determining whether we have a continued onsensus on those
>>>>> point.    
>>>> 
>>>> Excellent suggestion, I will do that.
>>> 
>>> I object.
>> 
>> To what? Do you mean that you would prefer we work this out here on
>> the
>> mailing list rather than through the draft revision process? That's
>> fine with me too.
> 
> I'd prefer that we work it out here. As I said, I consider this to be a
> potential protocol error, if indeed the current text can be interpreted
> in the suggested manner.

To address AD review comments 6, 7, and 8, here's what I propose for
Section 4.1:


4.1.  Discovering Server-side TLS Support

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support TLS.  Depending on
   policy, the use of TLS is automatically disabled in these cases.

   To achieve this, we introduce a new RPC authentication flavor called
   AUTH_TLS.  This new flavor signals that the client wants to initiate
   TLS negotiation if the server supports it.  Except for the
   modifications described in this section, the RPC protocol is unaware
   of security encapsulation at the transport layer.

   When an RPC client is ready to begin a TLS session, it sends a NULL
   RPC procedure with an auth_flavor of AUTH_TLS.  The value of AUTH_TLS
   is defined in Section 8.1.  The NULL request is made to the same port
   as if TLS were not in use.

   The length of the opaque data constituting the credential sent in the
   RPC Call message MUST be zero.  The verifier accompanying the
   credential MUST be an AUTH_NONE verifier of length zero.

   The flavor value of the verifier in the RPC Reply message received
   from the server MUST be AUTH_NONE.  The length of the verifier's body
   field is eight.  The bytes of the verifier's body field encode the
   ASCII characters "STARTTLS" as a fixed-length opaque.

   If the RPC server replies with a reply_stat of MSG_ACCEPTED and an
   AUTH_NONE verifier containing the "STARTTLS" token, the RPC client
   follows with a "ClientHello" message.  The client MAY proceed with
   TLS session establishment even if the Reply's accept_stat is not
   SUCCESS (for example, if the accept_stat is PROG_UNAVAIL).  Once the
   TLS handshake is complete, the RPC client and server have established
   a secure channel for communicating.

   If the Reply's reply_stat is MSG_ACCEPTED but the verifier does not
   contain the "STARTTLS" token, or if the Reply's reply_stat is
   MSG_DENIED, the RPC client MUST NOT send a "ClientHello" message.
   RPC operation can continue, but in the clear.

   If, after a successful RPC AUTH_TLS probe, the subsequent TLS
   handshake should fail for any reason, the RPC client reports this
   failure to the upper-layer application the same way it reports an
   AUTH_ERROR rejection from the RPC server.

   If an RPC client uses the AUTH_TLS authentication flavor on any
   procedure other than the NULL procedure, or an RPC client sends an
   RPC AUTH_TLS probe within an existing TLS session, the RPC server
   MUST reject that RPC Call by setting the reply_stat field to
   MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
   field to AUTH_BADCRED.


And for Section 5.1:


5.1.  Base Transport Considerations

5.1.1.  RPC-on-TLS Operation on TCP

   The use of TLS [RFC8446] protects RPC on TCP connections.  Typically,
   once an RPC client completes the TCP handshake, it uses the mechanism
   described in Section 4.1 to discover RPC-on-TLS support for that
   connection.  If spurious traffic appears on a TCP connection between
   the initial clear-text AUTH_TLS probe and the TLS session handshake,
   receivers MUST discard that data without response and then SHOULD
   drop the connection.

   The protocol convention specified in the current document assumes
   there can be no more than one concurrent TLS session per TCP
   connection.  This is true of current generations of TLS, but might be
   different in a future version of TLS.

   Once a TLS session is established on a TCP connection, no further
   clear-text communication can occur on that connection until the
   session is terminated.  When operation is complete, an RPC peer
   terminates a TLS session by sending a TLS Closure Alert and then
   closes the TCP connection.

   Furthermore:

   o  The use of TLS does not alter RPC record framing used on TCP
      transports.

   o  If an RPC server responds with PROG_UNAVAIL to an RPC Call within
      an established TLS session, that does not imply that RPC server
      will subsequently reject the same RPC program on a different TCP
      connection.

   o  If a client uses an ephemeral source port for a TCP connection and
      does not present authentication material to initiate TLS host
      authentication, the server MUST abort the TLS handshake with a
      handshake_failure alert.

   Backchannel operation occurs only on connected transports such as
   TCP.  To protect backchannel operations, an RPC server uses the
   existing TLS session on that connection to send backchannel
   operations.  The server does not attempt to establish a TLS session
   on a TCP connection for backchannel operation.

5.1.2.  RPC-on-TLS Operation on UDP

   RPC over UDP is protected using DTLS [I-D.ietf-tls-dtls13].  As soon
   as a client initializes a UDP socket for use with an unfamiliar
   server, it uses the mechanism described in Section 4.1 to discover
   DTLS support for an RPC program, and then negotiate a DTLS session
   for that program.  Connected operation is RECOMMENDED.

   Once an RPC client establishes a DTLS session for an RPC program, the
   RPC server MUST reject UDP-transported Calls in that RPC prgram from
   that RPC client that are not protected by the established DTLS
   session.

   Sending a TLS Closure Alert terminates a DTLS session.  Subsequent
   RPC messages exchanged between the RPC client and server are no
   longer protected until a new DTLS session is established.

   Each RPC message MUST fit in a single DTLS record.  DTLS
   encapsulation has overhead, which reduces the effective Path MTU
   (PMTU) and thus the maximum RPC payload size.  Using DTLS does not
   introduce reliable or in-order semantics to RPC on UDP.  The use of
   DTLS record replay protection is REQUIRED.

5.1.3.  RPC-on-TLS Operation on Other Transports

   Transports that provide intrinsic TLS-level security (e.g., QUIC)
   need to be addressed separately from the current document.  In such
   cases, the use of TLS is not opportunistic as it can be for TCP or
   UDP.

   RPC-over-RDMA can make use of transport layer security below the RDMA
   transport layer [RFC8166].  The exact mechanism is not within the
   scope of this document.  Because there might not be other provisions
   to exchange client and server certificates, authentication material
   exchange needs to be provided by facilities within a future RPC-over-
   RDMA transport protocol.



>>>>> On Thu, Apr 9, 2020 at 3:28 PM Chuck Lever <
>>>>> [e-mail]>
>>>>> wrote:
>>>>> 
>>>>>> On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <
>>>>>> [e-mail]> wrote:
>>>>>> 
>>>>>> 8. Section 5.1.2:
>>>>>> 
>>>>>>  As soon as a client
>>>>>>  initializes a socket for use with an unfamiliar server, it
>>>>>> uses the
>>>>>>  mechanism described in Section 4.1 to discover DTLS support
>>>>>> and then
>>>>>>  negotiate a DTLS session.
>>>>>> 
>>>>>> So first of all is the usage of TLS for TCP completely
>>>>>> separate
>>>>>> from using DTLS over UDP? So having determined TLS support
>>>>>> for
>>>>>> TCP does not indicate the same for UDP? And is it in any
>>>>>> cases
>>>>>> possible to skip the initial RPC null request with AUTH_TLS
>>>>>> authentication and go directly to negotiate TLS after support
>>>>>> has
>>>>>> been determined with a server? 
>>>>> 
>>>>> There seems to be a high-order bit here that rpc-tls does not
>>>>> currently
>>>>> address. Leaving it unaddressed could introduce significant
>>>>> interoperability issues.
>>>>> 
>>>>> Our new STARTTLS RPC NULL probe carries an RPC program. Does a
>>>>> successful
>>>>> probe mean that the RPC server supports TLS for every RPC
>>>>> program
>>>>> on that
>>>>> that host? on that port? Or just for the program used in the
>>>>> probe?
>>>>> I think
>>>>> it means TLS can be used only with the RPC program used in that
>>>>> probe,
>>>>> and only for the lifetime of that connection. (ie each
>>>>> connection
>>>>> has to
>>>>> do the probe).
>>>>> 
>>>>> Since the STARTTLS RPC NULL probe is always done in clear-text,
>>>>> that means
>>>>> a second probe cannot be done once a TLS session has been
>>>>> established on
>>>>> a connection. (A separate connection must be established to
>>>>> initiate a
>>>>> second TLS session).
>>>>> 
>>>>> Therefore with RPC-on-TLS we do not allow multiple RPC programs
>>>>> to
>>>>> share
>>>>> a TLS session. And we do not allow multiple RPC-on-TLS sessions
>>>>> per
>>>>> TCP
>>>>> connection.
>>>>> 
>>>>> For DTLS, the STARTTLS probe has to be done for each RPC
>>>>> program on
>>>>> each
>>>>> server. Only that one RPC program can use the established DTLS
>>>>> session.
>>>>> 
>>>>> 
>>>>> This means RPC-on-TLS robs us of some TCP connection sharing
>>>>> opportunities.
>>>>> Is there consensus on this, or should these design points be
>>>>> revisited?

--
Chuck Lever