Last Modifield: 08/02/2002
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 for supporting IP security Policies. This model preferrably derives from the Information 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:
draft-ietf-ipsec-policy-model-00.txt
draft-ietf-ipsec-vpn-policy-schema-00.txt
draft-ietf-ipsec-spsl-00.txt
draft-ietf-ipsec-sps-00.txt
draft-ietf-ipsec-secconf-00.txt
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.
| JAN 00 | Post an Internet-Draft on IPsec Policy Management Roadmap | |
| JAN 00 | Post an Internet-Draft on Requirements for IPsec Policy Management | |
| FEB 00 | Post a revised draft for the IPsec Policy Information and Data Model | |
| JUN 00 | Conduct initial interop testing of a Policy Exchange and Negotiation Protocol | |
| SEP 00 | Submit applicable drafts for PS consideration | |
| OCT 00 | Revisit WG charter |
Minutes of IPSec Policy, IPSP, 55th IETF, Monday, November 18, 3:30 pm EST Attendance at the meeting was over 100 people. The meeting opened with agenday bashing and a status of the WG documents. The policy configuration documents are within episolon of being ready to present to the IESG for a request for promotion to Proposed Standard. Other Working Group items need discussion and decisions about direction. The Area Direction, Steve Bellovin verifies that he alone has looked at the submitted documents and he provided feedback to the document authors. The IESG as a whole has not yet seen them. The AD comments are summarized in the Chairs' presentation. Man Li asked if AES must be added to the supported algorithms list, and the answer was yes. Another was whether or not the lifetime counters should be specified at 64-bits in the IPSec architecture document. The answer is no, but we should make sure that the IPSec group is aware of the need to match the lifetime counter size to the linespeed. For configuration, we have chosen 64-bits because it is large enough for all expected needs. Eric Vyncke presented the IPSec Configuration Policy Model status. In response to his comments that the ICPM is fairly abstract was is not expected to have much in the way of concrete security considerations, Steve Bellovin commented that he expects the WG's in the security area to have expertise for writing good security considerations sections. Luis Sanchez replied that the Architecture document will be revived for use as a normative reference, and this will answer many of the questions for security considerations. The ICPM revisions based on AD feedback will be incorporated and the document will be resubmitted very soon. The WG Chairs will notify the AD when the new documents are available, and this will alert him to begin tracking the document through the IESG document tracker. Man Li presented the Policy Information Base (PIB) document. This document is complete, modulo the 64-bit counters. Robert Story presented a summary of the MIB document. The MIB extends the ICPM with generic offset in the iPHeaderFilter. This document is nearly done, normative and non-normative references have been added, and the AD comments on the other documents will be addressed in this document as well. The next version will be available very soon. Demonstrations of the net-policy project (net-policy.sf.net) were available during the conference of the freely available reference release (http://net-policy.sourceforge.net for Linux and PlutoPlus + Apache + perl for GUI). An informal poll showed that a handful of attendees are planning to use PIBs or MIBs in projects in the very near future. Demonstrations of the net-policy project (net-policy.sf.net) could be given during the conference of the freely available reference release could be given by the above 3 people. Bill Sommerfield presented the PF_POLICY concept, which is one part of a three-part API for IPSec: IPSec management, PF_POLICY, PF_KEY. He was asked several questions about how PF_KEY might change and what the status of documentation and implementation is. He said that some minor parts of the implementation were done and that he needed time to write up the documentation. He got a volunteer to assist in writing a requirements document. We can expect a document on PF_POLICY by second quarter 2003. Michael Richardson re-presented slides about policy discovery. We need further discussion on the mailing list about how this might be used for enterprise and ISP |