[OAUTH-WG] specification of authorization code properties

PRATEEK MISHRA <prateek.mishra@oracle.com> Wed, 29 September 2010 23:34 UTC

Message-ID: <4CA3CCBE.80107@oracle.com>
Date: Wed, 29 Sep 2010 19:33:18 -0400
From: PRATEEK MISHRA <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DB9A2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] specification of authorization code properties
Precedence: list

I read through v10 from the perspective of an implementor, and it seemed 
to me that properties of generated authorization code and its treatment 
by various entities need to be called out explicitly as a 
counter-measure against various simple attacks.

I would also comment that the exchanges between the end-user, client and 
authorization endpoints, beginning with the issuance of an authorization 
code (in SAML 2.0 called a browser artifact) and terminating with the 
client obtaining an access token (in SAML 2.0 the RP obtaining a SAML 
assertion) essentially follow the SAML web browser artifact profile and 
are therefore open to all of the attacks that the SSTC considered for 
this protocol.

1) For example, given the current description it seems that perfectly 
reasonable for an end-user authorization endpoint to generate a sequence 
of increasing integers as an authorization code or always return a 
constant value for a request with a given (client_id, redirection_uri) 
pair of inputs. So this leads to the possibility of an adversary using 
some simple techniques to guess valid authorization codes and obtain an 
access token.

2) There is a need to articulate some of the minimum properties that an 
authorization code should possess. I understand that there is an attempt 
here to give maximum choice to implementors.

For example, the SAML 2.0 artifact format description includes the 
following language -

[quote]
The MessageHandle value is constructed from a cryptographically strong 
random or
pseudorandom number sequence [RFC1750] generated by the issuer. The 
sequence consists of
values of at least 16 bytes in size.
[\quote]


3) I am also puzzled by the discrepancy between the language used to 
describe the generation and use of an authorization code -

[quote - generation - p.18]
The authorization code
SHOULD expire shortly after it is issued. The authorization
server MUST invalidate the authorization code after a single
usage. The authorization code is bound to the client
identifier and redirection URI.
[\quote]

VS


[quote - use - p.23]
The authorization server MUST:
o Validate the client credentials (if present) and ensure they match
the authorization code.
o Verify that the authorization code and redirection URI are all
valid and match its stored association.
[\quote]


I dont understand how the authorization code is related to the client 
credentials, or what is meant by "valid" or the reference
to "stored association". Is there an assumption that authorization 
server has a stateful table of (authorization code, client id, 
redirection uri) values?
Shouldnt this test be limited to checking whether the authorization code 
is being used with the correct client identifier and redirection URI?

[OAUTH-WG] Next steps (draft timeline) Eran Hammer-Lahav
[OAUTH-WG] specification of authorization code pr… PRATEEK MISHRA
Re: [OAUTH-WG] specification of authorization cod… Torsten Lodderstedt
Re: [OAUTH-WG] Next steps (draft timeline) Torsten Lodderstedt
Re: [OAUTH-WG] Next steps (draft timeline) Eran Hammer-Lahav
Re: [OAUTH-WG] specification of authorization cod… PRATEEK MISHRA
Re: [OAUTH-WG] specification of authorization cod… Torsten Lodderstedt
Re: [OAUTH-WG] specification of authorization cod… Brian Campbell