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

[Chuck Lever <[e-mail]>]

> On Apr 21, 2020, at 3:46 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi,
> 
> See inline. 
> 
> On Sun, 2020-04-19 at 11:40 -0400, Chuck Lever wrote:
>> 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.
> 
> Okay, I think that is fine. 
> 
>> 
>> 
>>> 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.
>> 
> 
> I think this is clear. I don't think I can provide better guidance. I think we
> will get feedback on this when we go to IETF last call if it is insufficient. 
> 
> I hope the WG memeber can also check this also.

Thanks, Magnus.

I've pushed all of these updates to the rpc-tls github repo:

Editor's copy: https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.html

rfcdiff with -06: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-nfsv4-rpc-tls.txt&url2=https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.txt

Commit log with individual changes: https://github.com/chucklever/i-d-rpc-tls/commits/master


Dave has added a 10-minute slot to tomorrow's meeting for a final walk through
to discuss any remaining open controversies before I submit -07. Everyone,
please review the material at the above links so we can have firm closure on
this review process.

Thanks for everyone's time!


--
Chuck Lever