Re: [Wimse] Attempts to apply pieces of OAuth DPoP to workload identity

[Pieter Kasselman <[e-mail]>]

Hi Hannes

The proposal I was looking at is more focused on the JWT being used for authentication. This is the case with the JWT-SVID from SPIFFE. Since it is a bearer token, and the workload presents it to another workload as part of a request, the second workload can take the JWT-SVID and impersonate the original caller by calling a third workload. By binding the request to the JWT SVID, the moment a request is made without the binding proof, or with a binding proof that is not bound to the request, it can be detected.

The scenario where Authorization Tokens are used (obtained from the Authorization server (AS)), is addressed by other mechanisms like DPoP and Transaction Tokens (DPoP to bind the Authorization Token to the sender, Transaction Tokens to swap the Authorization Token for a Transaction Token which cannot be replayed at the front door of the resource service).

Does that help?

Cheers

Pieter

From: Wimse <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: Thursday, November 30, 2023 9:15 AM
To: Evan Gilman <[e-mail]>
Cc: [e-mail]
Subject: Re: [Wimse] Attempts to apply pieces of OAuth DPoP to workload identity


Hi Evan,



thanks for your detailed response.


Am 29.11.2023 um 23:42 schrieb Evan Gilman:
On Wed, Nov 29, 2023 at 7:48 AM Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> wrote:
This scenario assumes that WL 1 has, somehow, obtained a token to
interact with the AS (possibly in the way described in
<draft-hofmann-wimse-workload-identity-bcp>).


Now, WL 1 can use the AS to request a token to access two other workloads.

Apologies in advance, as it's a little hard for me to reason about AS involvement here .. but I think the example works even without it, if we assume that WL 1 has received a platform-specific JWT by some opaque mechanism.

Are you concerned that

- WL 2 would steal the token?

- WL 3 steals the token?

Yes. I think "steal" the token is one vector (e.g. the service has been compromised), but there are others as pointed out in today's call (e.g. tokens getting logged, leaking via crash dump, etc).



I consider all these cases as "stealing". Of course, there are differences in how the tokens get into the wrong hands. I think it is nevertheless good to distinguish these cases.


The general concern is that anyone who obtains the token can impersonate WL 1. Currently, `aud` value and tight expiry is the best mitigation we have, but these fall short in a number of ways.

There is an implicit assumption in the communication model that the "edge workload", i.e. the workloads that obtain the request from outside the network (potentially from a user) are assumed to be more secure than "internal" workloads. Is this a correct assumption? (Here is a drawing for a graphical representation)


          +--------------+
 -------->|              |
          |   Edge       |
          | Workload     |
 <--------|              |
          +--------^-----+
               |   |
               |   |
          +----v---------+
          |              |
          |  Internal    |
          |  Workload    |
          |              |
          +--------^-----+
               |   |
               v   |

                ...

               |   ^
               |   |
          +----v---------+
          |              |
          |  Internal    |
          |  Workload    |
          |              |
          +--------------+





You made some comments on the call today about it being important to know for whom the token is for. I'm curious to hear your thoughts on the importance of the `aud` mechanism beyond replay mitigation.



I was trying to find out what type of threats are relevant in the scenarios being discussed. The threat that is addressed by an audience-restricted access token is that a stolen token cannot be presented elsewhere for illegitimate access to other resources.



- WL 1 uses a token with some other workload not listed in that chain?

From my perspective, we are talking about an identity token, and WL 1 should be able to present its identity to whomever it needs to. And WL 1 should be able to do that in a way that doesn't risk it being stolen by whomever happens to see it.

OK.



- the token is used by some eavesdropped sitting between the
communication paths of the WLs?

This is also a concern, I think it's practically indistinguishable from a compromised WL 2 in terms of security posture (if you get the token you win)? A very common pattern is TLS-terminating load balancers, which could be pictured as WL 2 or could be considered a person in the middle. In other words, it should not be the case that a compromised load balancer leads to total compromise because the attacker now has access to all the credentials and can attach them to (new) arbitrary requests... same for compromised WL 2. Hope that makes sense



OK.



Thanks for your quick feedback, Evan.



Ciao

Hannes