[Wimse] Re: Request for Agenda Item: Workload identity authenticator levels

[Watson Ladd <[e-mail]>]

On Tue, Jul 9, 2024 at 10:48 AM Pieter Kasselman
<[e-mail]> wrote:
>
> Hi Watson
>
> It's not so much about use cases/justification for weak authentication, but a way to classify it, and more importantly for people defining systems to 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 frequently applied to ensure a workloads identity. The reality is that bearer tokens and shared secrets where no attestation of the workload ever takes place exists, and without a way to classify these relative to the better practices (strong crypto, hardware, attestation etc) only sophisticated customers will be able to discern systems. Put another way, it is hard to avoid something that is harmful, if you have no way to tell if it is harmful (or at least 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 <[e-mail]>
> Sent: Tuesday, July 9, 2024 6:34 PM
> To: Pieter Kasselman <[e-mail]>
> Cc: Saxe, Dean <[e-mail]>; [e-mail]
> Subject: Re: [Wimse] Re: Request for Agenda Item: Workload identity authenticator levels
>
> I am very confused and not following the conversation here.
>
> The orchestrator definitionally authenticates workloads in the same way that 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 not 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 confidence 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



-- 
Astra mortemque praestare gradatim