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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 26 Jan 2022 17:48:25 +0000

If the claim is about "capturing the signing key, forging claims and at forging EATs", then how about "forging-protection"?   Security-level is confusingly broad.

Eric

From: Laurence Lundblade, January 25, 2022 1:48 PM

(forking the discussion since this is security-level semantics, not early assignment)

On Jan 24, 2022, at 6:11 AM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

A comment on the overall "Security Level Claim".  The overall intent of claim is about the signing key protection countermeasures.   A term like "security-level" and "security-level-label" seem overly generic for this task, considering everything we are doing is about security.   What about a more descriptive claim name like "signing-key-protection”?

It’s not just about signing key protection. Here’s some of the description:

This claim characterizes the entity's ability to defend against attacks aimed at capturing the signing key, forging claims and at forging EATs. 

For many implementations this is the security level of the Attesting Environment so it covers collecting the claims and such.

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 27 Jan 2022 18:13:07 +0000

Hi Eric,

I don’t really find the security-level overly broad. It has always been intended to provide an of the means by which assets are protected by the attesting environment. This goes beyond key protection in many cases to consider the mechanisms used to protect the claims that are being collected.

What we have is closely aligned with techniques commonly used to secure assets in many use-cases (FIDO authenticators, TEE,  TPMs, Secure MCUs and the like), and provides a useful indication of the security intent behand the realization of an attesting environment.

There are parallels with the definitions used in formal security certifications, but without the tie to a Protection Profile or similar security requirements that would go with a certification. An environment such as the Titan security chip<https://docs.opentitan.org/> may never receive a formal security certification, but it is quite clearly designed with the intent of offering significant hardware-based protection for assets, for example.

Best regards
Jeremy

On 26/01/2022, 17:49, "RATS" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
If the claim is about "capturing the signing key, forging claims and at forging EATs", then how about "forging-protection"?   Security-level is confusingly broad.

Eric

On Jan 24, 2022, at 6:11 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 27 Jan 2022 20:01:44 +0000

Hi Jeremy,

In my original emails below I had no issue with the objectives of this
claim.   It is just that the used term is so generic that it can mean
anything functional objective.  And this term has been used before (e.g.,
per Wikipedia: "Security Level
<https://en.wikipedia.org/wiki/Security_level> " in cryptography is a
measure of the strength that a cryptographic primitive - such as a cipher or
hash function - achieves.).

What all the descriptions about the objective being served by the claim
suggest to me that a term like "attesting-environment-protection-method(s)"
could be a better fit.  

I included an '(s)' on the proposed term because as per the EAT draft,
multiple countermeasures might be utilized in a particular level.  And after
doing additional thinking I do have some questions on the specifics of this
claim.  Perhaps it is relevant to have a mailing list discussion on whether
the claims should alternatively consist of a leaf-list of ENUMs rather than
a strict hierarchical level of four values.  Some reasons a discussion this
might be worthwhile:

(a) Restricted Level effectively is an opinion on whether the TCB is small
or not.  How do you make this choice?

(b)  Secure-Restricted points to a FIDO reference with three MUST and three
SHOULD requirements.  Are any of these six independent relevant to a relying
party?  Are only the MUST requirements required to be met?  Right now the
answer is no as a strict reading of the claim text makes the SHOULD claims
mandatory.

(c) Hardware: the term "substantial" can mean many things of interest to a
Relying Party.  For example, chips that automatically destroy persistent
data when extracted or physically examined are more costly.  But I don't
know if this is required by substantial or whether we need a "Hardware++"
level too.    Additionally, Hardware is supposed to include the capabilities
of lower levels.  As one of the SHOULD requirements of Secure Restricted is
that apps hosted be primarily security-oriented, a strict reading would
disqualify the majority of Apps from this level.

Eric

From: Jeremy O'Donoghue, January 27, 2022 1:13 PM

Hi Eric,

I don't really find the security-level overly broad. It has always been
intended to provide an of the means by which assets are protected by the
attesting environment. This goes beyond key protection in many cases to
consider the mechanisms used to protect the claims that are being collected.

What we have is closely aligned with techniques commonly used to secure
assets in many use-cases (FIDO authenticators, TEE,  TPMs, Secure MCUs and
the like), and provides a useful indication of the security intent behand
the realization of an attesting environment.

There are parallels with the definitions used in formal security
certifications, but without the tie to a Protection Profile or similar
security requirements that would go with a certification. An environment
such as the Titan security chip <https://docs.opentitan.org/>  may never
receive a formal security certification, but it is quite clearly designed
with the intent of offering significant hardware-based protection for
assets, for example. 

Best regards

Jeremy

On 26/01/2022, 17:49, "RATS" <[email-masked]
<mailto:[email-masked]> > wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of
any links or attachments, and do not enable macros.

If the claim is about "capturing the signing key, forging claims and at
forging EATs", then how about "forging-protection"?   Security-level is
confusingly broad.

Eric

(forking the discussion since this is security-level semantics, not early
assignment)

On Jan 24, 2022, at 6:11 AM, Eric Voit (evoit) <[email-masked]> wrote:

A comment on the overall "Security Level Claim".  The overall intent of
claim is about the signing key protection countermeasures.   A term like
"security-level" and "security-level-label" seem overly generic for this
task, considering everything we are doing is about security.   What about a
more descriptive claim name like "signing-key-protection"?

It's not just about signing key protection. Here's some of the description:

This claim characterizes the entity's ability to defend against attacks
aimed at capturing the signing key, forging claims and at forging EATs. 

For many implementations this is the security level of the Attesting
Environment so it covers collecting the claims and such.

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 28 Jan 2022 04:43:28 +0000

I don't think it is that difficult to concretize the mapping.  When we started editing the doc, there were security certification programs such as FIDO already in existence.  Since that time, GlobalPlatform's SESIP program and ARM's PSA Certified program have also matured.  All of these programs have progressive levels based on the level of validation performed on the target-of-evaluation (TOE).

For instance, a device can achieve FIDO Level 1 via manufacturer questionnaire (with the manufacturer expected to provide honest answers).  The TOE may actually contain a TCB that provides high-levels of security assurance (e.g. TPM), but Level 1 is what the manufacturer is willing invest in  for certification so that is the maximum achievable level of certification available.

If approached from that perspective, and equivalence mapping could be:

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

Granted, this is information that is reported by the device so one could consider it self-attested data.  That being said - it is not in the interests of a manufacturer to report a security level that does not correspond to any kind of 3rd-party validation in my opinion, as it affects reputation.  A bad actor may also produce a device that reports a higher level of security than for which it could be certified, but in that case a relying party should also make use of a valid endorsement (https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-8.2).

References:

[1]  https://fidoalliance.org/certification/authenticator-certification-levels/
[2] https://en.wikipedia.org/wiki/PSA_Certified (Sorry for the Wikipedia reference, but this description is fairly accessible and accurate)
[3] https://www.trustcb.com/iot/sesip/

From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Thursday, January 27, 2022 12:02 PM
To: Jeremy O'Donoghue <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: rats <[email-masked]>; Smith, Ned <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

In my original emails below I had no issue with the objectives of this claim.   It is just that the used term is so generic that it can mean anything functional objective.  And this term has been used before (e.g., per Wikipedia: "Security Level<https://en.wikipedia.org/wiki/Security_level>" in cryptography is a measure of the strength that a cryptographic primitive - such as a cipher or hash function - achieves.).

What all the descriptions about the objective being served by the claim  suggest to me that a term like "attesting-environment-protection-method(s)" could be a better fit.

I included an '(s)' on the proposed term because as per the EAT draft, multiple countermeasures might be utilized in a particular level.  And after doing additional thinking I do have some questions on the specifics of this claim.  Perhaps it is relevant to have a mailing list discussion on whether the claims should alternatively consist of a leaf-list of ENUMs rather than a strict hierarchical level of four values.  Some reasons a discussion this might be worthwhile:

(a) Restricted Level effectively is an opinion on whether the TCB is small or not.  How do you make this choice?

(b)  Secure-Restricted points to a FIDO reference with three MUST and three SHOULD requirements.  Are any of these six independent relevant to a relying party?  Are only the MUST requirements required to be met?  Right now the answer is no as a strict reading of the claim text makes the SHOULD claims mandatory.

(c) Hardware: the term "substantial" can mean many things of interest to a Relying Party.  For example, chips that automatically destroy persistent data when extracted or physically examined are more costly.  But I don't know if this is required by substantial or whether we need a "Hardware++" level too.    Additionally, Hardware is supposed to include the capabilities of lower levels.  As one of the SHOULD requirements of Secure Restricted is that apps hosted be primarily security-oriented, a strict reading would disqualify the majority of Apps from this level.

Eric

I don't really find the security-level overly broad. It has always been intended to provide an of the means by which assets are protected by the attesting environment. This goes beyond key protection in many cases to consider the mechanisms used to protect the claims that are being collected.

Best regards
Jeremy

On 26/01/2022, 17:49, "RATS" <[email-masked]<mailto:[email-masked]>> wrote:

Eric

A comment on the overall "Security Level Claim".  The overall intent of claim is about the signing key protection countermeasures.   A term like "security-level" and "security-level-label" seem overly generic for this task, considering everything we are doing is about security.   What about a more descriptive claim name like "signing-key-protection"?

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 28 Jan 2022 15:06:28 +0000

Hi Giridhar,

The text you have below describing levels is far superior to the current
text in the EAT draft.   This is why I provided examples (a), (b), and (c)
below on what the text of draft-ietf-rats-eat actually says right now.

Assuming for a moment that others agree that the current draft text is
insufficient, what should the text actually say?  Mapping below, the high
level FIDO guidance its levels is 57,000 words
<https://fidoalliance.org/specs/fido-security-requirements/fido-authenticato
r-security-requirements-v1.5-fd-20211102.html> .   Looking just at the
specifics of "Authenticator Certification Level L1+", there is a 34,000 word
questionnaire
<https://media.fidoalliance.org/wp-content/uploads/2021/12/FINAL-FIDO_Authen
ticator_Certification-L1_VQ_20201231_RELEASE-1.xlsx> .  A quick look at the
PSA resources <https://www.psacertified.org/what-is-psa-certified/>
suggests definitions which are equivalently large.

Considering this, my initial reaction is why can't the EAT claims simply
adopt another organizations' definitions rather than trying to create
something new?  I.e., have the claim be "external-certification-level", and
make the definitions the industry certifications as listed below?  This
would seem to have the benefit of removing the IETF having to define/defend
new meanings, and the downstream costs of everyone having to negotiate these
mappings.

Eric 

From: Giridhar Mandyam <[email-masked]> 
Sent: Thursday, January 27, 2022 11:43 PM
To: Eric Voit (evoit) <[email-masked]>; Jeremy O'Donoghue
<[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: rats <[email-masked]>; Smith, Ned <[email-masked]>
Subject: RE: [Rats] Meaning of security level claim

I don't think it is that difficult to concretize the mapping.  When we
started editing the doc, there were security certification programs such as
FIDO already in existence.  Since that time, GlobalPlatform's SESIP program
and ARM's PSA Certified program have also matured.  All of these programs
have progressive levels based on the level of validation performed on the
target-of-evaluation (TOE).  

For instance, a device can achieve FIDO Level 1 via manufacturer
questionnaire (with the manufacturer expected to provide honest answers).
The TOE may actually contain a TCB that provides high-levels of security
assurance (e.g. TPM), but Level 1 is what the manufacturer is willing invest
in  for certification so that is the maximum achievable level of
certification available.

Sec Level = 1:  Lowest level of security assurance.  No 3rd-party validation
of TOE.

Sec Level = 4:  FIDO Level 3/3+ or higher, SESIP Level 3, ARM PSA Cert Level
3

Granted, this is information that is reported by the device so one could
consider it self-attested data.  That being said - it is not in the
interests of a manufacturer to report a security level that does not
correspond to any kind of 3rd-party validation in my opinion, as it affects
reputation.  A bad actor may also produce a device that reports a higher
level of security than for which it could be certified, but in that case a
relying party should also make use of a valid endorsement
(https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-
8.2).

References:

[1]
https://fidoalliance.org/certification/authenticator-certification-levels/

[2] https://en.wikipedia.org/wiki/PSA_Certified (Sorry for the Wikipedia
reference, but this description is fairly accessible and accurate)

From: RATS <[email-masked] <mailto:[email-masked]> > On Behalf
Of Eric Voit (evoit)
Sent: Thursday, January 27, 2022 12:02 PM
To: Jeremy O'Donoghue <[email-masked]
<mailto:[email-masked]> >; Laurence Lundblade
<[email-masked] <mailto:[email-masked]> >
Cc: rats <[email-masked] <mailto:[email-masked]> >; Smith, Ned
<[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Meaning of security level claim

Hi Jeremy,

 

Eric

Hi Eric,

Best regards

Jeremy

Eric

 

On Jan 24, 2022, at 6:11 AM, Eric Voit (evoit) <[email-masked]
<mailto:[email-masked]> > wrote:

LL

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 28 Jan 2022 17:11:18 +0000

Hi Eric, Giri, all,

Currently, in PSA evidence we have an optional self-asserting claim
called Certification Reference [1].  It is an opaque pointer into a
blob of certification-related metadata (that includes the PSA
"security level") published by the certification lab.

However, its usage is not particularly solid (self-assertion == meh!)
and we are looking at the association between attester and
certification related information being made instead by the verifier
based on endorsements from the relevant supply chain entity /
certification lab.

So, whilst Eric's suggestion seems to me to provide a very reasonable
way forward (though there are registration aspects to be taken into
account too), I don't think we'd use it, mostly because of the
self-asserting nature of such claim.

[1] https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-08.html#section-3.2.3

On Fri, Jan 28, 2022 at 3:06 PM Eric Voit (evoit)
<evoit=[email-masked]> wrote:
>
> Hi Giridhar,
>
>
>
> The text you have below describing levels is far superior to the current text in the EAT draft.   This is why I provided examples (a), (b), and (c) below on what the text of draft-ietf-rats-eat actually says right now.
>
>
>
> Assuming for a moment that others agree that the current draft text is insufficient, what should the text actually say?  Mapping below, the high level FIDO guidance its levels is 57,000 words.   Looking just at the specifics of "Authenticator Certification Level L1+", there is a 34,000 word questionnaire.  A quick look at the PSA resources suggests definitions which are equivalently large.
>
>
>
> Considering this, my initial reaction is why can't the EAT claims simply adopt another organizations' definitions rather than trying to create something new?  I.e., have the claim be "external-certification-level", and make the definitions the industry certifications as listed below?  This would seem to have the benefit of removing the IETF having to define/defend new meanings, and the downstream costs of everyone having to negotiate these mappings.
>
>
>
> Eric
>
>
>
> To: Eric Voit (evoit) <[email-masked]>; Jeremy O'Donoghue <[email-masked]>; Laurence Lundblade <[email-masked]>
> I don’t think it is that difficult to concretize the mapping.  When we started editing the doc, there were security certification programs such as FIDO already in existence.  Since that time, GlobalPlatform’s SESIP program and ARM’s PSA Certified program have also matured.  All of these programs have progressive levels based on the level of validation performed on the target-of-evaluation (TOE).
>
>
>
> In my original emails below I had no issue with the objectives of this claim.   It is just that the used term is so generic that it can mean anything functional objective.  And this term has been used before (e.g., per Wikipedia: "Security Level" in cryptography is a measure of the strength that a cryptographic primitive — such as a cipher or hash function — achieves.).
>
>
>
> There are parallels with the definitions used in formal security certifications, but without the tie to a Protection Profile or similar security requirements that would go with a certification. An environment such as the Titan security chip may never receive a formal security certification, but it is quite clearly designed with the intent of offering significant hardware-based protection for assets, for example.
>
>
>
> Best regards
>
> Jeremy
>
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

--
Thomas

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 28 Jan 2022 17:18:42 +0000

Hi Thomas,

The dloas claim does exactly what you describe, simply based on an approach used by GlobalPlatform (although it is really just a URL, so fairly flexible). If the URL is held by a trusted entity (e.g. a Certification Body), it is stronger than a self-assertion.

Jeremy

On 28/01/2022, 17:11, "Thomas Fossati" <[email-masked]> wrote:

Hi Eric, Giri, all,

--
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 28 Jan 2022 09:25:10 -0800

In many cases security-level will not be self assessment:

- It is used in attestation results

- The attester is known to be trustworthy in reporting the the security level. Perhaps the device maker burns some fuses in the chip to set the security level at the factory.

- It is claiming the lowest level possible (as a warning)

- The attester is reporting it for a submodule, for example a TEE is indicating the lower security level of an HLOS like Android.

- The attester as received proof of the security level of a submodule.

I have other things to say here, but need a little more time to write them out.

LL

> On Jan 28, 2022, at 9:11 AM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Eric, Giri, all,
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jan 2022 14:20:13 -0500

> - It is claiming the lowest level possible (as a warning)

I think that this is the key part that makes it useful, even when self-asserted.

It is saying, "I am *least* THIS vulnerable",
          not "I am at *most* THIS secure".

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

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 30 Jan 2022 10:57:41 -0800

On Jan 28, 2022, at 11:20 AM, Michael Richardson <[email-masked]> wrote:
>          not "I am at *most* THIS secure”.

Yes, exactly.

The old text made it too likely someone would claim HW security if just one part of the attester used HW security.

I’ve made a PR <https://github.com/ietf-rats-wg/eat/pull/162> to make this more clear. The new text is:

The security level claimed MUST be for the weakest point in the entity, not the strongest. For example, if attestation key is protected by hardware, but the rest of the attester is in a TEE, the claim must be for secure-restriced.¶ <file:///Users/lgl/Documents/EAT/eat-drafts/sl1/draft-ietf-rats-eat.html#section-3.11-4>

Happy to have suggestions for wording improvements here.

Thanks!

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 30 Jan 2022 11:54:22 -0800

Here’s some frame up for the current choice in the EAT draft. Three options. In theory we can have combination of them. They are not mutually exclusive.

Report certifications received
This is nothing more than providing a reference to and identification of the exact certifications received. All characterization of security is left up to the certification program. This is just a reporting activity. 

Classification Scheme for Certifications Received
Here we define 3 to 4 high-level buckets in to which certifications received can be sorted. This will involve writing criteria against which to evaluate certification programs and/or evaluating certification programs. It is probably better to write criteria rather so that we don’t have to evaluate all certification programs and so future ones can be anticipated.

Simplest Possible Security Classification 
Some simple coarse security levels are defined. They are generally independent of certification schemes. They are useful to give a very rough idea of the effort put into security.

The first one is clear and straight forward because we don’t need any discussion of characterization of how secure something is. The certification program has already done that. This is the DLOAs claim that exists now (or some other similar means if we don’t like DLOAs). 

For the second one, I understand the desire for clarity and sharpness in the definition this might give over the existing security-level claim, but it seems like large and difficult work to me. It would require a lot of learning and thinking about a lot of security certification programs. (Further comments below). If we did anything like this, it would have to be separate document, not part of the EAT draft. It’s just too big IMO.

The last one is what I want security-level to be. I would even be OK reducing it to three levels instead of four and to wording improvements and to adding examples. It won’t be useful for everyone, but I think it is useful enough to be retained.

Note that security-level can be reported even if there is no certification. (The reference to FIDO AROE is not a requirement for FIDO certification). Whether an RP believes it or not will depend on the circumstances, but it will be believable in some cases.

One comment below.

LL

The FIDO security levels is a mapping of existing certification programs to a set of buckets. The FIDO security levels were hard to construct. It was a many-year balancing act involving many slide decks.

The FIDO security levels mapping solves a different problem than we are considering here. Its job is to define specific criteria and process to achieve FIDO certification. It only mapped programs to the levels that were suited to FIDO certification and for which there was business interest. It is a simpler thing to do than a general classification scheme for certification programs.

Different certification programs have very different characteristics. Mapping them is not easy. FIPS focuses highly on the implementation of the cryptography. Common Criteria is very thorough and covers everything but is very expensive. Others tend towards check lists and don’t involve threat analysis of the TOE.

> On Jan 28, 2022, at 7:06 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Giridhar,
>  
> Assuming for a moment that others agree that the current draft text is insufficient, what should the text actually say?  Mapping below, the high level FIDO guidance its levels is 57,000 words <https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-security-requirements-v1.5-fd-20211102.html>.   Looking just at the specifics of "Authenticator Certification Level L1+", there is a 34,000 word questionnaire <https://media.fidoalliance.org/wp-content/uploads/2021/12/FINAL-FIDO_Authenticator_Certification-L1_VQ_20201231_RELEASE-1.xlsx>.  A quick look at the PSA resources <https://www.psacertified.org/what-is-psa-certified/> suggests definitions which are equivalently large.
>  

I think adopting existing certification work is an excellent and proper thing to do. The primary way to do that is by reporting certifications received. We have the DLOAs claim for that. Maybe there could be another way of reporting.

The only external certification level scheme I know of is FIDO’s security levels, but it only covers a few programs (not FIPS, Arm PSA…) and is FIDO specific. I don’t think there is any ready-made levels classification scheme we can use.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 31 Jan 2022 08:56:48 +0000

+1 for this formulation.

On 30/01/2022, 18:57, "RATS" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
On Jan 28, 2022, at 11:20 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

Yes, exactly.

I’ve made a PR<https://github.com/ietf-rats-wg/eat/pull/162> to make this more clear. The new text is:

The security level claimed MUST be for the weakest point in the entity, not the strongest. For example, if attestation key is protected by hardware, but the rest of the attester is in a TEE, the claim must be for secure-restriced.¶<file:///Users/lgl/Documents/EAT/eat-drafts/sl1/draft-ietf-rats-eat.html#section-3.11-4>

Thanks!

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 31 Jan 2022 09:10:02 +0000

I’m really against attempting the second option. It is incredibly hard, likely to send us down a rat-hole (pun intended!)

One of the issues that quickly arises when trying to align classification of security schemes is that politics – both from companies participating at the various SDOs and Industry Organizations and, increasingly from national and supra-national bodies. I wish I did not have to say, for example, that the forthcoming EUCC scheme can, under some circumstances, end up classifying a piece of CRM software as “more secure” than a constrained device with HW protection for keys and extensive side-channel protection, but this is unfortunately true(*).

I have spent more time than I would ever like to admit involved in such discussions, and I know that Laurence has had similar past experience. The classifications we have with security-level are imperfect, rather broad, and self-declared, but they do have some grounding in the way that real systems are built, and this should make them surprisingly useful in practice. Perhaps we can discuss how the text describing security-level can be improved, but I do believe the basic principle is the right one.

Between them, the first and third options, which we already have in the draft, cover everything a relying party might reasonably want to know about an attesting environment.
Best regards
Jeremy

(*) because under EUCC, only National CBs can certify product at more than a “basic” level of protection, even if a lab is satisfied that the product is more secure than that.

On 30/01/2022, 19:54, "Laurence Lundblade" <[email-masked]> wrote:

One comment below.

LL

On Jan 28, 2022, at 7:06 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Giridhar,

Assuming for a moment that others agree that the current draft text is insufficient, what should the text actually say?  Mapping below, the high level FIDO guidance its levels is 57,000 words<https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-security-requirements-v1.5-fd-20211102.html>.   Looking just at the specifics of "Authenticator Certification Level L1+", there is a 34,000 word questionnaire<https://media.fidoalliance.org/wp-content/uploads/2021/12/FINAL-FIDO_Authenticator_Certification-L1_VQ_20201231_RELEASE-1.xlsx>.  A quick look at the PSA resources<https://www.psacertified.org/what-is-psa-certified/> suggests definitions which are equivalently large.

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 31 Jan 2022 10:31:58 +0100

Hi Jeremy,

I highlighted what I think to be a key statement.

On 31.01.22 10:10, Jeremy O'Donoghue wrote:
> cover everything a relying party might reasonably want to know

This is why I indicated that we are starting to conflate Evidence and 
Attestation Results here. The current security-level Claim in Evidence 
is probably fine, as it is clearly a self-assertion. The same 
security-level in Attestation Results is semantically not the same. In 
Attestation Results now you do not know, if this to be interpreted as a 
self-assertion that was placed in Evidence or the output of policy and 
appraisal of Evidence. At least not by that Claim alone and have to 
admit I would not know how to produce an EAT that tells me that.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jan 2022 09:55:31 -0500

Laurence Lundblade <[email-masked]> wrote:
    > Classification Scheme for Certifications Received Here we define 3 to 4
    > high-level buckets in to which certifications received can be
    > sorted. This will involve writing criteria against which to evaluate
    > certification programs and/or evaluating certification programs. It is
    > probably better to write criteria rather so that we don’t have to
    > evaluate all certification programs and so future ones can be
    > anticipated.

I agree with Jeremy.
I don't see any value in a device telling anyone about Certifications
Received.  a) self-assertion, b) will change over time.

The only useful thing here is for the device to assert, "I am a FOO model,
running Firmware Bar".
The rest is in Evaluation Policy, Reference Values, etc. which would permit a
mapping that "model FOO" has certification X.

I would in general, discourage a RP from asking about certification X,
preferring something a bit higher level, but some of them will want this.
(Many of them will be wrong but they will think they need it)

So, I can see some kind of certification being in the Attestation Results.
I suspect that some kind of embedded W3C Verified Credential is probably
correct here.   ("Device Models FOO has passed eir's on-street driving test")
[I prefer Elverson pronouns for AIs:
https://en.wikipedia.org/wiki/Spivak_pronoun ]

I don't ever see these as being Evidence.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 31 Jan 2022 16:34:36 +0000

I think this also highlights something interesting.   

When we first started talking EAT, the claims were coming from Attesters.  But a Relying Party's Appraisal Policy is about Attestation Results.  And at the Relying Party there is a lot of checking to do even, when the RP trusts a Verifier. 

Based on this thread I have been trying to internalize how a static, self-asserted security-level could be meaningfully used by either a Verifier or Relying Party.

Thought 1: a Verifier will have to understand what kind of Claims should be accepted by a specific type of Attester.  And knowing the Attesting device type means the Verifier *usually* should already knows the static, self-asserted security-level.

Thought 2: I have been trying to Relying Party pseudo-code that would act upon a self-asserted security-level in the Appraisal Policy for Attestation Results.  The single Appraisal Policy example I can come up with is something like: 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.  Another way to say this policy is the Relying Party should only be able to use the self-asserted security-level claim when the level is entangled with some Verifier validation.

These two thoughts highlight that not all EAT Claims should be equally digestible by Relying Party's Appraisal Policy for Attestation Results.  And right now we have no guidance for how specific Claims can be safely used at the Relying Party.  Ultimately this is why I find the term "security-level" a bit dangerous.  An uneducated Relying Party coder might just write a Appraisal Policy which accepts this value.  Personally I think this particular claim should only be visible to the Verifier, and never be directly encoded in AR.  If the Relying Party really needs such a claim, a safer name would be "self-asserted-security-level".

Eric

P.S.: At some point, the RATS WG should have an opinion on what the visible Policy Language objects should be for processing by the Appraisal Policy for Attestation Results.  Starting with a very rich language here could prove counter-productive.

> From: Henk Birkholz, January 31, 2022 4:32 AM
> 
> Hi Jeremy,
> 
> This is why I indicated that we are starting to conflate Evidence and Attestation
> Results here. The current security-level Claim in Evidence is probably fine, as it is
> clearly a self-assertion. The same security-level in Attestation Results is
> semantically not the same. In Attestation Results now you do not know, if this to
> be interpreted as a self-assertion that was placed in Evidence or the output of
> policy and appraisal of Evidence. At least not by that Claim alone and have to

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 31 Jan 2022 17:07:25 +0000

Sorry to add to an already long discussion, but I wanted to clarify something regarding the example mapping I sent below.

Even if a certification has been obtained by the manufacturer for the entity in question, the security level is *always* a self-reported value.  In that regards, the 2nd option is not really meaningful ('Classification for Certification Levels Received') nor valid.  My example below comparing to SESIP/FIDO/PSA Cert. sec. cert levels was an example of how an implementor can make the determination of what value to set the security level, but the security level claim ultimately will be self-reported.  I believe it is not in an entity manufacturer's interest  to over-report its security assurance if it has obtained a 3rd-party certification (due to the impact to reputation), and a bad actor may over-report its security level regardless of security certification status.  It is up to the Relying Party as to how much trust they put into the claim value, and I think this is beyond the scope of the EAT document.

That being said, I can think of a couple of different ways an RP can assign trust to the security level as reported by the entity (or more precisely, the entity attester):

a) An attestation can be accompanied by an endorsement (obtained in-band in the EAT token or out-of-band), and the endorser may provide implicit or explicit assurances that the entity reporting of security level is accurate.

b) An RP can rely on a trusted 3rd-party service to validate the reported security level against (e.g. FIDO Metadata Service, NIST's CMVP lookup service).

I believe the above options are already addressed in https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-7.1.  Option a) relates to the trust anchor, and b) can be included in the appraisal policy.

-Giri

From: Jeremy O'Donoghue <[email-masked]>
Sent: Monday, January 31, 2022 1:10 AM
To: Laurence Lundblade <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; rats <[email-masked]>; Smith, Ned <[email-masked]>
Subject: Re: [Rats] Meaning of security level claim

I'm really against attempting the second option. It is incredibly hard, likely to send us down a rat-hole (pun intended!)

One of the issues that quickly arises when trying to align classification of security schemes is that politics - both from companies participating at the various SDOs and Industry Organizations and, increasingly from national and supra-national bodies. I wish I did not have to say, for example, that the forthcoming EUCC scheme can, under some circumstances, end up classifying a piece of CRM software as "more secure" than a constrained device with HW protection for keys and extensive side-channel protection, but this is unfortunately true(*).

Best regards
Jeremy

(*) because under EUCC, only National CBs can certify product at more than a "basic" level of protection, even if a lab is satisfied that the product is more secure than that.

On 30/01/2022, 19:54, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Here's some frame up for the current choice in the EAT draft. Three options. In theory we can have combination of them. They are not mutually exclusive.

Classification Scheme for Certifications Received
Here we define 3 to 4 high-level buckets in to which certifications received can be sorted. This will involve writing criteria against which to evaluate certification programs and/or evaluating certification programs. It is probably better to write criteria rather so that we don't have to evaluate all certification programs and so future ones can be anticipated.

The first one is clear and straight forward because we don't need any discussion of characterization of how secure something is. The certification program has already done that. This is the DLOAs claim that exists now (or some other similar means if we don't like DLOAs).

For the second one, I understand the desire for clarity and sharpness in the definition this might give over the existing security-level claim, but it seems like large and difficult work to me. It would require a lot of learning and thinking about a lot of security certification programs. (Further comments below). If we did anything like this, it would have to be separate document, not part of the EAT draft. It's just too big IMO.

The last one is what I want security-level to be. I would even be OK reducing it to three levels instead of four and to wording improvements and to adding examples. It won't be useful for everyone, but I think it is useful enough to be retained.

One comment below.

LL

Different certification programs have very different characteristics. Mapping them is not easy. FIPS focuses highly on the implementation of the cryptography. Common Criteria is very thorough and covers everything but is very expensive. Others tend towards check lists and don't involve threat analysis of the TOE.

Hi Giridhar,

The only external certification level scheme I know of is FIDO's security levels, but it only covers a few programs (not FIPS, Arm PSA...) and is FIDO specific. I don't think there is any ready-made levels classification scheme we can use.

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 31 Jan 2022 18:09:45 +0100

Hi all,

it seems to me that Eric's comment is actually reflected by one of 
Giri's earlier comments, which stated that "Security Level was 
designated for early assignment in draft -09". -09 of EAT included no 
tangible content about Attestation Results. At that point in time, the 
document was essentially about Attester produced Evidence and included 
two notes that highlighted:

> TODO: mention use for Attestation Evidence and Results.

and

> TODO: add paragraph here about use for Attestation Evidence and for Results.

Maybe that is the reason for concern today. That the document grew in 
scope in a way that now makes some individuals uncomfortable with the 
application of certain claim. In this case, namely security-level in 
Attestation Results, I think.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 31 Jan 2022 17:17:51 +0000

(not as chair)
The basic assumption of attestation results is the claims asserted by the Verifier are meaningful to the RP / Appraisal policy for AR. The other assumption is the RP and Attester interact as a consequence of successful appraisals. Hence, the claims asserted by the Attester should not be entirely foreign to the RP. It is reasonable to assume that a Verifier might forward Evidence claims as AR claims where the only difference, is the Verifier vetted them. 

Similarly for Endorsement claims, the Endorser could assert claims that are forwarded to the RP where the only difference is the Verifier vetted them. 

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. 

The third option is the Verifier derives a security level claim through inference based on a set of other claims. But given the RP trusts the Verifier, does it matter if the security level claim was the result of inference vs. endorsement vs. evidence? I don't think the RP should care too much about it except that a forensic log might want to know.

-Ned

On 1/31/22, 8:35 AM, "RATS on behalf of Eric Voit (evoit)" <[email-masked] on behalf of evoit=[email-masked]> wrote:

    Eric

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 31 Jan 2022 18:37:01 +0100

Hi Ned,

On 31.01.22 18:17, Smith, Ned wrote:
> (not as chair)
> The basic assumption of attestation results is the claims asserted by the Verifier are meaningful to the RP / Appraisal policy for AR. The other assumption is the RP and Attester interact as a consequence of successful appraisals. Hence, the claims asserted by the Attester should not be entirely foreign to the RP.

Yes, I think both assumptions capture the fundamental idea well. Also an 
Entity can take on both the role of a Verifier and a Relying Party. As 
Giri also highlighted in a different branch of this thread, the RATS 
architecture is robust enough to cover various scenarios.

> It is reasonable to assume that a Verifier might forward Evidence claims as AR claims where the only difference, is the Verifier vetted them.

That is also a correct assumption and this is the open construction site 
that I (as an individual) see here.

> Similarly for Endorsement claims, the Endorser could assert claims that are forwarded to the RP where the only difference is the Verifier vetted them.

Sure. In this flow, Evidence and Endorsement look very alike to a 
Relying Party, I think.

> 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…

This seems to be a vital question that we should resolve rather quickly.

> The third option is the Verifier derives a security level claim through inference based on a set of other claims. But given the RP trusts the Verifier, does it matter if the security level claim wa…

While you list that as the third option, to me this "feels" like the 
default case. The "Verifier's decision" can be based on security-level, 
or derived from endorsed Claims or way more complex policies.

What is really important to Relying Parties, I think, is that it is very 
clear, as simply as possible, and unambiguous what the Verifier is 
trying to "tell the Relying Party". If that leads to misunderstanding or 
interoperability issues, aren't all the preceding steps basically moot?

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 31 Jan 2022 18:50:24 +0100

Just in case, I skimmed the whole EAT-11 I-D and now I have to correct 
myself here. Already the abstract says:

> An Entity Attestation Token (EAT) provides a signed (attested) set of claims that describe state and characteristics of an entity, typically a device like a phone or an IoT device. These claims are used by a Relying Party to determine how much it wishes to trust the entity. An EAT is either a CWT or JWT with some attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT.

I am a bit lost, now. Whenever we discussed EAT in the past it seemed 
very clear to me that we are talking about Evidence. Apparently, the 
abstract tells me I am mistaken.

So, I can try to fall back to what is written in EAT-11 Section 1.3.1 
and 1.3.2:

> Any claim defined in this document or in the IANA CWT or JWT registry may be used in Attestation Evidence.

That sounds rather straight forward to me.

> Any claim defined in this document or in the IANA CWT or JWT registry may be used in Attestation Results.

That sounds less simple, but the next paragraph states:

> Many claims in Attestation Evidence simply will pass through the Verifier to the Relying Party without modification. They will be verified as authentic from the device by the Verifier just through normal verification of the Attester's signature. The UEID, Section 3.4, and Location, Section 3.14, are examples of claims that may be passed through.

That seems to cover the "self-assertions". Is security-level covered by 
this text, too? Is that the problem?

Viele Grüße,

Henk

On 31.01.22 18:09, Henk Birkholz wrote:
>> When we first started talking EAT, the claims were coming from 
>> Attesters.  But a Relying Party's Appraisal Policy is about 
>> Attestation Results.  And at the Relying Party there is a lot of 
>> checking to do even, when the RP trusts a Verifier.
>>
>> Based on this thread I have been trying to internalize how a static, 
>> self-asserted security-level could be meaningfully used by either a 
>> Verifier or Relying Party.
>>
>> Thought 1: a Verifier will have to understand what kind of Claims 
>> should be accepted by a specific type of Attester.  And knowing the 
>> Attesting device type means the Verifier *usually* should already 
>> knows the static, self-asserted security-level.
>>
>> Thought 2: I have been trying to Relying Party pseudo-code that would 
>> act upon a self-asserted security-level in the Appraisal Policy for 
>> Attestation Results.  The single Appraisal Policy example I can come 
>> up with is something like: 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.  Another way to say this policy is the Relying Party 
>> should only be able to use the self-asserted security-level claim when 
>> the level is entangled with some Verifier validation.
>>
>> These two thoughts highlight that not all EAT Claims should be equally 
>> digestible by Relying Party's Appraisal Policy for Attestation 
>> Results.  And right now we have no guidance for how specific Claims 
>> can be safely used at the Relying Party.  Ultimately this is why I 
>> find the term "security-level" a bit dangerous.  An uneducated Relying 
>> Party coder might just write a Appraisal Policy which accepts this 
>> value.  Personally I think this particular claim should only be 
>> visible to the Verifier, and never be directly encoded in AR.  If the 
>> Relying Party really needs such a claim, a safer name would be 
>> "self-asserted-security-level".
>>
>> Eric
>>
>> P.S.: At some point, the RATS WG should have an opinion on what the 
>> visible Policy Language objects should be for processing by the 
>> Appraisal Policy for Attestation Results.  Starting with a very rich 
>> language here could prove counter-productive.
>>
>>> Attestation

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 31 Jan 2022 18:13:44 +0000

> 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.

cheers,
-- 
Thomas

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 31 Jan 2022 18:37:48 +0000

> From: Thomas Fossati, January 31, 2022 1:14 PM
>
> > > 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.
> >
> 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
>

The combination of all are possible too.  E.g.,
4. The Verifier says that Attester says that security-level=="N" and Verifier 
says that security-level=="N-1"

> 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.

Hopefully the set of alternatives with semantics can be 
encapsulated/named/transported unambiguously.  YANG for all its complexity 
does a good job of this.

Eric

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 31 Jan 2022 19:54:12 +0000

(not as chair)
I agree that encapsulation is a reasonable way to solve this. The Endorser claims already is (Endorser says security-level=X) and the Attester Evidence already says Attester says security-level=Y). Verifier can add an encapsulation layer to say:
 (Verifier says 
	(Endorser says security-level=X),
	(Attester says security-level=Y),
	security-level=Z)

X, Y and Z could all be the same or different values. 
If Verifier says all three then it assumes RP knows how to disposition them, e.g., Level Z is the effective security level and X and Y go into a forensic log etc...

The expressiveness of YANG seems adequate, but if not using YANG does AR4SI I-D define an encapsulation that has enveloping semantics for:
	entity (i.e., organization or device or key) says X?

-Ned

    Eric

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 31 Jan 2022 12:15:32 -0800

The first EAT drafts were authored before the RATS Architecture defined Evidence and Results. There was at first no explicit text, but that doesn’t automatically make it only for Attestation Evidence.

Over a year ago, draft -05 is the first to mention Evidence and Results. All it had with this “TODO”, which does indicate intent for both:

Draft -10 fulfilled that TODO by adding the text we’re discussing now.

I don’t think the document grew in scope (I was always working on it as both). It just wasn’t explicit until draft-10. Just because it took time to make it explicit doesn’t make it right to assume it was only for Evidence.

Can we explicitly agree that EAT is for both Attestation Results and Evidence?

LL

> On Jan 31, 2022, at 9:09 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
> 
> it seems to me that Eric's comment is actually reflected by one of Giri's earlier comments, which stated that "Security Level was designated for early assignment in draft -09". -09 of EAT included no tangible content about Attestation Results. At that point in time, the document was essentially about Attester produced Evidence and included two notes that highlighted:
> 
> Maybe that is the reason for concern today. That the document grew in scope in a way that now makes some individuals uncomfortable with the application of certain claim. In this case, namely security-level in Attestation Results, I think.
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 31 Jan 2022 12:32:42 -0800

> On Jan 31, 2022, at 1:31 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Jeremy,
> 
> This is why I indicated that we are starting to conflate Evidence and Attestation Results here. The current security-level Claim in Evidence is probably fine, as it is clearly a self-assertion. The same security-level in Attestation Results is semantically not the same. In Attestation Results now you do not know, if this to be interpreted as a self-assertion that was placed in Evidence or the output of policy and appraisal of Evidence.

Like many things in Attestation Results, you need to know the policy, procedure and reputation of the Verifier to know its true value.

Even with measurements (hashes of code and memory against references values), you have to know how secure the measurer is, whether it covered everything it needed to, the lack of bugs in the Verifier, the defenses of the Verifier against network born attacks...

We are talking about the characterization of security here. There is no such thing as a “security meter” or such that can establish absolute trust in values.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 31 Jan 2022 20:38:21 +0000

> From: Smith, Ned, January 31, 2022 2:54 PM
> 
> (not as chair)
> I agree that encapsulation is a reasonable way to solve this. The Endorser claims
> already is (Endorser says security-level=X) and the Attester Evidence already says
> Attester says security-level=Y). Verifier can add an encapsulation layer to say:
>  (Verifier says
> If Verifier says all three then it assumes RP knows how to disposition them, e.g.,
> Level Z is the effective security level and X and Y go into a forensic log etc...

Exactly.   And this means the Appraisal Policy for Attestation Results will need to understand this mapping.   The decision we are making right now on how verbose the objects visible to this policy is critical to whether RATS succeeds or not.  

The Relying Party is the ultimate customer.  And the Relying Party logic should be as simple as possible.  Why would a Relying Party coder ever want the Endorser and the Attester's security-level if it has been given the Verifier's security-level?  Even if it is only delivered one of these, the namespace delivered needs to be able to differentiate between all three security-levels described above.

> The expressiveness of YANG seems adequate, but if not using YANG does AR4SI
> I-D define an encapsulation that has enveloping semantics for:

AR4SI Section 3.2, Steps 5 & 6 defines the Appraisal Policy for Attestation Results when the use case is connectivity.  But it does not the encapsulation for delivering the objects in a namespace.

Eric

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jan 2022 16:45:37 -0500

Maybe a few someones could articulate *their* use case for "security-level" before we
go any further.

---

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

eric> Why would a Relying Party coder ever want the Endorser and the Attester's security-level if it has been given the Verifier's security-level?  

I don't know. I presume, if it is important for RP to know, there would be an Appraisal policy for AR that establishes the context with the Verifier. The default assumption would be: (Verifier says security-level=Z) etc. I am aware of cases where attester and endorser claims are passed through to RP but these are still a case of (Verifier says X). 
-nms

    Eric

---

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

The use cases I'm aware of are closer to "Attester satisfies security policy X" rather than "Attester satisfies security level X".
-Ned

On 1/31/22, 1:46 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jan 2022 20:49:32 -0500

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: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 1 Feb 2022 01:56:55 +0000

> From: Smith, Ned, January 31, 2022 7:56 PM
>
> eric> Why would a Relying Party coder ever want the Endorser and the 
> Attester's
> security-level if it has been given the Verifier's security-level?
>
> I don't know. I presume, if it is important for RP to know, there would be 
> an
> Appraisal policy for AR that establishes the context with the Verifier. The 
> default
> assumption would be: (Verifier says security-level=Z) etc. I am aware of 
> cases
> where attester and endorser claims are passed through to RP but these are 
> still a
> case of (Verifier says X).

I don't know either.

The point I was making is that we should *try* to reduce the number and 
interplay of objects exposed to the Relying Party.  A small well thought-out 
set of API/objects available to a policy language is better than a rich API 
with many similar elements exposed simply due to a fear-of-missing-out.

Eric

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 1 Feb 2022 05:29:53 +0000

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.

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.

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.  

-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

Maybe a few someones could articulate *their* use case for "security-level" before we go any further.