Internet Engineering Task ForceNetwork Working Group E. Carrara(KTH) Lehtovirta,Request for Comments: 4563 KTH Category: Standards Track V. Lehtovirta K. Norrman(Ericsson) INTERNET-DRAFT EXPIRES: September 2006 MarchEricsson June 2006 The Key ID Information Type for the General Extension Payload inMIKEY <draft-ietf-msec-newtype-keyid-05.txt>Multimedia Internet KEYing (MIKEY) Status ofthis memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis Memo This document specifies an Internet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listthis protocol. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in September 2006.this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in,e.g.,for example, the Multimedia Broadcast/Multicast Service specified in the3rdThird Generation Partnership Project.TABLE OF CONTENTSTable of Contents 1.Introduction...................................................2Introduction ....................................................2 1.1. Conventions Used in This Document ..........................2 2.Rationale......................................................2Rationale .......................................................2 3. Relations to MIKEY andGKMARCH.................................4GKMARCH ..................................3 4. The Key ID Information Type for the General ExtensionPayload..4Payload ...4 5. Emptymap type definitionMap Type Definition for the CS IDmap type...............5Map Type ................5 6. TransportConsiderations.......................................6Considerations ........................................5 7. SecurityConsiderations........................................6Considerations .........................................5 8. IANAConsiderations............................................7Considerations .............................................7 9.Acknowledgements...............................................8Acknowledgements ................................................7 10.Author's Addresses............................................8 11. References....................................................8References .....................................................8 10.1. Normative References ......................................8 10.2. Informative References ....................................8 1. Introduction The3rdThird Generation Partnership Project (3GPP) is currently involved in the development of a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS), and its security architecture [MBMS]. [MBMS] requires the use of the Multimedia Internet KEYing (MIKEY) Protocol[RFC3830],[RFC3830] to convey the keys and related security parameters needed to securethemultimedia that is multicast or broadcast. One of the requirements that MBMS puts on security is the ability to perform frequent updates of the keys. The rationale behind this is that it will be costly for subscribers to re-distribute the decryption keys to non-subscribers. The cost for re-distributing the keys using the unicast channel should be higher than the cost of purchasing the keys for this scheme to have an effect. To implement this, MBMS uses athree levelthree-level key management, to distribute group keys to the clients, and be able to re-key by pushing down a new group key. As illustrated in the section below, MBMS has the need to identify which types ofkeykeys are involved in the MIKEYmessage,message and their identity. This memo specifies a new Type for the General Extension Payload in MIKEY, to identify the type and identity of keys involved. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Rationale An application where this extension is used is MBMS key management. The key management solution adopted by MBMS usesthree levelthree-level key management. The keys are used in the way described below. "Clients" refers to the clients who have subscribed to a given multicast/broadcast service. * The MBMS User Key (MUK), a point-to-point key between the multicast server and eachclientclient. * The MBMS Service Key (MSK), a group key between the multicast server and all theclientsclients. * The MBMS Traffic Key (MTK), a group traffic key between the multicast server and all clients. The Traffic Keys are the keys that are regularly updated. The point-to-point MUKkey(first-level key) is shared between the multicast server and the client via means defined by MBMS [MBMS]. The MUK is used as a pre-shared key to run MIKEY with the pre-shared key method [RFC3830], and to deliver (point-to-point) theMSK key.MSK. The same MSKkeyis pushed to all the clients, to be used as a(second- level)(second-level) group key. Then, the MSK is used to push to all the clients an MTKkey (third- level(third-level key), the actual group key that is used for the protection of the media traffic. For example, the MTK could be the master key for the Secure Real-time Transport Protocol (SRTP) [RFC3711] in the streaming case. A Key Domain identifier defines the domain where the group keys are valid or applicable. Forexampleexample, it may define a specific service provider. To allow the key distribution described above, an indication of the type and identity of keys being carried in a MIKEY message is needed. This indication is carried in a new Type of the General Extension Payload in MIKEY. It is necessary to specify what Crypto Session ID (CS ID) map type is associated with a given key. There arecases, for examplecases (for example, the download case inMBMS,MBMS) where the required parameters are signalled in-band (each downloaded Digital Rights Management ContentFormat-Format object [DCF] contains the necessary parameters needed by the receiver to process it). Since the parameters are not transported by MIKEY, this implies that a CS ID map type needs to be registered to the "emptymap"map", as defined in Table 3, which is to be used when the map/policy information is conveyed outside of MIKEY. 3. Relations to MIKEY and GKMARCHMIKEY accordingAccording to[RFC3830][RFC3830], MIKEY is a registration protocol that supports re-keying for unicast in the terms of the MSEC Group Key Management Architecture [RFC4046]. MBMS uses MIKEY both as a registration protocol and arekeyre-key protocol, and the specified extension implements the necessary additions to [RFC3830] that allows MIKEY to function both as a unicast and multicastrekeyre-key protocol in the MBMS setting. 4. The Key ID Information Type for the General Extension Payload The General Extension payload in MIKEY is defined in Section 6.15 of [RFC3830]. The General Extension payload type (Key ID Information) defined in the present document is not restricted to MBMS. Applications using this General Extension payload type may define new Key ID types, and these applications MUST define the semantics and usage of the Key ID Type sub-payloads according to Section 8. The MBMS use of the Key ID Typesub-payloadssub-payloads, defined in Table22, is specified in [MBMS]. The Key ID Information Type (Type 3) formats the General Extension payload as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. The Key ID Information General ExtensionPayload.Payload Next Payload and Length are defined in Section 6.15 of [RFC3830]. * Type (8 bits): identifies the type of the General Extension Payload [RFC3830]. This memo adds Type 3 to the ones already defined in [RFC3830]. Type | Value | Comments ------------------------------------------------------------ Key ID | 3 | information on type and identity of keys Table 1. Definition of thenewNew General ExtensionPayload.Payload * Key ID Information (variable length): the general payload data transporting the type and identifier of a key. This field is formed by Key ID Type sub-payloads as specified below. The Key ID Type sub-payload is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Type ! Key ID Length ! Key ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The Key ID Typesub-payload.Sub-payload * Key ID Type (8 bits): describes the type of the key ID. Predefined types are listed in Table 2. Key ID Type | Value | Comment------------------------------------------------------------------------------------------------- MBMS Key Domain ID | 0 | ID of the group key domain MBMS Service Key ID | 1 | ID of the group key MBMSTransportTraffic Key ID | 2 | ID of the group traffic key Table 2. Type definitions for KeyIDs.IDs * Key ID Length (8 bits): describes the length of the Key ID field in octets. * Key ID (variable length): defines the identity of the key. Note that there may be more than one Key ID Type sub-payload in an extension, and that the overall length (i.e., the sum of lengths of all Key ID Type sub-payloads) of the Key ID information field cannot exceed 2^16 - 1 octets. 5. Emptymap type definitionMap Type Definition for the CS IDmap typeMap Type When the security policy information is conveyed outside of MIKEY, the CS ID map type is set to a value defined in Table 3 to indicate "empty map". In this case, there MUST NOT be any Security Policy payload present in the message. CS ID map type | Value | Comments------------------------------------------------------------------------------------------------------------------------- Empty map | 1 | Used when the map/policy information | | is conveyed outside of MIKEY Table 3. Definition of the CS IDmap type.Map Type. 6. Transport Considerations As specified in Section 7 of [RFC3830], the underlying transport of the MIKEY protocol has to be defined for each type of transport. When the Key-ID payload is used with MBMS, the transport is UDP, and the usage of MIKEY over UDP in the MBMS setting is defined in [MBMS]. 7. Security Considerations The usage of MIKEY for updating the traffic encryption key (MTK) in the broadcast manner, described in Section 2, deviates from the way MIKEY [RFC3830] was originally designed. There aremainlytwo main points that are related to the security of the described usage. First, the delivery of the MTK is not source origin authenticated, but rather protected by a group MAC, keyed by the group key (MSK). The threat this raises is that users that are part of the group are able to sendfakedfake MTK messages to other group members. The origin of the MTK messages is a node inside the core network, and the trust model used inMBMS,MBMS is that only trusted traffic is allowed to be senton the MBMS bearers(from within the operator'snetwork).network) on the MBMS bearers. However, there is always the risk that traffic is injected on the air interface between the base stations and the user equipment. It is possible for members of the group (i.e., with access to the MSK) to spoof MTK updates to other members of the group. 3GPP decided that the technical difficulties and costs involved in performing such an attack are large enough compared to the expected gain for the attacker, that the risk was deemed acceptable. Note that, since the delivery of the MTK is not source origin authenticated, there is nothing gained by adding source origin authentication to the RTP streams (e.g., using SRTP-TESLA[SRTP_TESLA]).[RFC4383]). Hence, the current use of the specified extension is not compatible with SRTP-TESLA, which requires source origin authentication of the integrity key. Note that in MBMS the MSK is protected end-to-end, from the multicast server to the clients, using a client-unique key MUK, but the MTK is delivered under protection by the group key MSK, so source origin authentication is not achieved. Secondly, the delivery of the MTK is separated from the delivery of the security policy. The security policy is delivered with the MSK. The delivery of the MTKs is assumed to beveryfrequent (some scenarios require the delivery of MTKs to be as frequent as a few seconds apart). This would imply that the cost (in terms of bandwidth) would be very high if the security policy was delivered together with each MTK. Furthermore, the security policy parameters of the streaming session are not anticipated to change during the session, even though there would be an update of the MTK. It was decided in 3GPP that there was no need for updating the policy during an ongoing session, and that the cost of allowing such a feature, only to be on the safe side, would be too high. On the other hand, updating the security policy during an ongoing session would be possible by updating the MSK. The Empty map type used when the security policy is delivered in band relies on the security provided by DCF [DCF], and MIKEYisis, in thiscasecase, only used to provide the master key for the DCF processing. 8. IANA ConsiderationsPlease add the following to the IANA registry at http://www.iana.org/assignments/mikey-payloads (To be removed by after IANA processing).According to Section 10 of RFC 3830, IETF consensus is required to register values in the range 0-240 in the Type namespace of the MIKEY General Extension Payload and the CS ID map type namespace of the Common Header Payload. A new value in the MIKEY General Extension Payload Type name spaceneeds to behas been registered for this purpose. The registered value for Key ID isrequested to be3 according to Section 4.It is also requested to registerAlso, the value 1 has been registered for the Empty map in the existing CS ID map namespace of the Common HeaderPayloadPayload, as specified in Table33, in Section 5. The new name space for the following field in the Key ID information sub-payload (from Sections 4 and 5)is requested tohas been established and will be managed by IANA: * Key ID TypeIt is requested thatThe IANAregisterhas registered the pre-defined types of Table 2 for this namespace. IANAiswill alsorequested tomanage the definition of additional values in the future. Values in the range 0-240 for each name space SHOULD be approved by the process of IETFconsensusconsensus, and values in the range 241-255 are reserved for Private Use, according to [RFC2434]. 9. Acknowledgements We would like to thank Fredrik Lindholm. 10.Author's Addresses Questions and comments should be directed to the authors: Elisabetta Carrara Royal Institute of Technology Stockholm Phone: Sweden EMail: carrara@kth.se Vesa Lehtovirta Ericsson Research 02420 Jorvas Phone: +358 9 2993314 Finland EMail: vesa.lehtovirta@ericsson.com Karl Norrman Ericsson Research SE-16480 Stockholm Phone: +46 8 4044502 Sweden EMail: karl.norrman@ericsson.com 11.References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3830]Arkko et al.,Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [MBMS] 3GPP TS 33.246, "Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security; Security of Multimedia Broadcast/MulticastService."Service". 10.2. Informative References [RFC3711]Baugher et al.,Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)",RFC3711,RFC 3711, March 2004. [DCF]OMA,Open Mobile Alliance, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0", Candidate Version 2.0 - 29 March2005 [SRTP_TESLA] Baugher et al.,2005. [RFC4383] Baugher, M. and E. Carrara, "The Use ofTESLA in SRTP", draft-ietf- msec-srtp-tesla-05.txt. WorkTimed Efficient Stream Loss-Tolerant Authentication (TESLA) inprogress.the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006. [RFC4046]Baugher et al., "MSECBaugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Authors' Addresses Elisabetta Carrara Royal Institute of Technology Stockholm Sweden EMail: carrara@kth.se Vesa Lehtovirta Ericsson Research 02420 Jorvas Finland Phone: +358 9 2993314 EMail: vesa.lehtovirta@ericsson.com Karl Norrman Ericsson Research SE-16480 Stockholm Sweden Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF atietf- ipr@ietf.org. Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document andietf-ipr@ietf.org. Acknowledgement Funding for theinformation contained herein areRFC Editor function is providedon an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft will expire in September 2006.by the IETF Administrative Support Activity (IASA).