rfc2093.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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:        [phone] (ext.  203)
   EMail:  [e-mail]

   Carl Muckenhirn
   SPARTA, Inc.
   Secure Systems Engineering Division
   9861 Broken Land Parkway, Suite 300
   Columbia, MD 21046-1170
   United States
   Phone:        [phone] (ext.  208)
   EMail:  [e-mail]






Harney & Muckenhirn           Experimental                     [Page 23]