Subject: [OAUTH-WG] Signatures, Why?

From: Blaine Cook <[email-masked]>
Date: Thu, 4 Mar 2010 12:00:59 -0800

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.

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 04 Mar 2010 15:27:58 -0500

> - 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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Mar 2010 13:11:42 -0800

> 2) For ensuring integrity

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?

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

I am confused by this statement. Would you elaborate?

---

From: Brian Eaton <[email-masked]>
Date: Thu, 4 Mar 2010 14:10:50 -0800

> 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

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 05 Mar 2010 00:31:12 -0500

Dick Hardt wrote:
> ...

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Mar 2010 21:42:07 -0800

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

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

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

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 05 Mar 2010 01:18:51 -0500

> 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 toke…
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

---

From: Brian Eaton <[email-masked]>
Date: Thu, 4 Mar 2010 22:40:51 -0800

On Thu, Mar 4, 2010 at 10:18 PM, Igor Faynberg
<[email-masked]> wrote:
> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 05 Mar 2010 07:54:29 +0100

Hi all,
> - 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
> a good idea of what they are as we move towards the Anaheim WG.
regards,
Torsten.
> b.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 05 Mar 2010 02:38:20 -0500

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

---

From: Ethan Jewett <[email-masked]>
Date: Sun, 7 Mar 2010 11:24:07 -0600

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 of the request becomes an issue for large
request uploads and download especially. Some examples:

1. Video and media file access requests, including streaming
2. Google Docs document list API upload/download requests

In both of the situations outlined above, SSL/TLS imposes a
performance overhead that should theoretically have user experience
implications. As I've been thinking about this issue, the following
matrix has proven helpful in visualizing the problem space and helping
to show that SSL/TLS is a clear winner in only a limited (but
admittedly very common) portion of the problem space.

---------------------------------------------------------------------------------------------
|                   | Sensitive to connection latency | Not sensitive
to connection latency |
---------------------------------------------------------------------------------------------
| Large requests    | SSL/TLS not a good option       | SSL/TLS may be
an option            |
---------------------------------------------------------------------------------------------
| No large requests | SSL/TLS may be an option        | SSL/TLS is a
good option            |
---------------------------------------------------------------------------------------------

** How does signing address these use cases? **

The answer to this question depends on the form that signing ends up
taking. If only the authentication parameters are signed, then we are
in a situation similar to OAuth 1.0a in which latency is minimal
because the hash operation used in the signing is cheap and is
executed on a very small amount of data. Further, performance is
unrelated to request size because only the authentication parameters
are signed and the length of these parameters are unrelated to the
request payload.

If full message signing is required, then we start to run into the
encryption penalty, as effort to calculate the hash of the entire
payload should scale more or less linearly with the size of the
payload. However, connection latency should remain minimal for small
requests.

Of course, using signatures without transport-layer security brings
with it a whole new matrix of known security considerations. As
mentioned at the beginning of this little essay, from a security
perspective, signing appears to be at least as good in all respects as
bearer tokens sent in the clear.

** Conclusion **

There are theoretical and currently deployed use-cases in which
dispensing with SSL/TLS and signing at least the authentication
parameters of a request makes sense. These are use cases in which
SSL/TLS has an undesirable user experience impact and in which leaving
the request payload in the clear does not have significant negative
security impacts. For this reason, and because the signing approach is
the predominant deployed OAuth method (even though SSL/TLS with a
bearer token is an option), we should maintain a signature method in
the current draft.

** References **

1. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.8589&rep=rep1&type=pdf
- Anatomy and Performance of SSL Processing - Li Zhao, Ravi Iyer,
Srihari Makineni, Laxmi Bhuyan - p. 4 is the meat

2. http://iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf -
A Performance Analysis of Secure HTTP Protocol - Xubin He

---

From: John Panzer <[email-masked]>
Date: Sun, 7 Mar 2010 11:23:45 -0800

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

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

> requests and that of this overhead almost 90% is incurred in the

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(?).

> encrypting the request becomes the limiting factor relatively quickly

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.

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.

> request (Dashboard widget, for example)

May be better served by a push mechanism in any case...

> bearer token is an option), we should maintain a signature method in

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.)

>
> ** References **
>
> 1.
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.8589&rep=rep1&type=pdf

---

From: John Kemp <[email-masked]>
Date: Sun, 7 Mar 2010 14:40:00 -0500

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

[...]

> 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

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.

> 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

---

From: Ethan Jewett <[email-masked]>
Date: Sun, 7 Mar 2010 14:08:55 -0600

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

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

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

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

> 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).

> 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

---

From: Ethan Jewett <[email-masked]>
Date: Sun, 7 Mar 2010 14:13:54 -0600

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

---

From: John Kemp <[email-masked]>
Date: Sun, 7 Mar 2010 15:37:19 -0500

Ethan,

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

> 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

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

---

From: Leif Johansson <[email-masked]>
Date: Sun, 07 Mar 2010 22:42:40 +0100

> 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

---

From: Brian Eaton <[email-masked]>
Date: Sun, 7 Mar 2010 21:22:06 -0800

> it out. The following is the result of that work.

<snip>

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 08 Mar 2010 14:04:50 +0100

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 08 Mar 2010 14:38:27 +0100

Hi Ethan,

<snip>
> 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.

> 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

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.

---

From: John Panzer <[email-masked]>
Date: Mon, 8 Mar 2010 09:58:49 -0800

On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt <[email-masked]
> wrote:

> used for multiple HTTPS-Connections. Thus an application can establish the
> first

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.

---

From: Jochen Hiller <[email-masked]>
Date: Mon, 8 Mar 2010 20:21:03 +0100

On Mon, Mar 8, 2010 at 6:58 PM, John Panzer <[email-masked]> wrote:

> On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt <
> [email-masked]> wrote:
>
>> ...
>>>
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

---

From: Brian Eaton <[email-masked]>
Date: Mon, 8 Mar 2010 11:46:10 -0800

On Mon, Mar 8, 2010 at 11:21 AM, Jochen Hiller <[email-masked]> wrote:
> The

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.

---

From: Jochen Hiller <[email-masked]>
Date: Mon, 8 Mar 2010 21:05:14 +0100

Hi Brian,

> guess is most of it, but if you saw differently that would be very

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 8 Mar 2010 12:35:19 -0800

> (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

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 08 Mar 2010 16:01:27 -0500

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

---

From: John Kemp <[email-masked]>
Date: Mon, 8 Mar 2010 16:09:00 -0500

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 8 Mar 2010 14:06:36 -0800

> 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 authe…

correct

---

From: Ethan Jewett <[email-masked]>
Date: Mon, 8 Mar 2010 21:39:51 -0500

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 8 Mar 2010 19:29:55 -0800

> 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

---

From: John Panzer <[email-masked]>
Date: Mon, 8 Mar 2010 19:41:20 -0800

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.

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 09 Mar 2010 15:04:05 +0100

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

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 09 Mar 2010 11:24:29 -0500

Torsten Lodderstedt wrote:
> ...
> I don't consider RSA a good option for signing requests from consumer 
> to resources because of its performance
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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 09 Mar 2010 21:02:25 +0100

Hi Igor,
>> 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 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.
> <snip>
> 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.
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.

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 09 Mar 2010 15:53:16 -0500

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:
>> And so my question here is: What was the reason for choosing a 
>> private key short here?
> operations per second and the results show verification (the public 
> key operation) is significantly faster then signing.
>
>>
>>
>>
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 20:19:57 -0700

<hat type='chair'/>

> 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/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 12 Mar 2010 06:56:19 +0100

I volunteer to write it up.

---

From: Eve Maler <[email-masked]>
Date: Fri, 12 Mar 2010 10:22:12 -0800

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.

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

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: Dick Hardt <[email-masked]>
Date: Fri, 12 Mar 2010 10:43:27 -0800

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

---

From: Brian Eaton <[email-masked]>
Date: Fri, 12 Mar 2010 11:06:49 -0800

On Fri, Mar 12, 2010 at 10:22 AM, Eve Maler <[email-masked]> 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

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 12 Mar 2010 14:38:55 -0500

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:
>> 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.
>
> 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
> ------------------------------------------------------------------------
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 12 Mar 2010 11:46:24 -0800

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:
>>

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 12 Mar 2010 16:15:01 -0500

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

---

From: Eve Maler <[email-masked]>
Date: Fri, 12 Mar 2010 14:09:22 -0800

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

Eve Maler
[email-masked]

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 15 Mar 2010 13:07:25 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, March 11, 2010 10:20 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] Signatures, Why?

<hat type='chair'/>

Peter

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 15 Mar 2010 23:50:07 +0100

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.

---

From: John Panzer <[email-masked]>
Date: Mon, 15 Mar 2010 23:22:33 -0700

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 <
[email-masked]> wrote:

> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please review
> it.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Brian Eaton <[email-masked]>
Date: Mon, 15 Mar 2010 23:28:08 -0700

On Mon, Mar 15, 2010 at 11:22 PM, John Panzer <[email-masked]> 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. =)

---

From: Paul Lindner <[email-masked]>
Date: Mon, 15 Mar 2010 23:30:55 -0700

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

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 16 Mar 2010 02:48:28 -0400

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:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     "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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi all,
>
>         http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy.
>         Please review it.
>
>>>         [email-masked] <mailto:[email-masked]>
>>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 16 Mar 2010 15:02:37 +0100

I think signing Authorization Headers would make sense.

regards,
Torsten.

Am 16.03.2010 07:48, schrieb Igor Faynberg:
> 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

---

From: John Kemp <[email-masked]>
Date: Tue, 16 Mar 2010 15:45:05 +0200

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 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 <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 16 Mar 2010 15:11:10 +0100

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:
> "Protect integrity of whole request - authorization data and payload 
> when communicating over unsecure channel"
>
> 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.)
>

---

From: Ethan Jewett <[email-masked]>
Date: Tue, 16 Mar 2010 10:45:32 -0400

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

---

From: Brian Eaton <[email-masked]>
Date: Tue, 16 Mar 2010 10:51:04 -0700

> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please review

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

---

From: John Panzer <[email-masked]>
Date: Tue, 16 Mar 2010 10:58:48 -0700

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).

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Tue, 16 Mar 2010 13:50:25 -0500

>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: [email-masked] [mailto:[email-masked]] On Behalf Of John Kemp
Sent: Tuesday, March 16, 2010 9:45 AM
To: Faynberg, Igor (Igor)
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Signatures, Why?

Regards,

- johnk

---

From: John Panzer <[email-masked]>
Date: Tue, 16 Mar 2010 12:05:33 -0700

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) <
[email-masked]> 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?
>
> 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
> 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?
> >>
> >> On Mon, Mar 15, 2010 at 11:22 PM, John Panzer <[email-masked]<mailto:
> [email-masked]>> wrote:
> >>

---

From: Eve Maler <[email-masked]>
Date: Tue, 16 Mar 2010 13:35:43 -0700

Hi Brian,

> 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
[email-masked]