Summary

  • RFC 3631's durable lesson is architectural: a named security mechanism has no complete meaning until it is bound to a threat model, protection layer, identity and trust policy, key lifecycle, message coverage and application decision.
  • Mandatory-to-implement creates a common interoperable option. It does not prove that the option was enabled, negotiated, validated correctly or used for the action under review.
  • A defensible security claim needs a joined receipt from configuration and negotiation through peer validation, protected bytes, authorization and observed result. A green handshake is one record in that chain.

The mechanism was real; the promotion was not

Start with a narrow claim: two endpoints completed a cryptographic handshake. That can be valuable evidence. It may identify a protocol version, cipher suite, key-exchange mode, certificate path and transcript. It may show that later records were encrypted and integrity-protected under keys derived from that exchange.

The error begins when the claim is promoted without intermediate records. “Handshake complete” becomes “the right service”; “valid certificate” becomes “authorized institution”; “authenticated channel” becomes “authenticated user”; “protected request” becomes “permitted action”; and “server accepted bytes” becomes “business operation completed.” Each promotion crosses a different authority boundary.

RFC 3631, published by the Internet Architecture Board in December 2003, warned against precisely this style of substitution. It is an Informational document, not an Internet Standard and not a current algorithm profile. Its algorithm examples belong to their period. Its more durable contribution is a design method: choose a mechanism from the threat and the protected object, then account for granularity, implementation layer, trust, deployment and failure modes.

The RFC Editor record and IETF Datatracker preserve that status. The document history is evidence about publication, not adoption. The errata search is a maintenance record, not a certification of any implementation.

The threat model comes before the shopping list

RFC 3631 begins its decision factors with the threat model: who may attack which resource, by what means and in what location. That ordering matters. A control catalogue that starts with products can produce impressive coverage against the wrong adversary. A backbone monitoring station and a word-processing host can run the same software while presenting radically different leverage to an attacker.

RFC 3552, the IETF's companion guidance for Security Considerations, makes the same structure explicit. A threat model identifies assumed attacker capabilities and the threats deliberately left outside the design. It warns application designers not to assume that all attackers are off path and asks limited-domain protocols to consider what happens when deployment escapes the original boundary.

The practical record therefore begins before a cipher is chosen. It names the asset, action and consequence; on-path, off-path, insider and compromised-endpoint capabilities; accepted exclusions; required confidentiality, integrity, authentication, replay resistance, availability and authorization properties; and the time for which each property must survive. “Strong encryption” is not a threat model because it does not state what is being defended from whom.

An implementation obligation is not an operating fact

RFC 3631 explains why the IETF uses mandatory-to-implement mechanisms. If two products support disjoint options, they may be individually rich and mutually unusable. A shared required option establishes an interoperability floor.

That floor has a carefully limited subject: implementations. It does not compel an operator to enable the option, make it the default or keep an obsolete algorithm active. RFC 3365, published as BCP 61, draws the same line while insisting that IETF protocols provide appropriate strong security. Confidentiality is not always the only required service, and implementation does not equal use.

For an audit, four states must not collapse into one: the code contains a capability; configuration permits it; the peers selected it; and the inspected exchange actually used it. A fifth state asks whether its parameters met the policy in force at that moment. A product data sheet can establish none of the last four.

This distinction also protects retirement. A once-mandatory algorithm may remain in code for interoperability while policy disables it. Conformance evidence and exposure evidence can legitimately point in opposite directions. Leadership needs both rather than a single badge marked “supports security.”

Layer and granularity decide what the green light covers

RFC 3631 compares protection at different layers. A lower-layer mechanism can cover many upper-layer protocols without modifying each application, but it usually knows less about application principals and intent. A signed object can retain origin and integrity evidence through storage and forwarding, but it protects that object rather than every exchange around it. A gateway can protect traffic between networks while leaving activity inside either network outside the tunnel's assertion.

This is not a contest for the universally best layer. It is a demand to name the boundary. A link encryptor says something about one link. An IPsec tunnel says something about selected IP traffic between security-association endpoints. TLS says something about a transport channel and its authenticated peers under an application profile. An object signature says something about bytes, a key and a validation context that may survive delivery.

The record must identify the protected unit—link, packet class, host, gateway, transport connection, application principal, message or durable object—and the unprotected gaps. Otherwise a broad mechanism name encourages a broad claim that its own specification never made.

One authenticated moment does not cover the rest of the session

RFC 3631 uses HMAC to expose a temporal boundary. A shared-secret challenge can authenticate an exchange and resist replay when used properly. But authenticating only the beginning of a TCP connection and leaving later protocol units unprotected permits the session to be stolen after the check.

The lesson is larger than that period's example. Security evidence needs a coverage map. Which request fields entered the MAC or signature? Were headers, method, destination, nonce and body bound together? Did every state-changing message carry integrity protection? Could a protected envelope contain an unbound instruction? Did retransmission or reconnection create a fresh authorization context?

A verifier can correctly report “MAC valid” while the application incorrectly concludes “operation authorized.” The first statement concerns bytes and a key. The second needs a principal, scope, policy version, freshness rule and resource decision. The receipt must preserve both statements and the rule that joined them.

Framework names defer the decisive question

RFC 3631 says that SASL has the properties of the mechanism actually negotiated. It gives GSS-API the same treatment: the framework carries opaque tokens, but the underlying mechanism must be assessed independently. This is governance hidden inside protocol composition. A framework expands choice; it cannot make every choice equivalent.

Record the offered set, selected mechanism, negotiation transcript, channel binding, fallback behavior and effective security properties. If the selection is weaker than policy, the failure belongs at the negotiation boundary even when both endpoints behaved according to the framework grammar.

Modern TLS makes the point in a more familiar form. RFC 8446 defines TLS 1.3 as application-protocol independent. It provides a handshake and record layer, but the higher-level protocol defines how TLS begins and what the authenticated peer is allowed to do. Version, cipher suite, certificate use, ALPN, resumption and 0-RTT state are not decorative fields. They change the resulting claim; 0-RTT, for example, carries replay constraints that an application must understand.

A certificate path does not choose the intended endpoint

RFC 3631's TLS discussion was written in an era when warning dialogs commonly allowed users to continue after authentication failures. The dated interface detail illustrates a current principle: cryptography cannot rescue a validation decision that the application bypasses.

RFC 9325, today's BCP 195 recommendations, sharpens the endpoint boundary. Hostname validation is security-critical in ordinary authenticated TLS. A certificate can be valid and the peer can prove possession of its private key while the connection still does not terminate at the desired endpoint.

The useful receipt records the reference identity the application intended, the names in the credential, the matching rule, trust anchors, validation time, status inputs, policy exceptions and final endpoint decision. It separately records the application or user principal. Server authentication does not automatically authenticate a client, and client authentication does not automatically authorize an operation.

Certificate graphs add another allocation of authority. RFC 3631 contrasts hierarchical roots with a web of trust, but both require a reliable starting point and reliable relevant links. Signature validity answers whether a key signed the bytes. Trust policy answers why that key's statement is accepted for this purpose. Those decisions should never be merged into a bare “signature valid” field.

Key management is part of the mechanism, not housekeeping

The algorithm can be sound while the keys make the system indefensible. RFC 4107, BCP 107, distinguishes automated and manual key management. Automated systems can confirm liveness, establish fresh keys and support rekeying at scale. Manual keying can be reasonable only in bounded conditions and still needs identifiers, transitions, replacement and compromise handling.

A complete operating claim therefore names key origin, generation method, storage boundary, peer binding, creation time, allowed use, rotation, retirement and compromise state. “Encrypted” without this record leaves unanswered whether a long-lived secret was copied across many endpoints, whether a revoked peer retained access, or whether a resumed session preserved a property expected only from a fresh handshake.

Current TLS guidance extends the lifecycle to session-ticket keys and forward secrecy. Key material can be fresh for one exchange while an old ticket-encryption key or reused secret changes the historical exposure. The control surface is not the cipher-suite label alone.

IPsec presence does not identify the packet's branch

RFC 3631 described IPsec as broad network-layer protection and warned that host or gateway granularity might be too coarse for application identity. RFC 4301 gives the later architecture a precise operating model. Security services depend on the selected protocol, mode, Security Association endpoints, keys and policy. Traffic is classified by policy and can be protected, discarded or bypassed.

That produces a simple audit question: which branch did this packet take? A healthy tunnel proves that a Security Association exists and may prove traffic crossed it. It does not prove that the disputed packet matched the protect rule rather than a bypass rule, that the inner application principal was authorized, or that the destination processed the request.

Preserve policy-database version, selectors, SA identifiers, counters, packet or flow correlation, peer validation and the inner application's decision. Gateway identity and user identity remain separate even when one network diagram draws them inside the same green tunnel.

Topology is a security assumption with an expiry date

RFC 3631 calls a firewall a topological defence. It depends on a meaningful inside/outside boundary and cannot by itself stop an inside attacker. Tunnels, wireless links, alternate connections and exposed endpoints can change the boundary without changing the firewall's status light.

Address- and name-based authentication have a similar hidden dependency. Routing, DHCP, spoofing, proxies and DNS can alter what an address or name observation means. DNSSEC can protect signed DNS data against modification; it cannot manufacture truth for an incorrect underlying assertion or turn a hostname into application authorization.

The operating record must therefore version topology and trust assumptions. It should include alternate paths, tunnels, cloud edges, administrative domains and exception rules. A firewall rule reviewed last quarter may be syntactically unchanged and semantically obsolete because the route around it changed.

Endpoint compromise is the boundary a handshake cannot cross

RFC 3631 ends with a deliberately unglamorous limit: no network security mechanism is perfect, and endpoint compromise can defeat it. Encryption protects data in transit; it does not ensure that the sender created honest input or that the receiver handles plaintext safely. A valid signature can preserve an attacker-controlled object's provenance perfectly.

This is where the framework in Lu Heng's Reality Layers and Running Code Primary becomes operational. The formal mechanism, negotiated state, validation result, application decision and observed effect are related records, not synonyms. Minimum Initial Specification argues for a common minimum without centralizing future choice; a security receipt should similarly make evidence portable without letting the transport mechanism seize application authority. Authority and Belief supplies the final discipline: every trusted assertion has an issuer, scope and limit.

A security claim needs a joined receipt

For each consequential action, preserve the resource and threat model; required properties; implementation and build; policy and configuration; offered and negotiated parameters; peer reference identity, credentials, trust anchors and validation result; key origin and lifecycle; exact protected packets, records or objects; application principal and authorization rule; resulting permit or reject; and the data-plane or business observation.

Keep negative paths as first-class evidence: alert, downgrade, fallback, bypass, replay rejection, expired credential, missing name match, truncation, policy exception and compromised-key response. A dashboard that stores only successful sessions cannot demonstrate that the refusal path worked.

RFC 3631's mechanism catalogue has aged. Its warning has not. Security is not a substance sprinkled over a finished protocol. It is a chain of bounded decisions. The handshake can be entirely valid while the claim made from it remains false.

Sources

  1. RFC 3631 — Security Mechanisms for the Internet
  2. RFC 3631 plain text
  3. RFC Editor information for RFC 3631
  4. IETF Datatracker record for RFC 3631
  5. IETF history for RFC 3631
  6. RFC 3631 errata search
  7. RFC 2316 — Report of the IAB Security Architecture Workshop
  8. RFC 3365 — Strong Security Requirements for IETF Standard Protocols
  9. RFC 3552 — Guidelines for Writing RFC Text on Security Considerations
  10. RFC 4107 — Guidelines for Cryptographic Key Management
  11. RFC 4301 — Security Architecture for the Internet Protocol
  12. RFC 8446 — The Transport Layer Security Protocol Version 1.3
  13. RFC 9325 — Recommendations for Secure Use of TLS and DTLS
  14. Lu Heng — Running Code Primary
  15. Lu Heng — Minimum Initial Specification
  16. Lu Heng — On Reality Layers
  17. Lu Heng — On Authority and Belief