IPSP Working Group L.A. Sanchez
INTERNET-DRAFT BBN Technologies
Expire in March, 2001 H. Orman
Novell Corporation
November 16, 2000
A Roadmap for IPsec Policy Management
draft-ietf-ipsp-roadmap-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the approach that the IPSP WG will follow
to resolve the challenges that IPsec compliant devices phase with
respect to modeling, specifying, translating, provisioning,
exchanging, negotiating, checking and enforcing IPsec policies.
1. What is the IPSP WG trying to solve?
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.
2. Roadmap to a solution
In essence the IPSP WG will produce a set of documents and working
code. To accomplish this the IPSP WG will work on the items listed
below. Please note, that not all items require code
development. Below, you will find a complete list of all
items. The IPSP WG will:
1) first establish the requirements for IPsec policy
management. Any solution developed under the IPSP umbrella
MUST meet these requirements. The requirements document
will cover all aspects of IPsec policy management including:
- IPsec data model
- IPsec policy architecture
- IPsec policy specification
- IPsec policy provisioning
- IPsec security gateway discovery
- IPsec policy discovery, negotiation, conflict
resolution and compliance checking
This WG item will produce a standards-track document.
2) define a data model for IPsec policies. This model will be
compatible with the P-CIM [PCIM]. This WG item will
produce a standards-track document.
3) develop an architecture for IPsec policy management. The
document will discuss and cover the following topics:
- IPsec data model
- IPsec policy specification
- IPsec policy provisioning
- IPsec security gateway discovery
- IPsec policy discovery, negotiation, conflict
resolution and compliance checking
This WG item will produce a standards-track document.
4) develop a flexible, vendor-independent language to
represent IPsec policies. The language MUST follow the
IPsec data model which in turns follows the P-CIM.
This WG item will produce a standards-track document and
parser implementations.
5) develop guidelines for the provisioning of IPsec policies
using existing policy provisioning protocols. This includes
profiles for distributing IPsec policies over protocols
such as LDAP, COPS, SNMPCONF, FTP, etc.
This WG item will produce standards-track documents and
implementations.
6) specify and develop adopt or develop an IPsec policy
exchange and negotiation protocol. The protocol must be
capable of:
i) discovering security gateways
ii) exchanging 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.
Note that the WG MAY decide to divide the above-mentioned
functionality into one or more protocols. This WG item will
produce a standards-track document and implementations.
3. Roadmap Nutshell
Requirements document. Standards track.
Roadmap Document. This is the roadmap document. Standards track.
Data Information Model. Standards track.
Policy Management Architecture. Standards track.
Specification Language. Standards track document and a reference
implementation of the parser.
Provisioning Guidelines. Standards track document and implementations
using existing provisioning protocols.
Policy Exchange and Negotiation Protocol. At least one standards
track document and implementation.
4. Security Considerations
The document provides a framework for applications to identify the
relevant policies in place across the network. Policies must be
communicated in a secure way so as not to jeopardize the ability
of the application to run. It is also important to ensure that the
policies that are communicated statically or dynamically to the
Policy Enforcement device are doen so, securely. Not doing so could
compromise the security of the entire network.
REFERENCES
[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401.
[RFC2403] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402
[RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406.
[PCIM] Moore, et al., "Policy Core Information Model -- Version 1
Specification"
ftp://ftp.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-07.txt
[RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407.
[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409.
Authors' Addresses
Luis A. Sanchez
BBN Technologies
GTE Internetworking
10 Moulton Street
Cambridge, MA 02140
Voice: (617) 873-3351
EMail: lsanchez@bbn.com
Hilarie Orman
Novell, Inc.
Net Content Services
1800 South Novell Place
Provo, UT 84606
Voice: (801)861-5278
EMail: horman@novell.com