Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

From: William Mills <[email-masked]>
Date: Sat, 5 Feb 2011 08:41:41 -0800

Reading through and looking at your example in 1.1 I think you don't have enough lines.  Your text specified 9 elements to be signed, but you only have 7 lines in the text to be signed.  The way I read the text you should have 9 elements followed by newlines, which can be empty, but the newlines should be there.

-bill

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 21, 2011 5:10 PM
To: OAuth WG
Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02

http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02

New version includes the following changes:

   o  Added body-hash support.
   o  Updated OAuth 2.0 reference to -12 and added token type registration template.
   o  Removed error and error URI attributes (codes were just a duplication of the HTTP status codes).

Feedback would be greatly appreciated.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 5 Feb 2011 10:00:09 -0700

I'm confused. Can you cut-and-paste the problematic text?

From: William Mills [mailto:[email-masked]]
Sent: Saturday, February 05, 2011 8:42 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: draft-hammer-oauth-v2-mac-token-02

-bill

EHL

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 7 Feb 2011 17:36:04 +0100

A couple of editorial notes:

3.2 has a mismatch of parameters between the example and the text (eg, "using access token j92fsdjf094gjfdi,..." where h480djs93hd8 from 1.1 is used in the example). The timestamp and nonce are also mismatched, though bodyhash seems correct. As a result, the signature is invalid for the example.

3.3.1 gives an example of a request but doesn't provide the secret or a signature. It's not necessary here, but adding a valid Authentication header for this line as well as "using.... secret...algorithm" statement gives implementors more information to validate their work against the spec. Adding the algorithm for the token/secret would also inform the method implied (sha1) for the body hash in this example.

If these two issues are resolved, the spec gives 3 clear examples (eg, test case) for implementors to confirm their understanding of the signature process.  It's a valuable side-effect with very little effort or distraction.

skylar

On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote:

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

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 7 Feb 2011 18:24:39 +0100

On body-hash...

Having completed a trial implementation, it seems redundant, and potentially problematic, to include the body-hash in the Authentication header. The danger is that implementors may neglect to recalculate the hash themselves, reusing the value (even if incorrect) provided by the client. Why not just require the provider to calculate this and validate it by comparing the final signature? This way it's clearer for everyone what the expectations are in validating the signature.

I propose either a flag (eg, usebodyhash="1") or an algorithm (bodyhashalgorithm="sha1"). If this parameter was provided, the correct hash would be added to the base string for signing. If omitted (or set false?) then an empty string is used for base string element #4.

On including parameters for signing...

I'd retract my suggestion that we'd include parameter-hash in the header. Instead, I would suggest making parameters optional in calculating the signature using a flag as with bodyhash. Providers could require including parameters if so desired. Parameters could be included as currently defined, or with a hash method similar to entity-body (which I find both simpler and more congruent). 

Again, the goal in making query parameters optional is to allow providers to make signature calculation as simple as possible for clients (so much as it is in line with the security requirements of the provider) and avoid complexities in implementation such as those that tripped up OAuth 1.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 10:26:46 -0700

Yeah...

I struggled with that. There is no reason to include the body hash with the request other than to indicate a body hash is included in the normalized request string. It's just that an attribute like 'bodyhash=true' is so ugly...

I'm still thinking about this.

EHL

> -----Original Message-----
> From: Skylar Woodward [mailto:[email-masked]]
> Sent: Monday, February 07, 2011 9:25 AM
> Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02
> 
> On body-hash...
> 
> Having completed a trial implementation, it seems redundant, and
> potentially problematic, to include the body-hash in the Authentication
> header. The danger is that implementors may neglect to recalculate the hash
> themselves, reusing the value (even if incorrect) provided by the client. Why
> not just require the provider to calculate this and validate it by comparing the
> final signature? This way it's clearer for everyone what the expectations are
> in validating the signature.
> 
> I propose either a flag (eg, usebodyhash="1") or an algorithm
> (bodyhashalgorithm="sha1"). If this parameter was provided, the correct
> hash would be added to the base string for signing. If omitted (or set false?)
> then an empty string is used for base string element #4.
> 
> 
> I'd retract my suggestion that we'd include parameter-hash in the header.
> Instead, I would suggest making parameters optional in calculating the
> signature using a flag as with bodyhash. Providers could require including
> parameters if so desired. Parameters could be included as currently defined,
> or with a hash method similar to entity-body (which I find both simpler and
> more congruent).
> 
> Again, the goal in making query parameters optional is to allow providers to
> make signature calculation as simple as possible for clients (so much as it is in
> line with the security requirements of the provider) and avoid complexities in
> implementation such as those that tripped up OAuth 1.
> 
> 
>

---

From: William Mills <[email-masked]>
Date: Mon, 7 Feb 2011 14:06:19 -0800

Nevermind.  I have found the source of my confusion, and it was self-inflicted.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Saturday, February 05, 2011 9:00 AM
To: William Mills; OAuth WG
Subject: RE: draft-hammer-oauth-v2-mac-token-02

-bill

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 22:45:56 -0700

Hi Skylar, 

> implementation such as those that tripped up OAuth 1.

I have been opposed this line of thinking for over two years now.

As actual code shows, producing the normalized request string per this specification is straight-forward. Developers finding it hard should use a library and not try to write their own. They can also cut-and-paste the 10 or so lines it takes to produce the string.

This authentication method comes with well understood security properties. By making query parameters optional because of developer ease, providers will be giving up an important part of the protection this protocol offers. This is especially true for the majority of APIs where query parameters are critical to the request integrity.

The right solution here is to provide either a library for your developers, or an API without any parameters.

EHL

---

From: Skylar Woodward <[email-masked]>
Date: Tue, 8 Feb 2011 08:43:07 +0100

Here's a thought:

	signed_content="request,query,body"

If not included, it defaults to "request,query". It's non-breaking (except for the implied removal of bodyhash), allows for either body or query content to be omitted from the signature, and looks less ugly than bodyhash=true.  If you prefer, the value of this attribute could be one of a predefined string (request_query, request_query_body, request, etc.) rather than individual parsed elements.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 8 Feb 2011 01:20:41 -0700

There is no way I'm going to allow not signing the request URI and any query parameters. That leaves just the body...

EHL

> Sent: Monday, February 07, 2011 11:43 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> If not included, it defaults to "request,query". It's non-breaking (except for
> the implied removal of bodyhash), allows for either body or query content to
> be omitted from the signature, and looks less ugly than bodyhash=true.  If
> you prefer, the value of this attribute could be one of a predefined string
> (request_query, request_query_body, request, etc.) rather than individual
> parsed elements.
> 
> > I struggled with that. There is no reason to include the body hash with the
> request other than to indicate a body hash is included in the normalized
> request string. It's just that an attribute like 'bodyhash=true' is so ugly...
> >
> >> potentially problematic, to include the body-hash in the
> >> Authentication header. The danger is that implementors may neglect to
> >> recalculate the hash themselves, reusing the value (even if
> >> incorrect) provided by the client. Why not just require the provider
> >> to calculate this and validate it by comparing the final signature?
> >> This way it's clearer for everyone what the expectations are in validating
> the signature.
> >>
> >> (bodyhashalgorithm="sha1"). If this parameter was provided, the
> >> correct hash would be added to the base string for signing. If
> >> omitted (or set false?) then an empty string is used for base string
> element #4.
> >>
> >>
> >> Instead, I would suggest making parameters optional in calculating
> >> the signature using a flag as with bodyhash. Providers could require
> >> including parameters if so desired. Parameters could be included as
> >> currently defined, or with a hash method similar to entity-body
> >> (which I find both simpler and more congruent).
> >>
> >> Again, the goal in making query parameters optional is to allow
> >> providers to make signature calculation as simple as possible for
> >> clients (so much as it is in line with the security requirements of
> >> the provider) and avoid complexities in implementation such as those that
> tripped up OAuth 1.
> >>
> >>
> >>
> >>>   o  Updated OAuth 2.0 reference to -12 and added token type
> >>> registration
> >> template.
> >>>   o  Removed error and error URI attributes (codes were just a
> >>> duplication
> >> of the HTTP status codes).
> >>>

---

From: Skylar Woodward <[email-masked]>
Date: Tue, 8 Feb 2011 09:57:02 +0100

> This authentication method comes with well understood security properties. By making query parameters optional because of developer ease, providers will be giving up an important part of the protec…

Is the same then not true of content body? Why require one and not the other? Either you trust providers to decide when the content/parameter portions of a request (or an API) are critical to request integrity, or you don't.

With that argument  you should just require a body hash and be done with it. What's the argument to make it an optional part of the base string?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 8 Feb 2011 08:46:09 -0700

While important, the body is not always available for inspection and hashing. All the parameters normalization is done to ensure it will be possible on even the most limited platform. The same cannot be done for the body. That's why it is optional.

EHL

> Sent: Tuesday, February 08, 2011 12:57 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> > This authentication method comes with well understood security
> properties. By making query parameters optional because of developer
> ease, providers will be giving up an important part of the protection this
> protocol offers. This is especially true for the majority of APIs where query
> parameters are critical to the request integrity.
> 
> Is the same then not true of content body? Why require one and not the
> other? Either you trust providers to decide when the content/parameter
> portions of a request (or an API) are critical to request integrity, or you don't.
> 
> With that argument  you should just require a body hash and be done with it.
> What's the argument to make it an optional part of the base string?