# WimSE BoF at IETF 118 {#wimse-bof-at-ietf-118} Tuesday, Nov. 7, 13:00-15:00, Congress Hall 1 Note Takers: Dean H. Saxe / Rifaat Shekh-Yusef ## Agenda {#agenda} 5 Opening Chairs * Side meeting tomorrow at 10am. * Non-WG forming BoF today. * We'll gauge the activity today to determine next steps - BoF in Brisbane or creating a WG between 118 and 119 10 Standards and related work Pieter Kasselman * One challenge today is that customers run workloads in multiple clouds with no mechanisms to reason over the identity systems across these clouds * Need standards for a variety of things, eg. authN, authZ, federation, attestation, monitoring, worload federations, etc * Many existing standards that we could leverage, including other organizations' standards (see Pieter's slide for a description of the various standards) * Challenges: There's a gap today, even with all of the existing standards. When we go end-to-end the standards don't fully align * Client registration * Request binding * Resiliency * Latency * These standards exist, but lack clarity in how to use them in a composable manner. * How do we connect all these standards? Request binding (Evan): * simplified example JWT * differences from regular OAuth include tightly scoped expiration, audience is another workload * Which has implication on availability and scalability * DPoP was considered to be applied to workload security, but it has some limitations: * JWT placement is one issue * htm, htu claims * This was not a perfect fit for SPIFFE - DPoP is HTTP centric, but workloads may not be HTTP centric We needed something more flexible Do we need a new spec for that? 10 Use cases doc Pieter Kasselman and Justin Richer * What's a workload? * a singular piece of software ... deployed with a specific purpose * Which may consist of many copies of software executing the same tasks * Identity is needed to allow us to identify each one of these worloads * SPIFEE allows us to give identities and keys to the workloads, but it leaves some open questions * OAuth abstracts all these workloads into a resource server concept * If you explode the RS you see it represents multiple services in many cases. How does the leaf node understand the context of the request? * How do we cross boundaries and make sure it makes sense * This workload can call another workload, possibly in another cloud. How do we convey information between these workloads and across clouds? How do we reason about each workload's internal state? How much do the individual elements in the workload trust each other (see Justin's slides, how does Qux trust Baz?). * Use cases * Constrained credentials - how do we prevent token replay? * Cross-workload acces: because of the large number of clients, there is no client registration? * Chain of custody of requests - know who was in the path of a set of requests? * How do I make low latency/high resiliency local decisions about authZ? * How do we reconcile logs across these workloads, especially when the workload is disconnected from its control plane for an extended period? * Location authorization 10 Quick introduction to SPIFFE Evan Gilman * Workload identity spec lives inside the CNCF * AuthZ is out of scope for SPIFFE * SPIFFE identifiers are structured as URIs * Reuses existing identity documents, e.g., x509 and JWT * They are used separately, some people use both at the same time * SPIFFE has platform agnostic issuance of identities and credentials * Agents communicate with an SPIRE server API server * Support federations * We are not asking to move SPIFFE * there are gaps in the ecosystem today that SPIFFE cannot solve, these use cases are out of scope for SPIFFE and need a home. 15 Workload Identity BCP Hannes Tschofenig * there's a new draft from Hannes in datatracker * Workloads in distributed systsme need to access protected resources but we lack scalable mechanisms to enable this. * In OAuth we use Client Id and Client Secret * K8s has a control plane * Has agents that communicate with control plane and instantiate worloads * Define profiles that could help people use the existing protocols properly 15 SPIFFE token group presentation Marco Marques, Charles Miers, and Marcos Simplicio * Nested Token Model * a decentralized mechanism to locally create authenticated statements * supports extension and incremental signing (aggregation) * can covey multiple sets of claims in a size sensitive manner with cheap singature validation * tokens are tech agnostic, the POC uses a JSON based model * Minimal claims enabled to ensure interop * Payload, Signature, and Nested * Common name * Public Key * ID document * Signature schemes * ID mode backed by an ID provider (SPIRE in this case) binds the issuer to a unique audience * identify and link issuer and audience * (see image presented in slide which shows the nested nature of the tokens and how they are composed across hops) * ekr - what assertions can be made based upon signature ID? * If one document starts as JWT and change tp CBOR, how do you detect that? * George Fletcher - there are properties of the transaction context that should be immutable as it passes through multiple services * What is one of the entities in the path is compromised? more work to be done on this * Anonymous mode which uses ephemeral keys and aggregation scheme to create smaller token signature chains * does not require an aud claim to bind sender/receiver * aggregates singatures based on Schnorr Signatue Concatenation * the target workload can validate all of the signatures * Future work: a hybrid mode 15 Token containers Justin Richer and Orie Steele * Token containers enable a mechanism to inlcude >1 token/request. HTTP only enables one * What if we need more than one token? * Workload processing * every stage can augment the request with additional attestable data * Back to Justin's diagram * Afte the gateway receives an access token, the token is no longer an access token when it hits foo or bar * it's no longer an access token, esp. with token binding * it's metadata about the request when passed to downstream nodes * Build the system as a graph to allow additional values to the structure * Tokens contained in buckets, buckets are contained in crates. * reference any node in the crate via its hash * * Interesting properties: * You can trim few nodes and the graph would still be valid * the trimmed graph can be added to and then merged back to the original graph * Orie - digital credential workflows * these graphs can be uses for selective disclosure * Roman Danyliw - what's the overlap with the SPICE BoF? * the data structure (crate) needs to be defined somewhere, that's probably in SPICE (Justin) * Roman - I should not try to link SPICE and WIMSE together? * Pieter Kasselman - these are all ways to solve different aspects of the use cases. Both are valid at different points in time. * * If there are other ways of providing us with the same properties, we will consider that. * supply chain needs a graph structure as was described before. * What is the role of transparency? It is not clear if this is needed here? 40 Scope, charter, next steps, open discussion Chairs * This is not a WG *yet*, nor is this a WG forming BoF * almost everything is open for discussion * Proposed charter: see mailing list or Yaron's slides * Proposed BCPs * Gap-filling work * Standardize new solutions if gaps can't be addressed in other WGs and/or SDOs * Deliverables in priority order * use cases * best practices, informational docs that are implementable today * note these may be point in time with a future planned deprecation * Architecture & Gaps * New standards (lowest priority) * Preferably relying on existing WG work * Ekr: The charter is open ended * Start with an architecture and continue from there * Justin - "I agree" The goal from initial conversation was to identify specific things and put together a BCP/architecture to identify where the gaps are for more work to be done. * Roman - charter text reads like a standing WG. Why do we need a WG to find out what the problems are? * Cullen J (Cisco) - I'm really glad to see this. Risky place for a blank check open charter. This could be a magnet for work rejected @ other SDOs. BCPs are probably "usage documents" * Cedric Fournet - Not sure what's a workload and what is not. What is specific to a workload? * Hannes Tschoefenig - Focus on fine tuning the use cases. * Roman - What do we mean by "architecture" * Is this new architecture? existing architecture? * Hannes: utilize existing architecture * Roman: are you saying that all the deployed architecture are not documents? * Yes * Cullen - we need a roadmap of how things are run today... this is more than just looking at source code * Roman - do we have an IETF pattern where we document the architecture of non-IETF standards? * Justin - the context gets lost over time due to institutional knowledge going away. * preventing rediscovery should be part of this work * what weird hacks are being done that work and need fences put around them * * Pieter: * sometimes it is just documenting our own protocols and how they should be used properly * If a workload identity is compromised, it has a major impact that goes beyond what a user identity compromise entails * Hannes: sometimes we document what are some of the implementation produced but it was not documented properly for us to be consumed * AJ: I am still confused. Are we talking about Identity and authentication for the workload in the cloud? * Yes * Chair (Joseph Salowey) - I know we want to get to a concise charter. I want to understand if there is work here that is appropriate for the IETF? * Yes - 33, No 4, 61 no opinion * Next Question - How many people would contribute to this by authoring or reviewing documents? * Yes 30, No 10 , no opinion 58 Murray: Is this SEC or ART area? Orie: Feels like ART becuase we are talking about documeting what's out there Ekr: it depends on what we will be doing. Francesca: There is lots of interest but the scope is not clear yet.