idnits 2.17.00 (12 Aug 2021) /tmp/idnits58973/draft-tschofenig-hiprg-hip-srtp-01.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 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 626. ** 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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, 2005) is 6053 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: 'I-D.ietf-hip-sip' is defined on line 569, but no explicit reference was found in the text == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 -- No information found for draft-ietf-hip-multi6 - is the name correct? -- No information found for draft-ietf-hip-sip - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 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: April 26, 2006 F. Muenz 5 FH-Landshut 6 M. Shanmugam 7 TUHH 8 October 23, 2005 10 Using SRTP transport format with HIP 11 draft-tschofenig-hiprg-hip-srtp-01.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 April 26, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The Host Identity Protocol (HIP) is a signaling protocol which adds a 45 new layer between the traditional Transport and Network layer. HIP 46 is an end-to-end authentication and key exchange protocol, which 47 supports security and mobility in a commendable manner. The HIP base 48 specification is genralized and purported to support different key 49 exchange mechanisms in order to provide confidentiality protection 50 for the subsequent data traffic. In some cases it might not be 51 desirable to establish IPsec security associations for protection of 52 media traffic. This draft explains how keying material and 53 parameters for usage with the Secure Real Time Protocol (SRTP) can be 54 established using HIP. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. SRTP in HIP . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1.1. Setting up an SRTP Association . . . . . . . . . . . . 7 64 4.1.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 9 66 5.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.2. Pseudo-random byte-string (RAND) . . . . . . . . . . . . . 9 68 5.3. Security Policies (SP) . . . . . . . . . . . . . . . . . . 10 69 5.4. Master Key Identifier (MKI) . . . . . . . . . . . . . . . 12 70 6. Key management . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 20 79 1. Introduction 81 The Host Identity Protocol (HIP) [I-D.ietf-hip-base] provides a way 82 to separate the dual role of IP (end point identifier and locator) by 83 adding a new layer between the traditional Network and Transport 84 layer. This separation helps the end host to achieve mobility, 85 furthermore, HIP provides better security features (like end-to-end 86 authentication, confidentiality for the data traffic etc) than other 87 multi6 proposals [I-D.ietf-hip-multi6]. 89 HIP is based on public key cryptography. All HIP hosts have a 90 public/private key pair. HIP introduces a new name space called Host 91 Identity. It is nothing but the public key of an asymmetric key 92 pair. It provides a rapid exchange of host identities (public keys) 93 between communicating hosts and (optionally) establishes IPsec SAs to 94 protect subsequent data traffic. It is a four-way handshake 95 protocol, which supports end-to-end authentication and the data 96 traffic may experience IPsec ESP encapsulation. 98 Transport connections and security associations between the 99 communicating HIP hosts are bound to the HITs and IP addresses are 100 used for routing purposes only. Therefore, changes to IP addresses 101 do not change the connections or associations. So, when any of the 102 peers move (mobility scenarios), it uses a readdressing mechanism to 103 update the current location of the peer, thereby supporting mobility 104 in a seamless manner. 106 The HIP base exchange provides mutual authentication of the hosts, 107 but does not specify any mechanism for protecting data packets. 108 [I-D.ietf-hip-esp] draft proposes a way to use IPsec ESP format with 109 HIP. 111 Secure Real Time Protocol (SRTP) is a profile for Real Time Protocol 112 (RTP), which provides a framework for providing encryption, 113 integrity, message authentication, confidentiality and protection 114 against replay attacks for the real-time data traffic. 116 SRTP mandates the use of a external key management protocol to 117 exchange keys and cryptographic parameters, which are used to derive 118 keys (like cipher suites, random number etc.,). This draft proposes 119 a way to exchange the SRTP relevant parameters during the HIP base 120 exchange. Besides this, we inherited the key derivation procedure of 121 SRTP to show how the keys will be manipulated and maintained for the 122 data traffic. Appendix A describes one possible use case to support 123 this document. 125 This document is organized as follows. Section 3 explains the 126 revised base exchange, Section 4 explains the rekeying scenario, 127 Section 5 presents the packet format and Section 6 explains the key 128 derivation, and future work. 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 optionl parameter, refers to Master Key Identifier 143 used in SRTP packets. 145 3. Goal 147 The HIP base exchange is used to set up a HIP association between two 148 hosts. The base exchange provides two-way host authentication and 149 key material generation, but it does not provide any means for 150 protecting data communication between the hosts. In this document, 151 we specify the use of SRTP for protecting user data traffic after the 152 HIP base exchange. Note that we did not consider the key management 153 issues in this draft. 155 To facilitate the use of SRTP, the HIP base exchange messages require 156 some minor additions to the parameters transported. In the R1 157 packet, the responder adds the possible KEYING Parameter before 158 sending it to the Initiator. The Initiator gets the proposed 159 transforms, selects one of those proposed transforms, and adds it to 160 the I2 packet in the corresponding KEYING Parameter. 162 In this context, the goal of our proposal is to, 164 o define new parameter exchange for the relevant SRTP parameters. 166 o define the relevant packets structure and parameters. 168 4. The Protocol 170 In this section, the protocol for setting up an SRTP association to 171 be used with HIP association is described. 173 4.1. SRTP in HIP 175 4.1.1. Setting up an SRTP Association 177 Setting up an SRTP Association between hosts using HIP consists of 178 two messages passed between the hosts. The parameters are included 179 in R1 and I2 messages during base exchange. 181 Initiator Responder 182 I1 183 ----------------------------------> 184 R1: T, KEYING PARAMS 185 <---------------------------------- 186 I2: T, KEYING PARAMS 187 ----------------------------------> 188 R2 189 <---------------------------------- 191 The integration of HIP and SRTP requires some changes, as mentioned 192 earlier, in the HIP parameters. The changes are (will be) adding, 194 T: The timestamp, used mainly to prevent replay attacks. 196 KEYING parameter contains 198 RAND: Random/pseudo-random byte-string, RAND(nonce) is used as a 199 fresh value for the key generation. 201 SP: The security policies for the data security protocol. (eg. 202 Algorithms and transforms and PRFs supported by the peers). The 203 cipher suites can be negotiated from R1/I2 packet. 205 MKI : to identify the Master key and Master salt. 207 The R1 message contains the KEYING PARAMS, in which the sending host 208 defines the possible Algorithms and transforms, random number and 209 optionally MKI it is willing to use for the SRTP association. 211 The I2 message contains the response to an KEYING PARAMS received in 212 the R1 message. The sender must select one of the proposed 213 transforms from the SP parameter in the R1 message and include the 214 selected one in the SP parameter in the I2 packet. In addition to 215 the transform, the host includes the RAND parameter, containing the 216 random value (and optionally MKI) to be used as a salt by the peer 217 host. In the R2 message, HIP exchange is finalized. 219 4.1.2. Rekeying 221 Rekeying can be supported using the UPDATE packet of HIP. The peer 222 which wants to rekey should use the UPDATE packet with the 223 appropriate parameters. The mechanism is explained below: 225 Initiator Responder 227 UPDATE: KEYING PARAMS [, DIFFIE_HELLMAN] 228 -----------------------------------------------> 229 UPDATE: KEYING PARAMS [, DIFFIE_HELLMAN] 230 <----------------------------------------------- 231 Fig 2:Rekeying mechanism 233 Figure 2 depicts the rekeying scenario. Here, assume that the 234 Initiator wants to rekey after the Initial exchange. It can send the 235 rekeying parameters in the Update packet. The same mechanism is 236 followed here, the Initiator chooses its Diffie-Hellmann value and 237 sends it to the Responder. It may send a new MKI value to identify 238 the incoming packet. 240 The other parameters are explained in [I-D.ietf-hip-base]. The 241 Responder checks the return routability by sending the Update seq 242 message containing its Diffie-Hellmann value and relevant parameters 243 for the rekeying. After receiving the packet, the Initiator sends 244 the ACK thereby both the peers concluding the rekeying procedure and 245 now, both of the peers expect to receive the traffic in the new 246 keying material. 248 5. Parameter and Packet Formats 250 This section explains the relationship between the SRTP and KEYING 251 parameter and presents the proposed packet format. 253 Master Key - derived from Diffie-Hellmann value 255 Master Salt - RAND in the KEYING parameter 257 MKI - Master Key Identifier 259 Master Key and its length - obtained from Diffie-Hellmann key 260 exchange 262 Session keys are derived using Master key, Master salt and SP and the 263 details are up to the key managament protocol. 265 As discussed previously, KEYING parameters contains four element: 267 5.1. Timestamp 269 The timestamp, used mainly to prevent replay attacks. Like in the 270 SRTP packet format a 32-bit value is used to store the timestamp. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Timestamp (T) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Fig 4: Timestamp parameter 282 Type: 40001 (experimental identifier range) 283 Length: 4 284 Value: Timestamp 286 5.2. Pseudo-random byte-string (RAND) 288 The RAND or master salt parameter is used as a fresh value for the 289 key generation. The RAND parameter is a 112 bit quantity. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 | | 298 | Pseudo-random byte-string (RAND) | 299 | | 300 | | 301 | | 302 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Fig 5: Pseudo-random byte-string parameter 308 Type: 40002 (experimental identifier range) 309 Length: 14 310 Value: Pseudo-random byte-string 312 5.3. Security Policies (SP) 314 The security policies for the data security protocol. (eg. algorithms 315 and transforms and PRFs supported by the peers). The cipher suites 316 can be negotiated from I2/R2 packet. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ~ Security policy parameters ~ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Fig 6: Security policy parameters parameters 328 Type: 40004 (experimental identifier range) 329 Length: variable 330 Value: See below 332 The security policy parameters themselves are built up by a set of 333 Type/Length/Value fields: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Length | Value ~ 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Type (8 bits): specifies the type of the parameter. 343 Length (8 bits): specifies the length of the Value field (in bytes). 345 Value (variable length): specifies the value of the parameter. 347 Type | Length | Meaning | Value 348 -----+--------+----------------------------+-------------------- 349 1 | 1 | SRTP and SRTCP encr transf | see below 350 2 | 2 | Encr session key length | 128 351 3 | 1 | SRTP and SRTCP auth transf | see below 352 4 | 2 | Auth session key length | 160 353 5 | 2 | Tag length | 80 354 6 | 4 | SRTP prefix_length | var(default 0) 355 7 | 1 | Key derivation PRF | see below 356 8 | 8 | Key derivation rate | var(default 0) 357 9 | 8 | SRTP-packets-max-lifetime | var 358 10 | 8 | SRTCP-packets-max-lifetime | var 359 11 | 1 | Forward Error Control | 2-bits 361 For the Encryption transforms, a one byte length is enough. The 362 currently defined possible values are: 364 SRTP and SRTCP encr transf | Value 365 ---------------------------+------ 366 NULL | 0 367 AES-CM | 1 368 AES-F8 | 2 370 where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [RFC3711]. 372 For the Authentication transforms, a one byte length is enough. The 373 currently defined possible Values are: 375 SRTP and SRTCP auth transf | Value 376 ----------------------------+------ 377 NULL | 0 378 HMAC-SHA-1 | 1 380 For the Key derivation PRF, a one byte length is enough. The 381 currently defined possible values are: 383 Key derivation PRF | Value 384 ------------------------+------- 385 NULL | 0 386 AES_CM | 1 388 5.4. Master Key Identifier (MKI) 390 The MKI identifies the master key and master salt from which the 391 session key(s) were derived that authenticate and/or encrypt the 392 particular packet. 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 ~ MKI (variable) ~ 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Fig 7: SRTP MKI parameter 404 Type: 40001 (experimental identifier range) 405 Length: variable 406 Value: Master Key Identifier (MKI) 408 6. Key management 410 This section explains how the key management scheme can be used for 411 the data traffic. After the initial base exchange, both peers have 412 the same master key, salt and agreed crypto transforms (including 413 pseudo random function). When the application receives the data 414 traffic after the base exchange, an API is invoked and asks the HIP 415 daemon for the appropriate key to process the data packet. 417 The SRTP based key derivation helps to generate the session keys for 418 both peers, so that they have the same keys in possession for 419 encrypting/decrypting the incoming packets. It generates three keys 420 namely encryption key to provide confidentiality for the data 421 packets, authentication key for providing integrity and salt key for 422 the AES counter mode. For that, it uses the master key, salt and 423 crypto transforms together with the packet index. 425 Figure 6 depicts the example implementation architecture of the 426 proposed mechanism: 428 +------------+ 429 -------------+ API | KEY ENGINE | 430 Application |<------------->| | 431 | | | 432 | | | 433 | | HIP daemon | 434 | +------------+ 435 | 436 User space | 437 -------------+ 438 PF_INET || || PF_RAW 439 ==================||==========||============= 440 || || 441 Kernel space 442 +--------------+ 443 | TCP|UDP / IP | 444 +--------------+ 446 Fig 5: Example Implementation Architecture 448 Figure 6 depicts the key derivation, for example, when the peer 449 receives a packet it gets the packet index, MKI, which is used for 450 identifying the relevant master key and transforms. Then, the key 451 derivation function, which is explained below, will generate the 452 required keys. 454 packet index ---+ 455 | 456 v 457 +-----------+ master +--------+ session encr_key 458 | ext | key | |----------> 459 | key mgmt |-------->| key | session auth_key 460 | (optional | | deriv |----------> 461 | rekey) |-------->| | session salt_key 462 | | master | |----------> 463 +-----------+ salt +--------+ 465 Fig 6: SRTP Key Derivation 467 For single key derivation (key_derivation_rate = 0), we define x for 468 later use in calculating keys using PRF and length of PRF bit string 469 output like shown in the following table: 471 X ROC || SEQ Usage PRF output length n 472 --------------------------------------------------------------- 473 0x00 000000000000 SRTP encryption 128 bit 474 0x01 000000000000 SRTP message auth. 160 bit 475 0x02 000000000000 SRTP salting key 112 bit 476 0x03 000000000000 SRTCP encryption 128 bit 477 0x04 000000000000 SRTCP message auth. 160 bit 478 0x05 000000000000 SRTCP salting key 112 bit 479 PRF_n (master_key, x) 481 For multiple key derivation (key_derivation_rate = 1,2,...2E24) 482 x must be calculated according to the following sequence: 484 r = index / key_derivation_rate 485 (with "/" defines r = 0 for key_derivation_rate = 0) 487 with index is a 48-bit concatenation of the 32 bit Roll Over Counter 488 (ROC) and the 16 bit sequence number of the SRTP packet given in the 489 SRTP header (ROC||SEQ) 491 r must be the same length like index, which results in leading zeros. 493 Next concatenate an 8-bit label for selecting the usage with r 494 key_id =