> Between these two options, I would be more attracted to the latter. It's
> always been a bit of a sore point that the request URI was not covered by the
> client's signature, but to avoid the complexity of URL comparison, we did the
> "resource" thing instead. But maybe it makes sense to include the whole URL
> after all.
>
> OLD: { "resource": "new-reg", ... }
> NEW: { "url": "https://example.com/acme/new-reg
> <https://example.com/acme/new-reg>", ... }
>
> Now that I look at that, there's one more additional property, in addition to
> mitigating issues (1) and (2) here. In cases where the server might have
> multiple ACME services running (e.g., for different CAs), it prevents a TLS
> MitM like a CDN from switching requests between them.
>
> Do folks have opinions on whether we should do this?
>
> I think channel binding, in the form discussed above, is a more elegant
> solution to this. IIUC, with channel binding, the token would implicitly tie
> in the server's identity, since it was issued in response to a request for
> that server.
I’ll plug this kind of binding into the model and run the analysis again.
Best,
Karthik
>
> Where server_id could be the ACME server’s SNI or certificate-hash.
> In other words, the domain validation challenge currently includes the
> client’s identity and the server’s challenge,
> but it does not include the server’s identity, allowing the challenge
> response to be used with multiple servers.
> This may well be a privacy feature (?) but if not then adding further context
> to the challenge response will add protection
> in the multiple CA use case
>
>
> Issue 3: Contact-based Recovery can be Hijacked
> -------------------------------------------------------------------
>
> The use of sender-authenticated channels in ACME (HTTPS/SNI/DNS) seems to be
> relatively secure.
> However, more attention needs to be paid to the receiver-authenticated
> channels like email, because they are
> easy to get wrong. For example, if the ACME server (in some future draft)
> uses the website administrator’s email
> address to send the domain validation token, a naive implementation of this
> kind of challenge would be vulnerable to attack.
>
> In the -01 specification, the contact channel (typically email) is used for
> account recovery
> when the ACME client has forgotten its account key. We show how the careless
> use of this channel can be vulnerable to attack, and propose a countermeasure.
>
> Suppose an ACME client C issues an account recovery request for account A
> with a new key K to the ACME server S.
> A network attacker blocks this request and instead sends his own account
> recovery request for account A (pretending to be C)
> with his own key K’. The server S will then send C an email asking to click
> on a link.
> C will think this is a request in response to its own account recovery
> request and will click on it.
> S will think that C has confirmed account recovery and will transfer the
> account A to the attacker’s key K’.
>
> In the above attack, the attacker did not need to compromise the contact
> channel (or for that matter, the ACME channel).
> This seems to directly contradict the security considerations in 9.3, unless
> I am reading something wrong.
> The key observation here is that on receiver-authenticated channels (e.g.
> email) the receiver does not get to
> bind the token provided by the server with its own account key. Consequently,
> we need to add further checks.
>
> The email sent from S to C should contain a fresh token + C’s new account key
> (e.g. within a key-authz field)
> Instead of clicking on the link (out-of-band), C should cut and paste the
> token into the ACME client which
> can first check that the account key provided by the server matches the one
> in the ACME client and only
> then does it send the token back to the server.
>
> Alternatively, if we don’t want to change ACME too much, we must require that
> the email recipient at C
> visually confirms that the account key (thumbprint) provided by the server
> matches the one displayed
> in the ACME client.
>
> The attack described here is on account recovery, but a similar attack
> appears if we allow email-based
> domain validation. A malicious ACME server or man-in-the-middle can then get
> certificate issued for C’s
> domains with its own public key, without compromising the contact/validation
> channel. The mitigation
> for that attack would be very similar to the one proposed above.
>
> Emails with clickable links are *BAD*; we should enhance their security by
> linking them better with
> the ACME account key.
>
>
> Proposal
> ---------------
>
> I notice that -02 has removed account recovery completely. I would recommend
> that we can
> include account recovery, by piggybacking on the account roll-over mechanism
> and using MACs
> instead of bearer tokens sent in emails.
>
> The proposal that came up in discussions with Richard Barnes is as follows.
>
> Currently, account roll-over does something like the following: It signs the
> roll-over request with the old key, where the request itself contains a
> signature of the old key with the new key.
> Note that it would be fine to flip the order of these signatures: It could
> sign the roll-over request with the new key, where the request itself
> contains a signature of the new key with the old key.
>
> We further observe that account recovery is a form of roll-over where you are
> expected to know a secret that has been delivered out-of-band.
> So, let’s assume that when the ACME client initiates account recovery, the
> server will somehow out-of-band authenticate the user’s request
> and issue the user with a MAC key (e.g. it may email a MAC key to the contact
> email address, but it would be better advised to ask the user some questions
> first.)
>
> Now, the ACME client can complete the account recovery by sending a message
> as follows: It signs the recovery request with a new account key, and the
> request itself
> contains a MAC of the new key with the recovery MAC key.
>
> To make this fully uniform with account roll-over, it would also be
> attractive to flip the order of signatures in the roll-over request, as
> described above, so that the outer
> signature is always with the new key, and the inner JWS is either a signature
> with the old account key or a MAC with the recovery key.
> account key, and the request itself contains a signature of the old key with
> the new key.
>
> I agree that this is worth doing. It's worth having some recovery mechanism
> in here to avoid CAs having to invent their own (and possibly introduce
> vulns). I would propose we do this in 2-3 pull requests:
>
> 1. Swap the order of the signatures in account key roll-over
>
> OLD: Sign(K_old_priv, Sign(K_new_priv, Fingerprint(K_old_pub)))
> NEW: Sign(K_new_priv, Sign(K_old_priv, Fingerprint(K_new_pub)))
>
> 2. Add a section on how to do account recovery if you have a recovery key
> provisioned, namely:
>
> NEW: Sign(K_new_priv, MAC(K_recovery, Fingerprint(K_new_pub)))
>
> (We can benefit from JWS's conflation of signature and MAC here.)
>
> 3. (Optional) Define a way to provision a client with a recovery key.
>
> I mark (3) as optional because neither of the options for how to do it are
> especially nice. On the one hand, if you do it in-band, then you have to add
> a lot of complexity to encrypt the recovery key so that only the client can
> read it (in order to keep it out of the hands of a TLS MitM). On the other
> hand, if you do it out-of-band, then you're vulnerable to hijacking via
> compromise of the contact channel. Between those two, my preference would be
> for the latter, just for simplicity, but I'm open to suggestions.
>
> --Richard
>
>
>
> Best,
> Karthik
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org <mailto:Acme@ietf.org>
> https://www.ietf.org/mailman/listinfo/acme
> <https://www.ietf.org/mailman/listinfo/acme>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
