[Wimse] Re: Request for Input: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments

[Justin Richer <[e-mail]>]

Hi Yaron,

[Chair hat on] That’s a great question and it raises the importance of dependencies between different parts of WIMSE work, which all of the document authors and contributors need to be aware of when working on these docs. Please note: It’s OK to non-normatively cite documents that are incomplete (i.e., still in the I-D phase), but care needs to be taken not to normatively cite something that is not done or else we have to ship the documents together in some way. Any such dependencies should be decided on explicitly by the WG.


[Chair hat off] That’s a great question and I think there’s a pretty straightforward way out of the dependency trap:

I would still like to see this document focus on my point (2) below and the implications of it, and cover all three cases. But on top of that, I think there’s room to mention that the token you get from any of these processes could be a regular access token, to be used at another RS, or some kind of other artifact like a WIT or a SPIFFE JWT-SVID or some assertion — all of which are NOT access tokens and are instead usually used to GET access tokens or do some other action. This document doesn’t need to (and shouldn’t) go into detail about the content and format of the tokens, but I do think it makes sense for this document to differentiate based on token use.

So that gives us a framework with three inputs paths and three output goals:

Inputs: environment, file system, socket

Outputs: access token, identity document, assertion

Maybe the identity document and assertion are actually the same? I don’t know, but they are clearly made for a different purpose from the access token, which is classically about an authorized grant of access and not the identity of a party. I think that this is where the PoP aspects can also be defined — where do the secrets come from? Are they parallel with the token or through something else? Are they ephemeral or part of the workload’s configuration? All of these are important discussion points that don’t directly require this document to define how to DO PoP on any type of token or use case.


 — Justin

On Aug 7, 2024, at 9:25 AM, Yaron Sheffer <[e-mail]> wrote:

Hi Justin,

I’m puzzled by your proposal, because you are mixing existing deployments (workload security in K8s, the current focus of the document) with future, “aspirational” problems. The WIMSE token does not exist yet, all we have is a not-yet-adopted draft that defines it.

There’s a lot of value in documenting existing (pre-WIMSE) practices of getting workload credentials, and in recommending the best security for these practices.

In the future there may be value in having an Informational document about various ways of provisioning WIMSE tokens.

But mixing the two is IMHO a bad idea.

Thanks,
                Yaron


From: Justin Richer <[e-mail]<mailto:[e-mail]>>
Date: Friday, 2 August 2024 at 0:31
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Wimse] Re: Request for Input: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments
Chair hat off — this is entirely my position as a member of the community.

My answer to the question is a form of (B), but I think there’s actually more to do than just add some OAuth considerations to the document.

As the document stands today, I do not believe that it addresses the milestone or deliverable as defined by the working group, in either its stated scope or its content. I would like to offer what I hope is a helpful framing of the goals that I believe this document should ascribe to. I believe the document can reach these goals if we choose to, but it would need a good amount of work to get to that point.


1) It should be informational, not BCP. We are far too early in the work of WIMSE to determine what "best practices" are by the IETF definition. [1]


2) It should explicitly enumerate and address the three non-oauth means of "getting a token" that are common in this space. These are hinted at in the document, but to my understanding these practices are:

 - Setting environment variables
 - Mounting a file on a virtual filesystem (usually through some container overlay, etc)
 - Reading from a local socket through an agent

Each of these approaches has different security considerations and tradeoffs, and this document is the perfect place to address each of these practices with clear, sober advice for implementors on what to choose and when to choose it.


3) It should focus on the token from (2) in the cases where it’s a WIMSE token, as defined by other docs in this WG. Specifically it should point out that what you’re mounting/loading/etc is not an "access token" in the traditional sense, as it’s not intended to directly call another service after an act of delegation. Instead, it’s a means of identifying the workload instance and allowing it to perform core functions, which might include getting an access token through some means.


4) It should point to other work for trading the WIMSE token from (3) for an access token where needed, these won’t be in this document. The WG has identified token exchange/translation and as-of-yet-undefined "local token issuance" as means of going from the WIMSE space into OAuth space, and vice versa. This document shouldn’t specify how to do any of that, but should instead point forward to other work as out of scope. This work could also talk about getting transaction tokens or other artifacts.


5) In the case where the token from (2) is actually an access token or used as such, there should be security considerations and discussion around the tradeoff — because somebody’s going to do it that way anyway regardless of how much we warn them. This document is a good place to discuss such tradeoffs — for example, you save a round trip, but now you have a much more dangerous artifact immediately available.


6) It should address but not define proof of possession, to the extent that it talks about loading and managing associated secrets alongside the token. The means of token PoP should be covered by other documents, such as the proposed S2S document.


I think that if we address the six points here, this document could be an incredibly useful piece of work for the wider community. I also don’t think it’s a massive amount of work to get there — certainly much more than what the document currently addresses, but as it’s informational and largely documenting and commenting on existing practices instead of inventing protocols and formats, I believe a lot of the knowledge already exists out there in the community and it needs to be distilled and edited.


— Justin

https://datatracker.ietf.org/doc/html/rfc1818


On Jul 29, 2024, at 6:21 AM, Pieter Kasselman <[e-mail]<mailto:[e-mail]>> wrote:

During the Working Group meeting in Vancouver there was discussion on the scope of the Working Group document titled Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments [1], which was adopted in accordance with the following deliverable in the charter [2]:


  *   [I or BCP] Document and make recommendations based on operational experience to existing token distribution practices for workloads.


This is intended to respond to the following milestone [3]:


  *   Submit informational document describing considerations for filesystem-based JWT delivery in Kubernetes to the IESG


Please reply to the list to indicate which of the following options represent the appropriate scope for this document:


  1.  Document existing practices without specific recommendations on how to obtain, protect and use OAuth Access Tokens.
  2.  Document existing practices along with strong recommendations on how to obtain, protect and use OAuth Access Tokens.
  3.  Need more information (please state what more information you need).
  4.  No opinion (i.e., this isn’t a topic you care strongly about).

Please reply to the list by August 12th, 2024.

Thank you,

Pieter and Justin

[1] https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp/
[2] https://datatracker.ietf.org/doc/charter-ietf-wimse/
[3] https://datatracker.ietf.org/wg/wimse/about/