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

[Pieter Kasselman <[e-mail]>]

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).

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