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

Neil Madden <neil.madden@forgerock.com> Sun, 24 November 2019 09:43 UTC

Return-Path: <neil.madden@forgerock.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 00E71120108 for <oauth@ietfa.amsl.com>; Sun, 24 Nov 2019 01:43:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=forgerock.com
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 pc6e-_HaTxR3 for <oauth@ietfa.amsl.com>; Sun, 24 Nov 2019 01:43:17 -0800 (PST)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 81237120105 for <oauth@ietf.org>; Sun, 24 Nov 2019 01:43:17 -0800 (PST)
Received: by mail-wr1-x42d.google.com with SMTP id t2so13839120wrr.1 for <oauth@ietf.org>; Sun, 24 Nov 2019 01:43:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=vqgaYtE8KFvaEd8X/6cbhE0IdwE+Ylfl0tlq3rl0bZk=; b=N6TJEH85XlZVvBXCdbUfzuCG0v+0Fkveakg8Gr36NlDtLwwk7pMfk7Uloi9bMXXxH7 RsjAxgA7fBk3uOBwGsLAPNAK/ZSdRl10CcUieZSqvsVDGIXkYuoXokDiUE2oTM3Q58MX 11esqCI9m0AC1RFo+VdxU2Fwje4d6By7ylF/g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=vqgaYtE8KFvaEd8X/6cbhE0IdwE+Ylfl0tlq3rl0bZk=; b=tzHxefW+GOCHyzrJGFvNPj0GTvCtjiWpyvIlxfwypwI7aQLevZ6Bwp92FSffrYxIQz aTigfvPgaMvUgEQFUpP1yfNbfwu+kJdIybuhMNFcdjFdxnjXkAfaKGFicRZj2LmUriqm QMfFjKmiuONo/6VmSZxvlf1b9HoRoc22wSp6Ff4UMqh4UuApYSrluaWbVE02GPT2hag1 MnVXRxmqEi6/86aqLCNGBIWjUDEr8c9mLP909/hcSTQnmY6VnWeAGj2GJCwlAjpeF8cW jlfYHL6rN19IQQv6TzGN003DXogKv44jvkDAkvNx1lKl1hoczsZ4vZ9zbiU6glGgrgA5 DYnw==
X-Gm-Message-State: APjAAAV14vKfwOZ/Fozh9JGFQDFAGw9rf/xR7JIQ2An0TApiEGidbf5h fUmVEz9xSGe3GODrXIJ7Vc9LJQ==
X-Google-Smtp-Source: APXvYqwtEMFcYeigil3enddOFidA8Get2z4r9+I3eL9QQ2/B4VPbM6mnb6nqZd1KHhLlLCks28gBJg==
X-Received: by 2002:adf:e74e:: with SMTP id c14mr25414785wrn.124.1574588595637; Sun, 24 Nov 2019 01:43:15 -0800 (PST)
Received: from ?IPv6:2a01:4c8:1e:a0cd:ec52:ae7:a130:6e65? ([2a01:4c8:1e:a0cd:ec52:ae7:a130:6e65]) by smtp.gmail.com with ESMTPSA id w12sm4604327wmi.17.2019.11.24.01.43.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Nov 2019 01:43:14 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-944A09A1-3A13-45F2-A1CC-949B6B75E95B"
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 24 Nov 2019 09:43:13 +0000
Message-Id: <E192E3A8-55BB-48AC-BCC3-F40EA9B04ABF@forgerock.com>
References: <1561F036-BE65-45B7-B206-5702774B3DBF@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
In-Reply-To: <1561F036-BE65-45B7-B206-5702774B3DBF@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/meLg5wTPD9i_6AZmmspHdDyPf20>
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: Sun, 24 Nov 2019 09:43:21 -0000

On 24 Nov 2019, at 07:59, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> 
> Hi Neil,
> 
> I would like to summarize what I believe to have understood is your opinion before commenting:
> 1) audience restricted access tokens is the way to cope with replay attempts between RSs

It’s one way, but yes that is sufficient. 

> 2) TLS prevents replay at the same RS
> 
> re 1) that works as long as ASs support audience restrictions and the audience restriction is the actual resource server URL, otherwise a staged RS can obtain access tokens audience restricted for a different RS and replay it there

Yes, audience restrictions only work if the AS supports it. DPoP only works if the AS, client, and *all* RSes all support it, right?

I’m not sure of your second point. Obviously an audience restriction needs to be unambiguous if it is to have any effect. 

> re 2) it seems you look onto that threat from the inside of a TLS connection. Let’s assume the attacker obtains the access tokens at the application layer, e.g. through a log file, referrer header, mix-up, browser history and then sends it through a new TLS connection to the same RS. How does TLS help to detect this replay?

These are token leakage/theft not replay - https://en.m.wikipedia.org/wiki/Replay_attack

And TLS has done a lot to protect against even these threats. For example, leaking credentials in logs was much more of a threat when you had to consider all kinds of proxies and middleboxes along the route. TLS has completely eliminated that threat, leaving just the logs at the RS itself. And the others are largely protected against by not putting access tokens in URLs, and things like Referrer-Policy/rel=no-referrer.

Leaking an audience-restricted access token into the logs of the RS itself seems a relatively minor threat to worry about. If you’re not managing logs securely then you’re probably already leaking all kinds of PII and other sensitive data that the access token grants access to. 

If the client and RS can’t get these things right then I would question whether public key signatures and associated key management is more likely to be done right. 

With macaroons the complexity is reduced and the AS performs all the checks. 

With ECDH, although complex, the critical security checks are encoded into the key derivation process - leading to the very desirable property that security failures become interoperability failures and so are more likely to be found and fixed in testing. (See the work done on using implicit nonces in TLS for an example of this principle - https://blog.cloudflare.com/tls-nonce-nse/)

— Neil

> 
>>> Am 24.11.2019 um 08:40 schrieb Neil Madden <neil.madden@forgerock.com>:
>>> 
>>> On 22 Nov 2019, at 13:33, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>> 
>>> Hi Neil,
>>> 
>>>>> On 22. Nov 2019, at 20:50, Neil Madden <neil.madden@forgerock.com> wrote:
>>>> 
>>>> Hi Torsten,
>>>> 
>>>>> On 22 Nov 2019, at 12:15, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>> 
>>>>> Hi Neil,
>>>>> 
>>>>>> On 22. Nov 2019, at 18:08, Neil Madden <neil.madden@forgerock.com> wrote:
>>>>>> 
>>>>>> 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.
>>>> 
>>>> It also protects against replay. If you capture TLS-encrypted packets with Wireshark you not only cannot decipher them but also cannot replay them because they include specific anti-replay measures at the record level in the form of unique session keys and record sequence numbers included in the MAC calculations. This is essential to the security of TLS.
>>> 
>>> I understand. I was looking onto TLS from an application perspective, that might explain differing perception.
>>> 
>>>> 
>>>>> 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.
>>>> 
>>>> OK, good - these are threats beyond token replay (at least as I understand that term). It would be good to explicitly add them to the DPoP document motivation.
>>>> 
>>>> Note that most of these ways that an access token can leak also apply equally to leak of the DPoP JWT, so the protection afforded by DPoP boils down to how well the restrictions encoded into the JWT prevent it from being reused in this case - e.g., restricting the expiry time, audience, scope, linking it to a specific request (htm/htu) etc. 
>>>> 
>>>> Every single one of those restrictions can be equally well encoded as caveats on a macaroon access token without any need for public key signatures or additional tokens and headers.
>>>> 
>>>>>> 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).
>>>> 
>>>> Many services already do this. For example, Google encodes the intended RS into the scopes on GCP (https://developers.google.com/identity/protocols/googlescopes) A client can do a single authorization flow to authorize all the scopes it needs and then use repeated calls to the refresh token endpoint to obtain individual access tokens with subsets of the authorized scopes for each endpoint.
>>> 
>>> And that works at google? How does the client indicate the RS it wants to use the first access token (that is obtains in the course of the code exchange)?
>> 
>> It doesn’t. The initial access token would be for all scopes and the client simply discards that one (or revokes it if the AS supports revoking individual tokens). 
>> 
>>>> (I think Brian also mentioned this pattern at OSW, but it might have been somebody else).
>>> 
>>> I know the pattern and we used this at Deutsche Telekom, but I don’t know any other deployment utilising this pattern. In my observation, most people treat access tokens as cookies and use them across RSs. Another reason might be that, before resource indicators, there was no interoperable way to ask for a token for a certain RS.
>> 
>> I don’t know anybody using DPoP either. The point is that you can do this kind of thing right now, so DPoP needs to have a stronger justification for why this isn’t sufficient.
>> 
>>>>>> 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? 
>>>> 
>>>> These are all alternatives. Any one of them prevents the specific attack of replay by the RS to another RS.
>>> 
>>> And which does for replay with the same RS?
>> 
>> TLS. 
>> 
>> — Neil