2.6.3 IP Security Policy (ipsp)

Last Modified: 2003-02-14

Chair(s):

Security Area Director(s):

Security Area Advisor:

Technical Advisor(s):

Mailing Lists:

Description of Working Group:

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.

Goals and Milestones:

Internet-Drafts:

No Request For Comments

Working group: IPSP
Minute-taker: Michael Richardson
 
There were no comments during the traditional minute reserved for agenda 
bashing.

WG Status.    - Hilarie Orman summarized the document status:
 
 Sent to Security ADs on 2002/8/27.
 	- IPsec Policy Requirements (informational)
 	- IPsec Configuration Policy Model
 	- IPsec Policy Information Base (informational)
 
The IESG reviewed documents and provided feedback on the first two.  The 
authors discussed the commetns with the AD's, made changes, and 
resubmitted the drafts.  The drafts are marked in the ID tracker with 
dependencies, and thus, the PIB will not be reviewed until the 
Configuration Policy Model has been resubmitted.  The chairs believe that 
this has been done and that the AD should take action.
 
The MIB draft received extensive discussion and is dependent on the IPSec 
DOI MIB which only recently was submitted to the IESG; discussion with the 
IPSec chairs revealed that IPSec intends to advance all of its MIB 
documents simultaneously and expects quick approval.  We will proceed with 
the IPSP MIB document on that assumption.

Lee Rafalow has served as the IPSP liason to the DMTF, and with his able 
help the IPSP Policy Configuration Model was able to benefit from the 
groundwork in the DMTF.  Lee has left policy standards work, and this 
jeopardizes IPSP's ability to resolve the remaining minor but thorny 
issues of compatibility.  A new liason is sought (post IETF note: Andrea 
Westerinen is our new DMTF liason).

Other charter items for the WG has received some interest, but there has not 
been enough momentum to produce results.  These items are the protocol for 
discovering security pathways (gateway sequences with compatible 
policies) and the API for reading/writing IPSec policy in an running 
system, much like PF_KEY.  We need volunteers to work on these items.

2) Eric Vyncke, IPsec Policy Configuration Model.

The name of this document has changed to: IPsec Policy 
Configuration Information Model.  Some changes in latest draft were due to 
new features in DMTF specification.  There are some conflicts with newer 
DMTF direction vs IPsec direction.  There have been problems keeping in 
contact with the DMTF work; our liason to the DMTF has abandoned his role.

3) Man Li, PIB document
    Has been sent to IESG and review is pending (see above).
 
4) Wes Hardarker, IPSP - IPsec Policy MIB.
    This has received feedback from ADs, but isn't in IESG last-call.
    - multiple vendors planning implementations
    - switch to SNMP model of encoding some integer types, and various 
rules.
 
5) Bill Sommerfield reports no progress on PF_POLICY.  Seeking 
volunteers.
 
6) Luis Sanchez, SPP presentation (same as 1998); seeking 
volunteers.
 
7) Working group charter discussion.