Merge branch 'master' into addressing-issue-73-review-thomas

Author: henkbirkholz

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

@@ -136,7 +136,8 @@ 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, Appraisal 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 illustrates three main interaction models that can be used in specific RATS-related solution documents:
+ This document illustrates three main interaction models between various RATS roles, namely Attesters, Verifiers, and Relying Parties that can be used in specific RATS-related specifications.
+ Using Evidence as a prominent example, these three interaction models are:
 
 1. *Challenge/Response Remote Attestation*:
    A Verifier actively challenges an Attester and receives time-fresh Evidence in response.
@@ -194,7 +195,7 @@ Generally, it is marked by the handoff from the final bootloader or initial OS k
 This document:
 
 * outlines common interaction models between RATS roles;
-* illustrates interaction models focusing on conveying Evidence about boot-time integrity from Attesters to Verifiers;
+* illustrates interaction models using the conveyance of Evidence about boot-time integrity as an example throughout this document;
 * does not exclude the application of those interaction models to runtime integrity or the conveyance of other RATS Conceptual Messages;
 * does not cover every detail about Evidence conveyance.
 
@@ -227,16 +228,19 @@ In order to ensure Evidence is appropriately conveyed through the interaction mo
 
 Authentication Secret:
 
-: An Authentication Secret MUST be exclusively available to an Attesting Environment of the Attester.
+: An Authentication Secret MUST be established before any RATS interaction takes place, and it must be made available exclusively to an Attesting Environment of the Attester.
 
 : The Attester MUST protect Claims with this Authentication Secret to prove the authenticity of the Claims included in Evidence.
 The Authentication Secret MUST be established before RATS take place.
 
 Attester Identity:
 
-: A statement made by an Endorser about an Attester that affirms the Attester's distinguishability. (Note that distinguishability does not imply uniqueness.)
+: A statement made by an Endorser about an Attester that affirms the Attester's distinguishability.
 
-: The provenance of Evidence for a distinguishable Attesting Environment MUST be unambiguous.
+: In essence, an Attester Identity can either be explicit (e.g., via a Claim in Evidence or Endorsement) or implicit (e.g., via a signature that matches a trust anchor).
+Note that distinguishability does not imply uniqueness; for example, a group of Attesters can be identified by an Attester Identity.
+
+: The provenance of Evidence SHOULD be distinguishable with respect to the Attesting Environment and MUST be unambiguous with respect to the Attester Identity.
 
 : An Attester Identity MAY be an Authentication Secret which is available exclusively to one of the Attesting Environments of the Attester.
 It could be a unique identity, it could be included in a zero-knowledge proof (ZKP), it could be part of a group signature, or it could be a randomized DAA credential {{DAA}}.
@@ -610,11 +614,19 @@ One example of a specific handle representation is {{-epoch-markers}}.
 
 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 trusted third party (TTP) -- 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}}).
+In some deployments, a Verifier may obtain a Handle from the Handle Distributor and forward it to an Attester.
+While feasible if the Handle can be authenticated (e.g., an Epoch Marker with a verifiable timestamp), this indirection introduces additional latency for the Attester and can make freshness semantics harder to appraise.
+Therefore, direct distribution of Handles from the Handle Distributor to Attesters is the recommended approach.
+
 Timestamps created from local clocks (absolute clocks using a global timescale, as well as relative clocks, such as tick-counters) of Attesters and Verifiers MUST be cryptographically bound to fresh Handles received from the Handle Distributor.
 This binding provides a proof of synchronization that MUST be included in all produced Evidence.
 This model provides proof that Evidence generation happened after the Handle generation phase.
 The Verifier can always determine whether the received Evidence includes a fresh Handle, i.e., one corresponding to the current Epoch.
 
+The term "uni-directional" refers to the individual conveyance channels: one from the Handle Distributor to the Attester, and one from the Attester to the Verifier.
+Together, they establish the attestation loop without requiring request/response exchanges.
+This model does not assume that Verifiers broadcast Handles, as such a setup would require Verifiers to take on the Handle Distributor role and undermine the separation of duties between these roles.
+
 ### Handle Lifecycle and Propagation Delays
 
 The lifecycle of a handle is a critical aspect of ensuring the freshness and validity of attestation Evidence.
@@ -626,6 +638,7 @@ To manage this complexity, it is essential to define a clear policy for handle v
 
 * *Handle Expiry*:
   Each handle should have a well-defined expiration time, after which it is considered invalid.
+  An Attester that is aware of the expiration time MUST NOT send Evidence with an expired handle.
   This expiry must account for expected propagation delays and be clearly communicated to all entities in the attestation process.
 
 * *Synchronization Checks*:
@@ -792,6 +805,9 @@ In the sequence diagram above, the Verifier initiates an attestation by generati
 The PubSub server then forwards this handle to the Attester by notifying it.
 This mechanism ensures that each handle is uniquely associated with a specific attestation request, thereby enhancing security by preventing replay attacks.
 
+While this model allows for Verifier-specific Handles and custom freshness policies, such policies must be defined and enforced outside the scope of this specification.
+For instance, a Verifier may choose to include a Handle reference in its appraisal policy or request specific handling by the PubSub server through implementation-specific mechanisms.
+
 #### Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe
 
 ~~~~ aasvg
@@ -876,8 +892,10 @@ 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 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.
+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 the `AttRes` topic (= Attestation Result) on the PubSub server, which then serves as the dissemination point from which subscribers, such as Relying Parties or other authorized roles, retrieve the result.
+
 
 #### Attestation Result Generation
 
@@ -912,6 +930,9 @@ Attestation Result Generation is the same for both publish-subscribe models,*Cha
 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`.
 
+In some deployments, Attesters may also subscribe to the `AttRes` topic to consume Attestation Results.
+This reuses the same publish-subscribe mechanism described here and may support local policy decisions or caching.
+
 # Implementation Status
 
 Note to RFC Editor: Please remove this section as well as references to {{BCP205}} before AUTH48.
@@ -1030,10 +1051,16 @@ To mitigate these risks, it is essential to implement robust security measures:
   Implementing strong isolation mechanisms for topics can help prevent the Broker from inadvertently or maliciously routing notifications to unauthorized parties.
   This includes using secure naming conventions and access controls that restrict the Broker's ability to manipulate topic subscriptions.
 
+  In addition to isolating topics, privacy can be preserved by minimizing the inclusion of personally identifying information or unique Attester identifiers in messages published to shared topics, unless strictly required by the subscriber’s role or appraisal policy.
+
 * *Trusted Association Verification:*
   To further safeguard against confusion attacks where the Broker might misroute notifications, mechanisms should be in place to verify the trust association between senders and receivers continuously.
   This can be facilitated by cryptographic assurances, such as digital signatures and trusted certificates that validate the sender's identity and the integrity of the message content.
 
+  Implementations may use Verifier Endorsements or pre-established authorization policies to define valid sender-receiver associations.
+  These policies can be cryptographically enforced using signed metadata, access control lists, or secured registration procedures on the PubSub server.
+  The precise method is deployment-specific.
+
 * *Audit and Monitoring:*
   Regular audits and real-time monitoring of Broker activities can detect and respond to anomalous behavior that might indicate security breaches or manipulation attempts.
   Logging all actions performed by the Broker provides an audit trail that can be critical for forensic analysis.
@@ -1045,6 +1072,9 @@ To mitigate these risks, it is essential to implement robust security measures:
 By addressing these vulnerabilities proactively, the integrity and confidentiality of the attestation process can be maintained, reducing the risks associated with Broker-mediated communication in remote attestation scenarios.
 It is crucial for solution architects to incorporate these security measures during the design and deployment phases to ensure that the attestation process remains secure and trustworthy.
 
+This specification does not require the PubSub server to attest to the Handle or cryptographically prove its dissemination.
+If such assurances are needed (e.g., for auditability or binding Handle provenance), additional mechanisms---such as signed delivery receipts or logs---must be provided by the PubSub infrastructure.
+
 ## Additional Application-Specific Security Considerations
 
 The security and privacy requirements for remote attestation can vary significantly based on the deployment environment, the nature of the attestation mechanisms used, and the specific threats each scenario faces.