Re: [OAUTH-WG] specification of authorization code properties

[Brian Campbell <[e-mail]>]

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
<[e-mail]> 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 <[e-mail]>:
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>