Produce a position paper on machine identity's role in overall Confidential Computing attestation

[TheBankster]

A recent post by me on LinkedIn has generated an outlier amount of engagement and a spirited discussion. https://www.linkedin.com/posts/markfishelnovak_machine-identity-in-cybersecurity-and-iam-activity-7111375919142879232-2Li2

The SIG should research and publish a document (in the form of a position paper) around the role of machine identity in overall attestation. There are two camps: one (in which I find myself) claims that machines are pets, not cattle, and the actual security principal worth tracking is code identity, as established by TEE attestation. In that view, machine identity has a very limited role (such as a claim resulting from mapping of an endorsement certificate into machine location for jurisdictions that restrict where data processing can be done). The opposing camp feels that even those parts of the hosting machine outside of the "confidential TCB" are worth attesting for an improved security posture.

The answer will not be universal across scenarios. For instance, privacy considerations may discourage the use of machine identity, while cloud scenarios might call for it.

[muhammad-usama-sardar]

The SIG should research and publish a document (in the form of a position paper) around the role of machine identity in overall attestation.

IMHO such camps generally arise only due to vague terms, such as machine identity. So I personally see defining the term "machine identity" as a good first step.

Another perspective is that neither the document nor the presentation talk about confidential computing (CC). So it is reasonable to assume that CC was out of scope of the document and presentation.

In the CC context, I can imagine various things that may come under the umbrella of the term "machine identity", for example, for Intel TDX:

• Platform Provisioning ID (PPID)
• Platform Instance ID (PIID)
• Family-Model-Stepping-PlatformCustomSKU (FMSPC)

Similarly, for Arm CCA:

• CCA platform Implementation ID
• CCA platform Instance ID

So the first logical step, in any case, is to define what exactly among others is what you refer to as "machine identity".

[TheBankster]

These are great points.

I would say that, for purposes of datacenter design, Requestor Identity has to be seen mostly (*) from the POV of the relying party, and from that perspective, it has two components: 1) code identity (security sensitive) and 2) hosting device properties such as location, or whether the device is fully patched (what I would call “compliance sensitive”).

(*) such requestor identity can still serve a security purpose of defense in depth — a known device is guaranteed to be physically secure, if it’s fully patched outside the bare minimum of its confidential TCB, then it’s less likely to let malware through, etc.

Again from the POV of relying party such requestor identity claims most often need to be compressed down to their bare essence claims that a relying party can expect for its secure and compliant operation, such is “the requestor has the code identity I expect” (security principal id) and “satisfies the compliance requirement for this code” (“cleared to process personal data of German citizens”).

The attestation service policy would determine what requestor claims map to which claims destined for the relying party.

These are the types of considerations I would like to see reflected in the paper I believe we should research and author.

On Wed, Sep 27, 2023 at 1:35 AM Muhammad Usama Sardar < @.***> wrote:

The SIG should research and publish a document (in the form of a position paper) around the role of machine identity in overall attestation.

IMHO such camps generally arise only due to vague terms, such as machine identity. So I personally see defining the term "machine identity" as a good first step.

Another perspective is that neither the document https://s3.amazonaws.com/content-production.cloudsecurityalliance/bzkky9f21l48c3vhnj8eg7on6av3?response-content-disposition=inline%3B%20filename%3D%22Machine%20Identity%20in%20Cybersecurity%20and%20IAM.pdf%22%3B%20filename%2A%3DUTF-8%27%27Machine%2520Identity%2520in%2520Cybersecurity%2520and%2520IAM.pdf&response-content-type=application%2Fpdf&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAS6XDIRHKHO4F5SU4%2F20230927%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230927T080334Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=1d29e30f551c42bcc394883562a2a3ac7b82e4505679a9b229f125af87149bc6 nor the presentation https://s3.amazonaws.com/content-production.cloudsecurityalliance/96ec89bxd9km2r14w5k0pwt7pwtn?response-content-disposition=inline%3B%20filename%3D%22Machine%20Identity%20in%20Cybersecurity%20and%20IAM%20Slide%20Deck.pdf%22%3B%20filename%2A%3DUTF-8%27%27Machine%2520Identity%2520in%2520Cybersecurity%2520and%2520IAM%2520Slide%2520Deck.pdf&response-content-type=application%2Fpdf&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAS6XDIRHKHO4F5SU4%2F20230927%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230927T080340Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=a921260da5da0f72b68cf569db9a7868fb4323a61cc658dd065c33956880a3fd talk about confidential computing (CC). So it is reasonable to assume that CC was out of scope of the document and presentation.

In the CC context, I can imagine various things that may come under the umbrella of the term "machine identity", for example, for Intel TDX:

• Platform Provisioning ID (PPID)
• Platform Instance ID (PIID)
• Family-Model-Stepping-PlatformCustomSKU (FMSPC)

Similarly, for Arm CCA:

• CCA platform Implementation ID
• CCA platform Instance ID

So the first logical step, in any case, is to define what exactly among others is what you refer to as "machine identity".

— Reply to this email directly, view it on GitHub https://github.com/CCC-Attestation/meetings/issues/21#issuecomment-1736951710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKPG2YCKSZYFMUW6AEGHOXDX4PQNZANCNFSM6AAAAAA5IAAKKE . You are receiving this because you authored the thread.Message ID: @.***>

[thomas-fossati]

@TheBankster, FYI. Likely relevant to this -- as well as to the GRC SIG work -- is the "Scalable Remote Attestation for Systems, Containers, and Applications" document that Kathleen Moriarty (@KME) is pursuing in the RATS working group.

[TheBankster]

Thanks for sharing Thomas! Will definitely take a look.

[thomas-fossati]

Another perspective is that neither the document nor the presentation talk about confidential computing (CC). So it is reasonable to assume that CC was out of scope of the document and presentation. [...]

@muhammad-usama-sardar the two links do not work (for me). Is there another way to access that content?

[muhammad-usama-sardar]

@muhammad-usama-sardar the two links do not work (for me). Is there another way to access that content?

also does not work for me now. Anyway, I updated the links in my original comment. Please check. They work for me now.

If the links still do not work, the original link is here. There search for "Prefer to access this resource without an account?" and exactly below that there are two links for publication and presentation.

[thomas-fossati]

@muhammad-usama-sardar the two links do not work (for me). Is there another way to access that content?

also does not work for me now. Anyway, I updated the links in my original comment. Please check. They work for me now.

If the links still do not work, the original link is here. There search for "Prefer to access this resource without an account?" and exactly below that there are two links for publication and presentation.

Awesome, thanks a lot Usama!