Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
Extracted elements (30)
NTP-based out-of-band clock synchronization is preferred over inband MIKEY piggybacking because NTP allows half-roundtrip MIKEY variants, while inband synchronization requires a full MIKEY handshake and only works when the media receiver is the MIKEY initiator.
TESLA's initial key (parameter 10 in RFC 4383, the receiver clock lag) is omitted from MIKEY transport because it can be computed from MIKEY's own synchronized clocks or from the inband timestamp exchange defined in Section 4.3.
The initial TESLA key is carried in MIKEY's General Extensions Payload rather than a new payload type, because that payload was designed to allow extensions without defining a completely new payload each time; the key is part of the authenticated/signed data.
TESLA parameter bootstrapping via MIKEY is designed for use with SRTP-TESLA (RFC 4383); the MIKEY session itself may be established via SDP (RFC 2327) and SIP (RFC 3261) for end-to-end session setup.
This document extends MIKEY (RFC 3830) with new SP payload and General Extension Payload values; all MIKEY key management variants (symmetric, public key, signed DH, DHHMAC, RSA-R) can be used to carry TESLA parameters.
A four-byte integer value for policy item 6 (interval duration) and a two-byte integer value for policy item 7 (key disclosure delay) are RECOMMENDED.
Authentication and Integrity MUST be provided when sending the TESLA parameters, especially for the initial key.
Confidentiality MAY be provided for the TESLA parameters during bootstrapping.
Out-of-band synchronization using NTP is the RECOMMENDED approach for clock synchronization; inband determination via MIKEY piggybacking MAY be used when the media receiver is also the MIKEY initiator.
Policy type 9 (local timestamp at media receiver) SHOULD be used if inband time synchronization (alternative 2) is used; otherwise it SHOULD be omitted.
TESLA parameter bootstrapping MUST be integrity protected to prevent modification of the parameters and their values, and authentication MUST be provided.
The exchanged parameters MUST be integrity protected to allow the recipient to detect adversarial modification; MIKEY's authentication and key exchange algorithms provide this protection.
Time values for session start (policy item 5) and local timestamp (policy item 9) SHALL be transported in NTP-UTC format as described in Section 6.6 of RFC 3830.
To prevent replay attacks, a freshness guarantee MUST be provided; the TESLA bootstrapping message exchange MUST be unique and fresh, and the session key MUST be bound to the protocol session including the exchanged parameters.
A new Prot type value of 1 is defined for TESLA in the MIKEY SP payload, alongside the existing value 0 for SRTP. This allows MIKEY to negotiate TESLA as a distinct security protocol.
For inband time synchronization, the media receiver (MIKEY initiator) sends its local time t_r; the data sender replies with its time t_s and the echoed t_r. The receiver computes clock drift as D_t = t_s - t_r + S.
TESLA parameters to be bootstrapped via MIKEY include: PRF identifier (F and F'), key chain key length, TESLA MAC identifier, MAC output length, session start time, interval duration, key disclosure delay, key chain length, and the initial key of the chain.
TESLA policy TLV types 1–9 encode: PRF identifier, PRF output length, TESLA MAC identifier, MAC output length, session start, interval duration, key disclosure delay, key chain length, and optional local receiver timestamp.
IANA added 'TESLA I-Key' (value 2) to the existing MIKEY General Extension Payload 'Type' registry created by RFC 3830. Values 0 and 1 were already registered.
IANA added 'TESLA' (value 1) to the existing MIKEY 'Prot type' registry created by RFC 3830. Values up to 240 require expert review; 241–255 are private use.
IANA created a new 'TESLA-MAC' registry for MAC functions used in TESLA policy, with initial value HMAC-SHA1 = 0. Expert review required for values 0–240; 241–255 reserved for private use.
IANA created a new 'TESLA-PRF' registry for pseudo-random functions used in TESLA policy, with initial value HMAC-SHA1 = 0. Expert review required for values 0–240; 241–255 reserved for private use.
Denial-of-service via parameter modification: altering key disclosure delay or interval duration causes state mismatch between sender and receiver. Countermeasure: integrity protection of all exchanged parameters via MIKEY.
Downgrading attack: an adversary on the signaling path may modify the offered algorithm list to force selection of a weaker hash. Countermeasure: integrity and authentication protection of the parameter exchange via MIKEY.
Man-in-the-middle attack: without mutual authentication, an adversary can intercept and substitute TESLA parameters. Countermeasure: MIKEY provides authenticated and integrity-protected parameter exchange with session key establishment.
Replay attack: replayed MIKEY messages carrying TESLA parameters can cause DoS, downgrading, or MITM. Countermeasure: freshness guarantee and unique session key bound to the full protocol exchange, including TESLA parameters.
Traffic analysis: an on-path adversary can observe TESLA parameters to assist future attacks. Countermeasure: confidentiality via MIKEY public-key or symmetric-key encryption modes. The initial hash key does not require confidentiality due to the one-way property of the hash chain.
The General Extension Payload carries: Next payload (8 bits), Type (8 bits), Length (16 bits), and Data (variable). A new Type value of 2 (TESLA I-Key) carries the TESLA initial key.
The Security Policy (SP) payload carries: Next payload (8 bits), Policy no (8 bits), Prot type (8 bits), and Policy param length (16 bits) followed by variable-length Policy param TLVs.
The SP payload's Policy param field is composed of TLV triples: Type (8 bits), Length (8 bits), Value (variable). Each TLV encodes one TESLA policy parameter.