WimSE BoF at IETF 118

Tuesday, Nov. 7, 13:00-15:00, Congress Hall 1

Note Takers: Dean H. Saxe / Rifaat Shekh-Yusef

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.