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

Neil Madden <> Fri, 22 November 2019 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58171120147 for <>; Fri, 22 Nov 2019 04:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 52zMJSJKKpQQ for <>; Fri, 22 Nov 2019 04:50:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1ABA0120899 for <>; Fri, 22 Nov 2019 04:50:06 -0800 (PST)
Received: by with SMTP id f129so6121239wmf.2 for <>; Fri, 22 Nov 2019 04:50:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sURTW2guBwLuBiqnSgghIZIbyzKIlw6Tez3CVxwaEMc=; b=KfSg7/NoCALuPeD3g6YYZXiMWfcYJC1CXTiGH86aCPSo0Rtjyuy3ynbokYwkjRVRyk vfdW3wcpt5eNukHonskGCAx42Kh5k9yMXpGI4dZ7Sl0dxg7cfahD7ikn/1VPu8F39p/d oMlY5YDJw+WqO5T1Ebrlh+a710mz1HdvIOVz0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sURTW2guBwLuBiqnSgghIZIbyzKIlw6Tez3CVxwaEMc=; b=pHKK+9H7sMj8QJpxs8hUAVt8ZGyxAn1PJ6Jf5O1h73MQbxBNY7vwxwrA8QJm0cNPbL ph7MJFDqmrkkrkkyXLtovtQvDuOEJUBFh4Yxm0SFevYrxJzMZOgxuhzd8FcvCDDVDScT RSd29NUm5UShKeCWo35HEOH/YMBqLCB1Xw5DAy7Nv/MqcJy8ERUH5DKdp8izVhRa8ZkB sdYlC0lNzibB+sBz63UzP8xtjUgMgh0VA79T7EardegYyt4D/tgCmfZgJ+suPKPrcaPa cC14e6kFBmgArGdedaQqLAgM5I3r0uP6IpJaS/2Bp1U4KE/UMUGIyq602EVEQH0pQpla mdog==
X-Gm-Message-State: APjAAAVrHDJK5QUSYCxn+K/KlB4M+tMtBzFu7QC9KC/+UHq0edXAbUYJ PcKhS9QlfQ08wVogAJ2kMyvh/g==
X-Google-Smtp-Source: APXvYqxN9nZQWWNDRB/UTB62g3s1VTaJQ71mN3io3BgA1Mr2JT537yJIbvKfUH3eANpT+nKwvwO7Sw==
X-Received: by 2002:a1c:6144:: with SMTP id v65mr16735318wmb.53.1574427004552; Fri, 22 Nov 2019 04:50:04 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id o1sm7842500wrs.50.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Nov 2019 04:50:03 -0800 (PST)
From: Neil Madden <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E46BD393-7001-4533-9213-54372290FC8A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 22 Nov 2019 12:50:01 +0000
In-Reply-To: <>
Cc: Justin Richer <>, oauth <>
To: Torsten Lodderstedt <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Nov 2019 12:50:15 -0000

Hi Torsten,

On 22 Nov 2019, at 12:15, Torsten Lodderstedt <> wrote:
> Hi Neil,
>> On 22. Nov 2019, at 18:08, Neil Madden <> 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.

> 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 <>.
> <> 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 ( <>). 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.

(I think Brian also mentioned this pattern at OSW, but it might have been somebody else).

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

-- Neil