rfc2093.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,292 行 · 第 1/4 页

   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,