RFC 4563

RFC 4563: The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) ✨

Okay bestie, here's the header situation 🎀 This is an Internet Standards Track doc from the Network Working Group, written by E. Carrara (KTH) and V. Lehtovirta and K. Norrman (both Ericsson). It's dated June 2006 🌸 The header doesn't list any RFC that it obsoletes or updates, so there's nothing it replaces or patches.

Part 1 of 2 💖

---

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Copyright Notice 💅

Copyright (C) The Internet Society (2006).

Abstract 🌈

Okay so this memo adds a brand-new Type (the Key ID Information Type) to the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol 🔑 It's used in things like the Multimedia Broadcast/Multicast Service from the Third Generation Partnership Project. Iconic. 👑

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................2
   2. Rationale .......................................................2
   3. Relations to MIKEY and GKMARCH ..................................3
   4. The Key ID Information Type for the General Extension Payload ...4
   5. Empty Map Type Definition for the CS ID Map Type ................5
   6. Transport Considerations ........................................5
   7. Security Considerations .........................................5
   8. IANA Considerations .............................................7
   9. Acknowledgements ................................................7
   10. References .....................................................8
      10.1. Normative References ......................................8
      10.2. Informative References ....................................8

1. Introduction ✨

Okay so the Third Generation Partnership Project (3GPP) is currently building a multicast and broadcast service, the Multimedia Broadcast/Multicast Service (MBMS) 📡 It also has its own security architecture [MBMS], and that's the bit we care about here.

[MBMS] needs the Multimedia Internet KEYing (MIKEY) Protocol [RFC3830] to carry the keys and related security parameters that are needed to secure multimedia that's multicast or broadcast 🔐

One of the security requirements MBMS has is being able to update the keys often 🔄 The reasoning is that it'll be expensive for subscribers to re-distribute the decryption keys to non-subscribers 💸 Re-distributing the keys over the unicast channel should be pricier than just buying the keys, otherwise the scheme doesn't work. Main character logic, honestly 💅 To make this happen, MBMS uses three-level key management: it distributes group keys to the clients, and it can re-key by pushing down a new group key 🦋 As the section below explains, MBMS needs a way to figure out which types of keys are involved in a MIKEY message, plus their identities 🧚

So this memo defines a new Type for the General Extension Payload in MIKEY, to identify the type and identity of the keys involved 🫶

1.1. Conventions Used in This Document 📝

Here's the vocab you need to know. 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 🌸

Okay so the main use case for this extension is MBMS key management 💖 MBMS uses three-level key management, and the keys get used in the way described below. "Clients" means 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 each client.
• The MBMS Service Key (MSK), a group key between the multicast server and all the clients.
• The MBMS Traffic Key (MTK), a group traffic key between the multicast server and all clients.

The Traffic Keys are the ones that get updated regularly 🔄

The point-to-point MUK (the first-level key) is shared between the multicast server and the client through means that MBMS defines [MBMS] 🤝 The MUK acts as a pre-shared key to run MIKEY with the pre-shared key method [RFC3830], and it's also how the MSK gets delivered point-to-point 📬 The same MSK is pushed to all the clients and used as a (second-level) group key 🍓

Then the MSK is used to push an MTK (third-level key) to all the clients ✨ The MTK is the actual group key that protects the media traffic. For example, in the streaming case, the MTK could be the master key for the Secure Real-time Transport Protocol (SRTP) [RFC3711] 🎬

A Key Domain identifier defines the domain where the group keys are valid or applicable. For example, it might name a specific service provider 🌈

To make the key distribution above work, a MIKEY message needs to indicate the type and identity of the keys it carries 🔑 That indication rides in a new Type of the General Extension Payload in MIKEY 💜

It's also necessary to specify which Crypto Session ID (CS ID) map type goes with a given key 🙈 In some cases, like the download case in MBMS, the required parameters are signalled in-band. Each downloaded Digital Rights Management Content Format object [DCF] contains the parameters the receiver needs to process it 📦 Since those parameters aren't carried by MIKEY, a CS ID map type needs to be registered as the "empty map" (see Table 3), which gets used when the map/policy information is conveyed outside of MIKEY 🧚

3. Relations to MIKEY and GKMARCH 🦋

According to [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 as both a registration protocol and a re-key protocol. The extension specified here adds what's needed on top of [RFC3830], so MIKEY can work as both a unicast and a multicast re-key protocol in the MBMS setting 🌸

7. Security Considerations 🔐✨

Okay bestie, this is the spicy section 🌶️ so pay attention. Using MIKEY to update the MTK in broadcast mode (the stuff from Section 2) is not how MIKEY [RFC3830] was originally designed, so it's a bit of a rebel. There are two big things to know about security here 👑

First, the MTK delivery is not source origin authenticated. Instead, it's protected by a group MAC that's keyed with the group key (MSK) 🫣 The problem is that anyone in the group can send fake MTK messages to other group members. The MTK messages come from a node inside the core network, and the MBMS trust model says only trusted traffic (from inside the operator's network) gets sent on the MBMS bearers. But traffic can still be injected on the air interface between the base stations and the user equipment. Group members with access to the MSK could spoof MTK updates to other members. 3GPP looked at it and decided the technical difficulties and costs of pulling that off are high enough compared to what an attacker would gain, so the risk was judged acceptable 🤷‍♀️

Also, since the MTK delivery isn't source origin authenticated, adding source origin authentication to the RTP streams (for example with SRTP-TESLA [RFC4383]) gets you nothing. So the current use of this extension is not compatible with SRTP-TESLA, which needs 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. The MTK, though, is delivered under protection by the group key MSK, so source origin authentication isn't achieved 🙈

Second, the MTK delivery is separated from the security policy delivery. The security policy comes along with the MSK. MTKs are expected to show up frequently (some scenarios need them only a few seconds apart), so if the security policy rode along with every single MTK, the bandwidth cost would be super high 💸 On top of that, the policy parameters of a streaming session usually don't change during the session, even when the MTK gets updated. 3GPP decided there was no need to update the policy during an ongoing session, and that the cost of allowing it, just to be on the safe side, would be too much. That said, updating the security policy mid-session would still 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]. In that case, MIKEY is only used to provide the master key for the DCF processing 🎀

8. IANA Considerations 📋

Per 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 in the CS ID map type namespace of the Common Header Payload 🧚

A new value in the MIKEY General Extension Payload Type name space has been registered for this purpose. The registered value for Key ID is 3, according to Section 4 🍓

The value 1 has also been registered for the Empty map in the existing CS ID map namespace of the Common Header Payload, as specified in Table 3 in Section 5 ✨

A new name space has been set up for the following field in the Key ID information sub-payload (from Sections 4 and 5), and IANA will manage it:

• Key ID Type

IANA has registered the pre-defined types from Table 2 for this namespace. IANA will also handle any additional values in the future. Values in the range 0-240 for each name space SHOULD be approved through the IETF consensus process, and values in the range 241-255 are reserved for Private Use, according to [RFC2434] 🌈

9. Acknowledgements 🫶

Huge thanks to Fredrik Lindholm 💜

10. 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, 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/Multicast Service".

10.2. Informative References

• [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
• [DCF] Open Mobile Alliance, OMA-DRM-DCF-V2_0-20050329-C, "DRM Content Format V2.0", Candidate Version 2.0 - 29 March 2005.
• [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
• [RFC4046] Baugher, 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 in BCP 78. Except as set out there, the authors keep all their rights.

This document and the information in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether a license under those rights is available. It also doesn't claim to have made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to tell it about any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🌸