Subject: [OAUTH-WG] single use authorization codes

From: Brian Eaton <[email-masked]>
Date: Tue, 13 Jul 2010 21:11:46 -0700

Draft 10 currently requires that the authorization code issued for the
web-app profile is a single use token.  That won't scale well.

This got added in draft 4, I'm not sure why.  Anybody know...?

Here's the relevant section:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3

"The authorization code SHOULD expire shortly after it is issued.  The
authorization server MUST invalidate the authorization code after a
single usage."

I think better language would be something like this:

"Under normal circumstances, clients will use the authorization code
immediately after receiving a redirect from the Authorization Server.
Authorization codes SHOULD expire shortly after they are issued to
minimize the risk of leaks.  Clients MUST NOT reuse verification
codes.  Authorization servers MAY make authorization codes single use
tokens.  If an Authorization Server detects multiple attempts to
exchange a single verification code for an access token, the
verification code may have leaked.  The Authorization Server MAY
revoke all tokens previously issued based on that verification code."

Justification...

"Authorization servers MAY make authorization codes single use
tokens": this is not a MUST because single use tokens are expensive
and slow to implement.  They require synchronous replication of
server-side state.  Because the oauth client and the user who approved
the request may be in geographically distant locations, this is pretty
much guaranteed to be either slow, or unreliable, or both.  When
things like immediate mode with automatic authorization are used, lots
and lots verification codes are going to be issued for no good reason.
 Server-side storage for those tokens is wasteful, so people are going
to end up using cryptographic implementations of verification codes.

"The authorization code SHOULD expire shortly after it is issued":
this is a good idea because we are passing authorization tokens via
browser redirects, and browser redirects are leaky channels.  If one
of these tokens leaks, someone who captures the token can replay it to
the client web site, and the client web site will then happily swap
the code for an access token.  The client web site will then associate
the victim's access token with the attacker's account.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 21:26:04 -0700

How about:

Authorization codes SHOULD expire shortly after they are issued to
minimize the risk of leaks.  Clients MUST NOT reuse authorization
codes.  If an authorization code is used more than once, the authorization
server SHOULD revoke all tokens previously issued based on that authorization
code.

EHL

On 7/13/10 9:11 PM, "Brian Eaton" <[email-masked]> wrote:

Justification...

Cheers,
Brian
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Eaton <[email-masked]>
Date: Tue, 13 Jul 2010 21:32:43 -0700

I'd suggest "authorization server MAY revoke all tokens".

Revoking an access token that was just issued is surprisingly tricky.
Fast to verify, easy to revoke, scalable: pick two.

---

From: "William Mills" <[email-masked]>
Date: Tue, 13 Jul 2010 21:40:54 -0700

That's even worse I think, it's a harder problem.  Why do we want to
revoke previously issued tokens here?  It closes one door but opens a
DOS attack.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eran Hammer-Lahav
	Sent: Tuesday, July 13, 2010 9:26 PM
	To: Brian Eaton; OAuth WG
	Subject: Re: [OAUTH-WG] single use authorization codes

	How about:
	
	Authorization codes SHOULD expire shortly after they are issued
to
	minimize the risk of leaks.  Clients MUST NOT reuse
authorization
	codes.  If an authorization code is used more than once, the
authorization
	server SHOULD revoke all tokens previously issued based on that
authorization
	code.
	
	EHL

		Draft 10 currently requires that the authorization code
issued for the
		web-app profile is a single use token.  That won't scale
well.
		
		This got added in draft 4, I'm not sure why.  Anybody
know...?

		
		"The authorization code SHOULD expire shortly after it
is issued.  The
		authorization server MUST invalidate the authorization
code after a
		single usage."

		"Under normal circumstances, clients will use the
authorization code
		immediately after receiving a redirect from the
Authorization Server.
		Authorization codes SHOULD expire shortly after they are
issued to
		minimize the risk of leaks.  Clients MUST NOT reuse
verification
		codes.  Authorization servers MAY make authorization
codes single use
		tokens.  If an Authorization Server detects multiple
attempts to
		exchange a single verification code for an access token,
the
		verification code may have leaked.  The Authorization
Server MAY
		revoke all tokens previously issued based on that
verification code."
		
		Justification...
		
		"Authorization servers MAY make authorization codes
single use
		tokens": this is not a MUST because single use tokens
are expensive
		and slow to implement.  They require synchronous
replication of
		server-side state.  Because the oauth client and the
user who approved
		the request may be in geographically distant locations,
this is pretty
		much guaranteed to be either slow, or unreliable, or
both.  When
		things like immediate mode with automatic authorization
are used, lots
		and lots verification codes are going to be issued for
no good reason.
		 Server-side storage for those tokens is wasteful, so
people are going
		to end up using cryptographic implementations of
verification codes.
		
		"The authorization code SHOULD expire shortly after it
is issued":
		this is a good idea because we are passing authorization
tokens via
		browser redirects, and browser redirects are leaky
channels.  If one
		of these tokens leaks, someone who captures the token
can replay it to
		the client web site, and the client web site will then
happily swap
		the code for an access token.  The client web site will
then associate
		the victim's access token with the attacker's account.
		
		Cheers,
		Brian

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 09:40:15 -0700

On Tue, Jul 13, 2010 at 9:40 PM, William Mills <[email-masked]> wrote:
> That's even worse I think, it's a harder problem.

Revoking previously issued refresh tokens is pretty easy.

Revoking the corresponding access tokens is hard in general, but in
some environments is feasible.

> Why do we want to revoke previously issued tokens here?

The threat model is an attacker who somehow grabs a verification code
from a user on the fly, then races to be the first one to exchange the
verification code with the authorization server.  The idea is to make
sure that if there is a race, the attacker always loses eventually.

This is sort of a remote scenario, though.  In practice if
verification codes leak, we're going to have trouble keeping the
protocol secure.

> It closes one door but opens a DOS attack.

What's the DOS attack?

---

From: "William Mills" <[email-masked]>
Date: Wed, 14 Jul 2010 11:58:09 -0700

If I can see things go by on the fly I can submit the token late and
mess with the user by revoking their session.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 13:35:10 -0700

> mess with the user by revoking their session.

Meh.

If the best the attacker can do in those circumstances is DOS, we're
in good shape.

Bear in mind that if we do nothing, the attacker can probably get the
user's data.

---

From: "William Mills" <[email-masked]>
Date: Wed, 14 Jul 2010 14:28:54 -0700

We're trying to design around transport security with short expiration
and single use tokens.  SSL solves the problem 

> -----Original Message-----
> From: Brian Eaton [mailto:[email-masked]] 
> Sent: Wednesday, July 14, 2010 1:35 PM
> To: William Mills
> Cc: Eran Hammer-Lahav; OAuth WG
> If the best the attacker can do in those circumstances is 
> DOS, we're in good shape.
> 
> Bear in mind that if we do nothing, the attacker can probably 
> get the user's data.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 14 Jul 2010 23:44:58 +0200

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.

>>> If I can see things go by on the fly I can submit the token
>>>        
>> late and
>>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 14 Jul 2010 14:57:36 -0700

On Wed, Jul 14, 2010 at 2:28 PM, William Mills <[email-masked]> wrote:
> and single use tokens.  SSL solves the problem.

No, we're not, and no, it doesn't.

The issue here is not that tokens are sent over unencrypted channels,
or unauthenticated channels.

The issue here is that browsers make it hard for server A to pass
information through the client in such a way that only server B can
read the information.

I have some notes on the challenges here:
http://www.ietf.org/mail-archive/web/oauth/current/msg03662.html.

Cheers,
Brian

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 15 Jul 2010 03:23:40 -0400

An important point, which I think should be captured in the security 
consideration section.

Igor

Torsten Lodderstedt wrote:
> depends on the length and randomness of the code. Should the spec 
> state something about that?
>
> regards,
> Torsten.
>