Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (3880)

[John Bradley <[e-mail]>]

It is true that a AS cannot tell what instance of a native client it is issuing a token to via the redirect URI.

10.16 is only talking about an attack on the client based on a lack of audience information. 

If there is a security consideration around AS differentiating between instances of public clients that should be documented separately.
It might be possible using dynamic registration to give each instance of a client a separate client_id but I don't think that is manageable if the AS needs to maintain state for each client_id.

Depending on the threat we are trying to mitigate using the forthcoming Proof of Possession spec to bind tokens to specific client instances may be a solution.

I think the issues need to be kept separate.

John B.


On Feb 4, 2014, at 3:50 PM, Prateek Mishra <[e-mail]> wrote:

> Well, the proposed correction does point to a genuine security hazard
> 
> Specifically, when client instances share the same re-direct URI, typically mobile clients
> 
> this is independent of whether implicit or code flows are used
> 
> It is only injective clients - each of whose instances bind to unique redirect URLs - that can support discriminative Az servers
> 
> So I would re-phrase the proposed text as:
> 
> [quote]
> For public, non-injective clients, this specification does not
> provide any method for the authorization server to determine what
> client an access token was issued to.
> [\quote]
> 
> - prateek
> 
> 
>> The text in 10.16 is correct.
>> 
>> This is a security consideration that has caused serious problems for Facebook and other implementers.
>> 
>> In the Implicit flow there is no way for a client to know if a access token was issued to it or another client.
>> 
>> The UA presenting the access token in an implicit flow may be the resource owner but may also be any other client that has ever received an access token for the resource.
>> 
>> In the implicit flow the Authorization server knows what client it has issued a access token to via the registered redirect URI.
>> 
>> The change doesn't reflect the intent of the security consideration.
>> 
>> John B.
>> 
>> 
>> On Feb 4, 2014, at 1:13 PM, RFC Errata System <[e-mail]> wrote:
>> 
>>> The following errata report has been submitted for RFC6749,
>>> "The OAuth 2.0 Authorization Framework".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=3880
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Eriksen Costa <[e-mail]>
>>> 
>>> Section: 10.16
>>> 
>>> Original Text
>>> -------------
>>> For public clients using implicit flows, this specification does not
>>> provide any method for the client to determine what client an access
>>> token was issued to.
>>> 
>>> Corrected Text
>>> --------------
>>> For public clients using implicit flows, this specification does not
>>> provide any method for the authorization server to determine what
>>> client an access token was issued to.
>>> 
>>> Notes
>>> -----
>>> A client can only know about tokens issued to it and not for other clients.
>>> 
>>> Instructions:
>>> -------------
>>> This errata is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --------------------------------------
>>> RFC6749 (draft-ietf-oauth-v2-31)
>>> --------------------------------------
>>> Title               : The OAuth 2.0 Authorization Framework
>>> Publication Date    : October 2012
>>> Author(s)           : D. Hardt, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : Web Authorization Protocol
>>> Area                : Security
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>