idnits 2.17.1 draft-zhou-mmusic-sdes-keymod-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2012) is 4412 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: 'RFC4566' is defined on line 439, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multiparty Multimedia Session Control S. Zhou, Ed. 3 Internet-Draft T. Tian 4 Intended status: Standards Track Z. Xie 5 Expires: September 27, 2012 ZTE Corporation 6 March 26, 2012 8 Security Descriptions Extension for Media Streams 9 draft-zhou-mmusic-sdes-keymod-01 11 Abstract 13 This document provides an extension to the cryptographic attribute 14 (RFC 4568) defined for Session Description Protocol (RFC 4566) to 15 enhance end-to-end communication security, so that some scenarios, 16 e.g., forking and re-targeting can especially benefit from the 17 extension. The usage of the provided extension in Secure Real-time 18 Transport Protocol (SRTP, RFC3711) is also defined in this document. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 27, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Extension to SDES . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Usage of keymod with Offer/Answer . . . . . . . . . . . . . . 4 58 3.1. Generating the Initial Offer - Unicast Streams . . . . . . 5 59 3.2. Generating the Initial Answer - Unicast Streams . . . . . 5 60 3.3. Procesing of the Initial Answer - Unicast Streams . . . . 6 61 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Applicability in Re-targeting Scenarios . . . . . . . . . . . 7 63 5.1. Single CDIV instance . . . . . . . . . . . . . . . . . . . 7 64 5.2. Multiple CDIV instances . . . . . . . . . . . . . . . . . 8 65 5.3. Computation of K1' . . . . . . . . . . . . . . . . . . . . 9 66 6. Applicability in Forking Scenarios . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 To ensure the media security established by Session Initiation 77 Protocol (SIP), SDP Security Descriptions (SDES) is defined in RFC 78 4568 [RFC4568], where a cryptographic attribute and application in 79 Secure Real-time Transport Protocol (SRTP,RFC 3711 [RFC3711]) unicast 80 media streams are provided. 82 SDP Security Descriptions (SDES) is essentially a key transportation 83 scheme in offer/answer model, in which keying material for the 84 direction from offerer to answerer is chosen independently by the 85 offerer and transported in clear text, the keying material for the 86 reverse direction is also chosen independently by the answerer and 87 transported in clear. Later the transported keying materials are 88 provided to SRTP protocol to secure outgoing or incoming media 89 communication. The protection of the transported keying materials 90 obviously relies on the security of the signaling protocol which is 91 beyond the scope of this document. 93 When SDES is applied in some scenarios,e.g., forking and re- 94 targeting, the intermediate users and devices besides the ultimate 95 answerer also have knowledge of the keying material used for the 96 outgoing media from the offerer, which is a security threat to the 97 content of the end-to-end communication in the affected direction. 99 To resolve the problem, it is suggested exchanging a new pair of 100 offer/answer with a new key between the offerer and the ultimate 101 answerer,i.e., by using SIP UPDATE message[RFC3311], but it will 102 require more round trip messages. In this document, a resolution is 103 introduced based on the defined SDES extension. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Extension to SDES 113 Following the ABNF format in Security Descriptions, a new session 114 parameter extension "keymod" is defined as follows: 116 srtp-session-extension = keymod 117 keymod = "keymod:" 118 keymod-info = "|""|" 119 keymod-type = "rand"/"rand-salt"/keymod-type-ext 120 keymod-type-ext = 1*(VCHAR) 121 kdf-func = 1*(ALPHA / DIGIT / "_") 122 keymod-val = *(base64);base64 encoded binary string 123 base64 = ALPHA/DIGIT/"+"/"/"/"=" 125 where base64 encoding follows RFC3548 [RFC3548], ALPHA, DIGIT, and 126 VCHAR are defined in RFC4234 [RFC4234]. 128 The defined "keymod" is a negotiated parameter, which indicates it 129 does not apply to data sent from the answerer to the offerer, as 130 defined in RFC 4568 [RFC4568]. 132 An answer MAY contain keymod value indicating the answerer is asking 133 for the offerer to refresh its keying material using the information 134 following it. 136 If keymod-type is "rand", then only master key is requested to 137 refresh according to specified function kdf-func; 139 If keymod-type is "rand-salt", then master key and master salt are 140 both requested to refresh, the master key will be refreshed according 141 to specified function kdf-func and the refresh method of master salt 142 is simply replacement in this document. 144 The key derivation fumction kdf-func can be as simple as an 145 assignment(defined as "is" ), or an XOR between the old master key 146 and the keymod-val value(defined as "xor"), or as complicated as any 147 other key derivation functions based on cryptographic primitives, 148 e.g., RFC 2104 [RFC2104]. 150 In this document, only the two simple functions are defined:"is" and 151 "xor", that is 153 kdf-func = "is"/"xor"/kdf-func-ext 155 kdf-func-ext= 1*(ALPHA / DIGIT / "_") 157 And if no kdf-func is indicated in keymod-info, the default kdf-func 158 is "is". 160 3. Usage of keymod with Offer/Answer 161 3.1. Generating the Initial Offer - Unicast Streams 163 The generation of the initial offer for a unicast stream MUST follow 164 that of the crypto attribute RFC4568 [RFC4568], and MAY 166 also include an additional "keymod" parameter with keymod-val being 167 NULL. It indicates to the ultimate answerer that the offerer wants 168 to employ the mechanism specified in 170 this document, a key agreement mechanism with a higher security level 171 than the original SDES. 173 3.2. Generating the Initial Answer - Unicast Streams 175 The generation of the initial answer for a unicast stream MUST 176 follows that of the crypto attribute RFC4568 [RFC4568], and if the 177 offer message includes a "keymod" parameter, it SHOULD also include 178 an additional "keymod" parameter. That is, when an offered crypto 179 attribute is accepted, the crypto attribute in the answer MUST 180 contain the following: 182 o The tag and crypto-suite from the accepted crypto attribute in the 183 offer (the same crypto-suite MUST be used in the send and receive 184 direction). 186 o The key(s) the answerer will be using for media sent to the 187 offerer. 189 Additionaly the answer MAY contain: 191 o The keymod parameter for media sent from the offerer to the 192 answerer. 194 The keymod parameter is constrained by the following limits: 196 o If keymod type is "rand", the keymod-val value MUST be at the 197 minimum length required by the specified crypto-suite for the 198 master key. 200 o If keymod type is "rand-salt", the keymod-val value length MUST be 201 no less than the addition of the minimum lengths of master key and 202 master salt required by the specified crypto-suite. 204 The keymod parameter and the master key retrieved from the offer 205 message MAY be used together to derive a new master key used for the 206 media from the offerer to the answerer. 208 3.3. Procesing of the Initial Answer - Unicast Streams 210 When the offerer receives the answer, the offerer MUST do necessary 211 verifications following RFC 4568 [RFC4568]. 213 If the answer includes a "keymod" value in "crypto" attribute, the 214 offerer MUST derive a new master key from the previous master key 215 sent in the offer message and the keymod-info value received in the 216 answer message. 218 Specifically, if the keymod type retrieved from the answer message is 219 "rand", a new master key will be derived from the previous master key 220 and the keymode-val value according to specified key derivation 221 function kdf-func. 223 If the keymod type retrieved from the answer message is "rand-salt", 224 a new master key will be derived from the previous master key and the 225 keymode-val value according to specified key derivation function kdf- 226 func, and the master salt will be replaced with the salt value 227 contained in the keymode-val. 229 The derived new master key and new master salt will be used to 230 protect the media from the offerer to the answerer. 232 4. Example 234 This example shows use of the keymod extension described in this 235 document. The "a=crypto" line is actually a one long line, which is 236 shown as two lines due to page formatting. 238 The following is an offer using crypto attribute indicating deploying 239 keymod, asking the answerer to return a keymod value : 240 v=0 241 o=alice 2890844730 2890844731 IN IP4 host.example.com 242 s= 243 c=IN IP4 192.0.2.1 244 t=0 0 245 m=audio 20000 RTP/AVP 0 246 a=crypto:1 AES_CM_128_HMAC_SHA1_80 247 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 248 keymod:rand|xor| 250 The following is an answer with the keymod extension where type 251 "rand" is chosen and the refreshment of master key is "xor": 253 v=0 254 o=Bob 2890844725 2890844725 IN IP4 host.example.org 255 s= 256 c=IN IP4 192.0.2.2 257 t=0 0 258 m=audio 30000 RTP/AVP 0 259 a=crypto:1 AES_CM_128_HMAC_SHA1_32 260 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; 261 keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew== 263 The following is an answer with the keymod extension where type 264 "rand-salt" is chosen and the refreshments of master key and master 265 salt are both "is": 267 v=0 268 o=Bob 2890844725 2890844725 IN IP4 host.example.org 269 s= 270 c=IN IP4 192.0.2.2 271 t=0 0 272 m=audio 30000 RTP/AVP 0 273 a=crypto:1 AES_CM_128_HMAC_SHA1_32 274 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32; 275 keymod:rand-salt|WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz 277 5. Applicability in Re-targeting Scenarios 279 In this section, applicability of the defined keymod parameter in re- 280 targeting scenarios is provided. 282 Re-targeting, or Communications Diversion (CDIV) service is a widely 283 used communication service which enables a served user to divert the 284 communications addressed to the served user's address to another 285 destination according to the specified service type. As define in 286 RFC 4458 [RFC4458] and 3GPP TS 24.604 [TS], there are several 287 conditions that may incur a CDIV service, e.g., when the served user 288 is at the statuses of "Not reachable" , "User busy", "No reply", or 289 the served user has registered with the CDIV Agent Server (AS) to 290 redirect the call unconditionally.The redirected destination may be 291 another call number or a voice mailbox of the same user. CDIV may 292 happen multiple times consecutively till the last destination, see 293 the example below. 295 5.1. Single CDIV instance 297 See Figure 1, A initiates a call to B by including a crypto attribute 298 with a key parameter K1 and an empty KEYMOD1 in the SIP message. B 299 has subscribed a CDIV service to divert calls to C. When the 300 diversion condition is met, the call is re-invited by the Proxy or 301 CDIV AS to C. Proxy sends re-invite SIP message which includes K1, 302 KEYMOD1 and an additional "cause" value to C (the usage and the 303 specification of the CAUSE parameter refers to RFC 4458 [RFC4458] , 304 then C determines it a CVID call and responds with a SIP message with 305 a key parameter K2 and a keymod parameter KEYMOD2. When A receives 306 the SIP message including K2 and KEYMOD2, A will derive a new key 307 parameter K1' from K1 and KEYMOD2 the same way as C. Thus the 308 communication between A and C is protected by K2 and K1', i.e., A 309 uses K1' to protect the media sent from A to C, and C uses K2 to 310 protect the media sent from C to A. 312 A Proxy B C 313 | | | | 314 |---INVITE(K1,KEYMOD1)-->| | | 315 | |---INVITE(K1,KEYMOD1)--->| | 316 | |------CDIV triggered-----| | 317 | |---INVITE(K1,CAUSE,KEYMOD1)------>| 318 | |<--------200 OK(K2,KEYMOD2)-------| 319 |<----200 OK(K2,KEYMOD2)-| | | 320 |---------------------------K1'encrypted media------------->| 321 |<-------------------K2 encrypted media---------------------| 323 Figure 1 325 5.2. Multiple CDIV instances 327 See Figure 2, A initiates a call to B by including a crypto attribute 328 with a key parameter K1 and an empty KEYMOD1 in the SIP message. B 329 has subscribed a CDIV service to divert calls to C. When the 330 diversion condition for B is met, the call is re-invited by the CDIV 331 AS to C. C has also subscribed a CDIV service to divert calls to D. 332 When the diversion condition for C is met, the call is re-invited by 333 the Proxy or CDIV AS to D. Proxy sends re-invite SIP message which 334 includes K1, KEYMOD1 and an additional "cause" value to D (the usage 335 and the specification of the CAUSE parameter refers to RFC 4458 336 [RFC4458], then D determines it a CVID call and responds with a SIP 337 message with a key parameter K2 and a keymod parameter KEYMOD2. When 338 A receives the SIP message including K2 and KEYMOD2, A will derive a 339 new key parameter K1' from K1 and KEYMOD2 the same way as D. Thus the 340 communication between A and D is protected by K2 and K1', i.e., A 341 uses K1' to protect the media sent from A to D, and D uses K2 to 342 protect the media sent from D to A. 344 A Proxy B C D 345 | | | | | 346 |-INVITE(K1,KEYMOD1)->| | | | 347 | |---INVITE(K1,KEYMOD1)-->| | | 348 | |-CDIV triggered---------| | | 349 | |------INVITE(K1,CAUSE,KEYMOD1)->| | 350 | |-----CDIV triggered-------------| | 351 | |--------INVITE(K1,CAUSE,KEYMOD1)------>| 352 | |<---------200 OK(K2, KEYMOD2)----------| 353 |<-200 OK(K2,KEYMOD2)-| | | | 354 |-------------------------K1'encrypted media----------------->| 355 |<-------------------K2 encrypted media-----------------------| 357 Figure 2 359 5.3. Computation of K1' 361 n the above examples, if key method "inline" is used in key 362 parameter. K1 consists of a master key msk1 and a master salt mss1, 363 K2 consists of a master key msk2 and a master salt mss2. 365 If keymod type is "rand", the keymod-val contained in KEYMOD2 is used 366 to calculate the new master key: 368 msk1'=kdf-func(keymod-val, msk1) 370 If keymod type is "rand-salt", the keymod-val contained in KEYMOD2 371 can be divided into two parts, key and salt, a new master key will be 372 calculated as: 374 msk1'=kdf-func(keymod-val(key), msk1) 376 and a new master salt will be: 378 mss1'=keymod-val(salt). 380 6. Applicability in Forking Scenarios 382 In this section, applicability of the defined keymod parameter in 383 forking scenarios is provided, see the example below. 385 See Figure 3, A initiates a call to a user U by including a crypto 386 attribute with a key parameter K1, an empty KEYMOD1 in the SIP 387 message. And U has multiple devices, e.g., B,C,D, then the call is 388 forked to all the devices till user U answers the call from D. D 389 responds with a SIP message with a key parameter K2 and a keymod 390 parameter KEYMOD2. When A receives the SIP message including K2 and 391 KEYMOD2, A will derive a new key parameter K1' from K1 and KEYMOD2 392 the same way as D. Thus the communication between A and D is 393 protected by K2 and K1', i.e., A uses K1' to protect the media sent 394 from A to D, and D uses K2 to protect the media sent from D to A. The 395 computation of K1' is exactly the same as in Section 5.3 397 A Proxy B C D 398 | | | | | 399 |-INVITE(K1,KEYMOD1)->| | | | 400 | |--INVITE(K1,KEYMOD1)-->| | | 401 | |-----INVITE(K1,KEYMOD1)------>| | 402 | |--------INVITE(K1,KEYMOD1)---------->| 403 | |<------200 OK(K2, KEYMOD2)-----------| 404 |<-200 OK(K2,KEYMOD2)-| | | | 405 |------------------------K1'encrypted media---------------->| 406 |<------------K2 encrypted media----------------------------| 408 Figure 3 410 7. IANA Considerations 412 This document includes no request to IANA. 414 8. Security Considerations 416 This document includes an extension to the crypto attribute defined 417 inRFC 4568 [RFC4568], so the security considerations are mostly the 418 same, except that the described solution improves a security drawback 419 when RFC 4568 [RFC4568] is applied in some specific scenarios, i.e., 420 forking and re-targeting. 422 9. References 424 9.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 430 Encodings", RFC 3548, July 2003. 432 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 433 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 434 RFC 3711, March 2004. 436 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 437 Specifications: ABNF", RFC 4234, October 2005. 439 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 440 Description Protocol", RFC 4566, July 2006. 442 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 443 Description Protocol (SDP) Security Descriptions for Media 444 Streams", RFC 4568, July 2006. 446 9.2. Informative References 448 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 449 Hashing for Message Authentication", RFC 2104, 450 February 1997. 452 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 453 UPDATE Method", RFC 3311, October 2002. 455 [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session 456 Initiation Protocol (SIP) URIs for Applications such as 457 Voicemail and Interactive Voice Response (IVR)", RFC 4458, 458 April 2006. 460 [TS] "3GPP TS 24.604 Communication Diversion (CDIV) using IP 461 Multimedia (IM) Core Network (CN) subsystem; Protocol 462 specification". 464 Authors' Addresses 466 Sujing Zhou (editor) 467 ZTE Corporation 468 No.68 Zijinghua Rd. Yuhuatai District 469 Nanjing, Jiang Su 210012 470 R.R.China 472 Email: zhou.sujing@zte.com.cn 473 Tian Tian 474 ZTE Corporation 475 No.68 Zijinghua Rd. Yuhuatai District 476 Nanjing, Jiang Su 210012 477 P.R.China 479 Phone: +86-025-5287-7867 480 Email: tian.tian1@zte.com.cn 482 Zhenhua XIe 483 ZTE Corporation 484 No.68 Zijinghua Rd. Yuhuatai District 485 Nanjing, Jiang Su 210012 486 P.R.China 488 Phone: +86-25-52871287 489 Fax: +86-25-52871000 490 Email: xie.zhenhua@zte.com.cn