WIT with Confirmation (Proof-of-possession) referencing Transport-layer security

[kenmccracken-google]

This spec should support an Option that builds on secure Workload Transport-layer authentication. Well-established protocols exist for Workload-to-Workload communication over mutually authenticated TLS 1.3.

I would like to propose an Option 3: Transport-layer Proof-of-possession, with a reference to the TLS credential used in the cnf claim of the WIT, based on https://datatracker.ietf.org/doc/html/rfc8705#section-3.1.

1. In the section The Workload Identity Token {#to-wit}, change the description of cnf to the following:

• cnf : A confirmation claim containing either the public key of the workload OR a cryptographically strong hash of the X.509 certificate conveyed during Transport layer security.
  • The public key cnf contains the jwk member as defined in {{Section 3.2 of RFC7800}}. The workload MUST prove possession of the corresponding private key when presenting the WIT to another party, which can be accomplished by using it in conjunction with one of the methods in {{dpop-esque-auth}} or {{http-sig-auth}}. As such, it MUST NOT be used as a bearer token and is not intended for use in the Authorization header.
  • The X.509 certificate hash cnf contains the x5t#S256 hash as described in Section 3.1 of [RFC8705]. When this value is provided, Proof-of-possession is delegated to the Transport-layer. The receiving Workload MUST verify that the x5t#S256 claim matches the hash of the Client's X.509 Certificate presented at the Transport-layer.

2. Add the following sub-section after Option 2: Authentication Based on HTTP Message Signatures {#http-sig-auth}:

Option 3: Transport-layer Proof-of-possession

In the case where Workload-to-Workload communication is secured by Mutually-authenticated Transport Layer Security 1.3, Proof-of-possession is conveyed via each Workload's CertificateVerify message. In this case, the Transport-layer guarantees that each Workload has already validated its Peer's Proof-of-possession of the Private Key. Proof-of-possession is conveyed during the TLS 1.3 handshake protocol using each peer's Certificate and CertificateVerify messages, along with other protocol messages transmitted. The Transport-layer must cache the SHA-256 hash of the validated Client Certificate and the first Subject Alternative Name (SAN) URI entry for use at the Application-layer. When the Destination Workload receives a WIT at the Application-layer with cnf claim with x5t#S256 property, it MUST establish Proof-of-possession as follows:

• Validate that the Certificate-bound WIT's cnf claim's x5t#S256 property matches the cached SHA-256 hash of the validated Client Certificate.
• Validate that the WIT's sub claim matches the first Subject Alternative Name (SAN) URI entry.

The first step proves that the WIT was issued to the holder of the PrivateKey for the X.509 Certificate presented by the client, and that Private Key was used to establish the mTLS session over which the WIT was transmitted. The second step validates that both the X.509 Certificate and the WIT were issued to the same Workload.

[jsalowey]

Do you see this as an alternate optimization which reuses the TLS handshake or is it in addition to the PoP. Why would I do this instead of just using TLS?

• TLS cert is not a "WIMSE" cert (not a WIMSE identifier URI SAN but some other format)
• WIT contains additional information (not sure about that)?

It seems that some of the properties would be different.

• Explicit binding to audience and other tokens/headers?
• WIT can be used with any TLS channel from the same endpoint?

Losing some of these properties is probably not be great. Perhaps we can use TLS exported authenticators to bind to the application exchange.

[kenmccracken-google]

Hi @jsalowey , thanks for your feedback and questions.

| Do you see this as an alternate optimization which reuses the TLS handshake or is it in addition to the PoP.

Yes, this is an optimization to reuse the TLS handshake's PoP.

| Why would I do this instead of just using TLS?

The WIT is an forwardable application tier credential. The proxy can forward it to backend services. The WIT may provide additional security context for the client's associated request, although they are not called out explicitly in this spec. (The spec does not explicitly say claims like aud are disallowed from WIT, and I think we should keep this option open).

| TLS cert is not a "WIMSE" cert

Could you clarify what you mean? I was thinking that in the case where a WIT contains a hash of the certificate in the "cnf", usually the TLS X.509 cert should be a "WIMSE" cert. The constraint to only allow a hash of a WIMSE cert in the WIT could be optionally enforced by the IdP at WIT issuance time.

| WIT contains additional information (not sure about that)?

I think this is optional but would suggest that possible extensions could be aud or scope.

| Explicit binding to audience and other tokens/headers?

Can we move these to the WIT?

| WIT can be used with any TLS channel from the same endpoint?

In the case where cnf contains an x5t#S256, the WIT can be used on any TLS channel that originated using the same certificate.

| Losing some of these properties is probably not be great. Perhaps we can use TLS exported authenticators to bind to the application exchange.

This could be an area of exploration. I haven't looked at using TLS exported authenticators for this use case.