NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 18-Jul-00
Chair(s):
Hilarie Orman <horman@novell.com>
Luis Sanchez <lsanchez@bbn.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Marcus Leech <mleech@nortelnetworks.com>
Mailing Lists:
General Discussion:ipsec-policy@vpnc.org
To Subscribe: ipsec-policy-request@vpnc.org
In Body: subscribe
Archive: http://www.vpnc.org/ipsec-policy/
Description of Working Group:
Note: Lee M. Rafalow (rafalow@us.ibm.com) is the Policy Schema Advisor for IPSP
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:
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:
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 |
Internet-Drafts:
No Request For Comments
IPSP Meeting (August 4, 2000)
----------------------------
Chairs:
Luis Sanchez
Hilarie Orman
Luis Sanchez
------------
Luis gave an update on the working group status. Brief overview of previous 3 meetings; new drafts have been submitted, old drafts have been revised/renewed:
- Configuration Policy Model
- IPSP Requirements
- IPSP Architecture
- IPSP Information Base (PIB)
- Security Policy Protocol (SPP)
Luis Sanchez and Russ Mundy had a meeting with the Policy Framework co-chairs to discuss inconsistencies between P-CIM and IPSP Data Model with respect to authentication items.
This is ongoing work, more on the mailing list.
Hilarie Orman
-------------
Hilarie discussed the new roadmap draft (sent to the mailing list). The main documents envisioned are:
Requirements
Data model
Architecture
Policy language
Also parser implementation(s)
Provisioning
Also implementation(s)
Policy exchange and negotiation protocol
All these documents will be standards track. The architecture document brings together all the other documents, describing their composition and operation.
Large number of documents (9 or so), need to be synchronized with each other; some of them are early versions of the standards track documents, some are relevant independent submissions. The Policy Terminology draft (draft-ietf-policy-terminology) is of particular interest for obvious reasons.
Total size of drafts about 500Kbytes! A lot of material, and there is a need to reduce them so they can be read and understood.
Issues: authentication policy must be defined, security domain definition, policy integrity assurance if it's not received from a trusted source.
Question from the audience about the configuration language (is one needed, are we going to specify it, what would it be). Luis answered that the language is not believed to be in our scope (to be discussed on the mailing list if people think it's needed).
David Waitzman
--------------
David presented SPSL and discussed some recent changes in the draft
(draft-ietf-ipsp-spsl-00)
SPSL follows the IPsec model (draft-ietf-ipsp-config-policy-model-01). The policy classes have a mapping to SPSL constructs (e.g., IPsecPolicyGroup corresponds to a set of policy objects from an SPSL file); in some cases, that mapping does not exist (e.g., SACondition has no equivalent in SPSL), because they are not needed (can be included if necessary). David discussed all the mappings between the poliy model and SPSL.
Summary: SPSL represents the policy model fairly well, a few extension necessary to support some properties.
Contact info: mcondell@bbn.com
Matt Blaze
----------
Matt discussed the requirements draft (draft-ietf-ipsp-requirements-00).
What is the main requirement? We need to provision policy for IPsec nodes. The key management protocol(s) (IKE) doesn't (and shouldn't) handle policy. IPSP is framework for managing IPsec policy.
Problem space:
- Any node may "run" IPSP
- IPSP must handle decentralized, heterogeneous administration
- SA parameters not specified in advance
Need common language for resolving policies; language/system must handle complex administration details (remote administration, delegation, etc.)
Need well-defined semantics -- secure, sound, comprehensible. Even implementation should be fairly straightforward.
So, the requirements are:
- A policy model
- Gateway discovery mechanism
- A policy language for nodes
- Policy distribution mechanism
- Policy discovery protocol
- Method for resolving SA parameters
- Semantics for compliance checking SA parameters and gateway against each node's policy
- No changes to anything else (especially IKE)
Policy model -- everything works based on the semantics defined therein. Model must be abstract.
Discovery protocol -- directly from charter.
Language -- external representation. May be different from host's vendor policy configuration mechanism. Output of policy discovery protocol, input to SA resolution and compliance checking.
Policy distribution mechanism -- handle remote administration, delegate authorization/responsibility.
Policy discovery -- provide information so other hosts can find out how to communicate with it.
SA parameter resolution -- efficiently determine, given the two nodes' policies, whether and how they can communicate (SA parameters).
Compliance checking -- given a set of SA parameters and other information, must be able to verify whether parameters meet policy and gateway is authorized/correct. Policy enforcement is really done here.
Slides available at http://www.crypto.com/talks/
Angelos Keromytis
-----------------
Gave a presentation on the architecture draft.
Some notes from Matt Blaze on the questions asked:
Q: for many people configuration is *the* problem
architecture shouldn't describe particular protocol (SPP)
LUIS: agree that config is a problem
- other groups do config provisioning
- we provide guidelines for provisioning protocols
- needs to be added to architecture document
- other documents will discuss specific provisioning protocols
Q: Which groups?
LUIS snmpconf, rapp, ldap
Q: any considation in this group for DMTF?
- distributed mgt task force (another organization)
- DMTF is involved in information model for ipsec policies
- working to make consistent with ipsp
Arayhan Cuervo
--------------
Arayhan discussed some of his thoughts on IPSP. The main points:
- Use IKE or other protocols as much as possible in doing discovery, negotiation, distribution, etc.
- Separate SG discovery and policy distribution/discovery protocols.
- End hosts do not deal with IPSP at all.
- Identity protection of IPSP initiator.
- Policy should be confidential.
- Pre-authenticate firewalls/SGs before doing policy negotiation
(using IPsec or some other protocol ???)
- Distribute more than IPsec policy.
draft-ietf-cuervo-ipsp-arch-00
Jamie Jason
-----------
Jamie discussed the policy model draft
(draft-ietf-ipsp-config-policy-model-01)
Model represents configuration portion on DMTF IPsec policy model, derives from PCIM where appropriate (some differences). Similar modeling technique as PCIM. Some changes from previous version of the draft (aggregation of policy groups/rules, roles, fallback actions, IPSO filters, credential filters). DMTF has more "start conditions" for SA setup (e.g., machine boots, IKE message is intercepted, etc.) More static actions (closer to firewall filters), how to handle IPv4 DF bit for tunnels. More changes described.
Explicit DH groups were removed from latest version, but may be added back.
Man Li
------
Man Li discussed the IPsec Policy Information Base draft
(draft-ietf-ipsp-ipsecpib)
The draft describes an IPsec PIB that enables a policy server (PDP) to push down security policy to IPsec-enabled devices (PEP), using COPS-PR for transport.
PDP pushes down IPsec policy with DECISION messages containing IPsec PIB, either in response to PEP's REQUEST or when the PEP's IPsec policy changes at the PDP. Consistent with the IPsec Configuration Policy Model. The IPsec PIB currently has 7 groups and 17 tables (see draft for more details -- Man Li briefly described all these).
The draft is a first design, items to be added are:
- IP security option filters, credential filters
- startup conditions that caused IPsec rule evaluation
- De-couple IKE from IPsec
- Fallback actions (e.g., "talk to gateway A, if unable talk to B")
-------
Ricky Chalet (Redcreek) mentioned starting an IPSP MIB -- contact him if interest.
Luis Sanchez asked the DMTF folks to give examples for "network level policies".
Hilarie: please use the mailing list, get some discussion going on.
-Angelos
None received.