RFC 2627
Key Management for Multicast: Issues and Architectures
Key Management for Multicast: Issues and Architectures 💖
Okay bestie, this is RFC 2627 🎀, filed under the Network Working Group. It's Informational, so it's giving "here's some good info" and not "you must do this." The authors are D. Wallner, E. Harder, and R. Agee from the National Security Agency, and it's dated June 1999 📅. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here ✨.
Status of this Memo 📜
This memo provides information for the Internet community 📚. It does not specify an Internet standard of any kind 🙅. Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved. 💜
Abstract 🦋
This report is all about the tricky problem of key management for multicast communication sessions 😭. It focuses on two main areas: initializing the multicast group with a common net key, and rekeying the multicast group 🔑. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey) 🔄.
The big highlight is a technique that allows for secure compromise recovery, and it's also robust against collusion of excluded users 👑. This is a feature that most other multicast key management proposals [1,2,4] haven't really dug into, so it's a whole main character moment 💅. The benefits are that it minimizes the number of transmissions required to rekey the multicast group, and it imposes minimal storage requirements on the multicast group 🧚.
1.0 MOTIVATION 🌸
Future networks are going to have requirements that really strain what current key management architectures can do 😳. One of those requirements is the secure multicast requirement 🔥. There's a huge need for high bandwidth, very dynamic secure multicast communications, and it's showing up everywhere: commercial, government, and Internet communities alike 🌍.
So what is the secure multicast requirement, exactly? It's when multiple users who share the same security attributes and communication requirements need to securely talk to every other member of the multicast group, using one common multicast group net key 🫶. The biggest perk of multicast is that multiple receivers simultaneously get the same transmission 📡. The problem, then, is getting every user to determine or obtain the same net key without letting unauthorized parties do the same (that's initializing the multicast group), and securely rekeying the users of the multicast group whenever that's needed 🔐.
At first glance, this might not seem any different from current key management scenarios 🙈. This paper will show, however, that future multicast scenarios will have very divergent and dynamically changing requirements, and that makes them very challenging to address from a key management perspective 💀.
2.0 INTRODUCTION 🧚
The networks of the future will support gigabit bandwidths for individual users, all the way up to large groups of users 🚀. These users will have various quality of service options and multimedia applications that include video, voice, and data, all running on the same network backbone 🎬. People in a bunch of different communities are really into the idea of making small groups of users who can all talk to each other, while staying securely isolated from everyone else on the network 🫧.
The key management infrastructure has to support bandwidths ranging from kilobits/second to gigabits/second, handle a range of multicast group sizes, and be flexible enough to handle environments like wireless and mobile technologies 📶. On top of those performance needs, the security requirements of different scenarios are also super wide-ranging 🎭. It is required that users can be added and removed securely and efficiently, both individually and in bulk 🧹. The system must be resistant to compromise, meaning users who have been dropped should not be able to read any subsequent traffic, even if they share their secret information 🙅♀️.
The costs we're trying to minimize are the time required for setup, the storage space for each end user, and the total number of transmissions required for setup, rekey, and maintenance 💸. It's also expected that any proposed multicast security mechanisms will be implemented no lower than any layer with the characteristics of the network layer of the protocol stack 🥞. Bandwidth efficiency for any key management system must also be considered ⚡. The trade-off between security and performance across the entire multicast session establishment will get a closer look later in this document 🔍.
Here's the roadmap 🗺️: the next section explains several potential scenarios where multicast capabilities may be needed, and quantifies their requirements from both a performance and security perspective. After that, Section 4.0 lists factors you need to consider when designing a potential solution 🧠. Several security services get covered at some point in this document, but most of the focus is on generating and distributing multicast group net keys 🔑. It is assumed that all potential multicast participants, through some manual or automated, centralized or decentralized mechanism, have already received initialization keying material (e.g. certificates) 📇. This document does not address the initialization key distribution issue 🙅. Section 5 will then detail several potential multicast key management architectures, both manual (symmetric) and public key based (asymmetric), and highlight their relative advantages and disadvantages (Note: The list of advantages and disadvantages is by no means all inclusive.) ⚖️. This section especially emphasizes our technique, which allows for secure compromise recovery 💖.
3.0 MULTICAST SCENARIOS ✨
okay so there are a bunch of scenarios that could totally stress out the key management infrastructure 😭 like wargaming, law enforcement, teleconferencing, command and control conferencing, disaster relief, and distributed computing (and more, not just these). 🌸 The big stuff to look at for each one is the potential multicast group sizes, how fast users need to be brought online (initialization requirements), how fast someone needs to be added or deleted after setup (add/drop requirements), size dynamics (how many people are joining or leaving per unit of time), top level security requirements, and misc special issues for that scenario. 💅 Some of these are future needs and some are needed RIGHT NOW, no cap. 🔥
let's look at two examples, distributed gaming and teleconferencing. 🎀
Distributed gaming is basically the government simulating a conflict for training and evaluation 🎮. It's not just real comms gear, it's a huge web of computer simulations with stuff like video conferencing and image processing. 🧚 Honestly it can be MORE demanding from a key management perspective than an actual scenario, and here's why. First, the simulation nodes might be spread out all over the country 🗺️.
Second, really big bandwidth is what makes real time simulation possible, and that means users have to get dropped in and out of the sim super quickly ⚡. This is potentially the most demanding scenario of ANY we looked at, periodt. 👑
This one could have group sizes of 1000 or more participants 🫶, and some of them might be grouped into smaller subgroups. 💜 The groups have to be initialized really fast, like a ten second total initialization time ⏱️. It's also super intense because users might need to be added or dropped within one second 😭. For size dynamics, we estimate around ten percent of group members might change over a one minute period 🦋. Data rates are all over the place, from kilobits per second (simulating tactical users) all the way up to gigabits per second (multicast video) 🌈. The distributed gaming scenario has a pretty thorough set of security requirements covering access control, user to user authentication, data confidentiality, and data integrity 🔐. It also has to be "robust," which means it has to handle noisy operating environments that are typical for some tactical devices 📡. And availability applies here too, which means the communications network giving you the multicast capability has to be up and functioning for a specified percentage of the time ✨.
Teleconferencing is the less dramatic sibling 🌷. It may involve group sizes of potentially 1000 or more participants too 🙈. These groups may take up to minutes to initialize. It's less demanding because users may need to be added or dropped within seconds instead of within one second 🍓. For size dynamics, we estimate around ten percent of group members may change over a period of minutes 🕰️. Data rates range from kilobits per second to 100's of Mb per second 💖. The teleconference scenario also has a pretty thorough set of security requirements covering access control, user to user authentication, data confidentiality, data integrity, and non-repudiation 💅. Availability is applicable here too 🫧. And the time frame for when this scenario must be provided is now 🚨.
4.0 ARCHITECTURAL ISSUES 🏗️
there are SO many factors you have to take into account when you're building the desired key management architecture 🧠. The big ones are level (strength) of security, cost, initializing the system, policy concerns, access control procedures, performance requirements, and support mechanisms 💜. On top of that, multicast groups bring their own set of issues, including:
- What are the security requirements of the group members? Most likely there will be some group controller, or controllers 👑. Do the other members possess the same security requirements as the controller(s)? 🤔
- Interdomain issues: when you cross from one "group domain" to another domain with a potentially different security policy, which policy is enforced? 🌉 For example, say two users want to communicate but have different cryptoperiods and/or key length policies 🙃.
- How does the formation of the multicast group happen? Will the group controller start the user joining process, or will the users start it themselves when they join the formation of the multicast group? 🦋
- How do you handle the case where certain group members have inferior processing capabilities that could delay the formation of the net key? 🐢 Do these users hold up the whole multicast group, or do they come online later so everyone else can get brought up faster? ⚡
- You have to minimize the number of bits required for multicast group net key distribution 📉. This really impacts bandwidth limited equipment 🫠.
All of these issues and more need to be considered, along with the communication protocols that will support the multicast capability you want ✨. The next section digs into some of these and presents some candidate architectures that could tackle the key management problem for multicasting 🎀.
5.0 CANDIDATE ARCHITECTURES 🧩
there are a few basic functions that have to happen for a secure multicast session to work at all 💅. The order these functions happen in, and how efficient the whole solution ends up being, comes down to trade-offs between the factors we listed above 🌈. Before we look at specific architectures, let's outline these basic functions and define some terms we'll use in the representative architectures 📚. Here they are:
- Someone decides a multicast session is needed, sets the security attributes for that session (e.g., classification levels of traffic, algorithms to be used, key variable bit lengths, etc.), and creates the group access control list, which we'll call the initial multicast group participant list 📝. The entity doing all of that is called the INITIATOR 👑. At this point, the multicast group participant list is strictly a list of users the initiator wants in the multicast group 🫶.
- The initiator decides who will control the multicast group. This controller is called the ROOT (or equivalently the SERVER) 🖥️. Often the initiator becomes the root, but control can also be handed off to someone other than the initiator 🤝. (Some key management architectures employ multiple roots, see [4].) The root's job is to add and delete group participants, do user access control against the security attributes of that session, and distribute the traffic encryption key for the session, which we'll call the multicast group NET KEY 🔑. After initialization, the entity with the authority to accept or reject adding future group participants, or deleting current ones, is called the LIST CONTROLLER 💅.
This may or may not be the initiator. The list controller is separated from the root for reasons that will become clear later 👀. In short, it may be desirable for someone to have the authority to accept or reject new members, while another party (the root) actually performs the function 🧚.
- Every participant in the multicast session is called a GROUP PARTICIPANT 🌸. Specific group participants other than the root or list controller are called LEAVES 🍃.
- After the root checks the security attributes of the participants on the multicast group participant list to make sure they all support the required security attributes, the root passes the multicast group list to all other participants and creates and distributes the Net Key 🔐. If a participant on the list didn't meet the required security attributes, that leaf must be deleted from the list ❌.
Multiple issues can come up with distributing the multicast group list and Net Key 😵💫.
a. There's an issue with the time ordering of these functions. The multicast group list could be distributed before or after the link is secured (i.e., the Net Key is distributed) ⏳.
b. There's an issue when a leaf refuses to join the session. If a leaf refuses, we can send out a modified list before sending the Net Key, but sending out modified lists, potentially multiple times, would be inefficient 🙄. Instead, the root could just keep going and would not send the Net Key to those participants on the list who rejected the session 🏃♀️.
For the scenario architectures that follow, we assume the multicast group list will be distributed to the group participants once before the Net Key is distributed 📬. Unlike the scheme described in [4], we recommend that the multicast group participant list be provided to all leaves 💜. By distributing this list to the leaves, they can figure out upfront whether they want to participate in the multicast group or not, which saves potentially unnecessary key exchanges 🦋.
Four potential key management architectures for distributing keying material for multicast sessions are presented next 🎁. Remember that the features that are highly desirable for the architecture include: the time required to set up the multicast group should be minimized, the number of transmissions should be minimized, and memory/storage requirements should be minimized 🧠. As you'll see, the first three proposals each fall short in a different aspect of these desired qualities 🥲, whereas the fourth proposal appears to strike a balance across the features we want 🫶. So the fourth proposal is the one recommended for general implementation and use 👑✨.
Heads up, bestie: these approaches also address securely eliminating users from the multicast group, but they don't specifically address adding new users after the initial setup, because that's seen as evident as to how it would be done 🙈.
5.1 Manual Key Distribution 🔑✨
okay bestie, so with manual key distribution the symmetric key gets delivered without any public key exchanges 🗝️💅 To set up a multicast group, Net Key with manual key distribution needs a whole sequence of events where Net Key and spare Net Keys get ordered by the root of the multicast session group. Alternate (supersession) Net Keys also get ordered by the root, to be used if a group participant (or participants) gets compromised 😭 The Net Keys get distributed to each individual group participant, often through some centralized physical intermediate location. At some predetermined time, everyone switches to the new Net Key. Group participants keep using this Net Key until a predetermined time when they need another new Net Key. If the Net Key gets compromised during that time, the alternate Net Key gets used. Participants switch to the alternate Net Key as soon as they receive it, or when the root notifies them that everyone has the new Net Key and the switchover should happen. This whole procedure gets repeated for each cryptoperiod 🔁
A scheme like this may be attractive because the methods already exist and users already understand them 🎀 Unfortunately, it can take forever to set up the multicast group, since it depends on how long it takes to order the keying material and get it delivered 🐢 For most real time scenarios, this method is much too slow 💀
5.2 N Root/Leaf Pairwise Keys Approach 🌸
this one is a brute force method to give the whole multicast group a common Net Key 💪 The initiator sets the security attributes for a particular session, makes a list of the group participants they want, and sends that list to everyone on it. The leaves respond with an initial acceptance or rejection of participation. Sending the list up front saves time, because nobody has to do key exchanges with people who already said no 🙅♀️ The root (who, for this and future examples, is assumed to be the initiator) generates a pairwise key with one of the participants, the leaves, using some standard public key exchange technique (for example, a Diffie-Hellman public key exchange.) Then the root gives the security association parameters of the multicast (which may be different from the parameters of the initial pairwise key) to that first leaf. Parameters may include things like classification and policy 📋 Some negotiation of the parameters may be necessary, through a Security Association Management Protocol, or SAMP. The leaf is allowed to reject the connection to the multicast group based on those parameters and the multicast group list. If the leaf rejects the session, the root just repeats this process with another leaf 🔄
Once a leaf accepts participation in the multicast session, the two of them choose a Net Key to be used by the group 🤝 The Net Key could be generated through another public key exchange between the two entities, or simply chosen by the root, depending on the policy in place for the multicast group (i.e. this policy decision will not be a real time choice). The tricky bit is how much trust the leaf has in the root 👀 If the initial pairwise key exchange provides some level of user authentication, then it seems fine to just have the root select the Net Key at this stage. Another question is how much trust there is in the strength of the generated key's security. With a cooperative process, both entities (leaf and root) provide information that gets used to form the Net Key, which is very teamwork-coded ✨
The root then does a pairwise key exchange with another leaf and optionally does the negotiation we talked about earlier. Once that leaf accepts joining the multicast group, the root sends the leaf the Net Key 🎁
This pairwise key exchange and Net Key distribution keeps going for all N users of the multicast group 🔁
Root and leaves cache pairwise keys for later use. These keys serve as Key Encryption Keys (KEKs) that get used to rekey leaves in the net at a later time 🔐 Only the root caches all of the leaves' pairwise keys. Each individual leaf caches only its own unique pairwise Key Encryption Key.
There are two cases to think about when caching the KEKs 🧠 The first case is when the Net Key and KEK are per session keys. Here, if you want to exclude a group participant from the multicast session (and rekey the remaining participants with a new Net Key), the root distributes a new Net Key encrypted with each individual KEK to every legitimate remaining participant. These KEKs get deleted once the multicast session is completed 🗑️
The second case is when the KEKs are valid for more than one session. In this case, the Net Key may also be valid for multiple sessions, or the Net Key may still only be valid for one session, like in the case above. Whether the Net Key is valid for one session or more than one session, the KEK will be cached. If the Net Key is only valid per session, the KEKs get used to encrypt new Net Keys for later multicast sessions. Deleting group participants works the same as in the previous case, whether the Net Key is per session or meant for multiple sessions 💖
A scheme like this may be attractive to a user, because it is a straightforward extension of certifiable public key exchange techniques 📜 It may also be attractive because it does not involve third parties. Only the participants who are part of the multicast session take part in the keying mechanism 🫶 What makes this scheme so undesirable is that it is transmission intensive as we scale up in numbers, even for the most computationally efficient participants, not to mention those with less capable hardware (tactical, wireless, etc.) 😩 Every time you need to drop an "unauthorized" participant, a new Net Key has to be distributed 🚫
This distribution requires a transmission from the Root to each remaining participant, where the new Net Key gets encrypted under the cover of each participant's unique pairwise Key Encryption Key (KEK) 🔒
Note: This approach is essentially the same as one proposal to the Internet Engineering Task Force (IETF) Security Subworking Group [Ref 1,2].
Also, there are lots of twists you can put on an approach like this 🌈 For example, instead of having the root do all N key exchanges, the root could hand some of that functionality (and control) to a number of leaves beneath it. Say the multicast group list gets split in half: the root tells one leaf to take half of the users and do a key exchange with them (and then distribute the Net Key), while the root takes care of the other half of the list. (The chosen leaves are functioning as a root, so we can call them "subroots." These subroots have leaves beneath them, and the subroots maintain the KEK of each leaf beneath them.) This scales better than the original approach as N gets large 📈 Specifically, it takes less time to set up (or rekey) the multicast net, because the job of performing pairwise key exchanges and distributing the Net Key gets shared among multiple group participants and can happen in parallel. In the original approach, the root is the only one distributing the Net Key to all of the participants 🏃♀️💨
This scheme isn't free of security concerns, though 😬 It pushes trust down to each subgroup controller, since the root assumes these "subroot" controllers are acting in a trustworthy way. Every control element (root and subroots) must remain in the system throughout the multicast. This makes removing someone from the net (especially a subroot) harder and slower because of the distributed control. When you remove a participant who has been functioning as a subroot on behalf of the root, distributing the Net Key, extra steps are needed. A new subroot must be delegated by the root to replace the removed subroot. A key exchange (to generate a new pairwise KEK) must happen between the new subroot and each leaf the removed subroot was responsible for. Then a new Net Key gets distributed from the root, to the subroots, and to the leaves. Note that this last step would have been the only step required if the removed party was a leaf with no controlling responsibilities 🫠
5.3 Complementary Variable Approach 🦋
okay so let's say we have N leaves 🌟 The Root performs a public key exchange with each leaf i (i= 1,2, ..., N). The Root caches each pairwise KEK, and each leaf stores its own KEK. The root gives the multicast group list of participants and attributes to all users. Participants accept or reject participation in the multicast session, same as described in the previous sections 🙋♀️ The root encrypts the Net Key for the multicast group to each leaf, using that leaf's own unique KEK(i). (The Root either generated this Net Key himself, or generated it cooperatively with one of the leaves, as we talked about earlier.) On top of the encrypted Net Key, the root also encrypts something called complementary variables and sends them to the leaves 🎀
A leaf will NOT receive its own complementary variable, but it will receive the other N-1 leaf complementary variables 🙈 The root sends the Net Key and complementary variables j, where j=1,2,...,N and j not equal to i, encrypted by KEK(i) to each leaf. So every leaf receives and stores N variables, which are the Net Key and N-1 complementary variables 📦
So if you want to cut a user from the multicast group and get the remaining participants back up on a new Net Key, here's how it goes 💅 Basically, to cut leaf number 20 out of the net, one message gets sent out that says "cut leaf 20 from the net." All of the other leaves (and the Root) generate a new Net Key based on the current Net Key and complementary variable 20. [Thus some type of deterministic key variable generation process will be necessary for all participants of the multicast group.] This newly generated variable gets used as the new Net Key by all remaining participants of the multicast group. Everyone except leaf 20 can generate the new Net Key, because they have complementary variable 20, but leaf 20 does not 🤯
A scheme like this seems really desirable from the transmission savings point of view, since a rekey message encrypted with each individual KEK to every leaf doesn't have to be sent to delete someone from the net. In other words, you get one plaintext message to the multicast group versus N encrypted rekey messages ⚡ There are two major drawbacks with this scheme, though 🥲 The first is the storage requirements for the (N-1) complementary variables. The second is that when deleting multiple users from the multicast group, collusion becomes a concern. That means the deleted users could work together and share their individual complementary variables to regain access to the multicast session 🚨
5.4 HIERARCHICAL TREE APPROACH 🌳✨
okay bestie, the Hierarchical Tree Approach is our recommended approach for the multicast key management problem 💅 it gives you these must-have features:
- Provides for the secure removal of a compromised user from the multicast group
- Provides for transmission efficiency
- Provides for storage efficiency
it's giving balance 🫶 it weighs the cost of time, storage, and how many messages have to be sent, using a hierarchy of auxiliary keys to help distribute a new Net Key. the result is that both the storage each user needs and the transmissions needed for a key replacement grow logarithmically with the number of users, and there are no background transmissions at all 🔥 it's also robust against collusion of excluded users. the scheme is hierarchical, but it doesn't need any infrastructure beyond a server (like a root). the presence of other elements could be used to your advantage tho 👀 (see Figure 1)
--------------------------
| |
| S E R V E R |
| |
--------------------------
| | |
| | . . . . |
- - -
|1| |2| |n|
- - -Figure 1: Assumed Communication Architecture
okay so the scheme, its advantages, and its disadvantages get broken down in more detail below 🧚 check out Figure 2. it shows the logical key distribution architecture, where keys only exist at the server and at the users. so in this setup the server holds Keys A through O, plus the KEKs of each user. and User 11 holds its own unique KEK, plus Keys F, K, N, and O 💖
net key Key O
-------------------------------------
intermediate | |
keys | |
Key M Key N
----------------- --------------------
| | | |
| | | |
Key I Key J Key K Key L
-------- -------- --------- ----------
| | | | | | | |
| | | | | | | |
Key A Key B Key C Key D Key E Key F Key G Key H
--- --- --- --- --- ---- ---- ----
| | | | | | | | | | | | | | | |
- - - - - - - - - -- -- -- -- -- -- --
|1| |2| |3| |4| |5| |6| |7| |8| |9| |10| |11| |12| |13| |14| |15| |16|
- - - - - - - - - -- -- -- -- -- -- --
usersFigure 2: Logical Key Distribution Architecture
next up, we look at how the key hierarchy gets organised and set up 🌸 it'll be super clear how to add users once the hierarchy is in place, and we'll also cover removing a user. ngl the passing of the multicast group list and any negotiation protocols is not part of this chat, just to keep things simple 🙈
we build a rooted tree from the bottom up, with one leaf for each user, like in Figure 2. (the tree is drawn as a balanced binary tree just for convenience, but it doesn't have to be balanced or binary. some preliminary analysis on tree shaping has been done ✨) each user sets up a unique pairwise key with the server. for users who can transmit, this can happen through the public key exchange protocol. receive-only users are trickier, so it's easiest to assume they have a pre-placed key 🎀
once every user has a pairwise key the server knows about, the server generates a key for every remaining node in the tree, following the security policy in place for that session. the keys themselves should be generated by a robust process 💜 we also assume users know nothing about keys they don't need. (note: the remaining nodes have no users, since they're just logical nodes, and the server alone generates each key by secure means.) starting with the nodes whose children are all leaves and working toward the root, the server sends the key for each node, encrypted under the keys of that node's children. by the end, each user can work out the keys for every node above her leaf. and yes, every user ends up holding the root key, which is the shared Net Key for the group 👑
a user at depth d stores d+1 keys. so for the Figure 2 example, a user at depth d=4 holds five keys: the unique Key Encryption Key from the pairwise key exchange, three intermediate node keys (each one separately encrypted and sent), and the common Net Key for the multicast group, which is also separately encrypted 🧚
there's also a way to send all of the intermediate node keys and the root node key in one message. in that case, every node key is encrypted with the unique pairwise key of the individual leaf. so each user only needs one transmission (a bigger message) to get all the node keys, instead of d transmissions 🍓 with this method, the leaf needs some way to figure out which key goes with which node level.
heads up: this approach needs extra processing power at the server, which other approaches might not need. in the worst case, the server has to generate all the intermediate keys in the architecture 😭
5.4.1 The Exclusion Principle 🔐
okay now the spicy part 🔥 say User 11 (marked in black on Figure 2) needs to get kicked out of the multicast group. then every key User 11 holds (the bolded Keys F, K, N, O) has to be changed and handed out to the users who need them, without letting User 11 or anyone else get their hands on them. we replace the bolded keys User 11 has, working from the bottom up. the server picks a new key for the lowest node, then sends it encrypted with the right daughter keys (those transmissions are the dotted lines). so in this example, Key F gets replaced first, and the new key goes out encrypted with User 12's unique pairwise key 💖
since we go bottom up, each replacement key is already replaced before it gets used to encrypt anything else. for example, the new Key K goes to User 12 encrypted in the newly replaced Key F, and it also goes out as one multicast transmission encrypted in the node key shared by Users 9 and 10 (Key E). the new Key N goes to Users 9, 10, and 12 encrypted in the newly replaced Key K, and also gets encrypted in the node key shared by Users 13, 14, 15, and 16 (Key L). the new Key O goes to Users 9, 10, 12, 13, 14, 15, and 16 encrypted in the newly replaced Key N, and also gets encrypted in the node key shared by Users 1, 2, 3, 4, 5, 6, 7, and 8 (Key M) ✨
the number of transmissions is the sum of the degrees of the replaced nodes. in a k-ary tree where a sits at depth d, that comes to at most kd-1 transmissions. so in this example, it takes seven transmissions to exclude User 11 from the multicast group and get the other 15 users onto a new multicast group Net Key that User 11 can't access 🌈 it's easy to see that the system is robust against collusion: no set of users together can read any message unless one of them could have read it on their own 💅
if you use the same strategy from the previous section and send multiple keys in one message, the number of transmissions can drop even further, down to four transmissions 🦋 just note that the messages get bigger in bits. there also has to be a way for each leaf to figure out which key in the message goes with which node of the hierarchy. so in this example, the four replacement keys (F, K, N, and O) go to User 12 in one message encrypted under User 12's unique pairwise key. keys K, N, and O go to Users 9 and 10 in one message encrypted under the node key shared by Users 9 and 10 (Key E). keys N and O go to Users 13, 14, 15, and 16 in one message encrypted under the node key they share (Key L). and key O goes to Users 1 through 8 encrypted under the node key they share (Key M). so the number of transmissions needed is at most (k-1)d 🎀
the table below shows what happens when a user gets removed, and how storage and transmission needs grow as the number of users grows 📊
Table 1: Storage and Transmission Costs
Number Degree Storage per user Transmissions to Transmissions
of users (k) (d+1) rekey remaining to rekey
participants of remaining
multicast group- participants of
one key per message multicast
(kd-1) group -
multiple keys
per message
(k-1)d
8 2 4 5 3
9 3 3 5 4
16 2 5 7 4
2048 2 12 21 11
2187 3 8 20 14
131072 2 18 33 17
177147 3 12 32 22The benefits of this scheme are so iconic 😭✨
- The costs of user storage and rekey transmissions stay balanced and scalable as the number of users goes up 📈 This is not the case for [1], [2], or [4] 💅
- The auxiliary keys can carry other keys and messages 🦋 So the hierarchy can put subgroups that want to talk securely (i.e. without transmitting to the rest of the large multicast group) under particular nodes. That means no separate Net Keys for those subgroups, which is lowkey genius. This works best if the users already operate in a hierarchy to begin with (e.g., military operations), since the key hierarchy can reflect that.
- The hierarchy can mirror the network architecture, which boosts efficiency because each user gets fewer irrelevant messages 🌸 Server responsibilities can also be split up among subroots (all of which must be secure).
- The security risk tied to receive-only users can be minimized by collecting them in one particular area of the tree 🧚
- This approach is resistant to collusion among arbitrarily many users. Not even a little bit of drama 👑
As noted earlier, in the rekeying process after one user is compromised, with one key per message, each replaced key has to be decrypted successfully before the next key can be replaced (unless users can cache the rekey messages). Honestly, this bottleneck could be a real problem on a noisy or slow network 🙈 (If multiple users are being removed, this can be parallelized, so the expected time to rekey is roughly independent of the number of users removed.)
By increasing the valences and decreasing the depth of the tree, you can reduce the storage requirements for users, but at the price of increased transmissions 🍓 For example, in the one key per message case, if n users are arranged in a k-ary tree, each user will need storage. Rekeying after one user is removed now requires transmissions. As k approaches n, this approaches the pairwise key scheme described earlier in the paper ✨
5.4.2 Hierarchical Tree Approach Options 🎀
5.4.2.1 Distributed Hierarchical Tree Approach
Okay, the Hierarchical Tree Approach from this section could be distributed as described in Section 5.2, so it looks more like the proposal put forth in [4] 💖 Subroots could exist at each of the nodes to handle any joining or rekeying needed for any of the subordinate users. This could be especially attractive for users who don't have a direct connection back to the Root. Remember from Section 5.2 that trusting these subroots to act with the authority and security of a Root is a potentially dangerous proposition 😬 [4] echoes this thought too.
Some practical recommendations for these subroots include the following. The subroots should not be allowed to change the multicast group participant list that they've been given by the Root. One method to accomplish this would be for the Root to sign the list before providing it to the subroots. Authorized subroots could, though, be allowed to set up new multicast groups for users below them in the hierarchy 🦋
It's important to note that although this distribution may seem to help with the time required to initialize the multicast group (compared to the time required to initialize the group as described in Section 5.4) and with periodic rekeying, it does not appear to provide any benefit when rekeying the multicast group after a user has been compromised 💀
It's also noted that whatever the key management scheme is (hierarchical tree, distributed hierarchical tree, core based tree, GKMP, etc.), there will be a "hit" incurred to initialize the multicast group with the first multicast group net key. So the hierarchical tree approach does not suffer from additional complexity compared to the other schemes when it comes to initialization 🧚
5.4.2.2 Multicast Group Formation
Although this paper presented the formation of the multicast group as being Root initiated, the hierarchical approach is consistent with user initiated joining 🌈 User initiated joining is the method of multicast group formation presented in [4]. It may be desirable when some core subset of users in the multicast group need to be brought online and communicating more quickly. Other participants can then be brought in whenever they wish. With this type of approach, though, there is no finite period of time by which it can be ensured that all participants will be part of the multicast group.
For example, in the case of a single root, the hierarchy is set up once, at the beginning, by the initiator (also usually the root), who also generates the group participant list. The group of keys for each participant can then be individually requested (pulled) as soon as, but not until, each participant wishes to join the session 🫶
5.4.2.3 Sender Specific Authentication
In the multicast environment, participants may at times want to uniquely identify which participant is the sender of a multicast group message 🔍 In the multicast key distribution system described by Ballardie [4], the notion of "sender specific keys" is presented.
Another option for letting participants of a multicast group uniquely determine the sender of a message is a signature process. When a member of the multicast group signs a message with their own private signature key, the recipients of that signed message can use the sender's public verification key to determine whether the message really is from who it claims to be from ✍️
Another related idea is when two users of a multicast group want to communicate strictly with each other and don't want anyone else to listen in 🤫 If this communication relationship is known when the multicast group is originally set up, then these two participants could simply be placed adjacent to one another at the lowest level of the hierarchy (below a binary node). They would then naturally share a secret pairwise key. Otherwise, a simple way to do this is to perform a public key based pairwise key exchange between the two users to generate a traffic encryption key for their private unicast communications. Through this process, not only will the encrypted transmissions between them be readable only by them, but unique sender authentication can also be accomplished via the public key based pairwise exchange 💜
5.4.2.4 Rekeying the Multicast Group and the Use of Group Key Encryption Keys
[4] makes use of a Group Key Encryption Key that can be shared by the multicast group for use in periodic rekeys of the multicast group. Aside from the potential security drawbacks of implementing a shared key for encrypting future keys, a Group Key Encryption Key is of no benefit to a multicast group if a rekey is necessary due to the known compromise of one of the members 🚨 The strategy for rekeying the multicast group presented in Section 5.4.1 specifically addresses this critical problem and offers a way to accomplish the task with minimal message transmissions and storage requirements 👑
The question can now be asked whether a rekey of the multicast group is necessary in a non-compromise scenario. For example, if a user decides they no longer want to participate in the group and asks the list controller to remove them from the multicast group participant list, will a rekey be necessary? If the security policy of the multicast group mandates that deleted users can no longer receive transmissions, then a rekey of a new net key will be required. If the multicast group security policy doesn't care that the deleted person can still decrypt transmissions (encrypted under the group net key they might still hold), but does care that they cannot encrypt and transmit messages, a rekey will once again be necessary. The only alternative to rekeying the multicast group in this scenario would be for a recipient to check every received message's sender against the group participant list, rejecting any message sent by a user not on the list. This is not a practical option 🙅♀️ So it's recommended to always rekey the multicast group when someone is deleted, whether it's because of compromise or not 🔐
5.4.2.5 Bulk Removal of Participants
As indicated in Section 2, the need may arise to remove users in bulk 📦 If the users are set up as discussed in Section 5.4.1 into subgroups that want to communicate securely, all under the same node, then bulk removal can be done quite simply if the whole node is to be removed. The same technique described in Section 5.4.1 is used to rekey any shared node key that the remaining participants hold in common with the removed node.
Bulk removal gets harder when the participants to be removed are dispersed throughout the tree 😵💫 Depending on how many participants are removed and where they're located in the hierarchy, the number of transmissions required to rekey the multicast group could be equivalent to brute force rekeying of the remaining participants. The question also comes up of at what point the remaining users should be restructured into a new hierarchical tree, or whether a new multicast group should be formed. Restructuring the hierarchical tree would most likely be the preferred option, because it wouldn't require performing pairwise key exchanges again to form the new user unique KEKs ✨
5.4.2.6 ISAKMP Compatibility
So far this document has focused mainly on the architectural trade-offs involved in generating, distributing, and maintaining the traffic encryption keys (Net Keys) for multicast groups 🧠 There are other elements involved in establishing a secure connection among the multicast participants that haven't been discussed in any detail. For example, the concept of being able to "pick and choose" and negotiate the capabilities of the key exchange mechanism and various other elements is a very important and necessary aspect 💅
The NSA proposal to the Internet Engineering Task Force (IETF) Security Subworking Group [Ref. 3], entitled "Internet Security Association and Key Management Protocol (ISAKMP)", has attempted to identify the various functional elements required for establishing a secure connection for the largest current network, the Internet 🌐 While the proposal has currently focused on the problem of point to point connections, the functional elements should be the same for multicast connections, with appropriate changes to the techniques chosen to implement the individual functional elements. Thus, implementing ISAKMP is compatible with the use of the hierarchical tree approach 🩷
6.0 Summary ✨
okay so here's the tea 🫖 there are two big problems when you're trying to solve multicast key management. 🔥 The first is getting a multicast group set up securely (initialization). The second is rekeying the group with a shared net key, which is the part where things get messy. 😭 Lots of papers already cover initialization, but they don't really handle how to kick out a compromised user quickly and securely. That's the gap, bestie. 💀
So this paper proposed a hierarchical tree approach to fix that. 🌳 It's robust against collusion (aka a bunch of bad actors teaming up), and it balances how many transmissions and how much storage you need to rekey the group when something goes wrong. Iconic. 👑
It's also worth noting that this proposal lines up with other multicast key management solutions [4] 🫶 and gives you multiple options for how to actually implement it. Main character energy, periodt. 💅
7.0 Security Considerations
Security concerns are discussed throughout this memo. 🔐🛡️ Like, the whole thing is basically about keeping the group safe, so keep that in mind as you read. 🙈
8.0 References
- Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Architecture", RFC 2094, September 1994. 📚
- Harney, H., Muckenhirn, C. and T. Rivers, "Group Key Management Protocol Specification", RFC 2093, September 1994. 📚
- Maughan, D., Schertler, M. Schneider, M. and J.Turner, "Internet Security Association and Key Management Protocol, Version 7", February 1997. 📚
- Ballardie, T., "Scalable Multicast Key Distribution", RFC 1949, May 1996. 📚
- Wong, C., Gouda, M. and S. Lam, "Secure Group Communications Using Key Graphs", Technical Report TR 97-23, Department of Computer Sciences, The University of Texas at Austin, July 1997. 📚
Authors' Addresses 🎀
Debby M. Wallner
National Security Agency
Attn: R2
9800 Savage Road STE 6451
Ft. Meade, MD. 20755-6451
Phone: 301-688-0331
EMail: dmwalln@orion.ncsc.milEric J. Harder
National Security Agency
Attn: R2
9800 Savage Road STE 6451
Ft. Meade, MD. 20755-6451
Phone: 301-688-0850
EMail: ejh@tycho.ncsc.milRyan C. Agee
National Security Agency
Attn: R2
9800 Savage Road STE 6451
Ft. Meade, MD. 20755-6451Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💜
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 🧚
📦 where this page comes from
- ietf: rfc2627 1999-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms