SPARTA, Inc. Hugh Harney, Eric Harder INTERNET-DRAFT SPARTA, Inc., National Security Agency draft-harney-sparta-lkhp-sec-00.txt March, 1999 Logical Key Hierarchy Protocol Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Document expiration: August 30, 1999 Abstract This document presents a Logical Key Hierarchy (LKH) Compromise Recovery (CR) implementation for the key management protocol suggested in the paper "Key Management for Multicast: Issues and Architectures"[10]. The goals of this paper include: defining the CR method, identifying the requirements, defining the operational protocol, and recommending an implementation for an LKH CR implementation. INTERNET-DRAFT LKH Protocol March, 1999 Copyright Notice Copyright Oc The Internet Society (1999). All Rights Reserved. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 2] INTERNET-DRAFT LKH Protocol March, 1999 Contents 1 Background 4 1.1 Security for Multicast . . . . . . . . . . . . . . . . . . . . . . 5 2 Compromise Recovery 5 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Compromise Recovery Policy . . . . . . . . . . . . . . . . . . . . 6 2.2.1Restoration of Secure Network Operations . . . . . . . . . . . . 6 2.2.2Restrict Comprise Recovery Actions to Authorized Individuals . . 6 2.2.3Multiple Co-Located Compromises . . . . . . . . . . . . . . . . 6 2.2.4Secure Compromise Recovery Life-Cycle . . . . . . . . . . . . . 7 2.2.5System Stability After a Compromise . . . . . . . . . . . . . . 7 2.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1Generation of LKH Arrays . . . . . . . . . . . . . . . . . . . . 7 2.3.2Generation of Support Materials . . . . . . . . . . . . . . . . 7 2.3.3Secure Compromise Recovery . . . . . . . . . . . . . . . . . . . 7 2.3.4Normal Operation Requirements . . . . . . . . . . . . . . . . . 8 3 LKH CR Protocol Specification 10 3.1 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1LKH Establishment Protocol . . . . . . . . . . . . . . . . . . . 11 3.2 CR Policy and Enforcement . . . . . . . . . . . . . . . . . . . . . 14 3.2.1Compromise Event . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2Single Message to Exclude Compromised Member . . . . . . . . . . 18 3.2.3New Group Key . . . . . . . . . . . . . . . . . . . . . . . . . 18 4 RECOMMENDATIONS 19 4.1 Develop Multicast Framework . . . . . . . . . . . . . . . . . . . . 19 4.2 Computer Trust Requirements . . . . . . . . . . . . . . . . . . . . 20 5 Addresses of Authors 22 Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 3] INTERNET-DRAFT LKH Protocol March, 1999 1 Background Multicasting technology has been a promise for many years now, a blend between unicast (point-to-point) and broadcast (on sender, many, unidentifiable receivers), multicasting allows a group of participants to communicate efficiently between themselves using public networks. Security has been a key area holding back widespread adoption of multicast. Group communications can be obtained using unicast methods (e.g., send an e-mail to each participant), but this has an impact on the network infrastructure, requiring sufficient resources to send each message from the sender to each recipient uniquely (an e-mail to 100 addresses requires the sender to actually send 100 messages). Using multicast, information is sent once into the multicast infrastructure and the infrastructure creates new messages/packets only when needed. Depending upon the networking technologies in use, multicast can be performed with a single message. Group communications can also be obtained using broadcast methods, though these methods tend to be simplex (one-way) in nature. In this case, the sender simply broadcasts his information and each receiver must determine if the message is of interest to them. This approach is inefficient due to the processing required at each broadcast recipient to filter out the wanted from unwanted messaging. Broadcasting is also not practical with some networking technologies (e.g., packet switched). Multicasting, in general, provides the capability for information to be disseminated to an identified group of participants efficiently. Multicasting is typically performed by creating a group where participants place information destined for all other participants. This group can be in the form of a newsgroup, IP address, or ATM address. The security challenge for multicasting is in providing an effective method of controlling access to the group (and it's information) that is as efficient as the underlying multicast. A primary method of limiting access to information is through encryption and selective distribution of the keys used to encrypt group information. Control of the key distribution process provides effective control of the group. The controlling policy for key distribution may differ among groups. For instance, military organizations may wish to distribute keys to particular individuals or units based on location or permissions; banks may wish to limit key distribution to particular trusted individuals; individuals may wish to limit distribution to particular family members. The range of options is limitless. Establishing this cryptographic group on an internet is not a trivial task. The entire group must converge on a single suite of security mechanisms for data protection. The single cryptographic key must be created and distributed to all members of the group in a secure manner. Some type of access control policy must be enforced as part of the key distribution mechanism. These policies must be created and disseminated to the groups in a manner that that can be trusted. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 4] INTERNET-DRAFT LKH Protocol March, 1999 The decision to create a cryptographic group on the internet is a decision based on the data that is going to be passed across the network and the needs of the communicating group. If the data being passed across the network is extremely important and not time sensitive, the security policy for creation, dissemination, and access control may be stringent. Alternately, if the data is not very sensitive, the security policies of the group may be more relaxed. This is an important distinction because there is a trade-off between security (assurance that the policy is in effect) and performance (time and resources necessary to implement the policy). The job of coordinating that trade-off falls to a management protocol. 1.1 Security for Multicast The issue of secure multicast communications for multicast groups has two parts. The first part consists of the mechanisms used to secure the data while it is in transit between the multicast group members. The second part, is the management of the security groups. Management in this case, refers to: 1. Creation and distribution of keys, 2. Enforcement of access control policies, and 3. Operational control (e.g., compromise recovery, rekey, identity infrastructure issues). This document presents a Logical Key Hierarchy (LKH) Compromise Recovery (CR) implementation for the key management protocol suggested in the paper ``Key Management for Multicast: Issues and Architectures''[10]. The goals of this paper include: defining the CR method, identifying the requirements, defining the operational protocol, and recommending an implementation for an LKH CR implementation. 2 Compromise Recovery 2.1 Definitions For the purpose of this document, a group is a gathering of communicating members with a single key. If the group key is compromised, then secure communication must be restored through a recovery action. A compromise occurs when a member of the group can no longer be trusted (e.g. group member loses their key or a group member's key is stolen). When this happens, the group needs to change the compromised keys, without giving Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 5] INTERNET-DRAFT LKH Protocol March, 1999 the new keys to the compromised member. This document proposes as LKH CR protocol for this purpose. 2.2 Compromise Recovery Policy A compromise is an event that makes a trusted member of a group untrusted and untrustable. All keys in that member's possession are considered ``lost``. Many different events may trigger a compromise including: equipment loss, discovery of inappropriate data transfer and theft. Compromising events are defined by the CR Policy. The CR Policy must be defined and understood prior to the compromise. The policy should define what type of compromise requires recovery, the speed with which recovery must be completed, and the level of acceptable risk to the system. The following sections identify the minimum CR Policy assumptions that would be necessary to support the LKH CR protocol presented in this document. 2.2.1 Restoration of Secure Network Operations Network operations should be restored with a minimal number of messages and with minimal delay. The goal of recovery is to resume operations in a secure mode quickly and efficiently. The size of the LKH array and the extent of the compromise will determine the number of messages required to recover the LKH. 2.2.2 Restrict Comprise Recovery Actions to Authorized Individuals The CR process changes the group membership and common group keys. An unauthorized CR action could subvert the group into communicating with unauthorized individuals or be used to deny service to the network. In order to prevent unauthorized CR actions and reduce system vulnerability, only authorized individuals should be allowed to identify that a compromise has occurred, assess the risk, and implement the necessary CR action. 2.2.3 Multiple Co-Located Compromises The CR process shall provide mechanisms to allow recovery from single- and multiple-entity compromises. Historically, compromises have occurred due to the breach of physical security measures at a particular location. In a group environment, it is possible that several group members will be physically co-located. The CR process should be capable of dealing with multiple co-located compromises. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 6] INTERNET-DRAFT LKH Protocol March, 1999 2.2.4 Secure Compromise Recovery Life-Cycle The entire life-cycle of the CR process must be secure. This includes the generation of CR materials, establishment of the CR group, execution of recovery from an event, and termination of CR for a group. 2.2.5 System Stability After a Compromise The outcome of any compromise event and the resulting CR action must leave the group capable of recovering from another compromise. 2.3 Requirements The following sections present the requirements necessary to support the LKH CR protocol. 2.3.1 Generation of LKH Arrays The LKH array generation mechanisms, as well as the LKH arrays, must be protected from unauthorized access. The CR Manager will have the only access to these mechanisms. Further, the computers on which these mechanisms reside must also be sufficiently protected from unauthorized access. 2.3.2 Generation of Support Materials The LKH CR process will be supported by certificates. The certificate registration process must provide mechanisms to ensure that there is unambiguous identification of individuals and authorities. The mechanisms and processes within the certificate registration process must also be verifiable and protected from unauthorized access and disclosure. 2.3.3 Secure Compromise Recovery The CR process includes the exchange of sensitive materials (LKH key array). To ensure that the compromise recovery process is secure, it must include mechanisms for: 1. Identifying all group members; Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 7] INTERNET-DRAFT LKH Protocol March, 1999 2. Identifying all CR agents; 3. Verifying the authority for all sensitive acts; 4. Verifying the integrity of all data exchanges; 5. Protecting all information that could be used to attack the CR system; and 6. Verifying the assurance level of all CR computer components. 2.3.4 Normal Operation Requirements The requirements identified in this section support the distribution, management and storage of the LKH arrays prior to a compromise event. These requirements must also be fully satisfied upon completion of a CR action. 2.3.4.1 Minimal Exposure of LKH Arrays The LKH arrays are sensitive information and, if left unprotected, can be used to attack or compromise the secure group. The use of routers and other network components to distribute the LKH arrays should take place with the understanding that the compromise of the component could lead to group attacks. In order to help minimize the risk of exposure, the LKH arrays should be held by as few computers as possible. Each CR Manager that maintains an LKH array must provide adequate physical, procedural, and computer trust protection mechanisms to protect the array. 2.3.4.2 Authentication of Identities For all key management actions, the identities of the receiving and sending parties need to be mutually understood. This requirement could be met by verifying the public key of a party during key generation. 2.3.4.3 Verification of Authorization The management actions supporting CR are critical to group security. The identification and participation authorization of each group member involved in a critical action must be verified. This requires a clear security policy understood across the group. This policy can be static or dynamic based on a policy dissemination mechanism. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 8] INTERNET-DRAFT LKH Protocol March, 1999 2.3.4.4 Computer Security Trust Requirements The LKH key arrays are critical. If these arrays reside unencrypted on a computer at any time, then that computer must be trusted to protect the group's data. This requirement would be supported by maintaining only the LKH arrays on group member's computers. Each group member's computer must be trusted to protect the group's data. 2.3.4.5 Cryptographic Structure of Groups It is anticipated that very large groups may choose to implement this LKH CR technique to support their CR process. In order to provide the best management and oversight, the large group should be constructed as the union of multiple smaller groups. Each of the smaller groups will have its own LKH array structures. These smaller LKH array structures will provide the capability to: 1. Localize the CR processes; 2. Generate and maintain smaller LKH arrays; 3. Localize the CR reporting procedures; 4. Localize CR management; and 5. Implement cryptographic gateways to minimize any single group traffic key exposure. 2.3.4.6 CR Message Requirements There are security requirements placed on CR messages to ensure that the messages are sent and received by the individuals with the appropriate authority levels. CR messages should provide the following information: 1. Source verification; 2. Authority verification; 3. Confidentiality of data from unauthorized access; 4. Verifiable integrity of all data exchanges; 5. Protection of all information that could be used to attack the CR system; and Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 9] INTERNET-DRAFT LKH Protocol March, 1999 6. Verifiable assurance levels of all CR computer components. The CR messages do not have a secure association (SA) with the group and, therefore, confidentiality must be provided within the recovery key schema. 2.3.4.7 Compromise Event Discovery and Reporting A deliberate compromise event may be difficult to discover because it is in the interest of the attacker to keep the compromise a secret. As long as the compromise remains undiscovered, the attacker will continue to have access to the group's data. An accidental or unintentional compromise will likely be reported as soon as the action is identified. However, regardless of the source of the compromise, the CR Manager must have sufficient mechanisms established to identify a compromise. The CR Manager must then assess the extent of the compromise to identify the necessary CR actions for recovery. All CR actions will result in a temporary disruption of the group while the group member's identities are verified and the keys are changed and disseminated. A complete discussion of compromise discovery and reporting is outside the scope of this document. Formal compromise discovery and reporting policies should be developed to support this process. The LKH CR technique presented in this document relies on input from a compromise discovery action to identify the compromised group member. 3 LKH CR Protocol Specification The logical definition of a secure group is multiple members communicating via a common key scheme. The focus of the LKH CR protocol is the CR protocol of this group. The methods used to create, distribute, verify, and authenticate the common group key are outside the scope of this document. 3.1 Group Establishment A large group can be serviced by several independent CR Agents each controlling a subset of the CR domain. This architecture distributes the processing and communication requirements of CR actions across the group thus avoiding communication and processing bottle-necks. For example, in an hierarchical tree CR protocol, a 2-layered LKH structure with the CR Manager, ``Member 1``, at the top. The second layer members (1.1 to 1.5) are all subject to CR actions initiated by ``Member 1``. Each of the second tier members themselves have sub-nodes and hence, have LKH Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 10] INTERNET-DRAFT LKH Protocol March, 1999 databases. The top node in the LKH is identified as ``Member 1`` for the discussion in the following sections. ``Member 1`` (Node 1 in the LKH schematic) will act as the CR Manager. The second level nodes act as CR Agents. 3.1.1 LKH Establishment Protocol The CR Manager and each of the CR Agents, will either create or obtain the LKH databases and distribute the appropriate keys to the members in their domain. These keys are extremely important to the continued secure operation of the group. As such, the distribution of these keys needs to be a secure process. The keys must be kept confidential. All the members need to have an unambiguous identification of any party downloading keys to them. The CR Manager and CR Agents need to have unambiguous identification of the members to which they will distribute keys. The members need to verify that the CR Manager and CR Agents are authorized to act in those roles. Each of these requirements is similar if not exactly equal to the requirements needed to distribute the original group key. To avoid redundancy of action, wherever possible, the CR data will be distributed with the symmetric key. 3.1.1.1 Generation of LKH Array The CR Manager generates the keys needed to construct a LKH array. There are two methods for generating an LKH array for very large groups. First, the CR Manager could generate a very deep array capable of encompassing all the potential members of the group. Second, the CR Manager can generate a smaller array capable of recovering the first tier of a group. These first tier members can act as delegated CR Agents, each generating LKH arrays for group members in branches below them. Of the two methods for generating an LKH array for large groups, the delegated CR mechanism provides greater scalability. The issue with this delegated approach is the CR Manager and CR Agents must be identified to the group members prior to the establishment of a group. One mechanism for accomplishing this is the use of a group policy token. The CR Manger and CR Agents could be identified and a single group authority could authorize them. This method of establishing LKH arrays will be illustrated in the following specification. The CR Manager generates and stores the list of keys. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 11] INTERNET-DRAFT LKH Protocol March, 1999 3.1.1.2 Distribution of LKH Array to Group Members The distribution of LKH array material should involve a peer-to-peer session association. The security of the group is built from a collection of peer-to-peer access control decisions. It is important to note that all access control decisions do not need to be made by the CR Manager or any central point. A multicast group can easily be constructed by a number of peer-to-peer access control decisions. The critical issue is to ensure that the access control decisions are made by members authorized to make such a decision for the group. The identity of group access control points is a matter for group policy. The simplest policy is that one site makes all group access decisions. A more scaleable solution identifies multiple points authorized to make these decisions for the group. An even more scaleable solution allows any group member (with proof that they have been accepted into the group) to make an access control decision for the group. Essentially, known group members could be allowed to vouch for new group members. In the case of distribution of CR material, the generator of the LKH array could distribute pieces of the array to authorized distribution points within the group for subsequent distribution. 3.1.1.2.1 Establishment of a Secure Association Modern SA protocols like the Internet Secure Association Key Management Protocol (ISAKMP) are suited to this task. The security characteristics of the establishment protocol for the SA should include: 1. Verification of all identities; 2. Validation of public certificates (if used); 3. Creation of a pairwise traffic confidentiality key; and 4. Transfer of identity and certificate information to multicast security management protocol. Once the SA is established, the multicast security management protocol can use that SA for secure confidential communications. 3.1.1.2.2 Data Structure of LKH Array Download Message When the identities of each side of the SA are known to the multicast security protocol, the multicast security protocol can use these identities along with the verified information on the public certificates to enforce group security policy. The group security policy includes information about authorized Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 12] INTERNET-DRAFT LKH Protocol March, 1999 CR mechanisms and distribution authorities. The management protocol needs to verify that the CR Manager is authorized to download the LKH CR arrays. The management protocol will take the identity and authority information verified in the establishment of the SA and make sure that it meets the policy criteria. In order to verify authority, there has to be something that identifies authorized CR Agents. This could be an internal configuration file or it could be a data structure that dynamically conveys a policy from an authorized source. In the case of a data structure, this policy data structure (token) could be sent with the LKH array. The data structure of the LKH array and (optional) Policy Token is: 2 bytes Data ID 16 bytes Grp ID 8 bytes Date/Time 1 byte Sig Alg ID 2 bytes Cert Infra ID 1 byte LKH Version 4 bytes LKH array length Variable LKH array 1 byte (policy token) 4 bytes (# packets) Variable (Packets 1-n) 1 byte (Pub Cert) 2 byte (# Packets) 1 byte (Packets 1-n) Variable Sig where: Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 13] INTERNET-DRAFT LKH Protocol March, 1999 Data ID: Identifies the packet as a CR data item. 1=LKH array, 2=LKH array with policy token, 3=LKH array with policy token and public certificate of signer Grp ID: Specifies the group the LKH array will address Date/Time: Self-explanatory Sig Alg ID: Specifies the signature algorithm used in this data item Cert Infra ID: Specifies the certificate infrastructure needed for verifying signature LKH ver: Version of the LKH CR protocol LKH Array Length: Total number of bytes in the LKH array LKH Array: Data ( ) signifies optional fields (Policy Token): Identifies the Policy Token (# Packets): Self-explanatory (Policy Token Packets 1-n): Self-explanatory (Pub Cert): Identifies public certificate data being sent (# Packets): Self-explanatory (Packets 1-n): Self-explanatory Sig: Signature field as identified earlier 3.2 CR Policy and Enforcement 3.2.1 Compromise Event The CR Manager, designated as Member 1, manages compromises occurring in the second tier of the hierarchy. In the second tier member designations (eg., 1.1), the number to the left of the decimal refers to the CR Manager. The number to the right of the decimal is the unique identifier of the CR Agent. The third tier is comprised of group members who do not act as CR Agents. In the third tier designations (eg., 1.1.5), the first number refers to the CR Manager. The second number designates the second tier CR Agent that owns the domain on which this particular member resides. The third number, in this example 5, is a unique identifier. This numbering scheme is useful for reporting compromises and allows the member designation of the bottom tier member to uniquely identify that member, the CR Manager, and the delegated CR Agent in the hierarchy above. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 14] INTERNET-DRAFT LKH Protocol March, 1999 3.2.1.1 Compromised Discovery After a compromise is discovered, a compromised report is received by Member 1, the CR Manager. The contents of this message include, at a minimum, the identity of the compromised member and, in the case of a multi-tiered architecture, a path to that member. The active member in this example is the CR Manager (Member 1). The CR Manager will verify that the CR report was received and is authentic. It will then initiate CR actions. 3.2.1.2 Recovery Protocol The CR Manager creates the CR message based on the information that was passed within the CR report. The CR Manager sends this message to all members of its domain utilizing the multicast communication address of the group. The CR message is sent on the group address and to the common key management port routing to the key management application resident at each member. Each member verifies that the CR message is authentic and that the signature on that message comes from a party that is authorized to send a CR message. This authorization decision is based on some known policy that has been previously configured for the group. One mechanism that is useful for configuring group policy is a policy token. Each CR message will contain a Date/Time stamp. A CR action may only be processed if its Date/Time stamp is later than the Date/Time stamp of the last CR action processed for the group. In the event of multiple CR actions, the CR messages should be processed in ascending order according to their date/time stamp. After the CR message has been verified, each member will decrypt their portion of the CR message. That single CR message will recover some portion of the compromised group and provide the first tier members the means to the reset group traffic keys to a new secure key. Any member in the path of a compromised member and will be unable to decrypt the new group traffic key. The LKH shown in Figure 1 represents virtual nodes as letters and members nodes as numerals. Assuming Member 1 is compromised, the symbolic form of the recovery message is: CompHdr{[Sec HdrB(MGK')B], [Sec HdrD(MGK',A')D], [Sec Hdr2 (MGK',C',A')2]}Siglkhc Notation: CompHdr{} = CR message header for message between {} Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 15] INTERNET-DRAFT LKH Protocol March, 1999 LKHController | | A------------B | | | | C------D E------F | | | | 1---2 3---4 5---6 7---8 Figure 1: Sample Compromise [SecHdr*(MGK').] = Data packet containing a security header that allows the decryption of the data package encrypted in key * (in this case, the data packet contains MGK: Multicast Group Key Prime) {}SigXo = Public key signature of data contained within {}, public key to verify is Xo. The data structure of the CR message follows: 1 byte CR Msg ID 16 bytes Grp ID 8 bytes Date/Time 1 byte Encr Alg ID 1 byte Sig Alg ID 1 byte Hash ID 2 bytes Cert Infra ID 1 byte CR Msg Type 1 byte Tree type 1 byte LKH Ver 4 bytes # Packets Variable Packets 1-n Variable Sig Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 16] INTERNET-DRAFT LKH Protocol March, 1999 CR Msg ID: CR Message ID distinguishes this message from other key management messages. Suggest an integer value with: 66=CR. Grp ID: Group identification value is a 16 byte string that identifies the specific group the CR message is to recover. Suggest this field be the group common name. Date/ Time: This field specifies the date/time this message was sent. Encr Alg ID: Encryption Algorithm Identification. This field specifies the exact cryptographic algorithm to be used by this message. An integer value suffices. 1=DES CBC, 2=triple DES. Sig Alg ID: Signature Algorithm Identification. This field identifies the algorithm used to sign this message. Suggestion 1=DSS. Hash ID: Hash Identification specifies the hash algorithm used. Suggestion 1=SHA. Cert Infra ID: Certificate Infrastructure Identification specifies type and location of certificate infrastructures. CR Msg Type: CR Message Type specifies type of CR message. Suggest: 1=Group Recovery, 2=Individual Recovery, 3=Maintenance, 4=Delete Group Key. Tree Type: This specifies the mechanism used by the CR process. LKH Ver: LKH Protocol Version. Suggestion 1=first. # Packets: Number of Packets specifies the number of information data items in the payload of the CR message. Packets 1-n: Each individual packet will take the following form: 1 byte Packet type 4 bytes Length of packet Variable Data Packet type: Specifies the data within the packet. Suggest: 1=encrypted key(s), 2=cryptographic changeover time, 3=unencrypted data. Packet Length: An integer specifying the number of bytes in the data packet. Sig: The signature block contains the actual signature in the algorithm specified in the Sig Alg ID data field. It should take the following form: 1 byte Signature format 4 bytes Length of data Variable Data Signature format: This field defines the exact data contained in the data field. Suggest: 1=DSS, 2=DSS Harney/Harder draft-hwithapublicrcertificatenofesigningyparty.-sparta-lkhp-sec-00.txt [Page 17] INTERNET-DRAFT LKH Protocol March, 1999 3.2.2 Single Message to Exclude Compromised Member The CR Manager has been notified of the compromised status of a tertiary member (eg., 1.1.1). The CR Agent in the compromise path generates a message using keys stored in its database that will exclude the compromised member from receiving the new group key. CompHdr{[SecHdrB(MGK0)B];[SecHdrD(MGK0;A0)D];[SecHdr1:1:2(MGK0; C0; A0)1:1:2]}SigX1:1 The CR message is sent out over the multicast communication address. All nodes in the group and in the subgroup receive that message and each authorized member decrypts the new traffic key. It is possible that the CR Agent could act as a cryptographic gateway for its sub-nodes. A cryptographic gateway changes the cryptographic traffic key for a branch of a group. A message encrypted with the group key of the second tier would come to the CR Agent who would then take all the data and re-encrypt that data in the group key common for its branch. The CR Agent's CR message will be restricted only to group members in its domain. There are two possible scenarios to support this restriction. In the first, the CR Agent could be a cryptographic gateway and therefore would have a group address for it's branch. The group address could offer a limited distribution option to preclude external transmission. In the second scenario, the CR Agent could establish a special local group address for the branch. 3.2.3 New Group Key When suborninate CR Agents are used all members in the path of a compromise must be brought back into the secure group. To accomplish this, the CR Manager (Member 1) creates a SA with the delegated CR Agent using a SA protocol like ISAKMP. Once a SA is established, the CR Manager sends a combination message to the delegated CR Agent (Member 1.1). This combination message tells the CR Agent that one of a its sub-nodes has been compromised and also passes the new secure group key. The CR Agent verifies that the CR Manager is the originator of this message and then updates it's group key. The CR Agent then begins CR actions for his domain. The symbolic form of the message is: CompHdr[(SecHdr1 (MGK')1, CompRpt)Sig1]1 Notation: Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 18] INTERNET-DRAFT LKH Protocol March, 1999 CompHdr{} = CR message header for message between {} SecHdr*(MGK') = Data packet containing a security header that allows the decryption of the data package encrypted in key * (in this case, the data packet contains MGK: Multicast Group Key Prime) {}SigXo = Public key signature of data contained within {}, public key to verify is Xo. The message structure for this combination message is exactly the same as the group recovery message defined in Section 3.2.2. This message utilized a new data packet type, Packet Type 3, to transmit the CR report to the CR Manager. 4 RECOMMENDATIONS 4.1 Develop Multicast Framework In the interest of standardization and efficiency, it is reasonable to propose a standard multicast security framework that could organize the establishment of security for multicast groups. In such a framework, CR would be a component of the overall security profile for a group. The LKH CR protocol could be an option for supporting CR within a standardized framework architecture. The LKH CR protocol is part of a complete multicast security management protocol. It provides CR services for a group without respect to the distribution methodologies or underlying communication protocols. The LKH CR protocol does make some assumptions about services provided by the more general multicast security management protocol. This protocol should include mechanisms to support the following requirements: - Verifiable and understandable security policy; - Unambiguous identification of members; - Verification of authority to perform relevant actions; and - Confidential delivery of information to group members. These basic services are fundamental to securing groups with keys. A well-orchestrated protocol should incur the overhead of these services once and pass all necessary information to the group members. The LKH CR does not implement these mechanisms due to the assumption that these services are available during secure key establishment. Implementing these services Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 19] INTERNET-DRAFT LKH Protocol March, 1999 within the LKH CR protocol is redundant. 4.2 Computer Trust Requirements Multicast security protocols do not allow each member of a group to verify the identity and authority of every other member of the group. This means that each member of the group must \trust"some other party (group member or not) to verify another group member. This cooperative enforcement of security policy across the group requires a base-level of trust in those verifying authorities. It is important that every group member, CR Agent, or CR Manager with access to either the group key or the LKH key array (in unencrypted form), is capable of protecting that information from unauthorized disclosure. This requires that all proper rules must be enforced as part of the group security protocol. These computers must also be trusted not to divulge the keys via an unofficial route (e.g., a hacker exploiting a weakness in another application). Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 20] INTERNET-DRAFT LKH Protocol March, 1999 The following documents were used in the preparation of this document: References [1] [RFC 2093] Harney H., Muckenhirn C., and Rivers T., Group Key, Management Protocol Specification, RFC 2093, Experimental, July 1997. [2] [RFC 2094] Harney H., Muckenhirn C., and Rivers T., Group Key Management Protocol Architecture, RFC 2094, Experimental, July 1997. [3] [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, Proposed Standard, November 1998. [4] [RFC 2412] Orman H. K., The OAKLEY Key Determination Protocol, RFC 2412, Informational, November 1998. [5] [RFC 2409] Harkins D., and Carrel D., The Internet Key Exchange (IKE), RFC 2409, Proposed Standard, November 1998. [6] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3) Addendum 1, Cooperating Families, SDN.301.1, Rev. 1.2, 1988-07-12. [7] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3), SDN.301, Rev. 1.5, 1989-05-15. [8] [RFC 1949] Ballardie, A., Scalable Multicast Key Distribution, RFC 1949, Experimental, May 1996. [9] [RFC 2459] Housley R., Ford W., Polk T., and Solo D., Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2450, Proposed Standard, January 1999. [10] Wallner, D., Harder E., and Agee R., Key Management for Multicast: Issues and Architectures, Internet Draft, Informational, September 1998. Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 21] INTERNET-DRAFT LKH Protocol March, 1999 5 Addresses of Authors Hugh Harney (point-of-contact) SPARTA, Inc. Secure Systems Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, MD 21046-1170 United States telephone: +1 410 381 9400 (ext. 203) electronic mail: hh@columbia.sparta.com Eric J. Harder R231 National Security Agency 9800 Savage Road Suite 6534 Fort Meade, MD 20755 United States telephone: +1 301 688 0847 electronic mail: ejh@tycho.ncsc.mil Document expiration: August 30, 1999 Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 22] - --------------F49BFCF24022E6D94642B018 Content-Type: text/plain; charset=us-ascii; name="draft-harney-sparta-msmp-sec-00.txt" Content-Disposition: inline; filename="draft-harney-sparta-msmp-sec-00.txt" Content-Transfer-Encoding: 7bit SPARTA, Inc. Hugh Harney, Eric Harder INTERNET-DRAFT SPARTA, Inc., National Security Agency draft-harney-sparta-msmp-sec-00.txt March, 1999 Multicast Security Management Protocol (MSMP) Requirements and Policy Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To view the entire list of current Internet-Drafts, please check the ``lid-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Document expiration: August 30, 1999 Abstract This Internet-Draft describes issues relating to the management of cryptographic keys in support of multicast communications. It describes the functional and security requirements of an electronic key management system for multicast. Copyright Notice Copyright Oc The Internet Society (1999). All Rights Reserved. INTERNET-DRAFT MSMP Requirements and Policy March, 1999 Contents 1 INTRODUCTION 3 1.1 Desirable Features . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Candidate Applications . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1Teleconferencing . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2Broadcast (NNTP, NASA broadcast) . . . . . . . . . . . . . . . . 5 1.3 Security for Multicast . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1Securing Multicast Packets . . . . . . . . . . . . . . . . . . . 6 1.3.2Managing Secure Groups . . . . . . . . . . . . . . . . . . . . . 7 2 REQUIREMENTS 7 2.1 Real World Requirements . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2Flexibility/Modularity . . . . . . . . . . . . . . . . . . . . . 9 2.1.3Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1Algorithm Definition . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2Key Generation Definition . . . . . . . . . . . . . . . . . . . 11 2.3 Authorization Definition . . . . . . . . . . . . . . . . . . . . . 12 2.3.1Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2Key Dissemination Architectures . . . . . . . . . . . . . . . . 13 2.3.3Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.5Rekey Approach . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.6Compromise . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1Self Defined . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.2Communications Protocol Independent . . . . . . . . . . . . . . 18 2.4.3Architecture Independent . . . . . . . . . . . . . . . . . . . . 19 3 POLICY COMPONENTS 19 3.1 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.1Operational Policy . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.2Key Dissemination Policy . . . . . . . . . . . . . . . . . . . . 20 3.2.3Access Control Policy . . . . . . . . . . . . . . . . . . . . . 21 3.2.4Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.5Compromise Policy . . . . . . . . . . . . . . . . . . . . . . . 21 4 DESIGN RECOMMENDATIONS 22 4.1 Global Policy Mechanism . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Limited Group of Security Mechanisms . . . . . . . . . . . . . . . 22 4.3 Policy Decomposition Of Multicast Protocols . . . . . . . . . . . . 23 5 Addresses of Authors 26 Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 2] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 1 INTRODUCTION Multicasting technology has been a promise for many years now. A blend between unicast (point to point) and broadcast (on sender, many, unidentifiable receivers), multicasting allows a group of participants to communicate efficiently between themselves using public networks. Security has been a key area holding back widespread adoption of multicast. Group communications can be obtained using unicast methods (e.g., send an e-mail to each participant), but this has an impact on the network infrastructure, requiring sufficient resources to send each message from the sender to each recipient uniquely (an e-mail to 100 addresses requires the sender to actually send 100 messages). Using multicast, information is sent only once into the multicast infrastructure and the infrastructure only creates new messages/packets when needed. Depending upon the networking technologies in use, multicast can be performed with a single message. Multicasting, in general, provides the capability for information to be disseminated to an identified group of participants efficiently. Multicasting is typically performed by creating a group where participants place information destined for all other participants. This group can be in the form of a newsgroup, IP address, or ATM address. The security challenge for multicasting is in providing an effective method of controlling access to the group (and it's information) that is as efficient as the underlying multicast. A primary method of limiting access to information is through encryption and selective distribution of the keys used to encrypt group information. Control of the key distribution process provides effective control of the group. The controlling policy for key distribution may differ among groups. For instance, organizations may wish to distribute keys to particular individuals or units based on location or permissions; banks may wish to limit key distribution to particular trusted individuals; or individuals may wish to limit distribution to particular family members. The range of options is limitless. Establishing this cryptographic group on an internet is not a trivial task. The entire group must converge on a single suite of security mechanisms for data protection. The single cryptographic key must be created and distributed to all members of the group in a secure manner. Some type of access control policy must be enforced as part of the key distribution mechanism. These policies must be created and disseminated to the groups in a manner that can be trusted. The decision to create a cryptographic group on the internet is a based on the data that is going to be passed across the network and the needs of the communicating group. If the data passed across the network is extremely important and not time sensitive, the security policy for creation, dissemination, and access control may be stringent. Alternately, if the data is not very sensitive, the security policies of the group may be more relaxed. This is an important distinction because there is Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 3] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 a trade-off between security (assurance that the policy is in effect) and performance (time and resources necessary to implement the policy). The job of coordinating that trade-off falls to a management protocol. This paper identifies and discusses the security and key management requirements for cryptographic groups. This includes group creation, group key creation, key distribution, policy creation, policy distribution, access control and group behaviors (management, rekey and compromise recovery). The goal is to craft the specific requirements for a Multicast Security Management Protocol (MSMP). 1.1 Desirable Features The desirable features for a MSMP include: - The security management protocol shall operate in a heterogeneous communications protocol environment - The security management protocol shall provide and utilize all reasonable security mechanisms to provide high assurance to security-relevant management events. - The security management protocol shall protect the group from all known security attacks pertaining to security management. 1.2 Candidate Applications In looking to the internet, the Inter-Domain Routing Protocol (IDRP) and the Distance Vector Multicast Routing Protocol (DVMRP) use multicast as a mechanism for parties to relay common information to their peers. Each party both sends and receives information in the multicast channel. As appropriate, a party may choose to leave or join the communication without the express permission of any of the other parties. More interestingly, the multicast internet protocol (IP) model has the receiver telling the network to add it to the distribution for a particular multicast address, whether it exists yet or not, and the sender is not consulted as to the addition of the receiver. Other applications of multicast communications in the internet (e.g., NASA select broadcasts) can be viewed as implementing the sender model because the sender selects the broadcast time, channel, and content, though not the destinations. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 4] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 1.2.1 Teleconferencing Video or audio teleconferencing is one model of multicast communications. Widespread use of the video or audio teleconferencing applications will result in many small groups existing at one time. These groups will be highly dynamic. Individual users may have several applications, or instances of applications, running simultaneously with different keys. Individuals will gain access to groups based on their network address and on personal characteristics (e.g., name, organization, physical location, authorizations) that may be contained in cryptographic certificates. There may even be a secondary mechanism for finer grained access management controlled locally. 1.2.2 Broadcast (NNTP, NASA broadcast) Another scenario for group keys is a large single keyed group. There are some interesting environmental constraints on key management imposed by the characteristics of extremely large groups (e.g., network news and broadcast). Network news transmissions represent the case of extremely large groups where each recipient receives the same data package. The keying of a secure network news group is complicated by the unidirectional characteristic of the communications. The sheer size of network newsgroups precludes any sort of standard reply from each recipient, as these acknowledgments would easily consume all available network bandwidth for popular groups. cooperative enforcement of the group security policies would require that all entities enforcing the access control policy were trusted to do so. This requirement may seem difficult to manage. Yet, the group with access to the data decryption key are trusted to protect that data. It seems logical that those same members should be trusted, by default, to protect the key that is protecting the data. Essentially, the group members trusted to protect the data being encrypted are available, and trusted, to enforce the groups' access control policy. The problem devolves to how do we use those members to speed group establishment. The security of the key is inversely proportional to the number of holders of that key. This observation leads to some potential alternatives for controlling the keys protecting information in such a group. One alternative for large groups is to compose it of smaller groups connected by ``cryptographic gateways''. (1) In principle, if any single endpoint goes - ------------------------------ 1. Cryptographic gateway refers to a device that is trusted to decrypt and re-encrypt traffic from one ``enclave'' to another. Such a device may be a specialized multicasting gateway, providing security translation service between a local network and the multicast backbone. Also, such a device may be Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 5] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 bad, the compromise is confined to that communication group. In effect, the compromised cryptographic key would have limited utility. The geographical location of that communication net bounds the utility of the key. Systems that require actual broadcast of secure packets (e.g. satellite downfeeds and some cable architectures) could not use the meshed large cryptographic group. 1.3 Security for Multicast The issue of secure multicast communications for multicast groups has two parts. The first part consists of the mechanisms used to secure the data while it is in transit between the multicast group members. The second part is the management of the security groups. Management in this case, refers to: - Creation and distribution of keys, - Enforcement of access control policies, and - Operational control (e.g., compromise recovery, rekey, identity infrastructure issues). 1.3.1 Securing Multicast Packets When a group of entities share a cryptographic key, for encryption of data traffic over a multicast address, they all share use of that key. Multicast communications allow any member of the group to encrypt a message and have it decrypted by multiple destinations. The sender ID is included in an IP packet but any member of the group can create a packet with any sender ID making it impossible to unambiguously distinguish the source of the transmission based on the key used to decrypt the transmission. This implies that a separate mechanism must authenticate the source for transmission in a cryptographic group. Several mechanisms exist that can authenticate individual sources of transmission in a cryptographic group. The most obvious and widely used mechanism is the digital signature. Digital signatures have the advantage of being received by a wide audience and being created by a very narrow audience. They have the disadvantage of taking a long time (as compared to encryption) either to sign or to verify. Depending on the type of communication going on, the time required to use a digital signature may - ------------------------------ employed where there are issues of cryptographic releasability, allowing for groups to be created, that use several cryptographic algorithms. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 6] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 make it impractical.(2) For communications that are not time sensitive, it may be reasonable to apply a digital signature. Network news maybe appropriate for digital signatures. 1.3.2 Managing Secure Groups The MSMP encompasses all the issues of a cryptographic group. The management of multicast secure groups is most likely an application layer protocol. Each group of members needs an instance of the management application layer protocol. Those protocol instances need to cooperate to successfully enforce the group's policies and provide keys and group management information. There are many management issues associated with the securing of a multicast group, including: - Key generation procedures, - Key distribution to all group members, - Commonly understood group mechanisms, and - Orchestrated group actions. The next section outlines the details of the target requirements for such a group management protocol. 2 REQUIREMENTS A clear collection and definition of the multicast security and key managment requirements will help in the definition of the MSMP. Many people have an idea of how to solve multicast key management problems for specific systems. The requirements presented in this paper were collected from the requirements for multicast key and security management from different types of systems. Several multicast security proposals were also reviewed to include their stated requirements.[1, 2, 3, 4, 5, 8] - ------------------------------ 2. The use of digital signatures for streaming applications may be impractical on a ``packet-by-packet'' basis, though it may be possible to perform a digital signature verification on a periodic basis over ``chunks'' of the previously transmitted stream. Also, the use of a running cryptographic checksum, initialized by an authenticated message (signed precursor), may also serve this purpose. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 7] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 2.1 Real World Requirements There are two broad requirements of the real world: efficiency and utility. MSMP must present a useful functionality set for most applications. It must contain enough options to allow it to operate across heterogeneous systems and configurations. Unfortunately, the desire to provide a functional tool set for the widest range of applications conflicts with other concerns, namely efficient use of resources and performance. 2.1.1 Performance - MSMP shall establish small groups in a few seconds. - MSMP shall support large groups that never converge. - MSMP shall support confirmation of group convergence (merge) in large groups, where required by group policy. - The MSMP should be able to accommodate a variety of convergence states. 2.1.1.0.1 Resource Utilization It is desirable to perform managment operations when they have the least operational impact. It may be useful to describe a performance curve for multicast security management over the life span of a secure group. The set-up phase of the group is where a majority of the management functions should occur. Interactions that would interrupt the group (rekey, compromise recovery, leave, join) should be localized to members of the group requiring the service. These interactions should also be streamlined to minimize the impact on the legitimate group members. In the group communications of a multicast group, the security management set-up takes place coincident with the group set-up. During normal group communication, the security managment of the group is merely a watchdog effort ensuring the group is operating correctly. During a re-key, leave, or join, security management occurs, but it is minimal and localized, if possible. The group communications processing increases if there is a compromise of a group member. If compromise recovery is possible for a group, the security management protocol will become active in keying the compromised individual out of the group. In most instances, a new group is created that excludes the compromised entity. The security managment protocol would also support documentation of information for a forensic review of the compromise. In summary, the MSMP must: Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 8] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 - Front load processing requirements (set-up) and - Provide audit mechanisms. 2.1.2 Flexibility/Modularity MSMP must be flexible enough to apply to many different environments. It must be modular to easily allow users to adapt the protocol to their environment. One mechanism to create an efficient and highly flexible protocol is to provide a single architecture that supports multiple specialized sub-protocols. To some degree, it may make sense to make protocol "objects" optimized for a particular need. In summary, the MSMP must: - Support multiple environments and - Provide mechanisms for the expansion and optimization for special environments. 2.1.3 Scalability Scalability refers to the protocols' ability to do two things -- support groups with large numbers of users and support large numbers of individual groups. Unfortunately, these two architectures can be at odds with each other. 2.1.3.1 Many Group Members Some multicast groups have an extremely high number of sites. Usually, most group members are receive-only and very few are transmit. There are some interesting requirements associated with this type of group. The security protocol may need to operate "out of band" and each individual site will need to correlate keys to the appropriate group address. There are architectural issues with whether a group like this should even share a single key. Today's architecture relays a single message around the globe. This may not be desirable in the case of a secure group. A key shared by many people really will not protect much information. Of course, it is also true that if a key holder cannot be trusted to protect the key, nor can they be trusted with the information protected by the key. An alternative architecture to the single key per group is the large group built up of smaller groups connected by cryptographic gateways. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 9] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 | ___________________|___________________ | | | Key=1 Key=1/2 Key=2/3 _____|_____ _____|_____ _____|_____ | | | | | | Key=1 Key=1 Key=2 Key=2 Key=3 Key=3 Figure 1: Use of Cryptographic Gateways to Reduce Key Exposure Figure 1 presents this type of large group. These composite groups have the advantage of limiting the utility of any single cryptographic key and tighter control can be placed on access control by specifying local trusted controllers. The MSMP need do very little to support this type of group. Each local group is feasibly a normal cryptographic group. The cryptographic gateway can either be a local decision or it could be stated in the policy. See Figure 1 In summary, the MSMP must: - Enforce communications policy defined by group and - Link single key(s) to individual groups. 2.1.3.2 Large Numbers of Small Groups Another scalability issue is that the protocol must support a large number of groups each with a fairly small number of members. It seems reasonable to predict that the internet will probably have many IP video or audio teleconferences occurring at any one time. The scalabilty issues with this scenario deal with availability of resources. An approach that relies on a central server in establishing groups would likely experience problems as the number of groups increases and, given the dynamic nature of groups, the group's lifespan decreases. That central server would become very busy and a potential single point of failure. In summary, the MSMP must Support small group proliferation without creating communication or processing overloads. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 10] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 2.2 Security Requirements There are security requirements inherently tied to a protocol that manages keys [3,4,5]. The following sections attempt to identify all of these possible requirements. Protocols designed to service a particular environment will have a tailored subset of requirements. However, a generic MSMP must be flexible enough to satisfy these broad requirements. The use of cryptography to protect data shifts the burden of security to the management of the cryptographic key. In essence, control of the key is equivalent to control of the data, and key management becomes the pivotal point for cryptographic-based security. 2.2.1 Algorithm Definition Due to the nature of groups, negotiation of cryptographic algorithms is difficult, if not impossible. MSMP must define a common algorithm policy. This could be optimized to the environment. Alternatively, the Internet Secure Association Key Management Protocol (ISAKMP now IKE) could negotiate the algorithm suite. If ISAKMP was able to completely cover the domain of the potential user base of the MSMP, then ISAKMP would be an adequate solution. The problem arises when a user tries to utilize MSMP without having benefit of a pre-negotiation by ISAKMP. MSMP would have to either negotiate the algorithm suite itself or cause ISAKMP to do so. In summary, the MSMP should: - Select cryptographic algorithms based on negotiated group policy, and - Provide an interface for ISAKMP to establish the cryptographic environment. 2.2.2 Key Generation Definition Two general mechanisms exist for the generation of cryptographic keys. A cooperative peer exchange [8] of key information can create a cryptographic key. Alternatively, a single entity can use a key generation technology to generate a key by itself. The choice of which mechanism to use is determined by the security requirements of the group and the communication resources available to the MSMP. For each environment, a policy decision will have to be made. The MSMP must support both mechanisms as directed by a policy decision. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 11] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 In summary, the MSMP must enforce key generation policy. 2.3 Authorization Definition The definition of authorization mechanisms, and infrastructure, must be consistent across a MSMP domain. Due to the potential use of authorization tokens and certificates [ 9,10] for identity within the MSMP, the only way to make correct access control decisions would be to have a common authorization definition. It may be possible to define a mapping between authorization mechanisms to allow heterogeneous authorization infrastructures to interact. However, this mapping mechanism currently falls outside the scope of this security protocol. In summary, the MSMP must: - Enforce authorization policy, and - Support a common authorization definition, and/or - Support a common mapping of definition between authorization infrastructures. 2.3.1 Access Control Access control, as it relates to security and key management, denies the key from entities without permission to hold the key. Historically, asymmetric key management protocols have implemented a policy of peer review. Peers cooperate to create the key. They "know" each others' identity based upon information passed. This identity information was previously certified by a trusted third party. Each peer "knew" that it wanted (or was allowed) to create a secure session with the other entity. In the case of a multicast group, the peer-to-peer relationship for access control is impossible to implement. The number of messages required for every member in a group to identify, verify and perform access control for every other member group is prohibitive in terms of processing and bandwidth. Hence, the access control mechanisms must be different for multicast groups. In a multicast group, it is reasonable for the group owner to define the access control policy. To summarize, the MSMP must: - Support configuration of the access control policy, - Distribute the access control policy to group, and Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 12] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 - Verify access control. Since the MSMP has to control access to the key, it performs the access control decisions. These access control decisions lay the very foundation for group security. There are two different philosophies: rules-based and identity-based access control. 2.3.1.1 Identity-Based Identity-based access control decisions lend themselves to groups where all participants of the group are known in advance. These decisions are very clean and provide a high degree of assurance that only those group members listed have access to the data. This assumes, of course, that the mechanism for identifying group members is a strong one. Identity in this case can mean individual identities as defined by individual's certificates or it can refer to an IP address of a host machine. Any identity-based access control policy requires that all access control decision makers have of the list of approved identities. The MSMP must provide a mechanism to disseminate not only the policy, but also the actual list of approved group members to all access control decision points. 2.3.1.2 Rule-Based Rule-based access control [9,10] relies on some set of preestablished parameters known about each potential member of the group. A certificate architecture infrastructure provides a framework to make rule-based access control decisions. The asymmetrical signed certificates, signed by a trusted entity, provide information about each individual. An issue with rule-based access control is that the rule enforcement must be consistent across the entire group. This is easily accomplished if a single point is making all the access control decisions. However, with multiple access control decisions being made by multiple members of the group, the MSMP must provide a mechanism to disseminate the access control rules and access control policy. 2.3.2 Key Dissemination Architectures Just as there are different levels of data, there are different levels of security (trust in the access control) that apply to a group. There is a natural trade-off between how fast the group can be established and the degree of assurance of the group. These two factors tend to oppose each other in secure group management. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 13] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 In a small highly secure group, it may be desirable to have a single trusted authority or a small subset of trusted authorities to control access to the group key. This architecture leads to a very tightly controlled group. Such groups have a very difficult time scaling for a large group. Access control requirements and control of the group, may be relaxed to allow some or all group members to disseminate the key based on the passing of some rudimentary access control rules. This would result in an increase in the speed of establishing an extremely large group. In either instance, the host making access control decisions to the cryptographic key needs to be trusted to make those decisions. The definition of trust is up to the owners of the data. It could take the form of formal computer security trust levels or it could be defined locally. In summary, the MSMP must: - Support configurable key dissemination architectures and protocols, and - Conform to computer security trust requirements imposed by the architecture. 2.3.3 Trust The mechanisms used to support and implement a MSMP must be ``trusted'' which means that the mechanisms are responsible for enforcing security and the level of security enforced by the system is dependent on the flawless execution of these resources. If the MSMP must enforce trust policies, it needs to be cognizant of the trust topology of its resources. If a sub-group of routers has the necessary trust mechanisms to protect keys, it is a candidate for a key dissemination protocol. However, this would impose a trust topology on the multicast internet. Use of these trusted routers would need management. The trust levels need monitoring (to verify the trusted state is exists), and the list of trusted routers must be available to all entities that desire to create groups. To summarize, the MSMP must: - Enforce policy concerning data protection and computer security trust level; - Maintain verification of the trusted state of "trusted" entities, in accordance with data protection accreditation; and - Maintain state information for its domain in order to know ``who'' to trust. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 14] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 2.3.4 Authorization Multicast groups require authorization of all important security actions. The multicast protocols must provide a mechanism where each group member can verify the identity of the entity asking it to perform important actions and check this identity against a pre-stored list of permissions. In peer security protocols, the authorization mechanism is relatively simple. Each peer [6, 7] will make the decision to create a secure session with another peer based upon the IP address or user ID of the peer. Since there is direct communication between peers during secure association establishment, there is perfect knowledge of the identity of the communication partner. In the case of MSMP, there is a requirement for a different authorization mechanism. Group members, in many instances, accept a key as valid without participating in the key's creation. There is a degree of trust on the part of the group member that the key is valid and does indeed belong to the group claimed. A MSMP could fail if it does not have a full set of authorization mechanisms. The SMKD protocol [8] is designed for core base trees (CBT). The security protocol utilizes CBT routers to disseminate group keys. The CBT routers all undergo a mutual suspicious exchange verifying identities and authorization to receive the key. The group members strongly authenticate themselves to the CBT routers when they request a group key. However, the CBT routers do not strongly identify themselves to the group members. Nor do the new members have information from a trusted source authorizing the router to distribute the group key. In this protocol it is conceivable that a CBT router could become a rogue router. When the group member makes a request to join a group, the rouge router could give it a bogus key for that group and create an entire sub-group with this bogus key. It could trick members of the false group into communicating sensitive information on the bad key. In short, not having a robust authorization mechanism and utilizing the mechanism, could lead to masquerade attacks. In summary, the MSMP must enforce authorization policy concerning group establishment, key dissemination, rekey and compromise recovery. 2.3.5 Rekey Approach Traditionally, a cryptographic key was treated as if it had a shelf life. More accurately, a cryptographic key is changed when too much data was protected by that single key. The most straightforward mechanism to achieve this changeover is to cancel the old group and create new group in its place containing all the old members. However, the creation of a cryptographic group, especially a large one, is an arduous task requiring a great deal of access control decisions, messages, processing and processing resources. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 15] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 This is a time consuming process. In many cases, it is preferable to minimize the disruption of the communication group by sending out a single message that will change the group's key. This process is called rekeying a group. When the rekey occurs, the single secure message containing the new group key is created. That message is transmitted to the group. Included in that message is some sort of cryptographic changeover time. This time is far enough into the future that most, if not all, of the group members are sure to receive the rekey message prior to changeover time. At that cryptographic changeover time, all group members will switch to the new cryptographic key for the group. To allow for graceful transition between old and new group keys, there is usually a short period of time when either key decrypts messages. This allows messages that were in transmission, encrypted under the old group key, to be received at their destinations and decoded immediately after the cryptographic changeover time. However, all messages being sent after crypto-changeover time use the new key for encryption. Usually, only large groups securing critical communications use rekey. The MSMP should support the concept of rekey particularly for critical groups that cannot withstand an interruption in service. 2.3.6 Compromise For the purpose of this discussion: - A compromise is the loss of trust in an entity with access to keys. This loss of trust (implies an assumption that the key has been exposed) invalidates the key. - A compromise is not an administrative decision to remove or replace an entity with access to key. A loss of trust in that entity is not assumed. Administrative decisions do not necessarily imply that the key held by an entity is invalid. The compromise of a secure group member is a more serious problem than the discovery of a compromised member for pairwise secure communication. In the case of pairwise communication, the secure association is deleted and no further action need take place. If a group member is compromised, the compromised member needs deletion from the group, but at the same time the other group members need to be able to continue their communications without a disruption of service. The seriousness associated with disruption of service and the urgency of removing a compromised member is a trade-off. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 16] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 There are several issues dealing with the handling of a compromised group member that could lead to many requirements on the MSMP. The general goal of dealing with a compromised group member is to return the group to a secure state. This compromised entity is denied access to future group information. Normally, one creates a separate group that includes all members of the original group minus the compromised member. This imposes several management requirements on the security management protocol. The security management protocol must be able to either recognize the compromise of a group member or accept a report that a group member is compromised. There are at least two separate means for dealing with compromises. One mechanism recently put forth [10] replaces the compromise recovery keys within the group. These keys split the group in such a manner that it would be easy to send a single message to multiple group members to get them on a new secure group transmission key. This mechanism would reduce the amount of time needed to reconstitute the secure group, after discovery of a compromise. However, this mechanism also requires management of these compromised recovery keys and the storage of compromise recovery by all the group members. Such a compromise recovery mechanism would be extremely valuable in the case of long-term static groups. This is especially true if the communications are critically important. Another compromise recovery mechanism is simply to cancel the compromised group and create a new group that is exactly equal to the old, minus the compromised member. This mechanism has simplicity on its side, but certainly is slower and causes more disruption to the group communications. In short, the MSMP must enforce compromise recovery policy as defined at group establishment. 2.4 Protocol Requirements The multicast security protocol has requirements levied upon it based more in the good design of a protocol rather than focused on the security aspects of the protocol. The following sections attempt to catalog these design goals. 2.4.1 Self Defined The MSMP should provide a complete tool set for the management of keys and security for cryptographic groups. It should generate and contain all the information the protocol needs to function. The one possible exception could be the certificate's infrastructure, if one is needed. In the case of the certificate infrastructure, a very good case exists for the utilization of existing infrastructures rather than trying to reinvent it. The MSMP Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 17] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 must: - Provide mechanisms to allow group-wide enforcement of group policy, and - Support existing certificate infrastructures. 2.4.2 Communications Protocol Independent The MSMP should be independent of the communication system it is being transmitted over and any protocol that it might be servicing. A majority of the work done in this area has been under the auspices of the IPSEC Working Group. However, the MSMP not only services IP layer security, but will also serve session and application layer security. The MSMP will also reside on hosts serviced by heterogeneous communication protocols. As an application protocol itself, MSMP should be completely divorced from the nature of the communication. The MSMP should not target a specific communication protocol. However, that does not mean that an option under the MSMP cannot target a specific communication environment. For example, the general protocol could offer an option for those systems that operate solely over ATM or CBT networks. These homogeneous networks offer distinct advantages for a security management protocol. A security management protocol could utilize a trusted backbone of routers [8] to either set groups up more quickly or to ease the recovery from a compromise. The MSMP should offer mechanisms that allow customized protocols. It is also important to realize that different cryptographic groups, depending on their utilization, have different requirements and natures. For instance, a large IP network may have the luxury to limit the number of endpoints with identical keys, thereby limiting the scope of a compromise. In other systems (e.g. cable system or especially those utilizing satellite downfeeds), there is no capability to limit the scope of compromised keys by limiting the size of key groups. The MSMP must: - Remain independent of any specific communication protocol or infrastructure; - Support operation as a source to destination protocol; and - Support homogeneous systems with optimized solutions. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 18] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 2.4.3 Architecture Independent The MSMP should provide multicast security management regardless of the environment it is serving. This protocol should satisfy at least 95 percent of the security architectures that require secure keys. For example, the MSMP should be able to support networks that push a group key onto the end points and where the end points pull the group. A large group could be built up of multiple cooperatives or it could simply be a large commonly held group of symmetrical keys. Again, the MSMP should be able to satisfy both cases. The MSMP should be configurable to support extremely high security groups, even though they incur a degradation in terms of speed. Conversely, it should be configurable to support groups that trade high security for speed and ease of group establishment. Obviously, a single scheme for creating secure groups and distributing keys to those end points will not be adequate to satisfy all the different architectures and environments the MSMP will be supporting. A single, universally accepted, protocol construct is required that allows access to sub-protocols optimized for different environments. 3 POLICY COMPONENTS Security mechanisms and security protocols all enforce some policy or policies within their domain. A clear definition of the enforced policies is critical to the successful design and implementation of a security protocol. The following section attempts to define policies that are being enforced by the MSMP. 3.1 Security Policy Security policy is a statement of the rules enforced by security mechanisms. There are multiple rules the MSMP will be able to enforce. In a dynamic system, groups define these policies based on the data that particular group will protect. The security policy can be static, and therefore assumed, or it can be dynamic and tailored to the requirements of the group. A dynamic security policy would allow the group owner to identify one or several key locations as well as authorizing new group members as needed. If MSMP has a dynamic security policy, a mechanism must define and disseminate this policy across the group. The MSMP must understand the policy and verify the authorization of that policy. A group security policy will make statements about the key the group will Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 19] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 share. For example, it is reasonable to see a policy that identifies a key for financial data. The MSMP must implement this policy across the group uniformly. 3.2 Architecture The more interesting policies MSMP will enforce involve the structure of the group itself. The MSMP will enforce policy roles, key distribution behaviors, access control, rekey, and compromise recovery. 3.2.1 Operational Policy All of the proposed multicast security protocols [1, 2, 8] assumed a structure of the key management protocol itself. A single entity creates the key and makes it available for dissemination to group members. The various proposals disagree about key dissemination, if routers are used to make access control decisions, and how access control decisions are decided. There is no reason that the MSMP need operate the exact same way as it creates keys for different groups in different environments. A mechanism that conveys to the MSMP the operational policies will facilitate a more dynamic protocol. 3.2.2 Key Dissemination Policy Another group policy is key dissemination. A single entity may create the keys, but the key can be disseminated to the group members in several manners. One key dissemination policy could be that a single trusted entity performs all key dissemination and associated access control decisions. This single point to dissemination policy is not performance oriented and may not be acceptable for larger groups. Another policy is to delegate responsibility for key dissemination to a subset of routers. This policy assumes trusted routers. The trusted routers must protect the key and make access control decisions in accordance with the sensitivity of the data been protected. Yet another policy, is that any group member disseminates the group key to any potential group member that meets a certain set of criteria. The particular policy for key dissemination is highly dependent on the sensitivity of the data to be protected. Depending on the data being protected, the same application could have a very different trust requirement placed on the dissemination of key. The MSMP could change its dissemination mechanisms or indeed its utilization of sub-protocols based on a policy statement about key dissemination and trust requirements. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 20] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 3.2.3 Access Control Policy Perhaps the most critical policy definition of the group is that of access control. The access control policy defines the user or host that have access to the cryptographic key. This policy can be identity- or rule-based or a mixture of both. In any case, the access control policy must be unambiguously stated so that only authorized group members receive the key. There are several ways to define access control policy. It can be based on a human identity, IP address, permission parameters, job title, or company name. The requirement is that the parameter be unambiguous and verifiable. The most common mechanism is a certificate. The information in a certificate supports an access control decision because a trusted third party verifies the accuracy of that information. The MSMP could operate between multiple certificate infrastructures providing there is a policy that clearly stated the acceptable certificate parameters in each infrastructure. In short, the access control policy states who should have access to the keys and the mechanisms used to prove that. 3.2.4 Rekey Policy As described in earlier sections, a rekey is a useful action when a cryptographic key is of long duration or is protecting a great amount of data. The decision to rekey is appropriate for any particular group and the mechanism that rekey will utilize is the rekey policy. Rekey involves the creation of the new group key and the creation of a globally acceptable message to disseminate that key to all the current group members. A single group entity needs to coordinate this process. After all there can only be one valid group key at a time. The rekey policy would need to state clearly the individual authorized to perform the rekey, the time of the rekey, and the time allotted for graceful key changeover. 3.2.5 Compromise Policy Compromise recovery policy involves several decisions. There is the decision whether to pre-place a compromise recovery key hierarchy or to delete and rebuild the group. Another decision, is who has the authority to declare the group compromised and how was that decision communicated to the group. Perhaps the most difficult part about compromise recovery is discovering the compromise. The rules for discovering a compromise and reporting it are beyond the scope of this security protocol. However, the MSMP will need to Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 21] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 have the capability to accept notification that the group is compromised. How that notification is communicated or utilized by the MSMP is a policy decision. Compromise recovery key structures can be pre-placed in a secure group along with the normal group encryption keys. However, the MSMP must define the nature of the key structures' needs and pass it to the group at the time of group establishment. 4 DESIGN RECOMMENDATIONS The analysis and review of the MSMP requirements and policies have resulted in two recommendations regarding the direction of the multicast security effort. The first recommendation is to create a globally acceptable policy mechanism that is accepted across the environments and would completely define the cryptographic group. The second recommendation deals with the design and implementation of the MSMP. 4.1 Global Policy Mechanism One thing that became clear during the analysis of multicast group requirements is that there are many policy decisions involved with group establishment. The multicast environment, unlike the pairwise environment where a peer-to-peer negotiation is uncomplicated, requires more coordination between the group members. Certainly, a single group member can make the cryptographic key. There are multiple ways the MSMP could disseminate cryptographic key to the group. There is the issue of whether or not the group needs a rekey and, if it does, how to orchestrate the rekey. There is the whole issue of compromise recovery orchestration. Many of these decisions are highly dependent upon the sensitivity of the data, the duration of the group, and the criticality of the communication. There is a strong argument for each of these options. The MSMP should be capable of being configured to satisfy most environmental requirements. Because the entire group needs a common policy and group definition, it makes sense for a single mechanism to provide this information. It would be best if this policy definition mechanism performed all MSMP configuration actions. Hence, one recommended goal for the MSMP is that a single mechanism is defined that will inform the MSMP of the group policy. 4.2 Limited Group of Security Mechanisms The following recommendation deals with the protocol design and implementation. A small subset of security protocols should be designed and optimized for specific practical environments. These specialized protocols come from a generally accepted group specification message. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 22] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 This recommendation suggests a highly modularized MSMP with a small, fully optimized, sub-protocol. There are benefits to doing this, including having a universally accepted definition of multicast groups. The end points could then either participate in a group (providing possession of the optimized sub-protocol), go get the appropriate sub-protocol, or not join the group. End systems could load those modules that are relevant to them and ignore all the others. This leads to a protocol structure that works efficiently for specific environments, provides universal protocol recognition, and allows conservation of user resources. >From the point of view of developing an international standard, the modularized approach leads to a highly useful and efficient standard and protocol. A high degree of interoperability exists due to the universally accepted group definition. Each environment could have a the MSMP targeted for that environment. Homogeneous environments could use CBT routers or intermediate routers to distribute to key. Heterogeneous environments could have the end systems generate group keys without the knowledge of the routers. Extremely large unicast networks could utilize unique communication infrastructures like group set-up servers. Extremely high security systems could include a compromise recovery key structure. 4.3 Policy Decomposition Of Multicast Protocols The following table illustrates how some multicast protocols would decompose into the policy components previously identified. Each protocol makes different assumptions of it's environment and those assumptions lead to different policies. Yet, these policies can be represented using the same decomposition format. GKMP Operational - Certificate Infrastructure ID, Group Controller IP address: a.b.c, Group 1st member IP address: a.b.c.d, Group Owner Common Name: X, Dissemination - Group Controller only (push or pull) or any member Access Control - Mutual suspicious, IP address list or Rules: IP a.b.*, Common Name: *.acme.com Rekey - Token required, uses GKEK sent during group establishment Compromise Recovery - Destroy group, create new, with certificate revocation capability during establishment SMKD Operational - CBT routers relays key, routers undergo rigorous authentication Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 23] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 Dissemination - Download from responding CBT router Access Control - Host sends signature to router Rekey - NA Compromise Recovery - Destroy group, create new Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 24] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 The following documents were used in the preparation of this document: References [1] [RFC 2093] Harney H., Muckenhirn C., and Rivers T., Group Key, Management Protocol Specification, RFC 2093, Experimental, July 1997. [2] [RFC 2094] Harney H., Muckenhirn C., and Rivers T., Group Key Management Protocol Architecture, RFC 2094, Experimental, July 1997. [3] [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, Proposed Standard, November 1998. [4] [RFC 2412] Orman H. K., The OAKLEY Key Determination Protocol, RFC 2412, Informational, November 1998. [5] [RFC 2409] Harkins D., and Carrel D., The Internet Key Exchange (IKE), RFC 2409, Proposed Standard, November 1998. [6] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3) Addendum 1, Cooperating Families, SDN.301.1, Rev. 1.2, 1988-07-12. [7] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3), SDN.301, Rev. 1.5, 1989-05-15. [8] [RFC 1949] Ballardie, A., Scalable Multicast Key Distribution, RFC 1949, Experimental, May 1996. [9] [RFC 2459] Housley R., Ford W., Polk T., and Solo D., Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 2450, Proposed Standard, January 1999. [10] Wallner, D., Harder E., and Agee R., Key Management for Multicast: Issues and Architectures, Internet Draft, Informational, September 1998. Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 25] INTERNET-DRAFT MSMP Requirements and Policy March, 1999 5 Addresses of Authors Hugh Harney (point-of-contact) SPARTA, Inc. Secure Systems Engineering Division 9861 Broken Land Parkway, Suite 300 Columbia, MD 21046-1170 United States telephone: +1 410 381 9400 (ext. 203) electronic mail: hh@columbia.sparta.com Eric J. Harder R231 National Security Agency 9800 Savage Road Suite 6534 Fort Meade, MD 20755 United States telephone: +1 301 688 0847 electronic mail: ejh@tycho.ncsc.mil Document expiration: August 30, 1999 Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 26]