Re: [Rats] Charra: certificate-name vs TPM-name

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 04 August 2020 16:14 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 877FB3A0ADC for <rats@ietfa.amsl.com>; Tue, 4 Aug 2020 09:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=ms6if8y+; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=W0Q2sn5a
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 XIQJ2wiyN-jz for <rats@ietfa.amsl.com>; Tue, 4 Aug 2020 09:14:00 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F623A0A12 for <rats@ietf.org>; Tue, 4 Aug 2020 09:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27527; q=dns/txt; s=iport; t=1596557640; x=1597767240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TTT/oiJgiWxETGh/iwYT17fZ47HlzZ/gS/hJ8B7avtw=; b=ms6if8y+/wAHAP8EUCllWWwgDLlAB5xe9dLH2SBz0ZIO+5LHMjEUxzya ETOv6lNF9c7yV1yt9RXjlHE29VDBqSyNu/QFgeDoORzhWcFESg79jzNUV 1K3wTwUsBz/O7U+ixPVj4wUXG3agXAzHp77pOOfmDuIvjiMKBYd2bSHrz A=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:jc2Nnh+qq6MxC/9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHxkClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DZAQCtiClf/5hdJa1gGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBSoEjL1EHbystLywKh3EDjVGHWpEJglMDVQQHAQEBCQMBAS0CBAEBhEwCgiQCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBBIbEwEBNwEPAgEIEQQBASEHBwIwFAkIAQEEDgUIBhSDBYF+TQMfDwGndQKBOYhhdIE0gwEBAQWFHRiCBwcJgTiBU4Edih4agUE/gRFDgk0+hD80gxOCLZl8gRmbAgqCYoQ4gluTGYJ8iU6TMbFLAgQCBAUCDgEBBYFqI4FXcBU7gmlQFwINjh8MF4NOilZ0NwIGCAEBAwl8jkcBgRABAQ
X-IronPort-AV: E=Sophos;i="5.75,434,1589241600"; d="p7s'?scan'208,217";a="522133183"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Aug 2020 16:13:59 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 074GDxAo024526 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Aug 2020 16:13:59 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 11:13:58 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 11:13:58 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 4 Aug 2020 12:13:58 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/R93ngUQvJW6sxOA50vNdAPuvS1LBGqSsosYJcvnY+ve5f50D37mSO+TAEwFpDve8t1cf+a97wr5joqm6rbz1GC4q5LadvDcxikaP5k7xGfAWJObosNAtdYm3Ual6iN8zSB9i+UBmQtfReIPkJr+X4Xdh/j436RJ/1yDpQ/GiIgL3y/4GCz58MFvMKze4pxEKZB+40IIOyc3VB+oMaM9zoOUWTlINjMRzSMPQXApEwxFDb6Xu6mWXWVpi5C0qPEBCbgHCFo/QlSEcEO1e3SnTykJ0OellJbRgPS61eGXSSy8QGp6oqrT10JBU/WxJG3jYhyZdTmMq3w92THf3IZww==
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=XhfpeSn7nTgzosUetI6UNCXOOy6AIGjpQu+O5dAfRHY=; b=ns+t5jqXWJHro/DCQVaND9j3/otfBaxhLgFdIVCmpiNq/uYxTQ9r1przyLI1QMxT37NSdo4lXAF1K/2mEZySmMC+orkn3FPYU7JU42g9+lWuS07MGK42v7KJohsQ+Ahj3iWaDhdfFm6dJXk9BqClk6IiQkm4pjbBNYJmfIUlQ6zPWJkVfbVXDZg2j2Rxem1uCwxqXuaRQipUN2XwI3DhuzesXOjgnrbRJ0YiiKYYsGu7VqJxwn8uT6uyfR2/XYOzJnpECy1rNJrIOa+bV9mEWIJOZaTp6SN3me+813JEgGAWvKd3YhVIcG/3aj3z2cxnA0uDgO+1F2VHGjVEpGukPQ==
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=XhfpeSn7nTgzosUetI6UNCXOOy6AIGjpQu+O5dAfRHY=; b=W0Q2sn5aTS4VoiCtgSTRdbtaRe+rPpwyEz6uqTfymU4MkzD9Jl0pJ+xuHTvxT867bHEWeK+v4uvqNUIzg4jm6H8gOlfHgXMxs/0s6omgRgIfzkJVNBU4iDF+6011pfak7CmVdtq4I0aagXb4kZeSElKAsEhahsJk01SZ85T8scE=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4175.namprd11.prod.outlook.com (2603:10b6:208:153::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Tue, 4 Aug 2020 16:13:57 +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.3239.022; Tue, 4 Aug 2020 16:13:57 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Panwei (William)" <william.panwei@huawei.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Charra: certificate-name vs TPM-name
Thread-Index: AdZk7AdVjrhIJhH+SNGp+N2fr3/WmwBS28JgANYNhuAAG/cWAAAaz+Iw
Date: Tue, 04 Aug 2020 16:13:56 +0000
Message-ID: <BL0PR11MB312281C2968D603F3062D6F2A14A0@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <BL0PR11MB3122B1E0BA81CB3CFA8F1AB3A1730@BL0PR11MB3122.namprd11.prod.outlook.com> <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com> <BL0PR11MB31228868F764A95881E9306DA14D0@BL0PR11MB3122.namprd11.prod.outlook.com> <d9338204e8ff4adc8670033197774f1d@huawei.com>
In-Reply-To: <d9338204e8ff4adc8670033197774f1d@huawei.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.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b5c9b588-9cac-4681-68a1-08d8389163e2
x-ms-traffictypediagnostic: MN2PR11MB4175:
x-microsoft-antispam-prvs: <MN2PR11MB4175270F3092728671BE8C75A14A0@MN2PR11MB4175.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2hmxE7B+1yJWHWim7dQ3/dHIloos5T5AYE8p2MYFOZBzTeRIBvvOT7hVHSHPCGEWaRoAGtCx2WfL709t3sHyRAmrMardbZnydmg+28MZ9VyaQoCRO3uy803pdTxYLuVrDYGILFNN8dLSmQ5jkOo47utljVLefdOmlPdBHbKas0Vwh4tUJCjBxtjT307x3zuMuyW4ZoQ68KBReYPcnkBDOYKA8cfKUN6+CIAvZ2Rc8KK2rrWslNc4Qhiqh3zlzU7OXh9wJhfkrcGyeUozLcRZtLOB2XzjAvG0lQe8VIE9pwOiDCgb6ER4CYX/99iFHtAwP+6uOPuebIzvCzrJScz1wQ==
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)(366004)(346002)(396003)(376002)(39860400002)(136003)(52536014)(9686003)(55016002)(66446008)(99936003)(7696005)(76116006)(26005)(186003)(33656002)(6506007)(5660300002)(66946007)(64756008)(66616009)(66476007)(66556008)(53546011)(8936002)(66574015)(71200400001)(316002)(83380400001)(478600001)(6916009)(4326008)(2906002)(8676002)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: DXw1Fx2ErQ7IpizKkjA7fCXztcdTV27DlDlPC5mpWfA/HJqC3WcXs2qNViy1P199hTwLoQVS3og2Ew0U/zWpFltYqCf5D+FnAzshE984yMSqaxeLoAuyTc3A03y91h12wQOIWroTNITVCbYu6KAANJYk/B5VqWo4ZR4Sqdy73QZ0+Q+cG/6dh3B8aRsYR1hHEAmgvlc2kmgGI8BkWVW7m+d66II6/TkF7P7CV2k0QP86sSfV/TFnNXeaf4VRJyvqoDyqwGgGmrB86uuSIOLQ4v9ga80dRVfzJV9XlGz0B3ibcqv8Ib3RuBfebqsLZj1E0A2WlO1MpHnOAuHu3g4AUX/p7hgNHiWXqRiBaLc98Wy82njXxKqkwO3jhj8hqPQcuKYOVBYtioWfQtA9k8iVEHmhpkMmrtOAjJS5KLo5p9EkagiKZndLt2S+QjPoJ9Cnl7yr6MuTzX5G9Gp7k4dlspgAI57XWAgfimsi+KK447PQYoz4MVNcuyYtLQi0vB3vH78JAh5WgWjoR7yF7pEtoOsZdBeE5m5iyLBsFUVdfzCEUUcL4aYMspErVvvSehBmS4nx5rO5P4anXhvunxjtvyLt2Z+T++qtPn8u/cr6kaH9Svf485L8R/o99RXAFTscrpLYcT+Ldg839vBPVeUjkQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0090_01D66A58.B2EDBF00"
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: b5c9b588-9cac-4681-68a1-08d8389163e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 16:13:56.7492 (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: 2YCOuziI4f1ex+ZSyAbpIh+AmqT2GYKEOwrUvSQQUGdrj8mcDzf09eswy7h8uBmS
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4175
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Nm1mhob0o66vUgScpZqZ7q513Fs>
Subject: Re: [Rats] Charra: certificate-name vs TPM-name
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, 04 Aug 2020 16:14:03 -0000

Hi Wei Pan,

 

Below I cut the thread to the last bit of difference.  I think we agree on
everything else.

 

From: Panwei (William), August 4, 2020 1:18 AM



Hi Eric,

 

Thanks for your reply. After a twice thinking, I realize it's true that the
difference between our proposals is that whether to contain <tpm-name> in
the response and whether to make <certificate-name> unique across different
TPMs.

Some thoughts please see inline.

 

Regards & Thanks!

Wei Pan

 

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, 2020 12:42 AM
To: Panwei (William) <william.panwei@huawei.com
<mailto:william.panwei@huawei.com> >
Cc: rats@ietf.org <mailto:rats@ietf.org> 
Subject: Re: [Rats] Charra: certificate-name vs TPM-name

 

Hi Wei Pan,

 

I fully agree that multiple line cards per switch/router is necessary. The
current model does support this, as the RPC output is a list.  Lists are
identified by the "[]" in the tree diagram.   So for any current list entry,
a <certificate-name> which is unique to an individual TPM can be placed
within this list. 

 

The real difference I see between our proposals is that you want <tpm-name>
explicitly listed in the RPC response, 

 

[Wei] Indeed.

 

and I thought a unique <certificate-name> which doesn't require users of
single TPM devices to understand <tpm-name> is preferable.  I.e., some
complexity is hidden within the router so that a class of developers need
not care.

 

[Wei] But I think some new complexities for multi-TPM devices have also
emerged.

The first complexity is that the certificate name should be unique across
TPMs.

Imagine this case: there are two TPMs and each one has a certificate, e.g.,
tpmA's certificate is cert1 and tpmB's certificate is cert2. When tpmA
changes its certificate, it releases the name 'cert1' and names the new
certificate 'cert3'. Right after that tpmB changes its certificate, and
names the new certificate 'cert1' because 'cert1' is unique right now. But
you can see a potential problem here, if the Verifier receives the
attestation response before receiving the updates of the certificates, it
will wrongly match the record according to the certificate-name, as it
doesn't know the owner of 'cert1' is changed. Although the Verifier will
fail to verify the signature, but it doesn't know what's the real problem.

So, the second complexity is that the certificate name should not be reused
by other TPMs.

There may be other complexities that I didn't come up with.

 

<eric2> If the charra model's <certificate-name> were populated with
something like "cert1", I would absolutely agree with you.   But that is not
what I am proposing.  

 

Stepping back, perhaps the conventions used for YANG object naming are
causing some mis-communications here.  

 

In the example below, use:

*	"ks" as the prefix for ietf-keystore.yang
*	"tpm" as the prefix for charra

 

<tpm:certificate-ref> points to an instance of  

 
"/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ks:certificates/ks:certif
icate/ks:name"

 

It is over in ietf-keystore.yang, you would have that <ks:name> be something
human readable like "cert1".  But we likely wouldn't want two human readable
names for the same certificate in different yang models.

 

Looking back at the path from ietf-keystore.yang, you can see that there is
no TPM differentiator in that YANG datastore for asymmetric keys.  In other
words the primary repository for asymmetric-key information does not use
anything like <tpm:tpm-name> as part of its key.  This is why I believe that
<tpm:certificate-name> is best system generated, and need not be human
readable.  So what I would do in implementation for <tpm:certificate-name>
is to populate it with the value of "/ks:asymmetric-key/ks:name" appended
with the value of
"/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name".  This long a
string isn't necessary, but it works and requires no additional human
configuration.  Other protections could be put into place as well, such as
an XPATH constraint on <tpm:certificate-name> so that it is never the same
as "../../tpm:tpm-name/tpm:certificate-name".

 

Again, I wouldn't be overly upset if the WG did have a preference for the
nested key option of <tpm:tpm-name> and <tpm:certificate-name>.  It is less
efficient, and exposes extra complexity to the receiver (nested identifiers
and the need for single TPM devices to expose a TPM-name).  But it has the
benefit of being simple to understand.

 

/Eric2