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

Neil Madden <> Fri, 15 November 2019 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B30B1208DD for <>; Fri, 15 Nov 2019 08:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 8M0o2dSz1ATv for <>; Fri, 15 Nov 2019 08:45:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BA281208E3 for <>; Fri, 15 Nov 2019 08:45:32 -0800 (PST)
Received: by with SMTP id t1so11703870wrv.4 for <>; Fri, 15 Nov 2019 08:45:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5uOJYEO/hcLjDoS4/qz+BbFuf7isLcgalJkVEpCQtew=; b=L8IOIvuU86YFk9hg681N0NfKxbtMtS25q/0kwtcY6lAm/g5vvoJuAurCueIAgdkN3s 2RXQCKuEwP07MnUEyfeAV3/SbJg3kbgprfvLgC4mWGaZQZU2BiQqBxexy4iJLcvhqm65 AYAjKWS66bq6S+wkBpzKC+wTdMXpgk1cYgc1w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5uOJYEO/hcLjDoS4/qz+BbFuf7isLcgalJkVEpCQtew=; b=QDfXjYppBZuweMo6aZH3yzd3fe3tjsSyDXxBTZvhFUVdFZQooLo0jNiFJ1WUJyCFyi DXA3qcIVZBdIKL8e3/QI0PerekyzbmKtbbRc4TgNrInJdNPyKZqxzpCC3p2e5v82WNnx VjLaWygfD4PtUe+B9AXXYLz+inib/7l2Ous2P/hRAAgp0qwBwNMnZNaIaUv7y1wDl1wa 4tfciJa4PAFtQsvQSJA25vYDZKJ1wX7oM5uzpwmJcqjneyD66ZNKL+pMatLfxYgPExKn BsuiTHhg9lqlNc4lSDch5rcSBfFr0I6DwJ0Mb/CJYj8/hZc2UwC59UntYso+G3PLEkei 3pDQ==
X-Gm-Message-State: APjAAAWYJgwk8cBI6rllBL5ttEswW1b01wIy+bH96TOq10VhluYlqPoa X6dzF5twViFSxRHTtBsst4i3RMxheCw=
X-Google-Smtp-Source: APXvYqyDcCCiN6DJam6kf4UCXReSXg7yihIsW100RcdldWz8cIcMxmSesTZDssT5GQGFzke4tlKU0A==
X-Received: by 2002:adf:f60e:: with SMTP id t14mr15793783wrp.292.1573836330520; Fri, 15 Nov 2019 08:45:30 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id z6sm12636149wro.18.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 08:45:29 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Madden <>
In-Reply-To: <>
Date: Fri, 15 Nov 2019 16:45:27 +0000
Cc: oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Paul Querna <>
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, 15 Nov 2019 16:45:56 -0000

A few comments below.

On 15 Nov 2019, at 15:32, Paul Querna <> wrote:
> Echoing Neil's concerns, I posted this to the issue tracker:
> I've been talking to several large scale API operators about DPoP.  A
> consistent concern is the CPU cost of doing an asymmetric key
> validation on every HTTP Request at the RS.
> Micro-benchmarks on this are easy to make, and at lower in the
> protocol stack, eg TLS, there is only one asymmetric operation before
> a symmetric key is exchanged, so maybe DPoP as it stands would be hard
> to deploy.

Right, which was the intention of my proposed alternative scheme: the client and RS do a single ECDH operation each and then can reuse the derived HMAC key for many requests.

> I think the primary concern is at the RS level of validation.
> Depending on the RS, the "work" of a request can be highly variable,
> so adding a single asymmetric key operation could be a significant
> portion of CPU usage at scale.
> In my discussions, at the AS layer, there is a general belief that the
> request rate and overhead of validating a DPoP signature can be OK.
> (I work at Okta -- the AS CPU usage is important too, but we already
> do a bunch of "other" expensive work on token requests, such that
> adding one more EdDSA validate is a rounding error in the short term).
> Supporting `HS256` or similar signing of the proof would be one way to
> reduce the CPU usage concerns.
> The challenge seems to be getting the symmetric key to the RS in a
> distributed manner.
> This use case could be scoped as a separate specification if that
> makes the most sense, building upon DPoP.
> Throwing out a potential scheme here:
> - **5.  Token Request (Binding Tokens to a Public Key)**: The request
> from the client is unchanged. If the AS decides this access token
> should use a symmetric key it:
> 1) Returns the `token_type` as `DPoP+symmetric`
> 2) Adds a new field to the token response: `token_key`.  This should
> be a symmetric key in JWK format, encrypted to the client's DPoP-bound
> asymmetric key using JWE.  This means the client still must be able to
> decrypt this JWE before proceeding using its private key.
> - **6.  Resource Access (Proof of Possession for Access Tokens)**: The
> DPoP Proof from the client would use the `token_key` issued by the AS.
> - **7.  Public Key Confirmation**: Instead of the `jkt` claim, add a
> new `cnf` claim type: JSON Encrypted Key or  `jek`.  The `jek` claim
> would be an JWE encrypted value, containing the symmetric key used for
> signing the `DPoP` proof header in the RS request.   The JWE
> relationship between the AS and RS would be outside the scope of the
> specification -- many AS's have registries of RS and their
> capabilities, and might agree upon a symmetric key distribution system
> ahead of time, in order to decrypt the `jek` confirmation.

If the RS has a client secret to access the token introspection endpoint, this could be reused in this case.

Whether this scheme is acceptable depends on clarifying the threat model that DPoP is intended to address. If we are only concerned about a fake RS (without any genuine relationship with the AS) and a client being tricked into sending it an access token, then this approach would be fine. The fake RS is unable to obtain the HMAC key and so all it can do is try and replay the access token and DPoP token somewhere else (which should be prevented by the claims in the DPoP token).

But if we are concerned about a potentially malicious RS that *does* have valid credentials (but is not the RS that the client thinks it is, or is a genuine RS that has been compromised), then this scheme fails because the malicious RS learns the HMAC key and then can use it to create any DPoP proofs that it wants, so the access token is completely compromised.

In the ECDH solution I proposed, a unique key is derived for each RS and the hostname of that RS is included in the key derivation. Assuming the client doesn't make a mistake when including this information then this means that the RS does not ever learn a HMAC key that is valid for any other server and so is unable to make any forgeries.

> I think this scheme would change RS validation of an DPoP-bound proof
> from one asymmetric key verify, into two symmetric key operations: one
> signature verify on the DPoP token, and potentially one symmetric
> decrypt on the `jek` claim.

This does mean that the AS either needs to know ahead of time which RS will receive the access token (so that it can pre-encrypt the key for them), or else it needs to keep the symmetric DPoP keys around in a recoverable form - which creates a potential risk if clients reuse keys for multiple access tokens.

-- Neil