Re: [Rats] Attestation Timing Definitions

["Eric Voit (evoit)" <[e-mail]>]

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:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, March 11, 2020 6:10 AM
To: Laurence Lundblade <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
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=[e-mail] <mailto:evoit=[e-mail]> > 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