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

Andrii Deinega <andrii.deinega@gmail.com> Mon, 29 July 2024 22:57 UTC

Return-Path: <andrii.deinega@gmail.com>
X-Original-To: wimse@ietfa.amsl.com
Delivered-To: wimse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA4C151087 for <wimse@ietfa.amsl.com>; Mon, 29 Jul 2024 15:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay-nZBfaD5FA for <wimse@ietfa.amsl.com>; Mon, 29 Jul 2024 15:57:29 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7620C14F6E1 for <wimse@ietf.org>; Mon, 29 Jul 2024 15:57:29 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2ef2d96164aso45791621fa.3 for <wimse@ietf.org>; Mon, 29 Jul 2024 15:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722293848; x=1722898648; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QABGX7wNbzSIw/I/PiZTJVUh7SZN/GUQzdEbS0uRGrc=; b=NXOumeAuSOopHBvJKQ1LLdlc7XnAT1aH7gMSy/D6ZAOzB7WTZiy/uaLNp5FM3SRBQN 1LpT0kP1dg1mYrEsIDvxQiVRNGkVvWwped+G0bkdY23MhlkCEoqityo2pKMbIean5KSn YKo56XOZAoyLBoW5QKIcnFHCaRu0dVEnOUnlawJ4hENMNLpCVJO+ccFRmgxZK0p8ZvP0 C7AHNb4hhTNKw9V2cKEBJeG5SYN6n+YotDXhr241OIotMAVIPn8A9DCZXOhysDoW9FoG jPK+gY5B25n7YaM5/EuIm3NWJhyFQk/4/YqmfWSeMgVF73B9abNd4l1vAuAN/iGDtrue 9crA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722293848; x=1722898648; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QABGX7wNbzSIw/I/PiZTJVUh7SZN/GUQzdEbS0uRGrc=; b=v0a074uyOJml3Zhu2lLctCpfJpDJnKVGCcNgzb1srSCVeKFpDMnJFWMhTqMUKLemOE 9hRZTdW7hmJjKwfe/gFJNEpWd7tlpsZwts2GAjAspQ1238ehaeuMGTEEyMKrhTH8IUBF +vRShv+BTkAw/djosiR++04NFqGlzRTQCNjpBxQ7Pv7ZsuNYlMX1/E9Ewnrtm92IDHUn 03e5GDmu2xQaeunhqQvlP3qI6zxplcb/J41Rly6foz8jL5qeTaP7SmBkjdSSnGRKhdzI LFHU9INYvtHhZTV5mXWeq2yoI1yu0Petf8DkXPG1591N3nfAJe7TYe9s4FaKRz+zZtCB Aqmw==
X-Forwarded-Encrypted: i=1; AJvYcCWavF2phHXY2gpGSN/FH06vG4ZbWYvcnumaniCoRwTtyhWwWWQAYOz6bKLqsAjyy3XmOzSSwt4s0a2TyV4HqA==
X-Gm-Message-State: AOJu0YyxEjNzsT6uJJx7L7xY3wJllbg9YwOlivlFv/e2EJDHTgZNSemb 57HD1DkgtlVRcpH+SwoaQ865XNg/MSDAlcSUqiy27OnBrjrswta8zJ2aN0zkABbiDuD1F7AENOL TqAAdYJiDYymsZpnRwfRL3ghG5UI=
X-Google-Smtp-Source: AGHT+IFi8CFAJiuAhxI3dCO50JyJwYZaQJmqKYDnDYoy9lHMLhwmy7UQ7SBB8MO8fb77iLf/TRjLb50uan4IAUSG3SY=
X-Received: by 2002:a2e:9608:0:b0:2ef:2443:ac8c with SMTP id 38308e7fff4ca-2f12ee422eemr56967951fa.31.1722293847570; Mon, 29 Jul 2024 15:57:27 -0700 (PDT)
MIME-Version: 1.0
References: <DBAPR83MB0437B6623ED287A218D1FE4F91B72@DBAPR83MB0437.EURPRD83.prod.outlook.com> <7c7c2092-a806-4f28-a37b-f3556b9858a5@cisco.com>
In-Reply-To: <7c7c2092-a806-4f28-a37b-f3556b9858a5@cisco.com>
From: Andrii Deinega <andrii.deinega@gmail.com>
Date: Mon, 29 Jul 2024 15:57:16 -0700
Message-ID: <CALkShctBATK+KknNNtvDP_Yti5tH2omYKv9JQqSjAhEte95LcQ@mail.gmail.com>
To: "Flemming Andreasen (fandreas)" <fandreas=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fbc49a061e6ac826"
Message-ID-Hash: CE4E4776BRCUNOYFUQCB2NK52OZD44OL
X-Message-ID-Hash: CE4E4776BRCUNOYFUQCB2NK52OZD44OL
X-MailFrom: andrii.deinega@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Pieter Kasselman <pieter.kasselman=40microsoft.com@dmarc.ietf.org>, "wimse@ietf.org" <wimse@ietf.org>, Justin Richer <jricher@mit.edu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Wimse] Re: Request for Input: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments
List-Id: WIMSE Workload Identity in Multi-Service Environment <wimse.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wimse/VFuuS2zZTwEIizR5kGPjPF8HXh4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wimse>
List-Help: <mailto:wimse-request@ietf.org?subject=help>
List-Owner: <mailto:wimse-owner@ietf.org>
List-Post: <mailto:wimse@ietf.org>
List-Subscribe: <mailto:wimse-join@ietf.org>
List-Unsubscribe: <mailto:wimse-leave@ietf.org>

Pieter, I choose to go with C.

ATs need to be protected from replay attacks, there must be a proof of
possession mechanism in place, without that we can't simply refer to it as
BCP.

https://mailarchive.ietf.org/arch/msg/wimse/HeF1jAzR6p1BPT_jx_6MuLN7WM0 is
also my feedback on this document.

All the best,
Andrii


On Mon, Jul 29, 2024 at 3:17 PM Flemming Andreasen (fandreas) <fandreas=
40cisco.com@dmarc.ietf.org> wrote:

> Given the choices, I would go for option A (i.e. no specific
> recommendations), the reason being I don't think it makes a lot of sense
> for WIMSE to recommend one thing based purely on OAuth access tokens, when
> we may end up specifying something different using WIMSE tokens (or
> whatever we end up calling it). I do think pointing out potential issues
> with current mechanisms would be helpful though.
>
> Thanks
>
> -- Flemming
>
>
> On 7/29/24 06:21, Pieter Kasselman 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 -- wimse@ietf.org
> To unsubscribe send an email to wimse-leave@ietf.org
>