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.

I don't have a problem with that at all. IMO this should be clearly
mentioned somewhere in rpc-tls (which I can add if you agree).


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

Exactly why I started this sub-thread: Correction could be necessary.
So, we're right on the same page.


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

And/or:

rpc-tls should mandate a particular response if the client sends an
AUTH_TLS probe with an RPC program that the server does not recognize
on that port. Obvious choice is PROG_UNAVAIL -- and in this case, this
carries the additional meaning that the STARTTLS probe has failed.

I hope that is enough to imply that the client has a limited choice
of RPC program numbers to use in its AUTH_TLS probes.

Does rpc-tls need to explicitly state that the backchannel MUST NOT send
an AUTH_TLS probe on a connection with an established TLS session? It
is already implied by "no clear-text RPCs are allowed after a TLS
session is established". But perhaps it would be helpful implementation
guidance.


> However,
> I'd first like to understand why it is desirable to treat TLS/DTLS
> differently from ordinary TCP/UDP in that situation.

I agree that we should avoid unnecessary divergence in behavior. Let's
go back to Magnus' original comment:

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


The underlying question I read here is "after an AUTH_TLS probe, how
long can a client assume the RPC server supports RPC-on-TLS, and for
which RPC programs?"

Magnus' comment was made regarding UDP/DTLS, so my initial response was
that rpc-tls needs to stipulate how TLS sessions are used on transports
that are unlikely to use a connection. Thus I said earlier in this thread:

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

Then I started thinking about TCP.

Since we have implementations that use the same connection to transport
multiple RPC programs, we have to make a different statement. What should
that statement be?

I wondered again about whether it makes sense to permit or encourage
multiple TLS sessions on the same connection.

If you wanted to, how would you establish a second TLS session? Because
of the "no clear-text RPCs after a TLS session has been established"
stipulation, the client would have to perform a bunch of AUTH_TLS probes
_before_ sending any ClientHello messages.

(And in any event we probably want rpc-tls to discuss what should happen
if there is traffic on the connection between the AUTH_TLS probe and
the ClientHello message).

But it's likely that multiple TLS sessions makes sense only when there
are multiple certificates on the client side. So this is very likely
out of scope for rpc-tls. Then do we explicitly forbid the use of
multiple TLS sessions per connection for this iteration of RPC-on-TLS?


--
Chuck Lever