Re: [Rats] Standardizing TPM output in attestation evidence

"Panwei (William)" <william.panwei@huawei.com> Thu, 05 August 2021 10:07 UTC

Return-Path: <william.panwei@huawei.com>
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 7AD053A0783 for <rats@ietfa.amsl.com>; Thu, 5 Aug 2021 03:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bw3Yjd-ObfL1 for <rats@ietfa.amsl.com>; Thu, 5 Aug 2021 03:07:39 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D5C3A0781 for <rats@ietf.org>; Thu, 5 Aug 2021 03:07:38 -0700 (PDT)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GgPRW56s9z6G9dr for <rats@ietf.org>; Thu, 5 Aug 2021 18:07:19 +0800 (CST)
Received: from kwepeml500002.china.huawei.com (7.221.188.128) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 5 Aug 2021 12:07:35 +0200
Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500002.china.huawei.com (7.221.188.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 5 Aug 2021 18:07:33 +0800
Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2176.012; Thu, 5 Aug 2021 18:07:33 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Laurence Lundblade <lgl@island-resort.com>, rats <rats@ietf.org>
Thread-Topic: [Rats] Standardizing TPM output in attestation evidence
Thread-Index: AQHXiW8wfMLtrg0bjU6R31UTnWUtX6tkpzbg
Date: Thu, 05 Aug 2021 10:07:33 +0000
Message-ID: <fa4098b851034bcbb9504928bfcd903d@huawei.com>
References: <88C94025-5596-4E81-9618-036D6CF9F6E9@island-resort.com>
In-Reply-To: <88C94025-5596-4E81-9618-036D6CF9F6E9@island-resort.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.125.35]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/EkhLvQ1SjhTt8SZ5GFfoBpGMW4c>
Subject: Re: [Rats] Standardizing TPM output in attestation evidence
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: Thu, 05 Aug 2021 10:07:44 -0000

Hi Laurence,

Thanks for sharing your thoughts. I think the use case is reasonable.
I agree with you that these types of devices may not use YANG, so some other means need to be provided, for example defining the CWT claims.

The CHARRA draft defines the attestation evidence suitable for devices using TPMs in YANG, but YANG doesn't provide security protection for the output of TPM. Actually the output of TPM is already signed by the TPM itself, what we need is to provide a secure transportation for the output, for example using NETCONF. TPM itself isn't the Attesting Environment, so it doesn't produce the Evidence directly, it needs other component's help to generate the YANG styled Evidence, and TPM's output is 
So this may be a little different than the current EAT claims. We have two options to handle the TPM's output, one is to define the traditional CWT claims, and the TPM's output is the "value" part of the claim, and then use the EAT attester's key to protect the claim. The other option is to just define the UCCS-style claims and use the secure transportation to transfer the claims and no need to sign the claims again.

I don't know whether this should be defined in EAT draft or a separate draft. But I'd like to highlight that even if the device only has TPM and has no EAT attester/Attesting environment, the YANG data models may also not be suitable for this device and it has to use some other format data models.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Laurence
> Lundblade
> Sent: Thursday, August 5, 2021 4:27 AM
> To: rats <rats@ietf.org>
> Subject: [Rats] Standardizing TPM output in attestation evidence
> 
> There has been a side discussion about TPMs and EAT. This is to bring it to
> the main RATS list and to state more clearly the use case I have in mind.
> 
> The devices I’m thinking of are roughly this:
>  - Desktops, servers, IoT devices… (not network equipment, probably not
> mobile phones)
>  - They have an off-the-shelf TPM2 soldered on to their PCB
>  - Likely to be Intel CPUs, but not necessarily
> 
> We want these devices to do attestation and generate attestation evidence
> (all devices on the Internet should do attestation at some point!). We want
> that attestation evidence to include measurements taken by the TPM. We
> also want attestation evidence from parts of the device other than the TPM.
> 
> That’s the very general use case I have in mind very simply stated.
> 
> Assuming this use case makes sense, then how should this get standardized
> and implemented?
> 
> There is protocol standardization in YANG now for TPM output, but I don’t
> think we want to use YANG for this. I don’t think YANG is in common use for
> these types of devices and has a particular interaction model. I think EAT is
> a good candidate because it is an independently secured blob that can be
> carried by the protocols already in use with these devices.
> 
> This then requires that some output from the TPM be put into an EAT. It
> seems useful to standardize that here in RATS and it seems in scope for the
> charter.
> 
> I don’t have a strong opinion or detailed proposal for what TPM output
> goes into the EAT or the particular HW, SW and attestation architecture of
> the device. That’s something we can work out. I am pretty sure the device
> would have two attesters in a compound/layered arrangement. The
> attestation evidence produced by the TPM would be nested in the
> attestation evidence produced by the EAT attester.
> 
> I have some leaning towards putting this work in the EAT document, but it
> could also be in another document.
> 
> I think this is important for RATS because of the very strong association of
> TPMs with good attestation and for the goal to support attestation for all
> kinds of devices and environments (not just network equipment).
> 
> 
> A few things this is not about:
> 
> - This is not about changing the format that a TPM2 outputs. This is about
> the ability to use the off-the-shelf TPMs that are manufactured by the
> millions and sitting in warehouses today.
> 
> - This is not about local device boot architecture. This is about remote
> attestation, about attestation evidence transmitted to the verifier/relying
> party.
> 
> LL
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats