Re: [OAUTH-WG] Flowchart for legs of OAuth

Skylar Woodward <skylar@kiva.org> Fri, 08 April 2011 18:16 UTC

Return-Path: <skylar@kiva.org>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D86F3A69F4 for <oauth@core3.amsl.com>; Fri, 8 Apr 2011 11:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18-9P3nnW8gl for <oauth@core3.amsl.com>; Fri, 8 Apr 2011 11:16:22 -0700 (PDT)
Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by core3.amsl.com (Postfix) with SMTP id B02C03A69D6 for <oauth@ietf.org>; Fri, 8 Apr 2011 11:16:21 -0700 (PDT)
Received: from mail-pz0-f46.google.com ([209.85.210.46]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKTZ9RXjUWJXhwn13+eBd6w2kvFNYC2NDk@postini.com; Fri, 08 Apr 2011 11:18:07 PDT
Received: by pzk9 with SMTP id 9so1694634pzk.5 for <oauth@ietf.org>; Fri, 08 Apr 2011 11:18:06 -0700 (PDT)
Received: by 10.142.224.11 with SMTP id w11mr2086578wfg.136.1302286685930; Fri, 08 Apr 2011 11:18:05 -0700 (PDT)
Received: from [10.0.1.9] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id x11sm3944953wfd.1.2011.04.08.11.18.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 11:18:04 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Skylar Woodward <skylar@kiva.org>
X-Priority: Normal
In-Reply-To: <EFE3F36C-8917-4705-9EE5-832C111CF38A@oracle.com>
Date: Fri, 08 Apr 2011 11:18:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <072CFC71-0FFE-4A69-8A2D-20D8A734389C@kiva.org>
References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <AANLkTimGjiCGk5dpA=YVzq5vDkLR2+caSz=pZ5WiZO9H@mail.gmail.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <BANLkTiniuuRXtkzLubgOjVursVtOGjFe6A@mail.gmail.com> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <BANLkTi=XyF25vB6qKX2q8iOpEaZ1yQx9Jw@mail.gmail.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <BANLkTik5u5+jjTwnwNCQVyzMux4aMB98yg@mail.gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4D9A318D.3090908@lodderstedt.net><38AE5D29-996A-49AA-89A0-3A15AB4C0823@kiva.org> <1567368214-1301980513-cardhu_decombobulator_blackberry.rim.net-2135712133-@b1.c11.bise7.blackberry> <57E21FB2-6030-4485-BA46-0E12245E9D63@kiva.org> <4D9EAAA2.9030809@lodderstedt.net> <D76D1310-67E! !E-4CEB-8B0B-15FD63BA3DA3@kiva.org><17C3457F-22A3-42F9-BA0A-80CEDED9DF70@oracle.com> <859122783-1302280631-cardhu_decombobulator_blackberry.rim.net-1217985074-@b1.c11.bise7.blackberry> <EFE3F36C-8917-4705-9EE5-832C111CF38A@oracle.com>
To: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: Apple Mail (2.1082)
Cc: Kris Selden <kris.selden@gmail.com>, "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 08 Apr 2011 18:16:23 -0000

I can't see the purpose of "generated secret" by the client. I fear this is going to lead down the same confusing path as the last thread on auth codes.

Essentially what you're asking for is a unique session ID per grant request.  If TLS is required across all connections to protect the generated secret/ID, then this secret serves no security purpose. The token (and auth code represented by it during the first leg) serves as the session ID anyway, so the client-generated secret is redundant. Additionally you have to deal with the provider rejecting secrets if they are not unique.

Such a secret would provide no identity guarantee beyond the "same session" guarantee provided the token. Any application can use an existing client ID, make up a secret, and authenticate. The server knows nothing more about the identity of the client.  Identity and secrets must be established outside the OAuth handshake - at the same point where application identity data (icon, name, owner) is managed.


On Apr 8, 2011, at 9:49 AM, Phil Hunt wrote:

> I am assuming the outbound requests are secured by TLS, but for various reasons the return path (e.g. the redirect) might not be. Thus, one restriction would be that the server never returns the code to the client.
> 
> Thus, you could submit a secret simply for the purpose of verifying the same specific requestor for each operation.
> 
> Phil
> phil.hunt@oracle.com
> 
> 
> 
> 
> On 2011-04-08, at 9:36 AM, torsten@lodderstedt.net wrote:
> 
>> This would be another possible standard option. As you pointed out, it would help to detect authz code theft even for native apps. It would not help wrt client authorization since there are no properties associated with the new credential.
>> 
>> The key is: how does the authz server get to know this secret? As the redirects are not fully protected against leaks (history, referers) I would not pass it in as a parameter to the authz request. 
>> 
>> Regards,
>> Torsten.
>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland  
>> 
>> -----Original Message-----
>> From: Phil Hunt <phil.hunt@oracle.com>
>> Date: Fri, 8 Apr 2011 09:22:18 
>> To: Skylar Woodward<skylar@kiva.org>
>> Cc: Torsten Lodderstedt<torsten@lodderstedt.net>; Kris Selden<kris.selden@gmail.com>; Zeltsan, Zachary \(Zachary\)<zachary.zeltsan@alcatel-lucent.com>; oauth@ietf.org<oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>> 
>> Why not have the client app generate a random text string to be used as a request secret.  The random text string would be matched during all subsequent requests by the client surrounding a particular authorization.  Assuming the endpoints all require TLS for request side operations it would prevent interception issues and bind the authz code to a particular client instance even when matching client credentials are used by an intercepting hacker.
>> 
>> Would this help to satisfy at least some of the client app instance identification issues?
>> 
>> Note: it had also occurred to me that client apps should have static client_instance identifiers. In practical terms this might be tied to an IMEI number for example on a smart phone or other static information. However, I don't think it would solve this security issue since it would be easy to imitate. The above solution suggests a changing random string instead.
>> 
>> Phil
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> 
>> On 2011-04-08, at 12:10 AM, Skylar Woodward wrote:
>> 
>>> Yes, I can see how this might seem confusing. Actually, we're authenticating the client with authorization server - not a resource request.  On the MAC threads we discussed how the token can be used for both.  Hopefully that clears everything up, but I'll briefly address some of the questions inline.
>>> 
>>> On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote:
>>> 
>>>> Hi Skylar,
>>>> 
>>>> Am 06.04.2011 18:02, schrieb Skylar Woodward:
>>>>> Well, I should elaborate. The method of authorization is open to the client, and in this case (Kiva), MAC tokens are being used. The client authenticates on the access_token request by presenting a MAC authentication header. Creating the MAC signature requires a secret. In the native client case, since there is no secret, it signs with the empty string. So, how would you interpret this mechanism? Are we using an empty string secret or signing without a secret? In terms of communicating to the developers, they are told they don't have a secret. For purposes of signing, they are instructed to sign with them empty string when they have no secret.
>>>> 
>>>> You are talking about using the client secret to authenticate resource server request, correct? This is not in scope of the core spec. I was talking about authenticating the client with the authorization server.
>>>> 
>>>> Apart from that, do you think singing with an empty string adds any security to your solution?
>>> 
>>> No. It's about congruence at this point. Also, a MAC token by definition is signed so it has to be some other assertion if it is not signed.
>>> 
>>>> Moreover as far as I understand the MAC-Spec, it recommends to use authorization server issued secrets to sign the request. So why do you need a client secret for request signing?
>>>> 
>>>>> Alternatively, one could use Bearer token for client authentication in this case where the token is just the client ID. To me this is more confusing because they must authenticate with different token types for secret vs. non-secret.  Other opinions?
>>>> 
>>>> I'm confused now, why is the token the client id? A token is used by the authorization server and may contain (or refer to) any data you need to authorize access of the client to the resource server.
>>> 
>>> Right, you're confusing the spec with the use. I'm considering the case of a simple Bearer assertion in cases of client authentication where clients have no secret since an ID/password assertion would imply an empty-string password or secret. As Marius said, we're splitting hairs at this point.  Section 3.1 makes no notes on the possible value of client_secret for clients w/o secrets, so the assumption was that a value of "client_secret=&..." would be ignored resulting in an invalid Client Password submission.
>>> 
>>>> 
>>>>> As to the question of interoperability, the fact that OAuth allows freedom of choice to the AS for method of authentication makes this point moot. Would you agree? (short of various providers could pooling together to standardize on an auth method outside of the spec).
>>>> 
>>>> What authentication are you refering to? Who do you want to authenticate?
>>> 
>>> Client authentication. Section 3.2.
>>> 
>>>> 
>>>> regards,
>>>> Torsten.
>>>> 
>>>>> 
>>>>> 
>>>>> On Apr 4, 2011, at 10:15 PM, torsten@lodderstedt.net wrote:
>>>>> 
>>>>>> Hi Skylar,
>>>>>> 
>>>>>> Thank you for sharing this information with us. Some thougts:
>>>>>> 
>>>>>> The empty string makes your implementation syntactically compliant but does obviously not comply with its semantics and the security considerations/expectations associated with a secret. Moreover, what about interoperability?
>>>>>> 
>>>>>> I think not using secrets for such clients is the honest solution. We can just change the spec's text to express what we think is the right way.
>>>>>> 
>>>>>> regards,
>>>>>> Torsten.
>>>>>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Skylar Woodward<skylar@kiva.org>
>>>>>> Date: Mon, 4 Apr 2011 19:14:53
>>>>>> To: Torsten Lodderstedt<torsten@lodderstedt.net>
>>>>>> Cc: Zeltsan, Zachary (Zachary)<zachary.zeltsan@alcatel-lucent.com>; Kris Selden<kris.selden@gmail.com>; oauth@ietf.org<oauth@ietf.org>
>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>>>>>> 
>>>>>> In our implementation (not yet public) we accept the empty string ("") as the value for clients not issued secrets. While this was done to simplify the interface and implementation, it would make it compliant in my view.  In this case, the authorization server is validating the credentials, which are the client ID and the empty string, which is equivalent security-wise to any other length of "secret" issued to a native client.
>>>>>> 
>>>>>> Besides, for many providers, the client credentials will only be a client ID. They would plan to secure all exchanges over TLS and credentials serve just as a tracking device or at best, a weak form of identification.
>>>>>> 
>>>>>> skylar
>>>>>> 
>>>>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote:
>>>>>> 
>>>>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary):
>>>>>>>> According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials".
>>>>>>>> How can this be done if a client is an application that can't have a client secret?
>>>>>>>> The authorization code grant does require client authentication (per section 4.1):
>>>>>>>> 
>>>>>>>> (D)  The client requests an access token from the authorization
>>>>>>>>     server's token endpoint by authenticating using its client
>>>>>>>>     credentials, and includes the authorization code received in the
>>>>>>>>     previous step.
>>>>>>>> 
>>>>>>>> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens.
>>>>>>> In my opinion, this part of the spec is misleading. Authorization code MUST be possible without client authentication. Otherwise, OAuth is useless for native apps.
>>>>>>> 
>>>>>>> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 describes how the flow can be protected in such cases.
>>>>>>> 
>>>>>>> regards,
>>>>>>> Torsten.
>>>>>>>> Zachary
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu
>>>>>>>> Sent: Monday, April 04, 2011 2:30 PM
>>>>>>>> To: Kris Selden
>>>>>>>> Cc: oauth@ietf.org
>>>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>>>>>>>> 
>>>>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden<kris.selden@gmail.com>   wrote:
>>>>>>>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once.
>>>>>>>>> 
>>>>>>>>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token?
>>>>>>>> The authorization code grant, aka web server flow.
>>>>>>>> 
>>>>>>>> The spec is misleading in this respect IMO.
>>>>>>>> 
>>>>>>>> Marius
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>