IPsec Policy WG Meeting Date: December 11, 2000 Time: 1930-2200 Minutes Recorded by: Angelos Keromytis Meeting agenda 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 - implementations Policy exchange and negotiation protocol: standards track IMPLEMENTATIONS! 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) ------------------------------------------- http://rafalow.home.mindspring.com/dmtf.htm 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 Condition differences: - 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) Group-related differences: - 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 Policy Roles: - IPSP uses explicit association of rules with interfaces; PCIM uses a named relationship. - IdentityContext 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) ----------------------------------- draft-ietf-ipsp-ipsecpib-01.txt 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 --- Luis: - 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.