Re: [Rats] Attestation Timing Definitions

[Laurence Lundblade <[e-mail]>]

Hi Wei,

below...



> On Mar 11, 2020, at 7:24 PM, Panwei (William) <[e-mail]> wrote:
> 
>  
>  
> Regards & Thanks!
> 潘伟 Wei Pan
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>  
> From: Laurence Lundblade [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Thursday, March 12, 2020 1:33 AM
> To: Panwei (William) <[e-mail] <mailto:[e-mail]>>
> Cc: Eric Voit (evoit) <evoit=[e-mail] <mailto:evoit=[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Rats] Attestation Timing Definitions
>  
>  
> 
> 
> On Mar 10, 2020, at 8:20 PM, Panwei (William) <[e-mail] <mailto:[e-mail]>> 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?
> 


The main purpose of this diagram is to label points in time and time(e) is defined as an Attester signing Evidence, so choose another letter if it is not signing Evidence. 

I am working on mapping the time(*)’s into the time values in EAT so we know if we have the necessary claims defined in EAT to cover all the flows. 


If this is to be a Rats architecture diagram, then it’s about more than labeling points in time and should start talking about formats and names for that Attester signing that is not Evidence. Or maybe call it proprietary format or a TBD format. It also begs the question of the signing keys get set up and distributed, which is complicated stuff.

It seems pretty clear to me in the Rats architecture doc that in the Passport model that the Attester just passes Attestation Results through without further signing. I don’t think it should be called Passport if there is additional signing in the Attester.

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

Generally speaking, it seems OK to have an Attestation Result as a claim in Evidence. It means that some other Verifier did some of the work. The second Verifier would need some means to trust the first Verifier. I think my example of the first Verifier checking PCRs and HW measurements and the second one being an ML-based system fits here. I suspect we’re going to see all sorts of things in claims over the years, some wonderful, some horrible.

But, maybe that is not what is needed in this case, if you define the second signing to not be Evidence.


Anyway, the main thought is to change that time(e) to time (n) if it is not an Attester signing Evidence.


LL