From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3711.txt | 3139 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3139 insertions(+) create mode 100644 doc/rfc/rfc3711.txt (limited to 'doc/rfc/rfc3711.txt') diff --git a/doc/rfc/rfc3711.txt b/doc/rfc/rfc3711.txt new file mode 100644 index 0000000..ecc0648 --- /dev/null +++ b/doc/rfc/rfc3711.txt @@ -0,0 +1,3139 @@ + + + + + + +Network Working Group M. Baugher +Request for Comments: 3711 D. McGrew +Category: Standards Track Cisco Systems, Inc. + M. Naslund + E. Carrara + K. Norrman + Ericsson Research + March 2004 + + + The Secure Real-time Transport Protocol (SRTP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes the Secure Real-time Transport Protocol + (SRTP), a profile of the Real-time Transport Protocol (RTP), which + can provide confidentiality, message authentication, and replay + protection to the RTP traffic and to the control traffic for RTP, the + Real-time Transport Control Protocol (RTCP). + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 + 2. Goals and Features . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. SRTP Cryptographic Contexts. . . . . . . . . . . . . . . 7 + 3.2.1. Transform-independent parameters . . . . . . . . 8 + 3.2.2. Transform-dependent parameters . . . . . . . . . 10 + 3.2.3. Mapping SRTP Packets to Cryptographic Contexts . 10 + 3.3. SRTP Packet Processing . . . . . . . . . . . . . . . . . 11 + 3.3.1. Packet Index Determination, and ROC, s_l Update. 13 + 3.3.2. Replay Protection. . . . . . . . . . . . . . . . 15 + 3.4. Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15 + + + +Baugher, et al. Standards Track [Page 1] + +RFC 3711 SRTP March 2004 + + + 4. Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19 + 4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1.1. AES in Counter Mode. . . . . . . . . . . . . . . 21 + 4.1.2. AES in f8-mode . . . . . . . . . . . . . . . . . 22 + 4.1.3. NULL Cipher. . . . . . . . . . . . . . . . . . . 25 + 4.2. Message Authentication and Integrity . . . . . . . . . . 25 + 4.2.1. HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25 + 4.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 26 + 4.3.1. Key Derivation Algorithm . . . . . . . . . . . . 26 + 4.3.2. SRTCP Key Derivation . . . . . . . . . . . . . . 28 + 4.3.3. AES-CM PRF . . . . . . . . . . . . . . . . . . . 28 + 5. Default and mandatory-to-implement Transforms. . . . . . . . . 28 + 5.1. Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29 + 5.2. Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29 + 5.3. Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29 + 6. Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29 + 7. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 7.1. Key derivation . . . . . . . . . . . . . . . . . . . . . 30 + 7.2. Salting key. . . . . . . . . . . . . . . . . . . . . . . 30 + 7.3. Message Integrity from Universal Hashing . . . . . . . . 31 + 7.4. Data Origin Authentication Considerations. . . . . . . . 31 + 7.5. Short and Zero-length Message Authentication . . . . . . 32 + 8. Key Management Considerations. . . . . . . . . . . . . . . . . 33 + 8.1. Re-keying . . . . . . . . . . . . . . . . . . . . . . . 34 + 8.1.1. Use of the for re-keying. . . . . . . 34 + 8.2. Key Management parameters. . . . . . . . . . . . . . . . 35 + 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 + 9.1. SSRC collision and two-time pad. . . . . . . . . . . . . 37 + 9.2. Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38 + 9.3. Confidentiality of the RTP Payload . . . . . . . . . . . 39 + 9.4. Confidentiality of the RTP Header. . . . . . . . . . . . 40 + 9.5. Integrity of the RTP payload and header. . . . . . . . . 40 + 9.5.1. Risks of Weak or Null Message Authentication. . . 42 + 9.5.2. Implicit Header Authentication . . . . . . . . . 43 + 10. Interaction with Forward Error Correction mechanisms. . . . . 43 + 11. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43 + 11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44 + 11.3. Re-keying and access control . . . . . . . . . . . . . . 45 + 11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46 + 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 47 + 14.2. Informative References . . . . . . . . . . . . . . . . . 48 + Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51 + Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51 + B.1. AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51 + + + +Baugher, et al. Standards Track [Page 2] + +RFC 3711 SRTP March 2004 + + + B.2. AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52 + B.3. Key Derivation Test Vectors. . . . . . . . . . . . . . . 53 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56 + +1. Introduction + + This document describes the Secure Real-time Transport Protocol + (SRTP), a profile of the Real-time Transport Protocol (RTP), which + can provide confidentiality, message authentication, and replay + protection to the RTP traffic and to the control traffic for RTP, + RTCP (the Real-time Transport Control Protocol) [RFC3350]. + + SRTP provides a framework for encryption and message authentication + of RTP and RTCP streams (Section 3). SRTP defines a set of default + cryptographic transforms (Sections 4 and 5), and it allows new + transforms to be introduced in the future (Section 6). With + appropriate key management (Sections 7 and 8), SRTP is secure + (Sections 9) for unicast and multicast RTP applications (Section 11). + + SRTP can achieve high throughput and low packet expansion. SRTP + proves to be a suitable protection for heterogeneous environments + (mix of wired and wireless networks). To get such features, default + transforms are described, based on an additive stream cipher for + encryption, a keyed-hash based function for message authentication, + and an "implicit" index for sequencing/synchronization based on the + RTP sequence number for SRTP and an index number for Secure RTCP + (SRTCP). + +1.1. Notational Conventions + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. The + terminology conforms to [RFC2828] with the following exception. For + simplicity we use the term "random" throughout the document to denote + randomly or pseudo-randomly generated values. Large amounts of + random bits may be difficult to obtain, and for the security of SRTP, + pseudo-randomness is sufficient [RFC1750]. + + By convention, the adopted representation is the network byte order, + i.e., the left most bit (octet) is the most significant one. By XOR + we mean bitwise addition modulo 2 of binary strings, and || denotes + concatenation. In other words, if C = A || B, then the most + significant bits of C are the bits of A, and the least significant + bits of C equal the bits of B. Hexadecimal numbers are prefixed by + 0x. + + + + +Baugher, et al. Standards Track [Page 3] + +RFC 3711 SRTP March 2004 + + + The word "encryption" includes also use of the NULL algorithm (which + in practice does leave the data in the clear). + + With slight abuse of notation, we use the terms "message + authentication" and "authentication tag" as is common practice, even + though in some circumstances, e.g., group communication, the service + provided is actually only integrity protection and not data origin + authentication. + +2. Goals and Features + + The security goals for SRTP are to ensure: + + * the confidentiality of the RTP and RTCP payloads, and + + * the integrity of the entire RTP and RTCP packets, together with + protection against replayed packets. + + These security services are optional and independent from each other, + except that SRTCP integrity protection is mandatory (malicious or + erroneous alteration of RTCP messages could otherwise disrupt the + processing of the RTP stream). + + Other, functional, goals for the protocol are: + + * a framework that permits upgrading with new cryptographic + transforms, + + * low bandwidth cost, i.e., a framework preserving RTP header + compression efficiency, + + and, asserted by the pre-defined transforms: + + * a low computational cost, + + * a small footprint (i.e., small code size and data memory for + keying information and replay lists), + + * limited packet expansion to support the bandwidth economy goal, + + * independence from the underlying transport, network, and physical + layers used by RTP, in particular high tolerance to packet loss + and re-ordering. + + These properties ensure that SRTP is a suitable protection scheme for + RTP/RTCP in both wired and wireless scenarios. + + + + + +Baugher, et al. Standards Track [Page 4] + +RFC 3711 SRTP March 2004 + + +2.1. Features + + Besides the above mentioned direct goals, SRTP provides for some + additional features. They have been introduced to lighten the burden + on key management and to further increase security. They include: + + * A single "master key" can provide keying material for + confidentiality and integrity protection, both for the SRTP stream + and the corresponding SRTCP stream. This is achieved with a key + derivation function (see Section 4.3), providing "session keys" + for the respective security primitive, securely derived from the + master key. + + * In addition, the key derivation can be configured to periodically + refresh the session keys, which limits the amount of ciphertext + produced by a fixed key, available for an adversary to + cryptanalyze. + + * "Salting keys" are used to protect against pre-computation and + time-memory tradeoff attacks [MF00] [BS00]. + + Detailed rationale for these features can be found in Section 7. + +3. SRTP Framework + + RTP is the Real-time Transport Protocol [RFC3550]. We define SRTP as + a profile of RTP. This profile is an extension to the RTP + Audio/Video Profile [RFC3551]. Except where explicitly noted, all + aspects of that profile apply, with the addition of the SRTP security + features. Conceptually, we consider SRTP to be a "bump in the stack" + implementation which resides between the RTP application and the + transport layer. SRTP intercepts RTP packets and then forwards an + equivalent SRTP packet on the sending side, and intercepts SRTP + packets and passes an equivalent RTP packet up the stack on the + receiving side. + + Secure RTCP (SRTCP) provides the same security services to RTCP as + SRTP does to RTP. SRTCP message authentication is MANDATORY and + thereby protects the RTCP fields to keep track of membership, provide + feedback to RTP senders, or maintain packet sequence counters. SRTCP + is described in Section 3.4. + + + + + + + + + + +Baugher, et al. Standards Track [Page 5] + +RFC 3711 SRTP March 2004 + + +3.1. Secure RTP + + The format of an SRTP packet is illustrated in Figure 1. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ + |V=2|P|X| CC |M| PT | sequence number | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | timestamp | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | synchronization source (SSRC) identifier | | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | + | contributing source (CSRC) identifiers | | + | .... | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | RTP extension (OPTIONAL) | | + +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | payload ... | | + | | +-------------------------------+ | + | | | RTP padding | RTP pad count | | + +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ + | ~ SRTP MKI (OPTIONAL) ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | : authentication tag (RECOMMENDED) : | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + +- Encrypted Portion* Authenticated Portion ---+ + + Figure 1. The format of an SRTP packet. *Encrypted Portion is the + same size as the plaintext for the Section 4 pre-defined transforms. + + The "Encrypted Portion" of an SRTP packet consists of the encryption + of the RTP payload (including RTP padding when present) of the + equivalent RTP packet. The Encrypted Portion MAY be the exact size + of the plaintext or MAY be larger. Figure 1 shows the RTP payload + including any possible padding for RTP [RFC3550]. + + None of the pre-defined encryption transforms uses any padding; for + these, the RTP and SRTP payload sizes match exactly. New transforms + added to SRTP (following Section 6) may require padding, and may + hence produce larger payloads. RTP provides its own padding format + (as seen in Fig. 1), which due to the padding indicator in the RTP + header has merits in terms of compactness relative to paddings using + prefix-free codes. This RTP padding SHALL be the default method for + transforms requiring padding. Transforms MAY specify other padding + methods, and MUST then specify the amount, format, and processing of + their padding. It is important to note that encryption transforms + + + +Baugher, et al. Standards Track [Page 6] + +RFC 3711 SRTP March 2004 + + + that use padding are vulnerable to subtle attacks, especially when + message authentication is not used [V02]. Each specification for a + new encryption transform needs to carefully consider and describe the + security implications of the padding that it uses. Message + authentication codes define their own padding, so this default does + not apply to authentication transforms. + + The OPTIONAL MKI and the RECOMMENDED authentication tag are the only + fields defined by SRTP that are not in RTP. Only 8-bit alignment is + assumed. + + MKI (Master Key Identifier): configurable length, OPTIONAL. The + MKI is defined, signaled, and used by key management. The + MKI identifies the master key from which the session + key(s) were derived that authenticate and/or encrypt the + particular packet. Note that the MKI SHALL NOT identify + the SRTP cryptographic context, which is identified + according to Section 3.2.3. The MKI MAY be used by key + management for the purposes of re-keying, identifying a + particular master key within the cryptographic context + (Section 3.2.1). + + Authentication tag: configurable length, RECOMMENDED. The + authentication tag is used to carry message authentication + data. The Authenticated Portion of an SRTP packet + consists of the RTP header followed by the Encrypted + Portion of the SRTP packet. Thus, if both encryption and + authentication are applied, encryption SHALL be applied + before authentication on the sender side and conversely on + the receiver side. The authentication tag provides + authentication of the RTP header and payload, and it + indirectly provides replay protection by authenticating + the sequence number. Note that the MKI is not integrity + protected as this does not provide any extra protection. + +3.2. SRTP Cryptographic Contexts + + Each SRTP stream requires the sender and receiver to maintain + cryptographic state information. This information is called the + "cryptographic context". + + SRTP uses two types of keys: session keys and master keys. By a + "session key", we mean a key which is used directly in a + cryptographic transform (e.g., encryption or message authentication), + and by a "master key", we mean a random bit string (given by the key + management protocol) from which session keys are derived in a + + + + + +Baugher, et al. Standards Track [Page 7] + +RFC 3711 SRTP March 2004 + + + cryptographically secure way. The master key(s) and other parameters + in the cryptographic context are provided by key management + mechanisms external to SRTP, see Section 8. + +3.2.1. Transform-independent parameters + + Transform-independent parameters are present in the cryptographic + context independently of the particular encryption or authentication + transforms that are used. The transform-independent parameters of + the cryptographic context for SRTP consist of: + + * a 32-bit unsigned rollover counter (ROC), which records how many + times the 16-bit RTP sequence number has been reset to zero after + passing through 65,535. Unlike the sequence number (SEQ), which + SRTP extracts from the RTP packet header, the ROC is maintained by + SRTP as described in Section 3.3.1. + + We define the index of the SRTP packet corresponding to a given + ROC and RTP sequence number to be the 48-bit quantity + + i = 2^16 * ROC + SEQ. + + * for the receiver only, a 16-bit sequence number s_l, which can be + thought of as the highest received RTP sequence number (see + Section 3.3.1 for its handling), which SHOULD be authenticated + since message authentication is RECOMMENDED, + + * an identifier for the encryption algorithm, i.e., the cipher and + its mode of operation, + + * an identifier for the message authentication algorithm, + + * a replay list, maintained by the receiver only (when + authentication and replay protection are provided), containing + indices of recently received and authenticated SRTP packets, + + * an MKI indicator (0/1) as to whether an MKI is present in SRTP and + SRTCP packets, + + * if the MKI indicator is set to one, the length (in octets) of the + MKI field, and (for the sender) the actual value of the currently + active MKI (the value of the MKI indicator and length MUST be kept + fixed for the lifetime of the context), + + * the master key(s), which MUST be random and kept secret, + + + + + + +Baugher, et al. Standards Track [Page 8] + +RFC 3711 SRTP March 2004 + + + * for each master key, there is a counter of the number of SRTP + packets that have been processed (sent) with that master key + (essential for security, see Sections 3.3.1 and 9), + + * non-negative integers n_e, and n_a, determining the length of the + session keys for encryption, and message authentication. + + In addition, for each master key, an SRTP stream MAY use the + following associated values: + + * a master salt, to be used in the key derivation of session keys. + This value, when used, MUST be random, but MAY be public. Use of + master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" + salt is treated as 00...0. + + * an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate", + where an unspecified value is treated as zero. The constraint to + be a power of 2 simplifies the session-key derivation + implementation, see Section 4.3. + + * an MKI value, + + * values, specifying the lifetime for a master key, + expressed in terms of the two 48-bit index values inside whose + range (including the range end-points) the master key is valid. + For the use of , see Section 8.1.1. is an + alternative to the MKI and assumes that a master key is in one- + to-one correspondence with the SRTP session key on which the + range is defined. + + SRTCP SHALL by default share the crypto context with SRTP, except: + + * no rollover counter and s_l-value need to be maintained as the + RTCP index is explicitly carried in each SRTCP packet, + + * a separate replay list is maintained (when replay protection is + provided), + + * SRTCP maintains a separate counter for its master key (even if the + master key is the same as that for SRTP, see below), as a means to + maintain a count of the number of SRTCP packets that have been + processed with that key. + + Note in particular that the master key(s) MAY be shared between SRTP + and the corresponding SRTCP, if the pre-defined transforms (including + the key derivation) are used but the session key(s) MUST NOT be so + shared. + + + + +Baugher, et al. Standards Track [Page 9] + +RFC 3711 SRTP March 2004 + + + In addition, there can be cases (see Sections 8 and 9.1) where + several SRTP streams within a given RTP session, identified by their + synchronization source (SSRCs, which is part of the RTP header), + share most of the crypto context parameters (including possibly + master and session keys). In such cases, just as in the normal + SRTP/SRTCP parameter sharing above, separate replay lists and packet + counters for each stream (SSRC) MUST still be maintained. Also, + separate SRTP indices MUST then be maintained. + + A summary of parameters, pre-defined transforms, and default values + for the above parameters (and other SRTP parameters) can be found in + Sections 5 and 8.2. + +3.2.2. Transform-dependent parameters + + All encryption, authentication/integrity, and key derivation + parameters are defined in the transforms section (Section 4). + Typical examples of such parameters are block size of ciphers, + session keys, data for the Initialization Vector (IV) formation, etc. + Future SRTP transform specifications MUST include a section to list + the additional cryptographic context's parameters for that transform, + if any. + +3.2.3. Mapping SRTP Packets to Cryptographic Contexts + + Recall that an RTP session for each participant is defined [RFC3550] + by a pair of destination transport addresses (one network address + plus a port pair for RTP and RTCP), and that a multimedia session is + defined as a collection of RTP sessions. For example, a particular + multimedia session could include an audio RTP session, a video RTP + session, and a text RTP session. + + A cryptographic context SHALL be uniquely identified by the triplet + context identifier: + + context id = + + where the destination network address and the destination transport + port are the ones in the SRTP packet. It is assumed that, when + presented with this information, the key management returns a context + with the information as described in Section 3.2. + + As noted above, SRTP and SRTCP by default share the bulk of the + parameters in the cryptographic context. Thus, retrieving the crypto + context parameters for an SRTCP stream in practice may imply a + binding to the correspondent SRTP crypto context. It is up to the + implementation to assure such binding, since the RTCP port may not be + + + +Baugher, et al. Standards Track [Page 10] + +RFC 3711 SRTP March 2004 + + + directly deducible from the RTP port only. Alternatively, the key + management may choose to provide separate SRTP- and SRTCP- contexts, + duplicating the common parameters (such as master key(s)). The + latter approach then also enables SRTP and SRTCP to use, e.g., + distinct transforms, if so desired. Similar considerations arise + when multiple SRTP streams, forming part of one single RTP session, + share keys and other parameters. + + If no valid context can be found for a packet corresponding to a + certain context identifier, that packet MUST be discarded. + +3.3. SRTP Packet Processing + + The following applies to SRTP. SRTCP is described in Section 3.4. + + Assuming initialization of the cryptographic context(s) has taken + place via key management, the sender SHALL do the following to + construct an SRTP packet: + + 1. Determine which cryptographic context to use as described in + Section 3.2.3. + + 2. Determine the index of the SRTP packet using the rollover counter, + the highest sequence number in the cryptographic context, and the + sequence number in the RTP packet, as described in Section 3.3.1. + + 3. Determine the master key and master salt. This is done using the + index determined in the previous step or the current MKI in the + cryptographic context, according to Section 8.1. + + 4. Determine the session keys and session salt (if they are used by + the transform) as described in Section 4.3, using master key, + master salt, key_derivation_rate, and session key-lengths in the + cryptographic context with the index, determined in Steps 2 and 3. + + 5. Encrypt the RTP payload to produce the Encrypted Portion of the + packet (see Section 4.1, for the defined ciphers). This step uses + the encryption algorithm indicated in the cryptographic context, + the session encryption key and the session salt (if used) found in + Step 4 together with the index found in Step 2. + + 6. If the MKI indicator is set to one, append the MKI to the packet. + + 7. For message authentication, compute the authentication tag for the + Authenticated Portion of the packet, as described in Section 4.2. + This step uses the current rollover counter, the authentication + + + + + +Baugher, et al. Standards Track [Page 11] + +RFC 3711 SRTP March 2004 + + + algorithm indicated in the cryptographic context, and the session + authentication key found in Step 4. Append the authentication tag + to the packet. + + 8. If necessary, update the ROC as in Section 3.3.1, using the packet + index determined in Step 2. + + To authenticate and decrypt an SRTP packet, the receiver SHALL do the + following: + + 1. Determine which cryptographic context to use as described in + Section 3.2.3. + + 2. Run the algorithm in Section 3.3.1 to get the index of the SRTP + packet. The algorithm uses the rollover counter and highest + sequence number in the cryptographic context with the sequence + number in the SRTP packet, as described in Section 3.3.1. + + 3. Determine the master key and master salt. If the MKI indicator in + the context is set to one, use the MKI in the SRTP packet, + otherwise use the index from the previous step, according to + Section 8.1. + + 4. Determine the session keys, and session salt (if used by the + transform) as described in Section 4.3, using master key, master + salt, key_derivation_rate and session key-lengths in the + cryptographic context with the index, determined in Steps 2 and 3. + + 5. For message authentication and replay protection, first check if + the packet has been replayed (Section 3.3.2), using the Replay + List and the index as determined in Step 2. If the packet is + judged to be replayed, then the packet MUST be discarded, and the + event SHOULD be logged. + + Next, perform verification of the authentication tag, using the + rollover counter from Step 2, the authentication algorithm + indicated in the cryptographic context, and the session + authentication key from Step 4. If the result is "AUTHENTICATION + FAILURE" (see Section 4.2), the packet MUST be discarded from + further processing and the event SHOULD be logged. + + 6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for + the defined ciphers), using the decryption algorithm indicated in + the cryptographic context, the session encryption key and salt (if + used) found in Step 4 with the index from Step 2. + + + + + + +Baugher, et al. Standards Track [Page 12] + +RFC 3711 SRTP March 2004 + + + 7. Update the rollover counter and highest sequence number, s_l, in + the cryptographic context as in Section 3.3.1, using the packet + index estimated in Step 2. If replay protection is provided, also + update the Replay List as described in Section 3.3.2. + + 8. When present, remove the MKI and authentication tag fields from + the packet. + +3.3.1. Packet Index Determination, and ROC, s_l Update + + SRTP implementations use an "implicit" packet index for sequencing, + i.e., not all of the index is explicitly carried in the SRTP packet. + For the pre-defined transforms, the index i is used in replay + protection (Section 3.3.2), encryption (Section 4.1), message + authentication (Section 4.2), and for the key derivation (Section + 4.3). + + When the session starts, the sender side MUST set the rollover + counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps + modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 + (see security aspects below). The sender's packet index is then + defined as + + i = 2^16 * ROC + SEQ. + + Receiver-side implementations use the RTP sequence number to + determine the correct index of a packet, which is the location of the + packet in the sequence of all SRTP packets. A robust approach for + the proper use of a rollover counter requires its handling and use to + be well defined. In particular, out-of-order RTP packets with + sequence numbers close to 2^16 or zero must be properly handled. + + The index estimate is based on the receiver's locally maintained ROC + and s_l values. At the setup of the session, the ROC MUST be set to + zero. Receivers joining an on-going session MUST be given the + current ROC value using out-of-band signaling such as key-management + signaling. Furthermore, the receiver SHALL initialize s_l to the RTP + sequence number (SEQ) of the first observed SRTP packet (unless the + initial value is provided by out of band signaling such as key + management). + + On consecutive SRTP packets, the receiver SHOULD estimate the index + as + i = 2^16 * v + SEQ, + + where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) + such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC + + s_l (see Appendix A for pseudocode). + + + +Baugher, et al. Standards Track [Page 13] + +RFC 3711 SRTP March 2004 + + + After the packet has been processed and authenticated (when enabled + for SRTP packets for the session), the receiver MUST use v to + conditionally update its s_l and ROC variables as follows. If + v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC, + then s_l is set to SEQ if and only if SEQ is larger than the current + s_l; there is no change to ROC. If v=(ROC+1) mod 2^32, then s_l is + set to SEQ and ROC is set to v. + + After a re-keying occurs (changing to a new master key), the rollover + counter always maintains its sequence of values, i.e., it MUST NOT be + reset to zero. + + As the rollover counter is 32 bits long and the sequence number is 16 + bits long, the maximum number of packets belonging to a given SRTP + stream that can be secured with the same key is 2^48 using the pre- + defined transforms. After that number of SRTP packets have been sent + with a given (master or session) key, the sender MUST NOT send any + more packets with that key. (There exists a similar limit for SRTCP, + which in practice may be more restrictive, see Section 9.2.) This + limitation enforces a security benefit by providing an upper bound on + the amount of traffic that can pass before cryptographic keys are + changed. Re-keying (see Section 8.1) MUST be triggered, before this + amount of traffic, and MAY be triggered earlier, e.g., for increased + security and access control to media. Recurring key derivation by + means of a non-zero key_derivation_rate (see Section 4.3), also gives + stronger security but does not change the above absolute maximum + value. + + On the receiver side, there is a caveat to updating s_l and ROC: if + message authentication is not present, neither the initialization of + s_l, nor the ROC update can be made completely robust. The + receiver's "implicit index" approach works for the pre-defined + transforms as long as the reorder and loss of the packets are not too + great and bit-errors do not occur in unfortunate ways. In + particular, 2^15 packets would need to be lost, or a packet would + need to be 2^15 packets out of sequence before synchronization is + lost. Such drastic loss or reorder is likely to disrupt the RTP + application itself. + + The algorithm for the index estimate and ROC update is a matter of + implementation, and should take into consideration the environment + (e.g., packet loss rate) and the cases when synchronization is likely + to be lost, e.g., when the initial sequence number (randomly chosen + by RTP) is not known in advance (not sent in the key management + protocol) but may be near to wrap modulo 2^16. + + + + + + +Baugher, et al. Standards Track [Page 14] + +RFC 3711 SRTP March 2004 + + + A more elaborate and more robust scheme than the one given above is + the handling of RTP's own "rollover counter", see Appendix A.1 of + [RFC3550]. + +3.3.2. Replay Protection + + Secure replay protection is only possible when integrity protection + is present. It is RECOMMENDED to use replay protection, both for RTP + and RTCP, as integrity protection alone cannot assure security + against replay attacks. + + A packet is "replayed" when it is stored by an adversary, and then + re-injected into the network. When message authentication is + provided, SRTP protects against such attacks through a Replay List. + Each SRTP receiver maintains a Replay List, which conceptually + contains the indices of all of the packets which have been received + and authenticated. In practice, the list can use a "sliding window" + approach, so that a fixed amount of storage suffices for replay + protection. Packet indices which lag behind the packet index in the + context by more than SRTP-WINDOW-SIZE can be assumed to have been + received, where SRTP-WINDOW-SIZE is a receiver-side, implementation- + dependent parameter and MUST be at least 64, but which MAY be set to + a higher value. + + The receiver checks the index of an incoming packet against the + replay list and the window. Only packets with index ahead of the + window, or, inside the window but not already received, SHALL be + accepted. + + After the packet has been authenticated (if necessary the window is + first moved ahead), the replay list SHALL be updated with the new + index. + + The Replay List can be efficiently implemented by using a bitmap to + represent which packets have been received, as described in the + Security Architecture for IP [RFC2401]. + +3.4. Secure RTCP + + Secure RTCP follows the definition of Secure RTP. SRTCP adds three + mandatory new fields (the SRTCP index, an "encrypt-flag", and the + authentication tag) and one optional field (the MKI) to the RTCP + packet definition. The three mandatory fields MUST be appended to an + RTCP packet in order to form an equivalent SRTCP packet. The added + fields follow any other profile-specific extensions. + + + + + + +Baugher, et al. Standards Track [Page 15] + +RFC 3711 SRTP March 2004 + + + According to Section 6.1 of [RFC3550], there is a REQUIRED packet + format for compound packets. SRTCP MUST be given packets according + to that requirement in the sense that the first part MUST be a sender + report or a receiver report. However, the RTCP encryption prefix (a + random 32-bit quantity) specified in that Section MUST NOT be used + since, as is stated there, it is only applicable to the encryption + method specified in [RFC3550] and is not needed by the cryptographic + mechanisms used in SRTP. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ + |V=2|P| RC | PT=SR or RR | length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | SSRC of sender | | + +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | + | ~ sender info ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | ~ report block 1 ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | ~ report block 2 ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | ~ ... ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | |V=2|P| SC | PT=SDES=202 | length | | + | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | + | | SSRC/CSRC_1 | | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | ~ SDES items ~ | + | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | + | ~ ... ~ | + +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | + | |E| SRTCP index | | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ + | ~ SRTCP MKI (OPTIONAL) ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | : authentication tag : | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + +-- Encrypted Portion Authenticated Portion -----+ + + + Figure 2. An example of the format of a Secure RTCP packet, + consisting of an underlying RTCP compound packet with a Sender Report + and SDES packet. + + + + + + +Baugher, et al. Standards Track [Page 16] + +RFC 3711 SRTP March 2004 + + + The Encrypted Portion of an SRTCP packet consists of the encryption + (Section 4.1) of the RTCP payload of the equivalent compound RTCP + packet, from the first RTCP packet, i.e., from the ninth (9) octet to + the end of the compound packet. The Authenticated Portion of an + SRTCP packet consists of the entire equivalent (eventually compound) + RTCP packet, the E flag, and the SRTCP index (after any encryption + has been applied to the payload). + + The added fields are: + + E-flag: 1 bit, REQUIRED + The E-flag indicates if the current SRTCP packet is + encrypted or unencrypted. Section 9.1 of [RFC3550] allows + the split of a compound RTCP packet into two lower-layer + packets, one to be encrypted and one to be sent in the + clear. The E bit set to "1" indicates encrypted packet, and + "0" indicates non-encrypted packet. + + SRTCP index: 31 bits, REQUIRED + The SRTCP index is a 31-bit counter for the SRTCP packet. + The index is explicitly included in each packet, in contrast + to the "implicit" index approach used for SRTP. The SRTCP + index MUST be set to zero before the first SRTCP packet is + sent, and MUST be incremented by one, modulo 2^31, after + each SRTCP packet is sent. In particular, after a re-key, + the SRTCP index MUST NOT be reset to zero again. + + Authentication Tag: configurable length, REQUIRED + The authentication tag is used to carry message + authentication data. + + MKI: configurable length, OPTIONAL + The MKI is the Master Key Indicator, and functions according + to the MKI definition in Section 3. + + SRTCP uses the cryptographic context parameters and packet processing + of SRTP by default, with the following changes: + + * The receiver does not need to "estimate" the index, as it is + explicitly signaled in the packet. + + * Pre-defined SRTCP encryption is as specified in Section 4.1, but + using the definition of the SRTCP Encrypted Portion given in this + section, and using the SRTCP index as the index i. The encryption + transform and related parameters SHALL by default be the same + selected for the protection of the associated SRTP stream(s), + while the NULL algorithm SHALL be applied to the RTCP packets not + to be encrypted. SRTCP may have a different encryption transform + + + +Baugher, et al. Standards Track [Page 17] + +RFC 3711 SRTP March 2004 + + + than the one used by the corresponding SRTP. The expected use for + this feature is when the former has NULL-encryption and the latter + has a non NULL-encryption. + + The E-flag is assigned a value by the sender depending on whether the + packet was encrypted or not. + + * SRTCP decryption is performed as in Section 4, but only if the E + flag is equal to 1. If so, the Encrypted Portion is decrypted, + using the SRTCP index as the index i. In case the E-flag is 0, + the payload is simply left unmodified. + + * SRTCP replay protection is as defined in Section 3.3.2, but using + the SRTCP index as the index i and a separate Replay List that is + specific to SRTCP. + + * The pre-defined SRTCP authentication tag is specified as in + Section 4.2, but with the Authenticated Portion of the SRTCP + packet given in this section (which includes the index). The + authentication transform and related parameters (e.g., key size) + SHALL by default be the same as selected for the protection of the + associated SRTP stream(s). + + * In the last step of the processing, only the sender needs to + update the value of the SRTCP index by incrementing it modulo 2^31 + and for security reasons the sender MUST also check the number of + SRTCP packets processed, see Section 9.2. + + Message authentication for RTCP is REQUIRED, as it is the control + protocol (e.g., it has a BYE packet) for RTP. + + Precautions must be taken so that the packet expansion in SRTCP (due + to the added fields) does not cause SRTCP messages to use more than + their share of RTCP bandwidth. To avoid this, the following two + measures MUST be taken: + + 1. When initializing the RTCP variable "avg_rtcp_size" defined in + chapter 6.3 of [RFC3550], it MUST include the size of the fields + that will be added by SRTCP (index, E-bit, authentication tag, and + when present, the MKI). + + 2. When updating the "avg_rtcp_size" using the variable "packet_size" + (section 6.3.3 of [RFC3550]), the value of "packet_size" MUST + include the size of the additional fields added by SRTCP. + + + + + + + +Baugher, et al. Standards Track [Page 18] + +RFC 3711 SRTP March 2004 + + + With these measures in place the SRTCP messages will not use more + than the allotted bandwidth. The effect of the size of the added + fields on the SRTCP traffic will be that messages will be sent with + longer packet intervals. The increase in the intervals will be + directly proportional to size of the added fields. For the pre- + defined transforms, the size of the added fields will be at least 14 + octets, and upper bounded depending on MKI and the authentication tag + sizes. + +4. Pre-Defined Cryptographic Transforms + + While there are numerous encryption and message authentication + algorithms that can be used in SRTP, below we define default + algorithms in order to avoid the complexity of specifying the + encodings for the signaling of algorithm and parameter identifiers. + The defined algorithms have been chosen as they fulfill the goals + listed in Section 2. Recommendations on how to extend SRTP with new + transforms are given in Section 6. + +4.1. Encryption + + The following parameters are common to both pre-defined, non-NULL, + encryption transforms specified in this section. + + * BLOCK_CIPHER-MODE indicates the block cipher used and its mode of + operation + * n_b is the bit-size of the block for the block cipher + * k_e is the session encryption key + * n_e is the bit-length of k_e + * k_s is the session salting key + * n_s is the bit-length of k_s + * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a + non-negative integer, specified by the message authentication code + in use. + + The distinct session keys and salts for SRTP/SRTCP are by default + derived as specified in Section 4.3. + + The encryption transforms defined in SRTP map the SRTP packet index + and secret key into a pseudo-random keystream segment. Each + keystream segment encrypts a single RTP packet. The process of + encrypting a packet consists of generating the keystream segment + corresponding to the packet, and then bitwise exclusive-oring that + keystream segment onto the payload of the RTP packet to produce the + Encrypted Portion of the SRTP packet. In case the payload size is + not an integer multiple of n_b bits, the excess (least significant) + bits of the keystream are simply discarded. Decryption is done the + same way, but swapping the roles of the plaintext and ciphertext. + + + +Baugher, et al. Standards Track [Page 19] + +RFC 3711 SRTP March 2004 + + + +----+ +------------------+---------------------------------+ + | KG |-->| Keystream Prefix | Keystream Suffix |---+ + +----+ +------------------+---------------------------------+ | + | + +---------------------------------+ v + | Payload of RTP Packet |->(*) + +---------------------------------+ | + | + +---------------------------------+ | + | Encrypted Portion of SRTP Packet|<--+ + +---------------------------------+ + + Figure 3: Default SRTP Encryption Processing. Here KG denotes the + keystream generator, and (*) denotes bitwise exclusive-or. + + The definition of how the keystream is generated, given the index, + depends on the cipher and its mode of operation. Below, two such + keystream generators are defined. The NULL cipher is also defined, + to be used when encryption of RTP is not required. + + The SRTP definition of the keystream is illustrated in Figure 3. The + initial octets of each keystream segment MAY be reserved for use in a + message authentication code, in which case the keystream used for + encryption starts immediately after the last reserved octet. The + initial reserved octets are called the "keystream prefix" (not to be + confused with the "encryption prefix" of [RFC3550, Section 6.1]), and + the remaining octets are called the "keystream suffix". The + keystream prefix MUST NOT be used for encryption. The process is + illustrated in Figure 3. + + The number of octets in the keystream prefix is denoted as + SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive, + non-zero value of SRTP_PREFIX_LENGTH. This means that, even if + confidentiality is not to be provided, the keystream generator output + may still need to be computed for packet authentication, in which + case the default keystream generator (mode) SHALL be used. + + The default cipher is the Advanced Encryption Standard (AES) [AES], + and we define two modes of running AES, (1) Segmented Integer Counter + Mode AES and (2) AES in f8-mode. In the remainder of this section, + let E(k,x) be AES applied to key k and input block x. + + + + + + + + + + +Baugher, et al. Standards Track [Page 20] + +RFC 3711 SRTP March 2004 + + +4.1.1. AES in Counter Mode + + Conceptually, counter mode [AES-CTR] consists of encrypting + successive integers. The actual definition is somewhat more + complicated, in order to randomize the starting point of the integer + sequence. Each packet is encrypted with a distinct keystream + segment, which SHALL be computed as follows. + + A keystream segment SHALL be the concatenation of the 128-bit output + blocks of the AES cipher in the encrypt direction, using key k = k_e, + in which the block indices are in increasing order. Symbolically, + each keystream segment looks like + + E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ... + + where the 128-bit integer value IV SHALL be defined by the SSRC, the + SRTP packet index i, and the SRTP session salting key k_s, as below. + + IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16) + + Each of the three terms in the XOR-sum above is padded with as many + leading zeros as needed to make the operation well-defined, + considered as a 128-bit value. + + The inclusion of the SSRC allows the use of the same key to protect + distinct SRTP streams within the same RTP session, see the security + caveats in Section 9.1. + + In the case of SRTCP, the SSRC of the first header of the compound + packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s + SHALL be replaced by the SRTCP encryption session key and salt. + + Note that the initial value, IV, is fixed for each packet and is + formed by "reserving" 16 zeros in the least significant bits for the + purpose of the counter. The number of blocks of keystream generated + for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream + re-use, see below. The AES has a block size of 128 bits, so 2^16 + output blocks are sufficient to generate the 2^23 bits of keystream + needed to encrypt the largest possible RTP packet (except for IPv6 + "jumbograms" [RFC2675], which are not likely to be used for RTP-based + multimedia traffic). This restriction on the maximum bit-size of the + packet that can be encrypted ensures the security of the encryption + method by limiting the effectiveness of probabilistic attacks [BDJR]. + + For a particular Counter Mode key, each IV value used as an input + MUST be distinct, in order to avoid the security exposure of a two- + time pad situation (Section 9.1). To satisfy this constraint, an + implementation MUST ensure that the combination of the SRTP packet + + + +Baugher, et al. Standards Track [Page 21] + +RFC 3711 SRTP March 2004 + + + index of ROC || SEQ, and the SSRC used in the construction of the IV + are distinct for any particular key. The failure to ensure this + uniqueness could be catastrophic for Secure RTP. This is in contrast + to the situation for RTP itself, which may be able to tolerate such + failures. It is RECOMMENDED that, if a dedicated security module is + present, the RTP sequence numbers and SSRC either be generated or + checked by that module (i.e., sequence-number and SSRC processing in + an SRTP system needs to be protected as well as the key). + +4.1.2. AES in f8-mode + + To encrypt UMTS (Universal Mobile Telecommunications System, as 3G + networks) data, a solution (see [f8-a] [f8-b]) known as the f8- + algorithm has been developed. On a high level, the proposed scheme + is a variant of Output Feedback Mode (OFB) [HAC], with a more + elaborate initialization and feedback function. As in normal OFB, + the core consists of a block cipher. We also define here the use of + AES as a block cipher to be used in what we shall call "f8-mode of + operation" RTP encryption. The AES f8-mode SHALL use the same + default sizes for session key and salt as AES counter mode. + + Figure 4 shows the structure of block cipher, E, running in f8-mode. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Baugher, et al. Standards Track [Page 22] + +RFC 3711 SRTP March 2004 + + + IV + | + v + +------+ + | | + +--->| E | + | +------+ + | | + m -> (*) +-----------+-------------+-- ... ------+ + | IV' | | | | + | | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*) + | | | | | + | | +-> (*) +-> (*) ... +-> (*) + | | | | | | | | + | v | v | v | v + | +------+ | +------+ | +------+ | +------+ + k_e ---+--->| E | | | E | | | E | | | E | + | | | | | | | | | | | + +------+ | +------+ | +------+ | +------+ + | | | | | | | + +------+ +--------+ +-- ... ----+ | + | | | | + v v v v + S(0) S(1) S(2) . . . S(L-1) + + Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). + The figure represents the KG in Figure 3, when AES-f8 is used. + +4.1.2.1. f8 Keystream Generation + + The Initialization Vector (IV) SHALL be determined as described in + Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP). + + Let IV', S(j), and m denote n_b-bit blocks. The keystream, + S(0) ||... || S(L-1), for an N-bit message SHALL be defined by + setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0. For + j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it + is not already an integer) compute + + S(j) = E(k_e, IV' XOR j XOR S(j-1)) + + Notice that the IV is not used directly. Instead it is fed through E + under another key to produce an internal, "masked" value (denoted + IV') to prevent an attacker from gaining known input/output pairs. + + + + + + + +Baugher, et al. Standards Track [Page 23] + +RFC 3711 SRTP March 2004 + + + The role of the internal counter, j, is to prevent short keystream + cycles. The value of the key mask m SHALL be + + m = k_s || 0x555..5, + + i.e., the session salting key, appended by the binary pattern 0101.. + to fill out the entire desired key size, n_e. + + The sender SHOULD NOT generate more than 2^32 blocks, which is + sufficient to generate 2^39 bits of keystream. Unlike counter mode, + there is no absolute threshold above (below) which f8 is guaranteed + to be insecure (secure). The above bound has been chosen to limit, + with sufficient security margin, the probability of degenerative + behavior in the f8 keystream generation. + +4.1.2.2. f8 SRTP IV Formation + + The purpose of the following IV formation is to provide a feature + which we call implicit header authentication (IHA), see Section 9.5. + + The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following + way: + + IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC + + M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from + the cryptographic context. + + The presence of the SSRC as part of the IV allows AES-f8 to be used + when a master key is shared between multiple streams within the same + RTP session, see Section 9.1. + +4.1.2.3. f8 SRTCP IV Formation + + The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the + following way: + + IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC + + where V, P, RC, PT, length, SSRC SHALL be taken from the first header + in the RTCP compound packet. E and SRTCP index are the 1-bit and + 31-bit fields added to the packet. + + + + + + + + + +Baugher, et al. Standards Track [Page 24] + +RFC 3711 SRTP March 2004 + + +4.1.3. NULL Cipher + + The NULL cipher is used when no confidentiality for RTP/RTCP is + requested. The keystream can be thought of as "000..0", i.e., the + encryption SHALL simply copy the plaintext input into the ciphertext + output. + +4.2. Message Authentication and Integrity + + Throughout this section, M will denote data to be integrity + protected. In the case of SRTP, M SHALL consist of the Authenticated + Portion of the packet (as specified in Figure 1) concatenated with + the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M + SHALL consist of the Authenticated Portion (as specified in Figure 2) + only. + + Common parameters: + + * AUTH_ALG is the authentication algorithm + * k_a is the session message authentication key + * n_a is the bit-length of the authentication key + * n_tag is the bit-length of the output authentication tag + * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as + defined above, a parameter of AUTH_ALG + + The distinct session authentication keys for SRTP/SRTCP are by + default derived as specified in Section 4.3. + + The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for + any particular fixed value of the key. + + We describe the process of computing authentication tags as follows. + The sender computes the tag of M and appends it to the packet. The + SRTP receiver verifies a message/authentication tag pair by computing + a new authentication tag over M using the selected algorithm and key, + and then compares it to the tag associated with the received message. + If the two tags are equal, then the message/tag pair is valid; + otherwise, it is invalid and the error audit message "AUTHENTICATION + FAILURE" MUST be returned. + +4.2.1. HMAC-SHA1 + + The pre-defined authentication transform for SRTP is HMAC-SHA1 + [RFC2104]. With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL + be 0. For SRTP (respectively SRTCP), the HMAC SHALL be applied to + the session authentication key and M as specified above, i.e., + HMAC(k_a, M). The HMAC output SHALL then be truncated to the n_tag + left-most bits. + + + +Baugher, et al. Standards Track [Page 25] + +RFC 3711 SRTP March 2004 + + +4.3. Key Derivation + +4.3.1. Key Derivation Algorithm + + Regardless of the encryption or message authentication transform that + is employed (it may be an SRTP pre-defined transform or newly + introduced according to Section 6), interoperable SRTP + implementations MUST use the SRTP key derivation to generate session + keys. Once the key derivation rate is properly signaled at the start + of the session, there is no need for extra communication between the + parties that use SRTP key derivation. + + packet index ---+ + | + v + +-----------+ master +--------+ session encr_key + | ext | key | |----------> + | key mgmt |-------->| key | session auth_key + | (optional | | deriv |----------> + | rekey) |-------->| | session salt_key + | | master | |----------> + +-----------+ salt +--------+ + + Figure 5: SRTP key derivation. + + At least one initial key derivation SHALL be performed by SRTP, i.e., + the first key derivation is REQUIRED. Further applications of the + key derivation MAY be performed, according to the + "key_derivation_rate" value in the cryptographic context. The key + derivation function SHALL initially be invoked before the first + packet and then, when r > 0, a key derivation is performed whenever + index mod r equals zero. This can be thought of as "refreshing" the + session keys. The value of "key_derivation_rate" MUST be kept fixed + for the lifetime of the associated master key. + + Interoperable SRTP implementations MAY also derive session salting + keys for encryption transforms, as is done in both of the pre- + defined transforms. + + Let m and n be positive integers. A pseudo-random function family is + a set of keyed functions {PRF_n(k,x)} such that for the (secret) + random key k, given m-bit x, PRF_n(k,x) is an n-bit string, + computationally indistinguishable from random n-bit strings, see + [HAC]. For the purpose of key derivation in SRTP, a secure PRF with + m = 128 (or more) MUST be used, and a default PRF transform is + defined in Section 4.3.3. + + + + + +Baugher, et al. Standards Track [Page 26] + +RFC 3711 SRTP March 2004 + + + Let "a DIV t" denote integer division of a by t, rounded down, and + with the convention that "a DIV 0 = 0" for all a. We also make the + convention of treating "a DIV t" as a bit string of the same length + as a, and thus "a DIV t" will in general have leading zeros. + + Key derivation SHALL be defined as follows in terms of