idnits 2.17.1 draft-ietf-ipsec-ikev2-tutorial-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (February 2003) is 7740 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: 'Bra96' is mentioned on line 14, but not defined == Unused Reference: 'HC98' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'HKP99' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'MSST98' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'Orm96' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 684, but no explicit reference was found in the text -- No information found for draft-ietf-ipsec-ike-crack - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CRACK' ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) -- No information found for draft-ietf-ipsec-ike-crack - is the name correct? -- Duplicate reference: draft-ietf-ipsec-ike-crack, mentioned in 'HKP99', was also mentioned in 'CRACK'. -- Possible downref: Normative reference to a draft: ref. 'HKP99' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-06 == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-jfk-03 -- Possible downref: Normative reference to a draft: ref. 'JFK' == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-01 ** Obsolete normative reference: RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'Orm96') -- Possible downref: Non-RFC (?) normative reference: ref. 'PK01' ** Obsolete normative reference: RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Possible downref: Normative reference to a draft: ref. 'XAUTH' Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group INTERNET-DRAFT 3 Radia Perlman 5 draft-ietf-ipsec-ikev2-tutorial-01.txt 6 February 2003 8 Understanding IKEv2: Tutorial, and rationale for decisions 9 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 [Bra96]. Internet Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and working groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 The main job of a protocol specification is to document how the 33 protocol works. It is sometimes difficult to learn how a protocol 34 works from such a document, because there are so many details, and 35 the necessary formalism for accuracy makes a specification long and 36 difficult to read. What also is usually lost in the process of 37 creating an RFC for a protocol is documentation of the tradeoffs that 38 were considered when making controversial choices. Sometimes it is 39 possible to find this information on the email archives, but that is 40 a daunting task. This document is intended to work both as a 41 tutorial to understanding IKEv2, and a summary of the controversial 42 issues, with the reasoning on all sides of each issue. If any 43 differences in details exist between this document and the IKEv2 44 specification, the IKEv2 specification is authoritative. 46 1. Introduction 48 IKE (Internet Key Exchange) is the protocol which performs mutual 49 authentication and establishes security associations (SAs) for IPsec. 50 The base protocol of the first version of IKE was documented in RFCs 51 2407, 2408, 2409. Also, IKEv1 implementations incorporated additional 52 functionality including features for NAT traversal, legacy 53 authentication, and remote address acquisition, which were not 54 documented in the base documents. The goal of the IKEv2 specification 55 is to specify all that functionality in a single document, as well as 56 simplify and improve the protocol, and fix various problems in IKEv1 57 that had been found through deployment or analysis. It was also a 58 goal of IKEv2 to understand IKEv1 and not to make gratuitous changes. 59 The intention was to make it as easy as possible for IKEv1 60 implementations to be modified for IKEv2, and to benefit from the 61 experience gained from deployment of IKEv1. 63 IKEv2 preserves most of the features of the original IKE, including 64 identity hiding, perfect forward secrecy, two phases, and 65 cryptographic negotiation, while greatly redesigning the protocol for 66 efficiency, security, robustness, and flexibility. This document is 67 intended to be a readable description of all the concepts, rather 68 than being a complete specification of all the details. It also 69 explains reasoning on all sides of controversial issues. 71 For simplicity of description, we refer to the two parties in an IKE 72 exchange as "Alice" and "Bob", where Alice is the initiator of the 73 exchange. These names allow us to use the pronouns "she" and "he". 75 2.0 Overview of IKEv2 77 IKEv2 has an initial handshake in which Alice and Bob negotiate 78 cryptographic algorithms, mutually authenticate, and establish a 79 session key, creating an IKE-SA. Additionally, a first IPsec SA is 80 established during the initial IKE-SA creation. 82 All IKEv2 messages are request/response pairs. It is the 83 responsibility of the side sending the request to retransmit if it 84 does not receive a timely response. 86 The initial exchange usually consists of two request/response pairs. 87 (Additional request/response pairs might be needed for DOS 88 protection, if Alice attempts to use a Diffie-Hellman group Bob does 89 not support, or if Bob will authenticate Alice through some legacy 90 mechanism such as a token card, OTP, or name/password. 92 The first pair negotiates cryptographic algorithms and does a 93 Diffie-Hellman exchange. The second pair is encrypted and integrity 94 protected with keys based on the Diffie-Hellman exchange. In this 95 exchange Alice and Bob divulge their identities and prove it using an 96 integrity check generated based on the secret associated with their 97 identity (private key or shared secret key) and the contents of the 98 first pair of messages in the exchange. Also, the first IPsec SA is 99 created. 101 After the initial handshake, additional requests can be initiated by 102 either Alice or Bob, and consist of either informational messages or 103 requests to establish another child-SA. Informational messages 104 include such things as null messages for detecting peer aliveness, 105 and deletion of SAs. 107 The exchange to establish a child-SA consists of an optional Diffie- 108 Hellman exchange (if perfect forward secrecy for that child-SA is 109 desired), nonces (so that a unique key for that child-SA will be 110 established), and negotiation of traffic selector values which 111 indicate what addresses, ports, and protocol types are to be 112 transmitted over that child-SA. 114 3.0 Two Phases 116 In IKEv2 terminology, the first phase consists of the (usually 4) 117 messages that create the IKE-SA and the first associated IPsec SA 118 (known as a "child-SA"). Once the IKE-SA is created, it can be used 119 for sending authenticated notification messages, reliable dead-peer 120 detection, and inexpensive creation of additional child-SAs. 122 It was argued in [PK01] and [JFK] that having two phases was 123 unnecessary and added complexity, and additional SAs between the same 124 pair of nodes could be accomplished by creating additional IKE-SAs. 125 However, child-SA creation is less expensive, and experience with 126 IKEv1 showed the two phases to be useful, since there were scenarios 127 in IPsec deployments in which a sufficient number of child-SAs 128 between the same pair of nodes was desirable that the extra spec 129 complexity was worth it for the efficiency of child-SA creation. 131 Why do people find it useful to create multiple IPsec SAs between the 132 same pair of hosts? 134 * avoiding multiplexing multiple conversations over the same SA. 135 Several years ago Bellovin pointed out that if encryption is done 136 without integrity protection, there is a splicing attack whereby a 137 process involved in one flow can, through an active attack, cause 138 traffic for a different flow to be decrypted and delivered to the 139 process in the first flow. Of course, nobody should be doing 140 encryption without integrity protection. It is likely there is no 141 similar flaw if integrity is used. But in a case where a router is 142 delivering traffic on behalf of multiple customers, and the data is 143 going to another router in order to access other machines of those 144 customers, the customers feel safer knowing that their traffic is 145 being delivered with a different SA (and different key) than traffic 146 between nodes belonging to other customers. 148 * different security properties of different flows. According to 149 policy, some traffic might be only integrity-protected. Other traffic 150 might be encrypted with a short key. Other traffic might be encrypted 151 with a long key. Other traffic might use a vanity crypto algorithm 152 designed by one of your customers, and it will make them happy if you 153 use their algorithm for their traffic. In [PK01] it was argued that 154 all traffic might as well be protected according to the needs of the 155 traffic that requires the strongest protection. The counter-argument 156 is that there might be performance reasons or legal reasons (or 157 vanity reasons) why this is undesirable. 159 * different SAs for different classes of service. There might be 160 different classes of service, such as priority classes, that might 161 cause traffic for one class to travel much more slowly to the SA 162 destination than other types of traffic to that SA destination. To 163 avoid replay attacks, the recipient keeps track of which sequence 164 numbers have been received. Typically, it only keeps track of the 165 highest n sequence numbers, up to the highest sequence number it has 166 seen on this SA, and data with sequence numbers lower than that are 167 discarded. If different classes of service have widely different 168 delivery times, the recipient would have to keep track of a larger, 169 and possibly unbounded, set of sequence numbers. 171 In JFK it was envisioned that IKE would be used solely for setting up 172 an SA, and there would be no IKE messages other than the initial 173 handshake. In IKEv1, the second phase was used either for setting up 174 an additional SA or for sending informational messages. Once the WG 175 consensus was to keep the two phase structure, both uses of the 176 second phase; creation of new child-SAs, and the ability to send 177 reliable and authenticated informational messages were deemed 178 important. The ability to send informational messages increases 179 IKEv2's robustness by detecting error conditions, allowing rekeying, 180 and detecting a dead peer, as well as being a potentially valuable 181 feature for future functionality. 183 Note that the ability to create additional child-SA's is optional in 184 IKEv2, so it is legal for an implementation to have the behavior 185 envisioned in the JFK spec. 187 4.0 Perfect Forward Secrecy/Computation Tradeoff 189 The IKEv2 handshake includes nonces in addition to Diffie-Hellman 190 values. If each side chose a unique private Diffie-Hellman number for 191 each exchange, there would be no need for nonces. It is reasonable 192 for an implementation to choose less than perfect forward secrecy by 193 reusing the Diffie-Hellman number (avoiding expensive 194 exponentiations), since the nonces, which must be unique for each 195 exchange, will ensure unique keys for each IKE-SA. Likewise, child- 196 SAs established through an IKE-SA can choose perfect forward secrecy 197 and generate and send Diffie-Hellman values, or simply use nonces to 198 establish unique keys. 200 Note that even if Bob (or Alice) reuses his Diffie-Hellman value 201 (call it "B"), there will still be perfect forward secrecy so long as 202 Bob forgets B as soon as any SA based on B is closed. If Bob 203 remembers B for, say, an hour longer than that, then perfect forward 204 secrecy is only slightly affected, and really not affected in any 205 practical sense. 207 5.0 Colocated Services 209 In some cases Bob might host many different services (e.g., distinct 210 web sites with different identities). All these identities would have 211 the same IP address, but would have different keys and certificates. 212 Having Alice initiate a connection to Bob's IP address does not 213 inform Bob who she wants to communicate with. Therefore, IKEv2 allows 214 Alice to specify an identity for Bob. This feature was given the 215 affectionate name "You Tarzan. Me Jane." by Hugh Daniel. The name is 216 quite appropriate because in the same message in which Alice reveals 217 her identity she requests a specific identity for Bob. 219 6.0 DOS protection 221 Photuris specified a mechanism known as a "stateless cookie", in 222 order to avoid a certain type of DoS attack. The attack involves 223 sending nuisance SA-creation-request packets to a server (Bob) from 224 an unauthorized node with the purpose of exhausting the server's 225 computation or memory resources. Such attacks typically are sent from 226 forged source addresses, both to avoid prosecution and to make it 227 difficult for these packets to be easily filtered. Photuris's cookie 228 design was a way of assuring Bob that the SA-requester could receive 229 at the IP address it claimed to be coming from before Bob devoted 230 significant resources to authenticating the request and creating the 231 SA. 233 A method of implementing stateless cookies is for Bob to have a 234 secret S, that he shares with nobody and changes periodically. When 235 he gets a request from IP address x with no cookie, he sends 236 cookie=h(S,x) to x, but otherwise does nothing with the request. When 237 he gets a request from IP address x with cookie=c, Bob verifies if 238 c=h(S,x) and if so, continues processing. (If Bob has recently 239 changed S's, he might want to see if the cookie verifies with the old 240 S if it fails with the new S). 242 OAKLEY had the stateless cookie be optional. If there was no attack, 243 the protocol would avoid the extra round trip for the cookie 244 exchange. If Bob was getting low on resources, perhaps because of an 245 attack, Bob could refuse requests that didn't contain a cookie. 246 IKEv2 uses the OAKLEY idea of having the cookie exchange be optional. 248 This aspect of IKEv2 was the subject of some debate in the WG. There 249 were two alternatives for providing this feature. The chosen 250 alternative was the OAKLEY-style optional extra round trip. It was 251 possible, (as specified in JFK, suggested in [PK01], and specified in 252 the next version of IKEv2 after the JFK and IKEv2 author teams 253 decided to work together on a single document), to provide this 254 feature without adding an additional round trip. The arguments for 255 avoiding the extra round trip were: 257 * it saves a round trip 259 * it avoids forcing Bob to make a decision about whether he is under 260 attack 262 The WG decided in favor of the additional round trip for this case 263 because: 265 * it made the protocol much simpler, since after the initial pre- 266 exchange, Bob is not stateless. As a result of the protocol being 267 simpler, it was likely that future changes would not break the 268 handshake, and that future functionality could be incorporated 269 without a redesign. 271 * it makes message 3 shorter, since the mechanism by which Bob can be 272 stateless is to have Alice repeat everything Bob would have needed to 273 remember in message 3. 275 * This design makes it easy to defend against a "fragmentation 276 attack", a DOS attack on an IKE exchange that was pointed out by 277 Charlie Kaufman that could enable an attacker to prevent IKE 278 exchanges from completing. Since message 3 in an IKE exchange tends 279 to be long (it includes certificates), and IKE runs over UDP, it is 280 likely that it will need to be fragmented. With the variant in which 281 Bob is stateless until verifying message 3, (and it is message 3 in 282 which Alice sends the cookie), an attacker could send fragments, 283 exhausting Bob's reassembly resources, so that Bob's IKE would never 284 get to see and verify the cookie. With the extra two messages for 285 cookie exchange, all messages are sufficiently short so that 286 reassembly would not be required, and a fragmentation attack cannot 287 prevent Bob from verifying Alice's cookie. 289 Once Bob has verified Alice's cookie, it is a fairly easy 290 implementation trick to ensure the rest of the IKE exchange 291 completes, even in the face of a fragmentation attack, by providing a 292 side-channel from IKE to the reassembly code, whereby Bob can inform 293 the reassembly code of preferred IP addresses (those that have 294 returned a valid cookie). 296 7.0 Cryptographic Negotiation 298 In IKEv1, cryptographic negotiation was "a la carte", meaning that 299 each algorithm (encryption, integrity protection/prf 300 (prf=pseudorandom function), Diffie-Hellman group), was independently 301 negotiated. Aside from being complex to understand, it also created 302 an exponential expansion, since if there were k of one type of 303 algorithm that could interwork with j of another, there had to be k*j 304 seperate proposals. In the original IKEv2 design, the a la carte 305 concept was kept, but the SA payload was simplified somewhat. Also, 306 the exponential explosion of proposals was avoided by allowing sets 307 of algorithms that could interwork together to be presented as a 308 single proposal, and Bob could narrow the choices down to any one 309 from the set. JFK, in contrast, had no negotiation of cryptographic 310 algorithms, which was even simpler, but made it difficult to migrate 311 to different algorithms in the future. 313 The IKEv2 and JFK authors together agreed that a compromise would be 314 suites, as was done in SSL. With a suite, all parameters are encoded 315 into a single suite number, and negotiation consists of offering one 316 or more suites and having the other side choose. It was assumed this 317 would be a noncontroversial decision, but unfortunately it turned out 318 to be controversial. The arguments in favor of suites are: 320 * it is simpler and more compact to encode 322 The arguments in favor of a la carte are: 324 * it is more flexible 326 * there is the fear that there will be an exponential number of 327 suites defined 329 * it is a gratuitous change from IKEv1 that made a lot of unnecessary 330 work for implementations. Suites might have been OK if starting from 331 scratch, but a la carte was easier for migrating from an IKEv1 code 332 base. 334 Although there was sympathy with the a la carte supporters, a 335 decision had to be made, and based on a straw poll at a WG meeting, 336 the decision was to use suites. 338 8.0 Acquiring an IP address 340 When an endnode dials into a firewall, it is often the case that the 341 endnode needs to be given an IP address. Even if the endnode has an 342 IP address for where it is currently residing in the Internet, it may 343 need an address specific for the network inside the firewall, since 344 with its IPsec tunnel, the endnode will now be logically inside the 345 firewall. There were two proposed methods of doing this: 347 * MODECFG, which involves a field in the IKE exchange in which Bob 348 tells Alice an IP address, and 350 * DHCP-relay, which involves running DHCP over IKE or over an ESP 351 connection set up specifically for this purpose. 353 The appeal of MODECFG is that it is very simple, and minimizes the 354 number of messages and crypto operations in getting an IPsec session 355 set up. The appeal of DHCP-relay is that it provides all of the 356 flexibility and power of DHCP (including extensions that might be 357 defined in the future) and does so in a way that appears to make it 358 independent of the IKE specification. One thing that can be done with 359 DHCP-relay is end-to-end authentication between the client and the 360 DHCP server, for instance. 362 The use of MODECFG does not preclude the use of tunnelled DHCP for 363 uses other than acquiring leases on IP addresses, and if there is 364 functionality that can only be done using DHCP-relay, this may be 365 done. The worry was that both MODECFG and DHCP-relay might be needed, 366 and that even though DHCP-relay was more complex than MODECFG, if 367 doing MODECFG meant implementations had to support both, doing DHCP- 368 relay instead of MODECFG would mean less implementation effort. 369 However, the decision was that for now, since MODECFG was simpler, 370 higher performance, fully specified, and gave all currently-needed 371 functionality, IKEv2 would assign addresses using MODECFG. 373 9.0 NAT Traversal 375 People love to hate NAT (Network Address Translation) gateways, but 376 they are a fact of life in the Internet. NAT-Traversal [KSH01] 377 designed a mechanism that was deployed in IKEv1, and IKEv2 copied the 378 design. The NAT-Traversal design accommodated existing NATs as much 379 as possible (without sacrificing security or significantly impacting 380 performance). 382 NATs were originally invented primarily because of the shortage of 383 IPv4 addresses, though there are other rationales. IP nodes that are 384 "behind" a NAT have IP addresses that are not globally unique, but 385 rather are assigned from some space that is unique within the network 386 behind the NAT but which are likely to be reused by nodes behind 387 other NATs. Some people consider the fact that the nodes in their 388 network cannot be directly addressed from outside a security feature. 389 And it even allows a network using some addressing scheme different 390 from IPv4 to connect to the Internet. 392 9.1 The games NATs play 394 Generally, nodes behind NATs can communicate with other nodes behind 395 the same NAT and with nodes with globally unique addresses, but not 396 with nodes behind other NATs. When a node behind a NAT makes a 397 connection to a node on the real Internet, the NAT gateway assigns 398 the inner node a global IP address (which the Internet will route to 399 the NAT box), keeps the mapping for the duration of the conversation 400 (where "duration" has to be heuristically determined by the NAT box), 401 and modifies the IP addresses in the header appropriately. For 402 outgoing packets, the NAT box modifies the source address. For 403 incoming packets, the NAT box modifies the destination address to be 404 the address of the node on the internal network. 406 If the NAT box does not have a sufficiently large pool of global IP 407 addresses to hand out a unique one to each node inside its net that 408 is communicating outside, then NAT boxes translate based on UDP or 409 TCP ports. This is known as a NAPT box. 411 NAPT boxes are foiled by ESP, because ESP encrypts the layer 4 412 header. Some NAPT boxes attempted to make ESP work by doing the 413 following (assume the NAPT box has only one globally unique address, 414 "C"): 416 * when it sees an ESP packet from inner node IP address A to outer 417 node IP address B, the only extra information is the SPI=x. So the 418 NAPT box rewrites the source address A to C, and keeps track of the 419 fact that an ESP packet came from A recently, and there is no current 420 mapping for an incoming SPI corresponding to x. 422 * when the NAPT sees an ESP packet from B to C, with an SPI=y that 423 the NAPT has no mapping for, it assumes B is really trying to respond 424 to A, and makes a mapping that (C,y)=A. 426 An additional problem with NATs and IKEv1 is that IKEv1 specified 427 that IKE messages must be sent to port 500, and sent from port 500. 428 If IKEv1 had specified that you initiate by sending to 500, but 429 respond to whatever port you received an IKE packet from, things 430 would have been simpler. But NAPTs, understanding IKE will want both 431 source and destination UDP ports to remain as 500 make a special case 432 for packets on UDP port 500. If the ports are 500, the NAPT does not 433 modify the UDP ports. Instead, the NAPT makes mappings based on the 434 what used to be called the "cookie fields" in the IKEv1 payload (and 435 in IKEv2 are called the SPIs). 437 The way it works is that when the NAPT box sees a packet on port 500, 438 it looks at the SPI pair (ci,cr). If it does not yet have a mapping 439 for that pair, the packet will have to be coming from inside the net, 440 from IP address A, to IP address B. The NAPT box makes a mapping that 441 IKE connection (ci,cr) is for node A. The box does not modify the UDP 442 ports or the IKE SPIs. It merely records the SPI pair for its IP 443 address mapping. Outgoing packets from A to that IKE connection will 444 always get translated as having source address C. But incoming 445 packets to C from that SPI pair will get translated to destination 446 address A. 448 In the beginning of the IKE connection, Bob has not yet chosen a SPI, 449 so the SPI pair will be (ci,0). If two nodes from inside the net 450 initiate IKE connections to Bob simultaneously, and both choose 451 SPI=ci, the NAPT would not be able to differentiate. But since SPIs 452 are 8-bytes long, and recommended to be chosen at random, this is 453 unlikely to happen. 455 9.2 NAT detection 457 NAT-Traversal was designed for enabling IKEv1 to work through NATs 458 without requiring modifications of the NATs, and IKEv2 has pretty 459 much copied the design. The first step is for Alice and Bob to notice 460 that one of them is behind a NAT. In IKEv2 this is done by including 461 two notify payloads in messages 1 and 2, called NAT-DETECTION- 462 SOURCE-IP and NAT-DETECTION-DESTINATION-IP. These notify payloads 463 consist of a one-way hash of the IP address and port. The reason it 464 is a hash rather than the actual address is because some people have 465 argued that the actual address of a node behind a NAT might be 466 secret. Given there are only 32-bits in an IP address and the port is 467 known to be equal to 500, it is possible to do a brute force search 468 and discover the actual IP address, but having the payload convey the 469 hash rather than the actual address is at least a nuisance to someone 470 that would want to find the address. 472 Mysteriously, the NAT-DETECTION payloads are ignored by Bob. However, 473 if Alice notices a discrepancy between the IP addresses in the header 474 of the received message 2, and the hashes in the payloads, she 475 reverts to NAT behavior. 477 9.3 So, you're behind a NAT. What do you do? 479 In NAT-mode, packets on a child-SA (e.g., ESP packets) are sent with 480 UDP encapsulation. This means that instead of indicating the ESP 481 header with an IP header protocol type (and having the ESP header 482 immediately following the IP header), the IP header will indicate 483 "UDP", and the presence of the ESP header will be indicated by using 484 port 4500 in the UDP header. 486 NAPTs do not do any special-case processing with port 4500 (as they 487 do with port 500). So, if there is a packet from internal node A to 488 B, with UDP header, and ports 4500, and no mapping on the NAPT box 489 yet for A, the NAPT box will make a mapping from A to (IP address C, 490 port x), and overwrite the IP source address to C and the UDP source 491 port to x. When Bob receives a packet to port 4500 (indicating IPsec 492 UDP encapsulation), Bob responds to the port from which it was 493 received, so will respond to IP address C, port x. When the NAPT box 494 receives this packet from Bob to (C,x), it will translate the IP 495 address from C to A, and the port from x to 4500. 497 In addition to sending the child-SA packets on 4500, IKE (once the 498 NAT is detected) sends the remaining messages of the IKE handshake 499 over port 4500 instead of 500 (and does not insist on receiving them 500 from source port 4500). Using port 4500 for IKE wasn't strictly 501 necessary but had some advantages: 503 * It enables the NAPT box not to do special case processing for IKE, 504 and instead modify the UDP ports (as it would with anything else) 505 instead of relying on the IKE SPIs, which was a somewhat fragile and 506 very complex mechanism, 508 * It winds up creating fewer mapping entries in the NAPT box, since 509 the same port mapping for UDP-encapsulated child-SA packets will work 510 for the IKE exchange. (i.e., there is no need to keep mappings for 511 IKE cookie pairs). 513 * Since NAT boxes are only using heuristics for how long to keep a 514 mapping, if there were a different mapping for IKE than for the 515 child-SA, it could be that the NAT would forget the UDP port mapping 516 for the child-SA, but remember the IKE-SA cookie mapping. This would 517 be bad because dead peer detection is done by sending IKE 518 informational messages, which would indicate the SA was alive, but 519 child-SAs would go into a black hole because the NAT box would no 520 longer know how to map packets from B to A. 522 9.3 Encoding both IKE and ESP with port 4500 524 The mechanism for this encoding was copied from [HSSVC]. If a NAT is 525 detected, ESP packets will be sent with UDP encapsulation, using port 526 4500. Also, IKE packets will be sent to port 4500. How can the 527 receiving end distinguish between an ESP packet and an IKE packet? 529 In either case the packet will start with an IP header, with protocol 530 type=UDP (17). Then there is a UDP header, with destination 531 port=4500. After the UDP header is either an ESP packet or an IKE 532 packet. The first 4 bytes of an ESP packet is the SPI, which is not 533 allowed to be zero. So, to distinguish an IKE packet from an ESP 534 packet, if it is an IKE packet, the first 4 bytes after the UDP 535 header are 0, and then the IKE packet. 537 With this encoding, the overhead for UDP encapsulation of ESP packets 538 is minimized, and the extra 4 bytes of overhead is only on IKE 539 packets, and there are not many of those (compared to data packets). 541 10.0 Identity Hiding 543 Some people argue that identity hiding is an exotic feature that 544 cryptographers put into IKEv1 just because they could. In many cases, 545 such as those where nodes are at a fixed IP address, the identity is 546 not hidden. 548 And, there are different flavors of identity hiding. IKEv2 does 549 identity hiding of both parties from passive attackers. 551 In theory (and in IKEv1) one could hide the identities from active 552 attackers. With public encryption keys, if at least one side already 553 knows the identity and public key of the other, then it is possible 554 to protect both sides from any active attacker (assuming the 555 encryption key is not escrowed or otherwise compromised). With pre- 556 shared secret keys, assuming both parties already know who they 557 expect to be speaking with (within a small set, perhaps), it is also 558 possible to protect both identities from active attack. (But in fact, 559 in IKEv1, this was too strong an assumption, and identities with the 560 in-theory identity-hiding secret key protocol required, in practice, 561 that the identities be the IP addresses.) Additionally, having n 562 different protocols for slightly different security properties in 563 IKEv1 was deemed to be too complex for any benefit it gained, so 564 IKEv2 only supports public signature keys and pre-shared keys. 566 However, with public signature keys, one side or the other has to 567 reveal its identity first (before the other side has proven its 568 identity). Whichever side reveals its identity first, if it is 569 talking to an active attacker, it will have revealed its identity to 570 that attacker. In [PK01] it was argued that it was more important to 571 protect the identity of the initiator, since in the client-server 572 model, the server would be at a fixed IP address and would not have a 573 hideable identity. However, Charlie Kaufman later argued that a much 574 easier attack is a polling attack, in which the attacker merely opens 575 an IPsec connection to a node. If the responder reveals its identity 576 first, then this simple attack, which is easier to mount than a 577 passive attack, will reveal the identity at that address. If the 578 model were changed to a strict client-server model in which clients 579 never respond to connections, and server identities are not important 580 to protect, then it is reasonable to have the responder reveal its 581 identity first. The WG's decision was that they did not want to limit 582 IPsec's use to a strict client-server mode. 584 To avoid a polling attack, (in which an active attacker simply 585 initiates a connection to an IP address to find the identity 586 associated with that IP address) IKEv2 has the initiator reveal its 587 identity first. The active attack that IKEv2 has chosen not to deal 588 with involves having someone impersonate Bob's IP address and 589 discover the identities of parties that attempt to communicate with 590 that IP address. This attack is difficult to mount and it is not 591 obvious what benefit it would gain the active attacker. Alice has 592 only initiated a connection to an IP address. If she is not speaking 593 to the real Bob, she will discover this and break the connection. So 594 the active attacker cannot prove she intended to speak to Bob; merely 595 that she initiated an IPsec connection to a particular IP address. 597 11.0 Legacy Authentication 599 Alice might be a human, without a public key pair or a shared 600 cryptographic key. She might be using a token card (such as 601 SecureID), or a password. 603 There were several proposed extensions to IKEv1 for providing legacy 604 authentication [XAUTH], [CRACK], [EAP]. Given they were all 605 technically acceptable, one had to be chosen. The EAP protocol 606 [EAP], designed within the pppext WG, was adopted for IKEv2. 608 To use EAP with IKEv2, Alice, in message 3, reveals her identity, but 609 does not put in a certificate or an authentication payload. Bob, in 610 message 4, reveals and proves his identity, and specifies what type 611 of legacy authentication he wants, along with a text string to be 612 displayed at the client end (such as "this is your challenge for your 613 challenge/response token"). Alice can respond as Bob requests, or can 614 NAK and suggest a different type of EAP authentication. The IKEv2 615 spec really just references the EAP specification, so the design and 616 the types are defined within EAP. In IKEv2, mostly for illustrative 617 purposes, 3 of the EAP types are mentioned; MD5-Challenge, OTP, and 618 generic token card. In MD5-Challenge, the client must compute the 619 response, and not just mirror the text string. For OTP, depending on 620 whether the implementation is based on human-with-paper or client- 621 computed hash, the client either just sends the string the user types 622 or treats it as a password and hashes it n times. In the third type, 623 the client displays the text string to the human, which responds by 624 typing something (perhaps the display from the token card), and the 625 client sends that string back to the server. If the server is 626 satisfied, it responds with what would have been the 4th message in 627 the IKE handshake, choosing the selectors and cryptographic 628 algorithms for the child-SA. Additional exchanges are allowed, for 629 instance, if the user mistypes the value and the server gives the 630 user an extra chance. 632 12.0 References 634 [CRACK] Harkins, D., Korver, B., Piper, D., "IKE 635 Challenge/Response 636 for Authenticated Cryptographic Keys", 637 draft-ietf-ipsec-ike-crack-00.txt, October, 1999. 639 [EAP] Blunk, L. and Volibrecht, J., "PPP Extensible 640 Authentication 641 Protocol (EAP), RFC 2284, March 1998. 643 [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange 644 (IKE)", 645 RFC 2409, November 1998. 647 [HKP99] Harkins, D., Korver, B., Piper, D., "IKE 648 Challenge/Response for 649 Authenticated Cryptographic Keys", draft-ietf-ipsec-ike- 650 crack-00.txt 652 [HSSVC] Huttunen, A., Swander, B., Stenbert, M., Volpe, V., and 653 DiBurro, L., 654 "UDP Encapsulation of IPsec Packets", draft-ietf-ipsec- 655 udp-encaps-06.txt, 656 January 2003. 658 [JFK] Aiello, W., Bellovin, S., Blaze, M., Canetti, R., 659 Ioannidis, J., 660 Keromytis, A., Reingold, O., draft-ietf-ipsec-jfk-03, 661 April 2002. 663 [KSH01] Kivinen, T., Stenberg, M., Huttunen, A., Dixon, W., 664 Swander, B., 665 Volpe, V., and DiBurro, L., "Negotiation of NAT-Traversal 666 in 667 the IKE", draft-ietf-ipsec-nat-t-ike-01.txt, October 668 2001. 670 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, 671 J. 672 "Internet Security Association and Key Management 673 Protocol 674 (ISAKMP)", RFC 2408, November 1998. 676 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 677 2412, November 1998. 679 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 680 exchange Standard", WET-ICE Security Conference, MIT, 681 2001, 682 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 684 [Pip98] Piper, D., "The Internet IP Security Domain Of 685 Interpretation for ISAKMP", RFC 2407, November 1998. 687 [XAUTH] Beaulieu, S., and Pereira, R., "Extended Authentication 688 within IKE (XAUTH)", draft-beaulieu-ike-xauth-02.txt, 689 October 2001. 691 Authors' Addresses 693 Radia Perlman 694 radia.perlman@sun.com 695 Sun Microsystems