On Sun, May 18, 2025, 10:27 William Herrin <b...@herrin.us> wrote:
> On Sun, May 18, 2025 at 8:02 AM brent saner via NANOG
> <nanog@lists.nanog.org> wrote:
> >Transports in SMTP do not authenticate, they identify (if at all).
>
> Hi Brent,
>
> I'm unclear what distinction you're drawing between "identify" and
> "authenticate." "I am who I say I am," is the sum total of
> authentication. Everything beyond that gets into authorization.
>
I'd argue against that. "You *know me* as FOO and here is proof" is
authentication. Identity verification is only half of authentication ("here
is proof"), the other half is a mapping of entity/identity from that ("you
*know me* as"). (And then *what that entity* has access to (and how, etc.)
is authorization. I think we can all agree on that.)
I can use the same username, DN, whatever across multiple services but
unless that service has knowledge of that identity, I'm not going far.
This is why all EAP-TLS is TLS but not all TLS is EAP-TLS. Take a stab at
what the "A" in "EAP" is (RFC 3748).
Or why TLS-PSK is a thing (RFC 4279). There's not even a cert involved in
that- not even a public key since it's symmetric.
This is because the purpose of *TLS*, specifically, is encryption. Its
purpose is to protect data, not authenticate to a service. mTLS is closer
to an extension of TLS handshaking; it's just an additional verification
that the other end's *encryption context* is verified (signed by a trusted
source) and *valid* (not in expiry/is after allowed usage date/time, etc.)
Which is why it's "*mutual* TLS" and not EAP.
All mTLS auth is mTLS. Not all mTLS is mTLS auth.
The verified identity may then be FURTHER used for mapping to an internal
context. It is at *this point*, which MTAs do not do, that it becomes
authentication ("it identifies as being in this/these OUs/groups", "it
belongs to this ORG", etc.). The validity *establishes* the trust that
"yep, I saw these claims at the time of creation." The issuer provides no
verification *of those claims*, just that they were *made*.
This is *also* why id-kp-(server|client)Auth EKUs exist in the first place.
Per 4.2.1.12 of RFC 5280, these *specifically* are bits that are *only* and
*optionally* valid for *service-defined behavior*, and not tied to the
actual verification of the issuance nor the issuance itself.
Trust is not the entirety of authentication. It is erroneous to understand
it as such.
> Which now that I think about it sounds a lot like there's a layer
> violation in giving TLS certificates a "for this purpose" tag at all.
> I knew there was a reason I didn't like it but I was having trouble
> putting my finger on it.
>
They were established for cryptographic contexts in which there is a clear
service (web, specifically) with a defined provider and consumer (or
"server" and "client").
>
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HPBNJVPJMAFOFSW4LA24432ELFG3YE7Z/
