From 048d43f7805cb5520f079313730613d6b59d9fb0 Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Thu, 8 Jul 2021 00:35:41 +0200 Subject: [PATCH 01/11] Introduced publish-subscribe model. * Removed "delta" TODO as there was nothing to be fixed. * Fixed line break in uni-directional diagram. Signed-off-by: Michael Eckel --- ...-ietf-rats-reference-interaction-models.md | 249 +++++++++++++++++- 1 file changed, 245 insertions(+), 4 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 606f481..a306e69 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -353,7 +353,8 @@ The final output of the Verifier are Attestation Results. Attestation Results co generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | | - | evidence, eventLogs -------------------------------------> | | | + | evidence, eventLogs -------------------------------------> | + | | | appraiseEvidence(evidence, eventLogs, refValues) | attestationResult <= | ~ ~ @@ -378,8 +379,6 @@ The final output of the Verifier are Attestation Results. Attestation Results co | | ~~~~ -TODO: Describe Deltas - Uni-Directional Remote Attestation procedures can be initiated both by the Attester and by the Verifier. Initiation by the Attester can result in unsolicited pushes of Evidence to the Verifier. Initiation by the Verifier always results in solicited pushes to the Verifier. @@ -394,7 +393,7 @@ Timestamps created from local clocks (absolute clocks using a global timescale, This binding provides a proof of synchronization that MUST be included in all produced Evidence. Correspondingly, conveyed Evidence in this model provides a proof that it was fresh at a certain point in time. -While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey evidence generated from Claim values that have changed and new Event Logs entries since the previous conveyance. This updates reflecting the differences are called "delta" in the sequence diagram above. +While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey evidence generated from Claim values that have changed and new Event Log entries since the previous conveyance. These updates reflecting the differences are called "delta" in the sequence diagram above. Effectively, the Uni-Directional model allows for a series of Evidence to be pushed to multiple Verifiers simultaneously. Methods to detect excessive time drift that would mandate a fresh Handle to be received by the Handle Distributor as well as timing of Handle distribution are out-of-scope of this document. @@ -452,6 +451,248 @@ While a Handle Distributor is not required in this model, it is also limited to Handles provided by a specific subscribing Verifier MUST be used in Evidence generation for that specific Verifier. The Streaming model uses the same information elements as the Challenge/Response and the Uni-Directional model. Methods to detect excessive time drift that would mandate a refreshed Handle to be conveyed via another subscribe operation are out-of-scope of this document. + + + +## Publish-Subscribe Remote Attestation + +The publish-subscribe messaging pattern is widely used for communication in different areas. +The strengths of the communication pattern include loose coupling and scalability. +Unlike the Streaming Remote Attestation interaction model, Attesters do not (need to) know the corresponding Verifiers of attestation Evidence. +Nor do Verifiers (need to) know consumers of their produced Attestation Results. +With an increasing number of Attesters, Verifiers, and Relying Parties, the publish-subscribe pattern may reduce interdependencies and provide better scalability. + +There exist several publish-subscribe solutions. +In the IoT landscape, for example, the Message Queuing Telemetry Transport (MQTT) protocol is widely used ({{-MQTT}}). +For remote attestation, the TCG has published the Trusted Network Communications (TNC) specification, an open Network Admission Control (NAC) solution ({{-TNC}}). +TNC is based on a Metadata Access Point (MAC) server which implements the publish-subscribe pattern. + +With publish-subscribe, clients typically *connect* to (or *register* with) a publish-subscribe server (PubSub server). +Clients may *publish* data in the form of a *message* under a certain *topic*. +*Subscribers* to that topic get *notified* whenever a message arrives under a topic, and the appropriate message is forwarded to them. +Depending on the particular publish-subscribe model and implementation, clients can be either publishers or subscribers or both. + +In the following sections, the interaction models *Challenge/Response Remote Attestation over Publish-Subscribe* and *Uni-Directional Remote Attestation over Publish-Subscribe* are described. +There are different phases that both models go through: + +1. Handle Generation +2. Attestation +3. Verification +4. Attestation Result Consumption + +The models only differ in the handle generation phase. Attestation, verification, and attestation result consumption are identical from a protocol point of view. + + +### Connection Establishment and Client ID + +~~~~ +.--------. .---------------. +| Client | | PubSub Server | +'--------' '---------------' + | | + | connect(id=C?) --------------------------------------> | + | | + | addClient(id=C?) + | | + | <----------------------------------------- conAck(id?) | + | | + ~ ~ +~~~~ + +Depending on the PubSub server, clients connecting to it must provide their own (unique) client ID or are assigned a (unique) client ID by the PubSub server. +In the diagram above, the optional client ID arguments are marked with a trailing "?". +After the PubSub server receives a connection request, it adds the client to its internal management facilities with its (unique) ID. +In addition, clients may need to authenticate to the server and/or vice versa in a separate step. +All of this is beyond the scope of this document. + +For reasons of readability, the connection step is omitted in the following diagrams as well as acknowledgement steps for subscribing and publishing. + + +### Handle Generation for Challenge/Response Remote Attestation over Publish-Subscribe + +~~~~ + +.----------. .---------------. .----------. +| Attester | | PubSub Server | | Verifier | +'----------' '---------------' '----------' + | | | | +=======================[HANDLE GENERATION PHASE]======================== + | | | | + | sub(topic=AttReq) -----------> | | + | | <------ pub(topic=AttReq, | + | | handle) | + | <--------- notify(topic=AttReq | | + | handle) | | + ~ ~ ~ +~~~~ + +The Challenge/Response Remote Attestation over Publish-Subscribe model uses the same information elements as the Challenge/Response Remote Attestation model. +Handles are provided by a Verifier on a per-request basis. +In the sequence diagram above, an Attester subscribes to the "AttReq" (= Attestation Request) topic on the PubSub server. +The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server forwards to the Attester by notifying it. + +### Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe + +~~~~ +.----------. .-------------. .---------------. .----------. +| Attester | | Handle | | PubSub Server | | Verifier | +'----------' | Distributor | '---------------' '----------' + | '-------------' | | + | | | | +=======================[HANDLE GENERATION PHASE]======================== + | | | | + | . | | + | sub(topic=handle) --------------> | <--- sub(topic=Handle) | + | . | | + | | | | + | generateHandle() | | + | | => handle | | + | | | | + | | pub(topic=Handle, | | + | | handle) -----> | | + | x | | + | | | + | <------------ notify(topic=Handle | notify(topic=Handle, | + | handle) | handle) ------> | + | | | + ~ ~ ~ +~~~~ + +The Uni-Directional Remote Attestation over Publish-Subscribe model uses the same information elements as the Uni-Directional Remote Attestation model. +Accordingly, Handles are created by a 3rd party, the Handle Distributor. +In the sequence diagram above, both an Attester and a Verifier subscribe to the "Handle" topic on the PubSub server. +When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards the Handle to them (handle generation phase). + +### Attestation and Verification + +~~~~ + ~ ~ ~ + | | | +.----------. .---------------. .----------. +| Attester | | PubSub Server | | Verifier | +'----------' '---------------' '----------' + | | | +* ========================[ATTESTATION PHASE]========================= * +* | | | * +* | | <---- sub(topic=AttEv) | * +* | | | * +**********[loop]******************************************************** +* | | | * +* generateClaims(attestingEnvironment) | | * +* | => claims, eventLogs | | * +* | | | * +* collectClaims(claims, claimSelection) | | * +* | => collectedClaims | | * +* | | | * +* generateEvidence(handle, authSecIDs, | | * +* | collectedClaims) | | * +* | => evidence | | * +* | | | * +* | pub(topic=AttEv, | | * +* | evidence, eventLogs) -------> | | * +* | | notify(topic=AttEv, | * +* | | evidence, | * +* | | eventLogs) ---> | * +* | | | * +* ========================[VERIFICATION PHASE]======================== * +* | | | * +* | | appraiseEvidence( * +* | | evidence, * +* | | eventLogs, * +* | | refValues) * +* | | attestationResult <= | * +* | | | * +************************************************************************ + | | | + ~ ~ ~ +~~~~ + +Exactly as in the Challenge/Response and Uni-Directional models, there is an attestation-verification loop in which the Attester generates Evidence and the Verifier appraises it. +In the Publish-Subscribe model above, the Attester publishes Evidence to the topic "AttEv" (= Attestation Evidence) on the PubSub server, to which a Verifier subscribed before. +The PubSub server notifies Verifiers, accordingly, by forwarding the attestation Evidence. +Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas' for Evidence and Event Logs. +Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server. + +### Attestation Result Consumption + +~~~~ + ~ ~ ~ ~ + | | | | +.----------. .---------------. .---------------. .----------. +| Attester | | Relying Party | | PubSub Server | | Verifier | +'----------' '---------------' '---------------' '----------' + | | | | +=================[ATTESTATION RESULT CONSUMPTION PHASE]================= + | | | | + | | sub(topic=AttRes) | | + | | handle) ---------> | | + | | | | +**********[loop]******************************************************** +* | | | | * +* | | | <-------- pub(topic=AttRes, * +* | | | attestationResult) * +* | | notify(topic=AttRes | | * +* | | <-- attestationResult) | | * +* | | | | * +************************************************************************ + | | | | + ~ ~ ~ ~ +~~~~ + +Attestation Result consumption by Relying Parties is the same for both publish-subscribe models, Challenge/Response Remote Attestation over Publish-Subscribe and Uni-Directional Remote Attestation over Publish-Subscribe. +Relying Parties subscribe to topic "AttRes" (= Attestation Result) on the PubSub server. +The PubSub server forwards Attestation Results to the Relying Parties as soon as they are published to topic "AttRes". + +### Publish/Subscribe Topics + +Many publish-subscribe models provide hierarchical organization of topics. +This way, subscribers can subscribe to either all attestations (topic "AttRes"), or, for example, to topic "AttRes/DbServers/Germany" to receive only attestations from database servers in Germany. +Further, it may be required to distinguish between uni-directional and challenge-response attestation evidence. +For this purpose a wildcard subscription may be useful, for example "AttRes/DbServers/Germany/\*\*/uni" (to receive only uni-directional attestation evidence) or "AttRes/DbServers/Germany/\*\*/cr" (to receive only challenge-response attestation evidence). + +### Security Considerations + +Attestation Evidence is digitally signed and, thus, authenticated and integral. +A man-in-the-middle attack that tampers with the Evidence undetected is practically infeasible. +The PubSub server is used for (temporarily) storing and forwarding attestation Evidence to interested clients, i. e. Verifiers. +Further, Attestation Results published on the SubSub server by Verifiers are digitally signed, too, and cannot be altered undetected. + +### Reference Implementation(s) + +* On the practical Application of a Trusted Information Agent -- Michael Eckel. *Master's Thesis*. (September 30, 2014) -- \ + Realize TPM-based remote attestation on the TNC publish-subscribe server called Metadata Access Point (MAP). + Uses TPM 1.2, Java, jTSS Wrapper, and TCG Trusted Network Communications (TNC) on Android platforms. + +* TODO + + + + + + + + + + + + + + + + + + + + + + + + + + + + + # Additional Application-Specific Requirements From e204d7dc169947998be86f937705edcb01557d65 Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Thu, 8 Jul 2021 00:43:09 +0200 Subject: [PATCH 02/11] Added informative reference to TNC and MQTT. Signed-off-by: Michael Eckel --- draft-ietf-rats-reference-interaction-models.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index a306e69..d9bfe52 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -79,6 +79,23 @@ informative: The Faulkner Journal: 25.2 DOI: "10.1353/fau.2010.0002" date: 2010 + TNC: + title: TCG Trusted Network Communications TNC Architecture for Interoperability + author: + - ins: TCG + name: Trusted Computing Group + seriesinfo: + Specification Version 2.0 + Revision 13 + date: 2017 + MQTT: + title: Message Queuing Telemetry Transport (MQTT) Version 5.0 Committee Specification 02 + author: + - ins: OASIS + name: Organization for the Advancement of Structured Information Standards + seriesinfo: + MQTT Version 5.0 + date: 2018 --- abstract From e05ce9cdfc1dbdcde5d2e01010e5cd16d7310aca Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Thu, 8 Jul 2021 00:46:52 +0200 Subject: [PATCH 03/11] Fixing informative references. Signed-off-by: Michael Eckel --- draft-ietf-rats-reference-interaction-models.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index d9bfe52..0257c30 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -67,7 +67,7 @@ informative: name: Liqun Chen seriesinfo: ACM: > - Proceedings of the 11rd ACM conference on Computer and Communications Security + Proceedings of the 11th ACM conference on Computer and Communications Security page: 132-145 date: 2004 turtles: @@ -85,8 +85,7 @@ informative: - ins: TCG name: Trusted Computing Group seriesinfo: - Specification Version 2.0 - Revision 13 + Specification: Version 2.0 Revision 13 date: 2017 MQTT: title: Message Queuing Telemetry Transport (MQTT) Version 5.0 Committee Specification 02 @@ -94,7 +93,7 @@ informative: - ins: OASIS name: Organization for the Advancement of Structured Information Standards seriesinfo: - MQTT Version 5.0 + Specification: Version 5.0 date: 2018 --- abstract @@ -480,8 +479,8 @@ Nor do Verifiers (need to) know consumers of their produced Attestation Results. With an increasing number of Attesters, Verifiers, and Relying Parties, the publish-subscribe pattern may reduce interdependencies and provide better scalability. There exist several publish-subscribe solutions. -In the IoT landscape, for example, the Message Queuing Telemetry Transport (MQTT) protocol is widely used ({{-MQTT}}). -For remote attestation, the TCG has published the Trusted Network Communications (TNC) specification, an open Network Admission Control (NAC) solution ({{-TNC}}). +In the IoT landscape, for example, the Message Queuing Telemetry Transport (MQTT) protocol is widely used ({{MQTT}}). +For remote attestation, the TCG has published the Trusted Network Communications (TNC) specification, an open Network Admission Control (NAC) solution ({{TNC}}). TNC is based on a Metadata Access Point (MAC) server which implements the publish-subscribe pattern. With publish-subscribe, clients typically *connect* to (or *register* with) a publish-subscribe server (PubSub server). From 3b6a7dbffc6a8e9cb6bab3808291ccd0f0b99d2e Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Sun, 10 Sep 2023 12:39:37 +0200 Subject: [PATCH 04/11] Added pub-sub model; fixed CDDL; polished. --- ...-ietf-rats-reference-interaction-models.md | 597 ++++++++++-------- 1 file changed, 334 insertions(+), 263 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index a1a926b..226fae8 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -45,15 +45,15 @@ author: normative: RFC2119: RFC3161: TSA - RFC5280: + RFC5280: X509 RFC7049: CBOR RFC7252: COAP RFC8174: BCP205: RFC7942 - RFC8610: + RFC8610: CDDL + RFC9334: RATS informative: - I-D.ietf-rats-architecture: RATS I-D.ietf-rats-tpm-based-network-device-attest: RIV I-D.birkholz-rats-tuda: TUDA DAA: @@ -95,6 +95,30 @@ informative: seriesinfo: Specification: Version 5.0 date: 2018 + DesignPatterns: + title: Design Patterns - Elements of Reusable Object-Oriented Software + author: + - ins: E. Gamma + name: Erich Gamma + - ins: R. Helm + name: Richard Helm + - ins: R. Johnson + name: Ralph Johnson + - ins: J. Vlissides + name: John Vlissides + seriesinfo: + Publisher: Addison-Wesley + date: 1994 + ISIS: + title: Exploiting Virtual Synchrony in Distributed Systems + author: + - ins: K. Birman + name: Ken Paul Birman + - ins: T. Joseph + name: Thomas A. Joseph + seriesinfo: + DOI: 10.1145/41457.37515 + date: 1987 --- abstract @@ -113,8 +137,9 @@ This document defines interaction models that can be used in specific RATS-relat The primary focus of this document is the conveyance of attestation Evidence. The reference models defined can also be applied to the conveyance of other Conceptual Messages in RATS. Specific goals of this document are to: -1.) prevent inconsistencies in descriptions of interaction models in other documents (due to text cloning and evolution over time), and to -2.) enable to highlight an exact delta/divergence between the core set of characteristics captured here in this document and variants of these interaction models used in other specifications or solutions. +1. prevent inconsistencies in descriptions of interaction models in other documents (due to text cloning and evolution over time), and to + +2. enable to highlight an exact delta/divergence between the core set of characteristics captured here in this document and variants of these interaction models used in other specifications or solutions. In summary, this document enables the specification and design of trustworthy and privacy preserving conveyance methods for attestation Evidence from an Attester to a Verifier. While the conveyance of other Conceptual Messages is out-of-scope the methods described can also be applied to the conveyance of, for example, Endorsements or Attestation Results. @@ -295,15 +320,17 @@ The way these handles are processed is the most prominent difference between the ## Challenge/Response Remote Attestation -~~~~ +~~~~ aasvg .----------. .----------. | Attester | | Verifier | -'----------' '----------' +'----+-----' '-----+----' + | | +==========================[ATTESTATION PHASE]=========================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | | | - | <-- requestAttestation(handle, authSecIDs, claimSelection) | + |<--- requestAttestation(handle, authSecIDs, claimSelection) | | | collectClaims(claims, claimSelection) | | => collectedClaims | @@ -311,9 +338,12 @@ The way these handles are processed is the most prominent difference between the generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | | - | evidence, eventLogs -------------------------------------> | + | evidence, eventLogs -------------------------------------->| + | | +==========================[VERIFICATION PHASE]========================== | | - | appraiseEvidence(evidence, eventLogs, refValues) + | appraiseEvidence(evidence, + eventLogs, refValues) | attestationResult <= | | | ~~~~ @@ -346,24 +376,28 @@ For this purpose, it validates the signature, the Attester Identity, and the Han Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference Values, such as Reference Integrity Measurements. The final output of the Verifier are Attestation Results. Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness. -### Models and example sequences of Challenge/Response Remote Attestation -According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed. This section highlights the information flows between the Attester, Verifier, and Relying Party undergoing Remote Attestation Procedure, using these models. +### Models and Example Sequences of Challenge/Response Remote Attestation -1. Passport Model +According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed. +This section highlights the information flows between the Attester, Verifier, and Relying Party undergoing Remote Attestation Procedure, using these models. + +#### Passport Model The passport model is so named because of its resemblance to how nations issue passports to their citizens. In this model, the attestation sequence is a two-step procedure. In the first step, an Attester conveys Evidence to a Verifier, which compares the Evidence against its appraisal policy. The Verifier then gives back an Attestation Result to the Attester, which simply caches it. In the second step, the Attester presents the Attestation Result (and possibly additional Claims/Evidence) to a Relying Party, which then compares this information against its own appraisal policy to establish the trustworthiness of the Attester. -~~~~ +~~~~ aasvg .----------. .----------. .---------------. | Attester | | Verifier | | Relying Party | -'----------' '----------' '---------------' +'----+-----' '-----+----' '-------+-------' + | | | +==========================[ATTESTATION PHASE]=========================== | | | generateClaims(attestingEnvironment) | | | => claims, eventLogs | | | | | - | <------- requestAttestation(handle, | | + |<-------- requestAttestation(handle, | | | authSecIDs, claimSelection) | | | | | collectClaims(claims, claimSelection) | | @@ -373,34 +407,46 @@ then gives back an Attestation Result to the Attester, which simply caches it. I authSecIDs, collectedClaims) | | | => evidence | | | | | - | evidence, eventLogs ---------------> | | + | evidence, eventLogs ---------------->| | + | | | +==========================[VERIFICATION PHASE]========================== | | | | appraiseEvidence(evidence, | | eventLogs, refValues) | | attestationResult <= | | | | | - | <----------------- attestationResult | | + |<------------------ attestationResult | | | | | - | evidence, attestationResult -------------------------> | + | evidence, attestationResult -------------------------->| | | | - | | appraiseResult(evidence, +=================[ATTESTATION RESULT CONSUMPTION PHASE]================= + | | | + | | appraiseResult(evidence, | | attestationResult) | | | ~~~~ -2. BackGround Check Model +#### Background Check Model -The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party. The Attester conveys Evidence to the Relying Party, which does not process its payload, but relays the message and optionally checks its signature against a policed trust anchor store. Upon receiving the Evidence, the Relying Party initiates a session with the Verifier. Once the session is established, it forwards the received Evidence to the Verifier. The Verifier appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party. The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. +The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. +In this model, the attestation sequence is initiated by a Relying Party. +The Attester conveys Evidence to the Relying Party, which does not process its payload, but relays the message and optionally checks its signature against a policed trust anchor store. +Upon receiving the Evidence, the Relying Party initiates a session with the Verifier. +Once the session is established, it forwards the received Evidence to the Verifier. +The Verifier appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party. +The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. -~~~~ +~~~~ aasvg .----------. .---------------. .----------. | Attester | | Relying Party | | Verifier | -'----------' '---------------' '----------' +'----+-----' '-------+-------' '-----+----' + | | | +==========================[ATTESTATION PHASE]=========================== | | | generateClaims(attestingEnvironment) | | | => claims, eventLogs | | | | | - | <----- requestAttestation(handle, | | + |<------ requestAttestation(handle, | | | authSecIDs, claimSelection) | | | | | collectClaims(claims, | | @@ -411,36 +457,45 @@ The background-check model is so named because of the resemblance of how employe authSecIDs, collectedClaims) | | | => evidence | | | | | - | evidence, eventLogs ------------> | | + | evidence, eventLogs ------------->| | + | | | +==========================[VERIFICATION PHASE]========================== | | | | | (handle, evidence, | - | | eventLogs) --------> | + | | eventLogs) --------->| | | | | | appraiseEvidence(evidence, | | eventLogs, refValues) | | attestationResult <= | | | | - | | <--------- (evidence, | + | |<---------- (evidence, | | | attestationResult) | | | | - | appraiseResult(evidence, | - | attestationResult) | +=================[ATTESTATION RESULT CONSUMPTION PHASE]================= + | | | + | appraiseResult(evidence, | + | attestationResult) | | | | ~~~~ ## Uni-Directional Remote Attestation -~~~~ +~~~~ aasvg .----------. .--------------------. .----------. | Attester | | Handle Distributor | | Verifier | -'----------' '--------------------' '----------' +'----+-----' '---------+----------' '-----+----' | | | +=======================[HANDLE GENERATION PHASE]======================== | generateHandle() | | | => handle | | | | - | <----------------------------- handle | handle ----------> | + |<------------------------------ handle | handle ----------->| | | | - generateClaims(attestingEnvironment) x | + | x | + | | +==========================[ATTESTATION PHASE]=========================== + | | + generateClaims(attestingEnvironment) | | => claims, eventLogs | | | collectClaims(claims, claimSelection) | @@ -449,29 +504,39 @@ The background-check model is so named because of the resemblance of how employe generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | | - | evidence, eventLogs -------------------------------------> | + | evidence, eventLogs -------------------------------------->| + | | +==========================[VERIFICATION PHASE]========================== | | - | appraiseEvidence(evidence, eventLogs, refValues) + | appraiseEvidence(evidence, + | eventLogs, + | refValues) | attestationResult <= | ~ ~ | | -**********[loop]******************************************************** -* | | * -* generateClaims(attestingEnvironment) | * -* | => claimsDelta, eventLogsDelta | * -* | | * -* collectClaims(claimsDelta, claimSelection) | * -* | => collectedClaimsDelta | * -* | | * -* generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * -* | => evidence | * -* | | * -* | evidence, eventLogsDelta --------------------------------> | * -* | | * -* | appraiseEvidence(evidence, eventLogsDelta, refValues) * -* | attestationResult <= | * -* | | * -************************************************************************ + .--------[loop]------------------------------------------------------. +| | | | +| =====================[DELTA ATTESTATION PHASE]====================== | +| | | | +| generateClaims(attestingEnvironment) | | +| | => claimsDelta, eventLogsDelta | | +| | | | +| collectClaims(claimsDelta, claimSelection) | | +| | => collectedClaimsDelta | | +| | | | +| generateEvidence(handle, authSecIDs, collectedClaimsDelta) | | +| | => evidence | | +| | | | +| | evidence, eventLogsDelta --------------------------------->| | +| | | | +| =====================[DELTA VERIFICATION PHASE]===================== | +| | | | +| | appraiseEvidence(evidence, | +| | eventLogsDelta, | +| | refValues) | +| | attestationResult <= | | +| | | | + '--------------------------------------------------------------------' | | ~~~~ @@ -481,7 +546,8 @@ Initiation by the Verifier always results in solicited pushes to the Verifier. The Uni-Directional model uses the same information elements as the Challenge/Response model. In the sequence diagram above, the Attester initiates the conveyance of Evidence (comparable with a RESTful POST operation or the emission of a beacon). -While a request of Evidence from the Verifier would result in a sequence diagram more similar to the Challenge/Response model (comparable with a RESTful GET operation). The specific manner how Handles are created and used always remains as the distinguishing quality of this model. +While a request of Evidence from the Verifier would result in a sequence diagram more similar to the Challenge/Response model (comparable with a RESTful GET operation). +The specific manner how Handles are created and used always remains as the distinguishing quality of this model. In the Uni-Directional model, handles are composed of cryptographically signed trusted timestamps as shown in {{-TUDA}}, potentially including other qualifying data. The Handles are created by an external 3rd entity -- the Handle Distributor -- which includes a trustworthy source of time, and takes on the role of a Time Stamping Authority (TSA, as initially defined in {{-TSA}}). @@ -497,71 +563,97 @@ Methods to detect excessive time drift that would mandate a fresh Handle to be r ## Streaming Remote Attestation -~~~~ +Streaming Remote Attestation serves as the foundational concept for both the observer pattern ({{ISIS}) and the publish-subscribe pattern ({{DesignPatterns}}). +It entails establishing subscription states to continuously verify the status of remote devices. +The observer pattern directly connects observers to subjects without a broker, while the publish-subscribe pattern involves a central broker for message distribution. +In the following, the streaming remote attestation without a broker (observer pattern) as well as with a broker (publish-subscribe pattern) are described. + +### Streaming Remote Attestation without a Broker + +~~~~ aasvg .----------. .----------. | Attester | | Verifier | -'----------' '----------' +'----+-----' '-----+----' + | | +=======================[HANDLE GENERATION PHASE]======================== + | | + | generateHandle() + | handle<= | + | | + |<------------ subscribe(handle, authSecIDs, claimSelection) | + | handle --------------------------------------------------->| + | | +==========================[ATTESTATION PHASE]=========================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | | | - | <----------- subscribe(handle, authSecIDs, claimSelection) | - | subscriptionResult --------------------------------------> | - | | collectClaims(claims, claimSelection) | | => collectedClaims | | | generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | | - | evidence, eventLogs -------------------------------------> | +==========================[VERIFICATION PHASE]========================== + | | + | handle, evidence, eventLogs ------------------------------>| | | - | appraiseEvidence(evidence, eventLogs, refValues) + | appraiseEvidence(evidence, + | eventLogs, + | refValues) | attestationResult <= | ~ ~ | | -**********[loop]******************************************************** -* | | * -* generateClaims(attestingEnvironment) | * -* | => claimsDelta, eventLogsDelta | * -* | | * -* collectClaims(claimsDelta, claimSelection) | * -* | => collectedClaimsDelta | * -* | | * -* generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * -* | => evidence | * -* | | * -* | evidence, eventLogsDelta --------------------------------> | * -* | | * -* | appraiseEvidence(evidence, eventLogsDelta, refValues) * -* | attestationResult <= | * -* | | * -************************************************************************ + .--------[loop]------------------------------------------------------. +| | | | +| =====================[DELTA ATTESTATION PHASE]====================== | +| | | | +| generateClaims(attestingEnvironment) | | +| | => claimsDelta, eventLogsDelta | | +| | | | +| collectClaims(claimsDelta, claimSelection) | | +| | => collectedClaimsDelta | | +| | | | +| generateEvidence(handle, authSecIDs, collectedClaimsDelta) | | +| | => evidence | | +| | | | +| =====================[DELTA VERIFICATION PHASE]===================== | +| | | | +| | evidence, eventLogsDelta --------------------------------->| | +| | | | +| | appraiseEvidence(evidence, | +| | eventLogsDelta, | +| | refValues) | +| | attestationResult <= | | +| | | | + '--------------------------------------------------------------------' | | ~~~~ -Streaming Remote Attestation procedures require the setup of subscription state. +The observer pattern is employed in scenarios where message delivery does not involve a central broker. +Instead, an observer directly subscribes to the observed resource through another entity. +Consequently, this other entity possesses direct knowledge of the observer and is responsible for maintaining the subscription state. Setting up subscription state between a Verifier and an Attester is conducted via a subscribe operation. The subscribe operation is used to convey required Handles for producing Evidence. Effectively, this allows for a series of Evidence to be pushed to a Verifier, similar to the Uni-Directional model. While a Handle Distributor is not required in this model, it is also limited to bi-lateral subscription relationships in which each Verifier has to create and provide its individual Handle. Handles provided by a specific subscribing Verifier MUST be used in Evidence generation for that specific Verifier. -The Streaming model uses the same information elements as the Challenge/Response and the Uni-Directional model. +The streaming model without a broker uses the same information elements as the Challenge/Response and the Uni-Directional model. Methods to detect excessive time drift that would mandate a refreshed Handle to be conveyed via another subscribe operation are out-of-scope of this document. - -## Publish-Subscribe Remote Attestation +### Streaming Remote Attestation with a Broker The publish-subscribe messaging pattern is widely used for communication in different areas. The strengths of the communication pattern include loose coupling and scalability. -Unlike the Streaming Remote Attestation interaction model, Attesters do not (need to) know the corresponding Verifiers of attestation Evidence. +Unlike the *Streaming Remote Attestation without a Broker* interaction model, Attesters do not (need to) know the corresponding Verifiers of attestation Evidence. Nor do Verifiers (need to) know consumers of their produced Attestation Results. With an increasing number of Attesters, Verifiers, and Relying Parties, the publish-subscribe pattern may reduce interdependencies and provide better scalability. -There exist several publish-subscribe solutions. +There exist several publish-subscribe technologies and solutions. In the IoT landscape, for example, the Message Queuing Telemetry Transport (MQTT) protocol is widely used ({{MQTT}}). For remote attestation, the TCG has published the Trusted Network Communications (TNC) specification, an open Network Admission Control (NAC) solution ({{TNC}}). TNC is based on a Metadata Access Point (MAC) server which implements the publish-subscribe pattern. +Further technologies and solutions include, among others, the Advanced Message Queuing Protocol (AMQP), Apache Kafka, Google Cloud Pub/Sub, RabbitMQ, and ZeroMQ. With publish-subscribe, clients typically *connect* to (or *register* with) a publish-subscribe server (PubSub server). Clients may *publish* data in the form of a *message* under a certain *topic*. @@ -576,219 +668,201 @@ There are different phases that both models go through: 3. Verification 4. Attestation Result Consumption -The models only differ in the handle generation phase. Attestation, verification, and attestation result consumption are identical from a protocol point of view. - +The models only differ in the handle generation phase. +Attestation, verification, and attestation result consumption are identical from a protocol point of view. -### Connection Establishment and Client ID +#### Connection Establishment and Client ID -~~~~ -.--------. .---------------. -| Client | | PubSub Server | -'--------' '---------------' +~~~~ aasvg + .--------. .---------------. + | Client | | PubSub Server | + '---+----' '-------+-------' | | - | connect(id=C?) --------------------------------------> | + connect(?id=C) ------------------------------------------->| | | - | addClient(id=C?) + | addClient(?id=C) | | - | <----------------------------------------- conAck(id?) | + |<-------------------------------------------------- conAck(?id) | | ~ ~ ~~~~ Depending on the PubSub server, clients connecting to it must provide their own (unique) client ID or are assigned a (unique) client ID by the PubSub server. -In the diagram above, the optional client ID arguments are marked with a trailing "?". -After the PubSub server receives a connection request, it adds the client to its internal management facilities with its (unique) ID. +In the diagram above, the optional client ID arguments are marked with a preceding "?". +After the PubSub server has received a connection request, it adds the client to its internal management facilities with its (unique) ID. In addition, clients may need to authenticate to the server and/or vice versa in a separate step. All of this is beyond the scope of this document. +In the following, the term "handle" is used instead of the (unique) client ID. -For reasons of readability, the connection step is omitted in the following diagrams as well as acknowledgement steps for subscribing and publishing. +For reasons of readability, the connection step is omitted in the following diagrams as well as acknowledgment steps for subscribe and publish operations. -### Handle Generation for Challenge/Response Remote Attestation over Publish-Subscribe +#### Handle Generation for Challenge/Response Remote Attestation over Publish-Subscribe -~~~~ +~~~~ aasvg .----------. .---------------. .----------. | Attester | | PubSub Server | | Verifier | -'----------' '---------------' '----------' - | | | | +'----+-----' '-------+-------' '-----+----' + | | | =======================[HANDLE GENERATION PHASE]======================== - | | | | - | sub(topic=AttReq) -----------> | | - | | <------ pub(topic=AttReq, | - | | handle) | - | <--------- notify(topic=AttReq | | - | handle) | | + | | | + sub(topic=AttReq) ---------------->| | + | |<------------ pub(topic=AttReq, + | | handle) + |<------------------- notify(topic=AttReq, handle) | + | | | ~ ~ ~ ~~~~ -The Challenge/Response Remote Attestation over Publish-Subscribe model uses the same information elements as the Challenge/Response Remote Attestation model. +The *Challenge/Response Remote Attestation over Publish-Subscribe* interaction model uses the same information elements as the *Challenge/Response Remote Attestation* interaction model. Handles are provided by a Verifier on a per-request basis. In the sequence diagram above, an Attester subscribes to the "AttReq" (= Attestation Request) topic on the PubSub server. The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server forwards to the Attester by notifying it. -### Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe +#### Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe -~~~~ -.----------. .-------------. .---------------. .----------. -| Attester | | Handle | | PubSub Server | | Verifier | -'----------' | Distributor | '---------------' '----------' - | '-------------' | | - | | | | +~~~~ aasvg +.----------. .-------------. .---------------. .----------. +| Attester | | Handle | | PubSub Server | | Verifier | +'----+-----' | Distributor | '-------+-------' '-----+----' + | '------+------' | | + | | | | =======================[HANDLE GENERATION PHASE]======================== - | | | | - | . | | - | sub(topic=handle) --------------> | <--- sub(topic=Handle) | - | . | | - | | | | + | | | | + | | | | + sub(topic=Handle) -------------------->| | + | | | | + | | |<--------- sub(topic=Handle) + | | | | + | | | | | generateHandle() | | - | | => handle | | - | | | | - | | pub(topic=Handle, | | - | | handle) -----> | | - | x | | + | | => handle | | + | | | | + | pub(topic=Handle, | | + | | handle) --------->| | + | x | | + | | | + |<--------------------- notify(topic=Handle, handle) | | | | - | <------------ notify(topic=Handle | notify(topic=Handle, | - | handle) | handle) ------> | + | notify(topic=Handle, handle) ------->| | | | ~ ~ ~ ~~~~ -The Uni-Directional Remote Attestation over Publish-Subscribe model uses the same information elements as the Uni-Directional Remote Attestation model. +The *Uni-Directional Remote Attestation over Publish-Subscribe* model uses the same information elements as the Uni-Directional Remote Attestation model. Accordingly, Handles are created by a 3rd party, the Handle Distributor. -In the sequence diagram above, both an Attester and a Verifier subscribe to the "Handle" topic on the PubSub server. -When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards the Handle to them (handle generation phase). +In the sequence diagram above, both an Attester and a Verifier subscribe to the topic "Handle" on the PubSub server. +When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards ("notify") the Handle to them (handle generation phase). -### Attestation and Verification +#### Attestation and Verification -~~~~ +~~~~ aasvg ~ ~ ~ | | | .----------. .---------------. .----------. | Attester | | PubSub Server | | Verifier | -'----------' '---------------' '----------' +'----+-----' '-------+-------' '-----+----' | | | -* ========================[ATTESTATION PHASE]========================= * -* | | | * -* | | <---- sub(topic=AttEv) | * -* | | | * -**********[loop]******************************************************** -* | | | * -* generateClaims(attestingEnvironment) | | * -* | => claims, eventLogs | | * -* | | | * -* collectClaims(claims, claimSelection) | | * -* | => collectedClaims | | * -* | | | * -* generateEvidence(handle, authSecIDs, | | * -* | collectedClaims) | | * -* | => evidence | | * -* | | | * -* | pub(topic=AttEv, | | * -* | evidence, eventLogs) -------> | | * -* | | notify(topic=AttEv, | * -* | | evidence, | * -* | | eventLogs) ---> | * -* | | | * -* ========================[VERIFICATION PHASE]======================== * -* | | | * -* | | appraiseEvidence( * -* | | evidence, * -* | | eventLogs, * -* | | refValues) * -* | | attestationResult <= | * -* | | | * -************************************************************************ + | |<---------- sub(topic=AttEv) + | | | + .--------[loop]------------------------------------------------------. +| | | | | +| ========================[ATTESTATION PHASE]========================= | +| | | | | +| generateClaims(attestingEnvironment) | | | +| | => claims, eventLogs | | | +| | | | | +| collectClaims(claims, claimSelection) | | | +| | => collectedClaims | | | +| | | | | +| generateEvidence(handle, authSecIDs, | | | +| | collectedClaims) | | | +| | => evidence | | | +| | | | | +| pub(topic=AttEv, | | | +| | evidence, eventLogs) ----------->| | | +| | | | | +| | notify(topic=AttEv, | | +| | | evidence, | | +| | | eventLogs) ---------->| | +| | | | | +| ========================[VERIFICATION PHASE]======================== | +| | | | | +| | | appraiseEvidence( | +| | | evidence, | +| | | eventLogs, | +| | | refValues) | +| | | attestationResult <= | | +| | | | | +| ===============[ATTESTATION RESULT CONSUMPTION PHASE]=============== | +| | | | | +| | |<--------- pub(topic=AttRes, | +| | | attestationResult) | +| | | | | + '--------------------------------------------------------------------' | | | ~ ~ ~ ~~~~ -Exactly as in the Challenge/Response and Uni-Directional models, there is an attestation-verification loop in which the Attester generates Evidence and the Verifier appraises it. +Exactly as in the Challenge/Response and Uni-Directional interaction models, there is an attestation-verification loop in which the Attester generates Evidence and the Verifier appraises it. In the Publish-Subscribe model above, the Attester publishes Evidence to the topic "AttEv" (= Attestation Evidence) on the PubSub server, to which a Verifier subscribed before. The PubSub server notifies Verifiers, accordingly, by forwarding the attestation Evidence. Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas' for Evidence and Event Logs. Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server. -### Attestation Result Consumption +#### Attestation Result Consumption -~~~~ +~~~~ aasvg ~ ~ ~ ~ | | | | -.----------. .---------------. .---------------. .----------. +.----+-----. .--+------------. .-------+-------. .-----+----. | Attester | | Relying Party | | PubSub Server | | Verifier | -'----------' '---------------' '---------------' '----------' +'----+-----' '--+------------' '-------+-------' '-----+----' | | | | =================[ATTESTATION RESULT CONSUMPTION PHASE]================= | | | | - | | sub(topic=AttRes) | | - | | handle) ---------> | | + | sub(topic=AttRes) | | + | handle) ----------------->| | | | | | -**********[loop]******************************************************** -* | | | | * -* | | | <-------- pub(topic=AttRes, * -* | | | attestationResult) * -* | | notify(topic=AttRes | | * -* | | <-- attestationResult) | | * -* | | | | * -************************************************************************ + .--------[loop]------------------------------------------------------. +| | | | | | +| | | |<--------- pub(topic=AttRes, | +| | | | attestationResult) | +| | | | | | +| | |<----------------- notify(topic=AttRes | | +| | | | attestationResult) | | +| | | | | | + '--------------------------------------------------------------------' | | | | ~ ~ ~ ~ ~~~~ -Attestation Result consumption by Relying Parties is the same for both publish-subscribe models, Challenge/Response Remote Attestation over Publish-Subscribe and Uni-Directional Remote Attestation over Publish-Subscribe. -Relying Parties subscribe to topic "AttRes" (= Attestation Result) on the PubSub server. -The PubSub server forwards Attestation Results to the Relying Parties as soon as they are published to topic "AttRes". +Attestation Result consumption by Relying Parties is the same for both publish-subscribe models,*Challenge/Response Remote Attestation over Publish-Subscribe* and *Uni-Directional Remote Attestation over Publish-Subscribe*. +Relying Parties subscribe to topic `AttRes` (= Attestation Result) on the PubSub server. +The PubSub server forwards Attestation Results to the Relying Parties as soon as they are published to topic `AttRes`. -### Publish/Subscribe Topics +#### Publish/Subscribe Topics Many publish-subscribe models provide hierarchical organization of topics. -This way, subscribers can subscribe to either all attestations (topic "AttRes"), or, for example, to topic "AttRes/DbServers/Germany" to receive only attestations from database servers in Germany. +This way, subscribers can subscribe to either all attestations (topic `AttRes`), or, for example, to topic `AttRes/DbServers/Germany` to receive only attestations from database servers in Germany. Further, it may be required to distinguish between uni-directional and challenge-response attestation evidence. -For this purpose a wildcard subscription may be useful, for example "AttRes/DbServers/Germany/\*\*/uni" (to receive only uni-directional attestation evidence) or "AttRes/DbServers/Germany/\*\*/cr" (to receive only challenge-response attestation evidence). +For this purpose a wildcard subscription may be useful, for example `AttRes/DbServers/Germany/\*\*/uni` (to receive only uni-directional attestation evidence) or `AttRes/DbServers/Germany/\*\*/cr` (to receive only challenge-response attestation Evidence). -### Security Considerations +#### Security Considerations Attestation Evidence is digitally signed and, thus, authenticated and integral. A man-in-the-middle attack that tampers with the Evidence undetected is practically infeasible. -The PubSub server is used for (temporarily) storing and forwarding attestation Evidence to interested clients, i. e. Verifiers. +The PubSub server is used for (temporarily) storing and forwarding attestation Evidence to interested clients, i. e., Verifiers. Further, Attestation Results published on the SubSub server by Verifiers are digitally signed, too, and cannot be altered undetected. -### Reference Implementation(s) +#### Reference Implementation(s) -* On the practical Application of a Trusted Information Agent -- Michael Eckel. *Master's Thesis*. (September 30, 2014) -- \ +The following reference implementations exist: + +* On the practical Application of a Trusted Information Agent -- Michael Eckel. *Master's Thesis*. (September 30, 2014) -- Realize TPM-based remote attestation on the TNC publish-subscribe server called Metadata Access Point (MAP). Uses TPM 1.2, Java, jTSS Wrapper, and TCG Trusted Network Communications (TNC) on Android platforms. - -* TODO - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Additional Application-Specific Requirements @@ -824,7 +898,7 @@ It is up to the individual working groups to use this information as they see fi ## Implementer -The open-source implementation was initiated and is maintained by the Fraunhofer Institute for Secure Information Technology - SIT. +The open-source implementation was initiated and is maintained by the Fraunhofer Institute for Secure Information Technology SIT. ## Implementation Name @@ -832,7 +906,7 @@ The open-source implementation is named "CHAllenge-Response based Remote Attesta ## Implementation URL -The open-source implementation project resource can be located via: https://github.com/Fraunhofer-SIT/charra +The open-source implementation project resource can be located via: ## Maturity @@ -840,7 +914,7 @@ The code's level of maturity is considered to be "prototype". ## Coverage and Version Compatibility -The current version ('1bcb469') implements a challenge/response interaction model and is aligned with the exemplary specification of the CoAP FETCH bodies defined in Section {{coap-fetch-bodies}} of this document. +The current version ('6194b3b') implements a challenge/response interaction model and is aligned with the exemplary specification of the CoAP FETCH bodies defined in Section {{coap-fetch-bodies}} of this document. ## License @@ -848,7 +922,8 @@ The CHARRA project and all corresponding code and data maintained on GitHub are ## Implementation Dependencies -The implementation requires the use of the official Trusted Computing Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted Platform Module (TPM) 2.0. The corresponding code and data is also maintained on GitHub and the project resources can be located via: https://github.com/tpm2-software/tpm2-tss/ +The implementation requires the use of the official Trusted Computing Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted Platform Module (TPM) 2.0. +The corresponding project resources (code and data) for Linux-based operating systems are maintained on GitHub at . The implementation uses the Constrained Application Protocol {{-COAP}} (http://coap.technology/) and the Concise Binary Object Representation {{-CBOR}} (https://cbor.io/). @@ -858,9 +933,13 @@ Michael Eckel (michael.eckel@sit.fraunhofer.de) {: #security-and-privacy-considerations} # Security and Privacy Considerations -In a remote attestation procedure the Verifier or the Attester MAY want to cryptographically blind several attributes. For instance, information can be part of the signature after applying a one-way function (e. g. a hash function). -There is also a possibility to scramble the Nonce or Attester Identity with other information that is known to both the Verifier and Attester. A prominent example is the IP address of the Attester that usually is known by the Attester itself as well as the Verifier. This extra information can be used to scramble the Nonce in order to counter certain types of relay attacks. +In a remote attestation procedure the Verifier or the Attester MAY want to cryptographically blind several attributes. +For instance, information can be part of the signature after applying a one-way function (e. g., a hash function). + +There is also a possibility to scramble the Nonce or Attester Identity with other information that is known to both the Verifier and Attester. +A prominent example is the IP address of the Attester that usually is known by the Attester itself as well as the Verifier. +This extra information can be used to scramble the Nonce in order to counter certain types of relay attacks. # Acknowledgments @@ -871,41 +950,33 @@ Olaf Bergmann, Michael Richardson, and Ned Smith {: #coap-fetch-bodies} # CDDL Specification for a simple CoAP Challenge/Response Interaction -The following CDDL specification is an exemplary proof-of-concept to illustrate a potential implementation of the Challenge/Response Interaction Model. The transfer protocol used is CoAP using the FETCH operation. The actual resource operated on can be empty. Both the Challenge Message and the Response Message are exchanged via the FETCH operation and corresponding FETCH Request and FETCH Response body. - -In this example, evidence is created via the root-of-trust for reporting primitive operation "quote" that is provided by a TPM 2.0. - -~~~~ CDDL -RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body - -CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed - nonce: bytes, - pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID - [ + pcr: uint .size 1 ], - ] - ], - ] - -CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, - tpm-native-signature: bytes, - ? ak-cert: bytes, ; attestation key certificate - ] - -TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME - TPMS_CLOCK_INFO, - firmwareVersion: uint .size 8 - quote-responses: [ * [ pcr: uint .size 1, - + [ pcr-value: bytes, - ? hash-alg-id: uint .size 2, - ], - ], - ? pcr-digest: bytes, - ], - ] - -TPMS_CLOCK_INFO = [ clock: uint .size 8, - resetCounter: uint .size 4, - restartCounter: uint .size 4, - save: bool, - ] +The following CDDL specification is an exemplary proof-of-concept to illustrate a potential implementation of the Challenge/Response Interaction Model. +The used communication protocol is CoAP. +Both the request message and the response message are exchanged via the FETCH operation and corresponding FETCH request and FETCH response body. + +In this example, Evidence is created via the root-of-trust for reporting primitive operation "quote" that is provided by a TPM 2.0. + +~~~~ cddl +charra-bodies = charra-attestation-request / charra-attestation-response + +charra-attestation-request = [ + hello: bool, ; if true, the TPM 2.0 AK Cert shall be conveyed + key-id: bytes, ; the key ID to use for signing + nonce: bytes, ; a (random) nonce, providing freshness and/or recentness + pcr-selections: [ * pcr-selection ] +] + +pcr-selection = [ + tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID + pcrs: [ + pcr: uint .size 2 + ] +] + +charra-attestation-response = [ + attestation-data: bytes, ; TPMS_ATTEST.quoted + tpm2-signature: bytes, + ? ak-cert: bytes, ; TPM2 attestation key certificate (AK Cert) +] ~~~~ + From 6fd36ab931465c87b67d5f2eca487136c34bb88a Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Sun, 10 Sep 2023 13:26:21 +0200 Subject: [PATCH 05/11] Minor adaptions. --- ...-ietf-rats-reference-interaction-models.md | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 226fae8..2b52a01 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -77,7 +77,7 @@ informative: name: Robert Rudnicki seriesinfo: The Faulkner Journal: 25.2 - DOI: "10.1353/fau.2010.0002" + DOI: 10.1353/fau.2010.0002 date: 2010 TNC: title: TCG Trusted Network Communications TNC Architecture for Interoperability @@ -419,14 +419,14 @@ then gives back an Attestation Result to the Attester, which simply caches it. I | | | | evidence, attestationResult -------------------------->| | | | -=================[ATTESTATION RESULT CONSUMPTION PHASE]================= +=================[ATTESTATION RESULT PROCESSING PHASE]================= | | | - | | appraiseResult(evidence, - | | attestationResult) + | | appraiseResult(policy, + | | attestationResult) | | | ~~~~ -#### Background Check Model +#### Background-Check Model The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party. @@ -471,9 +471,9 @@ The Relying Party then checks the Attestation Result against its own appraisal p | |<---------- (evidence, | | | attestationResult) | | | | -=================[ATTESTATION RESULT CONSUMPTION PHASE]================= +=================[ATTESTATION RESULT PROCESSING PHASE]================= | | | - | appraiseResult(evidence, | + | appraiseResult(policy, | | attestationResult) | | | | ~~~~ @@ -666,10 +666,10 @@ There are different phases that both models go through: 1. Handle Generation 2. Attestation 3. Verification -4. Attestation Result Consumption +4. Attestation Result Processing/Consumption The models only differ in the handle generation phase. -Attestation, verification, and attestation result consumption are identical from a protocol point of view. +Attestation, verification, and attestation result processing/consumption are identical from a protocol point of view. #### Connection Establishment and Client ID @@ -795,7 +795,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | | | refValues) | | | | attestationResult <= | | | | | | | -| ===============[ATTESTATION RESULT CONSUMPTION PHASE]=============== | +| ===============[ATTESTATION RESULT PROCESSING PHASE]=============== | | | | | | | | |<--------- pub(topic=AttRes, | | | | attestationResult) | @@ -811,7 +811,7 @@ The PubSub server notifies Verifiers, accordingly, by forwarding the attestation Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas' for Evidence and Event Logs. Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server. -#### Attestation Result Consumption +#### Attestation Result Processing/Consumption ~~~~ aasvg ~ ~ ~ ~ @@ -820,7 +820,7 @@ Verifiers appraise the Evidence and publish the Attestation Result to topic "Att | Attester | | Relying Party | | PubSub Server | | Verifier | '----+-----' '--+------------' '-------+-------' '-----+----' | | | | -=================[ATTESTATION RESULT CONSUMPTION PHASE]================= +=================[ATTESTATION RESULT PROCESSING PHASE]================= | | | | | sub(topic=AttRes) | | | handle) ----------------->| | @@ -838,7 +838,7 @@ Verifiers appraise the Evidence and publish the Attestation Result to topic "Att ~ ~ ~ ~ ~~~~ -Attestation Result consumption by Relying Parties is the same for both publish-subscribe models,*Challenge/Response Remote Attestation over Publish-Subscribe* and *Uni-Directional Remote Attestation over Publish-Subscribe*. +Attestation Result processing/consumption by Relying Parties is the same for both publish-subscribe models,*Challenge/Response Remote Attestation over Publish-Subscribe* and *Uni-Directional Remote Attestation over Publish-Subscribe*. Relying Parties subscribe to topic `AttRes` (= Attestation Result) on the PubSub server. The PubSub server forwards Attestation Results to the Relying Parties as soon as they are published to topic `AttRes`. @@ -906,7 +906,7 @@ The open-source implementation is named "CHAllenge-Response based Remote Attesta ## Implementation URL -The open-source implementation project resource can be located via: +The open-source implementation project resource can be located via: ## Maturity From e7ab1d170f136a492f5ab0108ccfcc08990946df Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Sun, 10 Sep 2023 13:48:42 +0200 Subject: [PATCH 06/11] Fixed diagrams (minor alignment issues). --- draft-ietf-rats-reference-interaction-models.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 2b52a01..9c23d6e 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -419,7 +419,7 @@ then gives back an Attestation Result to the Attester, which simply caches it. I | | | | evidence, attestationResult -------------------------->| | | | -=================[ATTESTATION RESULT PROCESSING PHASE]================= +=================[ATTESTATION RESULT PROCESSING PHASE]================== | | | | | appraiseResult(policy, | | attestationResult) @@ -471,7 +471,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | |<---------- (evidence, | | | attestationResult) | | | | -=================[ATTESTATION RESULT PROCESSING PHASE]================= +=================[ATTESTATION RESULT PROCESSING PHASE]================== | | | | appraiseResult(policy, | | attestationResult) | @@ -795,7 +795,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | | | refValues) | | | | attestationResult <= | | | | | | | -| ===============[ATTESTATION RESULT PROCESSING PHASE]=============== | +| ===============[ATTESTATION RESULT PROCESSING PHASE]================ | | | | | | | | |<--------- pub(topic=AttRes, | | | | attestationResult) | @@ -820,7 +820,7 @@ Verifiers appraise the Evidence and publish the Attestation Result to topic "Att | Attester | | Relying Party | | PubSub Server | | Verifier | '----+-----' '--+------------' '-------+-------' '-----+----' | | | | -=================[ATTESTATION RESULT PROCESSING PHASE]================= +=================[ATTESTATION RESULT PROCESSING PHASE]================== | | | | | sub(topic=AttRes) | | | handle) ----------------->| | From 0c730e22c463c46ab01bc61276cdc8e7f6304742 Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Sun, 10 Sep 2023 13:53:38 +0200 Subject: [PATCH 07/11] fixup! Fixed diagrams. Signed-off-by: Michael Eckel --- draft-ietf-rats-reference-interaction-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 9c23d6e..9d0c50a 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -760,7 +760,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top ~~~~ aasvg ~ ~ ~ | | | -.----------. .---------------. .----------. +.----+-----. .-------+-------. .-----+----. | Attester | | PubSub Server | | Verifier | '----+-----' '-------+-------' '-----+----' | | | From 3b8c229cbec008b6f039b643c728e19e959eb01d Mon Sep 17 00:00:00 2001 From: Michael Eckel Date: Sun, 10 Sep 2023 14:04:19 +0200 Subject: [PATCH 08/11] Fixed diagrams again. Signed-off-by: Michael Eckel --- ...-ietf-rats-reference-interaction-models.md | 50 +++++++++---------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 9d0c50a..48ce6c8 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -397,8 +397,8 @@ then gives back an Attestation Result to the Attester, which simply caches it. I generateClaims(attestingEnvironment) | | | => claims, eventLogs | | | | | - |<-------- requestAttestation(handle, | | - | authSecIDs, claimSelection) | | + |<--------------------- requestAttestation(handle, | + | authSecIDs, claimSelection) | | | | collectClaims(claims, claimSelection) | | | => collectedClaims | | @@ -407,17 +407,17 @@ then gives back an Attestation Result to the Attester, which simply caches it. I authSecIDs, collectedClaims) | | | => evidence | | | | | - | evidence, eventLogs ---------------->| | + | {evidence, eventLogs} -------------->| | | | | ==========================[VERIFICATION PHASE]========================== | | | - | appraiseEvidence(evidence, | - | eventLogs, refValues) | + | appraiseEvidence(evidence, | + | eventLogs, refValues) | | attestationResult <= | | | | | |<------------------ attestationResult | | | | | - | evidence, attestationResult -------------------------->| + | {evidence, attestationResult} ------------------------>| | | | =================[ATTESTATION RESULT PROCESSING PHASE]================== | | | @@ -443,11 +443,11 @@ The Relying Party then checks the Attestation Result against its own appraisal p | | | ==========================[ATTESTATION PHASE]=========================== | | | - generateClaims(attestingEnvironment) | | - | => claims, eventLogs | | + |<--------------------- requestAttestation(handle, | + | authSecIDs, claimSelection) | | | | - |<------ requestAttestation(handle, | | - | authSecIDs, claimSelection) | | + generateClaims(attestingEnvironment) | | + | => {claims, eventLogs} | | | | | collectClaims(claims, | | claimSelection) | | @@ -457,19 +457,19 @@ The Relying Party then checks the Attestation Result against its own appraisal p authSecIDs, collectedClaims) | | | => evidence | | | | | - | evidence, eventLogs ------------->| | + | {evidence, eventLogs} ------------->| | | | | ==========================[VERIFICATION PHASE]========================== | | | - | | (handle, evidence, | - | | eventLogs) --------->| + | | {handle, evidence, | + | | eventLogs} --------->| | | | | | appraiseEvidence(evidence, | | eventLogs, refValues) | | attestationResult <= | | | | - | |<---------- (evidence, | - | | attestationResult) | + | |<---------- {evidence, | + | | attestationResult} | | | | =================[ATTESTATION RESULT PROCESSING PHASE]================== | | | @@ -489,7 +489,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | generateHandle() | | | => handle | | | | - |<------------------------------ handle | handle ----------->| + |<---------------------------- {handle} | {handle} --------->| | | | | x | | | @@ -504,7 +504,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | | - | evidence, eventLogs -------------------------------------->| + | {evidence, eventLogs} ------------------------------------>| | | ==========================[VERIFICATION PHASE]========================== | | @@ -527,7 +527,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | generateEvidence(handle, authSecIDs, collectedClaimsDelta) | | | | => evidence | | | | | | -| | evidence, eventLogsDelta --------------------------------->| | +| | {evidence, eventLogsDelta} ------------------------------->| | | | | | | =====================[DELTA VERIFICATION PHASE]===================== | | | | | @@ -581,7 +581,7 @@ In the following, the streaming remote attestation without a broker (observer pa | handle<= | | | |<------------ subscribe(handle, authSecIDs, claimSelection) | - | handle --------------------------------------------------->| + | {handle} ------------------------------------------------->| | | ==========================[ATTESTATION PHASE]=========================== | | @@ -596,7 +596,7 @@ In the following, the streaming remote attestation without a broker (observer pa | | ==========================[VERIFICATION PHASE]========================== | | - | handle, evidence, eventLogs ------------------------------>| + | {handle, evidence, eventLogs} ---------------------------->| | | | appraiseEvidence(evidence, | eventLogs, @@ -619,7 +619,7 @@ In the following, the streaming remote attestation without a broker (observer pa | | | | | =====================[DELTA VERIFICATION PHASE]===================== | | | | | -| | evidence, eventLogsDelta --------------------------------->| | +| | {evidence, eventLogsDelta} ------------------------------->| | | | | | | | appraiseEvidence(evidence, | | | eventLogsDelta, | @@ -731,7 +731,7 @@ The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server f =======================[HANDLE GENERATION PHASE]======================== | | | | | | | | - sub(topic=Handle) -------------------->| | + sub(topic=Handle) ------------------->| | | | | | | | |<--------- sub(topic=Handle) | | | | @@ -739,7 +739,7 @@ The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server f | generateHandle() | | | | => handle | | | | | | - | pub(topic=Handle, | | + | pub(topic=Handle, | | | | handle) --------->| | | x | | | | | @@ -780,8 +780,8 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | | collectedClaims) | | | | | => evidence | | | | | | | | -| pub(topic=AttEv, | | | -| | evidence, eventLogs) ----------->| | | +| pub(topic=AttEv, | | | +| | evidence, eventLogs) ------------>| | | | | | | | | | notify(topic=AttEv, | | | | | evidence, | | From a66817fe2ec85c89586e510cc6d57d82bb133909 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sun, 10 Sep 2023 20:47:35 +0200 Subject: [PATCH 09/11] 1st hotfix on terminology --- ...-ietf-rats-reference-interaction-models.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index 48ce6c8..fe092d2 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -325,7 +325,7 @@ The way these handles are processed is the most prominent difference between the | Attester | | Verifier | '----+-----' '-----+----' | | -==========================[ATTESTATION PHASE]=========================== +=================[Evidence Generation and Conveyance]=================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | @@ -340,7 +340,7 @@ The way these handles are processed is the most prominent difference between the | | | evidence, eventLogs -------------------------------------->| | | -==========================[VERIFICATION PHASE]========================== +==========================[Evidence Appraisal]========================== | | | appraiseEvidence(evidence, eventLogs, refValues) @@ -392,7 +392,7 @@ then gives back an Attestation Result to the Attester, which simply caches it. I | Attester | | Verifier | | Relying Party | '----+-----' '-----+----' '-------+-------' | | | -==========================[ATTESTATION PHASE]=========================== +=================[Evidence Generation and Conveyance]=================== | | | generateClaims(attestingEnvironment) | | | => claims, eventLogs | | @@ -409,7 +409,7 @@ then gives back an Attestation Result to the Attester, which simply caches it. I | | | | {evidence, eventLogs} -------------->| | | | | -==========================[VERIFICATION PHASE]========================== +==========================[Evidence Appraisal]========================== | | | | appraiseEvidence(evidence, | | eventLogs, refValues) | @@ -419,7 +419,7 @@ then gives back an Attestation Result to the Attester, which simply caches it. I | | | | {evidence, attestationResult} ------------------------>| | | | -=================[ATTESTATION RESULT PROCESSING PHASE]================== +====================[Attestation Result Generation]===================== | | | | | appraiseResult(policy, | | attestationResult) @@ -441,7 +441,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | Attester | | Relying Party | | Verifier | '----+-----' '-------+-------' '-----+----' | | | -==========================[ATTESTATION PHASE]=========================== +=================[Evidence Generation and Conveyance]=================== | | | |<--------------------- requestAttestation(handle, | | authSecIDs, claimSelection) | @@ -457,9 +457,9 @@ The Relying Party then checks the Attestation Result against its own appraisal p authSecIDs, collectedClaims) | | | => evidence | | | | | - | {evidence, eventLogs} ------------->| | + | {evidence, eventLogs} ----------->| | | | | -==========================[VERIFICATION PHASE]========================== +==========================[Evidence Appraisal]========================== | | | | | {handle, evidence, | | | eventLogs} --------->| @@ -471,7 +471,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | |<---------- {evidence, | | | attestationResult} | | | | -=================[ATTESTATION RESULT PROCESSING PHASE]================== +====================[Attestation Result Generation]===================== | | | | appraiseResult(policy, | | attestationResult) | @@ -485,7 +485,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | Attester | | Handle Distributor | | Verifier | '----+-----' '---------+----------' '-----+----' | | | -=======================[HANDLE GENERATION PHASE]======================== +==========================[Handle Generation]=========================== | generateHandle() | | | => handle | | | | @@ -493,7 +493,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | | | | x | | | -==========================[ATTESTATION PHASE]=========================== +=================[Evidence Generation and Conveyance]=================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | @@ -506,7 +506,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | | | {evidence, eventLogs} ------------------------------------>| | | -==========================[VERIFICATION PHASE]========================== +==========================[Evidence Appraisal]========================== | | | appraiseEvidence(evidence, | eventLogs, @@ -516,7 +516,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | | .--------[loop]------------------------------------------------------. | | | | -| =====================[DELTA ATTESTATION PHASE]====================== | +| =============[Delta Evidence Generation and Conveyance]============= | | | | | | generateClaims(attestingEnvironment) | | | | => claimsDelta, eventLogsDelta | | @@ -529,7 +529,7 @@ The Relying Party then checks the Attestation Result against its own appraisal p | | | | | | {evidence, eventLogsDelta} ------------------------------->| | | | | | -| =====================[DELTA VERIFICATION PHASE]===================== | +| =====================[Delta Evidence Appraisal]===================== | | | | | | | appraiseEvidence(evidence, | | | eventLogsDelta, | @@ -575,7 +575,7 @@ In the following, the streaming remote attestation without a broker (observer pa | Attester | | Verifier | '----+-----' '-----+----' | | -=======================[HANDLE GENERATION PHASE]======================== +==========================[Handle Generation]=========================== | | | generateHandle() | handle<= | @@ -583,7 +583,7 @@ In the following, the streaming remote attestation without a broker (observer pa |<------------ subscribe(handle, authSecIDs, claimSelection) | | {handle} ------------------------------------------------->| | | -==========================[ATTESTATION PHASE]=========================== +=================[Evidence Generation and Conveyance]=================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | @@ -594,7 +594,7 @@ In the following, the streaming remote attestation without a broker (observer pa generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | | -==========================[VERIFICATION PHASE]========================== +==========================[Evidence Appraisal]========================== | | | {handle, evidence, eventLogs} ---------------------------->| | | @@ -606,7 +606,7 @@ In the following, the streaming remote attestation without a broker (observer pa | | .--------[loop]------------------------------------------------------. | | | | -| =====================[DELTA ATTESTATION PHASE]====================== | +| =============[Delta Evidence Generation and Conveyance]============= | | | | | | generateClaims(attestingEnvironment) | | | | => claimsDelta, eventLogsDelta | | @@ -617,7 +617,7 @@ In the following, the streaming remote attestation without a broker (observer pa | generateEvidence(handle, authSecIDs, collectedClaimsDelta) | | | | => evidence | | | | | | -| =====================[DELTA VERIFICATION PHASE]===================== | +| =====================[Delta Evidence Appraisal]===================== | | | | | | | {evidence, eventLogsDelta} ------------------------------->| | | | | | @@ -705,7 +705,7 @@ For reasons of readability, the connection step is omitted in the following diag | Attester | | PubSub Server | | Verifier | '----+-----' '-------+-------' '-----+----' | | | -=======================[HANDLE GENERATION PHASE]======================== +==========================[Handle Generation]=========================== | | | sub(topic=AttReq) ---------------->| | | |<------------ pub(topic=AttReq, @@ -728,7 +728,7 @@ The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server f '----+-----' | Distributor | '-------+-------' '-----+----' | '------+------' | | | | | | -=======================[HANDLE GENERATION PHASE]======================== +==========================[Handle Generation]=========================== | | | | | | | | sub(topic=Handle) ------------------->| | @@ -755,7 +755,7 @@ Accordingly, Handles are created by a 3rd party, the Handle Distributor. In the sequence diagram above, both an Attester and a Verifier subscribe to the topic "Handle" on the PubSub server. When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards ("notify") the Handle to them (handle generation phase). -#### Attestation and Verification +#### Evidence Generation and Appraisal ~~~~ aasvg ~ ~ ~ @@ -768,7 +768,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | | | .--------[loop]------------------------------------------------------. | | | | | -| ========================[ATTESTATION PHASE]========================= | +| ===============[Evidence Generation and Conveyance]================= | | | | | | | generateClaims(attestingEnvironment) | | | | | => claims, eventLogs | | | @@ -787,7 +787,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | | | evidence, | | | | | eventLogs) ---------->| | | | | | | -| ========================[VERIFICATION PHASE]======================== | +| ========================[Evidence Appraisal]======================== | | | | | | | | | appraiseEvidence( | | | | evidence, | @@ -795,7 +795,7 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top | | | refValues) | | | | attestationResult <= | | | | | | | -| ===============[ATTESTATION RESULT PROCESSING PHASE]================ | +| ==================[Attestation Result Generation]=================== | | | | | | | | |<--------- pub(topic=AttRes, | | | | attestationResult) | @@ -820,7 +820,7 @@ Verifiers appraise the Evidence and publish the Attestation Result to topic "Att | Attester | | Relying Party | | PubSub Server | | Verifier | '----+-----' '--+------------' '-------+-------' '-----+----' | | | | -=================[ATTESTATION RESULT PROCESSING PHASE]================== +====================[Attestation Result Generation]===================== | | | | | sub(topic=AttRes) | | | handle) ----------------->| | From e66e042c3b4de1188c71b0a95d77ad48c03d2023 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sun, 10 Sep 2023 20:48:19 +0200 Subject: [PATCH 10/11] fixing ISIS ref --- draft-ietf-rats-reference-interaction-models.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index fe092d2..ed4203d 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -563,7 +563,7 @@ Methods to detect excessive time drift that would mandate a fresh Handle to be r ## Streaming Remote Attestation -Streaming Remote Attestation serves as the foundational concept for both the observer pattern ({{ISIS}) and the publish-subscribe pattern ({{DesignPatterns}}). +Streaming Remote Attestation serves as the foundational concept for both the observer pattern ({{ISIS}} and the publish-subscribe pattern ({{DesignPatterns}}). It entails establishing subscription states to continuously verify the status of remote devices. The observer pattern directly connects observers to subjects without a broker, while the publish-subscribe pattern involves a central broker for message distribution. In the following, the streaming remote attestation without a broker (observer pattern) as well as with a broker (publish-subscribe pattern) are described. From bcfd21302b8d2b652253400fb95cd58c7dbd792f Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Sun, 10 Sep 2023 21:39:50 +0200 Subject: [PATCH 11/11] pruning proposal down for submission of -08 --- ...-ietf-rats-reference-interaction-models.md | 97 +++++-------------- 1 file changed, 23 insertions(+), 74 deletions(-) diff --git a/draft-ietf-rats-reference-interaction-models.md b/draft-ietf-rats-reference-interaction-models.md index ed4203d..873259f 100644 --- a/draft-ietf-rats-reference-interaction-models.md +++ b/draft-ietf-rats-reference-interaction-models.md @@ -342,8 +342,7 @@ The way these handles are processed is the most prominent difference between the | | ==========================[Evidence Appraisal]========================== | | - | appraiseEvidence(evidence, - eventLogs, refValues) + | appraiseEvidence(evidence, eventLogs, refValues) | attestationResult <= | | | ~~~~ @@ -563,10 +562,10 @@ Methods to detect excessive time drift that would mandate a fresh Handle to be r ## Streaming Remote Attestation -Streaming Remote Attestation serves as the foundational concept for both the observer pattern ({{ISIS}} and the publish-subscribe pattern ({{DesignPatterns}}). -It entails establishing subscription states to continuously verify the status of remote devices. +Streaming Remote Attestation serves as the foundational concept for both the observer pattern ({{ISIS}}) and the publish-subscribe pattern ({{DesignPatterns}}). +It entails establishing subscription states to enable continuous remote attestation. The observer pattern directly connects observers to subjects without a broker, while the publish-subscribe pattern involves a central broker for message distribution. -In the following, the streaming remote attestation without a broker (observer pattern) as well as with a broker (publish-subscribe pattern) are described. +In the following Subsections, streaming remote attestation without a broker (observer pattern) as well as with a broker (publish-subscribe pattern) are illustrated. ### Streaming Remote Attestation without a Broker @@ -631,31 +630,23 @@ In the following, the streaming remote attestation without a broker (observer pa ~~~~ The observer pattern is employed in scenarios where message delivery does not involve a central broker. -Instead, an observer directly subscribes to the observed resource through another entity. -Consequently, this other entity possesses direct knowledge of the observer and is responsible for maintaining the subscription state. +Instead, an observer directly subscribes to observed resources via a dedicated mechanism. +Consequently, these dedicated mechanisms contain information about the observer and are responsible for maintaining subscription state. Setting up subscription state between a Verifier and an Attester is conducted via a subscribe operation. -The subscribe operation is used to convey required Handles for producing Evidence. +The subscribe operation is used to convey Handles required for Evidence generation. Effectively, this allows for a series of Evidence to be pushed to a Verifier, similar to the Uni-Directional model. -While a Handle Distributor is not required in this model, it is also limited to bi-lateral subscription relationships in which each Verifier has to create and provide its individual Handle. +While a Handle Distributor is not mandatory in this model, the model is also limited to bi-lateral subscription relationships, in which each Verifier has to create and provide Handles individually. Handles provided by a specific subscribing Verifier MUST be used in Evidence generation for that specific Verifier. The streaming model without a broker uses the same information elements as the Challenge/Response and the Uni-Directional model. -Methods to detect excessive time drift that would mandate a refreshed Handle to be conveyed via another subscribe operation are out-of-scope of this document. +Methods to detect excessive time drift that would render Handles stale and mandate a fresh Handles to be conveyed via another subscribe operation are out-of-scope of this document. ### Streaming Remote Attestation with a Broker The publish-subscribe messaging pattern is widely used for communication in different areas. -The strengths of the communication pattern include loose coupling and scalability. -Unlike the *Streaming Remote Attestation without a Broker* interaction model, Attesters do not (need to) know the corresponding Verifiers of attestation Evidence. -Nor do Verifiers (need to) know consumers of their produced Attestation Results. -With an increasing number of Attesters, Verifiers, and Relying Parties, the publish-subscribe pattern may reduce interdependencies and provide better scalability. - -There exist several publish-subscribe technologies and solutions. -In the IoT landscape, for example, the Message Queuing Telemetry Transport (MQTT) protocol is widely used ({{MQTT}}). -For remote attestation, the TCG has published the Trusted Network Communications (TNC) specification, an open Network Admission Control (NAC) solution ({{TNC}}). -TNC is based on a Metadata Access Point (MAC) server which implements the publish-subscribe pattern. -Further technologies and solutions include, among others, the Advanced Message Queuing Protocol (AMQP), Apache Kafka, Google Cloud Pub/Sub, RabbitMQ, and ZeroMQ. - -With publish-subscribe, clients typically *connect* to (or *register* with) a publish-subscribe server (PubSub server). +Unlike the *Streaming Remote Attestation without a Broker* interaction model, Attesters do not (need to) be aware of corresponding Verifiers. +In scenarios with large numbers of Attesters and Verifiers, the publish-subscribe pattern may reduce interdependencies and improve scalability. + +With publish-subscribe, clients typically *connect* to (or *register* with) a publish-subscribe server (PubSub server or Broker). Clients may *publish* data in the form of a *message* under a certain *topic*. *Subscribers* to that topic get *notified* whenever a message arrives under a topic, and the appropriate message is forwarded to them. Depending on the particular publish-subscribe model and implementation, clients can be either publishers or subscribers or both. @@ -664,38 +655,12 @@ In the following sections, the interaction models *Challenge/Response Remote Att There are different phases that both models go through: 1. Handle Generation -2. Attestation -3. Verification -4. Attestation Result Processing/Consumption +2. Evidence Generation and Conveyance +3. Evidence Appraisal +4. Attestation Result Generation The models only differ in the handle generation phase. -Attestation, verification, and attestation result processing/consumption are identical from a protocol point of view. - -#### Connection Establishment and Client ID - -~~~~ aasvg - .--------. .---------------. - | Client | | PubSub Server | - '---+----' '-------+-------' - | | - connect(?id=C) ------------------------------------------->| - | | - | addClient(?id=C) - | | - |<-------------------------------------------------- conAck(?id) - | | - ~ ~ -~~~~ - -Depending on the PubSub server, clients connecting to it must provide their own (unique) client ID or are assigned a (unique) client ID by the PubSub server. -In the diagram above, the optional client ID arguments are marked with a preceding "?". -After the PubSub server has received a connection request, it adds the client to its internal management facilities with its (unique) ID. -In addition, clients may need to authenticate to the server and/or vice versa in a separate step. -All of this is beyond the scope of this document. -In the following, the term "handle" is used instead of the (unique) client ID. - -For reasons of readability, the connection step is omitted in the following diagrams as well as acknowledgment steps for subscribe and publish operations. - +From a remote attestations procedure's point of view Evidence Generation, Conveyance, and Appraisal, as well as Attestation Result Generation are identical in both models. #### Handle Generation for Challenge/Response Remote Attestation over Publish-Subscribe @@ -753,7 +718,7 @@ The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server f The *Uni-Directional Remote Attestation over Publish-Subscribe* model uses the same information elements as the Uni-Directional Remote Attestation model. Accordingly, Handles are created by a 3rd party, the Handle Distributor. In the sequence diagram above, both an Attester and a Verifier subscribe to the topic "Handle" on the PubSub server. -When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards ("notify") the Handle to them (handle generation phase). +When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards ("notify") the Handle to them during Handle Generation. #### Evidence Generation and Appraisal @@ -805,13 +770,13 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top ~ ~ ~ ~~~~ -Exactly as in the Challenge/Response and Uni-Directional interaction models, there is an attestation-verification loop in which the Attester generates Evidence and the Verifier appraises it. +Exactly as in the Challenge/Response and Uni-Directional interaction models, there is an Evidence Generation-Appraisal loop, in which the Attester generates Evidence and the Verifier appraises it. In the Publish-Subscribe model above, the Attester publishes Evidence to the topic "AttEv" (= Attestation Evidence) on the PubSub server, to which a Verifier subscribed before. The PubSub server notifies Verifiers, accordingly, by forwarding the attestation Evidence. Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas' for Evidence and Event Logs. Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server. -#### Attestation Result Processing/Consumption +#### Attestation Result Generation ~~~~ aasvg ~ ~ ~ ~ @@ -838,7 +803,7 @@ Verifiers appraise the Evidence and publish the Attestation Result to topic "Att ~ ~ ~ ~ ~~~~ -Attestation Result processing/consumption by Relying Parties is the same for both publish-subscribe models,*Challenge/Response Remote Attestation over Publish-Subscribe* and *Uni-Directional Remote Attestation over Publish-Subscribe*. +Attestation Result Generation is the same for both publish-subscribe models,*Challenge/Response Remote Attestation over Publish-Subscribe* and *Uni-Directional Remote Attestation over Publish-Subscribe*. Relying Parties subscribe to topic `AttRes` (= Attestation Result) on the PubSub server. The PubSub server forwards Attestation Results to the Relying Parties as soon as they are published to topic `AttRes`. @@ -847,23 +812,7 @@ The PubSub server forwards Attestation Results to the Relying Parties as soon as Many publish-subscribe models provide hierarchical organization of topics. This way, subscribers can subscribe to either all attestations (topic `AttRes`), or, for example, to topic `AttRes/DbServers/Germany` to receive only attestations from database servers in Germany. Further, it may be required to distinguish between uni-directional and challenge-response attestation evidence. -For this purpose a wildcard subscription may be useful, for example `AttRes/DbServers/Germany/\*\*/uni` (to receive only uni-directional attestation evidence) or `AttRes/DbServers/Germany/\*\*/cr` (to receive only challenge-response attestation Evidence). - -#### Security Considerations - -Attestation Evidence is digitally signed and, thus, authenticated and integral. -A man-in-the-middle attack that tampers with the Evidence undetected is practically infeasible. -The PubSub server is used for (temporarily) storing and forwarding attestation Evidence to interested clients, i. e., Verifiers. -Further, Attestation Results published on the SubSub server by Verifiers are digitally signed, too, and cannot be altered undetected. - -#### Reference Implementation(s) - -The following reference implementations exist: - -* On the practical Application of a Trusted Information Agent -- Michael Eckel. *Master's Thesis*. (September 30, 2014) -- - Realize TPM-based remote attestation on the TNC publish-subscribe server called Metadata Access Point (MAP). - Uses TPM 1.2, Java, jTSS Wrapper, and TCG Trusted Network Communications (TNC) on Android platforms. - + # Additional Application-Specific Requirements @@ -951,7 +900,7 @@ Olaf Bergmann, Michael Richardson, and Ned Smith # CDDL Specification for a simple CoAP Challenge/Response Interaction The following CDDL specification is an exemplary proof-of-concept to illustrate a potential implementation of the Challenge/Response Interaction Model. -The used communication protocol is CoAP. +The communication protocol used is CoAP. Both the request message and the response message are exchanged via the FETCH operation and corresponding FETCH request and FETCH response body. In this example, Evidence is created via the root-of-trust for reporting primitive operation "quote" that is provided by a TPM 2.0.