Re: [Rats] Attestation Timing Definitions

[Laurence Lundblade <[e-mail]>]

> On Mar 10, 2020, at 8:20 PM, Panwei (William) <[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)           |
>         |<-----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)


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. 

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.

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

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

LL