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

Commentary: < EOM 
 In sections " 9.6 . License " and " 9.7 . Implementation Dependencies " the two mentions of " github " should be " GitHub " . 
 Based on Here starts to talk about “ additional requirements ” , but I wonder there is no other places in this draft talking about requirement , so what are the basic requirements ? 
 Perhaps we should introduce a dedicated section " ( Basic ) Requirements " , describing basic requirements , such as : " Integrity " : The information provided by the Attester MUST be integral . This may be achieved by means of a digital signature over the attestation evidence . " ( Attester ) Authentication " : The information provided by the Attester MUST be authentic . The Attester should authenticate itself to the Verifier . This may be an implicit authentication by means of a digital signature over the Attestation Evidence , which does not require additional protocol steps . 
 I suggest to place the new section"(Basic ) Requirements " directly after " Scope and Intent " . 
 Based on “ Direct comparison ” is n’t the correct expression , the comparison can have other rules . 
 I agree . So , we should remove the words " via appraisal by direct comparison . " 
 Based on Is it appropriate to say “ correct Evidence ” ? If saying so , I think it means that the Evidence satisfies the Attestation Policy for Evidence . 
 " I think it means that the Evidence satisfies the Attestation Policy for Evidence . " : I agree . So , perhaps it is the best to just remove the words " correct and " , because this is about authenticity and not at all related to correctness . Correct me if I am wrong .
Mailing list commentary: Hi Henk , I ' ve reviewed the reference interaction models I - D recently , I hope the comments below can help improve the draft before the IETF110 draft submission cut - off . 1 . Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology , so I suggest making it a sub - section of Section 2 Terminology . Examples of these types of co - located environments include : a Trusted Execution Environment ( TEE ) , Baseboard Management Controllers ( BMCs ) , as well as other physical or logical protected / isolated / shielded   ( e.g. embedded Secure Elements ( eSE ) or Trusted Platform Modules ( TPM ) ) . Comment > About " these types of co - located environments " , The previous sentences are about the Verifier and Attester do n't need to be remote . So " these " is weird here , because here is about the attesting environment and target environment . 2 . Section 5 Direct Anonymous Attestation Comment > I think it 's better to move this section to the bottom of the draft . DAA does n't introduce a new information elements , and only augments the scope / definition of Attester Identity and Authentication Secret IDs , describing it after the introduction of all the 3 basic interaction models would be better . Putting DAA in the middle makes me feel the basic interaction models rely upon DAA , but actually it 's not . This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters . The existing duties of the role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections . Comment > Without DAA , I think the also needs to provision the Attester Identity to Attesters . And as I understand , the DAA Issuer is a supply chain entity before the Attester being shipped , so it is the Endorser when DAA is used , right ? If yes , then in the next sentence , the comparison between and DAA Issuer does n't make sense to me . 3 . Section 5.1 Endorsers Comment > Does this section have difference with the definition of in architecture draft ? If not , is it necessary to keep this section ? Comment > This section only describes the Layered Attestation , but the scope of Endorsement is more than what 's described here . Endorsement indicates the Attester 's various capabilities such as Claims collection and Evidence signing . For other situations than , the Endorser and Endorsement are also needed . So why only mention Layered Attestation here ? I do n't see any special relationship between DAA and . 4 . Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA , an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties . DAA Issuers offer zero - knowledge proofs based on public key certificates used for a group of Attesters [ DAA ] . Effectively , these certificates share the semantics of Endorsements , with the following exceptions : Comment > In the first sentence , I suggest saying that " a DAA Issuer takes on the role of an Endorser " . o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid . To keep their anonymity the Attester randomizes this credential each time that it is used . Comment > How to understand " Evidence is valid " ? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance ? Or does it mean the Evidence comes from a RoT and is trustable ( although the Evidence can diverge from the Reference Values ) ? Comment > When saying " Attester randomizes this credential " , how many credentials does an Attester have ? 1 ) Can a DAA Issuer have multiple key pairs and use them for one Attester ? 2 ) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester ? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from to Verifier . Comment > Is there another way to convey the public key certificate , for example , can the public key certificates be conveyed from to Attester first and then from Attester to Verifier ? The zero - knowledge proofs required can not be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser . Due to that semantic overlap , the Endorser role is augmented via the definition of DAA duties as defined below . This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles . Comment > For " the definition of DAA duties as defined below " , what is the definition of DAA duties ? Comment > In the last sentence , the Endorsement with its original definition is the third party statement for Verifier and Attester , is n't it ? So , " augmentation " is n't the correct expression . 5 . Section 6 Normative Prerequisites Attester Identity : The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous . Comment > The Attester Identity is to identify which Attester the Evidence comes from . But if the Attester has multiple , what should be the Attester Identity ? Comment > The TPM 's AIK certificate is one kind of Attester Identity , right ? Attestation Evidence Authenticity : Attestation Evidence MUST be correct and authentic . Comment > Is it appropriate to say " correct Evidence " ? If saying so , I think it means that the Evidence satisfies the Attestation Policy for Evidence . Authentication Secret : An Authentication Secret MUST be available exclusively to an Attester 's Attesting Environment .    protect Claims with that , thereby proving the authenticity of the Claims included in Evidence . The Authentication Secret MUST be established before RATS can take place . Comment > Does the Authentication Secret represent the identity of the Attesting Environment ? Comment > How to understand the Authentication Secret , and is it necessary all the time ? For example , in our implementation , during the router booting up , the BIOS measures the BootLoader and records the measured hash value into the TPM , and the BootLoader measures the OS and records the measured hash value into the TPM as well . From the Layered Attestation perspective , I think ( BIOS + TPM ) is the Attesting Environment and ( BootLoader + TPM ) is also the Attesting Environment . But the Claims ( measured hash values ) are n't protected separately , and they finally becomes the Evidence ( TPM Quote ) and it 's only protected by the TPM 's AIK . So , what is the Authentication Secret ? 6 . Section 7 Generic Information Elements Attester Identity ( ' attesterIdentity ' ): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity . Comment > Previous section says " Attester Identity " is about " a distinguishable Attesting Environment " , and here says it 's about " a distinguishable Attester " . Comment > How to understand " without accompanying evidence about its validity " ? Attester Identity ( ' attesterIdentity ' ): mandatory In DAA , the Attester 's identity is not revealed to the verifier . The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence . The evidence is verified using the 's public key . Comment > I think here means the DAA credential represents the Attester Identity . Comment > There is ambiguity of " that is randomized " , does it mean randomized or randomized credential ? Comment > For " confirm the validity of their evidence " , what does " their " refer to ? And what does " the validity of evidence " mean ? Authentication Secret IDs ( ' authSecID ' ): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence . Comment > Previous section says " Authentication Secret " is used to protect Claims , but here says it 's used to protect Evidence . Comment > As I understand , if Authentication Secret represents the identity of Attesting Environment , then it 's not mandatory , at least in our implementation . Authentication Secret IDs ( ' authSecID ' ): mandatory In DAA , Authentication Secret IDs are represented by the ( DAA issuer ) 's public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence . In DAA , an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments . This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used . Comment > In my understanding , here says that the DAA credential identities the Attesting Environment . Compared with the description in the " Attester Identity " part , what does the DAA credential represent actually ?   ( ' refClaims ' ) mandatory Reference Claims are components of as defined in [ I - D.ietf - rats - architecture ] . [ Editor 's Note : Definition might become obsolete , if replaced by . Is there a difference between Claims and Values here ? Analogously , why is not named in the RATS arch ? ] Comment > I suggest using to keep consistent with the RATS arch .   are used to appraise the Claims received from an Attester via appraisal by direct comparison . Comment > " Direct comparison " is n't the correct expression , the comparison can have other rules . Claim Selection ( ' claimSelection ' ): optional A statement that represents a ( sub-)set of Claims that can be created by an Attester . Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence . An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection . Comment > The " all Claims " may be ambiguous , I 'd like to double check , does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection ? 7 . Section 8.1 Challenge / Response Remote Attestation Comment > In the sequence diagram , some elements in the bracket are not defined in the " Information Elements " section , such as targetEnvironment , collectedClaims , eventLog . Should these elements be defined ? 8 . Section 9 Additional Application - Specific Requirements Depending on the use cases covered , there can be additional requirements . An exemplary subset is illustrated in this section . Comment > Here starts to talk about " additional requirements " , but I wonder there is no other places in this draft talking about requirement , so what are the basic requirements ? Regards & Thanks !
Paragraph (version A):
Furthermore, any processes and duties that go beyond carrying out
remote attestation procedures are out-of-scope.  For instance, using
the results of a remote attestation that are created by the Verifier,
e.g., how to triggering remediation actions or recovery processes, as
well as such remediation actions and recovery processes themselves,
are also out-of-scope.
Paragraph (version B):
Furthermore, any processes and duties that go beyond carrying out
remote attestation procedures are out-of-scope.  For instance, using
the results of a remote attestation that are created by the Verifier,
e.g., how to trigger remediation actions or recovery processes, as
well as such remediation actions and recovery processes themselves,
are also out-of-scope.
Paragraph (version B):
Information provided by an Attester MUST be integral.  This may be
achieved by means of a digital signature over Attestation
Evidence.  The signature may be symmetric, such as an HMAC, or
asymmetric, such as ECDSA.
Paragraph (version B):
The information provided by the Attester MUST be authentic.  For
that purpose, the Attester should authenticate itself to the
Verifier.  This may be an implicit authentication by means of a
digital signature over the Attestation Evidence, which does not
require additional protocol steps, or may be achieved by using a
confidential channel by means of encryption.
Paragraph (version A):
An Attester Identity MAY be a unique identity, it MAY be included
in a zero-knowledge proof (ZKP), or it MAY be part of a group
signature, or it MAY be a randomised DAA credential.
Paragraph (version A):
Attestation Evidence MUST be correct and authentic.
Paragraph (version A):
In order to provide proofs of authenticity, Attestation Evidence
SHOULD be cryptographically associated with an identity document
(e.g. an PKIX certificate or trusted key material, or a randomised
DAA credential), or SHOULD include a correct and unambiguous and
stable reference to an accessible identity document.
Paragraph (version B):
An Attester Identity MAY be a unique identity, it MAY be included
in a zero-knowledge proof (ZKP), or it MAY be part of a group
signature, or it MAY be a randomized DAA credential.
Paragraph (version B):
Attestation Evidence MUST be authentic.
Paragraph (version B):
In order to provide proofs of authenticity, Attestation Evidence
SHOULD be cryptographically associated with an identity document
(e.g., a PKIX certificate or trusted key material, or a randomized
DAA credential respectively), or SHOULD include a correct,
unambiguous, and stable reference to an accessible identity
document.
Paragraph (version A):
Reference Claims are used to appraise the Claims received from an
Attester via appraisal by direct comparison.  For example,
Reference Claims MAY be Reference Integrity Measurements (RIM) or
assertions that are implicitly trusted because they are signed by
a trusted authority (see Endorsements in I-D.ietf-rats-
architecture).  Reference Claims typically represent (trusted)
Claim sets about an Attester's intended platform operational
state.
Paragraph (version B):
Reference Claims are used to appraise the Claims received from an
Attester.  For example, Reference Claims MAY be Reference
Integrity Measurements (RIM) or assertions that are implicitly
trusted because they are signed by a trusted authority (see
Endorsements in I-D.ietf-rats-architecture).  Reference Claims
typically represent (trusted) Claim sets about an Attester's
intended platform operational state.
Paragraph (version A):
An Attestation Result is produced by the Verifier as the output of
the appraisal of Evidence.  Attestation Results include condensed
assertions about integrity or other characteristics of the
corresponding Attester that are digestable by Relying Parties.
Paragraph (version B):
An Attestation Result is produced by the Verifier as the output of
the appraisal of Evidence.  Attestation Results include condensed
assertions about integrity or other characteristics of the
corresponding Attester that are processible by Relying Parties.