RFC 3740
The Multicast Group Security Architecture
📜 The Multicast Group Security Architecture 🦋
okay bestie, this one is RFC 3740 💖 It's from the Network Working Group and it's Informational, so it's giving "here's some info" and not a standard 🙈 It was written by T. Hardjono from Verisign and B. Weis from Cisco, and it's dated March 2004. The header doesn't list anything it obsoletes or updates, so no drama there ✨
Status of this Memo 🌸
This memo is for the Internet community to read as information. It is not an Internet standard of any kind, and anyone can distribute it freely ✨
Copyright Notice 🎀
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 🔥
okay so this doc gives an overview and the reasoning behind the multicast security architecture 💅 that locks down data packets for really big multicast groups. It starts by introducing a Multicast Security Reference Framework, then goes through the security services that can be part of a secure multicast solution. It's giving organized, no cap 🧚
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Summary of Contents of Document. . . . . . . . . . . . . 3
1.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Design: The Multicast Security Reference
Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4
2.2.1. Group Controller and Key Server. . . . . . . . . 6
2.2. Elements of the Centralized Reference Framework. . . . . 5
2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7
2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 7
2.3. Elements of the Distributed Reference Framework. . . . . 8
3. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9
3.2. Group Key Management . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Security Policies. . . . . . . . . . . . . . . 11
4. Group Security Associations (GSA). . . . . . . . . . . . . . . 12
4.1. The Security Association . . . . . . . . . . . . . . . . 12
4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13
4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14
4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
4.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 17
5. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18
5.2. Multicast Source Authentication and Data Integrity . . . 18
5.3. Multicast Group Authentication . . . . . . . . . . . . . 19
5.4. Multicast Group Membership Management. . . . . . . . . . 19
5.5. Multicast Key Management . . . . . . . . . . . . . . . . 20
5.6. Multicast Policy Management. . . . . . . . . . . . . . . 21
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22
6.2. Group Key Management . . . . . . . . . . . . . . . . . . 22
6.3. Multicast Security Policies. . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 261. Introduction ✨
securing IP multicast group communication is a complex task with lots of moving parts 🧩 Because of that, a secure IP multicast protocol suite must have a number of functional areas that each handle a different part of the solution. This doc describes those functional areas and how they connect to each other 💜
1.1. Scope 🌈
This architecture is all about securing large multicast groups. It can also work for smaller groups, but it's not necessarily the most efficient way to do it 🙈 For small ad-hoc group communication, other architectures (for example, the Cliques architecture [STW]) can be more efficient.
This architecture is "end to end" 🦋 It doesn't require multicast routing protocols (for example, PIM [RFC2362]) to take part. Bad routing can cause denial of service to application layer groups that follow this architecture 😭 But the routing can't touch the authenticity or secrecy of group data or management packets, so that part stays safe ✨ The multicast routing protocols could also use this architecture to protect their own multicast and group packets. That would be separate from any secure application layer group though.
This architecture also doesn't require IP multicast admission control protocols (for example, IGMP [RFC3376] and MLD [RFC3019]) to be part of secure multicast groups 💅 So a "join" or "leave" for a secure group is independent of a "join" or "leave" of an IP multicast group. Like, joining a secure group means getting authenticated and authorized by a security device, while joining an IP multicast group means contacting a multicast-aware router. Admission control protocols could also use this architecture to protect their own multicast packets, but again, that's separate from any secure application layer group.
This architecture doesn't explicitly describe how secure multicast groups deal with Network Address Translation (NAT) [RFC2663] 🙈 Multicast routing protocols usually need the source and destination addresses and ports of an IP multicast packet to stay unchanged. That's what lets consistent multicast distribution trees get built across the network. If NAT is used in a network, the connectivity of senders and receivers can get messed up. This situation isn't improved or made worse by deploying this architecture, so it's not this architecture's fault 💀
Finally, this architecture doesn't require reliable mechanisms for either data or management protocols 🫶 Reliable multicast routing techniques (for example, FEC [RFC3453]) boost the availability of secure multicast groups. However, leaving that capability out of a deployment doesn't affect the authenticity or secrecy of group data or management packets 🌸
1.2. Summary of Contents of Document 🎀
This document gives an architectural overview of the security services needed to secure large multicast groups. It provides a Reference Framework for organizing the different elements of the architecture, and it explains those elements too 🧚
The Reference Framework sorts the elements of the architecture into three Functional Areas related to security. These cover how data is treated when it's being sent to a group, how the keying material used to protect that data is managed, and the policies that govern a group 👑
Another big item in this document is the definition and explanation of Group Security Associations (GSA). A GSA is the multicast version of the unicast Security Association (SA) 💖 It's specific to multicast security and is the foundation for the work on group key management, so it's a main character here ✨
1.3. Audience 🦋
This document is for the technical community, implementers of IP multicast security technology, and anyone who wants a general background in multicast security 🫶 It assumes you already know the Internet Protocol, the IPsec suite of protocols (for example, [RFC2401]), related networking technology, and general security terms and concepts. So if you've got that down, you're the target reader 🔥
1.4. Terminology 💜
The following key terms are used throughout this document 📖
- 1-to-N: a group with one sender and many receivers.
- Group Security Association (GSA): a bundling of Security Associations (SAs) that together define how a group communicates securely. The GSA may include a registration protocol SA, a rekey protocol SA, and one or more data security protocol SAs.
- M-to-N: a group with many senders and many receivers, where M and N aren't necessarily the same value 🌈
- Security Association (SA): a set of policy and cryptographic keys that provide security services to network traffic that matches that policy 🔐
2. Architectural Design: The Multicast Security Reference Framework 🌸
This section gets into the complex issues of multicast security using a Reference Framework 💅 The Reference Framework is used to classify functional areas, functional elements, and interfaces. Two designs of the Reference Framework are shown: a centralized design, and a distributed design that extends the centralized design for very large groups 👑
2.1. The Reference Framework 🦋
The Reference Framework is built on three broad functional areas (as shown in Figure 1). It pulls in the main entities and functions related to multicast security and shows how they relate to each other ✨ It also looks at multicast security from the perspective of multicast group types (1-to-N and M-to-N), and the classes of protocols (the exchanged messages) needed to secure multicast packets 🧚
The goal of the Reference Framework is to give some general context around the functional areas and the relationships between them. Some issues span more than one functional area, and the framework encourages precisely identifying and describing those issues, especially ones that are hard to express in terms of a single functional area 💖 For example, expressing policies about group keys involves both the group key management and multicast policies functional areas. Literally a perfect example of why this matters 🙈
When you look at the Reference Framework diagrams, remember that the single "boxes" don't necessarily mean one matching physical entity doing that function 🫶 Instead, a box should be read loosely as covering a given function related to a functional area. Whether that function is really built as one or more physical entities depends on the particular solution. For instance, the box labeled "Key Server" has to be understood in broad terms as referring to the functions of key management 💜
Similarly, the Reference Framework admits that some implementations may merge a number of the "boxes" into a single physical entity 🌈 That can even happen across functional areas. For example, one entity in a group could act as both a Group Controller and a Sender to that group ⭐
The protocols to be standardized are shown in the Reference Framework diagrams by the arrows that connect the various boxes. See more details in Section 4, below 🎀
2.2. Elements of the Centralized Reference Framework ✨
Okay bestie, the Reference Framework diagram in Figure 1 is giving boxes and arrows 📦➡️. The boxes are the functional entities, and the arrows are the interfaces between them. Those interfaces need standard protocols so the multicast services can actually work between the entities 🔌💖.
Also, not every system doing multicast security has to implement a protocol for every interface 🙈. Some interfaces can be covered by manual configuration, or skipped entirely if the application doesn't need them. Lowkey so chill 💅.
There are three sets of functional entities, and we'll go through each one 🧚.
+--------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| |
| +------+ |
| Multicast |Policy| |
| Security |Server| |
| Policies +------+ |
| ^ |
| | |
| | |
| v |
| +------+ |
| Group |Group | |
| Key |Ctrl/ |<---------+ |
| Management |Key | | |
| |Server| V |
| +------+ +--------+ |
| ^ | | |
| | |Receiver| |
| | | | |
| v +--------+ |
| +------+ ^ |
| | | | |
| Multicast |Sender|----------+ |
| Data | | |
| Handling | | |
| +------+ |
| |
+--------------------------------------+Figure 1: Centralized Multicast Security Reference Framework
2.2.1. Group Controller and Key Server 👑
The Group Controller and Key Server (GCKS) is the entity and functions that handle issuing and managing the cryptographic keys a multicast group uses. The GCKS also does user-authentication and authorization checks on the candidate members of the group 🔐.
Okay, the Key Server (KS) and the Group Controller (GC) have kinda different jobs and could technically be seen as separate entities 🤓. For now, the framework treats them as one "box" to keep the design simple, and so it doesn't force standardizing the protocol between the KS and the GC. It is stressed that the KS and GC need not be co-located 📍. Future designs could standardize the GC-KS protocol without changing the other components, which is so iconic 🦋.
2.2.2. Sender and Receiver 📨
The Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group, only a single sender is authorized to transmit data to the group. In an M-to-N multicast group, two or more group members are authorized to be senders. In some groups, every member is authorized as a sender 🌈.
Both the Sender and the Receiver have to interact with the GCKS entity for key management 🗝️. That covers user and/or device authentication, user and/or device authorization, getting keying material under the group's key management policies, grabbing new keys during key-updates, and getting other messages about managing keying material and security parameters.
Senders and Receivers can get a lot of their policy from the GCKS entities 💜. Joining a multicast group is usually bundled with the Sender/Receiver getting keying material from a GCKS entity. None of this stops the Sender/Receiver from talking directly to the Policy Server, though 🫶.
2.2.3. Policy Server 📜
The Policy Server is the entity and functions used to create and manage security policies for a specific multicast group. It works with the GCKS entity to install and manage the security policies for group membership and for the group's keying material 🎀.
How the Policy Server interacts with the other entities in the Reference Framework depends a lot on the security circumstances the given policy is addressing 🌸.
2.3. Elements of the Distributed Reference Framework 🌐
Big groups spread across wide geographic regions of the Internet need to scale, so the framework's elements also have to work as a distributed system 😭. Figure 2 shows how distributed designs that support large group scalability fit into the Reference Framework.
+-----------------------------------------------------------------+
| |
| |
| FUNCTIONAL |
| AREAS |
| +------+ +------+ |
| Multicast |Policy|<-------------------------------->|Policy| |
| Security |Server| |Server| |
| Policies +------+ +------+ |
| ^ ^ |
| | | |
| | | |
| v v |
| +------+ +------+ |
| Group |Group |<-------------------------------> |Group | |
| Key |Ctrl/ |<---------+ |Ctlr/ | |
| Management |Key | | |Key | |
| |Server| V |Server| |
| +------+ +--------+ +------+ |
| ^ | | ^ |
| | |Receiver| | |
| | | | | |
| v +--------+ | |
| +------+ ^ V |
| | | | +--------+ |
| Multicast |Sender|----------+ | | |
| Data | |-------------------------------->|Receiver| |
| Handling | | | | |
| +------+ +--------+ |
+-----------------------------------------------------------------+Figure 2: Distributed Multicast Security Reference Framework
In a distributed design, the GCKS entity talks to other GCKS entities to scale the key management services 🚀. GCKS entities need a way to authenticate their peer GCKS entities, a way to handle authorization, and a way to interact securely to pass keys and policy. That's a lot of trust-building, bestie 🤝.
Policy Servers have to interact with each other securely too, so policies can be communicated and enforced across the Internet 🌍.
Two Receiver boxes are shown. One is for when the Sender and Receiver use the same GCKS entity (centralized architecture), and the other is for when they use different GCKS entities (distributed architecture) ✨. In the distributed design, all Receivers must obtain identical keys and policy. Each member of a multicast group may talk to a primary GCKS entity, like the "nearest" GCKS entity, measured by a well-defined and consistent metric 📏. Similarly, a GCKS entity may interact with one or more Policy Servers, which are also arranged in a distributed architecture 💅.
3. Functional Areas 🎀
The Reference Framework identifies three functional areas. They are:
- Multicast data handling. This area covers the security-related treatments of multicast data by the sender and the receiver. This functional area is further discussed in Section 3.1.
- Group Key Management. This area is concerned with the secure distribution and refreshment of keying material. This functional area is further discussed in Section 3.2.
- Multicast Security Policies. This area covers aspects of policy in the context of multicast security, taking into consideration the fact that policies may be expressed in different ways: that they may exist at different levels in a given multicast security architecture, and that they may be interpreted differently according to the context in which they are specified and implemented. This functional area is further discussed in Section 3.3.
3.1. Multicast Data Handling 🔥
In a secure multicast group, the data typically needs to be:
- Encrypted using the group key, mainly for access control and possibly also for confidentiality.
- Authenticated, for verifying the source and integrity of the data. Authentication takes two flavors: a. Source authentication and data integrity. This functionality guarantees that the data originated with the claimed source and was not modified en route (either by a group member or an external attacker). b. Group authentication. This type of authentication only guarantees that the data was generated (or last modified) by some group member. It does not guarantee data integrity unless all group members are trusted.
While multicast encryption and group authentication are fairly standard and similar to encrypting and authenticating a point-to-point communication, source authentication for multicast is considerably more involved 🧠. Consequently, off-the-shelf solutions (e.g., taken from IPsec [RFC2406]) may be sufficient for encryption and group authentication. For source authentication, however, special-purpose transformations are necessary. See [CCPRRS] for further elaboration on the concerns regarding the data transforms 📚.
Multicast data encrypted and/or authenticated by a sender should be handled the same way by both centralized and distributed receivers (as shown in Figure 2) 💖.
The "Multicast Encapsulating Security Payload" [BCCR] provides the definition for Multicast ESP for data traffic. The "Multicast Source Authentication Transform Specification" [PCW] defines the use of the TESLA algorithm for source authentication in multicast 🦋.
3.2. Group Key Management ✨
okay so "keying material" is the umbrella term 💅 It covers the cryptographic keys that belong to a group, the state tied to those keys, and the other security parameters related to them. So managing a group's keys automatically means managing their state and parameters too. 🔑 There are a bunch of specific issues that have to be sorted out, and these may include the following:
- Methods for member identification and authentication.
- Methods to verify the membership to groups.
- Methods to establish a secure channel between a GCKS entity and the member, for the purpose of delivery of shorter-term keying material pertaining to a group.
- Methods to establish a long-term secure channel between one GCKS entity and another, for the purpose of distributing shorter-term keying material pertaining to a group.
- Methods to effect the changing of keys and keying material.
- Methods to detect and signal failures and perceived compromises to keys and keying material.
The requirements for managing keying material have to be looked at alongside whatever policies apply in the situation at hand. 🧚 Context is everything, bestie.
Core to key management is Security Association (SA) Management, which we'll get into more below. 🦋
A "Group Key Management Architecture" document [BCDL] goes deeper on the key management architecture for multicast security. It's built on the Group Security Association (GSA) concept, and it defines the roles of the Key Server and Group Controller in more detail. 👑
"The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP], and "MIKEY" [ACLNM] are three real protocols that implement the group key management function. Three instances, all iconic 🌈
3.3. Multicast Security Policies 🎀
Multicast Security Policies are the rulebook, so they must provide the rules of operation for the other elements of the Reference Framework. 📖 Policies can sometimes get distributed in an ad-hoc way, but ngl, things are way more coordinated and way more trustworthy when a Policy Controller distributes the Security Policies to the group. 💜
Multicast security policies have to hold more info than a regular peer-to-peer policy. 🙈 Not only do they describe the security mechanisms for the group communication, they also have to describe the rules for governing the secure group. For example, the policy would spell out the authorization level an entity needs before it can join a group. It gets even more intense with advanced operations, like when a group member must be forcibly removed from the group, and what to do if group members need to resynchronize because some key management messages got lost. 😭
The policy has to be applied at the Group Controller element and at the member (sender and receiver) elements, and that application needs to be described. IETF already has a basis for security policy management, but multicast security policy management stretches the unicast concepts in three areas:
- Policy creation,
- High-level policy translation, and
- Policy representation.
Some examples of work on multicast security policies include the Dynamic Cryptographic Context Management project [Din], Group Key Management Protocol [Har1, Har2], and Antigone [McD]. 🌸
Policy creation for secure multicast has way more dimensions than the single-administrator policy that the existing unicast policy frameworks assume. 💀 Secure multicast groups are usually large, and by their very nature they stretch across several administrative domains, if not a different domain for each user. There are several methods to consider when creating a single, coherent group security policy. They include a top-down specification of the group policy from the group initiator, and negotiation of the policy between the group members (or prospective members). Negotiation can be as simple as a strict intersection of the members' policies, or extremely complicated using weighted voting systems. 🍓
Translating policy rules from one data model to another is way harder in a multicast group. 😩 It's especially true when group membership spans multiple administrative domains. Policies written at a high level with a Policy Management tool have to be translated into more precise rules that the available security policy mechanisms can both understand and implement. With multicast and all its participants, it's essential that the individual translation done for each participant ends up using a mechanism that works with the results of every other translation. Usually, translating high-level policy into specific policy objects has to produce the same objects so that all of the group members can communicate. That requirement puts constraints on how the high-level policies get used and represented. 🫶
It's also important that policy negotiation and translation happen as an integral part of joining a group. Adding a member to a group is meaningless if they can't actually participate in the group communications. 🙅♀️
4. Group Security Associations (GSA) ✨
4.1. The Security Association 🔐
A security association is a commonly used term in cryptographic systems (e.g., [RFC2401, RFC2406bis, RFC2409]). In this document, it means any set of policy and cryptographic keys that provide security services for the network traffic matching that policy. 💖 A Security Association usually contains the following attributes:
- selectors, such as source and destination transport addresses.
- properties, such as an security parameter index (SPI) or cookie pair, and identities.
- cryptographic policy, such as the algorithms, modes, key lifetimes, and key lengths used for authentication or confidentiality.
- keys, such as authentication, encryption and signing keys.
Group key management uses a different set of abstractions than point-to-point key management systems (such as IKE [RFC2409]). Still, the abstractions used in the Group Key Management functional area may be built from the point-to-point key management abstractions. 🧩
4.2. Structure of a GSA: Introduction 🌈
Security associations (SAs) for group key management are more complex, and usually more numerous, than for point-to-point key management algorithms. The point-to-point version sets up a key management SA to protect application SAs (usually one or two, depending on the protocol). Group key management, though, may need up to three or more SAs. 😳 We'll describe these SAs in later sections.
A GSA holds all of the SA attributes from the previous section, plus some extra attributes that are about the group. As shown in Figure 3, the GSA builds on the SA in two distinct ways. ✨
- First, the GSA is a superset of an SA (Figure 3(a)). A GSA has group policy attributes. For example, the kind of signed credentials needed for group membership, whether group members will be given new keys when a member is added (called "backward re-key" below), or whether group members will be given new keys when a member is removed from the group ("forward re-key"). A GSA also includes an SA as an attribute of itself. 👑
- Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is made up of multiple SAs, and these SAs may be used for several independent purposes. 🍓
+---------------+ +-------------------+
| GSA | | GSA |
| | | +-----+ +-----+ |
| | | | SA1 | | SA2 | |
| +----+ | | +-----+ +-----+ |
| | SA | | | +-----+ |
| +----+ | | | SA3 | |
| | | +-----+ |
+---------------+ +-------------------+
(a) superset (b) aggregation
Figure 3: Relationship of GSA to SA4.3. Structure of a GSA: Reasoning 🧠
Figure 4 shows the three categories of SAs that can be aggregated into a GSA. 💅
+------------------------------------------------------------+
| |
| +------------------+ |
| | GCKS | |
| | | |
| | REG REG | |
| | / REKEY \ | |
| +---/-----|----\---+ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| +----------/------+ | +------\----------+ |
| | REG | | | REG | |
| | REKEY-----+----REKEY | |
| | Sender | | Receiver | |
| | DATA----------DATA | |
| +-----------------+ +-----------------+ |
| |
| |
+------------------------------------------------------------+
Figure 4: GSA Structure and 3 categories of SAsThe three categories of SAs are:
- Registration SA (REG): A separate unicast SA between the GCKS and each group member, regardless of whether the group member is a sender or a receiver or acting in both roles. 📬
- Re-key SA (REKEY): A single multicast SA between the GCKS and all of the group members. 🔄
- Data Security SA (DATA): A multicast SA between each multicast source speaker and the group's receivers. There may be as many data SAs as there are multicast sources allowed by the group's policy. 🎶
Each of these SAs gets defined in more detail in the next section. 🦋
4.4. Definition of GSA ✨
okay so the three categories of SAs line up with three different kinds of communication that group stuff usually needs 💖 this bit breaks down the SAs from Figure 4, one by one, bestie 🦋
- Registration SA (REG): 🎀
okay this one is for bi-directional unicast chats between the GCKS and a group member (a Sender or a Receiver, either way). It only exists between the GCKS and a Member 💅 The GCKS is the one in charge of access control to the group keys, handing out policy to members (or people who want to become members), and dishing out group keys to the Sender and Receiver members 🔥 Using a unicast SA as the starting point for key management is honestly super common across a bunch of group key management environments [RFC3547, GSAKMP, CCPRRS, RFC2627, BMS] ✨
The member starts the REG SA to pull GSA info from the GCKS 🧚 This is how a member asks to join the secure group, or how it gets its GSA keys re-initialized after dropping out (like when its computer got switched off during re-key operations 💀). The GSA info it pulls down is connected to the other two SAs that make up the GSA 💜
Note that this unicast SA is what protects the other elements of the GSA 🫶 So the REG SA is crucial and totally inseparable from the other two SAs in the definition of a GSA, no cap.
BUT (and this is important 🙈) needing a REG SA doesn't mean you need a registration protocol to create it. The REG SA could be set up through manual means instead, like being handed over on a smart card 🌸 So what really matters is that a REG SA exists and is used to protect the other SAs, periodt.
From the view of one GCKS, there are as many unique REG SAs as there are members (Senders and/or Receivers) in the group. That can be a scalability concern for some apps 😭 A REG SA can be set up on-demand with a short lifetime, whereas the re-key and data security SAs get set up for at least the life of the sessions they support 🌈
Conversely, the REG SA could stick around for the whole group lifetime if scalability isn't an issue ⭐ A long-term REG SA like that would be handy for re-synchronization or deregistration purposes 🍓
- Re-key SA (REKEY): 💜
sometimes a GCKS needs to be able to "push" new SAs as part of the GSA 🚀 Those new SAs have to go out to all group members. Other times the GCKS needs to quickly revoke access for one or more group members 🙅♀️ The Re-key SA handles both of those needs, iconic 👑
This Re-key SA is a unidirectional multicast of key management messages from the GCKS to all group members 💖 So the GCKS and every member of the group all know about this SA.
This SA isn't negotiated, because all the group members have to share it 🫶 That means the GCKS must be the authentic source, and it acts as the sole point of contact for group members who want to get this SA 🔐
A rekey SA isn't absolutely required to be part of a GSA 🦋 For example, some groups might have a lifetime that's short enough that a rekey just isn't needed ⏳ On the flip side, the policy for the group could specify multiple rekey SAs of different types 💅 For instance, if the GC and KS are separate entities, the GC might deliver rekey messages that adjust the group membership, while the KS delivers rekey messages with new DATA SAs ✨
- Data Security SA (DATA): 🌸
this one protects data between member senders and member receivers 💖
One or more SAs are needed for multicast transmission of data messages from the Sender to the other group members 🧚 This SA is known by the GCKS and by all members of the group.
No matter how many instances of this third category of SA there are, it isn't negotiated. Instead, all group members get it from the GCKS 🎀 The GCKS itself doesn't use this category of SA at all.
From the Receivers' point of view, there's at least one data security SA for the member sender (or more than one) in the group 👑 If the group has more than one data security SA, the data security protocol must have a way of telling them apart (for example, with an SPI) 🔥
There are a few possibilities for how many data security SAs a group can have 🌈
- Each sender in the group could get its own unique data security SA. That means each receiver has to keep track of as many data security SAs as there are senders in the group 😭 In this setup, each sender can be verified using source origin authentication techniques ✨
- The entire group deploys a single data security SA for all senders. Receivers then only have to maintain one data security SA 💅
- A combination of 1. and 2. 🫶
4.5. Typical Compositions of a GSA 🍓
depending on the multicast group policy, there are lots of ways a GSA can be put together 🦋 To give you some examples, here are a few possible compositions:
- a group of memory-constrained members may only need a REG SA and a single DATA SA 🧚
- a "pay-per-session" app, where all of the SA info needed for the session can be handed out over a REG SA 💖 Re-key and re-initialization of DATA SAs might not be necessary, so there's no REKEY SA in this one 🌸
- a subscription group, where the keying material changes as membership changes 🔥 A REG SA is needed to distribute the other SAs, and a REKEY SA is needed to re-initialize a DATA SA whenever membership changes 🎀
5. Security Services 🛡️
this section figures out which security services belong on the designated interfaces of Figure 2 🦋 Each distinct security service gets assigned to specific interfaces. For example, multicast source authentication, data authentication, and confidentiality all happen on the multicast data interface between Senders and Receivers in Figure 2 💜 Authentication and confidentiality might also be needed between the Key Server and group members (the Senders and Receivers of Figure 2), but the services needed for multicast key management can be unicast as well as multicast 🫶 So a security service in the Multicast Security Reference Framework basically names a specific function along one or more Figure 2 interfaces ✨
This document doesn't try to analyze trust relationships, detailed functional requirements, performance requirements, suitable algorithms, or protocol specifications for IP multicast and application-layer multicast security 🙈 Instead, that work will happen as the security services get further defined and realized in algorithms and protocols 🌈
5.1. Multicast Data Confidentiality 🔐
this security service handles encrypting multicast data on the Sender's end and decrypting it on the Receiver's end 💖 It can also apply the keying material that Multicast Key Management provides under Multicast Policy Management, but it's independent of both of them 🧚
A big part of Multicast Data Confidentiality is figuring out and explaining which specific ciphers should be used for multicast data 💅 Obviously, not every cipher is going to be suitable for IP multicast and application-layer multicast traffic 😭 Since this traffic is usually connectionless UDP flows, stream ciphers may be unsuitable, though hybrid stream/block ciphers might have advantages over some block ciphers 🌸
When it comes to application-layer multicast, you have to think about what happens when encrypted data gets sent in a multicast environment with no admission control 💀 Basically, practically any application program can join a multicast event without taking part in any multicast security protocol, so this security service also cares about how multicast confidentiality services (intended or not) affect application programs 🙈 The effects on both Senders and Receivers get considered 🫶
In Figure 2, Multicast Data Confidentiality sits in the Multicast Data Handling Area, along the interface between Senders and Receivers 🦋 The algorithms and protocols that come out of work on this security service may be applied to other interfaces and areas of Figure 2 whenever multicast data confidentiality is needed ✨
5.2. Multicast Source Authentication and Data Integrity 🛡️
this security service handles source authentication and integrity verification of multicast data 💜 It covers the transforms done at both the Sender's end and the Receiver's end 🔥 It assumes the appropriate signature and verification keys get provided through Multicast Key Management, under Multicast Policy Management as described below 🌈
This is one of the harder areas of multicast security, thanks to the connectionless and real-time requirements of lots of IP multicast apps 😭 There are some classes of application-layer multicast security where offline source and data authentication is good enough though 🌸 As discussed earlier, not every multicast app needs real-time authentication and data-packet integrity 💅 Still, a robust solution to multicast source and data authentication is necessary for a complete multicast security solution 👑
In Figure 2, Multicast Source and Data Authentication sits in the Multicast Data Handling Area, along the interface between Senders and Receivers ✨ The algorithms and protocols produced for this functional area might be applicable to security services in other functional areas that use multicast services, like Group Key Management 🧚
5.3. Multicast Group Authentication 💖
this security service gives a limited amount of authenticity for the transmitted data 🎀 It only guarantees that the data originated with (or was last modified by) one of the group members 🫶 It does not guarantee the data's authenticity if other group members aren't trusted 🙈
The big perk of group authentication is that it's guaranteed through relatively simple and efficient cryptographic transforms 🦋 So when source authentication isn't the top priority, group authentication becomes useful 💜 It's also useful even when source authentication happens later on, because it provides a simple-to-verify weak integrity check, which is a good measure against denial-of-service attacks 🛡️
The Multicast Group Authentication security service is placed in the Multicast Data Handling Area, along the interface between Senders and Receivers 🌈
5.4. Multicast Group Membership Management ✨
Okay bestie, this security service is all about registering members with the Group Controller 🎀 and de-registering them later. These are security functions, totally separate from the IP multicast "join" and "leave" stuff members do for group admission control (think IGMP [RFC3376] and MLD [RFC3019]). Don't mix them up 🙈
Registration covers member authentication, notification and negotiation of security parameters, and logging of information, all according to the policies of the group controller and the would-be member. 💅 Usually there's an out-of-band advertisement of group info before registration happens, and the would-be member is typically the one who kicks off the registration process.
De-registration can start from either side: the member or the group controller. Either way, the group controller logs the de-registration event, then invokes the right mechanism for terminating that member's membership (see Section 5.5). Clean exit, no drama 👋
This service also covers the membership communication between different GCKS servers in a distributed group design 🌐
In Figure 2, Multicast Group Membership lives in the Group Key Management Area and has interfaces to Senders and Receivers 🧚
5.5. Multicast Key Management 🔑
This security service is the keying material queen 👑. It handles distributing and updating the cryptographic keying material for the whole life of the group. The components include:
- GCKS-to-member notification (to a Sender or Receiver) about the current keying material, like group encryption and authentication keys, auxiliary keys for group management, keys for source authentication, etc. 🔐
- Updating the current keying material, depending on circumstances and policies. 🔄
- Terminating groups securely, including the secure group itself and its associated keying material. 🧹
Among its responsibilities: managing keys securely between Key Servers and group members, handling how keying material gets distributed over multicast, and meeting the scalability or other performance requirements for multicast key management [RFC2627, BMS]. Key Servers and group members can also team up with a common Public Key Infrastructure (PKI) for better scalability of authentication and authorization 🤝
For an interoperable and secure IP multicast security protocol, this service may need to specify host abstractions such as a group security association database (GSAD) and a group security policy database (GSPD) for IP multicast security 📚. Since IP multicast and application-layer multicast overlap to some degree, that overlap needs to be considered. So this service looks at the key management requirements for IP multicast, the key management requirements for application-layer multicast, and how well any specific realization of Multicast Key Management can satisfy both 🧩. ISAKMP was also designed to be extensible to multicast key management for both IP multicast and application-layer multicast security [RFC2408]. That means multicast key management protocols may use the existing ISAKMP standard's Phase 1 and Phase 2 protocols, possibly with needed extensions (such as GDOI [RFC3547] or application-layer multicast security) ✨
This service also covers the key management communication among different GCKS servers in a distributed group design 🌸
Multicast Key Management shows up in both the centralized and distributed designs, as shown in Figure 2, and it's placed in the Group Key Management Area 🎯
5.6. Multicast Policy Management 📜
This security service handles everything related to multicast group policy, including membership policy and multicast key management policy. 💖 One of the first jobs in further defining it is figuring out the different areas of multicast policy. Multicast Policy Management includes designing the policy server for multicast security, defining the particular policies used for IP multicast and application-layer multicast security, and setting up the communication protocols between the Policy Server and the Key Server.
It may be realized using a standard policy infrastructure, like a Policy Decision Point (PDP) and Policy Enforcement Point (PEP) architecture [RFC2748]. So it may not be necessary to reinvent a separate architecture for multicast security policy, which is very efficient of us 🙌 At minimum, though, this service gets realized as a set of policy definitions, such as multicast security conditions and actions.
The Multicast Policy Management security service describes the communication between an instance of a GCKS and an instance of the Policy Server. The information sent may include policies about groups, memberships, keying material definitions and their permissible uses, and other stuff. It also describes communication between and among Policy Servers. Group members aren't expected to directly participate in this service, but that option isn't ruled out 🤷♀️
6. Security Considerations 🛡️
Serious moment incoming 😤 This document describes an architectural framework for protecting multicast and group traffic with cryptographic protocols. Three functional areas are identified within the framework, and each one has its own unique security considerations, which we'll go through below.
This architectural framework is end-to-end, and it does not rely on the network that connects group controllers and group members. It also does not try to resolve security issues in the unicast or multicast routing infrastructures, or in multicast admission control protocols. So denial of service, message deletion, and other active attacks against the unicast or multicast routing infrastructures are not addressed by this framework 🚨 Section 1.1 explains how the network infrastructure relates to the multicast group security architecture.
6.1. Multicast Data Handling 🎀
Cryptographic protocols that protect multicast data are responsible for providing confidentiality and group authentication. They should also be able to provide source authentication, so they can uniquely identify senders to the group. Replay protection of multicast data is also desirable, but it may not always be possible, because maintaining replay protection state for multiple senders is complex 😵💫 Section 3.1 goes deeper into the security requirements for this area.
6.2. Group Key Management 🗝️
Group key management protocols provide cryptographic keys and policy to group members. They're responsible for authenticating and authorizing group members before revealing those keys, and for providing confidentiality and authentication of those keys during transit. They also provide a means for rekeying the group if the policy specifies a lifetime for the keys ⏳ And they're responsible for revocation of group membership once one or more group members have had their authorization revoked 🚫 Section 3.2 describes the security requirements of this area in more detail.
6.3. Multicast Security Policies 📋
Cryptographic protocols that provide multicast security policies are responsible for distributing that policy in a way that keeps the policy's integrity intact. If the policy itself is confidential, they're also responsible for authenticating group controllers and group members, and for providing confidentiality of the policy during transit 🔒
7. Acknowledgements 💜
Much of the text in this document was derived from two research papers 📄 The framework for this document came from a paper co-authored by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore. The description of the GSA came from a document co-authored by Hugh Harney, Mark Baugher, and Thomas Hardjono. George Gross suggested a number of improvements that were included in later versions of this document 🫶
8. References 📚
8.1. Normative References
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 🦋
- [RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. 🌈
8.2. Informative References ✨
Okay bestie, now we're in the reading list, the big stack of "go look this up" 📚 Everything here is a reference the spec points to, and I'm keeping every title, author, date, and link exactly as the original has them, typos included. 🫶
[ACLNM] J. Arkko, et. al., "MIKEY: Multimedia Internet KEYing", Work in Progress, December 2003.
[BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, "MESP: A Multicast Framework for the IPsec ESP", Work in Progress, October 2002.
[BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group Key Management Architecture", Work in Progress, September 2003.
[BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization, http://www.securemulticast.org/draft-balenson-groupkeymgmt-oft-00.txt, Work in Progress, February 1999. 🌸
[CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., Saha D., "An IPSec-based Host Architecture for Secure Internet Multicast", http://www.isoc.org/isoc/conferences/ndss/2000/proceedings/028.pdf, NDSS 2000.
[Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C., and Sherman, A., "Policy-Based Security Management for Large Dynamic Groups: An Overview of the DCCM Project," DARPA Information Survivability Conference and Exposition, http://download.nai.com/products/media/nai/doc/discex-110199.doc.
[GSAKMP] H. Harney, et. al., "GSAKMP", Work in Progress, October 2003.
[Har1] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[Har2] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone: A Flexible Framework for Secure Group Communication," Proceedings of the Eight USENIX Security Symposium, pp 99-113, August, 1999. 💅
[PCW] Perrig, A., Canetti, R. and B. Whillock, TESLA: Multicast Source Authentication Transform Specification", Work in Progress, October 2002.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406bis] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, March 2003.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, September 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzong, S., Rajan, R. and A. Sastry, "COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC3019] Haberman, B. and R. Worzella, "IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol", RFC 3019, January 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 🦋
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, M., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The Group Domain of Interpretation", RFC 3547, December 2002.
[STW] M., Steiner, Tsudik, G., Waidner, M., CLIQUES: A New Approach to Group key Agreement, IEEE ICDCS'98 , May 1998.
9. Authors' Addresses 🧚
Here's who wrote it, with their contact details, so you know exactly who to blame (or thank) 💜
Thomas Hardjono
VeriSign
487 E. Middlefield Rd.
Mountain View, CA 94043, USA
Phone:(650) 426-3204
EMail: thardjono@verisign.com
Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
Phone: (408) 526-4796
EMail: bew@cisco.com10. Full Copyright Statement 🎀
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions in BCP 78, and apart from what BCP 78 sets out, the authors keep all of their rights.
This document and everything in it are handed over "AS IS", no strings. The contributor, whatever organization they represent or sponsor them (if any), the Internet Society, and the Internet Engineering Task Force all say no to every warranty, whether stated or implied. That includes no promise that using the information won't infringe anyone's rights, and no implied promise of merchantability or fitness for a particular purpose. 🙈
Intellectual Property 🌈
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid, or how far they reach. It also doesn't say whether licenses for those rights are actually out there. And no, it hasn't gone hunting for those rights on its own either. 🔍 For how rights work across RFC documents, check BCP 78 and BCP 79.
Any IPR disclosures sent to the IETF Secretariat are available, along with any licensing assurances, or the outcome of an attempt to get a general license or permission for implementers or users to use the proprietary rights. You can find all of that in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that to ietf-ipr@ietf.org. 💖
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3740 2004-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms