Prateek,

as I remember previous discussions, both design options (self-contained short-living/one-time use tokens as well as random strings) shall be feasible. So your contribution would helpful anyway.

regards,
Torsten.

Am 01.10.2010 18:36, schrieb PRATEEK MISHRA:
Torsten,

Brain Campbell points out that previous discussions suggest that the authorization code is meant to be a cryptographically protected one-use token (vs. a random string) but that these
key (essential!) details are not available draft 10.

http://www.ietf.org/mail-archive/web/oauth/current/msg03885.html

I would say then that the analogy with the SAML Web SSO browser profile isn't exact but nevertheless some threats are common to both scenarios. I will try to summarize these once a concrete proposal for authorization code is made available by the authors.

- prateek
Thank you for your advice. The Oauth security considerations are not finished 
yet. They will handle the issues you raised, too.

Regards,
Torsten.


Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA<prateek.mis...@oracle.com>:

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to