Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

[Brian Sipos <[e-mail]>]

Ben,
I really appreciate the critical eye for security implications and know that small oversights can lead to big problems.
Part of the reason for this somewhat slow drag toward a solid set of TLS requirements is the starting point of web-PKI-focused tools and TCPCLv3 statement that "Nothing in TCPCL prevents the use of the TLS protocol to secure a connection" leaves gaps to fill.

Related to your earlier reply, I think that allocating a EKU OID for DTN will help to turn some of these assumptions about CA behavior into actual encoded claims of purpose. Do you think that these two can be treated as equivalent for the goal of recommended security policy?

  1.  A certificate with an exact NODE-ID (and EKU either absent or including DTN). This leaves no doubt about the claim.
  2.  A certificate with a DNS-ID or IPADDR-ID and with a EKU including DTN. Indicates that the CA is aware that the host is intended as a DTN node.

Should #2 be explicitly related to the use of opportunistic security? Only if an entity has enabled opp. sec. does the DNS-ID or IPADDR-ID matter. Otherwise, only the NODE-ID matters.
Do other protocols make a hard separation between "enabled or disabled" in relation to opportunistic security?

For background on how this would be used in DTN: Because DTN is an overlay network, bundle routing always requires a node to have logic related to "when a bundle needs to go to endpoint X, it's next hop should be node Y over convergence layer Z" where "Y" is the next-hop Node ID and "Z" is the transport which (for internet transports) includes either a DNS name or IP address (i.e. some way to contact the node). The idea is that a peer already has an idea of "what node am I looking to send this to" and uses that DNS name or IP address to contact that node.
I think that this means that the in-band Node ID is superfluous for this use, and is more useful as a diagnostic "oops, I was trying to contact Z but you claim to be W" warning mode. This is how some existing DTN stacks behave.
The benefit to having a certificate claim on a Node ID directly is that there is added agility to use multiple DNS names or IP addresses over time as network topology or access change (as a DTN is wont to do).

One last topic of the authentication logic: I did originally look at requiring it that way, but the current text has a behavior which that type of logic does not; if a certificate does contain an IPADDR-ID then the current text requires it to match the connection. The different claim types are ANDed together. If a cert has a NODE-ID and an IPADDR-ID they both must authenticate the peer, regardless of policy. Policy may only allow the absence of a claim type it may not allow a failed claim type.

________________________________
From: Benjamin Kaduk <[e-mail]>
Sent: Monday, November 16, 2020 20:39
To: Brian Sipos <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

Hi Brian,

Thanks for the updates in the -22 (and -23 that landed more recently).

On Tue, Oct 27, 2020 at 03:49:24AM +0000, Brian Sipos wrote:
> Ben et al.,
> I've posted an updated draft which includes changes to address all but one of the latest SECDIR comments. The one remaining comment relates to when TLS is supposed to be negotiated for use:

I think we need to continue the conversation about
naming/certificate-validation; more below.

> I think we can also wordsmith the setting of CAN_TLS a little more;
> previous discussion indicated a desire to (e.g.) not require TLS when
> operating over IPsec, but that's a different criterion than "capable of
> exchanging messages [with TLS]".  It's also inconsistent with a desire
> to make TLS support mandatory to implement (but not mandatory to use),
> since mandatory to implement implies mandatory to be "capable of
> exchanging messages with TLS", thus mandatory to use.
>
> For my own purposes and for public network use TLS would be expected, so I don't have a full idea of when TLS would be desirable to negotiate away. Would a more generic statement, inverting the current logic, such as the following work?
>
> When sufficient security is not supplied by network layers under TCPCL, the the CAN_TLS flag within its Contact Header SHALL be set to 1.
> When CAN_TLS flag is set to 1, the peer SHALL be capable of exchanging messages according to TLS 1.3 [RFC8446] or any successors which are compatible with that TLS ClientHello.

This phrasing would address my concerns (I gave a different alternative in
my response to Ran a few minutes ago).



Back to the topic of naming and the authentication/certificate-validation
procedures.  Instead of just looking at diffs, I went and re-read all of
§4.4 of the -23 to try to look at a coherent picture of the current draft.
I'll put some specific comments later on, but will try to stick to a
high-level picture here since I'm still not sure that we're understanding
each other very well.

In a typical PKI setup, such as the Web PKI, a CA issuing a certificate
only is making claims about the specific bits in the certificate: for
Subject information like a DNS-ID, the CA verifies that the entity
requesting the certificate controls the domain name in question, and
specific X.509 extensions or extendedKeyUsage values may have additional
semantics (and require additional CA verification of the entity requesting
the certificate).  In particular, it does not say anything about the
general trustworthiness of the holder of the certified private key -- one
example of this is how ACME/Let's Encrypt makes it easy for
spammers/phishers to get valid Web PKI certificates for their malicious
domains.  So in this document when we set up a scenario where an entity
authenticated only with DNS-ID or IPADDR-ID is then somehow trusted to
provide a valid/correct Node ID in the SESS_INIT, this is a huge leap of
faith, in the general case.  Now, if we limited our trust anchors to only
CAs that do additional validation (such as only issuing certificates to
trusted end-entities), or if we required a DTN-specific extendedKeyUsage
value and assign semantics to that EKU value that requires the CA to be
careful about who it issues certificates for, then this leap of faith can
become more controlled and limited, but with only the procedures we
describe in the -23, it's a rather unbounded risk.

Accordingly, if a given entity is willing to accept DNS-ID authentication
of a peer and any claimed Node ID from that peer, then the provable
security of the entire network of nodes that includes that entity degrades
accordingly (in the internet threat model), since the attacker can claim
any Node ID.  A more subtle security policy can improve the situation, if
we could know a priori that (for example) certain Node IDs will always be
able to provide a certificate for that NODE-ID -- then we could only fall
back to allowing DNS-ID validation plus peer-claimed Node ID when we're
initiating connections to other nodes, and we could additionaly apply some
sort of filter to which received Node IDs we allow in the SESS_INIT.  But
that requires having policy in place before we start a connection, based on
the Node ID we're trying to reach -- a reactive behavior where we wait for
what the peer gives us and try to validate that leaves us open to an
attacker manipulating us into using the weakest validation procedures.

I'd like to have a better understanding of how you picture the case with no
NODE-ID in the cert being used, and what kind of limitations can be placed
on the peer's ability to claim arbitrary Node IDs in that case.  I feel
like I'm still assuming or inferring a lot, so I don't know how well my
understanding maps to the intended usage.  I'm happy to get on a call to
chat about this (and I plan to be in the IETF 109 gather.town space a lot
this week as well).


I also have a note in my specific comments about the apparent case when
just authenticating the peer's NODE-ID is not sufficient, and we would also
insiste on DNS-ID (or IPADDR-ID) validation.  In my intuition, the Node ID
is the application-layer identity that we're trying to authenticate, and
even if the DNS-ID authentication fails we still would believe that we're
talking to the intended Node.  As I say below, "what's the motivation for
failing the connection if the NODE-ID authenticates but the DNS-ID
doesn't?"  I could imagine that there's some desire to have an initial
authentication occur during the TLS handshake, in accordance with the
typical TLS implementation behavior, and then have a separate check for the
Node ID after the TLS handshake has completed; this would keep the
components separate and have a clean abstraction barrier, but the current
description in the -23 doesn't really give me the impression that that was
the intent.

The rest of my specific comments appear below.

Thanks again,

Ben


Section 4.4.1

   Node ID:  The ideal certificate identity is the Node ID of the entity
      using the NODE-ID definition below.  When the Node ID is
      identified, there is no need for any lower-level identification to
      be present (though it can still be present, and if so it is also
      validated).

It's pretty weird to say "if [lower-level identification is present] it
is also validated".  Part of why it is weird is because it's another
example of letting the as-yet-untrusted peer affect what validation
procedure is used for authenticating it, but it also feels like the
NODE-ID is the actual identifier we care about, and even if there's (for
example) DNS hijacking or NAT going on, if we have authenticated the
NODE-ID we know it's the entity we are trying to talk to.  What's the
motivation for failing the connection if the NODE-ID authenticates but
the DNS-ID doesn't?

   When only a DNS-ID or IPADDR-ID can be identified by a certificate,
   it is implied that an entity which authenticates using that
   certificate is trusted to provide a valid Node ID in its SESS_INIT;
   the certificate itself does not actually authenticate that Node ID.

Perhaps a bit meta, but trusting the end-entity with such a cert to
identify itself transitively implies trusting the CA to only issue
certificates to entries that are trusted to provide the correct Node ID.
So I'd consider adding another sentence here along the lines of
"Such trust is in general not guaranteed by PKI name certification,
though a specific set of trusted CAs may apply more stringent
certificate issuance criteria."

   The RECOMMENDED security policy of an entity is to validate a NODE-ID
   when present, and only require DNS-ID/IPADDR-ID authentication in the
   absence of a NODE-ID.

(This is still leeting the as-yet-untrusted entity affect its own
validation procedure.)

Section 4.4.3

   SHALL perform the certification path validation of [RFC5280] up to
   one of the entity's trusted CA certificates.  If certificate
   validation fails or if security policy disallows a certificate for
   any reason, the entity SHALL fail the TLS handshake with a bad
   certificate error.  Leaving out part of the certification chain can

nit: it's conventionally phrased as 'with a "bad_certificate" alert'.

   Either during or immediately after the TLS handshake if the active
   entity resolved a DNS name (of the passive entity) in order to
   initiate the TCP connection, the active entity SHALL authenticate
   that DNS name using any DNS-ID of the peer certificate.  If the DNS
   name authentication result is Failure or if the result is Absent and
   security policy requires an authenticated DNS name, the entity SHALL
   terminate the session (with a reason code of "Contact Failure").

(editorial) the actual behavior here is okay, but the way it is written
with "SHALL authenticate that DNS name" seems to strongly imply that the
entity has to go through the motions of doing that work, even if the
local security policy isn't going to care about the result.  My
preference (which you have no obligation to heed) would be to flip the
order around to say that if security policy requires the result, then it
SHALL do the DNS name authentication.
(Similarly for the IPADDR-ID and NODE-ID text, of course.)