Notetakers: Jeff Lombardo, Henk Birkholz
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-welcome-and-chair-updates-02
Full packed schedule.
Weekly Github digest
There are a lot documents rework at the moment that will presented in
this session.
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-welcome-and-chair-updates-02
This is mostly content restructuring - all the details of the convo are
on the list
2 major aspects:
Goal: To be able to progress them separately
Expected outcome: To be able to move more quickly to WGLC
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-workload-credentials-00
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/
S2S document has been split in 4
This is about the Workload credentials
Chagelog since IETF-123:
Queue:
Still some work todo, depends on when split happens
Justin / Chair: Document can move separately. Still this document
needs to go first.
Arndt: There are downref references now
Justin: Let's figure out if informative ref makes sense then
Yaron: it is not clear how we will go to the RFC Editor. It is a
good signal for the industry (document split)
Thibault: The split makes it easier to read. Question about section
5 - We might need to remove it. There are 2 formats (Token and
Certificate), Certificate is already used in Production but the
Token seems more experimental.
Arndt: The certificate format is aligned with SPIFFE.
Justin: This document is about standardizing for the WG on how to
talk about things, not necessarilly things in Production
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-workload-proof-token-00
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/
Signed with the private key of the Workload and sent along the WIT.
Generated for each request to match the audience.
Proove the possession of the key by the client (aka the workload).
Thereby, a Workload Identity Token is not a Bearer Token anymore.
The WPT can protect headers through the oth claim
One topic:
Profiling guidance
Arndt: Upcoming Decision: context specific Claims: a) one claim
for a map on the root level OR all claims on the root level?
Rohan: What are you trying to say as a Discussion.
Arndt: We want to define the scope as as the document scope
George: 2 questions - oth claim and protection of other header
from the requests. Should we have profiles to expand or do we aim to
embbed this in this specification?
Arndt: In other protocol, the information we want to protect might
not be in the header but the payload. So we may had to tackle that.
For compliance profiles, it will be up to the community.
Yaron: not confident about the synchronization in between the
proposal and the W2W document.
Arndt: In closed environments you are allowed to use dditional
claims as long as the keys do not collide.
Yaron: You cannot necessarilly induce this is a closed environment
Arndt: I agree
Slides:
https://datatracker.ietf.org/doc/slides-124-wimse-wimse-authentication-with-http-signatures/
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/
How to integrate HTTP Sig with the WIT
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/
Mostly mTLS but Client authentication is validation of the SPIFFE
identifier
Question 1: Should we move the Workload Certificate in this spec or not?
Joe: Think the Workload Identity Certificate in the Credentials
Draft but keep the TLS related elements in this Draft.
Brian: Agree with Joe. Uncomfortable about how the 4 Draft deal with
the way the WIMSE Identifier is dealt with when accessing TLS
resource.
Arndt: Think the having the WIT and IDentity Certificate in the same
document allow to compare them better
Usama: Comparing WIT + mTLS to mTLS, what are the advantages?
Question 2: DNS hostname is the only SNI option in certificate. Would it
not be great to have WIMSE identifier as a recognized scheme as a TLS
name extension?
Arndt: It addresses a real problem. I agree this is a problem space
we need to address.
Brian: No
Atul: Will there be problem with EKU from webpki?
Yaron: In the older S2S Draft we had an Implementation section. We
still need and we should bring that back in the Wiki
Justin: Encourage the authors to create a Wiki page
Justin: those Drafts are expected to go fast, also in reviewing so
please audience pay attention
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-wimse-architecture-00
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/
Two new versions (-06 now) and one interim
Topics to extend that will need more fleshing out: Security,
Authorization (we want to say more), Key Management (sort of
references), some type of "attestation"
Usama: There is no connections to attestation here, what are the
plans?
Henk: With TCG Attestation WG Co-Chair hat on: I don't know what you
want to talk about. There is a draft-novak-rats-twi-attestation in
RATS, maybe that is the part that you want to insert/reference here?
Arndt: I am a SPIFFE lead maintainer and they did a good job at
writting the section. They made some mentions to RATS. Authors
should look at it.
Mark: Because WIMSE went into Agent and Server deal with
attestation, there are some overlap. Happy to raise an issue.
Lucia: Regarding the Authorization, this is something we already did
but it was out of scope initally, if you want to work on that I can
do it.
Joe: For more details we might need to do a separate workstream of
document. Effectively this is not something in charter right now.
Justin: This is effectively explicitely out. In an Architecture
document, this is ok. Diving and solving the Authorization decision
is out of scope and related to future work. This is a reasonnable
topic for the second round of Draft. Still this is a good forum to
have the discussion.
Flemming: There is a need in Architure to talk about to talk about
workload instances.
Joe: Rephrasing: You can have multiple isntances of a workload and
you might want to do something with that. They are still Workloads.
Flemming: You still need that they might be different. You need to
convey the difference in the credential.
Jeff: WRT the identifier draft: how deep should we go? Especially if
we are forcing some signalling method (e.g., this one instance is
prohibited from interacting with my ecosystem).
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-workload-identifier-00
Draft: https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/
Recently adopted - Thanks
Text did not change since adoption
Worklaod Identifier scope will contained the Authority Trust Domain and
Path
SPIFFE does not want you to shoot yourself in the foot when dealing with
URI
Flemming: is that rules for everything or are we considering more
rules for SPIFFE?
Yaroslav: We will support SPIFFE specificities through "profilling"
currently
Flemming: SPIFFE Support IPV6
Yaroslav: That is because they are supporting : - We won't support
IPv6 for Scheme
Arndt: is there any use case to support IPv6?
Yaroslav: There might be specific scheme in the wild that we don't
want to restrict through WIMSE.
Henk: Every SPIFFE ID is a WIMSE ID but not contrary? Why would ":"
not be okay in the superset that is the WIMSE ID scheme?
Joe: the host portion of the URI is common to all the scheme...
maybe it is the way you look up to the key material or other use
case.
Peter: What does "no user information" refering about?
Yaroslav: We don't want the username and password part of the URI
support
Pamela: From reading the spec and the subset / superset, is there a
way to distinguish the two (SPIFFE / WIMSE) ?
Yaroslav: URI are very broad, we are constraining those to fit the
need here and limit the flexibility.
Each scheme needs to define what is specific to their support path
format.
Pieter: Who are the user of the WIMSE Scheme needs to be taken in
consideration
Yaron: Define a default scheme for people wanting an identifier but
not having a specific Scheme
Flemming: What can of semantics are going to use
Draft:
https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/
Added a new pattern, the service mesh
Multi-tenant problems:
issuer can be shared
Justin: We got only one review... this is not enough. Call for
reviewers. Recorded volunteers:
Draft:
https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/
Usama: can you explain what the Evidence in Step 1 is?
Yuan: this is the remote attestation
Usama: I would have expected the Agent to be the attester not the
proxy. Can you precise that? What is the boundary of the attester.
Justin: We have 4 minutes left, bring your questions to the list.
Justin: Have you guys submitted an ID yet? Please read the draft
Peter: This is just a starting point. This is keeping our CISO up at
night.
Jonathan: Just looking at the flow including the user. This is not
an Authentication but an Authorization.
Yuan: what is the entity is allowing to do. This exposes different
problems.
Jonmathan: This is the poroblem of semantics.
Yuan: We don't want the agent to be the user.
Yaroslav: There are lots of talks at this IETF. Before we decide
this is in or not, we need to discuss with the other WGs.
Jeff: If you remove AI, This is a Workload and this is the exact
same diagram as in the Architecture Draft. The Credential of the
Agent is then an OAuth Client credential that could allow you to
start an OAuth Authorization code grant flow.
Flemming: Not sure this is the WIMSE WG for this.
Slides:
https://datatracker.ietf.org/meeting/124/materials/slides-124-wimse-delegated-authorization-00
Draft:
https://datatracker.ietf.org/doc/draft-li-oauth-delegated-authorization/
Jeff: There seems to be a lot of Security problems on what is the DK
and how DAT are signed. Also not going through the AS does not allow
to manage session properly
Geroge: Token endpoint allows down-scoping with RT. This solution
does not seem to solve so much problems but create its own set of
Security problems.
This is out of scope of the Architecture but there is a reference in S2S
There is a de facto standard for WebPKI
Justin: And not Defakto, this is not a proprietary standard (typo in
the slides)
Yaroslav: You might want to come closer to WebBotAuth
There are 7 Drafts in, we need to review and ship them
Flemming: We need more interop meeting
Pieter: thanks to the Authors