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

[Chuck Lever <[e-mail]>]

> On Apr 20, 2020, at 8:45 AM, Trond Myklebust <[e-mail]> wrote:
> 
> On Mon, 2020-04-20 at 05:51 -0400, David Noveck wrote:
>> 
>> 
>> On Sun, Apr 19, 2020, 11:40 AM Chuck Lever <[e-mail]> wrote:
>>> > 
>>> > 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.
>>> > 
>>> 
>>> 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.
>> 
>> Actually, I didn't.  I got to Appendix A of 5531 directly, trying to understand the current role of AUTH_SYS for my slides Wednesday.
>> 
>>> 
>>> 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.
>> 
>> I agree but think we could non-controversially draw attention to the wealnesses of the existing approach by adding "(I.e. without transport-level encryption or client authentication)" after "by itself".  I think that is the kind of clarification that is reasonable even at this late stage.
> 
> Transport level encryption is not an indicator that this is a trusted client, only that the transport itself is secure; I could still have your server see a fudged client IP+port number (e.g. by routing through a NAT).
> Client authentication is really the only way to ascertain that the client is indeed the trusted entity without adding another layer of strong authentication on top of TLS.
> 
> In short: I'd prefer dropping the 'transport-level encryption or' bit in your proposal and just leave it as "(I.e. without client authentication)".

Here's how the middle section of Appendix A reads after this addition:

   Appendix A of [RFC5531] contains a brief explanation of security
   considerations:

      It should be noted that use of this flavor of authentication does
      not guarantee any security for the users or providers of a
      service, in itself.  The authentication provided by this scheme
      can be considered legitimate only when applications using this
      scheme and the network can be secured externally, and privileged
      transport addresses are used for the communicating end-points (an
      example of this is the use of privileged TCP/UDP ports in UNIX
      systems -- note that not all systems enforce privileged transport
      address mechanisms).

   It should be clear, therefore, that AUTH_SYS by itself (i.e., without
   strong client authentication) offers little to no communication
   security:


>> Ultimately this will need to be addressed by describing how the authentication material provided by the client is to be used. I had been thinking that would be done in NFSV4-specific documents but it might be possible/necessary to do some of this at the RPC level, given what RFC 5531 already says
>> 
>> 
>>> 
>>> --
>>> Chuck Lever
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> 
>> https://www.ietf.org/mailman/listinfo/nfsv4
>> 
> 

--
Chuck Lever