RFC 3586

IP Security Policy (IPSP) Requirements

📅 published August 2003, from ietf

IP Security Policy (IPSP) Requirements 🎀

Okay bestie, here are the deets 💅 This is RFC 3586, a Standards Track doc from the Network Working Group, dated August 2003. It was written by M. Blaze (AT&T Labs - Research), A. Keromytis (Columbia University), M. Richardson (Sandelman Software Works), and L. Sanchez (Xapiens Corporation) 👑 The title block doesn't list anything it obsoletes or updates, so no drama there ✨

Status of this Memo

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

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

Abstract

This doc is all about the problem space and the solution requirements for building an IP Security Policy (IPSP) configuration and management framework 🧚 IPSP gives you a scalable, decentralized way to manage, discover, and negotiate the host and network security policies that cover access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. It breaks down those architectural pieces and lays out what each one needs to do functionally 🫶

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

Here's the key word list 🔑 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 is hugely popular now as a way to protect Internet traffic and resources 🛡️ It can work 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 provide gateway services for virtual private networks (VPNs) 🚪
  • b) Secure end-to-end communication. Hosts use IPsec to implement host-level access control, protect the confidentiality and authenticity of network traffic exchanged with the peer hosts they talk to, and join virtual private networks 🔐

IPsec is honestly an amazing base for a very wide range of protection schemes 😭 But that same huge range of uses makes management really complex, especially as networks scale up and need different security policies, controlled by different entities, for different kinds of traffic in different parts of the network 🌸

As organizations deploy security gateways, the Internet splits into heterogeneous regions that enforce different access and security policies 🧩 Hosts still often need to communicate across network boundaries controlled by several different policies, though. The huge range of cryptographic parameter choices (at multiple protocol layers) makes things messy, and it means hosts and security gateways have to identify and negotiate a set of security parameters that meets each party's requirements 💖 It gets even more complicated once IPsec becomes the way firewalls enforce access control and VPN membership. Two IPsec endpoints that want to establish a security association have to identify not only the mutually acceptable cryptographic parameters, but also exactly what kind of access the combined security policy gives them 👑

Key management protocols such as ISAKMP [RFC-2408] support negotiating the cryptographic and other security parameters for IPsec security associations (SAs) 🗝️ But the IPsec key management layer doesn't offer a scheme for managing, negotiating, or enforcing the security policies that SAs operate under 😬

IPSP is the framework that fills that gap. It manages IPsec security policy, negotiates security association (SA) parameters between IPsec endpoints, and distributes authorization and policy information among hosts that need to communicate via IPsec 🎀

2. The IP Security Policy Problem Space

IPSP aims to give you a scalable, decentralized framework for managing, discovering, and negotiating the host and network IPsec policies that cover access, authorization, cryptographic mechanisms, confidentiality, data integrity, and other IPsec properties 🧚

The big problem IPSP solves is controlling security policy in a way that's actually useful across the wide range of IPsec applications and modes of operation. Here's what that looks like:

  • IPSP hosts can be IPsec endpoints, security gateways, network management hubs, or a combo of these functions 🌈 IPSP will manage end-user computers (fixed workstations controlled by one organization, or mobile laptops that need remote access to a corporate VPN), firewalls (which offer different services and give different classes of traffic and users different levels of access), 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 offer different services depending on where a client request came from), and so on 💻
  • IPSP administration is inherently heterogeneous and decentralized 🫧 A basic feature of IPsec is that two hosts can set up a Security Association even if they don't share a common security policy, or even trust each other at all. That property becomes even more pronounced at the higher level of abstraction IPSP manages ✨
  • The SA parameters acceptable to any pair of hosts (operating under different policies) often won't be specified in advance 🎲 IPSP will often have to negotiate and discover mutually acceptable SA parameters on-the-fly when two hosts try to create a new SA 🏃‍♀️
  • Some hosts are governed by policies that aren't directly specified in the IPSP language 🙈 For example, a host's IPsec policy might be derived from a bigger higher-layer security policy managed by some other system. Vendors might also build specialized (and proprietary) tools for managing policy in their products. In those cases, you need to derive an IPSP policy specification for only the parts of a host's policy that involve interoperating with other hosts running IPSP 🍓
  • IPSP has to scale to support complex policy administration schemes 📈 Even in modest-size networks, one administrator often has to control policy remotely, and must be able to change the policy on many different hosts at the same time 😤 In larger networks (or ones belonging to large organizations), a host's policy might be governed by several different authorities. For instance, 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, especially for 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, and the difficulty of understanding a 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 the 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 formal methods, like implementing security policies with provable properties 🔐⭐

3. Requirements for an IP Security Policy Configuration and Management Framework ✨

3.1. General Requirements ✨

okay so an IPSP solution MUST include all of these, no skipping bestie 💅

  • A policy model with well-defined semantics that captures the relationship between IPsec SAs and higher-level security policies 🧠
  • A gateway discovery mechanism that lets hosts figure out where to send IPsec traffic meant for a specific endpoint 🗺️
  • A well-specified language for describing host policies 📝
  • A way to split up responsibility for different parts of policy between different entities 🤝
  • A mechanism for discovering a host's policy 🔍
  • A mechanism for resolving the specific IPsec parameters two hosts under different policies should use (and for checking whether any such parameters even exist) 🧩
  • A well-specified mechanism for checking compliance with a host's policy when SAs get created ✅

the IPSP mechanisms must not require any protocol modifications to the IPsec standards, which are ESP [RFC-2406], AH [RFC-2402], and IKE [RFC-2409] 🙅‍♀️ they also have to stay independent of the SA-negotiation protocol, though they can assume some functionality from it. this is so future SA-negotiation protocols don't end up 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 what the model defines. ngl the model should stay independent of the specific policy distribution mechanism and policy discovery scheme, as much as it can 💖

3.2.2. Security Gateway Discovery 🗺️

the gateway discovery mechanism may be invoked by any host or gateway. its goal is to figure out which IPsec gateways exist between the initiator and the intended communication peer 🫶 the actual mechanism can also carry along info other parts of the IPSP architecture need, like policy discovery (the way [SPP] does it). and the discovery mechanism may have to run at any time, separate from existing security associations or other communication, so it can catch topology changes 🌈

3.2.3. Policy Specification Language 📝

so to do policy discovery, compliance checking, and resolution across a bunch of different hosts, you need a common language for expressing the policies of hosts that want to talk to each other 💜 statements in this language come out of policy discovery and feed into the resolution and compliance checking systems. a host's or network's security policy can be written in a vendor-specific way, but it gets translated into the common language when the IPSP services are going to manage it 🎀

3.2.4. Distributed policy 🌸

as we said earlier, it must be possible for all or part of a host's policy to be managed remotely, and 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 give the essential info that two IPsec endpoints can use to figure out what kinds of SAs are possible between them. this is especially important for hosts controlled by different entities that might not know anything about each other yet 🥺 but a host doesn't have to reveal its whole security policy, just enough to support the SA resolution system for hosts that might want to talk to 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 set has to meet both hosts' requirements and lead to a successfully created new SA 🦋

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 SAs created by IPSP-managed communication should depend only on how correct the compliance checking stage is. in particular, even if the SA resolution scheme produces an incorrect result (and it's likely to be computationally and conceptually complex, so that can happen), it should still be impossible to violate the specified policy of either host 🔥

4. Security Considerations 🔐

this document talks about the high-level requirements for a policy framework and architecture for IPsec. it also gives a justification for the various components 💅

🚨 The security stakes here are real: this is the high-level framework that the whole IPsec policy story is built on, so take the reasoning in this document seriously before you implement anything.

5. IANA Considerations 📋

no action is required by IANA ✨

6. Intellectual Property Statement ⚖️

the IETF doesn't take a position on whether any intellectual property or other rights claimed to cover the implementation or use of the technology in this document are valid or in scope, or on whether any license under those rights might be available. it also doesn't say it has tried to find any such rights 🙃 if you want info on the IETF's procedures for rights in standards-track and standards-related documents, check BCP-11 💖

copies of claims of rights made available for publication, and any assurances of licenses that will be made available (or the result of an attempt to get a general license or permission to use those proprietary rights by implementers or users of this spec), can be obtained from the IETF Secretariat 📬

the IETF also invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology required to practice this standard. send that info to the IETF Executive Director 🫡

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 belong to the authors. they aren't necessarily the views 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. so if something goes sideways, that's not on them 😭

9. Acknowledgements 🫶

the authors thank the members of the IPsec Policy working group who contributed to this document. the group is giving major teamwork energy 🌈

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

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

so this document and translations of it can be copied and handed out, and derivative works that comment on it, explain it, or help implement it can be written, copied, published, and distributed, in whole or in part, with no restrictions of any kind 🦋 the one condition is that the copyright notice and this paragraph are kept on every copy and derivative work. the document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. the exceptions are when you need it for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed), or when you're translating it into languages other than English 🌍

these limited permissions are perpetual and won't be revoked by the Internet Society or its successors or assignees 💜

and the usual legal-but-important bit: this document and the info in it are provided on an "AS IS" basis, and the Internet Society and the Internet Engineering Task Force disclaim all warranties, including any warranty that using the information won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 🙏

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 💖

📦 where this page comes from