On 27 Nov 2019, at 01:26, Richard Backman, Annabelle <richa...@amazon.com>
wrote:
>
>
> > That’s not proof of possession, that’s just verifying a MAC. PoP requires
> > the other party (client) to provide a fresh proof that they control a key.
> > The client isn’t using any key in this case.
>
> I think we’re operating with slightly different definitions for PoP. My
> definition is something along the lines of “a possessor of a key generated
> (or was in possession of) this data blob at some point.” You can probably see
> why we’re disagreeing over whether or not PoP is fundamental. I don’t think
> there is any point in continuing this semantic debate. 😃
See https://tools.ietf.org/html/rfc7800 <https://tools.ietf.org/html/rfc7800>
for a definition (section 3.6 in particular).
>
> > That’s not directly attached to the access token. This means that every RS
> > has to know about DPoP.
> True, but you could avoid that by embedding the access token in the DPoP
> proof (similar to draft-ietf-oauth-signed-http-request) and sending that as
> the sole token. Technically, that’s no longer a bearer token so sending it as
> “Authorization: bearer <token>” would be wrong, but DPoP already commits that
> sin.
>
> Also, if the AS is doing all authentication checks, then in a lot of cases
> the RS will need to provide the AS with additional request metadata along
> with the macaroon, such as the POST method used, origin (if it’s not
> inferable from whatever credentials the RS uses when calling the AS), request
> path, sender IP, client TLS certificate, token binding ID, etc. Obviously
> there are some caveats that don’t require this (e.g., timestamp). It remains
> to be seen whether the caveats required to meet DPoP’s use case fall into the
> former or latter category.
That’s true - and the RS being able to send more contextual info to the token
introspection endpoint would be useful regardless of token format.
The current model is that the AS validates the token and checks basic things
like the expiry time or audience and then returns any other constraints to the
RS such as the scope, any confirmation key, etc. This model can be followed
with macaroons - eg the scope returned should be the intersection of the
original token scope and any scope caveats on the token.
But for many of the things discussed in this thread, the AS can validate by
itself. For example, if the client appends an audience restricting a token to
one RS then the AS can validate that because the RS authenticates when it calls
the introspection endpoint. If the client appends something like a “jti” caveat
(probably renamed), then the AS can centrally record that to prevent replay -
this has the same caveats on scalability, but at least can be done once at the
AS rather than for each RS.
>
> > Please explain how to achieve the examples I gave of layered attenuation
> > without using macaroons.
> > 1. The client adds caveats (eg exp = now+5s) to an access token and sends
> > it to the RS. The RS creates four copies of the token with different scope
> > constraints and sends them to four individual microservices.
>
> For my example below:
> Let <at_0> be the access token obtained by the client from the AS
> Let JWE be a function that generates a JWE given a key and payload.
> Let <EKas> be the public encryption key for the AS.
>
> Client:
> <at_1> = JWE(<EKas>, { at: <at_0>, exp: … })
>
> RS:
> <at_2> = JWE(<EKas>, { at: <at_1>, scope: scope_a })
> <at_3> = JWE(<EKas>, { at: <at_1>, scope: scope_b })
> <at_4> = JWE(<EKas>, { at: <at_1>, scope: scope_c })
> <at_5> = JWE(<EKas>, { at: <at_1>, scope: scope_d })
>
Assuming you can only append caveats here, not new claims, then this is
functionally equivalent to macaroons. But only the AS can decrypt these layers,
so the RS is still forced to call the AS's token introspection endpoint to
validate this. So you've gained nothing over HMAC and added considerable CPU
and size overhead and a reduction in security.
This is also only secure if the encryption scheme is non-malleable, which (if
you want provable security) requires IND-CCA2. Not all JWE encryption schemes
provide this, e.g. RSA1_5 would not be secure for this. The ones that are
secure largely achieve that by the use of HMAC or another MAC in the
authenticated content encryption because they are hybrid encryption schemes -
effectively this is equivalent to using a macaroon where the identifier is an
encrypted HMAC key, which you can already do with macaroons.
> This pattern can be applied to the other scenarios you provided. The
> difference between macaroons and the above is that the former relies on
> chained HMACs and the latter on asymmetric crypto. You also lose the ability
> to inspect caveats or context that are already in the token, which may or may
> not be important. This is an interesting property of the macaroon pattern
> that I’m not sure you could replicate without basically implementing the
> macaroon pattern in a JWT format.
>
> > Validation at the AS is an advantage in most cases…
> Most, but not all. DPoP’s use of asymmetric signatures makes it more amenable
> to distributed validation in those scenarios where it is appropriate.
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. This downside of
signatures for authentication was pointed out by djb 18 years ago
(https://groups.google.com/forum/m/#!msg/sci.crypt/73yb5a9pz2Y/LNgRO7IYXOwJ
<https://groups.google.com/forum/m/#!msg/sci.crypt/73yb5a9pz2Y/LNgRO7IYXOwJ>),
which is why most modern crypto protocols either use Diffie-Hellman for authN
(https://noiseprotocol.org <https://noiseprotocol.org/>) or sign a hash of an
interactive handshake transcript (TLS 1.3 -
https://tools.ietf.org/html/rfc8446#section-4.4.3
<https://tools.ietf.org/html/rfc8446#section-4.4.3>) so that the signature is
tightly bound to a specific interactive protocol run.
> Your RS-specific token solution is only applicable to use cases where the
> RS-specific tokens are appropriate and viable. This is not a restriction that
> exists for DPoP as written. But you are correct, there are ways to use the
> macaroon pattern with asymmetric crypto. If that’s your proposal then I
> suggest specifying that, as most of the documentation I’ve seen (including
> the vast majority of the paper) focuses on the HMAC approach. While I can see
> how one could apply the pattern with asymmetric crypto, it wasn’t clear to me
> from that section of the paper that my thoughts match what they were
> describing.
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.
>
> > The AS can start issuing macaroons without either clients or RS being
> > aware….
> I’m not entirely sure what value you’re trying to get at here. I think you
> mean that the token handling/validation logic at the RS and AS isn’t
> significantly different for non-constrained macaroons versus constrained
> macaroons, whereas it is for DPoP? True, for DPoP the RS would need to know
> that it should send the DPoP proof to the AS, but RSes could be configured to
> always include it if present in the request. On the AS side, regardless of
> token format the AS will need logic to validate that the sender constraint is
> fulfilled. This may be very simple (e.g., just a timestamp check), or as
> relative complex as validating a DPoP token, depending on the needs of the
> use case and the caveats involved.
My point is that if say Google decided to start issuing macaroon-based access
tokens from their AS today, assuming that their RSes are doing token
introspection (I've no idea if they do or not), then it's likely nothing would
break. OAuth access tokens are opaque and their format unspecified, so only
software that is making additional assumptions about the format of access
tokens would be impacted. Clients can then later start adding caveats (by
choosing to make additional assumptions about the token format), while RSes
still don't have to make any changes. The RS would only need to make changes to
support things like htu/htm, but these are only applicable if you want to
provide defence against more advanced threat models such as TLS compromise.
DPoP only effectively prevents cross-RS replay if all RSes implement it,
otherwise the ones that don't are still vulnerable. When you have 1000+
microservices (e.g., https://twitter.com/JackKleeman/status/1190354757308862468
<https://twitter.com/JackKleeman/status/1190354757308862468>) then this is a
big deal.
>
> > (Re: asymmetric crypto) That’s not a requirement, it’s a technology choice.
> Fair enough, but technology choices are driven by requirements. Based on
> conversations I’ve had with John Bradley (and others I think?), this one in
> particular stems in part from the desire to keep the key locked up behind the
> browser’s crypto API, and not directly exposed to JavaScript. I’m somewhat
> skeptical of the value of this, since an attacker could just as easily call
> the crypto API directly, but if we see this as a requirement, then that would
> seem to require asymmetric crypto. However, as you noted that would not rule
> out the use of the macaroon pattern.
Right, I don't think this works for browsers. (I don't think anything will work
for browsers until they abandon the weak same-origin policy and replace it with
a more serious security model, such as https://github.com/Agoric/SES). I think
it is a genuine advantage of DPoP for mobile devices though, and I'd support a
draft that targeted that use case specifically.
>
> > There are plenty of existing interoperable macaroon libraries…
> “Use one of these existing libraries” is not appropriate as normative text in
> a specification. That format needs to be explicitly defined. Caveat types
> (e.g., expiry, source IP, client TLS certificate, etc.) need to be defined,
> probably with an IANA registry. Processing instructions need to be written
> (e.g., what happens when caveats conflict?). Security considerations around
> third-party caveats need to be written.
Sure, but that's work for me and the WG (if there's interest in standardizing
this). Your previous point was that they require "non-trivial work to use ...
and require developers to learn a new token format". That burden is
significantly reduced when developers can just add a dependency and call a
one-liner to add a caveat.
>
> > HMAC-SHA256 is very widely implemented (and usually securely). That’s all
> > you need.
> That’s what people said about SHA-1. Cryptographic agility is a feature, not
> a bug.
Actually I would bet a lot of money on HMAC-SHA256 not being broken any time
during our lifetimes. HMAC-SHA1 is still secure, as is HMAC-MD5, despite both
of those hash functions no longer being collision resistant. The reason is that
(a) preimage resistance often holds up much better than collision resistance
(e.g. the best preimage attacks against MD5 are still not practical), and (b)
the security proofs for HMAC require only fairly minimal security properties
from the underlying hash function.
HMAC-SHA256 operates at a 256-bit security level which provides a huge margin
of safety against advances in cryptanalysis. It's also safe against quantum
attacks, as the best known attack (Grover's algorithm) would at best reduce the
security level to around a 128-bit level (which is still better than RSA 2048).
>
> Again, I’m not saying we shouldn’t use macaroons, but I think you are
> underselling the amount of work required and overselling their value.
>
Compared to DPoP? I've deliberately confined myself to advantages that apply to
DPoP in this thread, but they have advantages for other use-cases too.
-- Neil_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
