Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

["Smith, Ned" <[e-mail]>]

>> The TCG standardized a security level structure (e.g., CommonCriteriaMeasures) as an Endorsement in https://trustedcomputinggroup.org/wp-content/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdf.
>
>Thanks for the reference.  I could not find anything in https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-8.2 that prohibited
>an endorsement from being conveyed with the attestation (e.g. from the attester).
>
The RATS Architecture labels claims from Endorsers as Endorsements and claims from an Attester as Evidence. The claims could be the same claim text and formatting
but they are different information because one is asserted as Endorsement while the other is asserted as Evidence. The Verifier should treat these differently in terms
of how it arrives at a conclusion to accept it or not.
>Note also that the endorsement in the TCG spec cited above appears to be a self-declaration by the manufacturer (e.g. can it pass CC).
>This is different from a DLOA, where a trusted 3rd-party has signed the digital letter.
The TCG spec defines a certificate extension format. Anyone can issue (sign) the certificate. Whether a Verifier accepts what the manufacturer or a common criteria evaluation lab issued is based on a policy (maybe a trust anchor list and a list of claims that each Endorser is expected to assert).
>
>So does this mean that security level as an EAT would be OK if conveyed as a X.509 and signed by a manufacturer key that is distinct
>from the attestation key?
I don’t think Verifier/Relying Party cares about the format of the claim as much as the semantics of what is asserted. The key identifies who is making the assertion.
The Attester (as a device) can’t perform a common criteria evaluation (AFAIK), it takes a human at least to do some of the evaluation. The evaluation result can be encoded in electronic form as a claim. The evaluation lab that did the analysis could use their key to sign the electronic claim thereby making it into an Endorsement.
The evaluation lab could however assert the claim is a Reference Value if it expected there should be a matching Evidence claim. Its largely up to the manufacturer and/or Relying Party to determine which form makes the most sense. My intuition for common criteria is the evaluation lab doesn’t expect the device under evaluation needs to assert its CC evaluation result. It just needs to assert an identity (such as I’m a model-X widget) and the evaluation lab asserts that a model-X widget has a CC evaluation result of blah.
>Note that  the EAT attestation key itself can be signed by the manufacturer already
The claim the manufacturer is making by signing the Attester key is that a particular instance of a model-X widget has an authenticatable identity. Evidence signed by the key is authenticated to that identity. It doesn’t necessarily imply that no matter what the Evidence might be, that the claims are ground truth. The Verifier still has to evaluate if it is reasonable for the Attester to collect a truthful claim. In the case of common criteria, that seems unrealistic because normally CC results are arrived at by a human – in particular a human from the CC evaluation lab.
>(see https://datatracker.ietf.org/doc/html/draft-ietf-cose-x509-08).  Moreover, EAT (at least in its CBOR form) is designed to be an
>efficient data structure, so it would be desirable to not have to pile on 509 certs in order to get the verifier the information that it needs.
I wasn’t implying this.


From: RATS <[e-mail]> on behalf of Giridhar Mandyam <[e-mail]>
Date: Friday, June 3, 2022 at 1:57 PM
To: "[e-mail]" <[e-mail]>
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

> The RIV draft (AFAIK) is not making a statement about whether Evidence signed by a TPM is self-asserted, nor does it try to define a security-level claim. The TPM is described as being a root-of-trust for reporting (i.e., it signs claims).

I disagree.  See Sec.1.4 of the RIV document:


“A key goal is to identify the software release(s) installed on the Attester, and to provide evidence that the software stored within hasn't been altered without authorization.”



If the TPM attestation carries such information in its evidence, I would state that it maps to sec level 3 (https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-4.2.8).  The above clearly identifies this information as evidence – not an endorsement.



> The TCG standardized a security level structure (e.g., CommonCriteriaMeasures) as an Endorsement in https://trustedcomputinggroup.org/wp-content/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdf.



Thanks for the reference.  I could not find anything in https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-8.2 that prohibited an endorsement from being conveyed with the attestation (e.g. from the attester).



Note also that the endorsement in the TCG spec cited above appears to be a self-declaration by the manufacturer (e.g. can it pass CC).  This is different from a DLOA, where a trusted 3rd-party has signed the digital letter.



So does this mean that security level as an EAT would be OK if conveyed as a X.509 and signed by a manufacturer key that is distinct from the attestation key?  Note that  the EAT attestation key itself can be signed by the manufacturer already (see https://datatracker.ietf.org/doc/html/draft-ietf-cose-x509-08).  Moreover, EAT (at least in its CBOR form) is designed to be an efficient data structure, so it would be desirable to not have to pile on 509 certs in order to get the verifier the information that it needs.


> Hence, it is an incorrect conclusion that a double standard is being applied to the RIV draft vs. the EAT draft.



You are welcome to your opinion, but I think the text I cited above from the RIV doc supports my argument.  By the way, as far as I can tell I never used the term “double standard”.  I was simply trying to leverage a draft that passed WGLC to frame this discussion.



-Giri

From: Smith, Ned <[e-mail]>
Sent: Friday, June 3, 2022 12:30 PM
To: Giridhar Mandyam <[e-mail]>; Jeremy O'Donoghue <[e-mail]>; Laurence Lundblade <[e-mail]>; Henk Birkholz <[e-mail]>
Cc: Eric Voit (evoit) <[e-mail]>; Eric Voit (evoit) <evoit=[e-mail]>; Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

It was observed in [1] that a security-level claim is reasonably suitable as an Endorsement. The thread in [1] explored the possibility that security-level wasn’t reasonable as Evidence which would equate to self-assertion. What seemed to be suggested as the way to address the issue was an argument that self-asserted security-level was reasonable. While that may be true (or not), it didn’t address the main point that often an independent entity (other than the Attester) has the authority to assert a security level. The example used in the FDO specification suggests as an example that common criteria could be used as a security level. But CC relies on an independent certifying entity.

[1] Adrian:
"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."
https://mailarchive.ietf.org/arch/msg/rats/KRVoK0ITFnKhhKUz2sgkg7qhl1c/

The RIV draft (AFAIK) is not making a statement about whether Evidence signed by a TPM is self-asserted, nor does it try to define a security-level claim. The TPM is described as being a root-of-trust for reporting (i.e., it signs claims). A TPM depends on a root-of-trust for measurement (RTM) which is the principal entity responsible for collecting / asserting claims. AFAIK the TCG has not tried to standardize a security-level claim structure that is measured into a PCR. The TCG standardized a security level structure (e.g., CommonCriteriaMeasures) as an Endorsement in https://trustedcomputinggroup.org/wp-content/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdf.  While it may be possible for a RTM to assert the CommonCriteriaMeasures claim as Evidence, that isn’t a reasonable interpretation of the TCG spec.

Hence, it is an incorrect conclusion that a double standard is being applied to the RIV draft vs. the EAT draft.

The line of reasoning in the last paragraph below [2] is suggesting that if a security-level claim is asserted in Evidence that Verifiers will have policy that accepts / rejects it. AND if an application doesn’t see a use for security-level claims then they can just ignore using it. (To which I agree.)

However, it is possible that if there isn’t strong justification for a claim (i.e., backed by use cases etc…) that the WG wants to error on the side of exclusion.

-Ned
From: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>
Date: Friday, June 3, 2022 at 11:37 AM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>, Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>, Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, Henk Berkholz <[e-mail]<mailto:[e-mail]>>
Cc: "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>>, "Eric Voit (evoit)" <evoit=[e-mail]<mailto:evoit=[e-mail]>>, Nancy Cam-Winget <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

My impression with the concerns being raised on security level is that there is not a clear delineation between whether it is attestation evidence and attestation results.  I was hoping to get guidance from the RIV doc, which the group has approved for advancement beyond LC, for guidance.  In this doc, all PCR entries are represented as attestation evidence.  As I have shown below, several of the PCR values as defined could be interpreted to be self-assessments or results.  I do think this is relevant -  other drafts that have successfully advanced beyond WGLC can be used for guidance in the context of EAT.
[2]
I have also highlighted that the group seems to have been comfortable with guidance such as “Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies)” in WG drafts that have been forwarded that have made it past LC.  Why can’t such guidelines apply to sec level?  If a verifier based on its local policy has determined sec level is not consequential they are free to ignore it.

-Giri

From: Smith, Ned <[e-mail]<mailto:[e-mail]>>
Sent: Friday, June 3, 2022 11:29 AM
To: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>; Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>; Laurence Lundblade <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>
Cc: Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>; Eric Voit (evoit) <evoit=[e-mail]<mailto:evoit=[e-mail]>>; Nancy Cam-Winget (ncamwing) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
I’m not sure how observations about a different draft / legacy technology addresses the issues raised related to the EAT draft security-level claim.
There might be issues with another draft, but those issues should be raised in the context of the draft to which they pertain.
-Ned

From: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 2, 2022 at 1:45 PM
To: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>, Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, Henk Berkholz <[e-mail]<mailto:[e-mail]>>
Cc: "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>>, "Smith, Ned" <[e-mail]<mailto:[e-mail]>>, "Eric Voit (evoit)" <evoit=[e-mail]<mailto:evoit=[e-mail]>>, Nancy Cam-Winget <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

I also make an observation that some of the persons who are claiming confusion about whether security level is attestation evidence, attestation results or some form of self-declaration seem to be quite comfortable with comparable (maybe greater) ambiguity with TPM’s.

For instance in https://www.ietf.org/archive/id/draft-ietf-rats-tpm-based-network-device-attest-14.html#name-notes-on-pcr-allocations:


  1.  “PCR[0] typically represents a consistent view of rarely-changed Host Platform boot components, allowing Attestation policies to be defined using the less changeable components of the transitive trust chain. “

How is a “rarely-changed” boot component identified?  Is this the “result” of a rules engine within the attester?



  1.  “PCR[4] is intended to represent the software that manages the transition between the platform's Pre-Operating System start and the state of a system with the Operating System present. ”



What if there are multiple OS’s in the system?  Which entity determines what constitutes the specific operating system that corresponds to this PCR?  Isn’t this an attestation result as opposed to just evidence, as this value cannot be in the quote without a preliminary determination (result) identifying which SW is responsible for the transition to the target OS?



  1.  The text goes on to state “Although the TCG PC Client document specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, *it should be noted that embedded software vendors may have considerably more flexibility*. Verifiers typically need to know which log entries are consequential and which are not (*possibly controlled by local policies*)”



So why is it OK for a RIV-compliant implementation (embedded software vendor) to assign arbitrary values to a PCR (which could conceivably span both evidence and results) with the expectation that a relying party/verifier to be able to apply the appropriate policy to interpret it, but it is unacceptable to expect a verifier to interpret sec level in the context of its own appraisal policy?

-Giri

From: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 12:29 PM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>
Cc: Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>; Eric Voit (evoit) <evoit=[e-mail]<mailto:evoit=[e-mail]>>; Nancy Cam-Winget (ncamwing) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

I’m pretty happy with the latest text. It’s a considerable improvement on what we had previously.

On 02/06/2022, 11:54, "RATS" <[e-mail]<mailto:[e-mail]>> wrote:


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

On Jun 2, 2022, at 10:50 AM, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ned,

this also reflects my perception of group consensus.

Maybe be little careful about concluding what consensus is here?

There are an equal number of people expressing support of security level as there are questioning it.

Isn’t consensus based on number of people, not on how long the list of questions is or how strong the view is?

LL