From 4a87e3f917cc7b77df2e5b9c0389d05082736139 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Mon, 23 Dec 2024 03:12:20 +0000 Subject: [PATCH] Script updating gh-pages from 165f190. [ci skip] --- draft-ietf-wimse-s2s-protocol.html | 33 +- draft-ietf-wimse-s2s-protocol.txt | 42 +- index.html | 10 +- ys-acks/draft-ietf-wimse-s2s-protocol.html | 2391 -------------------- ys-acks/draft-ietf-wimse-s2s-protocol.txt | 1133 ---------- ys-acks/index.html | 45 - 6 files changed, 44 insertions(+), 3610 deletions(-) delete mode 100644 ys-acks/draft-ietf-wimse-s2s-protocol.html delete mode 100644 ys-acks/draft-ietf-wimse-s2s-protocol.txt delete mode 100644 ys-acks/index.html diff --git a/draft-ietf-wimse-s2s-protocol.html b/draft-ietf-wimse-s2s-protocol.html index f81e07a..fbb45d2 100644 --- a/draft-ietf-wimse-s2s-protocol.html +++ b/draft-ietf-wimse-s2s-protocol.html @@ -22,21 +22,21 @@ Service B with mutual TLS authentication, while the next call from Service B to Service C would be authenticated at the application level. " name="description"> - + - - - - - - - - - - - - - - - - - -
Internet-DraftWIMSE S2S AuthNovember 2024
Campbell, et al.Expires 26 May 2025[Page]
-
-
-
-
Workgroup:
-
Workload Identity in Multi System Environments
-
Internet-Draft:
-
draft-ietf-wimse-s2s-protocol-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
B. Campbell
-
Ping Identity
-
-
-
J. Salowey
-
Venafi
-
-
-
A. Schwenkschuster
-
SPIRL
-
-
-
Y. Sheffer
-
Intuit
-
-
-
-
-

WIMSE Service to Service Authentication

-
-

Abstract

-

The WIMSE architecture defines authentication and authorization for software workloads -in a variety of runtime environments, from the most basic ones up to complex -multi-service, multi-cloud, multi-tenant deployments. This document defines the simplest, atomic unit of -this architecture: the protocol between two workloads that need to verify each other's identity -in order to communicate securely. The scope of this protocol is a single HTTP request-and-response -pair. To address the needs of different setups, we propose two protocols, -one at the application level and one that makes use of trusted TLS transport. -These two protocols are compatible, in the sense that a single call -chain can have some calls use one protocol and some use the other. Service A can call -Service B with mutual TLS authentication, while the next call from Service B to Service C -would be authenticated at the application level.

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- The latest revision of this draft can be found at https://ietf-wg-wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-s2s-protocol.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/.

-

- Discussion of this document takes place on the - Workload Identity in Multi System Environments Working Group mailing list (mailto:wimse@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/wimse/. - Subscribe at https://www.ietf.org/mailman/listinfo/wimse/.

-

Source for this draft and an issue tracker can be found at - https://github.com/ietf-wg-wimse/draft-ietf-wimse-s2s-protocol.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 26 May 2025.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

This document defines authentication and authorization in the context of interaction between two workloads. -This is the core component of the WIMSE architecture [I-D.ietf-wimse-arch]. -For simplicity, this document focuses on HTTP-based services, -and the service-to-service call consists of a single HTTP request and its response. -We define the credentials that both services should possess and how they are used to protect the HTTP exchange.

-

There are multiple deployment styles in use today, and they result in different security properties. -We propose to address them differently.

-
    -
  • -

    Many use cases have various middleboxes inserted between pairs of services, resulting in a transport layer -that is not end-to-end encrypted. We propose to address these use cases by protecting the HTTP messages at the application -level (Section 4).

    -
    • -
  • -

    The other commonly deployed architecture has a mutual-TLS connection between each pair of services. This setup -can be addressed by a simpler solution (Section 5).

    -
    • -
-

It is an explicit goal of this protocol that a service deployment can include both architectures across a multi-chain call. -In other words, Service A can call Service B with mutual TLS protection, -while the next call to Service C is protected at the application level.

-

For application-level protection we currently propose two alternative solutions, one inspired by DPoP [RFC9449] in Section 4.2 and -one which is a profile of HTTP Message Signatures [RFC9421] in Section 4.3. The design team believes that we need to pick -one of these two alternatives for standardization, once we have understood their pros and cons.

-
-
-

-1.1. Deployment Architecture and Message Flow -

-

Regardless of the transport between the workloads, we assume the following logical architecture:

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Workload - B - Workload - A - PEP - Identity - PDP - Server - (optional) - - -
-
-

The Identity Server provisions credentials to each of the workloads. At least Workload A (and possibly both) must be provisioned -with a credential before the call can proceed. Details of communication with the Identity Server are out of scope -of this document, however we do describe the credential received by the workload.

-

PEP is a Policy Enforcement Point, the component that allows the call to go through or blocks it. PDP is an optional -Policy Decision Point, which may be deployed in architectures where policy management is centralized. All details of -policy management and message authorization are out of scope of this document.

-

The high-level message flow is as follows:

-
    -
  • -

    Workload A obtains a credential from the Identity Server. This happens periodically, e.g. once every 24 hours.

    -
    • -
  • -

    Workload A makes an HTTP call into Workload B. This is a regular HTTP request, with the additional protection -mechanisms defined below.

    -
    • -
  • -

    Workload B now authenticates Workload A and decides whether to authorize the call. -In certain architectures, Workload B may need to consult with an external server to decide whether to accept the call.

    -
    • -
  • -

    Workload B returns a response to Workload A, which may be an error response or a regular one.

    -
    • -
-
-
-
-
-
-
-

-2. Conventions and Definitions -

-

This document uses "service" and "workload" interchangeably. Otherwise, all terms are as defined by [I-D.ietf-wimse-arch].

-

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", -"MAY", and "OPTIONAL" in this document are to be interpreted as -described in BCP 14 [RFC2119] [RFC8174] when, and only when, they -appear in all capitals, as shown here.

-
-
-
-
-

-3. Workload Identity -

-
-
-

-3.1. Trust Domain -

-

A trust domain is a logical grouping of systems that share a common set of security controls and policies. WIMSE certificates and tokens are issued under the authority of a trust domain. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. -A trust domain maps to one or more trust anchors for validating X.509 certificates and a mechanism to securely obtain a JWK Set [RFC7517] for validating WIMSE WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. This secure mechanism is out of scope for this document.

-

A single organization may define multiple trust domains for different purposes such as different departments or environments. Each trust domain must have a unique identifier. Workload identifiers are scoped within a trust domain. If two identifiers differ only by trust domain they still refer to two different entities.

-
-
-
-
-

-3.2. Workload Identifier -

-

This document defines a workload identifier as a URI [RFC3986]. This URI is used in the subject fields in the certificates and tokens defined later in this document. The URI MUST meet the criteria for the URI type of Subject Alternative Name defined in Section 4.2.1.6 of [RFC5280].

-
    -
  • -

    The name MUST NOT be a relative URI, and it MUST follow the URI syntax and - encoding rules specified in [RFC3986]. The name MUST include both a - scheme and a scheme-specific-part.

    -
    • -
-

In addition the URI MUST include an authority that identifies the trust domain within which the identifier is scoped. The trust domain SHOULD be a fully qualified domain name belonging to the organization defining the trust domain to help provide uniqueness for the trust domain identifier. The scheme and scheme specific part are not defined by this specification. An example of an identifier format that conforms to this definition is SPIFFE ID. -While the URI encoding rules allow host names to be specified as IP addresses, IP addresses MUST NOT be used to represent trust domains except in the case where they are needed for compatibility with existing naming schemes.

-
-
-
-
-
-
-

-4. Application Level Service To Service Authentication -

-

As noted in the Introduction, for many deployments communication between workloads cannot use -end-to-end TLS. For these deployment styles, this document proposes application-level protections.

-

The current version of the document includes two alternatives, both using the newly introduced -Workload Identity Token (Section 4.1). The first alternative (Section 4.2) is inspired by the OAuth DPoP specification. -The second (Section 4.3) is based on the HTTP Message Signatures RFC. We present both alternatives and expect -the working group to select one of them as this document progresses towards IETF consensus. -A comparison of the two alternatives is attempted in Section 4.4.

-
-
-

-4.1. The Workload Identity Token -

-

The Workload Identity Token (WIT) is a JWS [RFC7515] signed JWT [RFC7519] that represents the identity of a workload. -It is issued by the Identity Server and binds a public key to the workload identity. -A WIT MUST contain the following:

-
    -
  • -

    in the JOSE header:

    -
      -
    • -

      alg: An identifier for a JWS asymmetric digital signature algorithm - (registered algorithm identifiers are listed in the IANA JOSE Algorithms registry [IANA.JOSE.ALGS]). The value none MUST NOT be used.

      -
      • -
    • -

      typ: the WIT is explicitly typed, as recommended in Section 3.11 of [RFC8725], using the wimse-id+jwt media type.

      -
      • -
    -
    • -
  • -

    in the JWT claims:

    -
      -
    • -

      iss: The issuer of the token, which is the Identity Server, represented by a URI.

      -
      • -
    • -

      sub: The subject of the token, which is the identity of the workload, represented by a URI.

      -
      • -
    • -

      exp: The expiration time of the token (as defined in Section 4.1.4 of [RFC7519]). -WITs should be refreshed regularly, e.g. on the order of hours.

      -
      • -
    • -

      jti: A unique identifier for the token.

      -
      • -
    • -

      cnf: A confirmation claim containing the public key of the workload using 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 Section 4.2 or Section 4.3. As such, it MUST NOT be used as a bearer token and is not intended for use in the Authorization header.

      -
      • -
    -
    • -
-

An example WIT might look like this (all examples, of course, are non-normative and with line breaks and extra space for readability):

-
-
-
-
-eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikp1bmUgNSJ9.
-eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN0ZWQtY2VudHJhbC1hdXRob3Jpd
-HkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2
-lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmNjYTNDU0U0Y3diX18iLCJjbmYiOns
-iandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiX2FtUkMzWXJZYkho
-SDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV6ayJ9fX0.rOSUMR8I5WhM5C704l3iV
-dY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp6eL1M486XmRgl3uyjj6R_iuzNOA
-
-
-
Figure 1: -An example Workload Identity Token (WIT) -
-
-

The decoded JOSE header of the WIT from the example above is shown here:

-
-
-
-{
- "typ": "wimse-id+jwt",
- "alg": "ES256",
- "kid": "June 5"
-}
-
-
-
Figure 2: -Example WIT JOSE Header -
-

The decoded JWT claims of the WIT from the example above are shown here:

-
-
-
-{
- "iss": "wimse://example.com/trusted-central-authority",
- "exp": 1717612470,
- "sub": "wimse://example.com/specific-workload",
- "jti": "x-_1CTL2cca3CSE4cwb__",
- "cnf": {
-  "jwk": {
-   "kty": "OKP",
-   "crv": "Ed25519",
-   "x": "_amRC3YrYbHhH1RtYrL8cSmTDMhYtOUTG78cGTR5ezk"
-  }
- }
-}
-
-
-
Figure 3: -Example WIT Claims -
-

The claims indicate that the example WIT:

-
    -
  • -

    was issued by an Identity Server known as wimse://example.com/trusted-central-authority.

    -
    • -
  • -

    is valid until May 15, 2024 3:28:45 PM GMT-06:00 (represented as NumericDate Section 2 of [RFC7519] value 1717612470).

    -
    • -
  • -

    identifies the workload to which the token was issued as wimse://example.com/specific-workload.

    -
    • -
  • -

    has a unique identifier of x-_1CTL2cca3CSE4cwb__.

    -
    • -
  • -

    binds the public key represented by the jwk confirmation method to the workload wimse://example.com/specific-workload.

    -
    • -
-

For elucidative purposes only, the workload's key, including the private part, is shown below in JWK [RFC7517] format:

-
-
-
-
-{
- "kty":"OKP",
- "crv":"Ed25519",
- "x":"_amRC3YrYbHhH1RtYrL8cSmTDMhYtOUTG78cGTR5ezk",
- "d":"G4lGAYFtFq5rwyjlgSIRznIoCF7MtKDHByyUUZCqLiA"
-}
-
-
-
Figure 4: -Example Workload's Key -
-
-

The afore-exampled WIT is signed with the private key of the Identity Server. -The public key(s) of the Identity Server need to be known to all workloads in order to verify the signature of the WIT. -The Identity Server's public key from this example is shown below in JWK [RFC7517] format:

-
-
-
-{
- "kty":"EC",
- "kid":"June 5",
- "x":"kXqnA2Op7hgd4zRMbw0iFcc_hDxUxhojxOFVGjE2gks",
- "y":"n__VndPMR021-59UAs0b9qDTFT-EZtT6xSNs_xFskLo",
- "crv":"P-256"
-}
-
-
-
Figure 5: -Example Identity Server Key -
-
-
-

-4.1.1. The WIT HTTP Header -

-

A WIT is conveyed in an HTTP header field named Workload-Identity-Token.

-

For those who celebrate, ABNF [RFC5234] for the value of Workload-Identity-Token header field is provided in Figure 6:

-
-
-
-
-ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
-DIGIT = %x30-39 ; 0-9
-base64url = 1*(ALPHA / DIGIT / "-" / "_")
-WIT =  base64url "." base64url "." base64url
-
-
-
Figure 6: -Workload-Identity-Token Header Field ABNF -
-
-

The following shows the WIT from Figure 1 in an example of a Workload-Identity-Token header field:

-
-
-
-Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1
- NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN
- 0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXN
- lOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmN
- jYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU
- 1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV
- 6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp
- 6eL1M486XmRgl3uyjj6R_iuzNOA
-
-
-
Figure 7: -An example Workload Identity Token HTTP Header Field -
-

Note that per [RFC9110], header field names are case insensitive; -thus, Workload-Identity-Token, workload-identity-token, WORKLOAD-IDENTITY-TOKEN, -etc., are all valid and equivalent header field names. However, case is significant in the header field value.

-
-
-
-
-
-
-

-4.2. Option 1: DPoP-Inspired Authentication -

-

This option, inspired by the OAuth DPoP specification [RFC9449], uses a DPoP-like mechanism to authenticate -the calling workload in the context of the request. The WIMSE Identity Token (Section 4.1) is sent in the request as -described in Section 4.1.1. An additional JWT, the Workload Proof Token (WPT), is signed by the private key -corresponding to the public key in the WIT. The WPT is sent in the Workload-Proof-Token header field of the request. -A WPT contains the following:

-
    -
  • -

    in the JOSE header:

    -
      -
    • -

      alg: An identifier for an appropriate JWS asymmetric digital signature algorithm corresponding to - the confirmation key in the associated WIT.

      -
      • -
    • -

      typ: the WPT is explicitly typed, as recommended in Section 3.11 of [RFC8725], - using the application/wimse-proof+jwt media type.

      -
      • -
    -
    • -
  • -

    in the JWT claims:

    -
      -
    • -

      iss: The issuer of the token, which is the calling workload, represented by the same value as the sub claim - of the associated WIT.

      -
      • -
    • -

      aud: The audience of the token contains the HTTP target URI (Section 7.1 of [RFC9110]) of the request - to which the WPT is attached, without query or fragment parts.

      -
      • -
    • -

      exp: The expiration time of the WIT (as defined in Section 4.1.4 of [RFC7519]). WPT lifetimes MUST be short, - e.g., on the order of minutes or seconds.

      -
      • -
    • -

      jti: A unique identifier for the token.

      -
      • -
    • -

      wth: Hash of the Workload Identity Token, defined in Section 4.1. The value is the base64url encoding of the - SHA-256 hash of the ASCII encoding of the token's value.

      -
      • -
    • -

      ath: Hash of the OAuth access token, if present in the request, which might convey end-user identity and - authorization context of the request. The value, as per Section 4.1 of [RFC9449], - is the base64url encoding of the SHA-256 hash of the ASCII encoding of the access token's value.

      -
      • -
    • -

      tth: Hash of the Txn-Token [I-D.ietf-oauth-transaction-tokens], if present in the request, - which might convey end-user identity and authorization context of the request. The value MUST be the result of - a base64url encoding (as defined in Section 2 of [RFC7515]) of the SHA-256 hash of - the ASCII encoding of the associated token's value.

      -
      • -
    • -

      oth: Hash of any other token in the request that might convey end-user identity and authorization context of the - request, if such a token exists. - The value MUST be the result of a base64url encoding (as defined in Section 2 of [RFC7515]) of the - SHA-256 hash of the ASCII encoding of the associated token's value. - (Note: this is less than ideal but seems we need something like this for extensibility.)

      -
      • -
    -
    • -
-

An example WPT might look like the following:

-
-
-
-
-eyJhbGciOiJFZERTQSIsInR5cCI6IndpbXNlLXByb29mK2p3dCJ9.eyJhdGgiOiJDTDR3
-amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd3pDMGpJIiwiYXVkIjoiaHR0c
-HM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJleHAiOjE3Mjg2NTg2NzIsImlzcy
-I6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiI0YjQ
-yYzVmNjExZTJiMWNmYTFkMmM0MWIzYTJmYjc4MiIsInd0aCI6Ii1KaThUbE1ORmszcW16
-bXBBeEJPXzdXLVl1dGNIXzJfZnVGQUZGU1YxUmcifQ.jrUBsDjWMG_FpuhLo3lNC-IBei
-PQXZ4UOuttPdNj8fRmIG4ZDFF9B10y7uGbiNIhbRdpgG_KXEPLHXWnvzLmBA
-
-
-
Figure 8: -Example Workload Proof Token (WPT) -
-
-

The decoded JOSE header of the WPT from the example above is shown here:

-
-
-
-{
-  "alg": "EdDSA",
-  "typ": "wimse-proof+jwt"
-}
-
-
-
Figure 9: -Example WPT JOSE Header -
-

The decoded JWT claims of the WPT from the example above are shown here:

-
-
-
-{
-  "ath": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI",
-  "aud": "https://service.example.com/path",
-  "exp": 1728658672,
-  "iss": "wimse://example.com/specific-workload",
-  "jti": "4b42c5f611e2b1cfa1d2c41b3a2fb782",
-  "wth": "-Ji8TlMNFk3qmzmpAxBO_7W-YutcH_2_fuFAFFSV1Rg"
-}
-
-
-
Figure 10: -Example WPT Claims -
-

An example of an HTTP request with both the WIT and WPT from prior examples is shown below:

-
-
-
-POST /path HTTP/1.1
-Host: service.example.com
-Content-Type: application/json
-Authorization: Bearer 16_mAd0GiwaZokU26_0902100
-Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1
-  NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydX
-  N0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6Indpb
-  XNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RM
-  MmNjYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkV
-  kMjU1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1
-  RSNWV6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGd
-  pz2lHp6eL1M486XmRgl3uyjj6R_iuzNOA
-Workload-Proof-Token: eyJhbGciOiJFZERTQSIsInR5cCI6IndpbXNlLXByb29mK2p
-  3dCJ9.eyJhdGgiOiJDTDR3amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd
-  3pDMGpJIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJl
-  eHAiOjE3Mjg2NTg2NzIsImlzcyI6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWM
-  td29ya2xvYWQiLCJqdGkiOiI0YjQyYzVmNjExZTJiMWNmYTFkMmM0MWIzYTJmYjc4Mi
-  IsInd0aCI6Ii1KaThUbE1ORmszcW16bXBBeEJPXzdXLVl1dGNIXzJfZnVGQUZGU1YxU
-  mcifQ.jrUBsDjWMG_FpuhLo3lNC-IBeiPQXZ4UOuttPdNj8fRmIG4ZDFF9B10y7uGbi
-  NIhbRdpgG_KXEPLHXWnvzLmBA
-
-{"do stuff":"please"}
-
-
-
Figure 11: -Example HTTP Request with WIT and WPT -
-

To validate the WPT in the request, the recipient MUST ensure the following:

-
    -
  • -

    There is exactly one Workload-Proof-Token header field in the request.

    -
    • -
  • -

    The Workload-Proof-Token header field value is a single and well-formed JWT.

    -
    • -
  • -

    The WPT signature is valid using the public key from the confirmation claim of the WIT.

    -
    • -
  • -

    The typ JOSE header parameter of the WPT conveys a media type of wimse-proof+jwt.

    -
    • -
  • -

    The iss claim of the WPT matches the sub claim of the WIT. (Note: not sure iss in the WPT is useful or necessary.)

    -
    • -
  • -

    The aud claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request - in which the WPT was received, ignoring any query and fragment parts.

    -
    • -
  • -

    The exp claim is present and conveys a time that has not passed. WPTs with an expiration time unreasonably - far in the future SHOULD be rejected.

    -
    • -
  • -

    The wth claim is present and matches the hash of the token value conveyed in the Workload-Identity-Token header.

    -
    • -
  • -

    Optionally, check that the value of the jti claim has not been used before in the time window in which the - respective WPT would be considered valid.

    -
    • -
  • -

    If presented in conjunction with an OAuth access token, the value of the ath claim matches the hash of that token's value.

    -
    • -
  • -

    If presented in conjunction with a Txn-Token, the value of the tth claim matches the hash of that token's value.

    -
    • -
  • -

    If presented in conjunction with a token conveying end-user identity or authorization context, the value of - the oth claim matches the hash of that token's value.

    -
    • -
-
-
-
-
-

-4.3. Option 2: Authentication Based on HTTP Message Signatures -

-

This option uses the WIMSE Identity Token (Section 4.1) to sign the request and optionally, the response. -This section defines a profile of the Message Signatures specification [RFC9421].

-

The request is signed as per [RFC9421]. The following derived components MUST be signed:

-
    -
  • -

    @method

    -
    • -
  • -

    @request-target

    -
    • -
-

In addition, the following request headers MUST be signed when they exist:

- -

If the response is signed, the following components MUST be signed:

-
    -
  • -

    @status

    -
    • -
  • -

    @method;req

    -
    • -
  • -

    @request-target;req

    -
    • -
  • -

    Content-Type if it exists

    -
    • -
  • -

    Content-Digest if it exists

    -
    • -
  • -

    Workload-Identity-Token

    -
    • -
-

For both requests and responses, the following signature parameters MUST be included:

-
    -
  • -

    created

    -
    • -
  • -

    expires - expiration MUST be short, e.g. on the order of minutes. The WIMSE architecture will provide separate -mechanisms in support of long-lived compute processes.

    -
    • -
  • -

    nonce

    -
    • -
  • -

    tag - the value for implementations of this specification is wimse-service-to-service

    -
    • -
-

Since the signing key is sent along with the message, the keyid parameter SHOULD NOT be used.

-

It is RECOMMENDED to include only one signature with the HTTP message. -If multiple ones are included, then the signature label included in both the Signature-Input and Signature headers SHOULD -be wimse.

-

A sender MUST ensure that each nonce it generates is unique, at least among messages sent to the same recipient. -To detect message replays, -a recipient MAY reject a message (request or response) if a nonce is repeated.

-

To promote interoperability, the ecdsa-p256-sha256 signing algorithm MUST be implemented -by general purpose implementations of this document.

-

OPEN ISSUE: do we use the Accept-Signature field to signal that the response must be signed?

-

Following is a non-normative example of a signed request and a signed response, -where the caller is using the keys specified in Figure 4.

-
-
-
-=============== NOTE: '\' line wrapping per RFC 8792 ================
-
-GET /gimme-ice-cream?flavor=vanilla HTTP/1.1
-Host: example.com
-Signature: wimse=:K4dfGnguF5f1L4DKBSp5XeFXosLGj8Y9fiUX06rL/wdOF+x3zT\
-WmsvKWiY0B1oFZaOtm2FHru+YLjdkqa2WfCQ==:
-Signature-Input: wimse=("@method" "@request-target" "workload-identi\
-ty-token");created=1718291357;expires=1718291657;nonce="abcd1111";ta\
-g="wimse-service-to-service"
-Workload-Identity-Token: aGVhZGVyCg.VGhpcyBpcyBub3QgYSByZWFsIHRva2Vu\
-Lgo.c2lnbmF0dXJlCg
-
-
-
-
Figure 12: -Signed Request -
-

Assuming that the workload being called has the following keypair:

-
-
-
-{
- "kty":"OKP",
- "crv":"Ed25519",
- "x":"CfaY1XX-aHJpenRP8ATm3yGlbcKA_treqOfwKrilwyg",
- "d":"fycSKS-iHZ6TC1BNwN6cE0sOBP3-4KgR-eqxNpnyhws"
-}
-
-
-
Figure 13: -Callee Private Key -
-

A signed response would be:

-
-
-
-=============== NOTE: '\' line wrapping per RFC 8792 ================
-
-HTTP/1.1 404 Not Found
-Connection: close
-Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU\
-=:
-Content-Type: text/plain
-Signature: wimse=:NMrMn3xhI6m9PI8mKVfpnH5qFGcEfuFxiCmsB5PJhGjUHT/5J4\
-612EZwRw3V4kU4gGJmO+ER8RC4DM2HKVOYDQ==:
-Signature-Input: wimse=("@status" "workload-identity-token" "content\
--type" "content-digest" "@method";req "@request-target";req);created\
-=1718295368;expires=1718295670;nonce="abcd2222";tag="wimse-service-t\
-o-service"
-Workload-Identity-Token: aGVhZGVyCg.VGhpcyBhaW4ndCBvbmUsIHRvby4K.c2l\
-nbmF0dXJlCg
-
-No ice cream today.
-
-
-
-
Figure 14: -Signed Response -
-
-
-
-
-

-4.4. Comparing the DPoP Inspired Option with Message Signatures -

-

-This section is temporarily part of the draft, while we expect the working group -to select one of these options. -

-

The two workload protection options have different strengths and weaknesses regarding implementation -complexity, extensibility, and security. -Here is a summary of the main differences between -Section 4.2 and Section 4.3.

-
    -
  • -

    The DPoP-inspired solution is less HTTP-specific, making it easier to adapt for -other protocols beyond HTTP. This flexibility is particularly valuable for -asynchronous communication scenarios, such as event-driven systems.

    -
    • -
  • -

    Message Signatures, on the other hand, benefit from an existing HTTP-specific RFC with -some established implementations. This existing groundwork means that this option could -be simpler to deploy, to the extent such implementations are available and easily integrated.

    -
    • -
  • -

    Given that the WIT (Workload Identity Token) is a type of JWT, the -DPoP-inspired approach that also uses JWT is less complex and technology-intensive than Message -Signatures. In contrast, Message Signatures introduce an additional layer of -technology, potentially increasing the complexity of the overall system.

    -
    • -
  • -

    Message Signatures offer superior integrity protection, particularly by mitigating -message modification by middleboxes. See also Section 6.3.

    -
    • -
  • -

    A key advantage of Message Signatures is that they support response signing. -This opens up the possibility for future decisions about whether to make -response signing mandatory, allowing for flexibility in the specification -and/or in specific deployment scenarios.

    -
    • -
  • -

    In general, Message Signatures provide greater flexibility compared to -the DPoP-inspired approach. Future versions of this draft (and subsequent implementations) can decide -whether specific aspects of message signing, such as coverage of particular fields, -should be mandatory or optional. Covering more fields will constrain the proof -so it cannot be easily reused in another context, which is often a security improvement. The DPoP inspired approach could -be designed to include extensibility to sign other fields, but this would make it closer to -trying to reinvent Message Signatures.

    -
    • -
-
-
-
-
-
-
-

-5. Using Mutual TLS for Service To Service Authentication -

-

As noted in the introduction, for many deployments, transport-level protection -of application traffic using TLS is ideal.

-

In this solution, the WIMSE workload identity may be carried within an X.509 certificate. -The WIMSE workload identity MUST be encoded in a SubjectAltName extension of type URI. -There MUST be only one SubjectAltName extension of type URI in a WIMSE certificate. -If the workload will act as a TLS server for clients that do not understand WIMSE workload -identities it is RECOMMENDED that the WIMSE certificate contain a SubjectAltName of type -DNSName with the appropriate DNS names for the server. -The certificate may contain SubjectAltName extensions of other types.

-

WIMSE certificates may be used to authenticate both the server and client side of the connections. When validating a WIMSE certificate, the relying party MUST use the trust anchors configured for the trust domain in the WIMSE identity to validate the peer's certificate. Other PKIX [RFC5280] path validation rules apply. WIMSE clients and servers MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the other side of the connection.

-

Servers wishing to use the WIMSE certificate for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document.

-

WIMSE server certificates SHOULD have the id-kp-serverAuth extended key usage [RFC5280] field set and WIMSE client certificates SHOULD have the id-kp-clientAuth extended key usage field set. A certificate that is used for both client and server connections may have both fields set. This specification does not make any other requirements beyond [RFC5280] on the contents of WIMSE certificates or on the certification authorities that issue WIMSE certificates.

-
-
-

-5.1. Server Name Validation -

-

If the WIMSE client uses a hostname to connect to the server and the server certificate contain a DNS SAN the client MUST perform standard host name validation (Section 6.3 of [RFC9525]) unless it is configured with the information necessary to validate the peer's WIMSE identity. If the client did not perform standard host name validation then the WIMSE client SHOULD further use the WIMSE workload identifier to validate the server. The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of [RFC9525] but rather as a trust domain. The server identity is encoded in the path portion of the WIMSE workload identifier in a deployment specific way. Validating the WIMSE workload identity could be a simple match on the trust domain and path portions of the identifier or validation may be based on the specific details on how the identifier is constructed. The path portion of the WIMSE identifier MUST always be considered in the scope of the trust domain.

-
-
-
-
-

-5.2. Client Authorization Using the WIMSE Identity -

-

The server application retrieves the client certificate WIMSE URI subjectAltName from the TLS layer for use in authorization, accounting and auditing. For example, the full WIMSE URI may be matched against ACLs to authorize actions requested by the peer and the URI may be included in log messages to associate actions to the client workload for audit purposes. A deployment may specify other authorization policies based on the specific details of how the WIMSE identifier is constructed. The path portion of the WIMSE identifier MUST always be considered in the scope of the trust domain.

-
-
-
-
-
-
-

-6. Security Considerations -

-
-
-

-6.1. WIMSE Identity -

-

The WIMSE Identifier is scoped within an issuer and therefore any sub-components (path portion of Identifier) are only unique within a trust domain defined by the issuer. Using a WIMSE Identifier without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain. Additionally, the trust domain must be tied to an authorized issuer cryptographic trust anchor through some mechanism such as a JWKS or X.509 certificate chain. The association of an issuer, trust domain and a cryptographic trust anchor MUST be communicated securely out of band.

-

TODO: Should there be a DNS name to trust domain mapping defined or some other discovery mechanism?

-
-
-
-
-

-6.2. Workload Identity Token and Proof of Possession -

-

The Workload Identity Token (WIT) is bound to a secret cryptographic key and is always presented with a proof of possession as described in Section 4.1. The WIT is a general purpose token that can be presented in multiple contexts. The WIT and its PoP are only used in the application-level options, and both are not used in MTLS. The WIT MUST NOT be used as a bearer token. While this helps reduce the sensitivity of the token it is still possible that a token and its proof of possession may be captured and replayed within the PoP's lifetime. The following are some mitigations for the capture and reuse of the proof of possession (PoP):

-
    -
  • -

    Preventing Eavesdropping and Interception with TLS

    -
    • -
-

An attacker observing or intercepting the communication channel can view the token and its proof of possession and attempt to replay it to gain an advantage. In order to prevent this the -token and proof of possession MUST be sent over a secure, server authenticated TLS connection unless a secure channel is provided by some other mechanisms. Host name validation according -to Section 5 MUST be performed. The WIT itself is not usable without a proof of possession.

-
    -
  • -

    Limiting Proof of Possession Lifespan

    -
    • -
-

The proof of possession MUST be time limited. A PoP should only be valid over the time necessary for it to be successfully used for the purpose it is needed. This will typically be on the order of minutes. PoPs received outside their validity time MUST be rejected.

-
    -
  • -

    Limiting Proof of Possession Scope

    -
    • -
-

In order to reduce the risk of theft and replay the PoP should have a limited scope. For example, a PoP may be targeted for use with a specific workload and even a specific transaction to reduce the impact of a stolen PoP. In some cases a workload may wish to reuse a PoP for a period of time or have it accepted by multiple target workloads. A careful analysis is warranted to understand the impacts to the system if a PoP is disclosed allowing it to be presented by an attacker along with a captured WIT.

-
    -
  • -

    Binding to a Timestamp or Nonce

    -
    • -
-

A proof of possession should include information that can be used to uniquely identify it such as a unique timestamp or nonce. This can be used by the receiver to perform basic replay protection against tokens it has already seen. Depending upon the design of the system it may be difficult to synchronize the replay cache across all token validators. In this case, if the PoP is not sufficiently scoped it may be usable with another workload. -While a fresh nonce could be included in the PoP, a mechanism for distributing a fresh challenge nonce from the validator to provide single use properties of a PoP is outside the scope of this specification.

-
    -
  • -

    Binding to TLS Endpoint

    -
    • -
-

The POP MAY be bound to a transport layer sender such as the client identity of a TLS session or TLS channel binding parameters. The mechanisms for binding are outside the scope of this specification.

-
-
-
-
-

-6.3. Middle Boxes -

-

In some deployments the WIMSE token and proof of possession may pass through multiple systems. The communication between the systems is over TLS, but the token and PoP are available in the clear at each intermediary. While the intermediary cannot modify the token or the information within the PoP they can attempt to capture and replay the token or modify the data not protected by the PoP. Mitigations listed in the previous section can be used to provide some protection from middle boxes. Deployments should perform analysis on their situation to determine if it is appropriate to trust and allow traffic to pass through a middle box.

-
-
-
-
-

-6.4. Privacy Considerations -

-

WITs and the proofs of possession may contain private information such as user names or other identities. Care should be taken to prevent the disclosure of this information. The use of TLS helps protect the privacy of WITs and proofs of possession.

-

WITs and certificates with WIMSE identifiers are typically associated with a workload and not a specific user, however in some deployments the workload may be associated directly to a user. While these are exceptional cases a deployment should evaluate if the disclosure of WITs or certificates can be used to track a user.

-
-
-
-
-
-
-

-7. IANA Considerations -

-

TODO: maybe a URI Scheme registration of wimse in URI schemes per [RFC7595] but it's only being used in an example right now and might not even be appropriate. Or maybe use an ietf URI scheme a la URN Namespace for IETF Use somehow. Or maybe nothing. Or maybe something else.

-

TODO: tth, wth and maybe oth claim in JSON Web Token Claims Registry

-
-
-

-7.1. Media Type Registration -

-

TODO: application/wimse-id+jwt or appropriately bikeshedded media type name (despite my ongoing unease with using media types for typing JWTs) in Media Types.

-

TODO: application/wimse-proof+jwt ...

-
-
-
-
-

-7.2. Hypertext Transfer Protocol (HTTP) Field Name Registration -

-

TODO: Workload-Identity-Token from Section 4.1.1

-

TODO: Workload-Proof-Token from Section 4.2

-
-
-
-
-
-
-

-8. References -

-
-
-

-8.1. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC3986]
-
-Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
-
-
[RFC5234]
-
-Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
-
-
[RFC5280]
-
-Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
-
-
[RFC7515]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
-
-
[RFC7517]
-
-Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/rfc/rfc7517>.
-
-
[RFC7519]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
-
-
[RFC7800]
-
-Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/rfc/rfc7800>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC8725]
-
-Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, , <https://www.rfc-editor.org/rfc/rfc8725>.
-
-
[RFC9110]
-
-Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
-
-
[RFC9421]
-
-Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, , <https://www.rfc-editor.org/rfc/rfc9421>.
-
-
[RFC9525]
-
-Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, , <https://www.rfc-editor.org/rfc/rfc9525>.
-
-
-
-
-
-
-

-8.2. Informative References -

-
-
[I-D.ietf-oauth-transaction-tokens]
-
-Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-03>.
-
-
[I-D.ietf-wimse-arch]
-
-Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-02>.
-
-
[IANA.JOSE.ALGS]
-
-IANA, "JSON Web Signature and Encryption Algorithms", <https://www.iana.org/assignments/jose>.
-
-
[RFC7595]
-
-Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, , <https://www.rfc-editor.org/rfc/rfc7595>.
-
-
[RFC9449]
-
-Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/rfc/rfc9449>.
-
-
-
-
-
-
-
-
-

-Appendix A. Document History -

-

RFC Editor: please remove before publication.

-
-
-

-A.1. draft-ietf-wimse-s2s-protocol-01 -

-
    -
  • -

    Addressed multiple comments from Pieter.

    -
    • -
  • -

    Clarified WIMSE identity concepts, specifically "trust domain" -and "workload identifier".

    -
    • -
  • -

    Much more detail around mTLS, including some normative language.

    -
    • -
  • -

    WIT (the identity token) is now included in the WPT proof of possession.

    -
    • -
  • -

    Added a section comparing the DPoP-inspired app-level security option to -the Message Signature-based alternative.

    -
    • -
-
-
-
-
-

-A.2. draft-ietf-wimse-s2s-protocol-00 -

-
    -
  • -

    Initial WG draft, an exact copy of draft-sheffer-wimse-s2s-protocol-00

    -
    • -
  • -

    Added this document history section

    -
    • -
-
-
-
-
-
-
-

-Acknowledgments -

-

The authors would like to thank Pieter Kasselman for his detailed comments.

-

We thank Daniel Feldman for his contributions to earlier versions of this document.

-
-
-
-
-

-Authors' Addresses -

-
-
Brian Campbell
-
Ping Identity
- -
-
-
Joe Salowey
-
Venafi
- -
-
-
Arndt Schwenkschuster
-
SPIRL
- -
-
-
Yaron Sheffer
-
Intuit
- -
-
-
- - - diff --git a/ys-acks/draft-ietf-wimse-s2s-protocol.txt b/ys-acks/draft-ietf-wimse-s2s-protocol.txt deleted file mode 100644 index 5049c70..0000000 --- a/ys-acks/draft-ietf-wimse-s2s-protocol.txt +++ /dev/null @@ -1,1133 +0,0 @@ - - - - -Workload Identity in Multi System Environments B. Campbell -Internet-Draft Ping Identity -Intended status: Standards Track J. Salowey -Expires: 26 May 2025 Venafi - A. Schwenkschuster - SPIRL - Y. Sheffer - Intuit - 22 November 2024 - - - WIMSE Service to Service Authentication - draft-ietf-wimse-s2s-protocol-latest - -Abstract - - The WIMSE architecture defines authentication and authorization for - software workloads in a variety of runtime environments, from the - most basic ones up to complex multi-service, multi-cloud, multi- - tenant deployments. This document defines the simplest, atomic unit - of this architecture: the protocol between two workloads that need to - verify each other's identity in order to communicate securely. The - scope of this protocol is a single HTTP request-and-response pair. - To address the needs of different setups, we propose two protocols, - one at the application level and one that makes use of trusted TLS - transport. These two protocols are compatible, in the sense that a - single call chain can have some calls use one protocol and some use - the other. Service A can call Service B with mutual TLS - authentication, while the next call from Service B to Service C would - be authenticated at the application level. - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at https://ietf-wg- - wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-s2s- - protocol.html. Status information for this document may be found at - https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/. - - Discussion of this document takes place on the Workload Identity in - Multi System Environments Working Group mailing list - (mailto:wimse@ietf.org), which is archived at - https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at - https://www.ietf.org/mailman/listinfo/wimse/. - - Source for this draft and an issue tracker can be found at - https://github.com/ietf-wg-wimse/draft-ietf-wimse-s2s-protocol. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 26 May 2025. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (https://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Deployment Architecture and Message Flow - 2. Conventions and Definitions - 3. Workload Identity - 3.1. Trust Domain - 3.2. Workload Identifier - 4. Application Level Service To Service Authentication - 4.1. The Workload Identity Token - 4.1.1. The WIT HTTP Header - 4.2. Option 1: DPoP-Inspired Authentication - 4.3. Option 2: Authentication Based on HTTP Message Signatures - 4.4. Comparing the DPoP Inspired Option with Message Signatures - 5. Using Mutual TLS for Service To Service Authentication - 5.1. Server Name Validation - 5.2. Client Authorization Using the WIMSE Identity - 6. Security Considerations - 6.1. WIMSE Identity - 6.2. Workload Identity Token and Proof of Possession - 6.3. Middle Boxes - 6.4. Privacy Considerations - 7. IANA Considerations - 7.1. Media Type Registration - 7.2. Hypertext Transfer Protocol (HTTP) Field Name Registration - 8. References - 8.1. Normative References - 8.2. Informative References - Appendix A. Document History - A.1. draft-ietf-wimse-s2s-protocol-01 - A.2. draft-ietf-wimse-s2s-protocol-00 - Acknowledgments - Authors' Addresses - -1. Introduction - - This document defines authentication and authorization in the context - of interaction between two workloads. This is the core component of - the WIMSE architecture [I-D.ietf-wimse-arch]. For simplicity, this - document focuses on HTTP-based services, and the service-to-service - call consists of a single HTTP request and its response. We define - the credentials that both services should possess and how they are - used to protect the HTTP exchange. - - There are multiple deployment styles in use today, and they result in - different security properties. We propose to address them - differently. - - * Many use cases have various middleboxes inserted between pairs of - services, resulting in a transport layer that is not end-to-end - encrypted. We propose to address these use cases by protecting - the HTTP messages at the application level (Section 4). - - * The other commonly deployed architecture has a mutual-TLS - connection between each pair of services. This setup can be - addressed by a simpler solution (Section 5). - - It is an explicit goal of this protocol that a service deployment can - include both architectures across a multi-chain call. In other - words, Service A can call Service B with mutual TLS protection, while - the next call to Service C is protected at the application level. - - For application-level protection we currently propose two alternative - solutions, one inspired by DPoP [RFC9449] in Section 4.2 and one - which is a profile of HTTP Message Signatures [RFC9421] in - Section 4.3. The design team believes that we need to pick one of - these two alternatives for standardization, once we have understood - their pros and cons. - -1.1. Deployment Architecture and Message Flow - - Regardless of the transport between the workloads, we assume the - following logical architecture: - - +------------+ +------------+ - | | | | - | | | Workload B | - | Workload A |==============>| | - | | | +--------+ - | | | | PEP | - +------------+ +---+--------+ - ^ ^ ^ - | | | - | +----------------------+ | - | | | - v v v - +------------+ +------------+ - | | | | - | Identity | | PDP | - | Server | | (optional) | - | | | | - +------------+ +------------+ - - The Identity Server provisions credentials to each of the workloads. - At least Workload A (and possibly both) must be provisioned with a - credential before the call can proceed. Details of communication - with the Identity Server are out of scope of this document, however - we do describe the credential received by the workload. - - PEP is a Policy Enforcement Point, the component that allows the call - to go through or blocks it. PDP is an optional Policy Decision - Point, which may be deployed in architectures where policy management - is centralized. All details of policy management and message - authorization are out of scope of this document. - - The high-level message flow is as follows: - - * Workload A obtains a credential from the Identity Server. This - happens periodically, e.g. once every 24 hours. - - * Workload A makes an HTTP call into Workload B. This is a regular - HTTP request, with the additional protection mechanisms defined - below. - - * Workload B now authenticates Workload A and decides whether to - authorize the call. In certain architectures, Workload B may need - to consult with an external server to decide whether to accept the - call. - - * Workload B returns a response to Workload A, which may be an error - response or a regular one. - -2. Conventions and Definitions - - This document uses "service" and "workload" interchangeably. - Otherwise, all terms are as defined by [I-D.ietf-wimse-arch]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - -3. Workload Identity - -3.1. Trust Domain - - A trust domain is a logical grouping of systems that share a common - set of security controls and policies. WIMSE certificates and tokens - are issued under the authority of a trust domain. Trust domains - SHOULD be identified by a fully qualified domain name belonging to - the organization defining the trust domain. A trust domain maps to - one or more trust anchors for validating X.509 certificates and a - mechanism to securely obtain a JWK Set [RFC7517] for validating WIMSE - WIT tokens. This mapping MUST be obtained through a secure mechanism - that ensures the authenticity and integrity of the mapping is fresh - and not compromised. This secure mechanism is out of scope for this - document. - - A single organization may define multiple trust domains for different - purposes such as different departments or environments. Each trust - domain must have a unique identifier. Workload identifiers are - scoped within a trust domain. If two identifiers differ only by - trust domain they still refer to two different entities. - -3.2. Workload Identifier - - This document defines a workload identifier as a URI [RFC3986]. This - URI is used in the subject fields in the certificates and tokens - defined later in this document. The URI MUST meet the criteria for - the URI type of Subject Alternative Name defined in Section 4.2.1.6 - of [RFC5280]. - - The name MUST NOT be a relative URI, and it MUST follow the URI - syntax and encoding rules specified in [RFC3986]. The name MUST - include both a scheme and a scheme-specific-part. - - In addition the URI MUST include an authority that identifies the - trust domain within which the identifier is scoped. The trust domain - SHOULD be a fully qualified domain name belonging to the organization - defining the trust domain to help provide uniqueness for the trust - domain identifier. The scheme and scheme specific part are not - defined by this specification. An example of an identifier format - that conforms to this definition is SPIFFE ID - (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md). - While the URI encoding rules allow host names to be specified as IP - addresses, IP addresses MUST NOT be used to represent trust domains - except in the case where they are needed for compatibility with - existing naming schemes. - -4. Application Level Service To Service Authentication - - As noted in the Introduction, for many deployments communication - between workloads cannot use end-to-end TLS. For these deployment - styles, this document proposes application-level protections. - - The current version of the document includes two alternatives, both - using the newly introduced Workload Identity Token (Section 4.1). - The first alternative (Section 4.2) is inspired by the OAuth DPoP - specification. The second (Section 4.3) is based on the HTTP Message - Signatures RFC. We present both alternatives and expect the working - group to select one of them as this document progresses towards IETF - consensus. A comparison of the two alternatives is attempted in - Section 4.4. - -4.1. The Workload Identity Token - - The Workload Identity Token (WIT) is a JWS [RFC7515] signed JWT - [RFC7519] that represents the identity of a workload. It is issued - by the Identity Server and binds a public key to the workload - identity. A WIT MUST contain the following: - - * in the JOSE header: - - - alg: An identifier for a JWS asymmetric digital signature - algorithm (registered algorithm identifiers are listed in the - IANA JOSE Algorithms registry [IANA.JOSE.ALGS]). The value - none MUST NOT be used. - - - typ: the WIT is explicitly typed, as recommended in - Section 3.11 of [RFC8725], using the wimse-id+jwt media type. - - * in the JWT claims: - - - iss: The issuer of the token, which is the Identity Server, - represented by a URI. - - - sub: The subject of the token, which is the identity of the - workload, represented by a URI. - - - exp: The expiration time of the token (as defined in - Section 4.1.4 of [RFC7519]). WITs should be refreshed - regularly, e.g. on the order of hours. - - - jti: A unique identifier for the token. - - - cnf: A confirmation claim containing the public key of the - workload using 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 Section 4.2 or Section 4.3. As - such, it MUST NOT be used as a bearer token and is not intended - for use in the Authorization header. - - An example WIT might look like this (all examples, of course, are - non-normative and with line breaks and extra space for readability): - - eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikp1bmUgNSJ9. - eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN0ZWQtY2VudHJhbC1hdXRob3Jpd - HkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2 - lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmNjYTNDU0U0Y3diX18iLCJjbmYiOns - iandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiX2FtUkMzWXJZYkho - SDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV6ayJ9fX0.rOSUMR8I5WhM5C704l3iV - dY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp6eL1M486XmRgl3uyjj6R_iuzNOA - - Figure 1: An example Workload Identity Token (WIT) - - The decoded JOSE header of the WIT from the example above is shown - here: - - { - "typ": "wimse-id+jwt", - "alg": "ES256", - "kid": "June 5" - } - - Figure 2: Example WIT JOSE Header - - The decoded JWT claims of the WIT from the example above are shown - here: - - { - "iss": "wimse://example.com/trusted-central-authority", - "exp": 1717612470, - "sub": "wimse://example.com/specific-workload", - "jti": "x-_1CTL2cca3CSE4cwb__", - "cnf": { - "jwk": { - "kty": "OKP", - "crv": "Ed25519", - "x": "_amRC3YrYbHhH1RtYrL8cSmTDMhYtOUTG78cGTR5ezk" - } - } - } - - Figure 3: Example WIT Claims - - The claims indicate that the example WIT: - - * was issued by an Identity Server known as wimse://example.com/ - trusted-central-authority. - - * is valid until May 15, 2024 3:28:45 PM GMT-06:00 (represented as - NumericDate Section 2 of [RFC7519] value 1717612470). - - * identifies the workload to which the token was issued as - wimse://example.com/specific-workload. - - * has a unique identifier of x-_1CTL2cca3CSE4cwb__. - - * binds the public key represented by the jwk confirmation method to - the workload wimse://example.com/specific-workload. - - For elucidative purposes only, the workload's key, including the - private part, is shown below in JWK [RFC7517] format: - - { - "kty":"OKP", - "crv":"Ed25519", - "x":"_amRC3YrYbHhH1RtYrL8cSmTDMhYtOUTG78cGTR5ezk", - "d":"G4lGAYFtFq5rwyjlgSIRznIoCF7MtKDHByyUUZCqLiA" - } - - Figure 4: Example Workload's Key - - The afore-exampled WIT is signed with the private key of the Identity - Server. The public key(s) of the Identity Server need to be known to - all workloads in order to verify the signature of the WIT. The - Identity Server's public key from this example is shown below in JWK - [RFC7517] format: - - { - "kty":"EC", - "kid":"June 5", - "x":"kXqnA2Op7hgd4zRMbw0iFcc_hDxUxhojxOFVGjE2gks", - "y":"n__VndPMR021-59UAs0b9qDTFT-EZtT6xSNs_xFskLo", - "crv":"P-256" - } - - Figure 5: Example Identity Server Key - -4.1.1. The WIT HTTP Header - - A WIT is conveyed in an HTTP header field named Workload-Identity- - Token. - - For those who celebrate, ABNF [RFC5234] for the value of Workload- - Identity-Token header field is provided in Figure 6: - - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - DIGIT = %x30-39 ; 0-9 - base64url = 1*(ALPHA / DIGIT / "-" / "_") - WIT = base64url "." base64url "." base64url - - Figure 6: Workload-Identity-Token Header Field ABNF - - The following shows the WIT from Figure 1 in an example of a - Workload-Identity-Token header field: - - Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1 - NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN - 0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXN - lOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmN - jYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU - 1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV - 6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp - 6eL1M486XmRgl3uyjj6R_iuzNOA - - Figure 7: An example Workload Identity Token HTTP Header Field - - Note that per [RFC9110], header field names are case insensitive; - thus, Workload-Identity-Token, workload-identity-token, WORKLOAD- - IDENTITY-TOKEN, etc., are all valid and equivalent header field - names. However, case is significant in the header field value. - -4.2. Option 1: DPoP-Inspired Authentication - - This option, inspired by the OAuth DPoP specification [RFC9449], uses - a DPoP-like mechanism to authenticate the calling workload in the - context of the request. The WIMSE Identity Token (Section 4.1) is - sent in the request as described in Section 4.1.1. An additional - JWT, the Workload Proof Token (WPT), is signed by the private key - corresponding to the public key in the WIT. The WPT is sent in the - Workload-Proof-Token header field of the request. A WPT contains the - following: - - * in the JOSE header: - - - alg: An identifier for an appropriate JWS asymmetric digital - signature algorithm corresponding to the confirmation key in - the associated WIT. - - - typ: the WPT is explicitly typed, as recommended in - Section 3.11 of [RFC8725], using the application/wimse- - proof+jwt media type. - - * in the JWT claims: - - - iss: The issuer of the token, which is the calling workload, - represented by the same value as the sub claim of the - associated WIT. - - - aud: The audience of the token contains the HTTP target URI - (Section 7.1 of [RFC9110]) of the request to which the WPT is - attached, without query or fragment parts. - - - exp: The expiration time of the WIT (as defined in - Section 4.1.4 of [RFC7519]). WPT lifetimes MUST be short, - e.g., on the order of minutes or seconds. - - - jti: A unique identifier for the token. - - - wth: Hash of the Workload Identity Token, defined in - Section 4.1. The value is the base64url encoding of the - SHA-256 hash of the ASCII encoding of the token's value. - - - ath: Hash of the OAuth access token, if present in the request, - which might convey end-user identity and authorization context - of the request. The value, as per Section 4.1 of [RFC9449], is - the base64url encoding of the SHA-256 hash of the ASCII - encoding of the access token's value. - - - tth: Hash of the Txn-Token [I-D.ietf-oauth-transaction-tokens], - if present in the request, which might convey end-user identity - and authorization context of the request. The value MUST be - the result of a base64url encoding (as defined in Section 2 of - [RFC7515]) of the SHA-256 hash of the ASCII encoding of the - associated token's value. - - - oth: Hash of any other token in the request that might convey - end-user identity and authorization context of the request, if - such a token exists. The value MUST be the result of a - base64url encoding (as defined in Section 2 of [RFC7515]) of - the SHA-256 hash of the ASCII encoding of the associated - token's value. (Note: this is less than ideal but seems we - need something like this for extensibility.) - - An example WPT might look like the following: - - eyJhbGciOiJFZERTQSIsInR5cCI6IndpbXNlLXByb29mK2p3dCJ9.eyJhdGgiOiJDTDR3 - amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd3pDMGpJIiwiYXVkIjoiaHR0c - HM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJleHAiOjE3Mjg2NTg2NzIsImlzcy - I6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiI0YjQ - yYzVmNjExZTJiMWNmYTFkMmM0MWIzYTJmYjc4MiIsInd0aCI6Ii1KaThUbE1ORmszcW16 - bXBBeEJPXzdXLVl1dGNIXzJfZnVGQUZGU1YxUmcifQ.jrUBsDjWMG_FpuhLo3lNC-IBei - PQXZ4UOuttPdNj8fRmIG4ZDFF9B10y7uGbiNIhbRdpgG_KXEPLHXWnvzLmBA - - Figure 8: Example Workload Proof Token (WPT) - - The decoded JOSE header of the WPT from the example above is shown - here: - - { - "alg": "EdDSA", - "typ": "wimse-proof+jwt" - } - - Figure 9: Example WPT JOSE Header - - The decoded JWT claims of the WPT from the example above are shown - here: - - { - "ath": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI", - "aud": "https://service.example.com/path", - "exp": 1728658672, - "iss": "wimse://example.com/specific-workload", - "jti": "4b42c5f611e2b1cfa1d2c41b3a2fb782", - "wth": "-Ji8TlMNFk3qmzmpAxBO_7W-YutcH_2_fuFAFFSV1Rg" - } - - Figure 10: Example WPT Claims - - An example of an HTTP request with both the WIT and WPT from prior - examples is shown below: - - POST /path HTTP/1.1 - Host: service.example.com - Content-Type: application/json - Authorization: Bearer 16_mAd0GiwaZokU26_0902100 - Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1 - NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydX - N0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6Indpb - XNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RM - MmNjYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkV - kMjU1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1 - RSNWV6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGd - pz2lHp6eL1M486XmRgl3uyjj6R_iuzNOA - Workload-Proof-Token: eyJhbGciOiJFZERTQSIsInR5cCI6IndpbXNlLXByb29mK2p - 3dCJ9.eyJhdGgiOiJDTDR3amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd - 3pDMGpJIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJl - eHAiOjE3Mjg2NTg2NzIsImlzcyI6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWM - td29ya2xvYWQiLCJqdGkiOiI0YjQyYzVmNjExZTJiMWNmYTFkMmM0MWIzYTJmYjc4Mi - IsInd0aCI6Ii1KaThUbE1ORmszcW16bXBBeEJPXzdXLVl1dGNIXzJfZnVGQUZGU1YxU - mcifQ.jrUBsDjWMG_FpuhLo3lNC-IBeiPQXZ4UOuttPdNj8fRmIG4ZDFF9B10y7uGbi - NIhbRdpgG_KXEPLHXWnvzLmBA - - {"do stuff":"please"} - - Figure 11: Example HTTP Request with WIT and WPT - - To validate the WPT in the request, the recipient MUST ensure the - following: - - * There is exactly one Workload-Proof-Token header field in the - request. - - * The Workload-Proof-Token header field value is a single and well- - formed JWT. - - * The WPT signature is valid using the public key from the - confirmation claim of the WIT. - - * The typ JOSE header parameter of the WPT conveys a media type of - wimse-proof+jwt. - - * The iss claim of the WPT matches the sub claim of the WIT. (Note: - not sure iss in the WPT is useful or necessary.) - - * The aud claim of the WPT matches the target URI, or an acceptable - alias or normalization thereof, of the HTTP request in which the - WPT was received, ignoring any query and fragment parts. - - * The exp claim is present and conveys a time that has not passed. - WPTs with an expiration time unreasonably far in the future SHOULD - be rejected. - - * The wth claim is present and matches the hash of the token value - conveyed in the Workload-Identity-Token header. - - * Optionally, check that the value of the jti claim has not been - used before in the time window in which the respective WPT would - be considered valid. - - * If presented in conjunction with an OAuth access token, the value - of the ath claim matches the hash of that token's value. - - * If presented in conjunction with a Txn-Token, the value of the tth - claim matches the hash of that token's value. - - * If presented in conjunction with a token conveying end-user - identity or authorization context, the value of the oth claim - matches the hash of that token's value. - -4.3. Option 2: Authentication Based on HTTP Message Signatures - - This option uses the WIMSE Identity Token (Section 4.1) to sign the - request and optionally, the response. This section defines a profile - of the Message Signatures specification [RFC9421]. - - The request is signed as per [RFC9421]. The following derived - components MUST be signed: - - * @method - - * @request-target - - In addition, the following request headers MUST be signed when they - exist: - - * Content-Type - - * Content-Digest - - * Authorization - - * Txn-Token [I-D.ietf-oauth-transaction-tokens] - - * Workload-Identity-Token - - If the response is signed, the following components MUST be signed: - - * @status - - * @method;req - - * @request-target;req - - * Content-Type if it exists - - * Content-Digest if it exists - - * Workload-Identity-Token - - For both requests and responses, the following signature parameters - MUST be included: - - * created - - * expires - expiration MUST be short, e.g. on the order of minutes. - The WIMSE architecture will provide separate mechanisms in support - of long-lived compute processes. - - * nonce - - * tag - the value for implementations of this specification is - wimse-service-to-service - - Since the signing key is sent along with the message, the keyid - parameter SHOULD NOT be used. - - It is RECOMMENDED to include only one signature with the HTTP - message. If multiple ones are included, then the signature label - included in both the Signature-Input and Signature headers SHOULD be - wimse. - - A sender MUST ensure that each nonce it generates is unique, at least - among messages sent to the same recipient. To detect message - replays, a recipient MAY reject a message (request or response) if a - nonce is repeated. - - To promote interoperability, the ecdsa-p256-sha256 signing algorithm - MUST be implemented by general purpose implementations of this - document. - - - // OPEN ISSUE: do we use the Accept-Signature field to signal that - // the response must be signed? - - Following is a non-normative example of a signed request and a signed - response, where the caller is using the keys specified in Figure 4. - - =============== NOTE: '\' line wrapping per RFC 8792 ================ - - GET /gimme-ice-cream?flavor=vanilla HTTP/1.1 - Host: example.com - Signature: wimse=:K4dfGnguF5f1L4DKBSp5XeFXosLGj8Y9fiUX06rL/wdOF+x3zT\ - WmsvKWiY0B1oFZaOtm2FHru+YLjdkqa2WfCQ==: - Signature-Input: wimse=("@method" "@request-target" "workload-identi\ - ty-token");created=1718291357;expires=1718291657;nonce="abcd1111";ta\ - g="wimse-service-to-service" - Workload-Identity-Token: aGVhZGVyCg.VGhpcyBpcyBub3QgYSByZWFsIHRva2Vu\ - Lgo.c2lnbmF0dXJlCg - - Figure 12: Signed Request - - Assuming that the workload being called has the following keypair: - - { - "kty":"OKP", - "crv":"Ed25519", - "x":"CfaY1XX-aHJpenRP8ATm3yGlbcKA_treqOfwKrilwyg", - "d":"fycSKS-iHZ6TC1BNwN6cE0sOBP3-4KgR-eqxNpnyhws" - } - - Figure 13: Callee Private Key - - A signed response would be: - - =============== NOTE: '\' line wrapping per RFC 8792 ================ - - HTTP/1.1 404 Not Found - Connection: close - Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU\ - =: - Content-Type: text/plain - Signature: wimse=:NMrMn3xhI6m9PI8mKVfpnH5qFGcEfuFxiCmsB5PJhGjUHT/5J4\ - 612EZwRw3V4kU4gGJmO+ER8RC4DM2HKVOYDQ==: - Signature-Input: wimse=("@status" "workload-identity-token" "content\ - -type" "content-digest" "@method";req "@request-target";req);created\ - =1718295368;expires=1718295670;nonce="abcd2222";tag="wimse-service-t\ - o-service" - Workload-Identity-Token: aGVhZGVyCg.VGhpcyBhaW4ndCBvbmUsIHRvby4K.c2l\ - nbmF0dXJlCg - - No ice cream today. - - Figure 14: Signed Response - -4.4. Comparing the DPoP Inspired Option with Message Signatures - - - // This section is temporarily part of the draft, while we expect the - // working group to select one of these options. - - The two workload protection options have different strengths and - weaknesses regarding implementation complexity, extensibility, and - security. Here is a summary of the main differences between - Section 4.2 and Section 4.3. - - * The DPoP-inspired solution is less HTTP-specific, making it easier - to adapt for other protocols beyond HTTP. This flexibility is - particularly valuable for asynchronous communication scenarios, - such as event-driven systems. - - * Message Signatures, on the other hand, benefit from an existing - HTTP-specific RFC with some established implementations. This - existing groundwork means that this option could be simpler to - deploy, to the extent such implementations are available and - easily integrated. - - * Given that the WIT (Workload Identity Token) is a type of JWT, the - DPoP-inspired approach that also uses JWT is less complex and - technology-intensive than Message Signatures. In contrast, - Message Signatures introduce an additional layer of technology, - potentially increasing the complexity of the overall system. - - * Message Signatures offer superior integrity protection, - particularly by mitigating message modification by middleboxes. - See also Section 6.3. - - * A key advantage of Message Signatures is that they support - response signing. This opens up the possibility for future - decisions about whether to make response signing mandatory, - allowing for flexibility in the specification and/or in specific - deployment scenarios. - - * In general, Message Signatures provide greater flexibility - compared to the DPoP-inspired approach. Future versions of this - draft (and subsequent implementations) can decide whether specific - aspects of message signing, such as coverage of particular fields, - should be mandatory or optional. Covering more fields will - constrain the proof so it cannot be easily reused in another - context, which is often a security improvement. The DPoP inspired - approach could be designed to include extensibility to sign other - fields, but this would make it closer to trying to reinvent - Message Signatures. - -5. Using Mutual TLS for Service To Service Authentication - - As noted in the introduction, for many deployments, transport-level - protection of application traffic using TLS is ideal. - - In this solution, the WIMSE workload identity may be carried within - an X.509 certificate. The WIMSE workload identity MUST be encoded in - a SubjectAltName extension of type URI. There MUST be only one - SubjectAltName extension of type URI in a WIMSE certificate. If the - workload will act as a TLS server for clients that do not understand - WIMSE workload identities it is RECOMMENDED that the WIMSE - certificate contain a SubjectAltName of type DNSName with the - appropriate DNS names for the server. The certificate may contain - SubjectAltName extensions of other types. - - WIMSE certificates may be used to authenticate both the server and - client side of the connections. When validating a WIMSE certificate, - the relying party MUST use the trust anchors configured for the trust - domain in the WIMSE identity to validate the peer's certificate. - Other PKIX [RFC5280] path validation rules apply. WIMSE clients and - servers MUST validate that the trust domain portion of the WIMSE - certificate matches the expected trust domain for the other side of - the connection. - - Servers wishing to use the WIMSE certificate for authorizing the - client MUST require client certificate authentication in the TLS - handshake. Other methods of post handshake authentication are not - specified by this document. - - WIMSE server certificates SHOULD have the id-kp-serverAuth extended - key usage [RFC5280] field set and WIMSE client certificates SHOULD - have the id-kp-clientAuth extended key usage field set. A - certificate that is used for both client and server connections may - have both fields set. This specification does not make any other - requirements beyond [RFC5280] on the contents of WIMSE certificates - or on the certification authorities that issue WIMSE certificates. - -5.1. Server Name Validation - - If the WIMSE client uses a hostname to connect to the server and the - server certificate contain a DNS SAN the client MUST perform standard - host name validation (Section 6.3 of [RFC9525]) unless it is - configured with the information necessary to validate the peer's - WIMSE identity. If the client did not perform standard host name - validation then the WIMSE client SHOULD further use the WIMSE - workload identifier to validate the server. The host portion of the - WIMSE URI is NOT treated as a host name as specified in section 6.4 - of [RFC9525] but rather as a trust domain. The server identity is - encoded in the path portion of the WIMSE workload identifier in a - deployment specific way. Validating the WIMSE workload identity - could be a simple match on the trust domain and path portions of the - identifier or validation may be based on the specific details on how - the identifier is constructed. The path portion of the WIMSE - identifier MUST always be considered in the scope of the trust - domain. - -5.2. Client Authorization Using the WIMSE Identity - - The server application retrieves the client certificate WIMSE URI - subjectAltName from the TLS layer for use in authorization, - accounting and auditing. For example, the full WIMSE URI may be - matched against ACLs to authorize actions requested by the peer and - the URI may be included in log messages to associate actions to the - client workload for audit purposes. A deployment may specify other - authorization policies based on the specific details of how the WIMSE - identifier is constructed. The path portion of the WIMSE identifier - MUST always be considered in the scope of the trust domain. - -6. Security Considerations - -6.1. WIMSE Identity - - The WIMSE Identifier is scoped within an issuer and therefore any - sub-components (path portion of Identifier) are only unique within a - trust domain defined by the issuer. Using a WIMSE Identifier without - taking into account the trust domain could allow one domain to issue - tokens to spoof identities in another domain. Additionally, the - trust domain must be tied to an authorized issuer cryptographic trust - anchor through some mechanism such as a JWKS or X.509 certificate - chain. The association of an issuer, trust domain and a - cryptographic trust anchor MUST be communicated securely out of band. - - - // TODO: Should there be a DNS name to trust domain mapping defined - // or some other discovery mechanism? - -6.2. Workload Identity Token and Proof of Possession - - The Workload Identity Token (WIT) is bound to a secret cryptographic - key and is always presented with a proof of possession as described - in Section 4.1. The WIT is a general purpose token that can be - presented in multiple contexts. The WIT and its PoP are only used in - the application-level options, and both are not used in MTLS. The - WIT MUST NOT be used as a bearer token. While this helps reduce the - sensitivity of the token it is still possible that a token and its - proof of possession may be captured and replayed within the PoP's - lifetime. The following are some mitigations for the capture and - reuse of the proof of possession (PoP): - - * Preventing Eavesdropping and Interception with TLS - - An attacker observing or intercepting the communication channel can - view the token and its proof of possession and attempt to replay it - to gain an advantage. In order to prevent this the token and proof - of possession MUST be sent over a secure, server authenticated TLS - connection unless a secure channel is provided by some other - mechanisms. Host name validation according to Section 5 MUST be - performed. The WIT itself is not usable without a proof of - possession. - - * Limiting Proof of Possession Lifespan - - The proof of possession MUST be time limited. A PoP should only be - valid over the time necessary for it to be successfully used for the - purpose it is needed. This will typically be on the order of - minutes. PoPs received outside their validity time MUST be rejected. - - * Limiting Proof of Possession Scope - - In order to reduce the risk of theft and replay the PoP should have a - limited scope. For example, a PoP may be targeted for use with a - specific workload and even a specific transaction to reduce the - impact of a stolen PoP. In some cases a workload may wish to reuse a - PoP for a period of time or have it accepted by multiple target - workloads. A careful analysis is warranted to understand the impacts - to the system if a PoP is disclosed allowing it to be presented by an - attacker along with a captured WIT. - - * Binding to a Timestamp or Nonce - - A proof of possession should include information that can be used to - uniquely identify it such as a unique timestamp or nonce. This can - be used by the receiver to perform basic replay protection against - tokens it has already seen. Depending upon the design of the system - it may be difficult to synchronize the replay cache across all token - validators. In this case, if the PoP is not sufficiently scoped it - may be usable with another workload. While a fresh nonce could be - included in the PoP, a mechanism for distributing a fresh challenge - nonce from the validator to provide single use properties of a PoP is - outside the scope of this specification. - - * Binding to TLS Endpoint - - The POP MAY be bound to a transport layer sender such as the client - identity of a TLS session or TLS channel binding parameters. The - mechanisms for binding are outside the scope of this specification. - -6.3. Middle Boxes - - In some deployments the WIMSE token and proof of possession may pass - through multiple systems. The communication between the systems is - over TLS, but the token and PoP are available in the clear at each - intermediary. While the intermediary cannot modify the token or the - information within the PoP they can attempt to capture and replay the - token or modify the data not protected by the PoP. Mitigations - listed in the previous section can be used to provide some protection - from middle boxes. Deployments should perform analysis on their - situation to determine if it is appropriate to trust and allow - traffic to pass through a middle box. - -6.4. Privacy Considerations - - WITs and the proofs of possession may contain private information - such as user names or other identities. Care should be taken to - prevent the disclosure of this information. The use of TLS helps - protect the privacy of WITs and proofs of possession. - - WITs and certificates with WIMSE identifiers are typically associated - with a workload and not a specific user, however in some deployments - the workload may be associated directly to a user. While these are - exceptional cases a deployment should evaluate if the disclosure of - WITs or certificates can be used to track a user. - -7. IANA Considerations - - TODO: maybe a URI Scheme registration of wimse in URI schemes - (https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) per - [RFC7595] but it's only being used in an example right now and might - not even be appropriate. Or maybe use an ietf URI scheme a la URN - Namespace for IETF Use (https://www.iana.org/assignments/params/ - params.xhtml) somehow. Or maybe nothing. Or maybe something else. - - TODO: tth, wth and maybe oth claim in JSON Web Token Claims Registry - (https://www.iana.org/assignments/jwt/jwt.xhtml) - -7.1. Media Type Registration - - TODO: application/wimse-id+jwt or appropriately bikeshedded media - type name (despite my ongoing unease with using media types for - typing JWTs) in Media Types (https://www.iana.org/assignments/media- - types/media-types.xhtml). - - TODO: application/wimse-proof+jwt ... - -7.2. Hypertext Transfer Protocol (HTTP) Field Name Registration - - TODO: Workload-Identity-Token from Section 4.1.1 - - TODO: Workload-Proof-Token from Section 4.2 - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, DOI 10.17487/RFC3986, January 2005, - . - - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, - . - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . - - [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web - Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May - 2015, . - - [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, - DOI 10.17487/RFC7517, May 2015, - . - - [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, - . - - [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- - Possession Key Semantics for JSON Web Tokens (JWTs)", - RFC 7800, DOI 10.17487/RFC7800, April 2016, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best - Current Practices", BCP 225, RFC 8725, - DOI 10.17487/RFC8725, February 2020, - . - - [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, - Ed., "HTTP Semantics", STD 97, RFC 9110, - DOI 10.17487/RFC9110, June 2022, - . - - [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP - Message Signatures", RFC 9421, DOI 10.17487/RFC9421, - February 2024, . - - [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", - RFC 9525, DOI 10.17487/RFC9525, November 2023, - . - -8.2. Informative References - - [I-D.ietf-oauth-transaction-tokens] - Tulshibagwale, A., Fletcher, G., and P. Kasselman, - "Transaction Tokens", Work in Progress, Internet-Draft, - draft-ietf-oauth-transaction-tokens-03, 3 July 2024, - . - - [I-D.ietf-wimse-arch] - Salowey, J. A., Rosomakho, Y., and H. Tschofenig, - "Workload Identity in a Multi System Environment (WIMSE) - Architecture", Work in Progress, Internet-Draft, draft- - ietf-wimse-arch-02, 21 October 2024, - . - - [IANA.JOSE.ALGS] - IANA, "JSON Web Signature and Encryption Algorithms", - . - - [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines - and Registration Procedures for URI Schemes", BCP 35, - RFC 7595, DOI 10.17487/RFC7595, June 2015, - . - - [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., - Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of - Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, - September 2023, . - -Appendix A. Document History - - - // RFC Editor: please remove before publication. - -A.1. draft-ietf-wimse-s2s-protocol-01 - - * Addressed multiple comments from Pieter. - - * Clarified WIMSE identity concepts, specifically "trust domain" and - "workload identifier". - - * Much more detail around mTLS, including some normative language. - - * WIT (the identity token) is now included in the WPT proof of - possession. - - * Added a section comparing the DPoP-inspired app-level security - option to the Message Signature-based alternative. - -A.2. draft-ietf-wimse-s2s-protocol-00 - - * Initial WG draft, an exact copy of draft-sheffer-wimse-s2s- - protocol-00 - - * Added this document history section - -Acknowledgments - - The authors would like to thank Pieter Kasselman for his detailed - comments. - - We thank Daniel Feldman for his contributions to earlier versions of - this document. - -Authors' Addresses - - Brian Campbell - Ping Identity - Email: bcampbell@pingidentity.com - - - Joe Salowey - Venafi - Email: joe.salowey@gmail.com - - - Arndt Schwenkschuster - SPIRL - Email: arndts.ietf@gmail.com - - - Yaron Sheffer - Intuit - Email: yaronf.ietf@gmail.com diff --git a/ys-acks/index.html b/ys-acks/index.html deleted file mode 100644 index 5b6598f..0000000 --- a/ys-acks/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - ietf-wg-wimse/draft-ietf-wimse-s2s-protocol ys-acks preview - - - - -

Editor's drafts for ys-acks branch of ietf-wg-wimse/draft-ietf-wimse-s2s-protocol

- - - - - - -
WIMSE S2S Authplain textsame as main
- - -