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

[Hannes Tschofenig <[e-mail]>]

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]> 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