Summary

  • RFC 9644 gives operators a common YANG vocabulary for SSH algorithm capability and ordered policy; it does not define a per-session record of the algorithms actually negotiated.
  • A defensible claim must link registry and model revision, implementation capability, approved configuration, both peers' live offers, directional selections, host identity, NEWKEYS, authentication and the application result.
  • The proposed receipt is an operating control, not an RFC requirement: where an observation is unavailable, the conclusion must narrow rather than being filled by assumption.

The green diff stops too early

Imagine the change review after an SSH hardening exercise. The team can produce an IANA name, a generated YANG enumeration, a capability readout and a signed configuration change. All four may be accurate. The unanswered question is the one leadership thought it had commissioned: what protected the session that mattered?

The gap is not a defect in RFC 9644. The document defines reusable ietf-ssh-common, ietf-ssh-client and ietf-ssh-server groupings, together with generated modules for IANA-maintained algorithm enumerations. It creates a consistent way to express policy across implementations. It does not promise to be a session recorder, a peer-identity verdict or an application monitor.

That distinction matters because four statements that sound similar carry different evidential weight:

  1. an algorithm name exists in an IANA registry;
  2. an implementation reports that it supports the algorithm;
  3. a configuration permits the algorithm in a particular order;
  4. a particular connection negotiated the algorithm.

The first is vocabulary. The second is capability. The third is intent. Only the fourth is an event, and even it is not proof that the intended peer was authenticated or that the intended operation completed.

A registry is an address book, not an endorsement

RFC 9644 includes a mechanism for generating four YANG enumeration modules from IANA's SSH registries. When the source registries change, the generated modules gain a revision and represent the corresponding names and statuses. Unassigned and reserved values are omitted. This arrangement reduces drift between the public registry and what a YANG client can encode.

It does not turn registration into a security recommendation. IANA registries contain current, historical and differently classified entries. Requirement levels can change, as RFC 9142 demonstrates for key-exchange methods, while a registered identifier remains recognisable. A control system therefore needs to retain both the source registry snapshot and the policy decision that allowed or rejected a value. “Registered” and “approved here, now” are not synonyms.

The generated-module revision is equally important. Without it, an audit can prove that a list of names was accepted but not which public vocabulary the implementation and controller believed they shared. The first link in the receipt should therefore identify the IANA snapshot, the generated module revision or digest, and any implementation deviations that affect the exposed schema.

Support is not permission

RFC 9644's optional algorithm-discovery feature exposes supported-algorithms as operational, config false data. This is valuable inventory. It can reveal whether a device says it is capable of using a candidate key-exchange, host-key, encryption or MAC algorithm.

Capability does not establish permission. An implementation may support an algorithm that the organisation forbids. Nor does capability establish use. It may be absent from the configured list, lose to a more preferred common value, or never meet a compatible peer. The capability observation also needs a time and implementation identity: software upgrades, build options and feature declarations can change it.

The inverse case is dangerous too. RFC 9644 permits an algorithm list to be absent or empty, in which case the acceptable set is implementation-defined. An empty list cannot safely be rendered as a universal default. The receipt must either capture the implementation's effective behaviour or say that the permitted set could not be determined.

Ordered policy is only one side of the exchange

The transport-params-grouping holds ordered lists for key exchange, host keys, encryption and MACs. Their order carries intent: preference is not decoration. A policy receipt should preserve the exact ordered values, the configuration revision, the actor who approved it and the device that accepted it. Sorting the list for reporting would destroy information.

Yet an SSH choice is made with a peer. Under RFC 4253, each side sends SSH_MSG_KEXINIT name-lists. The selection follows client preference among values the server also offers, subject to the key-exchange method's host-key requirements. Encryption and MACs are selected separately for client-to-server and server-to-client traffic. A single undirected field such as “cipher: approved” discards part of the protocol result.

This creates a hard evidence boundary. A configuration system knows what it intended to permit. It normally does not know the other peer's live offer. A session observer or the SSH implementation must supply that event evidence. If no acceptable intersection exists, the connection terminates; acceptance of the configuration did not make an operational session inevitable.

The host-key field does not settle identity

Algorithm negotiation and peer identity are related but not interchangeable. A negotiated host-key algorithm describes a procedure. The receipt must still identify the host key actually presented and the validation decision applied to it. RFC 8332 sharpens this point: an RSA public-key format can participate in more than one RSA signature algorithm. “An RSA key existed” does not tell an auditor whether rsa-sha2-256 or rsa-sha2-512 was used.

RFC 9644 separately models client identity and server-authentication parameters, including references to keystore and truststore material. That separation is operationally honest. A server may offer an allowed host-key algorithm yet present an unexpected key. A known host key may be used under an algorithm the policy did not intend. A successful host check still says nothing about whether the client later authenticated or was authorised to perform the application operation.

The receipt should therefore carry the host-key fingerprint, validation basis and result without confusing those fields with the algorithm name. It should also record uncertainty. If a monitoring point can observe negotiation but not the trust decision inside the client, it may report the former and must leave the latter unresolved.

NEWKEYS is a boundary, not a decoration

RFC 4253's SSH_MSG_NEWKEYS activates the newly computed keys and algorithms. A trace that ends at two compatible KEXINIT offers has not proved that the cryptographic transition completed. Conversely, a transport that reaches NEWKEYS has not proved user authentication: RFC 4252 places that next decision above the transport layer.

This is why a useful receipt is a chain rather than a badge:

  • registry snapshot and generated YANG module revision;
  • implementation, feature and deviation set;
  • time-stamped capability observation;
  • exact ordered configuration and approval identity;
  • protected hashes or captures of both KEXINIT offers;
  • negotiated key-exchange, host-key, encryption and MAC values, retaining direction;
  • presented host-key fingerprint and validation decision;
  • evidence that NEWKEYS completed;
  • client-authentication method and result, without exposing credentials;
  • application operation, acceptance criterion and result.

No cited RFC mandates this unified record. It is an operating design derived from the boundaries among configuration, protocol and service. That qualification prevents the control from borrowing authority it does not have.

The minimum claim should survive missing evidence

Heng Lu's minimum-initial-specification principle is useful here because it forces the organisation to decide which sentence it must be able to support before building an elaborate control plane. A reasonable minimum is not “the device is secure.” It is narrower: for a named operation and time window, the organisation can link the approved policy to the session's observed choices, the validated peer and the operation's outcome.

Running-code primacy supplies the ordering. The registry and YANG model define a symbolic layer shared by controllers and devices. The actual exchange constrains that symbolism. If the two disagree, the operational observation governs the claim about what happened, while the disagreement becomes an incident to investigate.

This also explains why the receipt must be explicit about gaps. If only configuration evidence exists, the defensible statement is “the policy was accepted.” If KEXINIT and NEWKEYS are observed but host validation is not, the statement can cover algorithm activation but not peer identity. If transport and identity are proven but the application result is absent, service delivery remains unproven.

Sources

  1. Minimum initial specification
  2. Reality layers and symbolic power
  3. Running-code primacy
  4. RFC 9644 datatracker record
  5. RFC 9644 information page
  6. RFC 9644 HTML
  7. RFC 9644 plain text
  8. RFC 9644 XML
  9. RFC 9644 inline errata
  10. IANA Secure Shell protocol parameters
  11. IANA YANG parameters
  12. RFC 4250: SSH protocol assigned numbers
  13. RFC 4252: SSH authentication protocol
  14. RFC 4253: SSH transport layer protocol
  15. RFC 6187: X.509v3 certificates for SSH
  16. RFC 8332: RSA keys with SHA-2 signatures
  17. RFC 9142: SSH key-exchange method updates
  18. RFC 7950: YANG 1.1
  19. RFC 8341: network configuration access control
  20. RFC 8342: network management datastore architecture