Re: [dtn] PKIX Extended Key Purpose recommendations

[Brian Sipos <[e-mail]>]

Russ,
To give a very short background: DTN is an overlay network and uses Endpoint IDs (which are URIs) as bundle destinations and Node IDs (also URIs) as bundle origination and routing hops. This is slightly different from S/MIME in that DTN messaging is not symmetric (a bundle origin is a Node, but its destination is an Endpoint which may be "multicast"). The bundle protocol does have administrative messaging, for which the Node ID is the Endpoint ID, and a draft mechanism for a CA to verify the owner of a Node ID [6].

So there is a way for a CA to know that an end-entity both participates in DTN and has a Node ID for which bundles can be sent and received. The harm of incorrectly including the DTN EKU is a leaking, spoofing, or blackholing of bundles related to an impersonated node. Although based on current DTN implementations, the TCPCL-exchanged Node ID alone is not enough to impersonate a node. Higher-level routing data (mapping Node IDs to CL protocols and network addresses) associated with a bundle protocol agent is really needed to be manipulated to fully impersonate a node.
The harm of excluding the DTN EKU is a peer not being able to distinguish between an end-entity cert validated for and issued for e.g. HTTP being used for DTN authentication of a DNS-ID. This second harm is not so bad in the sense that if a CA has verified a DNS name that the certificate holder is still authenticated to be using that DNS name.

To Ben:
Maybe a better recommended policy is to require authentication of one of the NODE-ID, DNS-ID, or IPADDR-ID but to only use the received peer Node ID as authoritative (e.g. for peer discovery, updating routing tables, etc.) if the certificate has the DTN EKU value..? This allows flexibility in what kind of identity can be issue from a CA to establish the session but limits the use of a not-really-authenticated peer Node ID while still allowing normal routing to occur.

Since the recommended policy still requires mutual authentication, only the passive side can even use a DNS-ID to authenticate. So there are still potentially CA policy issues that need to be worked out e.g., allowing Node ID validation [6].

[6] https://tools.ietf.org/html/draft-ietf-acme-dtnnodeid-00
[7] https://tools.ietf.org/html/rfc4945#section-5.1.3.12

________________________________
From: Russ Housley <[e-mail]>
Sent: Saturday, November 21, 2020 13:15
To: Brian Sipos <[e-mail]>
Cc: [e-mail] <[e-mail]>; Ben Kaduk <[e-mail]>
Subject: Re: PKIX Extended Key Purpose recommendations

Brian:

I was referred to you from Ben Kaduk regarding the design and use of a new PKIX Extended Key Purpose. The use cases for this new purpose are for the IETF DTN WG (CCd on this email) and currently fall under three categories: bundle transport security (using TLS), bundle integrity (signing), and bundle confidentiality (encryption).

The idea is that a new OID is allocated for "DTN Security" and this would be present in the EKU to indicate that a CA has verified the key holder to be trusted to run a DTN node. There is an open question as to whether there is enough distinction between a purpose of "generating or accepting security blocks" and the purpose of "transporting a whole bundle untouched".

The good news for rationale and understanding of these uses are that they are very similar to SMTP/TLS [1] and S/MIME [2] respectively. Although it appears that the id-kp-emailProtection OID was only ever specified for S/MIME and not for email transport between MTAs. I don't know what kinds of policies SMTP MTAs have with regard to PKIX certificates, even recent MTA-STS spec [3] doesn't define or reference a more detailed PKIX profile and doesn't mention any X.509 extensions at all.

id-kp-emailProtection is for use with S/MIME.  It should only appear in certificates that also contain an email address for the subject.

The bad news is that in some very simple testing of adding a new purpose OID I see that OpenSSL, which is used by both of my reference libraries Qt5 and python "ssl" package, appears to assume [4] that when I want "TLS on a socket" what I mean is "TLS for Web client/server purposes" and requires either id-kp-serverAuth or id-kp-clientAuth. There also appear to be quite a number of other implicit uses of the Web purposes in OpenSSL and no real access via higher-level APIs to affect this. The other key purposes seem to be usable only through different APIs unrelated to TLS.

id-kp-serverAuth or id-kp-clientAuth are for use with TLS.  id-kp-serverAuth usually contains a domain name in the for the subject.  In the MTA example, the client also contains a domain name in the for the subject, but that is not the only situation where client authentication is used.

Ben originally referred me to [5] as an example of allocating new OIDs for another recent use of TLS for RPC. That draft doesn't really have a PKIX profile for how the new purposes inter-relate with existing purposes or how validation should treat the new purposes relative to pre-existing purposes.

All that said, the short question is: is there value in allocating an extended key purpose for DTN security?
If so, how much detail for a certificate profile and/or validation logic is either necessary or useful relative to any new purpose?

I do not know enough about DTN to know.  How would a CA know whether a particular certificate out to include the DTN-related EKU value or not?  What would be the harm if it was incorrectly included?  What would be the harm if it was incorrectly omitted?

Russ