Subject: [OAUTH-WG] Include Normalized Request with Raw Request

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 13 Jan 2010 22:51:34 -0700

Authentication Open Question #2: Should the normalized request be included
with the request?

In OAuth 1.0 the request is normalized into the signature base string by the
client and the server. The base string itself is never sent with the
request. Brian Eaton proposed [1] to include the signed string with the
request, removing the need for the server to regenerate the normalized
string, as well as allowing the client to use the included string to send
additional (signed) information that is not part of the HTTP request.

This is a significant departure from OAuth 1.0, but one that does call for
an in-depth discussion.

Some advantages to this approach are:

- the server can easily verify what is being signed
- the client can include additional parameters in the signed message
- the request remains valid even if changed by proxies or other
intermediaries

Some disadvantages are:

- the request is sent twice, once raw and once normalized
- it adds another place to make mistakes and create security holes if the
server uses the raw data without fully comparing it to the normalized
(signed) data
- since any server enforcing security will only use the data contained in
the normalized portion, it will create a de-facto standard for API requests
(not nearly as heavy as SOAP or WS-*) in which case the request itself is
normalized before sending.

QUESTIONS: How do people feel about this? What are some other advantaged and
disadvantages of this approach?

EHL

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 13 Jan 2010 22:58:15 -0800

> - the request remains valid even if changed by proxies or other

This is the part I didn't get in Brian's original thread, either.
Presumably, a request is valid only if the pieces in the normalized part and
in the raw part somehow match. If an (untrusted) proxy changes the raw
pieces, it destroys the request just like it would in normal OAuth, right?

I don't buy that we need to move heaven and earth just because some people
don't know how to put a signature base string together.

If we believe that the "meddling proxy" use cases are important to support
(i.e, we believe that a request modified by a third party should still carry
the same authority as the unmodified request), then we should just drop
signatures altogether and use bearer tokens. I don't see how getting rid of
the signature base string helps.

Dirk.

Some disadvantages are:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Blaine Cook <[email-masked]>
Date: Thu, 14 Jan 2010 13:08:44 +0000

> disadvantages of this approach?

The disadvantages you outlined massively outweigh the advantages. I've
had a persistent search for OAuth on Twitter for some time now, and
anecdotally, people are "getting" it more, or the libraries are
getting better. In that sense, I echo Dirk's sentiment here.

The signature in OAuth 1.0+ and in draft-hammer-http-token-auth is
designed to break if someone implements something insecurely. The goal
of these mechanisms is not to make it easy for people to authenticate
insecurely. It's to make it as easy as possible (but no easier) to
ensure secure authentication.

b.

---

From: John Panzer <[email-masked]>
Date: Thu, 14 Jan 2010 09:26:01 -0800

As mentioned (in a separate thread?) Salmon's magic envelope mechanism does
something similar, albeit without requiring JSON.  However Salmon has a
harder requirement, to have the signature survive not only a single hop and
untrusted proxies, but also storage and re-syndication.  Not clear on
whether this nail requires such a big hammer.

I will note that if the magic envelope mechanism [1] were used, it wouldn't
have to send the payload twice, but clients would need to know about the
format.  On the other hand, it does make it ~impossible to accidentally use
data without checking the signature, assuming libraries refuse to open the
envelope without a valid signature.

Not advocating either way, just thinking out loud.

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

[1] Synopsis of magic envelope:  base64 encode whatever you've got as a
payload, sign the result.  Include the exact thing signed as your new
payload, wrapped in a trivial envelope that identifies what it is -- that
could be XML, JSON, or simply a MIME type in an HTTP request.  When you want
the data, you base64 decode first.  And check the signature while you're at
it.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 14 Jan 2010 14:41:58 -0800

> disadvantages of this approach?

-1 to including a normalized version of the request with the request.

As you point-out, it's tantamount to including the body of request in
the payload and treating HTTP—a transfer protocol—as a transport layer,
ignoring the majority of the features HTTP offers.

I'm inclined to bite the bullet and profile the flexible Eaton style (C)
signing token format such that different HTTP elements can be
enumerated, and such can be used to establish a normalized structure for
signing/verification.

> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html

Paul

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jan 2010 19:31:47 -0700

I would like to request a consensus call on this. So far the few people who chimed in expressed their inclination not to include the normalized string in the request. If no one speaks up advocating the opposite, I will continue with the current approach of normalizing the request but not including it in the request.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, January 13, 2010 9:52 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Include Normalized Request with Raw Request
> 
> Authentication Open Question #2: Should the normalized request be
> included with the request?
> 
> client and the server. The base string itself is never sent with the request.
> Brian Eaton proposed [1] to include the signed string with the request,
> removing the need for the server to regenerate the normalized string, as
> well as allowing the client to use the included string to send additional
> (signed) information that is not part of the HTTP request.
> 
> This is a significant departure from OAuth 1.0, but one that does call for an in-
> depth discussion.
> 
> - since any server enforcing security will only use the data contained in the
> normalized portion, it will create a de-facto standard for API requests (not
> nearly as heavy as SOAP or WS-*) in which case the request itself is
> QUESTIONS: How do people feel about this? What are some other
> advantaged and disadvantages of this approach?
> 
> 
> EHL
>