NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 16-Nov-00
Hilarie Orman <firstname.lastname@example.org>
Luis Sanchez <email@example.com>
Security Area Director(s):
Jeffrey Schiller <firstname.lastname@example.org>
Marcus Leech <email@example.com>
Security Area Advisor:
Marcus Leech <firstname.lastname@example.org>
Lee Rafalow <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe
Description of Working Group:
The rapid growth of the Internet and the need to control access to network resources (bandwidth, routers, hosts, etc.) has quickly generated the need for representing, discovering, exchanging and managing the policies that control access to these resources in a scalable, secured and reliable fashion.
Current IP security protocols and algorithms [RFCs 2401-2412, 2085, 2104 and 2451] can exchange keying material using IKE [RFC2409] and protect data flows using the AH [RFC2402] and/or ESP protocols [RFC2406]. The scope of IKE limits the protocol to the authenticated exchange of keying material and associated policy information between the end-points of a security association.
However, along the path of a communication, there may be administrative entities that need to impose policy constraints on entities such as security gateways and router filters. There also is a need for end-points of a security association and/or, for their respective administrative entities, to securely discover and negotiate access control information for the end hosts and for the policy enforcement points (security gateways, routers, etc.) along the path of the communication.
To address these problems the IPSP Working Group will:
1) Specify a repository-independant Information Model and repository-specific Data Model for supporting IP security Policies. These models preferrably derive from the Information Model and the Data Model as defined in the Policy Framework WG.
2) Develop or adopt an extensible policy specification language. The language should be generic enough to support policies in other protocol domains, but must provide the necessary security mechanisms that are vital to IPSEC.
3) provide guidelines for the provisioning of IPsec policies using existing policy distribution protocols. This includes profiles for distributing IPsec policies over protocols such as LDAP, COPS, SNMP, and FTP,
4) adopt or develop a policy exchange and negotiation protocol. The protocol must be capable of: i) discovering policy servers, ii) distributing and negotiating security policies, and; iii) resolving policy conflicts in both intra/inter domain environments. The protocol must be independent of any security protocol suite and key management protocol. Existing protocol work in the IETF, such as SLP, will be considered if such protocols meet the requirements of this work.
5) Work with the "Policy Terminology" design team to define a common set of terms used in documents in the area of Policy Based (Network) Management.
The proposed work item for this group would yield standards that are compatible with the existing IPsec architecture [RFC 2401] and IKE [RFC 2409], complementing the standards work achieved by the IPsec Working Group. The data model, specification language and exchange protocol will evolve from some of the work previously published in the following documents:
This group will also coordinate with other IETF working groups working on specifying policies and policies schemas in order to maintain compatibility and interoperability. In particular, this working group will work closely with the Policy Framework WG to ensure that the IPsec Policy Information and data model fits and can be supported within the general Policy Framework.
Goals and Milestones:
Post an Internet-Draft on IPsec Policy Management Roadmap
Post an Internet-Draft on Requirements for IPsec Policy Management
Post a revised draft for the IPsec Policy Information and Data Model
Conduct initial interop testing of a Policy Exchange and Negotiation Protocol
Submit applicable drafts for PS consideration
Revisit WG charter
No Request For Comments
IPsec Policy WG Meeting
Date: December 11, 2000
Minutes Recorded by: Angelos Keromytis
Agenda bashing (L. Sanchez)
Roadmap document (H. Orman)
Requirements doc. (M. Blaze)
IPsec config. model (J. Jason)
QPIM/IPsec model (L. Rafalow)
Arch. Issues (A. Rayhan)
SPSL updates (M. Condell)
IPsec Config. MIB (R. Charlet)
IPsec MIB (M. Li)
Discussion (L. Sanchez)
Roadmap items (Hilarie Orman)
Hilarie talked about the intent on producing various documents:
Requirements: standards track
Data model: standards track
Architecture: standards track
Policy language: standards track
- also parser implementation
Provisioning: standards track
Policy exchange and negotiation protocol: standards track
Hilarie talked about the status of documents (see slides for draft names). Comments are sorely needed on the requirements and architecture drafts, to begin with; comments on all the other drafts (policy model, etc.) is also needed.
Need for policy MIBs; we also need to make sure the various (numerous) documents are consistent with each other.
We need definitions for:
- authentication policy (and translation into data items)
- definition of "security domain"
- policy integrity
Requirements Document (Matt Blaze)
Matt outlined the issues referenced in the requirements document:
- policy model
- gateway discovery mechanism
- policy languages for nodes
- means for distributing responsibility
- protocol for discovering policy
- method for resolving SA parameters
- semantics for compliance checking SA parameters & gateways against each node's policy
- no changes to anything else (IKE, IPsec, etc.)
Policy model: defines all the semantics of IPsec policy, and should be independent of specific details (language, protocols, etc.)
Gateway discovery: self-explanatory
IPSP language: this is for externalizing policy; how policy is expressed internally is not important for this WG
Distribute policy: delegation; must be possible to have remote administration of node's policy
Policy discovery: protocol used by nodes to determine how to talk to each other; does not need to be full disclosure.
SA parameter resolution: given the results from policy discovery, resolve those in determining what can/should be used for the SAs. Must be computationally efficient enough to be practical (general case is NP complete).
Compliance checking: given a set of proposed SA parameters, verify that a node must be able to verify whether they meet its own policy. This is where policy enforcement is implemented (and is safe even if SA resolution gives wrong results).
No changes to anything else: self-explanatory -- IPsec too long enough and is complicated enough.
Slides on: http://www.crypto.com/talks
Question: how much is authorization vs. "what to propose" ?
Answer: one input to IPSP as a system is "I want to talk to host foo, tell me what I need to do"; on the other side, the `responder` needs to verify a symmetric operation, in verifying that the proposed attributes (SA parameters, addresses, authentication mode, etc.) meet local node policy.
Question: in addition to doing gateway discovery, do we also discover other information like proxy nodes behind the gateway ?
Answer: this is probably outside the scope of the IPsec policy.
Question: When we're done with the work, do you think we'll be able to be as flexible/easy-to-use/whatever as SSL (talk to anyone in the world with minimal or no setup) ? Or is IPSP more geared towards extranet-like scenarios ?
Answer: We certainly want to be able to do the talk-to-anyone scenario. Solving the end-to-end communication case, makes it possible to actually solve the network-to-network (firewall-to-firewall) configuration etc.
IPsec Policy Model Updates (Jamie Jason)
Numerous changes to DMTF version since last IETF; model has stabilized, and has been submitted for inclusion in CIM v2.5. Those updates will be rolled up into IETF version.
Numerous changes in Policy, Condition/Filter, Action, Proposal/Transform classes were described (too many/too fast to write down -- see the slides for details).
New draft with those changes will probably be out in January.
Location of slides will be posted on the mailing list by Jamie.
Question: is the model supposed to capture authorization issues ?
Answer: the CredentialFilter entries are supposed to capture the authentication side of authorization; the rest of the model can capture authorization issues like time-of-day considerations (e.g., "users can only login between 9am-5pm")
IPSP Configuration Model Framework Feedback (Lee Rafalow)
Some differences in the models between PCIM/QPIM and IPsec Configuration Information model. Some of them come from layering variations:
- PCIM is a general framework
- QPIM is a domain-level policy model
- IPsec Configuration Information Model is a device-level policy model
- IPSP provides discipline specific condition evaluation information, where as QPIM uses a more generic approach
- There are different identities in IPsec, at different times in the protocol sequence.
- Condition evaluation is predicated on presence of information (e.g., some rule may begin as true, but eventually turn out to be false -- an example was given with Phase 1 IDs in IKE); this is partly because of authentication (some information in the protocol is authenticated/verified long after it is known/discovered/assumed)
- Priorities are applied to groups vs. individual filters (IPSP vs. QPIM)
- Rules in exactly one group (in PCIM they can be in multiple groups)
- Unique rule & group priorities (thus, deterministic rule evaluation order)
- Different Decision strategies:
-- IPSP uses MatchFirst
-- QPIM has a number of different strategies
- IPSP uses explicit association of rules with interfaces; PCIM uses a named relationship.
Other discussion topics:
- Sequence actions (like FallBack) between PCIM and IPSP somewhat different semantics ("mandatory" vs. "use first appropriate")
Question: what happens if we don't resolve those differences ?
Answer: we probably want to keep in sync as much as possible, if only to make it possible to interact. There aren't any specific disasters.
Comment from Luis: differences between the IPSP model and models from other WGs will be tolerated if it's necessary to be different. Otherwise, it makes sense to reconcile.
Lee: there are a couple of important differences, but most of the changes are details and don't really matter.
Architecture Issues (A. Rayhan)
draft-cuervo-ipsp-arch-02.txt (hasn't made it into the I-D yet)
Abdul discussed the issues on the mailing list:
- Discovery and resolution: should these be bundled ?
-- Currently, several concepts are merged in one protocol (gateway discovery, policy negotiation, exchange, resolution, distribution).
-- Proposal to separate discovery from resolution:
--- stable/scalable framework for the development of the architecture
--- provide stronger security model
--- allow better extensibility
There are two types of policies: distributed and local.
Distributed: SGs need to be discovered and tunneling policies should be resolved.
Local: access and SA policies are installed only on the two ends of the tunnel and there is no need for collective knowledge.
Distributed policies reflect mostly security requirements, whereas local policies reflect security policies.
Requirements for distributed policies:
- requests can at least be authenticated (can't be encrypted)
- piggyback requests in a message can be used to construct a topology matrix
- the topology matrix is used to resolve conflicts across SGs
- this phase precedes the next phase
- Policy Signaling Protocol
Requirements for local policies: (too fast to write down, see slides)
Summary: separate gateway discovery and policy distribution
Slides will be made available through the mailing list.
Question: are the end hosts involved in the signaling ?
Answer: they can be (they can pretend to be security gateways for themselves)
SPSL Updates (M. Condell)
Matt gave a quick update on the status of the SPSL draft; current one has expired but there's been work on the new one (hopefully available in the next month or two).
Briefly: some classes were combined, short form of policy class was dropped, added forward action, and some text cleanup.
Some more changes to appear (in the new draft): policy file description class (for describing the policy file itself), logging actions, add missing defaults for some selectors and actions, finish incomplete sections (certificate encodings, general SA endpoints, re-think object signing, support for DNS names wherever missing).
IPsec Configuration MIB (R. Charlet)
Rick talked about the status of this effort; in short, have done about 20% of a MIB so far, but in conflict with the IPsec PCIM at this point. Group of volunteers approach hasn't worked very well so far, will take the effort to the mailing list. Intent to have a -00 draft before next IETF.
A high-level group outline of the MIB was shown, feedback requested.
Question: is there any work in the Policy Framework WG that allows derivation of MIB from a PCIM ?
Answer: not really; there's some experience in the area, but no tools or anything solid at this point.
IPsec Policy Information Base (PIB) (M. Li)
PIBs are used by policy servers to distribute IPsec policy to IPsec-enabled devices (gateways, routers, laptops, etc.) using the COPS protocol. COPS is used for QoS configuration, so the goal is to reuse the same mechanism.
New items in draft -01:
- Separate roles in IPsec and IKE rules, so they can be used independently from each other.
- Added start-up conditions for IPsec and IKE rules
It used to be there was only "OnDemand" condition (as packets showed up). There are three new types:
- OnBoot (when a system boots)
- OnTraffic (OnDemand)
- OnPolicy (time-based, a rule is fired or becomes valid based on time constraints)
- Modified Selector table construction
- Added Conformance section
Things to add: need to align with IPsec Information Model, and add policy target IPsec capabilities.
Question: it seems difficult to keep this synchronized with the Information Model. It looks like it's a moving target trying to keep them consistent with each other.
Answer1: one approach is to get the Information Model more or less stable, then try to sync the PIB.
Answer2: there's all sorts of problems with policy versioning and migration, that are related to this. Difficult issue.
--- End of presentations ---
- We need to send the following documents to Last Call:
IPSP RoadMap, IPSP Requirements, IPsec Configuration Policy Model
Feedback is needed!
Hilarie: What's the status of implementations, especially on the Information Model ?
Jamie: there has been some feedback from inside the DMTF process, some people are trying to implement the Information Model.
Answer2: one reason we're not seeing implementation feedback is because policy is a large project *and* all-or-nothing. A "first step" approach may be easier to follow.
Luis: the information model is trying to capture the complexity of the existing IPsec protocols, thus it has to be pretty big and comprehensive.
Marcus: there's a large dependency on humans to interpret policy for firewalls etc. so IPSP should make it easier to automate this process.
End of session.