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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
