Re: [Rats] EAT claims needed by TEEP

Laurence Lundblade <> Tue, 27 October 2020 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EBE53A1495 for <>; Tue, 27 Oct 2020 11:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PNwoKDkj6n0d for <>; Tue, 27 Oct 2020 11:57:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E2073A12D6 for <>; Tue, 27 Oct 2020 11:57:30 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id XU9xkVV4PnXVXXU9xkayDa; Tue, 27 Oct 2020 11:57:30 -0700
X-CMAE-Analysis: v=2.4 cv=NO4QR22g c=1 sm=1 tr=0 ts=5f986d9a a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=0XtbOteLAAAA:20 a=4yAKxjYotTeE49IUHJkA:9 a=jYJq5EX27wIw55d-:21 a=pSlkukuaQ73D7JPG:21 a=QEXdDO2ut3YA:10 a=BBFS4BUNhsFNHM5XLKYA:9 a=km0EVC6CITI95vJ7:21 a=R4PnLxqbUAL_HJzJ:21 a=QwHWtzmgYTxBiXO4:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E4D0CE5-BAC2-4EE6-9A4B-5A16320DE1FC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Tue, 27 Oct 2020 11:57:29 -0700
In-Reply-To: <>
Cc: "" <>, teep <>
To: Dave Thaler <>
References: <>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfC2yaRiBDXM9OjnOyIHQg3tM0kPfUUvwYW8d3L/x6Tiyqp6rmVebIO9H6ledQ6Swi5NFKtMDFM73EXoO49VLqBEXevpFpJkDWOSHwZozCqaZoGygaS++ gYCDYVMUUgw5RC72uZliOfbzXIMvRQ0aANNNtrcLXwmGSrkvmvQgZSQYxG7kpBSu1GFWMvfeLDLdwBdh3IKg2qtUV6znVveCEUpklcVv8LdIT3R0Z5NY1aUC ltRkyNv48QWEH7RW9HzFH6TfB36F2fUUMIw5prUgBxU=
Archived-At: <>
Subject: Re: [Rats] EAT claims needed by TEEP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2020 18:57:44 -0000

Personally, I think attestation of TEE’s is pretty important and should be handled well in EAT. So I’m interested in working on and adding claims for this to EAT.

After reading section 7.1 in TEEP architecture, it does seem like there some work to do here to get to specific standardized interoperable claims.

More comments below.

> On Oct 26, 2020, at 3:15 PM, Dave Thaler <> wrote:
> As discussed in previous IETF meetings, if there are claims beyond the base set that
> other WGs need, they can be specified by the other WGs with review by RATS.
> The TEEP WG needs the following in EATs and I am not sure whether they can be
> covered by existing claims or whether TEEP-specific claims are needed.  From
> section 7.1 of draft-ietf-teep-architecture:
> Ø     -  Device Identifying Information: TEEP attestations may need to
> Ø        uniquely identify a device to the TAM.  Unique device
> Ø        identification allows the TAM to provide services to the device,
> Ø        such as managing installed TAs, and providing subscriptions to
> Ø        services, and locating device-specific keying material to
> Ø        communicate with or authenticate the device.
> I believe the Universal Entity ID Claim (ueid) is claim that meets the above requirement.
> But the TEEP arch then goes on to say:
> Ø        In some use cases it
> Ø        may be sufficient to identify only the class of the device.  The
> Ø        security and privacy requirements regarding device identification
> Ø        will vary with the type of TA provisioned to the TEE.
> Which EAT claim contains the device class? The closest thing I see is OEM Identification by IEEE (oemid)
> but I am not sure that is sufficient since it's only the OEM not the device class from that OEM.
> This doesn’t seem like something that should be TEEP specific though, so can someone tell me how to
> represent device class using the claims in the EAT spec?

I don’t think the OEMID, UEID or other should be (ab)used  to represent device class. That would result in them being less reliable and useful in a generic sense. We should come up with a new claim.

We can define a claim to be  the device class and make it a byte string like a UEID, but I think we have to go further to make it useful as an interoperable standardize claim. There has to be some method for the classification. TrustZone vs hypervisor based? Fast vs slow? Has a protected mode kernel and TAs? The TEEP document doesn’t say. This seems problematic without a classification scheme.

I wonder if the intent is more about grouping, in which case we can define a GEID (Group Entity ID) that looks a lot like a UEID. That seems useful and sensible to me. It is not about classification based on any characteristics. It lines up with the privacy preserving technique of one key per 100,000 devices.

> Ø     -  TEE Identifying Information: The type of TEE that generated this
> Ø        attestation must be identified, including version identification
> Ø        information such as the hardware, firmware, and software version
> Ø        of the TEE, as applicable by the TEE type.  TEE manufacturer
> Ø        information for the TEE is required in order to disambiguate the
> Ø        same TEE type created by different manufacturers and address
> Ø        considerations around manufacturer provisioning, keying and
> Ø        support for the TEE.
> Similarly for this requirement, the closest thing I see is Origination Claim (origination) but I am not sure
> that is sufficient since it's just the manufacturer not the "version identification information such as the
> hardware, firmware, and software version of the TEE”

Definitely not origination claim. The intent of it something like Endorser identification and I think it should be replaced by an Endorser/X.509 cert URL.

I would say, this is a combination of claims

I’ve just added a PR <> for HW version claims.

The intent for SW version claims is to use CoSWID. We should probably create some examples to see if it can represent what TEEP wants to represent.

The paragraph mentions “type of TEE”. I’m not sure what is intended. I don’t know of any common taxonomy for classifying TEEs.

> Should the TEEP WG define TEEP-specific claims for such information?

I’d like to see most of them go into EAT unless they are super specific to TEEP (TEEP not TEEs). I think there is value in broad standardize claims as it promotes interoperability of RATS.


> Dave
> _______________________________________________
> RATS mailing list
> <>
> <>