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

[Chuck Lever <[e-mail]>]

Hi Magnus-

Regarding closure on the remaining AD comments:


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

I've concluded that because...

• It is widely recognized these days that the source port is no realistic
indication of any degree of authority on the client,
• The new requirement was proposed well after the end of WGLC for rpc-tls,
• The use of a privileged port is discussed in RFC 5531 as implementation
guidance, not as a normative requirement,
• There seems to be an ongoing lack of consensus about what exactly should be
said,

... I will drop this new text entirely.

Dave Noveck pointed out to me that Appendix A of rpc-tls already quotes the
final paragraph of RFC 5531 Appendix A, which suggested the use of the source
port.

IMHO Appendix A of rpc-tls really ought to make some kind of statement about
how weak it is to use the client's source port, as the purpose of the source
port test is to mitigate the weaknesses of AUTH_SYS that are discussed in that
section. However, given how late it is, I leave that discussion to subsequent
documents. The source port test can remain an implementation quality issue for
the time being.


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

I've tried to resolve this issue in the following ways:

- I've removed the problematic rejection requirement.
- I've introduced discussion of the use of a CID or 5-tuple to identify the
participating endpoints.

Here's the new text:

5.1.2.  RPC-on-TLS Operation on UDP

   RPC over UDP is protected using the Datagram Transport Layer Security
   (DTLS) protocol [I-D.ietf-tls-dtls13].

   Using DTLS does not introduce reliable or in-order semantics to RPC
   on UDP.  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.  The use of DTLS record
   replay protection is REQUIRED when transporting RPC traffic.

   As soon as a client initializes a UDP socket for use with an RPC
   server, it uses the mechanism described in Section 4.1 to discover
   DTLS support for an RPC program on a particular port.  It then
   negotiates a DTLS session.

   When using connectionless operation, each DTLS session endpoint is
   identified by its 5-tuple -- the source and destination IP address
   and port numbers, along with the UDP transport protocol number (17).
   When using connected operation, the DTLS session endpoints are
   identified by connection ID (CID), as described in
   [I-D.ietf-tls-dtls-connection-id].  Connected operation is strongly
   RECOMMENDED.

   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.


If this text is still inadequate, I can reach out to the authors of
I-D.ietf-tls-dtls-connection-id for further guidance.


--
Chuck Lever