From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3586.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc3586.txt (limited to 'doc/rfc/rfc3586.txt') 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] + -- cgit v1.2.3