Extend JWT-SVID spec and Workload API profile to support OAuth DPoP about spiffe HOT 7 OPEN

Finally, the opt-in nature of the workload API extension is likely to protect us from potential failure modes like the one described above, since only a workload that is DPoP-aware will know how to request that flavor of token

I'm not sure I follow this logic. The workload requesting the DPoP token is generally not the validator, and the danger is in a validator that skips DPoP validation and just accepts the token as a simple bearer.

The workload API currently has a validation RPC. Should we consider extending this RPC to receive and validate DPoP proofs? This unfortunately places the burden of tracking a significant amount of state on the SPIFFE control plane (jti values, nonces), and centralizes the computational cost of the crypto operations, but nominally allows us to tackle the problem of validators not supporting DPoP head on: when we see a DPoP-enabled token, we insist on seeing and validating the DPoP proof. This behavior could be relaxed via control plane configuration while workloads are upgraded.

from spiffe.

Importantly, DPoP defines a mechanism to bind a key and present a proof of that key to an arbitrary OAuth token, not just a JWT. In order to be fully useful in SPIFFE, there would need to be definitions of additional profiling as described above, such as a means for a workload associating which key(s) would be expected to be associated with which token. DPoP gives one signature-based presentation method, and there are others such as HTTP Message Signatures (which I proposed an OAuth extension for here: https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig that could also be adapted where applicable).

from spiffe.

Finally, the opt-in nature of the workload API extension is likely to protect us from potential failure modes like the one described above, since only a workload that is DPoP-aware will know how to request that flavor of token

I'm not sure I follow this logic. The workload requesting the DPoP token is generally not the validator, and the danger is in a validator that skips DPoP validation and just accepts the token as a simple bearer.

Sorry, I should have clarified this point. I still have more research to do on how various kinds of validators behave, however, if we assume that some validators will reject requests which have a JWT with DPoP-related key claim but no attached DPoP proof, then we'll want to make sure that the workload transmitting its JWT-SVID knows how to form the proof, and we can get reasonable assurance of that via opt-in mechanism

The workload API currently has a validation RPC. Should we consider extending this RPC to receive and validate DPoP proofs?

I considered this too ... ultimately thought I'd exclude it from the proposal for a couple reasons. First, as you mention, it will provide some consistency and structure around the formation and validation of the proofs, however that also comes with rigidity downside. These proofs are at application level, so I think while covering HTTP is great and will get us a long way, it won't cover enough cases to be generally acceptable. I suspect people will form their own slightly-modified proofs to support things like Kafka messages, etc. This comes with some danger too ... we should carefully consider how we can provide suggestions/constraints/guardrails for this kind of thing

Second, I think having the validation RPC on the JWT-SVID profile is a great idea, but unfortunately I've found it's not used often in practice. Overhead related to crossing the API boundary on the validation hot-path has not been popular. It also has kind of a weird shape security-wise, because folks are told to treat these tokens as secret and not give them to anyone, but here they are giving it to SPIRE (when they could also simply validate it in-process). Of course, this may not be a problem for most threat models, but people flag it as an anti-pattern and it becomes a point of friction during security code review etc.

from spiffe.

In order to be fully useful in SPIFFE, there would need to be definitions of additional profiling as described above, such as a means for a workload associating which key(s) would be expected to be associated with which token.

Mind unpacking this a bit for me? A brief example of what kind of profile you envision, perhaps? The key binding in DPoP between a JWT-based access token and the DPoP proof feels a little funny to me, I wonder if there's something I'm missing.

DPoP gives one signature-based presentation method, and there are others such as HTTP Message Signatures

Interesting .. is this to say that we should consider supporting more than one scheme?

from spiffe.

Hi @evan2645, I spent some time today to understand this proposal and the implementation steps of DPoP.

I have a little other idea about letting workload pass jkt in cnf in JWTSVIDRequest. Different from the audience, I think the public key that a client side has for issuing DPoP proof is fixed for each workload identity in most cases. It needs to be verified by specifying htm/htu when creating DPoP proof.

From the implementation of SPIRE, it allows administrator to register multiple identities to the same workload. Therefore, the need to use different public keys for different workload identities cannot be met by passing in jkt. Since SPIFFE/SPIRE provides a unified identity system, I think it may be a better choice to allow public keys to be hosted when registering workload identities, or SPIFFE/SPIRE directly generates a public-private key pair for issuing DPoP proof, and provide an interface similar to FetchJWTDPoPSVID to obtain DPoP proof.

The above is my thoughts on SPIFFE/SPIRE combined with DPoP, and it is nice to see exploration in this area.

Finally celebrating "Demonstrating Proof-of-possession at the Application Layer" officially becoming the Standards

from spiffe.

In order to be fully useful in SPIFFE, there would need to be definitions of additional profiling as described above, such as a means for a workload associating which key(s) would be expected to be associated with which token.

Mind unpacking this a bit for me? A brief example of what kind of profile you envision, perhaps? The key binding in DPoP between a JWT-based access token and the DPoP proof feels a little funny to me, I wonder if there's something I'm missing.

There are two parts to DPoP - how you ask for a token bound to a specific key, and how you prove that you have that key when you present the token. SPIFFE shouldn't really need the first part, since in a SPIFFE system the keys are managed as part of the identities of the workloads. The second part, presentation, is still useful though, because it gives you a way to present proof of a key (like a SPIFFE-provided key in our case) alongside an access token that's associated with that key. What SPIFFE would need to define is how to manage that first linking, since the OAuth process probably wouldn't apply -- you're not likely to be doing a fully token request from each entity and binding to a single key, for example. But you could present a token, even a JWT SVID, along with a DPoP proof to show that you have the key referenced in the SVID. But all of that last bit needs to be written down in a way that makes sense in the SPIFFE world, and importantly how to receive the keys needed to verify the presentation.

DPoP gives one signature-based presentation method, and there are others such as HTTP Message Signatures

Interesting .. is this to say that we should consider supporting more than one scheme?

If you're talking about adding DPoP in addition to MTLS, you're already talking about more than one scheme. Ultimately a workload receiving a token needs to answer the question "was this token presented by the party who was supposed to be presenting it?" And we've got several ways to do that in practice already, some of them RFCs and some of them not.

from spiffe.

I've been having some offline conversations and thinking this through for some weeks now and wanted to leave a quick update on the current thinking:

• DPoP includes the pubkey as a JWK on the DPoP Proof, rather than putting it inside the token
  • This is necessary for OAuth which doesn't define access token format, but cumbersome for SPIFFE which would somewhat strongly prefer to have the JWK in the JWT-SVID itself
  • Moving this piece over would make us non-DPoP compliant and we'd likely lose support from off the shelf DPoP libraries
• DPoP Proof spec is designed for HTTP, but we need to support more protocols than just HTTP
  • Similar observation here about breaking validation pathways and compat with off-the-shelf DPoP libraries
• The ideal solution is not DPoP, but maybe DPoP-like
  • JWK can be placed in the JWT-SVID, and a proof inspired by DPoP can be defined
  • I have some personal hesitancy on defining the proof inside the SPIFFE project - my preference would be to define it elsewhere and refer to its use in SPIFFE spec (the same way JWT-SVID doesn't define JWT)

In all, I think this will be a heavier lift than I was hoping for, since it doesn't appear that we'll be able to use DPoP as-is.

from spiffe.