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

From: Chuck Lever <[email-masked]>
Date: Tue, 1 Sep 2020 11:06:18 -0400

> On Aug 31, 2020, at 4:44 PM, Benjamin Kaduk <[email-masked]> 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

   *  TLS Identifier

>>> (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.

> 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.

>>> (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.

>>> (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.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 1 Sep 2020 11:26:21 -0400

> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (8) Can we clarify the status of DNSSEC (or DANE) requirements?  Section 1
> assumes that support for DNSSEC is already available in an RPC
> implementation, but Section 7.1.1 says that "Clients [sic] implementors can
> choose from" a list of things including DANE TLSA records.  Why would we
> require DNSSEC support but not using the records if they're present?

OK, I'm parsing this comment more closely now.

The statement in Section 1 you refer to above is:

   The protocol specification in the current document assumes that
   support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available
   in an RPC implementation where TLS support is to be added.

I hadn't counted this as a "requirement" since a BCP14 keyword is
not used, and because it appears in the Introduction as background
material.

Section 7.1.1 currently says this:
                                                              Clients
   implementers can choose from the following to mitigate STRIPTLS
   attacks:

   *  A TLSA record [RFC6698] can alert clients that TLS is expected to
      work, and provide a binding of hostname to X.509 identity.  If TLS
      cannot be negotiated or authentication fails, the client
      disconnects and reports the problem.

   *  Client security policy can require that a TLS session is
      established on every connection.  If an attacker spoofs the
      handshake, the client disconnects and reports the problem.  If
      TLSA records are not available, this approach is strongly
      encouraged.

Here, it is assumed that the RPC-over-TLS implementation has DNSSEC
support. What is not assumed is that the peer always operates in
an environment where the DNS administrator has configured TLSA
records.

I'm open to suggestions on how to structure this section more clearly.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 1 Sep 2020 09:09:54 -0700

>    *  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?

>    and precisely specifying the role that each layer plays.

Sure, that cuts right to the point.

> privacy service would behave in this situation, but that would be the

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.

> compliance statement adds any value.

Okay.

>       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

---

From: Chuck Lever <[email-masked]>
Date: Tue, 1 Sep 2020 13:10:26 -0400

> On Sep 1, 2020, at 12:09 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

And perhaps the IP address of the peer has changed since the PSK
was originally exchanged.

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

Not clear to me that we need to define a TLS Exporter.

I think the only use for the identity information is to authenticate
the peer. We're not trying to use the PSK material for anything else.

So we want something that indicates that "this peer is the same peer
we contacted when the PSK was originally exchanged."

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 4 Sep 2020 11:22:02 -0400

> On Sep 1, 2020, at 1:10 PM, Chuck Lever <[email-masked]> wrote:
> 
> 
> 

This replacement for the Pre-Shared Key section might address
your comments here and in the COMMENT ballot position:

NEW:

5.2.2.  Pre-Shared Keys

   This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
   can be uniquely identified by keying material that has been shared
   out-of-band (see Section 2.2 of [RFC8446]).  At least the following
   parameter of the TLS connection SHOULD be exposed at the RPC layer:

   *  PSK Identifier

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 9 Sep 2020 10:58:16 -0400

Hi Ben-

It appears that many of your comments have overlapping impact on
the document, so I'm attempting to address all of them in my
working copy of the document and will post proposals for replacement
text once I feel that they coherently address your concerns.

More below.

> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

...

> (6) The usage of RFC 6125 procedures in Section 5.2.1 seems counter to its
> intent.  Specifically, we seem to be saying "the peer gave me a cert, let me
> look through it to see if it has something I like", but RFC 6125's intended
> procedure is "I know a list of names that I expect to see at least one of in
> the cert; these rules tell me whether the cert is valid for any such name".
> It's not entirely clear that it's appropriate for this document to specify
> how the client has to order its list of names by type (per Section 6.1 of
> RFC 6125's "The client constructs a list of acceptable reference
> identifiers"), which the bit about "The following precedence applies" seems
> to be doing.  To the extent that we give a recommendation to use DNS-ID
> instead of CN-ID, and ipAddress SAN instead of CN-ID, that's already covered
> by RFC 6125; it would be okay for us to say "use DNS-ID or iPAddress SAN",
> though.  (Roman's comment about "why not a normative MUST" for putting IP
> addresses in the iPAddress SAN is related, and if we don't have a compelling
> reason to allow the flexibility, we should limit to the specific
> DNS-ID/iPAddress options without allowing CN-ID.)
> 
> (6.1) Note additionally that if wildcard certificates are to be used, RFC
> 6125 requires the application protocol specification to give details on how
> they are to be used.
> 
> (6.2) RFC 6125's procedures are (facially, at least) only valid for TLS
> server authentication.  We also want to authenticate TLS clients, so we
> should say whether we expect the same procedures to be used, or what
> procedures should be used (even just as how it differs from the RFC 6125
> ones).  Of particular note is that, since the server is not initiating the
> network connection, it is unlikely to have a preconceived notion of what
> client identity to expect, and is likely limited to attempting to extract
> something from the certificate.  In this scenario a precedence list (as I
> complained about being inconsistent with RFC 6125 above) would be
> appropriate.

These two DISCUSS points are related to Section 5.2.1, and will
likely have to be dealt with by rewriting that section. The crux
of your commentary seems to be:

--- Clients use different logic for authenticating and authorizing
a TLS session than servers do, and what rpc-tls provides is a jumble.

As you point out, RFC 6125 stipulates that clients authenticate a
server by checking its presented identity against a list of known
identities. I don't see a need for rpc-tls to further decorate the
process laid out in RFC 6125, and I don't know of any issue with
disallowing CN-ID.

rpc-tls still thinks about the server-side authorization process in
terms of the NFS server's legacy IP access control list. Instead we
should think of it like GSS: the RPC layer handles authorization, full
stop, and nothing need be exposed otherwise. The peer's IP address may
be exposed to the upper layer service, but I don't see that rpc-tls
needs to take a position on that; it's an implementation quality issue.

However, rpc-tls does need to provide explicit instructions for servers
to authenticate clients. Thus editorially I think we need to split
Section 5.2.1 into a section that describes server authentication of
clients, and client authentication of servers.

I'm wondering if the PSK section likewise needs bifurcation. But also,
I'm not sure that the PSK identity needs to be surfaced, for similar
reasons: TLS should handle authorization -- either the session was
established by the rules, or it wasn't authorized, and that's all the
upper layer consumer needs to be aware of.

Finally, there's the issue of whether a TLS exporter will be necessary
for properly dealing with GSS channel binding. I haven't looked at that
closely yet, but it might need to be partially addressed in 5.2.1.

I'm interested in my co-author's thoughts, as well as the opinions of
those who have already implemented a RPC-over-TLS prototype.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 11 Sep 2020 12:48:32 -0400

Hi Ben-

I'm nearly done with the new text. I need some clarification below.

> COMMENT:
> I'm surprised that we don't make a normative reference to BCP 195's
> "Recommendations for Secure Use of Transport Layer Security (TLS) and
> Datagram Transport Layer Security (DTLS)" (we have only an informative
> reference from the security considerations).

Is there a specific change you'd like to see?

>   *  Host identity management and user identity management must be
>      enforced in the same security realm.  In certain environments,
>      different authorities might be responsible for provisioning client
>      systems versus provisioning new users.
> 
> I think this is only true from a certain point of view.  They have to be
> related, and (assuming Kerberos since non-Kerberos RPCSEC_GSS isn't really a
> thing) a cross-realm relationship would have to exist in at least one
> direction when client system and user provisioning are managed by separate
> kerberos realms, but the authorities in question do not need to be exactly
> the same.

I'm not clear what needs to change.

>   Encryption By Default:  Transport encryption can be enabled without
>      additional administrative tasks such as identifying client systems
>      to a trust authority, generating additional keying material, or
>      provisioning a secure network tunnel.
> 
> To clarify Roman's comment, it seems worth specifying that this is without
> additional *per-client* keying material.  Generating per-server keying
> material is clearly a minimum requirement.

The text was updated at Roman's request. It now reads:

   Encryption By Default:  Transport encryption can be enabled without
      additional administrative tasks such as identifying client systems
      to a trust authority and providing each with keying material.

Can you confirm this adequately addresses your comment?

> Section 4.1
> 
>   The mechanism described in the current document interoperates fully
>   with RPC implementations that do not support RPC-over-TLS.  Policy
>   settings on the RPC-over-TLS-enabled peer determine whether RPC
> 
> I'd consider joining the two sentences via ", subject to policy settings on
> the RPC-over-TLS-enabled peer that determine".

The text was updated at some point during IESG review. It now reads:

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-over-TLS.  When an
   RPC-over-TLS-enabled peer encounters a peer that does not support
   RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer
   determine whether RPC operation continues without the use of TLS, or
   RPC operation is not permitted.

Can you confirm this is adequate?

>   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.
> 
> We could probably normalize the wording between the TCP and UDP cases (e.g.,
> TCP says "typically, once a client completes the TCP handshake, it uses the
> mechanism [...]" but this uses descriptive text).  That would also let us
> decide whether or not to mention that (D)TLS usage is contingent on mutual
> support for STARTTLS.

The reason the TCP and UDP text diverge is because TCP is connection
oriented and UDP is not. The current UDP text is the result of some
earlier review comments in this area. Let me know if there is a
specific change you'd like to see here.

Also, I don't understand the last sentence of your comment. Can you
elucidate?

> Section 8.1
> 
> Isn't it codepoint squatting to claim auth flavor 7 before IANA has
> allocated it?  (This is usually a Discuss-level issue, but that part is too
> long already so I left it here.)

I agree it is slightly improper, but the authors were not aware of
IANA's authority over RPC authentication flavors until late in the
document's life cycle. It was a good faith oversight.

I believe we have IANA's permission at this point to use the value 7.

Is there a text change needed here?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 14 Sep 2020 18:46:39 -0400

> document's life cycle. It was a good faith oversight.

I think everyone  accepts that.

> I believe we have IANA's permission at this point to use the value 7.

It's best to ask them.  If they don't agree, we can ask for an early
allocation.

> Is there a text change needed here?

There might be.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 15 Sep 2020 09:25:36 -0400

> On Sep 14, 2020, at 6:46 PM, David Noveck <[email-masked]> wrote:
> 
> 
> 
> On Fri, Sep 11, 2020, 12:50 PM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ben-
> 
> > On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> >  
> 
> > Section 8.1
> > 
> It's best to ask them.  If they don't agree, we can ask for an early allocation.

Quoting from IANA review of draft-ietf-nfsv4-rpc-tls in late May:

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rpc-tls-07. If any part of this review is inaccurate, please let us know. 

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the RPC Authentication Flavor Numbers registry on the Remote Procedure Call (RPC) Authentication Numbers registry page located at:

https://www.iana.org/assignments/rpc-authentication-numbers/ <https://www.iana.org/assignments/rpc-authentication-numbers/>

a single, new registration will be made as follows:

Identifier String: AUTH_TLS
Flavor Name: TLS
Value: [ TBD-at-Registration ]
Description: Signals the use of TLS to protect RPC messages on socket-based transports.
Reference: [ RFC-to-be ]

IANA notes that the authors have requested a value of 7 for this registration.

"Permission to use" was admittedly a little strong. But they are aware of our use of 7 and according to the above registry, it is still unassigned.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 15 Sep 2020 22:11:55 -0400

I think that's fine but it is really up to Ben.

On Tue, Sep 15, 2020, 9:25 AM Chuck Lever <[email-masked]> wrote:

> The IANA Functions Operator has completed its review of
> draft-ietf-nfsv4-rpc-tls-07. If any part of this review is inaccurate,
> please let us know.
>
> The IANA Functions Operator understands that, upon approval of this
> document, there are two actions which we must complete.
>
> First, in the RPC Authentication Flavor Numbers registry on the Remote
> Procedure Call (RPC) Authentication Numbers registry page located at:
>
> https://www.iana.org/assignments/rpc-authentication-numbers/
>
> "Permission to use" was admittedly a little strong. But they are aware of
> our use of 7 and according to the above registry, it is still unassigned.
>
>