Subject: [Acme] Entropy requirement for challenge token

From: Zach Shepherd <[email-masked]>
Date: Wed, 22 Mar 2017 05:12:45 +0000

The following feedback is based on 8010a31 (current HEAD of master).

Section 6.2, Request Authentication, states "Note that authentication via signed JWS request bodies implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification."

Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and 8.4, DNS, each describe a GET request and specify a "token" value which "MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it."

This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

Assuming secrecy of the token is not important, I would propose removing the entropy requirement and including some discussion of the token in Section 10, Security Considerations.

Regards,
Zach Shepherd

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 22 Mar 2017 13:30:11 -0400

Hi Zach,

> This seems incongruous. If the token must be kept secret an attacker, it
> should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this the other
week until it was clarified for me by Jacob.

The token is random not to prevent a guessing attack but to prevent the
implementation of a server that can automatically reply to challenges
without being a party to the authorization creation (e.g. knowing the
token). It's OK for the token to be served via an unauthenticated channel,
it just can't be predictable.

I took a crack at rewording this in
https://github.com/ietf-wg-acme/acme/pull/284 - Hopefully if I'm completely
off-base someone can correct it to be accurate & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <[email-masked]> wrote:

> Section 6.2, Request Authentication, states "Note that authentication via
> signed JWS request bodies implies that GET requests are not authenticated.
> Servers MUST NOT respond to GET requests for resources that might be
> considered sensitive. Account resources are the only sensitive resources
> defined in this specification."
>
> Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS SNI); and
> 8.4, DNS, each describe a GET request and specify a "token" value which
> "MUST have at least 128 bits of entropy, in order to prevent an attacker
> from guessing it."
>
> This seems incongruous. If the token must be kept secret an attacker, it
> should not be served via an unauthenticated channel.
>
> Assuming secrecy of the token is not important, I would propose removing
> the entropy requirement and including some discussion of the token in
> Section 10, Security Considerations.
>
> Regards,
> Zach Shepherd
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Zach Shepherd <[email-masked]>
Date: Thu, 23 Mar 2017 17:34:28 +0000

It seems like the goal of this is to ensure that the ACME client is not able to control (or, perhaps, even influence) the choice of token and requiring that the token be sufficiently random is one way to achieve this. This prevents an attacker from "tricking" the ACME server into using a verification performed by the owner of an identifier as proof that the attacker controls the identifier.

Is this accurate? If so, it seems like some version of this explanation should be included in the Security Considerations section.

________________________________
From: Daniel McCarney <[email-masked]>
Sent: Wednesday, March 22, 2017 10:30 AM
To: Zach Shepherd
Cc: [email-masked]
Subject: Re: [Acme] Entropy requirement for challenge token

Hi Zach,

> This seems incongruous. If the token must be kept secret an attacker, it should not be served via an unauthenticated channel.

I agree the wording makes it incongruous, I was caught up on this the other week until it was clarified for me by Jacob.

The token is random not to prevent a guessing attack but to prevent the implementation of a server that can automatically reply to challenges without being a party to the authorization creation (e.g. knowing the token). It's OK for the token to be served via an unauthenticated channel, it just can't be predictable.

I took a crack at rewording this in https://github.com/ietf-wg-acme/acme/pull/284<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_284&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=-wsi8BGqTPZ2pJgly5Zek9hlFtTALxFUHGs27TMvg1s&s=_Tra8Ezjve5vo2ooWGFKPe2BHELn3kzY0WMkDBK3nLw&e=> - Hopefully if I'm completely off-base someone can correct it to be accurate & understandable.

On Wed, Mar 22, 2017 at 1:12 AM, Zach Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Zach Shepherd

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=-wsi8BGqTPZ2pJgly5Zek9hlFtTALxFUHGs27TMvg1s&s=aKavTfL1kLx6wAvRKcSMGq_FwERH4NCW4EQ--ipFWts&e=>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 23 Mar 2017 12:24:20 -0700

Yep, I think there are two ways of thinking about this, though it's
effectively a single problem:

 1. Prevent attackers from tricking a validation endpoint into serving a
valid challenge response.
 2. Prevent ACME clients from implementing a "naive" validation method
that would make (1) trivial.

I think Daniel's change at
https://github.com/ietf-wg-acme/acme/pull/284/files is a nice quick fix
to the issue, but I agree it could use a few extra sentences explaining
it in security considerations.

On 03/23/2017 10:34 AM, Zach Shepherd wrote:
>
> It seems like the goal of this is to ensure that the ACME client is
> not able to control (or, perhaps, even influence) the choice of token
> and requiring that the token be sufficiently random is one way to
> achieve this. This prevents an attacker from "tricking" the ACME
> server into using a verification performed by the owner of an
> identifier as proof that the attacker controls the identifier.
>
>
> Is this accurate? If so, it seems like some version of this
> explanation should be included in the Security Considerations section.
>
>
> ------------------------------------------------------------------------
> *From:* Daniel McCarney <[email-masked]>
> *Sent:* Wednesday, March 22, 2017 10:30 AM
> *To:* Zach Shepherd
> *Cc:* [email-masked]
> *Subject:* Re: [Acme] Entropy requirement for challenge token
>  
> Hi Zach,
>
>     > This seems incongruous. If the token must be kept secret an
>     attacker, it should not be served via an unauthenticated channel.
>
>
> I agree the wording makes it incongruous, I was caught up on this the
> other week until it was clarified for me by Jacob.
>
> The token is random not to prevent a guessing attack but to prevent
> the implementation of a server that can automatically reply to
> challenges without being a party to the authorization creation (e.g.
> knowing the token). It's OK for the token to be served via an
> unauthenticated channel, it just can't be predictable.
>
> I took a crack at rewording this
> in https://github.com/ietf-wg-acme/acme/pull/284
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_284&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=-wsi8BGqTPZ2pJgly5Zek9hlFtTALxFUHGs27TMvg1s&s=_Tra8Ezjve5vo2ooWGFKPe2BHELn3kzY0WMkDBK3nLw&e=>
> - Hopefully if I'm completely off-base someone can correct it to be
> accurate & understandable.
>
>     Section 6.2, Request Authentication, states "Note that
>     authentication via signed JWS request bodies implies that GET
>     requests are not authenticated. Servers MUST NOT respond to GET
>     requests for resources that might be considered sensitive. Account
>     resources are the only sensitive resources defined in this
>     specification."
>
>     Sections 8.2, HTTP; 8.3, TLS with Server Name Indication (TLS
>     SNI); and 8.4, DNS, each describe a GET request and specify a
>     "token" value which "MUST have at least 128 bits of entropy, in
>     order to prevent an attacker from guessing it."
>
>     This seems incongruous. If the token must be kept secret an
>     attacker, it should not be served via an unauthenticated channel.
>
>     Assuming secrecy of the token is not important, I would propose
>     removing the entropy requirement and including some discussion of
>     the token in Section 10, Security Considerations.
>
>     Regards,
>     Zach Shepherd
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=-wsi8BGqTPZ2pJgly5Zek9hlFtTALxFUHGs27TMvg1s&s=aKavTfL1kLx6wAvRKcSMGq_FwERH4NCW4EQ--ipFWts&e=>
>
>
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 28 Mar 2017 17:30:13 -0400

>
> I think Daniel's change at https://github.com/ietf-wg-
> acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it
> could use a few extra sentences explaining it in security considerations.

I will take a crack at amending this PR with a few sentences in the
security considerations section.

On Thu, Mar 23, 2017 at 3:24 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> I think Daniel's change at https://github.com/ietf-wg-
> acme/acme/pull/284/files is a nice quick fix to the issue, but I agree it
> could use a few extra sentences explaining it in security considerations.
>
>
> It seems like the goal of this is to ensure that the ACME client is not
> able to control (or, perhaps, even influence) the choice of token and requiring
> that the token be sufficiently random is one way to achieve this. This
> prevents an attacker from "tricking" the ACME server into using a
> verification performed by the owner of an identifier as proof that the
> attacker controls the identifier.
>
> Is this accurate? If so, it seems like some version of this explanation
> should be included in the Security Considerations section.
>
> ------------------------------
> *From:* Daniel McCarney <[email-masked]> <[email-masked]>
> I took a crack at rewording this in https://github.com/ietf-wg-
> acme/acme/pull/284
> Acme mailing [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 29 Mar 2017 14:59:39 -0400

Updated #284 to clarify the token entropy requirement in the security
considerations section. Thanks for the feedback.

On Tue, Mar 28, 2017 at 5:30 PM, Daniel McCarney <[email-masked]>
wrote:

>> acme/acme/pull/284/files is a nice quick fix to the issue, but I agree
>> it could use a few extra sentences explaining it in security considerations.
>
>
>> I think Daniel's change at https://github.com/ietf-wg-acm
>> e/acme/pull/284/files is a nice quick fix to the issue, but I agree it
>> > This seems incongruous. If the token must be kept secret an attacker,
>>> it should not be served via an unauthenticated channel.
>>
>>
>>> Section 6.2, Request Authentication, states "Note that authentication
>>> via signed JWS request bodies implies that GET requests are not
>>> authenticated. Servers MUST NOT respond to GET requests for resources that
>>> might be considered sensitive. Account resources are the only sensitive
>>> resources defined in this specification."
>>>