Re: [Wimse] Request Binding Proofs for Workload Identities

[Joseph Salowey <[e-mail]>]

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