idnits 2.17.1 draft-tschofenig-hiprg-hip-srtp-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 909. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 285 has weird spacing: '...ariable algo...' == Line 523 has weird spacing: '...ameters from ...' -- 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 (October 23, 2006) is 6394 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 == Outdated reference: A later version (-06) exists of draft-ietf-hip-esp-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft M. Shanmugam 4 Intended status: Informational Siemens Networks GmbH & Co KG 5 Expires: April 26, 2007 F. Muenz 6 October 23, 2006 8 Using SRTP transport format with HIP 9 draft-tschofenig-hiprg-hip-srtp-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The Host Identity Protocol (HIP) is a signaling protocol which adds a 43 new layer between the traditional Transport and the Network layer. 44 HIP is an end-to-end authentication and key exchange protocol, which 45 supports security and mobility in a commendable manner. The HIP base 46 specification is generalized and purported to support different key 47 exchange mechanisms in order to provide confidentiality protection 48 for the subsequent user data traffic. This draft explains a 49 mechanism to establish Secure Real Time Protocol associations, to 50 protect the user data packets, by using HIP. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. SRTP Parameter Exchange in HIP . . . . . . . . . . . . . . . . 7 58 4.1. Setting up an SRTP Association . . . . . . . . . . . . . . 7 59 4.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 9 61 5.1. General Parameters (SRTP_PARAM) . . . . . . . . . . . . . 9 62 5.2. Timestamp (SRTP_T) . . . . . . . . . . . . . . . . . . . . 11 63 5.3. Pseudo-random byte-string (SRTP_RAND) . . . . . . . . . . 11 64 5.4. Security Policies (SRTP_SP) . . . . . . . . . . . . . . . 12 65 5.5. Master Key Identifier (SRTP_MKI) . . . . . . . . . . . . . 14 66 5.6. NOTIFY Parameter . . . . . . . . . . . . . . . . . . . . . 14 67 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 15 68 6.1. Processing Outgoing Application Data . . . . . . . . . . . 15 69 6.2. Processing Incoming Application Data . . . . . . . . . . . 15 70 6.3. HMAC and SIGNATURE Calculation and Verification . . . . . 15 71 6.4. Processing Incoming SRTP Initialization (R1) . . . . . . . 15 72 6.5. Processing Incoming SRTP Reply (I2) . . . . . . . . . . . 16 73 6.6. Dropping HIP Associations . . . . . . . . . . . . . . . . 16 74 6.7. Initiating SRTP master key rekeying . . . . . . . . . . . 16 75 6.8. Finalizing Rekeying . . . . . . . . . . . . . . . . . . . 17 76 6.9. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 18 77 7. Implementation Considerations . . . . . . . . . . . . . . . . 19 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 8.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 20 80 8.2. Man in the Middle Attack . . . . . . . . . . . . . . . . . 20 81 8.3. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 20 82 8.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 21 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 89 Intellectual Property and Copyright Statements . . . . . . . . . . 26 91 1. Introduction 93 The Host Identity Protocol (HIP) [I-D.ietf-hip-base] provides a way 94 to separate the dual role of IP (end point identifier and locator) by 95 adding a new layer between the traditional Network and Transport 96 layer. This separation helps the end host to achieve mobility, 97 furthermore, HIP provides better security features (like end-to-end 98 authentication, confidentiality for the data traffic etc) than other 99 multi6 proposals. 101 HIP is based on public key cryptography. All HIP hosts have a 102 public/private key pair. HIP introduces a new name space called Host 103 Identity. It is nothing but the public key of an asymmetric key 104 pair. It provides a rapid exchange of host identities (public keys) 105 between communicating hosts, after mutual authentication, a HIP 106 association is established. For operational purposes, HIP uses Host 107 Identity Tags (HITs) [I-D.ietf-hip-base], which is hash of the public 108 key. During the base exchange, the hosts generate a shared keying 109 material using an authenticated Diffie-Hellman exchange. Note that 110 the HIP base exchange provides mutual authentication of the hosts, 111 but does not specify any mechanism for protecting data packets. 112 [I-D.ietf-hip-esp] draft proposes a way to use IPsec ESP format with 113 HIP. 115 Secure Real Time Protocol (SRTP) is a profile for Real Time Protocol 116 (RTP), which provides a framework for providing encryption, 117 integrity, message authentication, confidentiality and protection 118 against replay attacks for the real-time data traffic. SRTP mandates 119 the use of an external key management protocol to exchange keys and 120 cryptographic parameters, which are used to derive keys (like cipher 121 suites, random number etc.,). This draft proposes a way to exchange 122 SRTP relevant parameters during the HIP base exchange. Appendix A 123 describes one possible use case to support this document. 125 This document is organized as follows. Section 4 describes the 126 revised base exchange, Section 5 presents the packet format, Section 127 6 explains the packet processing and Section 7 talks about the key 128 management. 130 This document was developed in the context of investigating the 131 benefits of using HIP for SIP. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119] . 139 This draft uses the terminology defined in [I-D.ietf-hip-base] and 140 [RFC3261] . 142 The term MKI, an optional parameter, refers to Master Key Identifier 143 used in SRTP packets. 145 3. Goals 147 To facilitate the use of SRTP, the HIP base exchange messages require 148 some minor additions to the parameters transported. In the R1 149 packet, the responder adds the necessary parameters, which contains 150 transforms and other related information for the SRTP association, 151 before sending it to the Initiator. The Initiator gets the proposed 152 transforms, selects one of those proposed transforms, and adds it to 153 the I2 packet, as well as other information in the corresponding 154 parameters. 156 In this context, the goal of our proposal is to, 158 o define new parameter exchange for exporting the relevant SRTP 159 parameters in the HIP base exchange. 161 o describe the relevant packet formats. 163 4. SRTP Parameter Exchange in HIP 165 In this section, the protocol for setting up an SRTP association to 166 be used with HIP association is described. 168 4.1. Setting up an SRTP Association 170 Setting up an SRTP Association between hosts using HIP consists of 171 two messages passed between the hosts. The parameters are included 172 in R1 and I2 messages during base exchange. 174 Initiator Responder 175 I1 176 -------------------------------------------> 177 R1: SRTP_T, SRTP_PARAM, KEY_PARAM 178 <-------------------------------------------- 179 I2: SRTP_T, SRTP_PARAM, KEY_PARAM 180 -------------------------------------------> 181 R2 182 <-------------------------------------------- 184 Figure 1: Setting up an SRTP Association 186 The integration of HIP and SRTP requires some changes, as mentioned 187 earlier, in the HIP parameters. The changes are (will be) adding, 189 SRTP_T: The timestamp, used mainly to prevent replay attacks. 191 The SRTP_PARAM contains the information about the general description 192 of the message exchange. It is used for mapping a Crypto Sessions 193 (CS) to security protocol sessions. 195 KEYING parameter (KEY_PARAM) contains 197 SRTP_RAND: Random/pseudo-random byte-string, RAND(nonce) is used 198 as a fresh value for the key generation. 200 SRTP_SP: The security policies for the data security protocol. 201 (eg. algorithms and transforms and PRFs supported by the peers). 202 The cipher suites can be negotiated from R1/I2 packet. 204 SRTP_MKI : to identify the Master key and Master salt. 206 The R1 message contains the KEYING PARAMS, in which the sending host 207 defines the possible Algorithms and transforms, random number and, 208 optionally, a MKI it is willing to use for the SRTP association. 210 The I2 message contains the response to KEYING PARAMS received in the 211 R1 message. The sender must select one of the proposed transforms 212 from the SP parameter in the R1 message and include the selected one 213 in the SP parameter in the I2 packet. In addition to the transform, 214 the host includes the RAND parameter, containing the random value 215 (and optionally MKI) to be used as a salt by the peer host. In the 216 R2 message, HIP exchange is finalized. 218 4.2. Rekeying 220 Rekeying can be supported using the UPDATE packet of HIP. The peer 221 which wants to rekey should use the UPDATE packet with the 222 appropriate parameters. The mechanism is explained below: 224 Initiator Responder 226 UPDATE: SRTP_T, SRTP_PARAM, KEYING PARAMS [,DIFFIE_HELLMAN] 227 -------------------------------------------------------------> 228 UPDATE: SRTP_T, SRTP_PARAM, KEYING PARAMS [,DIFFIE_HELLMAN] 229 <------------------------------------------------------------- 230 UPDATE ACK 231 -------------------------------------------------------------> 233 Figure 2: Rekeying mechanism 235 Figure 2 depicts the rekeying scenario. Here, assume that the 236 Initiator wants to rekey after the Initial exchange. It can send the 237 rekeying parameters in the Update packet, includes its new Diffie- 238 Hellmann value, and sends it to the Responder. It may send a new MKI 239 value to identify the incoming packet. 241 The other parameters are explained in [I-D.ietf-hip-base]. The 242 Responder checks the return routability by sending the Update seq 243 message containing its Diffie-Hellmann value and relevant parameters 244 for the rekeying. After receiving the packet, the Initiator sends 245 the ACK thereby both the peers conclude the rekeying procedure and 246 now on, the peers expect to receive the traffic in the new keying 247 material. 249 5. Parameter and Packet Formats 251 This section discusses the SRTP related new parameters and presents 252 the proposed packet format. 254 The following list gives an overview of the parameters to be 255 exchanged in addition to the HIP base exchange: 257 Master Key and its length - obtained from Diffie-Hellmann key 258 exchange 260 Master Salt - RAND in the KEYING parameter 262 MKI - Master Key Identifier 264 Security Policies (SP) - Each policy will define pseudo-random 265 functions, algorithms and transforms for the establishment of a 266 Cryptographic Context for SRTP. 268 Timestamp - Used for preventing replay attacks. 270 Session keys are derived using Master key, Master salt and SP and 271 the details are up to the key management protocol. 273 The new parameters contain five elements summarized in the following 274 table: 276 Parameter Type Length Data 278 SRTP_PARAM 40000 variable Mapping Crypto Sessions 279 to security protocol 280 sessions 281 SRTP_T 40001 4 Used mainly to prevent 282 replay attacks 283 SRTP_RAND 40002 14 used as a fresh value for 284 the key generation 285 SRTP_SP 40003 variable algorithms, transforms, PRFs 286 supported by the peers 287 SRTP_MKI 40004 variable Master Key Identifier 289 The parameters SRTP_RAND, SRTP_SP and SRTP_MKI together form the 290 KEYING (KEY_PARAM) parameters. 292 5.1. General Parameters (SRTP_PARAM) 294 The general parameter is used for mapping a Crypto Sessions (CS) to 295 security protocol sessions. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 ! CSB ID ! 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 ! #CS ! CS ID map info | RESERVED | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 ! Policy_no_1 ! SSRC_1 ! 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 ! SSRC_1 (cont) ! ROC_1 ! 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 ! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 ! 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ! SSRC_2 (cont) ! ROC_2 ! 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ! ROC_2 (cont) ! : 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 316 : : : 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ! Policy_no_#CS ! SSRC_#CS ! 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 !SSRC_#CS (cont)! ROC_#CS ! 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ! ROC_#CS (cont)! 323 +-+-+-+-+-+-+-+-+ 325 Fig 4: Mapping parameters 327 Type: 40000 (experimental identifier range) 328 Length: variable 329 Value: Mapping information 331 CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that the 332 CSB ID be chosen at random by the Responder and sent with the R1 333 packet. This ID MUST be unique between each Initiator-Responder 334 pair, i.e., not globally unique. A Responder MUST check for 335 collisions when choosing the ID (if the Responder already has one 336 or more established CSBs with the Initiator). The Initiator uses 337 the same CSB ID in the response. 339 #CS (8 bits): indicates the number of Crypto Sessions that can be 340 handled concurrently by a CSB. A CSB may handle up to 255 CS at a 341 time. However, it is unlikely that this limited will be reached. 342 The integer 0 is interpreted as no CS included. This may be the 343 case in an initial setup message. 345 CS ID map info (16 bits): identifies the crypto session(s) for 346 which the SA should be created. 348 Policy_no_i (8 bits): The security policy applied for the stream 349 with SSRC_i. The same security policy may apply for all CSs. 351 SSRC_i (32 bits): specifies the SSRC that MUST be used for the 352 i-th SRTP stream. 354 ROC_i (32 bits): Current rollover counter used in SRTP. 356 NOTE: The stream using SSRC_i will also have Crypto Session ID equal 357 to no i (NOT to the SSRC). 359 5.2. Timestamp (SRTP_T) 361 The timestamp, used mainly to prevent replay attacks. As in the SRTP 362 packet format, a 32-bit value is used to store the timestamp. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Timestamp (T) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Fig 4: Timestamp parameter 374 Type: 40001 (experimental identifier range) 375 Length: 4 376 Value: Timestamp 378 5.3. Pseudo-random byte-string (SRTP_RAND) 380 The RAND or master salt parameter is used as a fresh value for the 381 key generation. The RAND parameter is a 112 bit quantity. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 | | 390 | Pseudo-random byte-string (RAND) | 391 | | 392 | | 393 | | 394 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Fig 5: Pseudo-random byte-string parameter 400 Type: 40002 (experimental identifier range) 401 Length: 14 402 Value: Pseudo-random byte-string 404 5.4. Security Policies (SRTP_SP) 406 The security policies for the data security protocol (e.g., 407 algorithms, transforms and PRFs supported by the peers). The cipher 408 suites can be negotiated from I2/R2 packet. The security policy 409 parameters are grouped together for being used with the policy 410 selector in the mapping parameter, that is a SRTP_SP parameter may 411 actually consist of multiple policies. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 ~ Security policy parameters ~ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Fig 6: Security policy parameters 423 Type: 40003 (experimental identifier range) 424 Length: variable 425 Value: See below 427 The security policy parameters themselves are built up by a set of 428 Type/Length/Value fields: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Length | Policy No. | Value ~ 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Type (8 bits): specifies the type of the parameter. 438 Length (8 bits): specifies the length of the Value field (in bytes). 440 Policy No. (8 bits): specifies the policy to which this TLV belongs. 441 It is used in conjunction with the Mapping parameter. All values 442 (0-255) may be used for policy identification. 444 Value (variable length): specifies the value of the parameter. 446 Type | Length | Meaning | Value 447 -----+--------+----------------------------+-------------------- 448 1 | 1 | SRTP and SRTCP encr transf | see below 449 2 | 2 | Encr session key length | 128 450 3 | 1 | SRTP and SRTCP auth transf | see below 451 4 | 2 | Auth session key length | 160 452 5 | 2 | Tag length | 80 453 6 | 4 | SRTP prefix_length | var(default 0) 454 7 | 1 | Key derivation PRF | see below 455 8 | 8 | Key derivation rate | var(default 0) 456 9 | 8 | SRTP-packets-max-lifetime | var 457 10 | 8 | SRTCP-packets-max-lifetime | var 458 11 | 1 | Forward Error Control | 2-bits 460 For the Encryption transforms, a one byte length is enough. The 461 currently defined possible Values are: 463 SRTP and SRTCP encr transf | Value 464 ---------------------------+------ 465 NULL | 0 466 AES-CM | 1 467 AES-F8 | 2 469 where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [RFC3711]. 471 For the Authentication transforms, a one byte length is enough. The 472 currently defined possible Values are: 474 SRTP and SRTCP auth transf | Value 475 ----------------------------+------ 476 NULL | 0 477 HMAC-SHA-1 | 1 479 For the Key derivation PRF, a one byte length is enough. The 480 currently defined possible values are: 482 Key derivation PRF | Value 483 ------------------------+------- 484 NULL | 0 485 AES_CM | 1 487 5.5. Master Key Identifier (SRTP_MKI) 489 The MKI identifies the master key and master salt from which the 490 session key(s) were derived that authenticate and/or encrypt the 491 particular packet. This parameter is OPTIONAL. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ MKI (variable) ~ 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Fig 7: SRTP MKI parameter 503 Type: 40004 (experimental identifier range) 504 Length: variable 505 Value: Master Key Identifier (MKI) 507 5.6. NOTIFY Parameter 509 The HIP base specification defines a set of NOTIFY error types. The 510 following error types are required for describing errors in SRTP 511 security policy during negotiation. 513 NOTIFY PARAMETER - ERROR TYPES Value 514 ------------------------------ ----- 516 NO_SRTP_PROPOSAL_CHOSEN TBD 518 None of the proposed SRTP Transform in the proposed 519 security policy was acceptable. 521 INVALID_SRTP_TRANSFORM_CHOSEN TBD 523 The SRTP chosen parameters from the proposed security 524 policy proposals do not correspond to those offered 525 by the responder. 527 6. Packet Processing 529 In general, packet processing is specified in the HIP base 530 specification [I-D.ietf-hip-base]. This section provides an overview 531 of changes needed when using the new SRTP extensions. 533 6.1. Processing Outgoing Application Data 535 When the SRTP format is used, the outgoing application data will be 536 encrypted using a cryptographic context. Details about the handling 537 of outgoing SRTP traffic is described in [RFC3711] Section 3.3. 539 6.2. Processing Incoming Application Data 541 When the SRTP format is used, the incoming application data will be 542 decrypted using a cryptographic context. Details about the handling 543 of incoming SRTP traffic is described in [RFC3711] Section 3.3. 545 6.3. HMAC and SIGNATURE Calculation and Verification 547 The new HIP parameters described in this document, SRTP_PARAM, 548 SRTP_T, SRTP_RAND, SRTP_SP and SRTP_MKI must be protected using HMAC 549 and signature calculations. In a typical implementation, they are 550 included in R1, I2, and UPDATE packet HMAC and SIGNATURE calculations 551 as described in [I-D.ietf-hip-base]. 553 6.4. Processing Incoming SRTP Initialization (R1) 555 The SRTP key exchange is initialized in the R1 message. The 556 receiving host (Initiator) selects the SRTP transforms from the 557 presented values in the R1 packet and establishes its SRTP 558 Cryptographic Context. For this the SRTP_SP will provide the 559 transforms and pseudo-random functions, the SRTP_MAPPING parameters 560 will provide information about what policy applies for which Crypto 561 Session (CS). If no suitable value is found, the negotiation is 562 terminated. 564 The selected values are subsequently used when generating and using 565 session keys according to the negotiated SP, and when sending the 566 reply packet I2. If the proposed alternatives are not acceptable to 567 the system, it may abandon the SRTP establishment negotiation, or it 568 may resend the I1 message within the retry bounds. 570 After creating cryptographic context, and performing other R1 571 processing, the system prepares and creates session keys derived from 572 the exchanged master key complying to the negotiated SPs. The 573 Initiator will then send the I2 packet with the selected SRTP 574 transforms. 576 6.5. Processing Incoming SRTP Reply (I2) 578 The following steps are required to process the incoming SRTP 579 initialization reply in I2 for creating the correct Cryptographic 580 Context on Responder side. It is assumed that the I2 packet has been 581 accepted for processing (e.g., has not been dropped due to HIT 582 comparisons as described in [I-D.ietf-hip-base]): 584 The SRTP_SP and SRTP_MAPPING parameters are verified and they MUST 585 have the same number of proposed policies in R1 and each policy 586 MUST match the values offered in the initialization packet. 588 The SRTP_MKI field is parsed to obtain the MKI that will be used 589 for selecting the appropriate master key. 591 The system creates session keys derived from the master key, 592 master salt and security policy for a certain SRTP stream. 594 Upon successful processing of the initialization reply message, a 595 possible old master key and session keys are dropped and the new 596 ones are installed, and a finalizing packet, R2, is sent. 597 Possible ongoing rekeying attempts are dropped. 599 6.6. Dropping HIP Associations 601 When the system drops a HIP association, as described in the HIP base 602 specification, the SRTP layer and any results from exchanges are not 603 affected. 605 6.7. Initiating SRTP master key rekeying 607 During SRTP rekeying, the hosts exchange new master keys from which 608 session keys will be derived. Use of the MKI for rekeying is 609 RECOMMENDED 611 A system may initiate the SRTP rekeying procedure at any time. The 612 system MUST NOT replace its current master key until the rekeying 613 packet exchange successfully completes. 615 The rekeying procedure uses the UPDATE mechanism defined in 616 [I-D.ietf-hip-base]. Because each peer must update their master 617 keys, the rekeying process requires that each side both send and 618 receive an UPDATE. A system will then rekey the session keys when it 619 has sent parameters to the peer and has received both an ACK of the 620 relevant UPDATE message and corresponding peer's parameters. It may 621 be that the ACK and the required HIP parameters arrive in different 622 UPDATE messages. This is always true if a system does not initiate 623 SRTP update but responds to an update request from the peer, but may 624 also occur if two systems initiate update nearly simultaneously. In 625 such a case, if the system has an outstanding update request, it 626 saves the one parameter and waits for the other before completing 627 rekeying. 629 The following steps define the processing rules for initiating an 630 SRTP update: 632 The system decides whether to continue to use the existing master 633 key or to create a new one. In the latter case, the system MUST 634 generate a new Diffie-Hellman public key. When using SRTP default 635 transforms, the master key MUST be replaced before any of the 636 index spaces are exhausted for any of the streams protected by one 637 and the same master key. 639 The system creates an UPDATE packet, which contains the 640 SRTP_PARAM, SRTP_T, SRTP_RAND, SRTP_SP and SRTP_MKI parameter. In 641 addition, the host MUST include DIFFIE_HELLMAN parameter. 643 The system sends the UPDATE packet. For reliability, the 644 underlying UPDATE retransmission mechanism SHOULD be used. 646 The system MUST NOT delete its existing master key, but continue 647 using them if its policy still allows. 649 In case a protocol error occurs and the peer system acknowledges 650 the UPDATE but does not itself send an SRTP parameters, the system 651 may not finalize the outstanding session key update request. To 652 guard against this, a system MAY re-initiate the SRTP update 653 procedure after some time waiting for the peer to respond, or it 654 MAY decide to abort the SRTP update after waiting for an 655 implementation-dependent time. The system MUST NOT keep an 656 oustanding SRTP update request for an indefinite time. 658 To simplify the state machine, a host MUST NOT generate new UPDATEs 659 while it has an outstanding SRTP update request, unless it is 660 restarting the update process. 662 6.8. Finalizing Rekeying 664 A system finalizes rekeying when it has both received the 665 corresponding UPDATE acknowledgement packet from the peer and it has 666 successfully received the peer's UPDATE. The following steps are 667 taken: 669 If the received UPDATE messages contains a new Diffie-Hellman key, 670 the system has a new Diffie-Hellman key from initiating SRTP 671 update, or both, the system selects the new master key. 673 The system draws session keys from the new master key. 675 The system cancels any timers protecting the UPDATE. 677 6.9. Processing NOTIFY Packets 679 The processing of NOTIFY packets is described in the HIP base 680 specification. 682 7. Implementation Considerations 684 This section explains the implementation considerations for the HIP- 685 SRTP exchange. After the initial base exchange, both peers have the 686 same master key, salt and agreed crypto transforms (including pseudo 687 random function). When the application receives the data traffic 688 after the base exchange, an API is invoked and asks the HIP daemon 689 for the appropriate key to process the data packet. 691 Figure 15 depicts the example implementation architecture of the 692 proposed mechanism: 694 +------------+ 695 -------------+ API | KEY ENGINE | 696 Application |<------------->| | 697 | | | 698 | | | 699 | | HIP daemon | 700 | +------------+ 701 | 702 User space | 703 -------------+ 704 PF_INET || || PF_RAW 705 ==================||==========||============= 706 || || 707 Kernel space 708 +--------------+ 709 | TCP|UDP / IP | 710 +--------------+ 712 Figure 15: Example Implementation Architecture 714 8. Security Considerations 716 Security is considered throughout this document. 718 The initial keying material is generated using using Diffie-Hellman 719 procedure. This document extends the usage of UDPATE packet, defined 720 in the base specification, for rekeying. The hosts may rekey for the 721 generation of new keying material using Diffie-Hellman procedure. 722 This mechanism enjoys the security protection provided by base 723 exchange using HMAC and signature verifications. 725 In this approach, we have tried to extend the HIP base exchange to 726 support SRTP based key management scheme. We have listed the 727 following security mechanisms that are incorporated with this idea: 729 8.1. Denial of Service 731 Threat: 733 A denial of service attack typically overloads the attacked nodes by 734 exploiting any state creation, CPU intensive calculation or simply 735 overloading their maximum available bandwidth. 737 Countermeasures: 739 This approach enjoys the merits of HIP like resisting CPU and memory 740 exhaustive DoS attacks by forcing the caller to calculate the 741 solution for a cryptographic puzzle. This provides only a basic DoS 742 protection for the callee. 744 8.2. Man in the Middle Attack 746 Threat: 748 An adversary might want to modify the parameters that are exchanged. 750 Countermeasures: 752 HIP uses authenticated Diffie-Hellmann key exchange, which prevents 753 the man-in-the-middle (MitM) attacks. The exchanged parameters are 754 protected in the same fashion as IPSec parameters are when HIP is 755 used for setting up IPSec security associations. 757 8.3. Eavesdropping 759 Threat: 761 A possible passive attack of an adversary is placing itself between 762 communication partners and collect data, that is exchanged between 763 them. As a result the adversary may learn about communciation and 764 encryption details. 766 Countermeasures: 768 Since the data traffic is encrypted, it is unreadable for the 769 attackers. 771 8.4. Authentication 773 Threat: 775 A malicious node may impersonate another node and perform actions on 776 behalf of this node for it's own needs. 778 Countermeasures: 780 Both peers are authenticated using asymmetric key (signature 781 verification) cryptography assuming that public keys can be acquired 782 by secure ways. 784 9. IANA Considerations 786 This document defines several new name spaces associated with the HIP 787 payloads. This section summarizes the name spaces for which IANA is 788 requested to manage the allocation of values. IANA is requested to 789 record the pre-defined values defined in the given sections for each 790 name space. IANA is also requested to manage the definition of 791 additional values in the future. 793 This document defines five new HIP parameters, namely SRTP_PARAM, 794 SRTP_T, SRTP_RAND, SRTP_SP and SRTP_MKI. These parameters currently 795 use the experimental identifer range of the HIP protocol. A decision 796 must be made on the final values. 798 The name spaces for the fields in the Security Policies parameter 799 (from Section 5.4) are requested to be managed by IANA. All proposed 800 values are summarized in the tables given in this section. 802 The name spaces for the fields in the Notify parameter (from Section 803 5.6) are requested to be managed by IANA. 805 10. Acknowledgements 807 The authors would like to gratefully acknowledge Pekka Nikander and 808 Jari Arkko for their comments to this document. 810 This document is a byproduct of the Ambient Networks Project, 811 partially funded by the European Commission under its Sixth Framework 812 Programme. It is provided "as is" and without any express or implied 813 warranties, including, without limitation, the implied warranties of 814 fitness for a particular purpose. The views and conclusions 815 contained herein are those of the authors and should not be 816 interpreted as necessarily representing the official policies or 817 endorsements, either expressed or implied, of the Ambient Networks 818 Project or the European Commission. 820 11. References 822 11.1. Normative References 824 [I-D.ietf-hip-base] 825 Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 826 "Host Identity Protocol", draft-ietf-hip-base-06 (work in 827 progress), June 2006. 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", March 1997. 832 [RFC3711] Baugher, M., Carrara, E., McGrew, D., Naslund, M., and K. 833 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 834 March 2004. 836 11.2. Informative References 838 [I-D.ietf-hip-esp] 839 Moskowitz, R., Nikander, P., and P. Jokela, "Using ESP 840 transport format with HIP", draft-ietf-hip-esp-03 (work in 841 progress), June 2006. 843 [RFC3261] Schulzrinne, H., Camarillo, G., Rosenberg, J., Peterson, 844 J., Sparks, R., Handley, M., and E. Schooler, "Session 845 Initiation Protocol", February 2005. 847 Authors' Addresses 849 Hannes Tschofenig 850 Siemens Networks GmbH & Co KG 851 Otto-Hahn-Ring 6 852 Munich, Bavaria 81739 853 Germany 855 Phone: +49 89 636 40390 856 Email: Hannes.Tschofenig@siemens.com 857 URI: http://www.tschofenig.com 859 Murugaraj Shanmugam 860 Siemens Networks GmbH & Co KG 861 Otto-Hahn-Ring 6 862 Munich, Bayern 81739 863 Germany 865 Email: murugaraj.shanmugam@siemens.com 867 Franz Muenz 869 Email: franz.muenz@thirdwave.de 871 Full Copyright Statement 873 Copyright (C) The Internet Society (2006). 875 This document is subject to the rights, licenses and restrictions 876 contained in BCP 78, and except as set forth therein, the authors 877 retain all their rights. 879 This document and the information contained herein are provided on an 880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 882 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 883 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 884 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 887 Intellectual Property 889 The IETF takes no position regarding the validity or scope of any 890 Intellectual Property Rights or other rights that might be claimed to 891 pertain to the implementation or use of the technology described in 892 this document or the extent to which any license under such rights 893 might or might not be available; nor does it represent that it has 894 made any independent effort to identify any such rights. Information 895 on the procedures with respect to rights in RFC documents can be 896 found in BCP 78 and BCP 79. 898 Copies of IPR disclosures made to the IETF Secretariat and any 899 assurances of licenses to be made available, or the result of an 900 attempt made to obtain a general license or permission for the use of 901 such proprietary rights by implementers or users of this 902 specification can be obtained from the IETF on-line IPR repository at 903 http://www.ietf.org/ipr. 905 The IETF invites any interested party to bring to its attention any 906 copyrights, patents or patent applications, or other proprietary 907 rights that may cover technology that may be required to implement 908 this standard. Please address the information to the IETF at 909 ietf-ipr@ietf.org. 911 Acknowledgment 913 Funding for the RFC Editor function is provided by the IETF 914 Administrative Support Activity (IASA).