Re: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module)

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 18 August 2020 12:07 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 A4AD03A05A7; Tue, 18 Aug 2020 05:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 5WV9h4s8MGxy; Tue, 18 Aug 2020 05:07:47 -0700 (PDT)
Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 4EB8F3A091D; Tue, 18 Aug 2020 05:07:44 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FeAABGxDtf/xoBYJlVChoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBSoRNCpVRnBQLAQEBAQEBAQEBBgEBLQI?= =?us-ascii?q?EAQGBNYMXAoIhASQ4EwIQAQEGAQEBAQEGBAIChlGGSgEBAQEDMgEFQRALEQQ?= =?us-ascii?q?BAQEnB0YJCAYBDAEFAgEBgyKCfAWvKHSBNIVSg1+BQIE4jR8PgU0/gREnD4I?= =?us-ascii?q?sLj6EEIYkBJAXiW+bfyoHgVuBCoEKBAuYfAUKHoMAiVyFBAaOPY1zhEifQAI?= =?us-ascii?q?EAgkCFYFqgXtNJE+CaVAXAg2OKxeOJnI3AgYBCQEBAwl8j0QBgRABAQ?=
X-IPAS-Result: =?us-ascii?q?A2FeAABGxDtf/xoBYJlVChoBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAUCBSoRNCpVRnBQLAQEBAQEBAQEBBgEBLQIEAQGBNYMXAoIhA?= =?us-ascii?q?SQ4EwIQAQEGAQEBAQEGBAIChlGGSgEBAQEDMgEFQRALEQQBAQEnB0YJCAYBD?= =?us-ascii?q?AEFAgEBgyKCfAWvKHSBNIVSg1+BQIE4jR8PgU0/gREnD4IsLj6EEIYkBJAXi?= =?us-ascii?q?W+bfyoHgVuBCoEKBAuYfAUKHoMAiVyFBAaOPY1zhEifQAIEAgkCFYFqgXtNJ?= =?us-ascii?q?E+CaVAXAg2OKxeOJnI3AgYBCQEBAwl8j0QBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="23737671"
Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 14:07:38 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAABGwztf/1lIDI1VChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQESAQEBAQEBAQEBAQEBQIFKgiqBRzAsCpVRnBQLAQMBAQE?= =?us-ascii?q?BAQYBAS0CBAEBgTWDFwKCHwIkOBMCEAEBBQEBAQIBBgRthWiFcQEBAQEDMgE?= =?us-ascii?q?FQRALEQQBAQEnB0YJCAYBDAEFAgEBgyKDAa8qdIE0hVKDXIFAgTgBjR4PgU0?= =?us-ascii?q?/gREnD4IsLj6EEIYkBJAXiW+bfyoHgVuBCoEKBAuYfAUKHoMAiVyFBAaOPY1?= =?us-ascii?q?zhEifQAIEAgkCFYFqI4FXTSRPgmlQFwINjisXjiZBMTcCBgEJAQEDCXyPRAG?= =?us-ascii?q?BEAEB?=
X-IronPort-AV: E=Sophos;i="5.76,327,1592863200"; d="scan'208";a="88716595"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2020 14:07:36 +0200
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 07IC7YMm001620 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 18 Aug 2020 14:07:34 +0200
Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 18 Aug 2020 14:07:29 +0200
To: "Panwei (William)" <william.panwei@huawei.com>, "Eric Voit (evoit)" <evoit@cisco.com>, "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>, "draft-ietf-rats-yang-tpm-charra@ietf.org" <draft-ietf-rats-yang-tpm-charra@ietf.org>, "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>, Michael Eckel <michael.eckel@sit.fraunhofer.de>
References: <BL0PR11MB312275D009055A74A688C083A1400@BL0PR11MB3122.namprd11.prod.outlook.com> <6d651f96f7d04f43a5cbb6d2ce8fbbc3@huawei.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <322dea6f-2f03-8cbd-5dfe-7eb88a275127@sit.fraunhofer.de>
Date: Tue, 18 Aug 2020 14:07:28 +0200
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: <6d651f96f7d04f43a5cbb6d2ce8fbbc3@huawei.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.206.156.41]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/DGzfSHciuCMhZwjS8_4L8xGXuy8>
Subject: Re: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module)
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: Tue, 18 Aug 2020 12:07:50 -0000

Hi all,

the use of UUIDs originates from the early days of module design (pre 
individual -00 I-D), I think. The only reason this usage exists is... 
because that is the only uniform method to identify both a legacy TPM 
1.2 and a TPM 2.0 via the TSS. That is not a very good stand-alone 
reason :-)

To make sure, I'll add two fellow colleagues as CC - just to be on the 
safe side.

Viele Grüße,

Henk

On 18.08.20 10:35, Panwei (William) wrote:
> Hi Eric,
> 
> Thanks for asking, but I’m afraid that the UUID structures weren’t 
> introduced by us Huawei. And we don’t use UUIDs, so we don’t object to 
> drop them from the model.
> 
> Regards & Thanks!
> 
> Wei Pan
> 
> *From:*Eric Voit (evoit) [mailto:evoit@cisco.com]
> *Sent:* Saturday, August 15, 2020 3:26 AM
> *To:* Panwei (William) <william.panwei@huawei.com>om>; Shwetha Bhandari 
> (shwethab) <shwethab@cisco.com>
> *Cc:* rats@ietf.org; draft-ietf-rats-yang-tpm-charra@ietf.org
> *Subject:* Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG 
> module)
> 
> Hi Wei Pan,
> 
> Just slightly related to the question you asked previously, I have a 
> question on the model/tree you sent back (in-line...)
> 
>> From: Panwei, August 14, 2020 6:01 AM
> 
>> To: Eric Voit (evoit) <evoit@cisco.com <mailto:evoit@cisco.com>>; Shwetha Bhandari (shwethab)
> 
>> 
> 
>> Hi Eric,
> 
>> 
> 
>> Thanks for your reply, please see inline.
> 
>> 
> 
>> Regards & Thanks!
> 
>> Wei Pan
> 
>> 
> 
>> From: Eric Voit (evoit) [mailto:evoit@cisco.com]
> 
>> Sent: Thursday, August 13, 2020 10:32 PM
> 
>> To: Panwei (William) <william.panwei@huawei.com <mailto:william.panwei@huawei.com>>; Shwetha 
> Bhandari
> 
>> (shwethab) <shwethab@cisco.com <mailto:shwethab@cisco.com>>
> 
>> Cc: rats@ietf.org <mailto:rats@ietf.org>; 
> draft-ietf-rats-yang-tpm-charra@ietf.org 
> <mailto:draft-ietf-rats-yang-tpm-charra@ietf.org>
> 
>> Subject: RE: Some new comments for CHARRA YANG module
> 
>> 
> 
>> Hi Wei Pan,
> 
>> 
> 
>> From: Panwei (William), August 13, 2020 8:29 AM Hi Eric,
> 
>> 
> 
>> 
> 
>> 2. The styles of challenge input for TPM1.2 and TPM2.0 are different.
> 
>>       +---x tpm20-challenge-response-attestation {TPM20}?
> 
>>       |  +---w input
> 
>>       |  |  +---w tpm20-attestation-challenge
> 
>>       |  |     +---w nonce-value          binary
> 
>>       |  |     +---w challenge-objects* []
> 
>>       |  |        +---w pcr-list* [TPM2_Algo]
> 
>>       |  |        |  +---w TPM2_Algo        identityref
> 
>>       |  |        |  +---w pcr-index*       tpm:pcr
> 
>>       |  |        +---w TPM2_Algo?          identityref
> 
>>       |  |        +---w (key-identifier)?
> 
>>       |  |        |  +--:(public-key)
> 
>>       |  |        |  |  +---w pub-key-id?   binary
> 
>>       |  |        |  +--:(uuid)
> 
>>       |  |        |     +---w uuid-value?   binary
> 
>>       |  |        +---w tpm-name*           string
> 
>> In the TPM2.0 challenge input, the nonce is put aside and the challenge-objects
> 
>> is a list. So you can challenge for different pcr-lists of different TPMs in one
> 
>> challenge input.
> 
>>       +---x tpm12-challenge-response-attestation {TPM12}?
> 
>>       |  +---w input
> 
>>       |  |  +---w tpm1-attestation-challenge
> 
>>       |  |     +---w pcr-index*              pcr
> 
>>       |  |     +---w nonce-value             binary
> 
>>       |  |     +---w TPM12_Algo?             identityref
> 
>>       |  |     +---w (key-identifier)?
> 
>>       |  |     |  +--:(public-key)
> 
>>       |  |     |  |  +---w pub-key-id?       binary
> 
>>       |  |     |  +--:(TSS_UUID)
> 
>>       |  |     |     +---w TSS_UUID-value
> 
>>       |  |     |        +---w  ulTimeLow?       uint32
> 
>>       |  |     |        +---w  usTimeMid?       uint16
> 
>>       |  |     |        +---w  usTimeHigh?      uint16
> 
>>       |  |     |        +---w  bClockSeqHigh?   uint8
> 
>>       |  |     |        +---w  bClockSeqLow?    uint8
> 
>>       |  |     |        +---w  rgbNode*         uint8
> 
> UUID is represented differently in the TPM1.2 and TPM2 models.   In fact 
> in the TPM1.2 modeling has the UUID broken into constituent parts, none 
> of which are mandatory where other UUID parts exist.  Shwetha told me 
> that the UUID structures originally came from Huawei.    A few questions:
> 
> (1) UUID only appears in RPCs.  It doesn't appear in the datanodes.   
> Nor does UUID appear in draft-ietf-netconf-keystore.  As a result it is 
> hard to see how it might correspond to a key, at least in an IETF YANG 
> ecosystem.  Is support for UUID really essential?   Why?
> 
> (2) Assuming you really want UUIDs, I am hoping the datatypes can be 
> reconciled between TPM1.2 and TPM2 RPCs.    Is there reason you wouldn't 
> just use the uuid YANG typedef of RFC6991 for both?
> 
> (3) Assuming you really want UUIDs, you need to propose how a UUID might 
> relate to keys within the IETF ecosystem of YANG models.
> 
> BTW: If you don't need UUIDs, we could always drop them from the model.  
> (Leaving them to vendor specific augmentations if necessary.)
> 
> Thanks,
> 
> Eric
> 
>>       |  |     +---w add-version?            boolean
> 
>>       |  |     +---w tpm-name*               string
>