From 58fe222ce37a9f91b799ac37de7de542b084817d Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 9 Sep 2024 15:08:39 +0200 Subject: [PATCH 1/7] update security consideration --- draft-ietf-oauth-status-list.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 66c92be..4c6a54e 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -35,6 +35,7 @@ normative: RFC7519: RFC7519 RFC8259: RFC8259 RFC8392: RFC8392 + RFC8725: RFC8725 RFC8949: RFC8949 RFC9052: RFC9052 RFC9110: RFC9110 @@ -571,7 +572,16 @@ Resulting in the byte array and compressed/base64url-encoded status list: # Security Considerations {#Security} ## Correct decoding and parsing of the encoded status list -TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data + +Implementers should be particularly careful for the correct parsing and decoding of the status list. Incorrect implementations may check the index on the wrong data or misscalculate the bit and byte index leading to an erroneous status of the Referenced Token. Beware, that bits are indexed (bit order) from least signicant bit to most significant bit (also called "right to left") while bytes are indexed (byte order) in their natural incrementing byte order (usually written for display purpose from left to write). Endianess does not apply here because each status value fits within a single byte. + +Implementations shall always verify correctness using the test vectors given by this specification. + +## Security Guidance for JWT and CWT + +Status List Token in JWT format should follow the security considerations of {{RFC7519}} and the best current practices of {{RFC8725}}. + +Status List Token in CWT format should follow the security considerations of {{RFC8392}}. ## Cached and Stale status lists @@ -580,12 +590,6 @@ in the Status List Token provides one mechanism for setting a maximum cache time a status list to a CDN or other distribution mechanism while giving guidance to consumers of the status list on how often they need to fetch a fresh copy of the status list even if that status list is not expired. -## Authorized access to the Status List {#security-authorization} -TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section - -## History -TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture - # Privacy Considerations ## Limiting issuers observability of token verification {#privacy-issuer} @@ -604,8 +608,9 @@ A malicious Issuer could bypass the privacy benefits of the herd privacy by gene Once the Relying Party receives the Referenced Token, this enables him to request the Status List to validate its status through the provided `uri` parameter and look up the corresponding `index`. However, the Relying Party may persistently store the `uri` and `index` of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for a KYC process that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential. +TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture + This behaviour could be mitigated by: -- adding authorization rules to the Status List, see [](#security-authorization). - regular re-issuance of the Referenced Token, see [](#implementation-lifecycle). ## Unlinkability @@ -875,6 +880,7 @@ for their valuable contributions, discussions and feedback to this specification -04 +* add security considerations on correct parsing and decoding * add CORS considerations to the http endpoint * fix reference of Status List in CBOR format * added status_list CWT claim key assigned From 3601702129a6cba0eaa7c744a6db5d4eefcc3aa7 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 9 Sep 2024 17:09:55 +0200 Subject: [PATCH 2/7] add privacy consideration on observability of outsiders --- draft-ietf-oauth-status-list.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 4c6a54e..32b6e86 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -604,7 +604,7 @@ The herd privacy is depending on the number of entities within the Status List c A malicious Issuer could bypass the privacy benefits of the herd privacy by generating a unique Status List for every Referenced Token. By these means, he could maintain a mapping between Referenced Tokens and Status Lists and thus track the usage of Referenced Tokens by utilizing this mapping for the incoming requests. This malicious behaviour could be detected by Relying Parties that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes. -## Unobservability of Relying Parties {#privacy-relying-party} +## Observability of Relying Parties {#privacy-relying-party} Once the Relying Party receives the Referenced Token, this enables him to request the Status List to validate its status through the provided `uri` parameter and look up the corresponding `index`. However, the Relying Party may persistently store the `uri` and `index` of the Referenced Token to request the Status List again at a later time. By doing so regularly, the Relying Party may create a profile of the Referenced Token's validity status. This behaviour may be intended as a feature, e.g. for a KYC process that requires regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of an employee credential. @@ -613,16 +613,27 @@ TODO elaborate on status list only providing the up-to date/latest status, no hi This behaviour could be mitigated by: - regular re-issuance of the Referenced Token, see [](#implementation-lifecycle). +## Observability of Outsiders + +Outside actors may analyse the publicly available Status Lists to get information on the internal processes of the Issuer and his related business. This data may allow inferences on the total number of issued Reference Tokens and the revocation rate. Additionally, actors may regularly fetch this data or use the historic data functionality to learn how these numbers change over time. + +This behaviour could be mitigated by: +- disable the historical data feature (TODO:link) +- disable the Status List Aggregation {#batch-fetching} +- choose non-sequential, pseudo-random or random indices +- use decoy entries to obfuscate the real number of Referenced Tokens within a Status List +- choose to deploy and utilize multiple Status Lists simultaneously + ## Unlinkability -Colluding Issuers and a Relying Parties have the possibility to link two transactions, as the tuple of `uri` and `index` inside the Referenced Token are unique and therefore traceable data. By comparing the status claims of received Referenced Tokens, two colluding Relying Parties could determine that they have interacted with the same user or an Issuer could trace the usage of its issued Referenced Token by colluding with various Relying Parties. It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties. +Colluding Issuers and Relying Parties have the possibility to link two transactions, as the tuple of `uri` and `index` inside the Referenced Token are unique and therefore traceable data. By comparing the status claims of received Referenced Tokens, two colluding Relying Parties could determine that they have interacted with the same user or an Issuer could trace the usage of its issued Referenced Token by colluding with various Relying Parties. It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties. To avoid privacy risks for colluding Relying Parties, it is RECOMMENDED that Issuers use batch issuance to issue multiple tokens, see [](#implementation-lifecycle). To avoid further correlatable information by the values of `uri` and `index`, Issuers are RECOMMENDED to: - choose non-sequential, pseudo-random or random indices -- use decoy or dead entries to obfuscate the real number of Referenced Tokens within a Status List +- use decoy entries to obfuscate the real number of Referenced Tokens within a Status List - choose to deploy and utilize multiple Status Lists simultaneously ## Third Party Hosting @@ -880,6 +891,7 @@ for their valuable contributions, discussions and feedback to this specification -04 +* add privacy consideration on observability of outsiders * add security considerations on correct parsing and decoding * add CORS considerations to the http endpoint * fix reference of Status List in CBOR format From 8111f4cb4e6685a6a631f930eaad53a8acbec815 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 9 Sep 2024 17:23:02 +0200 Subject: [PATCH 3/7] add privacy consideration on using private relay protocols --- draft-ietf-oauth-status-list.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 32b6e86..dc58bd3 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -70,6 +70,7 @@ informative: RFC6749: RFC6749 RFC7662: RFC7662 RFC7800: RFC7800 + RFC9458: RFC9458 SD-JWT.VC: I-D.ietf-oauth-sd-jwt-vc ISO.mdoc: author: @@ -592,7 +593,7 @@ a fresh copy of the status list even if that status list is not expired. # Privacy Considerations -## Limiting issuers observability of token verification {#privacy-issuer} +## Observability of Issuers {#privacy-issuer} The main privacy consideration for a Status List, especially in the context of the Issuer-Holder-Verifier model {{SD-JWT.VC}}, is to prevent the Issuer from tracking the usage of the Referenced Token when the status is being checked. If an Issuer offers status information by referencing a specific token, this would enable him to create a profile for the issued token by correlating the date and identity of Relying Parties, that are requesting the status. @@ -600,6 +601,8 @@ The Status List approaches these privacy implications by integrating the status The herd privacy is depending on the number of entities within the Status List called its size. A larger size results in better privacy but also impacts the performance as more data has to be transferred to read the Status List. +Additionally, the Issuer may analyse data from the HTTP request to identify the Relying Party, e.g. through the sender's IP address. This behaviour may be mitigated by private relay protocols or other mechanism hiding the original sender like {{RFC9458}}. + ## Malicious Issuers A malicious Issuer could bypass the privacy benefits of the herd privacy by generating a unique Status List for every Referenced Token. By these means, he could maintain a mapping between Referenced Tokens and Status Lists and thus track the usage of Referenced Tokens by utilizing this mapping for the incoming requests. This malicious behaviour could be detected by Relying Parties that request large amounts of Referenced Tokens by comparing the number of different Status Lists and their sizes. @@ -613,7 +616,7 @@ TODO elaborate on status list only providing the up-to date/latest status, no hi This behaviour could be mitigated by: - regular re-issuance of the Referenced Token, see [](#implementation-lifecycle). -## Observability of Outsiders +## Observability of Outsiders {#privacy-outsider} Outside actors may analyse the publicly available Status Lists to get information on the internal processes of the Issuer and his related business. This data may allow inferences on the total number of issued Reference Tokens and the revocation rate. Additionally, actors may regularly fetch this data or use the historic data functionality to learn how these numbers change over time. @@ -891,6 +894,7 @@ for their valuable contributions, discussions and feedback to this specification -04 +* add privacy consideration on using private relay protocols * add privacy consideration on observability of outsiders * add security considerations on correct parsing and decoding * add CORS considerations to the http endpoint From 543b2badf54f493810e4088ae99f93288d324b25 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 9 Sep 2024 18:42:35 +0200 Subject: [PATCH 4/7] Update draft-ietf-oauth-status-list.md Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index dc58bd3..18c8c59 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -574,7 +574,7 @@ Resulting in the byte array and compressed/base64url-encoded status list: ## Correct decoding and parsing of the encoded status list -Implementers should be particularly careful for the correct parsing and decoding of the status list. Incorrect implementations may check the index on the wrong data or misscalculate the bit and byte index leading to an erroneous status of the Referenced Token. Beware, that bits are indexed (bit order) from least signicant bit to most significant bit (also called "right to left") while bytes are indexed (byte order) in their natural incrementing byte order (usually written for display purpose from left to write). Endianess does not apply here because each status value fits within a single byte. +Implementers should be particularly careful for the correct parsing and decoding of the status list. Incorrect implementations might check the index on the wrong data or miscalculate the bit and byte index leading to an erroneous status of the Referenced Token. Beware, that bits are indexed (bit order) from least significant bit to most significant bit (also called "right to left") while bytes are indexed (byte order) in their natural incrementing byte order (usually written for display purpose from left to write). Endianness does not apply here because each status value fits within a single byte. Implementations shall always verify correctness using the test vectors given by this specification. From 2a6af2c2a0a7b00820d9848dbc277ab6b1d93dca Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Wed, 18 Sep 2024 08:41:30 +0200 Subject: [PATCH 5/7] Update draft-ietf-oauth-status-list.md Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index a41581a..0371961 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -617,7 +617,7 @@ Resulting in the byte array and compressed/base64url-encoded status list: Implementers should be particularly careful for the correct parsing and decoding of the status list. Incorrect implementations might check the index on the wrong data or miscalculate the bit and byte index leading to an erroneous status of the Referenced Token. Beware, that bits are indexed (bit order) from least significant bit to most significant bit (also called "right to left") while bytes are indexed (byte order) in their natural incrementing byte order (usually written for display purpose from left to write). Endianness does not apply here because each status value fits within a single byte. -Implementations shall always verify correctness using the test vectors given by this specification. +Implementations are RECOMMENDED to verify correctness using the test vectors given by this specification. ## Security Guidance for JWT and CWT From 9d35948b1444963b033411da961003a0ae350c90 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Wed, 18 Sep 2024 11:48:09 +0200 Subject: [PATCH 6/7] Update draft-ietf-oauth-status-list.md Co-authored-by: Tobias Looker --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 0371961..4239a56 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -621,7 +621,7 @@ Implementations are RECOMMENDED to verify correctness using the test vectors giv ## Security Guidance for JWT and CWT -Status List Token in JWT format should follow the security considerations of {{RFC7519}} and the best current practices of {{RFC8725}}. +A Status List Token in the JWT format should follow the security considerations of {{RFC7519}} and the best current practices of {{RFC8725}}. Status List Token in CWT format should follow the security considerations of {{RFC8392}}. From 2d30edce82c042135cf120343a1eeb450bae076b Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Wed, 18 Sep 2024 11:48:21 +0200 Subject: [PATCH 7/7] Update draft-ietf-oauth-status-list.md Co-authored-by: Tobias Looker --- draft-ietf-oauth-status-list.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-status-list.md b/draft-ietf-oauth-status-list.md index 4239a56..d43ed53 100644 --- a/draft-ietf-oauth-status-list.md +++ b/draft-ietf-oauth-status-list.md @@ -623,7 +623,7 @@ Implementations are RECOMMENDED to verify correctness using the test vectors giv A Status List Token in the JWT format should follow the security considerations of {{RFC7519}} and the best current practices of {{RFC8725}}. -Status List Token in CWT format should follow the security considerations of {{RFC8392}}. +A Status List Token in the CWT format should follow the security considerations of {{RFC8392}}. ## Cached and Stale status lists