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

["Saxe, Dean" <[e-mail]>]

Watson,

I think it's more challenging than simply making a pithy statement about shared secrets, even if I agree with the statement!  

In many cases, workloads operate on behalf of users.  There is a need to propagate properties of the authentication event(s) to downstream systems so they may be used as part of an authorization policy.

To use a FIDO specific example, two users can both authenticate with a FIDO-based credential such as a passkey.  One user uses a passkey that is synced across a fabric (e.g. Dashlane, 1Password, iCloud, etc.), potentially to many devices with different, unknown security postures.  The other uses a passkey bound to a hardware device like a Yubikey.    Both are using credentials that are highly phishing resistant and not shared secrets (yay!).  But these credentials have fundamentally different properties when we consider their storage, shareability, and recoverability.  They are not equal in terms of their inherent properties.

While this difference may not be impactful for all workloads, there are workloads that do need the ability to make authorization decisions based upon the properties of the authentication event(s).  My example focused on end-user authentication, but I believe the same to be true for a workload-to-workload authentication event, too.

-dhs

-- 
Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/> (he/him) 
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) 
E: [e-mail] <mailto:[e-mail]> | M: 206-659-7293 <tel:[phone]> 




On 7/9/24, 11:39 AM, "Watson Ladd" <[e-mail] <mailto:[e-mail]>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






On Tue, Jul 9, 2024 at 10:48 AM Pieter Kasselman
<[e-mail] <mailto:[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] <mailto:[e-mail]>>
> Sent: Tuesday, July 9, 2024 6:34 PM
> To: Pieter Kasselman <[e-mail] <mailto:[e-mail]>>
> Cc: Saxe, Dean <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[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