From a5c08c1a742a8e1f629ee2c984b4ab61f6376cda Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 20 Sep 2024 19:22:58 +0200 Subject: [PATCH 01/14] More on collections security Fix #115 Signed-off-by: Thomas Fossati --- draft-ietf-rats-msg-wrap.md | 214 ++++++++++++++++++++---------------- 1 file changed, 120 insertions(+), 94 deletions(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 759c6ac..8b3fd3e 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -175,8 +175,6 @@ The format of the CMW record is shown in {{fig-cddl-record}}. The JSON {{-json}} and CBOR {{-cbor}} representations are provided separately. Both the `json-record` and `cbor-record` have the same fields except for slight differences in the types discussed below. -A CMW record carried in a `"cmw"` JWT claim ({{iana-jwt}}) MUST be a `json-record`. -A CMW record carried in a `"cmw"` CWT claim ({{iana-cwt}}) MUST be a `cbor-record`. ~~~ cddl {::include cddl/cmw-record.cddl} @@ -260,11 +258,14 @@ receive. ## CMW Collections {#cmw-coll} Layered Attesters and composite devices ({{Sections 3.2 and 3.3 of -rats-arch}}) generate Evidence that consists of multiple parts. - For example, in data center servers, it is not uncommon for separate attesting environments (AE) to serve a subsection of the entire machine. One AE might measure and attest to what was booted on the main CPU, while another AE might measure and attest to what was booted on a SmartNIC plugged into a PCIe slot, and a third AE might measure and attest to what was booted on the machine's GPU. +To allow aggregation of multiple, potentially non-homogeneous evidence formats collected from different AEs, this document defines a CMW "collection" as a container that holds several CMW items, each with a label that is unique within the scope of the collection. -To address the composite Attester use case, this document defines a CMW "collection" as a container that holds several CMW items, each with a label that is unique within the scope of the collection. +Even though initially designed to support the layered Attester and composite device use cases, the CMW collection can be repurposed for other use cases requiring aggregation of RATS conceptual messages. +For example, collections may be used to carry groups of Endorsements or Reference Values, Attestation Results, and so on. +One CMW collection can be a mixture of different types of messages. +One CMW collection can be used to carry messages related to more than one device at a time. The CMW collection ({{fig-cddl-collection}}) is defined as a CBOR map or JSON object with CMW values, either native or "tunnelled" ({{cmw-tunnel}}). The position of a `cmw` entry in the `cmw-collection` is not significant. @@ -282,10 +283,19 @@ Since the collection type is recursive, implementations may limit the allowed de {: #fig-cddl-collection artwork-align="left" title="CDDL definition of the CMW collection format"} -Although initially designed for the composite Attester use case, the CMW collection can be repurposed for other use cases requiring CMW aggregation. +CMW itself provides no facilities for authenticity, integrity protection, privacy or attestation security. +It is up to the designer of each use case to understand the security properties necessary and add them around the collection. +A secure channel (e.g., using TLS) or some form of object security (e.g., using JWT) may be sufficient, but not always. -A CMW collection carried in a `"cmw"` JWT claim ({{iana-jwt}}) MUST be a `json-collection`. -A CMW collection carried in a `"cmw"` CWT claim ({{iana-cwt}}) MUST be a `cbor-collection`. +When a CMW is used to carry the Evidence for composite or layered attestation for a single device, the security properties needed are that of attestation. +In particular, all the members in a CMW must be bound together so that an attacker can not replace one Evidence message showing compromise with that from a non-compromised device. +The authenticity and integrity protection MUST be attestation-oriented. + +Note that EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating attestation that has built-in security and will be suitable for some of the same attestation Evidence use cases covered by CMW collections. +However, compared to CMW collections, EAT submods are limited in two ways: + +1. Only EAT-formatted payloads are supported, +2. They are not a good match for modelling layered attestation given their top-down structure does not fit the bottom-up way in which the chain of trust is built in layered attestation. ### CMW Collections' role in composite Attester topology @@ -293,7 +303,7 @@ A CMW Collection's tree structure is not required to be a spanning tree of the s If the labels carry semantic content for a Verifier (e.g. to improve Verifier performance or aid human comprehension), the collection SHOULD be integrity protected. For example, the collection can be integrity protected by including it in a signed token such as a CWT or JWT. -## CMW Tunnel {#cmw-tunnel} +### CMW Tunnel {#cmw-tunnel} The CMW tunnel type ({{fig-cddl-tunnel}}) allows for moving a CMW in one serialization format, either JSON or CBOR, into a collection that uses the opposite serialization format. @@ -309,13 +319,13 @@ The `#`, which is not an acceptable start symbol for the `Content-Type` producti The conversion algorithms are described in the following subsections. -### CBOR-to-JSON +#### CBOR-to-JSON The CBOR byte string of the serialised CBOR CMW is encoded as Base64 using the URL and filename safe alphabet ({{Section 5 of -base64}}) without padding. The obtained string is added as the second element of the `c2j-tunnel` array. The `c2j-tunnel` array is serialized as JSON. -### JSON-to-CBOR +#### JSON-to-CBOR The UTF-8 string of the serialized JSON CMW is encoded as a CBOR byte string (Major type 2). The byte string is added as the second element of the `j2c-tunnel` array. @@ -348,6 +358,101 @@ func CMWTypeDemux(b []byte) (CMW, error) { } ~~~ +# Transporting COSE and JOSE Web Tokens + +To allow embedding CMWs and CMW collections into CBOR-based protocols and web APIs, this document defines two `"cmw"` claims for JSON Web Tokens (JWT) and CBOR Web Tokens (CWT). + +Their definitions are provided in {{iana-jwt}} and {{iana-cwt}} respectively.. + +## Encoding Requirements + +A CMW collection carried in a `"cmw"` JWT claim ({{iana-jwt}}) MUST be a `json-collection`. +A CMW collection carried in a `"cmw"` CWT claim ({{iana-cwt}}) MUST be a `cbor-collection`. + +A CMW record carried in a `"cmw"` JWT claim ({{iana-jwt}}) MUST be a `json-record`. +A CMW record carried in a `"cmw"` CWT claim ({{iana-cwt}}) MUST be a `cbor-record`. + +# Transporting CMW in X.509 Messages {#x509} + +CMW may need to be transported in PKIX messages, such as Certificate Signing Requests (CSRs) or in X.509 Certificates and Certificate Revocation Lists (CRLs). +The former use is documented in {{-csr-a}}, the latter in Section 6.1 of {{DICE-arch}}. + +This section specifies the CMW extension to carry CMW objects. + +The CMW extension MAY be included in X.509 Certificates, CRLs {{-pkix}}, and CSRs. + +The CMW extension MUST be identified by the following object identifier: + +~~~asn.1 +id-pe-cmw OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-pe(1) TBD } +~~~ + +This extension SHOULD NOT be marked critical. +It MAY be marked critical in cases where the attestation-related information is essential for granting resource access, and there is a risk that legacy relying parties would bypass such controls. + +The CMW extension MUST have the following syntax: + +~~~asn.1 +CMW ::= CHOICE { + json UTF8String, + cbor OCTET STRING +} +~~~ + +The CMW MUST contain the serialized CMW object in JSON or CBOR format, using the appropriate CHOICE entry. + +The DER-encoded CMW is the value of the OCTET STRING for the extnValue field of the extension. + +## ASN.1 Module {#asn1-x509} + +This section provides an ASN.1 module {{X.680}} for the CMW extension, following the conventions established in {{RFC5912}} and {{RFC6268}}. + +~~~asn.1 +CMWExtn + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-cmw-collection-extn(TBD) } + +DEFINITIONS IMPLICIT TAGS ::= +BEGIN + +IMPORTS + EXTENSION + FROM PKIX-CommonTypes-2009 -- RFC 5912 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkixCommon-02(57) } ; + +-- CMW Extension + +ext-CMW EXTENSION ::= { + SYNTAX CMW + IDENTIFIED BY id-pe-cmw } + +-- CMW Extension OID + +id-pe-cmw OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-pe(1) TBD } + +-- CMW Extension Syntax + +CMW ::= CHOICE { + json UTF8String, + cbor OCTET STRING +} + +END +~~~ + +## Compatibility with DICE `ConceptualMessageWrapper` + +Section 6.1.8 of {{DICE-arch}} defines the ConceptualMessageWrapper format and the associated object identifier. +The CMW format defined in {{DICE-arch}} allows only a subset of the CMW grammar defined in this document. +Specifically, the tunnel and collection formats cannot be encoded using DICE CMWs. + # Examples The (equivalent) examples in {{ex-ja}}, {{ex-ca}}, and {{ex-ct}} assume that @@ -464,87 +569,6 @@ The following example shows the use of the `"cmw"` JWT claim to transport a CMW {::include cddl/eat-example-1.json} ~~~ -# Transporting CMW in X.509 Messages {#x509} - -CMW may need to be transported in PKIX messages, such as Certificate Signing Requests (CSRs) or in X.509 Certificates and Certificate Revocation Lists (CRLs). -The former use is documented in {{-csr-a}}, the latter in Section 6.1 of {{DICE-arch}}. - -This section specifies the CMW extension to carry CMW objects. - -The CMW extension MAY be included in X.509 Certificates, CRLs {{-pkix}}, and CSRs. - -The CMW extension MUST be identified by the following object identifier: - -~~~asn.1 -id-pe-cmw OBJECT IDENTIFIER ::= - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-pe(1) TBD } -~~~ - -This extension SHOULD NOT be marked critical. -It MAY be marked critical in cases where the attestation-related information is essential for granting resource access, and there is a risk that legacy relying parties would bypass such controls. - -The CMW extension MUST have the following syntax: - -~~~asn.1 -CMW ::= CHOICE { - json UTF8String, - cbor OCTET STRING -} -~~~ - -The CMW MUST contain the serialized CMW object in JSON or CBOR format, using the appropriate CHOICE entry. - -The DER-encoded CMW is the value of the OCTET STRING for the extnValue field of the extension. - -## ASN.1 Module {#asn1-x509} - -This section provides an ASN.1 module {{X.680}} for the CMW extension, following the conventions established in {{RFC5912}} and {{RFC6268}}. - -~~~asn.1 -CMWExtn - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-cmw-collection-extn(TBD) } - -DEFINITIONS IMPLICIT TAGS ::= -BEGIN - -IMPORTS - EXTENSION - FROM PKIX-CommonTypes-2009 -- RFC 5912 - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-pkixCommon-02(57) } ; - --- CMW Extension - -ext-CMW EXTENSION ::= { - SYNTAX CMW - IDENTIFIED BY id-pe-cmw } - --- CMW Extension OID - -id-pe-cmw OBJECT IDENTIFIER ::= - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-pe(1) TBD } - --- CMW Extension Syntax - -CMW ::= CHOICE { - json UTF8String, - cbor OCTET STRING -} - -END -~~~ - -## Compatibility with DICE `ConceptualMessageWrapper` - -Section 6.1.8 of {{DICE-arch}} defines the ConceptualMessageWrapper format and the associated object identifier. -The CMW format defined in {{DICE-arch}} allows only a subset of the CMW grammar defined in this document. -Specifically, the tunnel and collection formats cannot be encoded using DICE CMWs. - # Implementation Status This section records the status of known implementations of the protocol @@ -582,14 +606,16 @@ The developers can be contacted on the Zulip channel: # Security Considerations {#seccons} -This document introduces two encapsulation formats for RATS conceptual messages, record and tag. +## Records and CBOR Tags + RATS conceptual messages are typically secured using cryptography. If the messages are already protected, then there are no additional security requirements imposed by the introduction of this encapsulation. If an adversary tries to modify the payload encapsulation, it will result in incorrect processing of the encapsulated message and lead to an error. If the messages are not protected, additional security must be added at a different layer. As an example, a `cbor-record` containing an UCCS (Unprotected CWT Claims Sets) {{-rats-uccs}} can be signed using COSE Sign1 {{-cose}}. -This document introduces a format for holding multiple CMW items in a collection. +## Collections + If the collection is not protected from tampering by external security measures (such as object security primitives) or internal mechanisms (such as intra-item binding), an attacker could easily manipulate the collection's contents. It is the responsibility of the Attester who creates the CMW collection to ensure that the contents of the collection are integrity-protected. The designer of the attestation technology is typically in charge of ensuring that the security properties are met, not the user of the conceptual message wrapper. @@ -600,7 +626,7 @@ For example, key material used to sign/bind an entire CMW collection should be a The binding does not necessarily have to be a signature over the CMW collection, it might also be achieved through identifiers, cross-linking, signing or hashing between the members of the collection. Client-authenticated TLS may be used to bind a CMW collection of Evidence messages. However, the client key used with TLS should not be that of the end-user or owner of the device. -Instead, it should be attestation-oriented key material from the device or the attester manufacturer. +Instead, it must be attestation-oriented key material from the device or the attester manufacturer. # IANA Considerations From e60615de29cdef2dd8fd11570c4d8437324abb00 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 20 Sep 2024 19:29:48 +0200 Subject: [PATCH 02/14] remove extra `.` --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 8b3fd3e..e44964f 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -362,7 +362,7 @@ func CMWTypeDemux(b []byte) (CMW, error) { To allow embedding CMWs and CMW collections into CBOR-based protocols and web APIs, this document defines two `"cmw"` claims for JSON Web Tokens (JWT) and CBOR Web Tokens (CWT). -Their definitions are provided in {{iana-jwt}} and {{iana-cwt}} respectively.. +Their definitions are provided in {{iana-jwt}} and {{iana-cwt}} respectively. ## Encoding Requirements From c5da6fa6989e30352e56a28f790d69109c2b3fbc Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 20 Sep 2024 19:30:57 +0200 Subject: [PATCH 03/14] remove redundant refs --- draft-ietf-rats-msg-wrap.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index e44964f..2474c20 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -366,11 +366,11 @@ Their definitions are provided in {{iana-jwt}} and {{iana-cwt}} respectively. ## Encoding Requirements -A CMW collection carried in a `"cmw"` JWT claim ({{iana-jwt}}) MUST be a `json-collection`. -A CMW collection carried in a `"cmw"` CWT claim ({{iana-cwt}}) MUST be a `cbor-collection`. +A CMW collection carried in a `"cmw"` JWT claim MUST be a `json-collection`. +A CMW collection carried in a `"cmw"` CWT claim MUST be a `cbor-collection`. -A CMW record carried in a `"cmw"` JWT claim ({{iana-jwt}}) MUST be a `json-record`. -A CMW record carried in a `"cmw"` CWT claim ({{iana-cwt}}) MUST be a `cbor-record`. +A CMW record carried in a `"cmw"` JWT claim MUST be a `json-record`. +A CMW record carried in a `"cmw"` CWT claim MUST be a `cbor-record`. # Transporting CMW in X.509 Messages {#x509} From 22ff537b065db902866ba859ced1c768a9e2b556 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 20 Sep 2024 19:35:08 +0200 Subject: [PATCH 04/14] add ref from S3.3 (collections) to S8.2 (collections seccons) also create separate subsection for EAT submods considerations Signed-off-by: Thomas Fossati --- draft-ietf-rats-msg-wrap.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 2474c20..9426e88 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -290,8 +290,11 @@ A secure channel (e.g., using TLS) or some form of object security (e.g., using When a CMW is used to carry the Evidence for composite or layered attestation for a single device, the security properties needed are that of attestation. In particular, all the members in a CMW must be bound together so that an attacker can not replace one Evidence message showing compromise with that from a non-compromised device. The authenticity and integrity protection MUST be attestation-oriented. +For further security considerations about collections, see {{seccons-coll}}. -Note that EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating attestation that has built-in security and will be suitable for some of the same attestation Evidence use cases covered by CMW collections. +### Relation to EAT `submods` + +EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating attestation that has built-in security and will be suitable for some of the same attestation Evidence use cases covered by CMW collections. However, compared to CMW collections, EAT submods are limited in two ways: 1. Only EAT-formatted payloads are supported, @@ -614,7 +617,7 @@ If an adversary tries to modify the payload encapsulation, it will result in inc If the messages are not protected, additional security must be added at a different layer. As an example, a `cbor-record` containing an UCCS (Unprotected CWT Claims Sets) {{-rats-uccs}} can be signed using COSE Sign1 {{-cose}}. -## Collections +## Collections {#seccons-coll} If the collection is not protected from tampering by external security measures (such as object security primitives) or internal mechanisms (such as intra-item binding), an attacker could easily manipulate the collection's contents. It is the responsibility of the Attester who creates the CMW collection to ensure that the contents of the collection are integrity-protected. From 00a4c2d5a15f52b813ba0ec3955e8ce1fd93db8c Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 20 Sep 2024 19:37:14 +0200 Subject: [PATCH 05/14] revert must->should --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 9426e88..80ea3ab 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -629,7 +629,7 @@ For example, key material used to sign/bind an entire CMW collection should be a The binding does not necessarily have to be a signature over the CMW collection, it might also be achieved through identifiers, cross-linking, signing or hashing between the members of the collection. Client-authenticated TLS may be used to bind a CMW collection of Evidence messages. However, the client key used with TLS should not be that of the end-user or owner of the device. -Instead, it must be attestation-oriented key material from the device or the attester manufacturer. +Instead, it should be attestation-oriented key material from the device or the attester manufacturer. # IANA Considerations From 1b02f22593c7c397352c2b46d5f5ee87d7e18286 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 20 Sep 2024 19:56:36 +0200 Subject: [PATCH 06/14] add Laurence as contributor Signed-off-by: Thomas Fossati --- draft-ietf-rats-msg-wrap.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 80ea3ab..dc4c399 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -30,6 +30,12 @@ author: - name: Hannes Tschofenig email: hannes.tschofenig@gmx.net +contributor: + - name: Laurence Lundblade + organization: Security Theory LLC + email: lgl@securitytheory.com + contribution: Laurence contributed significant improvements around the security requirements and considerations for CMW collections. + normative: RFC4648: base64 RFC5280: pkix From 7dfdadfbadc0f3bcb65808967b3be46fa1aca423 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Sat, 21 Sep 2024 08:19:38 +0200 Subject: [PATCH 07/14] rephrase point 2 --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index dc4c399..379f60c 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -304,7 +304,7 @@ EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating However, compared to CMW collections, EAT submods are limited in two ways: 1. Only EAT-formatted payloads are supported, -2. They are not a good match for modelling layered attestation given their top-down structure does not fit the bottom-up way in which the chain of trust is built in layered attestation. +2. Their top-down structure does not align with the bottom-up approach layered attesters use to build the chain of trust, making them unsuitable for modelling layered attestation. ### CMW Collections' role in composite Attester topology From 03b8317bae922f10fa2ccc0a27dc54406a9e3dd2 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Mon, 23 Sep 2024 09:45:18 +0200 Subject: [PATCH 08/14] fix title --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 379f60c..5f8bfa1 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -367,7 +367,7 @@ func CMWTypeDemux(b []byte) (CMW, error) { } ~~~ -# Transporting COSE and JOSE Web Tokens +# Transporting CMW in COSE and JOSE Web Tokens To allow embedding CMWs and CMW collections into CBOR-based protocols and web APIs, this document defines two `"cmw"` claims for JSON Web Tokens (JWT) and CBOR Web Tokens (CWT). From a2cb293697e648f3c00727d6970e353df9872272 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Wed, 25 Sep 2024 18:55:14 +0200 Subject: [PATCH 09/14] wordsmithing Signed-off-by: Thomas Fossati --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 5f8bfa1..6e0637b 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -304,7 +304,7 @@ EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating However, compared to CMW collections, EAT submods are limited in two ways: 1. Only EAT-formatted payloads are supported, -2. Their top-down structure does not align with the bottom-up approach layered attesters use to build the chain of trust, making them unsuitable for modelling layered attestation. +2. Their top-down structure does not align well with the bottom-up approach layered attesters use to build the chain of trust, making them not ideal for modelling layered attestation. ### CMW Collections' role in composite Attester topology From 39e1f533af004805e30967fba3284101ac4c9a7f Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 27 Sep 2024 15:59:08 +0200 Subject: [PATCH 10/14] fix point 1 --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 6e0637b..d7ab313 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -303,7 +303,7 @@ For further security considerations about collections, see {{seccons-coll}}. EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating attestation that has built-in security and will be suitable for some of the same attestation Evidence use cases covered by CMW collections. However, compared to CMW collections, EAT submods are limited in two ways: -1. Only EAT-formatted payloads are supported, +1. {{EAT}} allows carrying non-EAT-formatted types by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket. However, these need to be specified in subsequent standard documents updating the EAT specification, 2. Their top-down structure does not align well with the bottom-up approach layered attesters use to build the chain of trust, making them not ideal for modelling layered attestation. ### CMW Collections' role in composite Attester topology From cc0c401905f3d5afdb888f4f081c7ba3e074e0cc Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 27 Sep 2024 17:05:56 +0200 Subject: [PATCH 11/14] fix: wrong EAT label Signed-off-by: Thomas Fossati --- draft-ietf-rats-msg-wrap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index d7ab313..99d8288 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -303,7 +303,7 @@ For further security considerations about collections, see {{seccons-coll}}. EAT submods ({{Section 4.2.18 of -rats-eat}}) provide a facility for aggregating attestation that has built-in security and will be suitable for some of the same attestation Evidence use cases covered by CMW collections. However, compared to CMW collections, EAT submods are limited in two ways: -1. {{EAT}} allows carrying non-EAT-formatted types by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket. However, these need to be specified in subsequent standard documents updating the EAT specification, +1. EAT {{-rats-eat}} allows carrying non-EAT-formatted types by augmenting the $EAT-CBOR-Tagged-Token socket or the $JSON-Selector socket. However, these need to be specified in subsequent standard documents updating the EAT specification, 2. Their top-down structure does not align well with the bottom-up approach layered attesters use to build the chain of trust, making them not ideal for modelling layered attestation. ### CMW Collections' role in composite Attester topology From cea1277c3341b39726a778a49991b4de9e9050df Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sat, 19 Oct 2024 20:33:38 +0200 Subject: [PATCH 12/14] Re-wording of the paragraph --- draft-ietf-rats-msg-wrap.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 99d8288..02ad445 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -293,10 +293,7 @@ CMW itself provides no facilities for authenticity, integrity protection, privac It is up to the designer of each use case to understand the security properties necessary and add them around the collection. A secure channel (e.g., using TLS) or some form of object security (e.g., using JWT) may be sufficient, but not always. -When a CMW is used to carry the Evidence for composite or layered attestation for a single device, the security properties needed are that of attestation. -In particular, all the members in a CMW must be bound together so that an attacker can not replace one Evidence message showing compromise with that from a non-compromised device. -The authenticity and integrity protection MUST be attestation-oriented. -For further security considerations about collections, see {{seccons-coll}}. +When a CMW is used to carry Evidence for composite or layered attestation of a single device, all components within the CMW must be cryptographically bound to prevent an attacker from replacing compromised Evidence with that of a non-compromised device. The protection of authenticity and integrity MUST be provided by the attestation technology. For additional security considerations related to collections, refer to {{seccons-coll}}. ### Relation to EAT `submods` From fb4a4f7bfa955261f8e478628bda9a6b24794cf1 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sun, 20 Oct 2024 13:23:23 +0200 Subject: [PATCH 13/14] Update draft-ietf-rats-msg-wrap.md --- draft-ietf-rats-msg-wrap.md | 74 ++++++++++++++++++++++++------------- 1 file changed, 49 insertions(+), 25 deletions(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 02ad445..4096ab0 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -20,21 +20,24 @@ pi: [toc, sortrefs, symrefs] author: - name: Henk Birkholz organization: Fraunhofer SIT - email: henk.birkholz@sit.fraunhofer.de + email: henk.birkholz@ietf.contact - name: Ned Smith organization: Intel email: ned.smith@intel.com - name: Thomas Fossati organization: Linaro email: thomas.fossati@linaro.org - - name: Hannes Tschofenig - email: hannes.tschofenig@gmx.net + - + name: Hannes Tschofenig + org: University of Applied Sciences Bonn-Rhein-Sieg + abbrev: H-BRS + email: Hannes.Tschofenig@gmx.net contributor: - name: Laurence Lundblade organization: Security Theory LLC email: lgl@securitytheory.com - contribution: Laurence contributed significant improvements around the security requirements and considerations for CMW collections. + contribution: Laurence made significant contributions to enhancing the security requirements and considerations for CMW collections. normative: RFC4648: base64 @@ -268,10 +271,9 @@ For example, in data center servers, it is not uncommon for separate attesting e One AE might measure and attest to what was booted on the main CPU, while another AE might measure and attest to what was booted on a SmartNIC plugged into a PCIe slot, and a third AE might measure and attest to what was booted on the machine's GPU. To allow aggregation of multiple, potentially non-homogeneous evidence formats collected from different AEs, this document defines a CMW "collection" as a container that holds several CMW items, each with a label that is unique within the scope of the collection. -Even though initially designed to support the layered Attester and composite device use cases, the CMW collection can be repurposed for other use cases requiring aggregation of RATS conceptual messages. -For example, collections may be used to carry groups of Endorsements or Reference Values, Attestation Results, and so on. -One CMW collection can be a mixture of different types of messages. -One CMW collection can be used to carry messages related to more than one device at a time. +Although originally designed to support layered Attester and composite device use cases, the CMW collection can be adapted for other scenarios that require the aggregation of RATS conceptual messages. +For instance, collections may be used to group Endorsements, Reference Values, Attestation Results, and more. +A single CMW collection can contain a mix of different message types, and it can also be used to carry messages related to multiple devices simultaneously. The CMW collection ({{fig-cddl-collection}}) is defined as a CBOR map or JSON object with CMW values, either native or "tunnelled" ({{cmw-tunnel}}). The position of a `cmw` entry in the `cmw-collection` is not significant. @@ -289,11 +291,14 @@ Since the collection type is recursive, implementations may limit the allowed de {: #fig-cddl-collection artwork-align="left" title="CDDL definition of the CMW collection format"} -CMW itself provides no facilities for authenticity, integrity protection, privacy or attestation security. -It is up to the designer of each use case to understand the security properties necessary and add them around the collection. -A secure channel (e.g., using TLS) or some form of object security (e.g., using JWT) may be sufficient, but not always. -When a CMW is used to carry Evidence for composite or layered attestation of a single device, all components within the CMW must be cryptographically bound to prevent an attacker from replacing compromised Evidence with that of a non-compromised device. The protection of authenticity and integrity MUST be provided by the attestation technology. For additional security considerations related to collections, refer to {{seccons-coll}}. +CMW itself provides no facilities for authenticity, integrity protection, or confidentiality. +It is the responsibility of the designer for each use case to determine the necessary security properties and implement them accordingly. +A secure channel (e.g., via TLS) or object-level security (e.g., using JWT) may suffice in some scenarios, but not in all. + +When a CMW is used to carry Evidence for composite or layered attestation of a single device, all components within the CMW must be cryptographically +bound to prevent an attacker from replacing compromised Evidence with that of a non-compromised device. The protection of authenticity and integrity +MUST be provided by the attestation technology. For additional security considerations related to collections, refer to {{seccons-coll}}. ### Relation to EAT `submods` @@ -366,9 +371,9 @@ func CMWTypeDemux(b []byte) (CMW, error) { # Transporting CMW in COSE and JOSE Web Tokens -To allow embedding CMWs and CMW collections into CBOR-based protocols and web APIs, this document defines two `"cmw"` claims for JSON Web Tokens (JWT) and CBOR Web Tokens (CWT). +To facilitate the embedding of CMWs and CMW collections in CBOR-based protocols and web APIs, this document defines two `"cmw"` claims for use with JSON Web Tokens (JWT) and CBOR Web Tokens (CWT). -Their definitions are provided in {{iana-jwt}} and {{iana-cwt}} respectively. +The definitions for these claims can be found in {{iana-jwt}} and {{iana-cwt}}, respectively. ## Encoding Requirements @@ -381,9 +386,10 @@ A CMW record carried in a `"cmw"` CWT claim MUST be a `cbor-record`. # Transporting CMW in X.509 Messages {#x509} CMW may need to be transported in PKIX messages, such as Certificate Signing Requests (CSRs) or in X.509 Certificates and Certificate Revocation Lists (CRLs). -The former use is documented in {{-csr-a}}, the latter in Section 6.1 of {{DICE-arch}}. -This section specifies the CMW extension to carry CMW objects. +The use of CMW in CSRs is documented in {{-csr-a}}, while its application in X.509 Certificates and CRLs is detailed in Section 6.1 of {{DICE-arch}}. + +This section outlines the CMW extension designed to carry CMW objects. The CMW extension MAY be included in X.509 Certificates, CRLs {{-pkix}}, and CSRs. @@ -407,7 +413,7 @@ CMW ::= CHOICE { } ~~~ -The CMW MUST contain the serialized CMW object in JSON or CBOR format, using the appropriate CHOICE entry. +The CMW MUST include the serialized CMW object in either JSON or CBOR format, utilizing the appropriate CHOICE entry. The DER-encoded CMW is the value of the OCTET STRING for the extnValue field of the extension. @@ -455,9 +461,28 @@ END ## Compatibility with DICE `ConceptualMessageWrapper` -Section 6.1.8 of {{DICE-arch}} defines the ConceptualMessageWrapper format and the associated object identifier. -The CMW format defined in {{DICE-arch}} allows only a subset of the CMW grammar defined in this document. -Specifically, the tunnel and collection formats cannot be encoded using DICE CMWs. +Section 6.1.8 of {{DICE-arch}} specifies the ConceptualMessageWrapper (CMW) format and its corresponding object identifier. +The CMW format outlined in {{DICE-arch}} permits only a subset of the CMW grammar defined in this document. +In particular, the tunnel and collection formats cannot be encoded using DICE CMWs. + +# Transporting CMW in EAT `submods` {#submods} + +{{Section 4.2.18 of -rats-eat}} allows carrying non-EAT-formatted types in EAT submods by augmenting the `$EAT-CBOR-Tagged-Token` socket or the `$JSON-Selector` socket. + +The following CDDL adds `cbor-CMW` and `json-CMW` to EAT using such extension points: + +~~~ cddl +$EAT-CBOR-Tagged-Token /= #6.CPA765(cbor-CMW) + +$JSON-Selector /= [ type: "CMW", nested-token: json-CMW ] +~~~ + +Where: + +* `cbor-CMW` and `json-CMW` are defined in {{collected-cddl}}, and +* `CPA765` is the CBOR tag for CMW ({{iana-cbor-tag}}). + +[^rfced] This document uses the CPA (code point allocation) convention described in {{?I-D.bormann-cbor-draft-numbers}}. For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note. # Examples @@ -660,13 +685,13 @@ IANA is requested to add a new `cmw` claim to the "JSON Web Token Claims" sub-re * Change Controller: IETF * Specification Document(s): {{type-n-val}} and {{cmw-coll}} of {{&SELF}} -## CBOR Tag Registration +## CBOR Tag Registration {#iana-cbor-tag} IANA is requested to add the following tag to the "CBOR Tags" {{!IANA.cbor-tags}} registry. | CBOR Tag | Data Item | Semantics | Reference | |----------|-----------|-----------|-----------| -| TBD | CBOR map, CBOR array, CBOR tag | RATS Conceptual Message Wrapper | {{type-n-val}}, {{cbor-tag}} and {{cmw-coll}} of {{&SELF}} | +| CPA765 | CBOR map, CBOR array, CBOR tag | RATS Conceptual Message Wrapper | {{type-n-val}}, {{cbor-tag}} and {{cmw-coll}} of {{&SELF}} | ## RATS Conceptual Message Wrapper (CMW) Indicators Registry {#iana-ind-ext} @@ -888,7 +913,7 @@ When using CMW collection, the preconditions apply for each entry in the collect The list of currently open issues for this documents can be found at [](https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/issues). -Note to RFC Editor: please remove before publication. +[^rfced] please remove before publication. # Acknowledgments {:numbered="false"} @@ -898,8 +923,7 @@ Brian Campbell, Carl Wallace, Carsten Bormann, Dionna Glaze, -{{{Ionuț Mihalcea}}} -Laurence Lundblade, +{{{Ionuț Mihalcea}}}, Michael B. Jones, Mohit Sethi, Russ Housley, From 3e7bf518b8c4b5f32752556350e2dd3cd42c3227 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sun, 20 Oct 2024 13:24:57 +0200 Subject: [PATCH 14/14] Update draft-ietf-rats-msg-wrap.md --- draft-ietf-rats-msg-wrap.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-rats-msg-wrap.md b/draft-ietf-rats-msg-wrap.md index 4096ab0..86d9260 100644 --- a/draft-ietf-rats-msg-wrap.md +++ b/draft-ietf-rats-msg-wrap.md @@ -296,9 +296,10 @@ CMW itself provides no facilities for authenticity, integrity protection, or con It is the responsibility of the designer for each use case to determine the necessary security properties and implement them accordingly. A secure channel (e.g., via TLS) or object-level security (e.g., using JWT) may suffice in some scenarios, but not in all. -When a CMW is used to carry Evidence for composite or layered attestation of a single device, all components within the CMW must be cryptographically -bound to prevent an attacker from replacing compromised Evidence with that of a non-compromised device. The protection of authenticity and integrity -MUST be provided by the attestation technology. For additional security considerations related to collections, refer to {{seccons-coll}}. +When a CMW is used to carry the Evidence for composite or layered attestation for a single device, the security properties needed are that of attestation. +In particular, all the members in a CMW must be bound together so that an attacker can not replace one Evidence message showing compromise with that from a non-compromised device. +The authenticity and integrity protection MUST be attestation-oriented. +For further security considerations about collections, see {{seccons-coll}}. ### Relation to EAT `submods`