From 2726176c9dd943f60d80966819c7881e81e554fb Mon Sep 17 00:00:00 2001 From: Jon Geater Date: Sun, 17 Mar 2024 00:22:51 +0000 Subject: [PATCH 01/15] Add Security Considerations consistent with RFC 3552 Signed-off-by: Jon Geater --- draft-ietf-scitt-scrapi.md | 157 ++++++++++++++++++++++++++++++++++++- 1 file changed, 156 insertions(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 83eda63..cd3affd 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -694,7 +694,162 @@ TODO # Security Considerations -TODO +## General scope + +This document describes the interoperable API for client calls to, and +implementations of, a Transparency Service as specified in +[SCITT-ARCH]. As such the security considerations in this +section are concerned only with security considerations that are +relevant at that implementation layer. All questions of security of the +related COSE formats, algorithm choices, cryptographic envelopes, +verifiable data structures and the like are handled elsewhere and out +of scope of this document. + +## Applicable Environment + +SCITT is concerned with issues of cross-boundary supply-chain-wide data +integrity and as such must assume a very wide range of deployment +environments. Thus, no assumptions can be made about the security of +the computing environment in which any client implementation of this +specification runs. + +## User-host authentication + +[SCITT ARCH] defines 2 distinct roles that require authentication: +Issuers who sign Statements, and clients that submit API calls on +behalf of Issuers. While Issuer authentication and signing of +Statements is very important for the trustworthiness of systems +implementing the SCITT building blocks, it is out of scope of this +document. This document is only concerned with authentication of API +clients. + +For those endpoints that require client authentication, Transparency +Services MUST support at least one of the following options: + * HTTP Authorization header with a bearer JWT + * domain-bound API key + * TLS client authentication + +Transparency Services MUST provide a configuration surface that +allows Issuers to specify which authorized clients can submit +Statements on their behalf. + +Where authentication methods rely on long term secrets, both clients +ad Transparency Services implementing this specification MUST allow +for the revocation and rolling of authentication secrets. + +## Primary threats + +### In scope + +The most serious threats to implementations on Transparency Services +are ones that would cause the failure of their main promises, to wit: + * Threats to strong identification, for example representing the + Statements from one issuer as those of another + * Threats to payload integrity, for example changing the contents of + a Signed Statement before making it transparent + * Threats to non-equivocation, for example attacks that would enable + the presentation or verification of divergent proofs for the same + Statement payload + +#### Denial of service attacks + +While denial of service attacks are very hard to defend against +completely, and Transparency Services are unlikely to be in the +critical path of any safety-liable operation, any attack which could +cause the _silent_ failure of Signed Statement registration, for +example, should be considered in scope. + +In principle DoS attacks are easily mitigated by the client +checking that the Transparency Service has registered any +submitted Signed Statement and returned a Receipt. Since +verification of Receipts does not require the involvement of the +Transparency Service DoS attacks are not a major issue. + +Clients to Transparency Services SHOULD ensure that Receipts are +available for their registered Statements, either on a periodic +or needs-must basis, depending on the use case. + +Beyond this, implementers of Transparency Services SHOULD implement +general good practice around network attacks, flooding, rate +limiting etc. + +#### Eavesdropping + +Since the purpose of this API is to ultimately put the message +payloads on a Transparency Log there is limited risk to eavesdropping. +Nonetheless transparency may mean 'within a limited community' rather +than 'in full public', so implementers MUST add protections against +man-in-the-middle and network eavesdropping, such as TLS. + +#### Message modification attacks + +While most relevant modification attacks are mitigated by the use of +the Issuer signature on the Signed Statement, the `Issue Statement` +endpoint presents an opportunity for manipulation of messages and +misrepresentation of Issuer intent that could mislead later Verifiers. + +Transparency Services offering the `Issue Statement` endpoint MUST +require authentication and transport-level security for that endpoint, +MUST NOT modify anything in the message to be signed, and MUST take +steps to ensure that the party calling the endpoint is authorized to +register statements on behalf of the specified Issuer. + +#### Message insertion attacks + +While most relevant insertion attacks are mitigated by the use of +the Issuer signature on the Signed Statement, the `Issue Statement` +endpoint presents an opportunity for insertion of messages and +misrepresentation of Issuer intent that could mislead later Verifiers. +There are 2 most likely avenues to this attack: +* Stolen client endpoint authentication credentials +* Stolen or misused Issuer keys held in the Transparency Service on + behalf of clients + +Clients relying on the `Issue Statement` endpoint SHOULD take steps +to ensure their endpoint authentication credentials are securely +stored and can be rotated and/or revoked in the case of a breach. + +Transparency Services offering the `Issue Statement` endpoint MUST +require authentication and transport-level security for that endpoint, +and MUST enable the rotation and revocation of those credentials. + +Transparency Services offering the `Issue Statement` endpoint MUST +take careful steps in both design and operation of their software +stack to prevent the theft or inappropriate use of the Issuer keys +they use to sign Statements on behalf of Issuers, such as HSMs for +storage and least-privilege, regularly refreshed access controls for +use. + +Transparency Services MAY also implement additional protections +such as anomaly detection or rate limiting in order to mitigate +the impact of any breach. + +### Out of scope + +#### Replay attacks + +Replay attacks are not particularly concerning for SCITT or SCRAPI: +once a statement is made it is intended to be immutable and non- +repudiable, so making it twice should not lead to any particular +issues. There could be issues at the payload level (for instance, +the statement "it is raining" may true when first submitted but not +when replayed), but being payload-agnostic implementations of SCITT +services cannot be required to worry about that. + +If the semantic content of the payload are time dependent and +susceptible to replay attacks in this way then timestamps MAY be +added to the payload signed by the Issuer. + +#### Message deletion attacks + +Once registered with a Transparency Service, Transparent Statements +cannot be deleted. Thus, any message deletion attack must occur +prior to registration else it is indistinguishable from a +man-in-the-middle or denial-of-service attack on this interface. + + + +# TODO TODO: Consider negotiation for receipt as "JSON" or "YAML". TODO: Consider impact of media type on "Data URIs" and QR Codes. From eeacff2dfe1a15543778422a6fc2ca7a74a69eef Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:41:38 -0700 Subject: [PATCH 02/15] Update draft-ietf-scitt-scrapi.md Co-authored-by: A.J. Stein --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index cd3affd..8c613f9 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -715,7 +715,7 @@ specification runs. ## User-host authentication -[SCITT ARCH] defines 2 distinct roles that require authentication: +[SCITT-ARCH] defines 2 distinct roles that require authentication: Issuers who sign Statements, and clients that submit API calls on behalf of Issuers. While Issuer authentication and signing of Statements is very important for the trustworthiness of systems From 3bb18eff8d43f260ea82821e7f1f671b2078f971 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:41:45 -0700 Subject: [PATCH 03/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 8c613f9..022202c 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -725,7 +725,7 @@ clients. For those endpoints that require client authentication, Transparency Services MUST support at least one of the following options: - * HTTP Authorization header with a bearer JWT + - HTTP Authorization header with a bearer JWT * domain-bound API key * TLS client authentication From 29826018ecf30f46610a58e2a42a5749bb94d940 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:41:54 -0700 Subject: [PATCH 04/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 022202c..49f32ca 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -726,7 +726,7 @@ clients. For those endpoints that require client authentication, Transparency Services MUST support at least one of the following options: - HTTP Authorization header with a bearer JWT - * domain-bound API key + - domain-bound API key * TLS client authentication Transparency Services MUST provide a configuration surface that From 8c70c8063bc29da2348d2909937bfbf6c114f65a Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:42:03 -0700 Subject: [PATCH 05/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 49f32ca..190733c 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -727,7 +727,7 @@ For those endpoints that require client authentication, Transparency Services MUST support at least one of the following options: - HTTP Authorization header with a bearer JWT - domain-bound API key - * TLS client authentication + - TLS client authentication Transparency Services MUST provide a configuration surface that allows Issuers to specify which authorized clients can submit From 6a39c793643eec3484becf6f32796c67208a6ab1 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:42:12 -0700 Subject: [PATCH 06/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 190733c..7488dfd 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -734,7 +734,7 @@ allows Issuers to specify which authorized clients can submit Statements on their behalf. Where authentication methods rely on long term secrets, both clients -ad Transparency Services implementing this specification MUST allow +and Transparency Services implementing this specification MUST allow for the revocation and rolling of authentication secrets. ## Primary threats From 5f74a7a9a3e60205aac78944f5563123fad8b290 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:42:19 -0700 Subject: [PATCH 07/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 7488dfd..16cb2fe 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -743,7 +743,7 @@ for the revocation and rolling of authentication secrets. The most serious threats to implementations on Transparency Services are ones that would cause the failure of their main promises, to wit: - * Threats to strong identification, for example representing the + - Threats to strong identification, for example representing the Statements from one issuer as those of another * Threats to payload integrity, for example changing the contents of a Signed Statement before making it transparent From c9ee9794d629a52997e2a35e2a1d3fd7e1c4dd3a Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:42:27 -0700 Subject: [PATCH 08/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 16cb2fe..c962c7c 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -745,7 +745,7 @@ The most serious threats to implementations on Transparency Services are ones that would cause the failure of their main promises, to wit: - Threats to strong identification, for example representing the Statements from one issuer as those of another - * Threats to payload integrity, for example changing the contents of + - Threats to payload integrity, for example changing the contents of a Signed Statement before making it transparent * Threats to non-equivocation, for example attacks that would enable the presentation or verification of divergent proofs for the same From befe0ad410a73189d21f95251b80a8b5de26ff91 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:42:34 -0700 Subject: [PATCH 09/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index c962c7c..0d449d1 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -747,7 +747,7 @@ are ones that would cause the failure of their main promises, to wit: Statements from one issuer as those of another - Threats to payload integrity, for example changing the contents of a Signed Statement before making it transparent - * Threats to non-equivocation, for example attacks that would enable + - Threats to non-equivocation, for example attacks that would enable the presentation or verification of divergent proofs for the same Statement payload From c006637e277b39d370b62fb00d3c0eea07304874 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:42:59 -0700 Subject: [PATCH 10/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 0d449d1..7d03b78 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -801,7 +801,7 @@ the Issuer signature on the Signed Statement, the `Issue Statement` endpoint presents an opportunity for insertion of messages and misrepresentation of Issuer intent that could mislead later Verifiers. There are 2 most likely avenues to this attack: -* Stolen client endpoint authentication credentials +- Stolen client endpoint authentication credentials * Stolen or misused Issuer keys held in the Transparency Service on behalf of clients From eaae668e51b8219ea5b4a8305c24913aa4f6e11a Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:43:04 -0700 Subject: [PATCH 11/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 7d03b78..733eb2c 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -802,7 +802,7 @@ endpoint presents an opportunity for insertion of messages and misrepresentation of Issuer intent that could mislead later Verifiers. There are 2 most likely avenues to this attack: - Stolen client endpoint authentication credentials -* Stolen or misused Issuer keys held in the Transparency Service on +- Stolen or misused Issuer keys held in the Transparency Service on behalf of clients Clients relying on the `Issue Statement` endpoint SHOULD take steps From 8067adb7045f6236cb51e7e78ac254ea4ea4364d Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:43:18 -0700 Subject: [PATCH 12/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 733eb2c..dd54c01 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -829,7 +829,7 @@ the impact of any breach. #### Replay attacks Replay attacks are not particularly concerning for SCITT or SCRAPI: -once a statement is made it is intended to be immutable and non- +once a statement is made, it is intended to be immutable and non- repudiable, so making it twice should not lead to any particular issues. There could be issues at the payload level (for instance, the statement "it is raining" may true when first submitted but not From 68d935d24bfc406c353c9255529dbe99f4f76785 Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:43:50 -0700 Subject: [PATCH 13/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index dd54c01..d679c6a 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -848,7 +848,6 @@ prior to registration else it is indistinguishable from a man-in-the-middle or denial-of-service attack on this interface. - # TODO TODO: Consider negotiation for receipt as "JSON" or "YAML". From 78bc6a72390b909d9036705df6f084a826ec520f Mon Sep 17 00:00:00 2001 From: Steve Lasker Date: Mon, 18 Mar 2024 00:43:55 -0700 Subject: [PATCH 14/15] Update draft-ietf-scitt-scrapi.md --- draft-ietf-scitt-scrapi.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index d679c6a..84f1d72 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -847,7 +847,6 @@ cannot be deleted. Thus, any message deletion attack must occur prior to registration else it is indistinguishable from a man-in-the-middle or denial-of-service attack on this interface. - # TODO TODO: Consider negotiation for receipt as "JSON" or "YAML". From 6a81982412e1eb8c87545f25def8311c8beee013 Mon Sep 17 00:00:00 2001 From: Jon Geater Date: Mon, 18 Mar 2024 09:23:59 +0000 Subject: [PATCH 15/15] Update draft-ietf-scitt-scrapi.md Co-authored-by: Steve Lasker --- draft-ietf-scitt-scrapi.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-scitt-scrapi.md b/draft-ietf-scitt-scrapi.md index 84f1d72..36c2699 100644 --- a/draft-ietf-scitt-scrapi.md +++ b/draft-ietf-scitt-scrapi.md @@ -842,7 +842,7 @@ added to the payload signed by the Issuer. #### Message deletion attacks -Once registered with a Transparency Service, Transparent Statements +Once registered with a Transparency Service, Registered Signed Statements cannot be deleted. Thus, any message deletion attack must occur prior to registration else it is indistinguishable from a man-in-the-middle or denial-of-service attack on this interface.