Hi Grace, With your thread model description, I’d like to add more points inline:
发件人: 吴攀雨 <wupany...@gmail.com> 发送时间: 2024年11月29日 23:20 收件人: Aaron Gable <aa...@letsencrypt.org> 抄送: IETF ACME <acme@ietf.org>; Q Misell <q...@as207960.net>; Mike Ounsworth <mike.ounswo...@entrust.com>; draft-geng-acme-public-key.auth...@ietf.org 主题: Re: [Acme] Re: 回复: [EXTERNAL] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge >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. [cid:image001.png@01DB44A3.C44DC270] 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. [Frank]: the above is specific thread model that adversary only take over the ACME client which play the roles of ACME proxy/client for the terminal/endpoint, so that he cannot cheat in the PoP process in the ACME challenge phase, but can cheap in the certificate application phase. And this is the easier case that can be mitigated by the consistency checking between the challenge phase and certificate application 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. [Frank]: this thread model description is not very clear. My understanding is that this case is when an adversary take over the terminal/endpoint, it then arbitrarily generates a public-private key pair on terminal, so that it can complete PoP in the challenge phase and completes the following certificate application phase. But with the whitelist mechanism in the IDP (pre-install or import the valid public key and then verify them), we still can mitigate this harder case. In summary, but combining the IDP public key whitelist and consistency checking between the 2 phases, we can mitigate all the mentioned attacks. 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. [Frank]: but still, the bad ACME client can only apply the certificate for the valid public key, if we adopt the IDP whitelist mechanism. My 2 cents. B.R. Frank [cid:image002.png@01DB44A3.C44DC270] Thanks, Grace Aaron Gable <aa...@letsencrypt.org<mailto:aa...@letsencrypt.org>> 于2024年11月28日周四 00:42写道： On Wed, Nov 27, 2024, 08:22 吴攀雨 <wupany...@gmail.com<mailto: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
