idnits 2.17.1 draft-ietf-ipsp-arch-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 438 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([IPSP-REQ]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (July 2000) is 8679 days in the past. Is this intentional? 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 section? 'IPSP-REQ' on line 361 looks like a reference -- Missing reference section? 'RFC-2409' on line 365 looks like a reference -- Missing reference section? 'Photuris' on line 368 looks like a reference -- Missing reference section? 'RFC 2119' on line 138 looks like a reference -- Missing reference section? 'SPP' on line 253 looks like a reference -- Missing reference section? 'RFC-2704' on line 375 looks like a reference -- Missing reference section? 'TDB' on line 174 looks like a reference -- Missing reference section? 'TBD' on line 226 looks like a reference -- Missing reference section? 'IPSP-TRUST' on line 371 looks like a reference -- Missing reference section? 'RFC-2119' on line 355 looks like a reference -- Missing reference section? 'RFC-2401' on line 358 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSP Working Group M. Blaze 2 Internet Draft AT&T Labs - Research 3 draft-ietf-ipsp-arch-00.txt A. Keromytis 4 U. of Pennsylvania 5 M. Richardson 6 Sandelman Software Works 7 L. Sanchez 8 BBN/GTEI 9 July 2000 11 IPsec Policy Architecture 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes an IP Security Policy architecture that 33 conforms to the requirements set forth in [IPSP-REQ]. The 34 architecture defines the mechanisms and protocols needed for 35 discovering, accessing, and processing security policy information 36 of varying granularity. The architecture accommodates topology and 37 policy changes without need of manual reconfiguration of clients 38 and security gateways. 40 1. Introduction 42 -------- ----- ----- -------- 43 |Host A|---|SG1|----- ... -----|SG2|---|Host B| 44 -------- ----- ----- -------- 46 Consider the simple scenario represented by the figure above: Host 47 A wishes to communicate with Host B; A only knows B's network 48 identifier (address) and what security requirements for such a 49 communication itself requires (e.g., A wants to use strong 50 encryption when talking to B). Both hosts are connected to a wide 51 area network through their security gateways (SG1 and SG2 52 respectively). Hosts A and B may know about their local security 53 gateways, because of local configuration; they do not know about 54 the other's security gateway however (or any possible intervening 55 security gateways). In some cases, they may not even know about 56 their local security gateways (e.g., in the case of a large 57 private network with outside links through a number of firewalls). 58 The security gateways may impose certain restrictions on the 59 traffic they see (e.g., only encrypted traffic is allowed to 60 go between A and B). 62 In such a scenario, Host A needs to determine: 64 - What its local policy with regards to end-to-end communication 65 with Host B is. This decision may be deferred to the network 66 administrator, as a matter of corporate policy. 68 - What B's policy with regards to the same end-to-end communication 69 is; if there is an intersection of the two policies, it has to 70 be determined, and the appropriate IPsec SAs have to be 71 negotiated and established. 73 - What security gateways (if any) are in the path between A and B, 74 and what their policies with respect to that communication is. 75 For example, SG1 may allow any kind of traffic between A and B, 76 whereas SG2 may require that any such traffic also be encrypted 77 to itself. Or, SG1 may require that traffic to Host B only be 78 authenticated but not encrypted end-to-end (e.g., certain 79 financial institutions impose such requirements on traffic as 80 a result of legislative controls), but that such traffic may be 81 encrypted from Host A to SG1 and then from SG1 to Host B again. 82 Naturally, Host A needs to ensure that SG1 actually has the 83 authority to make such statements. Depending on the individual 84 policies involved, any combination of these SAs may have to 85 be established by Host A: 87 - SA between Host A and Host B 88 - SA between Host A and SG1 89 - SA between Host A and SG2 90 - SA between SG1 and SG2 91 - SA between SG1 and Host B 92 - SA between SG2 and Host B 94 - The same requirement with regards to communication security 95 policy holds in the opposite direction as well (from Host B to 96 Host A), since most traffic is in fact bidirectional. Note 97 however that different requirements may exist for the two 98 directions. 100 - If either of the Security Gateways decides to establish an SA 101 between itself and the end-host (or some other SG), it may have 102 to recursively invoke the discovery protocol. 104 The scenario may be further complicated by the fact that Host A, 105 Host B, SG1, and SG2 may all lie in different administrative 106 domains with correspondingly different security policies. 108 Manual configuration of policies and gateways is difficult even in 109 the simple scenario described in this section. An architecture for 110 automated gateway and policy discovery and resolution is 111 necessary. Automatic keying may then be used to establish the 112 necessary SAs, e.g., IKE [RFC-2409] or Photuris [Photuris]. 114 Note that even in the trivial case of two hosts without an 115 intervening security gateway, the IPSP architecture allows the two 116 peers to determine what is necessary to establish a secure 117 communication channel (e.g., what authorities or CAs they both 118 trust). 120 Furthermore, note that there are multiple aspects of the overall 121 security policy that applies to a particular communications that 122 has to be made available in different parts of an IPsec 123 implementation; packet selectors have to be specified in the SPD of 124 a security gateway (or end-host), whereas SA parameters have to be 125 provided to the key management system (and ultimately in the 126 SADB). 128 Two more caveats: 130 The Security Policy System (SPS) defines a distributed database of 131 security policy information. It provides the mechanisms needed for 132 discovering, accessing, and processing security policy information 133 of hosts, subnets, or networks. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 137 this document are to be interpreted as described in [RFC 2119]. 139 2. Architecture Overview 141 The basic premises of the IPSP architecture are: 143 - Use of the SPP protocol [SPP] for gateway discovery and security 144 policy distribution. 146 - Use of a trust management system and language [RFC-2704] to 147 resolve and exchange policies respectively. Section 4 gives more 148 details. 150 - Most of the burden of discovering and processing policy is placed 151 on the initiator of a communications. Thus, expensive operations 152 such as policy resolution is (optionally) performed by the 153 initiator of a communications; security gateways need only 154 perform compliance checking, which is computationally cheaper. 155 Policy Servers MAY optionally perform policy resolution, to 156 improve caching and accelerate communication establishment. 158 - IPsec policy is defined in terms of local policy (describing what 159 requirements the host has for a particular communications) and 160 signed policy statements from trusted entities. What entities 161 (and to what extent) are trusted is a matter of local policy; 162 signed policy statements are acquired through the SPP protocol. 163 These statements may be used by an IPSP-compliant system in two 164 ways: 166 - To determine what traffic is allowed through a security gateway 167 or accepted by the remote host. 169 - To convince a security gateway or remote host to allow traffic 170 through. 172 Local policy is expressed in a vendor-specific way. It MUST 173 however be converted to a KeyNote local policy for processing by 174 IPSP. The Policy Model [TDB] describes the semantics of the 175 conversion. 177 (A "KeyNote local policy" is a policy statement that is 178 unconditionally trusted by the host. Such statements MUST be 179 securely stored and protected from tampering. In their simplest 180 form, local policies reduce to a list of trusted keys or CAs.) 182 3. Use of SPP in IPSP 184 SPP is a security gateway and policy discovery protocol. It allows 185 a host to determine what security gateways lie in the path to a 186 specific destination, and what their security policies are. SPP 187 may also be used to distribute certificates (or, more generally, 188 credentials). Note that since trust management credentials are 189 signed, it may not be necessary to sign the entire SPP payload when 190 exchanging policies (to be resolved before next version). 192 For more details on SPP, see [SPP]. 194 4. Compliance Checking and IPSP 196 Policies exchanged in SPP are encoded in KeyNote [RFC-2704] 197 credentials. These are signed statements that describe the 198 acceptable combinations of IPsec selectors (source/destination 199 address and masks, transport protocol and ports, etc.) and SA 200 parameters (encryption/authentication algorithms, key lengths, 201 etc.) 203 A host's local policy specifies what public keys are trusted to 204 make such statements; if KeyNote is used to specify local policy, 205 further restrictions on what these keys are allowed to mandate can 206 be expressed. Other languages (or methods) may be used to express 207 local security policy as well; however, these policies MUST be 208 translated to KeyNote local policies for processing by the trust 209 management system. A separate document will describe the names and 210 semantics of the various action attributes used in the KeyNote 211 credentials used in IPsec, based on the IPsec policy model 212 described in [TBD]. 214 Policy servers in SPP store credentials (signed policy statements) 215 created by the local network security administrator, as well as 216 cached credentials acquired by querying other SPP servers. These 217 credentials are then provided to the security gateway that 218 forwarded the SPP query, and to the host that initiated the SPP 219 protocol. The credentials may then be used in the key management 220 protocol to authorize the host to establish SAs, if necessary, as 221 described in [IPSP-TRUST]. In particular, the end-host may: 223 - Analyze the provided credentials to determine what, if any, SAs 224 must be negotiated with a particular security gateway or end host 225 (policy resolution). The algorithm for doing so is described in 226 a separate document [TBD]. 228 - Simply use the trust management engine to determine which of its 229 local policies with regards to a particular communications is 230 acceptable by the security gateway or remote host. For this, the 231 end-host emulates the compliance checking process that the 232 security gateway or remote host will perform when negotiating 233 SAs. 235 - The end-host may simply use the acquired credentials in the key 236 management protocol. If the necessary SAs are established, the 237 end-host may commence communications (or proceed with the policy 238 discovery); otherwise, an error is reported, or one of the 239 previous two approaches used. 241 The use of KeyNote credentials inside a key management protocol is 242 described in [IPSP-TRUST]. 244 Security gateways download policies from their configured Policy 245 Servers, to initialize their SPD tables. 247 Note that while KeyNote credentials may also provide authentication 248 information to be used by a key management protocol, other 249 authentication mechanisms (e.g., PKIX certificates) can be used for 250 this purpose as well. 252 Policy decorrelation is necessary to ensure that no conflicting 253 policies exist. This process is desribed in [SPP] and is directly 254 applicable to policies expressed in terms of KeyNote credentials. 256 Trust relations between different domains may also be described in 257 terms of KeyNote credentials. A separate document will describe 258 the operational implications of this. In particular, the 259 implications of delegation across domains and policy decorrelation 260 needs to be carefully examined and documented. 262 5. Legacy End-hosts 264 This section describes IPSP operation when either or both of the 265 end-hosts (origin and/or destination end-hosts) are not IPSP-aware. 267 5.1 Legacy Origin End-host 269 When an origin end-host operating inside a Security Domain does not 270 implement the Security Gateway Discovery Protocol, coordination 271 between Security Gateways and the end-host is not possible. 273 A Security Gateway that intercepts a packet from such a host MAY 274 initiate a Security Gateway discovery process, specifying that it 275 will be proxying traffic for the end-host. This will allow the 276 Security Gateway to establish IPsec tunnels with other Security 277 Gateways (and potentially the destination end-host itself) that 278 protects the origin end-host's traffic. 280 5.2 Legacy Destination End-host 282 When a destination end-host does not implement the SGDP, it is the 283 responsibility of the Policy Server of its Security Domain to 284 specify the end-to-end security parameters (if any). This means 285 that a Policy Server MUST be aware of which hosts it is responsible 286 for. 288 6. Legacy Security Gateways 290 Legacy Security Gateways do not participate in the discovery 291 process, since they do not implement the SGDP. Such a system, upon 292 receipt of a discovery packet may drop it (which will cause the 293 discovery process to time-out), forward it with no further 294 processing, or initiate an IPsec exchange with some remote host or 295 Security Gateway, based on its local (non-IPSP-conforming) security 296 policy. In the latter two cases, no further action is required by 297 any IPSP-compliant system, as the legacy Security Gateway is 298 transparent to the discovery process. 300 If the legacy Security Gateway drops the discovery packets and 301 sends back an appropriate ICMP message, the recipient of such a 302 message (another SG or the origin end-host) MAY establish the 303 necessary IPsec SAs with the legacy SG to allow traffic to flow 304 through the legacy SG. The legitimacy of the ICMP message MUST be 305 verified through cryptographic (or other) means. 307 Alternatively, the Security Gateway or origin end-host MUST 308 terminate the discovery process and notify the Policy Servers, SGs, 309 and origin end-host involved in the discovery process. 311 No solution as yet exists if the legacy Security Gateway silently 312 discards packets. 314 7. Security Considerations 316 This section has not been completed. It will be, in future versions 317 of this draft. 319 8. IANA Considerations 321 No actions by IANA are required (yet). 323 9. ToDo List 325 - Describe semantics and operational requirements for inter-domain 326 policies (delegation). 328 - Decorrelation in the context of delegation. 330 - Describe the resolution algorithm in detail (very similar to the 331 one described in SPP). 333 - Determine whether all SPP messages must be protected, given that 334 policies themselves are/may be signed. 336 - Describe SPD initialization by gateways (and end-hosts ?) 338 - Policy Server -- how does a host find out which one is the local 339 one ? DHCP, manual configuration, LDAP, Service Discovery 340 protocol, dedicated multicast address, other ? 342 - Mobile hosts and PS determination (same as above, more issues). 344 - Flesh out missing documents (find volunteers). 346 - Import policy model discussion. 348 - More verbose description of SPP ? Is reference sufficient ? 350 - Diagram with all possible SAs/tunnels in the example in 351 Introduction. 353 References: 355 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", RFC-2119, March 1997. 358 [RFC-2401] S. Kent, R. Atkinson, RFC2401: "Security Architecture 359 for the Internet Protocol", November 1998. 361 [IPSP-REQ] Blaze, M., Keromytis, A., Richardson, M., and L. 362 Sanchez, draft-ietf-ipsp-requirements-00.txt: "IPsec 363 Policy Discovery Protocol Requirements", October 1999. 365 [RFC-2409] Harkins, D., and D. Carrel, "The Internet Key Exchange 366 (IKE)", RFC 2409, November 1998. 368 [Photuris] Karn, P., and B. Simpson, Photuris: Session Key 369 Management Protocol, Work in Progress. 371 [IPSP-TRUST] Blaze, M., Ioannidis, J., and A. Keromytis, 372 draft-blaze-ipsp-trustmgt-00.txt: "Compliance 373 Checking and IPSEC Policy Management", March 2000. 375 [RFC-2704] Blaze, M., Feigenbaum, J., Ioannidis, J. and 376 A. Keromytis, "The KeyNote Trust-Management System 377 Version 2", RFC 2704, September 1999. 379 Authors' addresses: 381 Matt Blaze 382 AT&T Labs - Research 383 180 Park Avenue 384 Florham Park, New Jersey 07932-0971 386 Email: mab@research.att.com 388 Angelos D. Keromytis 389 Distributed Systems Lab 390 CIS Department, University of Pennsylvania 391 200 S. 33rd Street 392 Philadelphia, Pennsylvania 19104-6389 394 Telephone: +1 215 573 3639 395 Email: angelos@dsl.cis.upenn.edu 397 Michael C. Richardson 398 Sandelman Software Works Corp. 399 152 Rochester Street 400 Ottawa, ON K1R 7M4 401 Canada 403 Telephone: +1 613 276-6809 404 Email: mcr@sandelman.ottawa.on.ca 406 Luis A. Sanchez 407 BBN Technologies 408 GTE Internetworking 409 10 Moulton Street 410 Cambridge, MA 02140 411 USA 413 Telephone: +1 (617) 873-3351 414 Email: lsanchez@bbn.com 416 Expiration and File Name 418 This draft expires February 1, 2001 420 Its file name is draft-ietf-ipsp-arch-00.txt