Re: [Wimse] Request Binding Proofs for Workload Identities

[Joseph Salowey <[e-mail]>]

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)
> <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
>
>
>
>
>
>
>
>
>
>
>
> --
> Wimse mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wimse
>