Subject: Re: [OAUTH-WG] authz code randomness (was: single use authorization codes)

From: Brian Campbell <[email-masked]>
Date: Thu, 15 Jul 2010 08:22:50 -0600

I agree it's important but it belong in security considerations or
perhaps somewhere in the definition of the Authorization Code itself?

Either way here's some text that could be used as a starting point.  I
borrowed heavily from concepts and language in SAML regarding
artifacts and IDs which bear many similarities (artifacts especially)
to authorization codes.

    The Authorization Code value MUST be constructed from
    a cryptographically strong random or pseudo-random number
    sequence [RFC1750] generated by the Authorization Server.
    The probability of any two Authorization Code values being
    identical MUST be less than or equal to 2^(-128) and SHOULD
    be less than or equal to 2^(-160).

Also perhaps there should be a suggestion or requirement on the
maximum size of the code as well?

-Brian

On Thu, Jul 15, 2010 at 1:23 AM, Igor Faynberg
<[email-masked]> wrote:
> An important point, which I think should be captured in the security
> consideration section.
>
> Igor
>
> Torsten Lodderstedt wrote:
>>
>> what about guessing/brute force attacks on the code? Supposed an
>> authorization server issuing tokens for a client w/o secret. Then the number
>> of attempts needed to obtain a token issued to that client only depends on
>> the length and randomness of the code. Should the spec state something about
>> that?
>>
>> regards,
>> Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Jul 2010 19:06:59 +0200

sounds really good.

+1 for adding this to the authorization code's specification.

Am 15.07.2010 16:22, schrieb Brian Campbell:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Eaton <[email-masked]>
Date: Thu, 15 Jul 2010 10:39:09 -0700

>    be less than or equal to 2^(-160).

Does that text preclude using stateless authorization code implementations?

Authorization codes are issued frequently and change rapidly, so I am
very interested in supporting stateless implementations.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 15 Jul 2010 15:16:19 -0600

As written it probably does preclude that but I'm sure we could
massage it to be more flexible while still keeping the intent that the
code isn't something that can be easily guessed or is likely to
collide.

I must admit to never having considered the authz code as anything but
a random string as a reference that must be resolved.  Can you expand
on your thinking a bit, if only to enlighten me?

Are you thinking of embedding what would be the entire access token
response to the eventual authorization_code grant type request inside
the access token itself and encrypting and/or singing it?

---

From: Brian Eaton <[email-masked]>
Date: Thu, 15 Jul 2010 14:30:08 -0700

> the access token itself and encrypting and/or singing it?

Yes.

The oauth2 authorization code and the SAML artifact are similar in
that they end up creating this pattern:

user in location A creates some value
value is transferred to location B
server in location B resolves value
value expires

If A and B are geographically distant, you end up having to replicate
rapidly changing state.  that's expensive, and not terribly useful.

If you use a stateless implementation (e.g. authorization code is a
signed blob containing the client-id, the user-id, the list of scopes
granted, a timestamp, and a hash of the callback URL) things are much
more efficient.  The code is a bit longer.

Cheers,
Brian

---

From: Brian Campbell <[email-masked]>
Date: Thu, 15 Jul 2010 17:04:43 -0600

Okay, I'm with you.  Some text guiding the more obvious (to me anyway)
usage might still be useful.   Something like,

"If Authorization Code value is a reference to state on the server,
the value MUST/SHOULD be constructed from a cryptographically strong
random or pseudo-random number sequence [RFC1750] where the
probability of two Authorization Code values being identical is less
than or equal to 2^(-160)."

It's not as clean the previous text but still maybe useful.

I'm guessing you don't want any language restricting the length of the
code?  Though there is some practical limit due to the URL length in
the 302 (I think it has to be a redirect).

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Jul 2010 16:07:07 -0700

No normative language needed. Security consideration is the right approach. 

EHL

---

From: Brian Eaton <[email-masked]>
Date: Thu, 15 Jul 2010 16:36:14 -0700

> the 302 (I think it has to be a redirect).

There are certain practical limits, but I think there is still blood
on the specification from the last time normative language was
discussed.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 15 Jul 2010 21:03:09 -0600

> on the specification from the last time normative language was

That must have been been before my time - sorry for bringing it up
again.  We can put those skeletons back in the closet and move on.