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

[Chuck Lever <[e-mail]>]

> On Apr 16, 2020, at 4:30 PM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi, 
> 
> I have reviewed the text proposal and have this comment. 
> 
> On Tue, 2020-04-14 at 11:39 -0400, Chuck Lever wrote:
>>   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.
> 
> So what is this paragraph trying to say really. Is this a mix of OS/Socket level
> concerns with the transport protocol level.

NFS server implementations have traditionally required clients to use a
privileged source port when using weak authentication like AUTH_SYS.
When a client uses a flavor like krb5 that provides strong host
authentication, the privileged source port requirement is waived.

This bullet simply states that the server does not have to require a
privileged source port when using TLS, just like with krb5/i/p. So
a client using AUTH_SYS with TLS would be permitted to use an ephemeral
source port, which is a much less rare resource than a privileged source
port.

We could leave this statement for a subsequent NFS-specific document
but there are some non-NFS user space RPC implementations that have
the same requirement.

Or, I could move this bullet to the Security Considerations section.


> Becasue from my perspective, I don't
> see why it would matter if the NFS client use a single arbitrary source port for
> its TCP connection to the server, where it determines that it has reached the
> server with a requested SNI. After the TCP connection has been established it
> will have a specific 5-tuple. Then the client use RPC level authentication to
> prove to the server which user it is. Yes, that has certain weakness in that it
> doesn't identify the client host system, however for cases where one don't
> require that.  
> 
> 
> So related to my AD reveiw comment:
> 
>> 6. Section 5.1.1:
>>   After establishing a TLS session, an RPC server MUST reject with a
>>   reject_stat of AUTH_ERROR any subsequent RPC requests over a TLS-
>>   protected connection that are outside of a TLS session.
>> 
>> I assume this is actually bound to a host or a user identity? Because reading
>> the above sentence immediately made me ask how can the RPC server determine
>> that the RPC request is coming from an entity that already has an TLS session?
>> Can you please clarify this question?
> 
> For TCP I think the new text addresses this to simply stating the fact that once
> the TLS connection is established over the TCP connection it is impossible to
> use it in an non-secured way. 
> 
> However, for UDP I think an aspect of this question remains. 
> 
>>   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.
>> 
> 
> Is this on a per 5-tuple level? Can you make that explicit. If not can you
> please specify in which way the server will make the deterination that they
> should be in some other 5-tuple an the associated DTLS association?

Sure. I will try to make this more specific. I'll propose something in a
day or two.


> My understanding of DTSL is that over UDP for incoming packets it will look at
> the 5-tuple, The destination port for which DTLS server/client that receives the
> packet. And the source port + address for determining security context. After an
> DTLS association has been created on a 5-tuple incoming UDP datagram payloads
> needs to contain either DTLSplaintext or DTLS cipher text (see Section 4.1 of 
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/). If it doesn't match or
> succesfully deprotects then the paylaod is rejected. Thus it will not be on the
> same 5-tuple possible to receive any unprotected datagrams.
> 
> For issue 7, this fully addresses that one.
> 
> For issue 8. I think it is clear that you need to do the RPC call to find out
> support and that is scoped to the transport protocol and 5-tuple the request was
> done to. That is all fine with me. So issue resolved.

Thanks for your review. I think the clarifications you requested make this a
stronger document.


--
Chuck Lever