[Rats] EAT timestamps (was Re: Attestation Timing Definitions)

[Laurence Lundblade <[e-mail]>]

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=[e-mail]> wrote:
> 
> 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
> 
> 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 <[e-mail] <mailto:[e-mail]>> on behalf of "Eric Voit (evoit)" <evoit=[e-mail] <mailto:evoit=[e-mail]>>
> Date: Thursday, March 12, 2020 at 11:49 AM
> To: Laurence Lundblade <[e-mail] <mailto:[e-mail]>>, "Panwei (William)" <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Rats] Attestation Timing Definitions
>  
> Hi Laurence,
>  
> From: Laurence Lundblade, March 12, 2020 1:05 PM
> 
> 
> Hi Wei,
>  
> below...
> 
> 
> 
> On Mar 11, 2020, at 7:24 PM, Panwei (William) <[e-mail] <mailto:[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. 
> <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.
>  
> 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. 
> <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.  
>  
> 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?   
> 
> 
> 
>  
> 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.
> <eric> I think it is Evidence
>  
>  
> Anyway, the main thought is to change that time(e) to time (n) if it is not an Attester signing Evidence.
> <eric> It is an Attester signing Evidence.
> 
> Eric
>  
>  
> LL
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats