Summary

  • RFC 9645 creates reusable YANG groupings for TLS client identity, server identity, peer authentication, hello parameters and keepalive policy. It explicitly models a least-common-denominator configuration, not a complete session record.
  • A configured certificate, raw public key or PSK branch proves that an operator authorised a possibility. It does not prove whether the peer requested it, which credential was presented, whether the session resumed, which validation path succeeded, or what principal the application accepted.
  • A defensible authentication-path receipt must join module and configuration revision to the actual handshake branch, peer identity, validation result, optional client authentication, application principal and operation outcome. Missing observations must narrow the claim.

The audit returned a menu

Suppose a privileged service is reviewed after an unexpected change. The configuration database shows a valid RFC 9645 structure. The server has an X.509 identity. Its client-authentication container also permits certificate and raw-public-key validation. An external PSK is provisioned for emergency access. The TLS library reports support for the configured versions and ciphers.

The reviewer asks a simple question: which identity path protected the connection that changed the service?

The evidence packet answers with a menu. It proves what could have happened. It does not prove what did.

That gap is not a shortcoming in RFC 9645. The document defines ietf-tls-common, ietf-tls-client and ietf-tls-server, together with an IANA-maintained cipher-suite enumeration module. Its client and server groupings are designed for reuse by application models and intentionally exclude the underlying address and port strategy. The specification calls the generic models a least common denominator rather than a complete description of every TLS feature.

This is precisely why the model is useful: it does not pretend to own decisions that belong to the consuming protocol or implementation. Trouble begins when an organisation turns that deliberate boundary into a compliance shortcut.

Four identity branches are four different claims

RFC 9645's client identity and server identity choices cover certificates, raw public keys, TLS 1.2 PSKs and TLS 1.3 external PSKs. These are not interchangeable encodings of one fact.

A certificate branch can carry a chain and names whose acceptance depends on trust anchors, time, key usage, signature algorithms, reference identity and local policy. A raw-public-key branch removes certificate-chain semantics and normally rests on an exact trusted key relationship. A TLS 1.2 PSK combines a shared secret with the identity conventions of the earlier protocol. A TLS 1.3 external PSK adds an external identity, a hash and optional context or target parameters; RFC 9257 and RFC 9258 make clear that context and endpoint assignment matter, while group-shared keys can blur individual accountability.

The YANG choice proves that the configuration selected one identity form for an endpoint. It does not establish that the other endpoint offered or accepted the matching form during a particular exchange. Nor does it prove which concrete key or certificate bytes the TLS stack loaded at that instant.

The first rule of a useful receipt is therefore simple: record the authentication branch. A generic green field labelled “TLS identity configured” destroys information before the investigation even starts.

Server authentication and client authentication do not collapse into “mTLS”

The client grouping separates client-identity from server-authentication. The former is optional because client authentication may occur above TLS. Even when a client identity is configured, RFC 9645 says it is presented when the server requests it during session establishment.

The server grouping makes the other half equally explicit. server-identity is one decision. The optional client-authentication presence container is another. If that container is absent, the server should not request client credentials. If it is present, its CA certificates, exact end-entity certificates, raw keys and PSK mechanisms are additive possibilities for authenticating clients.

This structure defeats a common dashboard fiction. “Mutual TLS enabled” may mean the server was capable of requesting a client certificate. It may mean policy was present but the observed connection used a different listener. It may mean a resumed session relied on previously established state. It may mean TLS authenticated a device while the application later mapped it to a shared or unknown principal. None of those facts can be recovered from the phrase itself.

The receipt needs separate fields for whether client authentication was requested, what the client presented, how the server validated it, and which application principal resulted. Capability, request, presentation, validation and authorisation are five events, not one setting.

A resumed session carries a different proof burden

TLS 1.3 makes the distinction sharper. A full certificate-authenticated handshake and a PSK-based resumption handshake do not produce the same visible evidence. The current TLS 1.3 specification, RFC 9846, keeps version negotiation, signature algorithms, groups, key shares and PSK identities as distinct handshake inputs. A server selects a compatible PSK and cipher suite and verifies a binder that ties the selected PSK to the current transcript.

That binding matters, but it does not mean the current connection repeated the original certificate validation. During resumption the session may inherit security context from an earlier connection. A report that sees only “TLS succeeded” and displays the configured certificate can falsely imply that this certificate was presented and checked again.

External PSKs require another distinction. Their identifiers can be observable and linkable. A group PSK can authenticate membership in a set without proving which member acted. An imported PSK with context can bind the external provisioning process more tightly to the connection; a context-free PSK cannot support the same claim. The receipt must therefore identify the class of PSK and its context status without exposing the secret.

Early data raises the stakes again. Application bytes may be sent before the handshake has reached the same confirmation point as ordinary one-RTT traffic. A receipt that records only final session success can conceal that the consequential request occupied a different replay and authorisation boundary.

Version and cipher are not the identity verdict

RFC 9645's common grouping can configure TLS version bounds and a user-ordered cipher-suite list. Its optional supported-algorithm state describes implementation capability. These controls are important, but they answer different questions from peer identity.

The IANA TLS registry itself warns that algorithms weaken over time and that expert registration is not endorsement. It also distinguishes TLS 1.3 cipher-suite semantics from those of TLS 1.2 and earlier. RFC 9325 supplies deployment recommendations, while RFC 9852 now requires TLS 1.3 support for new protocols using TLS under its stated scope. The policy surrounding a stable identifier can therefore change while the identifier remains representable.

The live receipt should record negotiated version and cipher suite because they define the cryptographic channel. It must not use them as substitutes for the identity branch, the presented peer material or the validation outcome. “TLS 1.3 with an approved cipher” does not answer whether the peer was authenticated by certificate, raw key, external PSK or resumption state.

Configuration is a mandate to attempt

RFC 8342's distinction between intended configuration and operational state supplies a clean way to think about this. An approved configuration is an attributable mandate: the system is instructed to attempt connections within a defined possibility space. RFC 8341 helps restrict who may alter sensitive configuration. RFC 9641 and RFC 9642 let RFC 9645 reuse truststore and keystore material.

Each layer is valuable. None supplies the event result of the next layer.

A keystore reference can resolve successfully while the handshake selects another credential. A truststore bag can be available while a peer presents no certificate. Intended configuration can become applied state while the targeted listener is never reached. A handshake can authenticate a key while the application maps it to no authorised account. An authorised principal can still receive an application error.

Heng Lu's distinction between symbolic authority and running reality is practical here. The model has authority over vocabulary. Change control has authority over intent. The TLS stack executes a branch. The application assigns operational meaning. A credible assurance system preserves those boundaries instead of allowing the earliest green check to speak for everything downstream.

The minimum authentication-path receipt

No cited RFC mandates a unified receipt. The following is an operational design derived from the boundaries they expose:

  • RFC and YANG module revision, implemented features, deviations and consuming application model;
  • applied configuration revision, datastore origin, approving actor and activation time;
  • chosen endpoint identity branch and exact keystore or truststore references;
  • protected fingerprints or version identifiers for the credential and trust material actually loaded;
  • a session correlation identifier and reliable timestamps;
  • negotiated TLS version and cipher suite, kept separate from identity mode;
  • full, resumed or early-data path, including whether the PSK was external, imported with context, or derived from resumption;
  • peer-requested authentication, the identity actually presented and the validation method and result;
  • for client authentication, the request, client response, server validation and resulting application principal;
  • handshake completion, alerts and retry or fallback history;
  • application authorisation, operation, acceptance condition and outcome;
  • explicit unknown fields when an observation is unavailable.

The minimum supported sentence can now be precise: for this named session and operation, under this applied configuration, the endpoint used this authentication branch, validated this peer identity under this policy, mapped it to this principal, and produced this result.

Anything shorter may still be useful, but it must be labelled accordingly. If the branch is unknown, say only that the policy allowed several branches. If validation evidence is missing, do not claim peer identity. If the application result is absent, do not claim service delivery.

Sources

  1. Minimum initial specification
  2. Reality layers and symbolic power
  3. Running-code primacy
  4. RFC 9645 document history
  5. RFC 9645 information page
  6. RFC 9645 HTML
  7. RFC 9645 plain text
  8. RFC 9645 XML
  9. RFC 9645 inline errata
  10. IANA TLS parameters
  11. IANA TLS cipher-suite YANG module
  12. RFC 9641: truststore model
  13. RFC 9642: keystore model
  14. RFC 9846: current TLS 1.3
  15. RFC 9852: TLS 1.3 for new protocols
  16. RFC 9325: secure TLS deployment
  17. RFC 9257: external PSK guidance
  18. RFC 9258: importing external PSKs
  19. RFC 8341: network configuration access control
  20. RFC 8342: network management datastore architecture