Will take a look. Phil
Sent from my phone. On 2011-04-11, at 8:19, Justin Richer <jric...@mitre.org> wrote: > While this isn't the original use case I had in mind, this could be > covered by something in the OAuth2 Instance extension: > > http://tools.ietf.org/html/draft-richer-oauth-instance-00 > > -- Justin > > On Fri, 2011-04-08 at 12:22 -0400, Phil Hunt wrote: >> 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.h...@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, tors...@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<sky...@kiva.org> >>>>>> Date: Mon, 4 Apr 2011 19:14:53 >>>>>> To: Torsten Lodderstedt<tors...@lodderstedt.net> >>>>>> Cc: Zeltsan, Zachary (Zachary)<zachary.zelt...@alcatel-lucent.com>; Kris >>>>>> Selden<kris.sel...@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-boun...@ietf.org [mailto:oauth-boun...@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.sel...@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 >> >> _______________________________________________ >> 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
