RFC 4046
Multicast Security (MSEC) Group Key Management Architecture
Part 1 of 9 🎀
Multicast Security (MSEC) Group Key Management Architecture 🎀
okay bestie, this is RFC 4046 📜✨ It's an Informational doc from April 2005, published in the Network Working Group. The authors are M. Baugher (Cisco), R. Canetti (IBM), L. Dondeti (Qualcomm), and F. Lindholm (Ericsson). The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Status of This Memo 💅
this one is just sharing info with the internet community, it's not a standard of any kind 🫶 and distribution is totally unlimited, so share away.
Copyright Notice 🌈
Copyright (C) The Internet Society (2005).
Abstract 🌸
okay so this doc lays out the shared blueprint for MSEC key management protocols 🔑 they're designed to work with all kinds of security protocols, whether that's at the application, transport, or network layer. it also defines the group security association (GSA) and walks through the key management protocols that help set one up. the framework is modular and flexible, so you can build group key management for lots of different settings and tailor it to what an app actually needs ✨ and these MSEC protocols can handle one-to-many, many-to-many, or one-to-one communication. literally so versatile 😭
Table of Contents 📑
1. Introduction: Purpose of this Document ..........................2
2. Requirements of a Group Key Management Protocol .................4
3. Overall Design of Group Key Management Architecture .............6
3.1. Overview ...................................................6
3.2. Detailed Description of the GKM Architecture ...............8
3.3. Properties of the Design ..................................11
3.4. Group Key Management Block Diagram ........................11
4. Registration Protocol ..........................................13
4.1. Registration Protocol via Piggybacking or Protocol Reuse ..13
4.2. Properties of Alternative Registration Exchange Types .....14
4.3. Infrastructure for Alternative Registration
Exchange Types ............................................15
4.4. De-registration Exchange ..................................16
5. Rekey Protocol .................................................16
5.1. Goals of the Rekey Protocol ...............................17
5.2. Rekey Message Transport and Protection ....................17
5.3. Reliable Transport of Rekey Messages ......................18
5.4. State-of-the-art on Reliable Multicast Infrastructure .....20
5.5. Implosion .................................................21
5.6. Incorporating Group Key Management Algorithms .............22
5.7. Stateless, Stateful, and Self-healing Rekeying
Algorithms ................................................22
5.8. Interoperability of a GKMA ................................23
6. Group Security Association .....................................24
6.1. Group Policy ..............................................24
6.2. Contents of the Rekey SA ..................................25
6.2.1. Rekey SA Policy ....................................26
6.2.2. Group Identity .....................................27
6.2.3. KEKs ...............................................27
6.2.4. Authentication Key .................................27
6.2.5. Replay Protection ..................................27
6.2.6. Security Parameter Index (SPI) .....................27
6.3. Contents of the Data SA ...................................27
6.3.1. Group Identity .....................................28
6.3.2. Source Identity ....................................28
6.3.3. Traffic Protection Keys ............................28
6.3.4. Data Authentication Keys ...........................28
6.3.5. Sequence Numbers ...................................28
6.3.6. Security Parameter Index (SPI) .....................28
6.3.7. Data SA Policy .....................................28
7. Scalability Considerations .....................................29
8. Security Considerations ........................................31
9. Acknowledgments ................................................32
10. Informative References ........................................331. Introduction: Purpose of this Document ✨
so this doc basically sets up a common architecture for MSEC key management protocols 🧚 they're meant to back up application-, transport-, and network-layer security protocols. it also defines the group security association (GSA) and describes the key management protocols that help establish one. the framework and guidelines are modular and flexible, so group key management can be designed for all sorts of settings, specialized to what applications need 💖 and yep, MSEC key management can facilitate secure one-to-many, many-to-many, or one-to-one communication. iykyk 🫶
group and multicast apps running over IP networks have super diverse security needs [TAXONOMY] 🌸 their key management requirements (we briefly go over them in Section 2.0) include support for internetwork-, transport-, and application-layer security protocols. some apps keep things simpler by running key management messaging over a channel that's already secure, like TLS or IPsec 🔐 other security protocols work best with a key management protocol that can run over a session initiation or management protocol that's already deployed, like SIP or RTSP 📞 and some want a lightweight key management protocol that doesn't need a bunch of round trips ⚡ so, application-, transport-, and IP-layer data security protocols (for example, SRTP [RFC3711] and IPsec [RFC2401]) each benefit from different group key management systems. this doc defines one common architecture and design for all group key management (GKM) protocols 👑
this common architecture is called the MSEC group key management architecture 💅 it's based on the group control or key server model from GKMP [RFC2094], which group key management algorithms like LKH [RFC2627], OFT [OFT], and MARKS [MARKS] also assume. there are other approaches that this architecture doesn't cover, like the highly distributed Cliques group key management protocol [CLIQUES] or broadcast key management schemes [FN93,Wool] 🦋 MSEC key management might actually be complementary to those other designs, but integrating MSEC group key management with Cliques, broadcast key management, or other group key systems isn't considered in this document. not me being picky, just scoping 🙈
key management protocols are genuinely hard to design and validate 😭 the common architecture here makes that easier by defining shared abstractions and an overall design that can be specialized for different uses. main character energy for the architecture 🎀
this document builds on and extends the Group Key Management Building Block document from the IRTF SMuG research group [GKMBB], and it's part of the MSEC document roadmap 🗺️ the MSEC architecture [MSEC-Arch] defines a complete multicast or group security architecture, and key management is one component of it 🌈
the rest of this doc is organized like this: Section 2 covers the security, performance, and architectural requirements for a group key management protocol. Section 3 presents the overall architectural design principles. Section 4 describes the registration protocol in detail, and Section 5 does the same for the rekey protocol. Section 6 looks at the interface to the Group Security Association (GSA). Section 7 reviews scalability issues for group key management protocols, and Section 8 discusses security considerations 💖
2. Requirements of a Group Key Management Protocol 🔐✨
okay so, a group key management (GKM) protocol is basically the thing that keeps protected communication working between members of a secure group 💖 A secure group is a bunch of principals (members) who can be senders, receivers, or both to each other. And membership can change over time, which is the chaotic part 😭 The GKM protocol helps make sure only actual members can get into the group data (by getting the group keys), and can authenticate that data too. Its whole job is giving legit members the up-to-date cryptographic state they need for secrecy and authentication 🫶
Multicast apps like video broadcast and multicast file transfer usually have these key management requirements (see also [TAXONOMY]). Heads up: this list is neither applicable to every app nor exhaustive, so don't treat it as the Bible 🙈
- Group members receive security associations that include encryption keys, authentication/integrity keys, cryptographic policy that describes the keys, and attributes such as an index for referencing the security association (SA) or particular objects contained in the SA.
- In addition to the policy tied to group keys, the group owner or the Group Controller and Key Server (GCKS) may define and enforce group membership, key management, data security, and other policies. These may or may not be communicated to the entire membership 👑
- Keys will have a pre-determined lifetime and may be periodically refreshed 🔄
- Key material should be delivered securely to members of the group, so that it is secret, integrity-protected, and verifiably obtained from an authorized source 🔒
- The key management protocol should be secure against replay attacks and Denial of Service(DoS) attacks (see the Security Considerations section of this memo). This one is serious, bestie 😤
- The protocol should facilitate addition and removal of group members. Members who are added may optionally be denied access to the key material used before they joined the group, and removed members should lose access to the key material following their departure 🚪
- The protocol should support a scalable group rekey operation without unicast exchanges between members and a Group Controller and Key Server (GCKS), to avoid overwhelming a GCKS managing a large group 🌸
- The protocol should be compatible with the infrastructure and performance needs of the data security application, such as the IPsec security protocols AH and ESP, and/or application layer security protocols such as SRTP [RFC3711] 🎀
- The key management protocol should offer a framework for replacing or renewing transforms, authorization infrastructure, and authentication systems 🦋
- The key management protocol should be secure against collusion among excluded members and non-members. Specifically, collusion must not result in attackers gaining any additional group secrets than each of them individually are privy to. In other words, combining the knowledge of the colluding entities must not result in revealing additional group secrets. Not gonna lie, this is giving spy movie energy 🕵️♀️💅
- The key management protocol should provide a mechanism to securely recover from a compromise of some or all of the key material 🩹
- The key management protocol may need to address real-world deployment issues such as NAT-traversal and interfacing with legacy authentication mechanisms 🧚
In contrast to typical unicast key and SA negotiation protocols such as TLS and IKE, multicast group key management protocols provide SA and key download capability. This feature may be useful for point-to-point as well as multicast communication, so a group key management protocol may be useful for unicast applications too 💜 Group key management protocols may be used for protecting multicast or unicast communications between members of a secure group. Secure sub-group communication is also plausible using the group SA ✨
There are other requirements for small group operation with many, or all, members as potential senders. In this case, the group setup time may need to be optimized to support a small, highly interactive group environment [RFC2627] 🌈
The current key management architecture covers secure communication in large single-sender groups, such as source-specific multicast groups. Scalable operation across a range of group sizes is also a desirable feature, and a better group key management protocol will support large, single-sender groups as well as groups that have many senders. It may be that no single key management protocol can satisfy the scalability requirements of all group-security applications 🫠
It is useful to emphasize two non-requirements: technical protection measures (TPM) [TPM] and broadcast key management. 🙅♀️
Non-requirement #1 (TPM): TPM are used for things like copy protection, by preventing the device user from getting easy access to the group keys. There is no reason a group key management protocol cannot be used in an environment where the keys are kept in a tamper-resistant store, using various types of hardware or software to implement TPM. For simplicity, however, the MSEC key management architecture described in this document does not consider design for technical protection 🔐
Non-requirement #2 (broadcast): Broadcast key management when there is no back channel [FN93,JKKV94], or for a non-networked device such as a digital videodisc player. We assume IP network operation with two-way communication, however asymmetric, and authenticated key-exchange procedures that can be used for member registration. Broadcast applications may use a one-way Internet group key management protocol message and a one-way rekey message, as described below 📀
3. Overall Design of Group Key Management Architecture 🏗️💕
The overall group key management architecture is based upon a group controller model [RFC2093,RFC2094,RFC2627,OFT,GSAKMP,RFC3547] with a single group owner as the root-of-trust. The group owner designates a group controller for member registration and GSA rekeying 👑
3.1. Overview 🦋
The main goal of a group key management protocol is to securely provide group members with an up-to-date security association (SA), which contains the needed information for securing group communication (i.e., the group data). We call this SA the Data SA. To get this done, the group key management architecture defines the following protocols 🌟
(1) Registration Protocol
This is a unicast protocol between the Group Controller and Key Server (GCKS) and a joining group member. In this protocol, the GCKS and joining member mutually authenticate each other. If the authentication succeeds and the GCKS finds that the joining member is authorized, then the GCKS supplies the joining member with the following information:
- (a) Sufficient information to initialize the Data SA within the joining member. This information is given only if the group security policy calls for initializing the Data SA at registration, instead of, or in addition to, as part of the rekey protocol.
- (b) Sufficient information to initialize a Rekey SA within the joining member (see more details about this SA below). This information is given if the group security policy calls for a rekey protocol.
The registration protocol must ensure that the transfer of information from GCKS to member is done in an authenticated and confidential manner over a security association. We call this SA the Registration SA. A complementary de-registration protocol serves to explicitly remove Registration SA state. Members may choose to delete Registration SA state 🗝️
(2) Rekey Protocol
A GCKS may periodically update or change the Data SA by sending rekey information to the group members. Rekey messages may result from group membership changes, from changes in group security policy, from the creation of new traffic-protection keys (TPKs, see next section) for the particular group, or from key expiration. Rekey messages are protected by the Rekey SA, which is initialized in the registration protocol. They contain information for updating the Rekey SA and/or the Data SA, and can be sent via multicast to group members or via unicast from the GCKS to a particular group member 📨
Note that there are other means for managing (e.g., expiring or refreshing) the Data SA without interaction between the GCKS and the members. For example, in MARKS [MARKS], the GCKS pre-determines TPKs for different periods in the lifetime of the secure group and distributes keys to members based on their membership periods. Alternative schemes, such as the GCKS disbanding the secure group and starting a new group with a new Data SA, are also possible, although this is typically limited to small groups 🍓
Rekey messages are authenticated using one of the two following options:
- (1) Using source authentication [TAXONOMY], that is, enabling each group member to verify that a rekey message originates with the GCKS and none other.
- (2) Using only group-based authentication with a symmetric key. Members can only be assured that the rekey messages originated within the group. Therefore, this is applicable only when all members of the group are trusted not to impersonate the GCKS. Group authentication for rekey messages is typically used when public-key cryptography is not suitable for the particular group 🔑
The rekey protocol ensures that all members receive the rekey information in a timely manner. In addition, the rekey protocol specifies mechanisms for the parties to contact the GCKS and re-synch if their keys expired and an updated key has not been received. The rekey protocol for large-scale groups offers mechanisms to avoid implosion problems and to ensure reliability in its delivery of keying material 💪
Although the Rekey SA is established by the registration protocol, it is updated using a rekey protocol. When a member leaves the group, it destroys its local copy of the GSA. Using a de-registration message may be an efficient way for a member to inform the GCKS that it has destroyed, or is about to destroy, the SAs. Such a message may prompt the GCKS to cryptographically remove the member from the group (i.e., to prevent the member from having access to future group communication). In large-scale multicast applications, however, de-registration can potentially cause implosion at the GCKS 💀
Figure 1 is the big picture, so let's zoom out. Every group member, sender or receiver, uses the registration protocol to get authorized and authenticated access to a particular Group, its policies, and its keys 🔐 There are two main kinds of group keys: key encryption keys (KEKs) and traffic encryption keys (TEKs). For group authentication of rekey messages or data, key integrity or traffic integrity keys may be used too. We call integrity and encryption keys together "protection keys." So a traffic protection key (TPK) is the combo of a TEK and a traffic integrity key, or the key material used to generate them 💖
A KEK can be a single key that protects the rekey message, which typically carries a new Rekey SA (containing a KEK) and/or a Data SA (containing a TPK/TEK) ✨ A Rekey SA may also hold a vector of keys that are part of a group key membership algorithm [RFC2627,OFT,TAXONOMY,SD1,SD2]. The data security protocol uses TPKs to protect streams, files, or other data it sends and receives 🦋 So the registration protocol and/or the rekey protocol set up the KEK(s) and/or the TPKs. It's a whole team effort 🫶
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| GCKS |<------+ | |
| | | +--------------------+ | | |
| | REGISTRATION or | REGISTRATION or | |
| | DE-REGISTRATION | DE-REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v REKEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+Figure 1: Group Security Association Model 🎀
There are a few distinct outcomes from a successful registration protocol exchange 👀
- If the GCKS uses rekey messages, the admitted member gets the Rekey SA. The Rekey SA holds the group's rekey policy (not all of the policy needs to be revealed to members, fr), and at least a group KEK. On top of that, the GCKS sends a group key integrity key for integrity protection of rekey messages. If a group key management algorithm is used for efficient rekeying, the GCKS also sends one or more KEKs, as specified by the key distribution policy of that algorithm 🧁
- If rekey messages aren't used for the Group, the admitted member receives TPKs (as part of the Data Security SAs) that get passed to the member's Data Security Protocol (just like IKE does for IPsec) 🌸
- The GCKS may pass one or more TPKs to the member even when rekey messages are used, for efficiency reasons and according to group policy 💅
The GCKS creates the KEK and TPKs and downloads them to each member, since the KEK and TPKs are shared by the whole group 🌈 The GCKS is a separate logical entity that handles member authentication and authorization according to the group policy set by the group owner. It may present a credential signed by the group owner to the group member, so the member can check the GCKS's authorization 🔍 The GCKS, which may live on the same box as a member or be physically separate, runs the rekey protocol to push rekey messages with refreshed KEKs, new TPKs, and/or refreshed TPKs to members. Some group key management algorithms can refresh any of the KEKs (potentially), while others only refresh the group KEK 🧚
Alternatively, the sender may forward rekey messages on behalf of the GCKS when it uses a credential mechanism that supports delegation. So the sender, or other members, can source keying material (TPKs encrypted in the Group KEK) at the same time they source multicast or unicast data 🙈 As mentioned above, the rekey message can be sent using unicast or multicast delivery. When a member gets a TPK (as part of a Data SA) via a rekey message or a registration protocol exchange, the member's group key management functional block hands the new or updated security association (SA) to the data security protocol. That's what protects the data going from sender to receiver 🔥
The Data SA protects the data sent on the arc labeled DATA SECURITY PROTOCOL in Figure 1. A second SA, the Rekey SA, is optionally set up by the key management protocol for rekey messages, shown by the arc labeled REKEY PROTOCOL 💜 The rekey message is optional because all keys, KEKs and TPKs, can be delivered by the registration protocol exchanges, and those keys may not need updating. The registration protocol is protected by a third, unicast, SA between the GCKS and each member, called the Registration SA. There may be no need for the Registration SA to stick around after the registration protocol exchanges finish. The de-registration protocol may be used when explicit teardown of the SA is desirable (like when a phone call or conference ends) 📞 The three SAs together make up the GSA. The only optional SA is the Rekey SA 🫧
Figure 1 shows two blocks that are external to the group key management protocol: the policy and authorization infrastructures, which are discussed in Section 6.1. The Multicast Security Architecture document goes further into the SAs and how they're used as part of the complete architecture of a multicast security solution [MSEC-Arch] 📚
3.3. Properties of the Design ✨
The design of Section 3.2 gets scalable operation by (1) letting authenticated key exchange in a registration protocol be decoupled from a rekey protocol, (2) letting the rekey protocol use unicast push or multicast distribution of group and data keys as an option, (3) letting all keys be obtained by the unicast registration protocol, and (4) delegating the GCKS's functionality across multiple entities, i.e., permitting distributed operation of the GCKS 🌟
High-capacity operation comes from (1) amortizing computationally-expensive asymmetric cryptography over multiple data keys used by data security protocols, (2) supporting multicast distribution of symmetric group and data keys, and (3) supporting key revocation algorithms such as LKH [RFC2627,OFT,SD1,SD2], which let members be added or removed at logarithmic rather than linear space/time complexity 🚀 The registration protocol may use asymmetric cryptography to authenticate joining members and optionally set up the group KEK. Asymmetric cryptography such as Diffie-Hellman key agreement and/or digital signatures is amortized over the life of the group KEK 💎 A Data SA can be set up without asymmetric cryptography at all: the TPKs are simply encrypted in the symmetric KEK and sent unicast or multicast in the rekey protocol 🍓
The design of the registration and rekey protocols is flexible 🦄 The registration protocol sets up a Rekey SA or one or more Data SAs, or both types of SAs. At least one of the SAs is present (otherwise, there's no purpose to the Registration SA). The Rekey SA may update the Rekey SA, or set up or update one or more Data SAs. Individual protocols or configurations can use this flexibility to get efficient operation 🌷
3.4. Group Key Management Block Diagram
okay so bestie, this section is basically the big picture 🗺️✨ it shows how group key management protocols run between a GCKS and a member principal to set up a Group Security Association (GSA) 🫶. The GSA is made of a Data SA, an optional Rekey SA, and a Registration SA. The GCKS may use a delegated principal, like the sender, and that delegate has a delegation credential signed by the GCKS 🔐. The Member in Figure 2 can be a sender or receiver of multicast or unicast data, no cap 💅. Figure 2 has two functional blocks labeled GKM, with two arcs between them for the group key-management registration (reg) and rekey (rek) protocols 🎀. The actual message exchanges live in the GSA establishment protocols, which are the registration protocol and the rekey protocol we just went over 🦋.
Figure 2 also makes it clear that a full group-key management functional spec is way more than just the message exchange 🙈. Some of those blocks and arcs are specific to an operating system (OS) or vendor product, like vendor specs for products that update the IPsec Security Association Database (SAD) and Security Policy Database (SPD) [RFC2367] 💜. Different vendors also define the functions and interface of credential stores, which is CRED in Figure 2 🧚.
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 2: Group Key Management Block in a HostThe CONTROL function tells the GCKS to set up a group, admit a member, or remove a member, or it tells a member to join or leave a group 🎯. CONTROL includes authorization that's subject to group policy [GSPT], but how it's implemented is specific to the GCKS 🔒. For big multicast sessions, CONTROL could do session announcement functions to let a potential group member know it may join a group or receive group data (like a stream of file transfer protected by a data security protocol) 📢. Announcements tell group members to set up multicast SAs ahead of secure multicast data transmission 🌸. Session Description Protocol (SDP) is one form the announcements might take [RFC2327] 💖. The announcement function can live in a session directory tool, an electronic program guide (EPG), or other means 📺. The Data Security or the announcement function directs group key management using an application programming interface (API), which is specific to the host OS in its details 🛠️. A generic API for group key management is for further study, but this function is needed so Group (KEK) and Data (TPKs) key establishment can scale to the particular application 📈. A GCKS application program uses the API to start the procedures for establishing SAs on behalf of a Security Protocol, where members join secure groups and receive keys for streams, files, or other data 🦋.
The goal of the exchanges is to establish a GSA by updating the SAD of a key management implementation and the particular Security Protocol 🥰. The Data Security Protocol ("SECURITY PROTOCOL") in Figure 2 may span internetwork and application layers, or operate at the internetwork layer, like AH and ESP 🌐✨.
4. Registration Protocol 🎀
The design of the registration protocol is flexible and can support different application scenarios 💅. The chosen registration protocol solution reflects the specific requirements of specific scenarios 🦋. In principle, you can base a registration protocol on any secure-channel protocol, like IPsec and TLS, which is the case in tunneled GSAKMP [tGSAKMP] 🔐. GDOI [RFC3547] reuses IKE Phase 1 as the secure channel to download Rekey and/or Data SAs 💜. Other protocols, like MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges similar to IKE Phase 1, but they're specifically tailored for key download to get efficient operation ⭐. We'll dig into the design of a registration protocol in detail in the rest of this section 🧚.
4.1. Registration Protocol via Piggybacking or Protocol Reuse 🐣
Some registration protocols need to tunnel through a data-signaling protocol to take advantage of security functionality that already exists, and/or to optimize the total session setup time ⏱️. For example, a telephone call has strict delay bounds for setup time 📞. It's not feasible to run security exchanges in parallel with call setup, since the latter often resolves the address 🙅♀️. Call setup must complete before the caller knows the callee's address 💀. So in this case, it may be advantageous to tunnel the key exchange procedures inside call establishment [H.235,MIKEY], so both can complete (or fail, see below) at the same time 👯♀️.
The registration protocol has different requirements depending on the particular integration or tunneling approach 🎀. These requirements aren't necessarily security requirements, but they will have an impact on the chosen security solution 🦋. For example, the security association will certainly fail if the call setup fails in the case of IP telephony 📵.
Conversely, the registration protocol imposes requirements on the protocol that tunnels it 🔄. In the case of IP telephony, the call setup usually will fail when the security association isn't successfully established 😭. In the case of video-on-demand, protocols such as RTSP that convey key management data will fail when a needed security association can't be established 🎬.
Both GDOI and MIKEY use this approach, but in different ways 💖. MIKEY can be tunneled in SIP and RTSP 🌈. It takes advantage of the session information contained in these protocols and the possibility to optimize the setup time for the registration procedure ✨. SIP requires that a tunneled protocol must use at most one roundtrip (i.e., two messages) 🔥. This is also a desirable requirement from RTSP 🍓.
The GDOI approach takes advantage of the already defined ISAKMP phase 1 exchange [RFC2409], and extends the phase 2 exchange for the registration 👑. The advantage here is reusing a successfully deployed protocol and its code base, where the defined phase 2 exchange is protected by the SA created by phase 1 🙌. GDOI also inherits other ISAKMP functionality, so it's readily suitable for running IPsec protocols over IP multicast services 🌸.
4.2. Properties of Alternative Registration Exchange Types 🧁
The required design properties of a registration protocol come with different trade-offs ⚖️. A protocol that provides perfect forward secrecy and identity protection trades performance or efficiency for better security 🔐, while a protocol that completes in one or two messages may trade security functionality (e.g., identity protection) for efficiency 🏎️.
Replay protection generally uses either a timestamp or a sequence number 🕰️. The first requires synchronized clocks, while the latter requires retaining state 📦. In a timestamp-based protocol, a replay cache is needed to store the authenticated messages (or the hashes of the messages) received within the allowable clock skew 🗃️. The size of the replay cache depends on the number of authenticated messages received during the allowable clock skew 📏. During a DoS attack, the replay cache might become overloaded 🚨. One solution is to over-provision the replay cache, but this may lead to a large replay cache 😵. Another solution is to let the allowable clock skew change dynamically during runtime 🔄. During a suspected DoS attack, the allowable clock skew is decreased so that the replay cache stays manageable 🛡️.
A challenge-response mechanism (using Nonces) removes the need for synchronized clocks for replay protection when the exchange uses three or more messages [MVV] 🎲.
Additional security functions become possible as the number of allowable messages in the registration protocol increases 📈. ISAKMP offers identity protection, for example, as part of a six-message exchange 🕵️. With additional security features, however, comes added complexity 🌀: identity protection, for example, not only requires additional messages, but may result in DoS vulnerabilities since authentication is performed late in the exchange, after resources have already been devoted 😱.
In all cases, there are tradeoffs with the number of messages exchanged, the desired security services, and the amount of infrastructure needed to support the group key management service 🍭. Whereas protocols that use two or even one-message setup have low latency and computation requirements, they may require more infrastructure such as secure time, or offer less security such as the absence of identity protection ⏰. What tradeoffs are acceptable and what aren't is very much dictated by the application and application environment 🌍✨.
4.3. Infrastructure for Alternative Registration Exchange Types 🏗️
The registration protocol may need external infrastructures to handle authentication and authorization, replay protection, protocol-run integrity, and possibly other security services such as secure synchronized clocks 🔧. For example, authentication and authorization may need a PKI deployment (with either authorization-based certificates or a separate management) or may be handled using AAA infrastructure 🪪. Replay protection using timestamps requires an external infrastructure or protocol for clock synchronization ⏲️.
However, external infrastructures aren't always needed; for example, pre-shared keys are used for authentication and authorization 🗝️. This may be the case if the subscription base is relatively small 🤏. In a conversational multimedia scenario (e.g., a VoIP call between two or more people), the end user may handle the authorization by manually accepting or rejecting the incoming calls 📲. In that case, infrastructure support may not be required 💅🌸.
4.4. De-registration Exchange ✨
okay so the session-establishment protocol that carries a registration exchange (think SIP or RTSP 💅) usually has a session-disestablishment partner too, like RTSP TEARDOWN [RFC2326] or SIP BYE [RFC3261]. that teardown moment is a perfect chance to tell the endpoints that the GSA state is ending 🦋
the signal only needs to be a one-way notification from one side saying "the GSA is getting destroyed." to authenticate that notice, we may use a proof-of-possession of the group key(s) by one side to the other. 🔐
some apps like a mutual, two-message exchange so both sides get an acknowledgement that the GSA is coming down along with the session (RTSP or SIP sessions, for example). in that case, a two-way proof-of-possession could double as the mutual acknowledgement of the GSA disestablishment 🤝💖
5. Rekey Protocol 🔑
the group rekey protocol is the thing that moves keys and SAs between a GCKS and the members of a secure communications group 🎀 the GCKS sends rekey messages to update a Rekey SA, to initialize or update a Data SA, or both. rekey messages are protected by a Rekey SA. the GCKS may update the Rekey SA when group membership changes or when KEKs or TPKs expire. quick reminder: KEKs go with a Rekey SA, and TPKs go with a Data SA 🧚
here are some properties we totally want from the rekey protocol 👑
- The rekey protocol ensures that all members receive the rekey information in a timely manner.
- The rekey protocol specifies mechanisms allowing the parties to contact the GCKS and re-sync when their keys expire and no updates have been received.
- The rekey protocol avoids implosion problems and ensures reliability in delivering Rekey information.
okay and the rekey protocol is basically the main reason the whole group key management setup can scale 📈 so it's imperative that all of the above happens in a scalable way 😭 solutions already exist in the literature (both IETF standards and research articles) for parts of this. for example, the rekey protocol may use a scalable group key management algorithm (GKMA) to cut down on how many keys go in a rekey message. GKMA examples include LKH, OFT, subset difference based schemes, etc. 🌸
5.1. Goals of the Rekey Protocol 🎯
the goals of the rekey protocol are:
- to synchronize a GSA,
- to provide privacy and (symmetric or asymmetric) authentication, replay protection and DoS protection,
- efficient rekeying after changes in group membership or when keys (KEKs) expire,
- reliable delivery of rekey messages,
- member recovery from an out-of-sync GSA,
- high throughput and low latency, and
- support IP Multicast or multi-unicast.
we've got several major issues to figure out in rekey protocol design 🧩
- rekey message format,
- reliable transport of rekey messages,
- implosion,
- recovery from out-of-sync GSA,
- incorporating GKMAs in rekey messages, and
- interoperability of GKMAs.
real talk: interoperation of rekey protocol implementations isn't enough for a GCKS to rekey a group successfully 🙈 the GKMA has to interoperate too. that means standard versions of the group key management algorithms, like LKH, OFT, or Subset Difference, must be used.
the rest of this section goes deeper on all of these topics 🦋
5.2. Rekey Message Transport and Protection 🔐
rekey messages carry Rekey and/or Data SAs along with KEKs and TPKs. these messages need to be confidential, authenticated, and protected against replay and DoS attacks. they get sent via multicast or multi-unicast from the GCKS to the members 📨
rekey messages are encrypted with the Group KEK for confidentiality. when a GKMA is in use, parts of the rekey message get encrypted first with the appropriate KEKs, as the GKMA specifies. the GCKS authenticates rekey messages using either a MAC computed with the group Authentication key, or a digital signature. either way, a sequence number goes into the MAC or signature computation to protect against replay attacks 🛡️
⚠️ heads up: when group authentication uses a symmetric key, rekey messages are vulnerable to attacks by other members of the group. rekey messages get digitally signed when group members don't trust each other 💀
when asymmetric authentication is used, members receiving rekey messages become vulnerable to DoS attacks. an external adversary could send a bogus rekey message, and a member wouldn't be able to tell it's fake until after it has done an expensive digital signature operation 😩 to guard against this, a MAC may be sent as part of the rekey message. members only verify the signature after the MAC checks out successfully ✨
rekey messages contain group key updates for either a single membership change [RFC2627,OFT] or multiple membership changes [SD1,SD2,BatchRekey], and they may contain group key initialization messages [OFT] 🌈
5.3. Reliable Transport of Rekey Messages 📬
the GCKS must make sure that all members have the current Data Security and Rekey SAs. otherwise, authorized members could get accidentally left out of group communications 😭 so the GCKS needs either a rekey algorithm that's inherently reliable, or a reliable transport mechanism to send rekey messages. it's giving "no one gets left behind" 🫶
there are two dimensions to this problem. rekey messages that update group keys can get lost in transit, or a host can miss them while it's offline 📴 LKH and OFT group key management algorithms depend on the host having received the past history of updates. if the host goes offline, it'll need to resynchronize its group-key state when it comes back online, which may take a unicast exchange with the GCKS. the Subset Difference algorithm is different though 💜 it puts all the necessary state into its rekey messages, so members don't need to be always online or keep state. it also doesn't need a back channel and can run on a broadcast network. but if a rekey message gets lost in transmission, Subset Difference can't decrypt messages encrypted with the TPK that came in the lost rekey message. there are self-healing GKMAs proposed in the literature that let a member recover lost rekey messages, as long as the rekey messages before and after the lost one were received 🩹
rekey messages are usually short (for a single membership change, and for small groups too), which makes a reliable delivery protocol pretty easy to design 🍓 the security requirements might add another dimension to handle, though. some special cases process membership changes as a batch, which means fewer rekey messages but bigger ones 📦 also, out of all the KEKs sent in a rekey message, as many as half the members only need a single KEK. we can use all of these properties when designing the rekey message(s) and the protocol that delivers them reliably 🧠
three categories of solutions have been proposed 🗂️
- Repeatedly transmit the rekey message. in lots of cases, rekey messages turn into just one or two IP packets.
- Use an existing reliable multicast protocol/infrastructure.
- Use FEC for encoding rekey packets (with NACKs as feedback) [BatchRekey].
for small messages, category 3 is basically the same as category 1 ✨
a group member might be out of synch with the GCKS if it gets a rekey message whose sequence number is more than one greater than the last sequence number it processed. that's one way the member can tell it missed a rekey message 🕵️♀️ or, the data-security application can notice it's using an out-of-date key and tell the group key management module about it. what the GCKS member does next is a matter of group policy 📋 the member should log the condition, and it may contact the GCKS to rerun the re-registration protocol and get a fresh group key. the group policy also has to account for boundary conditions, like rekey messages getting reordered when rekeying happens so often that two messages could swap places on an IP network 🔄 and it has to consider DoS attacks, where an attacker delays or deletes a rekey message to make a subnetwork or subset of members all contact the GCKS at the same time 🚨
if a group member gets out of sync with the GSA, it should re-register with the GCKS. but in lots of cases there are simpler ways to resync with the group 🌷
- The member can open a simple unprotected connection (e.g., TCP) with the GCKS and get the current (or several recent) rekey messages. there's no need for authentication or encryption here, since the rekey message is already signed and multicast in the clear. someone might think this opens the GCKS up to DoS attacks from lots of bogus requests. but that doesn't seem to make things worse, because bombarding the GCKS with bogus resync requests would be way more problematic 💅
- The GCKS can post the rekey messages on some public site (e.g., a web site), and the out-of-synch member can grab the rekey messages from there 🌐
the GCKS may always offer all three ways to resync (re-registration, simple TCP, and public posting). that way, the member gets to pick how it resyncs, and the GCKS doesn't need to add yet another field to the policy token [GSPT] 🎀 or, a policy token can have a field that lists one or more methods supported for resynchronization of a GSA ⭐
5.4. State-of-the-art on Reliable Multicast Infrastructure 🎀
okay so the rekey message can be sent using reliable multicast 🦋 there are several reliable multicast protocols and they all have different properties. ngl though, there are no standards track reliable multicast protocols published at this time, even tho IETF consensus has been reached on two protocols that are meant to go into the standards track [NORM,RFC3450]. so this document does not recommend a particular reliable multicast protocol or set of protocols for group rekeying 💅 whether NAK-based, ACK-based or some other method is the right vibe depends on the application needs and the operational environment. in the future, group key management protocols might pick particular standards-based approaches that fit their app. a secure announcement facility may be needed to signal the use of a reliable multicast protocol, and that could be specified as part of group policy. the reliable multicast announcement and policy specification can only follow once reliable multicast standards exist though, so we're not going deeper on it in this doc 🙈
Today, the several MSEC group key management protocols support sequencing of rekey messages through a sequence number ✨ and that number gets authenticated along with the rekey message. a sender can re-transmit multiple copies of the message as long as they all have the same sequence number, so resending is a rudimentary way to overcome loss along the network path 🔁 a member who receives the rekey message checks the sequence number to detect duplicate and missing rekey messages, and the member receiver discards any duplicates it gets.
large rekey messages, like the ones that contain LKH or OFT tree structures, might benefit from transport-layer FEC in the future, once standards-based methods are available 🧚 but it's unlikely that forward error correction (FEC) methods will help short rekey messages that fit within a single message. for those, FEC just degenerates to simple retransmission of the message 🍓
5.5. Implosion 💥
implosion can happen for one of two reasons 😭 first, remember that one of the goals of the rekey protocol is to synchronize a GSA. when a rekey or Data SA expires, members may contact the GCKS for an update. if all, or even many, members contact the GCKS at about the same time, the GCKS might not be able to handle all of those messages. we call this an out-of-sync implosion.
the second case is in the reliable delivery of rekey messages. reliable multicast protocols use feedback (NACK or ACK) to figure out which packets must be retransmitted. packet losses can make many members send NACKs to the GCKS, and we call this feedback implosion 🙈
the implosion problem has been studied a lot in the context of reliable multicasting, and the proposed feedback suppression and aggregation solutions might be useful in the GKM context too ✨ members may wait a random time before sending an out-of-sync or feedback message. in the meantime, they might receive the necessary key updates and therefore not send a feedback message at all 🫶 another option is to have members contact one of several registration servers when they are out-of-sync, but that requires GSA synchronization between the multiple registration servers.
feedback aggregation and local recovery, which some reliable multicast protocols use, aren't easily adaptable to transporting rekey messages 🙃 aggregation raises authentication issues, and local recovery is more complex because members need to establish SAs with the local repair server. any member of the group or a subordinate GCKS may serve as a repair server, which can be responsible for resending rekey messages.
members may use the group SA, more specifically the Rekey SA, to authenticate requests sent to the repair server. however, replay protection requires maintaining state at members as well as at repair servers. authentication of repair requests is meant to protect against DoS attacks 🛡️ also, an out-of-sync member may use an expired Rekey SA to authenticate repair requests, which means repair servers have to accept messages protected by old SAs. yikes, iykyk 💀
a simpler mechanism can achieve local repair efficiently instead 👑 each member receives a set of local repair server addresses as part of group operation policy information. when a member doesn't receive a rekey message, it can send a "Retransmit replay message(s) with sequence number n and higher" message to one of the local repair servers. the repair server can either ignore the request if it is busy, or retransmit the requested rekey messages as it received them from the GCKS. the repair server (which is also another member) may choose to serve only m requests in a given time period (i.e., rate limits responses) or per a given rekey message. rate limiting the requests and responses protects the repair servers as well as other members of the group from DoS attacks 🌈
5.6. Incorporating Group Key Management Algorithms 🧁
group key management algorithms make rekeying scalable ✨ large group rekeying without employing GKMAs is prohibitively expensive, so they're kind of a must.
here are some considerations when picking a GKMA 💖
- Protection against collusion. members (or non-members) should not be able to collaborate to deduce keys they aren't privileged to have, following the GKMA key distribution rules 🕵️
- Forward access control the GKMA should ensure that departing members cannot get access to future group data 🚪
- Backward access control the GKMA should ensure that joining members cannot decrypt past data 🔒
5.7. Stateless, Stateful, and Self-healing Rekeying Algorithms 🦋
we sort group key management algorithms into three categories: stateful, stateless, and self-healing ✨
stateful algorithms [RFC2627,OFT] use KEKs from past rekeying instances to encrypt (protect) KEKs for the current and future rekeying instances. the main downside is that if a member was offline or otherwise failed to receive KEKs from a past rekeying instance, it may no longer be able to synchronize its GSA, even though it can still receive KEKs from all future rekeying instances 😩 the only fix is to contact the GCKS explicitly for resynchronization. also, the KEKs for the first rekeying instance are protected by the Registration SA. communication in that phase is one to one, so reliable delivery is easy to ensure 💅
stateless GKMAs [SD1,SD2] encrypt rekey messages with KEKs sent during the registration protocol. since rekey messages are independent of any past rekey messages (i.e., ones not protected by KEKs therein), a member may go offline and still keep decrypting future communications 🌙 the catch is that stateless GKMAs offer no mechanisms to recover past rekeying messages. stateless rekeying may also be relatively inefficient, especially for immediate (not batch) rekeying in highly dynamic groups.
in self-healing schemes [Self-Healing], a member can reconstruct a lost rekey message as long as it receives some past and some future rekey messages 🩹 literal main character energy 👑
5.8. Interoperability of a GKMA 🤝
most GKMA specifications don't specify packet formats, even though many group key management algorithms need format specification for interoperability 😤 there are several different ways to manage key trees and to number nodes within them. the following information is needed during initialization of a Rekey SA, or included with each GKMA packet:
- GKMA name (e.g., LKH, OFT, Subset Difference)
- GKMA version number (implementation specific). the version may imply several things, such as the degree of a key tree, proprietary enhancements, and it can qualify another field such as a key ID.
- Number of keys or largest ID
- Version-specific data
- Per-key information:
- key ID,
- key lifetime (creation/expiration data) ,
- encrypted key, and
- encryption key's ID (optional).
key IDs may change in some implementations, in which case one needs to send:
List of <old id, new id> pairs.
6. Group Security Association 🌸
the GKM architecture defines the interfaces between the registration, rekey, and data security protocols in terms of the Security Associations (SAs) of those protocols 💜 by isolating these protocols behind a uniform interface, the architecture lets implementations use whatever protocols suit their needs best. for example, a rekey protocol for a small group could use multiple unicast transmissions with symmetric authentication, while a rekey protocol for a large group could use IP Multicast with packet-level Forward Error Correction and source authentication 🚀
the group key management architecture provides an interface between the security protocols and the group SA (GSA) 🫧 the GSA consists of three SAs: Registration SA, Rekey SA, and Data SA. the Rekey SA is optional. there are two cases when defining the relationships between the three SAs, and in both cases the Registration SA protects the registration protocol 🎀
Case 1: group key management is done WITHOUT using a Rekey SA. the registration protocol initializes and updates one or more Data SAs (having TPKs to protect files or streams). each Data SA corresponds to a single group, and a group may have more than one Data SA 🍬
Case 2: group key management is done WITH a Rekey SA to protect the rekey protocol. upon successful completion, the registration protocol initializes the one or more Rekey SAs as well as zero or more Data SAs. when a Data SA is not initialized in the registration protocol, its initialization is done in the rekey protocol. the rekey protocol updates Rekey SA(s) AND establishes Data SA(s) ✨
6.1. Group Policy ✨
okay so group policy is explained in detail in the Group Security Policy Token document [GSPT] 📜 It can get shared through group announcements, key management protocols, and other out-of-band stuff (e.g., via a web page) 🌸 The group key management protocol carries the cryptographic policies of the SAs and the keys it sets up, plus extra policies for keeping the group running securely 🔐
the acceptable cryptographic policies for the registration protocol are not sent through the group key management protocol, and that's because they come before any of the key management exchanges 🙈 The registration protocol can run over TLS [TLS], IPsec, or IKE. So a security policy repository with some access protocol might need to get queried before the key-management session starts, just to figure out the starting cryptographic policies for that session 💅 This document assumes that repository and protocol exist for GCKS and member policy queries. So group security policy gets represented in a policy repository and is accessed using a policy protocol. Policy distribution may be a push or a pull operation 🦋
the group key management architecture assumes the following group policy info may be managed externally, e.g., by the content owner, group conference administrator, or group owner 👑
- the identity of the Group owner, the authentication method, and the delegation method for identifying a GCKS for the group;
- the group GCKS, authentication method, and delegation method for any subordinate GCKSs for the group;
- the group membership rules or list and authentication method.
there are two more policy-related requirements that live outside group key management, and they're giving main character energy 🎀
- There is an authentication and authorization infrastructure such as X.509 [RFC3280], SPKI [RFC2693], or a pre-shared key scheme, in accordance with the group policy for a particular group.
- There is an announcement mechanism for secure groups and events, which operates according to group policy for a particular group.
group policy decides how the registration and rekey protocols initialize or update Rekey and Data SAs 🧚 The next sections describe the potential info the GCKS sends for the Rekey and Data SAs. A member needs the info in those next sections to establish Rekey and Data SAs 💖
6.2. Contents of the Rekey SA 🔑
the Rekey SA protects the rekey protocol 🛡️ It holds cryptographic policy, Group Identity, and Security Parameter Index (SPI) [RFC2401] to uniquely identify an SA, replay protection info, and key protection keys ✨
6.2.1. Rekey SA Policy
- GROUP KEY MANAGEMENT ALGORITHM
this is the group key revocation algorithm that enforces forward and backward access control 🙅♀️ Examples of key revocation algorithms include LKH, LKH+, OFT, OFC, and Subset Difference [RFC2627,OFT,TAXONOMY,SD1,SD2]. If the key revocation algorithm is NULL, the Rekey SA contains only one KEK, which serves as the group KEK. The rekey messages initialize or update Data SAs as usual. However, the Rekey SA itself can be updated (the group KEK can be rekeyed) when members join or when the KEK is about to expire. Leave rekeying is done by re-initializing the Rekey SA through the rekey protocol 💀
- KEK ENCRYPTION ALGORITHM
this specifies a standard encryption algorithm such as 3DES or AES, and also the KEK KEY LENGTH 🍓
- AUTHENTICATION ALGORITHM
this algorithm uses digital signatures for GCKS authentication (since all shared secrets are known to some or all members of the group), or it uses some symmetric secret to compute MACs for group authentication 🫶 Symmetric authentication provides weaker authentication, because any group member can impersonate a particular source 😭 The AUTHENTICATION KEY LENGTH also needs to be specified.
- CONTROL GROUP ADDRESS
this address is used for multicast transmission of rekey messages 📡 This info is sent over the control channel, such as in an ANNOUNCEMENT protocol or call setup message. How well the control group address is protected is a matter of group policy 🌈
- REKEY SERVER ADDRESS
this address lets the registration server be a different entity from the server used for rekeying, such as for future invocations of the registration and rekey protocols 🦋 If the registration server and the rekey server are two different entities, the registration server sends the rekey server's address as part of the Rekey SA.
6.2.2. Group Identity
the group identity rides along with the SA (payload) info as an identifier if the specific group key management protocol lets multiple groups get initialized in a single invocation of the registration protocol, or multiple groups get updated in a single rekey message 🎀 It's often simpler to restrict each registration invocation to a single group, but that restriction isn't necessary 🙃 It's always necessary to identify the group when establishing a Rekey SA, either implicitly through an SPI or explicitly as an SA parameter 🔍
6.2.3. KEKs
depending on the key management algorithm, the Rekey SA contains one or more KEKs 🗝️ The GCKS holds the key encrypting keys of the group, while the members receive keys following the specification of the key management algorithm. When there are multiple KEKs for a group (as in an LKH tree), each KEK needs to be associated with a Key ID, which is used to identify the key needed to decrypt it 🌳 Each KEK has a LIFETIME associated with it, after which the KEK expires ⏳
6.2.4. Authentication Key
the GCKS provides a symmetric or public key for authenticating its rekey messages 🔏 Symmetric key authentication is only appropriate when all group members can be trusted not to impersonate the GCKS 🥺 The architecture doesn't rule out methods for deriving symmetric authentication keys at the member [RFC2409] instead of pushing them from the GCKS 🧠
6.2.5. Replay Protection
rekey messages need protection from replay/reflection attacks 🔁 Sequence numbers are used for this purpose, and the Rekey SA (or protocol) contains this info 🔢
6.2.6. Security Parameter Index (SPI)
the tuple <Group identity, SPI> uniquely identifies a Rekey SA 🆔 The SPI changes each time the KEKs change 🔄
6.3. Contents of the Data SA 📦
the GCKS specifies the data security protocol used for securely sending data from sender(s) to receiving members 🚀 Examples include IPsec ESP [RFC2401] and SRTP [RFC3711]. The contents of each of these protocols are out of scope for this document, but we list the info the registration protocol (or the rekey protocol) sends to initialize or update the Data SA 💅
6.3.1. Group Identity
the Group identity rides along with SA info when Data SAs are initialized or rekeyed for multiple groups in a single invocation of the registration protocol, or in a single Rekey message 🫧
6.3.2. Source Identity
the SA includes source identity info when the group owner chooses to reveal source identity to authorized members only 🕵️♀️ A public channel, such as the announcement protocol, is only appropriate when there's no need to protect source or group identities 📢
6.3.3. Traffic Protection Keys
no matter which data security protocol is used, the GCKS supplies the TPKs, or info to derive TPKs for traffic protection 🛡️
6.3.4. Data Authentication Keys
depending on the data authentication method the data security protocol uses, group key management may pass one or more keys, functions (e.g., TESLA [TESLA-INFO,TESLA-SPEC]), or other parameters used for authenticating streams or files 🌊
6.3.5. Sequence Numbers
the GCKS passes sequence numbers when the data security protocol needs them, for SA synchronization and replay protection 🔢✨
6.3.6. Security Parameter Index (SPI)
the GCKS may provide an identifier as part of the Data SA contents for data security protocols that use an SPI or similar mechanism to identify an SA or the keys within an SA 🆔
6.3.7. Data SA policy
the Data SA parameters are specific to the data security protocol, but they generally include the encryption algorithm and parameters, the source authentication algorithm and parameters, the group authentication algorithm and parameters, and/or replay protection info 💜
7. Scalability Considerations ✨
okay so group comms is SO diverse, bestie 🦋 teleconferencing can use a multipoint control unit (MCU) to squish a bunch of members into one session, and MCUs can even be organized hierarchically 🧚 a loosely coupled teleconferencing session [RFC3550] has no central boss at all, it's fully distributed and end-to-end 💅 teleconference sessions usually top out at dozens of participants. but video broadcast over multicast and media-on-demand over unicast? those are large-scale groups with hundreds to millions of participants 😭🔥
as we covered in the Requirements section, Section 2, the group key management architecture supports multicast apps with a single sender 💜 the architecture in this paper supports large-scale operation through these features:
- there's no need for a unicast exchange to hand data keys to a security protocol for members who already registered in the group. data keys can just get pushed in the rekey protocol 🚀
- the registration and rekey protocols are separable, so a group can decide how members get group secrets. a group might use a smart-card system in place of the registration protocol, which lets the rekey protocol work with no back channel for broadcast stuff like TV conditional access systems 📺✨
- the registration and rekey protocols support new keys, algorithms, authentication mechanisms and authorization infrastructures in the architecture. when the authorization infrastructure supports delegation (like X.509 and SPKI), the GCKS function can be distributed as shown in Figure 3 below 🌈
feature 1 is giving fast keying for data security protocols when the member is already in the group 🎀 that's realistic for subscriber groups and service provider customers who offer content events, but it might be too restrictive for apps that let people enroll right when the event starts 😬 the MSEC group key management architecture suggests hierarchically organized key distribution to handle a potential pile-up of mass simultaneous registration requests 🍓 the Figure 3 setup might be needed when normal clustering and load balancing for a central GCKS site can't meet customer requirements. but unlike regular caching and content distribution networks, the Figure 3 config has extra security ramifications for the physical security of a GCKS 🙈
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+Figure 3: Hierarchically Organized Key Distribution 🌸
more analysis and work is needed on the protocol instantiations of the group key management architecture, to figure out how well and how securely it can support large-scale multicast apps 🧐 besides being as secure as pairwise key management against man-in-the-middle, replay, and reflection attacks, group key management protocols have extra security needs. unlike pairwise key management, group key management has to stay secure against group members who try to impersonate a GCKS or disrupt its operation, and against non-members too 🫶
so secure groups need to converge on a common group key even when members are attacking the group, joining and leaving, or getting evicted 💀 group key management protocols also need to stay robust when DoS attacks or network partitions cause huge numbers of synchronized requests 😭 an instantiation of group key management therefore needs to think about how GCKS operation could be distributed across multiple GCKSs designated by the group owner, serving keys on behalf of a designated GCKS. the GSAKMP [GSAKMP] protocol uses the policy token and lets you designate some members as subordinate GCKSs to tackle this scalability issue 👑
8. Security Considerations 🔐
okay this section is serious, bestie, but it's also giving drama 😭 this memo describes the MSEC key management architecture. this architecture will be instantiated in one or more group key management protocols, which MUST be protected against man-in-the-middle, connection hijacking, replay, or reflection of past messages, and denial of service attacks 🚨
⚠️ the protocols MUST be protected against all of those attacks, no exceptions 💅
authenticated key exchange [STS,SKEME,RFC2408,RFC2412,RFC2409] techniques limit the effects of man-in-the-middle and connection hijacking attacks 🛡️ sequence numbers and low-computation message authentication techniques can be effective against replay and reflection attacks ✨ cookies [RFC2522], when properly implemented, give an efficient way to reduce the effects of denial of service attacks 🍪
this memo does not address attacks against key management or security protocol implementations, like so-called type attacks that aim to disrupt an implementation by things like buffer overflow 🙈 the focus of this memo is on securing the protocol, not on implementing it. literally a different vibe 💖
classical authenticated key exchange techniques can be applied to group key management, but new problems pop up with sharing secrets among a group of members 😬 group secrets may be disclosed by a member of the group, and group senders may be impersonated by other members of the group 💀 key management messages from the GCKS SHOULD NOT be authenticated using shared symmetric secrets unless all members of the group can be trusted not to impersonate the GCKS or each other 🙅♀️ similarly, members who disclose group secrets undermine the security of the entire group 💔 group owners and GCKS administrators MUST be aware of these inherent limitations of group key management 🧠
another limitation of group key management is policy complexity 🌀 peer-to-peer security policy is an intersection of the policy of the individual peers, but in secure groups a group owner sets group security policy externally. this document assumes there is no negotiation of cryptographic or other security parameters in group key management. so group security policy poses new risks to members who send and receive data from secure groups 😱 security administrators, GCKS operators, and users need to determine minimal acceptable levels of security (for example, authentication and admission policy of the group, key lengths, cryptographic algorithms and protocols used) when joining secure groups 📋
given the limitations and risks of group security, the security of the group key management registration protocol SHOULD be as good as the base protocols it's built on, such as IKE, IPsec, TLS, or SSL 🔒 the particular instantiations of this group key management architecture MUST ensure that the high standards for authenticated key exchange are preserved in their protocol specifications, which will be Internet standards-track documents that are subject to review, analysis, and testing 🧐
the second protocol, the group key management rekey protocol, is new and has unknown risks 👀 the source-authentication risks described above are obviated by the use of public-key cryptography 🔑 the use of multicast delivery may raise extra security issues like reliability, implosion, and denial-of-service attacks based on multicast 🌊 the rekey protocol specification needs to offer secure solutions to these problems. each instantiation of the rekey protocol, such as the GSAKMP Rekey or the GDOI Groupkey-push operations, needs to validate the security of its rekey specifications 🫠
novelty and complexity are the biggest risks to group key management protocols 😵💫 much more analysis and experience are needed so the architecture in this document can provide a well-articulated standard for the security and risks of group key management 📚✨
9. Acknowledgments 🌷
shoutout to the GKM Building Block [GKMBB] I-D by SMuG, which was a precursor to this document 🙌 thanks to Thomas Hardjono and Hugh Harney for their efforts. during the course of preparing this document, Andrea Colegrove, Brian Weis, George Gross, and several others in the MSEC WG and GSEC and SMuG research groups provided valuable comments that helped improve it 💜 the authors really appreciate their contributions 🎀
10. Informative References ✨
Okay bestie, time for the reading list 📚 These are the references the RFC leans on for background. Nothing here is required reading to implement the spec, but they're the receipts 💅
- [BatchRekey] Yang, Y. R., et al., "Reliable Group Rekeying: Design and Performance Analysis", Proc. ACM SIGCOMM, San Diego, CA, August 2001.
- [CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A New Approach to Group Key Agreement", IEEE ICDCS 97, May 1997
- [FN93] Fiat, A. and M. Naor, "Broadcast Encryption, Advances in Cryptology", CRYPTO 93 Proceedings, Lecture Notes in Computer Science, Vol. 773, pp. 480-491, 1994.
- [GKMBB] Harney, H., M. Baugher, and T. Hardjono, "GKM Building Block: Group Security Association (GSA) Definition," Work in Progress, September 2000.
- [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R. Fleischer, "Group Secure Association Key Management Protocol", Work in Progress, February 2003.
- [GSPT] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "The MSEC Group Security Policy Token", Work in Progress, August 2003.
- [H.235] International Telecommunications Union, "Security and Encryption for H-Series (H.323 and other H.245-based) Multimedia Terminals", ITU-T Recommendation H.235 Version 3, Work in progress, 2001.
- [JKKV94] Just, M., Kranakis, E., Krizanc, D., and P. van Oorschot, "On Key Distribution via True Broadcasting", Proc. 2nd ACM Conference on Computer and Communications Security, pp. 81-88, November 1994.
- [MARKS] Briscoe, B., "MARKS: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences", Proc. First International Workshop on Networked Group Communication (NGC), Pisa, Italy, November 1999.
- [MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [MSEC-Arch] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
- [MVV] Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1996.
- [NORM] Adamon, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
- [OFT] Balenson, D., McGrew, P.C., and A. Sherman, "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization", IRTF Work in Progress, August 2000.
- [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
- [RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture" RFC 2094, July 1997.
- [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
- [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
- [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
- [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
- [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [SD1] Naor, D., Naor, M., and J. Lotspiech, "Revocation and Tracing Schemes for Stateless Receiver", Advances in Cryptology - CRYPTO, Santa Barbara, CA: Springer-Verlag Inc., LNCS 2139, August 2001.
- [SD2] Naor, M. and B. Pinkas, "Efficient Trace and Revoke Schemes", Proceedings of Financial Cryptography 2000, Anguilla, British West Indies, February 2000.
- [Self-Healing] Staddon, J., et. al., "Self-healing Key Distribution with Revocation", Proc. 2002 IEEE Symposium on Security and Privacy, Oakland, CA, May 2002.
- [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", ISOC Secure Networks and Distributed Systems Symposium, San Diego, 1996.
- [STS] Diffie, P. van Oorschot, M., and J. Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic Publishers.
- [TAXONOMY] Canetti, R., et. al., "Multicast Security: A Taxonomy and some Efficient Constructions", IEEE INFOCOM, 1999.
- [TESLA-INFO] Perrig, A., Canetti, R., Song, D., Tygar, D., and B. Briscoe, "TESLA: Multicast Source Authentication Transform Introduction", Work in Progress, December 2004.
- [TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, "TESLA: Multicast Source Authentication Transform Specification", Work in Progress, April 2002.
- [tGSAKMP] Harney, H., et. al., "Tunneled Group Secure Association Key Management Protocol", Work in Progress, May 2003.
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0," RFC 2246, January 1999.
- [TPM] Marks, D. and B. Turnbull, "Technical protection measures: The Intersection of Technology, Law, and Commercial Licenses", Workshop on Implementation Issues of the WIPO Copyright Treaty (WCT) and the WIPO Performances and Phonograms Treaty (WPPT), World Intellectual Property Organization, Geneva, December 6 and 7, 1999.
- [Wool] Wool, A., "Key Management for Encrypted broadcast", 5th ACM Conference on Computer and Communications Security, San Francisco, CA, Nov. 1998.
Authors' Addresses 🎀
Meet the squad who wrote this! 🫶 Here are their contact details, exactly as published:
Mark Baugher
Cisco Systems
5510 SW Orchid St.
Portland, OR 97219, USA
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Ran Canetti
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532, USA
Phone: +1 914-784-7076
EMail: canetti@watson.ibm.com
Lakshminath R. Dondeti
Qualcomm
5775 Morehouse Drive
San Diego, CA 92121
Phone: +1 858 845 1267
EMail: ldondeti@qualcomm.com
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm, Sweden
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶✨
📦 where this page comes from
- ietf: rfc4046 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms