MIME-Version: 1.0
References: 
 <DBAPR83MB043778953C0CBEE5AF93CFD991DA2@DBAPR83MB0437.EURPRD83.prod.outlook.com>
 <26349E6F-7DFA-447D-977C-5E1C6E5E1F0D@amazon.com>
 <DBAPR83MB0437B1E1A87C9DDB4F2DFC3291DB2@DBAPR83MB0437.EURPRD83.prod.outlook.com>
 <CACsn0ckJKiFUG_SD6vd_kOh-vymudeEdZ4uc3YfVJgAGStFjWw@mail.gmail.com>
 <DBAPR83MB04377A8BF8F1BBEFE703F47D91DB2@DBAPR83MB0437.EURPRD83.prod.outlook.com>
In-Reply-To: 
 <DBAPR83MB04377A8BF8F1BBEFE703F47D91DB2@DBAPR83MB0437.EURPRD83.prod.outlook.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 9 Jul 2024 11:38:47 -0700
Message-ID: 
 <CACsn0ckeudqMtV4rXqD5zBLaZU=QhWo1xxK7=Zv0vdHoiSgq7w@mail.gmail.com>
To: Pieter Kasselman <pieter.kasselman@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: HEJ66U7OWCFSMJIW3BAOE2WXUSPYTJ7Z
CC: "Saxe, Dean" <deansaxe@amazon.com>, "wimse@ietf.org" <wimse@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BWimse=5D_Re=3A_Request_for_Agenda_Item=3A_Workload_identity_aut?=
 =?utf-8?q?henticator_levels?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/wimse/x0_r6EquTyLXkxIy9-_PiKQlR1I>

On Tue, Jul 9, 2024 at 10:48=E2=80=AFAM Pieter Kasselman
<pieter.kasselman@microsoft.com> wrote:
>
> Hi Watson
>
> It's not so much about use cases/justification for weak authentication, b=
ut a way to classify it, and more importantly for people defining systems t=
o define the level of authentication they desire.
>
> In an ideal world, we will only have strong cryptographic techniques with=
 hardware protection for keys and attestation mechanisms that are frequentl=
y applied to ensure a workloads identity. The reality is that bearer tokens=
 and shared secrets where no attestation of the workload ever takes place e=
xists, and without a way to classify these relative to the better practices=
 (strong crypto, hardware, attestation etc) only sophisticated customers wi=
ll be able to discern systems. Put another way, it is hard to avoid somethi=
ng that is harmful, if you have no way to tell if it is harmful (or at leas=
t not calibrated to the risks your willing to take).

We can just write "Shared Secrets considered harmful" and in
particular part of what we're doing is saying is how to do the service
to service right. No need for a heavyweight taxonomy. I'm also really
confused by saying we need hardware protection and frequent
attestation: to my mind workload approximates service in Kubernetes
language, and one doesn't need attestation (attest what to whom?) as
the constituents of the service are defined by the service definition.
You trust the admission system (but I might by rusty on the exact
terms) to deal with "who gets to define the service", which I think is
largely orthogonal.

On reflection I think there's an underlying difference here in terms
of how and where and what kinds of policies are being enforced, and it
might be useful to have that discussion explicitly.

Sincerely,
Watson
>
> Cheers
>
> Pieter (Identity enthusiast)
>
> -----Original Message-----
> From: Watson Ladd <watsonbladd@gmail.com>
> Sent: Tuesday, July 9, 2024 6:34 PM
> To: Pieter Kasselman <pieter.kasselman@microsoft.com>
> Cc: Saxe, Dean <deansaxe@amazon.com>; wimse@ietf.org
> Subject: Re: [Wimse] Re: Request for Agenda Item: Workload identity authe=
nticator levels
>
> I am very confused and not following the conversation here.
>
> The orchestrator definitionally authenticates workloads in the same way t=
hat e.g. a PID on a kernel identifies a process. One cannot talk about two =
PIDs being the same process (yes, yes linux threads, etc.) or two processes=
 having the same PID at the same time, because the relevant data structures=
 are indexed by PID. Conversely absent the orchestrator being trusted there=
's no way to know what a workload
> "is": it's just some process executing on a compute environment that isn'=
t trusted.
>
> When it comes to workload A directly authenticating to workload B, why no=
t use strong crypto, per transaction? And if you have that, why do you need=
 differentiation? It's easy to do service auth that's strong!
> There might be issues with chaining, but that's what the standards effort=
 here is to solve.
>
> This is different from human authentication as humans cannot multiply
> 2048 bit numbers in their heads and thus have to make do with passwords, =
ssh keys, etc. each with their own drawbacks and hence need to talk about c=
onfidence in human to machine (and human to human:
> medallion signature guarentees are a real thing!) authentication.
>
> What's the usecase for weak auth in service to service?
>
> Sincerely,
> Watson Ladd



--=20
Astra mortemque praestare gradatim