Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

[Rick Taylor <[e-mail]>]

Hi Brian,

From my reading of BPv7, a Node-ID is just an Endpoint ID with a special meaning (it’s the EID of the node itself, rather than another service on the node, or a multicast endpoint), so I suggest having the “otherName” OID registered as “DTN Endpoint ID” type.

There may be advantage to that flexibility beyond TCPCL, I can imagine use-cases where services may need to assert an identity just as a node does for TCPCL, and the generic “otherName” is the right tool for that job as well.

Cheers,

Rick


From: Brian Sipos [mailto:[e-mail]]
Sent: 24 August 2021 21:35
To: Rick Taylor
Cc: Birrane, Edward J.; R. Atkinson; Brian Sipos; [e-mail]
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

One remaining technical decision about this is: does the SAN otherName allow only Node ID values or any Endpoint ID values. This certificate profile will only have a use for Node ID, but this restriction is related to the SAN otherName type definition and not how that type is used by the profile. From the tool perspective, it seems a little easier to allow the type to contain any EID. A non-Node-ID value won't match any CL peer Node ID so there's no harm in the otherName value being an EID.

On Tue, Aug 24, 2021 at 4:20 PM Brian Sipos <[e-mail]<mailto:[e-mail]>> wrote:
Ed and Rick,
The fundamental issue is that tools can and do make assumptions beyond the already incompatible requirement from RFC 5280 that a SAN URI have an internet name (DNS FQDN or IP address), and there are some pre-existing issues anyway with tools using SAN URI and PKIX certificate constraints. The SAN extension is the right place to put it, but the "uniformResourceIdentifier" type . Like some other aspects of IETF protocols, where PKIX uses generic "URI" or similar terms what they really mean (and what tools/libraries can assume) "internet name URI."

The change is to redefine what is a NODE-ID (it changes from a SAN URI to a SAN otherName with a newly allocated type OID to specifically contain a DTN EID value). This will require no change or conflict with RFC 5280 or existing PKIX tooling or libraries. It will decouple the NODE-ID definition from any earlier/other use of SAN URI. I can draft a modified TCPCL document for these changes.

Rick, you are correct that the current definitions can be used in some circumstances (the proof-of-concept implementation works fine with Node IDs such as "dtn://node-A/") can run into problems when node names fall outside of allowed DNS names (e.g. "dtn://_node_A/" or other disallowed DNS name characters "dtn://_&@/") tools can rightfully refuse to either issue or accept certificates with these SAN URIs.

On Mon, Aug 23, 2021 at 3:38 PM Rick Taylor <[e-mail]<mailto:[e-mail]>> wrote:
Hi Brian, Ed,

I personally agree with the ACME Sec review...  I think subjectAltName is the wrong field to be using for Node-ID in the certificate, and using it definitely ties our hands with Naming and Addressing to only use Node-IDs (and by extension Endpoint IDs) that map to RFC3986 valid formats.

@Brian,  Can you suggest some replacement text for the 3rd paragraph of 4.4.1 that meet the ACME suggestion?

Everyone else, do you consider the change to use a different field/type in the certificate to be a change that requires returning TCPCLv4 to the WG.  Note that doing this will delay BPv7 and BPSec as they are all bound together.

With my chair hat on, I would suggest that the current text specifies the wrong field to use, rather than specifying something functionally incorrect.

Cheers,

Rick


From: dtn [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Birrane, Edward J.
Sent: 23 August 2021 17:12
To: Brian Sipos; R. Atkinson
Cc: Brian Sipos; [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] [EXT] Re: Important side issues from ACME Node ID Validation draft

Brian,

  If I am reading the TCPCLv4 document correctly (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26) then the NODE-ID is optional, and instead a DNS-ID/IPADDR-ID may be used.

  If the bundle EID scheme (there may be more than dtn://) does not map cleanly to a fully qualified domain name or IP address, my intuition is that the DNS-ID/IPADDR-ID construct would need to be used instead.

  Since this is a TCP convergence layer, we already need to map a domain name or an IP Address anyway.

  If that is the correct interpretation, it may be useful to strengthen the wording in the draft, but I don’t think we need a technical change.

  Am I missing something here?

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his) Embedded Applications Group Supervisor Space Exploration Sector Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Brian Sipos
Sent: Friday, August 20, 2021 3:36 PM
To: R. Atkinson <[e-mail]<mailto:[e-mail]>>
Cc: Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXT] Re: [dtn] Important side issues from ACME Node ID Validation draft

APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before clicking links or attachments

All,
After further discussion in the ACME WG (security area), based on a need to avoid the requirements on DNS-name/IP-address and to avoid both valid and invalid assumptions made by tools/libraries about SAN URI contents, the strong recommendation is to avoid the SAN uniformResourceIdentifier entirely in favor of a new SAN otherName type-id OID which is used just for DTN EID (and thus Node ID) claims.

Unfortunately, this would require editing of a portion of the TCPCLv4 draft now in the RFC editors queue, and a new IANA registration for the OID under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [6]. Is this late edit an acceptable path for the document?
It would avoid many potential interoperability issues that were brought up in the ACME discussion and require only slight change to a DTN implementation to use a different SAN type (but identically encoded value).

[6] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

On Wed, Aug 11, 2021 at 11:20 AM R. Atkinson <[e-mail]<mailto:[e-mail]>> wrote:


> On Jul 26, 2021, at 21:04, Brian Sipos <[e-mail]<mailto:[e-mail]>> wrote:
>
> The second issue is unfortunately more technical; the "dtn" URI scheme has been set in stone and is already in use, but the PKIX profile in [4] specifically requires that when any SAN URI which includes an authority part (the "dtn" scheme does, it is the node name) that authority is either a DNS name or IP address. And we know that a Node ID is _not_ going to contain a network-level name but some other name. This technically breaks the profile in [5] as well as [2], which both use SAN URI as Node ID authentication. Because neither RFC5280 nor RFC6125 require to dereference the SAN URI and the DTN PKIX profiles explicitly avoid the URI-ID definition of RFC6125, the only risk is really that some application may inadvertently try to DNS probe the node name (or something like that). I don't yet know how much of a blocking issue this will be, and it's unfortunate that it wasn't noticed earlier.

Brian,

DNS Operations folks consider “noise” DNS queries (such as an application trying to use DNS to resolve the node name or something similar) to be a significant operational challenge — because the volume of “noise” DNS queries already is high.

I imagine the DNS Operations folks would be greatly unhappy at the prospect of the DTN URI scheme being the cause of additional “noise” DNS queries.

A prospective change would be to update the PKIX profile in [4] to make clear that a dtn URI is neither a DNS name nor an IP address - ever.

In short, this looks like a real-world operational problem that will need _some_ form of solution, even if different from the prospective change I outlined just above.

Yours,

Ran

_______________________________________________
dtn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn