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

Neil Madden <> Thu, 28 November 2019 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7039E12092C for <>; Wed, 27 Nov 2019 23:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BOmMCKwU-_XI for <>; Wed, 27 Nov 2019 23:42:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A6DE120271 for <>; Wed, 27 Nov 2019 23:42:33 -0800 (PST)
Received: by with SMTP id b18so29824702wrj.8 for <>; Wed, 27 Nov 2019 23:42:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:message-id:date :cc:to; bh=EUg0fEYNO6rDjhMZiAqfljguKSuXyvjxU3wHVf2j+14=; b=Wb4jrPVEwKPF87GYev3fnmmVLsY2/c14Bfs4aQWx2TluKlO9qb7iXw4pWgMjTgCgJo nz8nKNkrSUWnfJIY7q4VAnNLdoeNHwstBpF3vhHjW9moXezFpKtJIO2xnlPMqic84bMS ZiOSWbq3ODc2N7DXXtrA1kXuz01JAP3PrUHao=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:cc:to; bh=EUg0fEYNO6rDjhMZiAqfljguKSuXyvjxU3wHVf2j+14=; b=cNcl+yqld96mUjeRGJFNGVnMtfVUTxaOz83fosPpZcWKhyKIC02NlFs+XIAWMXMWXK IbXeJD5TMLCq7DbYhf0OOrYne35EIEN2IrVNC1efKiBGtp87H77SzW231ae1kwPTp31i hegE/4CMxFx0bOPlfANA7yz+ypddub7CAL5ceWLHv9XW/1Omya7+w180Pf/b7nXue7MG JMSWv89j+nDLXP43tBgNhFp3ebljJHgu8XeC4In0/mZNMRP7YkiuCYlEQHPYFVSVDopP BlIReZPayZV0CBGyZ71OxKrZCbXDYqwJ3nvYU/mcudFhClxuoUq9BkLqmSYEXeygsuH3 3nDQ==
X-Gm-Message-State: APjAAAWSa7jYCV5DSU2IcpqYbyTS5kjUuHBeh9lGAVJQvYToJV580lTJ TcwF69E+S7rUPubFSzTD4CeDIA==
X-Google-Smtp-Source: APXvYqxu2PFLramDKM0Gp+sY5HKcZQ2z0E1DAKirlYTHh0/u4WtOHWnIthtRz8He7Ptmw53ulwLeFw==
X-Received: by 2002:a5d:630d:: with SMTP id i13mr30655507wru.369.1574926951927; Wed, 27 Nov 2019 23:42:31 -0800 (PST)
Received: from ?IPv6:2a01:4c8:1e:a0cd:9d35:32b:7c76:aa8b? ([2a01:4c8:1e:a0cd:9d35:32b:7c76:aa8b]) by with ESMTPSA id g74sm9207210wme.5.2019. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Nov 2019 23:42:30 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-CDC380CE-6801-471C-B895-52C1FA078B46"
Content-Transfer-Encoding: 7bit
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Message-Id: <>
Date: Thu, 28 Nov 2019 07:42:29 +0000
Cc: Brian Campbell <>, oauth <>
To: "Richard Backman, Annabelle" <>
X-Mailer: iPhone Mail (17A878)
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: Thu, 28 Nov 2019 07:42:37 -0000

> On 27 Nov 2019, at 20:30, Richard Backman, Annabelle <> wrote:
> > That is true, but is IMO more of a hindrance than an advantage for a PoP scheme. The very fact that the signature is valid at every RS is why you need additional measures to prevent cross-RS token reuse.

> The other methods you mention require their own additional measures in the form of key exchanges/handshakes. And you still need to prove possession of that shared key somehow.

This is true. The difference being that the derived key can then be reused for many requests. Because the key derivation is cryptographically tied to this context the RS can’t replay these symmetric tokens anywhere else. 

> In some cases, “derive a shared key and encrypt this blob” is easier; in some cases “sign this blob declaring your audience” is easier.

The ECDH scheme does challenge-response to ensure freshness. This was designed to match the anti-replay measures in the DPoP draft but without requiring the server store any state. If you don’t need replay protection (if TLS is enough) then you can indeed just sign the audience, or for ECDH you can do completely static ECDH between the client’s private key and the RS’s public key to derive a shared key that is the same for all time (until key rotation). But in that case you may as well just return a symmetric key directly from the AS... attached to a macaroon, say. 

> > The easiest way to use macaroons with asymmetric crypto is to make the macaroon identifier be an encrypted random HMAC key that the RS can decrypt (or a derived key using diffie-hellman). You can concatenate multiple encrypted keys for multiple RSes. Alternatively in a closed ecosystem you can encrypt the random HMAC with a key stored in a KMS (such as AWS KMS) and grant each RS decrypt permissions for that KMS key.
> Is the “random HMAC key that the RS can decrypt” the root key used to generate the macaroon? If so, how would you prevent one targeted RS from using the root key and macaroon identifier to construct an arbitrary macaroon for replay against another targeted RS? If not, how does the targeted RS use the decrypted “random HMAC key” to validate the macaroon? Is there a paper on this approach?

That is the easiest way to let the RS verify the macaroon on the assumption that the RS is trusted. I’m not aware of an alternative for asymmetric crypto when the RS is untrusted other than using the signature-based macaroon variant or having per-RS keys. 

I’m not really a fan of purely signature-based JWT access tokens because those tokens often contain PII and so should really be encrypted to avoid leaking details to the client (or anyone else if the token does leak). This came up in the discussion of the JWT-based access tokens draft, which is why I proposed for use in that draft. But if you’re doing encryption then you’re already down the path of having per-RS access tokens (and keys) - the compact encoding of JWE only allows a single recipient. 

> The KMS approach is just symmetric crypto mediated through a third party (and has the same centralization problem as validation at the AS).
> > Clients can then later start adding caveats…, while RSes still don't have to make any changes….
> > DPoP only effectively prevents cross-RS replay if all RSes implement it, otherwise the ones that don't are still vulnerable.
> This is because macaroons bake the proof into the “bearer” token (which is no longer really a bearer token) in the Authorization header, whereas DPoP puts it in a separate header.

That’s not the only difference. The other is that the AS does the validation. If the client appended the DPoP claims to the access token and signed the whole thing, and then the RS took that and sent it to the AS introspection endpoint to validate it, then that would have the same advantage of not requiring any changes at the RS. 

But if you do this then there’s no longer any reason to use public key signatures because the client and AS may as well agree a shared secret. (The AS can always impersonate a client anyway). At which point we’re basically back using macaroons. 

> draft-ietf-oauth-signed-http-request is another way to do this that doesn’t rely on macaroons.
> > Your previous point was that they require "non-trivial work to use ... and require developers to learn a new token format".
> By “non-trivial work to use” I was referring to work required from the working group, that I did not feel was being acknowledged.

Do you believe it’s a disproportionate amount of work compared to any other draft the WG works on?

> Looking back over the thread, I think my objection stems from you referring to macaroons as an “access token format” when they’re really an applied cryptography pattern. The “format” part would need to be defined by the working group. For what it’s worth, I think it’d be interesting to explore if/how the pattern could be applied to the JWT format, or what tweaks would be necessary to make it work. If we could describe a way to create macaroons that reuse the existing work on JWTs, that would be pretty cool.

There are existing interoperable macaroon libraries right now that define a common format [*]. Unless there was a compelling reason not to, I’d hope we’d just standardize that. 

[*] Actually they’ve gone through a couple of iterations. I believe the “libmacaroons V2 binary” format is what most now use. 

> > That burden is significantly reduced when developers can just add a dependency and call a one-liner to add a caveat.
> Libraries can certainly reduce the amount of work required by developers (and here I mean client developers, RS developers, AS developers, and OAuth client and server library developers), but come with their own concerns (e.g., platform availability, licensing, maintenance and reliability, etc.). It becomes one more dependency that developers have to consider.

I’m not really sure what your point is here. *Any* new addition to OAuth has to be implemented. Either that’s done with a library or you write your own. 

— Neil