> On 27 Nov 2019, at 20:30, Richard Backman, Annabelle <[email protected]>
> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
