Subject: [Rats] Age Claim in EAT

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 29 Jul 2020 08:37:55 +0000

Hi Laurence, Hi all,

How does the age claim work?

The spec says "represents the number of seconds that have elapsed since the token was created".

By creating a token you also protect the claims with a signature and hence you cannot change the content of the claims anymore (without breaking the signature).

Hence, here "creating a token" must mean something different. I suspect it means when certain values have been collected from the device and before the token with the signature was put together. Correct?

If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better go (somehow) with specific claims where the time difference between the collection of the data and the signature generation matters. I also wonder whether the number of seconds matter and whether you really want to communicate something more abstract, such as "I created a hash over the firmware during boot time" rather than "I created the hash over the firmware in real-time when I was asked".

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 29 Jul 2020 11:11:08 +0200

Hi Hannes,

in the scope of Evidence:

Signing a CWT structure is creating an EAT. This event is defined as 
time(EG) here: 
https://tools.ietf.org/html/draft-ietf-rats-architecture-05#appendix-A

"Creating a token" would mean "Evidence Generation", for example.

Age also is a time interval based on a time unit (units that apply to 
Henk are years, I claim that Henk's age is 21, of course. Trust in 
Henk's Claims can be established via Endorsements). Age is a time 
interval expressed as a duration. That means that the beginning of that 
time interval is set as zero (an epoch) and then counts the time units.

The semantics of age in EAT are:

the epoch is time(EG) and the unit is seconds.
This only works, if time sources for relative time-counters are 
available, of course.

Collection of Claims - time(CC) was proposed to the architecture, but 
did not find consensus yet (we are working on time(AA), though, the time 
at which the Attester becomes aware of a changes value in the Target 
Environment right now).

But! there is time(VG), the Value Generation. This time can often only 
be inferred or approximated (in contrast to time(AA)), but it is the 
best we have defined right now in the context of:

> If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better go (somehow) with specific claims where the time difference between the collection of the data and the signature generation matters.

As a note: We have not talked at all before about the common concept of 
"latches" or stage transitions... this is an important concept that does 
capture the "this event has happened" (before/after a defined event) and 
represents strong security implications that are not included in the 
RATS architecture today. Would that maybe help in your context?

Viele Grüße,

Henk

On 29.07.20 10:37, Hannes Tschofenig wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 30 Jul 2020 08:28:35 +0000

Thanks for the clarification, Henk.

Since I don't know what information consumers of Entity Attestation Tokens really need to make decisions I am not sure whether the current functionality is sufficient already or not. To me as a reader it appears underspecified.  At a minimum a reference to Appendix A of the RATS architecture document in the EAT spec would be useful.

Ciao
Hannes

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: Wednesday, July 29, 2020 11:11 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Rats] Age Claim in EAT

Hi Hannes,

Age also is a time interval based on a time unit (units that apply to Henk are years, I claim that Henk's age is 21, of course. Trust in Henk's Claims can be established via Endorsements). Age is a time interval expressed as a duration. That means that the beginning of that time interval is set as zero (an epoch) and then counts the time units.

the epoch is time(EG) and the unit is seconds.
This only works, if time sources for relative time-counters are available, of course.

Collection of Claims - time(CC) was proposed to the architecture, but did not find consensus yet (we are working on time(AA), though, the time at which the Attester becomes aware of a changes value in the Target Environment right now).

> If that's the case, I wonder whether it would also make sense to take into account that different information may be collected at a different point in time and hence the age indication would better…

As a note: We have not talked at all before about the common concept of "latches" or stage transitions... this is an important concept that does capture the "this event has happened" (before/after a defined event) and represents strong security implications that are not included in the RATS architecture today. Would that maybe help in your context?

Viele Grüße,

Henk

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 30 Jul 2020 10:01:02 +0000

Interesting.

We've implemented something similar (or at least tried to be compliant with the spec as much as we can)

For each claim we have at minimum the time of the claim request (R) by the attestating authority, the time of claim creation (C) by the reporting authority and the time of receipt (T) by the attesting authority.

One of the attestation rules is thus: R < C < T

Another would then deal with timliness of the obtaining of the claim, eg:   T -R < \epsilon

I agree that some idea of the latches/stage-transitions would help.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Hannes Tschofenig <[email-masked]>
Sent: 30 July 2020 11:28
To: Henk Birkholz <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Rats] Age Claim in EAT

Ciao
Hannes

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: Wednesday, July 29, 2020 11:11 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Rats] Age Claim in EAT

Hi Hannes,

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 30 Jul 2020 12:29:31 -0700

In concept, age is the difference between time(VG) and time(EG) as described in RATS Architecture Appendix A.

I think time(EG) is when the token is signed (or otherwise cryptographically protected). I’m surprised that Appendix A doesn’t define it as that important moment. Claims can change after time(EG).

After Eric created the timing diagrams for architecture I re-thought the age claim. I don’t think it is a general independent claim, but rather is an attribute of individual claims, for example the age of a location or of a SW measurement.  PR #59 <https://github.com/ietf-rats-wg/eat/pull/59/files> removes it as a top-level claim and adds an age item to the location claim.

There was some discussion between these two options:
  - Define a general way to add attributes like age (or time stamp) to any claim — A general claim decoration mechanism
  - Add an age (or time stamp) field to claims that need it

I’ve tended away from general attributes to keep code size and complexity down.

But what I really want to know is which manufacturer Endorses Henk, what is in his Endorsement and whether it is signed by a public key pair or a symmetric key. :-)

LL

> On Jul 29, 2020, at 2:11 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Hannes,
> 
> Signing a CWT structure is creating an EAT. This event is defined as time(EG) here: https://tools.ietf.org/html/draft-ietf-rats-architecture-05#appendix-A
>