Re: [Rats] Attestation Timing Definitions

"Panwei (William)" <william.panwei@huawei.com> Thu, 12 March 2020 02:24 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 DF9423A0496 for <rats@ietfa.amsl.com>; Wed, 11 Mar 2020 19:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8wmmXvIEEZP4 for <rats@ietfa.amsl.com>; Wed, 11 Mar 2020 19:24:38 -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 614FC3A045E for <rats@ietf.org>; Wed, 11 Mar 2020 19:24:38 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 32536FE44738B534FE3A for <rats@ietf.org>; Thu, 12 Mar 2020 02:24:36 +0000 (GMT)
Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 12 Mar 2020 02:24:35 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 12 Mar 2020 10:24:27 +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.1713.004; Thu, 12 Mar 2020 10:24:27 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Laurence Lundblade <lgl@island-resort.com>
CC: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Attestation Timing Definitions
Thread-Index: AdX3Ey664zQelNNbRnODHHrrt7v6I///kqkAgAASO4D//z7xkIACBfwA//78iWA=
Date: Thu, 12 Mar 2020 02:24:26 +0000
Message-ID: <1aa8a5c4038144f89ccf9d88a514fb6e@huawei.com>
References: <BYAPR11MB31256F11BD86730AF9D21B6CA1FF0@BYAPR11MB3125.namprd11.prod.outlook.com><CD539706-7F11-4FF1-8483-17F51329C014@island-resort.com> <BYAPR11MB312543840E706D6A0DBC8013A1FF0@BYAPR11MB3125.namprd11.prod.outlook.com> <817d60e7ab6b41d5bad81b7702002397@huawei.com> <870488EF-4981-44CA-A6B9-65E176D380FF@island-resort.com>
In-Reply-To: <870488EF-4981-44CA-A6B9-65E176D380FF@island-resort.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.152]
Content-Type: multipart/alternative; boundary="_000_1aa8a5c4038144f89ccf9d88a514fb6ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/TZsL8LnJmgKkuKGohh7tlGRJ-dk>
Subject: Re: [Rats] Attestation Timing Definitions
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: Thu, 12 Mar 2020 02:24:41 -0000


Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

From: Laurence Lundblade [mailto:lgl@island-resort.com]
Sent: Thursday, March 12, 2020 1:33 AM
To: Panwei (William) <william.panwei@huawei.com>
Cc: Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org>; rats@ietf.org
Subject: Re: [Rats] Attestation Timing Definitions




On Mar 10, 2020, at 8:20 PM, Panwei (William) <william.panwei@huawei.com<mailto:william.panwei@huawei.com>> wrote:

I think Ned’s email also has detailedly explained that the entity of Relying Party can also take on the role of Verifier, and in this case the Attester sends Evidence + previous Attestation Result to that entity, within that entity the Verifier role processes the Evidence and the Relying Party role consumes the two Attestation Results.

So, for a simple nonce-based Passport Model, the Attester just sends Attestation Result produced by the Verifier to the Relying Party, and the passport is simply the Attestation Result.
   .----------.                     .----------.  .---------------.
   | Attester |                     | Verifier |  | Relying Party |
   '----------'                     '----------'  '---------------'
      time(a)                             |               |
      time(b)                             |               |
        |                               time(c)           |
        |<-----nonce 1------------------time(d)           |
      time(e)                             |               |
        |------Evidence---------------->time(f)           |
        |                               time(g){@time(h)} |
        |<-----Attestation Result-------time(i)           |
        |                                 |             time(c’)
        |<-----nonce 2----------------------------------time(d’)
      time(e’)                            |               |
        |------Attestation Result---------------------->time(l)
        |                                 |             time(h)


This still doesn’t seem right. time(e’) indicates the Attester is signing and creating Evidence because of the definition of a time id label (e). Additionally, the only way to securely include nonce2 is if the Attester is signing which implies it is creating Evidence.
[Wei] The Attester sends messages to the RP, can it sign the whole message whose payload contains a ‘nonce’ field and a ‘Attestation Result’ field? Must it only be creating Evidence when the Attester is signing?

By my understanding in simple passport all the attester is doing is convey the exact bits it got from the Verifier to the RP. It can’t incorporate nonce2 in any meaningful way.

The only way to use nonce2 in the simple passport model is for it to go along side of nonce1 and arrive before time(e) to be part of Evidence. It could go direct to the Attester from the RP or it could go through the Verifier to the RP.
[Wei] I think this is also a reasonable case that the Evidence should include nonce from the RP and this may bring different considerations of timeliness.

Note that the latest EAT draft has an array of nonces rather than just one to accommodate this.





And for a complex model, which is the diagram 2 that Eric drew, the Attester will produce another Evidence to be sent together with the Attestation Result to the entity of Relying Party and Verifier.
For example, in the case of Eric’s draft (draft-voit-rats-trusted-path-routing), Evidence 1 is about the PCR value information, Attestation Result 1 says ‘boot processes have been verified successfully’, Evidence 2 is about time and changes since the Attester was last verified, Attestation Result 2 says ’time and changes are acceptable because only 5 minutes have passed since last verification and no changes happened’, then the Relying Party consumes these two Attestation Results to establish trust on the Attester.
   .----------.                     .------------.      .------------------------------------.
   | Attester |                     | Verifier 1 |      | Verifier 2     |     Relying Party |
   '----------'                     '------------'      '------------------------------------'
      time(a)                             |                   |                      |
      time(b)                             |                   |                      |
        |                               time(c)               |                      |
        |<-----nonce 1------------------time(d)               |                      |
      time(e)                             |                   |                      |
        |------Evidence 1-------------->time(f)               |                      |
        |                               time(g){@time(h)}     |                      |
        |<-----Attestation Result 1-----time(i)               |                      |
        |                                 |                   |                      |
      time(a’)                            |                   |                      |
      time(b’)                            |                   |                      |
        |                                 |                 time(c’)                 |
        |<-----nonce 2--------------------------------------time(d’)                 |
      time(e’)                            |                   |                      |
        |------Attestation Result 1 + Evidence 2----------->time(f')               time(l)
        |                                 |                 time(g’){@time(h’)}      |
        |                                 |                 time(i')-----AR 2----->time(l’)
        |                                 |                   |                    time(h)
        |                                 |                   |                    time(h’)

The flow seems technically correct, but a few comments:

- Seems like an awful lot of trouble just to add a nonce from the RP. If nonce2 can be made to arrive before time(e) either directly from the RP to the Attester or via Verifier 1 you get the same effect (I think) with much less trouble.
[Wei] Same as the previous one, nonce 2 arriving before time(e) is a reasonable case that should be considered.
Or maybe it is the job of Verifier 1 to check the PCRs and the job of Verifier 2 to impose the policy related to the age of Evidence 1? Maybe even Verifier 2 is a machine learning system run by a 3rd party while Verifier 1 is a dumber system that just knows about valid PCRs operated by the HW vendor.
[Wei] Yes, between the Attester and the RP there may be multiple Verifiers for different purposes.

- If using dual verifiers and using EAT, then Evidence 2 has three claims: nonce 2, issued at time and Attestation Result 1 as a submodule, right? Attestation Result 1 might be TPM format which implies EAT submods have to allow for TPM format attestations.
[Wei] I think it’s not appropriate to say Evidence contains Attestation Result, they may be transited in the same message, but they are semantically different. So the message sent by the Attester to the RP has three claims, of which the first two being seen as Evidence and the last one being seen as Attestation Result.

LL