idnits 2.17.1 draft-tschofenig-hiprg-hip-srtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 640. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 117 has weird spacing: '...he same key m...' == Line 160 has weird spacing: '... of IPs i.e, ...' == Line 164 has weird spacing: '... be exchang...' == Line 279 has weird spacing: '...ing the keyin...' == Line 289 has weird spacing: '...or will check...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3711' is defined on line 584, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-00 -- No information found for draft-ietf-hip-multi6 - is the name correct? -- No information found for draft-ietf-hip-sip - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-02 -- Duplicate reference: draft-ietf-hip-base, mentioned in 'RFC3830', was also mentioned in 'I-D.ietf-hip-base'. Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft Siemens 4 Expires: January 12, 2006 F. Muenz 5 FH-Landshut 6 M. Shanmugam 7 TUHH 8 July 11, 2005 10 Using SRTP transport format with HIP 11 draft-tschofenig-hiprg-hip-srtp-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 12, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The Host Identity Protocol is a signaling protocol which adds another 45 layer to the Internet model and (optionally) establishes IPsec ESP 46 SAs to protect subsequent data traffic. HIP is an end-to-end 47 authentication and key exchange protocol, which supports security and 48 mobility in a commendable manner. This draft explains a Secure Real 49 Time Protocol (SRTP) based mechanism for transmission of user data 50 packets, to be used with the Host Identity Protocol (HIP). 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1 Base Exchange . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2 Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.3 Packet Format . . . . . . . . . . . . . . . . . . . . . . 10 60 4. Key management . . . . . . . . . . . . . . . . . . . . . . . . 13 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 63 6.1 Normative References . . . . . . . . . . . . . . . . . . . 17 64 6.2 Informative References . . . . . . . . . . . . . . . . . . 17 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 66 Intellectual Property and Copyright Statements . . . . . . . . 19 68 1. Introduction 70 Host Identity Protocol (HIP) [I-D.ietf-hip-base] provides a way to 71 separate the dual role of IP (end point identifier and locator) by 72 adding a new layer between the traditional Network and Transport 73 layer . This separation helps the end host to achieve mobility, 74 furthermore, HIP provides better security features (like end-to-end 75 authentication, confidentiality for the data traffic etc) than other 76 multi6 proposals [I-D.ietf-hip-multi6]. 78 HIP is based on public key cryptography. All HIP hosts have a 79 public/private key pair. HIP introduces a new name space called Host 80 Identity. It is nothing but the public key of an asymmetric key 81 pair. It provides a rapid exchange of host identities (public keys) 82 between communicating hosts and (optionally) establishes IPsec SAs to 83 protect subsequent data traffic. It is a four-way handshake 84 protocol, which supports end-to-end authentication and the data 85 traffic may experience IPsec ESP encapsulation. Since different 86 sizes for the public key are possible, it uses the Host Identity Tag 87 (HIT), which is the hash of the public key, for operational 88 representation. The HIP header carries HIT (128 bits long), which is 89 similar to IPV6 addresses. 91 Transport connections and Security Associations between the 92 communicating HIP hosts are bound to the HITs only. IP addresses are 93 used for routing purposes only. Therefore, changes to IP addresses 94 do not change the connections or associations. So, when any of the 95 peers move, it uses a readdressing mechanism to update the current 96 location of the peer, thereby supporting mobility in a seamless 97 manner. 99 Session Initiation Protocol (SIP) is an application layer protocol, 100 which is capable of establishing modifying and terminating sessions 101 between the hosts. The SIP architecture uses URIs to uniquely 102 identify (maps) the user agents and has various infrastructure 103 components like proxy server, redirect server etc., to achieve 104 personal mobility. 106 SIP, when combined with RTP, can effectively handle multimedia 107 applications. SIP can also invite participants to already existing 108 sessions, such as multicast conferences. Media can be added to (and 109 removed from) an existing session. SIP relies on other security 110 protocols like TLS, IPsec, HTTP Digest mechanisms to protect the SIP 111 traffic. 113 HIP base exchange [I-D.ietf-hip-base] does not describe any transport 114 formats for user data. This document proposes extensions to HIP by 115 exporting the relevant parameters to support other key management 116 scheme, like MIKEY. SRTP proposes MIKEY [RFC3830] as a key 117 management protocol. We propose to use the same key management 118 scheme in HIP. HIP combined with MIKEY alike scheme can be used for 119 SRTP as a key management protocol to exchange Master Keys and create 120 a Cryptographic Context (SRTP RFC chapter 3.2). HIP has to satisfy 121 the requirements of SRTP (SRTP RFC chapter 7/8) for a key management 122 protocol and has to support the appropriate cryptographic algorithms 123 within its transform parameters. 125 HIP base exchange provides a mutual authentication of the hosts, but 126 does not specify any mechanism for protecting data packets for the 127 actual communication. [I-D.ietf-hip-esp] draft proposes a way to use 128 IPsec ESP format with HIP. In this document, we specify the use of 129 SRTP for protecting user data traffic after the HIP base exchange. 131 SRTP mandates the use of a external key management protocol (like 132 MIKEY) to exchange keys and cryptographic parameters, which are used 133 to derive keys (like cipher suites, random number etc.,). This draft 134 proposes a way to exchange the SRTP relevant parameters during the 135 HIP base exchange. Besides this, we inherited the key derivation 136 procedure of SRTP to show how the keys will be manipulated and 137 maintained for the data traffic. 139 This document explains the compatibility of HIP and SIP together with 140 the new KEY management scheme. Section 3 explains the revised base 141 exchange, and Section 4 explains the key derivation and future work. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 This draft used the terminology defined in [I-D.ietf-hip-base] and 150 [RFC3261]. 152 The term MKI refers to Master Key Identifier used in SRTP packets. 153 It is similar to SPIs in IPsec. 155 3. Message Flow 157 This section explains the integration of SIP and HIP. The motivation 158 to combine HIP and SIP is defined in [I-D.ietf-hip-sip]. SIP uses 159 URIs, which bind to an IP address or a host name. When HIP is used, 160 SIP headers will make use of HITs instead of IPs i.e, SIP URIs will 161 be bound to HITs. A HIT is derived from HI (public key), which 162 identify users/hosts and IP addresses. The resolution of IP from HI/ 163 HITs can be done via DNS or other mechanisms. Also, the HI/HITs can 164 be exchanged using SIP/SDP mechanism as desribed in [I-D.ietf-hip- 165 sip]. 167 Initially the caller sends an INVITE message to its proxy server, 168 assuming that the caller is already connected. Then the caller proxy 169 server locates the callee proxy server, possibly by performing a 170 particular type of DNS (Domain Name Service) lookup (DNS SRV record). 171 DNS will return the HI/HIT of the callee together with one or more IP 172 addresses of SIP proxies responsible for the callee. After 173 resolution it forwards the message to a callee proxy server and adds 174 a new entry in the SIP header (for route record routability). The 175 callee proxy receiving the INVITE message consults a location 176 database via a location service to resolve the HIT of the callee to 177 current IP address. Finally, it forwards the INVITE to the callee. 179 There are several ways how to combine SIP messages with HIP base- 180 exchange. SIP and HIP messages could be combined to reduce 181 roundtrips or can be used separately.The latter will be explained in 182 detail in this section. 184 +---------+ +---------+ 185 +------+ |SIP Proxy| |SIP Proxy| +------+ 186 |Caller| |Caller | |Callee | |Callee| 187 +------+ +---------+ +---------+ +------+ 188 +---INVITE-------->| | | 189 | +---INVITE---------->| | 190 | | +---INVITE-------->| 191 | | |<--OK-------------+ 192 | |<--OK---------------+ | 193 |<--OK-------------+ | | 194 +----------------------ACK-------------------------------->| 196 +---------+ 197 +------+ |HIP RVS | +------+ 198 |Caller| |Callee | |Callee| 199 +------+ +---------+ +------+ 200 | | | 201 +-------------------I1-------------->+-------I1--------->| 202 |<------------------R1-----------------------------------+ 203 +-------------------I2---------------------------------->| 204 |<------------------R2-----------------------------------+ 205 | | | 206 |<==================TCP/UDP Session=====================>| 208 Figure 1: SIP and HIP Base Exchange 210 Session establishment works in known ways. First an INVITE is routed 211 from the caller to the callee using SIP proxies. The callee then 212 answers with 200 OK and the caller acknowledges with an ACK message 213 directly to the callee. However in this scenario, the SDP of the SIP 214 signalling traffic will not include any SRTP parameters (transforms), 215 which will be decoupled and delegated to HIP. SIP only serves as a 216 rendezvous protocol for HIP to exchange end-host IP addresses and 217 negotiate HIP as the used end-to-end authentication and key exchange 218 protocol. 220 3.1 Base Exchange 222 After HIP is chosen there are again two possibilities on how to 223 proceed. Firstly HIP base-exchange may run directly between 224 communication partners or secondly the callee might be using HIP 225 rendezvous server which is shown in figure 1. 227 As explained in the previous sections, HIP allows the use of other 228 key management protocols. Figure 2 explains how the new KEYING 229 parameters fit into the HIP base exchange: 231 Initiator Responder 233 I1: ------Trigger exchange---------------------------------> 235 R1: <------ puzzle{HI(R),DH(R)}sig(R)------------------------ 237 I2: -{Soln,DH(I), KEYING param.,MKI, enc{HI}keymat }sig(I)-> 239 R2: <------ { KEYING param.,MKI, HMAC }sig(R) --------------- 241 Fig 2: Base Exchange 243 The Initiator starts the HIP connection by sending the trigger 244 message. This message is nothing but two IPs and HITs of the 245 Initiator and the Responder respectively. The Responder answers with 246 the R1 packet, the difference between the actual HIP exchange and the 247 proposed mechanism is the removal of the cipher suites, because the 248 transforms will be chosen via KEYING parameter. Since we have to 249 avoid the state creation, it sends a precomputed packet. 251 Context id = This 252 triple SHALL uniquely identiies a cryptographic context (SRTP RFC 253 chapter 3.2.3.). This context id together with MKI will be mapped to 254 the master key and cipher suites in KEYING management scheme to find 255 the session keys to process the packet. 257 Any specific transform parameters needed for the SRTP cryptographic 258 context will be exchanged by using SP parameter of KEYING parameter 259 in HIP. 261 Master Key - derived from Diffie-Hellmann value 263 Master Salt - RAND in the KEYING parameter 265 MKI - Master Key Identifier 267 Upon receiving it , the Initiator solves the puzzle and sends the I2 268 packet with the Diffie Hellmann value and its KEYING parameter. For 269 the explanation of KEYING parameter see above. The Initiator's HI is 270 encrypted by the keying material derived from the master key (Diffie 271 Hellmann value), so that the responder can also derive the same key 272 using the negotiated cipher suites and Diffie Hellmann value to 273 decrypt the HI. The key management and key derivation is up to the 274 KEY scheme. The whole packet is signed by the Initiator's public 275 key. 277 The Responder receives the packet verifies the solution, derives the 278 key using the Diffie Hellmann value and the KEYING parameter, 279 decrypts the HI, using the keying material , and verifies the 280 Signature. The Responder derives all the encryption and 281 authentication keys from the Initiator's master (Diffie Hellmann) and 282 salt key (KEYING parameter RAND). The reason for this is that both 283 the Initiator and Responder have the same key pairs for providing 284 confidentiality for the data traffic. 286 Next, the Responder sends its KEYING parameter , the same time stamp, 287 random no, the selected cipher suites and HMAC of the whole packet, 288 the key for HMAC is derived from the Master Key. It sends its MKI to 289 identify the incoming packet. The Initiator will check the HMAC and 290 also the Signature to verify the integrity and authenticity of the 291 packet. After this, the HIP association is established and both the 292 hosts use their respective master key and it derived keys for 293 protecting the traffic. The Master Key is 128 bit long, which can be 294 exchanged using the Diffie Hellmann parameter. 296 3.2 Rekeying 298 Rekeying can be supported using the UPDATE packet of HIP. The peer 299 which wants to rekey should use the UPDATE packet with the 300 appropriate parameters. The mechanism is explained below: 302 Initiator Responder 304 Update -Update([seq,REA],DH(R),KEYING param., MKI,HMAC)Sig(I) -----> 306 Seq <-Update seq([ack, REA],DH(I),KEYING param.,MKI,HMAC)Sig(R)- 308 Update ---------------Update ACK( ack, HMAC)Sig(I)-----------------> 309 ACK 310 Fig 3:Rekeying mechanism 312 Figure 3 depicts the rekeying scenario. Here, assume that the 313 Initiator wants to rekey after the Initial exchange. It can send the 314 rekeying parameters in the Update packet. The same mechanism is 315 followed here, the Initiator chooses its Diffie Hellmann value and 316 sends it to the Responder. The key for HMAC has been derived from 317 the old Master key. It also sends a new MKI value to identify the 318 incoming packet. 320 The Responder chooses its Diffie Hellmann value, verifies the HMAC 321 and Signature. The other parameters are explained in [I-D.ietf-hip- 322 base] draft. The Responder checks the return routability by sending 323 the Update seq message containing its relevant parameters for the 324 rekeying. After receiving the packet, the Initiator sends the ACK 325 thereby both the peers concluding the rekeying procedure and now, 326 both of the peers expect to receive the traffic in the new keying 327 material. 329 3.3 Packet Format 331 This section explains the packet format for the KEYING parameter in 332 more detail. 334 KEYING parameter contains 336 T: The timestamp, used mainly to prevent replay attacks. 338 RAND: Random/pseudo-random byte-string, RAND(nonce) is used as a 339 freshness value for the key generation (salts). 341 SP: The security policies for the data security protocol. (eg. 342 Algorithms and transforms and PRFs supported by the peers). The 343 cipher suites can be negotiated from I2/R2 packet. 345 MKI : It is similar to SPI i.e, to identify the Master key and 346 also security associations. 348 Master Key and its length - obtained from Diffie Hellmann key 349 exchange 351 session keys is derived using Master key and SP 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Encr. transf | Auth transf | Encr length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Auth Length | tag length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |FEC| Reserved | SRTP prefix length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | SRTP prefix length | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 366 | SRTP-packets-max-lifetime | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Key derivation rate | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | SRTCP-packets-max-lifetime | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Fig 4: Key management parameters 375 Type: 40000 (experimental identifier range) 376 Length: 256 bit 377 Value: Type/Meaning | Possible values 378 ------------------------------------------------------- 379 SRTP and SRTCP encr transf | see below 380 SRTP and SRTCP auth transf. | see below 381 tag length | 80 382 SRTP prefix_length | variable (default 0) 383 Key derivation PRF | see below 384 encr session key length | 128 385 auth session key length | 160 386 key derivation rate | variable (default 0) 387 SRTP-packets-max-lifetime | variable 388 SRTCP-packets-max-lifetime | variable 389 Forward Error Control | 2-bits 391 SRTP and SRTCP encr transf. | Value 392 --------------------------------- 393 NULL | 0 394 AES_CM | 1 395 AES_f8 | 2 397 SRTP and SRTCP auth transf. | Value 398 --------------------------------- 399 NULL | 0 400 HMAC-SHA1 | 1 402 Key derivation PRF | Value 403 --------------------------------- 404 NULL | 0 405 AES_CM | 1 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 ~ MKI (variable) ~ 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Fig 5: SRTP MKI parameter 417 Type: 40001 (experimental identifier range) 418 Length: variable 419 Value: Master Key Identifier (MKI) 421 4. Key management 423 This section explains how the key management scheme can be used for 424 the data traffic. After the initial base exchange, both peers have 425 the same master key, salt and agreed crypto transforms (including 426 pseudo random function). When the application receives the data 427 traffic after the base exchange, an API is invoked and asks the HIP 428 daemon for the appropriate key to process the data packet 430 The SRTP based key derivation helps to generate the session keys for 431 both peers, so that they have the same keys in possession for 432 encrypting/decrypting the incoming packets. It generates three keys 433 namely encryption key to provide confidentiality for the data 434 packets, authentication key for providing integrity and salt key for 435 the AES counter mode. For that, it uses the master key, salt and 436 crypto transforms together with the packet index. 438 Figure 6 depicts the example implementation architecture of the 439 proposed mechanism: 441 +------------+ 442 -------------+ API | KEY ENGINE | 443 Application |<------------->| | 444 | | | 445 | | | 446 | | HIP daemon | 447 | +------------+ 448 | 449 User space | 450 -------------+ 451 PF_INET || || PF_RAW 452 ==================||==========||============= 453 || || 454 Kernel space 455 +--------------+ 456 | TCP|UDP / IP | 457 +--------------+ 459 Fig 6: Example Implementation Architecture 461 Figure 7 depicts the key derivation, for example, when the peer 462 receives a packet it gets the packet index, MKI, which is used for 463 identifying the relevant master key and transforms. Then, the key 464 derivation function, which is explained below, will generate the 465 required keys. 467 packet index ---+ 468 | 469 v 470 +-----------+ master +--------+ session encr_key 471 | ext | key | |----------> 472 | key mgmt |-------->| key | session auth_key 473 | (optional | | deriv |----------> 474 | rekey) |-------->| | session salt_key 475 | | master | |----------> 476 +-----------+ salt +--------+ 478 Fig 7: SRTP Key Derivation 480 For single key derivation (key_derivation_rate = 0), we define x for 481 later use in calculating keys using PRF and length of PRF bit string 482 output like shown in the following table: 484 X ROC || SEQ Usage PRF output length n 485 --------------------------------------------------------------- 486 0x00 000000000000 SRTP encryption 128 bit 487 0x01 000000000000 SRTP message auth. 160 bit 488 0x02 000000000000 SRTP salting key 112 bit 489 0x03 000000000000 SRTCP encryption 128 bit 490 0x04 000000000000 SRTCP message auth. 160 bit 491 0x05 000000000000 SRTCP salting key 112 bit 492 PRF_n (master_key, x) 494 For multiple key derivation (key_derivation_rate = 1,2,...2E24) 495 x must be calculated according to the following sequence: 497 r = index / key_derivation_rate 498 (with "/" defines r = 0 for key_derivation_rate = 0) 500 with index is a 48-bit concatenation of the 32 bit Roll Over Counter 501 (ROC) and the 16 bit sequence number of the SRTP packet given in the 502 SRTP header (ROC||SEQ) 504 r must be the same length like index, which results in leading zeros. 506 Next concatenate an 8-bit label for selecting the usage with r 507 key_id =