On Sun, May 18, 2025, 10:27 William Herrin <bill@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").