Re: [OAUTH-WG] draft-fett-oauth-dpop-00

David Waite <david@alkaline-solutions.com> Wed, 10 April 2019 03:56 UTC

Return-Path: <david@alkaline-solutions.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 C59911205CC for <oauth@ietfa.amsl.com>; Tue, 9 Apr 2019 20:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDFlzlmIdq9b for <oauth@ietfa.amsl.com>; Tue, 9 Apr 2019 20:56:13 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8DF12022D for <oauth@ietf.org>; Tue, 9 Apr 2019 20:56:13 -0700 (PDT)
Received: from [IPv6:2601:282:202:b210:744d:4b75:c7bf:3de] (unknown [IPv6:2601:282:202:b210:744d:4b75:c7bf:3de]) by alkaline-solutions.com (Postfix) with ESMTPSA id 4070E3166E; Wed, 10 Apr 2019 03:56:11 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <C9EA5E6A-CE83-4F8C-889A-97CE3D608864@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E6FF4CF-0D68-43A0-9C60-6D39A2CE76F8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Tue, 09 Apr 2019 21:56:10 -0600
In-Reply-To: <C9ED70E2-FB98-4CE2-B973-394853831441@mit.edu>
Cc: Brian Campbell <bcampbell@pingidentity.com>, George Fletcher <gffletch=40aol.com@dmarc.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
To: Justin Richer <jricher@mit.edu>
References: <0a9af6f6-1b5d-244d-06af-9d14461b1d69@yes.com> <4c849a55-013c-c606-8877-ae39a6ab79ff@aol.com> <435a1adb-6293-8745-96e8-d608f7dd934f@yes.com> <458bb5b9-f31f-4564-ae13-bc9f17a3fa4a@aol.com> <62C502BF-326F-4849-A1D2-A59B190FF200@oracle.com> <5C2A69C0-FB0A-48EA-922A-EBDEF11BF707@mit.edu> <CA+k3eCQrSwibwhdg2YhSqp_yBzatF2z7Uxdy886=2K2yRkf8Mg@mail.gmail.com> <C9ED70E2-FB98-4CE2-B973-394853831441@mit.edu>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PFu0-yOevz3GSKpKNJO2-eQFd3w>
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 10 Apr 2019 03:56:17 -0000

My understanding:

The proof-of-possession needs to have a limited destination to prevent replay against other resources. Similar to resource indicators and to distributed OAuth, the client is expected to use a resource URL view of the world rather than an access-token-specific audience or scoped view of the world. (And method, because thats cheap to do.)

HTTP request signing has a high degree of complexity, and has had several iterations each with their own strengths and weaknesses (which I know you are intimately familiar with!)

There is nothing currently to prevent other specification(s) adding extra key/values corresponding to a header set and hash, query hash, body hash, and so on. If that holds true in the final specification, then an environment could require those keys to be present, and then leverage DPoP for both proof-of-possession and non-repudiation. 

-DW

> On Apr 9, 2019, at 8:36 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> Then why include the request at all? Simpler to just sign a nonce and send those, then.
> 
> — Justin
> 
>> On Apr 9, 2019, at 7:05 PM, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>> 
>> The thought/intent is that it's really about proof-of-possession rather than protecting the request. So the signature is over a minimal set of information.
>> 
>> On Mon, Apr 8, 2019 at 5:41 PM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> Corollary to this, are there thoughts of header protection under this method, and the associated issue of header modification?
>> 
>> — Justin
>> 
>>> On Apr 8, 2019, at 7:23 PM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>> 
>>> Question. One of the issues that Justin Richer’s signing draft tried to address was url modification by tls terminators/load balencers/proxies/api gateways etc. 
>>> 
>>> How do you see this issue in dpop? Is it a problem? 
>>> 
>>> Phil
>>> 
>>> On Apr 3, 2019, at 9:01 AM, George Fletcher <gffletch=40aol.com@dmarc.ietf.org <mailto:gffletch=40aol.com@dmarc.ietf.org>> wrote:
>>> 
>>>> Perfect! Thank you! A couple comments on version 01...
>>>> 
>>>>    POST /token HTTP/1.1
>>>>    Host: server.example.com <http://server.example.com/>
>>>>    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
>>>>    DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
>>>> 
>>>>    grant_type=authorization_code
>>>>    &code=SplxlOBeZQQYbYS6WxSbIA
>>>>    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>>>>    (remainder of JWK omitted for brevity)
>>>> 
>>>> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding header...
>>>> 
>>>> Also, there is no discussion of the DPoP-Binding header outside of the token request, but I suspect that is the desired way to communicate the DPoP-Proof to the RS.
>>>> 
>>>> Possibly an example in the session for presenting the token to the RS would help.
>>>> 
>>>> Thanks,
>>>> George
>>>> 
>>>> On 4/3/19 11:39 AM, Daniel Fett wrote:
>>>>> This is fixed in -01:
>>>>> 
>>>>> https://tools.ietf.org/html/draft-fett-oauth-dpop-01 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D01&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=TEa5Vgb3rAzxbIuavB1lN65fnkTxKoMp7F2rw1AjuEY&e=>
>>>>> 
>>>>> -Daniel
>>>>> 
>>>>> Am 03.04.19 um 17:28 schrieb George Fletcher:
>>>>>> A quick question regarding...
>>>>>> 
>>>>>>    o  "http_uri": The HTTP URI used for the request, without query and
>>>>>>       fragment parts (REQUIRED).
>>>>>> 
>>>>>> Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :)
>>>>>> 
>>>>>> On 3/28/19 6:17 AM, Daniel Fett wrote:
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D00&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=eeMGKZq5R86dv0XgrBsIijzuI8OzQqnE-vmUEZ836hY&e=>
>>>>>>> Abstract
>>>>>>> 
>>>>>>>    This document defines a sender-constraint mechanism for OAuth 2.0
>>>>>>>    access tokens and refresh tokens utilizing an application-level
>>>>>>>    proof-of-possession mechanism based on public/private key pairs.
>>>>>>> 
>>>>>>> Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!
>>>>>>> 
>>>>>>> If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_webhamster_draft-2Ddpop&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=RR3u82IhN7whr8LgXMWM2fWN7EKH6GO-Bs-HRxEwKHE&e=>
>>>>>>> - Daniel    
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=>
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth