Re: [Wimse] Request Binding Proofs for Workload Identities

[Pieter Kasselman <[e-mail]>]

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.

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)<https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/> 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:


  1.  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)
  2.  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:

  1.  typ: A field with the value dpop+jwt, which explicitly types the DPoP proof JWT as recommended in Section 3.11 of [RFC8725].
  2.  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)).
  3.  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:

  1.  iat (Issued At): The timestamp at which the Transaction Binding proof was created (REQUIRED)
  2.  jti (JWT ID): A unique identifier for the JWT to mitigate replay attacks (REQUIRED).
  3.  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)
  4.  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):

  1.  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.
  2.  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.
  3.  krt: The Kafka Request Type. This value MUST be used if this is a Kafka request.
  4.  ktn: The Kafka Topic name to which the request is being directed. This value MUST be used if this is a Kafka request.
  5.  ktp: The Kafka Partition within a topic. This value MUST be used if this is a Kafka request.
  6.  gsm: The gRPC service method. This value MUST be used if this is a gRPC request.
  7.  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:

  1.  The kid claim in the JWT SVID equals the kid claim in the Transaction Bindng Proof
  2.  The iat claim is in the accepted boundaries (less than 5 minutes old).
  3.  The tth claim matches the hash of the Transaction Token hash, if one is used.
  4.  The rqd claim contents matches the actual request details (e.g. htm and htu parameters match).
  5.  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