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 protected]> > *Sent:* Wednesday, March 22, 2017 10:30 AM > *To:* Zach Shepherd > *Cc:* [email protected] > *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 protected] > <mailto:[email protected]>> wrote: > > 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 > > > _______________________________________________ > Acme mailing list > [email protected] <mailto:[email protected]> > 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=> > > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
