[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IPSP Working Group             M. Richardson, Sandelman Software Works
Internet Draft                        A. Keromytis, U. of Pennsylvania
draft-richardson-ipsp-requirements-00.txt               L. Sanchez, BBN/GTEI
Expires April, 2000

            IPsec Policy Discovery Protocol requirements

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.

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).

Abstract

This document describes the problem and solution requirements for
an IPsec Policy Discovery protocol.

1.0 Introduction

1.1 Definition of terminology

Network security technologies are quickly being deployed over the
Internet these days; in particular, two categories enjoy widespread
usage:

a) security enforcement agents
   Security gateways (commonly known as firewalls) are being installed
   along the perimeter of private internets to enforce access control
   and protect confidentiality of network traffic; these upper-layer
   gateways along with traditional link encryptors make up a scattered
   and uncoordinated set of security enforcement agents attempting to
   protect the Internet traffic.

b) secure communication protocols
   Cryptographic algorithms are being incorporated into secure
   communication protocols such as IPSec, SSL and SOCKS in order to
   support strong data integrity, authentication, and confidentiality
   services.

On one hand, these technologies provide the much needed security
protection over the open Internet; on the other hand, they create a
complex management task that beg for scalable solutions.

The deployment of security gateways divides the Internet into
heterogeneous regions upholding different security policies, and the use
of different cryptographic mechanisms at multiple protocol layers
creates the need for negotiating the security mechanism and the key
parameters. As a result, in order to support a secure communication-
between two or more end-points, all the end-points and the security
enforcement agents on the communication's route must work together to
determine the suite of security services that can satisfy the security
policies, and negotiate a common set of security mechanisms to implement
these security services. While the negotiation of security mechanisms
and key parameters may be supported by key management protocols such as
ISAKMP [RFC-2408], a general and efficient process for managing the
security policies and deducing the security services for this
multi-party multi-layer security enforcement strategy is still
unavailable.

A IPsec Policy Discovery Protocol (IPDP) must provide the
essential infrastructure and the protocols necessary for conducting
this process. An IPDP must provide
IPSec with the scalability and management needed to become fully
deployable in operational environments.

1.2 Problem Description

The security management problem can be restated in the form of the
following four questions:

a) How does one manage the process of creating and modifying security
policies so as to maintain their mutual consistency?

b) How does one deduce the security requirements of an inter-domain
communication based on the security policies of network domains?

c) How to select the choices of security services and enforcement
agents in order to satisfy the security requirements?

d) How to orchestrate the negotiation of security mechanisms and
cryptographic parameters in order to provide seamless support of
security services?

The security management and scalability problems found in IPSec are
captured in the following example:

In order to pass IP datagrams through several layers of IPSec-based
firewalls, both the source and the destination of the datagrams must
establish security associations with all or some of these firewalls
encountered en-route.

However, neither the source nor the destination may know of the
existence of all intermediate firewalls a priori, due to either their
lack of knowledge about the network topology or the dynamics of the
routing algorithms.

Consequently, negotiations must be conducted in sequence, on a
trial-and-error basis. For instance, the source may become aware of the
presence of a firewall if it receives ICMP messages from the firewall as
it discards the packets for which it doesn't have a security
association.

The source must then negotiate a security association with the firewall,
use session keys to authenticate and/or encrypt the packets and
retransmit them to the firewall.

This process could be repeated until no more ICMP messages are received
from any firewall and the source is certain that the packets have
successfully arrived at their destination.

This clumsy process can be further complicated by the fact that many
firewalls may drop the packets without sending back any ICMP
messages. Also, long-term security associations may have been arranged
between some of the firewalls if technologies such as virtual private
networks (VPNs) are used in part of the Internet. As a result, the tasks
of finding existing security associations while negotiating for
necessary new ones can be difficult, time consuming, and probably
impossible to complete.

1.3 Basic Terminology

Security Gateway
        A security gateway refers to an intermediate system that
        implements IPSec protocols. For example, a router or a
        firewall implementing IPSec is a security gateway.

Security Domain
        A set of communicating entities and resources that share a
        common security policy enforced at a security gateway or
        host. The definition of security domain applies to networks
        protected by security gateways as well as to single
        hosts since a host could be the enforcer of its own
        policies. Security domains could exist inside other security
        domains.

Security Association
        A simplex "connection" that affords security services to the
        traffic carried by it.  Two types of securiy associations
        (SAs) are defined: transport mode and mode.  A transport
        mode SA is a security association between two hosts.  A
        tunnel mode SA is essentially an SA applied to an IP tunnel.
        Whenever either end of a security association is a security
        gateway, the SA MUST be tunnel mode.

Security Association Bundle
        A group of security associations that are used for
        communications that share a common endpoint.  For example,
        all the SAs that a particular host needs to use to
        communicate with another host, including any SAs that host
        itself needs with intermediate gateways.

2.0 IPDP feature requirements

A IPsec Policy Discovery Protocol must be a distributed system
which provides hosts and security gateways with the policy information
required to establish a secure communication end-to-end. The goal of
a policy discovery protocol is to provide the following services to
hosts and security gateways:

1. Discovery of security gateways
2. Management of dynamic security associations.
3. Resolution of security requirements for inter-domain communication
4. Consistency checking of local security policies.

As part of this, a Policy Discovery Protocol should provide a language
that allows one to specify security policies in terms of primitives such
as user identity or role, source and destination machine address and
port number, encryption and authentication algorithms.

A host should be able to discover any remote security gateways relevant
in an end-to-end communication.  The host must be able to validate the
identities of (local and remote) security policy agents and security
gateways. It must be able to verify that the gateways in question are
entitled to represent a destination host.

A related service required by the IPsec Policy Discovery Protocol is a
mechanism to express security policies and to populate a security server
with the policies for a given security domain. The mechanism should
follow an object-oriented approach, where one can declare various
configuration objects within a security domain as part of an overall
hierarchy supporting inheritance.

Attributes of the objects should be mandatory or optional. A mandatory
attribute has to be defined for all objects of the class; optional
attributes can be skipped. Attributes can also be single or multiple
valued.

2.1 IPDP architecture requirements

The architectural requirements of the IPsec Policy Discovery Protocol
are as follows:

2.1.1 Discover Gateways

        IPDP must be able to determine a set of necessary security
        gateways through which a message must travel to complete a
        communication on a single path between two hosts.

2.1.2 Verify Identities

        IPDP must allow hosts to verify the identities of gateways
        and other hosts with which they are communicating.  It must
        also be able to verify that a gateway that claims to represent
        a particular host actually does have the authority to represent
        that host.

2.1.3 Manage Bundles of Security Associations

        IPDP must be able to effectively manage bundles of security
        associations.  It must be able to create bundles from policy
        information, determine if existing security associations or
        bundles may be used when creating new bundles, create new
        security associations as needed for new bundles, and keep
        security associations in existing bundles up-to-date.

2.1.4 Require no changes to security protocols

        IPDP must not require changes, additions or modifications to the
        algorithms or protocols of the security protocols that use it.

2.1.5 Key Management Protocol Independence

        IPDP must be independent of any particular key management
        protocol.

2.1.6 No Exterior Infrastructure Dependency

        IPDP must not depend upon an exterior infrastructure, although
        implementations may use an exterior infrastructure. For example,
        public keys may be distributed using the existing DNS
        infrastructure.  IPDP must not prohibit other means for
        distributing keys.  Particular implementations may, however,
        rely on the DNS for key distribution, though they may not be as
        robust as implementations that provide several key distribution
        mechanisms.

        It is necessary, however, that the routing infrastructure be in
        place so IPDP servers may be contacted.  This is not a difficult
        requirement, since that infrastructure must be in place to send
        the communications that require the use of IPDP.

References:

[RFC-2401] S. Kent, R. Atkinson, RFC2401: "Security Architecture for the
           Internet Protocol", November 1998.

[RFC-2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, RFC2408:
           "Internet Security Association and Key Management Protocol
           (ISAKMP)", November 1998.


Author's Address

   Michael C. Richardson                      Luis A. Sanchez
   Sandelman Software Works Corp.             BBN Technologies
   152 Rochester Street                       GTE Internetworking
   Ottawa, ON K1R 7M4                         10 Moulton Street
   Canada                                     Cambridge, MA  02140
                                              USA
   Telephone:   +1 613 276-6809               Telephone: +1 (617) 873-3351
   EMail:       mcr@sandelman.ottawa.on.ca    Email: lsanchez@bbn.com


   Angelos D. Keromytis
   Distributed Systems Lab
   CIS Department, University of Pennsylvania
   200 S. 33rd Street
   Philadelphia, Pennsylvania  19104-6389

   EMail: angelos@dsl.cis.upenn.edu


Expiration and File Name

   This draft expires April 1, 2000

   Its file name is draft-ietf-ipsp-requirements-00.txt


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/