Internet Engineering Task Force Patrick McDaniel (U.of Michigan) INTERNET-DRAFT Hugh Harney (Sparta) draft-irtf-smug-polreq-00.txt Andrea Colgrove (Sparta) November 2000 Atul Prakash (U.of Michigan) Peter Dinsmore (NAI Labs) Expires May 2001 Multicast Security Policy Requirements and Building Blocks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Policy has long been accepted as means of bridging the gap between changing user requirements and static implementations. Policy management infrastructures provide abstractions of underlying services. In this way, applications can freely adapt to the needs and capabilities of changing environments. The policy approach has been especially successful in the deployment of security services. This document identifies the requirements of the policy management infrastructure of the SMuG [SMuG] secure multicast architecture. The requirements of the processes by which policies are created and enforced are presented. Major design decisions are presented and alternate solutions are identified. Relevant works defining architectures and protocols for the distribution, evaluation, and enforcement of policy are reviewed. We identify potential building blocks and identify a sample policy data structure appropriate for secure multicast. 1. Introduction The emergence of a vast array of group oriented applications has made the need for the management of policy within secure multicast evident. A security policy defines the security relevant behaviors, access control parameters, and security mechanisms used to implement the group [HCH+00]. A policy management infrastructure is a McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 2] collection of electronic services supporting the creation, storage, distribution, and interpretation of such policies. This document identifies the issues and requirements of the policy management infrastructure of the Secure Multicast Research Group (SMuG) secure multicast framework [HCBP99]. Known as Multicast Security Policies (problem area 3), this work will define the form, meaning, and means of distribution for security policies. This work will also provide guidelines for the specification and interpretation of policy within the other framework problem areas. The following subsections identify the high-level requirements and constraints of SMuG policy framework. We conclude the section with a road-map of this document. 1.1 Requirements A central requirement of the policy framework is flexibility. As indicated by the SMuG working group charter, a wide variety of applications and environments must be supported. This chiefly means that the policy framework must be able to integrate with emerging technologies, protocols, and applications. Thus, identifying singular policy implementing solutions or representations is insufficient. However, there is a delicate balance between flexibility and simplicity. Approaches providing a high degree of flexibility are often baroque; too many options and exceptions often lead to complicated or flawed implementations and serve as a barrier to understanding. The types of groups supported by the SMuG framework will have a direct affect on the policy architecture. Groups spanning autonomous systems (AS) may require the negotiation of policy parameters to meet the (sometimes conflicting) requirements of the group participants. Conversely, lightweight groups may require policy to be stipulated prior to session establishment and distributed efficiently. Thus, a policy infrastructure should allow these groups (any many other session environments) to be realizable within a single, unified architecture. We define the following deisgn goals for the development of the SMuG policy infrastructure. a) The architecture must be secure. All policies should be distributed in a manner consistent with the security requirements of the participating entities. As needed, the policies should be authentic, confidential, and fresh. b) The architecture should be flexible. The security requirements of many different session and operating environments should be addressable. Integration of new services and protocols should not require modification of the policy infrastructure or protocols. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 3] c) The architecture should be simple. Inasmuch as possible, the policy specifications and component protocols should limit complexity. d) The architecture should be efficient. All reasonable efforts should be exercised in identifying efficient solutions for the distribution and evaluation of policy. 1.2 Constraints Dependence on any particular security infrastructure is undesirable. For example, any solution requiring the availability of a public key infrastructure (PKI) may not be acceptable in all environments. However, a solution requiring the availability of public key certificates may be acceptable. A number of approaches for secure groups and policy management have been successfully developed and deployed. Any solution requiring the abandonment of accepted protocols and infrastructures may not be useful to a section of the targeted community. Therefore, within reason, existing approaches and technologies should be compatible with any proposed solution. However, we must weigh compatibility with existing approaches against solution complexity and efficiency. In particular, compatibility with the policy management standards efforts (e.g. IPSec policy management architecture [SC98], IETF policy group [SWM+99]) is desirable. 1.3 Document Organization The remainder of this document is as follows. Section 2 illustrates the potential use of policy through a detailed example. Section 3 provides background and efforts relating to the management of policy in distributed environments. Section 4 proposes serveral policy building blocks and identifies issues relating to their definition and use. Section 5 outlines the requirements, design, and operation of a policy management infrastructure within the SMuG framework. 2. Group Policy: An Example This section illustrates the use of group policy through a simple video broadcast session. The described group sustains a relatively unaltered security context throughout the session. Note that, due to the complex and changing nature of their sessions, other applications will require more complex policies, be deployed in environments spanning administrative domains, or require negotiation. Initially, an employee of company X determines the need to sponsor a video broadcast. For the purposes of this example, the expected membership of the group includes the sales force of X. Exterior to the application and policy framework, all participants receive a session announcement stating the start time, uniquely identifying session information, and location information (e.g., multicast McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 4] address). The delivery and format of such announcements is outside the scope of the SMuG framework. However, there are a number of tools currently available for the announcement of such sessions [HJ98,HAN96]. Prior to the establishment of the session at the advertised time, a group policy is stated. The policy issuer states the group policy as the collection of security requirements, authorization and access control parameters, and desired mechanisms used to achieve each. These statements can be abstract. However, where abstract policies are used, the policy must state how abstract policies can be addressed. For example, the issuer can (abstractly) state all group content be "strongly confidential". Further, the policy states that strong confidentiality can be achieved either through the encryption of application content using either the 3DES or DESX algorithms. The use of abstract policies allows the issuer to state security requirements without dictating precisely how they are to be addressed. The entities that are allowed to join the group (members of the sales force), broadcast content (the entity generating the video stream), and perform group management (entity initiating the session, distributing session keys, etc.) are identified in the policy via ACL or access criteria. Once the policy is fully specified, it is given a unique identifier and authenticated (e.g., through issuer digital signature). The policy and authenticating information is then placed in a policy repository. When the session is to begin, the group management entity (identified in the policy) retrieves and authenticates the policy from the repository. Throughout, this entity acts as a logical group leader called the group controller. Using its local policy (statement of local capabilities, desires, and security requirements of groups) as input, the group controller converts all abstract statements into concrete mechanisms and parameters trough the translation algorithm. For example, for the confidentiality policy described above and based on its local policy, it is at this point where the controller decides to implement strong confidentiality by using the DESX algorithm. After translation, all aspects of group operation are fully specified and concrete. As directed by the translated policy, the group controller initializes the appropriate network interfaces and security mechanisms and waits for members to join the session. At the scheduled time, each potential member initiates communication with the group controller. Based on policy, a member may be required to authenticate itself to the group controller prior to receiving the group policy. The member is authorized by presenting credentials stating its position in the sales force. After being authenticated, the member receives the translated group policy and specification from controller. The member verifies the correctness of the policy specification by validating the associated information (e.g., validating the correctness of the policy identifier and McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 5] digital signature). The member compares its local policy with the received group policy. If the member has the ability to implement the group policy and the policy is consistent with its local requirements, she will continue by attempting join the group. If the policy is not found to be acceptable, the member refrains from participation in the group. An accepting member sends a join request and receives the group keying material. Note that all exchanges involving the acquisition of policy, group join, and keying material download are likely to occur over a secure point to point channel (e.g., IPSec [KA98] connection). After the join completes, the member begins receiving the video content and group control information. Policy is used at each member to assess the correctness of each message. All correctly formed messages created with the authorizations (i.e., credentials or keys) and format, are accepted, decrypted, and passed to the application as necessary. Where needed, the authorization and access control policy is consulted during message processing. For example, the acceptance of a new session key may be predicated on the presentation of the group controller credentials. Thus, the operation of session rekeying, recovery from lost control messages, and the detection and subsequent ejection of misbehaving members will be performed as directed by group policy. If the behavior of the group controller diverges from the policy, the membership can either exit the group or initiate recovery. When the session is completed the group controller signals to the group the disbanding of the group. All members accept (the correctly authenticated) disband message and terminate the reception and processing of group messages. 3. Background and Related Efforts 3.1 Policy Frameworks Due to the increasing size and complexity of enterprise networks, the feasibility of traditional network management platforms to control and configure network devices has been called into question. The overhead of solutions that require administrators to manage each type of device independently is quickly becoming intractable. This is similarly true for software. In many environments, the costs associated with the management of even basic network services can easily equal that of hardware devices. One approach addressing these costs is the use of policy. The design of several policy management architectures are outlined in the following sub-sections. 3.1.1 IETF Policy Framework Working Group The IETF Policy Framework working group is chartered with the development of a reference architecture allowing the management of network devices through abstract policies. The group's draft McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 6] framework specification [SWM+99] identifies the entities and functions of policy implementing components for IP network devices. Policy is defined in the working group's reference architecture through policy rules. A policy rule is a conditional statement identifying a set of possibly abstract actions to be executed in environments when/where the conditions are satisfied. For example, the policy rule (if) network is congested (then) drop all packets from subnet 1 received at border routers states that when network congestion is detected, all border routers should be configured to drop packets received with a "from address" in subnet 1. This rule differs from traditional network management in that it is stated abstractly; the statement of how network congestion is detected, how border routers are identified, and how the particular router interfaces should be configured during times of congestion is outside the scope of the rule. It is up to other policy components to interpret and enforce this policy. The reference architecture identifies four policy components; policy editors, policy repositories, policy consumers, and policy targets. A policy editor provides interfaces for adding, deleting, and updating sets of policy rules. The policy editor is also responsible for detecting (and potentially resolving) instances of global conflicts. A global conflict occurs when two rules imply different (but conflicting) action in the absence of any operational context. For example, two rules stating a subnet should receive best effort and guaranteed service for the same traffic constitutes a global conflict. Rule updates are delivered to the policy repository by the policy editor. The policy repository acts as persistent store for policy rules. Policy consumers (see below) obtain relevant rules in the process of evaluating policy. In general, the policy repository does not act on or interpret policy rules. For example, an LDAP server [YHK95] is suggested to be a reasonable solution. A policy consumer is responsible for acquiring, evaluating, and translating policy rules into device dependent action. The consumer acquires relevant rules from the policy repository, evaluates their contents, and enforces them as prescribed by their definition. The policy consumer is also responsible for detecting local conflicts. A local conflict occurs when there are of two rules that conflict in the presence of contextual information. For example, a rule stating that a device should be enabled only during maintenance window may conflict if a second rule states that it should be disabled if an attack on the network has been detected. In this case, a local conflict occurs when an attack is detected during a maintenance window. Detection and resolution of both global and local conflicts is an area of open research. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 7] Rules are enforced by the direct monitoring of the environment. When a rule's conditions are satisfied, the actions are translated into device specific commands. Generally, this requires the re-provisioning of the device. In the above example, the rule ``drop all packets from the subnet 1 received at the border routers'' would be translated into commands altering the internal tables of the border interfaces of the specified routers. In this case, the border routers would act as policy targets. A policy target is the entity altering its behavior or configuration in accordance with a stated policy. Hardware devices can have varying levels of support for policy. In the above example, it was assumed that the border routers had no native understanding of the policy rules. However, in other environments, the network devices can act as both consumers and targets by acquiring and interpreting policy directly. For example, the router (acting as the policy consumer) could translate the above rule into the following; (if) congestion monitor counter > 5 (then) delete route sn1 /dev/eth0 The router (acting as the policy target) then monitors the congestion counter. Should the congestion counter exceed five, the route deletion would be executed. The IETF Policy Working Group framework largely views policy as independent sets of conditional actions to be applied to one or more targeted entities. The synchronization and secure distribution of policy over entities (as needed by groups) has not yet been addressed. Thus, while the identification of a common lexicon and policy management processes is useful, the use of this framework in secure group does not seem warranted. 3.1.2 Security Policy System (SPS) The Security Policy System [SC98] is a architecture supporting flexible definition and distribution of security policies for IPSec security associations (SA)s. The central specification documents include; an architecture overview [SC98], a policy specification language [CLZ99], and a policy distribution protocol definition [SC99]. The SPS architecture defines three classes of policy relevant entities; policy databases, policy servers, and policy clients. A policy database contains policy specifications to be used by clients and servers within a administrative domain. A policy server coordinates (with the client) the interpretation, negotiation, and enforcement of SA policies. A policy client is a connection initiating host. To simplify, policy clients query the policy database for (client->server) connection policies. The policy servers accept McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 8] connections only if they meet the requirements of policies obtained from a policy database in the server domain. The SPP protocol [... defines how the policy information is exchanged, processed, and protected by clients and servers][SC99]. Partly derived from the Routing Policy Specification Language [ABG+98], the language in which SPS policies are expressed is defined in [CLZ99]. Policy in SPSL is restricted to statements of acceptable IPSec parameters and packet filtering rules. Consistent with its stated mission, policy in SPS defines independent IP connection policies. Issues of the distribution and synchronization of the policies have yet to be addressed. While the basic architecture of SPS may be useful in deriving a SMuG policy framework, direct application of its mechanisms may be insufficient. 3.2 Current/Draft IETF Standards 3.2.1 Group Key Management Protocol (GKMP) One of the first attempts at standardizing secure multicast, GKMP [HMR97a,HMR97b] defines a protocol under which group session keys can be efficiently distributed. GKMP reduces the costs of authentication and initial key distribution by introducing a peer review process in which joining members can be authenticated by any current member of the group. Thus, GKMP supports large groups by distributing key management costs among all members. After being accepted into the group, newly joined members receive a Key Encrypting Key (KEK) under which all future session keys are delivered. A limitation of this approach is that compromised members can only be ejected by the establishment of a new group. Note that GKMP is a key management protocol, and as such does not mandate how the session key is used. Two roles are defined for the participants of the GKMP protocol. Group controllers are entities with the authority to perform group critical operations (e.g. rekey the group). A group member is any member not acting as a group controller. However, group members assist in the management of the group (e.g. performing peer reviews of member joins). A primitive form of policy is supported by GKMP. Distributed to each member as it gains access to the group, a policy token defines the group's operational parameters. Two kinds of policy are defined in the GKMP token; access control and session key lifetime. Access control is supported through the use of permissions certificates. Members holding a permission certificate satisfying the access control rules stated in the policy token are accepted into the group. The session key lifetime states the maximum time a particular session key will be used. An important realization made by the authors of GKMP was need for an explicit, unambiguous policy. If a group cannot agree on a single McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 9] interpretation for a policy, it is unlikely that the desired security facilities group will be correctly implemented. This highlights a key requirement of any policy system; even in the presence of heterogeneous members, the interpretation of policy must be deterministic and unambiguous. 3.2.2 Group Security Association Key Management Protocol (GSAKMP) Growing out of the GKMP efforts, GSAKMP defines an architecture and protocol used to implement secure multicast groups. Unlike its predecessors, the GSAKMP [HCH+00,HBH00] protocol focuses on the implementation of secure groups through the definition, evaluation, and enforcement of group policy. Similar to GKMP, policy is implemented in GSAKMP through the distribution of session specific policies. GSAKMP extends the IPSec [KA98] security association (SA) abstraction through group policy tokens defining the security requirements, mechanisms, and access control for multicast sessions. The session defining policy token is presented to each member as they join the group. The GSAKMP policy token is a highly flexible data structure used to define the behavior of the group. The policy token defines all aspects of group operation; which members are to be allowed into the group, how members are to be authenticated, how the group is to be created, what security guarantees will be provided, and the means by which all of these group activities will be achieved. The token supports an exhaustive list of policies (there are over 150 fields supporting a wide range of policies and mechanisms). With small exception, group controllers are free to define policies containing as many (or as few) of these policies as is desirable. Thus, groups with varying capabilities and requirements can be defined through the policy token. GSAKMP defines controller and member roles of group as in GKMP, but diverges from GKMP in that the only controllers perform authentication and key distribution. However, as needed in small or loosely coupled groups, group members may assume the role of controller. In addition to controller and member, GSAKMP defines a subordinate controller role. A subordinate controller is an entity that performs the duties of group controller for locally maintained subgroups. As identified by Mittra in the Iolus system [Mit97], partitioning large groups into smaller sub-groups can greatly reduce the costs of session rekeying and membership management. In this way, GSAKMP can support arbitrarily large groups without significantly sacrificing performance or security. GSAKMP is a work in progress. As such, its evolving standards may aid the definition of the SMuG Policy framework and its associated protocols. The definition of the policy token, in particular, may aid the definition of the SMuG policy representation. 3.3 Trust Management McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 10] Introduced in [BFL96] by Blaze et. al., trust management provides a unified approach for the specification and evaluation of authorization and access control policies. Trust management focuses centrally on development of access control policy through the specification of evaluation of trust relationships. At the core of any trust management system is a domain independent language used to specify the capabilities, policies, and relationships between entities. Each application subscribing to a trust management service provides policy specifications to a central component called the trust management engine. An application consults the engine for access control decisions at run-time. The engine evaluates the access control request using the policy specification and environmental data. Therefore, applications need not implement policy directly, but defer policy analysis to the trust management engine. Through rigorous analysis, the PolicyMaker [BFL96] trust management engine has been proven to be correct. Thus, with respect to the policy specification, any application using PolicyMaker is guaranteed to correctly evaluate each policy as defined the syntax of the policy representation. However, policy enforcement is left to the application. Several other systems (e.g KeyNote [BFK98,BFIK99] and REFEREE [CFL+98]) have extended the trust management architecture to allow easier integration with user applications and a minimal set of enforcement facilities. Other approaches aimed at addressing access control policies in distributed environments (e.g. Akenti [TJM+99], GAA API[RN00]) essentially address the management of trust in similar ways, but with somewhat different goals and requirements. Trust management systems are targeted to the independent evaluation of acceptance policies. This is incompatible with groups, where policy evaluation must also provide (continuous valued) software configuration. Moreover, unlike trust management, group policy evaluation is ongoing; each group must alter its behavior with respect to both changes in the environment and previous policy evaluations. 3.4 Policy Management Systems 3.4.1 Dynamic Cryptographic Context Management (DCCM) Developed by Branstad et. al., DCCM [DBH+00] is a system used to implement security in very large groups (100,000+ members). A principal aspect of the DCCM project is its use of policy as entirely defining the context in which a group operates. Policy may be negotiated or stated by an initiating member, and flexible mechanisms for policy representation and interpretation are defined. A DCCM project is a collection of group sessions sharing a single group policy and (potential) membership. Access control is performed at the project level; a member gaining access to the McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 11] project has the right to participate in any session within the project. A context is a single instantiation of the policy for the collection of group members participating in a project. All sessions within the project share a single context, but distribute keys and maintain membership independently. A DCCM Cryptographic Context Negotiation Template (CCNT) defines the types and semantics of the available mechanisms and parameters of a system. This combination of available mechanisms and parameters defined by the CCNT, called policy, is defined as axises of an n-dimensional space. Thus, a point in the n-dimensional space defined within the CCNT represents a fully specified project context. DCCM interprets policy by encoding in each CCNT a direct mapping between the points on each axis to security mechanisms and parameters. Policies are negotiated in DCCM by the Cryptographic Context Negotiation Protocol (CCNP). Each project initiator (member initiating a project) associates a policy proposal with the project at the time it is created. As each member joins, CCNP is used to reconcile the joining member's local policy with the policy proposal. To simplify, if an intersection between a joining member's requirements and the policy proposal can be found, the project's policy proposal is altered to reflect the intersection and the member joins the project. If no such intersection can be found, the member abstains from participating in the project. The DCCM project has investigated and implemented several important aspects of policy management. Experience gained during the application and subsequent use of a flexible policy schemas in groups will be used as input to the design of the policy representation. Furthermore, the DCCM negotiation protocols algorithms will be used as a starting point for the SMuG policy framework. However, the DCCM project/session group model may be inappropriate for some environments. 3.4.2 Antigone The Antigone framework [MPH99] provides flexible interfaces for the definition and implementation of a wide range of secure group policies. A central element of the Antigone architecture is a set of mechanisms (and associated micro-protocols) providing the basic services needed by secure groups. Policies are implemented by the composition and configuration of these mechanisms. Thus, Antigone does not dictate the available security policies to an application, but provides high-level mechanisms for implementing them. Antigone provides facilities for rapid configuration of security policies from a set of standard services. These policies are implemented using the a set of predefined mechanisms and micro-protocols. An application is free to use these standard policies, if they are satisfactory for its purpose, or build its own using the high-level mechanisms. A wide range of rekeying, data McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 12] security, member-data, and failure policies are implemented by these services. Similar in philosophy to a GSAKMP policy token [GSAKMP], a Antigone policy block is an electronic representation of group policy. This block is distributed to joining group members, and it accepted without modification. The format and interpretation of the policy block is left to policy implementing software. Specifications of the policy block for the predefined policies can be found in [MPH99]. Antigone does not currently support local policies. 4. Policy Definition and Building Blocks Central to the definition of the policy framework are the types of cryptographic mechanisms and session parameters it will support. In this section, we do not attempt to identify the specific policies to be supported, but to develop a philosophy under which we can can assess the requirements of a definition of policy for secure multicast. A prerequisite to the development this philosophy is the a definition of multicast policy. Policy has been used in many different contexts to define the means by which security is to be implemented. Often implicit, the definition of policy is derived from the goals of the system being designed. For example, trust management systems are designed to describe trust relationships and access control. However, these systems are often called policy management systems. Conversely, in [ABG+98], policy is defined (in part) as sets of packet filtering rules. For the purposes of this document, we define policy as the statement of the entirety of security relevant parameters of a multicast group. More specifically, we accept the policy definition found of GSAKMP: [... (a policy defines) the group security relevant behaviors, access control parameters, and security mechanisms....] [HCH+00] This definition best fits the viewpoint of policy as defining how security defines group behavior, who are the entities allowed to participate, and which mechanisms will be used to achieve mission critical goals. In assessing this view of policy, we have identified the following policy categories relevant to secure groups. These categories will serve as the building blocks [HCBP99] for the SMuG policy management framework. Support for some of these classes may be very simple (or implicitly stated), but no class may be left outside a policy definition. a. Identification McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 13] The group must have some means by which it can be unambiguously identified. Failure to correctly identify the group policies, messages, and participants can lead to incorrect and insecure operation. b. Authorization A group policy must identify the entities allowed to perform protected actions. Group authorization partially determines the trust embodied by the group by defining the parities allowed to participate in group activities. Because of the wide range of expected environments, flexible identification of entity authorizations is highly desirable. c. Access Control Access to the group relevant information and action must be stated by policy. An access control policy defines a mapping of authorized entities to the actions they are permitted to perform. At a minimum, this policy should state the acceptable identities or credentials required for group access. d. Mechanisms A identification of the security services used to support group communication is required. For example, policy must state the algorithms used to derive session keys and the types of data transforms to be applied to the group content. Each security service can have parameters and policies specific to its implementation. Thus, for forward compatibility with new approaches, service definitions should be extensible. e. Verification Each policy must present evidence of its validity. The means by which the origin, integrity, and freshness of the policy is asserted (for example, via digital signature) must be known by each group member prior to its acquisition. Appendix A presents an example data structure reflecting one realization of these building blocks within GSAKMP. This structure is intended to illustrate a SMuG policy instantiation; Other protocol or frameworks may define different data structures as needed and convenient. 4.1 Local Policy A local policy defines the capabilities and requirements of each potential group member. This policy identifies, at a minimum, the services and credentials available to the local member. The member makes an assessment of whether they will be able to participate in the group using local policy. A member that, due to a lack of the proper credentials and facilities, cannot implement the group policy McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 14] cannot participate in the group. A local policy also states the local requirements of the group. These requirements can be stated as a set of minimal policies. Unlike the definition of capabilities that states whether the member can participate, these requirements dictate whether the group member desires to participate. In the absence of policy negotiation, members encountering a group whose policy fails to meet this criteria can either refrain from participation or revise their local policy. A local policy must be reconciled with received policies (see Evaluation below). Through an evaluation algorithm, each process checks the compliance of a group policy against its local requirements. The means by which this process is performed will directly affect on the types and form of policy. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 15] 4.2 Policy Life-cycle +-----------------------------------------------------------------+ | +----------+ | | |6 | | | .....................+------------| revision | <---+ | | . | | | | | | . | +----------+ | | | . | | | | | V V V | | | +-------------+ +-------------+ +------------+ | | | |2 | |3 | |4 | | | | | negotiation | --> | translation | --> | evaluation | ---+ | | | | | | | | | | | +-------------+ +-------------+ +------------+ | | | ^ | | | | | V | | | +----------+ +-------------+ | | | |1 | |5 | | | | | creation | | enforcement | ---+ | | | | | | | | +----------+ +-------------+ | +-----------------------------------------------------------------+ FIGURE 1: The life-cycle of a group policy Described in figure 1, a group policy begins its life-cycle as a set of statements made at varying levels of abstraction. Over the course of a session, the policy is translated into low level mechanism action and parameters, and modified as events dictate. The processes used to interpret, evaluate and modify the policy are detailed below. The ordering is intended to illustrate one possible policy life-cycle. However, other orderings of these processes may be acceptable or a subset of these processes may be omitted entirely. We consider the requirements of these processes in the following text. 1 - Creation During creation, policy is specified in a data structure or lanaguage by one or more informed authorities. Policies can be expressed at varying levels of abstraction. For example, a specific policy could state that all group messages be encrypted using the 3DES-CBC algorithm. Conversely, an abstract policy could state that group messages be processed (sent) by a ``strong confidentiality'' mechanism. A policy database is populated with the completed specification for future use. Creation can occur at any time prior to the establishment of the group. Once specified, verification information (e.g., a digital signature) is associated with the policy structure. 2 - Negotiation McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 16] When a session is created, group policies are retrieved from the policy database by a subset of the participating entities. If the policy requirements of all group participants are not met by the specification, agreement on the group policy must be reached. An acceptable group policy is reached through the negotiation protocol. Alternatively, negotiation may also occur in response to a request for a policy revision (see 6 below). 3 - Translation Abstract policies are translated into software mechanisms through the translation process. For example, a "strong confidentiality" policy may be translated into the 3DES-CBC algorithm. Translation must be deterministic; the result of the translation process should be equivalent at all group members or occur prior to its distribution. 4 - Evaluation Initially, each group member evaluates received group policies for consistency with local policy. If it is found that the group policy is insufficient, the member may request a policy revision or abstain from participation in the group. Policies are also checked for self-consistency (see Verification above) during evaluation. Note that evaluation can be an ongoing process; group events may introduce new inconsistencies. The identification of such conflicts can lead to policy revisions. 5 - Enforcement Enforcement occurs at the group participants. This includes monitoring for policy relevant events and executing existing policies. For example, the session leader of a group with a perfect forward secrecy rekeying policy initiates a group rekey following each group member leave. 6 - Revision Policy revision occurs when some group relevant event requires modification of an existing policy. For example, the arrival of a member that does not have the ability to implement an existing policy may request a policy revision. Revisions to an existing policy can lead to further negotiation, translation, and evaluation. 4.3 Policy Creation and Negotiation The vast majority of existing secure group communication systems assume either an implicitly stated policy or relegate the creation of policy to a single authority. However, many environments in which the SMuG architecture is to be deployed span administrative domains. Thus, a single authority approach is not likely to meet the requirements of all applications. A means by which a agreement McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 17] over policy can be reached among multiple authorities is required. However, a single authority approach should be available for those environments for which it is appropriate. Support for the collaborative generation or modification of policy requires a negotiation protocol. This protocol should begin by one or more participants stating their desired policy (modifications). Using these statements, the group will propose (and possibly counter-propose) acceptable policies. Possibly after some iteration, the group should converge on a globally accepted policy. The algorithm used to develop the proposals can be as simple as finding an intersection of policy proposals (see DCCM, section 3.4.1 above), or employ complicated algorithms such as distributed voting. We note two kinds of negotiation relevant to secure groups; (1) negotiation towards a policy definition and (2) following a group member request for policy revision. Initially, it is necessary for the requirements of the group's expected participants to be reconciled either during policy creation or prior to group creation. This may lead to negotiation during which representatives from different administrative domains converge on a single abstract policy. The output of this negotiation may not be an explicit statement of mechanisms, authorizations, and access control statements, but provide sets of acceptable group operating parameters. Whether this negotiation process should occur in the critical path of group establishment or as part of the policy creation is an open question. A second negotiation protocol can be initiated after a (potentially translated) policy is received by a group member. Each member has unique local policies and abilities. Thus, as needed and desirable, a joining member may assert revisions to a current group policy. These policies will address either the member's inability to implement some policy or a violation of a policy requirement stated in the member's local policy. This process can proceed in essentially the same manner as described above, with the exception that members actively participate in negotiation. Independent of policy, each policy negotiation participant must state its acceptance for the group to proceed; joining members must be able to obtain evidence that some authority representing its interests accepted the modified policy. This, in itself, can introduce complexity into policy negotiation and distribution protocols. 4.4 Policy Translation Policy abstractions are likely to simplify the creation of group policies. However, these abstractions must be mapped into specific commands and parameters understood by the underlying software. This process, called translation, is made more difficult by the heterogenous nature of the participants; any solution must guarantee that the output of translation process be globally compatible. That McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 18] is, the translated policy implemented by each member must be interoperable with implementation at all other members. This constraint will have a direct affect on the kinds of allowable abstractions and their representations. An open question is whether it will be possible for each member to perform all translation at the point at which a group policy is received. It is not at all obvious that this is true for arbitrary policies and representations. If this is not the case, extra care must be taken in the initial evaluation of a policy. It would be undesirable for a group member to discover (at run-time) that it did not have the capability to implement a service required by a newly translated policy. It is also unclear how the translation algorithm will affect policy negotiation. If the result of the translation process is always interoperable with the translation at any other host, then the negotiation over the abstractions can be performed. Where the result may lead to incompatible solutions, translation must be performed before negotiation. Two decisions that need to be made are; a) which entities perform translation? and b) does translation occur before, after, or as part of negotiation? The answers to these questions will affect the design of the policy framework. 5. Requirements The following text considers the functional requirements of the policy framework. As one would expect, these requirements are likely to drive the design of the reference framework. 5.1 Trust Model The SMuG reference framework document [HCBP99] defines three classes of entities participating in the creation, distribution, and use of a group policies. These entities include; Policy Server Policy servers create, store, distribute, and potentially negotiate group policies. There are zero or more policy servers present in each administrative domain. Possibly configured through local policy, all group participants (members and group controllers) are required to explicitly state the policy servers they trust. If a participant cannot identify a trusted policy server, due diligence must be exercised in accepting received policies. An alternative design would state that no policy server is trusted. Each group controller (GCKS, see below) is the logical originator of a group policy. Acceptance of a policy could be predicated on it being authenticated (e.g. signed) by a trusted McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 19] GCKS. Policy servers would only act as policy repositories, and defer all policy management to the GCKS. Group Controller/Key Server (GCKS) Acting as logical leaders of the group, each GCKS is an entity participating in the creation and distribution of cryptographic material used to secure group action. For performance reasons, each GCKS will likely obtain a policy when a session is initialized. For that session, no further communication with the policy servers is required. In this model, each GCKS will serve as the policy client; received policies will be evaluated and translated by the GCKS as is appropriate for a particular session. With respect to policy, GCKS are trusted by the policy server to correctly acquire and represent policy. An open question is the role that the policy server plays in the negotiation of policy. If negotiation is performed by policy server, then each GCKS must trust the policy server to adequately represents its interests. Sender/Receiver The senders and receivers (identified throughout as group members) are the end-entities transmitting and receiving content. Each acts as a policy consumer and target; received policies are authenticated, translated, and enforced. The reference architecture states that communication between the senders and receivers and the policy server is not likely to occur. However, member participation in the development of policy is not ruled out. Thus, it is expected that the senders and receivers will be required to trust (at least one) GCKS participating in the session. In the above text, two models of policy ownership have been identified: a. policy server as owner/initiator of policy (and indirectly the group). In this model, policy servers are responsible for creating a policy consistent with the needs of the expected participants. The session participants must trust the policy servers to best represent their interests. b. GCKS as owner/initiator of policy. Policy servers act as repositories, and may aid in the process of policy generation, translation, and negotiation. However, resulting policies must ultimately be asserted or accepted by the GCKS. Which model (or possibly support for both) is appropriate for SMuG is an open question. 5.2 Group Model The types of groups that are supported by the SMuG framework will McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 20] have an affect both on the representation of policy and the way in which policy is evaluated. As presented in [CP99], a group may include one or more senders. Communication can be organized as a large broadcast group or distributed among an arbitrary number of smaller subgroups. At a minimum, a policy should state the rules by which a member can become a sender. This may fall into the larger context of definition of access control, where a sender becomes a distinct role. It may become necessary to implement a separate policy for locally maintained subgroups in a larger hierarchical group. This could occur in environments where the subgroup exists entirely within a protected network, but participates in the larger group extending beyond its borders. It is worth considering whether this represents a violation of the larger group policy. 5.3 Policy Representation The format of the representation of policy is known as a policy language. The policy language should be unambiguous, succinct, and clear. Because a policy will be interpreted by host software, the mapping of the policy to mechanism (translation) and credentials must be deterministic. The costs associated with policy distribution is likely to be a key determinant in the success of the policy framework. As such, the language should be designed to be represented in as small a electronic format as possible. Policy definitions must originate from security personnel which may or may not be directly involved in application development. Thus, the ability to relate the representation to real world objects is desirable. Where possible, a policy representation should be human readable. The policy language should be flexible. It is unrealistic to expect that any single definition can anticipate the needs of all future applications and mechanisms. Therefore, allowing the extension of the language to new kinds of policies and mechanism parameters is required. Often called a schema, the types of policies defined are outside the scope of this document. A detailed description of several dimensions along which a group policy can be defined is presented in [MHDP00]. It is worth noting that the schema will be a direct result of other policy design decisions. For example, the access control model defined for the SMuG framework will dictate many of the details of identification and role representation. There are several existing policy description languages. [MES99] provides a policy specification language under which new schemas can be defined. Similar approaches adapting the Security Policy Language [CLZ99], GSAKMP policy token [HCH+00], or DCCM cryptographic context negotiation templates [DBH+00] may provide McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 21] equally suitable solutions. These and other languages are being actively evaluated. 5.4 Problem Area 2 - Key Management The development of policies specific to the group key management problem area are needed. These policies will specify the algorithms and parameters used to authenticate members, establish (peer to peer) communication between the GCKS and potential group members, and the creation and distribution of group keying material. The means by which members are authenticated is centrally dependent on the mechanisms used for group establishment and subsequent communication. The current GCKS specification [HBH00] defines a multi-phase process during which each member is authenticated, obtains the group policy, receives group keying material, and participates in the group. The initial (authentication) phase requires the establishment of a peer to peer security association (SA1). A second long lived multicast security association (SA2) is used for the distribution of keying material. Lastly, the group content is distributed over a separate multicast security association (SA3). The group policy must specify the acceptable mechanisms and participants of used to create these SAs. It may not be reasonable to assume that all GCKSs and members have access to the same authentication facilities. Thus, it is necessary to support a range of solutions for the establishment of SA1. However, because they are shared, all parties must accept identical definitions for the policies defining SA2 and SA3. 5.5 Problem Area 1 - Data Handling The SMuG framework Data Handling problem area [CRC00] defines mechanisms providing data level security for the group content. Data transforms are applied to the group content before being transmitted. Specification of data handling policies requires the identification of low level transforms and cryptographic algorithms. Thus, some globally accepted naming scheme for each mechanism and parameter must be adopted. Enumerated types have long been used in many contexts for this purpose. It has been shown that the ordering of the application of data transforms can have a significant affect on the security and performance of the group. An open question is whether ordering the application of transforms should be specified in policy or stated in the data transform specification. An attractive approach is to define default behavior, but allow different orderings to be specified by policy. Identifying efficient data transforms is an area of active research. Each proposal introduces new parameters and requirements to the McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 22] group policy. Forward compatibility with future transforms is a requirement of the policy system. Thus, providing a means by which the representation may be extended to these new transforms is needed. At the administrative level, it may not be necessary to specify precise algorithms and parameters for group security. Thus, it is desirable to provide data security abstractions. For example, a policy such as "strong confidentiality" may best suit the needs of policy definition. Using the translation process, a group implementing this policy can best decide the how the enforce this policy. This also removes the requirement that the authority specifying policy understand the implications of the use of specific cryptographic algorithms and techniques. 5. Policy Reference Architecture The SMuG reference architecture [HCBP99] identifies three problem areas roughly defining separate, but dependent, research efforts. In this section, we look at the policy relevant requirements of this architecture. Central to the design of the policy framework is a description of the policy relevant responsibilities of the group entities. For example, statements about when translation occurs (with respect to other activities such as negotiation) are required. The following text describe issues relating to the generation and use of policy within the reference architecture. 5.1 Policy Server A policy server is the entity that stores, distributes, and manages group policies. In a centralized environment, there exists a single policy server stating group policy. In this environment, GCKS entities will appeal to the policy server for appropriate group policies. In a distributed environment, multiple policy servers may participate in the generation of a group policy. 5.2 Group Controller/Key Server (GCKS) The GCKS is an entity participating in the creation and distribution of cryptographic material used to secure group action. A secondary responsibility of the GCKS is the distribution of group policy to joining group members. 5.3 Policy Editor Defined in the IETF Policy Framework working group architecture document [SWM+99], a policy editor provides interfaces for the initial construction and evaluation of policies. Similar to other network management tools, the policy editor presents a simplifying user interface from which a coherent policy can be specified. The design of the policy editor is outside the scope of SMuG framework. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 23] However, guidelines for the development of policy editors may be useful. A policy generated via the policy editor is evaluated by checking the (potentially composite) policy statements for consistency. A policy is said to be consistent if no rules will conflict in any operational environment. The algorithm used to for the detection of inconsistencies is determined by the policy representation and model (see Policy Representation below). 5.4 Members It is not expected that group members will communicate directly with policy servers. However, the implications of such a decision should be carefully considered. At a minimum, each member must implement policy evaluation and enforcement facilities. The evaluation algorithm checks compatibility of a local policy with received policy. Depending on the kinds of negotiation available, this can lead to renegotiation of the group policy. Enforcement of a received policy requires the interpretation of policy into software action. If required, translation of policy into software specific configuration is also necessary. The policy representation should attempt to make this task as efficient and simple as possible. 5.5 Inter-Policy Server Protocol The inter-policy server protocol defines the format and meaning of communication between policy servers in a distributed environment. The specifics of this protocol are a direct result of the assignment of responsibilities of the policy servers. In environments where policy servers simply act as repositories for policy, this protocol will define the mechanisms by which policies from other domains can be retrieved via local policy servers. The protocol should be extended to meet the requirements of environments where policy servers actively participate in the policy negotiation. A key ingredient of this protocol a definition of the types of security required for the protocol itself. For example, it is likely that confidentiality of policies is needed. The assessment of these and other requirements is an ongoing work. 5.5 GCKS-Policy Server Protocol The GCKS-Policy Server protocol, at a minimum, will define a process whereby a policy can be obtained from the policy server. Similar to the Inter-Policy Server protocol, an assessment of the security requirements of this protocol is necessary. 5.6 Policy Representation McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 24] A policy specification language defines both how a policy is represented and the rules with which the representation is interpreted. The reference architecture language should not specify specific policies, but define how policies are represented (i.e. format of policy schemas). However, the definition of a reference schema using defined key management and data transform specifications may help illuminate the use of the language. [MHDP00] describes a possible design space of secure group communication policies and details the goals and requirements of a policy representation. 5.7 Negotiation Negotiation is the process whereby the policies of two or more members, GCKS, or domains can be reconciled. This collaborative effort may include a simple algorithm (e.g. the DCCM intersection algorithm), or more complicated multiparty protocols (e.g. weighted voting protocols). A desirable approach would define abstract interfaces and default negotiation techniques. This would allow future work to define different types of negotiation where needed. An open issue is the identification of a common API allowing the flexible definition of policy negotiation. Once a negotiation algorithm has been identified, it is necessary to identify which fields of a policy may be negotiated. This definition is likely to be specific to each application and environment. Thus, it may become necessary to extend the policy representation with "negotiable" designators and sets of acceptable policies. Finally, the parties which perform negotiation must be identified. Negotiation may be performed entirely within the policy framework (i.e. as part of the inter-policy server protocol), between policy servers, or between members and the GCKS. This decision will be a direct result of the assignment of policy related responsibilities. 6. References [ABG+98] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, and C. Villamizer. "Routing Policy Specification Language (RPSL)". Internet Engineering Task Force, January 1998. RFC 2280. [BFIK99] M. Matt Blaze, Joan Feigenbaum, J. Ioannidis, and Angelos D. Keromytis. "The KeyNote Trust Management System - Version 2". , Request for Comments (RFC) 2704, Internet Engineering Task Force, September 1999. [BFK98] Matt Blaze, Joan Feigenbaum, and Angelos D. Keromytis. "The KeyNote Trust Management System". In Cambridge 1998 Security Protocols International Workshop, 1998. Cambridge, England. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 25] [BFL96] M. Blaze, J. Feigenbaum, and Jack Lacy. "Decentralized Trust Management". In Proceedings of the 1996 IEEE Symposium on Security and Privacy, pages 164--173, 1996. Los Alamos. [CFL+98] Y. Chu, J. Feigenbaum, B. LaMacchia, P. Resnick, and M. Strauss. "REFEREE: Trust Management for Web Applications". Financial Cryptography '98, 1465:254--274, 1998. [CLZ99] M. Condell, C. Lynn and J. Zao, "Security Policy System Language", Internet Engineering Task Force, July 1999, draft-ietf-ipsec-spsl-01.txt (draft) [CP99] R. Canetti and B. Pinkas, "A Taxonomy of Multicast Security Issues (updated version)", Internet Research Task Force, April, 1999, draft-irtf-smug-taxonomy-01.txt (Draft). [CRC00] Ran Canetti, Pankaj Rohatgi, and Pau-Chen Cheng, "Multicast Data Security Transformations: Requirements, Considerations, and Prominent Choices", Internet Engineering Task Force, May 2000, draft-data-transforms.txt (Draft). [DBH+00] P. Dinsmore, D. Balenson, M. Heyman, P. Kruus, C Scace, and A. Sherman "Policy-Based Security Management for Large Dynamic Groups: A Overview of the DCCM Project", In Proceedings of DARPA Information Survivability Conference and Exposition (DISCEX '00), pages 64-73, DARPA, January 2000. [HBH00] H. Harney, M. Baugher, and T. Hardjono, "GKM Building Block: Group Security Association (GSA) Definition", Internet Engineering Task Force, February 2000, draft-irtf-smug-gkmbb-gsadef-00.txt (Draft). [HCBP99] T. Hardjono, R. Canetti, M. Baugher and P. Dinsmore, "Secure Multicast: Problem Areas, Framework, and Building Blocks", Internet Engineering Task Force, October, 1999, draft-irtf-smug-framework-00.txt (Draft) [HCH+00] H. Harney, A Colegrove, E. Harder, U. Meth, and R. Fleischer, "Group Secure Association Key Management Protocol", Internet Engineering Task Force, May 2000, draft-harney-sparta-gsakmp-sec-01.txt (Draft) [KA98] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", Internet Engineering Task Force, RFC 2401, November 1998. [HAN96] M. Handley, The sdr Session Directory: An Mbone Conference Scheduling and Booking System. Department of Computer Science, University College London, April, 1996. [HJ98] M. Handley and V. Jacobson, SDP: Session Description Protocol. Internet Engineering Task Force, RFC 2327, April, 1998. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 26] [HMR97a] Harney, Hugh, Carl Muckenhirn, and Thomas Rivers, "Group key management protocol (GKMP) architecture," Request for Comments (RFC) 2094, Internet Engineering Task Force (July 1997). [HMR97b] Harney, Hugh, Carl Muckenhirn, and Thomas Rivers, "Group key management protocol (GKMP) specification," Request for Comments (RFC) 2093, Internet Engineering Task Force (July 1997). [MHDP00] P. McDaniel, H. Harney, P. Dinsmore and A. Prakash, "Multicast Security Policy", Internet Engineering Task Force, June 2000, (draft) [MPH99] P. McDaniel, A. Prakash and P. Honeyman, "Antigone: A Flexible Framework for Secure Group Communication", In Proceedings of the 8th USENIX Security Symposium, pages 99-114, August, 1999 [RN00] T. Ryutov and C. Neuman, "Representation and Evaluation of Security Policies for Distributed System Services", In Proceedings of DARPA Information Survivability Conference and Exposition (DISCEX '00), pages 172-183, DARPA, January 2000. [SC98] L. Sanchez and M. Condell, "Security Policy System", Internet Engineering Task Force, November 1998, (draft) [SC99] L. Sanchez and M. Condell, "Security Policy Protocol", Internet Engineering Task Force, July 1999, (draft) [MES99] B. Moore, E. Ellesson, and J. Strassner, "Policy Framework Core Information Model", Internet Engineering Task Force, October 1999, (draft) [SMuG] Secure Multicast Research Group, Home Web Site, URL: http://www.ipmulticast.com/community/smug/ [SWM+99] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, and J. Wheeler, "Policy Framework", Internet Engineering Task Force, September 1999, (draft) [TJM+99] M Thompson, W. Johnson, S. Mudumbai, G. Hoo, K. Jackson, and A. Essiari, "Certificate-based Access Control for Widely Distributed Resources", Proceedings of 8th USENIX UNIX Security Symposium, USENIX Association, pages 215-227, August 1999. [X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) | ISO/IEC 8824-1:1998. [YHK95] W. Yeong, T. Howes and S. Kille, "Lightweight Directory Access Protocol", Internet Engineering Task Force RFC 1777, March 1995. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 27] Authors' addresses: Patrick McDaniel Department of Electrical Engineering and Computer Science University of Michigan 3115 EECS Building 1301 Beal Avenue Ann Arbor, MI 48109 pdmcdan@eecs.umich.edu Hugh Harney Sparta 9861 Broken Land Parkway Columbia, MD 21046 (410) 381-9400 x203 hh@sparta.com Andrea Colgrove Sparta 9861 Broken Land Parkway Columbia, MD 21046 (410) 381-9400 acc@columbia.sparta.com Atul Prakash Department of Electrical Engineering and Computer Science University of Michigan 2231 EECS Building 1301 Beal Avenue (734) 763-1585 aprakash@eecs.umich.edu Peter Dinsmore NAI Labs 3060 Washington Road, Glenwood, MD 21738 (443) 259-2346 Pete_Dinsmore@NAI.com McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 28] 7. Appendices Appendix A - A Policy Data Structure The following describes the ASN.1 [X.680] data structure used to define a group policy. We do not assert that all policy be represented in ASN.1, but due to its wide acceptance, is a convienent vehicle for describing such a structure. --------------------------------------------------------------------- GroupPolicyToken DEFINITIONS ::= BEGIN --- This is where Antigone or other policy specifications can be --- added GroupToken ::= CHOICE { gsakmp Token } --- GSAKMP Policy Token --- The Token consists of a tokenID, authorization field, access --- control field, cryptographic mechanisms field, and the token --- signature block. Token ::= SEQUENCE { tokenID TokenID, authorization Authorization, accessControl AccessControl, mechanisms Mechanisms, signatureBlock SignatureBlock } --- 1st Level Token Fields --- The TokenID field contains the token version number, the --- protocol using the token (GSAKMP), the identifier of the group, --- and a timestamp indicating when the token was signed. TokenID ::= SEQUENCE { version VersionType, protocol ProtocolGroupname, timestamp LifeDate } --- The Authorization Field contains information relating to the --- group owner and who may act in the roles of key servers and --- rekey controllers. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 29] Authorization ::= SEQUENCE { groupOwner CertInfo, gCKS AuthRoles, rekeyCont AuthRoles } --- The Access Control Field contains the rules and name --- constraints of group members AccessControl ::= SEQUENCE { permissions Permissions, access AuthRoles } --- The Mechanisms Field describes the security associations used --- for different aspects of group communications. The Mechanisms --- field consists of an application security association covering --- the data communications between group members (GKM-BB Type-3 --- SAs), a unicast security association for initial key and token --- download, key management security association for the --- protection of key management messages, and a bypass security --- association for allowing certain key management messages to --- pass through a system without cryptographic protection. Mechanisms ::= SEQUENCE { dataComm AppSA, unicast UnicastSA, groupManagement GSAKMP-SA } --- The signature block corresponds to the data associated with the --- authentication of the policy token. SignatureBlock ::= SEQUENCE { sigInfo SigInfo, sigData SigData } --- Mechanisms subfields --- The Application SA is a sequence of SAs where the key is --- preplaced (distributed via GSAKMP). AppSA ::= SEQUENCE { sPI INTEGER, appl Appl } McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 30] Appl ::= SEQUENCE OF SecurityAssociation ( WITH COMPONENTS { -- ..., keyCreationMethod --- (GsaKmp) } ) --- The Unicast Security association supports the security of new --- member join exchanges UnicastSA ::= SEQUENCE{ peer UniSA, gsa JoinMechs } UniSA ::= SecurityAssociation ( WITH COMPONENTS { --- ..., keyCreationMethod --- (IkeInfo) } ) JoinMechs ::= SEQUENCE{ keyEncrAlg GSAEncrAlg, keyCreationMeth GSAKMPInfo, sigAlg SignatureAlgorithm } --- The GSAKMP-SA specifies the security requirements for GSAKMP --- messages. GSAKMP-SA ::= SEQUENCE { --- This corresponds to the algorithm used to protect key --- download and CR keys keyEncAlg GSAEncrAlg, --- Method that GSAKMP uses to rekey GTEK sigInfo SigInfo rekeyMethod RekeyMethod, dataChannel MsgSA } MsgSA ::= SEQUENCE { rekey RekeyBypassSA } --- The ByPass-SA specifies a method of sending out messages --- without the security protection of the existing key management --- or application SA. McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 31] RekeyBypassSA ::= CHOICE { ipByPass IPByPass-SA } -- IPsec Bypass. Only bypasses should specify source ports IPByPass-SA ::= SEQUENCE { secProtocolID SecProtocolID (0), direction ProcessingDirection, selectors ByPassSelectors, sigInfo SigInfo } --- subtypes SecurityAssociation ::= SEQUENCE { secProtocol SecProtocol, keyLength INTEGER OPTIONAL, keyCreationMethod KeyCreationMethod, groupSrcAuth GroupSrcAuth OPTIONAL } SecProtocol ::= CHOICE { aH [0] AHInfo, eSP [1] ESPInfo, ipSecNone [2] BypassInfo --- Note: S/MIME and other apps can be added here } --- Information specific to IPsec Authentication Header SAs AHInfo ::= SEQUENCE { --- AH, corresponds to IPsec Protocol ID (sec. 4.4.1, DOI) secProtocolID SecProtocolID (2), direction ProcessingDirection, aHAlgorithm AHAlgorithm, encapsulationMode Mode, sALife IPLife, selectors IPSelectors } --- Information specific to IPsec Encapsulation Payload SAs ESPInfo ::= SEQUENCE { secProtocolID SecProtocolID (3), --- ESP direction ProcessingDirection, eSPAlgorithm ESPAlgorithm, McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 32] eSPAuthentication ESPAuth, encapsulationMode Mode, sALife IPLife, selectors IPSelectors } BypassInfo ::= SEQUENCE{ secProtocolID SecProtocolID (0), direction ProcessingDirection, selectors ByPassSelectors } SecProtocolID ::= ENUMERATED { ipSecNone(0), ah(2), esp(3), gsakmp(4) } ProcessingDirection ::= ENUMERATED { incoming(1), outgoing(2) } --- IPsec Mode: tunnel or transport Mode ::= ENUMERATED {tunnel(1), transport(2)} AHAlgorithm ::= ENUMERATED { ah-md5(2), ah-sha(3), ah-des(4) } --- DOI p. 10 ESPAlgorithm ::= ENUMERATED { esp-des-iv64(1), esp-des(2) } --- DOI p. 14 ESPAuth ::= ENUMERATED { hmac-md5(1), hmac-sha(2), des-mac(3), kpdk(4) } KeyDownloadAlgorithm ::= ENUMERATED { none(0), des-ecb(1), des3-ecb(2) } KeyCreationMethod ::= CHOICE { auto [0] GsaKmp, ikeStuff [1] IKEInfo, gsaJoin [2] GSAKMPInfo } GsaKmp ::= INTEGER (1) GSAKMPInfo ::= CHOICE{ dh DHInfo } DHInfo::= SEQUENCE { exch KeyExchange (1), n INTEGER, g INTEGER McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 33] } KeyExchange ::= ENUMERATED { dh(1) } RekeyMethod ::= ENUMERATED{ none(0), lkh(1), oft(2) } GroupSrcAuth ::= ENUMERATED{ none(0) } -- Cryptoperiod LifeType ::= ENUMERATED { seconds(1), kilobytes(2), date(3) } Time ::= SEQUENCE { lifeType LifeType (1), lifeTime INTEGER } Bytes ::= SEQUENCE { lifeType LifeType (2), lifeLength INTEGER } Date ::= SEQUENCE { lifeType LifeType(3), lifeDate LifeDate } LifeDate ::= CHOICE { gt [0] GeneralizedTime, utc [1] UTCTime } IPLife ::= CHOICE { time [0] Time, bytes [1] Bytes } Selectors ::= SEQUENCE { srcAddr IPAddress, dstAddr IPAddress, destPort INTEGER OPTIONAL, groupID GroupName OPTIONAL, -- From RFC 2459 secLabel SecLabel OPTIONAL } ByPassSelectors ::= Selectors ( WITH COMPONENTS {à, groupID ABSENT}) McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 34] IPAddress ::= OCTETSTRING(SIZE(4)) GroupName ::= SEQUENCE { addrProt Ipv4 OPTIONAL, mAddr IPAddress, num INTEGER, srcAddr IPAddress OPTIONAL } Ipv4 ::= GeneralString ( "IPv4" ) GSAEncrAlg ::= ENUMERATED{ none(0), des-ebc(1), triple-des-ecb(2) } SigInfo ::= SEQUENCE { sigAlg SignatureAlgorithm, hash HashAlg } AuthRoles ::= SET OF CertInfo SignatureAlgorithm ::= ENUMERATED{ dss(1) } PkiInfo ::= SEQUENCE { certType CertType, keyLength INTEGER, rootCA Roots } CertType ::= ENUMERATED{ x-509v3-dss-sha1(1), x-509v3-rsa-md5(2), x-509v3-rsa-sha1(3), spki(4) } Roots ::= SEQUENCE { sPKI SPKIroots, x509 X509roots } SPKIroots ::= SET OF GeneralString X509roots ::= SET OF PQDN CertInfo ::= SEQUENCE { subject CertNames, serial INTEGER OPTIONAL, pki PkiInfo } SigData ::= OCTET STRING McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 35] VersionType ::= GeneralString ( "GSAKMPv1.0" ) ProtocolGroupname ::= CHOICE { multi IPMulticast } IPMulticast ::= GroupName AccessList ::= SET OF PQDN --- This can be expanded and mapped to a particular context Permissions ::= CHOICE{ nullP [0] NullPermissions , sparta [1] SpartaPermissions } NullPermissions ::= ENUMERATED{none(0)} SpartaPermissions ::= SET OF SpartaPermission SpartaPermission ::= ENUMERATED { none(0), employee(1), management(2), finance(3), projectA(4), projectB(5), projectC(6), projectD(7) } --- From RFC 2459 allowing wildcard "*" for attribute value PQDN ::= DistinguishedName CertNames ::= CHOICE{ distn PQDN, altn IA5String, domain IA5String, address IPAddress } IKEInfo ::= SEQUENCE { iKE INTEGER(2), encrAlg IkeEncrAlg, hashAlg HashAlg, authMethod IkeAuthMeth, groupDesc IkeGroupDesc, groupType IkeGroupType, groupPrime INTEGER, groupGenOne INTEGER, groupGenTwo INTEGER, life IkeLifeType, prf IkePRF, keyLength INTEGER, McDaniel, Harney, Colgrove, Prakash, and Dinsmore [Page 36] fieldsize INTEGER } IkeEncrAlg ::= ENUMERATED { des-cbc(1), idea-cbc(2), bfish-cbc(3), rc5-r16-b64-cbc(4), des3-cbc(5), cast-cbc(6) } HashAlg ::= ENUMERATED { md5(1), sha(2), tiger(3) } IkeAuthMeth ::= ENUMERATED { preshared(1), dss-sig(2), rsa-sig(3), encrsa(4), revencrsa(5) } IkeGroupDesc ::= ENUMERATED { modp-768(1), modp-1024(2) } IkeGroupType ::= ENUMERATED { modp(1) } IkeLifeType ::= IPLife IkePRF ::= ENUMERATED{ none(0) } END --------------------------------------------------------------------- ---------------------------------------------------------------------------