idnits 2.17.1 draft-ietf-msec-newtype-keyid-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. ** 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 151: '...ese applications MUST define the seman...' RFC 2119 keyword, line 218: '...this case, there MUST NOT be any Secur...' RFC 2119 keyword, line 316: '... each name space SHOULD be approved by...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 2006) is 6609 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MBMS' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Carrara (KTH) 3 Lehtovirta, Norrman (Ericsson) 4 INTERNET-DRAFT 5 EXPIRES: September 2006 March 2006 7 The Key ID Information Type for the General Extension Payload in MIKEY 8 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire in September 2006. 35 Abstract 37 This memo specifies a new Type (the Key ID Information Type) for the 38 General Extension Payload in the Multimedia Internet KEYing 39 Protocol. This is used in, e.g., the Multimedia Broadcast/Multicast 40 Service specified in the 3rd Generation Partnership Project. 42 TABLE OF CONTENTS 44 1. Introduction...................................................2 45 2. Rationale......................................................2 46 3. Relations to MIKEY and GKMARCH.................................4 47 4. The Key ID Information Type for the General Extension Payload..4 48 5. Empty map type definition for the CS ID map type...............5 49 6. Transport Considerations.......................................6 50 7. Security Considerations........................................6 51 8. IANA Considerations............................................7 52 9. Acknowledgements...............................................8 53 10. Author's Addresses............................................8 54 11. References....................................................8 56 1. Introduction 58 The 3rd Generation Partnership Project (3GPP) is currently involved 59 in the development of a multicast and broadcast service, the 60 Multimedia Broadcast/Multicast Service (MBMS), and its security 61 architecture [MBMS]. 63 [MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) 64 Protocol [RFC3830], to convey the keys and related security 65 parameters needed to secure the multimedia that is multicast or 66 broadcast. 68 One of the requirements that MBMS puts on security is the ability to 69 perform frequent updates of the keys. The rationale behind this is 70 that it will be costly for subscribers to re-distribute the 71 decryption keys to non-subscribers. The cost for re-distributing the 72 keys using the unicast channel should be higher than the cost of 73 purchasing the keys for this scheme to have an effect. To implement 74 this, MBMS uses a three level key management, to distribute group 75 keys to the clients, and be able to re-key by pushing down a new 76 group key. As illustrated in the section below, MBMS has the need 77 to identify which types of key are involved in the MIKEY message, 78 and their identity. 80 This memo specifies a new Type for the General Extension Payload in 81 MIKEY, to identify the type and identity of keys involved. 83 2. Rationale 85 An application where this extension is used is MBMS key management. 87 The key management solution adopted by MBMS uses three level key 88 management. The keys are used in the way described below. 89 "Clients" refers to the clients who have subscribed to a given 90 multicast/broadcast service. 92 * The MBMS User Key (MUK), point-to-point key between the multicast 93 server and each client 95 * The MBMS Service Key (MSK), group key between the multicast server 96 and all the clients 98 * The MBMS Traffic Key (MTK), group traffic key between the 99 multicast server and all clients. 101 The Traffic Keys are the keys that are regularly updated. 103 The point-to-point MUK key (first-level key) is shared between the 104 multicast server and the client via means defined by MBMS [MBMS]. 105 The MUK is used as pre-shared key to run MIKEY with the pre-shared 106 key method [RFC3830], to deliver (point-to-point) the MSK key. The 107 same MSK key is pushed to all the clients, to be used as a (second- 108 level) group key. 110 Then, the MSK is used to push to all the clients an MTK key (third- 111 level key), the actual group key that is used for the protection of 112 the media traffic. For example, the MTK could be the master key for 113 the Secure Real-time Transport Protocol (SRTP) [RFC3711] in the 114 streaming case. 116 A Key Domain identifier defines the domain where the group keys are 117 valid or applicable. For example it may define a specific service 118 provider. 120 To allow the key distribution described above, an indication of the 121 type and identity of keys being carried in a MIKEY message is 122 needed. This indication is carried in a new Type of the General 123 Extension Payload in MIKEY. 125 It is necessary to specify what Crypto Session ID (CS ID) map type 126 is associated with a given key. There are cases, for example the 127 download case in MBMS, where the required parameters are signalled 128 in-band (each downloaded Digital Rights Management Content Format- 129 object [DCF] contains the necessary parameters needed by the 130 receiver to process it). Since the parameters are not transported 131 by MIKEY, this implies that a CS ID map type needs to be registered 132 to the "empty map" as defined in Table 3, which is to be used when 133 the map/policy information is conveyed outside of MIKEY. 135 3. Relations to MIKEY and GKMARCH 137 MIKEY according to [RFC3830] is a registration protocol that 138 supports re-keying for unicast in the terms of the MSEC Group Key 139 Management Architecture [RFC4046]. MBMS uses MIKEY both as a 140 registration protocol and a rekey protocol, and the specified 141 extension implements the necessary additions to [RFC3830] that 142 allows MIKEY to function both as a unicast and multicast rekey 143 protocol in the MBMS setting. 145 4. The Key ID Information Type for the General Extension Payload 147 The General Extension payload in MIKEY is defined in Section 6.15 of 148 [RFC3830]. The General Extension payload type (Key ID Information) 149 defined in the present document is not restricted to MBMS. 150 Applications using this General Extension payload type may define 151 new Key ID types, and these applications MUST define the semantics 152 and usage of the Key ID Type sub-payloads according to Section 8. 153 The MBMS use of the Key ID Type sub-payloads defined in Table 2 is 154 specified in [MBMS]. 156 The Key ID Information Type (Type 3) formats the General Extension 157 payload as follows: 159 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 ! Next payload ! Type ! Length ! 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 ! Key ID Information ~ 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1. The Key ID Information General Extension Payload. 169 Next Payload and Length are defined in Section 6.15 of [RFC3830]. 171 * Type (8 bits): identifies the type of the General Extension 172 Payload [RFC3830]. This memo adds Type 3 to the ones already 173 defined in [RFC3830]. 175 Type | Value | Comments 176 ------------------------------------------------------------ 177 Key ID | 3 | information on type and identity of keys 179 Table 1. Definition of the new General Extension Payload. 181 * Key ID Information (variable length): the general payload data 182 transporting the type and identifier of a key. This field is 183 formed by Key ID Type sub-payloads as specified below. 185 The Key ID Type sub-payload is formatted as follows: 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 ! Key ID Type ! Key ID Length ! Key ID ~ 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 2. The Key ID Type sub-payload. 193 * Key ID Type (8 bits): describes the type of the key ID. 194 Predefined types are listed in Table 2. 196 Key ID Type | Value | Comment 197 -------------------------------------- 198 MBMS Key Domain ID | 0 | ID of the group key domain 199 MBMS Service Key ID | 1 | ID of the group key 200 MBMS Transport Key ID | 2 | ID of the group traffic key 202 Table 2. Type definitions for Key IDs. 204 * Key ID Length (8 bits): describes the length of the Key ID 205 field in octets. 207 * Key ID (variable length): defines the identity of the key. 209 Note that there may be more than one Key ID Type sub-payload in an 210 extension, and that the overall length (i.e., the sum of lengths of 211 all Key ID Type sub-payloads) of the Key ID information field cannot 212 exceed 2^16 - 1 octets. 214 5. Empty map type definition for the CS ID map type 216 When the security policy information is conveyed outside of MIKEY, 217 the CS ID map type is set to value defined in Table 3 to indicate 218 "empty map". In this case, there MUST NOT be any Security Policy 219 payload present in the message. 221 CS ID map type | Value | Comments 222 ------------------------------------------------------------ 223 Empty map | 1 | Used when the map/policy information 224 | | is conveyed outside of MIKEY 226 Table 3. Definition of the CS ID map type. 228 6. Transport Considerations 230 As specified in Section 7 of [RFC3830], the underlying transport of 231 the MIKEY protocol has to be defined for each type of transport. 232 When the Key-ID payload is used with MBMS, the transport is UDP, and 233 the usage of MIKEY over UDP in the MBMS setting is defined in 234 [MBMS]. 236 7. Security Considerations 238 The usage of MIKEY for updating the traffic encryption key (MTK) in 239 the broadcast manner, described in Section 2, deviates from the way 240 MIKEY [RFC3830] was originally designed. There are mainly two 241 points that are related to the security of the described usage. 243 First, the delivery of the MTK is not source origin authenticated, 244 but rather protected by a group MAC, keyed by the group key (MSK). 245 The threat this raises is that users that are part of the group are 246 able to send faked MTK messages to other group members. The origin 247 of the MTK messages is a node inside the core network, and the trust 248 model used in MBMS, is that only trusted traffic is allowed to be 249 sent on the MBMS bearers (from within the operator's network). 250 However, there is always the risk that traffic is injected on the 251 air interface between the base stations and the user equipment. It 252 is possible for members of the group (i.e., with access to the MSK) 253 to spoof MTK updates to other members of the group. 3GPP decided 254 that the technical difficulties and costs involved in performing 255 such an attack are large enough compared to the expected gain for 256 the attacker, that the risk was deemed acceptable. Note that, since 257 the delivery of the MTK is not source origin authenticated, there is 258 nothing gained by adding source origin authentication to the RTP 259 streams (e.g., using SRTP-TESLA [SRTP_TESLA]). Hence, the current 260 use of the specified extension is not compatible with SRTP-TESLA, 261 which requires source origin authentication of the integrity key. 263 Note that in MBMS the MSK is protected end-to-end, from the 264 multicast server to the clients, using a client-unique key MUK, but 265 the MTK is delivered under protection by the group key MSK, so 266 source origin authentication is not achieved. 268 Secondly, the delivery of the MTK is separated from the delivery of 269 the security policy. The security policy is delivered with the MSK. 270 The delivery of the MTKs is assumed to be very frequent (some 271 scenarios require the delivery of MTKs to be as frequent as a few 272 seconds apart). This would imply that the cost (in terms of 273 bandwidth) would be very high if the security policy was delivered 274 together with each MTK. Furthermore, the security policy parameters 275 of the streaming session are not anticipated to change during the 276 session, even though there would be an update of the MTK. It was 277 decided in 3GPP that there was no need for updating the policy 278 during an ongoing session, and the cost of allowing such a feature, 279 only to be on the safe side, would be too high. On the other hand, 280 updating the security policy during an ongoing session would be 281 possible by updating the MSK. 283 The Empty map type used when the security policy is delivered in 284 band relies on the security provided by DCF [DCF], and MIKEY is in 285 this case only used to provide the master key for the DCF 286 processing. 288 8. IANA Considerations 290 Please add the following to the IANA registry at 291 http://www.iana.org/assignments/mikey-payloads (To be removed by 292 after IANA processing). 294 According to Section 10 of RFC 3830, IETF consensus is required to 295 register values in the range 0-240 in the Type namespace of the 296 MIKEY General Extension Payload and the CS ID map type namespace of 297 the Common Header Payload. 299 A new value in the MIKEY General Extension Payload Type name space 300 needs to be registered for this purpose. The registered value for 301 Key ID is requested to be 3 according to Section 4. 303 It is also requested to register the value 1 for the Empty map in 304 the existing CS ID map namespace of the Common Header Payload as 305 specified in Table 3 in Section 5. 307 The new name space for the following field in the Key ID information 308 sub-payload (from Sections 4 and 5) is requested to be managed by 309 IANA: 311 * Key ID Type 313 It is requested that IANA register the pre-defined types of Table 2 314 for this namespace. IANA is also requested to manage the definition 315 of additional values in the future. Values in the range 0-240 for 316 each name space SHOULD be approved by the process of IETF consensus 317 and values in the range 241-255 are reserved for Private Use, 318 according to [RFC2434]. 320 9. Acknowledgements 322 We would like to thank Fredrik Lindholm. 324 10. Author's Addresses 326 Questions and comments should be directed to the authors: 328 Elisabetta Carrara 329 Royal Institute of Technology 330 Stockholm Phone: 331 Sweden EMail: carrara@kth.se 333 Vesa Lehtovirta 334 Ericsson Research 335 02420 Jorvas Phone: +358 9 2993314 336 Finland EMail: vesa.lehtovirta@ericsson.com 338 Karl Norrman 339 Ericsson Research 340 SE-16480 Stockholm Phone: +46 8 4044502 341 Sweden EMail: karl.norrman@ericsson.com 343 11. References 345 Normative 347 [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC 348 3830, August 2004. 350 [MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation 351 Partnership Project; Technical Specification Group Services and 352 System Aspects; Security; Security of Multimedia Broadcast/Multicast 353 Service." 355 Informative 357 [RFC3711] Baugher et al., "The Secure Real-time Transport Protocol 358 (SRTP)", RFC3711, March 2004. 360 [DCF] OMA, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0", 361 Candidate Version 2.0 - 29 March 2005 363 [SRTP_TESLA] Baugher et al., "The Use of TESLA in SRTP", draft-ietf- 364 msec-srtp-tesla-05.txt. Work in progress. 366 [RFC4046] Baugher et al., "MSEC Group Key Management Architecture", 367 RFC 4046, April 2005. 369 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 370 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 371 1998. 373 Intellectual Property 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed 377 to pertain to the implementation or use of the technology described 378 in this document or the extent to which any license under such 379 rights might or might not be available; nor does it represent that 380 it has made any independent effort to identify any such rights. 381 Information on the procedures with respect to rights in RFC 382 documents can be found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use 387 of such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository 389 at http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at ietf- 395 ipr@ietf.org. 397 Copyright Notice 399 Copyright (C) The Internet Society (2006). This document is subject 400 to the rights, licenses and restrictions contained in BCP 78, and 401 except as set forth therein, the authors retain all their rights. 403 Disclaimer of Validity 405 This document and the information contained herein are provided on 406 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 407 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 408 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 409 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 410 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 413 This Internet-Draft will expire in September 2006.