GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3586

Network Working Group M. Blaze Request for Comments: 3586 AT&T Labs - Research Category: Standards Track A. Keromytis

                                                   Columbia University
                                                         M. Richardson
                                              Sandelman Software Works
                                                            L. Sanchez
                                                   Xapiens Corporation
                                                           August 2003
               IP Security Policy (IPSP) Requirements

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 This document describes the problem space and solution requirements
 for developing an IP Security Policy (IPSP) configuration and
 management framework.  The IPSP architecture provides a scalable,
 decentralized framework for managing, discovering and negotiating the
 host and network security policies that govern access, authorization,
 authentication, confidentiality, data integrity, and other IP
 Security properties.  This document highlights such architectural
 components and presents their functional requirements.

Table of Contents

 1.  Introduction..................................................  2
     1.1.  Terminology.............................................  2
     1.2.  Security Policy and IPsec...............................  2
 2.  The IP Security Policy Problem Space..........................  3
 3.  Requirements for an IP Security Policy Configuration and
     Management Framework..........................................  5
     3.1.  General Requirements....................................  5
     3.2.  Description and Justification...........................  5
           3.2.1.  Policy Model....................................  5
           3.2.2.  Security Gateway Discovery......................  6

Blaze, et al. Standards Track [Page 1] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

           3.2.3.  Policy Specification Language...................  6
           3.2.4.  Distributed policy..............................  6
           3.2.5.  Policy Discovery................................  6
           3.2.6.  Security Association Resolution.................  6
           3.2.7.  Compliance Checking.............................  7
 4.  Security Considerations.......................................  7
 5.  IANA Considerations...........................................  7
 6.  Intellectual Property Statement...............................  7
 7.  References....................................................  8
     7.1.  Normative References....................................  8
     7.2.  Informative References..................................  8
 8.  Disclaimer....................................................  8
 9.  Acknowledgements..............................................  8
 10. Authors' Addresses............................................  9
 11. Full Copyright Statement...................................... 10

1. Introduction

1.1. Terminology

 The keywords "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.2. Security Policy and IPsec

 Network-layer security now enjoys broad popularity as a tool for
 protecting Internet traffic and resources.  Security at the network
 layer can be used as a tool for at least two kinds of security
 architecture:
 a) Security gateways.  Security gateways (including "firewalls") at
    the edges of networks use IPsec [RFC-2401] to enforce access
    control, protect the confidentiality and authenticity of network
    traffic entering and leaving a network, and to provide gateway
    services for virtual private networks (VPNs).
 b) Secure end-to-end communication.  Hosts use IPsec to implement
    host-level access control, to protect the confidentiality and
    authenticity of network traffic exchanged with the peer hosts with
    which they communicate, and to join virtual private networks.
 On one hand, IPsec provides an excellent basis for a very wide range
 of protection schemes; on the other hand, this wide range of
 applications for IPsec creates complex management tasks that become
 especially difficult as networks scale up and require different
 security policies, and are controlled by different entities, for
 different kinds of traffic in different parts of the network.

Blaze, et al. Standards Track [Page 2] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

 As organizations deploy security gateways, the Internet divides into
 heterogeneous regions that enforce different access and security
 policies.  Yet it is often still necessary for hosts to communicate
 across the network boundaries controlled by several different
 policies.  The wide range of choices of cryptographic parameters (at
 multiple protocol layers) complicates matters and introduces the need
 for hosts and security gateways to identify and negotiate a set of
 security parameters that meets each party's requirements.  Even more
 complexity arises as IPsec becomes the means through which firewalls
 enforce access control and VPN membership; two IPsec endpoints that
 want to establish a security association must identify, not only the
 mutually acceptable cryptographic parameters, but also exactly what
 kind of access the combined security policy provides.
 While the negotiation of cryptographic and other security parameters
 for IPsec security associations (SAs) is supported by key management
 protocols (e.g., ISAKMP [RFC-2408]), the IPsec key management layer
 does not provide a scheme for managing, negotiating, or enforcing the
 security policies under which SAs operate.
 IPSP provides the framework for managing IPsec security policy,
 negotiating security association (SA) parameters between IPsec
 endpoints, and distributing authorization and policy information
 among hosts that require the ability to communicate via IPsec.

2. The IP Security Policy Problem Space

 IPSP aims to provide a scalable, decentralized framework for
 managing, discovering and negotiating the host and network IPsec
 policies that govern access, authorization, cryptographic mechanisms,
 confidentiality, data integrity, and other IPsec properties.
 The central problem solved by IPSP is that of controlling security
 policy in a manner that is useful for the wide range of IPsec
 applications and modes of operation.  In particular:
  1. IPSP hosts may serve as IPsec endpoints, security gateways,

network management hubs, or a combination of these functions.

       IPSP will manage end-users computers (which may be fixed
       workstations controlled by a single organization or mobile
       laptops that require remote access to a corporate VPN),
       firewalls (which provide different services and allow different
       levels of access to different classes of traffic and users),
       VPN routers (which support links to other VPNs that might be
       controlled by a different organization's network policy), web
       and other servers (which might provide different services
       depending on where a client request came from), and so on.

Blaze, et al. Standards Track [Page 3] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

  1. IPSP administration will be inherently heterogeneous and

decentralized. A basic feature of IPsec is that two hosts can

       establish a Security Association even though they might not
       share a common security policy, or, indeed, trust one another
       at all.  This property of IPsec becomes even more pronounced at
       the higher level abstraction managed by IPSP.
  1. The SA parameters acceptable to any pair of hosts (operating

under different policies) will often not be specified in

       advance.  IPSP will often have to negotiate and discover the
       mutually-acceptable SA parameters on-the-fly when two hosts
       attempt to create a new SA.
  1. Some hosts will be governed by policies that are not directly

specified in the IPSP language. For example, a host's IPsec

       policy might be derived from a more comprehensive higher-layer
       security policy managed by some other system.  Similarly, some
       vendors might develop specialized (and proprietary) tools for
       managing policy in their products.  In such cases, it is
       necessary to derive an IPSP policy specification for only those
       aspects of a host's policy that involve interoperability with
       other hosts running IPSP.
  1. IPSP must scale to support complex policy administration

schemes. In even modest-size networks, one administrator must

       often control policy remotely, and must have the ability to
       change the policy on many different hosts at the same time.  In
       larger networks (or those belonging to large organizations), a
       host's policy might be governed by several different
       authorities (e.g., several different departments might have the
       authority to add users to a firewall or open access to new
       services).  Different parts of a policy might be "owned" by
       different entities in a complex hierarchy.  IPSP must provide a
       mechanism for delegating specific kinds of authority to
       specific entities.
  1. The semantics of IPSP must be well defined, particularly with

respect to any security-critical aspects of the system.

  1. IPSP must be secure, sound, and comprehensible. It should be

possible to understand what an IPSP policy does; the difficulty

       of understanding an IPSP policy should be somewhat proportional
       to the complexity of the problem it solves.  It should also be
       possible to have confidence that an IPSP policy does what it
       claims, and that IPSP implementation is correct;
       architecturally, the security-critical parts of IPSP should be
       small and well-specified enough to allow verification of their
       correct operation.  Ideally, IPSP should be compatible with

Blaze, et al. Standards Track [Page 4] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

       formal methods, such as implementing security policies with
       provable properties.

3. Requirements for an IP Security Policy Configuration and

  Management Framework

3.1. General Requirements

 An IPSP solution MUST include:
  1. A policy model with well-defined semantics that captures the

relationship between IPsec SAs and higher-level security

       policies,
  1. A gateway discovery mechanism that allows hosts to discover

where to direct IPsec traffic intended for a specific endpoint,

  1. A well-specified language for describing host policies,
  1. A means for distributing responsibility for different aspects

of policy to different entities,

  1. A mechanism for discovering the policy of a host,
  1. A mechanism for resolving the specific IPsec parameters to be

used between two hosts governed by different policies (and for

       determining whether any such parameters exist); and,
  1. A well-specified mechanism for checking for compliance with a

host's policy when SAs are created.

 The mechanisms used in IPSP must not require any protocol
 modifications in any of the IPsec standards (ESP [RFC-2406], AH,
 [RFC-2402], IKE [RFC-2409]).  The mechanisms must be independent of
 the SA-negotiation protocol, but may assume certain functionality
 from such a protocol (this is to ensure that future SA-negotiation
 protocols are not incompatible with IPSP).

3.2. Description and Justification

3.2.1. Policy Model

 A Policy Model defines the semantics of IPsec policy.  Policy
 specification, checking, and resolution should implement the
 semantics defined in the model.  However, the model should be
 independent of the specific policy distribution mechanism and policy
 discovery scheme, to the extent possible.

Blaze, et al. Standards Track [Page 5] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

3.2.2. Security Gateway Discovery

 The gateway discovery mechanism may be invoked by any host or
 gateway.  Its goal is to determine what IPsec gateways exist between
 the initiator and the intended communication peer.  The actual
 mechanism employed may be used to piggy-back information necessary by
 other components of the IPSP architecture (e.g., policy discovery, as
 is done in [SPP]).  The discovery mechanism may have to be invoked at
 any time, independently of existing security associations or other
 communication, to detect topology changes.

3.2.3. Policy Specification Language

 In order to allow for policy discovery, compliance checking, and
 resolution across a range of hosts, a common language is necessary in
 which to express the policies of hosts that need to communicate with
 one another.  Statements in this language are the output of policy
 discovery, and provide the input to the policy resolution and
 compliance checking systems.  Note that a host's or network's
 security policy may be expressed in a vendor-specific way, but would
 be translated to the common language when it is to be managed by the
 IPSP services.

3.2.4. Distributed policy

 As discussed above, it must be possible for all or part of a host's
 policy to be managed remotely, possibly by more than one entity.
 This is a basic requirement for large-scale networks and systems.

3.2.5. Policy Discovery

 A policy discovery mechanism must provide the essential information
 that two IPsec endpoints can use to determine what kinds of SAs are
 possible between one another.  This is especially important for hosts
 that are not controlled by the same entity, and that might not
 initially share any common information about one another.  Note that
 a host need not reveal its entire security policy, only enough
 information to support the SA resolution system for hosts that might
 want to communicate with it.

3.2.6. Security Association Resolution

 Once two hosts have learned enough about each other's policies, it
 must be possible (and computationally feasible) to find an acceptable
 set of SA parameters that meets both host's requirements and will
 lead to the successful creation of a new SA.

Blaze, et al. Standards Track [Page 6] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

3.2.7. Compliance Checking

 When a host proposes the output of the SA resolution scheme, it must
 be checked for compliance with the local security policy of each
 host.  The security and soundness of the SAs created by IPSP-managed
 communication should depend only on the correctness of the compliance
 checking stage.  In particular, even if the SA resolution scheme
 (which is likely to be computationally and conceptually complex)
 produces an incorrect result, it should still not be possible to
 violate the specified policy of either host.

4. Security Considerations

 This document discusses the high-level requirements for a policy
 framework and architecture for IPsec.  A justification for the
 various components is given.

5. IANA Considerations

 No action is required by IANA.

6. Intellectual Property Statement

 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.
 Copies of claims of rights made available for publication and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

Blaze, et al. Standards Track [Page 7] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

7. References

7.1. Normative References

 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Level", BCP 14, RFC 2119, March 1997.
 [RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the
            Internet Protocol", RFC 2401, November 1998.

7.2. Informative References

 [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
            2402, November 1998.
 [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
            Payload (ESP)", RFC 2406, November 1998.
 [RFC-2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner,
            "Internet Security Association and Key Management Protocol
            (ISAKMP)", RFC 2408, November 1998.
 [RFC-2409] Harkins, D and D. Carrel, "The Internet Key Exchange
            (IKE)", RFC 2409, November 1998.
 [SPP]      Sanchez, L. and M. Condell, "The Security Policy
            Protocol", Work in Progress.

8. Disclaimer

 The views and specification here are those of the authors and are not
 necessarily those of their employers.  The authors and their
 employers specifically disclaim responsibility for any problems
 arising from correct or incorrect implementation or use of this
 specification.

9. Acknowledgements

 The authors thank the members of the IPsec Policy working group that
 contributed to this document.

Blaze, et al. Standards Track [Page 8] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

10. Authors' Addresses

 Matt Blaze
 AT&T Labs - Research
 180 Park Avenue
 Florham Park, NJ 07932  USA
 EMail: mab@crypto.com
 Angelos D. Keromytis
 Computer Science Department
 Columbia University
 1214 Amsterdam Avenue, M.C. 0401
 New York, NY 10027, USA
 EMail: angelos@cs.columbia.edu
 Michael C. Richardson
 Sandelman Software Works Corp.
 470 Dawson Avenue
 Ottawa, ON K1Z 5V7   Canada
 Phone: +1 613 276-6809
 EMail: mcr@sandelman.ottawa.on.ca
 Luis A. Sanchez
 Xapiens Corporation
 PO Box 9023694
 San Juan, PR  00902  USA
 Phone: +1 (787) 832-4717
 EMail: lsanchez@xapiens.com

Blaze, et al. Standards Track [Page 9] RFC 3586 IP Security Policy (IPSP) Requirements August 2003

11. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assignees.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Blaze, et al. Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3586.txt · Last modified: 2003/08/26 16:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki