Merge pull request #63 from ietf-rats-wg/fix-58

Addressing Usama's review from issue #56

Author: henkbirkholz

draft-ietf-rats-reference-interaction-models.md

@@ -57,6 +57,8 @@ normative:
 
 informative:
   I-D.birkholz-rats-tuda: TUDA
+  I-D.tschofenig-rats-psa-token: psa-token
+  I-D.ietf-rats-uccs: uccs
   DAA:
     title: Direct Anonymous Attestation
     author:
@@ -134,16 +136,21 @@ Analogously, a general overview about the information elements typically used by
 Remote ATtestation procedureS (RATS, {{-RATS}}) are workflows composed of roles and interactions, in which Verifiers create Attestation Results about the trustworthiness of an Attester's system component characteristics.
 The Verifier's assessment in the form of Attestation Results is produced based on Endorsements, Reference Values, Attestation Policies, and Evidence -- trustable and tamper-evident Claims Sets about an Attester's system component characteristics -- generated by an Attester.
 The roles *Attester* and *Verifier*, as well as the Conceptual Messages *Evidence* and *Attestation Results* are concepts defined by the RATS Architecture {{-RATS}}.
-This document defines interaction models that can be used in specific RATS-related solution documents.
-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.
+This document illustrates three main interaction models that can be used in specific RATS-related solution documents:
+
+1. Challenge/Response Remote Attestation
+2. Uni-Directional Remote Attestation
+3. Streaming Remote Attestation
+
+As a basis to describe the interaction models is this document, the example of attestation Evidence conveyance is used to illustrate the usage scenarios.
+The reference models defined can also be applied to the conveyance of other Conceptual Messages in RATS.
 This document aims to:
 
 1. prevent inconsistencies in descriptions of interaction models in other documents, which may occur due to text cloning and evolution over time, and to
-
 2. highlight the exact delta/divergence between the core characteristics captured 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 models described in this document may be adapted to apply to the conveyance of other Conceptual Messages, such as Endorsements or Attestation Results, or supplemental messages, such as Epoch Markers {{-epoch-markers}} or stand-alone event logs.
+In summary, this document enables the specification and design of trustworthy and privacy-preserving conveyance methods for RATS Conceptual Messages; specifically attestation Evidence conveyed from an Attester to a Verifier.
+While the exact details for conveyance of other Conceptual Messages is out of scope, the models described in this document may be adapted to apply to the conveyance of other Conceptual Messages, such as Endorsements or Attestation Results, or supplemental messages, such as Epoch Markers {{-epoch-markers}} or stand-alone event logs.
 
 # Terminology
 
@@ -159,8 +166,9 @@ A PKIX Certificate is an X.509v3 certificate as specified by {{-X509}}.
 "Remote Attestation" is a common expression often associated or connoted with certain properties.
 In the context of this document, the term "Remote" does not necessarily refer to a remote entity in the scope of network topologies or the Internet.
 It rather refers to decoupled systems or entities that exchange the Conceptual Message type called Evidence {{-RATS}}.
-This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system components of the same Composite Device (a single RATS entity), or the Verifier and Relying Party roles are hosted by the same entity, for example in a cryptographic key Broker system.
-If an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity. Examples of such isolated environments include a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g., embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). It is useful but not necessary for readers of this document to be familiar with the Concept Data/Message flows as described in {{Section 3.1 of -RATS}} and the definition of Attestation in general as described in {{-RIV}}. For the example of Evidence generation, it is also useful to be familiar the fact that Attesting Environment are layered (see {{turtles}} and Figure 1 in {{Section 2.1 of -rats-endorsements}}) and that the initial Attesting Environment ("layer 0") requires Endorsement from a trusted third party.
+This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system components of the same Composite Device (a single RATS entity), or the Verifier and Relying Party roles are hosted by the same entity, for example in a cryptographic key Broker system (see {{Section 6 of -RATS}} for more details).
+If an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.
+Examples of such isolated environments include a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g., embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).
 
 # Scope and Intent
 
@@ -189,10 +197,10 @@ Similarly, deviations from the generic model described in this document can be i
 In order to ensure appropriate conveyance of Evidence, the following requirements MUST be fulfilled:
 
 Integrity:
-: Information provided by an Attester MUST NOT have been altered since it was created. This may be achieved through a digital signature over Attestation Evidencewhich may be symmetric, like an HMAC, or asymmetric, like ECDSA.
+: Information provided by an Attester MUST NOT have been altered since it was created. This may be achieved via symmetric cryptography, e.g., using COSE Mac0 as in PSA TF-M profile ({{Section 5.2 of -psa-token}}), or asymmetric, like ECDSA.
 
 Authentication:
-: The information provided by the Attester MUST be authentic. To do this, the Attester should authenticate itself to the Verifier. This can be done through implicit authentication using a digital signature over the Attestation Evidence, which does not require additional protocol steps, or by using a confidential channel with encryption.
+: The information provided by the Attester MUST be authentic. To do this, the Attester should authenticate itself to the Verifier. This can be done through implicit authentication using a digital signature over the Attestation Evidence, which does not require additional protocol steps, or by using a secure channel (see {{-uccs}}) including authentication.
 
 # Normative Prerequisites
 
@@ -220,15 +228,13 @@ Attestation Evidence Authenticity:
 
 : In order to provide a proof of authenticity, Attestation Evidence can be cryptographically associated with an identity document (e.g., a PKIX certificate or trusted key material, or a randomized DAA credential {{DAA}}), or could include a correct, unambiguous, and stable reference to an accessible identity document.
 
+: Authenticity includes the protection of Evidence in a tamper-evident manner (e.g., either by signatures or by protection mechanisms implemented at both ends of a Secure Channel; see Authentication above).
+
 Evidence Freshness:
 
 : Evidence MUST include an indicator about its freshness that can be understood by a Verifier (See also {{Section 10 of -RATS}}).
 This enables interaction models to support the conveyance of proofs of freshness in a way that is useful to Verifiers and their appraisal procedures.
 
-Evidence Protection:
-
-: Evidence MUST be a set of well-formatted and well-protected Claims that an Attester can create and convey to a Verifier in a tamper-evident manner.
-
 # Generic Information Elements
 
 This section describes the essential information elements for the interaction models described in {{interaction-models}}.
@@ -914,15 +920,11 @@ This document outlines three interaction models for remote attestation procedure
 While the subsequent sections address additional security and privacy considerations, the security considerations from {{Section 12 of -RATS}} must also be adhered to.
 Additionally, for TPM-based remote attestation, the security considerations outlined in {{Section 5 of -RIV}} should be taken into account.
 
-## Cryptographic Blinding and Scrambling
+## Cryptographic Blinding
 
 In a remote attestation procedure, both the Verifier and the Attester may choose to cryptographically blind certain attributes to enhance privacy.
 For example, specific information can be included in the signature after being processed through a one-way function, such as a hash function.
 
-Additionally, there is an option to scramble the Nonce or Attester Identity using other information that is known to both parties.
-A common example is the IP address of the Attester, which is typically accessible to both the Attester and the Verifier.
-This additional information can be utilized to scramble the Nonce, thereby mitigating certain types of relay attacks.
-
 ## Trust Assumptions on the Handle Distributor
 
 The handle distributor, as a third party in remote attestation scenarios, holds a critical position similar to that of a Trusted Third Party (TTP).