Re: [OAUTH-WG] MAC Discussion

[Mike Jones <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Phil Hunt
Sent: Friday, August 10, 2012 10:03 AM
To: Richer, Justin P.
Cc: [e-mail] WG
Subject: Re: [OAUTH-WG] MAC Discussion

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
[e-mail]





On 2012-08-10, at 7:49 AM, Richer, Justin P. wrote:

> 
> On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote:
> 
>> 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. 
> 
> 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.
> 
>> 
>> 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. 
> 
> 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 argument per se. However, performance is not the only factor to look at and the negative performance impact caused by TLS is overrated.  
> 
> This is a red herring, as pointed out by other use cases.
> 
>> 
>> 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. 
> 
> 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 deal with. 
> 
> It's not just about threats, it's about capabilities and features. 
> 
> -- Justin
> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth