RFC 2093

Group Key Management Protocol (GKMP) Specification 🎀

Network Working Group 💖 RFC 2093 ✨ Authors: H. Harney and C. Muckenhirn, from SPARTA, Inc. 🧚 Category: Experimental 🧪 Date: July 1997 📅 Obsoletes / Updates: The header doesn't list anything this RFC obsoletes or updates, so there's nothing to report there 🫶

---

Status of This Memo 📜

okay so this memo defines an Experimental Protocol for the Internet community 🔬. It is not an Internet standard of any kind, so please don't treat it like one 🙈. They're asking for discussion and suggestions for improvement, and distribution is unlimited 💌.

Table of Contents 🗂️

   1. Background..................................................... 1
   2. Overview:  GKMP Roles.......................................... 3
   3. Data Item primitives........................................... 4
   4. Message definitions............................................ 6
   5. State definitions.............................................. 9
   6. Functional Definitions--Group Key Management Protocol.......... 13
   7. Security Considerations........................................ 23
   8. Author's Address............................................... 23

Abstract ✨

bestie, this one is the whole pitch 💅. The protocol creates grouped symmetric keys and distributes them to communicating peers 🔑. Here's why it's iconic:

1. It's virtually invisible to the operator 👀.
2. No central key distribution site is needed 🙌.
3. Only group members have the key 🔐.
4. It works in sender oriented or receiver oriented operation 🔄.
5. It can make use of multicast communications protocols 📡.

1 Background 🕰️

so traditional key management was basically copying the military's paper-based key accounting system 📄. Keys were physically distributed, ordered, and accounted for, which meant huge lead times and expensive operations 😩.

Then came cooperative key management algorithms, which let two pieces of equipment generate pairwise keys between themselves 🤝. That's way quicker and more reliable, and it can support a large number of secure communications ✨. The catch? Right now these methods only support pairwise keys 😭.

So this document describes a protocol for establishing and rekeying groups of cryptographic keys (more than two) on the Internet 🌐. We call it the Group Key Management Protocol (GKMP) 💜.

1.1 Protocol Overview 🌸

the GKMP creates keys for cryptographic groups, distributes those keys to the group members, and uses peer to peer reviews to enforce rule based access control of keys 🛡️. It also denies access to known compromised hosts and allows hierarchical control of group actions 👑.

The key generation concept is cooperative generation between two protocol entities 🤍. Several key generation algorithms are viable for the GKMP, including RSA, Diffie-Hellman, and elliptic curves 🧮. All of them use asymmetric key technology to pass information between two entities so they can create a single cryptographic key 🗝️.

Then the GKMP distributes the group keys to qualified GKMP entities 🎁. This is a mutually suspicious process, which means all actions and identities must be verified 🕵️‍♀️. Very healthy boundaries, honestly 💅.

The GKMP also has a peer to peer review process 🔍. Protocol entities pass permission certificates (PC) as part of group key distribution 📜. A PC holds access control information about a particular site, and a higher authority assigns that information and signs the PC ✍️. So each entity can verify the permissions of any other GKMP entity, but can't modify any of them 🙅‍♀️. Each protocol entity compares the permissions against the level of service requested 📏. If the permissions don't exceed or equal the request, the service is denied 🚫.

The GKMP supports compromise recovery 🩹. A Compromise Recovery List (CRL) of compromised GKMP entities gets distributed to group members during key management actions 📣. That lets group members drop connections with compromised entities, which is a whole main character move 🎬. The GKMP delegates control of groups to specific group controllers, so it's easier to distribute the CRL to the most important GKMP entities 🎯. During each key management action the CRL version number is passed along. When a CRL update is detected, it gets downloaded and verified, because it's signed by a higher authority 🔏.

The GKMP also allows control of group actions 🎛️. In some networks, a higher authority needs to strictly control how groups get generated, and those networks usually have a central network operations authority 🏢. The GKMP lets that authority remotely order group actions 📨. Those orders are signed by the authority and verified by every entity involved with the group ✅.

The GKMP is an application layer protocol and it doesn't depend on the underlying communication protocol 🧁. But if multicast service is available, it speeds up rekeying of the cryptographic groups 🚀. So the GKMP does use multicast services when they're available 💫.

2 Overview: GKMP Roles 🎭

okay so creating and distributing group keys means assigning roles 🧩. Roles identify what functions each host performs in the protocol. The two primary roles are key distributor and member 💖. The controller starts the creation of the key, forms the key distribution messages, and collects acknowledgments of key receipt from the receivers 📬. The members wait for a distribution message, then decrypt, validate, and acknowledge receipt of the new key 🥰.

2.1 Group controller 👑

The group controller (GC) is the group member with the authority to perform critical protocol actions 🔑. Those include creating key, distributing key, creating group rekey messages, and reporting on the progress of these actions 📊. Every group member has the capability to be a GC and could take on that duty once assigned 🌟.

The GC helps the cryptographic group reach and maintain key synchronization 🔄. A group has to operate on the same symmetric cryptographic key 🗝️. If part of the group loses or inappropriately changes its key, it can't send or receive data with another host that's on the correct key 😬. So the operations that create or change keys need to be unambiguous and controlled 🎀. It wouldn't make sense for multiple hosts to try rekeying a net at the same time 🙅‍♀️. That's why someone has to be in charge, and that someone is the controller 👸.

2.2 Group member 🫶

Simply put, a group member is any group host that isn't acting as the controller 🌷. Members assist the controller in creating key 🧑‍🤝‍🧑. They validate the controller's authorization to perform actions ✅. They accept key from the controller, request key from the controller, maintain local CRL lists, perform peer review of key management actions, and manage local key 🗂️.

3 Data Item primitives 🧱

3.1 Group members list: 📋

In a sender oriented group, the GC must be given a list of net members 📝. The controller then initiates contact with those net members and creates the group 🎉.

3.2 Group Token: 🎟️

The group token is created by the authority that commands a group 👑. The token holds the information net members need to confirm that a controller is authorized to create a group. It also says exactly what constraints are intended to be placed on the group 🔒. The group token contains the following fields:

• Group identification,
• GC ID,
• Group action (create, rekey, delete),
• Group permissions (rules to guide access control),
• Rekey interval (life span of group key),
• Token version (identifier to identify current token),
• Token signature (asymmetric signature using the group commanders private key),
• Group commanders public key (this public key is itself signed by the network security manager to bind the public to a specific net member ID).

3.3 Grp ID: 🆔

The group must be uniquely identified so several different groups can coexist on a network 🌈.

3.4 GTEK ID: 🏷️

This is the unique identifier of a GTEK, and it can include state information 💜.

3.5 GKEK ID: 🏷️

This is the unique identifier of a GKEK, and it can include state information 💜.

3.6 GTEK creation field: 🧪

In a cooperative key creation protocol, each party contributes a field that's used to create the key 🤝.

3.7 GKEK creation field: 🧪

In a cooperative key creation protocol, each party contributes a field that's used to create the key 🤝.

3.8 Distributor signature: ✍️

This is an asymmetric signature made using the GC's private key 🔏.

3.9 Distributor public key: 🔓

This is the public half of the GC's signature key pair. (This public key is itself signed by the network security manager to bind the public key to a specific net member ID.) 🔗

3.10 Member signature: ✍️

This is an asymmetric signature made using the selected member's private key 🔏.

3.11 Member public: 🔓

This is the public half of the selected member's signature key pair. (This public key is itself signed by the network security manager to bind the public key to a specific net member ID.) 🔗

3.12 Controller permissions: 🛂

Controller permissions are assigned by the security manager 🏛️. The security manager's signature binds the permissions to the controller ID 💖.

3.13 SKEK ID: 🆔

This field identifies exactly which SKEK is being created 🎯. That lets multiple groups interoperate on a net at the same time 🌸.

3.14 SKEK creation field: 🧪

This field contains the information contributed for use in the KEK creation process 🤝.

3.15 Member permissions: 🛂

Member permissions are assigned by the security manager 🏛️. The security manager's signature binds the permissions to the controller ID 💖. (Yes, the original says controller ID here too 👀.)

3.16 Encrypted Grp Keys: 🔐

This data item is encrypted in the KEK (session or group) created for the download of keys 📥. It carries the GTEK and GKEK created for a group, and a checksum is encrypted along with them 🧾. That way the confidentiality and data integrity of the GTEK and GKEK are both protected 🛡️.

3.17 Confirmation of decryption: ✅

This is a short (byte) field that indicates the message was decrypted and exactly what type of message it was 🎀.

3.18 Request: 🙋‍♀️

A request field holds the specific request one net member can make to another 💬. Requests range from group join, CRL update, pairwise TEK generation, detection, group creation, and status 🌈.

Member delete list:

This is a list of group members being administratively deleted from the group 🚪.

4 Message definitions 📨

4.1 Command_Create Group: 📣

This message contains the following data item primitives: Group members, Grp ID, Grp controller ID, Grp action, Grp permissions, Rekey interval, Token version, Token signature, and Token public key 🧾. It may be confidential because of the group permissions field 🙈. In sensitive systems, it will need encryption before transmission 🔒.

4.2 Create Grp Keys_1: 🗝️

This message passes the information needed to create the group keys from the GC to the selected net member 💌. It contains: Grp ID, Request, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, Grp token, Controller signature, and Controller public 📦.

4.3 Create Grp Keys_2: 🗝️

This message passes the information needed to create the group keys from the selected net member back to the GC 💞. It contains: Grp ID, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, member signature, and member public 📦.

4.4 Negotiate Grp Keys_1: 🤫

This message passes the group token and the GC's permissions to the selected net member 🎟️. That information can be sensitive and needs protecting, so this message is encrypted in the GTEK that was just created 🔐. The encryption includes the appropriate data integrity checks too 🛡️. This message1 contains: Grp ID, TEK ID, KEK ID, Group token, and Controller permissions 💅.

4.5 Negotiate Grp Keys_2: 🎀

okay so this message is how the selected net member's permissions get passed over to the GC 🫶 it carries the Grp ID, GTEK ID, GKEK ID, and Member permissions. ngl these permissions are sensitive info, so we're protecting them. that's why the whole message gets encrypted in the GTEK that was just created, and the encryption comes with the proper data integrity checks 🔒✨

4.6 Create Session KEK_1: 🦋

this one is giving "let's make a KEK for one time use." it sends the info needed to create that KEK between the GC and the selected net member 💜

4.7 Create Session KEK_2: 🌸

same vibe as 4.6 but flipped 🙃 this message sends the info to create a one time use KEK between the selected net member and the GC 💅

4.8 Negotiate Session Keys_1: 👑

this message is the main character 💖 it passes the group ID, SKEK ID, CRL version number, Group token, and GCs permissions over to the selected net member. all of that is sensitive, so it has to be protected 🫣 that's why it gets encrypted. if there's an appropriate pairwise key already available, that key should be used. if not, the KEK we just made could be used to encrypt the message instead 🧚

4.9 Negotiate Session Keys_2: 🍓

this one identifies the group, the SKEK, the CRL version number, and the member permissions. it can also be sensitive, so it needs protection too 🛡️💕

4.10 Download Grp Keys: 🌈

this message carries a GRP ID and the Encrypted Grp Keys data items ✨

4.11 Key download ack: 🫶

this is the receipt 🧾 it contains the GRP ID and the Confirmation_decryption data items. it confirms that the GTEK and GKEK were received and verified as decrypted. no cap, very important 💯

4.12 Rekey _Multicast: 💜

this message holds the Grp ID, GTEK ID, GKEK ID, Group token, and Controller permissions 🔑 the rekey message gets encrypted in the GKEK that's already sitting in all the group member sites. that means one single message can be accepted by every group member at once 🌟 iconic efficiency

4.13 Request_Group_Join: 🦋

this message contains Request, Grp ID, Member Signature, and Member Public 🎀

4.14 Delete_Group_Keys: 💀

this message contains grp ID, Request, Member delete list, Controller signature, and Controllers public 🗑️

4.15 Grp_Keys_Deleted_Ack: ✨

this message contains (grp ID, member ID, member signature, member public. 🙈

4.16 Delete_Group_Keys: 💀

this message contains (grp ID, request, member delete list, controller signature, controller public). it's a repeat of 4.14 with lowercase vibes 💅

4.17 Grp_Keys_Deleted_Ack: ✨

this message contains (grp ID, member ID, member signature, member public) 🌸 same as 4.15, just the mirror image 🪞

---

5 State definitions 🧠

there are thirteen separate states in the protocol. here's the breakdown, bestie 💖

5.1 State 1: 🌷

• the source address is checked to make sure it's not on the CRL 🚫
• the token field gets validated with the public key of the source 🔑
• the token version number is checked to make sure this token is current ⏰
• the group ID is checked to see if this group exists 🔍
• the controller ID field is then read. if the receiver is listed as the GC, the receiver takes on the role of controller 👑. if not, the role assumed is that of receiver
• the GC reads the group permission field in the group token. then it verifies that its personnel permissions exceed or equal those of the group 💪
• the GC creates its portion of the key creation message 🧩
• the Create Grp Keys_1 message is completed and transmitted 📨 slay

5.2 State 2: 🦢

• the source signature field is validated using the public key of the source ✍️
• the source ID field is compared against the local CRL. if the source is on the CRL, the association is terminated ❌
• the request field is read. the local contributions to the group keys are created 🧁
• the group keys are created and stored pending negotiation 📦
• the key table is updated to show the group key pending negotiation 📝

5.3 State 3: 🌺

• the permission certificate is retrieved and validated using the security managers public key. the permissions of the message source are checked to verify they meet or exceed those of the group 🛂
• the group token is retrieved and validated using the appropriate public key 🔐
• the token version number is checked to make sure the token is current ⏰
• the group ID specified in the token is compared with the actual group ID. if they're different, the exchange is terminated 🚪
• the controller ID specified in the token is compared with the GC ID. if they don't match, the exchange is terminated 🙅‍♀️
• the local permissions are compared to the permissions specified for the group. if they don't meet or exceed the group permissions, the exchange is terminated and a report is generated 📋
• the rekey interval specified in the token is stored locally ⏱️
• the key table is updated to reflect the key permissions, rekey interval, group ID, and current time 🗂️

5.4 State 4: 🍑

• the permission certificate is retrieved and validated using the security members public key. the permissions of the message source are checked to verify they meet or exceed those of the group 🛂
• the key table is updated to reflect the key permissions, rekey interval, group ID, and current time 🗂️

5.5 State 5: 🌙

• the source signature field is validated using the public key of the source ✍️
• the source ID field is compared against the local CRL. if the source is on the CRL, the association is terminated ❌
• the request field is read. the local contribution to the SKEK is created. the SKEK is created and stored pending negotiation 🥡
• the key table is updated to show the SKEK pending negotiation 📝

5.6 State 6: 🫧

• the permission certificate is retrieved and validated using the security managers public key. the permissions of the message source are checked to verify they meet or exceed those of the group 🛂
• the group token is retrieved and validated using the appropriate public key 🔐
• the token version number is checked to make sure the token is current ⏰
• the group ID specified in the token is stored 💾
• the controller ID specified in the token is compared with the GC ID. if they don't match, the exchange is terminated 🙅‍♀️
• the local permissions are compared to the permissions specified for the group. if they don't meet or exceed the group permissions, the exchange is terminated and a report is generated 📋
• the rekey interval specified in the token is stored locally ⏱️
• the key table is updated to reflect the key permissions, rekey interval, group ID, and current time 🗂️

5.7 State 7: 🌼

• the permission certificate is retrieved and validated using the security managers public key. the permissions of the message source are checked to verify they meet or exceed those of the group 🛂
• the key table is updated 🗂️

5.8 State 8: 🦄

• the group ID is checked 🔍
• the group keys are decrypted using the SKEK. data integrity checks are validated to make sure decryption went right ✅
• the key table is updated to reflect the new group keys, key permissions, rekey interval, group ID, and current time 🗂️

5.9 State 9: 📚

• update the group management log 📖

5.10 State 10: 🌟

• the permission certificate is retrieved and validated using the security managers public key. the permissions of the message source are checked to verify they meet or exceed those of the group 🛂
• the group token is retrieved and validated using the appropriate public key 🔐
• the token version number is checked to make sure the token is current ⏰
• the group ID specified in the token is checked 🔍
• the controller ID specified in the token is compared with the GC ID. if they don't match, the exchange is terminated 🙅‍♀️
• the local permissions are compared to the permissions specified for the group. if they don't meet or exceed the group permissions, the exchange is terminated and a report is generated 📋
• the rekey interval specified in the token is stored locally ⏱️
• the new group keys are decrypted with the current GKEK. the data integrity field is checked to make sure decryption went right ✅
• the key table is updated to reflect the key permissions, rekey interval, group ID, and current time 🗂️

5.11 State 11: 🎠

• validate the signature using the source's public key ✍️
• check to see if a member initiated group join is available. if not, ignore it. if so, begin distribution of group keys 🚀

5.12 State 12: 🧸

• validate the signature using the GCs public key ✍️
• retrieve the delete list. check to see if you're on it. if so, continue 📜
• create Grp_Keys_Deleted_Ack 📨
• delete the group keys 🗑️

5.13 State 13: 💫

• validate the signature using the GCs public key ✍️
• retrieve the delete list. if the list is a global delete, verify the alternative key 🔎
• switch group operations to the alternative key 🔁
• create Grp_Keys_Deleted_Ack 📨
• delete the group keys 🗑️

---

6 Functional Definitions--Group Key Management Protocol 🦋

the GKMP is made up of multiple functions that work together to create, distribute, rekey, and manage groups of symmetric keys 🔑 these functions are:

• Group creation (sender initiated group)
  • Create Group keys
  • Distribute Group keys
• Group rekey
  • Create Group keys
  • Rekey Group
• Member initiated join
• Group member delete

the following sections describe each function, including the data primitives and message constructs. the associated diagrams show the specifics (sequence, location, and communication sources and destinations) of the messages and processes needed 🗺️

6.1 Group creation 🌈

member initialization is a three-step function 🪜 it involves commanding the creation of the group, creating the group keys, and then distributing those keys to "other" group members 💌 messages between the GC and the first member generate two keys for future group actions: the group traffic encryption key (GTEK) and the group key encryption key (GKEK) 🔐 messages between the GC and the other members are for distributing the keys. these functions are described in the following sections ✨

6.1.1 Group command 📣

the very first action is for some entity to command the group. this command is sent to the GC 👑

6.1.2 Create group keys ✨

Okay so the first member has to team up with the GC to make the future group keys 🔑 Bestie, using two separate hosts is the move because it gives the best odds that the final key ends up with the right cryptographic properties 💅 One host could make the key solo IF its randomization function were robust AND trusted, but that usually needs specialized hardware that most host sites don't have 🙈 This protocol was built to run on generic hardware so it stays extendable, which is why cooperative key generation is the way 🫶

To keep group creation organized, the controller and the group members have to pass management info back and forth 📜 That info covers the GC's identity, its permissions, its authorization to create keys, the future group's permissions, the current state of the compromise list, and management info about the keys being made. All of it is protected from forgery with asymmetric signature tech 🔐 The public key for verifying net-wide parameters (like individual host permissions) is widely held. The public key for verifying locally generated info (like peer identity) gets sent along with the messages, so hosts don't have to store as many keys 🧚

The goals of the key creation process are:

• cooperatively generate a GTEK and GKEK,
• allow the key creators to verify the identity of the key creation partner by verifying the messages' signatures,
• share public keys,
• allow validation of the GC, by signing the group identification, GC identification, and group permissions,
• send the group identity, GC identity, group member identities, group permissions, and group rekey interval to the first member, signed by the group commander (when the group was remotely commanded).

This function is four messages between the GC and the first member 💜 First up, the GC sends a signed Create_Group_Keys_1 message to the first member. It carries two random values needed to generate the GTEK and GKEK, plus the GC's public key 🎀

The first member checks the signed Create_Group_Keys_1 message, then builds and sends a signed Create_Group_Keys_2 message back to the GC. They generate the GTEK and GKEK and store the GC's public key. The Create_Group_Keys_2 message holds the random values the GC needs to generate the GTEK and GKEK, plus the first member's public key ✨

The GC validates the signed Create_Group_Keys_2 message, generates the GTEK and GKEK, builds the Negotiate_Group_Keys_1 message for the first member, and stores the received public key 🌈

The GC sends the Negotiate_Group_Keys_1 message to the first member encrypted in the GTEK that was just generated 🔐

|___Net_Controller___|__________Messages__________|____Net_Member_B____|
|The Create Group    |<---- Command-Create Group  |                    |
|command is          |                            |                    |
|received by net     |                            |                    |
|member A.           |                            |                    |
|State 1             |                            |                    |
|                    |Create Grp Keys_1---->      |                    |
|                    |                            |State 2             |
|                    |<-----Create Grp Keys_2     |                    |
|State 2             |                            |                    |
|                    |Negotiate Grp Keys_1------> |                    |
|                    |                            |State 3             |
|                    |<-----Negotiate Grp Keys_2  |                    |
|State 4             |                            |                    |
              Figure 1:  State Diagram:  Create Group Keys

The first member decrypts the Negotiate_Group_Keys_1 message and pulls out the group identification, GC identification, group members, group permissions, key rekey interval, CRL version number, and certifying authority signature 🧾 The group identification, GC identification, and group permissions fields get checked against the group commander's signature (if the group was remotely commanded, that signature identifies the remote host). If everything checks out, the first member's internal structures get updated 💖

6.1.3 Distributing Group Keys to Other Members 💌

The other group members have to get the group keys before the group is fully operational, and this step is what makes that happen 🦋 It does four jobs:

• cooperatively generate a session key encryption key (SKEK) for the transmission of the GTEK and GKEK from the GC,
• allow each member to verify the identity of the controller and vice versa,
• allow each member to verify the controller's authorization to create the group,
• send the key packet (KP) (consisting of the GTEK, GKEK), group identity, GC identity, group member identities, group permissions, and group rekey interval to the other members.

This function is six messages between the GC and the other members 🎀 The first few set up the SKEK. The GC sends a signed Create_Session_KEK_1 message to the other member. It carries the random value the other member needs to generate the SKEK, plus the GC's public key 🌸

The other member checks the Create_Session_KEK_1 message, then builds and sends a Create_Session_KEK_2 message to the GC, generates the SKEK, and stores the GC's public key. The Create_Session_KEK_2 message has the random value the GC needs to generate the SKEK, plus the other member's public key 🧚

The GC validates the Create_Session_KEK_2 message, generates the SKEK, builds the Negotiate_Session_ KEK_1 message for the other member, and stores the received public key 💅

The GC sends the Negotiate_Session_KEK_1 message to the other member encrypted in the SKEK that was just generated. This message includes the group ID, group token, controller permissions, and CRL version number 🔐

The other member decrypts the Negotiate_Session_KEK_1 message, verifies the controller's authority and identification, makes sure the local CRL is up to date, and builds a Negotiate_Session_KEK_2 message for the GC 🫶

The GC receives the Negotiate_Session_KEK_2 message and builds a Download_Grp_Keys message for the other member 🌈

The GC sends the Download_Grp_Keys message to the other member encrypted in the SKEK that was just generated. (note: the key used to encrypt the negotiation messages can be combined differently to create the KEK.) 👑

The other member decrypts the Download_Grp_Keys message and extracts the KP, group identification, GC identification, group members, group permissions, key rekey interval, and group commander's signature. The group identification, GC identification, and group permissions fields get validated against the signature. If they validate, the other member's internal key storage tables get updated with the new keys 💖

6.2 Group Rekey 🌸

Rekey is a two-step function that involves message exchange between the GC and a "first member" and "other members" 🔄 Messages between the GC and the first member work exactly the same as they do for group creation. Messages between the GC and the other members are for distributing the new GTEK and the new GKEK. These functions are described in the following sections ✨

|___Net_Controller___|__________Messages________|Net_members,individual|
|                    |Create Session KEK_1---->  |                     |
|                    |                           |State 5              |
|                    |<-----Create Session KEK_2 |                     |
|State 5             |                           |                     |
|                    |Negotiate ess. Keys_1----->|                     |
|                    |                           |State 6              |
|                    |<-----NegotiateSess. Keys_2|                     |
|State 7             |                           |                     |
|                    |Download Grp Keys--------> |                     |
|                    |                           |State 8              |
|                    |<----- Key download ack    |                     |
|State 9             |                           |                     |
               Figure 2:  State Diagram:  Distribute Keys

6.2.1 Create Group Keys 🎀

The first member function for a rekey operation is the same as the one for key initialization. Please refer to the group creation section entitled "2.1 Create group keys".

6.2.2 Rekey 🦋

The purpose of rekey is as follows:

• send the new GTEK and new GKEK to the other members,
• allow each member to verify the identity of the controller,
• allow each member to verify the controller's authorization to rekey the group, group identification, and GC identification,
• send the group identity, GC identity, group member identities, group permissions, and group rekey interval to the other members.

The messages that create and negotiate the group keys are the same as the ones used during group creation, so they've been left out here 💜

The rekey portion of this function is one message between the GC and the other members. The GC builds a signed Rekey_Multicast message for the other member. As the name implies, this message can be multicast to the entire group 📣

|___Net_Controller___|__________Messages________|Net_members,individual|
|The Create Group    |<---- Command-Create Group |                     |
|command is          |                           |                     |
|received by net     |                           |                     |
|member A.           |                           |                     |
|State 1             |                           |                     |
|                    |Create Grp Keys_1---->     |                     |
|                    |                           |State 2              |
|                    |<-----Create Grp Keys_2    |                     |
|State 2             |                           |                     |
|                    |Negotiate Grp Keys_1------>|                     |
|                    |                           |State 3              |
|                    |<-----Negotiate Grp Keys_2 |                     |
|State 4             |                           |                     |
|                    |Rekey _Multicast------->   |                     |
|                    |                           |State 10             |
                    Figure 3:  State Diagram:  Rekey

The GC sends the signed Rekey_Multicast message to the other members encrypted in the current GKEK 🔐

The other members decrypt and validate the signed Rekey_Multicast message and extract the new KP, group identification, GC identification, group members, group permissions, key rekey interval, and rekey command signature 🧾 The group identification, GC identification, and group permissions fields get validated against the extracted rekey command signature. If they validate, the key database tables get updated 🌟

6.3 Member Initiated Join 💖

okay so the GKMP totally supports member initiated joins to the group 🫶 this is most giving when the group initiator doesn't need to control who's in the group, and just needs to check that everyone follows some rules that were agreed on ahead of time.

one example is corporation job vacancies 💼 a corporation wants its openings kept private, so it encrypts the announcements 🔐 the group creator literally doesn't care who grabs them, as long as they're in the corporation. when an employee tries to get in, the GC checks their permissions (signed by some higher authority 👑). if those permissions say they're part of the corporation, the controller lets them into the group. iykyk 😭

before a potential group member can join group operations, they have to request the key from the GC, identify themselves unambiguously, pass their permissions, and receive the keys. that's several messages going back and forth between the GC and the joining member 🦋 the purpose of these messages is:

• Request group join from the controller 🙋‍♀️
• cooperatively generate a SKEK for the transmission of the group traffic encryption and GKEK from the GC,
• allow each member to verify the identity of the controller and vice versa,
• allow each member to verify the controller's authorization to create the group,
• send the KP, group identity, GC identity, group member identities, group permissions, and group rekey interval to the other members,

the series of messages for a member initiated join is very similar to the series of messages used to distribute group keys during group creation. honestly they're identical except for one extra piece: a request to join message sent from the joining member to the controller when the join is member initiated 💅 this message should not require encryption, since it probably doesn't contain sensitive info. however, in some military systems, the fact that a member wants to join a group maybe sensitive from a traffic analysis viewpoint 🕵️‍♀️ in those specialized cases, a pairwise TEK may be created (if one doesn't already exist) to hide the service request 🤫

this function is made up of seven messages between the GC and the joining member ✨ the first message is created by the joining member and sent to the GC. it simply requests membership in the group from the controller. the controller decides whether to respond based on the group parameters: membership limits and membership lists 📋

the next messages set up a SKEK 🔑 the GC sends a signed Create_Session_KEK_1 message to the other member. this message has the random value the other member needs to generate the SKEK, and it also carries the public key of the GC.

the other member validates the Create_Session_KEK_1 message, builds and sends a Create_Session_KEK_2 message to the GC, generates the SKEK, and stores the received public key 🧚 the Create_Session_KEK_2 message contains the random value the GC needs to generate the SKEK, and it also carries the public key of the other member.

the GC validates the Create_Session_KEK_2 message, generates the SKEK, builds the Negotiate_Session_ KEK_1 message for the other member, and stores the received public key 🫧

the GC sends the Negotiate_Session_KEK_1 message to the other member, encrypted in the SKEK that was just generated 🔒

the other member decrypts the Negotiate_Session_KEK_1 message and builds a Negotiate_Session_KEK_2 message to send back to the GC 💜

the GC receives the Negotiate_Session_KEK_2 message and builds a Download_Grp_Keys message for the other member 🎀

the GC sends the Download_Grp_Keys message to the other member, encrypted in the SKEK that was just generated. (note: the key used to encrypt the negotiation messages can be combined differently to create the KEK.) 🌸

the other members decrypt the Download_Grp_Keys message and extract the KP, group identification, GC identification, group members, group permissions, key rekey interval, and group commander's signature 🖋️ the group identification, GC identification, and group permissions fields are validated based on the signature. if those fields validate, the other members' internal key storage tables get updated with the new keys ✨

|___Net_Controller___|__________Messages________|Net_Members,individual|
|                    |<------ Request_Group_Join |                     |
|State 11            |                           |                     |
|                    |Create Session KEK_1---->  |                     |
|                    |                           |State 5              |
|                    |<-----Create Session KEK_2 |                     |
|State 5             |                           |                     |
|                    |NegotiateSess. Keys_1----->|                     |
|                    |                           |State 6              |
|                    |<-----NegotiateSess. Keys_2|                     |
|State 7             |                           |                     |
|                    |Download Grp Keys--------> |                     |
|                    |                           |State 8              |
|                    |<----- Key download ack    |                     |
|State 9             |                           |                     |
                 Figure 4:  State Diagram:  Member Join

---

6.4 Member Deletion 🧹

okay so there are two kinds of member deletion: cooperative and hostile 🫶 cooperative deletion is removing a trusted group member for some management reason (i.e., reducing group size, or getting the member ready for a move). hostile deletion usually ends in a loss of secure state at the member's site (i.e., compromise, or equipment breakage) 😬

|___Net_Controller___|__________Messages__________|_____Net_Members_____|
|                    |Delete_Group_Keys ------>   |                    |
|                    |                            |State 12            |
|                    |<------ Grp_Keys_Deleted_Ack|                    |
|State 9             |                            |                    |
             Figure 5:  State Diagram:  Cooperative Delete

the two scenarios are super different challenges for the network 🕸️ in the cooperative case, minimizing network impact is paramount 👑 we want to keep the key group intact and be confident that removing the cooperative member has no impact on the security of future group operations. in the hostile case, the goal is to get back to a secure operating state as fast as possible 🏃‍♀️ and ngl there's a real trade-off here. we could kill the compromised group the moment the compromise is discovered, but that might cripple an important asset. so security concerns have to be balanced with operational concerns ⚖️

6.4.1 Cooperative Deletion

the cooperative deletion function happens between a trusted member and the GC 🤝 it results in a reliable deletion of the group key encryption keys and GTEKs at the deleted member. this deletion is meant to be an administrative function.

this function is two messages between the GC and the member. the GC sends the Delete_Group_Keys message to the group, encrypted in the GTEK. the message identifies the member(s) that need to delete the group keys. the member(s) decrypt the Delete_Group_Keys message, extract the group identification, check the deleted member list, delete the group traffic and key encryption keys for that group, and build the Group_Keys_Deleted_Ack message to send to the GC 💌

the Grp_Keys_Deleted_Ack message is encrypted in the group traffic key. the GC receives the Grp_Keys_Deleted_Ack message, decrypts it, and updates the group definition 🩷

|___Net_Controller___|__________Messages____________|_____Net_Members__|
|                    |Delete_Group_Keys ------>     |                  |
|                    |                              |State 13          |
               Figure 6:  State Diagram:  Hostile Delete

6.4.2 Hostile Deletion (Compromise)

hostile deletion happens when the group loses trust in a member 💀 we assume all the keys at the member's site have been lost, and we assume the member won't cooperate. therefore, we basically have to create another group, minus the untrusted member, and move group operations over to that new group 🚚 if the group loses trust in the controller, another controller has to be appointed first, and then the hostile deletion process can go ahead.

there are some serious security and operational issues around compromise recovery 😭 the core of it is a tradeoff between operational continuity and security vulnerability. if a member is found to be bad, then from a security point of view, all traffic on the network should stop. but if that traffic is supporting a critical operation, the group may prefer to live with the security leak rather than interrupt the group communication 🫠

the GKMP gives us two mechanisms to help restrict access by compromised members 🛡️ first, it implements a Certificate Revocation List (CRL), which is checked during the group creation process, so it won't let a compromised member into a new group. second, the GKMP makes it possible to create another group (minus the compromised member(s)). however, it does not dictate whether or not the group may keep operating with a compromised member.

the mechanism the GKMP uses to remove a compromised member is to key that member out 🔑 this means creating a new group without the compromised member and switching group operations over to it. the old group gets canceled through several multicasts of a group delete message 📣

this function is one message from the GC to all members. the GC sends the Delete_Group message to all members, encrypted in the GTEK. this results in the deletion of the group traffic and key encryption keys in all group members. all members decrypt the received Delete_Group message, validate the authorization, extract the group identification, and delete the group traffic and key encryption keys 🗑️✨

---

7 Security Conditions 🔐

this document, in its entirety, is all about security 🔥

8 Addresses of Authors 🎀

meet the brilliant minds behind it 🧠💜

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

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