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

[Magnus Westerlund <[e-mail]>]

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. 

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------