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
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
