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

Commentary: Based on Does the Authentication Secret represent the identity of the Attesting Environment ? 
 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 ? 
 This comment also addresses . TL;DR : A TPM AIK is an Authentication Secret . In the first draft , I named this element just " Secret " . And yes , an AIK ( Attestation Identity Key ) in TPM 1.2 terminology , or AK ( Attestation Key ) in TPM 2.0 terminology , can be such a " Secret " . The " Secret ID " basically is a key identifier / ID , e.g. , the fingerprint / hash of such a key or the public part of the AK . The TPM FAPI uses key paths , such as " HS / SRK / RSASignKey " . These are also valid key / secret identifiers / IDs . There is no official ( unique ) way of identifying keys , except for the FAPI key -- but : You need to use the FAPI for that purpose which is not available on embedded devices with no OS ( because it needs at least a filesystem ) . In summary , it can be stated that " Secret IDs " are application - specific . Now , what is the matter with " Authentication Secret " and " Authentication Secret ID " ? In a later draft I replaced " Secret ( ID ) " with " Authentication Secret ( ID ) " intentionally , after talking to a crypto colleague . " Authentication Secret " is more specific than just " secret " . And , in fact , its purpose is to provide authentication , i.e. evidence must provide the security property of " authentication " , so that one knows it originates from a valid / specific source , e.g. TPM . This can also be some kind of group key ( or DAA key ) . " Authentication Secret " : This element must be present in the attesting environment as it signs evidence ( and a digital signature provides integrity and authentication ) . " Authentication Secret ID(s ) " : This element must be mandatory as it identifies the " Authentication Secret(s ) " . 
 In our implementation , during the router booting up , the BIOS measures the BootLoader and records the measured hash value into the TPM , then the BootLoader measures the OS  and records the measured hash value into the TPM as well . Based on our implementation , I can see some inconsistencies from two different aspects : According to the definition of Layered Attestation , I think the Attesting Environments are BIOS and  . But , according to the definition of " Authentication Secret " , because the TPM 's AIK / AK signs Evidence so the TPM 's AIK / AK is the Authentication Secret , and because " Each Authentication Secret is uniquely associated with a distinguishable Attesting Environment " so the TPM should be the Attesting Environment . So , which one is correct ? 
 After talking with  I came to realize ( again ) that the use of a TPM creates this " interesting " setup of the two layers of Attesting Environments : Both the first layer that is the BIOS and the second layer that is the  share an Attesting Envirment component that is the TPM . In acronyms , the BIOS 's claim collection capability and the TPM that is an RTS and RTR compose the first Attesting Environment . The  's claim collection capability in combination with the identical TPM compose the seceond Attesting Environment . As a result , I agree that the sentence " Each Authentication Secret is uniquely associated with a distinguishable Attesting Environment " does not really allow for that scnerario and needs some help . 
 fixed in
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):
Each Authentication Secret is uniquely associated with a
distinguishable Attesting Environment.  Consequently, an
Authentication Secret ID also identifies an Attesting Environment.
Paragraph (version B):
Each distinguishable Attesting Environment has access to a
protected capability that provides an Authentication Secret
associated with that Attesting Environment.  Consequently, an
Authentication Secret ID can also identify an Attesting
Environment.