idnits 2.17.1 draft-ietf-ipsp-msme-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2001) is 8199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-ietf-policy-terminology (ref. 'TERM') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Condell, BBN 2 draft-ietf-ipsp-msme-00.txt 3 Expires May, 2002 November 14, 2001 5 Multidimensional Security Policy Management and 6 Enhancements for IP Security Policy 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This document describes the requirements and architecture for supporting 37 security policy resolution among a coalition of partners. It then 38 discusses how solutions necessary for the coalition resolution problem 39 may be utilized to improve the on-going development of an IPSP 40 solution. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 45 1.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. MSME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 51 2.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 52 2.4.1 MSME Components. . . . . . . . . . . . . . . . . . . . . 7 53 2.4.1.1 Policy Level Agreement . . . . . . . . . . . . . . . 7 54 2.4.1.2 Policy Compilation . . . . . . . . . . . . . . . . . 7 55 2.4.1.3 Resolution . . . . . . . . . . . . . . . . . . . . . 8 56 2.4.1.4 Exchange Protocol. . . . . . . . . . . . . . . . . . 8 57 2.4.1.5 Reconciliation . . . . . . . . . . . . . . . . . . . 9 58 2.4.1.6 Monitoring . . . . . . . . . . . . . . . . . . . . . 10 59 2.4.2 Partner-Dependent Components . . . . . . . . . . . . . . 10 60 2.4.2.1 Policy Management Tool . . . . . . . . . . . . . . . 10 61 2.4.2.2 Policy Language. . . . . . . . . . . . . . . . . . . 10 62 2.4.2.3 Local Policy Repositories. . . . . . . . . . . . . . 11 63 2.4.2.4 Policy Enforcement Points. . . . . . . . . . . . . . 11 64 2.4.3 Data Flow. . . . . . . . . . . . . . . . . . . . . . . . 12 66 3. Ideas for IPSP . . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.1 Late Name Binding. . . . . . . . . . . . . . . . . . . . . . 13 68 3.2 Generalization . . . . . . . . . . . . . . . . . . . . . . . 15 70 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 This document describes the requirements and architecture for the 77 Multidimensional Security Management and Enforcement (MSME) system. 78 MSME provides a means for members of a dynamic coalition with limited 79 trust between them to negotiate mutually agreeable policies that 80 enable mission relevant communications. MSME's solution allows each 81 member to maintain its own internal policy requirements, policy 82 languages, and policy management systems while enabling them to 83 exchange and resolve policies with other members of the coalition. 85 While it may be early for the IPSP working group to design solutions 86 beyond IPsec policy resolution between two hosts and any intervening 87 gateways, there are several benefits to looking at the requirements 88 and potential solutions for more complex security policy management 89 environments. It exposes issues with, and presents possible solutions 90 to, generalizing the IPSP work to security protocols other than IPsec. 91 It may also help the working group to design a solution that is more 92 extensible to other security policy management needs. 94 The next section describes the MSME system motivations, requirements, 95 and architecture. It is followed by a discussion of some of the ideas 96 that may be incorporated into the IPSP work. 98 1.1 Definitions 100 The following terms are used throughout this document, in addition to 101 the terms defined for general policy terminology [TERM]. 103 Coalition 105 A coalition is a group of administrative entities (e.g. companies, 106 countries) that work together to achieve a defined objective 107 (mission). The coalition will have specific communications 108 requirements necessary to accomplish the objective. 110 Partner 112 A partner is an administrative entity that participates in a 113 coalition. 115 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 116 "MAY" that appear in this document are to be interpreted as described 117 in [Bra97]. 119 2 MSME 121 The MSME system is being developed under DARPA contract [Contract 122 Number F30602-00-C-0062]. 124 2.1 Motivation 126 Policy management, while fundamental for good network security, is a 127 complex task. It is difficult in the IPSP world where two end-hosts 128 are trying to communicate, but is even more complex when groups are 129 trying to communicate. Coalitions are a particularly difficult 130 environment for policy management. There may be a large number of 131 partners that need to share policy information. Partners may join or 132 leave the coalition, each change possibly affecting the policy that 133 must be enforced. Each partner may have different management elements, 134 including different policy languages, policy distribution protocols, 135 and policy authoring tools. Each partner may even implement a 136 different set of security protocols. 138 Despite the heterogeneity of the coalition environment, it is 139 necessary to be able to determine if the coalition can implement the 140 security policies necessary to carry out its mission. This requires 141 that the coalition partners be able to exchange their policies, 142 determine a common set of policies among the partners, and insure that 143 all the communication requirements for the coalition can be met by all 144 the partners. If the requirements cannot be met, they must be flagged 145 so an administrator can fix them before they interfere with the 146 mission. 148 Additionally, once the policies are in place, partners will want to 149 ensure that the policies are being used and enforced correctly. Each 150 partner requires some level of monitoring to verify that it and other 151 partners are correctly enforcing the agreed upon policies. How much 152 information may be obtained from monitoring will depend upon where 153 monitoring probes are allowed to be placed, which, in turn, affects 154 what information is available to monitor. 156 2.2 Overview 158 The MSME architecture consists of a high-level policy description 159 language; protocols for transferring the policy between partners; and 160 algorithms for ensuring the internal consistency of the high-level 161 policy description, resolving the policies between partners, and 162 verifying that the resolved policy does not violate the policies of a 163 particular partner. 165 When a coalition forms, membership changes, or one or more partners' 166 policies change, each partner creates a policy level agreement (PLA). 167 The PLA contains high-level policy requirements and mappings from the 168 abstract requirements to concrete implementations that the partner 169 supports. Each partner checks that their PLA is self consistent and 170 that their local policies do not conflict with the high-level 171 requirements. If there is a conflict or inconsistency, human 172 intervention is required to correct the problem. 174 The partners then exchange their PLAs. Depending on the coalition, 175 partners may either exchange their PLAs with each other, or they may 176 hand them to a central server. The exchange must be authenticated and 177 may require confidentiality. Each partner, or a central server, as 178 agreed to by the coalition, must then resolve the PLAs. The 179 resolution process determines which concrete policies the coalition 180 members agree to use to implement the policies specified in their 181 PLAs. PLAs may be resolved by subsets of the coalition partners to 182 allow services among the subsets that do not involve the rest of the 183 coalition. The resolution process produces a resolved PLA (RPLA). 184 The RPLA will have to be distributed to each partner if the resolution 185 process was centralized. 187 When each partner receives or computes the RPLA, it must reconcile it 188 with its local policies to verify that it does not violate its local 189 policy. Additionally, the reconcilliation process can detect policy 190 rules that were not included in the RPLA because other coalition 191 members could not support them and may require manual intervention if 192 those communications must be supported. If the resolution process is 193 executed properly and no partner misbehaves, the reconciliation 194 process should not detect any rule violations, however, it is a 195 necessary step to ensure there were no problems. 197 The dynamic coalition environment will produce a very complex set of 198 policies, so it will be difficult to determine a priori if the correct 199 policies were negotiated. Monitoring can help determine if the 200 correct policies are being used and that policy enforcement points are 201 using them correctly. The power of monitoring will be limited by 202 where partners will allow monitoring probes to be placed, both 203 physically and because most communications will be encrypted. 205 Partners may have to take into account that policy may be defined by 206 different people at different levels. The high-level policy may be 207 defined by someone who established the coalition and its communication 208 requirements, but does not know how the requirements get implemented. 209 Similarly, bindings may be created by someone who understands the 210 low-level policies, but did not determine the high-level policy. 212 2.3 Requirements 214 This section will discuss some of the main requirements for the MSME 215 system. 217 * MSME MUST allow each partner to internally implement its own policy 218 languages, policy storage and policy distribution mechanisms. 219 However, MSME MAY impose requirements on them. 221 * MSME MUST provide a mechanism for partners to exchange their 222 policies and to resolve policy information using a common protocol. 223 The policies must be securely communicated, including 224 authentication and integrity checks. MSME SHOULD have a mechanism 225 by which coalition partners can associate security policy rules 226 with specific coalition partners. 228 * MSME SHOULD support both private peering (sub-coalitions) and 229 partial (or abstracted) sharing of internal policy information. 230 Some partners may want to keep portions of their policy private 231 from other partners. Obviously, those rules of their policy 232 relevant to the policy resolution need to be released to other 233 partners. 235 * MSME MUST provide a way to determine whether a specific 236 communication is permitted by the current policy agreement between 237 coalition partners before the communication is attempted. 239 * MSME MUST provide a way to establish and identify, at any 240 time, the set of authorized coalition partners and the entities 241 that they have authorized to engage in coalition activities. 243 * MSME MUST support security services implemented by multiple 244 security protocols (e.g., IPsec, TLS), and compositions thereof. 245 Therefore, MSME SHOULD support a security abstraction layer that 246 can map (high-level) policy intent to different (low-level) 247 security policy data models. Both the representation (language) and 248 exchange (protocol) of this abstraction must be supported. 250 * MSME MUST provide a way to monitor policies while they are in use 251 to confirm that the correct policies are installed in the 252 enforcement points, that they are being applied correctly, and that 253 the policy decision points (PDPs) and policy enforcement points 254 (PEAs) are behaving correctly. There must be a way to monitor both 255 the coalition policies and the local policies of the PDPs and PEAs. 257 2.4 Architecture 259 Figure 1 illustrates the components of the MSME system. The 260 partner-dependent components are not defined as part of the MSME 261 system, however, the system interacts with those components and may 262 impose requirements on them. Intra-partner components represent 263 components fully contained within a partner. Inter-partner components 264 which are not partner-dependent must exist as part of the MSME system, 265 but don't have to directly interoperate with other partners. Other 266 components are part of the MSME system and must be interoperable 267 between partners. 269 +--------------------------------------------------------------------+ 270 | Partner-dependent | MSME | 271 |......................................... | 272 |. Intra-partner . | 273 |. +--------------+ | +--------------+ . +-------------+ | 274 |. | PMT/ | | | Policy | . | Resolution | | 275 |. |Administrator | | | Compilation | . | | | 276 |. +--------------+ | +--------------+ . +-------------+ | 277 |. | . | 278 |. +--------------+ | +-------------+ +-------------+ | 279 |. | Policy | | |Policy Level | | Exchange | | 280 |. | Language | | | Agreement | | Protocol | | 281 |. +--------------+ | +-------------+ +-------------+ | 282 |. | . | 283 |. +--------------+ | +--------------+ . | 284 |. | Local Policy | | |Reconciliation| . | 285 |. | Repositories | | | | . | 286 |. +--------------+ | +--------------+ . | 287 |. | . | 288 |. +--------------+ | +-------------+ | 289 |. | PEPs | | | Monitoring | | 290 |. | | | | | | 291 |. +--------------+ | +-------------+ | 292 |......................................... | 293 +--------------------------------------------------------------------+ 295 Figure 1. MSME Architecture Components 297 The remainder of this section will describe the components and their 298 interactions in some detail and will provide a description of data 299 flow through the system to illustrate how the system is designed to 300 work. 302 2.4.1 MSME Components 304 2.4.1.1 Policy Level Agreement 306 Policy level agreements (PLAs) are the means by which each of the 307 partners in a coalition expresses and exchanges its policy. The PLAs 308 are expressed in a common language (PLAL) to facilitate exchange and 309 processing. 311 PLAs include the following information: 312 * The identity of the coalition to which a PLA applies 313 * The members of the coalition 314 * The member that created the PLA 315 * Versioning information for the PLA 316 * Abstract policy rules using arbitrary identifiers chosen by each 317 partner Some identifiers may be agreed upon to be globally unique. 318 * Bindings that map the identifiers to concrete assets or security 319 services. 321 Policy rules are defined at an abstract level, with conditions 322 expressed in terms of abstract entities or entity groups and actions 323 expressed in terms of security services and abstract mechanisms. The 324 services and mechanisms are a superset of those described in 325 [iso7498-2]. 327 Each abstract entity, service, or mechanism includes a textual name 328 which identifies one or more bindings which map the abstract part of 329 the rule to a concrete implementation (e.g., an IP address, or a 330 security protocol and its acceptable algorithms). Multiple bindings 331 may have the same name, since the required service may be implemented 332 in multiple security contexts (e.g., IPsec, TLS). 334 Some binding names may be globally recognized by the coalition 335 partners so that a partner may refer to other partners' entities 336 without having concrete bindings. For example, partner 1 can have an 337 abstract policy that requires ESP to be used between its gateways and 338 partner 2's gateways, without having to know the IP addresses of 339 partner 2's gateways when defining its policy. Those addresses will 340 be supplied by partner 2 in its PLA and will be bound to partner 1's 341 policy during the resolution process. 343 2.4.1.2 Policy Compilation 345 Compilation is the process by which each partner generates a PLA from 346 its abstract policy rules. The compilation process takes the set of 347 abstract policy rules and a database of bindings, assembles the 348 bindings needed to support the policy rules, confirms all the bindings 349 are available, other than those supposed to be supplied by other 350 partners, and checks to make sure that the policy rules are 351 self-consistent (i.e., the policies don't contain any contradictions). 352 The output of the process is either a complete PLA that may be 353 exchanged with other partners, or errors indicating that the PLA is 354 not consistent or complete and must be fixed by the policy 355 administrator. 357 2.4.1.3 Resolution 359 Resolution is the process of combining all (or some subset) of the 360 partners' PLAs into a single PLA containing rules consistent with all 361 of their policies. The 'combined' PLA is known as a resolved PLA 362 (RPLA). 364 Resolution combines two or more member PLAs in an attempt to generate 365 a single RPLA that is consistent with all of the policies expressed in 366 the individual PLAs. It identifies the security mechanisms supported 367 by all the parties required for each mission-related policy rule. It 368 also identifies the cases where all partners do not support a common 369 security mechanism for a policy rule, an indication that a 370 communication that cannot be successfully initiated due to current 371 policies, thus allowing the policy administrators to address any 372 potential deficiencies in their respective policy specifications. This 373 `diagnostic' use of resolution is an important function in real world 374 applications. 376 Resolution may be performed in a centralized manner, using a single 377 resolver for the coalition; in a decentralized manner, with each 378 member performing an independent resolution of the same set of PLAs; 379 or in some intermediate way. The MSME resolution mechanism should be 380 designed to support decentralized operations, as centralized 381 operations can be viewed as a special case of the more general 382 decentralized resolution architecture. 384 2.4.1.4 Exchange Protocol 386 The PLA exchange protocol is a common protocol is used for the 387 exchange of PLAs and RPLAs, and for monitoring the status of the 388 resolution process. 390 The exchange of PLAs and RPLAs between all partners requires some 391 exchange mechanism. Although nothing fundamentally precludes partners 392 from implementing differing exchange mechanisms on a bilateral or 393 multilateral basis, it is useful to consider a common exchange 394 protocol. Even if such a protocol is not universally adopted, its 395 architectural framework is helpful in ensuring that whatever exchange 396 mechanisms are implemented sufficiently support the requirements of 397 the MSME system. 399 The protocol's primary aim is to support the resolution process, by 400 allowing PLAs and RPLAs to be exchanged, and by allowing resolution 401 status information to be conveyed. The protocol should support the 402 following operations: 404 * Exchange of PLAs between partners, or from partners to a central 405 resolution authority. 407 * Exchange of RPLAs: In a centralized resolution architecture, 408 centrally resolved RPLAs will have to be propagated to coalition 409 partners. In a totally decentralized environment, partners may 410 still need to request each others' RPLAs for reconciliation 411 purposes. 413 * Co-ordination/synchronization of the resolution process: The 414 resolution process is essentially asynchronous, regardless of 415 whether it is performed centrally or in a distributed manner. Some 416 mechanism is required to inform entities within the coalition of 417 the current status of the resolution process. This may, for 418 example, include a means for requesting a new round of resolution, 419 or for of informing partners of the (un-)successful completion of a 420 resolution process. 422 The protocol must authenticate the source of the PLA and optionally 423 provide data confidentiality for the exchange. 425 2.4.1.5 Reconciliation 427 Once an RPLA has been generated, a reconciliation process must occur 428 so that each partner may verify that the RPLA is correct and that it 429 does not conflict with its internal policy rules. 431 A coalition partner cannot assume that any resolution that it did not 432 perform itself will yield a correct RPLA. The partner must confirm 433 that: no policy rules introduced to the coalition by the partner in 434 its PLA have been removed, no bindings have been defined in a manner 435 that conflicts with any of the definitions introduced by the partner 436 in its PLA, and no policy rules have been introduced in the RPLA that 437 conflict with any of the partner's policy rules in its PLA. 438 Additionally, a partner may use reconcilliation to identify places 439 where resolution occurred correctly, but did not achieve the desired 440 result, and may have to be adjusted by administrative intervention. 441 For example, it could detect policy rules that are not implementable 442 because no common security mechanisms exists with other partners, or 443 cases where a weaker, though still acceptable, mechanism was selected 444 instead of a stronger, more desireable one. 446 An incorrect RPLA may be generated for a number of reasons, including 447 incorrect implementation of the resolution algorithm, PLA 448 synchronization issues, or malicious intent by one of the coalition 449 partners. In order to ensure the correctness of a new RPLA that it has 450 received, a partner should evaluate its freshness and correctness before 451 provisioning it. 453 2.4.1.6 Monitoring 455 Monitoring ensures that RPLAs are being correctly generated and 456 enforced. A number of elements of the MSME system will be involved in 457 the process of monitoring that RPLAs are correctly implemented. The 458 cornerstone of the monitoring aspect of MSME is the reconciliation 459 process, which provides each partner with an essential sanity check 460 that the MSME system is generating correct policy. The versioning 461 mechanism provided by the PLAL provides a means to allow partners to 462 compare the versions of the RPLAs that they are using to ensure that 463 they are operating with consistent policies. Version checking is 464 further facilitated by the MSME PLA exchange protocol which allows 465 partners to query the status of the resolution process, and to 466 obtain the currently active RPLA. 468 Additional monitoring tasks may include verifying that enforcement 469 points are being configured with the correct policies and that they 470 are using them correctly. This monitoring is necessarily limited 471 since most communications are likely to be encrypted and a partner 472 will generally only have access to the unencrypted messages on its own 473 hosts. 475 2.4.2 Partner-Dependent Components 477 2.4.2.1 Policy Management Tool 479 The policy management tool (PMT) provides a user interface to the MSME 480 system. It provides an administrator the means to enter abstract 481 policies and bindings into the system. The PMT also must be able to 482 read the policies in a PLA or local repository and display the results 483 to the administrator. The administrator should be able to modify 484 these policies. 486 Policy management goes beyond just creating and viewing policies. The 487 PMT should provide an interface to other functions. For example, it 488 should be able to initiate the policy compilation process and display 489 the results, including any warnings or errors that it produces, so the 490 administrator can correct them. It may also be responsible for 491 initiating resolution, or at least for sending PLAs to a central 492 resolution point. 494 2.4.2.2 Policy Language 496 The choice of languages that a partner uses for defining its internal 497 policies are up to the partner, however there must be tools to 498 translate those languages to and from the PLA language in order to 499 create bindings and to translate RPLAs into the language(s) that the 500 local managment system uses to provision policy enforcement points. 502 2.4.2.3 Local Policy Repositories 504 Each partner maintains collections of information relating to their 505 existing internal policy environments. The nature of these 506 repositories is highly partner-specific. There may be databases 507 specifically for MSME data, or they may support both MSME and internal 508 policy management systems and provide the link between the two. This 509 section discusses what information the repositories must be able to 510 provide MSME. 512 The following information should be available: 514 * Asset data: Mappings between high-level assets and their 515 composition in terms of low-level assets. 517 * Security service to mechanism mappings: Whenever a high-level 518 policy requires a security service, this repository is consulted to 519 determine what mechanisms are available to implement that service. 521 * Local mechanism-specific security policy repositories 523 * Optionally, repositories of global data 525 The information in the local repositories is used in the generation of 526 bindings. For each asset specified in the high-level policy, the 527 corresponding low-level endpoints are determined from the asset 528 repository. Then for each low-level mechanism, the relevant 529 mechanism-specific repository is consulted to extract the information 530 required for policy resolution. 532 The local policy repository for each context is consulted to determine 533 which bindings are valid (from local context-specific policy 534 considerations) and may be included in the PLA. This process must 535 also be repeated with the resolved PLAs to ensure that the RPLA does 536 not violate any local policy constraints. 538 2.4.2.4 Policy Enforcement Points 540 Once a partner has received and successfully reconciled an RPLA, it 541 is up to the policy enforcement points to enforce the resolved 542 policies. This may require the partner to provision new 543 policy rules to its internal PEPs. 545 This will typically involve reprovisioning policy management and 546 enforcement agents within the partner's security domain. While this 547 provisioning is outside the scope of the MSME system, any MSME 548 implementation will have to consider the interaction between the RPLA 549 validation and acceptance mechanism, which is part of the core MSME 550 system, and the policy provisioning system, which is outside of it. 552 The nature of this link between MSME and policy provisioning 553 mechanisms is highly dependent on the nature of the specific 554 provisioning mechanisms in use. Conceptually, it would typically 555 involve the inverse of the process of extracting information 556 out of the local policy repositories. The new policy can then be 557 distributed by mechanisms such as those being developed by the 558 IPSP working group. 560 2.4.3 Data Flow 562 This section describes how the components of the MSME system work 563 together to provide policy management for dynamic coalitions. 565 +------------+ +------------+ 566 | Abstract | | Bindings | 567 | Policies | | | 568 +------------+ +------------+ 569 | | 570 v v 571 +--------------------+ 572 | Policy Compilation | 573 +--------------------+ 574 | 575 v 576 +-----+ +-----+ +-----+ 577 | PLA | | PLA | | PLA | 578 +-----+ +-----+ +-----+ 579 \ | / 580 v v v 581 +--------------------+ 582 | Policy Resolution | 583 +--------------------+ 584 | 585 v 586 +-----+ 587 |RPLA | 588 +-----+ 589 | 590 v 591 +--------------------+ 592 | Reconciliation | 593 +--------------------+ 594 | 595 v 596 +--------------------+ 597 | Provision policies | 598 +--------------------+ 600 Figure 2: MSME Data Flow 602 Policies are created by policy administrators. The people who create 603 the abstract policies and the bindings do not have to be the same, 604 since the people who understand the coalition's communication 605 requirements are not necessarily the same as those who understand the 606 concrete policies that the partner supports. 608 The MSME resolution process may be initiated for several reasons, 609 including a change in policy, abstract or concrete, or a change in the 610 coalition membership. 612 A partner must first generate a new PLA when a resolution exchange is 613 initiated and a partner determines that its policies (including 614 abstract rules, bindings, and contexts) have changed. If its policies 615 have not changed then its previous PLA may be reused. To generate a 616 new PLA, the compilation process is invoked. It takes the abstract 617 policy rules and the database of bindings, extracts the necessary 618 bindings and produces a consistent PLA, if possible. If there were 619 errors, they must be corrected manually by the policy administrators. 621 The PLA is sent, using the exchange protocol to one or more policy 622 resolvers that will be creating RPLAs. The policy resolver creates 623 an RPLA that satisfies the requirements of all the RPLAs, if possible. 624 If it is not possible, then an error is returned and the partners need 625 to manually correct their PLAs, if they wish, and attempt the resolution 626 again. Once the RPLA is produced it is sent to the partners, as needed. 628 The first step a partner performs upon receiving a new RPLA is 629 reconciliation to ensure that the RPLA is in fact consistent with its 630 policies. If reconciliation fails, the partner should correct the 631 problem, if possible, or report it to the other partners which may 632 have to make corrections to their policies to correct the problems. 634 If reconciliation succeeds, the partner should commence enforcement of 635 the RPLA. Again, the details of the operations required to enforce the 636 RPLA are partner-specific, but the overall principles are the same: 637 new concrete rules may need to be provisioned at enforcement points to 638 accommodate coalition policy. This necessarily implies a narrowing of 639 existing policy, since a broadening would require human negotiation 640 (if resolution failed, for example, one or more partners might agree 641 to relax their local policy restrictions to allow resolution to 642 succeed). 644 3. Ideas for IPSP 646 The MSME system is attempting to solve a different problem than is 647 currently being addressed by the IPSP working group so while its 648 architecture contains many similar elements, they are instantiated 649 differently. However, since it is also working in the security policy 650 management domain it may provide some insights that can improve the 651 final output of the IPSP WG, especially in the area of defining and 652 generalizing policy rules. This section explores some of the areas 653 where MSME's work may provide some insights into improving the IPSP 654 work. 656 3.1 Late Name Binding 658 Early IPSP working group drafts, now expired, such as the "Security 659 Policy Specification Language" (draft-ietf-ipsp-spsl-00.txt) and 660 "Security Policy Protocol" (draft-ietf-ipsp-spp-00.txt) included the 661 beginnings of an idea that some hosts should not be specified by IP 662 address, but could be addressed in a more general way. This allowed 663 policies, which were configured in the security servers, to be defined 664 in such a way that it did not need to specify an IP address for hosts 665 or gateways it may not know the IP address, or even if such a gateway 666 might exist. For example, those two drafts allowed policies to use 667 some defined strings such as "host", "remote-sg", or "local-sg" to 668 refer to such entities. 670 While it was an interesting idea, it was poorly developed and, as 671 described in those drafts, not completely implementable. While the 672 "host" tag could easily be interpreted as either the source or 673 destination of the communication, none of the others could be reliably 674 translated into a specific host or gateway. MSME provides some 675 insights into how to design this feature in an implementable fashion 676 and possibly ways to expand on the idea. In particular adding the 677 idea of binding a name to one or more assets could add this 678 flexibility. 680 The protocol and language could continue to use standardized strings 681 to refer to particular types of hosts as those drafts indicated. 682 However, the security servers would use bindings as part of their 683 local policies to map the strings to the appropriate network entities. 684 Their mapping could even be different for different policy rules so that 685 a communication being negotiated for host A could have a different 686 mapping than a communication being negotiate for host B, for example. 688 To illustrate this, let's look at the following example: 690 Host A ---- GW A ---- network ---- GW B -------------- Host B 691 \ 692 GW C ----- Host C 694 Host A initiates a request to discover the policy requirements for a 695 communication between itself and Host B. GW A has a policy that 696 requires a tunnel for that communication between itself and any 697 gateway that is authoritative over Hosts B or C (indicated by the 698 string "remote-sg"). GW B (or its policy server) has a binding that 699 maps the string "remote-sg" to GW B for this communication so GW A 700 then learns as part of the resolution that it needs to have a tunnel 701 with GW B. 703 If Host A then wants to communicate with Host C and the policies are 704 the same, GW B can have a binding that maps "remote-sg" to GWs B and C 705 so GW A can tunnel to either of them. 707 We can extend this concept beyond a few standardized strings that all 708 policy domains can implement. If we allow arbitrary names to be used 709 (or at least a private namespace), then security policy domains can 710 privately agree upon names to use to abstract portions of their policy 711 domains. 713 For example, if companies X and Y need to facilitate communications 714 between their engineering departments, they could agree upon "x_eng" 715 to be a name for X's engineering department and "y_eng" for Y's. X 716 can have a binding that maps "x_eng" to the necessary hosts in its 717 engineering department and Y can do similarly. Now X can create 718 policies in terms of "y_eng" instead of a list of all the IP addresses 719 in Y's engineering department. 721 This has a couple of advantages. Now the hosts in Y's engineering 722 department can change without Y having to inform X, since all Y needs 723 to do is change its binding and X's policy is still valid since the 724 name does not change. Additionally, it can help reduce the amount of 725 network information that each company needs to expose to the other. 727 While it may be possible to achieve some of this abstraction by using 728 wildcarded DNS names (e.g., *.eng.y.com) in policy rules, the binding 729 mechanism is much more powerful and general. Not only may it map from 730 a name to one or more hosts, but it can map from a name to one or more 731 conditions that are required (e.g., port, protocol, etc). For 732 example, company Y could have different bindings for its HTTP and FTP 733 servers, even if they are the same hosts, with the same host names, 734 since each binding would map the binding name to a set of hosts and a 735 port number. 737 3.2 Generalization 739 Currently, IPSP is looking exclusively at providing security policy 740 management for the IPsec security domain. If this can be accomplished 741 in a more general manner that allows the solution to be applied to 742 other security domains, it would increase the usefulness of the work, 743 without greatly increasing its scope. 745 One possible means of generalizing the IPSP work is to allow policy 746 rules to express multiple security domain options in one policy rule 747 by using bindings. 749 In order to accomplish this, policy rules must be able to be expressed 750 using names for the source and destination of the condition and the 751 action. For example, Company Y could have the policy: 753 src y_eng dst x_eng -> strong_authentication 755 Now, suppose both companies X and Y are willing to use either IPsec or 756 TLS to protect the communication. "y_eng," "x_eng," and 757 "strong_authentication" can refer to bindings that have both IPsec and 758 TLS mappings which can be sent along with the policy rule as part of 759 the policy discovery phase of IPSP's protocol. "y_eng" may map to a 760 set of IP addresses and port numbers in the IPsec context. In the TLS 761 context it may map to a set of user names. "strong_authentication" 762 may also map to the required mechanisms in each context such as an ESP 763 proposal or a TLS mac algorithm. 765 Company X can then have a similar policy: 767 src y_eng dst x_eng -> xs_authentication 769 X will have mappings for "x_eng" and "xs_authentication" in a similar 770 manor to Y. Note that "x_eng" and "y_eng" can be pre-agreed upon names 771 between the two companies as described above. "strong_authentication" 772 and "xs_authentication" are not, however. 774 Resolution of the two policies is performed at the mechanism level, as 775 would be done if the bindings did not exist. Only bindings in the 776 same context can be resolved and each context is resolved 777 independently. This allows the resolution to succeed if at least one 778 condition/action pair in one context can successfully resolve. If 779 multiple contexts successfully resolve, then both may be returned as 780 the answer. 782 4. Acknowledgments 784 The author thanks the MSME team, Luis Sanchez, Charlie Lynn, Geva 785 Patz, Alex Colvin, David Waitzman, and Rajesh Krishnan for their work 786 developing the MSME system and reviewing this draft. 788 5. References 790 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 791 Requirement Levels", RFC2119, March 1997. 793 [TERM] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, 794 B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, and 795 S. Waldbusser, Terminology for Policy-Based Management 796 draft-ietf-policy-terminology-04.txt (approved for RFC) 798 [iso7498-2] ISO. "Information Processing Systems - Open Systems 799 Interconnection - Basic Reference Model - part 2: Security 800 Architecture," first edition, International Standard ISO 7298-2, 801 ISP, February 1989. 803 Disclaimer 805 The views and specification here are those of the authors and are 806 not necessarily those of their employers. The authors and their 807 employers specifically disclaim responsibility for any problems 808 arising from correct or incorrect implementation or use of this 809 specification. 811 Copyright (C) The Internet Society (2001). All Rights Reserved. 813 This document and translations of it may be copied and furnished 814 to others, and derivative works that comment on or otherwise 815 explain it or assist in its implementation may be prepared, copied, 816 published and distributed, in whole or in part, without 817 restriction of any kind, provided that the above copyright notice 818 and this paragraph are included on all such copies and derivative 819 works. However, this document itself may not be modified in any 820 way, such as by removing the copyright notice or references to the 821 Internet Society or other Internet organizations, except as needed 822 for the purpose of developing Internet standards in which case the 823 procedures for copyrights defined in the Internet Standards 824 process must be followed, or as required to translate it into 825 languages other than English. The limited permissions granted above 826 are perpetual and will not be revoked by the Internet Society or 827 its successors or assigns. 829 This document and the information contained herein is provided on 830 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 831 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 832 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 833 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Author Information 838 Matthew N. Condell 839 BBN Technologies 840 10 Moulton Street 841 Cambridge, MA 02138 842 USA 843 Email: mcondell@bbn.com 844 Telephone: +1 (617) 873-6203