Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)
Extracted elements (24)
ROC synchronization failures arise because out-of-band signaling (e.g., MIKEY) delivers the ROC at key-establishment time, but a receiver may join hours later after SEQ has wrapped, leave and re-join after 2^15 packets, or receive a delayed pre-wraparound packet first—each scenario leaving local ROC inconsistent with the sender's current ROC with no in-band recovery path in standard SRTP.
Separate SRTP and SRTCP integrity parameters (types 14–19) were introduced because RCC applies only to SRTP (not SRTCP), requiring the ability to specify different authentication algorithms and tag lengths for each stream within a single MIKEY policy.
The ROC is carried inside the authentication tag rather than in the MKI field because the MKI has no defined semantics in RFC 3711 beyond specifying the master key, and the MKI field is not integrity protected—leaving it vulnerable to DoS attacks where an attacker modifies the ROC and the receiver remains out of synchronization until the next ROC is transmitted.
The RCC transform is an SRTP-only mechanism. SRTCP already carries the full packet index in every packet under integrity protection and therefore does not benefit from and MUST NOT use the RCC transform.
During MAC computation on a packet carrying the ROC, the session integrity key derivation MUST use the ROC value found in the received packet rather than the local ROC. This ensures that if the receiver has an incorrect ROC, MAC verification will fail and the receiver will not incorrectly update its ROC.
If MAC verification fails for a packet carrying the ROC (SEQ = 0 mod R), the packet MUST be dropped. The receiver must not update its local ROC based on an unverified packet.
In mode 2, packets with SEQ not equal to 0 mod R MUST be protected using the default SRTP integrity transform. Modes 1, 2, and 3 are all MANDATORY to implement, though local policy determines which modes may be used.
In mode 3 (no integrity protection), the receiver's SRTP layer SHOULD ignore the ROC from the packet if the application layer indicates the local ROC is already synchronized; the received ROC still MUST be removed from the packet before further processing.
Modes 1 and 2 MUST compute the MAC using HMAC-SHA1, identical to the pre-defined SRTP authentication transform. This ensures that the MAC algorithm is consistent across transform modes.
R MUST be a non-zero unsigned integer, transmitted in network byte order. If the ROC transmission rate is not included in the out-of-band negotiation, the default value of 1 SHALL be used.
The length of the ROC (4 octets) MUST be included in the 'Authentication tag length' parameter when negotiating RCC, making the minimum authentication tag length 32 bits. When using RCCm3, the tag-length MUST be set to exactly four octets.
The RCC transform SHALL only be applied to SRTP and SHALL NOT be used with SRTCP, because SRTCP already carries the entire packet index in-band.
When both a specific SRTP/SRTCP parameter (types 14–19) and a corresponding general parameter (types 2, 3, or 11) are present in the MIKEY policy, the more specific parameter SHALL take precedence over the general one.
The rate parameter R governs how frequently the ROC is included in SRTP packets (every Rth packet). R MUST be a non-zero unsigned integer; if not negotiated, the default value of 1 is used, meaning the ROC is included in every packet.
The Roll-over Counter Carrying Transform (RCC) embeds the sender's ROC into the SRTP authentication tag for packets whose sequence number SEQ equals 0 modulo a configurable rate R. The tag format for those packets is TAG = ROC_sender || MAC_tr, where MAC_tr is the HMAC-SHA1 output truncated by 32 bits.
Three transform modes are defined. Mode 1 (RCCm1): integrity protection only on packets carrying the ROC (SEQ = 0 mod R). Mode 2 (RCCm2): all packets integrity protected—ROC packets use the RCC tag, others use the default SRTP MAC. Mode 3 (RCCm3): no MAC at all; ROC is carried unprotected in a 4-octet tag for SEQ = 0 mod R packets.
Seven new values were registered in the MIKEY SRTP Type namespace (RFC 3830, Table 6.10.1.a): type 13 (ROC transmission rate, 16-bit integer), and types 14–19 for per-stream authentication algorithm, session auth key length, and authentication tag length for SRTP and SRTCP separately.
Three new values were registered in the MIKEY SRTP auth alg namespace (RFC 3830, Table 6.10.1.c): RCCm1 = 2, RCCm2 = 3, RCCm3 = 4. These correspond to the three integrity transform modes defined by this document.
In broadcast deployments using symmetric-key integrity protection, gaining access to the integrity key (e.g., by purchasing a subscription and extracting the key from a terminal) may be as easy as gaining transmit capability, undermining the group integrity model.
Mode 3 (NULL-MAC) introduces a persistent DoS vulnerability: an attacker who modifies the ROC in every Rth packet will cause the receiver to lose cryptographic synchronization until the next correctly received ROC. Mode 3 MUST only be used after proper risk assessment; the transport network must consist of trusted domains, be protected from packet injection, and use VPN or leased lines for any segments that leave the trusted domain.
The RCC transform makes the entire SRTP packet index (ROC || SEQ) public since it is transmitted without encryption. RFC 3711 did not identify a need to encrypt the SRTP index, but implementors should be aware that only SEQ was previously disclosed in normal SRTP operation.
When using RCCm1 or RCCm2, the effective MAC length for ROC-carrying packets is tag_length minus 4 octets, not tag_length octets. To maintain the same MAC forgery success probability as the RFC 3711 default transform on all packets, the tag-length SHOULD be set to 14 octets (yielding a 10-octet MAC_tr). A tag-length of 32 bits provides no security.
Sender state machine: for each RTP packet, if SEQ = 0 mod R, compute HMAC-SHA1 over (authenticated_portion || ROC_sender), truncate by 32 bits to get MAC_tr, set TAG = ROC_sender || MAC_tr, and append to packet; otherwise process the packet normally per RFC 3711. Receiver mirrors this: if SEQ = 0 mod R, extract ROC_sender from TAG, verify MAC using ROC_sender in place of local ROC, and on success set local ROC = ROC_sender; otherwise process normally.
When SEQ = 0 mod R, the authentication tag is TAG = ROC_sender (4 octets, 32 bits) || MAC_tr (tag_length minus 4 octets). MAC_tr is the most-significant (tag_length − 32) bits of the HMAC-SHA1 output. For other packets, the tag is the standard SRTP MAC with no ROC prepended.