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

On Aug 10, 2012, at 3:05 AM, Hannes Tschofenig wrote:

> Hi Justin, 
> 
> 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.

> 
> On Aug 9, 2012, at 10:37 PM, Justin Richer wrote:
> 
>> 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.
>> 
> 
> 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?

> 
> 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. 

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 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). 

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.

> 
>> 
>> 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.
>> 
>> 
> (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 properties better. 
> 

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

> Ciao
> Hannes
> 
>> -- Justin
>> 
>> On 08/09/2012 02:43 PM, William Mills wrote:
>>> 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 <ve7jtb@ve7jtb.com>
>>> To: William Mills <wmills_92105@yahoo.com> 
>>> Cc: Dick Hardt <dick.hardt@gmail.com>; "oauth@ietf.org" <oauth@ietf.org> 
>>> Sent: Thursday, August 9, 2012 11:26 AM
>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>> 
>>> 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.
>>> 
>>> On 2012-08-09, at 1:53 PM, William Mills 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 <dick.hardt@gmail.com>
>>>> To: William Mills <wmills_92105@yahoo.com> 
>>>> Cc: "oauth@ietf.org" <oauth@ietf.org> 
>>>> Sent: Thursday, August 9, 2012 10:27 AM
>>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>>> 
>>>> 
>>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote:
>>>> 
>>>>> 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.
>>>> 
>>>> 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  
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> 
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 