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

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 03 August 2020 16:41 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 3A2E83A0FE7 for <rats@ietfa.amsl.com>; Mon, 3 Aug 2020 09:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.698
X-Spam-Level:
X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[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_H3=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=FA7sUt4N; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=KRLaFK08
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 PEd7MtrqnEP5 for <rats@ietfa.amsl.com>; Mon, 3 Aug 2020 09:41:56 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABCB3A0FC2 for <rats@ietf.org>; Mon, 3 Aug 2020 09:41:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34165; q=dns/txt; s=iport; t=1596472916; x=1597682516; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iS7ksUsZUCerfh/OwQ/5+5mfr7/DlPgvtkBarfQYp4o=; b=FA7sUt4NxMk9t73uSko4Cc1khoKdeb3igp0u+6mL33KX7fgC1g5gDlwu NBK3mLWIVpaK41EylP0kXAdZ7ozNpI3SKaSoOdWuQa/oQU4xXo9i411a4 nYu0c298WHQNUc4TVbupbYP/lUyMCpEMkvC12cFxKXUy/Yv1Tq1z+0BKi Q=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3ACs3Hlh0NRorQQVnWsmDT+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?A0CbBQD+PChf/5BdJa1WChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgSMvUQdvKy0vLAqHcQONUIdakQmCUwNVBAcBAQEJAwE?= =?us-ascii?q?BLQIEAQGETAKCOgIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXEBAQEEEhsTAQE?= =?us-ascii?q?3AQ8CAQgRBAEBIQcHAjAUCQgBAQQOBQgGDQeDBYF+TQMfDwGnUwKBOYhhdIE?= =?us-ascii?q?0gwEBAQWFIBiCBwcJgTiBU4Edih4agUE/gRFDgk0+hBAvFR+DE4ItjzlUiWy?= =?us-ascii?q?BGZsACoJhhDiCW5MXn3qxSgIEAgQFAg4BAQWBaiOBV3AVO4JpUBcCDY4fg3G?= =?us-ascii?q?KVnQ3AgYIAQEDCXyNDi2BBgGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.75,430,1589241600"; d="p7s'?scan'208,217";a="533490104"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Aug 2020 16:41:55 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 073Gftsu004815 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2020 16:41:55 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 11:41:55 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Aug 2020 12:41:54 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 3 Aug 2020 11:41:54 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y7fi9tvv1Ul7HrEAAFeyffoIYtjiVD+g62bP+0cLH2O/eAPOiUNHrwdYrGJPZLI9/uOSc6bHbupxwDIQHARRvUrcB/ip335crgv5kruDbnJVKJa8gDMWw/KJDhqvXeRY3s+K2BQQAlkp+tzKXkZ1JEa/M49lMPsaLffp34Wvj555/3eKxC32xvAY0TRqqasMxF/DAo7WN5kcUvXcKfywI9vQhBmMQrtfNMQjBKOhKAuXtf7WlYB0QfPo04ClygSzTOvFVeXUW+Ml5b5lvH1yPrElKqSOdZzYAQZZCFNViAwVBQDg6RdmjbXWdDnUXxw5T8h0YOyDA9BuGeClwVmsSg==
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=vnzmNGWJFvx4MFQIOcFmCg/omF1JEf+MPDRMLabFPxA=; b=hVMnPE3jYvTnyKQxH0q90lricFdgmPUsF56tAklIJblZQtEt1K53jBjiLeyAXy7mc3gKkcYmbYmRvCjE4QHhLLnPiuYI5MK4auYjHM7KlydbNjQCE1dZqOvmlDidKy5qbS7ISfGuF4LLj6A8lu/FIchqrFym0Jbppr6Jo3a78PzJF87ONLZ9g/IFhsR9AkcosexRhVHtgzmiQetO91uZcdsgyTfuu29s6RvhNKg2AlqGPHC2i77qXwz6Eh9W/R/1P16FxyawziupmfvBkRY/MJI9225RGbJ7B5nM6tquO30RQv+W+YeBezhCGohJ5wVgR0UDQ4UIOCqHyxkXsWGCdA==
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=vnzmNGWJFvx4MFQIOcFmCg/omF1JEf+MPDRMLabFPxA=; b=KRLaFK08+9j3rrcbOc/XbAr56cegMzzuO94v1FO962rZuFqk+WRD5hYdOLJ9FKDIJnGtusC7eO+UK5esFFg/xWaFwzmypZhiLNVpGldYgI0B0QrIxb7y/dcQI1oDl10pXWGYHSpk9uuIDkgSFvHdaKLYDLAkSd9Q+8FUVAGyWm8=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2916.namprd11.prod.outlook.com (2603:10b6:208:72::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Mon, 3 Aug 2020 16:41:53 +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.021; Mon, 3 Aug 2020 16:41:53 +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/WmwBS28JgANYNhuA=
Date: Mon, 3 Aug 2020 16:41:52 +0000
Message-ID: <BL0PR11MB31228868F764A95881E9306DA14D0@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <BL0PR11MB3122B1E0BA81CB3CFA8F1AB3A1730@BL0PR11MB3122.namprd11.prod.outlook.com> <7a25c2715b5741018b0ed52ddfcde6e1@huawei.com>
In-Reply-To: <7a25c2715b5741018b0ed52ddfcde6e1@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.69]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bda63c38-ff68-4339-e284-08d837cc2078
x-ms-traffictypediagnostic: BL0PR11MB2916:
x-microsoft-antispam-prvs: <BL0PR11MB291608A30F2D32DB10D697E4A14D0@BL0PR11MB2916.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RtelIGYS9iX5IYP+QPSp12SDwQtiFYTkr9H2Rurx9tRZdU7bacijbk9f/JQHqkk9HDgQibWhNEh1tyClDpVdRy8J6WbowR5gF/lL6ijtJuKlWlRxAKqXdDfP5wlsLrsYuhGe+X+M3FZIRqIz0nnmOEj4j1VV/lGAIoGJvrl8Dyqqj0xfFJ05/dsPeKjn+BMpgvlL7aPMV30dLUfwJuSUvTMmNWnGchrtFV6ciOoaXr9PwuRd8GjNgMEEQjtrDvlgQB8Q/hZ5PAJvGFVEFaX3GbqNxUY9zbaW7myxDYXd+KdeT5C2Y6qlxCeL1IM3dauUiqMseI7sEl01Lcy6A/IH4Q==
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)(136003)(39860400002)(396003)(376002)(346002)(8936002)(8676002)(64756008)(66556008)(66476007)(66616009)(478600001)(7696005)(186003)(76116006)(66946007)(53546011)(6506007)(33656002)(99936003)(9686003)(4326008)(55016002)(66446008)(26005)(66574015)(83380400001)(86362001)(71200400001)(5660300002)(2906002)(52536014)(6916009)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Oc17sqPq+3eSBeL2iaHbxmz5aJm8zHhXTGYGwZqE9TJIsKPyj68/JNTf9gTIG3ItumCY2eiOQgrr/3hjzxn5sd7PxfkMahlPqgO3GmnD577ckhkn86aDvyaoWMYGUxkCjohQBUMZqJD/0iqQhKyOYzig9EBRHV6+H1IHVFB4R++aESOv6nIsPB78gu16xIUsXrsvwGXnkNGkbr5+TmLo/PKfIxl3U98lFCgT9FA6zzgy3636CYQzl1DlYNa2SOrrrfNyIHlkA/k+zKR28s4D/PuIPjEYpQlp/FcIgF2BlFyod+3FNFwmoNlcLD7KqINQja8MsAtKuT6Wpa3mYFvC6VIBJAmyzr/nkCHOXGLKxMIv9As0rtIEzktKJFaji+RyulrEWWCKtPwm9evj16A9QVBMQx1MI0wHrHk/REBQc2Zkyh47m52nGHdhZyMHtkvvvfzBTzBwaW2Mgg/utot3lFPFf86VyXAiAB8s5nevqMX7KCQGuc0y1w+FKy2bzY8iv2/wr8XtBn7PKv760EiHG92feW1V4fXumCbLeEso65phof6AEf3/meCQEiz3YoacygZkTb+iacQBm1HbU+rwIIccOZCcsmVY7xsNdcUCWYF5X6C0kJNTP5OF139NBgoOMIAQfUe/jV1iTd4eLzH9kw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05E4_01D66993.74B44AD0"
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: bda63c38-ff68-4339-e284-08d837cc2078
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 16:41:52.8925 (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: yJBSm0qNdGKeZkuoa3XkqPuUyg7IhpMiQe36e4UiANa9pPMeeEIvbE6ZP27RdzKL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2916
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/KZFBSteyJO6e7ip-l16x0MwoAt8>
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: Mon, 03 Aug 2020 16:41:59 -0000

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, 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.

 

Below are some extensive thoughts on both options.  In the end I really am
fine with both.

 

To start with, I believe some useful context comes from the
ietf-keystore.yang YANG model which is currently under WGLC as part of
draft-ietf-netconf-keystore-17.   Here the following structure can be used
to identify a unique certificate independent of any TPM:   

   module: ietf-keystore.yang
     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name                                    string
              +--rw certificates
                 +--rw certificate* [name]
                    +--rw name                      string

In this model, the certificate's name is accessed without any TPM
information.  The next level in the hierarchy is the key name.  Note that in
this model, certificate's <name> object different than currently in charra.
The charra leaf <certificate-ref> can point to that keystore:

              path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"

                 + "/ks:certificates/ks:certificate/ks:name";

This means we have access to all the certificate info which a keystore would
support.

 

More after your questions...

 

From: Panwei, August 2, 2020 10:02 AM



Hi Eric,

 

I don't object to contain the certificate-name in the response, I just
suggest to add the tpm-name in the response and use it as the key.

I don't believe that one TPM per router/switch is enough. From the security
perspective, I think one TPM per line card is needed, or at least using more
TPMs is the trend. So the YANG module should consider the forward
compatibility.

 

 

By using the tpm-name as the key of the output (and containing the
certificate-name in the output), there are several advantages:

1) It's easy for the readers to understand.

 

<eric> I believe it harder.   You still need to make <certificate-name>
mandatory.   Otherwise you likely need to acquire and test multiple keys
from a keystore to find the right one.   

 

Note: by mandating the key of <tpm-name> in your proposal you are enforcing
that only one response using a single key from TPM may be included.  Perhaps
this is a good thing.  It is not a good thing if anyone ever wants to return
two tpm quotes using different TPM keys as part of the same RPC response.

 

2) It's easy for the Verifier to distinguish which TPM each record
corresponds to and which certificate that TPM uses.

 

<eric> In both cases you need to get to the key itself from a keystore.   A
certificate points to a key, which is associated with a particular TPM.  The
key is already required for validating the signature of returned results.

 

3) If the re-keying happens and a new certificate-name is provided to the
Verifier, the Verifier only needs to query the Attester about the
certificates of the specific TPM and doesn't need to retrieve the
certificates of all TPMs.

 

<eric> This is not required for the existing model.  All you need to do is a
get on the existing model with the provided <certificate-name>. 

 

4) While using different TPM names is already required, this approach
doesn't further require to use different certificate names for different
TPMs.

 

<eric> If we make <certificate-name> dependent on <tpm-name>, then we have
the nested keys which we are trying to avoid for those devices which only
have a single TPM.   The main question I see from above is whether making
the <certificate-name> (which is system generated) unique across TPMs.
Again I believe this is helpful for those devices with just one TPM.

 

Eric

 

Regards & Thanks!

Wei Pan

 

From: Eric Voit (evoit) [ <mailto:evoit@cisco.com> mailto:evoit@cisco.com] 
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) < <mailto:william.panwei@huawei.com>
william.panwei@huawei.com>
Cc:  <mailto:rats@ietf.org> rats@ietf.org
Subject: Charra: certificate-name vs TPM-name

 

Hi Wei Pan,

 

During the RATS WG call you wondered why certificate-name should be used
rather than tpm-name.  There are two reasons:

 

(1) In RFC places like:

 

      +---x tpm20-challenge-response-attestation {TPM20}?

         +--ro output

            +--ro tpm20-attestation-response* []

               +--ro certificate-name?           string

               +--ro quote?                              binary

               +--ro quote-signature              binary

 

if just the tpm-name is provided, how does a Verifier know when a re-keying
happens?    With the current solution, when unknown certificate-name comes
back from the RPC, you just need to query:

 

    +--rw rats-support-structures

       +--rw tpms* [tpm-name]

          +--rw tpm-name                     string

          +--rw certificates

             +--rw certificate* [certificate-name]

                +--rw certificate-name    string

                +--rw certificate-ref?    leafref

                +--rw certificate-type?   enumeration

 

and then you can find the tpm-name, plus all the required info
post-certificate upgrade in one place.  If the certificate-name is not in
the RPC, a Verifier will have to make several guesses on what any failure of
signature verification might mean.

 

(2) The most common implementations will have just one TPM per
router/switch.  These implementations might never care about the tpm-name.
They will care about the certificate used on that router/switch.

 

Thanks,

Eric

 

Eric Voit 

.:|:.:|:. Cisco Systems, Inc.