Subject: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

From: Justas Janauskas <[email-masked]>
Date: Sun, 5 Aug 2012 13:30:55 +0300

Hello,

Sorry if this is not the right group to send this message; I am new here.

I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.

I made a small program to test correctness of an example and it shows
that it is incorrectly calculated in the document:
https://gist.github.com/3263677

I have also implemented an example from previous draft 00, section 1.2
which shows that request MAC is calculated correctly there:
https://gist.github.com/3263765

Thank you,
Justas Janauskas

---

From: Justin Richer <[email-masked]>
Date: Wed, 8 Aug 2012 11:08:08 -0400

Thanks Justas. The MAC document is currently without an editor within 
the WG, so this is the best place to record the error.

A wider note to the WG: I wouldn't mind taking over editorship of the 
MAC token document so long as I could get a co-editor with enough 
cryptographic expertise to make sure all the magical crypto bits work 
like they should. I've sent an email to the chairs saying as much, as well.

  -- Justin

On 08/05/2012 06:30 AM, Justas Janauskas wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Wed, 8 Aug 2012 08:22:39 -0700 (PDT)

Justin,

Count me in to help revive this and get it done.

-bill

________________________________
 From: Justin Richer <[email-masked]>
To: [email-masked] 
Sent: Wednesday, August 8, 2012 8:08 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

  -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Aug 2012 19:24:33 +0300

Hi Justas, 

thanks for sending your feedback to the list. 

There is indeed currently no editor for the document. That is, however, not the problem. 
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want. 

For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors. 

Ciao
Hannes

On Aug 8, 2012, at 6:08 PM, Justin Richer wrote:

> Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
> 
> A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
> 
> -- Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 8 Aug 2012 09:53:33 -0700

I have promised to put together a summary of the discussion presented in vancouver meeting. 

Unfortunately it may take a few weeks as i am away for another week and a half. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Wed, 8 Aug 2012 16:59:48 -0400

I believe that there's value in per-message signing completely apart 
from the channel level encryption. MAC tokens let us do this with a 
per-token secret using a pattern very well established in OAuth1. I'm 
sorry that I wasn't at the Vancouver meeting to voice this opinion, for 
what it's worth.

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Wed, 8 Aug 2012 17:21:52 -0400

We did discuss per message signing in Vancouver.

The idea is to get agreement on the threats we are trying to mitigate, then decide on the mechanisms.

Per message signing will likely still be one of the mechanisms. 

The chair will need to decide if we start fresh and copy the parts of MAC that are needed or try and continue the existing MAC draft.

John B.

On 2012-08-08, at 4:59 PM, Justin Richer wrote:

> I believe that there's value in per-message signing completely apart from the channel level encryption. MAC tokens let us do this with a per-token secret using a pattern very well established in OAuth1. I'm sorry that I wasn't at the Vancouver meeting to voice this opinion, for what it's worth.
> 
> -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Aug 2012 10:41:28 -0400

OK, that's fair. I just don't want process to get in the way of progress.

  -- Justin

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 09:52:55 -0700 (PDT)

I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.

I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.

-bill

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Aug 2012 10:27:27 -0700

> I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.

Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 

For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.

Just my $.02

-- Dick

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 10:53:43 -0700 (PDT)

MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.

________________________________
 From: Dick Hardt <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Just my $.02

-- Dick

---

From: Tom Brown <[email-masked]>
Date: Thu, 9 Aug 2012 12:57:58 -0500

also, the oauth 2 abstract says the following so it seems confusing that
oauth 1 is the proposed solution for mac:

This
   specification replaces and obsoletes the OAuth 1.0 protocol described
   in RFC 5849 <http://tools.ietf.org/html/rfc5849>.

On Thu, Aug 9, 2012 at 12:53 PM, William Mills <[email-masked]>wrote:

> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are
> libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model
> and will provide for a single codepath for sites that want to use both
> Bearer and MAC.
>
>    ------------------------------
> *From:* Dick Hardt <[email-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Thursday, August 9, 2012 10:27 AM
>
> *Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>
>
> I find the idea of starting from scratch frustrating.  MAC solves a set of
> specific problems and has a well defined use case.  It's symmetric key
> based which doesn't work for some folks, and the question is do we try to
> develop something that supports both PK and SK, or finish the SK use case
> and then work on a PK based draft.
>

---

From: John Bradley <[email-masked]>
Date: Thu, 9 Aug 2012 14:26:05 -0400

In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.

The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.

Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.

People are welcome to contribute to the use-case document.

Part of the problem with MAC has been that people could never agree on what it was protecting against.  

I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored. 

John B.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Aug 2012 19:29:11 +0100

> The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.

Just to clarify: I don't care if its documented in an I-D,
a tune you whistle, or a bunch of emails.

I do agree with what Hannes was saying in Vancouver: that
the WG need to figure out what you want and document that
however the chairs figure is best.

S

---

From: prateek mishra <[email-masked]>
Date: Thu, 09 Aug 2012 14:29:31 -0400

+1

finishing a draft for historical reasons without the full context of HoK 
use-cases and identified threats concerns me

> The Chair and AD indicated a desire to have a document on the 
> use-cases we are trying to address before deciding on progressing MAC 
> or starting a new document.
>
> Phil Hunt is going to put together a summery of the Vancouver 
> discussion and we are going to work on the use-case/problem 
> description document ASAP.
>
>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there 
>> are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 
>> auth model and will provide for a single codepath for sites that want 
>> to use both Bearer and MAC.
>>
>> ------------------------------------------------------------------------
>> *From:* Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> *To:* William Mills <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:* "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> <mailto:[email-masked]>>
>>> I find the idea of starting from scratch frustrating.  MAC solves a 
>>> set of specific problems and has a well defined use case.  It's 
>>> symmetric key based which doesn't work for some folks, and the 
>>> question is do we try to develop something that supports both PK and 
>>> SK, or finish the SK use case and then work on a PK based draft.
>>>
>> [email-masked] <mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 11:43:39 -0700 (PDT)

OK, I'll play and start documenting the use cases.  

Use case #1: Secure authentication in plain text connections:

Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.   the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.

-bill

________________________________
 From: John Bradley <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Dick Hardt <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

John B.

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 09 Aug 2012 22:22:47 +0300

> libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth

I work on the framework which already supports MAC (with major thanks to 
a user contribution). I'm not too worried that MAC draft may not end up 
being a final specification - because OAuth2.0 allows for different 
token types and whatever MAC already offers can be 'packaged' as a 
custom token if really needed, moreover, experienced users may help to 
fix whatever bugs that still remain in the draft; I'm very new to this 
list and effort, but I think I can get that it offers a (symmetric) 
holder-of-key support - and as such it's good for the framework because 
there will be users which will like working with MAC.

Having said that, I'd really like to give some support to the idea of 
completing the draft - to minimize the proliferation of custom token 
types which may end up trying to solve the same problem

> and will provide for a single codepath for sites that want to use
> both Bearer and MAC.

+1

Sergey

>> I find the idea of starting from scratch frustrating. MAC solves a set
>> of specific problems and has a well defined use case. It's symmetric
>> key based which doesn't work for some folks, and the question is do we
>> try to develop something that supports both PK and SK, or finish the
>> SK use case and then work on a PK based draft.
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Aug 2012 15:37:09 -0400

Use case #2: signature protection over plain HTTP parameters

MAC gives us message-level signing in a way that doesn't require all the 
parameters to be packed into an extra structure, like JWT/SAML do. TLS 
gives no application-layer verification of integrity of parameters, nor 
does it give you the ability to know who presented those parameters 
(unless you're doing mutual TLS, which nobody does). MAC gives you a 
fairly simple way to protect all parameters on a call to the resource 
server while still keeping all of those parameters in their native HTTP 
forms.

Use case #3: generic signed HTTP fetch (not directly addressed by MAC 
spec as of today)

Sometimes you want to create a URL with one service, fix all of the 
parameters in that URL, and protect those parameters with a signature. 
Then that URL can be passed to an untrusted service who cannot modify 
any portion of it. Nor can they re-use the signature portion to protect 
different parameters. We do this today with a 2-legged OAuth signature 
across a service URL. The "Client" generates the signed URLs and passes 
them to a user agent which actually does the fetch to the service.

  -- Justin

On 08/09/2012 02:43 PM, William Mills wrote:
> Some applications need a secure form authorization, but do not want or 
> need the overhead of encrypted connections.  HTTP cookies and their 
> ilk are replayable credentials and do not satisfy this need.   the MAC 
> scheme using signed HTTP authorization credentials offer the 
> capability to securely authorize a transaction, can offer integrity 
> protection on all or part of an HTTP request, and can provide replay 
> protection.
>
> -bill
>
> *From:* John Bradley <[email-masked]>
> *Cc:* Dick Hardt <[email-masked]>; "[email-masked]" 
> <[email-masked]>
> *Sent:* Thursday, August 9, 2012 11:26 AM

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Aug 2012 12:48:11 -0700

As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with.

I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard.

On Aug 9, 2012, at 10:53 AM, William Mills wrote:

> Sent: Thursday, August 9, 2012 10:27 Aa

---

From: Justin Richer <[email-masked]>
Date: Thu, 9 Aug 2012 16:08:35 -0400

With MAC, you should be able to re-use about 80-90% of your existing 
codepath that's in place for Bearer, simplifying the setup below.

I would figure that the "variant of OAuth2" issue is a red herring 
because not everyone out there is fully spec compliant. If they were, 
you wouldn't have so many beautiful snowflakes.

  -- Justin

On 08/09/2012 03:48 PM, Dick Hardt wrote:
> As an implementer, I have an app that accesses 10 different resources. 
> Some are OAuth 1.0A, some are a variant of OAuth 2. All have a 
> slightly different code path since each resource is its own beautiful 
> snowflake. I did not use any libraries for OAuth 2. Supporting MAC 
> would give me yet another library to integrate with.
>
> I'd be interested in what signing problems OAuth 1.0A has. I have my 
> own list of how writing to OAuth 1.0A is hard.
>
>> *Sent:* Thursday, August 9, 2012 10:27 Aa

---

From: George Fletcher <[email-masked]>
Date: Thu, 09 Aug 2012 16:32:10 -0400

+1

We've supported #3 for quite some time in our public APIs that pre-date 
OAuth.

Thanks,
George

On 8/9/12 3:37 PM, Justin Richer wrote:
> MAC gives us message-level signing in a way that doesn't require all 
> the parameters to be packed into an extra structure, like JWT/SAML do. 
> TLS gives no application-layer verification of integrity of 
> parameters, nor does it give you the ability to know who presented 
> those parameters (unless you're doing mutual TLS, which nobody does). 
> MAC gives you a fairly simple way to protect all parameters on a call 
> to the resource server while still keeping all of those parameters in 
> their native HTTP forms.
>
>
> any portion of it. Nor can they re-use the signature portion to 
> protect different parameters. We do this today with a 2-legged OAuth 
> signature across a service URL. The "Client" generates the signed URLs 
> and passes them to a user agent which actually does the fetch to the 
> service.
>
>
>  -- Justin
>
>> Some applications need a secure form authorization, but do not want 
>> or need the overhead of encrypted connections.  HTTP cookies and 
>> their ilk are replayable credentials and do not satisfy this need.   
>> the MAC scheme using signed HTTP authorization credentials offer the 
>>> auth model and will provide for a single codepath for sites that 
>>> want to use both Bearer and MAC.
>>>
>>>> question is do we try to develop something that supports both PK 
>>>> and SK, or finish the SK use case and then work on a PK based draft.
>>>>

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 13:47:30 -0700 (PDT)

Mostly it's around making sure you get the signature base string constructed right in my experience.

Sent: Thursday, August 9, 2012 12:48 PM

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Aug 2012 15:39:50 -0700

Yes, sort of.

I blew two days debugging my code accessing Twitter.

We had intermittent failures. It would work for hours, and then fail for hours.

Eventually I noticed that we were calling http://api.twitter.com instead of https://api.twitter.com. Once we changed that it worked fine.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Aug 2012 15:47:36 -0700

On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:

> With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below. 

That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAuth 2.0

> 
> I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so many beautiful snowflakes.

Being consistent in the spec would help, but likely would just give me snowflakes that look more like each other.

There are many aspects of the OAuth dance that are implementation dependent and it is simpler to just have a separate method for each one that deals with those unique characteristics. Note this is not theory, this is practice. Different modules was not an issue. Not having to use a library to sign requests and being able to use CURL or a browser to see what a request returned had a HUGE productivity gain for OAuth 2.0 implementations over OAuth 1.0A implemetations.

---

From: David Waite <[email-masked]>
Date: Thu, 9 Aug 2012 17:02:06 -0600

For #1:
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?

For #2:
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?

-DW

On Aug 9, 2012, at 1:37 PM, Justin Richer <[email-masked]> wrote:

> MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.
> 
> 
> Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
> 
> Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.
> 
> 
>  -- Justin
>

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 16:19:51 -0700 (PDT)

AS would still be required to be HTTPS as per the spec.

________________________________
 From: David Waite <[email-masked]>
To: [email-masked] 
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

For #1:

For #2:

-DW

>
>MAC gives us message-level signing in a way that doesn't require
      all the parameters to be packed into an extra structure, like
      JWT/SAML do. TLS gives no application-layer verification of
      integrity of parameters, nor does it give you the ability to know
      who presented those parameters (unless you're doing mutual TLS,
      which nobody does). MAC gives you a fairly simple way to protect
      all parameters on a call to the resource server while still
      keeping all of those parameters in their native HTTP forms.
>Sometimes you want to create a URL with one service, fix all of
      the parameters in that URL, and protect those parameters with a
      signature. Then that URL can be passed to an untrusted service who
      cannot modify any portion of it. Nor can they re-use the signature
      portion to protect different parameters. We do this today with a
      2-legged OAuth signature across a service URL. The "Client"
      generates the signed URLs and passes them to a user agent which
      actually does the fetch to the service.
>>>https://www.ietf.org/mailman/listinfo/oauth
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 9 Aug 2012 23:47:54 -0400

Bill,

I seem to recall in Paris that client misconfiguration of TLS was a concern.

In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication.

If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions.  Or conversely additional protection of the token endpoint needs to be considered for key distribution.

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 Aug 2012 10:01:30 +0300

Hi Bill, 

thanks for the feedback. Let's have a look at this use case: 

You need to provide me a bit more information regarding your use case. Could you please explain 

1) Who is authenticated to whom?
2) What plaintext connection are you talking about? 
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument? 
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well. 
5) What is the threat you are concerned about? 

Ciao
Hannes

PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 Aug 2012 10:05:23 +0300

Hi Justin, 

thanks for the feedback. Comments below. 

> MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity…

First, we have to assume as a starting point that we have bearer. So, assuming that there is actually plain HTTP for the communication between the client and the resource server does not exist. 

TLS does indeed not give the ability for the resource server to know who the client is. Client authentication would do that. 
Btw, the MAC draft does not allow the client to be authenticated. 

The MAC token does not protect all the parameters in the message. In fact, it protects only very, very few!

TLS is an application layer protocol (it runs on top of TCP) and protects the integrity and the confidentiality of the parameters in an end-to-end fashion. However, as others have noted the end on the server side may be a load balancer in case a system administrator has intentionally decided to terminate all secure traffic there. Saying that MAC would then be "more e2e" may be true unless the administrator has again decided to terminate it also at the load balancer (which may not be completely unlikely). 

> Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who ca…
(I personally would have even liked to get rid of the 2-legged OAuth use cases). 

I think that this use case is again a bit different from what we have been talking about so far. Maybe you want to compile an Internet draft so that we have more details to assess the security properties better. 

Ciao
Hannes

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 07:36:11 -0700 (PDT)

I would say that's true in theory, but practically speaking it's not gonna happen.  You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable.

If we're gonna improve on the current PKI that is SSL certificates we should do that separately.

________________________________
 From: John Bradley <[email-masked]>
To: William Mills <[email-masked]> 
Cc: David Waite <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Bill,

John B.

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 10 Aug 2012 14:38:03 +0000

> thanks for the feedback. Comments below. 

Sure thing, I think that use cases are very important to enumerate. I think the fact that several people in the WG are coming forward and saying "Yes I have use cases for this" is very telling that this is an important problem to solve.

> First, we have to assume as a starting point that we have bearer. So, assuming that there is actually plain HTTP for the communication between the client and the resource server does not exist. 

I'm confused here -- what exactly do you mean by this statement?

> Btw, the MAC draft does not allow the client to be authenticated. 

TLS mutual auth doesn't let you express the full context that comes with an OAuth token. 

> The MAC token does not protect all the parameters in the message. In fact, it protects only very, very few!

Which is why we need to update and fix it! I never said that MAC was *done*, just that it's a pretty good starting point and we shouldn't ignore it. This is the point that Bill was making, too, if I read it right.

> TLS is an application layer protocol (it runs on top of TCP) and protects the integrity and the confidentiality of the parameters in an end-to-end fashion. However, as others have noted the end on…

Load balancers and performance are a red herring and are distracting this conversation. There are other reasons to have message-level signing. Not everything is a single point-to-point HTTP transaction that TLS assumes. In such multi-hop scenarios, TLS can protect things on the wire but not within the components that can read and forward it, such as in use case #3 below.

> (I personally would have even liked to get rid of the 2-legged OAuth use cases). 

There are many, many important use cases that use the two legged pattern, and many, many people use them today in both OAuth1 (which never specified them) and OAuth2 (which finally embraced them as valid). They're not going away.

> I think that this use case is again a bit different from what we have been talking about so far. Maybe you want to compile an Internet draft so that we have more details to assess the security prop…

Yes it is, but it can be covered by the same solution set with some minor changes. Like I said, it's not directly covered by the MAC draft right now. 

I have other scenarios that have message-level signing as a stated requirement, full stop. I'd like to be able to use OAuth machinery to fulfill this.

 -- Justin

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 10 Aug 2012 14:38:53 +0000

Agreed w/Bill, let's not unnecessarily conflate the problem space.

 -- Justin

On Aug 10, 2012, at 10:36 AM, William Mills wrote:

________________________________
From: John Bradley <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: David Waite <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Bill,

John B.

________________________________
From: David Waite <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

For #1:

For #2:

-DW

On Aug 9, 2012, at 1:37 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

-bill

________________________________
From: John Bradley <[email-masked]><mailto:[email-masked]>
To: William Mills <[email-masked]><mailto:[email-masked]>
Cc: Dick Hardt <[email-masked]><mailto:[email-masked]>; "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

John B.

________________________________
From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Just my $.02

-- Dick

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

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

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

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

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

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 10 Aug 2012 14:41:05 +0000

What about security in depth? Signing + TLS is more secure than either alone, isn't it?

 -- Justin

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 07:42:42 -0700 (PDT)

________________________________
From: Hannes Tschofenig <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; John Bradley <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, August 10, 2012 12:01 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Hi Bill, 

wjm> the client is authenticated to the server.

wjm> generally an HTTP connection to a webservice

wjm>  Yes, annoying but true.  This may change, but we do business with enough folks that refuse SSL that this is a real problem.

wjm>  No, I'm pointing out the problems with a simple replayable credential like cookies as a comparison.

wjm> The vulnerability of plaintext connections: theft of credentials and tampering. 

Ciao
Hannes

---

From: Rob Richards <[email-masked]>
Date: Fri, 10 Aug 2012 11:00:33 -0400

I think you nailed it which that statement. Up until now it as been back 
and forth about one or the other. Personally I prefer to used layered 
security and not relying on a single point of attack. It's unrealistic 
to say everyone is going to want/need/be able to use (take your pick) 
signed/encrypted JWT. MAC at least offers an alternative, less 
complicated solution.

Rob

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Aug 2012 11:09:10 -0400

No I wasn't talking about changing TLS.  I think the TLS threat has been expressed more as people who turn verification in the client rather than any failure of the TLS protocol or certificates.

The question I was trying to get at was if any of the message signing was intended to protect against clients misconfiguring TLS or Man in the middle attacking communications with the RS or token server.

Part of the reason behind MAC has been expressed as concern that Server TLS doesn't prevent tokens from being intercepted and replayed sufficiently.   

Where TLS is used if we believe clients are properly implemented what is the signing getting us.

I think sessions without TLS and TLS terminated on the firewall need to be supported, but there the threat is clearer.

John

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 08:59:27 -0700 (PDT)

It's not intended to address anything in TLS other than the fact that we have real use cases where TLS isn't in play.  

Sent: Friday, August 10, 2012 8:09 AM

John

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Aug 2012 12:07:35 -0400

Specifically, there are cases where it "isn't in play at all" and cases 
where it "isn't in play end to end".

  -- Justin

On 08/10/2012 11:59 AM, William Mills wrote:
> It's not intended to address anything in TLS other than the fact that 
> we have real use cases where TLS isn't in play.
>
>
> *Cc:* David Waite <[email-masked]>; "[email-masked]" 
> <[email-masked]>
> *Sent:* Friday, August 10, 2012 8:09 AM
> No I wasn't talking about changing TLS.  I think the TLS threat has 
> been expressed more as people who turn verification in the client 
> rather than any failure of the TLS protocol or certificates.
>
> The question I was trying to get at was if any of the message signing 
> was intended to protect against clients misconfiguring TLS or Man in 
> the middle attacking communications with the RS or token server.
>
> Part of the reason behind MAC has been expressed as concern that 
> Server TLS doesn't prevent tokens from being intercepted and replayed 
> sufficiently.
>
> I think sessions without TLS and TLS terminated on the firewall need 
> to be supported, but there the threat is clearer.
>
> John
>
>> I would say that's true in theory, but practically speaking it's not 
>> gonna happen.  You're stating we need to come up with a better method 
>> for public key than we have now for this to be widely adopted, and I 
>> don't think that's reasonable.
>>
>> *From:* John Bradley <[email-masked] <mailto:[email-masked]>>
>> *Cc:* David Waite <[email-masked] 
>> <mailto:[email-masked]>>; "[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> *Sent:* Thursday, August 9, 2012 8:47 PM
>> If this is OK and we trust the client to do TLS server certificate 
>> verification correctly that needs to go in as one of our base 
>> assumptions.  Or conversely additional protection of the token 
>> endpoint needs to be considered for key distribution.
>>
>> John B.
>>> *From:* David Waite <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *To:* [email-masked] <mailto:[email-masked]>
>>> *Sent:* Thursday, August 9, 2012 4:02 PM
>>> Does the use of plain HTTP to talk to protected resources provide 
>>> significant value when using an AS that requires HTTPS? Or am I 
>>> misunderstanding, and this use case would also include new modes for 
>>> non-TLS communication with the AS?
>>>
>>> For #2:
>>> Would the signature protection just cover HTTP parameters, or would 
>>> it extend to covering any request data, such as a PUT binary 
>>> file? Would the integrity protection only cover requests, or would 
>>> you also have integrity protection of the response?
>>>
>>> -DW
>>>
>>>> all parameters on a call to the resource server while still keeping 
>>>> all of those parameters in their native HTTP forms.
>>>>
>>>>
>>>> parameters in that URL, and protect those parameters with a 
>>>>> Some applications need a secure form authorization, but do not 
>>>>> want or need the overhead of encrypted connections.  HTTP cookies 
>>>>> and their ilk are replayable credentials and do not satisfy this 
>>>>> need.   the MAC scheme using signed HTTP authorization credentials 
>>>>> offer the capability to securely authorize a transaction, can 
>>>>> offer integrity protection on all or part of an HTTP request, and 
>>>>> can provide replay protection.
>>>>>
>>>>> -bill
>>>>>
>>>>> *From:* John Bradley <[email-masked]> <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>
>>>>> *Cc:* Dick Hardt <[email-masked]> 
>>>>> <mailto:[email-masked]>; "[email-masked]" 
>>>>> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>>>>> In Vancouver the question was asked about the future of the MAC 
>>>>> spec due to it no linger having a editor.
>>>>>
>>>>> use-cases we are trying to address before deciding on progressing 
>>>>> MAC or starting a new document.
>>>>>
>>>>> I think there is general agreement that one or more proof 
>>>>> mechanisms are required for access tokens.
>>>>>> MAC fixes the signing problems encountered in OAuth 1.0a, yes 
>>>>>> there are libraries out there for OAuth 1.0a.  MAC fits in to the 
>>>>>> OAuth 2 auth model and will provide for a single codepath for 
>>>>>> sites that want to use both Bearer and MAC.
>>>>>>
>>>>>>> I find the idea of starting from scratch frustrating.  MAC 
>>>>>>> solves a set of specific problems and has a well defined use 
>>>>>>> case.  It's symmetric key based which doesn't work for some 
>>>>>>> folks, and the question is do we try to develop something that 
>>>>>>> supports both PK and SK, or finish the SK use case and then work 
>>>>>>> on a PK based draft.
>>>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Aug 2012 09:18:30 -0700

As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.

Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens. 

I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A?

-- Dick

On Aug 10, 2012, at 8:00 AM, Rob Richards wrote:

> I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution.
> 
> Rob
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Aug 2012 12:25:18 -0400

The reason is simple: to benefit from the rest of the improvements in 
the OAuth2 framework. These are just the ones off the top of my head:

1) Multiple means for getting a token (all the flows are now available)
2) No request tokens
3) No reliance on per-client secrets (though, addendum, I think the MAC 
spec should be augmented to use them if present)
4) Ability to integrate with many different extensions to OAuth2, both 
now and in the future

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Aug 2012 12:28:07 -0400

On 08/09/2012 06:47 PM, Dick Hardt wrote:
> That makes no sense, I would be adding MAC to the sites that support 
> MAC in addition to OAuth 1.0A or OAuth 2.0

You get to re-use all of the code for OAuth2 for issuing tokens (from 
server side) and requesting tokens (from client side). Apart from 
parsing the JSON value that's returned from the token endpoint (and you 
are using a generic parser there, right?), nothing changes here. The 
part where you *use* the token to access a protected resource (client), 
or *validate* a request to a protected resource (server) changes 
significantly, yes. But that's only a small part of the process.

> Being consistent in the spec would help, but likely would just give me 
> snowflakes that look more like each other.
>
> There are many aspects of the OAuth dance that are implementation 
> dependent and it is simpler to just have a separate method for each 
> one that deals with those unique characteristics. Note this is not 
> theory, this is practice. Different modules was not an issue. Not 
> having to use a library to sign requests and being able to use CURL or 
> a browser to see what a request returned had a HUGE productivity gain 
> for OAuth 2.0 implementations over OAuth 1.0A implemetations.
>
>>
>>  -- Justin
>>
>>> As an implementer, I have an app that accesses 10 different 
>>> resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All 
>>> have a slightly different code path since each resource is its own 
>>> beautiful snowflake. I did not use any libraries for OAuth 2. 
>>> Supporting MAC would give me yet another library to integrate with.
>>>
>>>>> I find the idea of starting from scratch frustrating.  MAC solves 
>>>>> a set of specific problems and has a well defined use case.  It's

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Aug 2012 09:43:53 -0700

Those reasons make sense to me, thanks for enumerating.

On Aug 10, 2012, at 9:25 AM, Justin Richer wrote:

> The reason is simple: to benefit from the rest of the improvements in the OAuth2 framework. These are just the ones off the top of my head:
> 
> 3) No reliance on per-client secrets (though, addendum, I think the MAC spec should be augmented to use them if present)
> 4) Ability to integrate with many different extensions to OAuth2, both now and in the future
> 
> -- Justin
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Aug 2012 09:48:59 -0700

On Aug 10, 2012, at 9:28 AM, Justin Richer wrote:

> You get to re-use all of the code for OAuth2 for issuing tokens (from server side) and requesting tokens (from client side). Apart from parsing the JSON value that's returned from the token endpoint (and you are using a generic parser there, right?), nothing changes here. The part where you *use* the token to access a protected resource (client), or *validate* a request to a protected resource (server) changes significantly, yes. But that's only a small part of the process.

That makes sense, sorry I was not clear on what I said did not make sense, which was "simplifying the setup below"

As a client developer, adding MAC to the mix *increases* my code base as it is yet another protocol to understand and implement against. OAuth 1.0A and OAuth 2.0 bearer are not going to go away.

-- Dick

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 09:57:35 -0700 (PDT)

In no particular order:

As I said before, and many have said before me, a major issue with OAuth 1.0a has always been the signing process.  Yes there are libraries.  MAC was begun before there were a significant number of libraries.  You also have to process/parse the post body for oauth_ variables if you're really going to be compliant, and people don't like that much.

OAuth 1.0a has signing with a client secret, but that secret is managed out of band.  MAC+Oauth 2 has the client secret issued with the token.  This is fundamentally different and far more suitable for the consumer/end user client case.  1.0a is structured more for a 3 party model, where the secret is used to authenticate the 3rd party, out of band secret management isn't as much of a problem there.  

1.0a is just clumsy to implement for consumer/end user clients, the OAuth 2 model is far cleaner, and in the end in 1.0a  the secret ends up not a secret anymore.  It ends up being the equivalent of bearer tokens in security.   This is because, I think,  fundamentally the client secret is tied in through the token request/auth stuff and then also in the access to the protected resource.  

We could theoretically have something very similar to the way MAC tokens would be fetched in OAuth 2, and use that secret with OAuth 1.0a signing to access the protected resource.  That would work, but it would be kinda gross.

-bill

________________________________
 From: Dick Hardt <[email-masked]>
To: Rob Richards <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, August 10, 2012 9:18 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

-- Dick

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Aug 2012 13:02:42 -0400

On 08/10/2012 12:48 PM, Dick Hardt wrote:
>>>> With MAC, you should be able to re-use about 80-90% of your 
>>>> existing codepath that's in place for Bearer, simplifying the setup 
>>>> below.
>>>
>> parsing the JSON value that's returned from the token endpoint (and 
>> you are using a generic parser there, right?), nothing changes here. 
>> The part where you *use* the token to access a protected resource 
>> (client), or *validate* a request to a protected resource (server) 
>> changes significantly, yes. But that's only a small part of the process.
>
> That makes sense, sorry I was not clear on what I said did not make 
> sense, which was "simplifying the setup below"
>
> As a client developer, adding MAC to the mix *increases* my code base 
> as it is yet another protocol to understand and implement against. 
> OAuth 1.0A and OAuth 2.0 bearer are not going to go away.
>
>
OK, I follow now. Yes, that's a fair concern for anyone who has to 
support multiple protocols that aren't mutually compatible. I'm 
personally hoping that OAuth2/MAC will help push out most (if not all) 
of the remaining OAuth1 pieces we have here, helping is shut down at 
least one of those.

  -- Justin