Subject: [Acme] Challenge objects are provoking implementation mistakes

From: Sophie Herold <[email-masked]>
Date: Tue, 19 Dec 2017 12:10:35 +0100

Hi,

It is part of the ACME security model that clients use the key
authorizations they have computed themselves for fulfilling challenges.

However, Sections 7.1.4. and 7.1.5. give examples of the server
returning the keyAuthorization as part of the challenge object.

If the client follows the schema

1. fulfill challenge
2. POST challenge URL

it is unlikely that the keyAuthorization returned by the server would be
used to fulfill the challenge (again).

However, it should be possible to obtain a working ACME client by
POSTing to the challenge URL first and using the keyAuthorization
returned by the server (and possibly changed by the server) to fulfill
the challenge afterwards. This should work since the servers challenge
checks (DNS, HTTP, ...) are not instantaneous and even retried. In this
case the MitM protection is bypassed by incautious client implementation.

If my interpretation is correct, I would suggest that the server MUST
NOT return the keyAuthorization object. That would reduce the likelihood
that the client is using a keyAuthorization fields returned by the server.

Maybe it would be also worth pointing out that clients MUST use the
keyAuthorization they computed themselves. However, without context that
might become a confusing tautology.

One more thing: During client implementation I also started to wonder if
I should check the identifier values (i.e. domains) the server returns
in challenges. I don't see an immediate risk in fulfilling challenges
for arbitrary domains the server returns to the client. But maybe there
would be a security benefit in checking if the challenge identifiers
match (up to some sub-domain logic) the once passed to newOrder/newAuthz
originally or are 'managed by the client in general'.

This would be relevant if the client has access to a domains web- or
dns-server, but this domain should only use ACME with a different CA/JWK
or no ACME at all.

Best,
Sophie

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 20 Dec 2017 19:07:19 -0800

> case the MitM protection is bypassed by incautious client implementation.

This is a good point. The other potential issue is reliability: a client
the depends on the returned keyAuthorization rather than the one it
provided might appear to work for a while, then stop working if the
server started validating challenges more quickly.

I would support a change so that the server does not echo the
keyAuthorization. This brings up another question: Why have the client
include the keyAuthorization in the challenge POST at all? Both sides
can calculate it from scratch, the POST is essentially just "I'm ready
for validation now!" I think we originally included it because we
anticipated had other challenges where the client would be expected to
provide some secret token in the challenge response, or some proof of
control of a key, so including some payload (keyAuthorization) for the
other challenge types seemed stylistically consistent with that.
However, I don't think it's really necessary.

---

From: Sophie Herold <[email-masked]>
Date: Wed, 27 Dec 2017 14:35:42 +0100

Hi,

I have posted a PR that implements both changes (not expecting and not
returning the keyAuthorization) as basis for a discussion.

https://github.com/ietf-wg-acme/acme/pull/375

Notably, I think this should be backwards compatible for clients as far
as we want it to be. The redundant keyAuthorization would just be
ignored by the server.

Best,
Sophie

On 21/12/17 04:07, Jacob Hoffman-Andrews wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>