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

[Trond Myklebust <[e-mail]>]

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)".
> 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 
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4