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

[Benjamin Kaduk <[e-mail]>]

Hi Brian,

On Wed, Nov 18, 2020 at 10:20:54PM +0000, Brian Sipos wrote:
> Ben,
> I see your concerns and I'm looking along a couple of different axes: what other specifications using TLS say to do (relative to RFC6125) and how some implementations behave relative to multiple identifiers and identifier types in PKIX certs.

I'm very grateful that you are willing to dig into the topic to this
extent; thank you!

> My current thinking is that there really are two separate "Verifying Service Identity" (Section 6 of RFC6125) searches:
> 
>   1.  Search based on both DNS-ID (if a name was used/relevant) and IPADDR-ID reference identifier. This verification succeeds if either identifier matches the cert.
>   2.  Search based on NODE-ID reference identifier.

I think in some sense that's correct, yes.  (A fairly strong sense, though
it's not quite something that I would say is "universally the correct way
to think about it" or something like that.)  <tangent>In a different
universe we might have attempted to separate them further, with #1 always
happening, at the TLS layer, and #2 also always happening but using some
different (application-layer, possibly CMS or something over a channel
binding value) mechanism and possibly different credentials type as well.
I say "in a different universe" because the path from where we are to such
a scenario is not very clear and there are no fundamental flaws with the
general structure we already have, so it doesn't seem worth just throwing
it all away to start over.</tangent>

> Unfortunately, there is a catch-22 about ordering because #1 is the typical peer authentication which is "built in" in many cases to existing tools (though TLS client address verification seems to be sporadic) while #2 is the new behavior based on post-handshake exchanged data, but the recommended policy is to do #2 unconditionally and only do #1 as a fallback. This means that #1 cannot occur until after the completion of #2 and evaluation by security policy.

Yes.

> So massaging this recommended policy becomes that either one of the following must succeed (no order):
> 
>   *   Verification #1 along with requiring an EKU for DTN security, or
>   *   Verification #2
> 
> This avoids an order or time dependence but does prohibit an implementation from failing early if #1 does not succeed. There's already a security threat for Node Impersonation and a user of the recommended policy just needs to be aware of this threat.
> 
> Does any of this sound reasonable?

I think it all sounds reasonable :)

We will recognize, of course, that this recommended policy will not apply
in all scenarios, and that when verification #1 is used without the EKU for
DTN security, the threat of node impersonation is more prominent (IIUC this
is basically what your last sentence about the "security threat" is
saying); in some scenarios that can be an acceptable risk.

Thanks again,

Ben

> From: Benjamin Kaduk <[e-mail]>
> Sent: Tuesday, November 17, 2020 21:21
> 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,
> 
> On Tue, Nov 17, 2020 at 04:56:11AM +0000, Brian Sipos wrote:
> > 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.
> 
> Understood.
> 
> > 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?
> 
> It will help to some extent, though in practice it might not help very much
> -- existing Web PKI CAs are pretty unlikely to start signing new EKUs
> without a fair bit of work.  (Mostly on non-technical aspects of things, as I
> understand it, though I am sure I will learn a lot at tomorrow's SAAG
> presentation on what is needed to set up a PKI.)
> 
> >   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.
> 
> The two are of course not exactly equivalent, but for the purposes of a
> default security policy it will probably be fine to accept either of them.
> (We will want to be clear in the definition of the EKU that the semantics
> include the holder of the certificate being trusted to provide a Node ID if
> one is not in the certificate, though.)
> 
> > 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?
> 
> In my mind #2 is a variation on non-opportunistic (or "full") security,
> rather than a form of opportunistic security, though in some sense there is
> a hierarchy or continuum and this is just one point on that ladder.
> Usually I see "opportunistic security" used to refer to just not attempting
> to authenticate the peer at all, ignoring failure to validate the expected
> hostname against the presented certificate, etc., but the #2 is still doing
> some partial validation, just at a different level of naming than #1.  So
> I'm not entirely sure that I understand the question about a hard
> separation for enabled/disabled.
> 
> > 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).
> 
> Thank you for this background; it is very reassuring to hear.  (It matches
> my intuition on how things should work, but I don't have much confidence
> that my intuition will always be correct, since this area is pretty far
> from my normal areas of expertise.)  I heartily agree about the benefits of
> having a Node ID directly in the certificate.
> 
> > 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.
> 
> I think this is actually a bad property to have, leading the system to
> become unnecessarily "fragile".  In particular, the semantics of a
> certificate are "the holder of the private key corresponding to this
> certificate can act as the various entities named in the Subject fields",
> but not "this is an exhaustive list of the names for the holder of the
> private key corresponding to the certificate".  So, we might end up in a
> scenario where the same entity can be named by any/all of Node-IDs A and B,
> and IP addresses X and Y.  But if those identities are bundled to gether
> into one certificate with A and X, and a second certificate with B and Y,
> then no single certificate could satisfy a peer that is trying to talk to
> node A on address Y -- with the current validation policy in the -23 the
> peer would have to fail the connection no matter what certificate is
> presented.
> 
> To put it more pithily: just because I have one IP address in my
> certificate does not mean that all of my IP addresses are in my
> certificate.
> 
> Does that help clarify my thinking?
> 
> Thanks again,
> 
> Ben