idnits 2.17.1 draft-ietf-ipsp-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 317 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 42 has weird spacing: '...ity now enjoy...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SPP' is mentioned on line 213, but not defined == Unused Reference: 'RFC-2401' is defined on line 266, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSP Working Group M. Blaze, AT&T Labs 2 Internet Draft A. Keromytis, U. of Pennsylvania 3 draft-ietf-ipsp-requirements-00.txt M. Richardson, Sandelman Software Works 4 Expires January, 2001 L. Sanchez, BBN/GTEI 5 July, 2000 7 IPSP Requirements 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- Drafts 17 as reference material or to cite them other than as "work in 18 progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 31 West Coast). 33 Abstract 35 This document describes the problem and solution requirements for 36 the IPsec Policy Protocol. 38 1.0 Introduction 40 1.1 Security Policy and IPSEC 42 Network-layer security now enjoys broad popularity as a tool for 43 protecting Internet traffic and resources. Security at the network 44 layer can be used as a tool for at least two kinds of security 45 architecture: 47 a) Security gateways. Security gateways (including "firewalls") at 48 the edges of networks use IPSEC to enforce access control, protect 49 the confidentiality and authenticity of network traffic entering 50 and leaving a network, and to provide gateway services for virtual 51 private networks (VPNs). 53 b) Secure end-to-end communication. Hosts use IPSEC to implement 54 host-level access control, to protect the confidentiality and 55 authenticity of network traffic exchanged with the peer hosts with 56 which they communicate, and to join virtual private networks. 58 On one hand, IPSEC provides an excellent basis for a very wide rage of 59 protection schemes; on the other hand, this wide range of applications 60 for IPSEC creates complex management tasks that become especially 61 difficult as networks scale up and require different security 62 policies, controlled by different entities, for different kinds of 63 traffic in different parts of the network. 65 As organizations deploy security gateways, the Internet divides into 66 heterogeneous regions that enforce different access and security 67 policies. Yet it is often still necessary for hosts to communicate 68 across the network boundaries controlled by several different 69 policies. The wide range of choices of cryptographic parameters (at 70 multiple protocol layers) complicates matters and introduces the need 71 to for hosts and security gateways to identify and negotiate a set of 72 security parameters that meets each party's requirements. Even more 73 complexity arises as IPSEC becomes the means through which firewalls 74 enforce access control and VPN membership; two IPSEC endpoints that 75 want to establish a security association must identify not only the 76 mutually acceptable cryptographic parameters, but also exactly what 77 kind of access the combined security policy provides. 79 While the negotiation of cryptographic and other security parameters 80 for IPSEC security associations (SAs) is supported by key management 81 protocols (e.g., ISAKMP [RFC-2408]), the IPSEC key management layer 82 does not provide a scheme for managing, negotiating and enforcing the 83 security policies under which SAs operate. 85 IPSP provides the framework for managing IPSEC security policy, 86 negotiating security association (SA) parameters between IPSEC 87 endpoints, and distributing authorization and policy information among 88 hosts that require the ability to communicate via IPSEC. 90 1.2 The IPSP Problem Space 92 IPSP aims to provide a scalable, decentralized framework for managing, 93 discovering and negotiating the host and network IPSEC policies that 94 govern access, authorization, cryptographic mechanisms, 95 confidentiality, data integrity, and other IPSEC properties. 97 The central problem to solved by IPSP is that of controlling security 98 policy in a manner that is useful for the wide range of IPSEC 99 applications and modes of operation. In particular: 101 - IPSP hosts may be serve as IPSEC endpoints, security gateways, 102 network management hubs, or a combination of these functions. 103 IPSP will manage end-users computers (which may be fixed 104 workstations controlled by a single organization or mobile laptops 105 that require remote access to a corporate VPN), firewalls (which 106 provide different services and allow different levels of access to 107 different classes of traffic and users), VPN routers (which 108 support links to other VPNs that might be controlled by a 109 different organization's network policy), web and other servers 110 (which might provide different services depending on where a 111 client request came from), and so on. 113 - IPSP administration will be inherently heterogeneous and 114 decentralized. A basic feature of IPSEC is that two hosts can 115 establish a Security Association even though they might not share 116 a common security policy, or, indeed, trust one another at all. 117 This property of IPSEC becomes even more pronounced at the higher 118 level abstraction managed by IPSP. 120 - The SA parameters acceptable to any pair of hosts (operating under 121 different policies) will often not be specified in advance. IPSP 122 will often have to negotiate and discover the mutually-acceptable 123 SA parameters on-the-fly when two hosts attempt to create a new SA. 125 - Some hosts will be governed by policies that are not directly 126 specified in the IPSP language. For example, a host's IPSEC 127 policy might be derived from a more comprehensive higher-layer 128 security policy managed by some other system. Similarly, some 129 vendors might develop specialized (and proprietary) tools for 130 managing policy in their products. In such cases, it is 131 necessary to to derive an IPSP policy specification only for 132 those aspects of a host's policy that involve interoperability 133 with other hosts running IPSP. 135 - IPSP must scale to support complex policy administration schemes. 136 In even modest-size networks, one administrator must often control 137 policy remotely, and must have the ability to change the policy 138 on many different hosts at the same time. In larger networks (or 139 those belonging to large organizations), a host's policy might be 140 governed by several different authorities (e.g. several different 141 departments might have the authority to add users to a firewall or 142 open access to new services). Different parts of a policy might 143 be "owned" by different entities in a complex hierarchy. IPSP 144 must provide a mechanism for delegating specific kinds of 145 authority to specific entities. 147 - The semantics of IPSP must be well defined, particularly with 148 respect to any security-critical aspects of the system 150 - IPSP must be secure, sound, and comprehensible. It should be 151 possible to understand what an IPSP policy does; the difficulty of 152 understanding an IPSP policy should be somewhat proportional to 153 the complexity of the problem it solves. It should also be 154 possible to have confidence that an IPSP policy does what it 155 claims to and that and IPSP implementation is correct; 156 architecturally, the security-critical parts of IPSP should be 157 small and well-specified enough to allow verification of their 158 correct operation. Ideally, IPSP should be compatible with formal 159 methods such as implementing security policies with provable 160 properties. 162 2 Requirements for IPSP 164 2.1 General Requirements 166 An IPSP solution must include 168 - A policy model with well-defined semantics that captures the 169 relationship between IPSEC SAs and higher-level security policies 171 - A gateway discovery mechanism that allows hosts to discover 172 where to direct IPSEC traffic intended for a specific endpoint. 174 - A well-specified language for describing host policies 176 - A means for distributing responsibility for different aspects of 177 policy to different entities 179 - A mechanism for discovering the policy of a host 181 - A mechanism for resolving the specific IPSEC parameters to be used 182 between two hosts governed by different policies (and for 183 determining whether any such parameters exist) 185 and 187 - A well-specified mechanism for checking for compliance with a 188 host's policy when SAs are created 190 The mechanisms used in IPSP must not require any protocol 191 modifications in any of the IPsec standards (ESP, AH, IKE). The 192 mechanisms must be independent of the SA-negotiation protocol, but may 193 assume certain functionality from such a protocol (this is to ensure 194 that future SA-negotiation protocols are not incompatible with IPSP). 196 2.2 Description and Justification 198 2.2.1 Policy Model 200 A Policy Model defines the semantics of IPsec policy. Policy 201 specification, checking, and resolution should implement the semantics 202 defined in the model. The model should, however, be independent of 203 the specific policy distribution mechanism and policy discovery 204 scheme, to the extent possible. 206 2.2.2 Gateway Discovery 208 The gateway discovery mechanism may be invoked by any host or gateway. 209 Its goal is to determine what IPSEC gateways exist between the 210 initiator and the intended communication peer. The actual mechanism 211 employed may be used to piggyback information necessary by other 212 components of the IPSP architecture (e.g., policy discovery, as is 213 done in [SPP]). The discovery mechanism may have to be invoked at any 214 time, independently of existing security associations or other 215 communication, to detect topology changes. 217 2.2.3 IPSP Language 219 In order to allow for policy discovery, compliance checking, and 220 resolution across a range of hosts, a common language is necessary in 221 which to express the policies of hosts that need to communicate with 222 one another. Statements in this language are the output of policy 223 discovery, and provide the input to the policy resolution and 224 compliance checking systems. Note that a host's or network's security 225 policy may be expressed in a vendor-specific way, but would be 226 translated to the common language when it is to be managed by the IPSP 227 services. 229 2.2.4 Distributed policy 231 As discussed above, it must be possible for all or part of a host's 232 policy to be managed remotely, possible by more than one entity. This 233 is a basic requirement for large-scale networks and systems. 235 2.2.5 Policy Discovery 237 A policy discovery mechanism must provide the essential information 238 that two IPSEC endpoints can use to determine what kinds of SAs are 239 possible between one another. This is especially important for hosts 240 that are not controlled by the same entity, and that might not 241 initially share any common information about each other. Note that a 242 host need not reveal its entire security policy, only enough 243 information to support the SA resolution system for hosts that might 244 want to communicate with it. 246 2.2.6 SA Resolution 248 Once two hosts have learned enough about each other's policies, it 249 must be possible (and computationally feasible) to find an acceptable 250 set of SA parameters that meets both host's requirements and will lead 251 to the successful creation of a new SA. 253 2.2.7 Compliance Checking 255 When a host proposes the output of the SA resolution scheme, it must 256 be checked for compliance with the local security policy of each host. 257 The security and soundness of the SAs created by IPSP-managed 258 communication should depend only on the correctness of the compliance 259 checking stage. In particular, the even if the SA resolution scheme 260 (which is likely to be computationally and conceptually complex) 261 produces an incorrect result, it should still not be possible to 262 violate the specified policy of either host. 264 3. References 266 [RFC-2401] S. Kent, R. Atkinson, RFC2401: "Security Architecture for the 267 Internet Protocol", November 1998. 269 [RFC-2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, RFC2408: 270 "Internet Security Association and Key Management Protocol 271 (ISAKMP)", November 1998. 273 Author's Address 275 Matt Blaze 276 AT&T Labs - Research 277 180 Park Avenue 278 Florham Park, NJ 07932 USA 279 Email: mab@research.att.com 281 Angelos D. Keromytis 282 Distributed Systems Lab 283 CIS Department, University of Pennsylvania 284 200 S. 33rd Street 285 Philadelphia, Pennsylvania 19104-6389 USA 286 EMail: angelos@dsl.cis.upenn.edu 288 Michael C. Richardson 289 Sandelman Software Works Corp. 290 152 Rochester Street 291 Ottawa, ON K1R 7M4 Canada 292 Telephone: +1 613 276-6809 293 EMail: mcr@sandelman.ottawa.on.ca 295 Luis A. Sanchez 296 BBN Technologies 297 GTE Internetworking 298 10 Moulton Street 299 Cambridge, MA 02140 USA 300 Telephone: +1 (617) 873-3351 301 EMail: lsanchez@bbn.com 303 Expiration and File Name 305 This draft expires January 1, 2001 307 Its file name is draft-ietf-ipsp-requirements-00.txt