From 3158b9823e7bba7ae971b9aa71b74c5096b6bf4d Mon Sep 17 00:00:00 2001 From: adeinega Date: Sun, 7 Jul 2024 00:54:02 -0700 Subject: [PATCH 1/5] Issue 15. --- ...t-saxe-wimse-token-exchange-and-translation-protocol.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index 5c800d2..ec877cf 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -126,6 +126,13 @@ TODO - this draft does not define normative specs for translating from arbitrary # Security Considerations +An AS performing token exchange SHOULD ensure it is the intended audience of a token being exchanged, and a client (whether it is an OAuth client or a workload) performing an exchange is allowed to perform such operation. +A value in the subject_token_type parameter MUST correspond to an actual token type provided in the subject_token parameter. +These are simple countermeasures against replay attacks and various forms of misuse, especially in cases when an AS who issued a token and an AS performing exchanges reside in different security domains. +Typically, self-contained tokens include the aud claim (an array of strings) representing their audience. +An extra care SHOULD be taken for tokens that can be passed through the front channel, and tokens that do not explicitly define their type. +Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs. + TODO Security - data loss in token translation may impact authZ decisions. Be careful when allowing multiple token translations since losses may grow over each step of translation. Embedding input tokens into output tokens can reduce this risk by allowing more complete context, at the risk of expanding the token size beyond what is practical. From 3ff4a571a8a0bc380440a5c99362767e9a0ca1a2 Mon Sep 17 00:00:00 2001 From: adeinega Date: Sun, 7 Jul 2024 00:58:42 -0700 Subject: [PATCH 2/5] Issue 15. --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index ec877cf..055cf64 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -129,7 +129,7 @@ TODO - this draft does not define normative specs for translating from arbitrary An AS performing token exchange SHOULD ensure it is the intended audience of a token being exchanged, and a client (whether it is an OAuth client or a workload) performing an exchange is allowed to perform such operation. A value in the subject_token_type parameter MUST correspond to an actual token type provided in the subject_token parameter. These are simple countermeasures against replay attacks and various forms of misuse, especially in cases when an AS who issued a token and an AS performing exchanges reside in different security domains. -Typically, self-contained tokens include the aud claim (an array of strings) representing their audience. +Typically, self-contained tokens include the aud claim (an array of strings) representing their audience (other types of tokens provide other means for the same). An extra care SHOULD be taken for tokens that can be passed through the front channel, and tokens that do not explicitly define their type. Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs. From c8085eb77d918368b403eb98bd09e9d4a51db464 Mon Sep 17 00:00:00 2001 From: adeinega Date: Sun, 7 Jul 2024 01:17:02 -0700 Subject: [PATCH 3/5] Mnr changes. --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index 055cf64..d48e90f 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -126,8 +126,9 @@ TODO - this draft does not define normative specs for translating from arbitrary # Security Considerations -An AS performing token exchange SHOULD ensure it is the intended audience of a token being exchanged, and a client (whether it is an OAuth client or a workload) performing an exchange is allowed to perform such operation. -A value in the subject_token_type parameter MUST correspond to an actual token type provided in the subject_token parameter. +An AS performing token exchange MUST ensure a client (whether it is an OAuth client or a workload) performing an exchange and a provied token is allowed to perform such operation on it. +An AS SHOULD ensure it is also the intended audience of a token being exchanged. +A value in the subject_token_type parameter MUST correspond to an actual token type provided in the subject_token parameter ({{RFC8693}}). These are simple countermeasures against replay attacks and various forms of misuse, especially in cases when an AS who issued a token and an AS performing exchanges reside in different security domains. Typically, self-contained tokens include the aud claim (an array of strings) representing their audience (other types of tokens provide other means for the same). An extra care SHOULD be taken for tokens that can be passed through the front channel, and tokens that do not explicitly define their type. From ca62df041a88b6a3a14eb8c7d5bec99783b53d40 Mon Sep 17 00:00:00 2001 From: adeinega Date: Sun, 7 Jul 2024 07:26:35 -0700 Subject: [PATCH 4/5] Mnr changes. --- ...mse-token-exchange-and-translation-protocol.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index d48e90f..afa4a40 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -126,13 +126,14 @@ TODO - this draft does not define normative specs for translating from arbitrary # Security Considerations -An AS performing token exchange MUST ensure a client (whether it is an OAuth client or a workload) performing an exchange and a provied token is allowed to perform such operation on it. -An AS SHOULD ensure it is also the intended audience of a token being exchanged. -A value in the subject_token_type parameter MUST correspond to an actual token type provided in the subject_token parameter ({{RFC8693}}). -These are simple countermeasures against replay attacks and various forms of misuse, especially in cases when an AS who issued a token and an AS performing exchanges reside in different security domains. -Typically, self-contained tokens include the aud claim (an array of strings) representing their audience (other types of tokens provide other means for the same). -An extra care SHOULD be taken for tokens that can be passed through the front channel, and tokens that do not explicitly define their type. -Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs. +As countermeasures against replay attacks and various forms of misuse, an authorization server performing token exchange +- MUST ensure a client (whether it is an OAuth client or a workload) is allowed to perform such operation. +- SHOULD ensure that a provided security token allows to perform such operation on it. +- SHOULD ensure it itseld, as an AS, is the intended audience of a token being exchanged. It is typical for self-contained tokens to include the aud claim (an array of strings) representing their intended audience (other types of tokens provide other means for the same). +- a value in the subject_token_type parameter MUST correspond to an actual type of a security token provided in the subject_token parameter ({{RFC8693}}). +These countermeasures become even more significant when an entity issuing security tokens and an AS performing exchange of them reside in different security domains. + +An extra care should be taken for tokens that can be passed around using the front channel, and those tokens that do not explicitly define their type. Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs. TODO Security - data loss in token translation may impact authZ decisions. Be careful when allowing multiple token translations since losses may grow over each step of translation. From c753bdfcfdc66178e24114158773a161d677aaac Mon Sep 17 00:00:00 2001 From: adeinega Date: Sun, 7 Jul 2024 07:29:02 -0700 Subject: [PATCH 5/5] Mnr changes. --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index afa4a40..2c25ef9 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -133,7 +133,7 @@ As countermeasures against replay attacks and various forms of misuse, an author - a value in the subject_token_type parameter MUST correspond to an actual type of a security token provided in the subject_token parameter ({{RFC8693}}). These countermeasures become even more significant when an entity issuing security tokens and an AS performing exchange of them reside in different security domains. -An extra care should be taken for tokens that can be passed around using the front channel, and those tokens that do not explicitly define their type. Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs. +An extra care should be taken for tokens that can be passed around using the front channel, and for those tokens that do not explicitly define their type. Examples here would be OpenID Connect ID Token, and various assertions represented as JWTs. TODO Security - data loss in token translation may impact authZ decisions. Be careful when allowing multiple token translations since losses may grow over each step of translation.