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

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

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]>
Date: Friday, June 3, 2022 at 11:37 AM
To: "Smith, Ned" <[e-mail]>, Jeremy O'Donoghue <[e-mail]>, Laurence Lundblade <[e-mail]>, Henk Berkholz <[e-mail]>
Cc: "Eric Voit (evoit)" <[e-mail]>, "Eric Voit (evoit)" <evoit=[e-mail]>, Nancy Cam-Winget <[e-mail]>, "[e-mail]" <[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]>
Sent: Friday, June 3, 2022 11:29 AM
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)


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