Subject: [OAUTH-WG] OAuth token entropy

From: Oleg Gryb <[email-masked]>
Date: Fri, 2 Nov 2012 09:16:46 -0700 (PDT)

Can somebody please provide clarification for this:
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.25.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?

---

From: Brian Campbell <[email-masked]>
Date: Fri, 2 Nov 2012 12:19:20 -0600

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 <[email-masked]> wrote:

>  <http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2> <http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2>http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.25.1.4.2.2 <http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-05#section-5.1.4.2.2>.  High entropy of secrets...
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Nov 2012 11:28:23 -0700 (PDT)

I believe the IESG wanted a higher level of entropy. It looks like the text may have gotten mangled along the way.  Torsten do you recall?

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-11-02, at 11:19 AM, Brian Campbell wrote:

> 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
> 
> 
> 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
> 
> ...

---

From: Oleg Gryb <[email-masked]>
Date: Fri, 2 Nov 2012 11:58:53 -0700 (PDT)

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 <[email-masked]> wrote:

From: Brian Campbell <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth token entropy
To: "Oleg Gryb" <[email-masked]>
Cc: "Torsten Lodderstedt" <[email-masked]>, "oauth" <[email-masked]>
Date: Friday, November 2, 2012, 2:19 PM

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).

OAuth mailing list

[email-masked]

---

From: John Bradley <[email-masked]>
Date: Fri, 2 Nov 2012 18:40:08 -0300

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.

---

From: Oleg Gryb <[email-masked]>
Date: Sun, 4 Nov 2012 09:41:37 -0800 (PST)

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 <[email-masked]> wrote:

From: John Bradley <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth token entropy
To: [email-masked]
Cc: "oauth" <[email-masked]>
Date: Friday, November 2, 2012, 5:40 PM

WG,

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

OAuth mailing list

[email-masked]