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

[Joseph Salowey <[e-mail]>]

I think the document is closest to a description of current mechanisms to
get authentication tokens for workloads and the security considerations
surrounding them.  I do not think we are in a place to define what is best
practice here, but perhaps after a bit more analysis and work on the
document we might be in that position.  Perhaps, at a later point when we
have made more progress we could recommend don't do this, but use this
other thing we are working on.

Answering the question as posed, I think this is an informational
document and not a BCP.  The document should describe the existing practice
and the security considerations associated with this practice.  At this
point I don't think I can say whether we will be able to make strong
recommendations on what to do in this document.  So I think that is
somewhat of a combination of A and C.

I think it would be good if we could make security recommendations that you
should use WIMSE tokens instead because they have properties X,Y and Z.  I
share the hesitation in describing how to obtain WIMSE tokens in this
document, I would prefer to keep them separated, but it's quite probable
that the same mechanisms will apply to WIMSE tokens with perhaps some
different caveats.

Cheers,

Joe

On Wed, Aug 7, 2024 at 6:26 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]>
> *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
>
>
>
> 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/
>
> [2] https://datatracker.ietf.org/doc/charter-ietf-wimse/
>
> [3] https://datatracker.ietf.org/wg/wimse/about/
>
>
> --
> Wimse mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>