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

[Yaron Sheffer <[e-mail]>]

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]>
Date: Friday, 2 August 2024 at 0:31
To: [e-mail] <[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" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc1818

On Jul 29, 2024, at 6:21 AM, Pieter Kasselman <[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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-bcp/

[2] https://datatracker.ietf.org/doc/charter-ietf-wimse/" rel="nofollow">https://datatracker.ietf.org/doc/charter-ietf-wimse/

[3] https://datatracker.ietf.org/wg/wimse/about/" rel="nofollow">https://datatracker.ietf.org/wg/wimse/about/