Re: [OAUTH-WG] Native clients & 'confidentiality'

[George Fletcher <[e-mail]>]

More inline:)

On 12/19/11 3:11 PM, Paul Madsen wrote:
> Hi George, inline
>
> thanks
>
> paul
>
> On 12/19/11 2:10 PM, George Fletcher wrote:
>> Hi Paul,
>>
>> Is the need to authenticate the client a need to ensure that the 
>> content is only displayed on certain devices/clients? Or prevent 
>> phishing/stealing of authz bearer tokens?
> I'm not best qualified to answer but I believe it's the latter, ie not 
> DRM motivated
>>
>> As you point out, it's possible to protect the bearer tokens and 
>> associated refresh tokens "via other mitigating mechanisms". I'm not 
>> sure it's possible to authenticate the device/client with out the 
>> device/client having some special "hardware" that can be leveraged in 
>> the authentication step.
> are you referring to a 'bootstrap' problem?
Well... more thinking about whether the set of devices/clients allowed 
to go through the "dynamic registration" process is "restricted" in some 
way (e.g. a certain manufacturer, or application running on a device). 
Given that the dynamic registration steps can be discovered, it become 
difficult to restrict what devices/clients can go through the dynamic 
registration steps.

>>
>> Even dynamic registration doesn't solve the security issues (the 
>> device/client can still be disassembled and associated values 
>> discovered) of the device/client, just mitigates the exposure risk. 
>> However, this does cause increased work for the AS as it will now be 
>> tracking each and every device as a unique client. It's also likely 
>> for the device registration steps to be discovered, in which case 
>> restricting to a particular device again fails.
> yes, but as you imply an attacker will only access those credentials 
> specific to that particular copy of the native client. Hopefully too 
> much work to be able to see Glee Season 2.
>
> Can you clarify what you mean about the device registration steps 
> being 'discovered'?
(see above). Basically, the question becomes... is any device/client ok 
to be used as long as it goes through the dynamic registration process 
and is "authorized" by the AS? If the answer is yes, then I think 
dynamic registration is a great solution.  Given all transactions are 
over SSL, getting any of client credentials, refresh_token or 
access_token is going to be difficult without access to the device/client.

There is the issue of the client sending the token to a rogue protected 
resource. Though that is pretty unlikely based on a native 
device/client. It would require a both a rogue client and a rogue 
protected resource. If this is a concern, then you are sort of back into 
the problem of needing to be able to at least identify the device/client.

Seems like a unique set of client credentials for every instance of the 
device/client plus short-lived access_tokens should be good enough for 
this use case. The associated refresh_token can always be revoked as 
well. All this doesn't obviate the need for "risk based authN/authZ" at 
the AS.
>>
>> It seems like trying to bind the bearer token to a device/client 
>> instance might be a better approach. That way you know that the 
>> customer correctly authorized that device/client instance and it is 
>> "allowed" to present the bearer token. Of course enforcing/proving 
>> the "allowed" part sort of breaks the "bearer" part:)
> yeah, how do we bind a bearer token to anything? :-) Doesnt that by 
> definition take us towards MAC?
I know, I'm stating the obvious... but thankfully it sounds like you 
don't need that level of security:)
>
>
>>
>> Thanks,
>> George
>>
>> On 12/19/11 1:09 PM, Paul Madsen wrote:
>>> Thanks Justin, FWIW, I agree with your analysis
>>>
>>> Seems to me we have the following breakdown of clients
>>>
>>> - confidential server clients
>>>
>>> - confidential native clients (somewhat theoretical at the moment, 
>>> assumes either 1) a client registration mechanism to deliver 
>>> credentials post installation, such as OpenID Connects Client 
>>> Registration spec, or 2) a distribution channel in which uniquely 
>>> credentials can be packaged into the binary before delivery)
>>>
>>> - public clients (no option of client authn, but still possible to 
>>> have some protection against token leakage via other mitigating 
>>> mechanisms)
>>>
>>> thanks again
>>>
>>> paul
>>>
>>> On 12/19/11 12:44 PM, Justin Richer wrote:
>>>> Native mobile clients can't really be confidential clients.
>>>>
>>>> The distinction between "public" and "confidential" clients is 
>>>> whether or not they can keep deployment-time secrets; which is to 
>>>> say, a client_secret. This is not to say that they can't keep *any* 
>>>> secrets. In particular those generated at runtime, like an access 
>>>> token or refresh token, could be held perfectly safe. But at the 
>>>> time the app is deployed to its running environment, you have to 
>>>> ask "who has access to its code and configuration?"
>>>>
>>>> Think of it this way. In the standard world, a native app gets 
>>>> copied to every device with the client_id and client_secret baked 
>>>> in. This makes the client_secret not very secret, and not at all 
>>>> unique. Anybody with access to the binary -- which is to say, every 
>>>> user -- could decompile the client_secret out of it and bake it 
>>>> into their *own* client, pretending to be your app and causing all 
>>>> kinds of havoc. This is a very different problem from somebody 
>>>> breaking into the token store and stealing an access token, which 
>>>> lets them only get to their own account.
>>>>
>>>> Compare this to a server-based app where the only ones with access 
>>>> to the binary and configuration are the administrators of the 
>>>> server, not the end users. It's a much more limited list of folks 
>>>> that can potentially see it, and therefore the client_secret can 
>>>> actually mean something and add a small extra layer of security.
>>>>
>>>> There are a few ways to mitigate this difference for public 
>>>> clients, such as using some kind of dynamic registration for all 
>>>> clients (which doesn't buy you much in terms of overall security) 
>>>> or putting up scary messages about native clients to try and 
>>>> educate your users. You can also use a trusted callback URL for 
>>>> your app on a hosted website that works in conjunction with your 
>>>> native app. This is actually the suggested use for the Implicit 
>>>> Flow, which was made for public clients in the browser.
>>>>
>>>> Native apps also have the concern of embedded browsers vs. external 
>>>> native browsers, and what trust the user puts into them. For all 
>>>> OAuth flows, you have to trust the browser provider on the platform 
>>>> of choice, since the user's going to be logging in directly through 
>>>> that browser. It's very much outside the scope of OAuth to make 
>>>> that world any better though, and there have been long and detailed 
>>>> discussions on this list about that very topic, leading to some 
>>>> concrete recommendations in the draft as it stands today.
>>>>
>>>> To answer your original query: I don't think that mandating one 
>>>> kind of client vs. the other will really help. OAuth 1.0 only had 
>>>> "confidential" clients, and that led to inane workarounds like 
>>>> Google's "anonymous/anonymous" client id/secret.
>>>>
>>>> Hope this helps.
>>>>
>>>>  -- Justin
>>>>
>>>> On 12/19/2011 07:19 AM, Paul Madsen wrote:
>>>>> Hi, the Online Media Authorization Protocol (OMAP) is a (as yet 
>>>>> unreleased) profile of OAuth 2.0 for online delivery of video 
>>>>> content based on a user's subscriptions (the TV Everywhere use case)
>>>>>
>>>>> We want to support both server & native mobile clients. It is for 
>>>>> the second class of clients that I'd appreciate some clarification 
>>>>> of 'confidentiality' as defined in OAuth 2.
>>>>>
>>>>> OAuth 2 distinguishes confidential & public clients based on their 
>>>>> ability to secure the credentials they'd use to authenticate to an 
>>>>> AS - confidential clients can protect those credentials, public 
>>>>> clients can't.
>>>>>
>>>>> Notwithstanding the above definition, the spec gives a degree of 
>>>>> discretion to the AS
>>>>>
>>>>>     The client type designation is based on the authorization server's
>>>>>     definition of secure authentication and its acceptable exposure
>>>>>     levels of client credentials.
>>>>>
>>>>>
>>>>> Give this discretion, is itpractical for the OMAP spec to 
>>>>> stipulate that 'All Clients (both server & native mobile), MUST be 
>>>>> confidential', ie let each individual OMAP AS specify its own 
>>>>> requirements of clients and their ability to securely authenticate?
>>>>>
>>>>> Is this consistent with the OAuth definition of confidentiality?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>