Re: [OAUTH-WG] Signatures, Why?

[Eve Maler]

Hi Brian,

On 16 Mar 2010, at 10:51 AM, Brian Eaton wrote:
> We didn't talk about the signed identity claims use case.  Some
> background on that is in this thread:
> 
> http://www.ietf.org/mail-archive/web/oauth/current/msg00530.html
> 
> Paul - does OpenSocial still need signed identity claims?
> 
> Eve - does UMA still need signed identity claims, or are you handling
> that outside of the OAuth spec?

UMA's core protocol is agnostic as to the format of the claims, though 
negotiating a desired claim format does have a few core-protocol implications.  
We anticipate that a couple of different formats are likely (strong interest 
has been expressed in SAML and JSON so far).

We do have use cases for third-party-asserted claims as well as self-asserted 
claims, and we anticipate that the former would be most easily solved (maybe 
"easily" should be in scare quotes) with signatures.  The use cases requiring 
this do tend to be for higher-security, higher-sensitivity applications 
(health, financial/insurance, etc.).

Note that by "claims", I'm referring here to the access authorization claims 
that an authorization manager would ask a requester to produce in order to 
prove suitability for getting access.  (The authorizing user might be 
delegating access to some protected web resource that contains identity claims 
about themselves; this is well outside the UMA core protocol.)

Eve

Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Panzer]

I would imagine that things like Content-Length: , Content-Encoding: and
Cache-Control: would be targets for attacks if they were not protected.
 There are also a lot of custom X- headers out there with unknown semantics.

BTW, another advantage of TLS is that it handles integrity of the HTTP
response as well.  I don't think the signing proposals include the response,
do they?

On Tue, Mar 16, 2010 at 11:50 AM, Zeltsan, Zachary (Zachary) <
zachary.zelt...@alcatel-lucent.com> wrote:

>
> >Would you care if some proxy or other intermediary changed the contents of
> >the Authorization HTTP header?
>
> In OAuth 1.0 the oauth_ parameters can be transmitted in the HTTP
> Authorization header - this is one of the options (and is the preferred
> one). In that case protection of the Authorization header's content is
> needed, but it is already provided by the signature. The parameter
> oauth_signature contains a signature over a string that includes the OAuth
> protocol parameters (excluding "oauth_signature").
>
> >How about if they changed the URL path passed or the HTTP method from GET
> >to POST?
>
> GET and POST (they are not parts of the HTTP headers) are also included in
> the signature base string in OAuth 1.0
>
> I believe that when OAuth parameters are transmitted in the Authorization
> header, OAuth 1.0 provides an adequate protection of that header's contents.
>
> Zachary
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> John Kemp
> Sent: Tuesday, March 16, 2010 9:45 AM
> To: Faynberg, Igor (Igor)
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Signatures, Why?
>
> On Mar 16, 2010, at 8:48 AM, Igor Faynberg wrote:
>
> > That's what I have been thinking. Why is it important to sign the
> headers?  (I am not against signing them, but I cannot see the need in the
> specific cases we had discussed. In other words, if I had signed the body of
> the request, I probably would not care if someone changed the headers.)
>
> Would you care if some proxy or other intermediary changed the contents of
> the Authorization HTTP header? How about if they changed the URL path passed
> or the HTTP method from GET to POST? Which other HTTP headers might you wish
> to be carried through intermediaries with the property of integrity?
>
> Regards,
>
> - johnk
>
> >
> > Igor
> >
> > Paul Lindner wrote:
> >> What about
> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html?
> >>
> >> That's in use and has been implemented in shindig for quite some time.
> >>
> >> That draft adds protection of the body -- I don't know of any draft that
> covers signing the headers...
> >>
> >>
> >> On Mon, Mar 15, 2010 at 11:22 PM, John Panzer  jpan...@google.com>> wrote:
> >>
> >>  I'm confused by one "pro" for signatures:
> >>
> >>  "Protect integrity of whole request - authorization data and
> >>  payload when communicating over unsecure channel"
> >>
> >>  I do not believe there is an existing concrete proposal that will
> >>  protect the whole request, unless you add additional restrictions
> >>  on the request types -- e.g., only HTTP GET or POST with
> >>  form-encoded data variables only.
> >>
> >>  If the assertion is that signatures will actually provide
> >>  integrity for arbitrary HTTP request bodies as well as the URL,
> >>  authority, and HTTP method:   I would like to see at least one
> >>  concrete proposal that will accomplish this.   IIRC there's only
> >>  one that I think is possibly implementable in an interoperable
> >>  way, and it supports only JSON payloads.  In other words, anyone
> >>  using body signing would need to wrap their data in JSON to do it.
> >>   (This is not necessarily the worst thing in the world, of course,
> >>  but it is something to be taken into account when listing pros and
> >>  cons.)
> >>
> >>  On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
> >>  mailto:tors...@lodderstedt.net>> wrote:
> >>
> >>  Hi all,
> >>
> >>  I composed a detailed summary at
> >>  http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
> >>  Please review it.
> >>
> >>  @Zachary: I also added some of your recent notes.
> >>
> >>  regards,
> >>  Torsten.
> >>
> >>>  I volunteer to write it up.
> >>>>  
> >>

Re: [OAUTH-WG] Signatures, Why?

[Zeltsan, Zachary (Zachary)]

>Would you care if some proxy or other intermediary changed the contents of 
>>the Authorization HTTP header? 

In OAuth 1.0 the oauth_ parameters can be transmitted in the HTTP Authorization 
header - this is one of the options (and is the preferred one). In that case 
protection of the Authorization header's content is needed, but it is already 
provided by the signature. The parameter oauth_signature contains a signature 
over a string that includes the OAuth protocol parameters (excluding 
"oauth_signature").

>How about if they changed the URL path passed or the HTTP method from GET >to 
>POST? 

GET and POST (they are not parts of the HTTP headers) are also included in the 
signature base string in OAuth 1.0

I believe that when OAuth parameters are transmitted in the Authorization 
header, OAuth 1.0 provides an adequate protection of that header's contents.

Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John 
Kemp
Sent: Tuesday, March 16, 2010 9:45 AM
To: Faynberg, Igor (Igor)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Signatures, Why?

On Mar 16, 2010, at 8:48 AM, Igor Faynberg wrote:

> That's what I have been thinking. Why is it important to sign the headers?  
> (I am not against signing them, but I cannot see the need in the specific 
> cases we had discussed. In other words, if I had signed the body of the 
> request, I probably would not care if someone changed the headers.)

Would you care if some proxy or other intermediary changed the contents of the 
Authorization HTTP header? How about if they changed the URL path passed or the 
HTTP method from GET to POST? Which other HTTP headers might you wish to be 
carried through intermediaries with the property of integrity? 

Regards,

- johnk

> 
> Igor
> 
> Paul Lindner wrote:
>> What about  
>> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html ? 
>> 
>> That's in use and has been implemented in shindig for quite some time.
>> 
>> That draft adds protection of the body -- I don't know of any draft that 
>> covers signing the headers...
>> 
>> 
>> On Mon, Mar 15, 2010 at 11:22 PM, John Panzer > <mailto:jpan...@google.com>> wrote:
>> 
>>  I'm confused by one "pro" for signatures:
>> 
>>  "Protect integrity of whole request - authorization data and
>>  payload when communicating over unsecure channel"
>> 
>>  I do not believe there is an existing concrete proposal that will
>>  protect the whole request, unless you add additional restrictions
>>  on the request types -- e.g., only HTTP GET or POST with
>>  form-encoded data variables only.
>> 
>>  If the assertion is that signatures will actually provide
>>  integrity for arbitrary HTTP request bodies as well as the URL,
>>  authority, and HTTP method:   I would like to see at least one
>>  concrete proposal that will accomplish this.   IIRC there's only
>>  one that I think is possibly implementable in an interoperable
>>  way, and it supports only JSON payloads.  In other words, anyone
>>  using body signing would need to wrap their data in JSON to do it.
>>   (This is not necessarily the worst thing in the world, of course,
>>  but it is something to be taken into account when listing pros and
>>  cons.)
>> 
>>  On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
>>  mailto:tors...@lodderstedt.net>> wrote:
>> 
>>  Hi all,
>> 
>>  I composed a detailed summary at
>>  http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
>>  Please review it.
>> 
>>  @Zachary: I also added some of your recent notes.
>> 
>>  regards,
>>  Torsten.
>> 
>>>  I volunteer to write it up.
>>>>  
>>>> 
>>>>  On 3/4/10 1:00 PM, Blaine Cook wrote:
>>>> 
>>>>>  One of the things that's been a primary focus of both today's WG call
>>>>>  and last week's call is what are the specific use cases for
>>>>>  signatures?
>>>>> 
>>>>>  - Why are signatures needed?
>>>>>  - What do signatures need to protect?
>>>>> 
>>>>>  Let's try to outline the use cases! Please reply here, so that we 
>>>>> have
>>>>>  a good idea of what they are as we move towards the Anaheim WG.
>>>>> 
>>>>  This was a valuable thread. Perhaps someone could write up a summary 
>>>> of
>>>>  t

Re: [OAUTH-WG] Signatures, Why?

[John Panzer]

SGTM -- I think the tradeoff is interoperable and simple hop-based integrity
protection (assuming existing TLS libraries exist) vs. more complicated but
full end to end integrity protection (and libraries need to be written).

On Tue, Mar 16, 2010 at 7:11 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>  Hi John,
>
> following your arguments, I could add "integrity protection of complete
> HTTP requests in an interoperable way" the the "pro HTTPS" section?
>
> regards,
> Torsten.
>
> Am 16.03.2010 07:22, schrieb John Panzer:
>
> I'm confused by one "pro" for signatures:
>
>  "Protect integrity of whole request - authorization data and payload when
> communicating over unsecure channel"
>
>  I do not believe there is an existing concrete proposal that will protect
> the whole request, unless you add additional restrictions on the request
> types -- e.g., only HTTP GET or POST with form-encoded data variables only.
>
>  If the assertion is that signatures will actually provide integrity for
> arbitrary HTTP request bodies as well as the URL, authority, and HTTP
> method:   I would like to see at least one concrete proposal that will
> accomplish this.   IIRC there's only one that I think is possibly
> implementable in an interoperable way, and it supports only JSON payloads.
>  In other words, anyone using body signing would need to wrap their data in
> JSON to do it.  (This is not necessarily the worst thing in the world, of
> course, but it is something to be taken into account when listing pros and
> cons.)
>
> On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> I composed a detailed summary at
>> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please
>> review it.
>>
>> @Zachary: I also added some of your recent notes.
>>
>> regards,
>> Torsten.
>>
>>  I volunteer to write it up.
>>
>> 
>>
>> On 3/4/10 1:00 PM, Blaine Cook wrote:
>>
>>
>>  One of the things that's been a primary focus of both today's WG call
>> and last week's call is what are the specific use cases for
>> signatures?
>>
>> - Why are signatures needed?
>> - What do signatures need to protect?
>>
>> Let's try to outline the use cases! Please reply here, so that we have
>> a good idea of what they are as we move towards the Anaheim WG.
>>
>>
>>  This was a valuable thread. Perhaps someone could write up a summary of
>> the points raised, either on the list or at the wiki?
>>
>> Peter
>>
>>
>>
>>
>> ___
>> OAuth mailing listoa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> ___
>> OAuth mailing listoa...@ietf.orghttps://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

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
 wrote:
> Hi all,
>
> I composed a detailed summary at
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please review
> it.

We didn't talk about the signed identity claims use case.  Some
background on that is in this thread:

http://www.ietf.org/mail-archive/web/oauth/current/msg00530.html

Paul - does OpenSocial still need signed identity claims?

Eve - does UMA still need signed identity claims, or are you handling
that outside of the OAuth spec?

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Ethan Jewett]

Thanks Thorsten, this is good.

The "Pro Signature" section seemed a little thin to me (pro HTTPS too,
though most security pros are included obliquely in the "Powerful"
bullet). I changed the "Pro Signature" section to:

 * Low latency and computational costs (HMAC)
 * Provides for authentication of request by proving possession of a
secret that is bound to an account (in OAuth 1.0a)
 * Can provide message integrity (in OAuth 1.0a for single-part
form-encoded requests, for query strings, and for request bodies under
the body-signing extension)
 * Can provide replay protection via signed nonces (in OAuth 1.0a)
 * Can provide expiration via signed timestamps (in OAuth 1.0a)

Ethan

On Mon, Mar 15, 2010 at 6:50 PM, Torsten Lodderstedt
 wrote:
> Hi all,
>
> I composed a detailed summary at
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please review
> it.
>
> @Zachary: I also added some of your recent notes.
>
> regards,
> Torsten.
>
> I volunteer to write it up.
>
> 
>
> On 3/4/10 1:00 PM, Blaine Cook wrote:
>
>
> One of the things that's been a primary focus of both today's WG call
> and last week's call is what are the specific use cases for
> signatures?
>
> - Why are signatures needed?
> - What do signatures need to protect?
>
> Let's try to outline the use cases! Please reply here, so that we have
> a good idea of what they are as we move towards the Anaheim WG.
>
>
> This was a valuable thread. Perhaps someone could write up a summary of
> the points raised, either on the list or at the wiki?
>
> Peter
>
>
>
> ___
> 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

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

Hi John,

following your arguments, I could add "integrity protection of complete 
HTTP requests in an interoperable way" the the "pro HTTPS" section?


regards,
Torsten.

Am 16.03.2010 07:22, schrieb John Panzer:

I'm confused by one "pro" for signatures:

"Protect integrity of whole request - authorization data and payload 
when communicating over unsecure channel"


I do not believe there is an existing concrete proposal that will 
protect the whole request, unless you add additional restrictions on 
the request types -- e.g., only HTTP GET or POST with form-encoded 
data variables only.


If the assertion is that signatures will actually provide integrity 
for arbitrary HTTP request bodies as well as the URL, authority, and 
HTTP method:   I would like to see at least one concrete proposal that 
will accomplish this.   IIRC there's only one that I think is possibly 
implementable in an interoperable way, and it supports only JSON 
payloads.  In other words, anyone using body signing would need to 
wrap their data in JSON to do it.  (This is not necessarily the worst 
thing in the world, of course, but it is something to be taken into 
account when listing pros and cons.)


On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


Hi all,

I composed a detailed summary at
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
Please review it.

@Zachary: I also added some of your recent notes.

regards,
Torsten.


I volunteer to write it up.



On 3/4/10 1:00 PM, Blaine Cook wrote:
   

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.
 

This was a valuable thread. Perhaps someone could write up a summary of
the points raised, either on the list or at the wiki?

Peter

   



___
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

Re: [OAUTH-WG] Signatures, Why?

[John Kemp]

On Mar 16, 2010, at 8:48 AM, Igor Faynberg wrote:

> That's what I have been thinking. Why is it important to sign the headers?  
> (I am not against signing them, but I cannot see the need in the specific 
> cases we had discussed. In other words, if I had signed the body of the 
> request, I probably would not care if someone changed the headers.)

Would you care if some proxy or other intermediary changed the contents of the 
Authorization HTTP header? How about if they changed the URL path passed or the 
HTTP method from GET to POST? Which other HTTP headers might you wish to be 
carried through intermediaries with the property of integrity? 

Regards,

- johnk

> 
> Igor
> 
> Paul Lindner wrote:
>> What about  
>> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html ? 
>> 
>> That's in use and has been implemented in shindig for quite some time.
>> 
>> That draft adds protection of the body -- I don't know of any draft that 
>> covers signing the headers...
>> 
>> 
>> On Mon, Mar 15, 2010 at 11:22 PM, John Panzer > > wrote:
>> 
>>  I'm confused by one "pro" for signatures:
>> 
>>  "Protect integrity of whole request - authorization data and
>>  payload when communicating over unsecure channel"
>> 
>>  I do not believe there is an existing concrete proposal that will
>>  protect the whole request, unless you add additional restrictions
>>  on the request types -- e.g., only HTTP GET or POST with
>>  form-encoded data variables only.
>> 
>>  If the assertion is that signatures will actually provide
>>  integrity for arbitrary HTTP request bodies as well as the URL,
>>  authority, and HTTP method:   I would like to see at least one
>>  concrete proposal that will accomplish this.   IIRC there's only
>>  one that I think is possibly implementable in an interoperable
>>  way, and it supports only JSON payloads.  In other words, anyone
>>  using body signing would need to wrap their data in JSON to do it.
>>   (This is not necessarily the worst thing in the world, of course,
>>  but it is something to be taken into account when listing pros and
>>  cons.)
>> 
>>  On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
>>  mailto:tors...@lodderstedt.net>> wrote:
>> 
>>  Hi all,
>> 
>>  I composed a detailed summary at
>>  http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
>>  Please review it.
>> 
>>  @Zachary: I also added some of your recent notes.
>> 
>>  regards,
>>  Torsten.
>> 
>>>  I volunteer to write it up.
  
 
  On 3/4/10 1:00 PM, Blaine Cook wrote:
 
>  One of the things that's been a primary focus of both today's WG call
>  and last week's call is what are the specific use cases for
>  signatures?
> 
>  - Why are signatures needed?
>  - What do signatures need to protect?
> 
>  Let's try to outline the use cases! Please reply here, so that we 
> have
>  a good idea of what they are as we move towards the Anaheim WG.
> 
  This was a valuable thread. Perhaps someone could write up a summary 
 of
  the points raised, either on the list or at the wiki?
 
  Peter
 
 
 
  ___
  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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

I think signing Authorization Headers would make sense.

regards,
Torsten.

Am 16.03.2010 07:48, schrieb Igor Faynberg:
That's what I have been thinking. Why is it important to sign the 
headers?  (I am not against signing them, but I cannot see the need in 
the specific cases we had discussed. In other words, if I had signed 
the body of the request, I probably would not care if someone changed 
the headers.)


Igor

Paul Lindner wrote:
What about  
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html 
?


That's in use and has been implemented in shindig for quite some time.

That draft adds protection of the body -- I don't know of any draft 
that covers signing the headers...



On Mon, Mar 15, 2010 at 11:22 PM, John Panzer > wrote:


I'm confused by one "pro" for signatures:

"Protect integrity of whole request - authorization data and
payload when communicating over unsecure channel"

I do not believe there is an existing concrete proposal that will
protect the whole request, unless you add additional restrictions
on the request types -- e.g., only HTTP GET or POST with
form-encoded data variables only.

If the assertion is that signatures will actually provide
integrity for arbitrary HTTP request bodies as well as the URL,
authority, and HTTP method:   I would like to see at least one
concrete proposal that will accomplish this.   IIRC there's only
one that I think is possibly implementable in an interoperable
way, and it supports only JSON payloads.  In other words, anyone
using body signing would need to wrap their data in JSON to do it.
 (This is not necessarily the worst thing in the world, of course,
but it is something to be taken into account when listing pros and
cons.)

On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:

Hi all,

I composed a detailed summary at
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
Please review it.

@Zachary: I also added some of your recent notes.

regards,
Torsten.


I volunteer to write it up.



On 3/4/10 1:00 PM, Blaine Cook wrote:
One of the things that's been a primary focus of both 
today's WG call

and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so 
that we have
a good idea of what they are as we move towards the 
Anaheim WG.
This was a valuable thread. Perhaps someone could write up 
a summary of

the points raised, either on the list or at the wiki?

Peter



___
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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

That's what I have been thinking. Why is it important to sign the 
headers?  (I am not against signing them, but I cannot see the need in 
the specific cases we had discussed. In other words, if I had signed the 
body of the request, I probably would not care if someone changed the 
headers.)


Igor

Paul Lindner wrote:
What about  
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html ? 



That's in use and has been implemented in shindig for quite some time.

That draft adds protection of the body -- I don't know of any draft 
that covers signing the headers...



On Mon, Mar 15, 2010 at 11:22 PM, John Panzer > wrote:


I'm confused by one "pro" for signatures:

"Protect integrity of whole request - authorization data and
payload when communicating over unsecure channel"

I do not believe there is an existing concrete proposal that will
protect the whole request, unless you add additional restrictions
on the request types -- e.g., only HTTP GET or POST with
form-encoded data variables only.

If the assertion is that signatures will actually provide
integrity for arbitrary HTTP request bodies as well as the URL,
authority, and HTTP method:   I would like to see at least one
concrete proposal that will accomplish this.   IIRC there's only
one that I think is possibly implementable in an interoperable
way, and it supports only JSON payloads.  In other words, anyone
using body signing would need to wrap their data in JSON to do it.
 (This is not necessarily the worst thing in the world, of course,
but it is something to be taken into account when listing pros and
cons.)

On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:

Hi all,

I composed a detailed summary at
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
Please review it.

@Zachary: I also added some of your recent notes.

regards,
Torsten.


I volunteer to write it up.



On 3/4/10 1:00 PM, Blaine Cook wrote:
  

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.


This was a valuable thread. Perhaps someone could write up a summary of
the points raised, either on the list or at the wiki?

Peter

  



___
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

Re: [OAUTH-WG] Signatures, Why?

[Paul Lindner]

What about
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html ?

That's in use and has been implemented in shindig for quite some time.

That draft adds protection of the body -- I don't know of any draft that
covers signing the headers...


On Mon, Mar 15, 2010 at 11:22 PM, John Panzer  wrote:

> I'm confused by one "pro" for signatures:
>
> "Protect integrity of whole request - authorization data and payload when
> communicating over unsecure channel"
>
> I do not believe there is an existing concrete proposal that will protect
> the whole request, unless you add additional restrictions on the request
> types -- e.g., only HTTP GET or POST with form-encoded data variables only.
>
> If the assertion is that signatures will actually provide integrity for
> arbitrary HTTP request bodies as well as the URL, authority, and HTTP
> method:   I would like to see at least one concrete proposal that will
> accomplish this.   IIRC there's only one that I think is possibly
> implementable in an interoperable way, and it supports only JSON payloads.
>  In other words, anyone using body signing would need to wrap their data in
> JSON to do it.  (This is not necessarily the worst thing in the world, of
> course, but it is something to be taken into account when listing pros and
> cons.)
>
> On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>>  Hi all,
>>
>> I composed a detailed summary at
>> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please
>> review it.
>>
>> @Zachary: I also added some of your recent notes.
>>
>> regards,
>> Torsten.
>>
>>  I volunteer to write it up.
>>
>> 
>>
>> On 3/4/10 1:00 PM, Blaine Cook wrote:
>>
>>
>>  One of the things that's been a primary focus of both today's WG call
>> and last week's call is what are the specific use cases for
>> signatures?
>>
>> - Why are signatures needed?
>> - What do signatures need to protect?
>>
>> Let's try to outline the use cases! Please reply here, so that we have
>> a good idea of what they are as we move towards the Anaheim WG.
>>
>>
>>  This was a valuable thread. Perhaps someone could write up a summary of
>> the points raised, either on the list or at the wiki?
>>
>> Peter
>>
>>
>>
>>
>> ___
>> OAuth mailing listoa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> ___
>> OAuth mailing listoa...@ietf.orghttps://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

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Mon, Mar 15, 2010 at 11:22 PM, John Panzer  wrote:
> I would like to see at least one concrete proposal that will
> accomplish this.

I think this goes for pretty much any of the requirements that have
been discussed. =)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Panzer]

I'm confused by one "pro" for signatures:

"Protect integrity of whole request - authorization data and payload when
communicating over unsecure channel"

I do not believe there is an existing concrete proposal that will protect
the whole request, unless you add additional restrictions on the request
types -- e.g., only HTTP GET or POST with form-encoded data variables only.

If the assertion is that signatures will actually provide integrity for
arbitrary HTTP request bodies as well as the URL, authority, and HTTP
method:   I would like to see at least one concrete proposal that will
accomplish this.   IIRC there's only one that I think is possibly
implementable in an interoperable way, and it supports only JSON payloads.
 In other words, anyone using body signing would need to wrap their data in
JSON to do it.  (This is not necessarily the worst thing in the world, of
course, but it is something to be taken into account when listing pros and
cons.)

On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>  Hi all,
>
> I composed a detailed summary at
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please review
> it.
>
> @Zachary: I also added some of your recent notes.
>
> regards,
> Torsten.
>
>  I volunteer to write it up.
>
> 
>
> On 3/4/10 1:00 PM, Blaine Cook wrote:
>
>
>  One of the things that's been a primary focus of both today's WG call
> and last week's call is what are the specific use cases for
> signatures?
>
> - Why are signatures needed?
> - What do signatures need to protect?
>
> Let's try to outline the use cases! Please reply here, so that we have
> a good idea of what they are as we move towards the Anaheim WG.
>
>
>  This was a valuable thread. Perhaps someone could write up a summary of
> the points raised, either on the list or at the wiki?
>
> Peter
>
>
>
>
> ___
> OAuth mailing listoa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing listoa...@ietf.orghttps://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

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

Hi all,

I composed a detailed summary at 
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please 
review it.


@Zachary: I also added some of your recent notes.

regards,
Torsten.

I volunteer to write it up.



On 3/4/10 1:00 PM, Blaine Cook wrote:
   

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.
 

This was a valuable thread. Perhaps someone could write up a summary of
the points raised, either on the list or at the wiki?

Peter

   



___
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

Re: [OAUTH-WG] Signatures, Why?

[Zeltsan, Zachary (Zachary)]

My highlights of the points raised on this thread are as follows:

A Client needs to sign a request for the temporary credentials to:
* Authenticate to the server
* Provide means for ensuring that a request has not been modified

A Client needs to sign a request for the token credentials to:
* Ensure that of all the legitimate Clients only the Client authorized by the 
Resource Owner can access the resource
* Provide means for ensuring that a request has not been modified

If a request is signed with the client's private key it can be used for 
providing non-repudiation; an alternative solution for non-repudiation would 
require involvement of a third party.

There are use cases where non-repudiation is needed.

TLS protects only a session, not the data that need to be re-used later. Unless 
the whole session has been recorded and its key has been stored, the TLS does 
not provide non-repudiation.

It appears that there is a consensus in UMA community that signing should 
remain an option for enabling authentication and auditing.

There are use cases for which performance of a TLS-based solution would be 
worse than that of the signature-based solution.

The signatures are widely used for providing security over the insecure 
channels in today's implementations. There is a view that the signature-based 
method should remain an option for providing security over an insecure channel.

Zachary

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter 
Saint-Andre
Sent: Thursday, March 11, 2010 10:20 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Signatures, Why?



On 3/4/10 1:00 PM, Blaine Cook wrote:
> One of the things that's been a primary focus of both today's WG call
> and last week's call is what are the specific use cases for
> signatures?
>
> - Why are signatures needed?
> - What do signatures need to protect?
>
> Let's try to outline the use cases! Please reply here, so that we have
> a good idea of what they are as we move towards the Anaheim WG.

This was a valuable thread. Perhaps someone could write up a summary of
the points raised, either on the list or at the wiki?

Peter

--
Peter Saint-Andre
https://stpeter.im/




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Eve Maler]

Agreed that token signing is separate from message signing as a proposition.  I 
just happened to stick all of our "signing" conversations into one bucket of 
notes...  Sorry that was confusing.

Eve

On 12 Mar 2010, at 11:06 AM, Brian Eaton wrote:

> On Fri, Mar 12, 2010 at 10:22 AM, Eve Maler  wrote:
>> It was observed that the argument in the OAuth community about token size
>> seems to be related to token signing, thusly: those who are willing to
>> require the Authorization Server to be stateless need large meaningful
>> tokens and want them signed; those who can use a stateful Authorization
>> Server can use small opaque tokens that don't need signing.
> 
> This seems orthogonal.  The confusion in this working group has not,
> for the most part, been about whether access tokens should be signed.
> 
> The debate has been more about whether clients need to use signatures
> when requesting access tokens, or when using access tokens.  On one
> side there are people who would prefer bearer tokens, and on the other
> side there are folks who want crypto in various bits of the protocol
> to meet different use cases.
> 
> Cheers,
> Brian


Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Yes, the third-party-based non-repudiation with symmetric cryptography 
is a complex thing.  The way I would apply it to the Client request  is 
as follows:


1)  The Client sends the token request, R, to the Third Party (and, you 
are right, the Third Party must know who the client is, and so  one 
shared secret is needed right there, given that there is no public key 
cryptography; so this secret is used to sign R);


2) The Third Party hashes the request using a secret that *only the 
Third Party knows* and sends this quantity, Q, back to the Client;


3) Now the Client sends to the server (R, Q).

The server could now go back to the Third Party and ask if Q is indeed 
what it had given. To eliminate this step, the Third Party can either 
encrypt (R, Q) with the secret shared with the server, or sign it with 
its secret, and return the resulting quantity, Q', to the Client.


The requirement her is that the Third Party must be trusted  by both the 
Client and the Server and--in addition--it must be trusted by the court, 
which could verify with the Third Party that it indeed has computed Q. 
(Verification, I understand, should be done involving a real person 
because, in general, escrowing signature keys makes signatures invalid.)


Igor

Dick Hardt wrote:

Hi Igor

Thanks for explanation. Unfortunately I am more  confused. How does the third 
party know who the Client is?

I don't understand how an Access Token plus a signing secret gives any more 
assurance than an Access Token unless I get the Access Token from a different 
place than the signing secret. Is that what I am missing?

-- Dick

On 2010-03-12, at 11:38 AM, Igor Faynberg wrote:

  

Dick,

The trick here is THE THIRD PARTY (referred to in the last words of Eve's 
message), who is effectively a witness to the transaction. (This works pretty 
much like when you want to switch your telephone provider. You would be 
transferred to the third party to confirm your request.) Absent of the 
private-key signature, this is the only known way to ensure non-repudiation.

Igor

Dick Hardt wrote:


On 2010-03-12, at 10:22 AM, Eve Maler wrote:

  

This nets out to the requesting party (person or company seeking access) having an 
incentive to say "It's really me accessing this", such that it mitigates the 
risk that the requester (client) will hand off both the access token and the signing 
secret to a third party.


Note I am NOT a security expert, and would appreciate an education on where I 
am wrong.

When I look at this, I question if there really is that much more value in the Client having two secret items over one secret item. 
I can see an advantage with something like using RAS, in that only the Client should have the private key, and if the private key can be used for lots of things, then there is some difference between a token and the private key. With symmetric keys, multiple parties have the keys, so non-repudiation is not possible.


-- Dick


___
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

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

Hi Igor

Thanks for explanation. Unfortunately I am more  confused. How does the third 
party know who the Client is?

I don't understand how an Access Token plus a signing secret gives any more 
assurance than an Access Token unless I get the Access Token from a different 
place than the signing secret. Is that what I am missing?

-- Dick

On 2010-03-12, at 11:38 AM, Igor Faynberg wrote:

> Dick,
> 
> The trick here is THE THIRD PARTY (referred to in the last words of Eve's 
> message), who is effectively a witness to the transaction. (This works pretty 
> much like when you want to switch your telephone provider. You would be 
> transferred to the third party to confirm your request.) Absent of the 
> private-key signature, this is the only known way to ensure non-repudiation.
> 
> Igor
> 
> Dick Hardt wrote:
>> 
>> On 2010-03-12, at 10:22 AM, Eve Maler wrote:
>> 
>>> This nets out to the requesting party (person or company seeking access) 
>>> having an incentive to say "It's really me accessing this", such that it 
>>> mitigates the risk that the requester (client) will hand off both the 
>>> access token and the signing secret to a third party.
>> 
>> Note I am NOT a security expert, and would appreciate an education on where 
>> I am wrong.
>> 
>> When I look at this, I question if there really is that much more value in 
>> the Client having two secret items over one secret item. 
>> I can see an advantage with something like using RAS, in that only the 
>> Client should have the private key, and if the private key can be used for 
>> lots of things, then there is some difference between a token and the 
>> private key. With symmetric keys, multiple parties have the keys, so 
>> non-repudiation is not possible.
>> 
>> -- Dick
>> 
>> 
>> ___
>> 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

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Dick,

The trick here is THE THIRD PARTY (referred to in the last words of 
Eve's message), who is effectively a witness to the transaction. (This 
works pretty much like when you want to switch your telephone provider. 
You would be transferred to the third party to confirm your request.) 
Absent of the private-key signature, this is the only known way to 
ensure non-repudiation.


Igor

Dick Hardt wrote:


On 2010-03-12, at 10:22 AM, Eve Maler wrote:

This nets out to the requesting party (person or company seeking 
access) having an incentive to say "It's really me accessing this", 
such that it mitigates the risk that the requester (client) will hand 
off both the access token and the signing secret to a third party.


Note I am NOT a security expert, and would appreciate an education on 
where I am wrong.


When I look at this, I question if there really is that much more 
value in the Client having two secret items over one secret item. 

I can see an advantage with something like using RAS, in that only the 
Client should have the private key, and if the private key can be used 
for lots of things, then there is some difference between a token and 
the private key. With symmetric keys, multiple parties have the keys, 
so non-repudiation is not possible.


-- Dick


___
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

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Fri, Mar 12, 2010 at 10:22 AM, Eve Maler  wrote:
> It was observed that the argument in the OAuth community about token size
> seems to be related to token signing, thusly: those who are willing to
> require the Authorization Server to be stateless need large meaningful
> tokens and want them signed; those who can use a stateful Authorization
> Server can use small opaque tokens that don't need signing.

This seems orthogonal.  The confusion in this working group has not,
for the most part, been about whether access tokens should be signed.

The debate has been more about whether clients need to use signatures
when requesting access tokens, or when using access tokens.  On one
side there are people who would prefer bearer tokens, and on the other
side there are folks who want crypto in various bits of the protocol
to meet different use cases.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-12, at 10:22 AM, Eve Maler wrote:

> This nets out to the requesting party (person or company seeking access) 
> having an incentive to say "It's really me accessing this", such that it 
> mitigates the risk that the requester (client) will hand off both the access 
> token and the signing secret to a third party.


Note I am NOT a security expert, and would appreciate an education on where I 
am wrong.

When I look at this, I question if there really is that much more value in the 
Client having two secret items over one secret item. 

I can see an advantage with something like using RAS, in that only the Client 
should have the private key, and if the private key can be used for lots of 
things, then there is some difference between a token and the private key. With 
symmetric keys, multiple parties have the keys, so non-repudiation is not 
possible.

-- Dick___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Eve Maler]

Here is some late input to this thread.  The UMA group had a F2F meeting on 
Wednesday, for which draft minutes are written up here:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-10

I had taken an action from the last OAuth telecon to collect UMA use cases that 
related to the "signature question(s)".  I have reproduced the various meeting 
notes on this point below. In essence, the UMA group continued to agree that 
message signing should remain an option, even with SSL in the picture, for 
authentication and auditing reasons.

Note that Tom Holodnik of Intuit took away an action item to formally write up 
and submit the small-business UMA scenarios he's been referring to in our 
ongoing work (hinted at below), so we expect those soon. The health-data 
scenario at http://kantarainitiative.org/confluence/display/uma/hdata_scenario 
is also likely to have higher security and service-authentication requirements 
that could end up demanding message signing.  Other submitted scenarios, so 
far, seem to have security requirements that are less stringent.

(I'll send another message in a moment on our discussion of the token 
validation question.)

Eve


Signing: Using today's WRAP, an UMA authorizing user can't be absolutely sure 
(based on a signed message) who accessed his protected resource, other than the 
client's IP address. It's only indirectly known by the AM, and that's only if a 
user policy made the AM demand some claim from the requester, and even so the 
authentication is at a "higher" level of the stack. So wherever there's a use 
case that requires that the access token be bound to the requester who wields 
it, we need signatures.

This nets out to the requesting party (person or company seeking access) having 
an incentive to say "It's really me accessing this", such that it mitigates the 
risk that the requester (client) will hand off both the access token and the 
signing secret to a third party. Online banking might rise to this level. But 
if you install TurboTax on your PC, is it likelier that you the requesting user 
would sign something that gets bound to your TurboTax instance, or sign 
something that gets handed to your TurboTax instance as a bearer token that 
they use on your behalf without the binding? TomH feels that, yes, it's quite 
possible for this to be a value-add provided by something like TurboTax as a 
"trusted computing" offering.

It was observed that the argument in the OAuth community about token size seems 
to be related to token signing, thusly: those who are willing to require the 
Authorization Server to be stateless need large meaningful tokens and want them 
signed; those who can use a stateful Authorization Server can use small opaque 
tokens that don't need signing.


On 11 Mar 2010, at 9:56 PM, Torsten Lodderstedt wrote:

> I volunteer to write it up.
>> 
>> 
>> On 3/4/10 1:00 PM, Blaine Cook wrote:
>>   
>>> One of the things that's been a primary focus of both today's WG call
>>> and last week's call is what are the specific use cases for
>>> signatures?
>>> 
>>> - Why are signatures needed?
>>> - What do signatures need to protect?
>>> 
>>> Let's try to outline the use cases! Please reply here, so that we have
>>> a good idea of what they are as we move towards the Anaheim WG.
>>> 
>> This was a valuable thread. Perhaps someone could write up a summary of
>> the points raised, either on the list or at the wiki?
>> 
>> Peter


Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

I volunteer to write it up.



On 3/4/10 1:00 PM, Blaine Cook wrote:
   

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.
 

This was a valuable thread. Perhaps someone could write up a summary of
the points raised, either on the list or at the wiki?

Peter

   



___
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

Re: [OAUTH-WG] Signatures, Why?

[Peter Saint-Andre]

On 3/4/10 1:00 PM, Blaine Cook wrote:
> One of the things that's been a primary focus of both today's WG call
> and last week's call is what are the specific use cases for
> signatures?
> 
> - Why are signatures needed?
> - What do signatures need to protect?
> 
> Let's try to outline the use cases! Please reply here, so that we have
> a good idea of what they are as we move towards the Anaheim WG.

This was a valuable thread. Perhaps someone could write up a summary of
the points raised, either on the list or at the wiki?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Ah, now I think I figured it out: x/s means x operations per second. 
(Initially, I thought x was the time it took to perform an operation, 
and /s was some time measured in one or other fraction of a second.)


Thanks!

Igor

P.S.:Just to state my preferences: I am actually very much for the 
public-key cryptography as the means of solving IdM problems. We have on 
the record the whole nation (Estonia) having moved to PKI, where people 
sign their votes with their private keys. That convinces me that it sort 
of scales, although I know that there are opinions.


Torsten Lodderstedt wrote:


RSA/1024:  70/s (sign), 1250/s (verify)



And so my question here is: What was the reason for choosing a 
private key short here?
I don't understand your point. I measured the number of sign/verify 
operations per second and the results show verification (the public 
key operation) is significantly faster then signing.










___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

Hi Igor,
I don't consider RSA a good option for signing requests from consumer 
to resources because of its performance
characteristics. Symmetric algorithms like HMAC are by magnitudes 
faster. I did some benachmarking in
a project in 2006. The measurements have been taken on a Windows PC  
(Intel Pentium M 1,7 GHz/1GB)

with Java 1.5.

HMAC-MD5: 33000/s (sign and verify)
RSA/512:  434/s (sign), 3300/s (verify)
RSA/1024:  70/s (sign), 1250/s (verify)

As you can see, there is a factor of 10 (verify) to 300 (sign) 
between RSA and HMAC-MD5. Today one would use
HMAC-SHA and probably RSA/2048 so I don't expect the proportions to 
be better for RSA.




...
As I mentioned sometime before, I believe that we should refer to 
private-key signing rather than RSA, which is just one algorithm that 
performs public/private key encryption. (For instance, ECC is another 
algorithm, and it is much faster.)


I know that, but the discussion was about RSA. So I refered to this 
term. Everything I said about RSA also holds for other public key 
algorithms. In fact I did the same benchmarking for ECC with comparable 
results. In my experiences, ECC mainly has the advantage of using much 
shorter keys then RSA.


And, with many thanks to Torsten for providing the 
measurements--always a good thing!--I am puzzled by an apparent 
reversal in the duration of signing and verification times.  
Typically, for the encryption, the RSA keys are chosen to be small so 
that public key operations are fast; that results in the private key 
operations being slow. It appears to me that the same choice makes 
sense for signatures. One party spends time ONCE signing something, 
and then verification, performed by others, is fast.
And so my question here is: What was the reason for choosing a private 
key short here?
I don't understand your point. I measured the number of sign/verify 
operations per second and the results show verification (the public key 
operation) is significantly faster then signing.


regards,
Torsten.

With thanks,

Igor





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Torsten Lodderstedt wrote:

...
I don't consider RSA a good option for signing requests from consumer 
to resources because of its performance
characteristics. Symmetric algorithms like HMAC are by magnitudes 
faster. I did some benachmarking in
a project in 2006. The measurements have been taken on a Windows PC  
(Intel Pentium M 1,7 GHz/1GB)

with Java 1.5.

HMAC-MD5: 33000/s (sign and verify)
RSA/512:  434/s (sign), 3300/s (verify)
RSA/1024:  70/s (sign), 1250/s (verify)

As you can see, there is a factor of 10 (verify) to 300 (sign) between 
RSA and HMAC-MD5. Today one would use
HMAC-SHA and probably RSA/2048 so I don't expect the proportions to be 
better for RSA.



As I mentioned sometime before, I believe that we should refer to 
private-key signing rather than RSA, which is just one algorithm that 
performs public/private key encryption. (For instance, ECC is another 
algorithm, and it is much faster.)


One advantage of using private-key (over symmetric key) signatures is 
that they automatically provide non-repudiation, and I would just like 
to keep this in the perspective.


And, with many thanks to Torsten for providing the measurements--always 
a good thing!--I am puzzled by an apparent reversal in the duration of 
signing and verification times.  Typically, for the encryption, the RSA 
keys are chosen to be small so that public key operations are fast; that 
results in the private key operations being slow. It appears to me that 
the same choice makes sense for signatures. One party spends time ONCE 
signing something, and then verification, performed by others, is fast.


And so my question here is: What was the reason for choosing a private 
key short here?


With thanks,

Igor


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

Hi Ethan,

I'm glad I managed to prompt some discussion on the topic!
   
Thank you very much for initiating this discussion! It will help to 
establish a common understanding

of what is required/feasible for the upcoming standard.

RSA vs. HMAC: I really have no idea. On the other hand, Google is the
only existing provider I am aware of that supports the RSA method, and
Google quickly adopted HMAC as well. If the only use-case for the RSA
method is to establish similar security properties to those provided
by SSL/TLS with no performance or implementation advantage, then we
should get rid of it. I think we already had this discussion and I
have no personal interest in rehashing it.
   
I really like RSA because of its adavantages from an operational 
security standpoint. A receiver does
not need to store any private data in order to authenticate the sender 
of a message. Therefore I see RSA
as a promising option to authenticate consumers on the OAuth 
authorization server (how to
get a token). One could even use hardware security moduls for 
authentication!


I don't consider RSA a good option for signing requests from consumer to 
resources because of its performance
characteristics. Symmetric algorithms like HMAC are by magnitudes 
faster. I did some benachmarking in
a project in 2006. The measurements have been taken on a Windows PC  
(Intel Pentium M 1,7 GHz/1GB)

with Java 1.5.

HMAC-MD5: 33000/s (sign and verify)
RSA/512:  434/s (sign), 3300/s (verify)
RSA/1024:  70/s (sign), 1250/s (verify)

As you can see, there is a factor of 10 (verify) to 300 (sign) between 
RSA and HMAC-MD5. Today one would use
HMAC-SHA and probably RSA/2048 so I don't expect the proportions to be 
better for RSA.


I think request signing can always be performed using a (symmetric) 
token secret issued by the OAuth authorization server.


regards,
Torsten.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Panzer]

Though not of course the body of a POST, unless it is form encoded
data, which merely pushes the problem of canonicalization (and thus
interoperability) outside the spec.

On Monday, March 8, 2010, Dick Hardt  wrote:
>
> On 2010-03-08, at 6:39 PM, Ethan Jewett wrote:
>
>> Request hijacking: I actually significantly understated the protection
>> against request hijacking that that the HMAC-SHA1 method of OAuth 1.0a
>> provides. In the worst case, a MITM can hijack a request but cannot
>> change the request method, URL, query parameters, nonce, or timestamp.
>> In the best case (a single-part form-encoded request body or a request
>> consisting only of query parameters), the MITM cannot modify the
>> request at all because it is fully signed. It is not true, as Dick
>> contends, that a MITM who has captured a signed OAuth 1.0a request can
>> use a signed access token as if it were a bearer token. It is far more
>> limited in the worst case, and useless in the best case.
>
> After reviewing the 3.4 of draft-hammer-oauth I see that the query string is 
> part of the string being signed, minimizing the attack surface. Thanks for 
> pointing out my misunderstanding.
>
> -- Dick
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-08, at 6:39 PM, Ethan Jewett wrote:

> Request hijacking: I actually significantly understated the protection
> against request hijacking that that the HMAC-SHA1 method of OAuth 1.0a
> provides. In the worst case, a MITM can hijack a request but cannot
> change the request method, URL, query parameters, nonce, or timestamp.
> In the best case (a single-part form-encoded request body or a request
> consisting only of query parameters), the MITM cannot modify the
> request at all because it is fully signed. It is not true, as Dick
> contends, that a MITM who has captured a signed OAuth 1.0a request can
> use a signed access token as if it were a bearer token. It is far more
> limited in the worst case, and useless in the best case.

After reviewing the 3.4 of draft-hammer-oauth I see that the query string is 
part of the string being signed, minimizing the attack surface. Thanks for 
pointing out my misunderstanding.

-- Dick


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Ethan Jewett]

I'm glad I managed to prompt some discussion on the topic!

In order to avoid responding to several individual messages in this
thread, I'll compile points:

Use cases: The request was for use cases where signatures a la OAuth
1.0a might be required. I've tried to provide some, along with
reasoning on how to identify use cases based on an understanding of
how requiring SSL/TLS results in certain performance changes. I think
the fact that there are a lot of use cases where signature schemes
don't provide an advantage in performance don't take anything away
from the argument that there are use cases where performance is worse.
There may be other use cases that have nothing to do with performance,
but we needed to get the topic on the table.

Amortization or priming of the SSL/TLS connection: Priming and
amortization are possible in a lot of circumstances though I've tried
to pick some where it is difficult. Whether priming is desirable at
all is another question. Is it really more developer friendly to have
to use this trick than to use an OAuth library to sign your requests?
Regardless, priming does not address use cases affected by the
symmetric/private encryption penalty (which is apparently
significant), or use cases where it is difficult to prime a connection
or amortize the connection penalty over a large number of requests.

RSA vs. HMAC: I really have no idea. On the other hand, Google is the
only existing provider I am aware of that supports the RSA method, and
Google quickly adopted HMAC as well. If the only use-case for the RSA
method is to establish similar security properties to those provided
by SSL/TLS with no performance or implementation advantage, then we
should get rid of it. I think we already had this discussion and I
have no personal interest in rehashing it.

Signing (a la OAuth 1.0a) over an insecure connection is as good as or
better than bearer-tokens over an insecure connection: I'll stand by
this, especially after reviewing RFC 2617 (1), which seems to
reinforce the position.

Request hijacking: I actually significantly understated the protection
against request hijacking that that the HMAC-SHA1 method of OAuth 1.0a
provides. In the worst case, a MITM can hijack a request but cannot
change the request method, URL, query parameters, nonce, or timestamp.
In the best case (a single-part form-encoded request body or a request
consisting only of query parameters), the MITM cannot modify the
request at all because it is fully signed. It is not true, as Dick
contends, that a MITM who has captured a signed OAuth 1.0a request can
use a signed access token as if it were a bearer token. It is far more
limited in the worst case, and useless in the best case.

To be clear: I want a bearer-token over SSL/TLS method in OAuth. I'm
not arguing against that. I'm simply trying to establish that there is
a use-case for a signature method.

Thanks,
Ethan

(1) http://www.apps.ietf.org/rfc/rfc2617.html#sec-4
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-08, at 1:09 PM, John Kemp wrote:

> 
> On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
>> 
>> 
>> 2) Client signed tokens are no more secure in MITM attacks than bearer 
>> tokens for on-the-fly attacks. If the attacker can disrupt the channel, the 
>> attacker can take the signed token and use it to make a valid call just as 
>> if it was a bearer token. Imagine the attacker disrupting every other 
>> request, and using the valid token to make an API call. 
> 
> I think that what you mean here is that the MITM steals (at least the signed 
> portion of) the request as well as the token. 

yes

> 
> If the MITM has to sign a request it created itself, even with a stolen 
> token, it will (or should) not have access to the secret key assigned to a 
> properly-provisioned client, and thus cannot authenticate correctly to the 
> recipient.

correct
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Kemp]

On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
> 
> 
> 2) Client signed tokens are no more secure in MITM attacks than bearer tokens 
> for on-the-fly attacks. If the attacker can disrupt the channel, the attacker 
> can take the signed token and use it to make a valid call just as if it was a 
> bearer token. Imagine the attacker disrupting every other request, and using 
> the valid token to make an API call. 

I think that what you mean here is that the MITM steals (at least the signed 
portion of) the request as well as the token. 

If the MITM has to sign a request it created itself, even with a stolen token, 
it will (or should) not have access to the secret key assigned to a 
properly-provisioned client, and thus cannot authenticate correctly to the 
recipient.

Regards,

- johnk

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Dick Hardt wrote:
2) Client signed tokens are no more secure in MITM attacks than bearer tokens for on-the-fly attacks. If the attacker can disrupt the channel, the attacker can take the signed token and use it to make a valid call just as if it was a bearer token. 


I don't understand. How will MITM be authenticated in this case? To 
determine whether the call is *valid*, the signature need to be checked 
against the identity of the presenter of the token.


Igor
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-07, at 12:13 PM, Ethan Jewett wrote:

> My point is only that bearer-tokens over an insecure channel seem to
> be always *less* secure or *as* secure (but never *more* secure) than
> using a signature approach over an insecure channel. As such, I'm
> uncomfortable taking away an existing, widely implemented, and usually
> more secure approach for authentication over an insecure channel
> (OAuth 1.0a signing) and replacing it with a less secure approach
> (bearer tokens w/o SSL/TLS).


This prompts me to argue that allowing signatures is worse than bearer tokens. 
(I'm adding to the conversation here, I don't consider myself a security expert)


1) The server needs to manage state for the nonces, and properly implement 
nonce management. This added complexity can lead to additional security holes 
in the server. I'd be curious on what penetration testing has been done on 
existing OAuth deployments.

2) Client signed tokens are no more secure in MITM attacks than bearer tokens 
for on-the-fly attacks. If the attacker can disrupt the channel, the attacker 
can take the signed token and use it to make a valid call just as if it was a 
bearer token. Imagine the attacker disrupting every other request, and using 
the valid token to make an API call. The Client does not know an attack is 
going on it thinks it is having to repeat every other call, and the Server 
likely thinks the connection is flaky.

3) Deployments are made assuming there is more security than bearer tokens. 
People deploy OAuth in situations where they would not deploy a bearer token 
architecture because they think the signatures prevent attacks.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Jochen Hiller]

Hi Brian,

On Mon, Mar 8, 2010 at 8:46 PM, Brian Eaton  wrote:

> On Mon, Mar 8, 2010 at 11:21 AM, Jochen Hiller 
> wrote:
> > The
> > required time has been reduced about 1 sec (exact time depends on device
> and
> > hardware capabilities), resulting in absolute processing times in range
> of
> > about 100-200 ms, not seconds (depends mainly on server and token
> > requirements).
>
> How much of the time savings was due to reducing network latency?  My
> guess is most of it, but if you saw differently that would be very
> interesting.
>

You are right: I forgot to mention "depends on network" for time reduction.

I do not (yet) have a regression test regarding performance measurements and
HTTPS. But that would be a good idea to get a better understanding where
time will be spent.

I will setup a simple JUnit testcase which takes performance measurements,
and keep you informed.

Bye, Jochen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Mon, Mar 8, 2010 at 11:21 AM, Jochen Hiller  wrote:
> The
> required time has been reduced about 1 sec (exact time depends on device and
> hardware capabilities), resulting in absolute processing times in range of
> about 100-200 ms, not seconds (depends mainly on server and token
> requirements).

How much of the time savings was due to reducing network latency?  My
guess is most of it, but if you saw differently that would be very
interesting.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Jochen Hiller]

On Mon, Mar 8, 2010 at 6:58 PM, John Panzer  wrote:

> On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> ...
>>>
>>> 1. Connection latency to bootstrap the connection (from the
>>> asymmetric/public-key encryption operations)
>>>
>>
>> Bootstrapping a SSL sessions is expensive. But every session can be
>> used for multiple HTTPS-Connections. Thus an application can establish the
>> first
>> HTTPS connection in the background before any user interaction takes place
>> and
>> reuse the session for further communication.
>>
>
> I think this point is worth calling out (and doing a bit of prototyping on)
> -- if the use case is a latency-sensitive client app that wishes to avoid
> cold-start HTTP(s) connections, then a warmup connect() or just an
> idempotent GET while the app is starting up / coming to the foreground could
> be a very good idea.  Good even without SSL, due to DNS overhead, and even
> more useful with SSL.  This could allow many apps to hide the latency hit
> from the user almost completely.
>
> If this is true, then it may mean that the SSL overhead would be a problem
> in far fewer cases than it might appear at first glance.
>
>
I am developing Android apps using a Security Token Service which forces use
of SSL. I ran exactly into the issue that the first request is expensive,
due to establish the SSL session between the Android app and the server. To
reduce the latency time for the first HTTPS request with user interaction, I
did exactly what you described: I run a simple GET request during app
startup, in background, reuse the HttpClient for further requests. The
required time has been reduced about 1 sec (exact time depends on device and
hardware capabilities), resulting in absolute processing times in range of
about 100-200 ms, not seconds (depends mainly on server and token
requirements).

I agree, that SSL simplifies the requirements for the client and client
developer. Every library on client you do NOT need, reduces complexity and
dependencies to other 3rd party libraries. Even generating nounces and
timestamps on client requires additional state to be maintained somewhere
within your app.

Cheers, Jochen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Panzer]

On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt  wrote:

> ...
>> 1. Connection latency to bootstrap the connection (from the
>> asymmetric/public-key encryption operations)
>>
>
> Bootstrapping a SSL sessions is expensive. But every session can be
> used for multiple HTTPS-Connections. Thus an application can establish the
> first
> HTTPS connection in the background before any user interaction takes place
> and
> reuse the session for further communication.


I think this point is worth calling out (and doing a bit of prototyping on)
-- if the use case is a latency-sensitive client app that wishes to avoid
cold-start HTTP(s) connections, then a warmup connect() or just an
idempotent GET while the app is starting up / coming to the foreground could
be a very good idea.  Good even without SSL, due to DNS overhead, and even
more useful with SSL.  This could allow many apps to hide the latency hit
from the user almost completely.

If this is true, then it may mean that the SSL overhead would be a problem
in far fewer cases than it might appear at first glance.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

Hi Ethan,




The most important and unavoidable tradeoff is performance. The


IMHO the comparison is asymmetric. You compare SSL, which offers  
various security

measures, with just signatures on plain HTTP requests. Sure, validating a
(HMAC) signature is cheap, but signatures only give you sender  
authentication and

(depending on what has been included in the digest computation)
message integrity protection. But any attacker might replay the  
messages, so what

about replay prevention?

Replay prevention over unsecure connections is typically (as in OAuth  
1.0 and OpenId)
implemented using nounces and timestamps. Validating nounces requires  
server-side,

cluster-wide state (transient or database). All requests must be validated
against this state in serialized order. So you end up with
a) scalability issues and
b) performance impacts.

SSL scales both linearly and horicontally.

Not to forget, a HTTP request may be cached by any proxy on the way  
from end user
device to target service. Care has to be taken in order to prevent  
proxies from

caching sensible requests.


performance tradeoff comes in two flavors:

1. Connection latency to bootstrap the connection (from the
asymmetric/public-key encryption operations)


Bootstrapping a SSL sessions is expensive. But every session can be
used for multiple HTTPS-Connections. Thus an application can establish  
the first

HTTPS connection in the background before any user interaction takes place and
reuse the session for further communication.


2. Processing to encrypt requests (from the symmetric/private-key
encryption operations)


TLS is powerful and expensive. That's true. I sometimes wish to have something
more lightweight and flexible where I could decide on a per-message  
base which security

features to use. But this is hugh story.

From my point of view, the working group should decide what OAuth 2.0  
should be:


1) a standard for token-based authentication and authorization or
2) a standard for HTTP security including token-based authentication  
and authorization


In the first case, token holder authentication (Holder of Key in SAML  
and WS-Trust) based on signing

a nounce should suffice.

In the later case, the standard should provide a (large) subset of SSL  
protection features,
e.g. message integrity, message confidentiality, server  
authentication, replay prevention.


regards,
Torsten.






___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

I would like to add another use case:

In the "How to get a token" scenario, usage of public key consumer  
authentication would require to use signatures in order to prove  
private key ownership.




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Sun, Mar 7, 2010 at 9:24 AM, Ethan Jewett  wrote:
> Before I get started, let me say that this should be taken with a very
> large grain of salt. I am not a technical expert in these areas. I've
> only done a fair amount of reading and following along with standards
> efforts. Conclusions here should be questioned thoroughly and
> corrected as necessary, but since no one else seems to be willing to
> systematically look into the performance argument for signatures vs.
> SSL/TLS, I thought I'd just sit down for a couple of hours and pound
> it out. The following is the result of that work.



A couple of quick notes on this.

1) Amortized analysis is really important when you are looking at
https connection overhead.  The first document you reference seems to
assume that each SSL session is used for exactly one HTTP request.
That's not the common case, though it certainly can happen in real
world environments.

Overhead from https is highly dependent on deployment scenarios, with
real world costs ranging from "free" to "ridiculously expensive",
depending on the details of the clients and servers and usage
patterns.

2) Your analysis of the overhead of OAuth 1.0a signing assumes that
HMAC is used rather than RSA.  You get very different numbers for RSA.

3) Security arguments for "signing" in OAuth can be fairly subtle.
Different people are using signing in different ways for different
reasons, with corresponding different requirements in terms of key
distribution and use of transport layer encryption.

4) I think "from a security perspective, signing appears to be at
least as good in all respects as bearer tokens sent in the clear"
overstates the case.  It depends on the bearer token,  the signature
scheme, and the security goals.  Check out the security considerations
of the digest auth spec (RFC 2617) for some of the trade-offs here.

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Leif Johansson]

On 03/04/2010 09:00 PM, Blaine Cook wrote:

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.


After reviewing the rest of the replies to this I'll offer up
something I believe is missing.

The hidden assumption of the questions is (I think) that the channel
is secure, yes? In that case: Signatures will protect you against 
failing to get your channel protection right - so will channel bindings btw!


Cheers Leif
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Kemp]

Ethan,

On Mar 7, 2010, at 3:13 PM, Ethan Jewett wrote:

> John,
> 
> Yes, I overstepped in the first section. I'll retract all the stuff
> about bearer-tokens over an insecure channel not having a use-case.
> Clearly they're used all over the place. Whether or not this is a good
> idea is another question entirely and you've outlined a good way to
> approach it.
> 
> My point is only that bearer-tokens over an insecure channel seem to
> be always *less* secure or *as* secure (but never *more* secure) than
> using a signature approach over an insecure channel.

Agreed, there is a spectrum of security requirements and associated methods of 
meeting those requirements.

Bearer tokens are a relatively weak source of authentication, whereas 
cryptographic signatures can better provide that property.

> As such, I'm
> uncomfortable taking away an existing, widely implemented, and usually
> more secure approach for authentication over an insecure channel
> (OAuth 1.0a signing) and replacing it with a less secure approach
> (bearer tokens w/o SSL/TLS).

I would certainly not suggest that we replace a relatively secure 
authentication mechanism (signatures using an appropriately-handled secret key) 
with a relatively insecure authentication mechanism (bearer tokens in the 
clear). 

SSL/TLS (or equivalent) provides another property of security 
(confidentiality). 

Any of these mechanisms might find an appropriate place in real-world 
implementations.

Cheers,

- johnk

> 
> Ethan
> 
> On Sun, Mar 7, 2010 at 1:40 PM, John Kemp  wrote:
>> On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote:
>> 
>> [...]
>> 
>>> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in
>>> nearly all use cases.
>> 
>> Just to point out that there are many use-cases which are today solved 
>> *only* with "bearer tokens" - namely any authentication method which uses 
>> regular Web cookies.
>> 
>> Cookies are often sent over an insecure channel. They are usually not 
>> signed. And any request which comes with a valid "session cookie" is assumed 
>> to be from a legitimate requester, even though with cross-site attacks 
>> through browsers, this is often a devastatingly wrong assumption (hence the 
>> need for a browser same-origin policy).
>> 
>> But the world has not collapsed.
>> 
>>> Any use case where spam is a threat, for
>>> example, is not an acceptable use case because of this attack because
>>> any MITM can send an arbitrary number of spam messages that the
>>> provider application will show as coming directly from the user. If
>>> you think Twitter direct-message spam is bad now...
>> 
>> You are talking about the /impact/ of an attack, and the impact of an attack 
>> on a system secured only with bearer tokens is often high. There is usually 
>> at least one other factor in security threat analysis, however - the /risk/ 
>> of a threat.
>> 
>> The risk of an attack on bearer tokens seems to be empirically low, despite 
>> the relative ease of such an attack.
>> 
>> The risk can also be mitigated by making bearer tokens expire quickly, or 
>> have one-time use semantics.
>> 
>> In short, bearer tokens work for quite a large set of use-cases.
>> 
>>> 
>>> Because of this and other possible attacks (successfully impersonating
>>> a provider gets you the bearer-token, for example), I think that
>>> bearer-tokens without SSL/TLS are not worth considering further for
>>> the vast majority of use cases.
>> 
>> I disagree, but I'm not sure it matters anyway for the purposes of deciding 
>> what features OAuth should support.
>> 
>> OAuth will support bearer (ie. unsigned) tokens sent over SSL. So it will 
>> support bearer tokens. It's just a question of whether the spec. should 
>> allow implementations to send bearer tokens over any other channel than an 
>> SSL/TLS channel.
>> 
>> If someone wishes to do the risk analysis and decides that a particular 
>> security feature is sufficient for what they want to do, why shouldn't they 
>> be allowed to do it? Someone who gets it wrong, shoots him- or her-self (and 
>> no-one else, as the whole community, or that company's partners don't have 
>> to play along) in the foot, right?
>> 
>> Make bearer+SSL/TLS mandatory to implement, but don't rule out bearer tokens 
>> being sent over insecure channels, and we should all be able to implement 
>> what we need to implement in peace.
>> 
>> Cheers,
>> 
>> - johnk
>> 
>> 
>> 
>> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Ethan Jewett]

John,

Yes, I overstepped in the first section. I'll retract all the stuff
about bearer-tokens over an insecure channel not having a use-case.
Clearly they're used all over the place. Whether or not this is a good
idea is another question entirely and you've outlined a good way to
approach it.

My point is only that bearer-tokens over an insecure channel seem to
be always *less* secure or *as* secure (but never *more* secure) than
using a signature approach over an insecure channel. As such, I'm
uncomfortable taking away an existing, widely implemented, and usually
more secure approach for authentication over an insecure channel
(OAuth 1.0a signing) and replacing it with a less secure approach
(bearer tokens w/o SSL/TLS).

Ethan

On Sun, Mar 7, 2010 at 1:40 PM, John Kemp  wrote:
> On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote:
>
> [...]
>
>> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in
>> nearly all use cases.
>
> Just to point out that there are many use-cases which are today solved *only* 
> with "bearer tokens" - namely any authentication method which uses regular 
> Web cookies.
>
> Cookies are often sent over an insecure channel. They are usually not signed. 
> And any request which comes with a valid "session cookie" is assumed to be 
> from a legitimate requester, even though with cross-site attacks through 
> browsers, this is often a devastatingly wrong assumption (hence the need for 
> a browser same-origin policy).
>
> But the world has not collapsed.
>
>> Any use case where spam is a threat, for
>> example, is not an acceptable use case because of this attack because
>> any MITM can send an arbitrary number of spam messages that the
>> provider application will show as coming directly from the user. If
>> you think Twitter direct-message spam is bad now...
>
> You are talking about the /impact/ of an attack, and the impact of an attack 
> on a system secured only with bearer tokens is often high. There is usually 
> at least one other factor in security threat analysis, however - the /risk/ 
> of a threat.
>
> The risk of an attack on bearer tokens seems to be empirically low, despite 
> the relative ease of such an attack.
>
> The risk can also be mitigated by making bearer tokens expire quickly, or 
> have one-time use semantics.
>
> In short, bearer tokens work for quite a large set of use-cases.
>
>>
>> Because of this and other possible attacks (successfully impersonating
>> a provider gets you the bearer-token, for example), I think that
>> bearer-tokens without SSL/TLS are not worth considering further for
>> the vast majority of use cases.
>
> I disagree, but I'm not sure it matters anyway for the purposes of deciding 
> what features OAuth should support.
>
> OAuth will support bearer (ie. unsigned) tokens sent over SSL. So it will 
> support bearer tokens. It's just a question of whether the spec. should allow 
> implementations to send bearer tokens over any other channel than an SSL/TLS 
> channel.
>
> If someone wishes to do the risk analysis and decides that a particular 
> security feature is sufficient for what they want to do, why shouldn't they 
> be allowed to do it? Someone who gets it wrong, shoots him- or her-self (and 
> no-one else, as the whole community, or that company's partners don't have to 
> play along) in the foot, right?
>
> Make bearer+SSL/TLS mandatory to implement, but don't rule out bearer tokens 
> being sent over insecure channels, and we should all be able to implement 
> what we need to implement in peace.
>
> Cheers,
>
> - johnk
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Ethan Jewett]

Thanks for your comments. I'm mostly interested in watching the
discussion unfold, but there are a couple of things to add:

On Sun, Mar 7, 2010 at 1:23 PM, John Panzer  wrote:

> You can make the token short-lived if this is a concern.  (Short lived
> meaning minutes.)  And presumably the user is rate limited in the first
> place, so there is an upper bound on the damage that can be done.
> It's possible to come up with scenarios where short lived bearer tokens
> won't work for #5.  I'm struggling to come up with any scenarios that really
> wouldn't want TLS as well.
> Note that TLS also takes care of the reverse trip -- the MITM cannot lie to
> the client about what happened, or feed it false information.  None of the
> signature options under discussion sign responses IIRC.

All true, but the upper bound of damage that can be done is definitely
higher than with a signature over an insecure connection. I'm just
very hesitant to take away signatures and provide only a less secure
method (or no method at all) over an insecure connection.

> I was excited to look at (1) a bit as I think actual research and numbers
> would be good.  It appears that this paper was also published in "IEEE
> International Symposium on Performance Analysis of Systems and Software
> (ISPASS), Austin Texas, Mar 2005," so the measurements are about 6 years old
> at this point.
> I also noticed that they did not mention HTTP keep-alive connections in
> conjunction with SSL performance.  If you are doing a high volume of server
> to server requests, this would be an obvious optimization in any case, and
> would amortize the public key operation overhead over a lot of transactions
> (IIUC).
> Below you mention the intermittent request case, where you have surprise
> requests from any of a large number of clients that hit your server (and so
> there's a cold-start penalty each time).  This is a worst case scenario for
> SSL connections.  I wonder what the overhead of SSL is for modern client
> hardware in these situations (and I'm thinking that in a thin client world,
> this is a very good use for silicon on the client.)
> They also didn't really go into the effects of specialized server hardware
> for SSL, which may not have been as available in 2004(?).

I recognize that the research I reference is dated. Unfortunately I do
not have much access to good research article search or to
subscription services for most journals. If someone with that access
would do the leg-work to find more recent articles, I'd be delighted
:-)

That said, on non-specialized hardware, I don't think crypto
operations have gotten much faster over the last 6 years aside from
the Moore's law speedups that apply to everything, so I think the
percentage estimates are probably OK.

> For today's realistic request traffic, I've been told that the public key
> setup is typically the limiting factor.  And in fact even with keep-alives
> turned on the main thing you'd need capacity for at scale is a cold start of
> your service under load (worst case scenario).  The public key operations
> would be a major issue then.

Actually, the finding that the private key operations are at least as
intensive at the public key operations for requests over 64Kb in size
was one of the things that most surprised me in this paper! I too was
under the impression that the main limiting factor was the public-key
operation and I didn't even think about the large-request case until I
started researching.

> Note that a possible workaround for these large-request situations is to use
> an SSL-secure API to retrieve a one-time bearer token for use with a
> subsequent large request (a video upload, say).  Since it's one time it
> can't be used to replay anything.  Since it's a large request the overhead
> of an initial small request is nearly irrelevant.

True. That sounds like a good idea. This is not part of either the
OAuth 1.0a or WRAP spec for bearer tokens. It would have to be added
(and perhaps should be).

> Thanks for writing all of this up.  It would be good to get some general
> quantification of user experience latency impact (if everyone agrees that's
> the main issue) and compare it against the known interoperability issues
> with signatures.  (There's a user experience impact there too.)

Agreed, that sounds like the right approach. I don't have the
expertise or time to do that quantitative testing. Maybe a large
provider would be willing to contribute a sampling of their test data.

Ethan
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Kemp]

On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote:

[...]

> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in
> nearly all use cases.

Just to point out that there are many use-cases which are today solved *only* 
with "bearer tokens" - namely any authentication method which uses regular Web 
cookies.

Cookies are often sent over an insecure channel. They are usually not signed. 
And any request which comes with a valid "session cookie" is assumed to be from 
a legitimate requester, even though with cross-site attacks through browsers, 
this is often a devastatingly wrong assumption (hence the need for a browser 
same-origin policy). 

But the world has not collapsed. 

> Any use case where spam is a threat, for
> example, is not an acceptable use case because of this attack because
> any MITM can send an arbitrary number of spam messages that the
> provider application will show as coming directly from the user. If
> you think Twitter direct-message spam is bad now...

You are talking about the /impact/ of an attack, and the impact of an attack on 
a system secured only with bearer tokens is often high. There is usually at 
least one other factor in security threat analysis, however - the /risk/ of a 
threat. 

The risk of an attack on bearer tokens seems to be empirically low, despite the 
relative ease of such an attack.
 
The risk can also be mitigated by making bearer tokens expire quickly, or have 
one-time use semantics. 

In short, bearer tokens work for quite a large set of use-cases.

> 
> Because of this and other possible attacks (successfully impersonating
> a provider gets you the bearer-token, for example), I think that
> bearer-tokens without SSL/TLS are not worth considering further for
> the vast majority of use cases.

I disagree, but I'm not sure it matters anyway for the purposes of deciding 
what features OAuth should support.

OAuth will support bearer (ie. unsigned) tokens sent over SSL. So it will 
support bearer tokens. It's just a question of whether the spec. should allow 
implementations to send bearer tokens over any other channel than an SSL/TLS 
channel. 

If someone wishes to do the risk analysis and decides that a particular 
security feature is sufficient for what they want to do, why shouldn't they be 
allowed to do it? Someone who gets it wrong, shoots him- or her-self (and 
no-one else, as the whole community, or that company's partners don't have to 
play along) in the foot, right? 

Make bearer+SSL/TLS mandatory to implement, but don't rule out bearer tokens 
being sent over insecure channels, and we should all be able to implement what 
we need to implement in peace.

Cheers,

- johnk



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[John Panzer]

Thanks for the comment.  I am not an expert either, but:

On Sun, Mar 7, 2010 at 9:24 AM, Ethan Jewett  wrote:

> Before I get started, let me say that this should be taken with a very
> large grain of salt. I am not a technical expert in these areas. I've
> only done a fair amount of reading and following along with standards
> efforts. Conclusions here should be questioned thoroughly and
> corrected as necessary, but since no one else seems to be willing to
> systematically look into the performance argument for signatures vs.
> SSL/TLS, I thought I'd just sit down for a couple of hours and pound
> it out. The following is the result of that work.
>
> ** Resource access without SSL/TLS - Signatures vs. Bearer-tokens **
>
> The crux of the trade-off comes down to this: In the case of signed
> authorization information (with a nonce), a Man in the Middle (MITM)
> attacker owns the individual message. The MITM can do the following:
>
> 1. Decline to deliver the message
> 2. Hold the message and deliver it later (subject to constraints on
> timestamp validity - so this is a limited attack)
> 3. Deliver the message with altered contents (only if the contents
> themselves are not signed)
>
> In the case of bearer-token authorization, a MITM owns the entire
> connection. The MITM can do the following:
>
> 1. Decline to deliver the message
> 2. Hold the message and deliver it later
> 3. Change the timestamp (if one is used at all)
> 4. Change the contents of the message
> 5. Create an arbitrary number of new messages with arbitrary contents
> using the bearer-token and deliver those (subject to bearer-token
> invalidation)
>
> In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in
> nearly all use cases. Any use case where spam is a threat, for
> example, is not an acceptable use case because of this attack because
> any MITM can send an arbitrary number of spam messages that the
> provider application will show as coming directly from the user. If
> you think Twitter direct-message spam is bad now...
>

You can make the token short-lived if this is a concern.  (Short lived
meaning minutes.)  And presumably the user is rate limited in the first
place, so there is an upper bound on the damage that can be done.

It's possible to come up with scenarios where short lived bearer tokens
won't work for #5.  I'm struggling to come up with any scenarios that really
wouldn't want TLS as well.

Note that TLS also takes care of the reverse trip -- the MITM cannot lie to
the client about what happened, or feed it false information.  None of the
signature options under discussion sign responses IIRC.


>
> Because of this and other possible attacks (successfully impersonating
> a provider gets you the bearer-token, for example), I think that
> bearer-tokens without SSL/TLS are not worth considering further for
> the vast majority of use cases.
>
> ** So what about SSL/TLS? Can't we just use that for everything and
> forget about signatures? **
>
> Yes, but there are tradeoffs.
>
> The most important and unavoidable tradeoff is performance. The
> performance tradeoff comes in two flavors:
>
> 1. Connection latency to bootstrap the connection (from the
> asymmetric/public-key encryption operations)
> 2. Processing to encrypt requests (from the symmetric/private-key
> encryption operations)
>
> Connection latency is incurred to the public-key cryptography
> operations that are used to facilitate the exchange of a shared
> secret, which can then be used in the much more efficient
> private/symmetric key cryptography used to encrypt the individual
> messages. Research (1) indicates that, on the web server, SSL
> introduces approximately a 70% overhead over basic HTTP for small
> requests and that of this overhead almost 90% is incurred in the
> public key operations.
>

I was excited to look at (1) a bit as I think actual research and numbers
would be good.  It appears that this paper was also published in "IEEE
International Symposium on Performance Analysis of Systems and Software
(ISPASS), Austin Texas, Mar 2005," so the measurements are about 6 years old
at this point.

I also noticed that they did not mention HTTP keep-alive connections in
conjunction with SSL performance.  If you are doing a high volume of server
to server requests, this would be an obvious optimization in any case, and
would amortize the public key operation overhead over a lot of transactions
(IIUC).

Below you mention the intermittent request case, where you have surprise
requests from any of a large number of clients that hit your server (and so
there's a cold-start penalty each time).  This is a worst case scenario for
SSL connections.  I wonder what the overhead of SSL is for modern client
hardware in these situations (and I'm thinking that in a thin client world,
this is a very good use for silicon on the client.)

They also didn't really go into the effects of specialized server hardware
for SSL, which may not have been as available in 200

Re: [OAUTH-WG] Signatures, Why?

[Ethan Jewett]

Before I get started, let me say that this should be taken with a very
large grain of salt. I am not a technical expert in these areas. I've
only done a fair amount of reading and following along with standards
efforts. Conclusions here should be questioned thoroughly and
corrected as necessary, but since no one else seems to be willing to
systematically look into the performance argument for signatures vs.
SSL/TLS, I thought I'd just sit down for a couple of hours and pound
it out. The following is the result of that work.

** Resource access without SSL/TLS - Signatures vs. Bearer-tokens **

The crux of the trade-off comes down to this: In the case of signed
authorization information (with a nonce), a Man in the Middle (MITM)
attacker owns the individual message. The MITM can do the following:

1. Decline to deliver the message
2. Hold the message and deliver it later (subject to constraints on
timestamp validity - so this is a limited attack)
3. Deliver the message with altered contents (only if the contents
themselves are not signed)

In the case of bearer-token authorization, a MITM owns the entire
connection. The MITM can do the following:

1. Decline to deliver the message
2. Hold the message and deliver it later
3. Change the timestamp (if one is used at all)
4. Change the contents of the message
5. Create an arbitrary number of new messages with arbitrary contents
using the bearer-token and deliver those (subject to bearer-token
invalidation)

In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in
nearly all use cases. Any use case where spam is a threat, for
example, is not an acceptable use case because of this attack because
any MITM can send an arbitrary number of spam messages that the
provider application will show as coming directly from the user. If
you think Twitter direct-message spam is bad now...

Because of this and other possible attacks (successfully impersonating
a provider gets you the bearer-token, for example), I think that
bearer-tokens without SSL/TLS are not worth considering further for
the vast majority of use cases.

** So what about SSL/TLS? Can't we just use that for everything and
forget about signatures? **

Yes, but there are tradeoffs.

The most important and unavoidable tradeoff is performance. The
performance tradeoff comes in two flavors:

1. Connection latency to bootstrap the connection (from the
asymmetric/public-key encryption operations)
2. Processing to encrypt requests (from the symmetric/private-key
encryption operations)

Connection latency is incurred to the public-key cryptography
operations that are used to facilitate the exchange of a shared
secret, which can then be used in the much more efficient
private/symmetric key cryptography used to encrypt the individual
messages. Research (1) indicates that, on the web server, SSL
introduces approximately a 70% overhead over basic HTTP for small
requests and that of this overhead almost 90% is incurred in the
public key operations.

As request size increases, the public key operation overhead remains
constant while the private key operations to encrypt the request
scales linearly with request size. As a result, the actual act of
encrypting the request becomes the limiting factor relatively quickly
for large requests.

Keep in mind, this is additional latency on the web server, not on the
client. Other research (2) indicates that clients may be even more
resource-bound for these types of operations, resulting in even more
severe latency problems.

It's important to note that these two types of performance impact
become problematic under different use cases.

** When SSL makes sense and when it doesn't **

SSL has negative performance impacts which will result in real user
experience impacts in certain situations. Service providers can use
specialized hardware to significantly accelerate the necessary
cryptography operations, but any client smaller than a medium-sized
web application provider will not be able to afford the cost of such
infrastructure. As such, these clients will suffer a user experience
impact from the required use of SSL/TLS connections in some
situations.

What are these situations?

Connection latency is an issue when new connections must be
established for most operations. This is the case for intermittent API
requests. Some use cases where this could be an issue (keeping in mind
that even an extra fraction of a second of wait-time is a
user-experience penalty that many applications may be unhappy paying):

1. Display statistics in a rich/desktop app in response to a user
request (Ego app on iPhone requesting statistics from Google
Analytics, for instance)
2. Check for new messages in a rich/desktop in response to a user
request (Dashboard widget, for example)
3. Request data within a web application from a little-used
third-party provider in response to a user request (web app like
youcalc.com with ability to connect to arbitrary OAuth-enabled
datastores)

Meanwhile, encryption

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Brian,

You are asking many interesting questions--maybe we should continue this 
when we meet in Anaheim. (The nights are getting shorter...)


In short, yes, non-repudiation, in general, is a very tough thing. We 
had been having long discussions with Steve Bellovin about that in 
PINT/SPIRITS times, and really, in the absence of private key signatures 
there, the only solution is some kind of a third-party interference.


You are right, non-repudiation was not an objective of OAuth 1.0, and I 
do not insist that non-repudiation be a requirement in OAuth, period. I 
merely pointed out that a private-key signature solves this problem too, 
while answering a question on why signatures are needed.


But your questions naturally make me think about the non-repudiation use 
case. I suspect that both the end-user and the Client would be involved 
because this is a three-way transaction. Of course, the case I alluded 
to dealt ONLY with the non-repudiation of the Client's request... 
Anyway, this is a very interesting and, I suspect, complex problem.


Let us talk with a piece of paper when we meet?

Igor

Brian Eaton wrote:

On Thu, Mar 4, 2010 at 10:18 PM, Igor Faynberg
 wrote:
  

The secure channel only delivers a request (or a token). But there is no
proof of authentication (or the means for non-repudiation) in the token
itself, unless the whole session has been recorded (and the key for it has
been stored).



The non-repudiation goal is the most interesting, because it is the
only one in your list that is not met by WRAP over https.

Non-repudiation can, sort of, be achieved by some OAuth 1.0a
deployments.  But not most of them.

The "token auth" drafts that Eran sent out earlier explicitly remove
the client secret from being used to sign resource requests, which
would even further restrict the number of OAuth deployments that could
claim something resembling non-repudiation.

I'd also note that non-repudiation was not a security goal of OAuth
1.0a, and as a consequence probably shouldn't be relied on for
non-repudiation.   For example, OAuth 1.0a doesn't use a trusted
timestamping service; if a key leaks, all documents signed with that
key are suspect.

There are existing schemes for non-repudiation that may be better
suited for your use cases.  Have you looked at alternatives to OAuth
signing?

But I have to admit I'm still unsure of your use cases.  For example,
do you have three players (client, server, user), or just two (client,
server)?  Which players are making statements that need the
non-repudiation property?

Cheers,
Brian
  

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Torsten Lodderstedt]

Hi all,

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
   
- end2end message-level security (w/ or w/o HTTPS) in order to prevent 
intermediaries from tampering messages - in such a scenario encryption 
should also be considered
- sender authentication - a signature based on the token secret might be 
used to prove legitimate ownership of the token

- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.
   

regards,
Torsten.

b.
___
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

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Thu, Mar 4, 2010 at 10:18 PM, Igor Faynberg
 wrote:
> The secure channel only delivers a request (or a token). But there is no
> proof of authentication (or the means for non-repudiation) in the token
> itself, unless the whole session has been recorded (and the key for it has
> been stored).

The non-repudiation goal is the most interesting, because it is the
only one in your list that is not met by WRAP over https.

Non-repudiation can, sort of, be achieved by some OAuth 1.0a
deployments.  But not most of them.

The "token auth" drafts that Eran sent out earlier explicitly remove
the client secret from being used to sign resource requests, which
would even further restrict the number of OAuth deployments that could
claim something resembling non-repudiation.

I'd also note that non-repudiation was not a security goal of OAuth
1.0a, and as a consequence probably shouldn't be relied on for
non-repudiation.   For example, OAuth 1.0a doesn't use a trusted
timestamping service; if a key leaks, all documents signed with that
key are suspect.

There are existing schemes for non-repudiation that may be better
suited for your use cases.  Have you looked at alternatives to OAuth
signing?

But I have to admit I'm still unsure of your use cases.  For example,
do you have three players (client, server, user), or just two (client,
server)?  Which players are making statements that need the
non-repudiation property?

Cheers,
Brian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Dick Hardt wrote:

...
If there is a secure channel between the Client and the PR, and the token is 
only accepted at one Client. What other advantages are there to the Client 
signing that you don't get from a bearer token?
...
The secure channel can only protect a session, not the data that need to 
be re-used later.


The secure channel only delivers a request (or a token). But there is no 
proof of authentication (or the means for non-repudiation) in the token 
itself, unless the whole session has been recorded (and the key for it 
has been stored).


Igor


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-04, at 9:31 PM, Igor Faynberg wrote:

> 
> 
> Dick Hardt wrote:
>> On 2010-03-04, at 12:27 PM, Igor Faynberg wrote:
>> ...
 - Why are signatures needed?
   
>>> 1) For authentication
>>> 
>>> 2) For ensuring integrity
>>> 
>>> 3) For non-repudiation
>>>
>> 
>> Those are the general capabilities of signatures. "Why does the Client need 
>> to sign the request / token?" is the full question.
>>  
> 
> Yes, these are the benefits of using signatures. As Brian has already 
> pointed, there have been cases on the record. I tried to summarize the 
> benefits in a short answer, but I don't mind elaborating.
>> Which party are we worried about authenticating?   
> 
> The Client, of course. And it is not simply that we are authenticating the 
> Client, we a) authenticate the token and b) ensure that it has not been 
> modified. Say, a rogue Client through some sort of phishing pretends to the 
> end user to be legitimate in accessing the user's data and--to the server 
> (i.e., service provider) it pretends to be a legitimate partner. A lot of bad 
> things may happen. Yet, if the request for *temporary credentials* is denied 
> when the signature is  verified and found wrong, nothing would proceed. Here, 
> only a legitimate client can even start a transaction.

What makes a client legitamate? In a rich application, all Client secrets can 
be discovered.

> 
> And then, later the request for *token credentials* also needs to be signed 
> (and differently) to ensure   that of all the legitimate Clients only the 
> Client authorized by the end user can access the record.
> 
>> What are we trying to ensure the integrity of?
> 
> The request, of course. Incidentally, this feature would come "for free" 
> anyway if the client signs the hash of the request and sends it along with 
> the request itself. (And throwing in a nonce into the hash would prevent 
> replay.)

Throwing in a nonce also introduces a requirement to the PR to maintain state.

...

So far, you are explaining security 101. 

If there is a secure channel between the Client and the PR, and the token is 
only accepted at one Client. What other advantages are there to the Client 
signing that you don't get from a bearer token?

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Dick Hardt wrote:

On 2010-03-04, at 12:27 PM, Igor Faynberg wrote:
...

- Why are signatures needed?
 
  

1) For authentication

2) For ensuring integrity

3) For non-repudiation



Those are the general capabilities of signatures. "Why does the Client need to sign 
the request / token?" is the full question.
  


Yes, these are the benefits of using signatures. As Brian has already 
pointed, there have been cases on the record. I tried to summarize the 
benefits in a short answer, but I don't mind elaborating.
Which party are we worried about authenticating? 
  


The Client, of course. And it is not simply that we are authenticating 
the Client, we a) authenticate the token and b) ensure that it has not 
been modified. Say, a rogue Client through some sort of phishing 
pretends to the end user to be legitimate in accessing the user's data 
and--to the server (i.e., service provider) it pretends to be a 
legitimate partner. A lot of bad things may happen. Yet, if the request 
for *temporary credentials* is denied when the signature is  verified 
and found wrong, nothing would proceed. Here, only a legitimate client 
can even start a transaction.


And then, later the request for *token credentials* also needs to be 
signed (and differently) to ensure   that of all the legitimate Clients 
only the Client authorized by the end user can access the record.



What are we trying to ensure the integrity of?


The request, of course. Incidentally, this feature would come "for free" anyway 
if the client signs the hash of the request and sends it along with the request itself. 
(And throwing in a nonce into the hash would prevent replay.)


 What statement is requires non-repudiation?

The mere transaction request, as far as I am concerned. If the Client later 
claims that no such request had been made, the Server will show the signed 
request. (Of course, here the best way to effect this is to use the private key 
for signature; otherwise a solution may become hairy--requiring a third party.)

Igor
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Brian Eaton]

On Thu, Mar 4, 2010 at 12:00 PM, Blaine Cook  wrote:
> Let's try to outline the use cases! Please reply here, so that we have
> a good idea of what they are as we move towards the Anaheim WG.

Luke summarized Facebook's use cases for signatures earlier:

http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-04, at 12:27 PM, Igor Faynberg wrote:

> 
> 
> Blaine Cook wrote:
>> - Why are signatures needed?
>>  
> 1) For authentication
> 
> 2) For ensuring integrity
> 
> 3) For non-repudiation

Those are the general capabilities of signatures. "Why does the Client need to 
sign the request / token?" is the full question.

Which party are we worried about authenticating? What are we trying to ensure 
the integrity of? What statement is requires non-repudiation?


>> - What do signatures need to protect?
>>  
> They protect against
> 
> 1) Fraudulent access (which, in absence of proper mechanisms, may not even 
> even be considered legally fraudulent while making considerable damage)
> 
> 2) Denial of a previous request.

I am confused by this statement. Would you elaborate?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Igor Faynberg]

Blaine Cook wrote:

- Why are signatures needed?
  

1) For authentication

2) For ensuring integrity

3) For non-repudiation

- What do signatures need to protect?
  

They protect against

1) Fraudulent access (which, in absence of proper mechanisms, may not 
even even be considered legally fraudulent while making considerable damage)


2) Denial of a previous request.


Igor


  

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Signatures, Why?

[Blaine Cook]

One of the things that's been a primary focus of both today's WG call
and last week's call is what are the specific use cases for
signatures?

- Why are signatures needed?
- What do signatures need to protect?

Let's try to outline the use cases! Please reply here, so that we have
a good idea of what they are as we move towards the Anaheim WG.

b.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth