Internet Engineering Task Force Baugher, McGrew, AVT Working Group Oran (Cisco) INTERNET-DRAFT Blom, Carrara, Naslund, EXPIRES: July 2002 Norrman (Ericsson) February 2002 The Secure Real Time Transport Protocol Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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/RTCP traffic. SRTP can achieve high throughput and low packet expansion. SRTP proves to be a suitable protection for heterogeneous environments, i.e., environments including both wired and wireless links. 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). INTERNET-DRAFT SRTP February, 2002 TABLE OF CONTENTS 1. Notational Conventions............................................3 2. Goals.............................................................3 3. SRTP Framework....................................................4 3.1 SRTP Cryptographic Contexts.....................................5 3.1.1 Transform-independent parameters............................6 3.1.2 Transform-dependent parameters..............................7 3.1.3 Mapping SRTP Packets to Cryptographic Contexts..............8 3.2 SRTP Packet Processing..........................................8 3.2.1 Packet Index Determination, and ROC, s_l Update............10 3.2.2 Replay Protection..........................................12 3.3 Secure RTCP....................................................12 4. Pre-Defined Cryptographic Transforms.............................16 4.1 Encryption.....................................................16 4.1.1 AES in Counter Mode........................................18 4.1.2 AES in f8-mode.............................................19 4.1.3 NULL Cipher................................................21 4.2 Message Authentication and Integrity...........................21 4.2.1. HMAC/SHA1.................................................22 4.2.2 TMMH.......................................................22 4.3 Key Derivation.................................................25 4.3.1 Key Derivation Algorithm...................................25 4.3.2 SRTCP Key Derivation.......................................27 4.3.3 AES-CM PRF.................................................27 5. Default and Mandatory Transforms.................................27 5.1 Encryption: AES-CM and NULL....................................27 5.2 Message Authentication/Integrity: HMAC/SHA1....................27 5.3 Key Derivation: AES-CM PRF.....................................27 6. SRTP/SRTCP Parameters............................................28 7. Adding SRTP Transforms...........................................28 8. Rationale........................................................29 8.1 Key derivation.................................................29 8.2 Salting key....................................................29 8.3 TMMH: Message Integrity from Universal Hashing.................30 8.4 Data Origin Authentication Considerations......................30 9. Key Management Considerations....................................30 10. Security Considerations.........................................32 10.1 SSRC collision and two-time pad...............................32 10.2 Key Usage.....................................................33 10.3 Confidentiality of the RTP Payload............................34 10.4 Confidentiality of the RTP Header.............................34 10.5 Integrity of the RTP packet...................................35 10.5.1 Integrity of the RTP header: IHA..........................35 11. Interaction with Forward Error Correction mechanisms............36 12. Scenarios.......................................................36 12.1 Two-party Unicast.............................................37 12.1.1 One bi-directional RTP stream.............................37 12.1.2 One master key per party..................................37 12.2 Multicast.....................................................38 Baugher, et al. [Page 2] INTERNET-DRAFT SRTP February, 2002 12.2.1 Small conference with one sender..........................38 12.2.2 Large multicast with one sender...........................39 12.3 Re-keying and access control..................................39 12.4 Summary of basic scenarios....................................41 13. IANA Considerations.............................................41 14. Acknowledgements................................................41 15. Author's Addresses..............................................41 16. References......................................................42 Appendix A: Pseudocode for Index Determination......................44 Appendix B: Test Vectors............................................44 B.1 AES-f8 Test Vectors............................................44 B.2 AES-CM Test Vectors............................................45 B.3 TMMH Test Vectors..............................................46 1. Notational Conventions The key words "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]. Terminology is conform to [RFC2828]. By convention, the left most bit (byte) 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. 2. Goals The security goals for SRTP are to ensure: * the confidentiality of the RTP and RTCP payloads, and * the integrity protection 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. 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: Baugher, et al. [Page 3] INTERNET-DRAFT SRTP February, 2002 * 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, and robustness to transmission bit-errors in the encrypted payload. These properties ensure that SRTP is a suitable protection scheme for RTP/RTCP in both wired and wireless scenarios. 3. SRTP Framework RTP is the Real Time Transport Protocol [RFC1889]. We define SRTP as a profile of RTP, in a way analogous to RFC1890 which defines the audio/video profile for RTP. Conceptually, we consider it to be a 'bump in the stack' implementation which resides between the RTP application and the transport layer, which intercepts RTP packets and then forwards an equivalent SRTP packet on the sending side, and which intercepts SRTP packets and passes an equivalent RTP packet up the stack on the receiving side. The format of an SRTP packet is illustrated in Figure 1. The Encrypted Portion of an SRTP packet consists of the encryption of the RTP payload of the equivalent RTP packet. (Our use of the word 'encryption' includes also the possibility of a 'NULL'- encryption.) The optional MKI and optional authentication tag are the only fields defined by SRTP that are not in RTP. Only 8-bit alignment is assumed. MKI (Master Key Identifier): variable 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.1.3. The MKI MAY be used by key management for the purposes of re-keying and identifies a particular master key within the cryptographic context, viz. Section 3.1.1. Authentication tag: variable length, optional Baugher, et al. [Page 4] INTERNET-DRAFT SRTP February, 2002 The authentication tag shall be 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, note that 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. 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 | | | | .... | +-+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SRTP MKI (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ authentication tag (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +- Encrypted Portion +---- Authenticated Portion Figure 1. The format of an SRTP packet. 3.1 SRTP Cryptographic Contexts Each SRTP session requires the sender and receiver to maintain cryptographic state information. This information is called the cryptographic context. 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 cryptographically secure way. Baugher, et al. [Page 5] INTERNET-DRAFT SRTP February, 2002 3.1.1 Transform-independent parameters 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.2.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 is the last received sequence number (possibly authenticated, if authentication is provided), * an identifier for the encryption algorithm, i.e., the cipher and its mode of operation, and related parameters (when encryption is provided), * an identifier for the message authentication algorithm, and related parameters (when authentication is provided), * a replay list, maintained by the receiver only (when authentication and replay protection are provided), containing indexes of recently received and authenticated SRTP packets, * an 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 bytes) of the MKI field, and (for the sender) the actual value of the currently active MKI, (the value of the last three MKI-related parameters above MUST be kept fixed for the life-time of the context) * the master key(s), * for each master key, means to maintain a count of the number of SRTP packets that has been processed with that master key (essential for security, see Sections 3.2.1 and 10), either in the form of an explicit counter, or, the value of the first SRTP index for which the key was used, * non-negative integers n_e, and n_a, determining the length of the session keys for encryption, and message authentication. Baugher, et al. [Page 6] INTERNET-DRAFT SRTP February, 2002 The master key(s) MUST be random and kept secret. In addition, for each master key, SRTP MAY choose to specify 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 10.2. A 'NULL'- salt is treated as 00...0. * an integer in the set {1,2,4,...,2^16}, the 'key_derivation_rate', where an unspecified value is treated as zero, * if the MKI-indicator is one, the actual MKI value for which the master key is valid, * <'From', 'To'> 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. These values are absolute quantities, not relative. SRTCP by default uses the same cryptographic context parameters, except: * no rollover counter or s_l-value needs 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 (c.f. above). Note in particular that the master key(s) MAY be shared between SRTP and SRTCP, if the pre-defined transforms (including the key derivation) are used but the session key(s) MUST NOT be so shared. 3.1.2 Transform-dependent parameters All encryption, authentication/integrity, and key derivation parameters are defined in the Transforms section dedicated to the particular encryption, authentication, or key derivation transform (see Section 4). Typical examples of such parameters are block size of ciphers, session keys, data for IV formation, etc. We note again (it cannot be stressed enough) that SRTP and SRTCP MUST use distinct (pseudo-)random session keys. Future SRTP transform specifications MUST include a section to list the additional cryptographic context's parameters for that transform, if any. Baugher, et al. [Page 7] INTERNET-DRAFT SRTP February, 2002 3.1.3 Mapping SRTP Packets to Cryptographic Contexts Recall that an RTP session for each participant is defined [RFC1889] 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 current RTP packet (for the sender) or SRTP packet (for the receiver). It is assumed that, when presented with this information, the key management returns a context with the information as described in Section 3.1. As noted above, SRTP and SRTCP by default shares 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 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. If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded from further processing. 3.2 SRTP Packet Processing The following applies to SRTP. SRTCP is described in Section 3.3. Assuming initialization of the cryptographic context(s) has taken place via key management, and as described in Section 3.2.1, to construct a proper SRTP packet, given an RTP packet, the sender has to do the following: 1. Determine which cryptographic context to use as described in Section 3.1.3. Baugher, et al. [Page 8] INTERNET-DRAFT SRTP February, 2002 2. Determine the index of the SRTP packet as described in Section 3.2.1, using the rollover counter in the cryptographic context and the sequence number in the RTP packet. 3. Determine the master key and master salt. If the MKI indicator in the context is set to one, this is done using the current MKI in the cryptographic context, otherwise, the index determined in the previous step is used. 4. Determine the session keys and 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 and the index, determined in Steps 2 and 3. 5. If encryption is provided, encrypt the RTP payload to produce the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers), using the encryption algorithm indicated in the cryptographic context, the session encryption key and salt (if used) found in Step 4, and the index found in Step 2. 6. If the MKI indicator is set to one, append the MKI to the packet. 7. If message authentication is provided, compute the authentication tag for the Authenticated Portion of the packet, as described in Section 4.2, using the current rollover counter (if used by the transform), the authentication 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.2.1, using the packet index determined in Step 2. To authenticate and decrypt a SRTP packet, the receiver has to do the following: 1. Determine which cryptographic context to use as described in Section 3.1.3. 2. Estimate the index of the SRTP packet from the rollover counter in the cryptographic context and the sequence number in the SRTP packet, as described in Section 3.2.1. 3. Determine the master key and master salt. If the MKI indicator in the context is set to one, this is done using the MKI in the SRTP packet, otherwise, the index from the previous step is used. 4. Determine the session keys, and session salt (if used by the transform) as described in Section 4.3, using master key, key_derivation_rate and session key-lengths in the cryptographic context and the index, determined in Steps 2 and 3. Baugher, et al. [Page 9] INTERNET-DRAFT SRTP February, 2002 5. If message authentication and replay protection are provided, first check if the packet has been replayed, as described in Section 3.2.2, using the Replay List in the context 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 index (rollover counter when used by the transform) 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. If encryption is provided, 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 found in Step 4, and the index from Step 2. 7. Update the rollover counter and last sequence number, s_l, in the cryptographic context as in Section 3.2.1, using the packet index estimated in Step 2. If replay protection is provided, also update the Replay List as described in Section 3.2.2. 8. When applicable, delete the MKI and authetication tag fields from the packet. 3.2.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, as described below. For the pre-defined transforms, the index i is used in replay protection (Section 3.2.3), encryption and message authentication (Sections 4.1 and 4.2), and for the key derivation (Section 4.3). It MAY also be used to determine the correct master key as indicated above. 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 estimate the correct index. That is, estimating the location in the sequence of all SRTP packets. Here, the index is defined as 2^16 * v + SEQ, where the RTP sequence number is SEQ, and v is an estimate for the current value of the rollover counter, ROC. This estimate is Baugher, et al. [Page 10] INTERNET-DRAFT SRTP February, 2002 based on SEQ, a previous estimate for ROC and the value s_l. The latter two are maintained locally by the receiver as described below. A robust approach for the proper use of a rollover counter for the pre-defined transforms 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 dealt with. Initially, the receiver MUST be given the current ROC value from the sender using out of band signaling (or ROC is zero at the beginning of the session), see Section 9. Furthermore, the receiver SHALL initialize s_l to the RTP sequence number (SEQ) of the first observed SRTP packet. On consecutive SRTP packets, the receiver MAY 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. After the packet has been processed using the estimated index, the receiver MUST decide if s_l and ROC should be updated. For instance, a simple (but not error robust) method is to simply set s_l to SEQ and, if the value v = ROC+1 was used, to update ROC to v. Caveat: if message authentication is not present, neither the initialization of s_l, nor the ROC update can be made completely robust on the receiving side. After a re-keying (changing to a new master key) occurs, the roll- over counter maintains its sequence of values, i.e., it MUST NOT be reset to zero, to avoid inconsistencies in key life-times. As the rollover counter is 32 bits long and the sequence number is 16 bits long, the maximum number of packets that can be secured with the same key is 2^48 using the pre-define 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 3.3 and the summary in Section 10.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 9) MUST be triggered, before this amount of traffic, and MAY be triggered earlier, e.g., for increased security and access control to media. Re-occurring key derivation, as determined by a non-zero key_derivation_rate (see Section 4.3), also gives stronger security, Baugher, et al. [Page 11] INTERNET-DRAFT SRTP February, 2002 but does not change the above absolute maximum value, i.e. the master key shall still be used for a maximum of 2^48 SRTP packets (or 2^31 SRTCP packets, see below). 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 in order for synchronization to be lost. Such drastic loss or reorder is likely to disrupt the RTP application itself. 3.2.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. SRTP provides protection against such attacks whenever message authentication is provided, through the storage of the indices of the most recently received and authenticated packets. 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 (successfully) 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.3 Secure RTCP Baugher, et al. [Page 12] INTERNET-DRAFT SRTP February, 2002 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 | +-|>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SRTP 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 Report and SDES packet. Secure RTCP follows the definition of Secure RTP. SRTCP adds three new fields to the RTCP packet definition, the SRTCP index, an Baugher, et al. [Page 13] INTERNET-DRAFT SRTP February, 2002 'encrypt-flag', and the authentication tag. Those fields MUST be appended to an RTCP packet when at least integrity protection (which is mandatory) is applied to the RTCP packet, in order to form an equivalent SRTCP packet, so that the added fields follow any other profile specific extensions. SRTCP adds an optional fourth field, the MKI, which functions according ot the MKI definition in section 3. An SRTCP packet is illustrated in Figure 2. According to [RFC1889] there is a 'recommended' packet format for compound packets. SRTCP MUST be given packets according to that recommendation in the sense that the first part MUST be a send/receive report. However, the so-called encryption prefix (Section 6.1 of [RFC1889]), a random 32-bit quantity intended to deter known plaintext attacks, MUST NOT be used (see below). The Encrypted Portion of an SRTCP packet consists of the encryption of the RTCP payload of the equivalent compound RTCP packet, from the first RTCP packet, i.e., from the ninth (9) byte 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, SRTCP index (after any encryption has been applied to the payload). The added fields are: E-flag: 1 bit, mandatory The E-flag indicates if the current SRTCP packet is encrypted or unencrypted. Section 9.1 of [RFC1889] 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, mandatory 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 (c.f. Section 3.2.1). Authentication Tag: variable length, mandatory The authentication tag shall be used to carry message authentication data. The optional field is the variable-length MKI (see Section 3). SRTCP uses the cryptographic context parameters and packet processing of SRTP, with the following changes: Baugher, et al. [Page 14] INTERNET-DRAFT SRTP February, 2002 * The receiver need not to 'estimate' the index, as it is explicitly signaled in the packet. * If the MKI indicator in the cryptographic context is zero, the master keys is determined by the current SRTP index, even though SRTCP has its own index. Since the SRTCP source as with any SSRC in an SRTP session has its own sequence number space, the master key lifetime MUST be based on the SRTP master key lifetime. The concomitant re-keying issues are discussed in sections 9 and 10. * Pre-defined SRTCP encryption is as defined in Section 4, but using the definition of the SRTCP Encrypted Portion as defined 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. Note that the master key and salt is shared between SRTP and SRTCP, but the (encryption) session key and salt will be distinct due to the key derivation definition (Section 4.3). The E-flag is assigned values 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.2.3, but using the SRTCP index as the index i, and as noted maintains a separate replay list specific to SRTCP. * The pre-defined SRTCP authentication tag is defined as in Section 4, but with the Authenticated Portion of the SRTCP packet defined 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). (Exception: when SRTP is not authenticated, the default authentication transform MUST be used for SRTCP.) Note that the master key is shared between SRTP and SRTCP, but the (authentication) session key will be distinct due to the key derivation definition (Section 4.3). * 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 RTCP packets processed, see below). There MAY also exist some minor transform specific changes, see Section 4 for the defined transforms. Baugher, et al. [Page 15] INTERNET-DRAFT SRTP February, 2002 As noted, the encryption prefix (Section 6.1 of [RFC1889]), is not to be used because this mechanism supports ciphers that are not secure against known plaintext attacks. Ciphers that are not secure against known-plaintext attacks SHOULD not be used to encrypt RTP messages. The pre-defined SRTP encryption uses a secure, additive stream cipher, and thus the prefix offers no benefit at all. The maximum number of SRTCP packets with a given session or master key is limited to 2^31. Due to for example re-keying, reaching this limit may or may not coincide with wrapping of the SRTCP index, and thus the sender MUST be able to deduce the packet count, e.g., as indicated before. Also, since the session keys for SRTP and SRTCP are by default derived from the same master key, new session and master keys for both protocols MUST be obtained before any of the two protocols reaches its maximum key-usage limit (c.f. 3.2.1). Message authentication for RTCP is REQUIRED, as it is the control protocol (e.g., it has a BYE packet). Note also that the cost in total bandwidth for RTCP authentication is not as high as the one of RTP authentication, as the recommended session bandwidth allocated to RTCP is at most 5% and the RTCP packets are less frequent. However, when adding authentication to RTCP, the overhead in bandwidth SHOULD be considered (the bandwidth will be more than 5%). Note however, that large-scale multicast application of SRTCP might require careful consideration in the configuration and use, see Section 12. The security risks that can occur wherever SRTCP is not used, MUST be taken seriously under consideration. 4. Pre-Defined Cryptographic Transforms While there are numerous encryption and message authentication algorithms that can be used in SRTP, we define below 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 7. 4.1 Encryption The following parameters are generic and common to all pre-defined, non-NULL, encryption transforms. * BLOCK CIPHER and mode are the block cipher used and its mode of operation (the default is AES in counter mode, see below) * n_b is the bit-size of the block for the block cipher * k_e is the session encrypting key * n_e is the bit-length of k_e (the default is 128 bits) * k_s is the so called session salting key Baugher, et al. [Page 16] INTERNET-DRAFT SRTP February, 2002 * n_s is the bit-length of k_s. n_s is at most n_b - 16 bits, and the default value is the maximum (n_b - 16). * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, an (at least) 8-bit non-negative integer, inferred from 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 use a 'seekable' segmented keystream generator (KG), which for each secret key maps the SRTP packet index into a pseudorandom keystream segment, used to encrypt 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. Decryption is done the same way, but swapping the roles of the plaintext and ciphertext. 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 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 so-called 'encryption prefix' of [RFC1889, Section 6.1]), and the remaining octets are called the keystream suffix. This process is illustrated in Figure 3. +----+ +------------------+---------------------------------+ | KG |-->| Keystream Prefix | Keystream Suffix |---+ +----+ +------------------+---------------------------------+ | | +---------------------------------+ v | Encrypted Portion 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 number of octets in the keystream prefix is denoted as Baugher, et al. [Page 17] INTERNET-DRAFT SRTP February, 2002 SRTP_PREFIX_LENGTH. The keystream prefix is reserved for use with certain message authentication transforms, such as the pre-defined TMMH transform (Section 4.2.2). The Prefix is indicated by a positive, non-zero value of this latter parameter. 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), and we define two modes of running AES, Segmented Integer Counter Mode AES and AES in f8-mode. In the sequel, let E(k,x) be AES applied to key k and input block x. AES has (default) n_e = 128-bit key size and (always) n_b = 128-bit block size. 4.1.1 AES in Counter Mode Conceptually, counter mode 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 is computed as follows. 4.1.1.1 Keystream Generation A keystream segment is 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) The inclusion of the SSRC allows the use of the same key to protect distinct SRTP streams. Exploiting such features is conditioned by requirements, see the security caveats in Section 10.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_s SHALL be replaced by the SRTCP session salt.) Note that the initial value, IV, is fixed for each packet. The number of blocks of keystream generated for any fixed value of IV MUST NOT exceed 2^16. 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 Baugher, et al. [Page 18] INTERNET-DRAFT SRTP February, 2002 '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]. 4.1.2 AES in f8-mode To encrypt UMTS (Universal Mobile Telecommunications System, as 3G networks) data, a solution (see [ES3D]) 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 f8-mode for RTP encryption, with default 128-bit key and block size. Figure 4 shows the structure of block cipher, E, running in what we shall call 'f8-mode of operation'. 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). Baugher, et al. [Page 19] INTERNET-DRAFT SRTP February, 2002 The figure represents the KG in Figure 3, when AES-f8 is used. 4.1.2.1 f8 Keystream Generation As above, let E(k_e,x) be the 128-bit output of AES in the encrypt direction when applied to the key k_e and n_b = 128-bit plaintext block x. The Initialization Vector (IV) is determined as described in Section 4.1.2.2. Let IV', S(j), and m denote n_b-bit blocks, determined below. The keystream, S(0) || ... || S(L-1), for an N-bit message is 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) 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. The role of the internal counter is to prevent short keystream cycles. The value of the key mask m is defined to 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 maximum allowable packet size can be determined as follows. The AES has a block size of 128 bits, and assuming that AES behaves like a random function, it is (heuristically) secure to generate somewhat less than 2^64 output blocks, we suggest a maximum of 2^32 blocks, which is sufficient to generate 2^39 bits of keystream. For practical sizes of the RTP packets, much fewer blocks are required though, and the counter j above will often be sufficient if implemented as a 16-bit counter. 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 10.5.1. The SRTP IV for 128-bit block AES-f8 is 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. Baugher, et al. [Page 20] INTERNET-DRAFT SRTP February, 2002 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, see Section 10.1. 4.1.2.3 f8 SRTCP IV Formation The SRTCP IV for 128-bit block AES-f8 is 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- and 31-bit fields added to the packet. 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", e.g., the encryption simply copies the plaintext input into the ciphertext output. 4.2 Message Authentication and Integrity Common parameters: * k_a is the session message authentication key * n_a is the bit-length of the authentication key (the default for the default transform is 128 bits) * n_tag is the bit-length of the output authentication tag (the default is 32 bits) * SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as defined above * M is the Authenticated Portion as specified in Section 3 for RTP and in Section 3.3 for RTCP. 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. Below we describe the process of computing authentication tags. The sender computes the tag of the Authenticated Portion and appends it to the packet. The SRTP receiver verifies a message/authentication tag pair as follows. A new authentication tag is computed over the Authenticated Portion using the selected algorithm and key, and it is compared to the tag associated with the received message. If the two tags are equal, then the message/tag pair is valid; otherwise, Baugher, et al. [Page 21] INTERNET-DRAFT SRTP February, 2002 it is invalid and the error audit message "AUTHENTICATION FAILURE" MUST be returned. 4.2.1. HMAC/SHA1 When HMAC/SHA1 is used, the SRTP_PREFIX_LENGTH is 0. For SRTP, the HMAC is applied to the concatenation of the Authenticated Portion of the packet (M) and the rollover counter in the cryptographic context, i.e. HMAC(k_a, M || ROC). For SRTCP, we apply HMAC to the corresponding M, only (as it already includes the SRTCP index). By default, the output shall be truncated to the n_tag left-most bits. Default value for n_a is 128 bits, and for n_tag it is 32 bits. 4.2.2 TMMH This document describes TMMH version two, which is not interoperable with the earlier version. In the following, the term TMMH refers to version two. TMMH is a simple function that maps a key and a message to a hash value. This hash value is encrypted by combining it with the keystream prefix to make the authentication tag, as described below. The key, message, and hash value are treated as sequences of unsigned sixteen bit integers in network byte order. In the following, we call such a 16-bit integer a word. The number of octets in the key and hash value MUST be a multiple of two (to be word-aligned). (Thus, n_tag and n_a MUST be multiples of 16.) Besides the above common parameters, we define the following parameters for TMMH: * TAG_WORDS, the number of words in the hash value, i.e., n_tag/16. The default is 2. The value of TAG_WORDS also defines the quantity SRTP_PREFIX_LENGTH to be TAG_WORDS * 2 (see Section 4.1). The number of words of the key, i.e. n_a/16, depends on the maximum length of any message to be authenticated as follows: MAX_MSG_LENGTH (octets) Key size (16-bit words) ---------------------------------------------------- 16 7 + 2 * TAG_WORDS 128 14 + 3 * TAG_WORDS 1024 21 + 4 * TAG_WORDS 8192 28 + 5 * TAG_WORDS 65536 35 + 6 * TAG_WORDS Baugher, et al. [Page 22] INTERNET-DRAFT SRTP February, 2002 For instance, an RTP packet of length 80 bytes to be authenticated with a 32-bit (2 word) tag, requires a 320-bit TMMH key. The default key-size is defined below. However, applications that know on beforehand the size of the longest message they will ever encounter MAY choose a smaller key-size. * TAG is the authentication tag, which is the output of TMMH * PREFIX is the keystream prefix for the current packet as defined in Section 4.1. * K is the key, i.e., k_a as obtained by applying the key * derivation. The default key-size is 94 octets, or 752 bits (to accommodate messages up to 65536 byte with a 2-word tag). * MSG_LEN, the number of octets in the message (before padding, when all-zero padding is needed to align to a word boundary when the message contains an odd number of octets) * p is equal to the prime number 2^16 + 1. In the following, we use the symbol * to denote integer multiplication and the symbol +32 to denote integer addition modulo 2^32. TMMH uses several key-dependent internal data structures: the length multiplier array L, and an array of subkeys A. The length multiplier array L is an array of words, the ith element of which is denoted as L[i], with i ranging from zero to (TAG_WORDS - 1). A subkey is an array consisting of (TAG_WORDS + 7) words, and the ith element of the subkey S is denoted as S[i]. Five subkeys are used in TMMH. The subkeys are stored in an array denoted A.The ith subkey is denoted as A[i], with i ranging from zero to 4. +----+----+----+----+----+----+----+----+----+----+----+--- Key |K[0]|K[1]|K[2]|K[3]|K[4]|K[5]|K[6]|K[7]|K[8]|K[9]|K[a]|... +----+----+----+----+----+----+----+----+----+----+----+--- +----+----+--------------------------------------------+--- Field |L[0]|L[1]| A[0] |... +----+----+--------------------------------------------+--- Figure 5. An illustration of how the arrays L and A are assigned from the words of the TMMH key K. In this example, TAG_WORDS is equal to two. Here K[i] denotes the ith word of the TMMH key (where i is a hexadecimal number). The field A[0] is the 0:th subkey. The length multiplier array L and the subkey array A are taken from the TMMH key K as follows. Baugher, et al. [Page 23] INTERNET-DRAFT SRTP February, 2002 1. The value L[i] is set to K[i], for i = 0 to TAG_WORDS-1. 2. The value A[i][j] (the jth element of the ith subkey) is set to K[ TAG_WORDS + j + (TAG_WORDS + 7) * i ]. This process is illustrated in Figure 5. We introduce the following notation: Let A_ij be the eight word vector A[i][j] || A[i][j + 1] || ... || A[i][j + 7]. The function V(S, M) defined below maps a subkey S and an eight-word data string M to a 32-bit unsigned integer. V(S,M) = S[0] * M[0] +32 S[1] * M[1] +32 ... +32 S[7] * M[7] Here +32 denotes integer addition modulo 2^32. The length of the subkey S may be greater than eight, but the excess words are ignored by the function V. (The definition of V such that the most significant words of the subkey may be ignored simplifies the exposition below.) If the message consists of less than 8 words, the remaining words are set to zero. The function U(S, M) is defined as U(S, M) = [ V(S, M) modulo p ] modulo 2^16. The core of TMMH is a 'compression' function C which maps a subkey value and an input string to an output string which is about eight times smaller than the input string. To compute C(S, D) for a given subkey value S and data string D of w words, do the following. 1) Divide up D into blocks of eight words each (note that the last word may contain less than eight words) i.e., D = D[0] || D[1] || ... || D[ ceil(w/8) ] where D[i] is the ith block, || denotes concatenation, and ceil(x) denotes the largest integer not less than x. 2) Apply the function U to each block, using the subkey value S each time, then concatenate the outputs as follows: C(S, D) = U(S, D[0]) || U(S, D[1]) || ... || U(S, D[ceil(w/8)]). The j:th word (j starting from zero), T[j], of the TMMH tag is computed using the following algorithm: set X to M and set i to zero while the number of words in X is greater than eight, do set X to C(A_ij, X) Baugher, et al. [Page 24] INTERNET-DRAFT SRTP February, 2002 increment i end while return [ [ [ L[j] * MSG_LEN ] +32 V(A_ij, X) ] mod p ] mod 2^16 To use TMMH to compute the authentication tag TAG of a message, the TMMH hash value of that message is computed, then that value is combined with the keystream prefix defined in Section 4.1. The combining operation is word-wise addition modulo 2^16: TAG[j] = (T[j] + PREFIX[j]) mod 2^16, for j = 0 to TAG_WORDS-1. Note that for RTP, where HMAC is applied to M || ROC, TMMH is applied to M only. This is so, because the dependence on ROC is for TMMH inherent to the PREFIX quantity. 4.3 Key Derivation 4.3.1 Key Derivation Algorithm Regardless of the encryption or message authentication transform that is employed (it may be a defined transform or newly introduced according to Section 7), SRTP key derivation is the process of generating session keys, without extra communication between the parties and in a sender-receiver synchronized way. master salt, packet index ---+ | | v +-----------+ +--------+ session encr_key | ext | master | |----------> | key mgmt | key | key | session auth_key | (optional |-------->| deriv |----------> | rekey) | | | session salt_key | | | |----------> +-----------+ +--------+ Figure 6: SRTP key derivation. At least one initial key derivation is always performed by SRTP, i.e., the first key derivation is mandatory. Further applications of the key derivation MAY be performed, according to the 'key derivation-rate' value in the cryptographic context. The key derivation function is defined to be initially invoked before the first packet and then, if derivation rate is r > 0, to be further invoked on every r:th packet, and produce session keys according to Baugher, et al. [Page 25] INTERNET-DRAFT SRTP February, 2002 the non-zero key derivation rate. 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. There is also a derivation of session salting keys for encryption transforms that so require, e.g., 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) is needed, and a default PRF transform is defined in Section 4.3.2. 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 is defined as follows. To generate session key(s)(and session salt(s)) for the current packet, let the n-bit SRTP key (or salt) for this packet be PRF_n(k_master, ((