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

[Justin Richer <[e-mail]>]

On 09/03/2012 10:25 AM, Sergey Beryozkin wrote:
> On 10/08/12 17:18, Dick Hardt wrote:
>> 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?
>
> I see OAuth 1.0A users starting asking why to move to OAuth 2.0, 
> especially now that there's a bit of concern there for some of the 
> users due to the recent critique of OAuth 2.0.
>
> IMHO one of the best reasons for completing the MAC spec is to help 
> OAuth 1.0 users with migrating to OAuth 2.0 as the code flow + MAC is 
> indeed very similar to OAuth 1.0A; having different OAuth camps out 
> there won't be great
>

Very much agreed! It's a glaring hole in the capabilities of OAuth 2.0, 
and one I'd like to see patched, and soon.

  -- Justin

> Thanks, Sergey
>
>>
>> -- 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
>>>
>>> On 8/10/12 10:41 AM, Richer, Justin P. wrote:
>>>> What about security in depth? Signing + TLS is more secure than 
>>>> either alone, isn't it?
>>>>
>>>>   -- Justin
>>>>
>>>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote:
>>>>
>>>>> 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."
>>>>>
>>>>> On Aug 9, 2012, at 9: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<[e-mail]>
>>>>>> To: William Mills<[e-mail]>
>>>>>> Cc: Dick Hardt<[e-mail]>; 
>>>>>> "[e-mail]"<[e-mail]>
>>>>>> 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<[e-mail]>
>>>>>>> To: William Mills<[e-mail]>
>>>>>>> Cc: "[e-mail]"<[e-mail]>
>>>>>>> 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
>>>>>>> [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
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth