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

[David Waite <[e-mail]>]

On Nov 15, 2019, at 8:32 AM, Paul Querna <[e-mail]> wrote:
> Supporting `HS256` or similar signing of the proof would be one way to
> reduce the CPU usage concerns.

There are a number of other potential asymmetrically signed messages, such as the access token. Is the assumption that these are also symmetrically protected, or that the cost here is amortized by caching?

If you are changing either your access tokens or dPoP proofs to use symmetric keys, you want to limit the number of parties who know that secret to the client, AS, and a single resource server. You’ll be audience-scoping either way, so it may make sense to use a symmetric algorithm for both. It starts to look like kerberos in HTTP and JSON when you squint.

> 
> The challenge seems to be getting the symmetric key to the RS in a
> distributed manner.

Yes, you need the same infrastructure for HMAC and AEAD in this case.

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

If you encrypt the key to the resource, then there is a risk that the key is retained while unprotected in memory. ECDH may be better here, although then we are making assumptions on the types of keys being used.

> - **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 you are negotiating a symmetric key with the RS for access tokens (again, why not at this point, just call it a JOSE Service Ticket) you can just use AEAD and not bother with wrapping/encrypting the client-negotiated key within the access token.

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

-DW