Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Tue, Sep 01, 2020 at 11:06:18AM -0400, Chuck Lever wrote:
> 
> 
> > On Aug 31, 2020, at 4:44 PM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > On Mon, Aug 31, 2020 at 11:06:51AM -0400, Chuck Lever wrote:
> >> Hi-
> >> 
> >> I've now addressed Roman's DISCUSS/COMMENT position. For reference, the
> >> current Editor's Copy with these changes can be found here:
> > 
> > Hmm, not quite -- the RFC 5487 ciphers are not compatible with TLS 1.3,
> > since TLS 1.3 redefines what a ciphersuite is (which also means that TLS
> > 1.3 provides native support for PSK handshakes), so you still need to
> > update Section 5.2.2 of this draft to refer to RFC 8446, removing the 4279
> > and 5487 references.
> 
> Whoops. A recent bad change needs to be reverted there.
> 
> NEW:
> 
> 5.2.2.  Pre-Shared Keys
> 
>    This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
>    is uniquely identified by keying material that has been shared out-
>    of-band or by a previous TLS-protected connection (see Section 2.2 of
>    [RFC8446]).  At least the following parameters of the TLS connection
>    SHOULD be exposed to the RPC server:
> 
>    *  The IP address of the peer that presented the certificate

In PSK mode, there may not be a certificate (though there can be, in
various scenarios).

>    *  TLS Identifier

Is this the PSK identifier or some other (TLS Exporter-generated?) value?

> 
> >>> (1) I don't think that the claim in Section 4.2 that "[b]oth RPC and TLS have
> >>> peer and user authentication" is correct, at least given my understanding of
> >>> those terms.  Using this document's definition of RPC "peer authentication"
> >>> as analogous to TLS server authentication, the functionality that TLS calls
> >>> "mutual authentication" is more analogous to RPC client authentication,
> >>> though it is sometimes repurposed for use for user authentication, with
> >>> concommittant bad user experience.  This analogy does not seem critical to
> >>> the mechanisms of this document, so I believe we should remove or modify it.
> >> 
> >> Perhaps it's a matter of terminology. RPCSEC_GSS "peer" authentication
> >> is truly mutual. For AUTH_SYS, both peers identify themselves by a name
> >> string in the RPC headers, though this is not cryptographically strong
> >> and thus is typically ignored by receivers.
> >> 
> >> I'm open to specific suggestions about how to modify the text.
> > 
> > I think it is a matter of terminology, yes -- RPCSEC_GSS has GSS
> > credentials for the user, specifically, but the TLS client credentials are
> > for the client, not the user, so it is misleading to say that TLS has user
> > authentication (in this context).
> 
> Ah, of course TLS and user authentication don't mix. I missed that.
> 
> OLD:
> 
>    Both RPC and TLS have peer and user authentication, with some overlap
>    in capability between RPC and TLS.  The goal of interoperability with
>    implementations that do not support TLS requires limiting the
>    combinations that are allowed and precisely specifying the role that
>    each layer plays.
> 
> NEW:
> 
>    There is some overlap between the authentication capabilities of RPC
>    and TLS.  The goal of interoperability with implementations that do
>    not support TLS requires limiting the combinations that are allowed
>    and precisely specifying the role that each layer plays.

Sure, that cuts right to the point.

> 
> > My suggestion would be something like:
> > 
> > Both RPC and TLS have provisions for both communication endpoints to
> > authenticate to each other, with some overlap in the authentication
> > semantics between RPC and TLS.
> > 
> >>> (4) I don't think it's particularly safe to suggest that non-protected RPCs
> >>> should be exchanged on the same 5-tuple that just terminated a DTLS
> >>> association, since neither DTLS nor UDP provide in-order delivery, so there
> >>> is ambiguity as to whether a datagram should be interpreted as DTLS
> >>> protected or not.  This is particularly problematic in the face of the three
> >>> different DTLS record headers (DTLSPlaintext, DTLSCiphertext(full), and
> >>> DTLSCiphertext(minimal)) with something like 10 or 11 different possible
> >>> values for the first byte that might be in flight, with limited "magic
> >>> number" verification fields available.  I think I need some input from the
> >>> TSV ADs about what the options are, though -- while a cooling-off period
> >>> might be fine if an ephemeral port is in use, it seems problematic for cases
> >>> where fixed port numbers are used for both source and destination.
> >> 
> >> This is a more complex issue, but I'm replying here to inquire if
> >> you've yet been able to circle back with the TSV ADs. Additional
> >> input is welcome.
> > 
> > The main output of my conversation with the TSV ADs was that we wanted to
> > get your (and the WG's) thoughts about how RPC is actually used, both for
> > NFSv4 and elsewhere.  If there are not any known/current deployments that
> > would be affected, then we can probably just document the risk and move on,
> > but if there are existing deployments that could trigger such a scenario,
> > we'll need to think through things more carefully.
> 
> NFSv4 does not permit the use of an unreliable datagram transport,
> so DTLS is not interesting in that case.
> 
> I'm not sure what is meant by "known/current deployments that would be
> affected." There are currently no implementations of RPC-over-TLS with
> DTLS. I actually don't know how UDP protected with a GSS integrity or
> privacy service would behave in this situation, but that would be the
> closest analog, IMO.

Right, the question is whether there's anybody doing RPC over UDP at the
moment with fixed port numbers and the potential for "fast" reconnection.
Off the top of my head, I think GSS would be fine since you have the GSS
security context handle to know what keys to use, and there's not a
"STARTTLS" analogue that involves mixing plaintext and GSS-protected
packets.

> 
> >>> (5) Section 5.2.1 requires that:
> >>> 
> >>>  *  Implementations SHOULD indicate their trusted Certification
> >>>     Authorities (CAs).
> >>> 
> >>> Indicate to whom?
> >> 
> >> The text is vague, but I assume based on context that the RPC-over-TLS
> >> implementation indicates the list of trusted CAs to the RPC server to
> >> make final decisions about authorization.
> > 
> > I'm still not entirely sure I am understanding properly.  This is sounding
> > (in some sense) like "one software component indicates to another software
> > component the list of trust anchors", but whether this is an instruction
> > ("use these") or a notification ("this is what I did") could be clarified.
> 
> Or this bullet could be removed. At this point I'm not certain the
> compliance statement adds any value.

Okay.

> 
> >>> (7) Section 5.2.1 uses the phrase "renegotiate the TLS session".
> >>> Renegotiation is not defined or allowed for TLS 1.3; generally one would
> >>> need to either remember the presented certificate and re-run the validation
> >>> process on it or shutdown the TLS connection and make a new one, though in
> >>> theory one could try to define a mechanism using post-handshake
> >>> authentication.  (I don't recommend the latter, though; it's not widely
> >>> implemented/used.)
> >> 
> >> OLD:
> >> 
> >> implementations MAY renegotiate the TLS session to reassess the
> >> connecting peer’s continued authorization.
> >> 
> >> NEW:
> >> 
> >> implementations MUST terminate the TLS session.
> > 
> > That is okay from the perspective of failing safe, but may be overly
> > restrictive.  I think it would be okay, if an implementation had the
> > ability to do so, to merely reevaluate the certificate originally presented
> > in the context of the new configuration.
> > Terminating the TLS session is a disruptive event, and this requirement
> > would require us to boot everyone's session every time the CA/CRL
> > configuration changes -- that is giving operators a huge disincentive to
> > ever change the CA/CRL configuration, which is arguably bad for the overall
> > security of the system.
> 
> OLD:
> 
>    *  When the configured trust base changes (e.g., removal of a CA from
>       the list of trusted CAs; issuance of a new CRL for a given CA),
>       implementations MAY renegotiate the TLS session to reassess the
>       connecting peer's continued authorization.
> 
> NEW:
> 
>    *  When the configured trust base changes (e.g., removal of a CA from
>       the list of trusted CAs; issuance of a new CRL for a given CA),
>       implementations SHOULD reevaluate the certificate originally
>       presented in the context of the new configuration and terminate
>       the TLS session if the certificate is no longer trustworthy.

I can live with that.  It would be nice to have a MUST-level requirement
for (roughly) "do something sensible", but you can't exactly write that in
an RFC, and I don't have better text to propose at the moment.

Thanks,

Ben