Subject: Re: [Rats] Meaning of security level claim

From: Henk Birkholz <[email-masked]>
Date: Tue, 1 Feb 2022 09:56:29 +0100

Hi Giri,

please find in-line a quick and dirty attempt to map the three examples 
to the architecture (as basis for me to get it appropriately) and some 
questions.

In essence, what I read from the description is that there are 
effectively three Entities (four, if you'd say that the MDS is a Relying 
Party Owner) that are the Attester (including the Authenticator), the 
Endorser (that provides the trust anchors for the Verifier) and the 
Website that is always the Relying Party and in at least the two latter 
scenarios could also be taking on the role of a Verifier (if you accept 
signature checking based on a trust anchor/endorsement as a minimum to 
call the procedure "appraisal of evidence" - it's a bit fringy, maybe, 
from my point of view).

Viele Grüße,

Henk

On 01.02.22 06:29, Giridhar Mandyam wrote:
> The use case I have in mind is regarding authentication on the web using FIDO-compliant implementations.  I'll try with an example.
> 
> User has personal device with FIDO authenticator and integration into browser.  User onboards authentication credentials for 3 different websites using the Webauthn API (https://www.w3.org/TR/webauthn-2/) .  Each relying party (website) obtains an attestation with sec. level reporting during credential registration (https://www.w3.org/TR/webauthn-2/#sctn-usecase-registration).  The 3 websites have different appraisal policies:
> 
> Website A:  Doesn't care about sec level.  Only cares about a non-phishable credential that can be used as a 2nd factor (along with password).  RP will always complete registration of the credential as long as user enters valid username/password.

I assume that the authenticity of the authenticator is checked via some 
endorsement/trust anchor in this scenario. Is that correct? (otherwise I 
don't see yet how the "non-phishable" is achieved)

> 
> Website B: Will inspect sec level and trust anchor.  Based on this, may require step-up authentication if the sec level is not sufficient or trust anchor is not among the RP-approved trusted roots.    RP is less concerned about the self-reported nature of sec level, as RP also leverages a back-end authentication mechanism (e.g. risk-based).  In short, the RP will always register the credential but its authentication policy may be modified based in part on reported sec level.

In this case, would you say that an Endorser role is working in 
conjunction with the Relying Party here (trust anchor in TA-store being 
the endorsement).

The risk assessment seems to be Appraisal Policies for Attestation 
Results. Formally, that would mean that there should be a minimal stub 
Verifier that produces the Attestation Result (forwarding an "un-vetted" 
security-level extracted from the Evidence) and some complementary 
signature checking based on the Endorsement. Does that sound right?

> 
> Website C:  Will inspect sec level and trust anchor.  RP is also a subscriber to the FIDO metadata service (MDS, see https://fidoalliance.org/metadata/) and will validate reported sec level against what MDS states as the cert level obtained by the authenticator vendor.  If the sec level does not match with MDS reporting, then the RP could potentially designate the authenticator as inauthentic and terminate registration of the credential.

Is the environment that is interacting with the MDS taking on the role 
of Verifier here? I assume so, as there is now an Appraisal Policy for 
Evidence in place that appraises the security level in Evidence produced 
by the Attester.

> 
> -Giri
> 
> -----Original Message-----
> From: RATS <[email-masked]> On Behalf Of Michael Richardson
> Sent: Monday, January 31, 2022 1:46 PM
> To: rats <[email-masked]>
> Subject: Re: [Rats] Meaning of security level claim
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> 
> Maybe a few someones could articulate *their* use case for "security-level" before we go any further.
> 
> --
> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 1 Feb 2022 10:24:21 +0000

Hi Henk,

> call the procedure "appraisal of evidence" - it's a bit fringy, maybe,

I am not Giri so this may be all wrong, but the way I understand the
mapping FIDO->RATS is slightly different:

* device + authenticator -> Attester
* Website -> RP + Verifier
* CA signing the device attestation key -> Endorser (for cryptographic
trust anchor)
* MDS -> Endorser (for certification and maybe other things)

> don't see yet how the "non-phishable" is achieved)

This case is not very clear to me either.  It seems that the Verifier
co-located with the Website A should at least verify that the
signature of the attestation key is correct, all the certs in the
chain validate, and that the cert chain is anchored on to an endorsed
CA.  This should be the minimal check, otherwise I don't think this
can map to a RATS scenario.

> conjunction with the Relying Party here (trust anchor in TA-store being

IIUC, a FIDO Website is also a Verifier which uses the CA (and RA)
issuing the attestation key cert as an Endorser.

> signature checking based on the Endorsement. Does that sound right?

Yes, that's my understanding.  (See above.)

> Evidence in place that appraises the security level in Evidence produced

The MDS is another kind of Endorser that Website C's Verifier trusts
and uses to enrich its Attestation Results with other metadata (e.g.,
sec level) so that Website C's RP can make a more informed decision.

cheers,

-- 
Thomas

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 1 Feb 2022 17:41:02 +0000

> In essence, what I read from the description is that there are effectively three Entities (four, if you'd say that the MDS is a Relying Party Owner) that are the Attester (including the Authenticator), the Endorser (that provides the trust anchors for the Verifier) and the Website that is always the Relying Party and in at least the two latter scenarios could also be taking on the role of a Verifier 

Apologies - I assumed that all RATS WG participants were somewhat familiar with the FIDO model.  There are some things that I referred to below in my example that may be a little obscure.  

Do you mean that there are three entities that are attesters?  If so, then to be clear there is only one attester - the authenticator.  The current acceptable attestation formats are provided in https://www.w3.org/TR/webauthn-2/#sctn-defined-attestation-formats, but the list can be extended via IETF/IANA expert review (https://datatracker.ietf.org/doc/rfc8809/).  The authenticator can generally take the form of a platform authenticator (e.g. https://developers.google.com/identity/fido/android/native-apps) or a discrete accessory (e.g. https://www.yubico.com/products/security-key/

If not, then your interpretation is almost correct.  The attester should be ideally integrated into the authenticator, but in certain deployments it is not.  For instance, a FIDO-compliant TPM attestation does not (in my opinion) fully address the security state of the authenticator as parts of the authentication operation (e.g. biometric match) occur outside of the TPM (e.g. SGX enclave) and the TPM attestation PCR's do not contain any info regarding sec boot (based on my understanding from MS team - if anyone is reading this who is more familiar with the Windows implementation then please correct me!).

In the FIDO model, MDS is definitely not an RP owner.  The MDS is an online service provided by FIDO which can be a source of trust anchors, cert. status, and general characteristics (e.g. fingerprint reader, IRIS scanner) of a FIDO-compliant authenticator.  Not all FIDO vendors choose to enable entries on MDS, so it may not be sufficiently authoritative for all RP's.  In that regards, MDS could serve a role as an Endorser.  That being said, EAT is not an approved FIDO attestation format yet so the issue of whether MDS would host EAT trust anchors is open.

You are correct in that I do assume the website is always the RP.  Moreover I assume the verifier/website/RP are all the same, but this does not have to be the case.

>(if you accept signature checking based on a trust anchor/endorsement as a minimum to call the procedure "appraisal of evidence" - it's a bit fringy, maybe, from my point of view).

See my description of the TPM attestation above.  In that case, the trust anchor is the only available information for appraisal (based on my own interpretation and conclusion).  Once again, persons who are more familiar with the Windows implementation are free to disabuse me of my notion.

-Giri

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Tuesday, February 1, 2022 12:56 AM
To: Giridhar Mandyam <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

Hi Giri,

please find in-line a quick and dirty attempt to map the three examples to the architecture (as basis for me to get it appropriately) and some questions.

In essence, what I read from the description is that there are effectively three Entities (four, if you'd say that the MDS is a Relying Party Owner) that are the Attester (including the Authenticator), the Endorser (that provides the trust anchors for the Verifier) and the Website that is always the Relying Party and in at least the two latter scenarios could also be taking on the role of a Verifier (if you accept signature checking based on a trust anchor/endorsement as a minimum to call the procedure "appraisal of evidence" - it's a bit fringy, maybe, from my point of view).

Viele Grüße,

Henk

> Website A:  Doesn't care about sec level.  Only cares about a non-phishable credential that can be used as a 2nd factor (along with password).  RP will always complete registration of the credentia…

I assume that the authenticity of the authenticator is checked via some endorsement/trust anchor in this scenario. Is that correct? (otherwise I don't see yet how the "non-phishable" is achieved)

> Website B: Will inspect sec level and trust anchor.  Based on this, may require step-up authentication if the sec level is not sufficient or trust anchor is not among the RP-approved trusted roots.…

In this case, would you say that an Endorser role is working in conjunction with the Relying Party here (trust anchor in TA-store being the endorsement).

The risk assessment seems to be Appraisal Policies for Attestation Results. Formally, that would mean that there should be a minimal stub Verifier that produces the Attestation Result (forwarding an "un-vetted"
security-level extracted from the Evidence) and some complementary signature checking based on the Endorsement. Does that sound right?

> Website C:  Will inspect sec level and trust anchor.  RP is also a subscriber to the FIDO metadata service (MDS, see https://fidoalliance.org/metadata/) and will validate reported sec level against…

Is the environment that is interacting with the MDS taking on the role of Verifier here? I assume so, as there is now an Appraisal Policy for Evidence in place that appraises the security level in Evidence produced by the Attester.

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 1 Feb 2022 11:18:04 -0800

> On Jan 31, 2022, at 10:13 AM, Thomas Fossati <[email-masked]> wrote:
> 
> On Mon, Jan 31, 2022 at 5:37 PM Henk Birkholz
>> On 31.01.22 18:17, Smith, Ned wrote:
>>> Would it matter to the RP if a security level claim was originated by the Attester or by the Endorser given it was vetted by the Verifier? All that matters is that the RP understands the semantics of the security level claim and that it trusts the Verifier to properly vet / appraise the claims.
>> 
>> This seems to be a vital question that we should resolve rather quickly.
> 
> There seem to be 3 different statements that a Verifier can make:
> 
> 1. Verifier says that Endorser says that security-level==N
> 2. Verifier says that Attester says that security-level==N
> 3. Verifier says that security-level==N
> 
> They differ in semantics even though the Attester "vets" all of them.
> 
> I think it is important that the Attestation Results are able to
> convey all three meanings to give the RP's more flexibility on
> deciding what is acceptable.

To me, this is operational policy for a particular verifier deployment, not something for a standards document.

There can be lots of other policies where the verifier picks the security level to report to the RP in other ways. Maybe it’s mapped based on vendor information. Maybe it's based on some other information from the Endorser. Could even be based on certifications received (but here the mapping is defined by the verifier, not an IETF standard).

I think the security level claim is useful in constructing various policies like this. It gives a rough baseline description that is broadly understood.

What Thomas proposes can be a new claim that is an array of three items, each a security level. The definition could be verifier proprietary, an informational document, from another SDO, but I don’t think it is general enough for EAT.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 1 Feb 2022 11:30:07 -0800

On Jan 31, 2022, at 4:58 PM, Smith, Ned <[email-masked]> wrote:
> 
> The use cases I'm aware of are closer to "Attester satisfies security policy X" rather than "Attester satisfies security level X”.

The way I’d approach that would be to define a claim that identifies security policies that were met. Perhaps an array of OIDs and URIs, each of which identify a security policy met.

That would be complimentary to security level as something that gives more detail to the simple, broadly understood security level claim.

LL

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Feb 2022 15:41:19 -0500

Giridhar Mandyam <[email-masked]> wrote:
    > Website A:  Doesn't care about sec level.

    > Website B: Will inspect sec level and trust anchor.

    > Website C:  Will inspect sec level and trust anchor.

You've told me that some "sec level" will be required, but you haven't told
me what it means, or how the verifier will believe the assertion.

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 1 Feb 2022 22:04:22 +0000

I assume you are trying to keep the email traffic down, so you have just repro'd a subset of the original use case. I will refer to my original post here:  https://mailarchive.ietf.org/arch/msg/rats/5JRy9tGHq78ZR7cojoplzpV6LQU/.

For Website A, no sec level is required.  It is basically a don't care.  Verification is with respect to an in-band x.509 chain that is associated with a known trust anchor.

For Website C, since it is referring back to MDS it will expect the sec level to correspond to certification level (see https://mailarchive.ietf.org/arch/msg/rats/db2ZQLJ_5g0o5ZAzDqGpMHg-R_0/).  If it does not, it will take a very specific action (I mentioned that it will terminate registration of the credential).  Verification is with respect to an in-band x.509 chain that is associated with a known trust anchor.

For Website B, it is only using the sec level to determine whether step up authentication is required.  An insufficient security level value will result in additional authentication factor(s) being required. The RP assumption is that the particular CA (trust anchor) will not issue a cert to a rogue actor, so the security level value itself does not need to be verified against a trusted 3rd-party (in contrast to Website C).  Verification will be with respect to the in-band 509 chain and trust anchor.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, February 1, 2022 12:41 PM
To: Giridhar Mandyam <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

    > Website C:  Will inspect sec level and trust anchor.

You've told me that some "sec level" will be required, but you haven't told me what it means, or how the verifier will believe the assertion.

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 1 Feb 2022 22:28:30 +0000

The idea of there being a single widely accepted notion of 'security level' doesn't seem realistic. 

On 1/31/22, 5:49 PM, "Michael Richardson" <[email-masked]> wrote:

    Smith, Ned <[email-masked]> wrote:
        > The use cases I'm aware of are closer to "Attester satisfies security
        > policy X" rather than "Attester satisfies security level X".  -Ned

    So, please confirm you are saying that you have no use case for "security-level"?

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 1 Feb 2022 22:39:00 +0000

(not as chair)
This is a long thread. Thanks for summarizing. 
The use case context for security level appears to be FIDO. Given this qualifying context, a precise meaning of some of the EAT Claims may be extrapolated. Without a qualifying context something like 'security level' seems too general to be meaningful. So I wonder if the thread lost the FIDO context somewhere along the way? Given the RATS Arch asserts that the RP is expected to have a use case context, then it seems the Verifier might be expected to tailor an attestation result according to the context; even if it is something as simple as Verifier recognizing the RP as a FIDO entity and therefore knows that 'security level' maps to a FIDO understanding of security level.
-Ned

On 2/1/22, 2:05 PM, "RATS on behalf of Giridhar Mandyam" <[email-masked] on behalf of [email-masked]> wrote:

    -Giri

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 1 Feb 2022 16:53:38 -0800

On Feb 1, 2022, at 2:39 PM, Smith, Ned <[email-masked]> wrote:
> 
> The use case context for security level appears to be FIDO. 

No, that’s not true. It’s much more broad.

I think Giri was only giving FIDO as one example.

I will provide a list of use cases in the next day or so (takes me time to write these things outl).

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Wed, 2 Feb 2022 18:36:05 +0000

FIDO is actually already in the use cases in the arch doc (https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-2.7), so that is why I fleshed it out with respect to sec level.  If need be, I can make an attempt to demonstrate use of sec level for the other use cases.  The only one that I cannot determine any obvious usage of sec. level for is HW watchdog (https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-2.6).

-Giri

From: Laurence Lundblade <[email-masked]>
Sent: Tuesday, February 1, 2022 4:54 PM
To: Smith, Ned <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; rats <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
On Feb 1, 2022, at 2:39 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Feb 2022 22:13:41 +0000

I still haven't internalized the broad applicability.  Laurence in yesterday's email you promised could you provide use case specifics.   As part of this could you show how EAT claims in namespaces which are then referenced in an Appraisal Policy for Attestation Results? 

I tried to lead things down this path in my email from Monday when I pointed to this use case:  "If you can trust the identity of the type of Attester, and the manufacturer of the Attester is Vendor-X, and if the Verifier accepts Trust Vendor-X equipment with a static, self-asserted security-level with a minimum level of '3', then allow the transaction."

Understanding complete policies like this will help with our dialogs to determine the most efficient objects for a use case.

Thanks,

Eric

From: Giridhar Mandyam, February 2, 2022 1:36 PM

-Giri

From: Laurence Lundblade <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, February 1, 2022 4:54 PM
To: Smith, Ned <[email-masked] <mailto:[email-masked]> >
Cc: Giridhar Mandyam <[email-masked] <mailto:[email-masked]> >; rats <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Meaning of security level claim

On Feb 1, 2022, at 2:39 PM, Smith, Ned <[email-masked] <mailto:[email-masked]> > wrote:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 3 Feb 2022 13:20:57 -0800

The TLDR is roughly this:
  - In Attestation Results, security-level is a simple, broadly accepted and understood high-level security characterization
  - In Attestation Evidence, the Attesting Environment is reporting the security-level of and Attestation Target, particularly a Target that it can evaluate and for which security-level may vary

TEE reporting on attached subsystems (Attestation Evidence)
An SoC (System on a Chip) is made up of a TEE and many subsystems. It is a composite device as described in RATS architecture.

The attestation is generated by the TEE. The Verifier has an endorsement for the TEE that indicates it has a high security level. There is no security-level in Attestation Evidence for the TEE itself.

The TEE’s attestation includes an EAT submodule for each of the subsystems and each submodule includes a security-level claim.

The TEE determines the security-level for each submodule by examining system information, how the submodule booted, what SW it is running and configuration built into the attester in the TEE. The TEE has broad access to memory and configuration for every subsystem on the device. The TEE may even run measurements and compare them to references values it has in the TEE.

A dynamic system is employed because the SW for the subsystems come from different vendors than the TEE and parties other than the TEE vendor can control how they boot. (This is in contrast to a static design where knowing the vendor and model of the device clearly tells you the disposition of all the subsystems).

Private Payment Network (Attestation Results)
A payment network chooses to allow payments to be made from desktops, laptops, mobile phones and payment terminals, allowing higher transaction amounts for more secure devices.

The system architecture has a device evaluation front end that characterizes transaction-originating devices based on whatever information it can get. This may include attestations, the network the transaction originated from, cell tower location and so on. Perhaps it uses machine learning system. It is a Verifier plus more. It outputs its characterization as an EAT token.

The actual payment processing part of the payment network accepts the EAT token as a standard characterization of the device’s security. It approves the transaction based on the device’s security, the amount and the account holder’s characteristics.

General Verifier Output (Attestation Results)

Any Verifier may wish to provide a simple broadly accepted, high-level classification of security of devices it Verifies. This might be a general 3rd party service that works for lots of use cases and device types. It might also be one that is industry specific, or one that is vendor specific.

The Verifier should publish its criteria for assigning security levels so, RPs know what they are getting, but it is generally free to do it as it sees fit.

It may assign based on certifications it recognizes the device has received. While this is mapping certifications to security level, it is not a general standard broad mapping. It may be in certain industries and applications that the mapping is direct and straight forward.

It may assign because it maintains a relationship with device vendors so as to know what security levels should be assigned.

It may assign based on machine learning algorithms it uses to evaluate Attestation Evidence.

The value add is that security-level is a simple, broadly accepted, useful security characterization. 

Metering sensors (The Verifier and RP are the same so, Attestation Results are the same as Evidence)
A vendor makes a range of metering sensors, perhaps for gas, water or electricity. Some are higher security and suitable for deployment when use is high and the environment is subject to attack. Others are not.

The product is sold internationally. The vendor doesn’t want to operate a verification service for various business reasons.

The sensors output EAT tokens that describe the various characteristics of the sensors in claims including security-level.

The vendor publishes the public key for verifying the tokens, publishes an EAT profile and recommends some EAT SW on GitHub for RP’s integrating the sensor into their systems.

The RP’s (gas, water or electricity vendors) to require a metering sensor of a particular security level depending on the amount used and the deployment environment. Here the Verifier and RP are the same.

This is secure because of the way the vendor builds their devices. They always protect the Attestation Environment very well which enables them to use the same key on high and low security devices, but the security of the rest of the device varies. The Attestation Environment is able to determine correctly the security of the rest of the device because the vendor builds the devices such that this is possible.

This might be written into a standard for metering sensor security and used across multiple vendors.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 4 Feb 2022 21:40:33 +0000

Hi Laurence,

Thanks for making the effort in doing this.  Perhaps the overall topic is something which needs an EAT authors' position for the next IETF.  Below are the two general questions I am mulling over when I compare what is below to previous dialogs on this thread:

(1) The meaning of security-level varies across the use cases below (i.e., in some cases it is a self appraisal, in others it is calculated by the Verifier.)   Should RATS support claims of the same name which can be generated as Evidence by the Attester or as Attestation Results from a Verifier?  I really don't know, but until today I have been assuming no.  Extending this question: is it possible for the Relying Party to evaluate both the Attester's self-appraisal and a Verifier's evaluation at the same time?  If this is possible, how does EAT handle namespaces so that the RP's Appraisal Policy for Attestation Results can process the same EAT claim from two sources?  We really should have a WG discussion on just this topic as it transcends anything specific to the security-level claim.

(2) The security-level claim currently has very ambiguous definitions in the current EAT draft.  While I agree that a general four level scaled scale is easy to understand, the semantic meaning of any specific level is not.  In fact it is very nuanced.  Earlier in this thread I pointed to external documents of tens of thousands of words dedicated to just this subject.   See: https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/       How do the EAT authors plan to address the semantic meaning of each specific level?  I believe the current wording to be insufficient.

I have additional specific questions, but they really don't matter until these are closed.

Thanks,
Eric

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Thursday, February 3, 2022 4:21 PM
To: Eric Voit (evoit) <[email-masked]>
Cc: rats <[email-masked]>; Giridhar Mandyam <[email-masked]>; Smith, Ned <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

 

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 6 Feb 2022 12:40:21 -0800

Focusing in on what is self-appraisal and what is not and what it’s good for.

Assuming four legal entities in the system:
- The manufacturer who makes the Attester and provides the Endorsement
- The manufacturer of a subsystem on a composite device distinct from the manufacturer of the Attester
- The Verifier
- The RP

In all the following, the security-level is reported in Attestation Results.

Scenario 1 — Verifier Appraisal
Here the Verifier does not receive e a security-level claim from the manufacturer. They figure one out. Perhaps they have a database of their own construction and look up based on HW OEM ID and HW Model. Perhaps they evaluate some measurements. Perhaps they look at some other claims.

This is kind of a mini certification program. The Verifier needs to publish their evaluation criteria.

This is clear NOT self-appraisal.

Scenario 2 — Security-Level in Endorsement
Here the verifier receives an endorsement that contains a security-level claim. They copy it to Attestation Results.

I call this self-appraisal because it is the manufacturer that is assigning the security level.

Scenario 3 — Security-level in Evidence
Here the verifier receives the security-level claim in Attestation Evidence. They copy it to the Attestation Results.

This is same as scenario 2. The path of transference is just different, but it is equally secure.

This is self-appraisal

Scenario 4 — Composite Device
Here the Attester evaluates the security-level of a separate subsystem on the device and reports it in an EAT submodule in Attestation Evidence. The Verifier passes it on to the RP.

This is not self-appraisal. 

We could have some other scenarios where security-level is in Evidence and the Verifier cross-checks, but I don’t think that really changes the main outline above.

Often self-appraisal is OK and highly useful. It happens all the time in the real world. For example, we sign contracts all the time without a notary. Product labels are not checked by a food safety lab for correctness. When we really do want something checked well, we do invoke the more expensive procedures and checking. If you are clearing $10 transactions, self-appraisal is OK, but maybe not if you are clearing $100,000 transactions. There’s a sliding scale. 

===> It is not self-appraisal when there is legal/business separation 
===> It is self-appraisal if the manufacture is reporting about itself regardless of the path of conveyance
===> self-appraisal is still useful

(I know I’m not yet, addressing how the RP might be informed as to which is self-appraisal and which is not)

LL

> On Feb 4, 2022, at 1:40 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Laurence,
>  
> (2) The security-level claim currently has very ambiguous definitions in the current EAT draft.  While I agree that a general four level scaled scale is easy to understand, the semantic meaning of any specific level is not.  In fact it is very nuanced.  Earlier in this thread I pointed to external documents of tens of thousands of words dedicated to just this subject.   See: https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/ <https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/>       How do the EAT authors plan to address the semantic meaning of each specific level?  I believe the current wording to be insufficient.
>

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 7 Feb 2022 17:26:03 +0000

>This is not self-appraisal.

I think this is a form of implicit self-appraisal.  The attester is evaluating the security level of a subsystem, but does not convey any information to the relying party as to the criteria it used to derive the security level.  With reference to the FIDO Metadata Service example I provided in https://mailarchive.ietf.org/arch/msg/rats/f58NMIi0kNrsWwcus_NAk7ales0/, the RP doesn’t know if the attester leveraged external sources of information on the security assurance level of the subsystem in question or applied its own evaluation heuristics.  The attester, in assigning the security level, is essentially self-declaring that the determination of the security level took place within the attester’s environment and as per a criteria that would be suitable for the RP/verifier.

-Giri

From: Laurence Lundblade <[email-masked]>
Sent: Sunday, February 6, 2022 12:40 PM
To: Eric Voit (evoit) <[email-masked]>
Cc: rats <[email-masked]>; Giridhar Mandyam <[email-masked]>; Smith, Ned <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Self-appraisal (was Re: [Rats] Meaning of security level claim)

This is self-appraisal

LL

On Feb 4, 2022, at 1:40 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Thanks,
Eric

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
Sent: Thursday, February 3, 2022 4:21 PM
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>; Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; Smith, Ned <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Meaning of security level claim

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Feb 2022 09:42:34 -0800

Hi Giri,

> On Feb 7, 2022, at 9:26 AM, Giridhar Mandyam <[email-masked]> wrote:
> 
> I think this is a form of implicit self-appraisal.  The attester is evaluating the security level of a subsystem, but does not convey any information to the relying party as to the criteria it used to derive the security level.  With reference to the FIDO Metadata Service example I provided in https://mailarchive.ietf.org/arch/msg/rats/f58NMIi0kNrsWwcus_NAk7ales0/ <https://mailarchive.ietf.org/arch/msg/rats/f58NMIi0kNrsWwcus_NAk7ales0/>, the RP doesn’t know if the attester leveraged external sources of information on the security assurance level of the subsystem in question or applied its own evaluation heuristics.  The attester, in assigning the security level, is essentially self-declaring that the determination of the security level took place within the attester’s environment and as per a criteria that would be suitable for the RP/verifier. 

There is separation between the legal entity that is doing the Appraising and the Attester so I really don’t think it is self-appraisal.

What the basis of the appraisal are and how the RP comes to know it are a different matter.  Just because that info doesn’t get to the RP in a useful way doesn’t make it self-appraisal.

This goes somewhat to the heart of the matter here — there are so many different system security architectures and there are so many ways attestation can work that an RP really needs to understand what a general purpose Verifier does before trusting it. I also think it beyond the ability and scope of this group to standardize what Verifiers do in a broad way.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Feb 2022 10:06:01 -0800

> There is separation between the legal entity that is doing the Appraising and the Attester so I really don’t think it is self-appraisal.

Oops, said that wrong.

There is separation between the subsystem being appraised and the Attester…

The subsystem being appraised is likely associated with a different legal entity (different company) than the Attester.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 8 Feb 2022 01:35:42 +0000

I’m having a really hard time following this thread. Possibly because the term ‘self-appraisal’ isn’t defined. The rats arch describes appraisal policy for Evidence and appraisal policy for attestation results. Verifier applies APFE and RP applies APFAR. None of this is considered self-appriasal.

In the context of roles and entities, the roles can be mixed and matched on different entities. Placing a Verifier role and Attester role on the same entity (device) has some challenges but not if the portion of the device that implements Attesting Environment is different from the portion of the device that implements Verifier. That is to say, the Verifier doesn’t depend on the Attesting Environment for its trustworthiness.

The term ‘self-appraisal’ seems to suggest some other interaction?

>I call this self-appraisal because it is the manufacturer that is assigning the security level.

Because the Endorsement that the Endorser provided to the Verifier isn’t Apprasial Policy for Evidence. The Endorsement claim is a statement about the Attester that the Verifier doesn’t expect to find in Evidence. It applies once the Verifier determines the Attester is the Attester it claims to be.

Appraisal of the Evidence claims along with the Endorsement claims expects there is additional criteria or context that should be considered given the accepted set of claims. Possibly, it might assert that a set A of reverence values must match Evidence and not a set B of reference values?

If the Endorser asserts a security level claim, then it requires context. For example, if the vendor went through FIPS validation, the device might have achieved a FIPS140-3 Level 2 certification. The security level is therefore “FIPS140-2 Level 2”.  If the claim is simply level = “2” there isn’t enough context for it to be meaningful.

It would be presumptuous for a Verifier Owner to write a policy (APFE) that equated security level = 2 to mean “FIPS140-3 Level 2”. Possibly, the Endorser had the device evaluated using Common Criteria and it achieved EAL2 so it reports security level = 2. But EAL2 != FIPS140-3 Level 2 so would be a poor appraisal policy.

It might make sense for the Endorser to provide a combination of claims that asserts EAL2 evaluation when both the set A and set B Reference Values are reported as Evidence.

The Relying Party might have an appraisal policy for Attestation Results that accepts EAL2 only if set B evidence claims are reported. Possibly, the RP knows about a configuration option for set A that is problematic and therefore has excluded it from the RP’s network?

If the Attester asserts EAL2, then the Verifier should not believe it because there is no way (according to Common Criteria evaluation for a device to do its own evaluation – this would be something like self-certification – and only could be self-appraisal if the APFE said to accept the self-certification claim). But it hurts my brain to think about this because it doesn’t seem to resonate with anything in the real world.

Maybe we can do a better job of defining the term “self-appraisal” so that more of the list are able to follow along?

Thanks,
Ned

From: Laurence Lundblade <[email-masked]>
Date: Monday, February 7, 2022 at 10:06 AM
To: Giridhar Mandyam <[email-masked]>
Cc: rats <[email-masked]>, "Smith, Ned" <[email-masked]>, "Eric Voit (evoit)" <[email-masked]>, Michael Richardson <[email-masked]>
Subject: Re: [Rats] Self-appraisal (was Re: Meaning of security level claim)

Oops, said that wrong.

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 8 Feb 2022 03:47:21 +0000

I agree with Ned.

To me, the “security-level” seems like redundant with the DLOA claim, because I feel they are both related to security certification schemes such as FIPS and Common Criteria.
If “security-level” and DLOA both need to be kept, then I would like to call “security-level” as “security-self-declaration”, and define it as the string type rather than the enumeration type, because it’s hard to just use few numbers to map with all the possible certifications, and it’s not good to do this mapping in IETF.
I think the most important thing is that if you want to use a numerical “level”, you need to clearly define the criteria. Otherwise, this “level” would be confusing no matter where it appears in.
If Verifier receives the security certificates directly/indirectly provided by Attester, it can appraise whether the certificates are valid and authentic, and it can conclude the result in Attestation Result. But it would be hard to understand if Attestation Result only says “security-level” is “2” or “3”.

Besides that, I also doubt whether it’s suitable to say that the “security-level” is included in the Endorsement. As I understand, the Endorsement endorses the authenticity of Attester. The “security-level” can be directly presented by Attester to Verifier, and this means it is included in Evidence. If Attester doesn’t have this information, then the most likely case is that it is provided by Reference Value provider to let Verifier use it as a reference, and this means it is included in Reference Values.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:[email-masked]] On Behalf Of Smith, Ned
Sent: Tuesday, February 8, 2022 9:36 AM
To: Laurence Lundblade <[email-masked]>; Giridhar Mandyam <[email-masked]>
Cc: rats <[email-masked]>; Eric Voit (evoit) <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Rats] Self-appraisal (was Re: Meaning of security level claim)

Thanks,
Ned

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 7, 2022 at 10:06 AM
To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Self-appraisal (was Re: Meaning of security level claim)

Oops, said that wrong.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Feb 2022 19:53:17 -0800

Hi Panwei,

> On Feb 7, 2022, at 7:47 PM, Panwei (William) <[email-masked]> wrote:
> 

The text defining security-level explicitly says it is NOT about certification.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Feb 2022 10:21:32 +0100

Hi Laurence,

and yet this example was provided by Giri:

> Sec Level = 1:  Lowest level of security assurance.  No 3rd-party validation of TOE.
> 
> Sec Level = 2:  FIDO Levels 1/1+, SESIP Level 1, ARM PSA Cert Level 1
> 
> Sec Level = 3:  FIDO Level 2, SESIP Level 2, ARM PSA Cert Level 2
> 
> Sec Level = 4:  FIDO Level 3/3+ or higher, SESIP Level 3, ARM PSA Cert Level 3

where:

1.) FIDO levels are literally "Authenticator Certification Levels"
2.) SESIP Assurance Levels represent a level of certification (where 1-3 
are basically these "self-assertions" and 4-5 are kind of endorsed, I 
think?)
3.) PSA literally has "Cert" in the quote

So... yeah. I get why this definitely looks like a "certification-level" 
and/or(!) a "security-self-declaration" (especially as SESTP literally 
reads like it is both). Consecutively, I am increasingly having doubts 
about the current definition of "security-level" and I think I am as 
least as confused as Eric, Ned, and Wei are. Which raises a big red flag 
for me.

Additionally, a problem that I see today (and that has not been visible 
in -09 of EAT, I think) is that you can just put these Claims in 
Attestation Results or Evidence and have no way that helps you to 
understand where these Claims are coming from really, which could be 
misleading and actually even be harmful to the Relying Party.

I am mostly okay with the other claims even (and am relatively neutral 
on other self-assertions, such as "secure-boot-label" or 
"debug-status-label").

If this block is the target:

> 
> nonce-label = 10
> ueid-label = 256
> sueids-label = 257
> oemid-label = 258
> hardware-model-label = 259
> hardware-version-label = 260
> security-level-label = 261
> secure-boot-label = 262
> debug-status-label = 263
> location-label = 264
> profile-label = 265
> submods-label = 266

I'd be leaning towards removing security-level from that list.

Viele Grüße,

Henk

On 08.02.22 04:53, Laurence Lundblade wrote:
> Hi Panwei,
> 
>> On Feb 7, 2022, at 7:47 PM, Panwei (William) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> To me, the “security-level” seems like redundant with the DLOA claim, 
>> because I feel they are both related to security certification schemes 
>> such as FIPS and Common Criteria.
>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 8 Feb 2022 16:13:11 +0000

(not as chair)
> Panwei said:
> Besides that, I also doubt whether it’s suitable to say that the “security-level” is included in the Endorsement. As I understand, the
> Endorsement endorses the authenticity of Attester. The “security-level” can be directly presented by Attester to Verifier, and this
> means it is included in Evidence.
It is important to consider whether or not an Attesting Environment is capable of collecting assurance claims. Often these have more to do with the development process then something a bit of code running on the Attester is able to assess. I don’t think it is an intended constraint on Endorsers that they cannot assert assurances claims or that “authenticity” does not include assurance.
-Ned

From: "Panwei (William)" <[email-masked]>
Date: Monday, February 7, 2022 at 7:47 PM
To: "Smith, Ned" <[email-masked]>, Laurence Lundblade <[email-masked]>, Giridhar Mandyam <[email-masked]>
Cc: rats <[email-masked]>, "Eric Voit (evoit)" <[email-masked]>, Michael Richardson <[email-masked]>
Subject: RE: [Rats] Self-appraisal (was Re: Meaning of security level claim)

I agree with Ned.

Regards & Thanks!
Wei Pan (潘伟)

Thanks,
Ned

Oops, said that wrong.

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 8 Feb 2022 16:49:47 +0000

Henk/William,

Thanks for the discussion.  Let me clarify from my perspective as best as I can based on my previous responses.

a) Many security certification regimes that could be relevant to attesting environments are gradated.  Therefore, a manufacturer may provide an attester that can meet a high-level of security assurance (e.g. TPM, Secure Element), but can obtain a low level of certification because they simply did not want to invest or support the necessary level of 3rd-party validation required to get a corresponding certification.

b) *If* a manufacturer has obtained a certification at a certain level, the attester should not declare a security level corresponding to a higher level of assurance than what the 3rd-party cert house has verified to.  As an example, if a manufacturer has only obtained PSA Certified Level 1 then the security level should not be set to a value of 3 (TEE level of assurance) even if the manufacturer has implemented the attester in a TEE environment.  The reason it is not in the manufacturer's interest to over-declare versus the obtained cert level is because the RP/verifier may have independent access to the certification status of the attester (I had mentioned the NIST lookup service as an example).

c) *If* a manufacturer has not obtained a certification but intends to do so, then the attester should not declare a security level higher than 0.  This value can be updated when then certification is obtained.

c) *If* a manufacturer has not obtained a certification and has no intention to do so, then the manufacturer can declare a security level as per their assessment of their implementation.  The RP/verifier will likely have to rely on an endorsement to confirm that the manufacturer is reporting this value in good faith.

> So... yeah. I get why this definitely looks like a "certification-level"and/or(!) a "security-self-declaration"

I view it as both.  Based on the methodology I outlined above, a manufacturer can use cert. status as a guideline in setting the sec. level.  But the manufacturer has options even if no certification has been obtained.

-Giri

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Tuesday, February 8, 2022 1:22 AM
To: Laurence Lundblade <[email-masked]>; Panwei (William) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; rats <[email-masked]>; Giridhar Mandyam <[email-masked]>; Smith, Ned <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Subject: Re: [Rats] Self-appraisal (was Re: Meaning of security level claim)

Hi Laurence,

where:

1.) FIDO levels are literally "Authenticator Certification Levels"
2.) SESIP Assurance Levels represent a level of certification (where 1-3 are basically these "self-assertions" and 4-5 are kind of endorsed, I
think?)
3.) PSA literally has "Cert" in the quote

So... yeah. I get why this definitely looks like a "certification-level"
and/or(!) a "security-self-declaration" (especially as SESTP literally reads like it is both). Consecutively, I am increasingly having doubts about the current definition of "security-level" and I think I am as least as confused as Eric, Ned, and Wei are. Which raises a big red flag for me.

Additionally, a problem that I see today (and that has not been visible in -09 of EAT, I think) is that you can just put these Claims in Attestation Results or Evidence and have no way that helps you to understand where these Claims are coming from really, which could be misleading and actually even be harmful to the Relying Party.

I am mostly okay with the other claims even (and am relatively neutral on other self-assertions, such as "secure-boot-label" or "debug-status-label").

Viele Grüße,

Henk

On 08.02.22 04:53, Laurence Lundblade wrote:
>> because I feel they are both related to security certification 
>> schemes such as FIPS and Common Criteria.
>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 8 Feb 2022 11:38:12 -0800

Hi Eric,

So security-level is intended only as a corse broad general characterization only. I don’t think it is possible to do anything else if it is to be broadly applicable.

Perhaps some more framing text in the document would help make this clear:

This is only a very coarse and broad characterization of the security of an implementation. Such characterization is all that is practically possible for something that is to apply to many use cases. It is not intended to be precise, nor a formal definition of the security of implementations, nor a classification system for certifications.

Use cases that wish for more precise definitions should invent their own claims. When the use case is narrowed, it is much more practical to be precise.

I think it could be even more corse and go down to three levels.

Seems to me that the attestation results document is attempting roughly the same thing. Here’s the text from draft-voit-rats-attestation-results:

>    1.  HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
>        which continually hashes security measurements in a way which
>        prevents an Attester from lying about measurements which have
>        been extended into the Attesting Environment (e.g., TPM2.0.)
> 
>    2.  Process-based: An individual process which has its runtime memory
>        encrypted by an Attesting Environment in a way that no other
>        processes can read and decrypt that memory (e.g., [SGX] or
>        [I-D.tschofenig-rats-psa-token].)
> 
>    3.  VM-based: An entire Guest VM (or a set of containers within a
>        host) have been encrypted as a walled-garden unit by an Attesting
>        Environment.  The result is that the host operating system cannot
>        read and decrypt what is executing within that VM (e.g.,
>        [SEV-SNP] or [TDX].)

Maybe we should be unifying our definitions?

(I have comments on this attestation results categorization, but won’t go into them yet)

> (2) The security-level claim currently has very ambiguous definitions in the current EAT draft.  While I agree that a general four level scaled scale is easy to understand, the semantic meaning of any specific level is not. 

The definition is intentionally corse, but I don’t think it is ambiguous. Perhaps it is ambiguous if you are expecting something that is not a coarse characterization.

Maybe you can give some specifics of examples of how and where it is ambiguous?

Personally, I spent decades working on SW clueless about security HW. I also wonder if concerns have some relation to unfamiliarity with HW security features.  HW security features are central to the definition. The levels could be described in terms of HW security features:

1 — Any hardware
2 and 3  — Hardware that provides an isolated execution environment. Examples are a TEE, virtualization, or an entirely separate CPU.
4 — The isolated execution environment from 2 and 3 plus some defenses against HW attacks. Examples include defenses against probing traces, defenses against clock, power supply glitching, etc...

> In fact it is very nuanced.

It is a corse characterization.

It’s not intended to be nuanced. Not sure what is nuanced about it.

> Earlier in this thread I pointed to external documents of tens of thousands of words dedicated to just this subject.   See: https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/ <https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/>  

This kinda makes my point. A precise security classification system, even in a narrowed use case context like FIDO, is very difficult.

>      How do the EAT authors plan to address the semantic meaning of each specific level?  I believe the current wording to be insufficient.

I don’t think it makes sense to greatly expand the text or try for anything other than a coarse characterization. But maybe improved wording be more clear about the HW for each level? Maybe this is surprising to you, but it is actually hard for me to see how the definitions are unclear, so examples and specifics of what is unclear would be helpful.

But maybe there is an expectation for something that is not a coarse characterization, something that is sharp and formulaic? I don’t think that is possible.

Maybe if that expectation is lowered, security-level makes more sense?

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 8 Feb 2022 11:54:10 -0800

Just a short response since I write too much..

Yes, security-level is for characterizing security.

No, it’s not based on certification, not even FIDO.

> On Feb 8, 2022, at 1:21 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> 2.) SESIP Assurance Levels represent a level of certification (where 1-3 are basically these "self-assertions" and 4-5 are kind of endorsed, I think?)

It’s an example, but not the definition or basis of security-level. I explicitly object to it as the basis or definition.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 8 Feb 2022 23:19:13 +0000

Hi Laurence,

See inline: <eric>

From: Laurence Lundblade, February 8, 2022 2:38 PM

Hi Eric,

<eric> Coarse grain can certainly be fine in some scenarios.  The trick is whether different types of Relying Parties can meaningfully action something generic.  (And since I don't have deep insight into the IoT space, I will support the consensus of experts there.)

<eric> Three can be fine.  The magic is:

*	if vendors/users can consistently categorize based on very well-frame definitions of the three (or four) levels.
*	if the Relying Party will take different policy actions based the value received.

       [SEV-SNP] or [TDX].)

<eric> There are parallels for sure.  But:

*	the items above are not used in any ar4si object definitions.  

*	the items above are true/false categorizations which are easier to qualify than numerical levels, and
*	the text referenced above was trying to align/adopt terminology under development within the Confidential Computing Consortium.  (With luck future definitions will be adopted from there.)

<eric> Some form of unification would be good.   IMHO it would be most appropriate to unify with Section 2.3 on "Trustworthiness Claims".  To align there will need to be:

(a) consensus on some set of object design principles, such as those of Section 2.3.1.

(b) agreement on how Relying Party Policy decisions are explicitly made.  E.g. see Section 3.2, Steps 5 & 6.

Note that prior to the Claims of Section 2.3.4, I have worked with implementations which attempted a numeric "trust score", which varied from 0%-100%.  Humans at first seemed to like seeing this score upon an GUI, but this numeric abstraction was not useful for policy based decisions.  For example, you would see 100% for older hardware which simply didn't have the self-diagnosis capabilities.  I considered newer hardware scoring 80% far more protected in practice. 

 

On Feb 4, 2022, at 1:40 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

<eric> Here are a few off the top of my head...   

*	What should be a score is Firmware is known to be out-of-date, deprecated, and there is an active exploit.  

*	Is all Hardware equal even if (a) one can scan and deliver signatures spanning a nonce and real, current firmware measurements  (b) another can be programmed by a hacker just to spit out a pre-programmed value.  

*	Is bios configuration part of what should be considered in the level?  How can a Relying Party hope to keep up with which bios configurations might open up security exploits.

These examples ultimately will drive the kind of Attestation Result Claims which are more concrete to program policy against than some coarse level.

1 — Any hardware

 

<eric> hopefully the examples I list above show why a coarse number doesn't seem (to me) to support policy decisions which can discriminate based on the capabilities of underlying hardware.

Earlier in this thread I pointed to external documents of tens of thousands of words dedicated to just this subject.   See:  <https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/> https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/  

<eric> I am a fan of binary yes/no decisions which can easily mapped to policy actions.

<eric> This is one reason I am hoping the claims from Attesters have fully separated namespaces from those generated by Verifiers. 

Eric

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 8 Feb 2022 23:20:39 +0000

(not as chair)
> c) *If* a manufacturer has not obtained a certification but intends to do so, then the attester should not declare a security level higher than 0.  This value can be updated when then certification…

Alternatively, the Attester should remain silent as it is likely the Attesting Env has no way of determining the security level of a Target Env based on the manufacturer / 3rd party criteria.

On 2/8/22, 8:50 AM, "RATS on behalf of Giridhar Mandyam" <[email-masked] on behalf of [email-masked]> wrote:

    Henk/William,

    -Giri

    -----Original Message-----
    From: Henk Birkholz <[email-masked]> 
    Sent: Tuesday, February 8, 2022 1:22 AM
    To: Laurence Lundblade <[email-masked]>; Panwei (William) <[email-masked]>
    Cc: Michael Richardson <[email-masked]>; rats <[email-masked]>; Giridhar Mandyam <[email-masked]>; Smith, Ned <[email-masked]>; Eric Voit (evoit) <[email-masked]>
    Subject: Re: [Rats] Self-appraisal (was Re: Meaning of security level claim)

    Hi Laurence,

    where:

    Viele Grüße,

    Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Feb 2022 13:17:47 -0500

> If “security-level” and DLOA both need to be kept, then I would like to
    > call “security-level” as “security-self-declaration”, and define it as
    > the string type rather than the enumeration type, because it’s hard to
    > just use few numbers to map with all the possible certifications, and
    > it’s not good to do this mapping in IETF.

I would like security-level removed from the base spec.

    > I think the most important thing is that if you want to use a numerical
    > “level”, you need to clearly define the criteria. Otherwise, this
    > “level” would be confusing no matter where it appears in.

This needs to go in another document.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Feb 2022 13:21:27 -0500

Henk Birkholz <[email-masked]> wrote:
    > Additionally, a problem that I see today (and that has not been visible in
    > -09 of EAT, I think) is that you can just put these Claims in Attestation
    > Results

I think that "security-level" might be very appropriate in Attestation
Results.  But on there.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Feb 2022 13:24:44 -0500

Giridhar Mandyam <[email-masked]> wrote:
    > a) Many security certification regimes that could be relevant to
    > attesting environments are gradated.  Therefore, a manufacturer may
    > provide an attester that can meet a high-level of security assurance
    > (e.g. TPM, Secure Element), but can obtain a low level of certification
    > because they simply did not want to invest or support the necessary
    > level of 3rd-party validation required to get a corresponding
    > certification.

Then I think that the verifier, when it puts such a claim into the
Attestation Results, should use the "foobar-level".
There could actually multiple and different "foobar" for a single device.

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 9 Feb 2022 12:53:42 -0800

Hi Eric,

Really appreciate the engagement here. The back and forth is bringing important things to light for RATS in general.

Something like this needs to be added to the definition of security-level:

Security-level is a characterization of the implementation of the entity, particularly (but not exclusively) the hardware. Security-level doesn’t change over time. It is an indication of the design intent of the Attester manufacturer. 

Security-level can occur in Attestation Results. When it does, it has the same meaning as above. It is not a summary of the results of the Verification. For example, security-level doesn’t change if the firmware is out of date.

A Verifier may insert security-level in Attestation Results, but when they do so it is because they have some mapping from known characteristics of the implementation, not because of checks they performed. For example, they may receive claims that a common-cfitiera certified Secure Element is in use by the Attester and put security-level = HW in the Attestation results.

A composite device with multiple entities may have individual security-levels for each entity through the use of EAT submodules.

I think this shows how security-level is close to the categorization in draft-voit-rats-attestation-results, though more details to be explored.

This seems like a major clarification, and… still seems like more to work out on self-appraisal, claims common to Results and Evidence and a few other things in this thread.

(no comments below)

LL

> On Feb 8, 2022, at 3:19 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Laurence,
>  
> See inline: <eric>
>  
> if vendors/users can consistently categorize based on very well-frame definitions of the three (or four) levels.
> if the Relying Party will take different policy actions based the value received.
>  
>  
> the items above are not used in any ar4si object definitions.  
> the items above are true/false categorizations which are easier to qualify than numerical levels, and
> the text referenced above was trying to align/adopt terminology under development within the Confidential Computing Consortium.  (With luck future definitions will be adopted from there.)
>  
> On Feb 4, 2022, at 1:40 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> What should be a score is Firmware is known to be out-of-date, deprecated, and there is an active exploit.  
>  
> Is all Hardware equal even if (a) one can scan and deliver signatures spanning a nonce and real, current firmware measurements  (b) another can be programmed by a hacker just to spit out a pre-programmed value.  
>  
> Is bios configuration part of what should be considered in the level?  How can a Relying Party hope to keep up with which bios configurations might open up security exploits.
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 9 Feb 2022 16:36:01 -0500

No hats and chiming in late

Sent from my mobile device

> On Jan 31, 2022, at 8:49 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Right, that works for the attestation sets draft. The specification met (or not) might include a level where certain policy, configuration settings, or measurements were attested to a profile that provides a level.

With a hat, the standard (RATS drafts) just holds the place for this sort of thing without getting into the levels or what an organization or vendor might decide based on it.

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 9 Feb 2022 21:43:38 +0000

(not as chair)
See comments inline.

From: Laurence Lundblade <[email-masked]>
Date: Wednesday, February 9, 2022 at 12:53 PM
To: "Eric Voit (evoit)" <[email-masked]>
Cc: rats <[email-masked]>, Giridhar Mandyam <[email-masked]>, "Smith, Ned" <[email-masked]>, Michael Richardson <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

Hi Eric,

Security-level can occur in Attestation Results. When it does, it has the same meaning as above. It is not a summary of the
results of the Verification. For example, security-level doesn’t change if the firmware is out of date.

A Verifier may insert security-level in Attestation Results, but when they do so it is because they have some mapping from known characteristics of the implementation, not because of checks they performed. For example, they may receive
[1]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^      [2]^^^^^^^^^^^^^^
[nms] Are you saying in [1] that the Verifier obtained a security-level claim from an Endorser?

claims that a common-cfitiera certified Secure Element is in use by the Attester and put security-level = HW in the Attestation results.
[nms] Why wouldn’t the Verifier just copy the security-level claim from the Endorser into the Attestation Results if the Endorser was trusted to provide such claim? Wouldn’t this constitute a check that the Verifier performs – referring to [2]?

A composite device with multiple entities may have individual security-levels for each entity through the use of EAT submodules.
[nms] A common criteria certification applies to the platform (module + sub-modules). If in the cases of a composite device, the other components are independently evaluated and receive their own certification level. It would be a mistake if a Verifier combined the results of multiple evaluations into a single evalueation results / security level OMHO. It would be better for Verifier to forward the evaluation claim from Endorser to RP and let Appraisal policy for AR (APFAR) decide how best to interpret the *effective* evaluation / security level.

(no comments below)

LL

On Feb 8, 2022, at 3:19 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

See inline: <eric>

·         if vendors/users can consistently categorize based on very well-frame definitions of the three (or four) levels.

·         if the Relying Party will take different policy actions based the value received.

·         the items above are not used in any ar4si object definitions.

·         the items above are true/false categorizations which are easier to qualify than numerical levels, and

·         the text referenced above was trying to align/adopt terminology under development within the Confidential Computing Consortium.  (With luck future definitions will be adopted from there.)

1 — Any hardware

Earlier in this thread I pointed to external documents of tens of thousands of words dedicated to just this subject.   See: https://mailarchive.ietf.org/arch/msg/rats/JlWiWRnnHheMgIFX5gmVu7iQ9_4/

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 10 Feb 2022 11:42:33 -0800

Hi Ned,

With the clarification below that a security-level claim describes the designed security of the implementation, a security-level claim in Attestation Results could come from any of the following:

— From Endorsement — The manufacturer is describing the security-level of their product. The Verifier believes it because they trust the manufacturer. The security-level is passed on to the RP.

— Conveyed in Evidence — This is the same as above, but the claim is conveyed through the Evidence. It is just a different path to convey the manufacturer’s description of their product. 

— In Evidence for separate target environment — The Attester examines something about a distinct target environment on the composite device and puts security-level for it in Evidence.

— The Verifier maps it from OEMID  — The Verifier has a table that maps OEMIDs and HW models to security-level

— The Verifier maps Certifications — The Verifier has a table that maps different certifications to security-levels. Perhaps it knows the certifications by a DLOA in either Evidence or in an Endorsement

There might be others. It’s perfectly fine too if some use cases that don’t use it at all, ar4si perhaps

For composite and complex devices, I agree that you probably wouldn’t want to reduce the security-levels for all the submodules down to one. Through EAT submodules you can have a claims-set for each of the subsystems, each with its own security-level. The security-levels wouldn’t be combined. 

I have a pretty broad view of what a Verifier can do and what can show up in Attestation Results. It could be very minimal or very expansive. I think EAT should support that broad range.

It’s also fine for RATS to define things like ar4si that are specific to a set of use cases, that don’t cover the whole range of what is possible.

LL

> On Feb 9, 2022, at 1:43 PM, Smith, Ned <[email-masked]> wrote:
> 
> (not as chair)
> See comments inline.
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]>>
> Cc: rats <[email-masked] <mailto:[email-masked]>>, Giridhar Mandyam <[email-masked] <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] <mailto:[email-masked]>>, Michael Richardson <[email-masked] <mailto:[email-masked]>>
>> On Feb 8, 2022, at 3:19 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi Laurence,
>>  
>> See inline: <eric>
>>

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 10 Feb 2022 21:05:13 +0000

Laurence,
Thanks for up-leveling the conversation. It strikes me that the idea behind the security level claim is that whatever security evaluation criteria are in use, there exists a mapping to a numerical value known as the security-level claim. This seems a bit like Godel numbering where the security level is the number and the function is the security evaluation / result.

I think my main concern is that a lot of effort seems to be focused on the mapping aspect and little effort on defining ways of representing commonly used security criteria such as FIPS140 or Common Criteria. Why not start with defining claims for the well-known criteria, that way there is something to map to a Godel number (if the idea of mapping criteria to numbers turns out to be useful)?

Thx,
Ned

From: Laurence Lundblade <[email-masked]>
Date: Thursday, February 10, 2022 at 11:42 AM
To: "Smith, Ned" <[email-masked]>
Cc: "Eric Voit (evoit)" <[email-masked]>, rats <[email-masked]>, Giridhar Mandyam <[email-masked]>, Michael Richardson <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

Hi Ned,

LL

On Feb 9, 2022, at 1:43 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

(not as chair)
See comments inline.

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 9, 2022 at 12:53 PM
To: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>, Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>, "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Meaning of security level claim

Hi Eric,

(no comments below)

LL

Hi Laurence,

See inline: <eric>

•         if vendors/users can consistently categorize based on very well-frame definitions of the three (or four) levels.

•         if the Relying Party will take different policy actions based the value received.

•         the items above are not used in any ar4si object definitions.

•         the items above are true/false categorizations which are easier to qualify than numerical levels, and

•         the text referenced above was trying to align/adopt terminology under development within the Confidential Computing Consortium.  (With luck future definitions will be adopted from there.)

1 — Any hardware

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Feb 2022 11:21:07 -0800

Hi Ned,

> On Feb 10, 2022, at 1:05 PM, Smith, Ned <[email-masked]> wrote:
> 

Having some personal experience with organizing existing certifications programs into levels in my FIDO work, I don’t think that is a good idea here in an IETF standard. I think it would be a large amount of controversial work. Probably political. Probably this WG doesn’t have enough experience with certification.

My hope for security-level is a very coarse characterization of the intended security of the implementation. Mostly amounts to:
   1 — No HW support for security
   2, 3 — TEE/Virtualization to isolate an execution environment
   4 — Has some HW defenses against physical / electrical attacks

Said another way:
  1 — No special defenses
  2,3 — Intended to defend against remote / network-borne attacks by having a smaller attack surface
  4 — Intended to defends against attacks where the device is physically captured and taken to the attackers lair.

It doesn’t say how well it defends against any of these attacks, because that is very difficult to assess that. Doing it well requires months or years and of analysis of the target implementation.

I don’t see how we can do much more than this coarse description of the intended design in any practical way.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Sat, 12 Feb 2022 00:01:08 +0000

(not as chair)
Laurence,
You may be missing my point. I’m not saying IETF should define a criteria. Rather there are already defined criteria (e.g. FIPS and CC). The missing element is how an Endorser (vendor or certification lab) tells a Verifier what the results of the evaluation were.  For FIPS140-3 a claim might look like:

fips140-3 = {
     level => 1..4
     plus => bool .default false
}

Since FIPS criteria is well-known, has a certifying body, and certification results are classified clearly. There is no ambiguity to defining a claim for it. I don’t see what about the above CDDL is either political or outside something the IETF could consider defining.

On the other hand, something that is “a very coarse characterization of the intended security of the implementation” seems much less well-defined and subject to interpretation.

Thx,
Ned

Date: Friday, February 11, 2022 at 11:21 AM

Hi Ned,

On Feb 10, 2022, at 1:05 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

Said another way:
  1 — No special defenses

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 14 Feb 2022 12:52:27 -0800

Hi Ned,

OK. I see.

Was thinking that a DLOA is how the results of a certification is conveyed.

Seems like what you are proposing is the definition for claim for each certification type. That could be OK too, but wouldn’t want to take that on in EAT now. Seems like a good thing for a separate draft.

LL

> On Feb 11, 2022, at 4:01 PM, Smith, Ned <[email-masked]> wrote:
> 
> (not as chair)
> Laurence,
>> On Feb 10, 2022, at 1:05 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 14 Feb 2022 21:12:30 +0000

> Was thinking that a DLOA is how the results of a certification is conveyed.

DLOA has to be supported by the cert regimes (see Figure 4-1 of https://globalplatform.org/wp-content/uploads/2015/12/GPC_DigitalLetterOfApproval_v1.0.pdf).  Outside of the GlobalPlatform administered programs (GPTEE, SESIP) and a couple of others, it is not clear that a digital LoA would even be made available for a manufacturer to include in an EAT.

> Seems like what you are proposing is the definition for claim for each certification type. That could be OK too, but wouldn’t want to take that on in EAT now. Seems like a good thing for a separate…

Agree that it is beyond EAT.  A digital letter of evidence for any and all possible security cert. regimes seems to be a tough task for the IETF, much less the RATS WG.

-Giri

From: Laurence Lundblade <[email-masked]>
Sent: Monday, February 14, 2022 12:52 PM
To: Smith, Ned <[email-masked]>
Cc: Eric Voit (evoit) <[email-masked]>; rats <[email-masked]>; Giridhar Mandyam <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

Hi Ned,

OK. I see.

LL

On Feb 11, 2022, at 4:01 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

(not as chair)
Laurence,

fips140-3 = {
     level => 1..4

Thx,
Ned

---

From: "Shaw, Adrian" <[email-masked]>
Date: Tue, 15 Feb 2022 11:04:57 +0000

Hi Laurence,

Can you clarify how the security-level claim could be used in a real protocol? Why would a verifier choose to rely on this instead of some information that comes directly from an Endorser? Without an example, it just seems a better fit for an endorsement.

Thanks,
Adrian

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: 14 February 2022 20:52
To: Smith, Ned <[email-masked]>
Cc: rats <[email-masked]>; Giridhar Mandyam <[email-masked]>; Eric Voit (evoit) <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

Hi Ned,

OK. I see.

LL

(not as chair)
Laurence,

fips140-3 = {
     level => 1..4

Thx,
Ned

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 11, 2022 at 11:21 AM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>, rats <[email-masked]<mailto:[email-masked]>>, Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Meaning of security level claim

Hi Ned,

Said another way:
  1 — No special defenses

LL