Draft: draft-ietf-rats-reference-interaction-models

Commentary: In all diagrams , valueGeneration should be replaced by produceClaims . The return type " claims " also indicates that claims are produced(/generated ) somehow . Generated claims , e.g. could be Measured Boot data ( TPM PCRs + the boot event log ) . BTW : I do n't see a passage in the text that describes valueGeneration . See also . 
 Diagrams should be as close to UML as possible to improve understanding . That is ( this applies to all diagrams ): Actions should be verbs , not nouns ( " generateValues " instead of " valueGeneration " ) . Returns of data should also be just arrows with data elements , i.e. nouns ( " evidence --- " instead of " returnEvidence --- " . Uni - Directional Remote Attestation : Handle Distributor should be at the top as an actor . It should be indicated that the " claimsDelta " value generation is a loop . 
 The text must be reworked . All above , the sequence in the diagram should be described entirely . This may also apply to the other models . 
 This should also be described in the text .
Paragraph (version A):
Each section starts with a sequence diagram illustrating the
interactions between Attester and Verifier.  While the interaction
models presented focus on the conveyance of Evidence, the intention
of this document is in support of future work that applies the
presented models to the conveyance of other Conceptual Messages,
namely Attestation Results, Endorsements, Reference Values, or
Appraisal Policies.
Paragraph (version A):
All interaction models have a strong focus on the use of a handle to
incorporate a type of proof of freshness.  The ways these handles are
processed is the most prominent difference between the three
interaction models.
Paragraph (version A):
This Challenge/Response Remote Attestation procedure is initiated by
the Verifier, by sending a remote attestation request to the
Attester.  A request includes a Handle, a list of Authentication
Secret IDs, and a Claim Selection.
Paragraph (version A):
In the Challenge/Response model, the handle is composed of qualifying
data in the form of a cryptographically strongly randomly generated,
and therefore unpredictable, nonce.  The Verifier-generated nonce is
intended to guarantee Evidence freshness.
Paragraph (version A):
The list of Authentication Secret IDs selects the attestation keys
with which the Attester is requested to sign the Attestation
Evidence.  Each selected key is uniquely associated with an Attesting
Environment of the Attester.  As a result, a single Authentication
Secret ID identifies a single Attesting Environment.
Paragraph (version A):
Analogously, a particular set of Evidence originating from a
particular Attesting Environments in a composite device can be
requested via multiple Authentication Secret IDs.  Methods to acquire
Authentication Secret IDs or mappings between Attesting Environments
to Authentication Secret IDs are out-of-scope of this document.
Paragraph (version A):
The Claim Selection narrows down the set of Claims collected and used
to create Evidence to those that the Verifier requires.  If the Claim
Selection is omitted, then by default all Claims that are known and
available on the Attester MUST be used to create corresponding
Evidence.  For example when performing a boot integrity evaluation, a
Verifier may only be requesting a particular subset of claims about
the Attester, such as Evidence about BIOS and firmware the Attester
booted up, and not include information about all currently running
software.
Paragraph (version A):
While it is crucial that Claims, the Handle, as well as the Attester
Identity information MUST be cryptographically bound to the signature
of Evidence, they may be presented in an encrypted form.
Paragraph (version A):
Cryptographic blinding MAY be used at this point.  For further
reference see section security-and-privacy-considerations.
Paragraph (version A):
As soon as the Verifier receives signed Evidence, it validates the
signature, the Attester Identity, as well as the Nonce, and appraises
the Claims.  Appraisal procedures are application-specific and can be
conducted via comparison of the Claims with corresponding Reference
Claims, such as Reference Integrity Measurements.  The final output
of the Verifier are Attestation Results.  Attestation Results
constitute new Claims Sets about an Attester's properties and
characteristics that enables Relying Parties, for example, to assess
an Attester's trustworthiness.
Paragraph (version A):
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.
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.  In the
Uni-Directional model, handles are composed of trustable signed
timestamps as shown in I-D.birkholz-rats-tuda, potentially including
other qualifying data.  The handles are created by an external 3rd
entity - the Handle Distributor - that includes a trustworthy source
of time and takes on the role of a Time Stamping Authority (TSA, as
initially defined in RFC3161).  Timstamps 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 every evidence created.  Correspondingly,
evidence created for conveyance via this model provides a proof that
it was fresh at a certain point in time.  Effectively, this allows
for series of evidence to be pushed to multiple Verifiers,
simultaniously.  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.
Paragraph (version A):
Streaming Remote Attestation procedures require the setup of
subscription state.  Setting up subscription state between a Verifier
and an Attester is conducted via a subscribe operation.  This
subscribe operation is used to convey the handles required for
Evidence generation.  Effectively, this allows for 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.  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.
Paragraph (version B):
Each section starts with a sequence diagram illustrating the
interactions between Attester and Verifier.  While the presented
interaction models focus on the conveyance of Evidence, the intention
of this document is in support of future work that applies the
presented models to the conveyance of other Conceptual Messages,
namely Attestation Results, Endorsements, Reference Values, or
Appraisal Policies.
Paragraph (version B):
All interaction models have a strong focus on the use of a handle to
incorporate a type of proof of freshness and to prevent replay
attacks.  The way these handles are processed is the most prominent
difference between the three interaction models.
Paragraph (version B):
The Attester boots up and thereby produces claims about its boot
state and its operational state.  Event Logs accompany the produced
claims by providing an event trail of security-critical events of a
system.  Claims are produced by all attesting Environments of an
Attester system.
Paragraph (version B):
The Challenge/Response remote attestation procedure is initiated by
the Verifier by sending a remote attestation request to the Attester.
A request includes a Handle, a list of Authentication Secret IDs, and
a Claim Selection.
Paragraph (version B):
In the Challenge/Response model, the handle is composed of qualifying
data in the form of a practically infeasible to guess nonce, such as
a cryptographically strong random number.  The Verifier-generated
nonce is intended to guarantee Evidence freshness and to prevent
replay attacks.
Paragraph (version B):
The list of Authentication Secret IDs selects the attestation keys
with which the Attester is requested to sign the Attestation
Evidence.  Each selected key is uniquely associated with an Attesting
Environment of the Attester.  As a result, a single Authentication
Secret ID identifies a single Attesting Environment.
Correspondingly, a particular set of Evidence originating from a
particular Attesting Environment in a composite device can be
requested via multiple Authentication Secret IDs.  Methods to acquire
Authentication Secret IDs or mappings between Attesting Environments
to Authentication Secret IDs are out-of-scope of this document.
Paragraph (version B):
The Attester collects Claims based on the Claim Selection.  With the
Claim Selection the Verifier defines the set of Claims it requires.
Correspondingly, collected Claims can be a subset of the produced
Claims.  This could be all available Claims, depending on the Claim
Selection.  If the Claim Selection is omitted, then by default all
Claims that are known and available on the Attester MUST be used to
create corresponding Evidence.  For example, when performing a boot
integrity evaluation, a Verifier may only be requesting a particular
subset of claims about the Attester, such as Evidence about BIOS/UEFI
and firmware that the Attester booted up, and not include information
about all currently running software.
Paragraph (version B):
With the Handle, the Authentication Secret IDs, and the collected
Claims, the Attester produces signed Evidence.  That is, it digitally
signs the Handle and the collected Claims with a cryptographic secret
identified by the Authentication Secret ID.  This is done once per
Attesting Environment which is identified by the particular
Authentication Secret ID.  The Attester communicates the signed
Evidence as well as all accompanying Event Logs back to the Verifier.
Paragraph (version B):
While it is crucial that Claims, the Handle, and the Attester
Identity information MUST be cryptographically bound to the signature
of Evidence, they MAY be presented obfuscated, encrypted, or
cryptographically blinded.  For further reference see section
security-and-privacy-considerations.
Paragraph (version B):
As soon as the Verifier receives the signed Evidence and Event Logs,
it appraises the Evidence.  For this purpose, it validates the
signature, the Attester Identity, and the Handle, and then appraises
the Claims.  Appraisal procedures are application-specific and can be
conducted via comparison of the Claims with corresponding Reference
Claims, 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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
In the Uni-Directional model, handles are composed of
cryptographically signed trusted timestamps as shown in I-D.birkholz-
rats-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 RFC3161).
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.  Correspondingly, conveyed Evidence in this model provides
a proof that it was fresh at a certain point in time.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Streaming Remote Attestation procedures require the setup of
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.  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.
Paragraph (version A):
Confidentiality of exchanged attestation information may be
desirable.  This requirement usually is present when communication
takes place over insecure channels, such as the public Internet.  In
such cases, TLS may be uses as a suitable communication protocol that
preserves confidentiality.  In private networks, such as carrier
management networks, it must be evaluated whether or not the
transport medium is considered confidential.
Paragraph (version A):
In particular use cases mutual authentication may be desirable in
such a way that a Verifier also needs to prove its identity to the
Attester, instead of only the Attester proving its identity to the
Verifier.
Paragraph (version B):
Confidentiality of exchanged attestation information may be
desirable.  This requirement usually is present when communication
takes place over insecure channels, such as the public Internet.  In
such cases, TLS may be used as a suitable communication protocol
which provides confidentiality protection.  In private networks, such
as carrier management networks, it must be evaluated whether or not
the transport medium is considered confidential.
Paragraph (version B):
In particular use cases, mutual authentication may be desirable in
such a way that a Verifier also needs to prove its identity to the
Attester, instead of only the Attester proving its identity to the
Verifier.