Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Got it. End-user authentication via USIM is indeed secure (and convenient). regards, Torsten. Igor Faynberg schrieb: As far the authentication goes, what I had in mind was that the network provider could authenticate the end-user. Alternatively, an application (not necessarily the USIM) on

[OAUTH-WG] Client Credentials and Refresh Tokens

Would anyone care to explain what the value of a refresh token is for peer to peer applications utilizing the client_credentials grant type, or validate if my explanation is the intended use case? Recall: * it is required to provide client credentials to get an access token [and refresh token] *

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On 6/2/11 8:38 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre > wrote: > > I'm not thinking about your use case, but things like enterprise > deployments in high-security environments where every person and every > software applic

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On Thu, Jun 2, 2011 at 7:13 PM, Peter Saint-Andre wrote: > I'm not thinking about your use case, but things like enterprise > deployments in high-security environments where every person and every > software application has a certificate or is otherwise provisioned for > authentication with the au

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On 6/2/11 6:48 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre > wrote: > > I think the SHOULD we had originally is probably fine -- with the > understanding that "SHOULD" means "you really ought to do this unless > you have a good

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre wrote: > I think the SHOULD we had originally is probably fine -- with the > understanding that "SHOULD" means "you really ought to do this unless > you have a good reason not to". I think one such really good reason > might be a authorization serv

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On 6/2/11 4:11 PM, Brian Eaton wrote: > On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre > wrote: > > I think I might have misunderstood that text -- I took it to be talking > about the client's authentication with the authorization server, not the > client

Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme

On 03/06/2011, at 1:44 AM, Eran Hammer-Lahav wrote: > > >> -Original Message- >> From: Mark Nottingham [mailto:m...@mnot.net] >> Sent: Wednesday, June 01, 2011 5:16 PM >> To: Eran Hammer-Lahav >> Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; >> 'Adam Barth (a...@a

Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme

Stephen, On 6/1/2011 5:16 AM, Stephen Farrell wrote: Just on DOSETA - that's not currently got any official home in the IETF so its not something that would be right to reference at this point (unless the oauth WG wanted to adopt DOSETA but I'd be very surprised if that were the case for timing

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre wrote: > I think I might have misunderstood that text -- I took it to be talking > about the client's authentication with the authorization server, not the > client's authentication with the resource server. No, you understand perfectly. We're t

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On 6/1/11 1:06 PM, Brian Eaton wrote: > Hey Peter - > > I haven't read all of your comments yet, but I wanted to clarify one > point about client impersonation and installed apps. The cuirrent text > is unrealistic, but your request would push it the wrong way. CC'ing > Torsten as well. > > --

Re: [OAUTH-WG] Text for Native Applications

On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton wrote: > Well, "rely" is a strong-term.  I know of various teams who do this.  I > don't know of any teams that put a heavy reliance on it. It might validly be just one element of a defense-in-depth strategy. Regards, Dave David B. Nelson Sr. Softwa

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On Thu, Jun 2, 2011 at 4:24 PM, Thomas Hardjono wrote: > Oh ok, now I get what "authenticating the client" means here. My bad. > Perhaps the term "authenticating" is not accurate. Maybe "integrity > verification" of client code is a better phrase. It *may* include integrity verification of the c

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

As far the authentication goes, what I had in mind was that the network provider could authenticate the end-user. Alternatively, an application (not necessarily the USIM) on the smart card could hold the secret and perform all cryptographic operations (what Thomas calls crypto-store). In eithe

Re: [OAUTH-WG] Text for Native Applications

On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills wrote: > In practice there are an extremely small number of cases where this is > actually done right, and legions of cases where it's done wrong. Industry > just doesn't get this right often enough to rely on it. > Well, "rely" is a strong-term.

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Absolutely! In fact, client_id, should be presumed to be TOTALLY different from the USIM (or ISIM) ID. The correlation of IDs is the network's job. (Hui-Lan and I, along with two other researchers, described how this can be done in a Bell Labs Technical Journal paper: http://onlinelibrary.wi

Re: [OAUTH-WG] Text for Native Applications

I wish I could talk about it.  You'll have to find someone who's not bound by stuff like employment contracts and trades secrets stuff to tell you the story. From: Skylar Woodward To: Dave Nelson Cc: "oauth@ietf.org" Sent: Wednesday, June 1, 2011 1:07 PM Subj

Re: [OAUTH-WG] Text for Native Applications

In theory this is true.. > I firmly believe that secrets can be sufficiently obfuscated > in code delivered in binary format without the benefit of a > symbol table, so as to be sufficiently resistant todiscovery > via disassembly by attackers you'd expect to encounter in a > typical comme

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

in my opinion, the problem with client authentication is more the secure distribution of the secret than the storage. How should a USIM help here? regards, Torsten. Thomas Hardjono schrieb: Thanks Igor, If you bring smartcards into the picture, then it's a different ballgame :) If mobile p

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

> __ > > From: Brian Eaton [mailto:bea...@google.com] > Sent: Thursday, June 02, 2011 3:45 PM > To: Thomas Hardjono > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > On Thu, Jun 2, 2011 at 11:40 AM, Thomas

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

The notion of client instance ids (eg as suggested) by USIMs suggested may be a slightly different identify then envisioned by client_id. I have mentioned the same issue before of identifying software separately from deployment instances which such a strong credential would map to. They likel

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Thanks Igor, If you bring smartcards into the picture, then it's a different ballgame :) If mobile phones are assumed to have smartcards (which is increasingly true today via USIMs), then OAUTH can assume that native apps (running on the phones) may have access to crypto-store. In this case the t

Re: [OAUTH-WG] Text for Native Applications

On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono wrote: > (a) Oauth2.0 today is designed for low-assurance environments. So I think > the WG is wasting a lot of time in trying to address whether the Client can > keep secrets. The WG should just assume that the problem of keeping secrets > is out

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono wrote: > Well, not to belabor this point :) but in Kerberos it is the proof of > possession of the client secret key which _is_ the authentication mechanism. > There is also PKINIT (RFC4556) which can be used to "pre-authenticate" the > user via D

Re: [OAUTH-WG] Text for Native Applications

Thomas Hardjono wrote: (a) Oauth2.0 today is designed for low-assurance environments. I don't think that was an objective. At least, the charter does not say that... So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assum

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

Actually, for the devices that use smart cards (mobile devices, in particular), this assumption is quite appropriate. Igor Thomas Hardjono wrote: ... However, there is indeed the assumption in Kerberos/RFC4120 (and in the original Needham-Schroeder protocol) that the "client" can keep

Re: [OAUTH-WG] Text for Native Applications

Hi Torsten, folks, I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and also the text of Section 9 of oath-draft16. I think there seems to be a disconnect (may be its just me). (a) Oauth2.0 today is designed for low-assurance environments. So I think the WG is wasting a

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Thursday, June 02, 2011 5:10 AM > To: Brian Eaton > Cc: OAuth WG > Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 > > I fully agree with Brian and would like to add some thoughts: >

Re: [OAUTH-WG] Getting the authorization code - Native Applications

On Wed, Jun 1, 2011 at 7:54 PM, Matias Woloski wrote: > I've read the latest spec and some of the discussions around the user-agent > flow and native apps. I've read about the different options to get the authz > code (copy-paste, polling the title of the window, custom scheme, etc). > I might be

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I agree with Brian. One of the use cases that relies on the issuing tokens to an unauthenticated client is Mobile App (http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01#section-3.4). A use case's requirement is that "authorization shall be valid for a prolonged duration". Such long-te

Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme

> -Original Message- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Wednesday, June 01, 2011 5:16 PM > To: Eran Hammer-Lahav > Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; > 'Adam Barth (a...@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss]

Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

I fully agree with Brian and would like to add some thoughts: Not authenticating the client does not directly create a security problem at all. If we would follow this line, every e-Mail client out there would be considered insecure because the client itself is never authenticated. Not even Ke

Re: [OAUTH-WG] Text for Native Applications

Dave, Skylar, the assumption of the OAuth 2.0 security threat model (http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1) is that client secrets, which are distributed with applications, cannot reliably kept confidential. Therefore the advice is given to use other means

Re: [OAUTH-WG] Text for Native Applications

I agree with Skylar. In the end, the most important point is how much the authorization server trusts the particular client and what privileges are associated with that client identity. In an open development model, I would not trust the client in the least and instead require the user to autho