Encrypted Key Transport for DTLS and Secure RTP
Extracted elements (28)
SRTP (rather than SRTCP) is used to carry EKT keying material because it shares fate with the transmitted media, SRTP rekeying can occur without concern for RTCP transmission limits, and it avoids the need for SRTCP compound packets with RTP translators and mixers.
The EKT Message Type byte is placed at the very end of the SRTP packet because the length of the SRTP portion is not known until decryption occurs, making forward parsing impossible. By parsing backwards from the packet end, the type can be determined before decryption.
EKT MAY be used with DTLS versions prior to 1.3, but pre-1.3 stacks lack built-in ACK message support. Implementations supporting EKT with pre-1.3 DTLS must add explicit affordances for sending ACK in response to EKTKey messages and verifying ACK receipt.
A new sender SHOULD send a FullEKTField as soon as possible, ideally in its initial SRTP packet. It is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets to accommodate packet loss.
EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's <From, To> fields. Senders MUST NOT include the MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use.
If a received EKT Tag has an unknown Message Type, the receiver MUST discard the whole EKT Tag. Message Type MUST be 2 for FullEKTField and 0 for ShortEKTField.
If a source has its EKTKey changed by key management, it MUST also change its SRTP master key. This ensures traffic can be decrypted only by participants who know the current EKTKey.
If an EKTKey message is received that cannot be processed, the recipient MUST respond with an appropriate DTLS alert. If the server did not include supported_ekt_ciphers in its EncryptedExtensions, EKTKey messages MUST NOT be sent.
Once a client and server have concluded a handshake negotiating an EKTCipher, the server MUST provide the client a key (EKTKey) to be used when encrypting/decrypting EKTCiphertext values. When an EKTKey is received and processed successfully, the recipient MUST respond with an ACK message.
Outbound packets SHOULD continue to use the old SRTP master key for 250 ms after sending any new key in a FullEKTField. This gives receivers time to obtain the new key before it is used for encryption.
Senders SHOULD periodically transmit the FullEKTField to accommodate new receivers joining a session. If sending audio and video, the RECOMMENDED frequency is the same as the intra-coded video frame rate. If only sending audio, the RECOMMENDED frequency is every 100 ms.
The ekt_key_value MUST NOT be used for encrypting or decrypting information after the TTL (ekt_ttl) expires. To mitigate the risk of an attacker blocking EKTKey updates, the lifetime of the EKTKey MUST be limited using ekt_ttl.
The EKTKey MUST NOT be used for encryption more than T times, where T is cipher-specific. For AESKW128 and AESKW256, T = 2^48. Retransmitting the same FullEKTField multiple times counts as only one encryption.
The default EKT Cipher is AES Key Wrap with Padding (RFC 5649). AESKW128 (L=16 bytes) MUST be implemented; AESKW256 (L=32 bytes) MAY be implemented. Both have T=2^48 as the maximum encryption count.
The Epoch field is a 16-bit integer indicating how many SRTP keys have been sent for a given SSRC under the current EKTKey prior to the current key. It starts at zero and increments each time a sender transmits a new key. The recipient MUST reject any future FullEKTField for this SPI and SSRC with an epoch value equal to or lower than one already seen.
The Security Parameter Index (SPI) is a 16-bit field in the FullEKTField that identifies the EKTKey, EKT Cipher, and associated SRTP master salt to be used for processing a given packet. Each distinct EKT parameter set MUST be associated with a distinct SPI value.
IANA created the 'EKT Ciphers' registry in the RTP Parameters registry group. Initial values: AESKW128=0, AESKW256=1, Reserved=255. New entries require Specification Required and must define L and T values.
IANA created the 'EKT Message Types' registry in the RTP Parameters registry group. Initial values: Short=0, Full=2, Reserved=255. New entries require Specification Required; even values SHOULD be allocated before odd values.
IANA registered TLS extension 'supported_ekt_ciphers' with value 39 in the TLS ExtensionType Values registry, applicable to ClientHello (CH) and EncryptedExtensions (EE), Recommended=Y.
IANA registered TLS handshake type 'ekt_key' with value 26 in the TLS HandshakeType registry, with DTLS-OK=Y.
EKT uses group shared symmetric keys (EKTKeys), so group members can impersonate each other — any group member can generate an EKT Tag for any SSRC. The entity distributing EKTKeys can decrypt any keys distributed via EKT and thus any media protected with those keys. This is an inherent limitation of the group key model.
SRTP master keys MUST be randomly generated, MUST NOT be reused for any other purpose, and MUST NOT be derived from other SRTP master keys. The key length of the EKT Cipher MUST be at least as long as the SRTP cipher and the DTLS-SRTP ciphers.
The SSRC in the EKTPlaintext prevents cross-stream cut-and-paste attacks, since an attacker cannot use an EKT Tag from one SSRC to reset the key for another. The Epoch field prevents rollback to a previous key. However, EKT has no replay protection, so an attacker could implant improper keys by replaying captured EKTCiphertext values.
Inbound EKT processing: (1) check final byte to determine EKT format, (2) look up EKT parameter set by SPI — if no match, return authentication failure, (3) authenticate and decrypt EKTCiphertext — abort on failure, (4) parse EKTPlaintext, (5) verify SSRC in EKTPlaintext matches SRTP packet SSRC, (6) save recovered keys indexed by SSRC, (7) proceed with normal SRTP processing.
Outbound EKT processing: (1) set SPI from outbound parameter set, (2) compute EKTPlaintext from SRTP master key/SSRC/ROC, (3) encrypt to EKTCiphertext using EKTCipher and EKTKey, (4) form and append FullEKTField. When not sending a FullEKTField, a ShortEKTField MUST be appended instead.
The EKTKey DTLS handshake message (type ekt_key, value 26) carries: ekt_key_value (1-256 bytes opaque), srtp_master_salt (1-256 bytes opaque), ekt_spi (uint16), and ekt_ttl (uint24, maximum lifetime in seconds).
The EKTPlaintext is the concatenation of SRTPMasterKeyLength (1 byte), SRTPMasterKey (1-242 bytes), SSRC (4 bytes), and ROC (4 bytes). This plaintext is encrypted to form the EKTCiphertext and never appears on the wire.
The FullEKTField consists of: EKTCiphertext (variable), SPI (16-bit), Epoch (16-bit), Length (16-bit), and Message Type byte (0x02). The ShortEKTField is a single zero byte (0x00). Both are appended to the end of the SRTP packet, after the authentication tag.