rfc2094.txt

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


RFC 2094                   GKMP Architecture                   July 1997


   The GKMP allows an external entity to determine the controller of a
   group.  The controller of the group should be able to handle the
   additional processing and communication requirements associated with
   the role.  If this is not a necessary function given the
   implementation, this assignment of controller duties can be set to
   some automated default.  However, even if defaulted some external
   management entity determines how the role of controller is allocated.

   The group manager can receive group progress reports from the group
   controller.  The GKMP provides a service for the network.  It makes
   sense that someone in the network is interested in the progress of
   this service.  The GKMP can provide progress reports.  It is up to
   the network management to determine the manner and recipient of the
   reports.  Reference figure 2:  Network manager interaction.


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

                  Figure 2:  Network Manager Interaction

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

   The creation of groups involves the assignment of a group address,
   update of router databases, and distribution of this group address to
   the group members.  This is a classic function of network management.
   The GKMP group controller would be another recipient of this
   information.

   Protocol role allocation  The Group Management Protocol assigns roles
   to members of a particular group.  These roles are binary one is
   either the control over the group or a member of a group.  Some
   external entity will allocate the identity of the group controller
   and group receiver.  This is a desirable aspect because some
   computers are more capable (i.e., central site, great deal of process
   power available to control a group).  We allow some external entity
   to allocate these roles to individual group members, this is
   important in the military application do to the fact that in a



Harney & Muckenhirn           Experimental                     [Page 12]

RFC 2094                   GKMP Architecture                   July 1997


   commercial application the allocating authority and group controller
   may very well always be the same.

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


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

                  Figure 3:  Distributed Group Management

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

3.2 Protocol 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 controller and
   receiver.  The controller initiates the creation of the key, forms
   the key distribution messages, and collects acknowledgment of key
   receipt from the receivers.  The receivers wait for a distribution
   message, decrypt, validate, and acknowledge the receipt of new key.

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

3.2.1 Group controller

   The group controller 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 group controller and
   could assume this duty upon assignment.





Harney & Muckenhirn           Experimental                     [Page 13]

RFC 2094                   GKMP Architecture                   July 1997


   The group controller helps the cryptographic group reach and maintain
   key synchronization.  A group must operate on the same symmetric
   cryptographic key.  If part of the group loses or inappropriately
   changes 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).

3.2.2 Group receiver

   Simply stated a group receiver is any group member who is not acting
   as the controller.  The group receivers 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.

3.3 Scenarios

3.3.1 Group establishment

   The protocol to establish a group of host that share a cryptographic
   key must create a high quality key, verify that all intended
   recipients have permission to join the group, distribute the key to
   all qualified members, and report on the progress.  This process
   consists of two phases:  creation of the key and distribution of the
   key.  Refer to figure 4:  Group Establishment.

   The group establishment process is proceeds in the following manner.
   First, a "create group" command is issued to the group commander.
   The group controller validates the command to ensure it came from an
   authorized commander and the group is within the controller's
   permission range.  Next, the controller creates a key.  Then that key
   is passed to the group members, after they pass the peer to peer
   review process.















Harney & Muckenhirn           Experimental                     [Page 14]

RFC 2094                   GKMP Architecture                   July 1997


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

                      Figure 4:  Group Establishment

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

   The group controller receives the command.  It verifies that the
   signature, thereby ensuring the message was sent by the claimed
   source and the message has not been modified in transit.

   Creation of group keys  The controller initiates the creation of two
   keys for use in the group.  The creation of a cryptographic key
   requires that the key be sufficiently random.  Randomizers, capable
   of creating high grade cryptographic key, tend to be hardware based
   and are not likely to be practical for this protocol.  There are
   several established key creation protocols based in software (e.g.,
   Diffe-Hellman, FireFly, RSA). All these software based algorithms
   involve two hosts cooperating to create a cryptographic key.  These
   software algorithms are more appropriate for this protocol.

   Also important, in the creation of these keys, is verification of the
   authorization of the key creation partner.  Authorization to posses
   the keys include permissions that equal or exceed the group traffic
   and identity verification.







Harney & Muckenhirn           Experimental                     [Page 15]

RFC 2094                   GKMP Architecture                   July 1997


   Distribution of group keys  The controller distributes the group keys
   to the net members.  The controller must verify the identity and
   permissions of each member prior to the key being distributed.


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


                          Figure 5:  Group Rekey

   Likewise, the net member must verify the controller's identity,
   authorization to perform this action, and permissions.

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

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

3.3.2 Group rekey

   Cryptographic key has a life span.  New key must replace "old" key
   prior to the end of its cryptographic life.  This process is rekey.

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

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

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









Harney & Muckenhirn           Experimental                     [Page 16]

RFC 2094                   GKMP Architecture                   July 1997


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

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

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

3.3.3 Deletion

   It is desirable to be able to delete group members for either
   administrative purposes or security reasons.  Administrative deletion
   is the deletion of a trusted group member.  It is possible to confirm
   the deletion of trusted group members.  Security relevant deletion is
   the deletion of an untrusted member.  It assumes that the member is
   ignore all deletion commands.