Subject: Re: [Rats] Thinking about Attestation Results

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Mar 2022 12:07:54 -0500

Laurence Lundblade <[email-masked]> wrote:
    > This is an attempt to step back and think about Attestation Results
    > (AR) in a broad and general way.

    > TLDR: RATS ought to focus on the semantics of the stuff in AR, not the
    > encoding or securing of it.

Is there a specific action that results from this discussion?

    > I think name-value pair claims are a good way to structure most AR.

    > AR Contents
    > This is the output from SW measurements verification, device identity,
    > claims passed through from the
    > Evidence, the general Verification results and such.

    > This is what really matters in RATS! They exist whether or not the RP
    > is combined with the Verifier. This is THE output from RATS.

Yes, I agree.

    > Below is a picture from from the RATS architecture document. At this
    > point it seems kind of a mis
    > characterization because it doesn’t mention JSON over TLS and/or Web APIs for AR.

But, it was never intended to be complete, but rather to show that the
translation of Evidence and AR was the problem of the Verifier.

I think that you are trying to create a normative greenfield specification.

I encourage you to do that, but caution that it has to be done with a
specific target in mind. Otherwise, you wind up repeating the disasters of
the 1980s known as ITU-T/OSI/ASN.1.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Mar 2022 22:47:36 +0000

I agree that we should focus on the semantics of the AR Contents.   Ar4si has a section on "Design Principles" of AR Claims as a building block here.  For easy readability, it is extracted below:

2.3.1.  Design Principles

   Trust is not absolute.  Trust is a belief in some aspect about an

   entity (in this case an Attester), and that this aspect is something

   which can be depended upon (in this case by a Relying Party.)  Within

   the context of Remote Attestation, believability of this aspect is

   facilitated by a Verifier.  This facilitation depends on the

   Verifier's ability to parse detailed Evidence from an Attester and

   then to assert conclusions about this aspect in a way interpretable

   by a Relying Party.

   Specific aspects for which a Verifier will assert trustworthiness are

   defined in this section.  These are known as Trustworthiness Claims.

   These claims have been designed to enable a common understanding

   between a broad array of Attesters, Verifiers, and Relying Parties.

   The following set of design principles have been applied in the

   Trustworthiness Claim definitions:

   1.  Expose a small number of Trustworthiness Claims.

       Reason: a plethora of similar Trustworthiness Claims will result

       in divergent choices made on which to support between different

       Verifiers.  This would place a lot of complexity in the Relying

       Party as it would be up to the Relying Party (and its policy

       language) to enable normalization across rich but incompatible

       Verifier object definitions.

   2.  Each Trustworthiness Claim enumerates only the specific states

       that could viably result in a different outcome after the Policy

       for Attestation Results has been applied.

       Reason: by explicitly disallowing the standardization of

       enumerated states which cannot easily be connected to a use case,

       we avoid forcing implementers from making incompatible guesses on

       what these states might mean.

   3.  Verifier and RP developers need explicit definitions of each

       state in order to accomplish the goals of (1) and (2).

       Reason: without such guidance, the Verifier will append plenty of

       raw supporting info.  This relieves the Verifier of making the

       hard decisions.  Of course, this raw info will be mostly non-

       interpretable and therefore non-actionable by the Relying Party.

   4.  Support standards and non-standard extensibility for (1) and (2).

       Reason: standard types of Verifier generated Trustworthiness

       Claims should be vetted by the full RATS working group, rather

       than being maintained in a repository which doesn't follow the

       RFC process.  This will keep a tight lid on extensions which must

       be considered by the Relying Party's policy language.  Because

       this process takes time, non-standard extensions will be needed

       for implementation speed and flexibility.

Having a really constrained set of AR generated Claims is critical.   My experience has been the RP just wants to be told "I can trust this aspect of the entire Attester".  Considering this, it would be great to understand any Use Case where the AR generated Trustworthiness Claims of Section 2.3.4 would be insufficiently granular for a real-world Policy rule.

Eric

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Monday, February 28, 2022 5:43 PM
To: rats <[email-masked]>
Subject: [Rats] Thinking about Attestation Results

This is an attempt to step back and think about Attestation Results (AR) in a broad and general way.

TLDR: RATS ought to focus on the semantics of the stuff in AR, not the encoding or securing of it.

LL

AR Security

When the Verifier is not combined into the RP, then there is network transfer of AR to the RP and it must be secured. 

AR mostly seems like a B2B backend transfer. Pretty sure TLS is they way to do this. There are enormous amounts of stuff transferred B2B like this these days. IT people know how to secure it so we probably don’t have to specify it or discuss it much.

It’s OK to have other ways to secure AR other than TLS, but I don’t think we need to worry too much about them. 

It’s fine that we say how to use EAT, CWT, JWT, X.509 and such to secure AR in RATS, but it’s not critical.

AR Encoding

When the Verifier is not combined with the RP, then there is network transfer of the AR to the RP that must be encoded.

CBOR, JSON, XML, ASN.1, … All seem possible and not something we have to lock down. 

JSON is at the top of my list because that seems the very common practice for B2B, but we have to expect lots of people will define lots of Web APIs I lots of ways for this. We can also say how to do it with JWT and CWT and such. 

I think it’s good that ar4si isn’t picking any specific encoding or security mechanism.

AR Contents

This is the output from SW measurements verification, device identity, claims passed through from the Evidence, the general Verification results and such.

This is what really matters in RATS! They exist whether or not the RP is combined with the Verifier. This is THE output from RATS. 

These seem candidate for standardization in AR:

- the overall result of a Verifier, perhaps detailed, perhaps simple summary

- SW measurements results

- device identity

- representing claims passed through (location, cryptographic keys…)

- certifications received

Below is a picture from from the RATS architecture document. At this point it seems kind of a mis characterization because it doesn’t mention JSON over TLS and/or Web APIs for AR.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 3 Mar 2022 00:16:39 -0800

> On Mar 2, 2022, at 2:47 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 

A quick answer for now.

FIDO attestation mostly is an implied binary yes/no, but also carries with it meta data about the FIDO authenticator.

Attestation in the Android key store gives you a bunch of information about the key including how use of the key was authorized and of course the pubic key.

We probably need to dive deeper into the security characteristics and levels that 2.3.4 is trying to define considering tie-ins to other work for this in the world like FIDO and other certification schemes, Android key store security levels.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 3 Mar 2022 14:08:07 +0000

> From: Laurence Lundblade, March 3, 2022 3:17 AM

>> On Mar 2, 2022, at 2:47 PM, Eric Voit (evoit) <[email-masked]
<mailto:[email-masked]> > wrote:

>> Having a really constrained set of AR generated Claims is critical.   My
experience 

>> has been the RP just wants to be told "I can trust this aspect of the
entire Attester".  

>> Considering this, it would be great to understand any Use Case where the
AR 

>> generated Trustworthiness Claims of Section 2.3.4 would be insufficiently
granular 

>> for a real-world Policy rule.

> FIDO attestation mostly is an implied binary yes/no, but also carries with
it meta data 

> about the FIDO  authenticator.

> Attestation in the Android key store gives you a bunch of information
about the key 

> including how use of the key was authorized and of course the pubic key.

The example above is identity information rather than immediately actionable
conclusions which the Verifier has made about the Attester.

Eric

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 9 Mar 2022 14:07:31 -0800

Continuing to work this this step by step… see below

> On Mar 3, 2022, at 6:08 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> >> On Mar 2, 2022, at 2:47 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
> >> Having a really constrained set of AR generated Claims is critical.   My experience 
> >> has been the RP just wants to be told "I can trust this aspect of the entire Attester".  
> >> Considering this, it would be great to understand any Use Case where the AR 
> >> generated Trustworthiness Claims of Section 2.3.4 would be insufficiently granular 
> > Attestation in the Android key store gives you a bunch of information about the key 
> The example above is identity information rather than immediately actionable conclusions which the Verifier has made about the Attester.

Well, yes, but it’s OK to send identity info to the RP, right?

Maybe we separate the claims in Attestation Results, the data actually received from the RP into two so the discussion is more clear?

Attester/Device Health
The output of the work a Verifier does to check the measurements it receives. Maybe it is a cross check against a vulnerability database too? Could even go so far as to be the output of a machine learning algorithm to evaluate health.

In the simplest form this is a binary yes/no, but it could also have a lot more like some of the stuff in ar4si. 

Not sure if certifications received goes here or below, but it could go here. Maybe it’s a factor in the health evaluation.

Attester/Device Meta Info
This includes things like:
 - Device identity (serial number, make, model and version)
 - GPS location
 - Application-specific passed through claims, such as a public key and info about the public key
 - Proprietary claims about the device from the manufacturer such as their particular version scheme, payment qualification indicators
 - Certifications received
 - Other claims like boot seed and uptime that people have proposed
 
I think some RP’s will want to run machine learning risk engines. These thrive on data so they want as much as possible. For example in a financial transaction, the RP might want to use machine learning to correlate the amount, originator and recipient with both Attester/Device Meta Info and with Attester/Device Health.

But even if they don’t run a machine learning risk engine, lots of this meta info is desirable.

It seems like ar4si is focused on device health. That’s fine and ar4si can do a lot, but that doesn’t mean that the other stuff must never be sent to the RP, right?

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 10 Mar 2022 14:33:01 +0000

Hi Laurence,

From: Laurence Lundblade, March 9, 2022 5:08 PM

>> On Mar 2, 2022, at 2:47 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

> FIDO attestation mostly is an implied binary yes/no, but also carries with it meta data 

<eric> Absolutely.  And there are a huge number of viable identity formats in play which will be specific by use case.

<eric> I see three categories: identity, claims, freshness.  And these need to be bound together to protect against things like replay attacks.  Here is a slide from a previous IETF on this:

Note that identity can be communicated via just a signature over a payload.

Attester/Device Health

 - GPS location

It seems like ar4si is focused on device health. 

<eric> Ar54si Section 2.3 is about device health claims.  Section 3 is about how an RP can process assertions about health.      

That’s fine and ar4si can do a lot, but that doesn’t mean that the other stuff must never be sent to the RP, right?

<eric> Yes, lots of stuff can be sent.  The question is what role receives it.   Early in RATS I received pushback from the writers of the architecture doc that the RP's device also has a Verifier embedded.  This resulted in Figure 1.  I expect you will need to be explicit on roles within devices when talking about what is sent to the RP.  Many will content that other stuff being sent is actually to the Verifier process which is co-resident with the RP.

Eric

LL