rfc2094.txt

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

   Administrative delete  Administrative deletion removes the group keys
   from trusted group members.  This deletion consists of two messages
   the first sends a command to the group encrypted in the groups TEK.
   The command essentially says:  acknowledge receipt and then delete
   group keys.  This command is signed by the group controller to
   prevent unauthorized deletions.

   The acknowledgment message is also encrypted under the group TEK and
   is sent to acknowledge receipt of the command.  We could acknowledge
   accomplishment of the command if the net is willing to accept the
   burden of creating pairwise keys between the exiting group members
   and the group controller.

   Compromise recovery  Compromise recovery is the deletion of untrusted
   group members.  This actually involves the creation of an entirely
   new group, without the untrusted member.  Once the new group is
   created, net operations can be shifted to the new group, effectively
   denying the untrusted member access to the data.







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


   There is always a trade-off between security and continued net
   operations when a member is found to be compromised.  The security
   first position states that if a member is compromised, the group must
   be destroyed and then a new secure group created.  However,
   operational concerns sometimes out weigh the security concerns.  The
   operational position is that the group will continue to operate with
   the compromised member and will shift to a new secure group when it
   becomes available.

   The GKMP does not mandate either position.  However, the speed and
   flexibility of the GKMP does allow a new secure group to be created
   quickly.  Thereby, restricting the potential damage done by a
   compromised member.

   Once a member is found to be compromised, that members certificate is
   added to a Certificate Revocation List (CRL). The CRL is an
   asymmetrically signed piece of data, signed by a security manager.
   The list is made up of compromised resource ID's, a version of the
   CRL, and perhaps an identifier of the security manager.  The CRL is
   accessed every time a new key is negotiated.  If one of the key
   creators is on the CRL the key is destroyed and interaction
   terminated.

   The idea behind a CRL is each host would keep records of all open
   associations and compromised resources.  The host would then make
   sure that it does not have and will not create a secure association
   open with anyone who is on the CRL. The CRL concept of becomes more
   complicated in the case of groups.  This is because it is not
   necessary for every member in the group to know who the other group
   members are.  Hence, a group member does not have sufficient
   information to identify compromised group associations.  The GKMP
   proposes that the group controllers be responsible for reviewing the
   CRL and taking appropriate actions should a group member be
   compromised.

   Another issue with CRLs is the speed that they can be distributed
   across a network.  Every time a key is created the cooperating hosts
   exchange the version number of their current CRL. If the versions do
   not match.  The most current version is passed to the host with the
   old version.  Hence, CRLs propagate when keys are created.  If this
   is infrequently and there is a single CRL insertion point, the list
   may take a few days to move across the net.  The GKMP allows a
   speedier distribution of the CRL.

   The GKMP delegates control of groups to specific group controllers (a
   subset of the network).  These controllers are responsible for
   maintaining the security of the group.  If quicker distribution of
   the CRL were desired, the CRL generator ( security management



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


   function could seed the CRL at these controllers.  Controllers are
   points of key management activity and are logical CRL staging areas.

4 Issues

   What are the unresolved issues with this protocol?

4.1 Access Control

   One interesting issue with a grouped key protocol is access control.
   This is because we are moving away from having humans in the loop or
   having a central authority to check the propriety of the group.

   The group protocol must police itself.  It must ensure that each
   member of a group meets the classic military access control policy (
   i.e., a group member`s classification level must be higher or equal
   to the classification of the group that it's in).

   Is allocation of permissions by a higher authority sufficient to
   provide access control?  Or is a more discretionary mechanism
   necessary?

4.2 MLS

   A GKMP must be capable of operating in a multi-level secure
   environment.  The integration of a key management protocol capable of
   creating keys of several different classifications with an operating
   system capable of operating with multiple classifications in non-
   trivial.

   Classified label standards needed to be incorporated.  The
   classification labels used by the key management protocol should
   coincide with the labels used by the MLS operating system.  These
   interoperability issues need to be addressed.

4.3 Error Conditions

   A group protocol is more complex than a pairwise protocol hence there
   are more possible error conditions.  In a pairwise protocol you have
   two parties; they must communicate between themselves.  It is
   relatively simple to define an take care of all the potential error
   conditions.









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


   One assumption with any group protocol is the underlying internet is,
   to some degree, always broken.  The protocol designer has to assume
   that messages will be delayed or destroyed in transit, all member
   will not receive all multicast messages, and acknowledgment of
   actions may not be delivered.  This assumption is important if a
   protocol uses multicast functions to speed-up actions.

   The protocol must provide recovery mechanisms to allow group members
   to recover from loss of messages.  It must recover in a way that is
   transparent to the host and underlying communications network.

   For example, there is an issue whether or not we can create an
   application layer acknowledgment of multi-cast actions.  The issue
   deals with the required bandwidth that acknowledgment would take up.
   It may be much more friendly to the underlying communications systems
   to have each member identify potential errors and correct them in a
   pairwise manner.  The task of handling error conditions in a key
   management protocol is double difficult because many error conditions
   can be induced error condition (invoked by a third party trying to
   break the security of that system) to retrieve there key that is in
   transit or to block the successful dissemination of a key thereby
   attacking the system security mechanism.

4.4 Commercial vs.  Military

   Commercial and military key management differ in many ways.
   Commercial Key management protocols tend to emphasize inter-
   operability, freedom of action, and performance.  Military systems
   tend to emphasize security and control of operations.

   There will be a difference in cryptographic algorithms.  The military
   protocol would certainly use high grade encryption because of
   protecting classified information.  The commercial system would
   probably using algorithms.  and techniques certified for unclassified
   communication systems.  The main difference is in the algorithms
   length and type.

   A military protocol would require more management and structure than
   a commercial one.  The military has always adopted a hierarchical
   communication structure and the commercial system, especially if you
   look at the internet, work mainly by anarchist style.

4.4.1 Algorithm Type

   Another difference between military and commercial key management is
   the type of cryptographic algorithms.  The commercial world uses
   encryption algorithms like DES and in the future Skipjack.  The
   military uses other cryptographic algorithms that differ in key



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


   length and have more restrictions.  An example of this would be the
   identification of ACCORDION, as a military key encryption algorithm
   as used in the EKMS program run by NSA.

   Any experiments with a grouped key management protocol must consider
   the differences between military and commercial algorithms.  The
   commercial algorithms tend to be quicker to implement, run faster,
   involve less processing time, and allows an unclassified experiment.
   However, we must be careful not paint an unrealistic picture of the
   performance of the protocol based on these commercial algorithms.  A
   military algorithm tends to be more cumbersome to process, slow to
   process, require more bandwidth, a lot of unpleasant characteristics
   from the commercial stand point, but allow for a higher grade of
   cryptographic security.  One way of dealing with the disparity
   between algorithms is to use the commercial cryptographic algorithms
   and leave the fields the size used by a comparative DOD cryptographic
   algorithms and insert delays to simulate DOD algorithm processing
   times.

4.4.2 Management Philosophy

   Management for a military network is far more structured than a
   commercial network.  A military network would restrict the creation
   of network groups, the rekeying of those groups, and access to the
   data contained in those groups.  In contrast the commercial world
   would enable any member in the network to create a group and allow
   any other member of the net to join that group.

   The group Key Management Protocol must allow for both these
   architectures i.e., all for very structure command control hierarchy
   and another free form group creation.

4.5 Receiver Initiated Operations

   How do they actually work, what are the performance trades,
   experimentation needed.

   Who is the group leader?

   How do we elect a new leader?

   Will multiple leaders be created?

   Will rule based access control allow fine enough access disgression?







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


   Methods for distributed GKP/GRP dissemination need to be examined.
   This includes:

    o  resolving group identification issues, such as how to notify
       potential members of membership requirements without compromising
       any security-relevant information about the group;

    o  approaches for rapidly identifying GKP/GRP sources must be
       developed, such as a "Key ARP" whereby a new member broadcasts
       into the group a request for key service and existing members
       resolve which will provide service; and,

    o  Security effects of distributing access control decisions must
       also be reviewed.

5 Security Considerations

   This document, in entirety, concerns security.

6 Addresses of Authors

   Hugh Harney
   SPARTA, Inc.
   Secure Systems Engineering Division
   9861 Broken Land Parkway, Suite 300
   Columbia, MD 21046-1170
   United States
   telephone:        [phone] (ext.  203)
   electronic mail:  [e-mail]



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











Harney & Muckenhirn           Experimental                     [Page 22]