Re: [Rats] Attestation Timing Definitions

Laurence Lundblade <lgl@island-resort.com> Thu, 12 March 2020 22:41 UTC

Return-Path: <lgl@island-resort.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 D643A3A0918 for <rats@ietfa.amsl.com>; Thu, 12 Mar 2020 15:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 qW65b6dg4fXi for <rats@ietfa.amsl.com>; Thu, 12 Mar 2020 15:41:37 -0700 (PDT)
Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) (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 523533A0913 for <rats@ietf.org>; Thu, 12 Mar 2020 15:41:37 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id CWWGjmA9ykEGdCWWGjHETj; Thu, 12 Mar 2020 15:41:36 -0700
X-CMAE-Analysis: v=2.3 cv=b6nMHeOx c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=K6EGIJCdAAAA:8 a=X0oUTWqLaGT5tGQ7ADcA:9 a=QEXdDO2ut3YA:10 a=zDh1Rca2SS7xkItnl24A:9 a=zy3aI5BceQOd7FCn:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <19331E26-5F18-4F37-AD4D-FEEB895B80A7@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_44021690-5C5F-4544-A352-7B9D81EDBA2C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Mar 2020 15:41:36 -0700
In-Reply-To: <BL0PR11MB312205B217AECC141105F685A1FD0@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "Panwei (William)" <william.panwei@huawei.com>, "rats@ietf.org" <rats@ietf.org>
To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>
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> <1aa8a5c4038144f89ccf9d88a514fb6e@huawei.com> <52200DF9-4B74-4408-A209-18B42DB48ACF@island-resort.com> <BL0PR11MB312205B217AECC141105F685A1FD0@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfOZ6nnjE4uK/uejyDZySrel5fK5/gjHpMTegGPma7jS+to7isbz+ahUZxsztsFo4+eGFWW/EiHEdyYQB47XRseJRj/HO2931WdzRSi2FFZsytMwHXEfA sapa6YZM78QysUElmiklCQSD6g2ZIL6tZRh1zmc5hOkiYhmEQj05g++/Jt1FcWDGsZTNAfqFniaDBDw8q1eCVp47QNkDwFBlSc+KiXAYPpLpSW/WCSfGPLoi NpCDwkFTX95MYD29PHkFZg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/-AsqHK-HoS1qQf-WpVR7-0B90O8>
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 22:41:39 -0000

Then the net net is that this diagram needs fixing:

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

Option 1) fix: change time(e’) to time(n) if what’s being signed at that time is NOT evidence

Option 2) fix: leave it as time(e’) and change the diagram so what is being signed IS evidence. This will involve adding a Verifier and such making it look a lot like the other diagram.


My main objective here is to understand what needs to go into EAT so it can represent Attestation Results well. I also care about the architecture document. The details of trusted path I leave in your hands. :-)

LL




> On Mar 12, 2020, at 11:49 AM, Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hi Laurence,
>  
> From: Laurence Lundblade, March 12, 2020 1:05 PM
> 
> Hi Wei,
>  
> below...
> 
> 
> On Mar 11, 2020, at 7:24 PM, Panwei (William) <william.panwei@huawei.com <mailto:william.panwei@huawei.com>> wrote:
>  
>  
>  
> Regards & Thanks!
> 潘伟 Wei Pan
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>  
> From: Laurence Lundblade [mailto:lgl@island-resort.com <mailto:lgl@island-resort.com>] 
> Sent: Thursday, March 12, 2020 1:33 AM
> To: Panwei (William) <william.panwei@huawei.com <mailto:william.panwei@huawei.com>>
> Cc: Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org <mailto:evoit=40cisco.com@dmarc.ietf.org>>; rats@ietf.org <mailto: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 |
...