Hi George, The really short summary is that Yahoo is fine with client based signatures being in the spec, although we do not want Service Providers to be obligated to support them. The decision as to whether or not signatures should be used, and which signature algorithm to use should be up to the Service Provider.
We are very strongly against signatures generated using the client secret for the overwhelming majority of our APIs which is why we want the signature algorithm to be chosen by the SP. A signature using the Access Token secret (without the client secret) is OK, although it¹s unnecessary for our applications. A plain bearer token by itself (provided that it¹s only valid for about an hour) is sufficient for all of Yahoo¹s services even without HTTPS. We¹d rather increase security by deploying HTTPS rather than requiring developers to sign their requests. Thanks Allen On 5/27/10 11:11 AM, "George Fletcher" <gffle...@aol.com> wrote: > Hmm... to me this says... > >> Yahoo won't deploy PRs that require client_secret signatures, but may have >> some internal apps where this is ok. >> >> So, to me that sounds like Yahoo is ok with client_secret based signatures >> as one way to sign the requests, but they don't want it to be the only way. > > I would like to bring back what Dirk has said earlier in this thread... > > 1. Signing isn't about the token but rather about the message > 2. Signing provides message integrity > 3. Signing provides (or should allow for) proof of sender > > I'd like to add... > 4. Signing (combined with appropriate information in the AT) enables "right to > present" the token > > I think that for certain use cases, its critical that the PR be able to ensure > that the client is "authorized" to present the AT. This isn't possible for > bearer tokens. I also don't believe this hurts sub-delegation because the AS > can create an AT that can be sub-delegated and when the sub-delegate presents > the AT, the PR can verify that the sub-delegate is allowed to present that AT. > > Thanks, > George > > On 5/27/10 12:58 PM, Allen Tom wrote: >> Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 The >> short summary is that Yahoo thinks that signatures should not be required for >> most use cases. In the exceptional cases where signatures are required, then >> it should be up to the service provider (and not the client) to determine >> when they¹re required, and which signature algorithm is to be used. Yahoo >> does not want to be forced to support signatures generated using the client >> secret we don¹t even want this to be an option for the overwhelming >> majority of our APIs. Due to the way services are deployed at Yahoo, our >> security team feels that in general, having PR endpoints validate signatures >> computed using the client secret makes our overall system LESS secure since >> we¹d be forced to distribute client secrets to the PR endpoints. Distributing >> the client secret to the PR endpoints is very undesirable, since doing so >> requires that the PR endpoints have the same level of security as the AS. >> >> Having a clean separation between the AS and the PR was one of the goals of >> Oauth-WRAP and having the PR authenticate the client using the client >> secret violates this goal. >> >> That being said, Yahoo does have private/internal APIs which require a very >> high level of security in which bearer tokens are not sufficient, and >> signatures using the AT secret aren¹t sufficient either in these cases, >> signing the request with the client secret is probably the right way to go. >> Again this should be up to the SP to determine that a signature is >> required, and how that signature is generated. >> >> So what I¹m trying to say is yes there are cases where it¹s desirable to >> have stronger signatures than just signing with the AT secret however I >> think that the cases in which signatures are required, and which signature >> algorithm is to be used should be entirely up to the SP. >> >> Does that clarify things? >> Allen >> >> >> >> >> On 5/27/10 9:04 AM, "Dirk Balfanz" <balf...@google.com> wrote: >> >> >>> >>> >>> On Thu, May 27, 2010 at 8:56 AM, David Recordon <record...@gmail.com> wrote: >>> >>>> I thought Allen clearly said that signing with the client secret won't work >>>> for Yahoo!? >>>> >>> >>> Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at >>> all. So I think we're good from the Yahoo! side of things. >>> >>> Allen - did I get this right? >>> >>> Dirk. >>> >>> >>> >>>> >>>> >>>>> Hi Dirk- >>>>> >>>>> We at Yahoo would be very much against using the client secret for signing >>>>> requests to Protected Resources, since this would require that the client >>>>> secret be distributed to the PR endpoints. For security reasons, one of >>>>> the design goals for WRAP was to keep the client secret a secret between >>>>> only the AS and the Client deliberately separating the authentication of >>>>> the client (on the AS) from the serving of the protected resource. >>>>> >>>>>> >From your post, it¹s not quite clear what the disadvantage is with using >>>>>> the Access Token secret for generating signatures. >>>>> >>>>> (forgive me if this was already discussed today - I was very zonked out >>>>> after 3 days of IIW) >>>>> >>>>> Thanks >>>>> Allen >>>>> >>>> >>>> >>>> On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balf...@google.com> wrote: >>>> >>>>> Sorry, I didn't mean to turn this into a debate over whether we should >>>>> have signatures. I think you guys stated your case clearly, and there are >>>>> other use cases as well. >>>>> >>>>> The questions I was trying to figure out was whether >>>>> >>>>> - you'd be ok using the client secret to sign instead of the token secret >>>>> (I think I heard David say that that was ok), >>>>> - you'd be ok with a signature scheme that's sufficiently factored out of >>>>> the rest of the spec that it might warrant it's own companion spec (I >>>>> agree that this is getting close to bikeshed territory, so let's worry >>>>> about this once we know what the signatures look like). >>>>> >>>>> Dirk. >>>>> >>>>> >>>>> On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshep...@facebook.com> >>>>> wrote: >>>>> >>>>>> So, when I argued for signatures, the specific use cases we are concerned >>>>>> with: >>>>>> >>>>>> - Mobile handsets and networks that don't support SSL very well >>>>>> - High-volume applications where SSL is a significant cost to both sides >>>>>> - for Facebook, the top few apps make up a significant amount of API >>>>>> traffic, so we could do signatures for them and not for everyone else >>>>>> >>>>>> I expect that these are issues that others will encounter as they expand >>>>>> into these areas- especially on the mobile side. These are not >>>>>> Facebook-specific issues. >>>>>> >>>>>> That said, I agree with David that we should just figure out what the >>>>>> signatures are - I don't really care where they live. If they need to >>>>>> live in a separate spec then whatever, as long as the specs interoperate >>>>>> very cleanly. But I would like to hear from other mobile developers if >>>>>> they have tried OAuth 2.0 with success (Brian, I think you mentioned you >>>>>> may have some data about that?) >>>>>> >>>>>> On May 26, 2010, at 11:20 AM, David Recordon wrote: >>>>>> >>>>>> >>>>>>> How about we figure out the technical details of signatures before >>>>>>> figuring out where they're placed? :) </bikeshed> >>>>>>> >>>>>>> >>>>>>> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balf...@google.com> >>>>>>> wrote: >>>>>>> Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec? To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: "If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)? Dirk. On Wed, May 26, 2010 at 10:55 AM, David Recordon <record...@gmail.com> wrote: I'd prefer that we keep signatures simple enough that they can remain in the core spec. --David On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balf...@google.com> wrote: >>>>>>> >>>>>> >>>>> >>>> >>> >> Repeating what I said before: >> >> - separate spec is fine by me >> - part of the point I'm trying to make is that that spec shouldn't be about >> signed _tokens_, but instead about signed _HTTP requests_ (so instead of >> merely proving that you know a secret that came with the token, you prove >> who you are when you use the token). >> >> I'd be interested what the Facebook guys think about this - I believe the >> current signature scheme is in there mostly to address a use case they had. >> >> Luke, Dave - would a separate signing spec be ok with you guys? >> >> Dirk. >> >> >> On Tue, May 25, 2010 at 6:56 PM, Allen Tom <a...@yahoo-inc.com> wrote: >> +1 >> >> I fully agree with Dirk and Brian that there needs to be some work on >> signatures. There are many types of applications that require higher levels >> of security than what bearer tokens can provide. >> >> That being said, I think that bearer token/refresh token model can satisify >> the majority of use cases - in fact it would satisfy 100% of all public APIs >> that we have at Yahoo. >> >> Perhaps in the interest of keeping the spec focused, it would make more >> sense to split out a Signed Token Spec, as Justin proposes, that is focused >> solely on uses cases that require a signature? >> >> Allen >> >> >> >> On 5/21/10 11:27 AM, "Richer, Justin P." <jric...@mitre.org> wrote: >> >>> > I have a slightly more radical proposal. What if we factor out the signed >>> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >>> given >>> > the same attention by the group and all that like Eran was talking about >>> > yesterday. What this would take is taking out all reference to signing and >>> > making core OAuth just about bare tokens, then have a separate spec that >>> > details what to call your shared secret parameters, how to get them, and >>> how >>> > to sign with them. This makes the core spec a lot simpler (as detailed >>> below) >>> > but makes the overall use case of using signed tokens more complicated to >>> > follow, as it'd be split in two. >>> > >>> > -- justin >>> > ________________________________________ >>> > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Dirk >>> > Balfanz [balf...@google.com] >>> > Sent: Thursday, May 20, 2010 7:39 PM >>> > To: OAuth WG >>> > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 >>> > >>> > Hi guys, >>> > >>> > at today's interim meeting, we were discussing Brian Eaton's proposal for >>> > OAuth signatures. He was proposing a mechanism that would (1) do away with >>> > base string canonicalization, (2) allow for symmetric and public keys, and >>> (3) >>> > allow for extensibility. >>> > >>> > He got homework from the group to prove the feasibility of his proposal by >>> > showing a couple of implementations. >>> > >>> > In this post, I would like to introduce another improvement of the OAuth 2 >>> > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it >>> would >>> > work both with the signing mechanism in the current spec, as well as with >>> > Brian's signature mechanism). The goal of my proposal is twofold: >>> > >>> > - it simplifies the spec. It will become more readable and therefore >>> easier to >>> > implement >>> > - it separates out the mechanisms for delegated authorization and for >>> > integrity protection into two independent pieces, which can be put >>> together by >>> > Servers and/or Clients like LEGO blocks. >>> > >>> > Summary: >>> > >>> > - use the client secret instead of the token secret for signing PR access >>> > requests. >>> > >>> > Long version of the proposal: >>> > >>> > - remove all references to access tokens that are not bearer tokens from >>> the >>> > spec. >>> > - stop calling the access tokens "bearer tokens". Call them just "access >>> > tokens". >>> > - remove all references to token secrets from the spec >>> > - remove all parts of the spec that are of the kind "if bearer_token then >>> X, >>> > else Y", and replace them with X. >>> > - delete section 5.3 >>> > - add a section called "Request Authentication" that goes something like >>> this: >>> > >>> > "Servers may require that requests be authenticated by the Client, so that >>> > presentation of the access token alone is not sufficient to access a >>> Protected >>> > Resource. This has several use cases, including, but not limited to, the >>> > following: >>> > >>> > - Non-repudiation: high-security deployments may require that requests be >>> > authenticated (signed) in a non-repudiateable way[1] >>> > - Access to protected resources is not protected by SSL, so that access >>> tokens >>> > may leak. >>> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may >>> > strip SSL protection before the request reaches the protected resource. >>> The >>> > protected resource, however, may require end-to-end integrity. >>> > >>> > If the Server requires that the Client authenticate PR access requests, >>> then >>> > the Client uses the following mechanism to sign their HTTP requests: >>> [...]" >>> > >>> > Then, we basically drop the old Section 5.3 here (except we use the client >>> > secret instead of the access token secret). Eventually, instead of Section >>> > 5.3, we may have Brian's new signature scheme section here, which would >>> add >>> > the option of public-key crypto[1], etc. >>> > >>> > What do you guys think? >>> > >>> > Dirk. >>> > >>> > [1] Technically speaking, the goal of non-repudiation can only be achieved >>> > once we have public-key crypto. >>> > >>> > _______________________________________________ >>> > 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 >> >> >>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> <ATT00001..txt> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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
