Notes from today's call

notes/20240416.md

@@ -6,17 +6,63 @@
   * Confirm everyone has access to [GitHub repo](https://github.com/dhs-aws/wimse-token-exch-design-team/)
   * Weekly meeting notes to be stored in GitHub under the /notes folder
   * Interim meeting scheduled for May 22 10:30 AM EDT (GMT-4).  Need a volunteer to lead the token exchange discussion since I'll be working from Osaka
+
+  * Yaroslav has volunteered
 
 * Intro from Evan - token exchange issues, considerations in SPIFFE, [draft use cases](https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/)
+
+Evan: Two things that are top of mind. Low hanging fruit between SPIFFE <-> OAuth/OIDC
+1. workload identity federation validated by an OIDC validator is super common (see examples from Evan [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) and [here]() ), lacks a spec, lacks an interop, exhanges in the APIs are all different .  We need to extract the important bits and put some context/control around it
+2. Client secrets (SKID/AKID) - looking to SPIFFE to solve this problem using the SVID as a cred to replace the secrets.  Can do this with mtls or SVID-JWT.  X509 is the more common pattern.  There are existing mechanisms to do this transition (Evan to send a link).  Recommends looking at the OAuth mTLS spec. Some of the more difficult issues are through rotation of certs.  Rotating the root cert requires updating all the clients. [George] Conversation about mTLS is happening within the txn-tokens work which profiles OAuth token exchange. [Dean] Add this to the reading list for two week so that we can discuss in 2 weeks.  Leave issues on the github repo. [George] Is there something in this draft that is more abstracted for WIMSE?  Do we need a COSE/CWT version?  
+
+Yaroslav: Is token exchange on the workload itself, or is it on an intermediary?
+Evan: Both! Sometimes it's a sidecar doing the exchange.  Exchanges usually result in domain specific tokens.
+Y: Gateway usecase (LB, for example) - translation here on the gateway?
+E: Less common, usually the gateway is doing SPIFFE on one side and something else on the other side 
+D: Is this a token exhange or a pass thru?
+E: Termination from one domain, transition to the 
+George: If part of what we're doing is enabling full path identification, this termination is an issue.  How do I translate user subject identifier in domain 1 to domain 2?  How do I pass through the API Gateway and know anything about the client in the other trust domain?  In Evan's example, the services behind APIG only know the identity of APIG.
+Y: It's not binary, we don't blindly trust.  APIG can tell us about the upstream caller.
+D: CSRB report - how do we know the token is not forged
+Y: APIG could verify info about a client and add attributions to build end-to-end-trust.  This could be used in downstream authZ
+G: If our trust is in the crypto signing of a token/issuance of a cert, if someone compromises this they mint tokens/connections.  How do you know that this was done by a service that we don't trust.  Put this on the list.  Bigger issue in a bearer token world vs. sender constrained. Sender constraining can impact widescale deployment becuase it might require token issuance per hop.  e.g. APIG gets a token, isuses a new token that is constrained, the next service gets the token and has to re-sender constrain.  Can we use Justin's bucket logic to layer on top?  Maybe this is only viable in super high risk scenarios.  We need different security layers to map to different risks.
+
+
 * Getting Things Done - Workstreams
   * Use Case development
     * build off Evan's [draft use cases](https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/)
     * Token translation - SPIFFE to JWT, JWT to SPIFFE, etc.
       * Do we know all the token types we wish to convert between?
       * Or do we want to build a generic token translation mechanism and then profiles for X to Y, Y to Z, etc.?
+
+[Evan] look at the docs I shared, everything results in a domain specific token.  If we want to work on this, how do we return an opaque credential?  If we do this, everything is generalized.  
+[Y] I would agree.  There are classes of tokens/constraints on different types of tokens.  X509 doesn't carry claims, for example.  
+[G] Interesting aspect, when token exchange came up it was how do I convert SAML assertions to access tokens.  The semantics of input and output are similar.  Evan, if I understand, there's another level - authZ - I have this token and I want access to the vault, so return a token that works at the resource.  This is almost like the JWT bearer flow to access a resource.  There's an authz issue here - can the inbound token be exchanged for the outbound token being requested.
+[E] this usually happens at the exchange.  Generally these are placed on top of other authN/authZ mechanisms.  Usually the token is used to authN against a system which results in a session token.
+[D] We can't define the authZ mechanisms
+[Y] 
+
+
     * User mapping across domains - How does Workload User A at MSFT translate to a user in AWS/GCP?
+    [G] this has been a convo in the identity chaining working group.  We should read the docs from that work in the OAuth WG.  In this space, it's largely a function of the authZ server in domain A providing context to domain B's authZ server.  Sometimes the mapping is direct, other times it is not.  The higher order bit: What use cases contain users that are different than the workload identity itself?  We probably have server to server workload identities and requests where we want to bind the requester (machine/human) to the machine to machine tokens. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining 
+    [E] In SPIFFE the way the mapping takes shape is at the edge.  SPIFFE is the normalized identity working across multiple clouds, but there's a transition/mapping to a local user
+
       * Do we need SCIM for both user and workload identities?
+      [E] this is a thing for IGA. This is new work happening at SPRL.  Other IGA startups are working on the space as well.
+      [G] 2 kinds of use cases?  1. Human entity is known across trust domains (use SCIM, other mechanisms), 2. The resource in the external trust domain only wants to know about the identifier for the human but doesn't need to know who the human is.  This is only for auditability.
+      
       * How do we avoid static mappings which are hard to maintain in large environments?
   * Security Considerations development
     * Look into the [CSRB report on Microsoft](https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review_of_the_Summer_2023_MEO_Intrusion_Final_508c.pdf) - can we reduce the risk of stolen signing keys/tokens?
+
+* Writing use cases - Dean to set up a google doc for us to author use cases.
+* [email protected], [email protected], [email protected]
+* 
+
+
 * Any Other Business?
+  [Y] PQC signatures is a hot topic. Can we use token exchange to move between non-PQC and PQC signatures?
+  [E] Gut reaction - another flavor of gateway trading of tokens.  Crypto agility is necessary for any practical work.  Take a stance that is pro crypto agility without specifying the specific crypto mechanisms
+  [Y] Make zoom recordings.
+  [E] Zoom AI transcript feature?
+  [Y] I'll see if I can enable.