Where zero-trust might exist

1. Scenarios that have no data
2. Scenarios with data that are never connected to power

Why?

Because the moment data is accessible by a human, or a system with potential human access - you inherently trust that human.

What about identity?

Digital identity is the only identity. Digital identities can be bio-metric or software-born authentication processes. Where bio-metrics are something you are, there are also software-born processes based on the concept of something you know or something you have challenges.

As we just explained, bio-metrics are authentication and not an identity. The resultant identity is a digital representation of a bio-metric authentication process that is usually unique to an individual person with some exceptions with twins and situations where parents and children are similar enough for some facial recognition not be able to differentiate them as seen with the iPhone.

Another reason bio-metric authentication can never be assurance that the person behind a digital identity is the authorised person is because it cannot eliminate coercion or physical force by other unauthorised people.

Regardless of which person operates the authentication process, no digital identity offers assurance that they are a true representation of a unique person.

In all zero-trust scenarios there is a digital identity, thus we cannot be assured the identity is the unique person we authorise.

Essentially, bio-metric and digital identity are synonymous for software processes, like zero-trust.

Who are authorised people?

When discussing identity or zero-trust, we always eventually need to use digital identity of an authorised person. What makes the authorised identity "trusted" at all times? That is literally the definition of "trust" so there can never be a zero-trust based on digital identity scenarios.

So how than can zero-trust provide any assurances that only authorised people and no other unauthorised person will? Zero-trust must trust the authorised human in an ironic twist of inherent conflicting design implementations; zero-trust uses identities and therefore assumes you have at some point previously authorised the person using that identity - trusting your one-time authentication for all future zero-trust actions using htat identity.

Can anything identity-based assure protection form  unauthorised humans?

Short answer, no.

Why? Let's look at the 2 most common identity-based systems; M/TLS and auto-segmentation.

Mutual TLS

There is no RFC for Mutual TLS.

I have had people tell me that rfc8705 defines M/TLS, but each person who said this must have simply done an internet search and saw Mutual-TLS in its very long title;

rfc8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

But not actually read anything beyond the title..

To quote the description of the rfc; OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS. This is plain and clear this OAuth 2.0 rfc simply happens to implement M/TLS for its Access Tokens because they are Certificate-Bound and they needed support for both self-signed and PKI.

Notably, rfc8705 is a proposed standard and Mutual TLS has been around a lot longer than February 2020 when rfc8705 was proposed.
The actual Mutual TLS rfc was none other than the rfc2246 for TLS 1.0 January 1999, and slightly improved in rfc5246 August 2008 for TLS 1.2 when the condition for Diffie-Hellman of TLS 1.0 no longer made sense in TLS 1.2 due to the supported cipher suites.
As you see, Mutual TLS has existed for more than 2 decades even if the name itself only started being used by zero-trust marketing slogans more recently.

The reason Mutual TLS is often associated to zero-trust is simply because both the client and server identities are certificate based, the transport layer handshake requires an authentication based on the validity of these certificates. In normal TLS the client will establish a connection only after it validates the server provided certificate which assures the client that the server identity is true based on a signing process done by the Certificate Authority (CA), ergo there was a one-time authentication the server performed to obtain the certificate. To establish a M/TLS connection the normal TLS connection is first established, then a mutual process is then required by the server to validate the client certificate in the same way the client validated the server. Ergo, each peer validates the identity mutually to then start transmitting data using TLS.

Key nuance to fully understand here;

• The server assumes the client has at some point previously performed a one-time authentication to obtain the certificate
• The server does not know if the original client has the certificate with the current client
• The client assumes the server has at some point previously performed a one-time authentication to obtain the certificate
• The client does not know if the original server has the certificate with the current server, unless the SNI extension is added and utilised correctly
• These mutually validated certificates provide authentication in the TLS handshake, they are unaware of the actually data being transmitted after M/TLS is established

During M/TLS data transmission, validated certificates provide a digital identity that may be used for authorisation purposes only. M/TLS does not confirm any authentication has occurred at the time of transport, the only authentication that occurred was one-time for the server when obtaining a server certificate and one-time for the client when obtaining the client certificate.

For authentication to occur during data transmission you can implement OAuth, HMAC, or some other additional process that provides authentication.
Without authentication per data transport, you "trust" it was done by this client at some prior point because you are not performing any verification of your own apart from this client having possession of the certificate. With SNI used the client is at-least verifying the server identity is associated with the domain name they expected but there is equally no challenge therefore without any challenges on this data transport context there is no authentication.

The clear take away here is authentication requires a challenge, and one-time prior authentication and a resultant identity is significantly different to authentication performed in the context of each data access or transport - due to inherent trust without verification.

Network Microsegmentation

There are 4 types of identities used in network segmentation implementations;

1. machine-based
Similar to software licenses often being bound to unique hardware identifiers, identities used in network segmentation are often representing the lowest level operating system when there are virtual hosts or containers being used.
Common use case for this is network segmentation to assure data confidentiality in a multi-tenant environment where dedicated network infrastructure is infeasible or uneconomic.

2. host-based
When there are virtual network interfaces, visualised operating system guests, or containers being used the identity is typically generated by the host to uniquely differentiate the guests.
In most cases, but not all, the host shares the unique identifier with guests.
Even when a guest is self-aware the guest's unique identifier may not be unique on the network due to conflicts that may arise when other hosts generate matching guest identifiers. This is common in container environments like Kubernetes because the guest identifiers cannot be unique as they are not reproducible using the hardware based identifiers as the seed to the resultant cryptographicly verifiable hash. For Kubernetes the cluster generates the guest identifier using a pseudo-random seed regardless of the host.
This means the identifier is unique only to the cluster, not unique to the network (which often only consists of the Kubernetes cluster, but not limited to)

3 application based (microsegmentation)
Very similar to the above scenario, there is a private certificate authority or public key infrastructure (PKI) that issue certificates to clients given the client provided unique identifier. Clients generally request their unique identifier from the host but in some environments like virtual machine guests and Kubernetes. But they often move to a pseudo-random value instead if they encounter any conflicts, sometimes even starting with this pseudo-random value if the administrator has encountered conflicts in their personal past experiences.
This is going to generate an identity for your application, but like the host-based approach it generally cannot be assumed it is a identity that remains unique to the network. It is possible, but we cannot assume it is fact.

4. account based
The least common method in context to network segmentation, but it is becoming more common in cloud native architectures.
The way this works is where a cloud service provider can assure each account is sufficiently segregated and you register multiple accounts and while you control each account you actually treat them as strong segregation control in workload architectures.
Commonly you have an account separate from workloads for audit logs, identity, and other highly sensitive purposes. You may also use multiple accounts to segregate each SDLC environment, i.e. production and any other non-production named account that will never need to be connected to production. Warning: these are semantically names only, do not think for a moment that your developer environment is exempt from the same security controls as production - they are both an account in a public cloud and you simply decided to semantically name them differently but that name does not change the risk in any way.

In the context of zero-trust and it's common referred to by network segmentation implementations, all 4 cases;

- uses identities for peers, but only some implementations will be sufficiently unique
- none are representation of an individual person
- none implement an authentication challenge per data access or transport
- all authentication is done one-time in the past
- the peers are always assumed/trusted to be previously authenticated
- identity is trusted to be that of the identity it represents, and not shared/copied/exposed

Conclusion

Zero-trust security means that no one is trusted by default from inside or outside the network, and verification is required from everyone trying to gain access to resources on the network. Each scenario is identity-based, and with that there is inherent trust and zero-challenges with assumed verification outside the data exchange.

We began this post stating zero-trust cannot exist, but the reality is much worse. All current implementations using only the identity do not even limit data access or decrease trust over any other system that uses actual authentication processes per data access and transmission.

But that's OK

Because we have a massive number of great authentication options, some that are session-based (app logins/time-based tokens), some that rely on pre-shared out-of-band secrets (OAuth/HMAC) that must be used per data access, and some that actually occur anytime data is accessed and expire the moment that access has ceased (database connections). The leading method for zero-trust (excluding micro-segmentation and M/TLS) is Multi-factor authentication (MFA) for the user performing actions (and we know the trust this requires from above), void of a person operator where we are in context of machine-to-machine there cannot be a MFA process, there must be some other machine friendly authentication method based on a secret which requires trust in how that machine obtains and stores the secret.

Our existing methods of authentication are already better security options for data access than zero-trust, network segmentation, and Mutual TLS can ever provide. Each has it's own use case, and offer a defence-in-depth layer critically important to use with authentication for data access. But do not be fooled that zero-trust exists or that anything identity-based can actually provide safe data access, safer than public, but less safe than real authentication provides.