Draft: draft-ietf-rats-ar4si

Commentary: Includes stuff from  ( as discussed on list ) , as well as text for
This document defines reusable Attestation Result information
elements.  When these elements are offered to Relying Parties as
Evidence, different aspects of Attester trustworthiness can be
evaluated.  Additionally, where the Relying Party is interfacing with
a heterogenous mix of Attesting Environment and Verifier types,
consistent policies can be applied to subsequent information exchange
between each Attester and the Relying Party.
This document defines reusable Attestation Result information
elements.  When these elements are offered to Relying Parties as
Evidence, different aspects of Attester trustworthiness can be
evaluated.  Additionally, where the Relying Party is interfacing with
a heterogeneous mix of Attesting Environment and Verifier types,
consistent policies can be applied to subsequent information exchange
between each Attester and the Relying Party.
Values 1 to 31: A standards enumerated reason for affirming.
None: The Verifier makes no assertions regarding this aspect of
trustworthiness.
Value 0: The Evidence received is insufficient to make a
conclusion.  Note: this should always be always treated
equivalently by the Relying Party as no claim being made.  I.e.,
the RP's Appraisal Policy for Attestation Results SHOULD NOT make
any distinction between a Trustworthiness Claim with enumeration
'0', and no Trustworthiness Claim being provided.
Value 1: The Evidence received contains unexpected elements which
the Verifier is unable to parse.  An example might be that the
wrong type of Evidence has been delivered.
Value -1: A verifier malfunction occurred during the Verifier's
appraisal processing.
Affirming: The Verifier affirms the Attester support for this aspect
of trustworthiness.
Values 2 to 31: A standards enumerated reason for affirming.
None: The Verifier makes no assertions about this Trustworthiness
Claim.
Value 0: Note: this should always be always treated equivalently
by the Relying Party as no claim being made.  I.e., the RP's
Appraisal Policy for Attestation Results SHOULD NOT make any
distinction between a Trustworthiness Claim with enumeration '0',
and no Trustworthiness Claim being provided.
Value -1: An unexpected error occurred during the Verifier's
appraisal processing.  Note: while no claim is being made, the
Relying Party MAY make a distinction between a Trustworthiness
Claim with enumeration '-1', and no Trustworthiness Claim being
provided.
The configuration is a known and approved config.
The configuration includes or exposes no known vulnerabilities.
The configuration includes or exposes known vulnerabilities.
The configuration is unsupportable as it exposes unacceptable
security vulnerabilities.
The file system includes contraindicated executables, scripts,
or files.
There is a hybrid alternative for the establishment and maintenance
of trustworthiness between an Attester and a Relying Party which is
not adversely impacted by the potential drawbacks with pure
background-check.  In this alternative, a Verifier evaluates an
Attester and returns signed Attestation Results back to this original
Attester no less frequently than a well-known interval.  This
interval may also be asynchronous, based on the changing of certain
Evidence as described in I-D.birkholz-rats-network-device-
subscription.
this Attester identity is accepted as sufficient proof of Attester
integrity.
Effectively this means that detailed forensic capabilities of a
robust Verifier are unnecessary because it is accepted that the code
and operational behavior of the Attester cannot be manipulated after
TEE initialization.
An example of such a scenario may be when an SGX's MRENCLAVE and
MRSIGNER values have been associated with a known QUOTE value.  And
the code running within the TEE is not modifiable after launch.
Zero Trust Architectures are referenced in US-Executive-Order eleven
times.  However despite this high profile, there is an architectural
gap with Zero Trust.  The credentials used for authentication and
admission control can be manipulated on the endpoint.  Attestation
can fill this gap through the generation of a compound credential
called AR-augmented Evidence.
This compound credential is rooted in the hardware based Attesting
Environment of an endpoint, plus the trustworthiness of a Verifier.
The overall solution is known as "Below Zero Trust" as the compound
credential cannot be manipulated or spoofed by an administrator of an
endpoint with root access.  This solution is not adversely impacted
by the potential drawbacks with pure background-check described
above.
To kick-off the "Below Zero Trust" compound credential creation
sequence, a Verifier evaluates an Attester and returns signed
Attestation Results back to this original Attester no less frequently
than a well-known interval.  This interval may also be asynchronous,
based on the changing of certain Evidence as described in I-
D.birkholz-rats-network-device-subscription.