Re: [Wimse] Roman Danyliw's Block on charter-ietf-wimse-00-01: (with BLOCK and COMMENT)

["Saxe, Dean" <[e-mail]>]

I won’t be as verbose as Pieter, Joe, and Justin.  I agree with each of their points.

I want to echo the importance of SCIM in this context as a generic identity provisioning protocol.  Workloads often work on behalf of users, therefore I expect collaboration between WIMSE and SCIM to address use cases for both human and non-human identities, including devices and workloads.

-dhs
--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: [e-mail]<mailto:[e-mail]> | M: 206-659-7293<tel:[phone]>

From: Wimse <[e-mail]> on behalf of Pieter Kasselman <pieter.kasselman=[e-mail]>
Date: Friday, February 16, 2024 at 2:28 AM
To: Joseph Salowey <[e-mail]>, Justin Richer <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [EXTERNAL] [Wimse] Roman Danyliw's Block on charter-ietf-wimse-00-01: (with BLOCK and COMMENT)


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Hi Roman, thanks for the review and clarifying questions. I added some responses in addition to those from Justin and Joe below (marked with [Pieter] to set it apart from Justin and Joe’s).

Cheers

Pieter

From: Wimse <[e-mail]> On Behalf Of Joseph Salowey
Sent: Thursday, February 15, 2024 6:58 PM
To: Justin Richer <[e-mail]>
Cc: [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Wimse] Roman Danyliw's Block on charter-ietf-wimse-00-01: (with BLOCK and COMMENT)



On Thu, Feb 15, 2024 at 7:25 AM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
Hi Roman, thanks for the review of the charter. Responses inline below — and to be clear, these represent my own interpretations of discussions, and I would welcome others on the list to chime in.

— Justin

On Feb 14, 2024, at 9:33 PM, Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Roman Danyliw has entered the following ballot position for
charter-ietf-wimse-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wimse/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

** The text in the goals section appears to be extremely open ended.  How will
the WG know it is done?  Is it possible to describe to describe a narrower
initial tranche of work and recharter later?  Is the intent to have a long
standing WG?  More specific are in the comments.

** If “non-HTTP transport protocols that are found in workload deployments,
such as GraphQL, gRPC, and Kafka” is in scope, can the deliverables please be
described.

The expectation is that this would be a long standing working group that’s specifically focused on the technology area in question.

Workloads present a reasonably broad technology area that’s applicable to a very large community (e.g., companies that have service-based architectures and large scales), and therefore the intent is to charter a working group to bring together the expertise to work on problems in this area. From all of our initial conversations, it’s clear that there is a wide need for work in this space for solutions that account for the specific concerns that workloads bring to the table. Since this is a massive space, with a lot of interest and investment right now, we also realized the need to have a solid place to start. For that, we have defined a set of deliverables that the group believes are immediately tractable and useful to the community, and the goals/scope section remains a broader guideline for what any future rechartering or additional deliverables would be.

As such, we wrote the charter with three main points:

- The overall area that the charter focuses on (workloads) with walls of what we don’t focus on
- A list of immediate concrete deliverables
- A set of filters for how to consider new work in the group, either as a new deliverable or a larger recharter discussion

With this setup, I believe that the working group ends when there are no active deliverables and no more inputs to the group that fit through this filter. The chairs will need to ardently apply such a filter to all proposed work to prevent this from becoming a dumping ground for "neat ideas" that have little to do with workloads and their surrounding technologies. The proposers are keenly aware of the tendency for long-running groups to grow well beyond their original agreement, and the bounds here are intended to prevent exactly that behavior. It would need to be enforced, of course, but we felt it was important for the charter to acknowledge both the wide space and the intent for addressing specific problems.

So while the group isn’t being chartered to, for instance, write a specific protocol named WIMSE, I do believe in the intent to limit the scope to tractable items within a specific space, even though we anticipate there being more items to come as the group continues. This is why we have the text calling out both HTTP and alternatives - the initial deliverables will be around HTTP based protocols and systems (where applicable), but we already know walking into this that the world of workloads doesn’t just run on HTTP. Even HTTP-based solutions are going to need to consider carefully what parts of HTTP they rely on. While we don’t expect to necessarily create a single solution that works across all delivery mechanisms, we also don’t want the WG to focus solely on HTTP in the long run.

If there are better ways to communicate this intent, both the limitations of scope and the long vision, I know we’d appreciate guidance in doing so.


[Joe] To add to what Justin has said,  we feel there is a need for a long standing working group to address this area, that being said we have a list of concrete deliverables that we want to address first.   The goals are intended as guidelines for rechartering to add items outside the current scope of deliverables.
With respect to “other protocols” the intent of the working group is for the solutions to be applicable across the range of protocols in use.  We will be successful if the mechanisms and constructions we develop are as ubiquitous as the current usage of JWT tokens across multiple protocols.  This may require specific adaptations to meet the needs of certain protocols like how entities are identified and named or of how information is propagated from one system to another across different protocols at different times.

[Pieter] We believe there is a need for a long standing working group to address issues with workload identity. Workload identity have some unique properties in terms of how they are created, provisioned, operated and change ownership that set it aside from user identities. These unique requirements are not addressed elsewhere and has become an industry wide issue, especially in terms of its impact on security. Workloads often have very broad access within systems and when they become compromised (e.g. by stealing their credentials and using that to impersonate and gain illicit access to resources). As the industry is pushing towards least privilege access, we need standardised ways to achieve this. As systems become more interconnected (often connecting systems that was not originally designed to be connected) it becomes increasingly important to have standardised ways to manage and use these identities in a secure ways. Addressing these issues will require sustained focus from experts in the field and we see WIMSE as the venue where this work can be done. The participants recognised that this is a broad goal based on the feedback from the BoF at IETF 118. To provide focus and create a natural check point for the working group, we defined specific deliverables as part of the charter. The intent was that as we identify additional deliverables, we will re-charter and if we do not identify new deliverables, the working group, on completion of the last deliverable would have concluded its business.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(3) Per the goal of “Identify and Advocate for Gap-filling Work: Engage with
other relevant working groups to pinpoint and address gaps in current
standards. This will involve thorough collaboration, ensuring that emerging
standards are consistent, holistic, and interoperable.” Does this bullet imply
new standardization activity?  What is the deliverable for "advocacy of
gap-filling work"?

The deliverable is engagement with other groups, and if that turns into a deliverable within that group then that’s great. Since we see WIMSE as a place to gather workload expertise, problems, and solution spaces, we think it’s important that this expertise be ready and willing to engage with other groups. We think of this as similar to a DISPATCH outcome — if someone brings work into this group that’s a better fit elsewhere, we’re saying that WIMSE will proactively seek and engage the "elsewhere".


(4) Per “Engage with other relevant working groups to pinpoint and address gaps
in current standards”, if this is in scope, what are the relevant WG and the
gaps?  As the initial deliverables are currently described, no existing IETF WG
appears to be built upon beyond JOSE and HTTP.  I observe that the charter says
to coordinate with OAuth, SCIM and RATS.  What gaps in what standards of those
WG is WIMSE focused on?

Token delivery and formats today are largely based on OAuth work, and some current OAuth drafts (like transaction tokens) are directly related to WIMSE’s goals and environments. I would personally argue that if WIMSE had been chartered at the time, the transaction token draft would belong in WIMSE and not in OAuth.

I believe "SCIM" might actually be a typo where we meant to say "SCITT", and with that and RATS you can start to address the foundational software, device, and system identities that workload identities can be built on — and in fact are built on today in running systems. But those spaces don’t get at the runtime context that WIMSE seeks to address, and likewise WIMSE does not seek to address supply chain or platform attestation.


[Joe] Yes I think SCIM should have been SCITT.

[Pieter] SCITT is a good addition here as the security of workload identity includes tying back into the supply chain (this is needed both for vulnerability management and incident response), but when I proposed the original text, the intent was that SCIM is also included in the set of working groups we will collaborate with. Provisioning of workload identities (not just identifiers, but also metadata needed to manage those identities) across different service environments is another critical part of managing workload identities at scale. SCIM already focuses on identity provisioning and extending SCIM with workload specific capabilities may become a necessity (something I expect may be identified in the architecture document). There is already some work happening in SCIM to support device provisioning, and similar work may be needed for workloads.


(5) Per the goal of “Initiate and develop new standards that provide the needed
functionality and ensure their widespread adoption to address propagating,
representing, and processing of workload identity”:

** what will the WG do to “ensure … widespread adoption”?  What’s the
deliverable?

We make good standards and engage the relevant communities, like any other WG would try to do. :) I admit that it’s a bit grandiose to say we can ensure it, but we certainly can try.

[Joe]  More concretely it's keeping the needs of the workload environment and problems space in mind, which includes developing solutions that are adaptable to other protocols and that integrate with the security requirements and mechanisms deployed in these environments.

[Pieter] This text is meant to guide the working group in making decisions in triaging different proposals. Widespread adoption follows from developing standards that can be used with existing systems such as SPIFFE and OAuth and widely deployed technologies like HTTP, gRPC and Kafka. We won’t be able to prioritise all of these (elsewhere we express preference for HTTP, but not to the exclusion of other protocols for example). We believe that picking proposals that are compatible with widely deployed systems will give us the broadest reach and the best chance of broad adoption.


** what is “processing of workload identity”?

I’ll say we struggled on capturing this at the right level for the charter — we are talking about situations like "what happens when a workload receives an identity from another workload?" The major space here is authorization, but we (1) believe that there are other functions beyond authorization, like call chain verification, and (2) we do not want the WG to focus on authorization technologies themselves. So, while this group would consider an application of, say, a cryptographic graph processing runtime provenance, it would not adopt a policy language or authorization rules system as an item.

[Joe] Processing would also include proof of possession or binding to identity where required.


(6) Per the entire list of deliverables, there seems to be an implicit
architecture of the solution but that isn’t sketched out anywhere.  See a few
example of that below.

We believe that there isn’t one single architecture that’s universally true, but we believe there are a lot of commonalities. The thing is, nobody has written those down anywhere. The Architecture document deliverable is specifically designed to capture this need. The specific deliverables, as they are today, reflect that we can see point solutions in this space but do not yet see a single grand overarching architecture that unites everything.


(7) Per the initial deliverable of “Securing service-to-service traffic”:
** Editorial. Expand “authn/authz”

** What is “strong identification of microservices …”?

By this we mean an ability to verify the identities of portions of a workload at runtime. Say I’ve got three micro services that talk to each other, I need to be able to identify them individually as well as identify them together in a context. This duality is found throughout the workload world.


** Is "within and across trust domains" effectively the internet then?

I don’t believe so, as when we say "across trust domains" we mean specific point to point connections that carry a specific context with them. So it isn’t meant to be "A and also Not A", it’s meant to be "A and B". The most important thing here, to me, is that the group is chartered for problems that exist within single domains (such as a tightly coupled call chain) as well as across connected systems (such as an API service running across multiple cloud environments).

[Pieter] This is not so much about where the traffic runs, but rather about how trust is segmented and managed. Trust domains effectively define security perimeters governed by specific security policies. They are used to segment compute environments and this segmentation may happen within an organization (between divisions or departments) or between organizations (e.g. two companies collaborating on a project). Traffic may be routed over the Internet, but often also get routed on private networks. When operating within a Trust Domain, the workload identity must be protected against compromise within the trust domain as part of ensuring least privilege access. A workload in one trust domain often needs to access a resource in another trust domain, when it crosses over from one trust domain to another, it may need additional measures to prevent it from being compromised, or from being compromised in the second trust domain and the used in the first trust domain. This is not so much about where the traffic is running, but rather about how to preserve trust in the workload identity within and across these trust domains when it is authenticating itself and when the workload identity is included in authorization decisions.

(8) Per the initial deliverable of “Token Issuance”:
** What is a “workload component”?

Part of a workload, most commonly a micro service of some kind.


** Is this work describing a new protocol (i.e., what is a “method for
issuance”)?  Does that protocol build on anything (e.g., is it HTTP-based?)?

Some existing systems are HTTP based, some are not. The WG would collect and evaluate these existing approaches.


** Is this the protocol for issuing the “JOSE-based token solution” described
in the previous bullet?

It might be, but the result might not be JOSE-based. These are composable solutions.


** What’s the different between local and generic token issuance?

"Local token issuance" was our intent to capture the practice of a workload component being able to create/sign its own tokens locally, where "generic token issuance" was that same component relying on a specialized "signing service" to do the issuing. Both are well established patterns, but there isn’t a lot of guidance about how to properly apply them. As such, in the wild you run into people using a local token signing key in a workload because it’s fast and simple, but without considering the security hazards and auditability tradeoffs. We anticipate this deliverable would change that.

[Pieter] Expanding on Justin’s comment, Generic can also be thought of as Centralised. Local can be the workload itself or another workload deployed closer to the computing edge (local to the workload) that issues tokens. Local issuance is needed to increase resiliency and reduce latency in distributed systems (all of which are densely populated by workloads). As Justin points out, these are not novel approaches, but the industry would benefit from guidance on how to think of mitigating the risks of localised issuance.

(9) Per the initial deliverable of a “Token exchange”
** What is the relationship between an incoming token and workload-specific
tokens?

The workload-specific token takes the incoming token as input to its context, along with the workload identity, runtime context, and other factors. So the workload-specific token is derived from the incoming token, but the incoming token isn’t the only input to that derivation process so we can’t say it’s a direct descendant.

Let’s say you’ve got a user that says "go print this photo", and you’ve got a workload that runs the photo storage and one that runs the printer. The incoming token has information about the user and what they’re asking you to do, but the workload need not know anything about the user as a person, but rather the photo entity being accessed. So the photo-storage workload token would say "you can fetch data for this photo", which is based on the exchange being done in the context of ’this user can load that photo" and "this workload is allowed to load photos at all". The printer likewise doesn’t need to know any of that information, only that they can access the photo data that’s been passed in to the workload and can access the printer. So the workload token here is more generic, "you can print the photo that I give you".

Both of these workloads might have multiple steps in the chain — for example, color correction, audit logging, resize/resample, checking printer ink levels, etc. All of that gets kicked off in the context


** Is the workload-specific token the "JOSE-based token solution" described
earlier?

It might be, but the result might also not be JOSE-based. These are composable solutions.


** Can the token formats which will be exchanged be described now?

We could enumerate some today (JWT, CWT, PASETO, Biscuit, Macaroon), but I don’t think it’s helpful to put those limitations into the charter text. Rather, I think that’s a job for WG consensus.


(10) Per the initial deliverable of “Document existing local token distribution
practices for workloads: An Informational deliverable describing the
considerations and best practices for filesystem-based token delivery in
Kubernetes.

** In my cursory review, the contents of
draft-hofmann-wimse-workload-identity-bcp-00 don’t seem to match the
description of this task.  The don’t seem to talk much about file-based token
delivery.  It sketches protocol interaction (Figure 1) relying on OAuth.

Yes, the input document is not explicit about that in its text, but that is the background from which it was written — what do you do when you are delivering a token to a workload without it going to an external service or making a network call? In addition to the BoF at the last meeting, the ongoing discussions on the mailing list and on regular phone calls have expanded the goal of this deliverable to address this more generally.


** This deliverable is framed as being “informational” status.  However,
publishing informational status documents isn’t an obvious scope from the text
is the goals section.

I would expect the WG to deliver standard and informational documents as best fits the individual deliverables. As this document specifically is describing best practices, we anticipated an informational RFC would be the right target.



--
Wimse mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/wimse