RFC 2094

Group Key Management Protocol (GKMP) Architecture

📅 published July 1997, from ietf

Group Key Management Protocol (GKMP) Architecture 🎀

RFC number: 2094
Authors: H. Harney and C. Muckenhirn, both from SPARTA, Inc. 🦋
Category: Experimental 🧪
Date: July 1997 📅
Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 💭

Status of this Memo ✨

okay bestie, first things first 🫶 this memo defines an Experimental Protocol for the Internet community. It is NOT an Internet standard of any kind. Discussion and suggestions for improvement are literally requested, so share your thoughts! Distribution is unlimited, so go wild 💜

Table of Contents 💅

1. Introduction.................................................   1
2. Multicast Key Management Architectures.......................   3
3. GKMP Protocol Overview.......................................   9
4. Issues.......................................................  19
5. Security Considerations......................................  22
6. Authors' Address.............................................  22

Abstract 🌸

this spec proposes a protocol to create grouped symmetric keys and hand them out to communicating peers, and it's giving everything 😭 the advantages are: 1) virtually invisible to the operator, 2) no central key distribution site needed, 3) only group members have the key, 4) sender or receiver oriented operation, and 5) it can make use of multicast communications protocols. iconic, honestly 👑

1 Introduction 🧚

this doc describes an architecture for managing cryptographic keys for multicast communications. we lay out the roles and responsibilities of each communications system element, define the security and functional requirements for each one, and give a detailed intro to the Group Key Management Protocol (GKMP) 💖 GKMP lets you create and distribute keys inside groups of any size, no global or centralized key manager required. it's the main character of this whole doc ✨ the GKMP mixes techniques developed for making pairwise keys with techniques used by a KDC to distribute symmetric keys (aka symmetric encryption of keys) so that a symmetric key can reach a whole group of hosts 🔥

1.1 Multicast Communications Environments 🍓

ok so the work behind this report was mainly about military command and control and weapons control systems. those systems tend to have top-down, commander-commanded communications flows 🫡 which party gets to be a member of a given communication (a multicast group, for example) is up to the "higher" level party(ies). this "sender-initiated" model (assuming the higher-level party is the one sending) maps well to broadcast media (like electromagnetic, free-space transmission) and circuit switched communications media (e.g., video teleconferencing, ATM multicast) 📡

now, if we look at applying this to the Internet, a somewhat different model seems to be going on, at least for some part of Internet multicast traffic 👀 IDRP and Distance Vector Multicast Routing Protocol (DVMRP) use multicast as a way for parties to relay common information to their peers. every party both sends and receives on the multicast channel. a party can choose to leave or join the communication whenever it wants, without the express permission of any of the other parties (this raises the question of meta-authorizations that let the parties cooperate, which is a whole mood 🙈). even more interesting: in the multicast IP model, the receiver tells the network to add it to the distribution for a particular multicast address, whether that address exists yet or not, and the transmitter isn't consulted about adding the receiver 💅

other Internet multicast apps, like NASA Select broadcasts, can be seen as implementing the sender model, since the sender picks the broadcast time, channel, and content, just not the destinations 📺

our goal is to provide key management services that support both communications (and implied access control) models and that work in either a circuit switched or packet switched environment 🦋

1.2 Security for Multicast 🔐

multicast communications, same as unicast, may require any of the security services defined in ISO 7498: access control, data confidentiality, traffic confidentiality, integrity/data authentication, source authentication, sender and receiver non-repudiation, and service assurance. but from the key management perspective, only data confidentiality, data authentication, and source authentication can be supported 😤 the rest (traffic confidentiality, non-repudiation, and service assurance) must be provided by the communications protocol. they may rely on cryptographic services, but those services don't guarantee them 🙅‍♀️

2 Multicast Key Management Architectures 💜

2.1 Current Operations 🕰️

there are several electronic mechanisms for generating and distributing symmetric keys to several computers (aka communications groups). these techniques generally rely on a key distribution center (KDC) to act as a go-between when setting up symmetric key groups. military systems like BLACKER, STU-II/BELLFIELD, and EKMS, plus commercial systems like X9.17 and Kerberos, all run on dedicated KDCs 🏛️

a group key request gets sent to the KDC through various means (on- or off-line). the KDC, acting as an access controller, decides whether or not the request is proper (i.e., whether all members of a group are cleared to receive all the data on a group). then the KDC calls up each individual member of the group and downloads the symmetric key to them. once each member has the key, the KDC notifies the requester, and then secure group communication can begin 🔑

ngl this was way faster than anything that needs human intervention. but it still takes quite a bit of set-up time 😩 and a third party, whose main interest isn't the communication, has to get involved too 🙃

pairwise keys can be created autonomously by a host on a network, using any number of key generation protocols (FireFly, Diffe-Hellman, RSA) 🧠 these protocols all rely on cooperative key generation algorithms to create a cryptographic key, and those algorithms rely on random information generated by each host. they also rely on peer review of permissions, to make sure the communication partners are who they claim to be and are authorized to receive the info being transmitted. this peer review process depends on a trusted authority assigning permissions to each host in the network that wants to be able to create these keys 🛡️

the real beauty of these pairwise key management protocols is that they can be built into the communication protocol or the application itself. so the key management becomes relatively invisible to the people in the system ✨

2.2 GKMP-Based Operations 🦋

the GKMP we're about to describe delegates access control, key generation, and distribution to the communicating entities themselves, instead of relying on a third party (a KDC) for those jobs 🙌 before actually distributing any keys, a few things have to be assumed for this document. first, there exists a "security manager" responsible for creating and distributing authentic identification and security permission information to parties. this could be a strictly hierarchical system (à la STU-III) or a more ad hoc system of cooperating peer "domain managers." how the certification hierarchy is implemented is NOT addressed in this document 🤷‍♀️ second, communicating parties are online for the keys formed and distributed by the GKMP 📶

2.2.1 Sender Initiated Operations 🚀

this section describes the basic operational concept for multicast key management with sender-initiated multicast support. this model of multicast communications was the basis for our original work on multicast key management 🥹 from a security standpoint, the sending application can control access to the transmission through both key distribution and communications distribution (not sending the transmission to some addresses) 🔥

Identification of Group Key Controller -- the originator of the multicast group creates or obtains a group management certificate from its certification hierarchy. the certificate identifies the holder as responsible for generating and distributing the group key. (naming standards aren't addressed here. the name should reflect the naming structures appropriate for the supported cryptographic service. for example, IP-level encryptors should use naming that reflects "host" identities (IP addresses, or DNS host names), and an RTP encryptor would use session names 🏷️) the originator then relays the membership list to the Group Key Management (GKM) application 📋

Group Key Creation -- the GKM application, operating on behalf of the originator, selects one member of the group, contacts it, and creates a Group Key Packet (GKP). a GKP contains the current group traffic encrypting key (GTEK) and the future group key encrypting key (GKEK). the GKM application then identifies itself as the group key controller, which the member validates, under cover of the GTEK 🔐

Group Key Packet (GKP) = [GTEKn,GKEKn+1]

as part of forming the group key packet, usage parameters appropriate for the underlying crypto-system get selected. unlike normal parameter negotiation (where a common security level/range and services are agreed on), the originator's GKM application selects these parameters, and the member must comply 😤 no arguing, no negotiating 💅

Group Key Distribution -- after the GKP is created, the group controller contacts each member of the group, creates a Session Key Package (SKP), validates their permissions (checking the member's certificate against the group parameters), and creates a Group Rekey Package for that member 📦 an SKP contains a session TEK and a session KEK for one particular member. a GRP contains the GKP encrypted in a KEK and signed using the originator's certificate ✍️

Session Key Package (SKP) = [STEK, SKEK]

Group Rekey Package (GRP) = {[GKP]KEK} SignatureController

Group Rekey -- when the group needs to be rekeyed, the originating GKM application selects a member, creates a new GKP, creates a new GRP (which is encrypted in the previously distributed next GKEK), and broadcasts it to the group 🔄

this procedure is fairly complex, but apart from distributing site-specific certificates, no centralized key management resources are needed. the only parties involved in the key management communications are the same parties who'll be participating in the group 🫶 ✨

2.2.2 Receiver Initiated Operations 🦋

okay so this section is about key management for receiver initiated multicast 💅. the problem is that the end participants aren't known ahead of time, which is lowkey a security nightmare 😭. and in a purely receiver initiated app (like DVMRP), there's no such thing as an "originator". the group members can be super dynamic too, with people joining and leaving literally minute by minute 🌈.

so for secure group comms to work, all members must obtain the same key. there are two ways to make that happen. you can use deterministic key generation with a secret, shared seed, or you can make one member responsible for creating the key 🔑. the seed approach is risky, especially if the seed gets lost, because that compromises both past and future traffic 💀. making one member the key "controller" has its own drawbacks, but they're about picking who the controller should be and making sure every member can actually reach them 🙈. the rest of this section looks at how the "controller" idea from above could work in the receiver initiated case ✨.

Selection of Group Key Controller 👑: a group member gets to be responsible for the initial group setup and for regularly generating and distributing new GRPs. the controller doesn't have to be the controller forever, but at any given moment only one controller may be active for each group. the controller can be picked by a voting system, by a simple default (whoever transmits to the group first is the controller), or by configuration 🎀.

The current controller's identity must be made available to all members, and to potential members, for initial group key load and error recovery. This info can be relayed by broadcast on a key management "channel," or through a directory service 📡. (the original says "broacast" lol, but we know what it means 💖)

Group Key Creation 🌸: the GKP gets created and distributed pretty much the same way it does in sender initiated operations. the controller creates a GKP together with the first group member who reaches out. then the GKM application identifies itself as the group key controller, and the member validates that, under cover of the GTEK. after that, parameter negotiation happens and the first group member gets keyed ✨.

Group Key Distribution 🧚: once the GKP exists, every other member who contacts the controller gets a SKP created, their permissions get validated, and then a GRP is loaded to them 💜.

for widely distributed groups, a form of distributed dissemination can be used 🌍. some number of regional GKM applications are enabled to validate the permissions of new members, and once a member passes, they get sent the current GKP. (access control isn't defined in this document, but it's assumed that both hierarchical and discretionary access control, meaning rule-based and identity-based, will be supported 🫶.) these regional key distributors do everything the controller does, except they don't create the GKP. and this idea can go even further, to the point where all current members can download the GKP and pass that ability along 🔥.

Group Rekey 🔁: when the group needs rekeying, the procedure is identical to the sender initiated case. the controlling GKM application selects a member, creates a new GKP, creates a new GRP (encrypted in the previously distributed next GKEK), and broadcasts it to the group 🍓.

2.3 GKMP Features ⭐

okay this part is where the GKMP gets to show off 😤. it's highlighting the areas where we think the GKMP approach has advantages over the "traditional" KDC based approaches 👑.

2.3.1 Multicast 📣

multicast protocols are becoming a bigger deal across the Internet 🌐. the biggest perk is that several receivers can simultaneously get the same transmission 🙌. if the transmission is sensitive, it should be encrypted 🔒. that means all members of the group must share the same encryption key to actually benefit from the multicast transmission 💖.

right now, the only way to set up a group of symmetric keys is with a centralized key management facility 🏢. that facility acts as a key broker, creating a key and distributing it to qualified group members. but this centralized concept has several problems, and those problems are a big part of why we want a distributed key management protocol 🦋.

2.3.2 Increase the autonomy of key groups 🌱

the GKMP extends the pairwise key paradigm to grouped keys ✨. this protocol can be integrated into communication protocols or applications, and it can become invisible to the host's operator 🫥. we'll use peer review to enforce our security policy 🧐.

the GKMP lets any host on a network create and manage a secure group 💅. maintaining those group keys can be done by the hosts that are interested in the group 🎀. the groups themselves are relatively autonomous, which makes the technology way easier to install and lets more hosts use secure multicast communications 🥰.

2.3.3 Latency ⏱️

latency is the time it takes to set up, tear down, or re-key a group 😩. put simply, it's how long it would take to set up a multicast address 🚀.

the GKMP can delegate group creation authority to any host in the network 💁‍♀️. basically, when a host needs a group, it has the tools to create that group and manage it. and since the host only needs to create a single group, it can focus entirely on that group 🎯.

with the current centralized key distribution approach, the group has to be requested from a central site 🏛️. that site processes the request according to its priority and current workload 😮‍💨. latency builds up if the central site's workload gets unwieldy, or if communications to the site become overloaded 📉.

2.3.4 Extendibility 🧩

one of the problems with a centralized key distribution system is that all the key management workload gets concentrated at one site 🥵. creating key groups (key creation, access review, and communication to group members) takes time and effort 💦. as the number of groups on the network grows, and the number of group members grows too, the workload at that central site quickly hits capacity 🚨.

the GKMP should let a great number of groups exist on the Internet without overloading any particular host 🙏. delegating the net-wide group creation and management workload puts the job of maintaining groups on the hosts that actually use them 🫶. that's not just more efficient, it's also the more appropriate place for the burden 💅.

the GKMP spreads the communication requirements for managing groups across the network 🕸️. each group manages itself using the same communication resources it already needs to pass traffic. if a communication group can support the group's traffic, it's likely able to support the minimal traffic needed to manage the keys for that group too 🧃.

the GKMP provides its own access control, based on signed netwide permission certificates 📜. this partially spreads out the burden of access control and permission management 🥳. a system wide authority must assign the permission certificates, but the day-to-day access control decisions are the GKMP's responsibility 💼.

2.3.5 Operating expense 💸

a centralized key distribution site holds, at one time or another, the keys for the whole net 😬. that makes it a juicy target for someone to compromise 🎯. to protect the site, physical and procedural security mechanisms get used (for example guards, fences, intrusion alarms, two person safes, and no-alone zones) 🚧. those mechanisms do not come cheap 💳.

letting hosts create and manage their own keys gets rid of the need for an online centralized key distribution site 🙌. the protocol approach restricts access to the keys to the hosts that use them (the minimal set) 🔐. the encryption mechanisms have already paid the cost of being physically secured, so the key management system doesn't add any extra cost 🤑.

2.3.6 Communication Resources 📡

a centralized site is involved in creating, distributing, rekeying, and providing access control for every group, so it gets accessed constantly 😵. the communication resources available to that site often become a bottleneck for the groups 🚧. that's why a big pipe usually gets installed to the facility 🛠️.

the GKMP delegates most of the key creation, distribution, rekey, and access control work to the hosts that need the secure communication 💪. there's no longer a single third party that has to be consulted before every group key management action 🙅‍♀️. so the communication requirements for managing keys have moved over to the groups themselves 🎉. the need for special high capacity communications is gone 🌟.

2.3.7 Reliability 🛡️

delegating key management responsibility to the groups gets rid of the centralized key management site as a single point of failure 💅. the groups that use the key are responsible for it 🫶. if the communications system fails for key management, it's also down for the communications themselves 😔.

the GKMP will try to delegate as many functions to the group as it can 🙆‍♀️. some functions still need to happen outside the group (like granting privileges), and those can still fail 🥲. when that happens, the GKMP will operate on the old set of permissions 🫡. those functions don't need to be in-line, since they're performed separately from the key management actions and aren't crucial to day-to-day operation 🌷.

2.3.8 Security 🔐

people are the riskiest element when it comes to security 🙃. a distributed protocol takes many people out of the key distribution chain 🧹. that limits the "exposure" of the key 💖.

3 GKMP Protocol Overview 🧚‍♀️

3.1 Supporting functions 🧰

a secure key management protocol needs a bunch of supporting functions, especially in a military environment 🎖️. the two major support functions are security management and network group management 🗂️. in the commercial world, a company could provide these support functions 🏢.

Security Management is all about permission management 🗝️. in a military environment, data gets separated along classic classification lines (TOP SECRET all the way down to UNCLASSIFIED) 🪖. in the commercial world, those levels are proprietary or need-to-know access 🤫.

network group management gives the key management protocol an interface to the communications system and controls network resources 🌐. some entity (either a commercial or military system, or the host or network operations center) has to give the key management protocol a list of the group members 📋. and if the network resources (bandwidth and processing) are considered scarce, a management structure has to allocate them ⚖️. ✨

3.1.1 Security management ✨

Security management is a role that covers the entire network 🌐. It handles netwide permission management, initializing the software, and compromise recovery. The GKMP relies on security management to operate, so it's literally the foundation 🫶. Check out Figure 1 for the security management view.

The GKMP must assume trusted handling of the protocol software before and during installation 💅. If the GKMP is going to use peer to peer access control, the system must control who gets which permissions. Those permissions have to be monitored and updated as needed. And overseeing all of this has to include maintaining a Certificate Revocation List 📜.

Secure start-up We need to control how GKMP software gets loaded onto a host and initialized 🚀. The protocol needs keys,

   Security Manager --> --> --> --> --> --> --> --> --> --> --> Network
                                   Permissions
                                   Secure Start-ups
                                   Compromise recovery

                    Figure 1:  Security Management View

public and private, to operate. It also has to have identity information for the host it will act on behalf of 🦋.

There are lifecycle and security concerns with the software while it's in transit, stored, distributed, and installed 😭. A one-time start-up procedure must verify the identity of the host. Procedural and physical identification techniques will do this, like Armed Forces Courier Service (ARFCS) accounting or registered mail 📬. When a key gets delivered, the security manager logs its receipt and takes responsibility for that key.

After the software is properly installed, a paper trail verifies the recipient 📝. The computer starts an association with the security management function to initialize the protocol software. That means creating a unique public and private key pair for network operation and receiving network permissions. This activation uses keys distributed with the software (only good for initialization) to secure an exchange with the security manager 🔐. Then the host creates its own unique public and private pair and sends the public key to the security manager. The security manager creates a credential that uniquely identifies the host and its permissions. That credential is signed by security management with its private key, and every net member can verify it with the public key ✨.

Permission management Each host on the network gets a permissions certificate signed by security management. It uniquely identifies that host and states which access permissions it's allowed. Hosts use these permission certificates to assign permissions to other hosts 🤝.

This process assigns permissions to equipment or human beings based on their duties. It involves security clearances and human judgment, so it's outside the scope of this protocol 🙅.

The security management function, especially in military operations, is responsible for managing permissions and classifications at each host. In the commercial world, permission management lines up with projects or duties 💼.

Compromise recovery management If a group member is found compromised, the protocol must make it possible to exclude that member and get back to secure operations 🚨. The security management function provides control of compromise recovery.

Usually, physical inspections or accounting techniques find compromises. Those separate systems report the compromise to the key management system. We have to assume that all keys resident at that host are lost 💀. The security management function rescinds the permission allocated to the compromised host. Then we create a list of all known compromised hosts and distribute that list across the network. Each host is then responsible for reviewing the propriety of each association and enforcing access control to data 🛡️.

3.1.2 Group management 🎀

The group manager works with other management functions in the network to provide the GKMP with group membership lists and group-relevant commands. The GKMP deals strictly with cryptographic keys. It relies on external communication and network management services to supply network-related information. Mainly, it relies on the network management service to provide the addresses of group members (if the group is sender initiated).

The GKMP lets an external entity determine the controller of a group. The controller should be able to handle the extra processing and communication requirements that come with the role. If that's not a necessary function given the implementation, the controller assignment can be set to some automated default. Even when it's defaulted, though, some external management entity still decides how the controller role gets allocated 🧚.

The group manager can receive group progress reports from the group controller. The GKMP provides a service for the network, so it makes sense that someone in the network is curious about how it's going 👀. The GKMP can provide progress reports. It's up to network management to determine the manner and recipient of those reports. Refer to Figure 2 for network manager interaction 📊.

   Group Manager --> --> --> --> --> --> --> --> -->Network Manager
           /\
           |
           |       Commands, Role assignments
           |       Group member list, Reports
           |
           \/
   {[Group Controller]     Network}

                  Figure 2:  Network Manager Interaction

Group to member mapping When the GKMP is implemented in sender initiated group establishment mode, a list of group member addresses must be provided as part of the group establishment command. The GKMP uses these addresses to contact the group members and create the group 🌸.

Creating a group involves assigning a group address, updating router databases, and distributing that group address to the group members. This is a classic network management function. The GKMP group controller would be another recipient of this information 💜.

Protocol role allocation The Group Management Protocol assigns roles to members of a particular group. These roles are binary: you're either the control over the group or a member of the group. Some external entity allocates the identity of the group controller and group receiver. This is a desirable aspect because some computers are more capable (like a central site with a ton of processing power for controlling a group) 💪. We let an external entity allocate these roles to individual group members. This is important in military applications, because in a commercial application the allocating authority and the group controller may very well always be the same 🏢.

Group key progress reporting The Group Key Management Protocol has to be able to report to somebody 📣. If we create a group, we should report it to the group requester. Conversely, if we are not able to

   Network = {[(Group 1 controller) Group 1 members],
   [(Group 2 controller) Group 2 members],
   [(Group 3 controller) Group 3 members], }

                  Figure 3:  Distributed Group Management

create a group, we should report that, especially since failure to create a group (at least as a first study) will highly correlate with a failure of the underlying communications. The Group Key Management Protocol doesn't have the ability to fix the underlying communications, so the communication management function must deal with these failures 🔧.

3.2 Protocol Roles 🎭

Creating and distributing a grouped key requires assigning roles. These identify what functions each individual host performs in the protocol. The two primary roles are controller and receiver. The controller initiates the creation of the key, forms the key distribution messages, and collects acknowledgments of key receipt from the receivers. The receivers wait for a distribution message, decrypt it, validate it, and acknowledge receipt of the new key 🔑.

One of the essential concepts behind the GKMP is delegation of group control 👑. Since each host in the network has the capability to act as a group controller, the processing and communication requirements of controlling the groups in the network can be distributed equitably throughout the network. That avoids potential single points of failure, communication congestion, and processor overloading. Refer to Figure 3 for distributed group management.

3.2.1 Group controller

The group controller is the group member with authority to perform critical protocol actions (i.e., creating a key, distributing a key, creating group rekey messages, and reporting on the progress of these actions) 👸. All group members have the capability to be a group controller and could assume this duty upon assignment.

The group controller helps the cryptographic group reach and maintain key synchronization. A group must operate on the same symmetric cryptographic key. If part of the group loses or inappropriately changes its key, it won't be able to send or receive data with another host operating on the correct key 😱. Therefore, it is important that the operations that create or change keys are unambiguous and controlled. It would not be appropriate for multiple hosts to try to rekey a net at the same time 🙅.

3.2.2 Group receiver

Simply put, a group receiver is any group member who is not acting as the controller 🙋. Group receivers will assist the controller in creating keys, validate the controller's authorization to perform actions, accept keys from the controller, request keys from the controller, maintain local CRL lists, perform peer review of key management actions, and manage local keys 💖.

3.3 Scenarios 🌈

3.3.1 Group establishment ✨

Okay so making a group where a bunch of hosts all share one cryptographic key is a whole production 💅 The protocol has to whip up a high quality key, check that every intended recipient actually has permission to join, hand the key out to all the qualified members, and report on how it's going 📣 It happens in two phases: creating the key, and then distributing it. Peep figure 4 below 🦋

The group establishment process goes like this. First, a "create group" command gets issued to the group commander. The group controller checks that the command really came from an authorized commander and that the group is within the controller's permission range 🫶 Next, the controller makes a key. Then that key gets passed to the group members, but only after they pass the peer to peer review process 🔍

   Group Controller
           |
           |
           \/      Create group keys
           |--> --> --> --> --> --> -->Group member
           |
           |
           \/      Distribute keys
           |--> --> --> --> --> --> --> Group member
           |
           |
           \/      Distribute keys
           |--> --> --> --> --> --> --> Group member
           |
           |
           \/      Distribute keys
           |--> --> --> --> --> --> --> Group member

                      Figure 4:  Group Establishment

Validate command The create group command is signed by the group commander (they may be the same device). This signature should be asymmetric in nature. The public key to validate this command can be sent with the command itself, if the public bound to the identity of the commander.

The group controller receives the command and verifies the signature. That check is what makes sure the message was sent by the claimed source and that nobody messed with it in transit 🕵️‍♀️

Creation of group keys The controller starts the creation of two keys for use in the group. A cryptographic key has to be sufficiently random, and that's the whole ballgame 🎲 Randomizers that can make high grade cryptographic keys tend to be hardware based, and they're not likely to be practical for this protocol. There are several established key creation protocols based in software (e.g., Diffe-Hellman, FireFly, RSA). All of these software based algorithms involve two hosts cooperating to create a cryptographic key, and these software algorithms are more appropriate for this protocol 💖

Also super important when making these keys is verifying the authorization of the key creation partner. Being authorized to possess the keys includes permissions that equal or exceed the group traffic and identity verification 👑

Distribution of group keys The controller distributes the group keys to the net members. The controller must verify the identity and permissions of each member before the key gets distributed 🛡️

                           Rekey Group
   Group Controller --> --> --> --> --> -->{Group (group member 1-n)}


                          Figure 5:  Group Rekey

Likewise, the net member must verify the controller's identity, its authorization to perform this action, and its permissions. Both sides check each other, bestie 🤝

The key being distributed is the same level as the data it will encrypt. Hence, we must encrypt the key during distribution 🔐 If no suitable key exists between the controller and member, a new key must be created. This new key is cooperatively created between the controller and net member in a similar manner as the net keys.

The controller creates a message for encryption in the key held between the controller and member. This message will include key management information and the keys 🍓

3.3.2 Group rekey ✨

A cryptographic key has a life span, and the new key must replace the "old" key before the end of its cryptographic life ⏳ This process is rekey 🔁

Rekey has the advantage of using an existing cryptographic association to distribute the key. Also, there is no requirement to verify the identity and authorization of the other members. Identity and authorization are assumed 🧚

A group rekey consists of two stages. First, the Group Controller creates new group keys. Second, these "new" keys are sent to the Group Members in a multicast message. Refer to figure 5: Group Rekey 🌈

Creation of group keys The controller of the rekey creates the new keys in exactly the same manner as used during group establishment.

Distribution of group keys The GKMP creates a message for the group address. This message uses one of the keys distributed during group establishment to encrypt the new keys. It also contains an authorization token identifying the controller as the rekey agent, plus new management data. All members of the group using a multicast protocol (if one exists) accept this message 📬

The message that rekeys the group encrypts the new keys in the existing KEK. Since all group members possess the KEK, the entire group can decrypt this message 🎀

The token authorizing the group controller to perform this rekey is also included. This token is asymmetrically signed by the group commander. It uniquely identifies the group controller's authority to rekey this group, and it also identifies the group, the level of traffic, and the rekey interval 💜

3.3.3 Deletion ✨

It's desirable to be able to delete group members, either for administrative purposes or for security reasons 🗑️ Administrative deletion is the deletion of a trusted group member, and it's possible to confirm the deletion of trusted group members. Security relevant deletion is the deletion of an untrusted member. It assumes that the member is ignoring all deletion commands 🙈

Administrative delete Administrative deletion removes the group keys from trusted group members. This deletion consists of two messages. The first sends a command to the group, encrypted in the group's TEK. The command essentially says: acknowledge receipt and then delete group keys. This command is signed by the group controller to prevent unauthorized deletions 🔏

The acknowledgment message is also encrypted under the group TEK and is sent to acknowledge receipt of the command. We could acknowledge accomplishment of the command if the net is willing to accept the burden of creating pairwise keys between the exiting group members and the group controller 🤔

Compromise recovery Compromise recovery is the deletion of untrusted group members. This actually involves creating an entirely new group, without the untrusted member. Once the new group is created, net operations can be shifted to the new group, which effectively denies the untrusted member access to the data 💀

There is always a trade-off between security and continued net operations when a member is found to be compromised. The security first position states that if a member is compromised, the group must be destroyed and then a new secure group created. However, operational concerns sometimes outweigh the security concerns. The operational position is that the group will continue to operate with the compromised member and will shift to a new secure group when it becomes available 😭

The GKMP does not mandate either position. However, the speed and flexibility of the GKMP does allow a new secure group to be created quickly, thereby restricting the potential damage done by a compromised member ⚡

Once a member is found to be compromised, that member's certificate is added to a Certificate Revocation List (CRL). The CRL is an asymmetrically signed piece of data, signed by a security manager. The list is made up of compromised resource IDs, a version of the CRL, and perhaps an identifier of the security manager. The CRL is accessed every time a new key is negotiated. If one of the key creators is on the CRL, the key is destroyed and the interaction is terminated 🚫

The idea behind a CRL is that each host would keep records of all open associations and compromised resources. The host would then make sure that it does not have, and will not create, a secure association with anyone who is on the CRL. The CRL concept becomes more complicated in the case of groups. This is because it is not necessary for every member of the group to know who the other group members are. Hence, a group member does not have sufficient information to identify compromised group associations. The GKMP proposes that the group controllers be responsible for reviewing the CRL and taking appropriate actions should a group member be compromised 🧐

Another issue with CRLs is the speed at which they can be distributed across a network. Every time a key is created, the cooperating hosts exchange the version number of their current CRL. If the versions do not match, the most current version is passed to the host with the old version. Hence, CRLs propagate when keys are created. If this happens infrequently and there is a single CRL insertion point, the list may take a few days to move across the net 🐢 The GKMP allows a speedier distribution of the CRL 🚀

The GKMP delegates control of groups to specific group controllers (a subset of the network). These controllers are responsible for maintaining the security of the group. If quicker distribution of the CRL were desired, the CRL generator (security management function) could seed the CRL at these controllers. Controllers are points of key management activity and are logical CRL staging areas 🏰

4 Issues ✨

What are the unresolved issues with this protocol? 🤷‍♀️

4.1 Access Control

One interesting issue with a grouped key protocol is access control. This is because we are moving away from having humans in the loop or having a central authority check the propriety of the group 👀

The group protocol must police itself. It must ensure that each member of a group meets the classic military access control policy (i.e., a group member's classification level must be higher or equal to the classification of the group that it's in) 🎖️

Is allocation of permissions by a higher authority sufficient to provide access control? Or is a more discretionary mechanism necessary? 🤔

4.2 MLS

A GKMP must be capable of operating in a multi-level secure environment. The integration of a key management protocol capable of creating keys of several different classifications with an operating system capable of operating with multiple classifications is non-trivial 🧩

Classified label standards need to be incorporated. The classification labels used by the key management protocol should coincide with the labels used by the MLS operating system. These interoperability issues need to be addressed 💅

4.3 Error Conditions ✨

okay so group protocols are way more complicated than pairwise ones 😭 With pairwise you've only got two parties who need to talk to each other, so it's pretty doable to plan for every possible error. With a group, things can go sideways in so many more ways 💀

One assumption you have to make with any group protocol is that the underlying internet is, to some degree, always kind of broken 🙈 Protocol designers have to assume messages can get delayed or destroyed in transit, that not every member will receive every multicast message, and that acknowledgments of actions might never be delivered. This matters a lot if the protocol uses multicast to speed things up 🚀

The protocol needs recovery mechanisms so group members can recover from lost messages 🫶 And that recovery has to be transparent to the host and to the underlying communications network.

For example, it's an open question whether we can create an application-layer acknowledgment for multicast actions 🤔 The problem is the bandwidth those acknowledgments would eat up. It may be way friendlier to the underlying communications systems if each member spots potential errors and corrects them in a pairwise manner. Handling error conditions in a key management protocol is doubly difficult 😤 because lots of error conditions can be induced by a third party trying to break the system's security. They might try to grab a key that's in transit, or block a key from being successfully disseminated, which attacks the security mechanism itself.

4.4 Commercial vs. Military 👑

Commercial and military key management are different in a bunch of ways. Commercial key management protocols tend to emphasize interoperability, freedom of action, and performance. Military systems tend to emphasize security and control of operations 🔐

There's also a difference in cryptographic algorithms. A military protocol would certainly use high-grade encryption to protect classified information. A commercial system would probably use algorithms and techniques certified for unclassified communication systems. The main difference is in algorithm length and type.

A military protocol would require more management and structure than a commercial one. The military has always adopted a hierarchical communication structure, while the commercial system, especially if you look at the internet, works mainly in an anarchist style 💅

4.4.1 Algorithm Type

Another difference between military and commercial key management is the type of cryptographic algorithms. The commercial world uses encryption algorithms like DES and, in the future, Skipjack 🧚 The military uses other cryptographic algorithms that differ in key length and have more restrictions. An example is ACCORDION, identified as a military key encryption algorithm used in the EKMS program run by NSA 🕵️

Any experiments with a grouped key management protocol must consider the differences between military and commercial algorithms. Commercial algorithms tend to be quicker to implement, run faster, involve less processing time, and allow an unclassified experiment. However, we must be careful not to paint an unrealistic picture of the protocol's performance based on these commercial algorithms 🙃 A military algorithm tends to be more cumbersome, slow to process, and require more bandwidth. It has a lot of unpleasant characteristics from the commercial standpoint, but it allows a higher grade of cryptographic security. One way of dealing with the disparity between algorithms is to use the commercial cryptographic algorithms, leave the fields the size used by a comparable DoD cryptographic algorithm, and insert delays to simulate DoD algorithm processing times ⏳

4.4.2 Management Philosophy

Management for a military network is far more structured than for a commercial network. A military network would restrict the creation of network groups, the rekeying of those groups, and access to the data contained in those groups 🪖 In contrast, the commercial world would enable any member of the network to create a group and allow any other member of the net to join that group 🌈

The group Key Management Protocol must allow for both of these architectures, i.e., both a very structured command and control hierarchy and free-form group creation 💜

4.5 Receiver Initiated Operations

How do they actually work? What are the performance trades? What experimentation is needed? 🧪

Who is the group leader? 👀

How do we elect a new leader? 🗳️

Will multiple leaders be created? 🤷‍♀️

Will rule-based access control allow fine enough access discretion? 🎀

Methods for distributed GKP/GRP dissemination need to be examined. This includes:

resolving group identification issues, such as how to notify potential members of membership requirements without compromising any security-relevant information about the group;
approaches for rapidly identifying GKP/GRP sources must be developed, such as a "Key ARP" whereby a new member broadcasts into the group a request for key service and existing members resolve which will provide service; and,
security effects of distributing access control decisions must also be reviewed.

5 Security Considerations 🔐

okay this whole document is about security, period 💀 Every single section is giving security, so this one is the entire vibe 🫶

6 Addresses of Authors 🦋

Hugh Harney
SPARTA, Inc.
Secure Systems Engineering Division
9861 Broken Land Parkway, Suite 300
Columbia, MD 21046-1170
United States
telephone:        +1 410 381 9400 (ext.  203)
electronic mail:  hh@columbia.sparta.com



Carl Muckenhirn
SPARTA, Inc.
Secure Systems Engineering Division
9861 Broken Land Parkway, Suite 300
Columbia, MD 21046-1170
United States
telephone:        +1 410 381 9400 (ext.  208)
electronic mail:  cfm@columbia.sparta.com

📦 where this page comes from

ietf: rfc2094 1997-07
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms