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

["Richard Backman, Annabelle" <[e-mail]>]

> That’s not the only difference. The other is that the AS does the validation.
That’s not an inherent difference between macaroons and JWT-based proofs. An RS that implements dpop-03 could fulfill the requirements of section 4.2 by sending the proof to the AS. The special knowledge the RS needs is only that the DPoP header exists and needs to be sent. And as we’ve both pointed out, JWT-based solutions don’t have to have that requirement.

> 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.
That’s not necessarily true. The token validation endpoint need not be at the AS, and there may be compelling reasons to separate validation from generation. For example:

  *   Scaling up for validation without increasing distribution of private keys.
  *   Performing token generation and validation in different trust zones (e.g., cloud vs. on-prem, across geopolitical boundaries).

> Do you believe it’s a disproportionate amount of work compared to any other draft the WG works on?
A lot of WG drafts use JWTs, and thus get a lot of this work “for free” because it was already done in RFCs 7515 through 7521. There is no comparable set of documents to reference for macaroons (though I am not intending to imply that we’d need to define 7 new RFCs just to use macaroons for DPoP). The common format used by existing macaroon libraries would probably be a reasonable starting point for that work, but history suggests that it’s unwise to underestimate the scope of such work.

> 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.
As I mentioned earlier in the thread, there is a good chance that developers (particularly RS/AS/OAuth library devs) will have already implemented support for JWTs, either by hand or via a library. So the use of a non-JWT format is new work that they would have to do. I agree that for developers that aren’t already supporting JWTs, it doesn’t make much difference one way or another.

–
Annabelle Richard Backman
AWS Identity


From: Neil Madden <[e-mail]>
Date: Wednesday, November 27, 2019 at 11:43 PM
To: "Richard Backman, Annabelle" <[e-mail]>
Cc: Brian Campbell <[e-mail]>, oauth <[e-mail]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On 27 Nov 2019, at 20:30, Richard Backman, Annabelle <[e-mail]> 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 https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 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