Subject: Re: [Rats] Often Attester == Device and profiles

From: "Smith, Ned" <[email-masked]>
Date: Wed, 19 Jan 2022 16:42:19 +0000

Does anyone think the current or proposed charter text limits the WG ability to define profiles? Nobody brought up charter scope concerns when the last time the WG had a profiles discussion.

From: Thomas Hardjono <[email-masked]>
Date: Wednesday, January 19, 2022 at 7:05 AM
To: Henk Berkholz <[email-masked]>, Laurence Lundblade <[email-masked]>, "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

>>> >>>TH seems to be saying that having standardized ARs is useful to RPs because RPs might not (want?) to know about the "FIDO" claim as it implies a bunch of things, but rather wants to know if those things reasonably implies a particular 'tier' as defined by one of the drafts. To which I agree. That seems reasonable.

>>> >>I’m fine with defining some trust tiers in this WG and they will be useful depending on the use case, but don’t see them as universal.

>>> Today, I do not share that assessment with the exception that the work
>>> is not finished by the WG of course - but that is actually the goal.
>>> Having said that: this kind of universally understood Attestation
>>> Results is not suitable for any scenario, I think. But it will be there
>>> and everybody can chose to conform - or not (and now help to extend it).

Since we are in the process of considering re-chartering of RATS, is this the opportune moment to talk about “Device Profiles” or “Attester Profiles”?   By “attester profiles” I mean the Attester construction and device compositions (HW/SW/FW) that may be relevant to certain industry verticals.

Clearly a physical router is different from consumer smartphone and different from IoT sensors and from VM stack using DICE, etc. etc.

The reason I bring-up “profiles” is to make the point that the correct interpretation by the (dumb) RP of the “Trustworthiness Tiers” (or any kind of Appraisal Results easy-to-parse labeling) involves the RP understanding the nature of the device that is the Attester.

So yes, a “universally understood attestation result” is difficult (impossible) to understand if there is no context for the RP. The “profile” is part of this background context.

--thomas

From: Henk Birkholz <[email-masked]>
Date: Wednesday, January 19, 2022 at 5:23 AM
To: Laurence Lundblade <[email-masked]>, Ned Smith <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Hi Laurence,

comments again in-line.

On 19.01.22 03:24, Laurence Lundblade wrote:

On Jan 18, 2022, at 1:23 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

(not as chair)
I'm trying to assess if this thread is leading somewhere concrete.
It seems LL was observing that it should be possible for Evidence to be the empty set and cited a FIDO use case.

I’m asserting that measurement is not necessary for many attestation use cases, one of which is FIDO.

(Where measurement is hashing some code, memory, config… and comparing to reference values. Reporting location, UEID, manufacturer, proof of passion is not measurement to me).

I’m OK with Evidence that is almost empty, only a nonce, Evidence with tons of claims that aren’t measurement claims, Evidence with tons of claims that are measurements, combos and so on.

TH seems to be saying that the RATS Arch doesn't prevent this interpretation.

Agreed.

HB seems to concur, but acknowledges something needs to be signed in Evidence, since signing the empty set doesn't work, if for no other reason than the Verifier needs to know who the Attester is.

What possibly is missing is the acknowledgement that the Verifier might receive Claims directly from an Endorser that adds the "FIDO" claim which presumably implies a bunch of properties about the Attester. (The RATS Arch suggests is an expected property of the arch).

I don’t think this is missing. Certainly not for the FIDO use case.

The FIDO protocol has extensible/pluggable attestation with a typing mechanism for different formats of attestation. EAT will hopefully be one of those. The FIDO Server knows what is going on before looking into the EAT. FIDO is the dog, Attestation/RATS/EAT is the tail. :-)

It’s often the root certificates that the FIDO Server trust that tells it that the Authenticator/Attester is FIDO and does FIDO stuff. So maybe that is an implicit claim in the endorsement?

I am sorry to berate that point, but what you are describing here is
exactly what we meant. You start with a proof of possession. In the FIDO
scenario that enables the individual identification of a device (in a
subset of cases identifying Claims are included in the otherwise rather
sparse Evidence Claims Set), and thereby:

1.) the Verifier/FIDO Service knows that the Authenticator/Attester is
FIDO and does FIDO stuff, and
2.) external "endorsed values" about an Attester can be associated with
that now identified Attester

This is literally how FIDO works. Or what essential discrepancy am I
missing here? Maybe we are still in some unwittingly limbo of
disconnect, but I read the fido and webauthn-2 specs and this is how it
seems to work. SO I am really interested, if there is a distinguishing
feature that I am not seeing today.

c

TH seems to be saying that having standardized ARs is useful to RPs because RPs might not (want?) to know about the "FIDO" claim as it implies a bunch of things, but rather wants to know if those things reasonably implies a particular 'tier' as defined by one of the drafts. To which I agree. That seems reasonable.

I’m fine with defining some trust tiers in this WG and they will be useful depending on the use case, but don’t see them as universal.

Today, I do not share that assessment with the exception that the work
is not finished by the WG of course - but that is actually the goal.
Having said that: this kind of universally understood Attestation
Results is not suitable for any scenario, I think. But it will be there
and everybody can chose to conform - or not (and now help to extend it).

Is this thread basically an expression of us being in agreement then?

Sort of :-)

LL

Viele Grüße,

Henk

-Ned

On 1/18/22, 9:42 AM, "Henk Birkholz" <[email-masked]<mailto:[email-masked]>> wrote:

     Hi Laurence,

     please find replies in-line:

     On 18.01.22 18:11, Laurence Lundblade wrote:

On Jan 14, 2022, at 5:27 AM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

[LL] >>> I also think it is fine for attestation to do no measurement.
It accepted by the Verifier to be in a good state if it is producing
valid attestations. This is how FIDO and the Android Key Store
attestation work.
[TH] I think the RATS-Arch is flexible enough to cover this use-case,
but there needs to be some way for the Verifier to communicate to the
RP that no measurement was done (of the Attesting Environment or even
the key-store environment in the Attester). So this scenario becomes
simply a signed claim by the device (Attester) of
proof-of-key-possession via a challenge nonce.

It is much more than proof of possession. In the case of FIDO, it is
also biometric authentication and all FIDO rules and procedures.
Whomever is trusting the FIDO authenticator wants to know that all this
is being done to know the end user was properly authenticated. They know
this because it is attested as being a FIDO Authenticator.

     While it is of course more (otherwise it would be just RFC 7800 - not
     trying to belittle RFC 7800 here; that one is great!), but I think what
     Thomas was trying to say here is that the trust relationship is
     basically boiled down to proof of possession: "if signed by this private
     key - that you can check via public key and corresponding trust anchor -
     than all assertions are up-leveled to Evidence Claims".

     In essence, it is actually proof-of-possession with various modular
     means how to handle the key that you possess and well-defined procedures
     and policies around it. That is the core of FIDO.

     That is literally why the slogan of FIDO is "simpler stronger
     authentication". Remote attestation is an option (for example as defined
     in webauthn-2), which is why it was so important to the working group to
     align these concepts with FIDO.

Another class of cases is DRM, content protection, IP protection and
such. The RP wants to know that device will protect the content before
it gives the content to it. An Attester might be good at protecting
videos, but bad a protecting corporate secrets and bad at biometric
authentication.

Would it be useful for EATS to refer to the notion of “Trustworthiness
Tier” from draft-rats-ar4si ?

Basically, I think we can do a little bit of trust characterization in
RATS, but the space is too big and varied by use case to do anything
comprehensive.

     I do not agree with the notion related to “Trustworthiness Tiers”,
     because these are targeting exactly that: comprehensive trust
     characterization. Sorry, but I fundamentally disagree with that comment
     and would need some in-depth explanation how you arrived at that conclusion.

Even just for measurement and non-measurement there’s a range. Some
attesters will measure badly, some will measure partially really well
and some that don’t measure at all will be excellent and very trusted.

     And the Verifier's policy will make sense of that spectrum.

The TCG may want to create some claims, root certificate or such to
indicate that the measurements made conform to some criteria they set,
because all measurement will not be done the way it thinks it should be
done.

     Referring here to TCG and FIDO in the same context of course could be
     interpreted as the "space is too big". But that is taking topics out of
     context in order to portrait that feeling. Pronounce as "they" and "it"
     also do not help. In contrast, I think that we layed out very well in
     the architecture how the appraisal of evidence that includes
     measurements asserting the trustworthiness of a device and based on that
     the appraisal of trusted claims (such as "debug mode" or "gps
     coordinates") work in RATS.

LL

     Viele Grüße,

     Henk

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 19 Jan 2022 19:00:40 +0000

hi Ned,

> So yes, a “universally understood attestation result” is difficult (impossible) to understand if there is no context for the RP. The “profile” is part of this background context.

I think one of the nice things about AR4SI is that it provides the
means to remove the need for the RP to have a precise understanding of
the attester's profile.  The verifier is doing the job of translating
the potentially very diverse set of evidence claims (and the further
semantics encoded in the combination constituting the specific
evidence profile) into a bunch of well-known / normalised claims that
can be universally digested.

cheers,
-- 
Thomas