Hi Ilari, Thanks for your comments, see our responses inline: -----邮件原件----- 发件人: ilariliusva...@welho.com <ilariliusva...@welho.com> 发送时间: 2024年11月25日 17:20 收件人: acme@ietf.org 主题: [Acme] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge
On Mon, Nov 25, 2024 at 03:11:21AM +0000, Xialiang(Frank, IP Security Standard) wrote: > Hi ACME experts, > We submitted and presented a new ACME paper at the IETF 121st meeting > -- https://datatracker.ietf.org/doc/draft-geng-acme-public-key/. > > This draft is about ACME Extension for Public Key Challenges: > basically, we think the current identity validation mechanism of ACME > check the ACME applicant’s control over the requested identity）needs > to consider some necessary extension in some specific use case (The > ACME proxy or ACME applicant itself is taken over by the adversary and > perform the public key replacement attack, result in the replacement > of the public key in the final CSR message and gain the control of the > real applicant’s identity). So, we propose a new ACME challenge type – > ACME public key challenge (pk-01, 3 types of identifier can be applied > with: pk, selfsign-cert and csr), together with IDP and known public > key authentication protocol (i.e., WebAuthn, Opaque/AKE, non- > interactive zero-knowledge (NIZK) discrete logarithm equality (DLEQ) > proof…). Through this extension, the public key authenticity, > consistency and mapping to the identity are all well checked and > protected. The goal of ACME is to be automated (the A even stands for "automated"). Flows involving browser (figure 1) do not look automated. [Frank]: Involving browsers doesn't mean not automated. For example, you can see ACME SSO draft (https://www.ietf.org/archive/id/draft-biggs-acme-sso-01.html). The main point here is about URL and IdP that ACME client is interacted with for the identity ownership validation. Secondly, proof of possession does not seem helpful countering public key replacement. The attacker controls the private half of the attack key, and can pass any proof of possesion for it. To actually prevent attacks like that, one would need authorization from domain for public keys. A long time ago I had an idea for using CAA records for such purpose. [Frank]: I agree that a straightforward PoP can not solve the public key replacement attack simply, so our propose is actually about authenticating ACME client's public key in the ACME challenge (with IdP) phase, and check and guarantee the public key in the CSR message is consistent with the previous phase. About CAA records mechanism, similar to your responses to Mr. Q. Misell, it is only for the domain name certificate issuance, not our case for the terminal/device certificate. However, having an identifier type for public keys could be useful. One could combine public key identifiers with profiles and order auto- finalize to simplify the protocol (parsing CSRs is not pleasant). Or to add strong key proof-of-possession (but that would cause problems with high-security environments that do not allow private key import/export). [Frank]: It's really simpler if we directly reuse the public key in certificate application phase after verifying it in challenge phase, avoiding parsing the CSR file. But we also think it undermines ACME's existing 3-phase decoupling framework (RFC8555). The decoupling design brings more benefits, including compatibility, easy expansion, and easy deployment. B.R. Frank -Ilari _______________________________________________ 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
