John, It makes perfect sense to add client_id and verification as you've described, since unlike 1.0, client secrets and signatures are not required in 2.0. Still, if a public client is a big high-volume website that talks to a big authorization server (e.g. Yahoo to FB), having a good entropy (at least 128 bits) is a good idea.
Another good idea would be to make a provision in a spec that would say that most likely the entropy will increase in the future OAuth versions. It would help implementers to make their systems (both clients and authz servers) more flexible and avoid 2K like effects in the future. Just think about fast opinion change about the "safe" symmetric key entropy in SSL for the last 15 years. That opinion was changing so fast that some privacy/compliance officers could not catch up with that pace and continued writing in their official privacy policies something like that: "your private information is protected in transition by SSL with a strong 56-bit encryption" in which cases I had to get back to them asking to remove number of bits from the policy to make it more universal and durable :) --- On Fri, 11/2/12, John Bradley <ve7...@ve7jtb.com> wrote: From: John Bradley <ve7...@ve7jtb.com> Subject: Re: [OAUTH-WG] OAuth token entropy To: o...@gryb.info Cc: "oauth" <oauth@ietf.org> Date: Friday, November 2, 2012, 5:40 PM The change we did to the last ish draft of OAuth to have the client send its client ID to the token endpoint even if it is not using a password reduces the need for additional entropy. Originally for public clients using code, an attacker had the address space of all the inflight codes for all clients. We reduced that to only being able to attack one client_id at a time. For confidential clients it should not be possible to brute force the token endpoint. Trying to explain all the issues is hard so those are not bad defaults, 128 bits is a 20 character character password using the printable ascii character set for out of band code delivery. John B. On 2012-11-02, at 3:58 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote: Thanks, Brian. "Must" for 128 bits makes perfect sense. 160 bits looks good as a recommended entropy as well. WG, Please update the doc. It's important to provide clear guidelines for OAuth implementers, which are many nowadays. --- On Fri, 11/2/12, Brian Campbell <bcampb...@pingidentity.com> wrote: From: Brian Campbell <bcampb...@pingidentity.com> Subject: Re: [OAUTH-WG] OAuth token entropy To: "Oleg Gryb" <o...@gryb.info> Cc: "Torsten Lodderstedt" <tors...@lodderstedt.net>, "oauth" <oauth@ietf.org> Date: Friday, November 2, 2012, 2:19 PM I believe the original text (which was borrowed from elsewhere) had a must followed by a should rather than two shoulds like that. The text seems to have drifted a bit in various places but the threat model text should probably be aligned with what's in core OAuth at http://tools.ietf.org/html/rfc6749#section-10.10 On Fri, Nov 2, 2012 at 10:16 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote: Can somebody please provide clarification for this: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2 5.1.4.2.2. High entropy of secrets... The probability of any two Authorization Code values being identical should be less than or equal to 2^(-128) and should be less than or equal to 2^(-160). Is there any reason why we have two inclusive conditions in this statement or is it a typo and you meant something else? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
