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

[Neil Madden <[e-mail]>]

On 27 Nov 2019, at 01:26, Richard Backman, Annabelle <[e-mail]> 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