idnits 2.17.1 draft-bellovin-useipsec-02.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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. 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 (October 2003) is 7499 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: 'RFC2041' is mentioned on line 201, but not defined -- Looks like a reference, but probably isn't: '2385' on line 301 -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent00a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent00b' -- Possible downref: Non-RFC (?) normative reference: ref. 'KINK' ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven M. Bellovin 3 Internet Draft AT&T Labs Research 5 Expiration Date: April 2004 October 2003 7 Guidelines for Mandating the Use of IPsec 9 draft-bellovin-useipsec-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Security Considerations sections of many Internet Drafts say, in 35 effect, "just use IPsec". While this is sometimes correct, more 36 often it will leave users without real, interoperable security 37 mechanisms. This memo offers some guidance on when IPsec should and 38 should not be specified. 40 1. Introduction 42 The Security Considerations sections of many Internet Drafts say, in 43 effect, "just use IPsec". While this is sometimes correct, more 44 often it will leave users without real, interoperable security 45 mechanisms. IPsec is often unavailable in the likely endpoints. 46 Even if it is available, it may not provide the proper granularity of 47 protection. Finally, if it is available and appropriate, the 48 document mandating it needs to specify just how it is to be used. 50 Recall that the goal is realistic, interoperable security. 51 Specifying, as the only security mechanism, a configuration which is 52 unavailable to -- and hence unusable by -- a majority of the user 53 community is tantamount to saying "turn off security". 55 For further guidance on security considerations (including discussion 56 of IPsec), see [RFC3552]. 58 NOTE: Many of the arguments below relate to the capabilities of 59 current implementations of IPsec. These may change over time; this 60 advice based on the knowledge available to the IETF at publication 61 time. 63 2. WARNING 65 The design of security protocols is a subtle and difficult art. The 66 cautions here about specifying use of IPsec should NOT be taken to 67 mean that that you should invent your own new security protocol for 68 each new application. If IPsec is a bad choice, use another 69 standardized, well-understood security protocol. Don't roll your 70 own. 72 3. The Pieces of IPsec 74 IPsec is composed of a number of different pieces. These can be used 75 to provide confidentiality, integrity, and replay protection; though 76 some these can be configured manually, in general a key management 77 component is used. Additionally, the decision about whether and how 78 to use IPsec is controlled by a policy database of some sort. 80 3.1. AH and ESP 82 The Authentication Header (AH) [RFC2402] and the Encapsulating 83 Security Protocol (ESP) [RFC2406] are the over-the-wire security 84 protocols. Both provide (optional) replay protection. ESP typically 85 is used to provide confidentiality (encryption), integrity and 86 authentication for traffic. ESP also can provide integrity and 87 authentication without confidentiality, which makes it a good 88 alternative to AH in most cases where confidentiality is not a 89 required or desired service. Finally, ESP can be used to provide 90 confidentiality alone, although this is not recommended [Bell96]. 92 The difference in integrity protection offered by AH is that AH 93 protects portions of the preceding IP header, including the source 94 and destination address. However, when ESP is used in tunnel mode 95 (see section 4.2), and if integrity/authentication is enabled, the IP 96 header seen by the source and destination hosts is completely 97 protected anyway. 99 AH can also protect those IP options that need to be seen by 100 intermediate routers, but must be intact and authentic when delivered 101 to the receiving system. At this time, use (and existence) of such 102 IP options is extremely rare. 104 If an application requires such protection, and if the information to 105 be protected cannot be inferred from the key management process, AH 106 must be used. (ESP is generally regarded as easier to implement; 107 however, virtually all IPsec packages support both.) If 108 confidentiality is required, ESP must be used. It is possible to use 109 AH in conjunction with ESP, but this combination is rarely required. 111 3.2. Transport and Tunnel Mode 113 AH and ESP can both be used in either transport mode or tunnel mode. 114 In tunnel mode, the IPsec header is followed by an inner IP header; 115 this is the normal usage for Virtual Private Networks (VPN), and it 116 is generally required whenever either end of the IPsec-protected path 117 is not the ultimate IP destination, e.g., when IPsec is implemented 118 in a firewall, router, etc. Transport mode is preferred for point- 119 to-point communication, though tunnel mode can be used for this 120 purpose. 122 3.3. Key Management 124 Any cryptographic system requires key management. IPsec provides for 125 both manual and automatic key management schemes. Manual key 126 management is easy; however, it doesn't scale very well. Also, 127 IPsec's replay protection mechanisms are not available if manual key 128 management is used. 130 One automated key exchange mechanism is available, Internet Key 131 Exchange (IKE) [RFC2409]. A new, simpler version of IKE is currently 132 being designed. A second mechanism, Kerberized Internet Negotiation 133 of Keys (KINK) [KINK], is being defined. It, of course, uses 134 Kerberos, and is suitable if and only if a Kerberos infrastructure is 135 available. 137 IKE can use public key certificates or shared secrets. Shared secret 138 authentication is simpler, but doesn't scale as well, since each 139 endpoint must share a unique secret with every peer with which it can 140 communicate, in order to uniquely authenticate these peers. 142 IKE also has public key variants. In most real-world situations, 143 these use locally-issued certificates. That is, the administrator of 144 the system or network concerned will issue certificates to all 145 authorized users; these certificates are useful only for IPsec. 147 It is sometimes possible to use certificates from an existing PKI 148 with IKE. In practice, this is rare. Furthermore, there not only is 149 no global PKI for the Internet, there probably never will be one. 150 Designing a structure which assumes such a PKI is a mistake. In 151 particular, assuming that an arbitrary node will have an "authentic" 152 certificate, issued by a mutually trusted third party and vouching 153 for that node's identity, is wrong. Again, such a PKI does not and 154 probably will not exist. Public key IKE is generally a good idea, 155 but almost always with locally-issued certificates. 157 Note that public key schemes require a substantial amount of 158 computation. Protocol designers should consider whether or not such 159 computations are feasible on devices of interest to their clientele. 160 Using certificates roughly doubles the number of large 161 exponentiations that must be performed, compared with shared secret 162 versions of IKE. 164 Today, even low-powered devices can generally perform enough 165 computation to set up a limited number of security associations; 166 concentration points, such as firewalls or VoIP servers, may require 167 hardware assists, especially if many peers are expected to create 168 security associations at about the same time. 170 3.4. Applications Program Interface (API) 172 It is, in some sense, a misnomer to speak of the API as a part of 173 IPsec, since that piece is missing on many systems. To the extent 174 that it does exist, it isn't standardized. The problem is simple: 175 it is difficult or impossible to request IPsec protection, or to tell 176 if was used for given inbound packets or connections. 178 Router- or firewall-based IPsec implementations pose even greater 179 problems, since there is no standardized over-the-wire protocol for 180 communicating this information from outboard encryptors to hosts. 182 4. Availability of IPsec in Target Devices 184 Although IPsec is now widely implemented, and is available for 185 current releases of most host operating systems, it is less available 186 for embedded systems. Few hubs, network address translators, etc., 187 implement it, especially at the low end. It is generally 188 inappropriate to rely on IPsec when many of the endpoints are in this 189 category. 191 Even for host-to-host use, IPsec availability (and experience, and 192 ease of use) has generally been for VPNs. Hosts that support IPsec 193 for VPN use do not always support it on a point-to-point basis, 194 especially via a stable, well-defined API ur user interface. 196 Finally, few implementations support multiple layers of IPsec. If a 197 telecommuter is using IPsec in VPN mode to access an organizational 198 network, he or she may not be able to employ a second level of IPsec 199 to protect an application connection to a host within the 200 organization. (We note that such support is, in fact, mandated by 201 Case 4 of Section 4.5 of [RFC2041]. Nevertheless, it is not widely 202 available.) The likelihood of such deployment scenarios should be 203 taken into account when deciding whether or not to mandate IPsec. 205 5. Endpoints 207 [RFC2401] describes many different forms of endpoint identifier. 208 These include source addresses (both IPv4 and IPv6), host names 209 (possibly as embedded in X.500 certificates), and user IDs (again, 210 possibly as embedded in a certificate). Not all forms of identifier 211 are available on all implementations; in particular, user-granularity 212 identification is not common. This is especially a concern for 213 multi-users systems, where it may not be possible to use different 214 certificates to distinguish between traffic from two different users. 216 Again, we note that the ability to provide fine-grained protection, 217 such as keying each connection separately, and with per-user 218 credentials, was one of the original design goals of IPsec. 219 Nevertheless, only a few platforms support it. Indeed, some 220 implementations do not even support using port numbers when deciding 221 whether or not to apply IPsec protection. 223 6. Selectors and the SPD 225 Section 4.4 of [RFC2401] describes the Security Policy Database (SPD) 226 and "selectors" used to decide what traffic should be protected by 227 IPsec. Choices include source and destination addresses (or address 228 ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port 229 numbers for TCP and UDP. Protocols whose protection requirements 230 cannot be described in such terms are poorer candidates for IPsecp in 231 particular, it becomes impossible to apply protection at any finer 232 grain than "destination host". Thus, traffic embedded in an L2TP 233 [RFC2661] session cannot be protected selectively by IPsec above the 234 L2TP layer, because IPsec has no selectors defined that let it peer 235 into the L2TP packet to find the TCP port numbers. Similarly, SCTP 236 [RFC2960] did not exist when [RFC2401] was written; thus, protecting 237 individual SCTP applications on the basis of port number could not be 238 done until a new document is written that defines new selectors for 239 IPsec. 241 The granularity of protection available may have side-effects. If 242 certain traffic between a pair of machines is protected by IPsec, 243 does the implementation permit other traffic to be unprotected, or 244 protected by different policies? Alternatively, if the 245 implementation is such that it is only capable of protecting all 246 traffic or none, does the device have sufficient CPU capacity to 247 encrypt everything? Note that some low-end devices may have limited 248 secure storage capacity for keys, etc. 250 Implementation issues are also a concern here. As before, too many 251 vendors have not implemented the full specifications; too many IPsec 252 implementations are not capable of using port numbers in their 253 selectors. Protection of traffic between two hosts is thus on an all 254 or nothing basis when these non-compliant implementations are 255 employed. 257 7. Broadcast and Multicast 259 Although the designers of IPsec tried to leave room for protection of 260 multicast traffic, the design has not yet been completed. There is, 261 as yet, no key management for the general case. Worse yet, an 262 important component of over-the-wire IPsec -- replay protection -- is 263 very difficult to implement in a multi-sender situation. IPsec is 264 thus inappropriate for such protocols unless and until suitable key 265 management and replay protection mechanisms are defined and available 266 in the target domain. (Single-sender multicast can be supported, if 267 suitable key management is available; the MSEC working group is 268 developing such a protocol.) 270 8. Mandating IPsec 272 Despite all of the caveats given above, it may still be appropriate 273 to use IPsec in particular situations. The range of choices make it 274 mandatory to define precisely how IPsec is to be used. Authors of 275 RFCs that rely on IPsec must specify the following: 277 (a) What selectors the initiator of the conversation (the client, 278 in client-server architectures) should use? In particular, 279 what addresses, port numbers, etc., are to be used? 281 (b) What IPsec protocol is to be used: AH or ESP? What mode is 282 to be employed: transport mode or tunnel mode? 284 (c) What form of key management is appropriate? 286 (d) What security policy database entry types should be used by 287 the responder (i.e., the server) when deciding whether or not 288 to accept the IPsec connection request. 290 (e) What form of identification and authentication should be used. 292 (f) Which of the many variants of IKE must be supported. 294 (g) Is suitable IPsec support available in likely configurations 295 of the products that would have to employ IPsec? 297 9. Example 299 Suppose that the designers of the Border Gateway Protocl (BGP) 300 [RFC1771] wished to use IPsec for security, rather than the mechanism 301 described in [2385]. Does it meet these criteria? (Note that the 302 deeper security issues raised by BGP are not addressed by IPsec or 303 any other transmission security mechanism. See [Kent00a] and 304 [Kent00b] for more details.) 306 Selectors 307 The issue of selectors is easy. BGP already runs between 308 manully-configured pairs of hosts on TCP port 179. The 309 appropriate selector would be the pair of BGP speakers, for 310 that port only. Note that the router's "loopback address" is 311 almost certainly the address to use. 313 Mode 314 Clearly, transport mode is the proper choice. The information 315 being communicated is generally not confidential, so 316 encryption need not be used. Either AH or ESP can be used; if 317 ESP is used, the sender's IP address would need to be checked 318 against the IP address asserted in the key management 319 exchange. (This check is mandated by [RFC2401].) 321 Key Management 322 To permit replay detection, an automated key management system 323 should be used, most likely IKE. 325 Security Policy 326 Connections should be accepted only from the designated peer. 328 Authentication 329 Given the number of BGP-speaking routers used internally by 330 large ISPs, it is likely that shared key mechanisms are 331 inadequate. Consequently, certificate-based IKE must be 332 supported. However, shared secret mode is reasonable on 333 peering links, or (perhaps) on links between ISPs and 334 customers. Whatever scheme is used, it must tie back to a 335 source IP address in some fashion, since other BGP policies 336 are expressed in terms of the peer's IP address. 338 Availability 339 For this scenario, availability is the crucial question. Do 340 likely BGP speakers -- both backbone routers and access 341 routers -- support the profile of IPsec described above? Will 342 use of IPsec, with its attendant expensive cryptographic 343 operations, raise the issue of new denial of service attacks? 344 The working group and the IESG must make these determinations 345 before deciding to use IPsec to protect BGP. 347 10. Security Considerations 349 IPsec provides transmission security and simple access control only. 350 There are many other dimensions to protocol security that are beyond 351 the scope of this memo. Within its scope, the security of any 352 resulting protocol depends heavily on the accuracy of the analysis 353 that resulted in a decision to use IPsec. 355 11. Acknowledgments 357 Ran Atkinson, Barbara Fraser, Paul Hoffman, Stephen Kent, Eric 358 Fleischman, and others have made many useful suggestions. 360 12. References 362 [Bell96] "Problem Areas for the IP Security Protocols", S.M. 363 Bellovin, Proc. Sixth Usenix Security Symposium, 1996, pp. 364 205-214. 366 [Kent00a] "Secure Border Gateway Protocol (Secure-BGP)", S. Kent, C. 367 Lynn, and K. Seo, IEEE Journal on Selected Areas in 368 Communications 18:4, April 2000, pp. 582-592. 370 [Kent00b] "Secure Border Gateway Protocol (S-BGP) -- Real World 371 Performance and Deployment Issues", S. Kent, C. Lynn, J. 372 Mikkelson, and K. Seo, Proc. Network and Distributed System 373 Security Symposium, February 2000. 375 [KINK] "Kerberized Internet Negotiation of Keys (KINK)", M. Thomas 376 and J. Vilhuber, work in progress, 2002. 378 [RFC1771] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter and T. 379 Li. RFC 1771, March 1995. 381 [RFC2401] "Security Architecture for the Internet Protocol", S. Kent 382 and R. Atkinson, RFC 2401, November 1998. 384 [RFC2402] "IP Authentication Header", S. Kent and R. Atkinson, RFC 385 2402, November 1998. 387 [RFC2406] "IP Encapsulating Security Payload (ESP)", S. Kent and R. 389 Atkinson, RFC 2406, November 1998. 391 [RFC2409] "The Internet Key Exchange (IKE)", D. Harkins and D. 392 Carrel. RFC 2409, November 1998. 394 [RFC2661] "Layer Two Tunneling Protocol L2TP", W. Townsley, A. 395 Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. RFC 2661, 396 August 1999. 398 [RFC2960] "Stream Control Transmission Protocol", R. Stewart, Q. Xie, 399 K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, 400 M. Kalla, L. Zhang, and V. Paxson. RFC 2960, October 2000. 402 [RFC3552] "Guidelines for Writing RFC Text on Security 403 Considerations", E. Rescorla and B. Korver, work in progress, 404 2002. 406 13. Author Information 408 Steven M. Bellovin 409 AT&T Labs Research 410 Shannon Laboratory 411 180 Park Avenue 412 Florham Park, NJ 07932 413 Phone: +1 973-360-8656 414 email: bellovin@acm.org