Summary

  • RFC 5197 compares seven MIKEY key-distribution approaches because “MIKEY is in use” does not say whether a session has perfect forward secrecy, both-party key contribution, fresh revocation evidence, protected replay state, group suitability or keys ready in time for early media.
  • A defensible operational receipt must bind the chosen mode to its prerequisites, transcript, identities, clock and cache state, TGK and TEK scope, forked responders, key-ready time and the exact security properties delivered—not merely configured.

A green light attached to the wrong claim

MIKEY was designed with Secure Real-time Transport Protocol in mind. It can establish a security context, transport or agree Traffic-Generating Keys and associate policy with one or more Crypto Sessions. That is substantial machinery. It is also exactly why a single status light is inadequate.

RFC 5197 is an Informational applicability analysis, not a new cipher and not a declaration that one mode dominates. It examines PSK, RSA, signed Diffie-Hellman, NULL, DH-HMAC, a SAML-assisted Diffie-Hellman design discussed in the document, and RSA-R with in-band certificate provision. These approaches share a framework while answering different security and deployment questions.

PSK is efficient and avoids PKI, but it has no perfect forward secrecy and the initiator generates the key material. RSA can scale through certificates and works in one message when the responder certificate is already known, but it also lacks PFS and leaves key generation with the initiator. DH-SIGN and DH-HMAC involve both parties and provide PFS, yet one leans on certificate infrastructure for scalable identity while the other begins with a shared secret and does not solve every group-keying topology. RSA-R helps when the final responder is not known in advance, but in-band certificate discovery does not create true PFS.

NULL deliberately contributes no key-management protection of its own.

All seven can truthfully be called MIKEY. They cannot truthfully be represented by one undifferentiated security state.

NULL exposes the transport boundary

MIKEY-NULL makes the problem visible because its name refuses to hide the dependency. It uses NULL encryption and authentication for key management and relies completely on an underlying layer such as TLS or IPsec. That can be a legitimate choice when the lower-layer endpoints are the intended security endpoints.

But a signaling path is not automatically end to end. If TLS terminates at a proxy, that proxy sits inside the protection boundary. RFC 5197 explicitly warns that intermediate nodes may obtain the exchanged master key in plain form. A record that says only TLS=yes and MIKEY=yes loses the most important fact: between which identities did TLS provide protection, and which processes handled clear keying material after termination?

This is not an argument that NULL is secretly broken. It is an argument against moving an assurance across layers. Lower-layer confidentiality can protect a hop. It cannot prove that the hop ends at the media peer. The receipt needs both endpoints, the intermediary chain and the selected MIKEY mode before anyone can infer who could observe the key.

The property matrix is the protocol surface

RFC 5197 compares modes along axes that operations often flatten: whether implementation is mandatory, how the approach scales, whether it needs PKI, whether it supplies PFS, whether both parties contribute to key generation and whether it supports group use. These are not academic annotations. Each axis changes what a later compromise or topology change means.

Consider the phrase “mutually authenticated.” In PSK mode, the responder message is optional; it may provide proof of possession or report an error. In RSA mode, the responder certificate must normally be available to the sender before the exchange, and certificate verification may depend on a separate component whose revocation information is not current. In DH-SIGN, each party contributes to the shared secret and signs its exchange, but broad deployment still needs a trustworthy way to bind certificates to identities. A successful parser and a valid signature do not answer the same question as a fresh revocation check.

“Fresh keys” is equally overloaded. Both-party contribution limits the ability of one side to force weak or predictable material and helps each participant establish freshness. PFS asks a different counterfactual: would compromise of long-term material expose earlier session keys? PSK and RSA do not provide that property. DH-SIGN and DH-HMAC do. RSA-R may carry an optional initiator random value, but the initiator cannot force the responder to use it honestly, so the document does not award true PFS.

The clean representation is a vector, not a badge: peer identity binding; responder proof; both-party contribution; PFS; replay decision; lower-layer exposure; group suitability; and media readiness, each with its own evidence.

Replay resistance lives partly outside the message

MIKEY uses timestamps together with message caching for replay handling rather than a challenge-response exchange. That makes loosely synchronized clocks and retained cache state part of the security mechanism. If synchronization is unavailable, RFC 5197 says replay handling may not work. The cache also needs enough capacity for the permitted clock skew and traffic pattern.

Two devices can therefore support the same mode and validate the same syntax while operating under materially different replay assurance. One has a disciplined time source, a declared skew window and cache entries retained across failover. The other restarts its cache, accepts broad skew and inherits time from an unrecorded proxy. Replay protected erases those differences.

A receipt should store the timestamp observed, time source, accepted skew, cache horizon, cache capacity, relevant cache hit or miss and restart epoch. Those fields do not replace cryptographic validation; they expose the state that made its replay conclusion possible. If an old message is accepted, peers can derive or install different TGKs and simply fail to communicate. “Encrypted media failed” is then a symptom, not a diagnosis.

One bundle does not mean one interchangeable key

MIKEY can establish several Crypto Sessions within a Crypto Session Bundle. They may share a TGK and security parameters while deriving distinct TEKs. The distinction matters when an implementation logs only CSB established. A later investigator needs to know which Crypto Session received which derived key and which SRTP identifiers bound that key to a stream.

Forking makes the scope hazardous. A SIP proxy may send an invitation and its MIKEY material to several destinations. In forward modes, several responders can receive material derived from the same source. If two branches use the same TEK and select the same 32-bit SSRC, SRTP derivation can produce the same session keys and initialization vectors. RFC 5197 describes the resulting two-time-pad danger.

The low probability of an accidental SSRC collision is not a receipt. The evidence is the responder set, branch identity, TEK scope and collision-detection outcome. A group label is not a substitute either: some modes can be used in centralized group distribution, some primarily fit point-to-point exchange, and DH-HMAC's virtues do not automatically extend to group keying.

Key establishment can finish after media begins

Mode choice also changes time. PSK and RSA can carry the needed material in a single initiator message. That lets both sides possess what they need before early SRTP arrives. Diffie-Hellman modes and RSA-R require a responder message before the initiator can calculate or receive the final key. Media can traverse a shorter path than a signaling answer and arrive first, even outside the classic call-centre use of early media.

An exchange can consequently be secure in design and operationally unready for the first packet. Dropping that packet is not evidence that SRTP is broken; accepting it through a fallback may silently alter the security policy. Record the offer time, responder contribution, transcript completion, key installation, first encrypted packet and first successful decrypt. Mode selected must never be promoted to key ready.

A receipt that says what happened

Start with the intended peers and media context. Record the mode and version actually negotiated, not only those enabled in configuration. Bind every prerequisite: PSK identity, certificate and chain, identity mapping, validation time, revocation evidence, credential server or lower-layer channel endpoints. Preserve which party supplied which entropy and the result claimed for PFS.

Attach the transcript hash and completion result to a CSB identifier. Record its Crypto Sessions, TGK identity, TEK derivation scope, responder branches and SSRC collision handling without exposing secret key values. Add timestamp source, skew and replay-cache state. Finish with key-ready time, first protected packet and decrypt outcome.

This schema is an operational inference, not a new wire requirement in RFC 5197. It follows a simpler discipline: implementation, configuration, selection, authentication, completion and usable media are different reality layers. A product can summarize them for an operator. It cannot discard them and later pretend the summary proves each one.

Sources

  1. RFC 5197 HTML
  2. RFC 5197 text
  3. RFC 5197 information page
  4. IETF Datatracker: RFC 5197
  5. RFC 5197 history
  6. RFC 5197 references
  7. RFC 5197 errata
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — MIKEY DH-HMAC
  11. RFC 4738 — MIKEY RSA-R
  12. RFC 4567 — Key Management Extensions for SDP and RTSP
  13. RFC 4568 — Security Descriptions for Media Streams
  14. RFC 5027 — Security Preconditions for Session Description Protocol Media Streams
  15. RFC 4086 — Randomness Requirements for Security
  16. RFC 4082 — TESLA
  17. RFC 4442 — Bootstrapping TESLA
  18. Heng Lu — reality layers and symbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy