Summary

  • RFC 5159 is a March 2008 Informational specification for four SDP attributes developed for OMA BCAST service and content protection.
  • bcastversion advertised the broadcast-system version understood by the sender or required by the session.
  • stkmstream associated protected media with one or more Short Term Key Message streams that a terminal should process.
  • The association reduced unnecessary reception work but did not deliver a key, prove entitlement, or confirm successful decryption.
  • A media-level stkmstream attribute overrode the session-level list, so scope resolution was part of the effective control state.
  • Stream identifiers were nonzero integers unique only within one SDP session and were not durable global identities.
  • SRTPAuthentication selected RCCm1, RCCm2 or RCCm3; naming an algorithm did not authenticate any packet.
  • SRTPROCTxRate declared how often a sender transmitted the rollover counter, with a default rate of one.
  • A declared ROC cadence did not prove that a receiver obtained the right counter in time or remained synchronized.
  • The RFC warned that an unprotected bcastversion could enable downgrade and an altered stkmstream could cause denial of service.
  • IETF registration made the attribute names interoperable while OMA retained change control over their interpretation.
  • Audits must separate signalled intent, message receipt, entitlement, installed state, authenticated traffic, decryption and playback.

A map to a key stream was not a key-transfer receipt

Broadcast distribution rewards economical reception. A handset should not spend radio time, battery and processing effort on every stream in a multiplex when only one or two streams carry the key messages needed for the chosen programme. RFC 5159's stkmstream attribute addressed that practical problem. It let the session description associate media with the Short Term Key Message streams that mattered for that media.

The attribute therefore carried routing intelligence. It told a terminal which stream or streams it ought to listen to and process. Multiple instances could identify alternatives or several required streams. At media level, the declaration displaced the session-level list. The receiver had to resolve scope before deciding what to consume.

None of those facts constituted delivery. The SDP could name the right stream while packets were absent, late, corrupted, unauthorized or unusable. The terminal could receive a message but lack entitlement to unwrap it. It could recover a key but fail to install the corresponding cryptographic context. It could install that state and still fail to authenticate or decrypt the media. Each transition needed its own observable result.

This is the first leadership distinction: discovery and possession are not interchangeable. A catalogue can point to a credential without conveying it. A policy can name an authority without obtaining its decision. A workflow that records only the pointer will overstate completion precisely when the downstream security action matters most.

Session-local numbers became ambiguous outside their namespace

RFC 5159 defined the key-message stream identifier as a nonzero integer, unique within the SDP session. That boundary was adequate for a terminal interpreting the live description. It was not a promise of global uniqueness, durable meaning or comparability across sessions.

Trouble begins when an operator exports stkmstream=7 into a log, analytics warehouse or incident ticket without the session identity and scope that gave seven its meaning. A later session may reuse the same number for a different stream. A media-level override may mean that the session-level record was never effective for the media under investigation. A revised description may remove the association entirely.

The evidentiary unit is therefore not the integer. It is the tuple: description identity, version or hash, session time, media section, effective scope, stream identifier and observed receiver action. Without that envelope, a clean-looking number becomes a false join key. It can connect events that never belonged together or detach a decryption failure from the control message that caused it.

Authentication parameters were instructions, not outcomes

Two other attributes described SRTP behavior. SRTPAuthentication mapped numerical values to the RCCm1, RCCm2 and RCCm3 authentication algorithms. SRTPROCTxRate declared a rollover-counter transmission rate from 1 through 65535 and assigned one as the default when the attribute was absent.

These declarations matter. An endpoint needs compatible rules before it can interpret protected traffic. But selecting RCCm2 is not evidence that a particular packet passed RCCm2 verification. Advertising a ROC rate is not proof that the corresponding counter arrived, arrived before it was needed, was authenticated, or updated the receiver's replay and sequence-number state.

The distinction is especially sharp around rollover. SRTP uses the rollover counter to extend a shorter packet sequence space. Sender and receiver may disagree about the high-order state even when both implement the same profile. A receiver that misses the relevant transmission can possess the correct SDP and the wrong live counter. The system is configured in agreement yet operationally out of sync.

Assurance should preserve at least four receipts: the negotiated or announced parameter, the actual control packet, the receiver's accepted state transition, and the authentication/decryption result for media governed by that state. A configuration screenshot proves only the first.

An unprotected capability label could weaken the session

bcastversion appeared to be ordinary metadata: a string identifying which BCAST version applied. Yet RFC 5159's security considerations warned that if the value was not integrity protected, an attacker could replace it with an older version and drive a downgrade. The field did not need to carry a key to affect security. It only needed to influence which security behavior the terminal selected.

The same section described a different risk for stkmstream. Tampering could direct the terminal away from necessary key-message streams or toward irrelevant ones, causing denial of service or wasting receiver resources. A map that is merely descriptive in one architecture becomes an enforcement input once software acts on it automatically.

This is why “no secret in the field” is an inadequate threat model. Control metadata can change the algorithm, the input stream and the interpretation path. Its authority comes from downstream execution. Integrity protection must cover the decision-relevant description, and the audit record must bind the received description to the behavior actually selected.

Registration and semantic custody belonged to different institutions

The document's status also carries a governance lesson. RFC 5159 is Informational, not an IETF Standards Track protocol. It registered SDP attribute names in the IANA namespace so implementations could use stable tokens. The underlying BCAST work belonged to the Open Mobile Alliance, which retained change control over the intended semantics.

Registration solved collision and discoverability problems. It did not transfer ownership of the technology, certify an implementation, or prove that deployed systems followed a particular OMA release. The IETF record and the OMA semantic source were complementary evidence, not substitutes for each other.

Later SDP multiplexing guidance classified bcastversion and stkmstream as NORMAL while leaving the two SRTP-specific attributes without a determined category. That registry work answers whether attributes can be copied across bundled media descriptions under a defined procedure. It is not a retrospective security grade and cannot prove present deployment. A registry row is a coordination artifact with a deliberately limited claim.

Historical deployment language must remain historical

RFC 5159 said the attributes were expected to be used with 3GPP MBMS, 3GPP2 BCMCS and DVB-H. The wording described the anticipated environment in 2008. It does not establish that a named operator deployed the attributes, that current handsets implement them, or that any historical service remained operational for a particular period.

Procurement notes and architecture inventories should retain that difference. “The specification was designed for this family of systems” is source-backed. “Our service used it” requires configuration, packet, device or vendor evidence. “The user successfully consumed protected content” requires a still stronger chain reaching entitlement, key processing and playback.

The RFC is most useful when read at its exact scale. It created vocabulary for describing control choices. It did not collapse the control plane into the outcome plane.

Sources

  1. RFC 5159, HTML
  2. RFC 5159, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5159 history
  6. RFC 5159 references
  7. RFC 5159 errata
  8. RFC 4566
  9. RFC 8866
  10. RFC 4771
  11. RFC 3711
  12. RFC 8859
  13. RFC 5761
  14. RFC 7201
  15. RFC 5764
  16. RFC 8126
  17. IANA SDP parameters
  18. IPR disclosure 2092
  19. RFC 2119
  20. RFC 8174
  21. RFC 3264
  22. Minimum Initial Specification
  23. On Reality Layers
  24. Running-Code Primacy