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
