Subject: Re: [Acme] draft-ietf-acme-dtnnodeid-07 issue

From: "Sipos, Brian J." <[email-masked]>
Date: Mon, 29 Nov 2021 13:29:54 +0000

All,

It appears that there is a logical issue in the current Node ID Validation
draft [1]; I had incorrectly assumed that the current three inputs of the
Key Authorization (token-chal, token-bundle, client account key thumbprint)
provide proof of access to both the validated BP channel and the ACME
channel. But I now realize that other validation methods can and do expose
the client account key thumbprint in the clear to eavesdroppers. So there is
actually not a guarantee that a Challenge Bundle is actually produced by the
real ACME client. An eavesdropper can observe the client account key
thumbprint from a different validation method, intercept a Challenge Bundle,
produce a proper key authorization digest, and send that in a Response
Bundle. All without the proper ACME client being involved.

I'm not sure that this represents an actual security issue, but it leaves
open a strange way for a validation to "succeed" without an ACME client
being involved and seems like a bad situation. This could be avoided in a
way similar to RFC 8823 does [3] by having one filterable unique token
provided to the ACME client (in RFC 8823 this is the "from" email address)
separate from a key-authorization-used-token delivered to the ACME client
only via the ACME channel (in RFC 8823 the "token-part2" text). Looking at
it this way, it seems like the "source" Node IDs in the Challenge Request
Object [1] really aren't necessary if an explicit per-challenge filter token
is provided instead (separate from the key-authorization-used-token also
provided in the same challenge). The filter token would be publicly visible
(in the bundle contents) but the key-authorization-used-token would be
private and available only to the correct ACME client.

I don't think this represents a major change to the workflow for this
validation method, it only removes the current double-purpose of the
"token-chal" value and separates it into client-side filter vs. the
key-authorization purposes.

Any feedback on the original or proposed changes are welcome,

Brian S.

[1] https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-07.html

[2] https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-dtnnodeid-03.txt

[3] https://www.rfc-editor.org/rfc/rfc8823.html