Re: [OAUTH-WG] signatures, v2

[Dirk Balfanz <[e-mail]>]

On Thu, Jul 22, 2010 at 3:01 PM, Torsten Lodderstedt <
[e-mail]> wrote:

>
>  On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt <
> [e-mail]> wrote:
>
>> Hi Dirk,
>>
>> I have some questions concerning your proposal:
>>
>> - As far as I understand, the difference to "magic signatures" lays in the
>> usage of a JSON token carrying issuer, not_before, not_after and audience.
>> While such properties are important for security tokens (assertions), I
>> cannot see an advantage of using this format for signatures of HTTP
>> requests. Would you please explain?
>>
>
>  You mean advantage over magic signatures? It's really a similar idea -
> it's just that magic signatures as is don't quite fit the bill. For example,
> they have newlines in them:
> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5
>
>
> I mean, what is the reason for including issuer, not_before, not_after and
> audience into a signature?
>

If the attacker could change the audience field without invalidating the
token, then parties other than the one for which the token is intended could
be tricked into accepting it.
Similarly, if the attacker could change the not_before and not_after fields
without invalidating the token, then the attacker could re-use an old token
without detection.
I'm not sure what would happen if the issuer field was outside the signed
payload, but I'd rather be safe than sorry, and include it in the signature.


>   - Key management
>> From my point of view, your proposal does cover key management for web
>> applications using RSA signatures. What about web applications intending to
>> sign resource server requests using HMAC (for performance reasons)? Do they
>> need to exchange secrets with the resource server?
>>
>
>  Correct - I'm not saying how HMAC keys are being distributed. Presumably,
> you would use a similar system to what many platform providers use today -
> you sign up as a developer, and they give you a "developer key" (or "API
> key").
>
>
> Such a system will work for a relatively static relation between client and
> server only. Do you suggest a client should register with every resource
> server in advance?
>

I'm personally in favor of using RSA keys and not requiring registration,
but there are legitimate reasons for taking the opposite approach - for
example, resource servers might require registration because they want
developers to sign ToSs and such.


> What about dynamic clients? Suppose a client is just configured with a URL
> pointing to a PortableContacts resource. The client discovers the respective
> authz server and obtains a token. What if the client wants to sign the
> messages to the resource server?
>

I would propose to use RSA signing in this case.


>   What about installed applications (mobile, desktop, set top boxes,
>> gaming devices)?
>>
>
>  I don't think that installed apps can ever authenticate themselves (i.e.,
> prove the statement "I am a copy of the FooBar app"), so I'm not trying to
> solve that. What we _can_ do is deliver OAuth tokens to an installed app of
> the user's choice, but the server won't know who received the token - only
> the user does.
>
>
> I think we can do more. Even installed applications can use signatures to
> protect messages on transport. What about that use case? Clearly they need
> appropriate key material. The token secret  issued by the authorization
> server could server that purpose.
>

What would the purpose of that signature be? Let's look at a few
possibilities:

- "I prove that I'm really a copy of the FooBar app"? You're just not gonna
be able to do that, because client apps can't keep secrets.
- "I prove that I'm the legitimate holder of this token"? If you don't leak
the token, then presenting the token itself proves this. Use SSL if you're
worried about leaking the token in transport.
- "I prove that the request wasn't tampered with in transport."? Use SSL.

What do you think?

Dirk.


>
>
>
>>  1) RSA: Do they need to provide their public key on a web server? This
>> would be an additional requirement for such applications.
>>  2) HMAC: Same as for web apps, but even harder because either (a) the
>> installed app has a static secret burned
>> into source code or (b) it needs to use a protocol for dynamic key
>> management the resource server has to implement. Is this the plan?
>>
>>
> regards,
> Torsten.
>