Subject: [OAUTH-WG] MAC Discussion

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

Justin wrote: 
"
I believe that there's value in per-message signing completely apart from the channel level encryption. 
"

May well be. But we have to figure out what exactly the reasons are why there is value. 

Bill wrote:
"
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case.
"

This would be a very quick process if we had ever done our home work properly. 

So, what are the problems it tries to solve? Yesterday I found an old presentation about MAC and the basic argument was that it has better performance than TLS. While that's true it is not a good argument per se. However, performance is not the only factor to look at and the negative performance impact caused by TLS is overrated.  

Here is the slide set I am talking about: 
http://www.tschofenig.priv.at/Why_are_we_Signing.pdf

In many cases I had noticed that more time was spent with the pictures (in slides and blog post) than with the content. That's not good IMHO. 

Bill, we can hardly call a specification "complete" if many of us don't know what problem it solves. John phrases it nicely as "Part of the problem with MAC has been that people could never agree on what it was protecting against." I am also interested in hearing about deployment constraints that people have. Blaine always said that many developers cannot get TLS to work. I am sure that's true but OAuth 2.0 requires TLS to be used anyway to secure the interaction with the authorization server. 

Note: I am not saying that we are not going to standardize something like the MAC token (maybe with different details) but let us spend a little bit of time to figure out what threats we want to deal with.

---

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

> May well be. But we have to figure out what exactly the reasons are why there is value. 

Yes, there is value in this, and that's why we're collecting a handful of use cases to support this. Otherwise, people wouldn't keep reinventing this. See SAML and OpenID Connect's signed request object for other examples.

> This would be a very quick process if we had ever done our home work properly. 

It's not done, but it's not empty. Why throw it out? Whether or not we continue the draft itself or import its best ideas into a new draft is beside the point.

> So, what are the problems it tries to solve? Yesterday I found an old presentation about MAC and the basic argument was that it has better performance than TLS. While that's true it is not a good a…

This is a red herring, as pointed out by other use cases.

> Bill, we can hardly call a specification "complete" if many of us don't know what problem it solves. John phrases it nicely as "Part of the problem with MAC has been that people could never agree o…

It solves this problem: How can I use the framework of OAuth to get a temporary signing key that I can use to protect HTTP messages with signing (without stuffing my parameters into a structured document like a SAML or JWT assertion)? There are many justifications for that problem and use cases that expand on this, but that's the core thing that the MAC does.

> Note: I am not saying that we are not going to standardize something like the MAC token (maybe with different details) but let us spend a little bit of time to figure out what threats we want to de…

It's not just about threats, it's about capabilities and features. 

 -- Justin

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

---

From: Phil Hunt <[email-masked]>
Date: Fri, 10 Aug 2012 10:03:22 -0700

There's no reason why the spec, or key elements of it can't be re-used.

But to assume it should be "THE" spec, goes against previous formal consensus (can't remember if it was Quebec or Paris meeting) and jumps the gun on defining what the problem is. If we jump into a spec without defining the problem, we're guessing.  What I saw of the previous email discussion was a lot of circular debate indicating no clear problem definition.

I agree, it would be nice to re-use code from previous implementations.  But that strikes me as an issue to raise when we discuss the implementation based upon future consensus of the problem.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Tue, 14 Aug 2012 19:17:38 +0000

Replying to Justin's point about the OpenID Connect signed request object, Justin, I don't believe this comparison is accurate.  When an OpenID Request Object is signed, a single, self-contained object is being signed.  The signing described in the MAC spec signs a combination of payload elements and transport elements.  It's a testament to the complexity of this approach that Eran kept changing which elements were signed and which weren't in successive drafts.

Signing an OpenID Connect Request Object is simple (just apply JWS).  Signing using the MAC algorithm is an exercise left to the reader...

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, August 10, 2012 10:03 AM
To: Richer, Justin P.
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] MAC Discussion

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Aug 2012 16:48:20 -0400

I would argue that it's exactly the process that you describe below that 
makes my original comparison accurate. As a strawman example, OAuth2 
core specifies a bunch of parameters that get sent to the Auth Endpoint, 
like scope and response_type. OpenID Connect defines a few more, like 
display. In order to get these protected by a signature, I have to take 
them out of the HTTP parameters and put them into a secondary object for 
message transit. What I believe you're missing is that there are times 
where I don't *want* to bundle everything up into a container object. 
Sure it's a relatively straightforward process to create a JSON object 
and sign it with JWS, but then the server has to unfurl the whole thing. 
What if I *want* to use my existing HTTP processors for pulling out 
variables? What if I need to do routing based on these? Connect takes 
the approach of letting you specify things in both the object and the 
query params and has rules about how their values have to match. The way 
we've had to do this in one of our systems is to take that signed JSON, 
preprocess it, and pretend that it's a parameter map so that other parts 
of the system can make any sense of it. I don't want to have to repeat 
that for every API I want to protect in a similar manner.

Are there use cases for putting everything into a single object? 
Absolutely! It's a great thing to be able to do, and we are using JWT 
and its kin all over the place to do just that. In Connect's case, there 
were other, more complex data structures that were at play that the 
request object uses. But if I just wanted to protect the default 
parameters with a signature, why should I jump through the hoops of 
putting it into a container? Are you really suggesting that in order to 
get signature protection on parameters, we should put everything into 
container objects? To me, this feels like a move back to SOAP more than 
anything else, and I'd like an alternative.

Could the MAC-draft be a lot better at defining these parameters? 
Absolutely, which is why I think we need to fix it. History informs us 
but it doesn't define us: Just because it hasn't been done right yet 
doesn't mean that it can't be done. Signing with the MAC algorithm 
*should* be simple. It should be at least as easy and powerful as 
OAuth1, and hopefully much easier if we do it right. I think that there 
have been real suggestions about *how* to do this as well.

At the end of the day, I think we need both approaches for different 
uses and deployments.

  -- Justin

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 15 Aug 2012 10:41:15 +0900

So, are we talking about the authz request or resource request?

=nat via iPhone

On Aug 15, 2012, at 5:49 AM, Justin Richer <[email-masked]> wrote:

> I would argue that it's exactly the process that you describe below that makes my original comparison accurate. As a strawman example, OAuth2 core specifies a bunch of parameters that get sent to the Auth Endpoint, like scope and response_type. OpenID Connect defines a few more, like display. In order to get these protected by a signature, I have to take them out of the HTTP parameters and put them into a secondary object for message transit. What I believe you're missing is that there are times where I don't *want* to bundle everything up into a container object. Sure it's a relatively straightforward process to create a JSON object and sign it with JWS, but then the server has to unfurl the whole thing. What if I *want* to use my existing HTTP processors for pulling out variables? What if I need to do routing based on these? Connect takes the approach of letting you specify things in both the object and the query params and has rules about how their values have to match. The way we've had to do this in one of our systems is to take that signed JSON, preprocess it, and pretend that it's a parameter map so that other parts of the system can make any sense of it. I don't want to have to repeat that for every API I want to protect in a similar manner.
>
> Are there use cases for putting everything into a single object? Absolutely! It's a great thing to be able to do, and we are using JWT and its kin all over the place to do just that. In Connect's case, there were other, more complex data structures that were at play that the request object uses. But if I just wanted to protect the default parameters with a signature, why should I jump through the hoops of putting it into a container? Are you really suggesting that in order to get signature protection on parameters, we should put everything into container objects? To me, this feels like a move back to SOAP more than anything else, and I'd like an alternative.
>
> Could the MAC-draft be a lot better at defining these parameters? Absolutely, which is why I think we need to fix it. History informs us but it doesn't define us: Just because it hasn't been done right yet doesn't mean that it can't be done. Signing with the MAC algorithm *should* be simple. It should be at least as easy and powerful as OAuth1, and hopefully much easier if we do it right. I think that there have been real suggestions about *how* to do this as well.
>
> At the end of the day, I think we need both approaches for different uses and deployments.
>
> -- Justin
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Aug 2012 08:50:20 +0300

Hi Nat, 

in the MAC discussions I was only talking about the interaction between the client and the resource server. 

Ciao
Hannes

On Aug 15, 2012, at 4:41 AM, Nat Sakimura wrote:

>> I would argue that it's exactly the process that you describe below that makes my original comparison accurate. As a strawman example, OAuth2 core specifies a bunch of parameters that get sent to the Auth Endpoint, like scope and response_type. OpenID Connect defines a few more, like display. In order to get these protected by a signature, I have to take them out of the HTTP parameters and put them into a secondary object for message transit. What I believe you're missing is that there are times where I don't *want* to bundle everything up into a container object. Sure it's a relatively straightforward process to create a JSON object and sign it with JWS, but then the server has to unfurl the whole thing. What if I *want* to use my existing HTTP processors for pulling out variables? What if I need to do routing based on these? Connect takes the approach of letting you specify things in both the object and the query params and has rules about how their values have to match. 
> The way we've had to do this in one of our systems is to take that signed JSON, preprocess it, and pretend that it's a parameter map so that other parts of the system can make any sense of it. I don't want to have to repeat that for every API I want to protect in a similar manner.
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 15 Aug 2012 12:15:27 +0300

Hi Mike
> Replying to Justin's point about the OpenID Connect signed request object, Justin, I don't believe this comparison is accurate.  When an OpenID Request Object is signed, a single, self-contained ob…

Is there a requirement to get a transport-independent token envelope 
working ? I guess it might be the case when OAuth2 is implemented with 
the help of HTTP-centric and existing stores (ex, WS-based ones).
MAC is an HTTP-centric scheme, so it seems OK that transport elements 
are also included

> Signing an OpenID Connect Request Object is simple (just apply JWS).  Signing using the MAC algorithm is an exercise left to the reader...

Even I was able to understand how MAC signature is done, with the help 
of stock Java classes. I reckon appying JWS is simple indeed, provided 
JWS routine is available :-). Not trying to compare both approaches 
here, but I agree with the statements that both mechanisms might be useful.

Btw, seeing http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-03 
referencing MAC too,

Cheers, Sergey