Yes Torsten, I believe the consensus we ended up out of that last discussion was that the spec and associated security considerations should be written in such a way as to allow for either approach.
On Fri, Oct 1, 2010 at 10:55 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
