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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 10 February 2021 08:52 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7458A3A0EC7 for <rats@ietfa.amsl.com>; Wed, 10 Feb 2021 00:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2EX25dJqZol for <rats@ietfa.amsl.com>; Wed, 10 Feb 2021 00:52:20 -0800 (PST)
Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980B03A0EC6 for <rats@ietf.org>; Wed, 10 Feb 2021 00:52:18 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FuHgDtnSNg/xoHYZlYAQmBCYFRgx+?= =?us-ascii?q?BSwGNOogrCCUDgQWbBTwLAQEBAQEBAQEBCSUIAgQBAQOESAKCBAElOBMCEAE?= =?us-ascii?q?BBgEBAQEBBgQCAoZODUMWAYIZYoEHAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?SAg1SZwEFMgEFOgcQCxIGLkkOBg0BAwQBAYJsAYMFBQuvGoE0hViDNIE+BoE?= =?us-ascii?q?4jTkWEA+BTT+BEScMA4IuNT6CXQKBMgGGIQSBVAFwAwZRCwEDIjEgAQENTB0?= =?us-ascii?q?HNAEFBg0XDwETJRABG4hSrypoLAeBa4ESgRgFC4gOhwSLQQUKH5MyBop4hHW?= =?us-ascii?q?RaY0rS5FOLRkEhFyBbIF7TSRPgmpPFwINh3+GKxiDTopaR2ICBgEJAQEDCXy?= =?us-ascii?q?GGYNvAYEOAQE?=
X-IPAS-Result: =?us-ascii?q?A2FuHgDtnSNg/xoHYZlYAQmBCYFRgx+BSwGNOogrCCUDg?= =?us-ascii?q?QWbBTwLAQEBAQEBAQEBCSUIAgQBAQOESAKCBAElOBMCEAEBBgEBAQEBBgQCA?= =?us-ascii?q?oZODUMWAYIZYoEHAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQESAg1SZwEFMgEFO?= =?us-ascii?q?gcQCxIGLkkOBg0BAwQBAYJsAYMFBQuvGoE0hViDNIE+BoE4jTkWEA+BTT+BE?= =?us-ascii?q?ScMA4IuNT6CXQKBMgGGIQSBVAFwAwZRCwEDIjEgAQENTB0HNAEFBg0XDwETJ?= =?us-ascii?q?RABG4hSrypoLAeBa4ESgRgFC4gOhwSLQQUKH5MyBop4hHWRaY0rS5FOLRkEh?= =?us-ascii?q?FyBbIF7TSRPgmpPFwINh3+GKxiDTopaR2ICBgEJAQEDCXyGGYNvAYEOAQE?=
X-IronPort-AV: E=Sophos;i="5.81,167,1610406000"; d="scan'208";a="24980096"
Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2021 09:52:15 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtHgDtnSNg/wpIDI1YAQkeAQELEgx?= =?us-ascii?q?AgVGCKXZZNzuNO4grCCUDgQWbQQsBAwEBAQEBCSUIAgQBAYRLAoICAiU4EwI?= =?us-ascii?q?QAQEFAQEBAgEGBHGFYQ1DFgGFagEFMgEFOgcQCxIGLkkOBg0BBwEBgmwBgwo?= =?us-ascii?q?LrxqBNIVYgzSBPgaBOI05FhAPgU0/gREnDAOCLjU+gl0CgTIBhiEEgVQBcAM?= =?us-ascii?q?GUQsBAyIxIAEBDUwdBzQBBQYNFw8BEyUQARuIUq8qaCwHgWuBEoEYBQuIDoc?= =?us-ascii?q?Ei0EFCh+TMgaKeIR1kWmNdpFOLRkEhFyBbCOBV00kT4JqTxcCDYd/hisYg06?= =?us-ascii?q?KWkJnAgYBCQEBAwl8hhmDbwGBDgEB?=
X-IronPort-AV: E=Sophos;i="5.81,167,1610406000"; d="scan'208";a="135767217"
Received: from ksapp01.sit.fraunhofer.de ([141.12.72.10]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2021 09:52:13 +0100
Received: from ksapp01.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by ksapp01.sit.fraunhofer.de (Postfix) with ESMTPS id 082188026D; Wed, 10 Feb 2021 09:52:13 +0100 (CET)
Received: from [192.168.16.50] (79.234.113.123) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 10 Feb 2021 09:52:12 +0100
To: "Panwei (William)" <william.panwei@huawei.com>
CC: "rats@ietf.org" <rats@ietf.org>
References: <bf19f185f996450abe753fa45e722ab4@huawei.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <6d20106f-7496-5600-1cf2-f5288c1a417a@sit.fraunhofer.de>
Date: Wed, 10 Feb 2021 09:52:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <bf19f185f996450abe753fa45e722ab4@huawei.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.113.123]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/XkVTNHCnxNlvXHvM835UCUJ7m7M>
Subject: Re: [Rats] Review comments about draft-ietf-rats-reference-interaction-models
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 08:52:25 -0000

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
>