From 2cd31e8fe1f28b538feb13bad4f9ee40ee977368 Mon Sep 17 00:00:00 2001 From: kenmccracken-google <155002249+kenmccracken-google@users.noreply.github.com> Date: Thu, 7 Nov 2024 11:52:20 -0500 Subject: [PATCH 1/7] WIT with Authentication Based on the Transport-layer --- draft-ietf-wimse-s2s-protocol.md | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index 33f2ce3..d65ae5a 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -172,12 +172,15 @@ While the URI encoding rules allow host names to be specified as IP addresses, I 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. +For deployments using end-to-end TLS, application-level credentials may enrich the security context. -The current version of the document includes two alternatives, both using the newly introduced +The current version of the document includes three alternatives, all using the newly introduced Workload Identity Token ({{to-wit}}). The first alternative ({{dpop-esque-auth}}) is inspired by the OAuth DPoP specification. -The second ({{http-sig-auth}}) 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 {{app-level-comparison}}. +The second alternative ({{http-sig-auth}}) is based on the HTTP Message Signatures RFC. The third +alternative ({{transport-layer-pop}}) is based on the TLS 1.3 and Token Binding RFCs. +We present the alternatives and expect +the working group to select those that should progress towards IETF consensus. +A comparison of the first two alternatives is attempted in {{app-level-comparison}}. ## The Workload Identity Token {#to-wit} @@ -195,8 +198,9 @@ A WIT MUST contain the following: * `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 {{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. + * `cnf`: A confirmation claim containing either the public key of the workload OR a cryptographically strong hash of the X.509 certificate that was 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](https://datatracker.ietf.org/doc/html/rfc8705#section-3.1) of [[RFC7805](https://datatracker.ietf.org/doc/html/rfc8705)]. When this value is provided, Proof-of-possession is delegated to the Transport-layer using the method in {{transport-layer-pop}}. 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. An example WIT might look like this (all examples, of course, are non-normative and with line breaks and extra space for readability): @@ -507,6 +511,16 @@ A signed response would be: ~~~ {: title="Signed Response"} +## Option 3: Authentication Based on the Transport Layer {#transport-layer-pop} + +This option provides authentication of the WIT using Transport Layer credentials. The proof-of-possession for the Workload's Private Key is provided in the WIT via a cyrptographically strong hash that MUST match the Transport Layer mutual authentication credential. The cryptographically strong hash binds the WIT to a particular Transport Layer certificate credential, so that it cannot be replayed without proof of the corresponding Workload Private Key. + +To authenticate a WIT using the Transport Layer, Workload-to-Workload communication MUST be secured by Mutually-authenticated [Transport Layer Security 1.3](https://datatracker.ietf.org/doc/html/rfc8446#section-2) (TLS 1.3). Proof-of-possession MUST be conveyed via each Workload's `CertificateVerify` message. In this case, each network peer MUST validate 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. The Transport Layer MUST cache the SHA-256 hash of the validated Client Certificate in the TLS session, 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 used at the Transport layer. + +This ensures that the WIT can only be used by a client with access to the Workload's Private Key. + ## Comparing the DPoP Inspired Option with Message Signatures {#app-level-comparison} From 3322058b87477c0e82ed5e5b77781c0763ffb21e Mon Sep 17 00:00:00 2001 From: kenmccracken-google <155002249+kenmccracken-google@users.noreply.github.com> Date: Thu, 7 Nov 2024 12:05:09 -0500 Subject: [PATCH 2/7] Update draft-ietf-wimse-s2s-protocol.md --- draft-ietf-wimse-s2s-protocol.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index d65ae5a..0ac86c5 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -43,6 +43,10 @@ author: fullname: "Yaron Sheffer" organization: Intuit email: "yaronf.ietf@gmail.com" + - + fullname: "Ken McCracken" + organization: Google + email: "kenmccracken@google.com" normative: RFC5234: @@ -515,7 +519,7 @@ A signed response would be: This option provides authentication of the WIT using Transport Layer credentials. The proof-of-possession for the Workload's Private Key is provided in the WIT via a cyrptographically strong hash that MUST match the Transport Layer mutual authentication credential. The cryptographically strong hash binds the WIT to a particular Transport Layer certificate credential, so that it cannot be replayed without proof of the corresponding Workload Private Key. -To authenticate a WIT using the Transport Layer, Workload-to-Workload communication MUST be secured by Mutually-authenticated [Transport Layer Security 1.3](https://datatracker.ietf.org/doc/html/rfc8446#section-2) (TLS 1.3). Proof-of-possession MUST be conveyed via each Workload's `CertificateVerify` message. In this case, each network peer MUST validate 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. The Transport Layer MUST cache the SHA-256 hash of the validated Client Certificate in the TLS session, 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: +When an Application receives a Certificate-bound WIT, it MUST treat the WIT as a JWT bound to an X.509 certificate in the manner described in [Section 3.1](https://datatracker.ietf.org/doc/html/rfc8705#section-3.1) of [[RFC8705](https://datatracker.ietf.org/doc/html/rfc8705)]. To authenticate a Certificate-bound WIT using the Transport Layer, Workload-to-Workload communication MUST be secured by Mutually-authenticated [Transport Layer Security 1.3](https://datatracker.ietf.org/doc/html/rfc8446#section-2) (TLS 1.3). Proof-of-possession MUST be conveyed via each Workload's `CertificateVerify` message. In this case, each network peer MUST validate 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. The Transport Layer MUST cache the SHA-256 hash of the validated Client Certificate in the TLS session, 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 used at the Transport layer. From 642112897407470f42428c779b88d7d23b930690 Mon Sep 17 00:00:00 2001 From: kenmccracken-google <155002249+kenmccracken-google@users.noreply.github.com> Date: Thu, 7 Nov 2024 13:13:09 -0500 Subject: [PATCH 3/7] Update draft-ietf-wimse-s2s-protocol.md --- draft-ietf-wimse-s2s-protocol.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index 0ac86c5..a2df4e1 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -176,7 +176,8 @@ While the URI encoding rules allow host names to be specified as IP addresses, I 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. -For deployments using end-to-end TLS, application-level credentials may enrich the security context. +For deployments using end-to-end TLS, application-level credentials may be used to enrich the +application security context. The current version of the document includes three alternatives, all using the newly introduced Workload Identity Token ({{to-wit}}). The first alternative ({{dpop-esque-auth}}) is inspired by the OAuth DPoP specification. @@ -189,7 +190,7 @@ A comparison of the first two alternatives is attempted in {{app-level-compariso ## The Workload Identity Token {#to-wit} 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. +It is issued by the Identity Server and binds a public key or certificate to the workload identity. A WIT MUST contain the following: * in the JOSE header: @@ -202,9 +203,9 @@ A WIT MUST contain the following: * `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 either the public key of the workload OR a cryptographically strong hash of the X.509 certificate that was 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](https://datatracker.ietf.org/doc/html/rfc8705#section-3.1) of [[RFC7805](https://datatracker.ietf.org/doc/html/rfc8705)]. When this value is provided, Proof-of-possession is delegated to the Transport-layer using the method in {{transport-layer-pop}}. 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. + * `cnf`: A confirmation claim containing either the public key of the workload OR a the hash of the X.509 certificate of the workload. + * The `cnf` MAY contain 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 `cnf` MAY contain the `x5t#S256` member as defined in [Section 3.1](https://datatracker.ietf.org/doc/html/rfc8705#section-3.1) of [[RFC7805](https://datatracker.ietf.org/doc/html/rfc8705)]. When this value is provided, Proof-of-possession is delegated to the Transport layer using the method described in {{transport-layer-pop}}. The receiving Workload MUST verify that the `x5t#S256` claim matches the SHA-256 hash of the Client's X.509 Certificate presented at the Transport layer. An example WIT might look like this (all examples, of course, are non-normative and with line breaks and extra space for readability): @@ -517,7 +518,7 @@ A signed response would be: ## Option 3: Authentication Based on the Transport Layer {#transport-layer-pop} -This option provides authentication of the WIT using Transport Layer credentials. The proof-of-possession for the Workload's Private Key is provided in the WIT via a cyrptographically strong hash that MUST match the Transport Layer mutual authentication credential. The cryptographically strong hash binds the WIT to a particular Transport Layer certificate credential, so that it cannot be replayed without proof of the corresponding Workload Private Key. +This option provides authentication of the WIT using Transport Layer credentials. The proof-of-possession for the Workload's Private Key is provided in the WIT via a cryptographically strong hash that MUST match the Transport Layer mutual authentication credential. The cryptographically strong hash binds the WIT to a particular Transport Layer certificate credential, so that it cannot be replayed without proof of the corresponding Workload Private Key. When an Application receives a Certificate-bound WIT, it MUST treat the WIT as a JWT bound to an X.509 certificate in the manner described in [Section 3.1](https://datatracker.ietf.org/doc/html/rfc8705#section-3.1) of [[RFC8705](https://datatracker.ietf.org/doc/html/rfc8705)]. To authenticate a Certificate-bound WIT using the Transport Layer, Workload-to-Workload communication MUST be secured by Mutually-authenticated [Transport Layer Security 1.3](https://datatracker.ietf.org/doc/html/rfc8446#section-2) (TLS 1.3). Proof-of-possession MUST be conveyed via each Workload's `CertificateVerify` message. In this case, each network peer MUST validate 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. The Transport Layer MUST cache the SHA-256 hash of the validated Client Certificate in the TLS session, 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: @@ -525,19 +526,19 @@ When an Application receives a Certificate-bound WIT, it MUST treat the WIT as a This ensures that the WIT can only be used by a client with access to the Workload's Private Key. -## Comparing the DPoP Inspired Option with Message Signatures {#app-level-comparison} +## Comparing the DPoP Inspired Option with Message Signatures and TLS Authentication {#app-level-comparison} This section is temporarily part of the draft, while we expect the working group -to select one of these options. +to select among these options. -The two workload protection options have different strengths and weaknesses regarding implementation +The three workload protection options have different strengths and weaknesses regarding implementation complexity, extensibility, and security. Here is a summary of the main differences between {{dpop-esque-auth}} and {{http-sig-auth}}. -- The DPoP-inspired solution is less HTTP-specific, making it easier to adapt for +- The DPoP-inspired and TLS authentcation options are less HTTP-specific, making them easier to adapt for other protocols beyond HTTP. This flexibility is particularly valuable for asynchronous communication scenarios, such as event-driven systems. @@ -550,19 +551,20 @@ DPoP-inspired approach that also uses JWT is less complex and technology-intensi 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 Signatures and TLS Authentication offer superior integrity protection, particularly by mitigating message modification by middleboxes. See also {{middleboxes}}. -- A key advantage of Message Signatures is that they support response signing. +- A key advantage of Message Signatures and TLS Authentication with AES-GCM 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 +- In general, Message Signatures and TLS Authentication provide greater flexibility compared to +the DPoP-inspired approach. For Message Signatures, 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 +so it cannot be easily reused in another context, which is often a security improvement. For TLS Authentication with AES-GCM, +all messages are integrity-protected. 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. From 817021b1654e16eb5055a72ced8c9b08f4db003f Mon Sep 17 00:00:00 2001 From: Ken McCracken Date: Mon, 25 Nov 2024 17:58:28 +0000 Subject: [PATCH 4/7] fix whitespace build errors. --- draft-ietf-wimse-s2s-protocol.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index a2df4e1..0824754 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -176,13 +176,13 @@ While the URI encoding rules allow host names to be specified as IP addresses, I 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. -For deployments using end-to-end TLS, application-level credentials may be used to enrich the +For deployments using end-to-end TLS, application-level credentials may be used to enrich the application security context. The current version of the document includes three alternatives, all using the newly introduced Workload Identity Token ({{to-wit}}). The first alternative ({{dpop-esque-auth}}) is inspired by the OAuth DPoP specification. The second alternative ({{http-sig-auth}}) is based on the HTTP Message Signatures RFC. The third -alternative ({{transport-layer-pop}}) is based on the TLS 1.3 and Token Binding RFCs. +alternative ({{transport-layer-pop}}) is based on the TLS 1.3 and Token Binding RFCs. We present the alternatives and expect the working group to select those that should progress towards IETF consensus. A comparison of the first two alternatives is attempted in {{app-level-comparison}}. From 22962e3f4d59e98a913ea69c1511cc5c80c38b5d Mon Sep 17 00:00:00 2001 From: Ken McCracken Date: Mon, 25 Nov 2024 19:04:46 +0000 Subject: [PATCH 5/7] Move Ken McCracken to Contributors. --- draft-ietf-wimse-s2s-protocol.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index 0824754..dede2f7 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -43,10 +43,6 @@ author: fullname: "Yaron Sheffer" organization: Intuit email: "yaronf.ietf@gmail.com" - - - fullname: "Ken McCracken" - organization: Google - email: "kenmccracken@google.com" normative: RFC5234: @@ -683,3 +679,7 @@ the Message Signature-based alternative. {:numbered="false"} TODO acknowledge. + +Contributors + +* Ken McCracken, Google, kenmccracken@google.com From 1ac40bf61c4b9d2991db78ba459b1b4ba4e50b90 Mon Sep 17 00:00:00 2001 From: Ken McCracken Date: Mon, 25 Nov 2024 20:43:37 +0000 Subject: [PATCH 6/7] formatting Contributors to a sub-heading --- draft-ietf-wimse-s2s-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index dede2f7..6ae239f 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -680,6 +680,6 @@ the Message Signature-based alternative. TODO acknowledge. -Contributors +## Contributors * Ken McCracken, Google, kenmccracken@google.com From 1ac0f0f64ef6505dc2e5073ce36efa0eb1be623e Mon Sep 17 00:00:00 2001 From: Ken McCracken Date: Mon, 25 Nov 2024 20:45:57 +0000 Subject: [PATCH 7/7] reverting formating as it breaks the build. --- draft-ietf-wimse-s2s-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index 6ae239f..dede2f7 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -680,6 +680,6 @@ the Message Signature-based alternative. TODO acknowledge. -## Contributors +Contributors * Ken McCracken, Google, kenmccracken@google.com