doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3586.txt b/doc/rfc/rfc3586.txt
new file mode 100644
index 0000000..d29280e
--- /dev/null
+++ b/doc/rfc/rfc3586.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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:
+
+      -  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
+
+
+      -  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.
+
+      -  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.
+
+      -  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.
+
+      -  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.
+
+      -  The semantics of IPSP must be well defined, particularly with
+         respect to any security-critical aspects of the system.
+
+      -  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:
+
+      -  A policy model with well-defined semantics that captures the
+         relationship between IPsec SAs and higher-level security
+         policies,
+
+      -  A gateway discovery mechanism that allows hosts to discover
+         where to direct IPsec traffic intended for a specific endpoint,
+
+      -  A well-specified language for describing host policies,
+
+      -  A means for distributing responsibility for different aspects
+         of policy to different entities,
+
+      -  A mechanism for discovering the policy of a host,
+
+      -  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,
+
+      -  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]
+