idnits 2.17.1 draft-bellovin-useipsec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 436. -- Found old boilerplate from RFC 3978, Section 5.5 on line 452. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 2004) is 7346 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: 'RFC3715' is mentioned on line 110, but not defined == Missing Reference: 'RFC3280' is mentioned on line 151, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'RFC2041' is mentioned on line 210, but not defined == Missing Reference: 'RFC3554' is mentioned on line 247, but not defined == Missing Reference: 'MIKEY' is mentioned on line 271, but not defined == Missing Reference: '2401bis' is mentioned on line 274, but not defined == Missing Reference: '2402bis' is mentioned on line 274, but not defined == Missing Reference: 'ESPv3' is mentioned on line 274, but not defined == Missing Reference: 'RFC2284' is mentioned on line 304, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) -- Looks like a reference, but probably isn't: '2385' on line 316 -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent00a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent00b' ** 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: 20 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steven M. Bellovin 2 Internet Draft AT&T Labs Research 4 Expiration Date: September 2004 March 2004 6 Guidelines for Mandating the Use of IPsec 8 draft-bellovin-useipsec-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Security Considerations sections of many Internet Drafts say, in 34 effect, "just use IPsec". While this is sometimes correct, more 35 often it will leave users without real, interoperable security 36 mechanisms. This memo offers some guidance on when IPsec should and 37 should not be specified. 39 1. Introduction 41 The Security Considerations sections of many Internet Drafts say, in 42 effect, "just use IPsec". While this is sometimes correct, more 43 often it will leave users without real, interoperable security 44 mechanisms. IPsec is often unavailable in the likely endpoints. 45 Even if it is available, it may not provide the proper granularity of 46 protection. Finally, if it is available and appropriate, the 47 document mandating it needs to specify just how it is to be used. 49 Recall that the goal is realistic, interoperable security. 50 Specifying, as the only security mechanism, a configuration which is 51 unavailable to -- and hence unusable by -- a majority of the user 52 community is tantamount to saying "turn off security". 54 For further guidance on security considerations (including discussion 55 of IPsec), see [RFC3552]. 57 NOTE: Many of the arguments below relate to the capabilities of 58 current implementations of IPsec. These may change over time; this 59 advice based on the knowledge available to the IETF at publication 60 time. 62 2. WARNING 64 The design of security protocols is a subtle and difficult art. The 65 cautions here about specifying use of IPsec should NOT be taken to 66 mean that that you should invent your own new security protocol for 67 each new application. If IPsec is a bad choice, use another 68 standardized, well-understood security protocol. Don't roll your 69 own. 71 3. The Pieces of IPsec 73 IPsec is composed of a number of different pieces. These can be used 74 to provide confidentiality, integrity, and replay protection; though 75 some these can be configured manually, in general a key management 76 component is used. Additionally, the decision about whether and how 77 to use IPsec is controlled by a policy database of some sort. 79 3.1. AH and ESP 81 The Authentication Header (AH) [RFC2402] and the Encapsulating 82 Security Protocol (ESP) [RFC2406] are the over-the-wire security 83 protocols. Both provide (optional) replay protection. ESP typically 84 is used to provide confidentiality (encryption), integrity and 85 authentication for traffic. ESP also can provide integrity and 86 authentication without confidentiality, which makes it a good 87 alternative to AH in most cases where confidentiality is not a 88 required or desired service. Finally, ESP can be used to provide 89 confidentiality alone, although this is not recommended [Bell96]. 91 The difference in integrity protection offered by AH is that AH 92 protects portions of the preceding IP header, including the source 93 and destination address. However, when ESP is used in tunnel mode 94 (see section 4.2), and if integrity/authentication is enabled, the IP 95 header seen by the source and destination hosts is completely 96 protected anyway. 98 AH can also protect those IP options that need to be seen by 99 intermediate routers, but must be intact and authentic when delivered 100 to the receiving system. At this time, use (and existence) of such 101 IP options is extremely rare. 103 If an application requires such protection, and if the information to 104 be protected cannot be inferred from the key management process, AH 105 must be used. (ESP is generally regarded as easier to implement; 106 however, virtually all IPsec packages support both.) If 107 confidentiality is required, ESP must be used. It is possible to use 108 AH in conjunction with ESP, but this combination is rarely required. 110 All variants of IPsec have problems with NAT boxes -- see [RFC3715] 111 for details -- but AH is considerably more troublesome. In 112 environments where there is substantial likelihood that the two end- 113 points will be separated by a NAT box, AH should be avoided. 115 3.2. Transport and Tunnel Mode 117 AH and ESP can both be used in either transport mode or tunnel mode. 118 In tunnel mode, the IPsec header is followed by an inner IP header; 119 this is the normal usage for Virtual Private Networks (VPN), and it 120 is generally required whenever either end of the IPsec-protected path 121 is not the ultimate IP destination, e.g., when IPsec is implemented 122 in a firewall, router, etc. Transport mode is preferred for point- 123 to-point communication, though tunnel mode can be used for this 124 purpose. 126 3.3. Key Management 128 Any cryptographic system requires key management. IPsec provides for 129 both manual and automatic key management schemes. Manual key 130 management is easy; however, it doesn't scale very well. Also, 131 IPsec's replay protection mechanisms are not available if manual key 132 management is used. 134 One automated key exchange mechanism is available, Internet Key 135 Exchange (IKE) [RFC2409]. A new, simpler version of IKE is currently 136 being designed. A second mechanism, Kerberized Internet Negotiation 137 of Keys (KINK) [KINK], is being defined. It, of course, uses 138 Kerberos, and is suitable if and only if a Kerberos infrastructure is 139 available. 141 IKE can use public key certificates or shared secrets. Shared secret 142 authentication is simpler, but doesn't scale as well, since each 143 endpoint must share a unique secret with every peer with which it can 144 communicate, in order to uniquely authenticate these peers. 146 IKE also has public key variants. In most real-world situations, 147 these use locally-issued certificates. That is, the administrator of 148 the system or network concerned will issue certificates to all 149 authorized users; these certificates are useful only for IPsec. 151 It is sometimes possible to use certificates [RFC3280] from an 152 existing public key infrastructure (PKI) with IKE. In practice, this 153 is rare. Furthermore, there not only is no global PKI for the 154 Internet, there probably never will be one. Designing a structure 155 which assumes such a PKI is a mistake. In particular, assuming that 156 an arbitrary node will have an "authentic" certificate, issued by a 157 mutually trusted third party and vouching for that node's identity, 158 is wrong. Again, such a PKI does not and probably will not exist. 159 Public key IKE is generally a good idea, but almost always with 160 locally-issued certificates. 162 Note that public key schemes require a substantial amount of 163 computation. Protocol designers should consider whether or not such 164 computations are feasible on devices of interest to their clientele. 165 Using certificates roughly doubles the number of large 166 exponentiations that must be performed, compared with shared secret 167 versions of IKE. 169 Today, even low-powered devices can generally perform enough 170 computation to set up a limited number of security associations; 171 concentration points, such as firewalls or VoIP servers, may require 172 hardware assists, especially if many peers are expected to create 173 security associations at about the same time. 175 3.4. Applications Program Interface (API) 177 It is, in some sense, a misnomer to speak of the API as a part of 178 IPsec, since that piece is missing on many systems. To the extent 179 that it does exist, it isn't standardized. The problem is simple: 180 it is difficult or impossible to request IPsec protection, or to tell 181 if was used for given inbound packets or connections. 183 There is an additional problem: applications generally are not built 184 directly on IP or IPsec. Rather, they are layered on top of some 185 transport protocol, which in turn is layered on IP or IPsec. 187 Router- or firewall-based IPsec implementations pose even greater 188 problems, since there is no standardized over-the-wire protocol for 189 communicating this information from outboard encryptors to hosts. 191 4. Availability of IPsec in Target Devices 193 Although IPsec is now widely implemented, and is available for 194 current releases of most host operating systems, it is less available 195 for embedded systems. Few hubs, network address translators, etc., 196 implement it, especially at the low end. It is generally 197 inappropriate to rely on IPsec when many of the endpoints are in this 198 category. 200 Even for host-to-host use, IPsec availability (and experience, and 201 ease of use) has generally been for VPNs. Hosts that support IPsec 202 for VPN use do not always support it on a point-to-point basis, 203 especially via a stable, well-defined API ur user interface. 205 Finally, few implementations support multiple layers of IPsec. If a 206 telecommuter is using IPsec in VPN mode to access an organizational 207 network, he or she may not be able to employ a second level of IPsec 208 to protect an application connection to a host within the 209 organization. (We note that such support is, in fact, mandated by 210 Case 4 of Section 4.5 of [RFC2041]. Nevertheless, it is not widely 211 available.) The likelihood of such deployment scenarios should be 212 taken into account when deciding whether or not to mandate IPsec. 214 5. Endpoints 216 [RFC2401] describes many different forms of endpoint identifier. 217 These include source addresses (both IPv4 and IPv6), host names 218 (possibly as embedded in X.500 certificates), and user IDs (again, 219 possibly as embedded in a certificate). Not all forms of identifier 220 are available on all implementations; in particular, user-granularity 221 identification is not common. This is especially a concern for 222 multi-users systems, where it may not be possible to use different 223 certificates to distinguish between traffic from two different users. 225 Again, we note that the ability to provide fine-grained protection, 226 such as keying each connection separately, and with per-user 227 credentials, was one of the original design goals of IPsec. 228 Nevertheless, only a few platforms support it. Indeed, some 229 implementations do not even support using port numbers when deciding 230 whether or not to apply IPsec protection. 232 6. Selectors and the SPD 234 Section 4.4 of [RFC2401] describes the Security Policy Database (SPD) 235 and "selectors" used to decide what traffic should be protected by 236 IPsec. Choices include source and destination addresses (or address 237 ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port 238 numbers for TCP and UDP. Protocols whose protection requirements 239 cannot be described in such terms are poorer candidates for IPsec in 240 particular, it becomes impossible to apply protection at any finer 241 grain than "destination host". Thus, traffic embedded in an L2TP 242 [RFC2661] session cannot be protected selectively by IPsec above the 243 L2TP layer, because IPsec has no selectors defined that let it peer 244 into the L2TP packet to find the TCP port numbers. Similarly, SCTP 245 [RFC2960] did not exist when [RFC2401] was written; thus, protecting 246 individual SCTP applications on the basis of port number could not be 247 done until a new document was written [RFC3554] that defined new 248 selectors for IPsec, and implementations appeared. 250 The granularity of protection available may have side-effects. If 251 certain traffic between a pair of machines is protected by IPsec, 252 does the implementation permit other traffic to be unprotected, or 253 protected by different policies? Alternatively, if the 254 implementation is such that it is only capable of protecting all 255 traffic or none, does the device have sufficient CPU capacity to 256 encrypt everything? Note that some low-end devices may have limited 257 secure storage capacity for keys, etc. 259 Implementation issues are also a concern here. As before, too many 260 vendors have not implemented the full specifications; too many IPsec 261 implementations are not capable of using port numbers in their 262 selectors. Protection of traffic between two hosts is thus on an all 263 or nothing basis when these non-compliant implementations are 264 employed. 266 7. Broadcast and Multicast 268 Although the designers of IPsec tried to leave room for protection of 269 multicast traffic, a complete design wasn't finished until much 270 later. There is, as yet, no key management for the general case, 271 though MIKEY [MIKEY] will work for peer-to-peer, simple one-to-many, 272 and small group multicast. Worse yet, an important component of 273 over-the-wire IPsec -- replay protection -- was designed even later 274 [2401bis,2402bis,ESPv3], and is thus unavailable in deployed 275 implementations. IPsec is thus inappropriate for such protocols 276 unless and until suitable key management and replay protection 277 mechanisms are available in the target domain. 279 8. Mandating IPsec 281 Despite all of the caveats given above, it may still be appropriate 282 to use IPsec in particular situations. The range of choices make it 283 mandatory to define precisely how IPsec is to be used. Authors of 284 RFCs that rely on IPsec must specify the following: 286 (a) What selectors the initiator of the conversation (the client, 287 in client-server architectures) should use? What addresses, 288 port numbers, etc., are to be used? 290 (b) What IPsec protocol is to be used: AH or ESP? What mode is 291 to be employed: transport mode or tunnel mode? 293 (c) What form of key management is appropriate? 295 (d) What security policy database entry types should be used by 296 the responder (i.e., the server) when deciding whether or not 297 to accept the IPsec connection request? 299 (e) What form of identification should be used? Choices include 300 IP address, DNS name, and X.500 distinguished name. 302 (f) What form of authentication should be used? Choices include 303 pre-shared secrets, certificates, and (for IKEv2) an EAP 304 exchange [RFC2284]. 306 (g) Which of the many variants of IKE must be supported? Main 307 mode? Aggressive mode? 309 (h) Is suitable IPsec support available in likely configurations 310 of the products that would have to employ IPsec? 312 9. Example 314 Suppose that the designers of the Border Gateway Protocl (BGP) 315 [RFC1771] wished to use IPsec for security, rather than the mechanism 316 described in [2385]. Does it meet these criteria? (Note that the 317 deeper security issues raised by BGP are not addressed by IPsec or 318 any other transmission security mechanism. See [Kent00a] and 319 [Kent00b] for more details.) 321 Selectors 322 The issue of selectors is easy. BGP already runs between 323 manully-configured pairs of hosts on TCP port 179. The 324 appropriate selector would be the pair of BGP speakers, for 325 that port only. Note that the router's "loopback address" is 326 almost certainly the address to use. 328 Mode 329 Clearly, transport mode is the proper choice. The information 330 being communicated is generally not confidential, so 331 encryption need not be used. Either AH or ESP can be used; if 332 ESP is used, the sender's IP address would need to be checked 333 against the IP address asserted in the key management 334 exchange. (This check is mandated by [RFC2401].) The RFC 335 author should pick one. 337 Key Management 338 To permit replay detection, an automated key management system 339 should be used, most likely IKE. Again, the RFC author should 340 pick one. 342 Security Policy 343 Connections should be accepted only from the designated peer. 345 Authentication 346 Given the number of BGP-speaking routers used internally by 347 large ISPs, it is likely that shared key mechanisms are 348 inadequate. Consequently, certificate-based IKE must be 349 supported. However, shared secret mode is reasonable on 350 peering links, or (perhaps) on links between ISPs and 351 customers. Whatever scheme is used, it must tie back to a 352 source IP address or AS number in some fashion, since other 353 BGP policies are expressed in these terms. 355 Availability 356 For this scenario, availability is the crucial question. Do 357 likely BGP speakers -- both backbone routers and access 358 routers -- support the profile of IPsec described above? Will 359 use of IPsec, with its attendant expensive cryptographic 360 operations, raise the issue of new denial of service attacks? 361 The working group and the IESG must make these determinations 362 before deciding to use IPsec to protect BGP. 364 10. Security Considerations 366 IPsec provides transmission security and simple access control only. 367 There are many other dimensions to protocol security that are beyond 368 the scope of this memo. Within its scope, the security of any 369 resulting protocol depends heavily on the accuracy of the analysis 370 that resulted in a decision to use IPsec. 372 11. Acknowledgments 374 Ran Atkinson, Barbara Fraser, Paul Hoffman, Stephen Kent, Eric 375 Fleischman, and others have made many useful suggestions. 377 12. References 379 [Bell96] "Problem Areas for the IP Security Protocols", S.M. 380 Bellovin, Proc. Sixth Usenix Security Symposium, 1996, pp. 381 205-214. 383 [Kent00a] "Secure Border Gateway Protocol (Secure-BGP)", S. Kent, C. 384 Lynn, and K. Seo, IEEE Journal on Selected Areas in 385 Communications 18:4, April 2000, pp. 582-592. 387 [Kent00b] "Secure Border Gateway Protocol (S-BGP) -- Real World 388 Performance and Deployment Issues", S. Kent, C. Lynn, J. 389 Mikkelson, and K. Seo, Proc. Network and Distributed System 390 Security Symposium, February 2000. 392 [KINK] "Kerberized Internet Negotiation of Keys (KINK)", M. Thomas 393 and J. Vilhuber, draft-ietf-kink-kink, work in progress, 2003. 395 [RFC1771] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter and T. 397 Li. RFC 1771, March 1995. 399 [RFC2401] "Security Architecture for the Internet Protocol", S. Kent 400 and R. Atkinson, RFC 2401, November 1998. 402 [RFC2402] "IP Authentication Header", S. Kent and R. Atkinson, RFC 403 2402, November 1998. 405 [RFC2406] "IP Encapsulating Security Payload (ESP)", S. Kent and R. 406 Atkinson, RFC 2406, November 1998. 408 [RFC2409] "The Internet Key Exchange (IKE)", D. Harkins and D. 409 Carrel. RFC 2409, November 1998. 411 [RFC2661] "Layer Two Tunneling Protocol L2TP", W. Townsley, A. 412 Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. RFC 2661, 413 August 1999. 415 [RFC2960] "Stream Control Transmission Protocol", R. Stewart, Q. Xie, 416 K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, 417 M. Kalla, L. Zhang, and V. Paxson. RFC 2960, October 2000. 419 [RFC3552] "Guidelines for Writing RFC Text on Security 420 Considerations", E. Rescorla and B. Korver, 2003. 422 13. Author Information 423 Steven M. Bellovin 424 AT&T Labs Research 425 Shannon Laboratory 426 180 Park Avenue 427 Florham Park, NJ 07932 428 Phone: +1 973-360-8656 429 email: bellovin@acm.org 431 IPR Disclosure Acknowledgement 433 By submitting this Internet-Draft, I certify that any applicable 434 patent or other IPR claims of which I am aware have been disclosed, 435 and any of which I become aware will be disclosed, in accordance with 436 RFC 3668. 438 Copyright Notice 440 Copyright (C) The Internet Society (2004). This document is subject 441 to the rights, licenses and restrictions contained in BCP 78, and 442 except as set forth therein, the authors retain all their rights. 444 Disclaimer 446 This document and the information contained herein are provided on an 447 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 448 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 449 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 450 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 451 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.