idnits 2.17.1 draft-dondeti-useipsec-430x-00.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 505. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 18, 2006) is 6400 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 441, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 444, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (ref. '2') (Obsoleted by RFC 5996) == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-05 -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '8') (Obsoleted by RFC 6407) == Outdated reference: A later version (-09) exists of draft-housley-aaa-key-mgmt-04 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-14 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Dondeti, Ed. 3 Internet-Draft V. Narayanan, Ed. 4 Intended status: Best Current QUALCOMM, Inc. 5 Practice October 18, 2006 6 Expires: April 21, 2007 8 Guidelines for using IPsec and IKEv2 9 draft-dondeti-useipsec-430x-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 21, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 IPsec encapsulation can be used to provide a secure channel between 43 two entities, to enforce controlled access to a network, or to 44 provide any combination of integrity protection, confidentiality, 45 replay protection, and traffic flow confidentiality of data being 46 transmitted between two or more endpoints over untrusted transmission 47 media or networks. Whereas various assortments of the protections 48 are possible to provide, it is not always safe to use some of the 49 combinations. Next, IPsec SAs are established either manually or 50 using a key management protocol such as IKEv2 with entity 51 authentication verified locally or with the assistance of a third 52 party. This document specifies when and how to use IPsec and IKEv2 53 and what combinations of protections afforded by those protocols are 54 safe and when. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Why is this document needed? . . . . . . . . . . . . . . . . . 3 61 3.1. On the types of use cases of IPsec . . . . . . . . . . . . 4 62 4. What IPsec provides . . . . . . . . . . . . . . . . . . . . . 5 63 5. Why use IPsec and where to use IPsec? . . . . . . . . . . . . 6 64 6. How to use IPsec to establish secure channel(s) between 65 network entities? . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Identify the Requirements and Constraints . . . . . . . . 6 67 6.1.1. Requirements and Constraints on the use of IPsec 68 encapsulation . . . . . . . . . . . . . . . . . . . . 6 69 6.1.2. Constraints and Requirements associated with 70 Selection of Key Management Protocol . . . . . . . . . 8 71 7. Key management for IPsec:IKEv2 . . . . . . . . . . . . . . . . 9 72 7.1. IKEv2 usage guidelines . . . . . . . . . . . . . . . . . . 9 73 7.2. Guidelines for using Traffic Selectors . . . . . . . . . . 9 74 7.3. IKEv2 support for network access control: IKEv2-EAP . . . 9 75 8. Group Key management for IPsec . . . . . . . . . . . . . . . . 9 76 9. IPsec and mobility . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. IKEv2 support for mobility . . . . . . . . . . . . . . . . 9 78 9.2. MOBIKE applicability . . . . . . . . . . . . . . . . . . . 9 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 Intellectual Property and Copyright Statements . . . . . . . . . . 12 88 1. Introduction 90 It is often a good idea to use an existing security encapsulation 91 protocol rather than inventing a new one every time a protocol needs 92 security guarantees such as integrity protection, message 93 authentication, confidentiality, replay protection or traffic flow 94 confidentiality of data in transit. IPsec is a natural candidate in 95 many instances. However, it is not sufficient to simply say "use 96 IPsec." For interoperability and effective use it is necessary to 97 specify in detail what aspects of IPsec are used. 99 IPsec is the IP layer security encapsulation protocol used to create 100 a secure channel between any combination of end hosts and security 101 gateways, or to enforce network access control, or to provide any 102 combination of integrity protection, confidentiality, replay 103 protection, and traffic flow confidentiality of data being 104 transmitted between two or more endpoints over untrusted transmission 105 media or networks. While it is possible to enable any combination of 106 the protections available, it is not always safe to use some of the 107 combinations. For instance, encryption without integrity protection 108 may not be safe in most usage scenarios, and especially when counter 109 mode encryption is used. 111 This document has three overall goals: The first is to explain 112 briefly what IPsec does and the second to make the case for IPsec as 113 the protocol of choice to establish a secure channel or to enforce 114 access control, and finally explain that just saying "use IPsec" is 115 not sufficient and describe what needs to be specified to correctly 116 use IPsec. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [1]. 124 This document reuses the terminology of the IPsec and IKEv2 125 specifications. 127 3. Why is this document needed? 129 Protocols defined in the IETF and in other standards bodies often 130 need a security encapsulation protocol or an access control 131 mechanism. In those cases, it is plausible to design a new protocol, 132 which is a rather difficult thing to do. It is quite easy to get 133 things wrong in designing a security protocol: simple oversights may 134 result in the entire process being useless. The other option is to 135 reuse an existing security protocol, IPsec being one of them. 136 However, simply stating that use IPsec is in most cases insufficient 137 for interoperability and more importantly for effective use. Once 138 again, it is plausible that careless employment of IPsec may result 139 in unneeded processing or overhead or worse in the whole process 140 being ineffective. 142 To that end, a BCP [6] was written to provide guidance on how to use 143 IPsecv2. Since then, the IPsecv3 suite of specifications were 144 written to make it easier to use IPsec. Let us consider the two 145 primary types of employment of IPsec and motivate the need for this 146 document. 148 3.1. On the types of use cases of IPsec 150 For instance, in many networks, including the Internet itself, the 151 transmission path between two infrastructure entities cannot be 152 trusted: the data may be sensitive and needs to be protected from 153 eavesdroppers or from packet modification or replay attacks. In 154 those instances, network architects or protocol designers simply 155 state that there needs to be an IPsec secure channel between those 156 entities. In most cases, that is insufficient. It is often the case 157 that there are several types of sensitive data to be sent between the 158 entities: some need confidentiality and integrity protection, others 159 may need integrity protection alone etc. Despite assumptions to the 160 contrary, with key management protocols such as IKEv2, it is 161 plausible to establish and maintain multiple secure channels or 162 tunnels quite easily. ESPv3, AHv3 and IKEv2 specifications were 163 developed primarily to bring IPsec more inline with the security 164 requirements of the various protocols and to make it easy to specify 165 which traffic needs what kind of protection via the key management 166 protocol. 168 Next, access control enforcement is another application of IPsec. 169 There are at least two types of access control for which IPsec is 170 best suited and commonly used. The first is "remote" access to 171 enterprise networks. The second is controlled access to a service 172 provider's network. In this model, there is a client attempting to 173 access the network and a server authenticating the client and 174 enforcing access control to the enterprise or the service provider's 175 network. The extensible authentication protocol (EAP) [7] allows 176 most flexibility for client authentication. The IKEv2 [2] protocol 177 enables the use of IPsec for access control with EAP for client 178 authentication. The catch here is that access control is only 179 effective with a proper security policy database. The need for 180 security policy enforcement is identified in other specifications 181 employing controlled access to networks: the IEEE 802.1X 182 specification identifies "port control" as an essential part of 183 enforcing access control. In brief, port control and security policy 184 databases specify which traffic, e.g., EAP traffic in case of 802.1X, 185 and key management traffic in case of IPsec, can bypass security 186 encapsulation -- which provides a guarantee that the entity that 187 established the SA is in fact sending the traffic -- requirements. 189 IPsec is also used for secure communication between end hosts. 190 Transport mode is typically used for either secure unicast or 191 multicast communication. IPsec encapsulation is also used for access 192 control enforcement of data being broadcast or multicast. 194 In the rest of this document, we explain what IPsec does, make a case 195 for using IPsec as a secure channel or an access control enforcement 196 protocol and finally provide guidance on how to use IPsec. 198 4. What IPsec provides 200 IPsec SAs may be established manually or by way of a key management 201 protocol: ESPv3 [3] or AHv3 [4] unicast SAs are established using 202 IKEv2 [2] and Group SAs are established using GDOI [8] or GSAKMP. 203 Manual keying has some limitations and must be employed with care. 204 However, it may be better to use manual keyed IPsec SAs than 205 inventing a new security encapsulation protocol. 207 Two different types of IPsec encapsulations have been specified in 208 [5]: with the first, the Encapsulating Security Payload (ESP), a 209 number of security properties can be provided, including integrity 210 protection, confidentiality, replay protection, and traffic flow 211 confidentiality. The second type of encapsulation, Authentication 212 Header (AH), provides integrity and replay protection, and unlike ESP 213 affords integrity protection of IP headers. 215 IPsec can be used in transport mode or a tunnel mode: transport mode 216 is employed when two endpoints require ESP or AH protection for next 217 layer protocol headers and the payload. Tunnel mode is employed 218 between a host and a security gateway or between security gateways by 219 encapsulating the entire IP packet and introducing an IP header for 220 routing the packet to the appropriate IPsec entity on route to the 221 final destination. 223 IPsec, especially when used to enforce access control, is associated 224 with a security policy database (SPD) that dictates the types of 225 traffic that needs what kind of IPsec protection and those that do 226 not need any protection. When specifications require the use of 227 IPsec, it is often useful to provide guidelines on SPD contents as 228 well for proper use of the protections afforded by IPsec. 230 5. Why use IPsec and where to use IPsec? 232 6. How to use IPsec to establish secure channel(s) between network 233 entities? 235 IPsec may be used as the security encapsulation protocol between two 236 or more network infrastructure entities in many cases, including 238 o to protect routing protocol messages, for instance, OSPF, BGP 240 o to protect AAA messages between a AAA client and a server, 241 typically in a hop-by-hop fashion 243 o to protect context transfer messages between two edge entities in 244 a service provider's network 246 o to provide a blanket secure channel between two network entities. 248 o more ... 250 6.1. Identify the Requirements and Constraints 252 The first step of course is to take stock of the constraints and the 253 requirements. The following questionnaire might help; note however 254 that each situation is unique and may have requirements and 255 constraints that may not be listed here. 257 6.1.1. Requirements and Constraints on the use of IPsec encapsulation 259 First we examine the requirements on the security encapsulation 260 itself. 262 o Type of protection -- 264 * Specifically, is confidentiality a requirement for all traffic? 266 * Would integrity protection alone be sufficient? Note that it 267 is plausible to use ESP with NULL encryption, effectively 268 providing integrity protection alone. 270 * Does the outermost IP header need integrity protection? Note 271 that AH mode of protection of headers implies that modification 272 of headers en route is prohibited. 274 * Is replay protection required? Note that IPsec specifications 275 mandate the inclusion of a sequence number in the header. 276 Turning off sequence number verification at the receiver only 277 saves the overhead of maintenance of a replay window and some 278 associated packet processing. However, it is plausible that 279 replay protection is provided through other means, breaks other 280 aspects of higher layer protocols or simply not needed. 282 + If replay protection is being employed, is an extended 283 sequence number (ESN) required? ESN is typically needed for 284 high data rate communication to avoid frequent rekeying. 285 IPsecv3 assumes automatic use of ESN, unless it is 286 explicitly turned off via a key management protocol. 288 * Is traffic flow confidentiality a requirement? When using ESP 289 with non-NULL encryption, IPsec allows the sender to provide 290 traffic flow confidentiality (TFC). TFC protects from entities 291 observing the traffic over the air or a wire from making 292 intelligent assessments about the contents of the traffic, 293 based on the length of IP packets. TFC padding is in addition 294 to the encryption related padding, and must be signaled. 296 o Granularity of protection or number of SAs between the same 297 entities -- 299 * Does all traffic between the network entities need protection? 300 If so, is the protection required the same in all cases? 302 o Origin and destination of traffic being protection or selection of 303 tunnel vs transport mode -- 305 * Is the traffic originating and destined for the IPsec 306 endpoints? This might imply the use of transport mode IPsec. 308 * Is the traffic originating or destined for entities beyond/ 309 behind the IPsec endpoints? This generally implies the use of 310 tunnel mode IPsec. However, if traffic were already in-IP 311 tunneled it may be plausible to use transport mode IPsec. Care 312 must be taken however in employing transport in this way as the 313 SPD capabilities may be limited as described in Page 13 of [5] 315 o Unicast or Group SAs -- 317 o Security Policy Database (SPD) and associated enforcement -- 319 The next step is to identify any constraints in specifying the 320 details of the security encapsulation needed. 322 o Is there a constraint that requires the design to turn off 323 integrity protection? Note that if confidentiality is needed, 324 integrity protection is automatically assumed to be needed in most 325 cases. The following process may help analyze whether an 326 exception of turning off integrity protection is even necessary: 328 * Is overhead the reason to not use integrity protection? 330 * Would the use of Counter mode encryption help alleviate the 331 per-packet overhead concerns? With CBC mode encryption, an IV 332 of length 16 octets is required. With counter mode, a counter 333 of length of 4 octets needs to be included in each packet. The 334 counter serves as part of the per-packet IV as well as the 335 sequence number for replay protection. 337 * Was MAC truncation considered? Use of an 8-octet MAC is well 338 within the recommendation of AES-CMAC specification. An even 339 shorter MAC, as short as 4 octets is better than no integrity 340 protection at all. 342 o 344 6.1.2. Constraints and Requirements associated with Selection of Key 345 Management Protocol 347 The second part of the exercise is to identify the requirements and 348 constraints associated with key management. 350 o Key management protocol -- Is a key management protocol required? 351 If so, which one? 353 * The choice of key management protocol depends very much on 354 whether unicast or group SAs are to be established. For 355 unicast SA establishment, IKEv2 is the only key management 356 protocol specified and for group IPsecv3 SA establishment, GKDP 357 is the only key management protocol specified at the time of 358 this writing. 360 o Entity authentication -- If a key management protocol is used, the 361 first step is to figure out how the IPsec endpoints are 362 authenticated to each other. In the use case under discussion, 363 the two endpoints are infrastructure entities: in this case 364 certificate based authentication or PSK-based authentication are 365 two viable choices. Requirements analysis would need to determine 366 if one of the options is better than the other. 368 o Security policy database reconciliation or Traffic selector 369 negotiation -- 371 o 372 The next step as in case of investigating the use of the security 373 encapsulation is to investigate any constraints. 375 o Manual keying is definitely an option to establish IPsecv3 SAs. 376 However manual keying has several inherent limitations. It is 377 important to investigate whether the constraints forcing the use 378 of manual keying are weighed against the following limitations of 379 manual keying: 381 * Rekeying is also manual and if manually keyed IPsec SAs are 382 used to protect high data rate flows, key reuse might occur. 383 Note that key reuse may result in compromising the protections 384 afforded by IPsec. 386 * Algorithm agility is not supported. 388 * Replay protection is not supported. 390 7. Key management for IPsec:IKEv2 392 7.1. IKEv2 usage guidelines 394 7.2. Guidelines for using Traffic Selectors 396 7.3. IKEv2 support for network access control: IKEv2-EAP 398 8. Group Key management for IPsec 400 9. IPsec and mobility 402 9.1. IKEv2 support for mobility 404 9.2. MOBIKE applicability 406 10. Security Considerations 408 11. IANA Considerations 410 12. Acknowledgments 412 13. References 413 13.1. Normative References 415 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 416 Levels", BCP 14, RFC 2119, March 1997. 418 [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 419 December 2005. 421 [3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 422 December 2005. 424 [4] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 426 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 427 Protocol", RFC 4301, December 2005. 429 13.2. Informative References 431 [6] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 432 draft-bellovin-useipsec-05 (work in progress), August 2006. 434 [7] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 435 Levkowetz, "Extensible Authentication Protocol (EAP)", 436 RFC 3748, June 2004. 438 [8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 439 Domain of Interpretation", RFC 3547, July 2003. 441 [9] Housley, R. and B. Aboba, "Guidance for AAA Key Management", 442 draft-housley-aaa-key-mgmt-04 (work in progress), October 2006. 444 [10] Aboba, B., "Extensible Authentication Protocol (EAP) Key 445 Management Framework", draft-ietf-eap-keying-14 (work in 446 progress), June 2006. 448 Authors' Addresses 450 Lakshminath Dondeti (editor) 451 QUALCOMM, Inc. 452 5775 Morehouse Dr 453 San Diego, CA 454 USA 456 Phone: +1 858-845-1267 457 Email: ldondeti@qualcomm.com 458 Vidya Narayanan (editor) 459 QUALCOMM, Inc. 460 5775 Morehouse Dr 461 San Diego, CA 462 USA 464 Phone: +1 858-845-2483 465 Email: vidyan@qualcomm.com 467 Full Copyright Statement 469 Copyright (C) The Internet Society (2006). 471 This document is subject to the rights, licenses and restrictions 472 contained in BCP 78, and except as set forth therein, the authors 473 retain all their rights. 475 This document and the information contained herein are provided on an 476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 480 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 483 Intellectual Property 485 The IETF takes no position regarding the validity or scope of any 486 Intellectual Property Rights or other rights that might be claimed to 487 pertain to the implementation or use of the technology described in 488 this document or the extent to which any license under such rights 489 might or might not be available; nor does it represent that it has 490 made any independent effort to identify any such rights. Information 491 on the procedures with respect to rights in RFC documents can be 492 found in BCP 78 and BCP 79. 494 Copies of IPR disclosures made to the IETF Secretariat and any 495 assurances of licenses to be made available, or the result of an 496 attempt made to obtain a general license or permission for the use of 497 such proprietary rights by implementers or users of this 498 specification can be obtained from the IETF on-line IPR repository at 499 http://www.ietf.org/ipr. 501 The IETF invites any interested party to bring to its attention any 502 copyrights, patents or patent applications, or other proprietary 503 rights that may cover technology that may be required to implement 504 this standard. Please address the information to the IETF at 505 ietf-ipr@ietf.org. 507 Acknowledgment 509 Funding for the RFC Editor function is provided by the IETF 510 Administrative Support Activity (IASA).