Hi Tianyu Zhang, Thanks for this proposal.
It would be helpful if we could back up a step: What types of attacks are you trying to mitigate here? The mechanism you describe here is very generic; anything at all could go in the newClientAuthz challenges. What sorts of properties of the client might the CA want to verify? What sorts of challenges allow the CA to verify those properties? For example, there have been proposals in the past for a CA to be able to require a client to complete an OAuth flow [1]. Is that something like what you have in mind? It would also be helpful to understand how your proposal relates to existing ACME mechanisms. For example, the external account binding facility [2] allows a CA to require that the client hold an external account -- and the external account could come with arbitrary extra requirements. Why is it difficult / impossible to address the attacks you're concerned about with existing mechanisms? Best, --Richard [1] https://www.ietf.org/archive/id/draft-biggs-acme-sso-01.html [2] https://rfcs.online/rfcs/rfc8555.html#section-7.3.4 On Tue, Jan 7, 2025 at 6:55 PM <zhangt...@mails.tsinghua.edu.cn> wrote: > Dear IETF ACME Working Group, > > I hope this message finds you well. > > I recently reviewed the attack model discussed in Section 11.1 of RFC > 8555, specifically regarding the consequences of compromising an ACME > account’s private key. In light of these concerns, I would like to propose > *ACME++*, an enhancement to the ACME protocol designed to prevent > attackers from issuing fraudulent certificates. Below, I provide an brief > overview of the key components of ACME++ and its protocol design. > > *1. Client Authz Object* > > ACME++ introduces enhanced client verification mechanisms, with a primary > focus on the *Client Authz* object. This object serves as a unique > verification token that binds an ACME client to a specific account. It > combines the client’s IP address and a client-generated ID, helping to > distinguish legitimate clients from potential attackers, while making the > system more resilient to brute-force and other types of attacks. > > *Client Authz Object Fields:* > > *Field Name* > > *Description* > > status > > Current verification status of the identifier. > > expires > > Current verification expiration time. > > identifier > > Unique identifier consisting of the client’s IP address and > client-generated ID. > > challenges > > A list of ACME *Challenge* objects for client verification. > > *2. newClientAuthz Directory Service* > > ACME++ introduces a new endpoint, *newClientAuthz*, as part of the CA > server *Directory* services. The client can send a POST-as-GET request to > /acme/client-authz/<authz_id> to access the *Client Authz* object. The > client can then complete the challenges in the object using HTTP-01 or > DNS-01 challenge types. Upon successful completion of all challenges, the > client is verified, and the CA updates the *Client Authz* object status > to "valid," allowing the CA to proceed with certificate issuance. > > *3. ACME++ Protocol Workflow* > > The ACME++ protocol workflow can be summarized as follows: > > 1. The ACME client initiates a newOrder request, including its IP > address, self-generated client ID, ACME account key, and Account UID in the > request to the CA server. > 2. The CA performs two verification steps: > - It checks whether the client’s communication IP matches the > submitted IP address. > - It verifies the existence of a valid *Client Authz* record for > the client. > > If both conditions are met, the CA proceeds with certificate issuance > according to the standard ACME protocol. If the IP addresses do not match, > the CA terminates the connection, as this may indicate a compromised ACME > account. If no valid *Client Authz* record exists, the CA generates a new > *Client > Authz* object for the client, assigns it a "pending" status, and returns > the object ID along with challenges to the client. > > The challenge generation follows a structured approach: the CA retrieves > all valid *Authz* records associated with the account and randomly > selects a few (in logarithmic scale) to create new challenges, which the > client must complete to re-validate domain ownership. > > > > I hope that ACME++ can provide an additional layer of security for > ACME-based certificate management, helping to mitigate potential attacks > while streamlining the verification process for legitimate clients. I would > greatly appreciate any feedback or suggestions the Working Group might have > regarding this proposal. > > Thank you for your attention to this matter. I look forward to your > thoughts. > > Best regards, > Tianyu Zhang > Tsinghua University > > > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
