As per Relevance of the word communication, we have this rfc below:
Network Working Group H.
Request for Comments: 2094 C.
Category: Experimental SPARTA, Inc
July 1997
Group Key Management Protocol (GKMP)
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Table of
1. Introduction................................................. 1
2. Multicast Key Management Architectures....................... 3
3. GKMP Protocol Overview....................................... 9
4. Issues....................................................... 19
5. Security Considerations...................................... 22
6. Authors' Address............................................. 22
This specification proposes a protocol to create grouped
keys and distribute them amongst communicating peers. This
has the following advantages: 1) virtually invisible to operator, 2)
no central key distribution site is needed, 3) only group
have the key, 4) sender or receiver oriented operation, 5) can
use of multicast communications protocols
1
This document describes an architecture for the management
cryptographic keys for multicast communications. We identify
roles and responsibilities of communications system elements
accomplishing multicast key management, define security
functional requirements of each, and provide a detailed
to the Group Key Management Protocol (GKMP) which provides
ability to create and distribute keys within arbitrary-sized
without the intervention of a global/centralized key manager.
GKMP combines techniques developed for creation of pairwise keys
techniques used to distribute keys from a KDC (i.e.,
encryption of keys) to distribute symmetric key to a group of hosts
Harney & Muckenhirn Experimental [Page 1]
RFC 2094 GKMP Architecture July 1997
1.1 Multicast Communications
The work leading to this report was primarily concerned with
command and control and weapons control systems, these systems
to have top--down, commander--commanded, communications flows.
choice of what parties will be members of a particular
(a multicast group for example) is at the discretion of the "higher
level party(ies). This "sender-initiated" (assuming the higher-
party is sending) model maps well to broadcast (as
electromagnetic, free-space, transmission) and circuit
communications media (e.g., video teleconferencing, ATM multicast).
In looking to apply this technology to the Internet, a
different model appears to be at work (at least for some portion
Internet multicast traffic). IDRP and Distance Vector
Routing Protocol (DVMRP) use multicast as a mechanism for parties
relay common information to their peers. Each party both sends
receives information in the multicast channel. As appropriate,
party may choose to leave or join the communication without
express permission of any of the other parties (this begs
question of meta-authorizations which allow the parties
cooperate). More interestingly, the multicast IP model has
receiver telling the network to add it to the distribution for
particular multicast address, whether it exists yet or not, and
transmitter not being consulted as to the addition of the receiver
Other applications of multicast communications in the Internet,
example NASA Select broadcasts, can be viewed as implementing
sender model since the sender selects the broadcast time, channel
and content, though not the destinations
It is our intention to provide key management services which
both communications (and implied access control) models and
in either a circuit switched or packet switched environment
1.2 Security for
Multicast communications, as with unicast, may require any of
security services defined in ISO 7498, access control,
confidentiality, traffic confidentiality, integrity/
authentication, source authentication, sender and receiver non
repudiation and service assurance. From the perspective of
management processes, only data confidentiality, data authentication
and source authentication can be supported. The other services
traffic confidentiality, non-repudiation, and service assurance
be provided by the communications protocol, they may rely
cryptographic services but are not guaranteed by them
Harney & Muckenhirn Experimental [Page 2]
RFC 2094 GKMP Architecture July 1997
2 Multicast Key Management
2.1 Current
There are several electronic mechanisms for generating
distributing symmetric keys to several computers (i.e.,
communications groups). These techniques, generally, rely on a
distribution center (KDC) to act as a go between in setting up
symmetric key groups. Military systems, such as BLACKER, STU
II/BELLFIELD, and EKMS, and commercial systems, such as X9.17
Kerberos, all operate using dedicated KDCs. A group key request
sent to the KDC via various means (on- or off-line) The KDC acting
an access controller decides whether or not the request is
(i.e., all members of a group are cleared to receive all the data
a group). The KDC would then call up each individual member of
group and down load the symmetric key. When each member had the
the KDC would notify the requester. Then secure group
could begin. While this was certainly faster then anything
requires human intervention. It still requires quite a bit of set-
time. Also, a third party, whose primary interest isn't
communication, needs to get involved
Pairwise keys can be created autonomously by the host on a network
using any number of key generation protocols (FireFly, Diffe-Hellman
RSA). These protocols all rely on cooperative key
algorithms to create a cryptographic key. These algorithms rely
random information generated by each host. These algorithms
rely on peer review of permissions to ensure that the
partners are who they claim to be and have authorization to
the information being transmitted. This peer review process
on a trusted authority assigning permissions to each host in
network that wants the ability to create these keys. The real
of these pairwise key management protocols is that they can
integrated into the communication protocol or the application.
means that the key management becomes relatively invisible to
people in the system
2.2 GKMP-Based
The GKMP described below, delegates the access control,
generation, and distribution functions to the communicating
themselves rather than relying on a third party (KDC) for
functions. As prelude to actually distributing key, a few
must be assumed (for purposes of this document): there exists
"security manager" responsible for creating and distributing
parties authentic identification and security permission
(The security manager function may be accomplished through a
hierarchical system (a la STU-III) or a more ad hoc system
Harney & Muckenhirn Experimental [Page 3]
RFC 2094 GKMP Architecture July 1997
cooperating peer "domain managers," the implementation of
certification hierarchy is not addressed in this document.);
communicating parties are online for the keys formed and
by the GKMP
2.2.1 Sender Initiated
This section describes the basic operational concept for
key management for sender initiated multicast support. This model
multicast communications was the basis for our original work
multicast key management. From a security viewpoint the
application is able to control access to the transmission
both key distribution and communications distribution (not
the transmission to some addresses).
Identification of Group Key Controller -- The originator of
multicast group creates or obtains a group management
from its certification hierarchy. The certificate identifies
holder as responsible for generation and distribution of the
key (Naming standards are not addressed here, the name should
the naming structures appropriate for the supported
service. For example, IP-level encryptors should use
reflecting "host" identities (IP addresses, or DNS host names),
encryptor would use session names). The originator relays
membership list to the Group Key Management (GKM) application
Group Key Creation -- The GKM application, operating on behalf
the originator, selects one member of the group, contacts it,
creates a Group Key Packet (GKP). A GKP contains the current
traffic encrypting key (GTEK) and future group key encrypting
(GKEK). The GKM application then identifies itself as the group
controller, which the member validates, under cover of the GTEK
Group Key Packet (GKP) = [GTEKn,GKEKn+1]
As part of group key packet formation, usage parameters,
for the underlying crypto-system, are selected. Unlike
parameter negotiation, where common security-level/range,
services are arrived at, the originator's GKM application
these parameters and the member must comply
Group Key Distribution -- After creation of the GKP, the
controller contacts each member of the group, creates a Session
Package (SKP), validates their permissions (check member'
certificate against group parameters), and create a Group
Harney & Muckenhirn Experimental [Page 4]
RFC 2094 GKMP Architecture July 1997
Package for that member. A SKP contains a session TEK and a
KEK for a particular member. A GRP contains the GKP encrypted in
KEK and signed using the originator's certificate
Session Key Package (SKP) = [STEK, SKEK
Group Rekey Package (GRP) = {[GKP]KEK}
Group Rekey -- When the group needs to be rekeyed, the
GKM application selects a member, creates a new GKP, creates a
GRP (which is encrypted in the previously distributed next GKEK)
broadcasts it to the group
This procedure is fairly complex, but other than for the
of site-specific certificates, no centralized key
resources are needed. The only parties to the key
communications are the same parties which will be participating
the group
2.2.2 Receiver Initiated
This section describes key management operational concept
receiver initiated multicast communication support. The
initiated model presents some interesting problems from a
view point since the end-participants are not known a priori. Also
in a purely receiver initiated application (such as DVMRP), there
no concept of an "originator" and the participants in the group
be quite dynamic with participants changing on a minute by
basis
For secure group communications to take place, all members
obtain the same key. This may be achieved by either
deterministic key generation techniques (using a secret, shared seed
or by making one member of the group responsible for creation of
key. The use of a deterministic key generator presents
problems, particularly regarding loss of the seed (it
both past and future traffic). The assignment of a member to
role of key "controller" also presents drawbacks, but these relate
determining which one should be the controller and the need for
member to contact him. The remainder of this discussion will look
how the "controller" concept from above could work in the
initiated case
Selection of Group Key Controller -- A group member will be
responsible for initial group establishment and periodic
and dissemination of new GRPs. There is no need for the
controller to be the controller for all time, but at any one
only one controller may be active for each group. Selection
Harney & Muckenhirn Experimental [Page 5]
RFC 2094 GKMP Architecture July 1997
controller may be made through a voting system, by a simple
(the first to transmit to the group is the controller),
configuration
The current controller's identity must be made available to
members, and potential members, for initial group key load and
recovery. The information may be relayed by broacast on a
management "channel," or through a directory service
Group Key Creation -- The GKP is created and distributed in
the same way as in sender initiated operations. The
creates a GKP with the first group member to initiate contact.
GKM application then identifies itself as the group key controller
which the member validates, under cover of the GTEK.
negotiation is performed and the first group member is keyed
Group Key Distribution -- After creation of the GKP, as
members contact the controller, a SKP is created, member
are validated and a GRP is loaded to the member
For widely distributed groups, a form of distributed
may be used. Some number of regional GKM applications are
with the ability to validate the permissions of new members and
validation send to them the current GKP.(Access control is
defined in this document, but it is assumed that both
and discretionaly (rule-based and identity-based) access control
be supported.) These regional key distributors perform the
functions as the controller, except that they do not create the GKP
This concept can be expanded to the point where all current
are capable of downloading the GKP, and passing on that capability
Group Rekey -- When the group need rekeying the procedure would
identical to the sender initiated case. The controlling
application selects a member, creates a new GKP, creates a new
(which is encrypted in the previously distributed next GKEK)
broadcasts it to the group
2.3 GKMP
This section highlights areas which we believe the GKMP approach
advantages over the "traditional" KDC based approaches
2.3.1
Multicast protocols are a growing area of interest for the Internet
The largest benefit of a multicast protocol is the ability of
receivers to simultaneously get the same transmission. If
transmission is of a sensitive nature, it should be encrypted.
Harney & Muckenhirn Experimental [Page 6]
RFC 2094 GKMP Architecture July 1997
means that the all members of the group must share the
encryption key to take benefit of the multicast transmission
To date the only way of setting up a group of symmetric keys is
the assistance of a centralized key management facility.
facility would act as a key broker creating a distributing key
qualified group members. There are several problems with
centralized concept. These problems give rise to many of
following motivations for creating a distributed key
protocol
2.3.2 Increase the autonomy of key
The GKMP proposes to extend the pairwise key paradigm to
keys. This protocol can be integrated into the
protocols or applications and can become invisible to the host'
operator. We will use peer review to enforce our security policy
The GKMP allows any host on a network to create and manage a
group. Maintenance of these group keys can be performed by the
interested in the group. The groups themselves will be
autonomous. This simplifies the installation of this
allowing more host to use secure multicast communications
2.3.3
Latency refers to the time to set-up or tear down or to re-key
group. In short this corresponds to the length of time it would
to set-up a multicast address
The GKMP can allow delegation of group creation authority to any
in the network. In essence, when a host needs a group it will
the tools needed to create that group and manage it. Additionally
since the host only needs to create a single group it can
on that particular group
In the current centralized key distribution approach. The group
be requested from the central site. The central site would
that request in accordance with it's priority and current workload
Latencies would develop if the workload of the central site
unwieldy or if the communications to the site become overloaded
2.3.4
One of the problems with a centralized key distribution system is
concentration of key management workload at a single site.
process of creating key groups -- key creation, access review
communication to group members takes time and effort. As the
Harney & Muckenhirn Experimental [Page 7]
RFC 2094 GKMP Architecture July 1997
of groups on the network grows and the number of group members group
The workload at that central sight quickly reaches capacity
GKMP should allow a great number of groups to exist on the
without overloading any particular host. Delegation of the net
group creation and management workload places the burden
maintaining groups on the hosts interested in using those groups
Not only is this more efficient, but it places the burden in
appropriate location
The GKMP distributes the communication requirements to manage
across the network. Each group manages the group using the
communication resources needed to pass traffic. It is likely that
a communication group can support the traffic of a group, it will
able to support the minimal traffic needed to management the keys
that group
GKMP provides it's own access control, based on signed
permission certificates. This partially disseminates the burden
access control and permission management. A system wide
must assign the permission certificates, but day to day
control decisions are a GKMP responsibility
2.3.5 Operating
A centralized key distribution site contains, at one time or another
the keys for the net. This is a valuable target for someone
compromise. To protect this site physical and procedural
mechanisms are employed (e.g., guards, fences, intrusion alarms,
person safes, no-alone zones). These mechanisms do not come cheap
Allowing the hosts to create and manage their keys eliminates
need for an on-line centralized key distribution site. The
approach restricts access to the keys to the hosts using them (
minimal set). Since, the encryption mechanisms will have
incurred the cost to be physically secured there is no
cost levied on the system by the key management system
2.3.6 Communication
Because a centralized site is involved in creating, distributing
rekeying, and providing access control for every group, it
frequently accessed. The communication resources available to
site often become a bottle neck for the groups. Therefore a big
is usually installed to this facility
Harney & Muckenhirn Experimental [Page 8]
RFC 2094 GKMP Architecture July 1997
The GKMP proposes delegating most of the key creation, distribution
rekey and access control mission to the hosts that need the
communication. There no longer is a single third party that must
consulted prior to every group key management action. Hence,
communications requirements to manage the keys have shifted to
groups themselves. The need for special high capacity
has been eliminated
2.3.7
Delegating key management responsibility to the groups eliminates
centralized key management site as a single point of failure.
groups that will use the key are responsible for it. If
communications system fails for the key management it is also
for the communications
The GKMP will attempt to delegate as many functions to the group
possible. There will be some functions which still need to
performed outside of the group (granting of privileges).
functions can still fail. The GKMP will operate on the old set
permissions. These functions need not be in-line. They
performed separate from the key management actions and are
crucial to day-to-day operation
2.3.8
People are the most risky element for security. A
protocol eliminates many people from the key distribution chain
This limits "exposure" of the key
3 GKMP Protocol
3.1 Supporting
A secure key management protocol needs a number of
functions, especially in a military environment. The two
support functions are security management and network
management. In the commercial world a company could provide
support functions
The issue of Security Management is permission management, in
military environment separation of data occurs along
classification lines (i.e., TOP SECRET to UNCLASSIFIED). In
commercial world these levels are proprietary or need to know access
Network group management provides an interface to the
system and control of network resources. Some entity either
commercial or military system, the host or network operations center
Harney & Muckenhirn Experimental [Page 9]
RFC 2094 GKMP Architecture July 1997
must provide the key management protocol with a list of the
members. Also, if the network resources, bandwidth and processing
are considered scarce a management structure must allocate them
3.1.1 Security
Security management is a role performed for the entire network.
involves netwide issues of permission management, initialization
software, and compromise recovery. The GKMP relies on
management to operate. Refer to figure 1: Security management view
The GKMP must assume trusted handling of the protocol software
and during installation. If the GKMP is to use peer to peer
control the system must control the assignment of permissions.
permissions must be monitored and updated as needed. Finally
overview of these permissions must include the maintenance of
Certificate Revocation List
Secure start-up We need to control the process of loading
software onto a host and initializing it. The protocol needs keys
Security Manager --> --> --> --> --> --> --> --> --> --> -->
Secure Start-
Compromise
Figure 1: Security Management
public and private, to operate. It also must have
information of the host on whose behalf it will act
There are some life cycle and security concerns with the
while in transit, stored, distributed, and installed. A one
start-up procedure must verify the identity of the host.
and physical identification techniques will verify the identity
the host (i.e., the Armed Forces Courier Service (ARFCS) accounting
or registered mail). Upon key delivery the security manager
it's receipt and assumes responsibility for the key
After proper installation of the software a paper trail verifies
recipient. The computer would initiate an association with
security management function to initialize the protocol
(create a unique public and private key pair for network
and receive network permissions). This activation process uses
distributed with the software (good only for initialization)
secure an exchange with the security manager. The host then
a unique public and private pair and sends the public key to
Harney & Muckenhirn Experimental [Page 10]
RFC 2094 GKMP Architecture July 1997
security manager. The security manager creates a credential
uniquely identifies the host and it permissions. This credential
signed by the security management with its private key and can
verified by all net members with the public key
Permission management Each host on the network is given
permissions certificate signed by the security management
uniquely identify that host and identifies the access permissions
is allowed. These permission certificates are used by the
hosts to assign permissions to other hosts
This process assigns permissions to equipment or human beings
accordance with their duties. This process involves
clearances and human judgment therefore it is outside the scope
this protocol
The security management function, especially in military operations
would be responsible for managing permissions and classifications
each host. In the commercial world, permission
corresponds to projects or duties
Compromise recovery management If a group member is
compromised, the protocol must facilitate the exclusion of
compromised member and return to secure operations. The
management function will provide control of compromise recovery
Usually, physical inspections or accounting techniques
compromises. These separate systems report the compromise to the
management system. We must assume the loss of all key resident
that host. The security management function will rescind
permission allocated to this compromised host. We create a list
all know compromised hosts and distribution that list across
network. Each host is then responsible for reviewing the
of each association and enforcing access control to data
3.1.2 Group
The group manager interacts with other management functions in
network to provide the GKMP with group membership lists and
relevant commands. The GKMP deals strictly with cryptographic key
It relies on external communication and network management
to supply network related information. Primarily, it relies on
network management service to provide it with the addresses of
members (if the group is sender initiated).
Harney & Muckenhirn Experimental [Page 11]
RFC 2094 GKMP Architecture July 1997
The GKMP allows an external entity to determine the controller of
group. The controller of the group should be able to handle
additional processing and communication requirements associated
the role. If this is not a necessary function given
implementation, this assignment of controller duties can be set
some automated default. However, even if defaulted some
management entity determines how the role of controller is allocated
The group manager can receive group progress reports from the
controller. The GKMP provides a service for the network. It
sense that someone in the network is interested in the progress
this service. The GKMP can provide progress reports. It is up
the network management to determine the manner and recipient of
reports. Reference figure 2: Network manager interaction
Group Manager --> --> --> --> --> --> --> --> -->Network
/\
|
| Commands, Role
| Group member list,
|
\/
{[Group Controller] Network
Figure 2: Network Manager
Group to member mapping When the GKMP is implemented in
initiated group establishment mode, a list of group member
must be provided as part of the group establishment command.
GKMP will use these addresses to contact the group members and
the group
The creation of groups involves the assignment of a group address
update of router databases, and distribution of this group address
the group members. This is a classic function of network management
The GKMP group controller would be another recipient of
information
Protocol role allocation The Group Management Protocol assigns
to members of a particular group. These roles are binary one
either the control over the group or a member of a group.
external entity will allocate the identity of the group
and group receiver. This is a desirable aspect because
computers are more capable (i.e., central site, great deal of
power available to control a group). We allow some external
to allocate these roles to individual group members, this
important in the military application do to the fact that in
Harney & Muckenhirn Experimental [Page 12]
RFC 2094 GKMP Architecture July 1997
commercial application the allocating authority and group
may very well always be the same
Group key progress reporting The Group Key Management Protocol
to be able to report to somebody. If we create a group, we
report it to group requester. Contrarily if we are not able
Network = {[(Group 1 controller) Group 1 members],
[(Group 2 controller) Group 2 members],
[(Group 3 controller) Group 3 members], }
Figure 3: Distributed Group
create a group we should report that especially since failure
create a group at least as a first study will highly correlate with
failure of the underlying communications. The Group Key
Protocol does not have an ability to fix the
communications so the communication management function must
with these failures
3.2 Protocol
Creation and distribution of grouped key require assignment of roles
These identify what functions the individual hosts perform in
protocol. The two primary roles are those of controller
receiver. The controller initiates the creation of the key,
the key distribution messages, and collects acknowledgment of
receipt from the receivers. The receivers wait for a
message, decrypt, validate, and acknowledge the receipt of new key
One of the essential concepts behind the GKMP is delegation of
control. Since each host in the network has the capability to act
a group controller, the processing and communication requirements
controlling the groups in the network can be distributed
throughout the network. This avoids potential single points
failure, communication congestion, and processor overloading.
to figure 3: Distributed group management
3.2.1 Group
The group controller is the a group member with authority to
critical protocol actions (i.e., create key, distribute key,
group rekey messages, and report on the progress of these actions).
All group members have the capability to be a group controller
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
key synchronization. A group must operate on the same
cryptographic key. If part of the group loses or
changes it's key, it will not be able to send or receive data
another host operating on the correct key. Therefor, it is
that those operations that create or change key are unambiguous
controlled (i.e., it would not be appropriate for multiple hosts
try to rekey a net simultaneously).
3.2.2 Group
Simply stated a group receiver is any group member who is not
as the controller. The group receivers will: assist the
in creating key, validate the controller authorization to
actions, accept key from the controller, request key from
controller, maintain local CRL lists, perform peer review of
management actions, and manage local key
3.3
3.3.1 Group
The protocol to establish a group of host that share a
key must create a high quality key, verify that all
recipients have permission to join the group, distribute the key
all qualified members, and report on the progress. This
consists of two phases: creation of the key and distribution of
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
authorized commander and the group is within the controller'
permission range. Next, the controller creates a key. Then that
is passed to the group members, after they pass the peer to
review process
Harney & Muckenhirn Experimental [Page 14]
RFC 2094 GKMP Architecture July 1997
Group
|
|
\/ Create group
|--> --> --> --> --> --> -->Group
|
|
\/ Distribute
|--> --> --> --> --> --> --> Group
|
|
\/ Distribute
|--> --> --> --> --> --> --> Group
|
|
\/ Distribute
|--> --> --> --> --> --> --> Group
Figure 4: Group
Validate command The create group command is signed by the
commander ( they may be the same device). This signature should
asymmetric in nature. The public key to validate this command can
sent with the command itself, if the public bound to the identity
the commander
The group controller receives the command. It verifies that
signature, thereby ensuring the message was sent by the
source and the message has not been modified in transit
Creation of group keys The controller initiates the creation of
keys for use in the group. The creation of a cryptographic
requires that the key be sufficiently random. Randomizers,
of creating high grade cryptographic key, tend to be hardware
and are not likely to be practical for this protocol. There
several established key creation protocols based in software (e.g.,
Diffe-Hellman, FireFly, RSA). All these software based
involve two hosts cooperating to create a cryptographic key.
software algorithms are more appropriate for this protocol
Also important, in the creation of these keys, is verification of
authorization of the key creation partner. Authorization to
the keys include permissions that equal or exceed the group
and identity verification
Harney & Muckenhirn Experimental [Page 15]
RFC 2094 GKMP Architecture July 1997
Distribution of group keys The controller distributes the group
to the net members. The controller must verify the identity
permissions of each member prior to the key being distributed
Rekey
Group Controller --> --> --> --> --> -->{Group (group member 1-n)}
Figure 5: Group
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
encrypt. Hence, we must encrypt the key during distribution. If
suitable key exists between the controller and member, a new key
be created. This new key is cooperatively created between
controller and net member in a similar manner as the net keys
The controller creates a message for encryption in the key
between the controller and member. This message will include
management information and the keys
3.3.2 Group
Cryptographic key has a life span. New key must replace "old"
prior to the end of its cryptographic life. This process is rekey
Rekey has the advantage of using an existing
association to distribute key. Also, there is no requirement
verify the identity and authorization for the other members
Identify and authorization are assumed
A group rekey consists of two stages. First the Group
creates new group keys. Second these "new" keys are sent to
Group Members in a multicast message. Refer to figure 5:
Rekey
Creation of group keys The controller of the rekey will create
new keys in exactly the same manner as used during
establishment
Harney & Muckenhirn Experimental [Page 16]
RFC 2094 GKMP Architecture July 1997
Distribution of group keys The GKMP creates a message for the
address. This message uses one of the keys distributed during
establishment to encrypt the new keys. It also contains
authorization token identifying the controller as the rekey agent
new management data. All members of the group using a
protocol (if one exists) accept this message
The message which rekeys the group encrypts the new keys in
existing KEK. Since all group members possess the KEK the
group can decrypt this message
The token authorizing the group controller to perform this rekey
also included. This token is asymmetrically signed by the
commander. It uniquely identifies the group controller's
to rekey this group. It also identifies the group the level
traffic and rekey interval
3.3.3
It is desirable to be able to delete group members for
administrative purposes or security reasons. Administrative
is the deletion of a trusted group member. It is possible to
the deletion of trusted group members. Security relevant deletion
the deletion of an untrusted member. It assumes that the member
ignore all deletion commands
Administrative delete Administrative deletion removes the group
from trusted group members. This deletion consists of two
the first sends a command to the group encrypted in the groups TEK
The command essentially says: acknowledge receipt and then
group keys. This command is signed by the group controller
prevent unauthorized deletions
The acknowledgment message is also encrypted under the group TEK
is sent to acknowledge receipt of the command. We could
accomplishment of the command if the net is willing to accept
burden of creating pairwise keys between the exiting group
and the group controller
Compromise recovery Compromise recovery is the deletion of
group members. This actually involves the creation of an
new group, without the untrusted member. Once the new group
created, net operations can be shifted to the new group,
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
operations when a member is found to be compromised. The
first position states that if a member is compromised, the group
be destroyed and then a new secure group created. However
operational concerns sometimes out weigh the security concerns.
operational position is that the group will continue to operate
the compromised member and will shift to a new secure group when
becomes available
The GKMP does not mandate either position. However, the speed
flexibility of the GKMP does allow a new secure group to be
quickly. Thereby, restricting the potential damage done by
compromised member
Once a member is found to be compromised, that members certificate
added to a Certificate Revocation List (CRL). The CRL is
asymmetrically signed piece of data, signed by a security manager
The list is made up of compromised resource ID's, a version of
CRL, and perhaps an identifier of the security manager. The CRL
accessed every time a new key is negotiated. If one of the
creators is on the CRL the key is destroyed and
terminated
The idea behind a CRL is each host would keep records of all
associations and compromised resources. The host would then
sure that it does not have and will not create a secure
open with anyone who is on the CRL. The CRL concept of becomes
complicated in the case of groups. This is because it is
necessary for every member in the group to know who the other
members are. Hence, a group member does not have
information to identify compromised group associations. The
proposes that the group controllers be responsible for reviewing
CRL and taking appropriate actions should a group member
compromised
Another issue with CRLs is the speed that they can be
across a network. Every time a key is created the cooperating
exchange the version number of their current CRL. If the versions
not match. The most current version is passed to the host with
old version. Hence, CRLs propagate when keys are created. If
is infrequently and there is a single CRL insertion point, the
may take a few days to move across the net. The GKMP allows
speedier distribution of the CRL
The GKMP delegates control of groups to specific group controllers (
subset of the network). These controllers are responsible
maintaining the security of the group. If quicker distribution
the CRL were desired, the CRL generator ( security
Harney & Muckenhirn Experimental [Page 18]
RFC 2094 GKMP Architecture July 1997
function could seed the CRL at these controllers. Controllers
points of key management activity and are logical CRL staging areas
4
What are the unresolved issues with this protocol
4.1 Access
One interesting issue with a grouped key protocol is access control
This is because we are moving away from having humans in the loop
having a central authority to check the propriety of the group
The group protocol must police itself. It must ensure that
member of a group meets the classic military access control policy (
i.e., a group member`s classification level must be higher or
to the classification of the group that it's in).
Is allocation of permissions by a higher authority sufficient
provide access control? Or is a more discretionary
necessary
4.2
A GKMP must be capable of operating in a multi-level
environment. The integration of a key management protocol capable
creating keys of several different classifications with an
system capable of operating with multiple classifications in non
trivial
Classified label standards needed to be incorporated.
classification labels used by the key management protocol
coincide with the labels used by the MLS operating system.
interoperability issues need to be addressed
4.3 Error
A group protocol is more complex than a pairwise protocol hence
are more possible error conditions. In a pairwise protocol you
two parties; they must communicate between themselves. It
relatively simple to define an take care of all the potential
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
that messages will be delayed or destroyed in transit, all
will not receive all multicast messages, and acknowledgment
actions may not be delivered. This assumption is important if
protocol uses multicast functions to speed-up actions
The protocol must provide recovery mechanisms to allow group
to recover from loss of messages. It must recover in a way that
transparent to the host and underlying communications network
For example, there is an issue whether or not we can create
application layer acknowledgment of multi-cast actions. The
deals with the required bandwidth that acknowledgment would take up
It may be much more friendly to the underlying communications
to have each member identify potential errors and correct them in
pairwise manner. The task of handling error conditions in a
management protocol is double difficult because many error
can be induced error condition (invoked by a third party trying
break the security of that system) to retrieve there key that is
transit or to block the successful dissemination of a key
attacking the system security mechanism
4.4 Commercial vs.
Commercial and military key management differ in many ways
Commercial Key management protocols tend to emphasize inter
operability, freedom of action, and performance. Military
tend to emphasize security and control of operations
There will be a difference in cryptographic algorithms. The
protocol would certainly use high grade encryption because
protecting classified information. The commercial system
probably using algorithms. and techniques certified for
communication systems. The main difference is in the
length and type
A military protocol would require more management and structure
a commercial one. The military has always adopted a
communication structure and the commercial system, especially if
look at the internet, work mainly by anarchist style
4.4.1 Algorithm
Another difference between military and commercial key management
the type of cryptographic algorithms. The commercial world
encryption algorithms like DES and in the future Skipjack.
military uses other cryptographic algorithms that differ in
Harney & Muckenhirn Experimental [Page 20]
RFC 2094 GKMP Architecture July 1997
length and have more restrictions. An example of this would be
identification of ACCORDION, as a military key encryption
as used in the EKMS program run by NSA
Any experiments with a grouped key management protocol must
the differences between military and commercial algorithms.
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
performance of the protocol based on these commercial algorithms.
military algorithm tends to be more cumbersome to process, slow
process, require more bandwidth, a lot of unpleasant
from the commercial stand point, but allow for a higher grade
cryptographic security. One way of dealing with the
between algorithms is to use the commercial cryptographic
and leave the fields the size used by a comparative DOD
algorithms and insert delays to simulate DOD algorithm
times
4.4.2 Management
Management for a military network is far more structured than
commercial network. A military network would restrict the
of network groups, the rekeying of those groups, and access to
data contained in those groups. In contrast the commercial
would enable any member in the network to create a group and
any other member of the net to join that group
The group Key Management Protocol must allow for both
architectures i.e., all for very structure command control
and another free form group creation
4.5 Receiver Initiated
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
potential members of membership requirements without
any security-relevant information about the group
o approaches for rapidly identifying GKP/GRP sources must
developed, such as a "Key ARP" whereby a new member
into the group a request for key service and existing
resolve which will provide service; and
o Security effects of distributing access control decisions
also be reviewed
5 Security
This document, in entirety, concerns security
6 Addresses of
Hugh
SPARTA, Inc
Secure Systems Engineering
9861 Broken Land Parkway, Suite 300
Columbia, MD 21046-1170
United
telephone: +1 410 381 9400 (ext. 203)
electronic mail: hh@columbia.sparta.
Carl
SPARTA, Inc
Secure Systems Engineering
9861 Broken Land Parkway, Suite 300
Columbia, MD 21046-1170
United
telephone: +1 410 381 9400 (ext. 208)
electronic mail: cfm@columbia.sparta.
Harney & Muckenhirn Experimental [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
