Re: [Wimse] Request Binding Proofs for Workload Identities

[Yaron Sheffer <[e-mail]>]

One more thing that makes this JWT look like a cert is that sometimes we would want a chain of trust. For example:

 
Service A calls Service B, both of them on the same K8s node. To do that, service A calls a local (on-node) token exchange service to obtain a JWT.
The token exchange service is local for performance (latency) reasons and to allow disconnected operation.
But since the token exchange service is local, we want to restrict its authority. Maybe by restricting the destination services that it’s allowed to include in its tokens. Or maybe by limiting the time duration of issued tokens. 
Both Service A and Service B need to validate that the token has been issued within these policy constraints. They can be provisioned with policy (which IMO is not great) or the policy can be specified by a second token, which is signed by a “root” token issuer.
 

Nobody is looking to recreate X.509 here, but we will have to solve some complex problems to enable a scalable solution.

 

Thanks,

                Yaron

 

 

From: Pieter Kasselman <[e-mail]>
Date: Monday, 4 December 2023 at 21:17
To: Joseph Salowey <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Wimse] Request Binding Proofs for Workload Identities

 

Hi Joe

 

I agree, once we include the public key as a claim in the JWT, it shares some characteristics with a cert. I don’t think we need to go down the path of trying to make an equivalent to a cert though, but we should think through the implications (e.g. should there be a constraint on how the key is used, or do we make that implicit, given that the keys are short lived, can we skip CRL equivalents like StatusList and so on). I would be a proponent for keeping things as light as possible (but no lighter ofcourse). With SPIFFE, at least, there is already mechanisms for distributing the X.509 SVIDs and JWT SVIDs, so perhaps those can be re-used. I would be in favour of separating the spec for the binding mechanism from any specs that reason over key management, as this may be addressed differently by different systems.

 

Agreed that we should allow for the cases where X.509 is deployed. I am less sure about more MTLS bindings as we have the X.509 SVIDs for that and the break and inspect proxy challenge is the reason we need the JWT solution. So perhaps in terms of scope, for this proposal, I would propose keeping it narrow to the JWT only solution (with allowance for attaching the X.509 cert through thumbprint or URL for those deployments that use it already). 

 

Cheers

 

Pieter

 

From: Joseph Salowey <[e-mail]> 
Sent: Monday, December 4, 2023 8:02 PM
To: Pieter Kasselman <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>; [e-mail]
Subject: Re: [Wimse] Request Binding Proofs for Workload Identities

 

 

 

On Mon, Dec 4, 2023 at 12:12 AM Pieter Kasselman <[e-mail]> wrote:

Thanks Joe

 

I would prefer to keep the proposal more generic to JWTs as well, and perhaps use JWT-SVID in SPIFFE environments as the worked example.

 

I originally thought we might just reference the keys, rather than including them in the JWT (JWT-SVID) to reduce size. But as you point out, there is a ton of key management problems that comes with that, including distributing the public keys for verification and keeping them up to date, which will introduce both latency and resiliency problems.

 

 

[Joe] So essentially the JWT is a certificate in a sense that it binds the public key to some information.  There still needs to be some management to keep the jwt and its private key up to date.  I

 

I think going down the path of including the key in the JWT would ensure it is always available, even if a key was rotated previously. I think we can allow for re-using the X.509 SVIDs, or other X.509 certs – there are several options for referencing X.509 in JWTs already. The downside is increasing the JWT size (which has bandwidth and COGS implications at scale). We also end up dragging X.509 cert validation into the mix, which will have to be handled at the application layer (this has proven challenging to developers from past experience). I think we can include it, but perhaps also have an option to include only the key.

 

[Joe] I think there will be folks who are using X509 deployments and it would be good to figure out how to integrate with those. Perhaps there are things we can leverage with mTLS.  Your suggestion of using x5u or x5t could help keep the jwt size more manageable.  

 

In other cases we'll need a "jwt-only" solution which will have to involve some key management of the jwt and its key-pair.  It's not clear to me how much of this exists already vs. needs to be defined as part of this work. 

 

 

Thoughts?

 

Cheers

 

Pieter

 

From: Joseph Salowey <[e-mail]> 
Sent: Sunday, December 3, 2023 11:06 PM
To: Pieter Kasselman <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>; [e-mail]
Subject: Re: [Wimse] Request Binding Proofs for Workload Identities

 

 

 

On Fri, Dec 1, 2023 at 7:54 AM Pieter Kasselman <pieter.kasselman=[e-mail]> wrote:

Hi Hannes 

 

I think we may want to distinguish between the different kinds of tokens that are being used and the different purposes they are being used for.

 

This proposal is not about making replay of OAuth Access Tokens, which carries authorization information, detectable. We have solutions for that (e.g. DPoP). 

 

The use cases I had in mind was more about those cases where tokens (in JWT format) is used for identification\authentication scenarios. The JWT-SVID is an example of this. Imagine a chain of workloads A->B->C. The idea is that if Workload A authenticates to B with their token, and B then uses A’s token to impersonate A to C, C can detect it (and preferably reject it, or at least take it into account when making the authorization decision, which may include other information from a transaction token, time of day, the risk management engine and so forth). The proposal is to create a proof (a JWS signature) that contains claims about the request. If workload B presents workload A’s JWT to workload C, it will be unable to produce a proof that binds it to the latest request.

 

Perhaps we should just be as specific as calling it “Request Binding Proofs for JWT SVIDs”, although I was hoping we could be a little more generic as there are bound to be other places where JWTs are being used for authentication in this way.

 

[Joe] I don't think we should tie this solely to JWT SVIDs, it can have broader applicability.  

 

In the description above I believe the proof is explicitly attached to a key (raw key or key in the form of an X.509 cert).  There is a trend for deployments to move to shorter lived keys; will this result in failures due to key rotation.  Should we include binding to a service identity as an alternative and require that the identity be attached to an authentication credential which requires strong proof of possession like an X509 SPIFFE Svid? 

 

 

 

Does that help?

 

Cheers

 

Pieter

 

From: Hannes Tschofenig <[e-mail]> 
Sent: Wednesday, November 29, 2023 3:37 PM
To: Pieter Kasselman <[e-mail]>; [e-mail]
Subject: Re: [Wimse] Request Binding Proofs for Workload Identities

 

Hi Pieter,

 

Am 28.11.2023 um 22:13 schrieb Pieter Kasselman:

Hi folks

 

The Constrained Credential Security use case that we identified in draft-gilman-wimse-use-cases-00 - Workload Identity Use Cases (ietf.org) has been coming up in a number of discussions. The absence of any good mitigations is considered a risk, and given the prevalence of token theft along with the attractiveness of a compromised workload identity, not an entirely unjustified one. 

 

I would like to suggest a different term for this use case, something like "capability restricted token" or "Tokens with reduced permissions". I think this describes it much better since you are talking about limiting the impact of token theft. The text in Section 4.10 of the OAuth Security BCP then come to  mind as possible solutions, such as sender-constrained access tokens or audience-restricted access tokens.

 

Before going into the details of your solution, I am wondering whether you are expecting

 

a) the "control plane" to provide a PoP-based service account token to the workload, or

b) that the authorization server provides the PoP token to the workload when the workload presents the service account token.

 

(Note that I am using the terms from <draft-hofmann-wimse-workload-identity-bcp> to refer to the two different entities issuing tokens.)

 

Ciao

Hannes

 

In SPIFFE, for example, it would be highly desirable to have a way to bind a JWT SVID to a transaction to enable workloads and cloud resources to detect if the JWT SVID is being replayed, and if it is, to take it into account when making an authorization decision (e.g. transaction with JWT SVIDs that are being replayed are rejected). Existing mechanism like DPoP that provide similar functionality to sender constrain Access Tokens does not quite work (for reasons that Evan Gilman outlined in the BoF session). 

 

Proposed WIMSE Deliverable

---------------------------------------

One proposal to address this is to introduce the concept of a Request Binding Proof. A Request Binding Proof cryptographically binds a JWT (e.g. JWT SVID) to a request in such a way that the JWT cannot be used with another request without being detected by the recipient of the JWT. When a workload makes a request to another workload or resource, it presents its JWT credential (e.g. a JWT SVID), along with a Request Binding Proof. The receiving workload will use the JWT as a way to authenticate the calling workload and then verify that the Request Binding Proof to ensure the JWT is used in the context of the current request. A specific application of this binding mechanism is to bind a SPIFFE Verifiable Identity Document JWT (SVID JWT) to a request. I would like to propose that the creation of a standard for a Request Binding Proof should be a WIMSE deliverable.

 

Strawman

--------------

Making a quick strawman sketch of what a transaction binding proof might look like, includes:

 
Include a reference to a public key or the public key itself  to JWT used by the workload (e.g. the JWT SVID does not include a public key today)
Define a request binding proof by profiling the JSON Web Signature (JWS) specification to contain specific claims that can be bound to the request.
 

Some additional ideas below:

 

Workload JWT claims (e.g. used as part of a JWT SVID extension)

--------------------------------------------------------------------------------------

To support request binding, JWTs MUST include a kid claim as defined in https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4 (open question, can this be the X5u or X5t parameter representing the X.509 SVID)?

 

Request Binding Proof

-----------------------------

The Request Binding Proof is a JWT [RFC7519] that is signed (using JSON Web Signature (JWS) [RFC7515]) with a private key chosen by the workload. The JOSE Header of a Request Binding Proof MUST contain at least the following parameters:
typ: A field with the value dpop+jwt, which explicitly types the DPoP proof JWT as recommended in Section 3.11 of [RFC8725].
alg: An identifier for a JWS asymmetric digital signature algorithm from [IANA.JOSE.ALGS]. It MUST NOT be none or an identifier for a symmetric algorithm (Message Authentication Code (MAC)).
kid: Claim indicating which key was used to secure the JWS. It must match the kid claim in the JWT SVID (open question, can this be the X5u or X5t parameter representing the X.509 SVID).
The JWS payload contains the following claims:
iat (Issued At): The timestamp at which the Transaction Binding proof was created (REQUIRED)
jti (JWT ID): A unique identifier for the JWT to mitigate replay attacks (REQUIRED).
tth: Hash of the Transaction Token (see transaction token draft: https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ ). The value MUST be the result of a base64url encoding (as defined in Section 2 of [RFC7515]) the SHA-256 [SHS] hash of the ASCII encoding of the associated access token's value. (OPTIONAL)
rqd: A claim, whose value is a JSON object the describes the request details bound to the workload identity. The contents of the rqd claim changes, depending on the typeof request. 
The JSON value of the rqd claim MAY include the following values, depending on the request type (these are meant to illustrative and may not be the most appropriate, correct or sufficient – a topic for discussion):
htm: The value of the HTTP method (Section 9.1 of [RFC9110]) of the request to which the JWT is attached. This value MUST be used if the request is an HTTP request.
htu: The HTTP target URI (Section 7.1 of [RFC9110]) of the request to which the JWT is attached, without query and fragment parts. This value MUST be used if the request is an HTTP request.
krt: The Kafka Request Type. This value MUST be used if this is a Kafka request.
ktn: The Kafka Topic name to which the request is being directed. This value MUST be used if this is a Kafka request.
ktp: The Kafka Partition within a topic. This value MUST be used if this is a Kafka request.
gsm: The gRPC service method. This value MUST be used if this is a gRPC request.
Other?
The proof is generated by using the private key corresponding to the kid claim in the JWT (e.g. JWT SVID) to sign over the JWT Request Binding Proof (more details to be added).

The Request Binding Proof is verified by using the public key corresponding to the kid claim in the JWT (e.g. JWT SVID) to verify the Transaction Binding Proof. In addition to the cryptographic verification, the verifier MUST verify that:
The kid claim in the JWT SVID equals the kid claim in the Transaction Bindng Proof
The iat claim is in the accepted boundaries (less than 5 minutes old).
The tth claim matches the hash of the Transaction Token hash, if one is used.
The rqd claim contents matches the actual request details (e.g. htm and htu parameters match).
Additional verification steps to be added
I would be happy to expand on the above and turn it into a ID draft if there is interest in pursuing this further in WIMSE or elsewhere.

Cheers

Pieter

 

 

 

 

 

-- 
Wimse mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/wimse