Draft: draft-ietf-rats-architecture

Commentary: Based on discussion at IETF about including a very high level summary , and text in the arch docs , draft - birkholz - rats - reference - interaction - model , and draft - birkholz - rats - tuda . Signed - off - by :   
 A quick review of the strawman , using the strawman to highlight a few points for discussion .
Paragraph (version B):
It is important to prevent replay attacks where an attacker replays
old Evidence or an old Attestation Result that is no longer correct.
To do so, some mechanism of ensuring that the Evidence and
Attestation Result are fresh, meaning that there is some degree of
assurance that they still reflect the latest state of the Attester,
and that any Attestation Result was generated using the latest
Appraisal Policy for Evidence.  There is, however, always a race
condition possible in that the state of the Attester, and the
Appraisal Policy for Evidence, may change immediately after the
Evidence or Attestation Result was generated.  The goal is merely to
narrow the time window to something the Verifier (for Evidence) or
Relying Party (for an Attestation Result) is willing to accept.
Paragraph (version B):
There are two common approaches to providing some assurance of
freshness.  The first approach is that a nonce is generated by a
remote entity (e.g., the Verifier for Evidence, or the Relying Party
for an Attestation Result), and the nonce is then signed and included
along with the claims in the Evidence or Attestation Result, so that
the remote entity knows that the claims were signed after the nonce
was generated.
Paragraph (version B):
A second approach is to rely on synchronized clocks, and include a
signed timestamp (e.g., using I.D.draft-birkholz-rats-tuda) along
with the claims in the Evidence or Attestation Result, so that the
remote entity knows that the claims were signed at that time, as long
as it has some assurance that the timestamp is correct.  This
typically requires additional claims about the signer's time
synchronization mechanism in order to provide such assurance.
Paragraph (version B):
In either approach, it is important to note that the actual values in
claims might have been generated long before the claims are signed.
If so, it is the signer's responsibility to ensure that the values
are still correct when they are signed.  For example, values might
have been generated at boot, and then used in claims as long as the
signer can guarantee that they cannot have changed since boot.
Paragraph (version A):
Any solution that conveys information used for security purposes,
whether such information is in the form of Evidence, Attestation
Results, or Endorsements, or Appraisal Policy, needs to support end-
to-end integrity protection and replay attack prevention, and often
also needs to support additional security protections.  For example,
additional means of authentication, confidentiality, integrity,
replay, denial of service and privacy protection are needed in many
use cases.
Paragraph (version B):
Any solution that conveys information used for security purposes,
whether such information is in the form of Evidence, Attestation
Results, or Endorsements, or Appraisal Policy, needs to support end-
to-end integrity protection and replay attack prevention, and often
also needs to support additional security protections.  For example,
additional means of authentication, confidentiality, integrity,
replay, denial of service and privacy protection are needed in many
use cases.  freshness discusses ways in which freshness can be used
in this architecture to protect against replay attacks.