From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2093.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc2093.txt (limited to 'doc/rfc/rfc2093.txt') diff --git a/doc/rfc/rfc2093.txt b/doc/rfc/rfc2093.txt new file mode 100644 index 0000000..95d1ac5 --- /dev/null +++ b/doc/rfc/rfc2093.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group H. Harney +Request for Comments: 2093 C. Muckenhirn +Category: Experimental SPARTA, Inc. + July 1997 + + + Group Key Management Protocol (GKMP) Specification + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo 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 + + This specification proposes a protocol to create grouped symmetric + keys and distribute them amongst communicating peers. This protocol + has the following advantages: 1) virtually invisible to operator, 2) + no central key distribution site is needed, 3) only group members + have the key, 4) sender or receiver oriented operation, 5) can make + use of multicast communications protocols. + +1 Background + + Traditional key management distribution has mimicked the military + paper based key accounting system. Key was distributed, ordered, and + accounted physically leading to large lead times and expensive + operations. + + Cooperative key management algorithms exist that allow pairwise keys + to be generated between two equipment's. This gives the a quicker + more reliable key management structure capable of supporting large + numbers of secure communications. Unfortunately, only pairwise keys + are supported using these methods today. + + + + +Harney & Muckenhirn Experimental [Page 1] + +RFC 2093 GKMP Specification July 1997 + + + This document describes a protocol for establishing and rekeying + groups of cryptographic keys (more than two) on the internet. We + refer to the approach as the Group Key Management Protocol (GKMP). + +1.1 Protocol Overview + + The GKMP creates key for cryptographic groups, distributes key to the + group members, ensures (via peer to peer reviews) rule based access + control of keys, denies access to known compromised hosts, and allow + hierarchical control of group actions. + + The key generation concept used by the GKMP is cooperative generation + between two protocol entities. There are several key generation + algorithms viable for use in the GKMP (i.e., RSA, Diffe-Hellman, + elliptic curves). All these algorithms use asymmetric key technology + to pass information between two entities to create a single + cryptographic key. + + The GKMP then distributes the group keys to qualified GKMP entities. + This distribution process is a mutually suspicious process (all + actions and identities must be verified). + + The GKMP provides a peer to peer review process. Protocol entities + pass permission certificates (PC) as part of the group key + distribution process. The PCs contain access control information + about a particular site. This access control information is assigned + by a higher authority which then signs the PC. Therefor each entity + can verify the permissions of any other GKMP entity but can modify + none. Each protocol entity checks the permissions and compares them + the level of service requested. If the permissions do not exceed or + equal the request, the service is denied. + + The GKMP supports compromise recovery. A list of compromised GKMP + entities is distributed to group members during key management + actions. In essence, a Compromise Recovery List (CRL) allows group + members to drop connections with compromised entities. The GKMP + delegates control of groups to specific group controllers so it will + be somewhat easier to distribute the CRL to the most important GKMP + entities. During each key management action the CRL version number + is passed, when a CRL update is detected it is downloaded and + verified (it is signed by a higher authority). + + The GKMP allows control of group actions. In certain networks it is + desirable for a higher authority to strictly control the generation + of groups. These networks usually have a central network operations + authority. The GKMP allows these authorities to remotely order group + actions. These orders are signed by that authority and verified by + all entities involved with the group. + + + +Harney & Muckenhirn Experimental [Page 2] + +RFC 2093 GKMP Specification July 1997 + + + The GKMP is an application layer protocol. It's independent of the + underlying communication protocol. However, if multicast service is + available it will speed the rekey of the cryptographic groups. + Hence, the GKMP does use multicast services if they are available. + +2 Overview: GKMP Roles + + Creation and distribution of grouped key require assignment of roles. + These identify what functions the individual hosts perform in the + protocol. The two primary roles are those of key distributor and + member. The controller initiates the creation of the key, forms the + key distribution messages, and collects acknowledgment of key receipt + from the receivers. The members wait for a distribution message, + decrypt, validate, and acknowledge the receipt of new key. + +2.1 Group controller + + The group controller (GC) is the a group member with authority to + perform critical protocol actions (i.e., create key, distribute key, + create group rekey messages, and report on the progress of these + actions). All group members have the capability to be a GC and could + assume this duty upon assignment. + + The GC 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 it's key, it will not be able to send or receive data to + another host operating on the correct key. Therefor, it is important + that those operations that create or change key are unambiguous and + controlled (i.e., it would not be appropriate for multiple hosts to + try to rekey a net simultaneously). Hence, someone has to be in + charge -- that is the controller. + +2.2 Group member + + Simply stated a group member is any group host who is not acting as + the controller. The group members will: assist the controller in + creating key, validate the controller authorization to perform + actions, 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. + + + + + + + + + + +Harney & Muckenhirn Experimental [Page 3] + +RFC 2093 GKMP Specification July 1997 + + +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 will then initiate contact with these net + members and create the group. + +3.2 Group Token: + + The group token is created by the authority which commands a group. + The Token contains information the net members need to ensure a + controller is authorized to create a group and exactly what + constrains are intended to be places on the group. The group token + contains the following fields: Group identification, + + o GC ID, + + o Group action (create, rekey, delete), + + o Group permissions (rules to guide access control), + + o Rekey interval (life span of group key), + + o Token version (identifier to identify current token), + + o Token signature (asymmetric signature using the group + commanders private key), + + o 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 to allow for several different + groups to coexist on a network. + +3.4 GTEK ID: + + Unique identifier of GTEK (can include state information). + +3.5 GKEK ID: + + Unique identifier of GKEK (can include state information). + + + + + + +Harney & Muckenhirn Experimental [Page 4] + +RFC 2093 GKMP Specification July 1997 + + +3.6 GTEK creation field: + + In a cooperative key creation protocol each party contributes some + field used to create the key. + +3.7 GKEK creation field: + + In a cooperative key creation protocol each party contributes some + field used to create the key. + +3.8 Distributor signature: + + Asymmetric signature using the GCs private key. + +3.9 Distributor public key: + + Public half of the GCs signature key pair. (this public key is + itself signed by the network security manager to bind the public to a + specific net member ID. + +3.10 Member signature: + + Asymmetric signature using the selected members private key. + +3.11 Member public: + + Public half of the selected members signature key pair. (this public + key is itself signed by the network security manager to bind the + public to a specific net member ID. + +3.12 Controller permissions: + + Controller permissions are assigned by the security manager. The + security managers signature will bind the permissions to the + controller ID. + +3.13 SKEK ID: + + This field identifies exactly which SKEK is being created. This + allows multiple groups to interoperate on a net simultaneously. + +3.14 SKEK creation field: + + This field contains the information contributed for use in the KEK + creation process. + + + + + + +Harney & Muckenhirn Experimental [Page 5] + +RFC 2093 GKMP Specification July 1997 + + +3.15 Member permissions: + + Member permissions are assigned by the security manager. The + security managers signature will bind the permissions to the + controller ID. + +3.16 Encrypted Grp Keys: + + This data item is encrypted in the KEK (session or group) created for + the download of keys. It is the GTEK and GKEK created for a group. + A checksum is also encrypted. This ensures the confidentiality and + data integrity of the GTEK and GKEK. + +3.17 Confirmation of decryption: + + This is a short (byte) field indicating decryption of the message and + exactly what type of message was decrypted. + +3.18 Request: + + A request field contains the specific request one net member may make + to another. The requests range from (group join, CRL update, + pairwise TEK generation, detection, group creation, status). + + Member delete list: + + 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, Token public key). + This message may be confidential due to the group permissions field. + In sensitive systems it will need encryption prior to 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. This message contains (Grp + ID, Request, GTEK ID, GKEK ID, GTEK creation field, GKEK creation + field, Grp token, Controller signature, Controller public) + + + + + + +Harney & Muckenhirn Experimental [Page 6] + +RFC 2093 GKMP Specification July 1997 + + +4.3 Create Grp Keys_2: + + This message passes the information needed to create the group keys + from the selected net member to the GC. This message contains: (Grp + ID, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field, + member signature, member public) + +4.4 Negotiate Grp Keys_1: + + This message passes the group token and GCs permissions to the + selected net member. This information can be sensitive and needs to + be protected. Therefor, this message is encrypted in the GTEK just + created. This encryption includes the appropriate data integrity + checks. This message1 contains: (Grp ID, TEK ID, KEK ID, Group + token, Controller permissions) + +4.5 Negotiate Grp Keys_2: + + This message passes the selected net members permissions to the GC. + This message1 contains: (Grp ID, GTEK ID, GKEK ID, Member + permissions). This information can be sensitive and needs to be + protected. Therefor, this message is encrypted in the GTEK just + created. This encryption includes the appropriate data integrity + checks. + +4.6 Create Session KEK_1: + + This message sends information to create a KEK for one time use + between the GC and selected net member. + +4.7 Create Session KEK_2: + + This message sends information to create a KEK for one time use + between the selected net member and GC. + +4.8 Negotiate Session Keys_1: + + This message passes the group ID, SKEK ID, CRL version number, Group + token and GCs permissions to the selected net member. This + information can be sensitive and needs to be protected. Therefor, + this message is encrypted. If an appropriate pairwise key is + available then that key should be used. If not the KEK just created + could be used to encrypt the message. + + + + + + + + +Harney & Muckenhirn Experimental [Page 7] + +RFC 2093 GKMP Specification July 1997 + + +4.9 Negotiate Session Keys_2: + + This message identifies the group, SKEK, CRL version number and the + member permissions. This information can also be sensitive and needs + protection. + +4.10 Download Grp Keys: + + This message includes a GRP ID and Encrypted Grp Keys data items. + +4.11 Key download ack: + + This message contains the GRP ID and Confirmation_decryption data + items. It confirms the receipt and verified decryption of the GTEK + and GKEK. + +4.12 Rekey _Multicast: + + This message contains: Grp ID, GTEK ID, GKEK ID, Group token, + Controller permissions. The rekey message is encrypted in the GKEK + already resident in all the group member sites. This leads to a + single message capable of being accepted by all group members. + +4.13 Request_Group_Join: + + This message contains Request, Grp ID, Member Signature, Member + Public. + +4.14 Delete_Group_Keys: + + This message contains: grp ID, Request, Member delete list, + Controller signature, 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). + +4.17 Grp_Keys_Deleted_Ack: + + This message contains (grp ID, member ID, member signature, member + public) + + + + +Harney & Muckenhirn Experimental [Page 8] + +RFC 2093 GKMP Specification July 1997 + + +5 State definitions + + There are thirteen separate states the in the protocol. They are + described below: + +5.1 State 1: + + The source address is checked to ensure it is not on the CRL. + + The token field is validated with the public key of the source. + + The token version number is checked to ensure 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 assumes the role of controller. If not, the + role assumed is that of receiver. + + The GC reads the group permission field in the group token. It then + verifies that its' personnel permissions exceed or equal those of the + group. + + The GC will creates its' portion of the key creation message. + + The Create Grp Keys_1 message is completed and transmitted. + +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. + + + + +Harney & Muckenhirn Experimental [Page 9] + +RFC 2093 GKMP Specification July 1997 + + + The group token is retrieved and validated using the appropriate + public key. + + The token version number is checked to ensure the token is current. + + The group ID specified in the token is compared with the actual group + ID. If they are different the exchange is terminated. + + The controller ID specified in the token is compared with the GC ID. + If they do not match the exchange is terminated. + + The local permissions are compared to the permissions specified for + the group. If they do not 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 are + 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. + + + + +Harney & Muckenhirn Experimental [Page 10] + +RFC 2093 GKMP Specification July 1997 + + + The group token is retrieved and validated using the appropriate + public key. + + The token version number is checked to ensure 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 do not match the exchange is terminated. + + The local permissions are compared to the permissions specified for + the group. If they do not 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 ensure proper decryption. + + 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 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. + + + + + +Harney & Muckenhirn Experimental [Page 11] + +RFC 2093 GKMP Specification July 1997 + + + The group token is retrieved and validated using the appropriate + public key. + + The token version number is checked to ensure 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 do not match the exchange is terminated. + + The local permissions are compared to the permissions specified for + the group. If they do not 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 ensure proper decryption. + + The key table is updated to reflect the key permissions, rekey + interval, group ID and current time. + +5.11 State 11: + + Validate signature using sources public key. + + Check to see if member initiated group join is available. If not, + ignore. If so begin distribution of group keys. + +5.12 State 12: + + Validate signature using GCs public. + + Retrieve delete list. Check to see if on delete list, if so + continue. + + Create Grp_Keys_Deleted_Ack + + Delete group keys + +5.13 State 13: + + Validate signature using GCs public. + + Retrieve delete list. If list is global delete, verify alternative + key. + + Switch group operations to alternative key. + + + +Harney & Muckenhirn Experimental [Page 12] + +RFC 2093 GKMP Specification July 1997 + + + Create Grp_Keys_Deleted_Ack. + + Delete group keys. + +6 Functional Definitions--Group Key Management Protocol + + The GKMP consists of multiple functions necessary to create, + distribute, rekey and manage groups of symmetric keys. These + functions are: + + o Group creation (sender initiated group) + + + -- Create Group keys + + -- Distribute Group keys + + o Group rekey + + + -- Create Group keys + + -- Rekey Group + + + o Member initiated join + + o Group member delete + + The following sections will describe each function, including data + primitives and message constructs. The associated diagrams will + represent the specifics (sequence, location and communications + sources and destinations) of the messages and processes necessary. + +6.1 Group creation + + Member initialization is a three-step function that involves + commanding the creation of the group, creation of the group keys and + then distribution of 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 the purpose of distributing the keys. These + functions are described in the following sections. + + + + + + + +Harney & Muckenhirn Experimental [Page 13] + +RFC 2093 GKMP Specification July 1997 + + +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 + + The first member must cooperate with the GC to create future group + keys. Reliance on two separate hosts to create group keys maximizes + the probability that the resulting key will have the appropriate + cryptographic properties. A single host could create the key if the + randomization function were robust and trusted. Unfortunately this + usually requires specialized hardware not available at most host + sites. The intent of this protocol was to utilize generic hardware + to enhance the extendibility of the GKMP. Hence, cooperative key + generation mechanisms are used. + + To facilitate a well ordered group creation, management information + must be passed between the controller and the group members. This + information uniquely identifies the GC identity, it's permissions, + authorization to create keys, the future groups permissions, current + state of the compromise list, and management information pertaining + to the keys being created. All this information is protected from + forgery by asymmetric signature technologies. The public key used to + verify net wide parameters (e.g., individual host permissions) are + widely held. The public key to verify locally generated information, + like peer identity, is sent with the messages. This alleviates the + hosts public key storage requirements. + + The goals of the key creation process are: + + o cooperatively generate a GTEK and GKEK, + + o allow the key creators to verify the identity of the key + creation partner by verifying the messages signatures. + + o share public keys + + o allow validation of the GC, by signing the group + identification, GC identification, and group permissions. + + o 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). + + + + + + +Harney & Muckenhirn Experimental [Page 14] + +RFC 2093 GKMP Specification July 1997 + + + This function consists of four messages between the GC and the first + member. The initial messages are for the establishment of the GTEK + and GKEK. This is accomplished by the GC sending a signed + Create_Group_Keys_1 message to the first member. This message + contains two random values necessary to generate the GTEK and GKEK. + This message also contains the public key of the GC. + + The first member validates the signed Create_Group_Keys_1 message, + builds and sends a signed Create_Group_Keys_2 message to the GC. He + generates the GTEK and GKEK, and stores the received public key. The + Create_Group_Keys_2 message contains the random values necessary for + the GC to generate the GTEK and GKEK. This message also contains the + public key of the first member. + + The GC validates the signed Create_Group_Keys_2 message, generates + the GTEK and GKEK, builds the Negotiate_Group_Keys_1 message for + transmission to 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 + extracts 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 are validated based on + the extracted group commanders signature (if this is a remotely + commanded group this signature identifies the remote host). If these + fields validate, the first members internal structures are updated. + + + + + +Harney & Muckenhirn Experimental [Page 15] + +RFC 2093 GKMP Specification July 1997 + + +6.1.3 Distributing Group Keys to Other Members + + The other group members must get the group keys before the group is + fully operational. The purpose of other group member initialization + is as follows: + + o cooperatively generate a session key encryption key (SKEK) for the + transmission of the GTEK and GKEK from the GC, + + o allow each member to verify the identify of the controller and + visa versa, + + o allow each member to verify the controllers authorization to + create the group, + + o 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 consists of six messages between the GC and the other + members. The initial messages are for the establishment of a SKEK. + This is accomplished by the GC sending a signed Create_Session_KEK_1 + message to the other member. This message contains the random value + necessary for the other member to generate the SKEK. This message + also contains 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 necessary for the GC to generate + the SKEK. This message also contains 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 transmission to + 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 + Negotiate_Session_KEK_1 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 authority and identification of the controller, ensures + the local CRL is up to date, and builds a Negotiate_Session_KEK_2 + message for transmission to the GC. + + + + + +Harney & Muckenhirn Experimental [Page 16] + +RFC 2093 GKMP Specification July 1997 + + + The GC receives the Negotiate_Session_KEK_2 message and builds a + Download_Grp_Keys message for transmission to 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 decrypts the Download_Grp_Keys message and extracts + the KP, group identification, GC identification, group members, group + permissions, key rekey interval, and group commanders signature. The + group identification, GC identification, and group permissions fields + are validated based on the signature. If these fields validate, the + other members internal key storage tables are 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 are exactly as described for group creation. + Messages between the GC and the other members are for the purpose of + distributing the new GTEK and the new GKEK. These functions are + +|___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 + + described in the following sections. + +6.2.1 Create Group Keys + + The first member function for a rekey operation is the same as that + for key initialization. Please refer to the group creation section + entitled "2.1 Create group keys". + + + + + +Harney & Muckenhirn Experimental [Page 17] + +RFC 2093 GKMP Specification July 1997 + + +6.2.2 Rekey + + The purpose of rekey is as follows: + + o send the new GTEK and new GKEK to the other members, + + o allow each member to verify the identify of the controller, + + o allow each member to verify the controllers authorization to + rekey the group, group identification, and GC identification, + + o send the group identity, GC identity, group member identities, + group permissions, and group rekey interval to the other members, + + The messages to create and negotiate the group keys are the same as + stated during group creation. As such they have been omitted here. + + The rekey portion of this function consists of one message between + the GC and the other members. The GC builds a signed Rekey_Multicast + message for transmission to the other member. As the name implies + this + +|___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 + + message can be multicast to the entire group. 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 + + + +Harney & Muckenhirn Experimental [Page 18] + +RFC 2093 GKMP Specification July 1997 + + + identification, and group permissions fields are validated based on + the extracted rekey command signature. If these fields validate, the + key database tables are updated. + +6.3 Member Initiated Join + + The GKMP will support member initiated joins to the group. This type + of service is most attractive when the group initiator does not need + to control group membership other than to verify that all members of + the group conform to some previously agreed upon rules. + + One example of this type of group is corporations job vacancies. A + corporation may want to keep its job vacancies confidential and may + decide to encrypt the announcements. The group creator doesn't care + who gets the announcements as long as they are in the corporation. + When an employee tries to access the information the GC looks at the + employees permissions (signed by some higher authority). If they + indicate the employee is part of the corporation the controller + allows access to the group. + + Before a potential group member can join group operations, they must + request the key from the GC, unambiguously identify themselves, pass + their permissions, and receive the keys. These require several + messages to pass between GC and the joining member. The purpose of + these messages are as follows: + + o Request group join from controller + + o cooperatively generate a SKEK for the transmission of the group + traffic encryption and GKEK from the GC, + + o allow each member to verify the identify of the controller and + visa versa, + + o allow each member to verify the controllers authorization to + create the group, + + o 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 to distribute group keys during group + creation. In fact, the series are identical except for the addition + of 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 does not contain sensitive + information. However, in some military systems the fact that a + member wants to join a group maybe sensitive from a traffic analysis + + + +Harney & Muckenhirn Experimental [Page 19] + +RFC 2093 GKMP Specification July 1997 + + + viewpoint. In these specialized instances, a pairwise TEK may be + created, if one does not already exist, to hide the service request. + + This function consists 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 request membership in the group from + the controller. The controller makes the decision whether to respond + to the request based on the group parameters - membership limits, + membership lists. + + The next messages are for the establishment of a SKEK. This is + accomplished by the GC sending a signed Create_Session_KEK_1 message + to the other member. This message contains the random value + necessary for the other member to generate the SKEK. This message + also contains 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 necessary for the GC to generate + the SKEK. This message also contains the public key of the other + member. + + The GC validates the Create_Session_KEK_2 message, generates the + SKEK, + +|___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 + + builds the Negotiate_Session_ KEK_1 message for transmission to 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. + + + +Harney & Muckenhirn Experimental [Page 20] + +RFC 2093 GKMP Specification July 1997 + + + The other member decrypts the Negotiate_Session_KEK_1 message and + builds a Negotiate_Session_KEK_2 message for transmission to the GC. + + The GC receives the Negotiate_Session_KEK_2 message and builds a + Download_Grp_Keys message for transmission to the other member. + + The GC sends theDownload_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 decrypts theDownload_Grp_Keys message and extracts + the KP, group identification, GC identification, group members, group + permissions, key rekey interval, and group commanders signature. The + group identification, GC identification, and group permissions fields + are validated based on the signature. If these fields validate, the + other members internal key storage tables are updated with the new + keys. + +6.4 Member Deletion + + There are two types of member deletion scenarios - cooperative and + hostile. The cooperative deletion scenarios is the removal of a + trusted group member for some management reason (i.e., reduce group + size, prepare the member for a move). The hostile deletion usually + results in + +|___Net_Controller___|__________Messages__________|_____Net_Members_____| +| |Delete_Group_Keys ------> | | +| | |State 12 | +| |<------ Grp_Keys_Deleted_Ack| | +|State 9 | | | + Figure 5: State Diagram: Cooperative Delete + + a loss of secure state at the members site (i.e., compromise, + equipment breakage). + + The two scenarios present different challenges to the network. + Minimization of network impact is paramount in the cooperative + scenario. We would like to leave the key group intact and have + confidence that removing the cooperative group member will have no + impact on the security of future group operations. In the case of a + hostile deletion, the goal is to return to a secure operating state + as fast as possible. In fact there is a trade-off. We could + eliminate the compromised group as soon as the compromise is + discovered, but this may cripple an important asset. So security + concerns need to be balanced with operational concerns. + + + + +Harney & Muckenhirn Experimental [Page 21] + +RFC 2093 GKMP Specification July 1997 + + +6.4.1 Cooperative Deletion + + The cooperative deletion function occurs between a trusted member and + the GC. It results in a reliable deletion of the group key encryption + and GTEKs at the deleted member. This deletion is intended to be an + administrative function. + + This function consists of 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, + deletes the group traffic and key encryption keys for that group, and + build the Group_Keys_Deleted_Ack message for transmission 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 occurs when a the group losses trust in a member. + We assume that all keys resident at the members site have been lost. + We also assume the member will not cooperate. Therefor, we must + essentially create another group, minus the untrusted member, and + transfer group operations to that new group. When the group losses + trust in the controller, another controller must be appointed and + then the hostile deletion process can proceed. + + There are some security and operational management issues surrounding + compromise recovery. The essence of the issues involve a tradeoff + between operational continuity and security vulnerability. If a + member is found to be bad, from a security point of view all traffic + on the network should stop. However, if that traffic is supporting a + critical operation, the group may prefer to live with the security + leak rather than interrupt the group communication. + + + + + + + + + + +Harney & Muckenhirn Experimental [Page 22] + +RFC 2093 GKMP Specification July 1997 + + + The GKMP provides two mechanisms to help restrict access of + compromised members. First, it implements a Certificate Revocation + List (CRL) which is checked during the group creation process. Thus + it will not allow a compromised member to be included in a new group. + Second, the GKMP facilitates the creation of another group (minus the + compromised member(s)). However, it does not dictate whether or not + the group may continue to operate with a compromised member. + + The mechanism the GKMP uses to remove a compromised member is to key + that member out. This entails creating a new group, without the + compromised member, and switching group operations. The old group is + canceled by several multicasts of a group delete message. + + This function consists of 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, extracts + the group identification, and delete the group traffic and key + encryption keys. + + +7 Security Conditions + + This document, in entirety, concerns security. + +8 Addresses of Authors + + 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 + + + + + + +Harney & Muckenhirn Experimental [Page 23] + -- cgit v1.2.3