On Sun, May 18, 2025, 22:32 William Herrin <bill@herrin.us> wrote:
On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
See RFC 4949, "authenticate" definition
Hi Brent,
From RRFC 4949: "authenticate: Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource."
In a letsencrypt certificate, the attribute whose truth is to be established is an encryption key associated with one or more FQDNs. Anything placing additional limits on that context is authorization.
Where, precisely, is this public key associated with FQDNs in SMTP? What are you verifying the CN/SANs against?
second and third deprecations.
Which basically state that Internet Drafts (and hence RFCs) should use a couple more precise terms (verify and validate) when talking about specific steps of the authentication process. They're "should," not "must" but even if you read them as "must," they in no way change the meaning of "authenticate."
How about the next entry, "authentication": "(I) The process of verifying a claim that a system entity or system resource has a certain attribute value." What "system entity" or "system resource" are you authenticating against in pure, straightforward TLS? CAs only provide trust and integrity of presented identity attributea, they don't store, manage, or otherwise control that identity. The Thawte intermediate keypairs have no clue what an "example.com" is, they just can provide evidence that was part of data that they signed. This is why "verification/validation" is preferred over "authentication" when *just* TLS is concerned - because "authentication" does not fit.
5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication.
I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified.
I'll side with IETF on this, thanks.
I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument.
Cryptographic exchange is not AAA. It can be used WITH AAA by *reusing the TLS identity within the service*, but it's not AAA - TLS is not a service itself, just as e.g. SCTP isn't a service. TLS is a specified transport layer providing encryption with multiple facilities ensuring that *communication* with the remote end can be trusted. Data hasn't even *hit the actual service yet*. All current RFC specifies AAA in conjunction with system resources/system entities, which have their own RFC-defined meanings, if you'd like to go down that route, but there's a reason "authenticate" was deprecated in favor of "verify" when certificates are confirmed against a trust chain.