Re: [Rats] Attestation Timing Definitions

"Panwei (William)" <william.panwei@huawei.com> Wed, 11 March 2020 12:46 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 DEBE63A1887 for <rats@ietfa.amsl.com>; Wed, 11 Mar 2020 05:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 Dn9c-BY3lRd7 for <rats@ietfa.amsl.com>; Wed, 11 Mar 2020 05:46:11 -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 19A283A185E for <rats@ietf.org>; Wed, 11 Mar 2020 05:46:11 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3AEBB192FB4A0B1444FD for <rats@ietf.org>; Wed, 11 Mar 2020 12:46:08 +0000 (GMT)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Mar 2020 12:46:03 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) 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 20:46:00 +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 20:46:00 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Attestation Timing Definitions
Thread-Index: AdX3Ey664zQelNNbRnODHHrrt7v6I///kqkAgAASO4D//z7xkIABsrUA//94r9A=
Date: Wed, 11 Mar 2020 12:46:00 +0000
Message-ID: <a2011a2dc5984e229c967bb07d45b6bd@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> <BL0PR11MB31227E2543173E166F763C66A1FC0@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB31227E2543173E166F763C66A1FC0@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.138.33.152]
Content-Type: multipart/alternative; boundary="_000_a2011a2dc5984e229c967bb07d45b6bdhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/D4NI4BAWPNFFWp3YDY_skMIILz4>
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 12:46:19 -0000

Hi Eric,

I agree there is no need to break out what is in the Verifier2+Relying Party. But it may be confusing when you just say sending Evidence to Relying Party, so it’s better to have some text clarifying that.

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

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Wednesday, March 11, 2020 8:35 PM
To: Panwei (William) <william.panwei@huawei.com>; Laurence Lundblade <lgl@island-resort.com>
Cc: rats@ietf.org
Subject: RE: [Rats] Attestation Timing Definitions

Hello Wei,

From: Panwei (William), March 10, 2020 11:20 PM
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)

<eric> Agree this is a valid model.  It is ½ way between Models (1) & (2) from the original email.  It prefer this model to the simple Passport Model (1) from Figure 4 of draft-ietf-rats-architecture.  I have been assuming Figure 4 simplified away the nonces.


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.

<eric> I agree that this is a viable variant.   Adding the numbers and the 'single quotes' to the second instance of the letters does provide useful specificity.   For simplicities sake, I probably wouldn't break out what is in the Verifier2+Relying Party.

Eric

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<mailto:lgl@island-resort.com>>
Cc: rats@ietf.org<mailto: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