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

Dick Hardt <dick.hardt@gmail.com> Fri, 10 August 2012 16:18 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2AD21F87B3 for <oauth@ietfa.amsl.com>; Fri, 10 Aug 2012 09:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.57
X-Spam-Level:
X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skmrGShM2sPJ for <oauth@ietfa.amsl.com>; Fri, 10 Aug 2012 09:18:37 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3623121F87BC for <oauth@ietf.org>; Fri, 10 Aug 2012 09:18:37 -0700 (PDT)
Received: by pbbrr4 with SMTP id rr4so2952639pbb.31 for <oauth@ietf.org>; Fri, 10 Aug 2012 09:18:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eLMWk3JyL3OdJdzgq+aP2I9Zy3BtRLYJ8NNUVDN2BqY=; b=ys55rBMdeu19DNBHys0j4PAEMk+PggiC5BKM4uzVKpmLrZFFNJ76EYYM98dm6CCqlE 5bWDhIjG2rNEerLBJfVHfkYnRhwFuVUED9QIBajHSckVNNmxiEzbya7qqcAU8os2Qina YoqKATvtmGGsEXe/Ww6G4dq/NMMy/Yzf5Ga0voS6dkTdzZKEvWZWua3lN4OS0z0VIGxV WGSZAgQIkFCrsOGgenerVeHo1T7SGTUetpcPS1rsNkz+iIV7xuBaLAQu6ip/gAiPDUe+ OVWoqKBai0XXsaHyuTBfUNo5DdqLQ7SASKaaWz8VVjfMMPxARHGGfTY8pR5k6U0aGbbt uSKg==
Received: by 10.68.241.65 with SMTP id wg1mr13960311pbc.25.1344615516898; Fri, 10 Aug 2012 09:18:36 -0700 (PDT)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id oa5sm3616285pbb.14.2012.08.10.09.18.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 09:18:34 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <50252211.2010105@cdatazone.org>
Date: Fri, 10 Aug 2012 09:18:30 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com>
References: <CAOKdZ1dzVcKBDt6CSLuHwc4NzUVd_hUMWdpJVS6=ncdJo05=UQ@mail.gmail.com> <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <EEBC9705-16C0-4697-8F38-28660C3CB553@ve7jtb.com> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> <B33BFB58CCC8BE4998958016839DE27E067DF372@IMCMBX01.MITRE.ORG> <50252211.2010105@cdatazone.org>
To: Rob Richards <rrichards@cdatazone.org>
X-Mailer: Apple Mail (2.1278)
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 16:18:38 -0000

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