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 protected]> 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. > > > 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 protected]> > wrote: > >> 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-acm >> e/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]> <[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]> >> 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] >>> 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 [email protected]https://www.ietf.org/mailman/listinfo/acme >> >> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
