Subject: [Rats] Attestation Timing Definitions

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Mar 2020 20:09:18 +0000

An interesting RATS discussion relates to which times might be of interest.
Specifically, should we define times of well-known attestation events, and
relate these times to the Topology model sequence diagrams contained within
Section 5 of draft-ietf-rats-architecture?  

I believe we should do this.  It provides us the option of correlating
event timings across various use cases. To help this discussion progress,
below are some strawman time definitions which might be interesting to
consider.  Each of these times is then used further below as part of a
sequence diagram which can match to a diagram from
draft-ietf-rats-architecture.

Strawman Time Definitions: 

Feel free to change/refine the definitions in the table below or add new
definitions.  Just please don't alter the current letter id assignment as
these ids are used later in the sequence diagrams.  Also note that these
definitions below could related to an absolute clock time such as
Coordinated Universal Time,  or be defined relative to some other timestamp
or timeticks counter.

id

name

strawman definition

time(a)

Time of claim generation

When a particular claim was created, or when any values within that claim
change

time(b)

Time of Attester awareness

When an Attester or Attester Component receives a claim

time(c)

Time of nonce generation

When a random number not predictable to an Attester is generated

time(d)

Time of nonce delivery

When the random number becomes known to Attester

time(e)

Time of Attester assembly

When an Attester marshals Evidence. This Evidence typically consists of one
or more sets of claims. Each set might be signed by signed by an Attester
Component.  Additionally some new claims might be generated as part of this
assembly.

time(f)

Time of Verifier Receipt

When a set of Evidence is received by a Verifier

time(g)

Time of Results

When Attestation Results were generated by a Verifier

time(h)

Time of Results expiry

When a Verifier states that a specific instance of Attestation Results
should no longer be accepted

time(i)

Time of Results delivery

When Attestation Results are pushed from a Verifier

time(j)

Time of passport assembly

Time when Evidence that includes Attestation Results is assembled in a
format digestible by a Relying Party

time(k)

Time of Evidence to Relying Party

When an Attester pushes Evidence to a Relying Party.  This evidence could
potentially include a Verifier's Attestation Results.

time(l)

Time of Relying Party receipt

When the Relying party receives Evidence from an Attester.

Matching Definitions to Architecture Figures

1.Simple Passport Model. 

This figure matches to the sequence diagram from Figure 4 of
draft-ietf-rats-architecture.

   .----------.                     .----------.  .---------------.

   | Attester |                     | Verifier |  | Relying Party |

   '----------'                     '----------'  '---------------'

      time(a)                             |               |

      time(b)                             |               |

      time(e)                             |               |

        |------Evidence---------------->time(f)           |

        |                               time(g)           |

        |                               time(j)           |

        |<-----Attestation Result-------time(i)           |

      time(k)--Attestation Result---------------------->time(l)

        |                                 |               |

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---------------------->time(l)

        |                                 |             time(h)

3. Simple Background Check Model.  

This figure matches to the sequence diagram from  Figure 5 of
draft-ietf-rats-architecture.

.----------.         .---------------.              .----------.

| Attester |         | Relying Party |              | Verifier |

'----------'         '---------------'              '----------'

   time(a)                   |                           |

   time(b)                   |                           |

   time(e)                   |                           |

   time(k)---Evidence------->|                           |

                             |------Evidence---------->time(f)

                             |                         time(g){@time(h)}

                           time(l)<-Attestation Result-time(i)

                           time(h)                       |

4. Nonce based Background Check Model

For completeness

.----------.         .---------------.              .----------.

| Attester |         | Relying Party |              | Verifier |

'----------'         '---------------'              '----------'

   time(a)                   |                           |

   time(b)                   |                           |

     |                     time(c)                       |

     |<------nonce---------time(d)                       |

   time(e)                   |                           |

   time(k)---Evidence------->|                           |

                             |------Evidence---------->time(f)

                             |                         time(g){@time(h)}

                           time(l)<-Attestation Result-time(i)

                           time(h)                       |

                             |                           |

Thanks,

Eric

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 10 Mar 2020 14:05:04 -0700

> On Mar 10, 2020, at 1:09 PM, Eric Voit (evoit) <evoit=[email-masked]> wrote:
> 
> This figure matches to the sequence diagram from Figure 3 of draft-voit-rats-trusted-path-routing
>    ..----------.                     ..----------.  .---------------.

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. 

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.

I don’t think Attesters can produce Attestation Results.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 10 Mar 2020 21:26:21 +0000

I second Laurence’s point about Attester sending AR to a RP or Attester sending Evidence to RP.
The use case would benefit from separating ‘entity’ from ‘role’. The entity implementing the RP also implements a Verifier (V2) (This is because Evidence at time k is different from Evidence at time f.

Might be better to name them Evidence-E1 (at time f) and Evidence-E2 (at time k). Now the diagram can show E2 from Attester to Verifier-V2.

The RP is accepting two inputs AR1 (at time i) and AR2 (at time h). Note: AR at time k is actually mislabeled Evidence-E2, but also includes a “passport”(?) which is AR1.

What isn’t shown is AR2 which passes from V2 to RP. This is uninteresting from a standards perspective because it is a local flow. It is interesting from an architecture perspective because the third entity needs policies for both Evidence and A.Results and has to account for all the time variables.

-Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Tuesday, March 10, 2020 at 2:05 PM
To: "Eric Voit (evoit)" <evoit=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Attestation Timing Definitions

On Mar 10, 2020, at 1:09 PM, Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>> wrote:

   ...----------.                     ...----------.  .---------------.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Mar 2020 22:10:19 +0000

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=[email-masked] <mailto:evoit=[email-masked]> > wrote:

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                                 |             time(c)

      time(e)                             |               |

      time(j)                             |               |

      time(k)--Attestation Result + Evidence----------->time(l)

        |                                 |             time(h)

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

<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"?

<eric>  Agree they do not produce Attestation Results.  

Eric

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 11 Mar 2020 03:20:10 +0000

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)

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.

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

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, March 11, 2020 6:10 AM
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Attestation Timing Definitions

Hi Laurence,

In-line with <eric>

Eric

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 11 Mar 2020 03:30:17 +0000

A minor update about the definition of expiry time：

time(h)

Time of Results expiry

Time stated by a Verifier when a specific instance of Attestation Results should no longer be accepted by a Relying Party

1.Simple Passport Model.
This figure matches to the sequence diagram from Figure 4 of draft-ietf-rats-architecture.

I think in this case the expiry time can also be included.

Regards & Thanks!
潘伟 Wei Pan

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 11 Mar 2020 12:35:12 +0000

Hello Wei,

From: Panwei (William), March 10, 2020 11:20 PM

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                                 |             time(c’)

      time(e’)                            |               |

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

      time(a)                             |                   |                      |

      time(b)                             |                   |                      |

        |                               time(c)               |                      |

      time(e)                             |                   |                      |

        |                               time(g){@time(h)}     |                      |

        |                                 |                   |                      |

      time(a’)                            |                   |                      |

      time(b’)                            |                   |                      |

        |                                 |                 time(c’)                 |

      time(e’)                            |                   |                      |

        |                                 |                   |                    time(h)

        |                                 |                   |                    time(h')

<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

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, March 11, 2020 6:10 AM
To: Laurence Lundblade <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Rats] Attestation Timing Definitions

Hi Laurence,

In-line with <eric>

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                                 |             time(c)

      time(e)                             |               |

      time(j)                             |               |

        |                                 |             time(h)

Eric

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 11 Mar 2020 12:43:36 +0000

Hello Wei,

From: Panwei (William), March 10, 2020 11:30 PM

time(h)

Time of Results expiry

<eric> Agree with text tweak.

1.Simple Passport Model. 

      time(a)                             |               |

      time(b)                             |               |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                               time(j)           |

        |                                 |             time(h)

<eric> I agree time(h) can be supported by this case.   If these timing diagrams ever make it into a rats-draft then we will need to determine which subset of variants to present as many variants exist. 

Eric

Regards & Thanks!

潘伟 Wei Pan

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 11 Mar 2020 12:46:00 +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

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Wednesday, March 11, 2020 8:35 PM
To: Panwei (William) <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: RE: [Rats] Attestation Timing Definitions

Hello Wei,

Eric

Regards & Thanks!
潘伟 Wei Pan

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, March 11, 2020 6:10 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Attestation Timing Definitions

Hi Laurence,

In-line with <eric>

Eric

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 11 Mar 2020 12:58:21 +0000

Hi Ned,

From: Smith, Ned, March 10, 2020 5:26 PM

<eric> Agree.  Hopefully my answer to Laurence clarified that.   If at some point we desire to place a sequence diagram into a draft, then we absolutely need to ensure each row is easily referenceable.

<eric> This is fine with me.  Right now I show "Attestation Result + Evidence".   But there is actually more than that in the variant of the Passport from draft-voit-rats-trusted-path-routing.

<eric> Agree.  Hopefully my answer to Laurence clarified that.   

<eric> Wei's email contains a good depiction of this flow.

Eric

-Ned

From: RATS <[email-masked] <mailto:[email-masked]> > on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, March 10, 2020 at 2:05 PM
To: "Eric Voit (evoit)" <evoit=[email-masked] <mailto:evoit=[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Attestation Timing Definitions

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                                 |             time(c)

      time(e)                             |               |

      time(j)                             |               |

        |                                 |             time(h)

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 11 Mar 2020 10:33:16 -0700

> On Mar 10, 2020, at 8:20 PM, Panwei (William) <[email-masked]> wrote:
> 

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.

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

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 12 Mar 2020 02:24:26 +0000

Regards & Thanks!
潘伟 Wei Pan

From: Laurence Lundblade [mailto:[email-masked]]
Sent: Thursday, March 12, 2020 1:33 AM
To: Panwei (William) <[email-masked]>
Cc: Eric Voit (evoit) <evoit=[email-masked]>; [email-masked]
Subject: Re: [Rats] Attestation Timing Definitions

On Mar 10, 2020, at 8:20 PM, Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:

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

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

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 12 Mar 2020 10:04:59 -0700

Hi Wei,

below...

> On Mar 11, 2020, at 7:24 PM, Panwei (William) <[email-masked]> wrote:
> 
>  
>  
> Regards & Thanks!
> 潘伟 Wei Pan
> From: Laurence Lundblade [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Panwei (William) <[email-masked] <mailto:[email-masked]>>
> Cc: Eric Voit (evoit) <evoit=[email-masked] <mailto:evoit=[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Mar 10, 2020, at 8:20 PM, Panwei (William) <[email-masked] <mailto:[email-masked]>> wrote:
>  

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.

> 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 successf…

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 12 Mar 2020 18:49:10 +0000

Hi Laurence,

From: Laurence Lundblade, March 12, 2020 1:05 PM

Hi Wei,

below...

On Mar 11, 2020, at 7:24 PM, Panwei (William) <[email-masked] <mailto:[email-masked]> > wrote:

Regards & Thanks!

潘伟 Wei Pan

From: Laurence Lundblade [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, March 12, 2020 1:33 AM
To: Panwei (William) < <mailto:[email-masked]> [email-masked]>
Cc: Eric Voit (evoit) < <mailto:evoit=[email-masked]> evoit=[email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Rats] Attestation Timing Definitions

On Mar 10, 2020, at 8:20 PM, Panwei (William) < <mailto:[email-masked]> [email-masked]> wrote:

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                                 |             time(c’)

      time(e’)                            |               |

        |                                 |             time(h)

 

<eric> time(e) may have a signing event.  E.g., a nonce may be combined evidence in a TPM proves the evidence was available on specific attester no later that time(e).   This possible action of signing has been included within the originally proposed definition.

 

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. 

<eric> The original purpose of the thread was the proper naming of time points.  The sequence diagrams are shown to help demonstrate how the times might be used.    

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.

<eric> I absolutely agree that all the signing, etc. needs to be addressed.  This is why drafts like draft-fedorkow-rats-network-device-attestation and  draft-voit-rats-trusted-path-routing exist.   Such discussions are best made in those deployment contexts, rather than in the architecture draft.  That is unless we are looking to significantly increase the complexity of draft-ietf-rats-architecture.  

<eric>  In the case Wei is showing,  the Attester would take the signature from the Attestation Results time(i) and nonce from time(d') and sign these within a TPM.  This becomes a standalone element delivered parallel with the original Attestation Results from time(i).  

If simply reusing "Passport" is confusing, the wording in the RATS Architecture document need to be updated to cover cases where the passport is enhanced like above.   Do we want to call this an "Extended Passport Model", a "Stamped Passport Model", something else?   

 

   ..----------.                     ..------------.      ..------------------------------------.

      time(a)                             |                   |                      |

      time(b)                             |                   |                      |

        |                               time(c)               |                      |

      time(e)                             |                   |                      |

        |                               time(g){@time(h)}     |                      |

        |                                 |                   |                      |

      time(a’)                            |                   |                      |

      time(b’)                            |                   |                      |

        |                                 |                 time(c’)                 |

      time(e’)                            |                   |                      |

        |                                 |                   |                    time(h)

        |                                 |                   |                    time(h’)

<eric> I think it is Evidence

<eric> It is an Attester signing Evidence.

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 12 Mar 2020 15:41:36 -0700

Then the net net is that this diagram needs fixing:

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=[email-masked]> wrote:
> 
> Hi Laurence,
>  
> On Mar 11, 2020, at 7:24 PM, Panwei (William) <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
>  
> Regards & Thanks!
> 潘伟 Wei Pan
...

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 13 Mar 2020 18:10:39 +0000

The “Extended|stamped Passport Model” is a similar pattern to the “Composite Device” scenario where Evidence isn’t simply forwarded by a lead Attester but the lead Attester supplies a ‘transited evidence’ claim as part of the additional Evidence it supplies.

I’m not sure RATS arch intended for the various ‘models’ to codify data structures e.g. a ‘Passport’ or if the intent is merely to observe the flow of Evidence and Attestation Results according to the named model. Maybe there is a similar need for a special type of claim that reinforces an expected flow or sequencing between roles? If in the Passport Model the Verifier supplies Attestation Results to the Entity that hosts the originating Attester role, then should the Verifier or Attester do something in the Attestation Results or in newly minted Evidence to acknowledge this?

For example, the Attester could create new Evidence with a ‘transited attestation result’ claim. The entity hosting the Relying Party might then host a Verifier role that specializes in checking for Passport Model compliance by verifying the ‘transited Attestation Results’ claim.  Possibly, the Relying Party has a policy that allows/disallows use of a Passport model (or a hybrid). Simply defining a ‘transited attestation results’ claim seems to address all possible models whether Passport, Background Check or some hybrid we haven’t though of yet.

Does anyone disagree?

-Ned

Copied text from below:
“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.
<eric>  In the case Wei is showing,  the Attester would take the signature from the Attestation Results time(i) and nonce from time(d') and sign these within a TPM.  This becomes a standalone element delivered parallel with the original Attestation Results from time(i).

If simply reusing "Passport" is confusing, the wording in the RATS Architecture document need to be updated to cover cases where the passport is enhanced like above.   Do we want to call this an "Extended Passport Model", a "Stamped Passport Model", something else?  “

From: RATS <[email-masked]> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]>
Date: Thursday, March 12, 2020 at 11:49 AM
To: Laurence Lundblade <[email-masked]>, "Panwei (William)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Attestation Timing Definitions

Hi Laurence,

Hi Wei,

below...

On Mar 11, 2020, at 7:24 PM, Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:

Regards & Thanks!
潘伟 Wei Pan

From: Laurence Lundblade [mailto:[email-masked]]
Sent: Thursday, March 12, 2020 1:33 AM
To: Panwei (William) <[email-masked]<mailto:[email-masked]>>
Cc: Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Attestation Timing Definitions

   ...----------.                     ...------------.      ...------------------------------------.

Eric

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 13 Mar 2020 18:21:04 +0000

See inline. Nms>

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Thursday, March 12, 2020 at 10:05 AM
On Mar 10, 2020, at 8:20 PM, Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:

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?
Nms> Signing/enveloping Attestation Results inside of new Evidence seems to be semantically similar to asserting a ‘transited Attestation Results’ claim. The idea is the claim asserts that its “saw this AR”. Not that it checked it / consumed it necessarily. The claim needs to disambiguate which Attestation Result. Hence, identity and replay are considerations. Enveloping the Attestation Result message is one way to identify it. There could be other ways to do that. Replay is already a consideration for Evidence. The nonce and timestamp claims included with the ‘transited AR’ claim might collectively address this.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 13 Mar 2020 21:33:57 +0000

Hi Ned,

I fully agree that there are similarities between "Stamped Passport Model" and "Composite Device".  For both, a Verifier needs to understand the implicit trust relationships between the various signed claims.

The way I internalize your thinking below is that we need glue that can express relationships between independently signed claims.  And beyond the 'transited Attestation Result' claim, I also believe there will be a 'sequence of claim creation' (i.e., a 'provable relative timing') claim.

Thinking of some possible future RATS drafts, I suspect that some claim language could be adopted to express these compositions.  With such a claim language, even structures paralleling those of DICE are conceivable.  Also conceivable are needs for the trusted discovery of valid Attester + Verifier structures by Relying Parties.  

In the short term, I don't think these complexities need to be included in the architecture document.  To make progress, I am simply asking that the terminology of the architecture document doesn't marginalize or make harder to describe the types of end-to-end architectures being explored with "Composite Device" and "Stamped Passport".

Per your note below on codifying the term "Passport".  You are right that the architecture now just describes the "Passport Model".   As long as somebody doesn't later try to define a "Passport", and then claim that a "Stamped Passport" is not really a  valid type of "Passport", I am good.

Eric

From: Smith, Ned, March 13, 2020 2:11 PM

Does anyone disagree?

-Ned

Copied text from below:

 

From: RATS <[email-masked] <mailto:[email-masked]> > on behalf of "Eric Voit (evoit)" <evoit=[email-masked] <mailto:evoit=[email-masked]> >
Date: Thursday, March 12, 2020 at 11:49 AM
To: Laurence Lundblade <[email-masked] <mailto:[email-masked]> >, "Panwei (William)" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Attestation Timing Definitions

Hi Laurence,

Hi Wei,

below...

 

Regards & Thanks!

潘伟 Wei Pan

 

      time(a)                             |               |

      time(b)                             |               |

        |                               time(c)           |

      time(e)                             |               |

        |                               time(g){@time(h)} |

        |                                 |             time(c’)

      time(e’)                            |               |

        |                                 |             time(h)

 

 

 

 

      time(a)                             |                   |                      |

      time(b)                             |                   |                      |

        |                               time(c)               |                      |

      time(e)                             |                   |                      |

        |                               time(g){@time(h)}     |                      |

        |                                 |                   |                      |

      time(a’)                            |                   |                      |

      time(b’)                            |                   |                      |

        |                                 |                 time(c’)                 |

      time(e’)                            |                   |                      |

        |                                 |                   |                    time(h)

        |                                 |                   |                    time(h’)

 

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 27 Mar 2020 14:41:40 -0700

Here’s my first pass at incorporating the timing definitions into EAT. A PR is here <https://github.com/ietf-rats-wg/eat/pull/59>.

Acquisition time — time(a) — This is the time that the value for a claim came to be, for example the time a measurement or a sample was taken. This value may be stored for a long time before the Attester collects it. Examples include a GPS sample taken before entering a basement, a SW measurement taken at boot or a SW integrity measurement taken by a run time integrity checker (RTIC).

Each claim, or even sub parts of a claim can have its own Acquisition Time. There is no generic means for time stamping a claim, instead the definition of each claim for which Acquisition Time is important should include a data item for an Acquisition Time.

This corresponds to Eric’s time(a). Maybe you’ll change my mind, but time(b) doesn’t seem important.

Time(c) and time(d) don’t need to be recorded in attestation evidence or results.

Issued At Time — time(e) — This is the time that a token is created, the time when all the claims are collected and the token is signed. For simplicity, it is assumed that all the claims are collected at the same time and that is the same time that the token is signed.  Each submodule may have have an issued at time. Though it is not expected to be common, this makes submodules a way to group claims that are collected together at a different time.

The Acquisition Time can be absolute or relative. If relative, it is to time(e) and is filled in by the attester when collecting the claims values.

The Issued At Time is always absolute or absent, never relative (If we allow it to be relative, we have add the complexity of distinguishing the collection time from the signing time and assume the signing time is the conveyance time as we don’t want any claims that are not signed).

Time(g) is IssuedAtTime for the attestation results.

The Expiration and Not-Before Time claims typically only go in the Attestation Result, the output of the Verifier, but they may occur in Attestation Evidence too. Like the Issued At Time, they are per submodule and absolute. When they go in the Attestation Result, they represent some recommendation by the Verifier as to the validity period, typically how long until the token is no longer considered trustworthy. It is more meaningful for the Verifier to make this recommendation than for an Attester to claim this about itself.

Expiration is time(h).

I don’t think time(i) or time(l) needs to be recorded.

Whether time(k) needs to be recorded depends on what passport assembly is.

LL

> On Mar 13, 2020, at 2:33 PM, Eric Voit (evoit) <evoit=[email-masked]> wrote:
> 
> Hi Ned,
>  
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of "Eric Voit (evoit)" <evoit=[email-masked] <mailto:evoit=[email-masked]>>
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>, "Panwei (William)" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>    ...----------.                     ...----------.  ..---------------.
>    ....----------.                     ....------------.      ....------------------------------------.
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats