Re: [Rats] Attestation Timing Definitions

"Panwei (William)" <william.panwei@huawei.com> Wed, 11 March 2020 03:20 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 DE5B33A103C for <rats@ietfa.amsl.com>; Tue, 10 Mar 2020 20:20: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 1u8i-AbumM1j for <rats@ietfa.amsl.com>; Tue, 10 Mar 2020 20:20: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 1588E3A103B for <rats@ietf.org>; Tue, 10 Mar 2020 20:20:38 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AB8F499823DBA9797D7B for <rats@ietf.org>; Wed, 11 Mar 2020 03:20:35 +0000 (GMT)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Mar 2020 03:20:13 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 11 Mar 2020 11:20:11 +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; Wed, 11 Mar 2020 11:20:11 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Attestation Timing Definitions
Thread-Index: AdX3Ey664zQelNNbRnODHHrrt7v6I///kqkAgAASO4D//z7xkA==
Date: Wed, 11 Mar 2020 03:20:10 +0000
Message-ID: <817d60e7ab6b41d5bad81b7702002397@huawei.com>
References: <BYAPR11MB31256F11BD86730AF9D21B6CA1FF0@BYAPR11MB3125.namprd11.prod.outlook.com><CD539706-7F11-4FF1-8483-17F51329C014@island-resort.com> <BYAPR11MB312543840E706D6A0DBC8013A1FF0@BYAPR11MB3125.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB312543840E706D6A0DBC8013A1FF0@BYAPR11MB3125.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.138.33.152]
Content-Type: multipart/alternative; boundary="_000_817d60e7ab6b41d5bad81b7702002397huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/a09bpAbmMIWQ0-NH4sW5hhXG2FM>
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: Wed, 11 Mar 2020 03:20:41 -0000

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)           |
        |<-----nonce1-------------------time(d)           |
      time(e)                             |               |
        |------Evidence---------------->time(f)           |
        |                               time(g){@time(h)} |
        |<-----Attestation Result-------time(i)           |
        |                                 |             time(c’)
        |<-----nonce2-----------------------------------time(d’)
      time(e’)                            |               |
        |------Attestation Result---------------------->time(l)
        |                                 |             time(h)


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')
More than Verifier 1 and Verifier 2 depicted in the diagram, between Attester and Relying Party there can be multiple Verifiers, whether within the same entity or not. I think this is an variant of the simple nonce-based passport model and the simple nonce-based passport model may be enough for timeliness consideration.

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

From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, March 11, 2020 6:10 AM
To: Laurence Lundblade <lgl@island-resort.com>
Cc: rats@ietf.org
Subject: Re: [Rats] Attestation Timing Definitions

Hi Laurence,

In-line with <eric>

From: Laurence Lundblade, March 10, 2020 5:05 PM
On Mar 10, 2020, at 1:09 PM, Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org<mailto:evoit=40cisco.com@dmarc.ietf.org>> wrote:

2. Nonce based Composite Evidence Passport.
This figure matches to the sequence diagram from Figure 3 of draft-voit-rats-trusted-path-routing
   ..----------.                     ..----------.  .---------------.
   | Attester |                     | Verifier |  | Relying Party |
   '----------'                     '----------'  '---------------'
      time(a)                             |               |
      time(b)                             |               |
        |                               time(c)           |
        |<-----nonce--------------------time(d)           |
      time(e)                             |               |
        |------Evidence---------------->time(f)           |
        |                               time(g){@time(h)} |
        |<-----Attestation Result-------time(i)           |
        |                                 |             time(c)
        |<-----nonce------------------------------------time(d)
      time(e)                             |               |
      time(j)                             |               |
      time(k)--Attestation Result + Evidence----------->time(l)
        |                                 |             time(h)

Something seems off here. By my understanding of the passport model, the Attestation Result is the passport and can only be created by a Verifier. This diagram seems to show the Attester creating there Attestation Result.

<eric> Agree that Attestation Results can only be created by a Verifier.  The reason this was on the diagram was that Figure 4 from draft-ietf-rats-architecture showed "Attestation Evidence" as part of this specific flow.  And it *is* part of the flow.  But there is other Evidence in the flow too.  To reflect this, I have added "+ Evidence" to the figure above.

Generalizing the question a bit, adding Evidence to a passport is a natural thing.  Think about your US passport.  Every time you go through a port, it is stamped with additional information.   And this becomes a part of that passport which subsequent countries can see.  But it wasn't information attested by the US.

Seems like one fix is to remove the second nonce and time(e) and say the the Attestation Result is exactly the same in both occurrences — classic passport where the attester just passes the result through.

The other fix is to have the Attester produce a second Attestation Evidence that includes the first Attestation Result, route that to a second verifier and then on to the RP. Then you have composition.

<eric> Hopefully my answer above clears this up.  There is more in draft-voit-rats-trusted-path-routing section 4.2 which addresses specific topics on this flow.

The main intent of this thread was to dive into the specific definitions of the timing definitions.  Perhaps if you have questions on this Section 4.21 flow, comment on the thread about "draft-voit-rats-trusted-path-routing"?

I don’t think Attesters can produce Attestation Results.

<eric>  Agree they do not produce Attestation Results.

Eric

LL