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

[Neil Madden <[e-mail]>]

A few comments below.

On 15 Nov 2019, at 15:32, Paul Querna <[e-mail]> wrote:
> 
> Echoing Neil's concerns, I posted this to the issue tracker:
> https://github.com/danielfett/draft-dpop/issues/56
> 
> 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