[Rats] FW: Comments on the changes of CHARRA YANG module

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 14 July 2020 11:45 UTC

Return-Path: <evoit@cisco.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 2AD2D3A0C00 for <rats@ietfa.amsl.com>; Tue, 14 Jul 2020 04:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.621
X-Spam-Level:
X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DQl5UFDh; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=n/bqmV/0
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 amFeLXCY3rbF for <rats@ietfa.amsl.com>; Tue, 14 Jul 2020 04:45:56 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193DF3A0BF9 for <rats@ietf.org>; Tue, 14 Jul 2020 04:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13584; q=dns/txt; s=iport; t=1594727155; x=1595936755; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KqxDGYTWCmBC5XQHL4Xkq0c4btTH8ZP7ROJIqk3GvVo=; b=DQl5UFDhsLiSYLoNfwQgG8na0jcjjkZbh2Y/l17cDlcFtRUeXztrTYL0 6tlkLnk7WdG4U99g5a1dC9zBeFFi19oEogIMjlSMTLjSZ1pk2SNrBXLfQ 2QSJSjYwfcyA4wi3Q7SJl19SP7LIoifhU+JtNcln8urdoDAEwCRmnqYq4 8=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A4F0aux2LS1SKLg5+smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dtkVbWUISd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhIEdnzZhvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQCQDmmQ1f/5pdJa1WCh4BAQsSDEC?= =?us-ascii?q?DHFEHgRotLywKh28DjVGBAZddgUKBEQNVBAcBAQEJAwEBLQIEAQGETAKCHAI?= =?us-ascii?q?kOBMCAwEBCwEBBQEBAQIBBgRthVsMhW8BAQEBAgESLgEBMAcBBAcEAgEIEQQ?= =?us-ascii?q?BAS8CMBsBAQUDAQEEDgUIBgsJgwWBfk0DDhEPAZ15AoE5iGF0gTSDAQEBBYU?= =?us-ascii?q?sGIIHBwmBOIFTgReJeQ8agUE/gRFDghgHLj6EEAUOCxEVgzKCLY8wN4lQgRW?= =?us-ascii?q?KBI9VgQQKgl2EMYJXknOCdY5ejWCTV50QAgQCBAUCDgEBBYFqI0SBE3AVO4J?= =?us-ascii?q?pUBcCDY4eDBeDTopWdDcCBggBAQMJfI0XASaBDQGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.75,350,1589241600"; d="p7s'?scan'208";a="782846490"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2020 11:45:54 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 06EBjsqH019237 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2020 11:45:54 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 06:45:54 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 06:45:53 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 14 Jul 2020 07:45:53 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqbasEQpTbrRrCLbfL3iupaZxFZGpAB8qYNINkG4Uq5hvKdw+MfrSObphMg0/KXs2A9eysh5c/6P+V0/56A9V1QvUy5Wi6JnWFqCL7r/gjx2Fi3w6rMpEBisE9zm1emy4kdg+gXuxV48y0O/Td7Nt9kHL8sxka2gj45cPmDoVHfcgCC/0ulJbMiJR/2/DXIrBnMXcdHINU1U+6jTJLVrBRPCHFd7/FLkgc8wsRZTn4VoDFSFGBbOunmjpk7X8tIqom489inyI4lqwJt/u9tFUwjMXsNc8ealUJqhamdAMUTmJnqRn7EOBGed8l7P2YvbBYi10oHGz/nMYLDw2F4byw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ua7/seXjYvUC9GZUKkgTTsoZ6UM10qvernICe/egj5w=; b=Y5X5HCKAQZBkA424FZvXo9j1iotAAaI3jGadT3N677/rh0Pqu6Xk3a7Lmh64pPby0z7XtNtJ5nw1THqw/HY4wNpL6wGqXuafGMlh70gZNk8fJXBVvqFJf7dgNeFdJTAfWSaBLq0kkbMldFKp5EfOdS7GTKo7Nx1vTSWvHCg8OzVSWdAmNYD66rY3zTOqlTf3DwkatQlGCZ1k01qug9nc3xenUnAtA0eg+/XT23Z8UPRgRW4TbZcKejkXfwhHwB0o32uXYx2i9Ea2HlsD2Mo05cMfvxFsWzMkU7qi9KdlJ9LCdlQxiqF3ydQOFkFW339wkA3ZU4Hs++tGG5dEUPOsEQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ua7/seXjYvUC9GZUKkgTTsoZ6UM10qvernICe/egj5w=; b=n/bqmV/0FzYtvb4Hr4B/Ni2RqVDNid2qCxSSaAH3kbveY+YLdFB931905dCWSbXzK+niPo2AvaSAdHYEJbWqrG31mK0e3qU5TxcJI/tulDAb2mfQZos43XI9uKwYdVI1K3uwbZLbYZkF1tY8+KEGoO3mha4TL18s66Q/cNVmJv8=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4173.namprd11.prod.outlook.com (2603:10b6:208:137::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Tue, 14 Jul 2020 11:45:52 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3195.017; Tue, 14 Jul 2020 11:45:52 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Panwei (William)" <william.panwei@huawei.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Comments on the changes of CHARRA YANG module
Thread-Index: AdZWpd3aUHkm/3I1RKafnNj2CppmIwAHwgsgAAAIMzAAAASPEADDs82Q
Date: Tue, 14 Jul 2020 11:45:52 +0000
Message-ID: <BL0PR11MB3122B754F8A0766C940E6CBBA1610@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <4e2e0b53d2be47009b1958758620914c@huawei.com> <BL0PR11MB312212DBDF82574A4A9621D3A1650@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB31220711F00B56420020F28FA1650@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB312286944CDCA49E90A186B6A1650@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB312286944CDCA49E90A186B6A1650@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 52f94bc0-166e-4075-d4ad-08d827eb760b
x-ms-traffictypediagnostic: MN2PR11MB4173:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR11MB41732BB3E7FF6D24313FCE60A1610@MN2PR11MB4173.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3631;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: u9NVlzSYQLSIY9Po6IFaoD0lDS2M8cIFgciJRYCdEGrlxX3a3Tr/YLmRehXAbV26+Bd0Ca+B3nxFkF0gMW7EEchwIaQWqAepwha95ev0rpXUChbKGVMUIeCvl9uiGFDpDIhn0VKkTNnJO/711ILxiX2TthFlhunltsvoGEO5rloffmT/y83M5tcWfQPeYvZSdrl73/JAMqjqaeObisLfG9bA9nH6nlRH0MApTnLIth54jORpJ++z4yFRzLuJ3KV4LZieXEdFjaGFw2rx4cdirWq9QEg7r9ttYv9eLWkqsUbt+m2oBYANjJS6bOP0s1bf
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(26005)(7696005)(33656002)(5660300002)(53546011)(66946007)(52536014)(2906002)(66446008)(64756008)(66616009)(66476007)(76116006)(186003)(66556008)(6506007)(6916009)(86362001)(8676002)(8936002)(478600001)(71200400001)(83380400001)(99936003)(316002)(9686003)(4326008)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 94V9GOeLNC37CcvSE8xGNubnL2lRkXg9u/7iH6526Avpl3emkoAOlPtVchK5F6NsyEpAkZ7uvJeOqElGkGHDtiT/LX+VCGyPikygqHDAgc8FMJuHk253mqXIm9BqSePULLqlEaUlZZeEanJFQWucIwH9ozCxekojEHL0ab9ITsh6wYUzuLiKgXNtip0cAs3rimkmVJa47oBjRqlCny4BzgywCgn4fcodVbtcAmzGNTHTRmasL+mKol3auummt/3ojK1ooi90BMgHRcAD3Tg2jLWHzBSyBbqNounhAlUjjLSH9L7Cn2HisuKRgTqJIqwvpBgkjrUFd8K4Si7S8tpLwfUQt1CavPzSt8fqn+bIU85Mre+HnWuRVKsfqEa8BgJEHsoU4VWF+1NPCnYiXjV2XGiRBLicsGM7SJ7EdyMKVrJmoC5gqkJWXGq0PmO6iZp++w5wpvzKpCFthpMPaO4EjBqeGzKZzV7NKCGKemGakaJCN/tiDeYEyZfTqR7n5aCf
Content-Type: multipart/signed; boundary="----=_NextPart_000_0048_01D659B2.CA602E40"; protocol="application/x-pkcs7-signature"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 52f94bc0-166e-4075-d4ad-08d827eb760b
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 11:45:52.2350 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KHr7XScCdIkqDtj14aarxXkQyyMgrdnlk2MSApEq4R0RsXMS3V7XiDf9UZNlEE2M
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4173
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/pB0Ret-gyteftx9-xoXSylwQ15g>
Subject: [Rats] FW: Comments on the changes of 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, 14 Jul 2020 11:46:05 -0000

Including the 'rats' alias.  I missed this in the original response...

-----Original Message-----
From: Eric Voit (evoit) 
Sent: Friday, July 10, 2020 11:24 AM
To: Panwei (William) <william.panwei@huawei.com>
Cc: rats-chairs@ietf.org
Subject: RE: Comments on the changes of CHARRA YANG module

Hi Wei Pan,

Thanks for the comments.  Some thoughts in-line...

> From: Panwei (William), July 10, 2020 6:39 AM
> 
> Hi Eric,
> 
> I've read the YANG modules you changed, actually I didn't get how the new
> modules worked when I read it the first time. After reading it a few times
> and discussion with others, I kind of figured out how it worked:

It seems like it would be good to add some text which explains common
operations outside of the YANG model.   I will propose some text to the
draft based on your thoughts lower in the thread.  

> 1. The Verifier (or Relying Party) uses the "rats-support-structures"
> datastore structure to retrieve the hardware information, i.e., all the
> compute-nodes and all the TPMs, from the Attester. Then the Verifier can
> establish the relationship between the TPM and its compute-node info and
> certificates info. Further, the Verifier can identify the TPM according to
> the certificate-name and/or the compute-node.

Yes.  A large benefit we don't send redundant information in a continuous
set of RPC replies.    And by sending the certificate as the unique
identifier, it becomes easy to handle certificate upgrades, as when you see
a new certificate being used, you then can retrieve the information from the
Attester.

> 2. Next, the Verifier uses the RPC structures to get Evidence in a
> challenge-response fashion. In the challenge input, the Verifier can use
the
> leaf "key-identifier" to ask Evidence of one specific TPM based on this
> TPM's unique credential, or it can use the leaf-list "tpm-name" to ask
> Evidence of one or more TPMs based on these TPMs' names.

The absence of either should result in the acquisition of PCR information
for all physical TPMs.  This is a benefit from the previous version where we
explicitly had a 'tpm-name' of 'ALL'.  That is the purpose of the YANG model
text:

        "Name of one or more unique TPMs on a device.  If this object
exists,
        a selection should pull only the objects related to these TPM(s).
If
        it does not exist, all qualifying TPMs that are 'hardware-based'
        equals true on the device are selected.";

> 3. In the response output, the Attester returns the Evidence. If the input
> contains only one TPM, then the output can match that TPM anyway. But if
> the
> input contains several "tpm-name", then the output is a set of Evidence of
> these TPMs, in this situation, the Verifier needs to use the
> "certificate-name" and/or "node-id" in each Evidence to identify which TPM
> produced it.

This is correct.

> If my understanding is right, then the YANG modules after changed have
> some
> assumptions which aren't explicitly said, I conclude them below:
> 1. The Verifier must retrieve the datastore first before initiate the
> challenge request.

With the current version, this is not the case.  (As there is not a required
key of 'tpm-name' mandatory in the RPC.)

What needs to happen is that there is a secure method of provisioning on the
certificate on the Verifier.  And if you receive an unknown certificate, you
have a choice of how to then acquire that information.   The current YANG
model points to ' ietf-keystore.yang' as a potential place to get that
information.

> 2. Every TPM should have a unique name, at least be unique in an Attester.

Yes.  And this could be a random system generated string.  It cannot be a
TPM path, as this could change on a reboot.

> 3. Every certificate should have a unique name. It should be unique in an
> Attester if the certificate-name can identify the TPM, or should be unique
> in a compute node if the certificate-name and the node-id are used
together
> to identify the TPM.

The certificate-name should be unique within a Attester.  I will add that as
a constraint to the YANG model via XPATH.  Good catch, I had not explicitly
said this is required.

> 4. For the input, if you choose to use the "key-identifier", then the
> list-leaf "tpm-name" must have only one value.
> My suggestion would be to have a section to describe the workflow or the
> example of how to use this YANG module. Also, explicitly pointing out the
> assumptions would be much better.

I agree.  In fact, I would argue that you should not allow both
'key-identifier' and 'tpm-name*' in the same query.  What happen if they
conflict?   If you agree, we could make an explicitly choice allowing either
one or the other.  

> Generally, I agree with the idea that don't use nested keys to identify
the
> TPM (and its position) in RPCs. This has a significant benefit of
> scalability. Because if in the future more dimensions are needed to
identify
> the TPM (and its position), the RPC structures don't need to be changed,
> only modifying the datastore structure is enough. But the current RPCs
also
> have a disadvantage that the key is very obscure and implicit, 

I assert this is a very large benefit.  You do not have to identify the key
at all in the query.
 
> for example,
> you need to use "certificate-name" and "node-id" as the key in the output.
I
> suggest that we can just use the "tpm-name" as the key of output. 

'tpm-name' is an internal structure to the Attester, and need not be used by
the Verifier where there is only one TPM.  This is a significant benefit of
getting rid of the key.   And for implementations with only one TPM, life is
much simpler.

> Two
> advantages would be: easier for readers to understand, the Verifier
doesn't
> need to search the database to find out the matched TPM.

There is another simplifying advantage of the current structure.  When a
certificate changes, you then can simply fetch the corresponding tpm info
from the datastore.  Certificate management/upgrades should become easier.

> Other comments:
> 1. Some elements in the "rats-support-structures" are changed from read-
> only
> to read-write, e.g., the "supported-algos" and "certificates" of TPM. Why
> these elements can be configured now?

On "supported-algos":  an operator might want to limit the universe of
supported-algos from the full set which might be available from a vendor.

On "certificates":  YANG has some structural issues with how config data can
be exposed.  I believe that an Attesting device should allow new
certificates to be provisioned in a place like ' ietf-keystore.yang'.
However I am not sure if YANG allows non-config leafrefs to point to
configuration data.  I get an error if I try to make these objects system
generated.  Any suggestions on how automatically update things here?  I do
know there are implications to NMDA (RFC-8342).

> 2. The outputs of RPC "tpm12-challenge-response-attestation" and
> "tpm20-challenge-response-attestation" contains the "node-id" and
> "node-physical-index". Can these two elements be omitted in the output?
> Because they can be get through the datastore.

I believe these can be removed.  Perhaps we can ask everyone during the IETF
session if they have any objections?

> 3. The output of RPC "log-retrieval" doesn't contain the "node-id" or
> "node-physical-index", and this is different with the outputs of other two
> RPCs. I wonder whether here is right and other two RPCs need to delete the
> two elements.

Agree.   The answer to the above question should be true here as well.

Thanks!
Eric

> Regards & Thanks!
> Wei Pan