[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-keromytis-ipsp-arch) 00

IPSP Working Group                                              M. Blaze
Internet Draft                                      AT&T Labs - Research
draft-ietf-ipsp-arch-00.txt                                A.  Keromytis
                                                      U. of Pennsylvania
                                                           M. Richardson
                                                Sandelman Software Works
                                                              L. Sanchez
                                                                BBN/GTEI
                                                               July 2000


                         IPsec Policy 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


         --------   -----               -----   --------
         |Host A|---|SG1|----- ... -----|SG2|---|Host B|
         --------   -----               -----   --------


   Consider the simple scenario represented by the figure above: Host
   A wishes to communicate with Host B; A only knows B's network
   identifier (address) and what security requirements for such a
   communication itself requires (e.g., A wants to use strong
   encryption when talking to B).  Both hosts are connected to a wide
   area network through their security gateways (SG1 and SG2
   respectively).  Hosts A and B may know about their local security
   gateways, because of local configuration; they do not know about
   the other's security gateway however (or any possible intervening
   security gateways).  In some cases, they may not even know about
   their local security gateways (e.g., in the case of a large
   private network with outside links through a number of firewalls).
   The security gateways may impose certain restrictions on the
   traffic they see (e.g., only encrypted traffic is allowed to
   go between A and B).

   In such a scenario, Host A needs to determine:

   - What its local policy with regards to end-to-end communication
     with Host B is.  This decision may be deferred to the network
     administrator, as a matter of corporate policy.

   - What B's policy with regards to the same end-to-end communication
     is; if there is an intersection of the two policies, it has to
     be determined, and the appropriate IPsec SAs have to be
     negotiated and established.

   - What security gateways (if any) are in the path between A and B,
     and what their policies with respect to that communication is.
     For example, SG1 may allow any kind of traffic between A and B,
     whereas SG2 may require that any such traffic also be encrypted
     to itself.  Or, SG1 may require that traffic to Host B only be
     authenticated but not encrypted end-to-end (e.g., certain
     financial institutions impose such requirements on traffic as
     a result of legislative controls), but that such traffic may be
     encrypted from Host A to SG1 and then from SG1 to Host B again.
     Naturally, Host A needs to ensure that SG1 actually has the
     authority to make such statements.  Depending on the individual
     policies involved, any combination of these SAs may have to
     be established by Host A:

     - SA between Host A and Host B
     - SA between Host A and SG1
     - SA between Host A and SG2
     - SA between SG1 and SG2
     - SA between SG1 and Host B
     - SA between SG2 and Host B

   - The same requirement with regards to communication security
     policy holds in the opposite direction as well (from Host B to
     Host A), since most traffic is in fact bidirectional.  Note
     however that different requirements may exist for the two
     directions.

   - If either of the Security Gateways decides to establish an SA
     between itself and the end-host (or some other SG), it may have
     to recursively invoke the discovery protocol.

   The scenario may be further complicated by the fact that Host A,
   Host B, SG1, and SG2 may all lie in different administrative
   domains with correspondingly different security policies.

   Manual configuration of policies and gateways is difficult even in
   the simple scenario described in this section.  An architecture for
   automated gateway and policy discovery and resolution is
   necessary.  Automatic keying may then be used to establish the
   necessary SAs, e.g., IKE [RFC-2409] or Photuris [Photuris].

   Note that even in the trivial case of two hosts without an
   intervening security gateway, the IPSP architecture allows the two
   peers to determine what is necessary to establish a secure
   communication channel (e.g., what authorities or CAs they both
   trust).

   Furthermore, note that there are multiple aspects of the overall
   security policy that applies to a particular communications that
   has to be made available in different parts of an IPsec
   implementation; packet selectors have to be specified in the SPD of
   a security gateway (or end-host), whereas SA parameters have to be
   provided to the key management system (and ultimately in the
   SADB).

   Two more caveats:

   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.

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


2.  Architecture Overview

   The basic premises of the IPSP architecture are:

   - Use of the SPP protocol [SPP] for gateway discovery and security
     policy distribution.

   - Use of a trust management system and language [RFC-2704] to
     resolve and exchange policies respectively.  Section 4 gives more
     details.

   - Most of the burden of discovering and processing policy is placed
     on the initiator of a communications.  Thus, expensive operations
     such as policy resolution is (optionally) performed by the
     initiator of a communications; security gateways need only
     perform compliance checking, which is computationally cheaper.
     Policy Servers MAY optionally perform policy resolution, to
     improve caching and accelerate communication establishment.

   - IPsec policy is defined in terms of local policy (describing what
     requirements the host has for a particular communications) and
     signed policy statements from trusted entities.  What entities
     (and to what extent) are trusted is a matter of local policy;
     signed policy statements are acquired through the SPP protocol.
     These statements may be used by an IPSP-compliant system in two
     ways:

     - To determine what traffic is allowed through a security gateway
       or accepted by the remote host.

     - To convince a security gateway or remote host to allow traffic
       through.

     Local policy is expressed in a vendor-specific way.  It MUST
     however be converted to a KeyNote local policy for processing by
     IPSP.  The Policy Model [TDB] describes the semantics of the
     conversion.

     (A "KeyNote local policy" is a policy statement that is
      unconditionally trusted by the host.  Such statements MUST be
      securely stored and protected from tampering.  In their simplest
      form, local policies reduce to a list of trusted keys or CAs.)


3.  Use of SPP in IPSP

   SPP is a security gateway and policy discovery protocol.  It allows
   a host to determine what security gateways lie in the path to a
   specific destination, and what their security policies are.  SPP
   may also be used to distribute certificates (or, more generally,
   credentials).  Note that since trust management credentials are
   signed, it may not be necessary to sign the entire SPP payload when
   exchanging policies (to be resolved before next version).

   For more details on SPP, see [SPP].


4.  Compliance Checking and IPSP

   Policies exchanged in SPP are encoded in KeyNote [RFC-2704]
   credentials.  These are signed statements that describe the
   acceptable combinations of IPsec selectors (source/destination
   address and masks, transport protocol and ports, etc.) and SA
   parameters (encryption/authentication algorithms, key lengths,
   etc.)

   A host's local policy specifies what public keys are trusted to
   make such statements; if KeyNote is used to specify local policy,
   further restrictions on what these keys are allowed to mandate can
   be expressed.  Other languages (or methods) may be used to express
   local security policy as well; however, these policies MUST be
   translated to KeyNote local policies for processing by the trust
   management system.  A separate document will describe the names and
   semantics of the various action attributes used in the KeyNote
   credentials used in IPsec, based on the IPsec policy model
   described in [TBD].

   Policy servers in SPP store credentials (signed policy statements)
   created by the local network security administrator, as well as
   cached credentials acquired by querying other SPP servers.  These
   credentials are then provided to the security gateway that
   forwarded the SPP query, and to the host that initiated the SPP
   protocol.  The credentials may then be used in the key management
   protocol to authorize the host to establish SAs, if necessary, as
   described in [IPSP-TRUST].  In particular, the end-host may:

   - Analyze the provided credentials to determine what, if any, SAs
     must be negotiated with a particular security gateway or end host
     (policy resolution).  The algorithm for doing so is described in
     a separate document [TBD].

   - Simply use the trust management engine to determine which of its
     local policies with regards to a particular communications is
     acceptable by the security gateway or remote host.  For this, the
     end-host emulates the compliance checking process that the
     security gateway or remote host will perform when negotiating
     SAs.

   - The end-host may simply use the acquired credentials in the key
     management protocol.  If the necessary SAs are established, the
     end-host may commence communications (or proceed with the policy
     discovery); otherwise, an error is reported, or one of the
     previous two approaches used.

   The use of KeyNote credentials inside a key management protocol is
   described in [IPSP-TRUST].

   Security gateways download policies from their configured Policy
   Servers, to initialize their SPD tables.

   Note that while KeyNote credentials may also provide authentication
   information to be used by a key management protocol, other
   authentication mechanisms (e.g., PKIX certificates) can be used for
   this purpose as well.

   Policy decorrelation is necessary to ensure that no conflicting
   policies exist.  This process is desribed in [SPP] and is directly
   applicable to policies expressed in terms of KeyNote credentials.

   Trust relations between different domains may also be described in
   terms of KeyNote credentials.  A separate document will describe
   the operational implications of this.  In particular, the
   implications of delegation across domains and policy decorrelation
   needs to be carefully examined and documented.


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

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

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


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


7.  Security Considerations

   This section has not been completed.  It will be, in future versions
   of this draft.


8.  IANA Considerations

   No actions by IANA are required (yet).


9.  ToDo List

   - Describe semantics and operational requirements for inter-domain
     policies (delegation).

   - Decorrelation in the context of delegation.

   - Describe the resolution algorithm in detail (very similar to the
     one described in SPP).

   - Determine whether all SPP messages must be protected, given that
     policies themselves are/may be signed.

   - Describe SPD initialization by gateways (and end-hosts ?)

   - Policy Server -- how does a host find out which one is the local
     one ? DHCP, manual configuration, LDAP, Service Discovery
     protocol, dedicated multicast address, other ?

   - Mobile hosts and PS determination (same as above, more issues).

   - Flesh out missing documents (find volunteers).

   - Import policy model discussion.

   - More verbose description of SPP ? Is reference sufficient ?

   - Diagram with all possible SAs/tunnels in the example in
     Introduction.


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]    Blaze, M., Keromytis, A., Richardson, M., and 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.

   [Photuris]    Karn, P., and B. Simpson, Photuris: Session Key
                 Management Protocol, Work in Progress.

   [IPSP-TRUST]  Blaze, M., Ioannidis, J., and A. Keromytis,
                 draft-blaze-ipsp-trustmgt-00.txt: "Compliance
                 Checking and IPSEC Policy Management", March 2000.

   [RFC-2704]    Blaze, M., Feigenbaum, J., Ioannidis, J. and
                 A. Keromytis, "The KeyNote Trust-Management System
                 Version 2", RFC 2704, September 1999.

Authors' addresses:

   Matt Blaze
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0971

   Email:       mab@research.att.com

   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 February 1, 2001

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


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