>Sorry, but this doesn't make sense to me. If the adversary is on the ACME client, then it doesn't matter that they don't have access to the keypair that the victim wants to include in the >certificate. The adversary can just generate their own keypair, create their own CSR, and complete any proof-of-possession challenges for that key -- because they do in fact possess it.
>It sounds to me like you're saying that these proof-of-possession challenges would only be able to be completed by someone who controls both the key *and* the domain in question. >This raises multiple questions in my mind: >- the ACME client does in fact control the domain in question, otherwise it wouldn't be able to complete normal domain control validation -- so what prevents it from being able to >complete these proof-of-possession challenges as well? >- ACME orders often contain multiple unrelated domains -- which of those domains is the one that gets tied to the key, and how is that communicated between the ACME client and >server? >- how do the challenge methods described by this draft ensure that an ACME client on a "proxy" is unable to complete them? -------------------------------------------------------------------------------------------------------------------------------------- Hi Aaron, Here I would like to refocus a point, our draft is mainly about issuing certificates to clients/terminals, especially within a corporate enterprise scenario, where an agent (network administrator) role is needed to request certificates for multiple clients/terminals. To recharacterize our threat modeling scenario, draw the following diagram for better understanding. The network administrator acts as an agent to request certificates for multiple end devices within the company. [image: image.png] In our threat model, the client/device holds its own public/private key pairs, and the ACME client only acts as a delegated agent role and does not possess any device private key. The ACME client in the figure uses the public key identity of terminal C to complete the proof-of-possession during the challenge interrogation phase. However, it replaces the public key identity when submitting the certificate application stage, but still tricks the CA into believing that it is issuing a certificate for terminal C. The adversary owns the corresponding private key of this certificate and realizes the effect of impersonating terminal C. Against this attack, our draft ensures the consistency of the two phases by verifying whether the public key information is the same in the certificate request submission phase and the challenge interrogation phase. Further, when an adversary arbitrarily generates a public-private key pair on the ACME client, completes proof-of-possession in the challenge interrogation phase and completes the certificate request. The attack can be mitigated by supplementing the above consistency check with a similar whitelisting mechanism. The public key identity is signed by the IDP and then handed over to the ACME server to verify whether the public key has the authority to apply, i.e., whether it is in the trusted list. This further enhances security and enables legitimacy verification. When the terminal is the thin client, the ACME client needs to generate a public-private key pair for the endpoint agent and import the issued certificate into the terminal. In this scenario it is reasonable to grant the ACME client to generate arbitrary public-private key pairs and request certificates, with a great deal of freedom. It is thus logical to ensure that ACME clients are honest and not attacked. [image: image.png] Thanks, Grace Aaron Gable <aa...@letsencrypt.org> 于2024年11月28日周四 00:42写道： > On Wed, Nov 27, 2024, 08:22 吴攀雨 <wupany...@gmail.com> wrote: > >> The main focus is on proxy scenarios where the adversary is on the ACME >> client and has access to the CSR file of another person's public key, but >> does not possess the private key corresponding to the public key of the >> certificate. Due to these risks, our proposed draft requires that the >> challenge needs to be completed at the final applicant and that the >> consistency between that submitted public key and the challenge >> interrogation phase be verified at the certificate application phase. >> > > Sorry, but this doesn't make sense to me. If the adversary is on the ACME > client, then it doesn't matter that they don't have access to the keypair > that the victim wants to include in the certificate. The adversary can just > generate their own keypair, create their own CSR, and complete any > proof-of-possession challenges for that key -- because they do in fact > possess it. > > It sounds to me like you're saying that these proof-of-possession > challenges would only be able to be completed by someone who controls both > the key *and* the domain in question. This raises multiple questions in my > mind: > - the ACME client does in fact control the domain in question, otherwise > it wouldn't be able to complete normal domain control validation -- so what > prevents it from being able to complete these proof-of-possession > challenges as well? > - ACME orders often contain multiple unrelated domains -- which of those > domains is the one that gets tied to the key, and how is that communicated > between the ACME client and server? > - how do the challenge methods described by this draft ensure that an ACME > client on a "proxy" is unable to complete them? > > Thanks, > Aaron > >>
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
