Re: [Rats] Review comments about draft-ietf-rats-reference-interaction-models

[Henk Birkholz <[e-mail]>]

Hi Wei,

thanks a lot for this batch of review comments! I created a whooping 21 
issues from them to track and address your comments individually at 
https://github.com/ietf-rats-wg/draft-ietf-rats-reference-interaction-models/issues

And when I write individually I mean by sections of text commented on. 
Sometimes there is more than one comment on a specific sub section in 
one issue.


Viele Grüße,

Henk

On 10.02.21 06:36, Panwei (William) wrote:
> 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
> 
>     Computing Environments (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 don’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 doesn’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 Endorser
> 
>     role and the duties of a DAA Issuer are quite similar as illustrated
> 
>     in the following subsections.
> 
> Comment > Without DAA, I think the Endorser 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 Endorser and DAA Issuer doesn’t make sense to me.
> 
> 3. Section 5.1 Endorsers
> 
> Comment > Does this section have difference with the definition of 
> Endorser 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 Layered Attestation, the 
> Endorser and Endorsement are also needed. So why only mention Layered 
> Attestation here? I don’t see any special relationship between DAA and 
> Layered Attestation.
> 
> 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 Endorser to Verifier.
> 
> Comment > Is there another way to convey the public key certificate, for 
> example, can the public key certificates be conveyed from Endorser to 
> Attester first and then from Attester to Verifier?
> 
>     The zero-knowledge proofs required cannot 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, isn’t 
> it? So, “augmentation” isn’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 Attesting 
> Environments, 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.
> 
>        The Attester MUST protect Claims with that Authentication Secret,
> 
>        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 
> Kernel 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) aren’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 Endorser'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 Endorser 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 Endorser
> 
>        (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?
> 
>     Reference Claims ('refClaims')  _mandatory_
> 
>        Reference Claims are components of Reference Values as defined in
> 
>        [I-D.ietf-rats-architecture].  [Editor's Note: Definition might
> 
>        become obsolete, if replaced by Reference Values.  Is there a
> 
>        difference between Claims and Values here?  Analogously, why is
> 
>        not named Reference Claims in the RATS arch?]
> 
> Comment > I suggest using Reference Values to keep consistent with the 
> RATS arch.
> 
>        Reference Claims are used to appraise the Claims received from an
> 
>        Attester via appraisal by direct comparison.
> 
> Comment > “Direct comparison” isn’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!
> 
> Wei Pan
>