rfc2093.txt

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

   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: