Re: [OAUTH-WG] Basic signature support in the core specification

[Torsten Lodderstedt <[e-mail]>]

Am 25.09.2010 04:22, schrieb Eran Hammer-Lahav:
> OAuth 2.0 is far from being published as an RFC. I estimate it is at 
> least 6 months away from reaching final IESG approval, if not a year. 
> This is mostly due to a significant effort needed in writing and 
> reviewing the security considerations section which so far has 
> received no attention. 

FYI: Mark McGloin and me started to work on the security considerations. 
We will announce once we have collected and written down enough to share 
with the WG.

One thing we most likely will come up with is the question how to 
prevent token phishing and abuse by resource servers.

We already had a discussion about such threat scenarios in the WG when 
James H. Manger brought up his sites proposal 
(http://www.ietf.org/mail-archive/web/oauth/current/msg02343.html, 
detailed threat description in 
http://www.ietf.org/mail-archive/web/oauth/current/msg02366.html). Up to 
now, we don't have a solution in the draft.

A simple signature mechanism just for this purpose (not for client 
authentication, message integrity nor token/assertion integrity 
protection) is one option, James's proposal would be another. Since a 
lot of running code is out there for OAuth 1.0a signature, I'm fine with 
John's proposal. I would just recommend to drop the client secret from 
the signature calculation because not all clients will have a secret and 
making client secrets avalailable to resource servers causes other 
(scalability and security) problems. Using such a mechanism in 
combination with HTTPS should suffice.

In my perception from IETF 78, a lot of IETF people assess OAuth to fall 
back behind established IETF authentication & authorization protocols 
like Kerberos in terms of security. As far as I remember people were 
nearly shocked at the WG meeting to read the transmission of tokens (== 
credentials) over a secure channel is just a SHOULD and not a MUST. 
Moreover, the potential for token abuse became apparent instantely. In 
my opinion, we should work towards security improvements otherwise 
approval by IETF will be very hard.

regards,
Torsten.


> We can easily lock down the bearer token portions and continue working 
> on the spec. The argument that it needs to be published as an RFC for 
> companies to deploy is both irrelevant and untrue. Facebook and 
> Salesforce are two examples.
>
> If your entire argument is that waiting for a signature will delay 
> core, I am happy to promise that if the rest of the specification is 
> done, and signatures are the only thing holding it back from 
> publication, that we can take them out and publish.
>
> My main issue with a separate specification is that is sends a clear 
> (and misguided) message that signatures are some advance and complex 
> thing most developers should ignore. It promoted bearer tokens to be 
> the preferred implementation (in practice, an implied MUST) which will 
> render any signature work pointless (an afterthought MAY). By putting 
> it in the same specification (and I have clearly demonstrated that 
> this can be done in under 4 pages) we give developers a complete 
> picture and let them choose. We also get to call out the shortcomings 
> of using bearer tokens and directly point to one possible alternative.
>
> It is ridiculous how much time those opposed to signatures have wasted 
> by demanding justification, proposing complex replacements, or just 
> intentionally derailed any effort to come up with a simple signature 
> solution.
>
> If we can't quickly agree on a new signature, I am going to take 1.0a 
> and paste it into the specification. That will be sad and pathetic, 
> and will ignore our responsibility to move the web forward, but its 
> light years better than a specification with only bearer tokens.
>
> We have to find a quick way to compromise, or we will find ourselves 
> with plenty more issues to resolve. I know a few people (myself 
> included) who dropped their opposition to bearer tokens (especially 
> without requiring HTTPS) that will be inclined to bring this up again 
> and reopen the topic. It seems those who promote bearer tokens as the 
> core 2.0 protocol got everything they wanted but have not given an 
> inch so far.
>
> EHL
>
>
> On 9/24/10 4:26 PM, "John Panzer" <[e-mail]> wrote:
>
>     -1 on requiring it to be part of core OAuth2.  Reasoning: It won't
>     be a MUST or even SHOULD requirement for either client or server,
>     so adding it later does not affect interop.  The actual schedule
>     to finalize the signature mechanism should not be affected either
>     way -- it's fine for a WG to produce 2 or more RFCs if that's the
>     right thing to do.  (If there were consensus today on what exactly
>     the signing mechanism should be I'd think differently, but I don't
>     believe there is.)
>
>     Caveat:  If there were consensus that OAuth 2 should simply adopt
>     the OAuth 1.0a signature mechanism today, I'd be okay with that,
>     just because there is some proven code out there.
>
>     This is of course a trade-off.  My bias:  I really want us to
>     stabilize what has been spec'd so far and move forward with that
>     while additional work happens.  There are already multiple
>     mutually implementations of "OAuth2" floating around and I'd
>     rather resolve that quickly.
>     --
>     John Panzer / Google
>     [e-mail] / abstractioneer.org
>     <http://www.abstractioneer.org/>  / @jpanzer
>
>
>
>     On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav
>     <[e-mail]> wrote:
>
>         Since much of this recent debate was done off list, I'd like
>         to ask people
>         to simply express their support or objection to including a
>         basic signature
>         feature in the core spec, in line with the 1.0a signature
>         approach.
>
>         This is not a vote, just taking the temperature of the group.
>
>         EHL
>
>         _______________________________________________
>         OAuth mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth