Re: [OAUTH-WG] Native clients & 'confidentiality'
George Fletcher <gffletch@aol.com> Wed, 21 December 2011 13:56 UTC
Return-Path: <gffletch@aol.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB121F8A70 for <oauth@ietfa.amsl.com>; Wed, 21 Dec 2011 05:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oty61kODlvSq for <oauth@ietfa.amsl.com>; Wed, 21 Dec 2011 05:56:19 -0800 (PST)
Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by ietfa.amsl.com (Postfix) with ESMTP id 716C221F8A64 for <oauth@ietf.org>; Wed, 21 Dec 2011 05:56:19 -0800 (PST)
Received: from mtaout-ma06.r1000.mx.aol.com (mtaout-ma06.r1000.mx.aol.com [172.29.41.6]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id pBLDttTp011230; Wed, 21 Dec 2011 08:55:55 -0500
Received: from palantir.local (unknown [10.172.1.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D5910E000081; Wed, 21 Dec 2011 08:55:54 -0500 (EST)
Message-ID: <4EF1E569.5090104@aol.com>
Date: Wed, 21 Dec 2011 08:55:53 -0500
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Madsen <paul.madsen@gmail.com>
References: <4EEF2BC4.7020409@gmail.com> <4EEF77E7.6030808@mitre.org> <4EEF7DEF.6090009@gmail.com> <4EEF8C2A.8030205@aol.com> <4EEF9A6B.7070307@gmail.com>
In-Reply-To: <4EEF9A6B.7070307@gmail.com>
Content-Type: multipart/alternative; boundary="------------010803070705040202000104"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1324475755; bh=mt8btd8w01NlpjKhli34CeZeT0TOyfOjvLbRcSLQscE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=LKGBa1z66ltcqZBg2xtn6hcUdA2Kz7D5Axn2tYhKKoLrXXXW4qT09ayYchssNz84N /JwrpJlNm9uc18+KKNbAhg0akR5Rtq4Dd8nQB1fIUFSlcK8TZQOxCsOoJPt6/vXKBj lXb3OJjqyO1E2blI3zLMuxNW9UTdXx/fb1mr+4xQ=
X-AOL-SCOLL-SCORE: 0:2:460849248:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d29064ef1e56a7698
X-AOL-IP: 10.172.1.214
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2011 13:56:21 -0000
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-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Justin Richer
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Michael Thomas
- Re: [OAUTH-WG] Native clients & 'confidentiality' Anthony Nadalin
- Re: [OAUTH-WG] Native clients & 'confidentiality' George Fletcher
- Re: [OAUTH-WG] Native clients & 'confidentiality' Justin Richer
- Re: [OAUTH-WG] Native clients & 'confidentiality' John Kemp
- Re: [OAUTH-WG] Native clients & 'confidentiality' John Kemp
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' John Kemp
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen
- Re: [OAUTH-WG] Native clients & 'confidentiality' George Fletcher
- Re: [OAUTH-WG] Native clients & 'confidentiality' zhang.ruishan
- Re: [OAUTH-WG] Native clients & 'confidentiality' Eran Hammer
- Re: [OAUTH-WG] Native clients & 'confidentiality' Paul Madsen