Re: [Wimse] Request Binding Proofs for Workload Identities

[Hannes Tschofenig <[e-mail]>]

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