IPSP Working Group A. Keromytis
Internet Draft U. of Pennsylvania
M. Richardson
Sandelman Software Works
L. Sanchez
BBN/GTEI
October 1999
draft-keromytis-ipsp-arch-00.txt
IPsec Policy Discovery Architecture
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 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."
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 an IP Security Policy architecture that
conforms to the requirements set forth in [IPSP-REQ]. The
architecture defines the mechanisms and protocols needed for
discovering, accessing, and processing security policy information
of varying granularity. The architecture accommodates topology and
policy changes without need of manual reconfiguration of clients
and security gateways.
1. Introduction
The Security Policy System (SPS) defines a distributed database of
security policy information. It provides the mechanisms needed for
discovering, accessing, and processing security policy information
of hosts, subnets, or networks.
In the SPS architecture there are two types of systems, Policy
Servers and Policy Clients. Policy Servers provide a security
policy repository that Policy Clients (end hosts and security
gateways) may consult to determine what the security parameters for
a particular communication should be.
Policy Clients must be configured to know their Policy Server(s).
This configuration may be manual or through some automated
discovery mechanism.
Policy Servers must be provided with the security policy for the
systems it is responsible for. How the policy is determined and
stored in the Policy Server itself is outside the scope of this
specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
1.1 Terminology
See [IPSP-REQ] for the terminology used throughout this document.
2. Architecture Overview
A host (H1) that wishes to communicate with a remote host (H2)
first needs to decide what the end-to-end security parameters of
that communication should be. These may be stored or otherwise
determined locally (e.g., an application required some specific
form of traffic protection, through some OS-specific mechanism), or
may be retrieved from its appointed Policy Server. The Policy
Server may also know exactly what SAs need to be negotiated, either
because it was configured with that information or because it has
cached the result of a previous lookup.
If the Policy Server does not have such cached information, the
host enters a discovery phase, wherein it tries to establish what
security gateways lie in the path to the remote endpoint. This is
achieved through a special discovery message that is sent to the
remote endpoint.
A security gateway that intercepts this message consults with its
Policy Server to determine what security parameters are required
for the packets from H1 to H2. The Policy Server may have cached
information from previous runs of the discovery process, in which
case it is returned to the security gateway (and from there, to the
origin of the discovery process). If not, the security gateway
forwards the discovery message to H2, along with its security
requirements for packets from H2 to H1 (the reverse path). Each
subsequent security gateway that intercepts this message repeats
this step. If at any point a Policy Server does have cached
information relevant to this discovery process, it may provide it
and cause the discovery process to end.
Eventually, the discovery message reaches the Security Gateway
"closest" to host H2, which consults its Policy Server. If the
Policy Server has not been configured to provide Security Policy
information for host H2, the Security Gateway will forward the
discovery message to host H2. In that case, host H2 determines the
security policy for the end-to-end communication (possibly by
querying its Policy Server). H2 then sends a message to that last
security gateway, describing the security requirements for packets
from H1 to H2.
That security gateway adds to these requirements its own (that is,
the requirements for packets from H1 to that security gateway).
This step is repeated until H1 receives a message from its closest
security gateway that contains the security requirements of all the
security gateways along the path to H2, as well as H2's
requirements. At the end of this process, both H1 and H2 have a
list of security requirements of all the security gateways along
the path between them. If H2 is not satisfied with these
requirements, it may initiate a discovery process to H1 on its own.
Furthermore, at each step where a host or security gateway receives
policy information, it MAY forward such information to its Policy
Server for caching, and it may cache the policy information
locally.
3. Security Gateway Discovery Protocol
This section gives a brief overview of the Security Gateway
Discovery Protocol. A separate document will describe the protocol
in more detail.
The Security Gateway Discovery Protocol (SGDP) is implemented as a
transport protocol over IP.
The SGDP allows the initiator of the discovery process to determine
the security policy of all Security Gateways between itself and the
remote end-host, as well as the security policy of the end-host
itself. The origin end-host or Security Gateway would then
establish the necessary SAs (or reuse existing SAs where
applicable/feasible) with the Security Gateways and remote
end-host, using some automated SA-negotiation protocol, such as IKE
[RFC-2409] or Photuris [Photuris].
The security policy information acquired through the discovery
process includes parameters for the SAs that should be established
with a particular SG or end-host, security credentials (e.g.,
certificates) that should be used by the SA-negotiation protocol,
as well as other (as yet undefined) information.
To compensate for topology changes, the discovery process may be
instructed to discard cached information, forcing a complete path
traversal to occur.
4. Security Policy Server Operation
The following sections discuss the operational requirements of a
Policy Server in the IPSP architecture.
4.1 Security Policy Server Query Protocol
This section gives a brief overview of the Security Policy Server
Query Protocol (SPSQP). A separate document will describe the
protocol in more detail.
The SPSQP supports the following primitives:
* Client registration (and de-registration).
* Client download of their security policy.
* Client download of cached security policy.
* Client upload of their security policy.
* Client upload of security policy found in a received SGDP
Discovery Message for caching purposes.
* Server push of (updated) security policy to registered clients.
A Policy Server MUST verify the legitimacy of clients downloading
or uploading security policy information. Clients MUST verify the
identity of the Policy Server.
All communications over SPSQP MUST be secured. IPsec MUST be used
to secure all communications between Policy Servers and clients
(end-hosts and Security Gateways), and verify the legitimacy of
Policy Servers and clients.
4.2 Security Policy Caching
A Policy Server, SG, or end-host MAY choose to cache policy (and
policy-related, such as credentials) information acquired through
the discovery process. Policy information MUST have an indication
as to what its cache lifetime is. Policy Servers, SGs, and
end-hosts that cache policy information MUST remove expired policy
entries from their caches.
Note that some policy objects MAY specify other types of expiration
mechanisms (e.g., online validity checks). There are two classes
of such objects:
* Policy information that is verified by SGs and end-hosts (e.g.,
certificates and other types of credentials). Policy Servers,
SGs, and end-hosts MAY periodically verify the validity of such
information in their caches. Invalid entries MUST be discarded.
* Policy information that is used-as is by SGs and end-hosts.
Policy Servers, SGs, and end-hosts that cache such objects MUST
periodically verify the validity of such information in their
caches. Invalid entries MUST be discarded.
4.3 Security Policy Decorrelation
Security Policies MUST be decorrelated. More text will be added in
this section, explaining the necessity and mechanics of
decorrelation. A separate document will describe the decorrelation
algorithm in more detail.
4.4 Policy Server Discovery
An end-host or Security Gateway MUST be configured so that it can
contact its Policy Server. Such information may include network
addresses, security credentials (for IPsec), etc.
Some automated mechanism for discovering a Policy Server MAY be
defined as part of this architecture. It is not yet known what
form this mechanism may take.
4.5 Where to Place a Policy Server
A Policy Server may co-exist with a Security Gateway, an end-host,
or may reside on a system by itself.
More text is needed here, explaining the tradeoffs and issues
involved with the different placements.
5. End-host Requirements
An end-host that complies with the IPSP architecture MUST be able
to initiate a Security Gateway discovery process (see Section 3).
If the end-host is expected to operate inside a Security Domain, it
MUST implement the client side of the Security Policy Server Query
Protocol (see Section 4.1). Implementation of the server side of
the SPSQ protocol is optional.
6. Legacy End-hosts
This section describes IPSP operation when either or both of the
end-hosts (origin and/or destination end-hosts) are not IPSP-aware.
6.1 Legacy Origin End-host
When an origin end-host operating inside a Security Domain does not
implement the Security Gateway Discovery Protocol, coordination
between Security Gateways and the end-host is not possible.
A Security Gateway that intercepts a packet from such a host MAY
initiate a Security Gateway discovery process, specifying that it
will be proxying traffic for the end-host. This will allow the
Security Gateway to establish IPsec tunnels with other Security
Gateways (and potentially the destination end-host itself) that
protects the origin end-host's traffic. The "reverse channel"
policy added to the discovery packet assumes that the destination
end-host implements SGDP (and can thus take advantage of this
information). If that is not true, a Security Gateway discovery
process will have to be initiated in the reverse direction by the
last Security Gateway (see section 6.2).
6.2 Legacy Destination End-host
When a destination end-host does not implement the SGDP, it is the
responsibility of the Policy Server of its Security Domain to
specify the end-to-end security parameters (if any). This means
that a Policy Server MUST be aware of which hosts it is responsible
for.
The Policy Server responsible for a legacy destination end-host MAY
initiate a Security Gateway discovery process in the reverse
direction if the origin end-host does not implement SGDP (i.e., the
discovery process was a proxy one). However, some mechanism needs
to be employed to avoid an endless loop of Security Gateway
discovery.
7. Legacy Security Gateways
Legacy Security Gateways do not participate in the discovery
process, since they do not implement the SGDP. Such a system, upon
receipt of a discovery packet may drop it (which will cause the
discovery process to time-out), forward it with no further
processing, or initiate an IPsec exchange with some remote host or
Security Gateway, based on its local (non-IPSP-conforming) security
policy. In the latter two cases, no further action is required by
any IPSP-compliant system, as the legacy Security Gateway is
transparent to the discovery process.
If the legacy Security Gateway drops the discovery packets and
sends back an appropriate ICMP message, the recipient of such a
message (another SG or the origin end-host) MAY establish the
necessary IPsec SAs with the legacy SG to allow traffic to flow
through the legacy SG. The legitimacy of the ICMP message MUST be
verified through cryptographic (or other) means.
Alternatively, the Security Gateway or origin end-host MUST
terminate the discovery process and notify the Policy Servers, SGs,
and origin end-host involved in the discovery process.
No solution as yet exists if the legacy Security Gateway silently
discards packets.
8. Security Considerations
This section has not been completed. It will be in future versions
of this draft.
9. IANA Considerations
A new transport protocol number for the SGDP needs to be assigned
by IANA. No further actions by IANA are required (yet).
References:
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC-2119, March 1997.
[RFC-2401] S. Kent, R. Atkinson, RFC2401: "Security Architecture
for the Internet Protocol", November 1998.
[IPSP-REQ] M. Richardson, A. Keromytis, L. Sanchez,
draft-ietf-ipsp-requirements-00.txt: "IPsec Policy
Discovery Protocol Requirements", October 1999
[RFC-2409] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. Authors' Address
[Photuris] Karn, P., and B. Simpson, Photuris: Session Key
Management Protocol, Work in Progress.
Authors' addresses:
Angelos D. Keromytis
Distributed Systems Lab
CIS Department, University of Pennsylvania
200 S. 33rd Street
Philadelphia, Pennsylvania 19104-6389
Telephone: +1 215 573 3639
Email: angelos@dsl.cis.upenn.edu
Michael C. Richardson
Sandelman Software Works Corp.
152 Rochester Street
Ottawa, ON K1R 7M4
Canada
Telephone: +1 613 276-6809
Email: mcr@sandelman.ottawa.on.ca
Luis A. Sanchez
BBN Technologies
GTE Internetworking
10 Moulton Street
Cambridge, MA 02140
USA
Telephone: +1 (617) 873-3351
Email: lsanchez@bbn.com
Expiration and File Name
This draft expires April 1, 2000
Its file name is draft-keromytis-ipsp-arch-00.txt