Paul, Thank you for your review and feedback. The situation that I see this experimental method being useful in is now explained more explicitly in new Section 1.5, and to me draws close analogies to both IP network access and the email validation of RFC 8823.
For the IP access case, there are interior transit networks and edge access networks and through delegation of IP address space edge networks can obtain blocks of addresses for which they have been delegated authority to control. It is up to each edge network to determine how to authorize use of any edge node address, which might involve things like IEEE 802.1x Port-based Network Access Control or 802.11i Wifi Protected Access. But any interior transit routers don't see those details, they only trust that the edge network has properly controlled the use of its allocated addresses. Similarly, the means by which an email edge message transfer agent (MTA) authenticates a message user agent (MUA) and authorizes access to a particular address is assumed and invisible to interior MTAs relaying messages from and to that address. There are plenty of mechanisms to do that access control via SMTP, POP, IMAP and their derivatives. Any interior MTAs must trust that the edge MTA has properly controlled the use of its mail domain. And there are mechanisms, such as DKIM of RFC 6376, for edge MTAs to vouch for its users to those interior MTAs. For BPv7 networks, sets of valid Node IDs can be similarly delegated to edge networks and left to each edge to determine how to authenticate and authorize edge nodes. This could include authentication and authorization at any under layer, including the same types of access control discussed above for IP network access or methods such as use of TLS within the TCPCLv4 of RFC 9174 which allows IP-based or DNS-name-based authentication and authorization to be used. Once an edge node is authorized to be able to access an edge network using a specific identity, the edge routers may add additional security to satisfy transit or interior network needs (which is discussed in Section 4 of the draft). But the analogy to IP and email address access still holds, I believe. All of that is separate from the on-path impersonation threat described in Section 6.2 of the draft, and maybe that section needs more explanation similar to the above. Even in cases where there was no integrity gateway and an interior network required no in-band, cryptographic integrity controls I think this experimental method is secure to on-path attack. The main requirement which mitigates an on-path attack is in Section 3.3 of the draft, which is that the Challenge Bundle from the ACME server shall have primary and payload integrity traced to the ACME server's BP node and trusted by the node-under-validation. This constraint might not be clear in the current text, and additional discussion in Section 4 or 6.2 could improve this. Even if a client's BP Agent ignored the security requirements on the Challenge Bundle, an on-path attacker would still not have access to the client's account key thumbprint or the server-supplied `token-chal` both necessary to generate the corresponding key authorization digest. If the attacker waits until the response bundle is sent and intercepts it, the worst the attacker can do is to drop the bundle and prevent the validation from succeeding. Any alteration there would cause the key auth. digest to fail to match and cause the validation to fail. Does any of this help out? Or suggest that more explanation (but not a change of behavior) is needed? Brian S. On Wed, Jun 4, 2025 at 9:01 PM Paul Wouters via Datatracker < [email protected]> wrote: > Paul Wouters has entered the following ballot position for > draft-ietf-acme-dtnnodeid-18: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am filing a ballot of Abstain, as I can't fully comprehend the security > model > of ACME issuing endpoint certificates through an insecure Bundle Protocol > based > network which is not end-to-end secure. The ACME protocol security is > bootstrapped by any ACME client being able to know that its content is only > readable by the ACME server, and visa versa. But that is not the case here. > > It is possible for intermediate BP nodes to > encapsulate-and-encrypt Challenge and/or Response Bundles while > they traverse untrusted networks, but that is a DTN configuration > matter outside of the scope of this document. > > Defining the lack of this core ACME requirement as out-of-scope kind of > confuses me as to what security guarantees ACME issued certificates offer. > Any > Intermediate BP node can get ACME certs issued for Node IDs behind it. So > what > does an ACME Node ID certificate really mean from a security point of view? > > > >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
