Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 22 November 2019 14:50 UTC

Return-Path: <torsten@lodderstedt.net>
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 A8C7C120876 for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 06:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 1FsQUkY3Y_hU for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 06:50:34 -0800 (PST)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527FD120867 for <oauth@ietf.org>; Fri, 22 Nov 2019 06:50:34 -0800 (PST)
Received: by mail-pj1-x102f.google.com with SMTP id t103so3141859pjb.6 for <oauth@ietf.org>; Fri, 22 Nov 2019 06:50:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=npSACM59pmclpEz2Ieeu4DkkkNo8iKI7NvYlRsmd5lg=; b=TdKgRaYkwV0I4MVgc90BbXDNqZ52XHTIyNSJrzFbJlcEwjMoqePTO6cegufHT9ktVy eCsenovtoJH27HUrofpKt49InwQxqP/JSbmtxIXWUWb3MNDyqIdlhtUvK0a9lQLFvtQ9 lrGuYFPibnthEAh9apaniJ5Ysl8ijnX5mZ03Ebg/QBlmboyKz1aEbgk7Xql1/6fXyn3n WkMUMIXETp3Eu9A1jrev12Ypf8tnVVF1dpJo42fU/+Q1YBy2u4nfq3T/lgh/u+NIVl9q KII9XCY/xHNor+uNtR5lk7+Hj+5pFhXNJhbMa0BU2E3Pm0CmK0lmBvSLJaVoLdyH134c CnFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=npSACM59pmclpEz2Ieeu4DkkkNo8iKI7NvYlRsmd5lg=; b=LBTfHeEogRXwi+qZRdUW896kPM5JarWDbWQYzG+S7T2XuUs6gtecbmG9HoXbtYcZQO WlUV0JA/vqnXnySWRYhx773q0U2WAxgKTq0DMCpeiwyasdeyHk4BB2CxVi+CuV5iR8+I FoS9wXZB0hQTnqE9xVk+ICC/5IUN0a3Hs+oMy1ULrL7FiVvZ0DMwt78ak8OKXGwBuZsw 96N9icU7PXfUi9pg+9MPwNAK9b7zxWOir0uMCtQTIcsBhRf59jqrimQ+AHuzEz9GAR3C PrnXQgF2EztOzzX3LASOxYsQzhp3JKsU54yLKeUyxQgD9Bzr//QoY6NYe1wLqLLhH8xw Ef+Q==
X-Gm-Message-State: APjAAAVmy4NGHVZD4ni26YDVSkyk4utjLtbLu8mS3uq6K2+ls1x6KL83 ihOUvwP3ul4oTexakucKl8rOUfo07z5K8fvW
X-Google-Smtp-Source: APXvYqxCUG/DboavWVlp9ZquhZSenaPE4lktz4mCIs7hM+284lKWT6NLEizGX92mk9NVtUauNZ1eVw==
X-Received: by 2002:a17:902:5a4d:: with SMTP id f13mr1952892plm.250.1574434233482; Fri, 22 Nov 2019 06:50:33 -0800 (PST)
Received: from [10.84.13.52] ([103.137.210.94]) by smtp.gmail.com with ESMTPSA id w69sm8138362pfc.164.2019.11.22.06.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Nov 2019 06:50:32 -0800 (PST)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <542F255E-FE31-4905-9253-7296FC7BEE87@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_9790B7A9-6C55-462E-A670-9A41F8350E91"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 22 Nov 2019 22:50:25 +0800
In-Reply-To: <8E53499A-C2E1-4FE6-AE9B-BE8C582BECD1@amazon.com>
Cc: Annabelle Backman <richanna@amazon.com>, oauth <oauth@ietf.org>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
References: <2EF412B8-AF8C-4642-9BE0-1B528B0C63D5@amazon.com> <288343F2-ACF0-43E0-8577-26AF45330E5C@forgerock.com> <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com> <6DECA422-AACC-4DAA-8CD2-FF57CE02DE3E@mit.edu> <0235F8A2-83C4-4804-8805-F50305E263BB@lodderstedt.net> <D43D3929-F1B7-4A2C-ABEC-1326F3F0926C@forgerock.com> <1FD6E2DF-013A-4F42-862B-ADEF45EAE689@lodderstedt.net> <D6F0034F-7F70-442C-8334-733359DE44A9@amazon.com> <36707A3C-788D-4ACF-AAEF-35582BFB89B7@lodderstedt.net> <8E53499A-C2E1-4FE6-AE9B-BE8C582BECD1@amazon.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/N959qdlFgHBrmZX68mgvmYPaf9g>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
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: Fri, 22 Nov 2019 14:50:37 -0000


> On 22. Nov 2019, at 22:12, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:
> 
> The service provider doesn't own the entire connection. They have no control over corporate or government TLS gateways, or other terminators that might exist on the client's side. In larger organizations, or when cloud hosting is involved, the service team may not even own all the hops on their side.

how are cookies protected from leakage, replay, injection in a setup like this?

> While presumably they have some trust in them, protection against leaked bearer tokens is an attractive defense-in-depth measure.

That’s a totally valid point. But again, such a solution makes the life of client developers harder. 

I personally think, we as a community need to understand the pros and cons of both approaches. I also think we have not even come close to this point, which, in my option, is the prerequisite for making informed decisions.

> 
> – 
> Annabelle Richard Backman
> AWS Identity
> 
> 
> On 11/22/19, 9:37 PM, "OAuth on behalf of Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> 
> 
> 
>> On 22. Nov 2019, at 21:21, Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org> wrote:
>> 
>> The dichotomy of "TLS working" and "TLS failed" only applies to a single TLS connection. In non-end-to-end TLS environments, each TLS terminator between client and RS introduces additional token leakage/exfiltration risk, irrespective of the quality of the TLS connections themselves. Each terminator also introduces complexity for implementing mTLS, Token Binding, or any other TLS-based sender constraint solution, which means developers with non-end-to-end TLS use cases will be more likely to turn to DPoP.
> 
>    The point is we are talking about different developers here. The client developer does not need to care about the connection between proxy and service. She relies on the service provider to get it right. So the developers (or DevOps or admins) of the service provider need to ensure end to end security. And if the path is secured once, it will work for all clients. 
> 
>> If DPoP is intended to address "cases where neither mTLS nor OAuth Token Binding are available" [1], then it should address this risk of token leakage between client and RS. If on the other hand DPoP is only intended to support the SPA use case and assumes the use of end-to-end TLS, then the document should be updated to reflect that.
> 
>    I agree. 
> 
>> 
>> [1]: https://tools.ietf.org/html/draft-fett-oauth-dpop-03#section-1
>> 
>> – 
>> Annabelle Richard Backman
>> AWS Identity
>> 
>> 
>> On 11/22/19, 8:17 PM, "OAuth on behalf of Torsten Lodderstedt" <oauth-bounces@ietf.org on behalf of torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
>> 
>>   Hi Neil,
>> 
>>> On 22. Nov 2019, at 18:08, Neil Madden <neil.madden@forgerock.com> wrote:
>>> 
>>> On 22 Nov 2019, at 07:53, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 22. Nov 2019, at 15:24, Justin Richer <jricher@mit.edu> wrote:
>>>>> 
>>>>> I’m going to +1 Dick and Annabelle’s question about the scope here. That was the one major thing that struck me during the DPoP discussions in Singapore yesterday: we don’t seem to agree on what DPoP is for. Some (including the authors, it seems) see it as a quick point-solution to a specific use case. Others see it as a general PoP mechanism. 
>>>>> 
>>>>> If it’s the former, then it should be explicitly tied to one specific set of things. If it’s the latter, then it needs to be expanded. 
>>>> 
>>>> as a co-author of the DPoP draft I state again what I said yesterday: DPoP is a mechanism for sender-constraining access tokens sent from SPAs only. The threat to be prevented is token replay.
>>> 
>>> I think the phrase "token replay" is ambiguous. Traditionally it refers to an attacker being able to capture a token (or whole requests) in use and then replay it against the same RS. This is already protected against by the use of normal TLS on the connection between the client and the RS. I think instead you are referring to a malicious/compromised RS replaying the token to a different RS - which has more of the flavour of a man in the middle attack (of the phishing kind).
>> 
>>   I would argue TLS basically prevents leakage and not replay. The threats we try to cope with can be found in the Security BCP. There are multiple ways access tokens can leak, including referrer headers, mix-up, open redirection, browser history, and all sorts of access token leakage at the resource server
>> 
>>   Please have a look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.
>> 
>>   https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8 also has an extensive discussion of potential counter measures, including audience restricted access tokens and a conclusion to recommend sender constrained access tokens over other mechanisms.
>> 
>>> 
>>> But if that's the case then there are much simpler defences than those proposed in the current draft:
>>> 
>>> 1. Get separate access tokens for each RS with correct audience and scopes. The consensus appears to be that this is hard to do in some cases, hence the draft.
>> 
>>   How many deployments do you know that today are able to issue RS-specific access tokens?
>>   BTW: how would you identify the RS?
>> 
>>   I agree that would be an alternative and I’m a great fan of such tokens (and used them a lot at Deutsche Telekom) but in my perception this pattern needs still to be established in the market. Moreover, they basically protect from a rough RS (if the URL is used as audience) replaying the token someplace else, but they do not protect from all other kinds of leakage/replay (e.g. log files).
>> 
>>> 2. Make the DPoP token be a simple JWT with an "iat" and the origin of the RS. This stops the token being reused elsewhere but the client can reuse it (replay it) for many requests.
>>> 3. Issue a macaroon-based access token and the client can add a correct audience and scope restrictions at the point of use.
>> 
>>   Why is this needed if the access token is already audience restricted? Or do you propose this as alternative? 
>> 
>>> 
>>> Protecting against the first kind of replay attacks only becomes an issue if we assume the protections in TLS have failed. But if DPoP is only intended for cases where mTLS can't be used, it shouldn't have to protect against a stronger threat model in which we assume that TLS security has been lost.
>> 
>>   I agree. 
>> 
>>   best regards,
>>   Torsten. 
>> 
>>> 
>>> -- Neil
>> 
>> 
>> 
> 
> 
>