Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-wimse-workload-to-workload-protocol-00
Notes: Justin and Pieter welcome the group and introduce the agenda.
Various links to repo, WIMSE website, and drafts in the slides.
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-wimse-wimse-architecture-00.pdf
Notes: Joe goes through the slides.
Dean: On the impersonation, there was a discussion at the OAuth security
workshop, and it will be worked on in the OIDC EKYC group.
Yaron: WIMSE Token is a really bad name. I suggest "WIMSE artifact".
We discussed larger WIMSE deployment and distributed issuance of
identities. When we talk about scalability then there is a responsibilty
on us to define how it works.
Joe: I agree that this is something we want to discuss. With regards to
the name, I am OK to use some other name.
Justin: You do not have WIMSE Tokens in the draft.
Pieter: I believe you changed it to WIMSE credentials.
Justin: Naming is hard. I recommend that the group takes some time to
agree on good terminology.
Usama: Could you elaborate on CC?
Joe: We have to look into what we could be consistent with. We want to
align with terminology from other communities.
Draft https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/03/
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-wimse-workload-to-workload-protocol-00
Notes: Yaron goes through the slides. Trust bundles (=trust anchor)
management might need to be discussed as well (open issue). There is
also an issue on how the private keys are provisioned to the workload.
With SPIFFE these private keys are provisioned via the agent to the
workload.
Another open issue is about the audience claim. (issue#26): how can the
callee verify the audience claim?
Rifaat: What is a trust bundle?
Yaron: It is a trust anchor.
Pieter: Mapping the terminology used in different groups is something we
need to do.
Draft
https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/
Notes: Yaroslav went through the slides and the recent changes
(credential issuance).
Mark Novak: We are still figuring out how to provisioning credentials to
the workloads. CC is different from how the provisioning is working
today. Suggestion: Leave it open for how solutions define the
provisioning.
Justin clarifies that the document does not go and specify all the
solutions that are not mentioned.
Pieter: The document captures the current state.
Joe: We can put text in the architecture spec about confidential
computing.
Justin: The purpose of the document was very specific to get the initial
set of credentials delivered to the workload. It is also not intended to
be exhaustive.
Justin asked the group for how many people read it. Maybe 6 or so.
New reviewers? Yaron, Joe, Dean, Mike put their hands up.
Yaroslav: We are not yet asking for WGLC.
Draft
https://datatracker.ietf.org/doc/draft-schwenkschuster-wimse-credential-exchange/
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-wimse-credential-exchange-00.pdf
Notes: Arndt went through his slide deck.
Usama: regarding the exchanges on slide 4, how will the previous
credential be revoked?
Arndt: At the moment there is no revocation discussed in the draft. The
format also needs to be considered.
Yaron: I am not sure about the difference between initial & on-demand
provisioning. We should also consider long-lived workloads where you can
renew credentials over the lifetime (which is related to revocation).
Arndt: In Kubernetes the credentials are provisioned by default - even
if you do not use them. This is where I would say that you should be
doing on-demand provisioning.
Pieter: The practice is that the credentials are short-lived since the
workloads are often short-lived. This addresses the revocation problem
as well.
Mark: How does remote attestation fit into the exchanges in slides#4?
Arndt: This is a super-new document and we can decide about extending
the document scope.
Arndt: Should we work on this document?
Mark: What do you mean by increased trust?
Arndt: You have a bearer token and exchange it for an PoP token.
Mark: Is there another example?
Arndt: not right now.
Joe: I have not read the draft and the discussions are useful. Some of
it should be wrapped in the architecture draft.
Pieter: Is there a pattern that should be standardized?
Arndt: I have not come across a lot of work out there.
Hannes: There is a lot of work from the PKIX world. If you think about
it in an abstract way, the OAuth DPoP work is a CSR.
Brian: What?
Hannes: I can explain later.
No Draft
Slides:
https://datatracker.ietf.org/doc/slides-122-wimse-identity-crisis/
Notes: Usama goes through his slide deck.
Arndt mentions the security assumptions of WIMSE where the platform is
trusted.
Justin: I encourage to send a draft to the mailing list.
No Draft
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-wimse-trustworthy-workload-identity-twi-00
Notes:
Hannes went through his slide deck. Goal: Discuss, what's the
interconnection point with WIMSE.
Usama: On slide 2, think the first point is misleading. Not aware of any
part of confidential computing that doesn't require trusting the
hardware.
Hannes: May be misleading. Intent was to describe CC as another layer of
isolation.
Usama: Agree from OS point of view. But, whole point of CC is about
chaining from CA to Hardware. Hardware is the trust anchor, how can you
remove it.
Michael: "Sentence says 'against the hardware owner and administrators'"
Hannes: "Maybe the wording could be improved. Intended to refer to more
isolation."
Monty: "Is this entirely focused on a technology that can isolate a
workload from the Hypervisor? Would this extend to deciding that a HV is
trustworthy? More open or closed?"
Hannes: Specifically talking about technologies like Intel and ARM.
Those have more than a hypervisor.
Monty: "So, it's more narrowly scoped"
Hanes: "Depends what you mean by narrow. Those are broad."
Usama: "This would exclude tech that doesn't provide"
Hannes: "interesting. we should discuss."
Usama: "We don't need to limit the scope to just VM based or Process
based. To follow up from what Monty was saying."
Hannes: "My sense of where industry is moving, to VM based systems. Not
focusing on other technologies".
Justin as Chair: "Already at time and on slide 3 of 10"
Hannes: "Invitation to everyone to participate in the conversation".
Justin as Chair: "Note that CC is not under IETF."
Mark Novak: "You can download the deck. Most important parts are the
definitions we're coming up with. Stress that we are after compatibility
with your work."
No Draft
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-wimse-wimse-impact-on-data-residency-requirements-for-handling-sensitive-data-01
Notes: Ramki goes through his presentation where he suggests to bind
three identities together (workload, domain and platform identity)
Usama: Which field in the Intel SGX are you referring to as identity?
What is the field in the code?
Ramki: I need to dig it up and come back to you.
Justin recommends to write a draft and to get feedback.
Notes: Mark asks to show the slides on the definitions.
Usama asks about the initial vs. the run-time measurements. I object the
idea that the workload identity is a stable construct.
Mark: Workload identity needs to be defined in terms of the relying
party to use it for authorization policies. The relying party gets both
measurements.
Pieter: We need to take this offline.
Yaron: CCC has its own ideas on what counts in terms of root of trust,
what the threat model is, etc.
We need to develop our own ideas.
Usama: I will write a mail with links to ongoing work.