The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
Extracted elements (23)
Digital signatures solve multicast source authentication but suffer high overhead in computation time and bandwidth. TESLA provides an efficient alternative with delayed per-packet authentication via a one-way key chain.
In a group security association, a shared symmetric key cannot provide data origin authentication because any group member can impersonate any other member; the MAC only guarantees the packet was not modified by an outside attacker. This motivates the use of TESLA rather than a simple group MAC.
The 80-bit TESLA MAC length is chosen to meet RFC 2104's requirements that MAC length be at least 80 bits and at least half the output size of the underlying hash (SHA-1 = 160 bits). This is intentionally shorter than IPsec's common 96-bit MAC but is sufficient given current cryptanalytic capabilities.
The MKI field necessarily separates the TESLA MAC from the SRTP MAC in the packet layout because SRTP does not cover the MKI in its MAC computation, and changing SRTP to include MKI coverage would require redefining the SRTP specification, which is impossible without breaking existing implementations.
The TESLA Authenticated Portion is defined as the RTP header plus the Encrypted Portion only, whereas the SRTP Authenticated Portion is extended to include the TESLA authentication extension. The SRTP MAC therefore covers the TESLA MAC tag, ensuring TESLA MAC packet integrity is verified by the outer SRTP integrity check.
For SRTCP, the external SRTP authentication tag is MANDATORY when TESLA is used (the E-bit, SRTCP index, and authentication tag are mandatory in SRTCP). The TESLA authentication extension SHALL be inserted before the MKI and authentication tag in the SRTCP packet.
For SRTP, the TESLA MAC input M' SHALL be the SRTP TESLA Authenticated Portion (RTP header concatenated with the Encrypted Portion) prepended with the rollover counter: M' = ROC || TESLA Authenticated Portion. For SRTCP, M' SHALL consist of the SRTCP TESLA Authenticated Portion only (RTCP header and Encrypted Portion).
If a received SRTP packet is judged to be replayed, it MUST be discarded and the event SHOULD be logged. If the SRTP integrity tag verification fails, the packet MUST likewise be discarded and the event SHOULD be logged.
It is RECOMMENDED that the SRTP MAC (group-key MAC used for DoS prevention) be truncated to 32 bits, since it serves only as protection against external attackers and not as a source-authentication mechanism.
TESLA implementations MUST support HMAC-SHA1 for both the TESLA MAC and the TESLA PRF. The key chain is defined as K_i = HMAC_SHA1(K_{i+1}, 0) and the MAC key as K'_i = HMAC_SHA1(K_i, 1).
TESLA MUST be bootstrapped at session setup for parameter exchange and initial key commitment; a digital signature algorithm is RECOMMENDED for this bootstrapping. Time synchronization to bound clock drift D_t is also required out-of-band before the session begins.
The HMAC-SHA1 algorithm SHALL be used to generate the TESLA MAC, applied to the TESLA chain key K'_i and input M'. The HMAC output SHALL be truncated to the n_m left-most bits (default 80 bits).
The SRTP replay list MUST NOT be updated based on the SRTP MAC; it MUST contain only indices of packets that have been TESLA-authenticated. Replay list updates occur only after successful TESLA verification.
To avoid the boundary condition where a key-disclosure packet for the final data packets is lost, null packets SHOULD be sent for d intervals of duration T_int after the stream ceases. The rate of null packets SHOULD match the average rate of the session media stream.
When a disclosed TESLA key is available for a buffered packet, TESLA verification MUST succeed for the packet to be used; if verification fails, the packet MUST be discarded and the event SHOULD be logged. If the TESLA safety condition does not hold (packet is 'unsafe'), it is RECOMMENDED to discard the packet.
When TESLA is applied to RTP, the TESLA authentication extension SHALL be inserted before the optional SRTP MKI and the recommended SRTP authentication tag in the SRTP packet.
When TESLA is used within SRTP, the default choice of the PRF for both F(x) (key chain derivation) and F'(x) (MAC key derivation) SHALL be HMAC-SHA1. Alternative PRFs SHALL follow the common SRTP guidelines for adding new security parameters.
Default SRTP TESLA parameters: TESLA PRF is HMAC-SHA1; key-chain output length n_p = 160 bits; F'-output length n_f = 160 bits; TESLA MAC algorithm is HMAC-SHA1 truncated to n_m = 80 bits. These defaults add 38 bytes per packet, which may exceed 50% overhead for some applications.
When TESLA is used, the SRTP cryptographic context SHALL be extended with 11 transform-dependent parameters: TESLA PRF identifier, key-chain output length n_p, F'-output length n_f, TESLA MAC identifier, TESLA MAC output length n_m, session start T_0, interval duration T_int, key-disclosure delay d, clock-drift bound D_t, key-chain length n_c, and the initial committed key.
SRTP TESLA security depends on the effective security of external systems that perform bootstrapping (key commitment) and time synchronization (clock-drift bound D_t). Compromise of these external systems undermines the TESLA source authentication guarantees; they are explicitly out of scope for this specification.
TESLA requires receiver buffering before authentication, making receivers vulnerable to denial-of-service attacks from floods of bogus packets. The external group-key SRTP MAC (MAY be used) provides a first line of defense against external DoS; its short 32-bit size is intentional since an adversary must average 2^31 attempts to forge an accepted packet before the TESLA check catches it.
TESLA security depends on correct computation of the 'safety condition' (Section 3.5 of RFC 4082) to verify that a disclosed key could not have been known by an attacker at the time the corresponding packet was sent. Packets that fail the safety condition are considered unauthenticated.
The TESLA authentication extension appended per-packet contains three mandatory fields: a 32-bit time interval identifier i, a variable-length Disclosed Key (K_(i-d)), and a variable-length TESLA MAC. Field lengths for Disclosed Key and TESLA MAC are established by the SRTP cryptographic context parameters.