Re: [OAUTH-WG] [EXT] Re: WGLC review of draft-ietf-oauth-security-topics-13

[Pedram Hosseyni]

Hi Mike,

> Wouldn't most RSs only trust access tokens from a single AS anyways?

At the last OSW, there was broad agreement that this is typically the 
case. Otherwise, the mitigation that we suggested in the paper would not 
prevent the attack.


> Would it be reasonable for the document to recommend that clients 
designate a specific AS for each RS that the client accesses (and not 
allow the user to select a different AS)? Would that help prevent the 
attack?


In principle, this should prevent the attack. However, this would 
require the client to identify the correct AS for each RS, which might 
not always be possible (e.g., in more dynamic settings) and more 
complicated than just delegating this decision to the RS.


Any opinions (also from other OAuth WG members) on this?

Best regards,
Pedram


On 26.11.19 21:08, Peck, Michael A wrote:

Hi Pedram,

I understand why a client would need to allow use of multiple authorization 
servers if the client needs to access various resource servers each of which 
may trust different ASs (e.g. the client supports accessing resources at 
multiple cloud storage services).

However, how common is the case that a client would need to allow selecting 
from multiple authorization servers for accessing a particular resource server?

Would it be reasonable for the document to recommend that clients designate a 
specific AS for each RS that the client accesses (and not allow the user to 
select a different AS)? Would that help prevent the attack? Wouldn't most RSs 
only trust access tokens from a single AS anyways?

Thanks,
Mike

On 11/26/19, 1:32 PM, "OAuth on behalf of Benjamin Kaduk"  wrote:

 Hi Pedram,
 
 Thanks for confirming that the scenario is as I was trying to understand

 it.  I don't think it's universal that all clients will give transitive
 access from the user to the accessed resource, though it's certainly
 common; the lack of exposition on that point is what I had been stumbling
 on.
 
 -Ben
 
 On Tue, Nov 26, 2019 at 06:33:04PM +0100, Pedram Hosseyni wrote:

 > Hi Ben,
 >
 > The attacker uses the (honest) client shown in Figure 4 as a regular
 > user. For example, the client might provide access to a cloud storage
 > via its website, i.e., by using the clients' website, a user can access
 > her files stored at the resource server.
 >
 > I'll try to clarify the attack with a simplified example.
 >
 > Let's assume that the client supports two authorization servers
 > AS_honest and AS_attacker. Intuitively, if the attacker phishes an
 > access token created by AS_honest for an honest user (Alice), one would
 > expect that sender-constraining the access token (e.g., via mTLS)
 > prevents the attacker from using this access token.
 >
 > The overall goal of the attacker is to use the sender-constrained access
 > token (which he cannot use directly at the resource server) to access
 > Alices cloud storage.
 >
 > The attack works as follows:
 >
 > First, the attacker visits the website of the client. Usually, the
 > attacker would now choose an AS, and after successful authentication,
 > access his files stored in the cloud. When selecting the AS, the
 > attacker chooses AS_attacker. In Step 5 of Figure 4, AS_attacker now
 > provides the phished access token. As this token is bound to this
 > client, the client can use it at the resource server for getting access
 > to the cloud storage of Alice. As the attacker is using the client
 > (through the clients' website), he now gets access to these files
 > (stored at the RS).
 >
 > Please let me know if you have any other questions.
 >
 > Best regards,
 > Pedram
 >
 >
 > On 26.11.19 16:51, Benjamin Kaduk wrote:
 > > Hi Pedram,
 > >
 > > On Thu, Nov 21, 2019 at 02:50:52PM +0100, Pedram Hosseyni wrote:
 > >> Also, for this or the next version of this document, the Cuckoo's 
Token
 > >> attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should
 > >> be addressed. We also discussed this issue extensively at the last OSW
 > >> in Stuttgart.
 > > I took a look at the paper, and I'm not sure I'm properly 
understanding the
 > > "Cuckoo's Token" attack.  Looking at Figure 4 of the paper to have
 > > something concrete to refer to, I assume that the client, as a white 
box,
 > > is presumed to be honest.  Since the access token is bound to the 
client, I
 > > assume that the attacker has to return the phished access token to the 
same
 > > client that originally (honestly) got it, as otherwise the token will 
not
 > > be usable at the RS.  The paper concludes that in step 6, the client 
gets
 > > access to the honest resource owner's resources, and furthermore that 
the
 > > attacker has access to those resources through the client.  It's that 
last
 

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

[Brian Campbell]

On Wed, Nov 27, 2019 at 3:31 AM Neil Madden 
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. 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),
> which is why most modern crypto protocols either use Diffie-Hellman for
> authN (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) so that the signature
> is tightly bound to a specific interactive protocol run.
>
>
Mostly for my own edification -  using Diffie-Hellman for authN (that a key
was held) was effectively at the heart of the "tentative suggestion for an
alternative design" that you had much early in this thread?

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

> On 27 Nov 2019, at 19:19, Brian Campbell  wrote:
> 
>> On Wed, Nov 27, 2019 at 3:31 AM Neil Madden  
>> 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. 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),
>>  which is why most modern crypto protocols either use Diffie-Hellman for 
>> authN (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) so 
>> that the signature is tightly bound to a specific interactive protocol run.
>> 
> 
> Mostly for my own edification -  using Diffie-Hellman for authN (that a key 
> was held) was effectively at the heart of the "tentative suggestion for an 
> alternative design" that you had much early in this thread?

Yes, exactly.

— Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

On Tue, Nov 26, 2019 at 6:26 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> > 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 ” would be wrong, but DPoP already commits
> that sin.
>

To clairy FWIW the current DPoP draft doesn't commit that sin. It uses
“Authorization: dpop ” and "DPoP: " headers.
There were some examples attempting to illustrate how all the pieces of the
proposal worked, including this particular part, in the slides I had for
Singapore. But unfortunately I never made it past slide #6.

On the other hand the OAuth MTLS draft does commit said sin. But it was
intentional with the aim of easing adoption/migration to it.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]


> On 27 Nov 2019, at 20:30, Richard Backman, Annabelle  
> 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 
> 

Re: [OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer

[Benjamin Kaduk]

On Thu, Nov 28, 2019 at 12:12:54AM +, Mike Jones wrote:
> Please also add these WGLC comments that a Microsoft Azure Active Directory 
> (AAD) developer asked me to convey:
> 
> 
>   1.  In 4.12, "Authorization servers MUST determine based on their risk 
> assessment whether to issue refresh tokens to a certain client [...]" I'm not 
> sure what this requirement requires in practice. AAD issues refresh_tokens to 
> all clients upon request and user consent and applies different lifetime 
> policies to different clients. We also routinely make risk assessments about 
> all manner of things. Does AAD thereby comply with this guideline? Reading 
> the whole paragraph, I think the paragraph is trying to encourage OAuth 
> clients which use a RT when the RT is returned but use auth codes when the RT 
> is not returned. That's fine, but the current text comes off as imposing a 
> vague requirement on authorization servers. Edits inline - "Authorization 
> servers MUST MAY dynamically determine based on their risk assessment whether 
> to issue refresh tokens to a certain client.  If the authorization server 
> decides not to issue refresh tokens, the client may SHOULD refresh access 
> tokens by utilizi
 ng other grant types, such as the authorization code grant type.  In such a 
case, the authorization server may utilize cookies and persistent grants to 
optimize the user experience."

FYI...

Using HTML bold/strikethrough doesn't work very well in the text/plain
portion, which is the only one displayed in the official archives:
https://mailarchive.ietf.org/arch/msg/oauth/Yzw0Mk4Ke3yyCH0Oo7MmatXA_tg

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer

[Mike Jones]

Please also add these WGLC comments that a Microsoft Azure Active Directory 
(AAD) developer asked me to convey:


  1.  In 4.12, "Authorization servers MUST determine based on their risk 
assessment whether to issue refresh tokens to a certain client [...]" I'm not 
sure what this requirement requires in practice. AAD issues refresh_tokens to 
all clients upon request and user consent and applies different lifetime 
policies to different clients. We also routinely make risk assessments about 
all manner of things. Does AAD thereby comply with this guideline? Reading the 
whole paragraph, I think the paragraph is trying to encourage OAuth clients 
which use a RT when the RT is returned but use auth codes when the RT is not 
returned. That's fine, but the current text comes off as imposing a vague 
requirement on authorization servers. Edits inline - "Authorization servers 
MUST MAY dynamically determine based on their risk assessment whether to issue 
refresh tokens to a certain client.  If the authorization server decides not to 
issue refresh tokens, the client may SHOULD refresh access tokens by utilizing 
other grant types, such as the authorization code grant type.  In such a case, 
the authorization server may utilize cookies and persistent grants to optimize 
the user experience."


  1.  In 4.12, the heading says "Authorization server MUST utilize one of these 
methods to detect refresh token replay for public clients" - however, it 
doesn't quite specify why refresh token replay is bad. The second paragraph 
described the goal more precisely ("If an attacker is able to exfiltrate and 
successfully replay [RTs]") - it's refresh token exfiltration that we MUST 
mitigate, not refresh token replay. Browser based apps that desire multiple 
access token should be able to use sender-constrained refresh tokens on 
multiple simultaneous HTTP requests - and some AAD apps do exactly this today. 
In practice, it's also difficult and undesirable to lock access to MSAL's RT 
cache - individual reads and writes are serialized, but { read, http request, 
write } events are not serialized. Here, just replace "to detect refresh token 
replay" with "to mitigate refresh token exfiltration" and then under "refresh 
token rotation," explain that such ASes using RT rotation to mitigate refresh 
token exfiltration MUST also forbid / prevent RT replay.


  1.  In 4.12, *Sender-constrained refresh tokens:* - sender-constrained tokens 
are absolutely valuable from a security perspective. However, without 
authenticating the sender, it's not necessarily an adequate protection for XSS. 
Some sender-constrained implementations (such as AAD's WIP spec for RTs) use 
un-attested keys and permit silent rebinding. Indeed, I think this will be 
common in browser based apps - attested keys have privacy implications leading 
to undesirable UX and rebinding prompts also lead to undesirable UX. An XSS 
attacker in those scenarios could likely silently rebind to an 
attacker-controlled key. It'd be good for the spec to acknowledge these aspects 
of sender-constrained tokens and make recommendations.
 *   It's these things that make us wary of moving from the implicit flow 
to RTs. The damage from exfiltrated RTs is much more severe, but the 
mitigations are less-specified by the BCPs, and thus seem less 
well-understood.. Frankly, I think each method of mitigation is worth of its 
own subsection with more discussion - 4.12.1, 4.12.2, etc.


  1.  In 4.12, *Refresh token rotation:* - in addition to Mike Jones' review 
comment. "The authorization server cannot determine which party submitted the 
invalid refresh token, but it can revoke the active refresh token" is the 
guidance given around revoking stolen RTs. I think this guidance should use an 
RFC2119 word in place of "can" - and that the guidance should be stronger, e.g. 
"SHOULD" or "MUST", w.r.t revoking the active refresh token. Rotating RTs 
doesn't do much any good as mitigation if the stolen RT remains valid.


  1.  In 4.12, we'd like to see fixed-expiry RTs of ~1 day added as "one of the 
methods to mitigate RT exfiltration for public clients" that ASes MUST utilize 
one of. This is what we're implementing; we think it's sound; and we'd like to 
see the draft say so, to remove all doubt.


   -- Mike


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

On 27 Nov 2019, at 01:26, Richard Backman, Annabelle  
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  
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 ” 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  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  be the public encryption key for the AS.
>  
> Client:
>  = JWE(, { at: , exp: … })
> 
> RS:
>  = JWE(, { at: , scope: scope_a })
>  = JWE(, { at: , scope: scope_b })
>  = JWE(, { at: , scope: scope_c })
>  = JWE(, { at: , 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…
>