Sure, and add to that using bearer tokens too (i.e. providers can choose to only support signed requests if that suits them).
EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Thursday, May 27, 2010 1:31 PM To: Allen Tom Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thanks, makes sense. +1 to SP's deciding on what signature mech is required :) On 5/27/10 4:08 PM, Allen Tom wrote: 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
