Re: [OAUTH-WG] [Unbearable] Scoping of keys on the client.

[John Bradley <[e-mail]>]

I used that as an example.  I know one AS that is doing that for refresh tokens as it doesn't require any client or protocol change.  

No the WG haven't discussed it.

The POP use case for AT is focused on app/client to RS.   Given that the AS and RS may not be in the same domain using token binding to secure the AT to the RS gets trickier.

In principal if the client knows the the URI of the resource server it could make a request to the RS and then take the public key and put it in a JWK to push to the AS as part of the existing POP key distribution spec. 

The client would then get back a AT bound to that key.

That limits the client to only using a single RS as tin the current spec the key is only exchanged for code.

The key could be sent with refresh tokens if we wanted to allow multiple RS with different keys, however to do that securely you really want to secure the refresh token, to do that in a public client the AS could use token binding.

Those are issues the OAuth WG will need to look at.   To do that properly knowing things like if the RT leaks to another app on the device can it still be used?  Those questions need to be answered to formulate security considerations, and determine if token binding is the correct tool to use for a given use case.


John B.


> On Mar 13, 2015, at 5:22 PM, Phil Hunt <[e-mail]> wrote:
> 
> Maybe I am recalling wrongly, but I don’t think OAuth WG discussed securing refresh tokens using binding (yet).  The OAuth POP use cases were focused on app-to-app access token security.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [e-mail]
> 
>> On Mar 13, 2015, at 12:58 PM, John Bradley <[e-mail]> wrote:
>> 
>> I think it is important to think through how the choices may impact how protocols can use token binding. 
>> 
>> The NAAPS profile of connect is a possible candidate for using token binding but that is highly dependent on how keys are shared on the client. 
>> 
>> A simple OAuth use case is using token binding to secure a refresh token.  
>> 
>> How secure that is would depend on what other apps on the device may be able to use that token if it leaked. 
>> 
>> Understanding how keys are shared between apps is I think important. 
>> 
>> John B
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Mar 13, 2015, at 2:46 PM, Phil Hunt <[e-mail]> wrote:
>>> 
>>> The problem being that this just becomes device binding and app to app token binding still isn't possible. 
>>> 
>>> Do we care?
>>> 
>>> Phil
>>> 
>>>> On Mar 13, 2015, at 10:18, Andrei Popov <[e-mail]> wrote:
>>>> 
>>>> Thanks for raising this topic John.
>>>> 
>>>>> I found some people that believe all apps sharing a common TLS library would be able to share the same ID/key for a origin.
>>>> In our prototypes so far (in Win10), the Token Binding Protocol implementation, the Token Binding key storage APIs, and the TLS library are three separate components. Among other things, this allows 3-rd-party apps share Token Binding keys and achieve single sign-on regardless of the TLS library they might be using (if they choose to do so).
>>>> 
>>>>> The different views impact security considerations in native environments.   As an example can you pass a token from one app to another and have it still work to the same origin, or is it a security feature that it won't work and the token cant be stolen from a app and re-used by a different app on the same device.
>>>> I think that single sign-on between apps and browsers is at least a useful option.
>>>> 
>>>>> I don't think there is anything in the specs on this.
>>>>> Figuring out where some of these issues get documented might be useful.
>>>> Documenting key scoping is indeed useful; on the other hand standardizing the specifics might require standardizing user and application isolation models across platforms, which I don't think would be in scope for this forum. Perhaps we could agree on some general principles and include implementation guidance on Token Binding key scoping?
>>>> 
>>>> Cheers,
>>>> 
>>>> Andrei
>>>> 
>>>> -----Original Message-----
>>>> From: Unbearable [mailto:[e-mail]] On Behalf Of John Bradley
>>>> Sent: Friday, March 13, 2015 9:57 AM
>>>> To: [e-mail]
>>>> Subject: [Unbearable] Scoping of keys on the client.
>>>> 
>>>> Now that we are officially a WG I have a question (no hat)
>>>> 
>>>> One thing that I identified as a potential issue talking to people who are working on early deployments, is the expectations around how keys are shared between applications.
>>>> 
>>>> I found some people that believe all apps sharing a common TLS library would be able to share the same ID/key for a origin.
>>>> 
>>>> Other folks were under the impression that each application would have its own key for an origin.
>>>> 
>>>> The different views impact security considerations in native environments.   As an example can you pass a token from one app to another and have it still work to the same origin, or is it a security feature that it won't work and the token cant be stolen from a app and re-used by a different app on the same device.
>>>> 
>>>> There was a middle view by the MDM people that the ID/key would be scoped to a profile/container so that all the enterprise apps would share ID/key but that social apps would not.
>>>> 
>>>> I don't know that there is necessarily one right answer, as this may be implementation dependent.  
>>>> 
>>>> I don't think there is anything in the specs on this.   One reason I ask is that some of those differences impact on Native Application Single Signon and OAuth.
>>>> 
>>>> In some of the Windows prototypes I understand there is a Key Storage API that is used to share keys between the browser and apps.  
>>>> 
>>>> Android, Windows, iOS , OSX may all have implementation specific details, but people building applications that leverage token binding will need to understand the differences as they may have security and privacy implications.
>>>> 
>>>> Figuring out where some of these issues get documented might be useful.
>>>> 
>>>> John B.
>>>> 
>>>> _______________________________________________
>>>> Unbearable mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>