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

"Panwei (William)" <william.panwei@huawei.com> Tue, 04 August 2020 06:31 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 B3CFE3A0EEA; Mon, 3 Aug 2020 23:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-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 AxlYa0FxW2Lw; Mon, 3 Aug 2020 23:31:27 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E4A553A0EE9; Mon, 3 Aug 2020 23:31:26 -0700 (PDT)
Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 68EA530947F0C9252121; Tue, 4 Aug 2020 07:31:25 +0100 (IST)
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 07:31:24 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml705-chm.china.huawei.com (10.98.57.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 4 Aug 2020 14:31:22 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Tue, 4 Aug 2020 14:31:22 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "Eric Voit (evoit)" <evoit@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>
Thread-Topic: Comments on the changes of CHARRA YANG module
Thread-Index: AdZWpd3aUHkm/3I1RKafnNj2CppmIwAHwgsgAAAIMzAAAASPEASf77EQABwSseAAG9AKEA==
Date: Tue, 4 Aug 2020 06:31:22 +0000
Message-ID: <701283a1d6214c789a5e3e8dd3d09d6e@huawei.com>
References: <4e2e0b53d2be47009b1958758620914c@huawei.com> <BL0PR11MB312212DBDF82574A4A9621D3A1650@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB31220711F00B56420020F28FA1650@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB312286944CDCA49E90A186B6A1650@BL0PR11MB3122.namprd11.prod.outlook.com> <3cac223f282f47f882f6da0507b0b841@huawei.com> <BL0PR11MB31223DF542FF5D75477ABAF0A14D0@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB31223DF542FF5D75477ABAF0A14D0@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.120.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/AIGzJOsSRpbSgAYbMqcQS6cCVwQ>
Subject: Re: [Rats] 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, 04 Aug 2020 06:31:29 -0000

Hi Eric,

I'm forwarding this thread to the rats mailing list.

Other comments but the below one are discussed in the other thread. 

> This is not a problem, the question is then do we make this a case
> statement, or use XPATH.   Either one works.  Do you want to propose the
> YANG model change?

Sure, I can propose a change in the github.

Regards & Thanks!

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:evoit@cisco.com]
> Sent: Tuesday, August 4, 2020 12:54 AM
> To: Panwei (William) <william.panwei@huawei.com>om>;
> draft-ietf-rats-yang-tpm-charra@ietf.org
> Cc: rats-chairs@ietf.org
> Subject: RE: Comments on the changes of CHARRA YANG module
> 
> Hi Wei Pan,
> 
> > Hi Eric,
> >
> > Thanks for your reply, and sorry for my late reply, please see inline.
> >
> > Regards & Thanks!
> > Wei Pan
> >
> > > -----Original Message-----
> > > From: Eric Voit (evoit) [mailto:evoit@cisco.com]
> > > Sent: Friday, July 10, 2020 11:24 PM
> > > 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.
> >
> > Thanks.
> >
> > > > 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.
> >
> > I agree with the design that sending the certificate identifier instead of
> the
> > actual certificate. As I explained in another email, I just suggest that
> adding the
> > tpm-name as the key.
> 
> We can work that one in the other thread.
> 
> > > > 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.";
> >
> > Yes, agreed.
> >
> > > > 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.
> >
> > If so, what's the purpose of the certificates in rats-support-structures?
> I assume
> > to use this module to get the certificates.
> 
> You need to store much common info about certificate (in the keystore
> draft), but you also need to know which TPM has what certificates (and this
> given to you by the <certificate-ref>).  Additionally different certificates
> might have different purposes with a TPM (here you populate
> <certificate-type>).
> 
> > > > 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.
> >
> > I'd like to say that if you using the tpm-name as the key for the output,
> there is
> > no need to require the certificate-name to be unique within a Attester.
> 
> See other thread.
> 
> > > > 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.
> >
> > Agree, a choice is much better.
> 
> This is not a problem, the question is then do we make this a case
> statement, or use XPATH.   Either one works.  Do you want to propose the
> YANG model change?
> 
> > > > 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.
> >
> > As I explained in another email, I feel like that adding the 'tpm-name' in
> the
> > output is useful, even if it is not used as the key.
> 
> Let's work this on the other thread.
> 
> > > > 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.
> >
> > But in current design, you need to fetch all TPMs info of an Attester. If
> the
> > output contains the tpm-name, you can only fetch this specific TPM info.
> 
> This is not correct.  You can fetch based on the <certificate-name>.
> 
> > > > 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?
> >
> > I also agree to remove these elements.
> 
> Thanks.  I have added the other authors to see if they have any issue with
> this?
> 
> Eric
> 
> 
> > > > 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