idnits 2.17.1 draft-ietf-ipsec-ikev2-rationale-00.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-24) 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: ---------------------------------------------------------------------------- ** 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. == 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 143 has weird spacing: '... are at fixed...' -- 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 2002) is 8104 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Bra96' on line 409 looks like a reference -- Missing reference section? 'Har01' on line 412 looks like a reference -- Missing reference section? 'PK01' on line 418 looks like a reference -- Missing reference section? 'Aie01' on line 405 looks like a reference -- Missing reference section? 'Ker01' on line 415 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Dan Harkins 3 INTERNET-DRAFT Charlie Kaufman 4 draft-ietf-ipsec-ikev2-rationale-00.txt Tero Kivinen 5 Expires: August 2002 Stephen Kent 6 Radia Perlman 7 February 2002 9 Design Rationale for IKEv2 10 12 Status of this Memo 14 This document is an Internet Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and working groups. Note that other groups may also distribute 18 working documents as Internet 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/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document describes the reasons for the design choices in IKEv2, 34 the protocol described in draft-ietf-ipsec-ikev2-01.txt. This 35 document describes why certain features are supported, and explains 36 the modifications between the second draft of IKEv2 and the first. It 37 describes both the changes we chose to make and the changes that we 38 considered but chose not to make. The changes are minor and mostly 39 based on feedback received from the first draft. 41 1. Introduction 43 IKEv2 [Har01] has been presented to the IPsec WG as a possible 44 successor to IKE (IKE is documented in RFCs 2407, 2408, and 2409). 45 IKEv2 preserves most of the features of the original IKE, including 46 identity hiding, perfect forward secrecy, two phases, and 47 cryptographic negotiation, while greatly redesigning the protocol for 48 efficiency, security, robustness, and flexibility. This document 49 explains the reasoning for the design choices made by IKEv2, as well 50 as possible alternatives, the advantages and disadvantages of these 51 alternatives, and a description of how the alternatives, if desired, 52 would be implemented. 54 2.0 Features for an IKE successor 56 At a minimum, such a protocol should perform mutual authentication 57 between two parties and establish cryptographic keys for integrity 58 and encryption of an IPsec SA. Simplicity is always a goal in any 59 protocol. Additional features, apropos a key and security 60 association management protocol for IPsec, include identity hiding, 61 cheap and graceful rekeying, dead peer detection, plausible 62 deniability, support for multiple services co-located at an IP 63 address, negotiation of peer-dependent IPsec policies, and a two- 64 phase structure to enable inexpensive creation of multiple SAs 65 between the same two hosts or security gateways. IKEv2 is a major 66 redesign of IKEv1. Syntax is preserved when there is no compelling 67 technical reason to change it, so that there might be some ability to 68 preserve code. However, IKEv2 is not (backwards) compatible with 69 IKEv1. A node that implements both IKEv2 and IKEv1 can interwork with 70 an IKEv1 node by detecting that the peer implements only IKEv1, and 71 thereafter communicating using only IKEv1. 73 2.1 Why Two Phases? 75 In IKEv2 terminology, the first phase is known as the IKE-SA. Once 76 the IKE-SA is created, it can be used for sending authenticated 77 notification messages, reliable dead-peer detection, and inexpensive 78 creation of "child-SAs", which are IPsec SAs for subscriber traffic. 79 In theory, IKE could facilitate creation of SAs for other protocols 80 as well. 82 We argued in [PK01] that having two phases was unnecessary and added 83 complexity. Since then, we have gotten feedback that the two phase 84 structure is useful and in typical IPsec deployments, multiple child- 85 SAs are indeed created. Also, once the details of the design were 86 worked out, we found that the ability to send authenticated 87 notification messages made certain necessary features, such as dead 88 peer detection, simpler and more robust. 90 Why do people find it useful to create multiple IPsec SAs between the 91 same pair of hosts? 93 - avoiding multiplexing multiple conversations over the same SA. 95 Several years ago Bellovin pointed out that if encryption is done 96 without integrity protection, there is a splicing attack whereby a 97 process involved in one flow through a shared crypto implementation 98 can, through an active attack, cause traffic for a different flow to 99 be decrypted and delivered to the process in the first flow. Of 100 course, nobody should be doing encryption without integrity 101 protection under these circumstances. It is likely there is no 102 similar flaw if integrity is used. But in a case where a security 103 gateway is delivering traffic on behalf of multiple customers, and 104 the data is going to another security gateway in order to access 105 other machines of those customers, the customers feel safer knowing 106 that their traffic is being carried via a different SA (and different 107 key) than traffic between nodes belonging to other customers. 109 - different security properties of different flows. According to 110 policy, some traffic might be only integrity-protected. Other traffic 111 might be encrypted with a short key. Other traffic might be encrypted 112 with a long key. Other traffic might use a vanity crypto algorithm 113 designed by one of your customers, and it will make them happy if you 114 use their algorithm for their traffic. In [PK01] we argued that all 115 traffic might as well be protected according to the needs of the 116 traffic that requires the strongest protection, but there might be 117 performance reasons or legal reasons (or vanity reasons) why this is 118 undesirable. 120 - different SAs for different classes of service. There might be 121 different classes of service, such as priority classes, that might 122 cause traffic for one class to travel much more slowly to the SA 123 destination than other types of traffic to the same SA destination. 124 To avoid replay attacks, the recipient keeps track of which sequence 125 numbers have been received. Typically, it only keeps track of the 126 highest n sequence numbers, up to the highest sequence number it has 127 seen on this SA, and data with sequence numbers lower than the "left" 128 side of the receive window are discarded. If different classes of 129 service have widely disparate delivery times, the recipient would 130 have to maintain a (potentially much) larger receive window to avoid 131 inappropriate discarding of "late arriving" IPsec traffic. 133 In addition to these reasons for creating multiple child-SAs, we 134 found that IKEv2's robustness is enhanced by its ability to use the 135 IKE-SA to send reliable and authenticated informational messages. 136 This detects error conditions, allows rekeying, and provides a method 137 for detecting a dead peer. 139 2.2 Identity Hiding 141 Some people argue that identity hiding is an exotic feature that 142 cryptographers put into IKEv1 just because they could. In many cases, 143 such as those where nodes are at fixed IP addresses, the identity is 144 not hidden. 146 And, there are different flavors of identity hiding. IKEv2 provides 147 identity hiding for both parties from passive attackers. Beyond that, 148 one might want to hide the identities from active attackers. With 149 public encryption keys, if at least one side already knows the 150 identity and public key of the other, then it is possible to protect 151 both sides from any active attacker (assuming the encryption key is 152 not escrowed or otherwise compromised). With pre-shared secret keys, 153 assuming both parties already know who they expect to be speaking 154 with (within a small set, perhaps), it is also possible to protect 155 both identities from active attack. 157 However, with public signature keys, one side or the other has to 158 reveal its identity first. If it is talking to an active attacker, it 159 will have revealed its identity. In [PK01] we argued that it was 160 more important to protect the identity of the initiator, since in the 161 client-server model, the server would be at a fixed IP address and 162 would not have a hideable identity. However, we later realized that 163 a much easier attack is a polling attack, in which the attacker 164 merely opens an IPsec connection to a node. If the responder reveals 165 its identity first, then this simple attack, which is easier to mount 166 than a passive attack, will reveal the identity at that address. If 167 the model were changed to a strict client-server model in which 168 clients never respond to connections, and server identities are not 169 important to protect, then it is reasonable to have the responder 170 reveal its identity first. The feedback we got from the WG was that 171 they did not want to change IPsec from a peer-ti-peer protocol into a 172 client-serverprotocol. 174 To avoid a polling attack, (in which an active attacker simply 175 initiates a connection to an IP address to find the identity 176 associated with that IP address) IKEv2 has the initiator reveal its 177 identity first. The active attack that IKEv2 has chosen not to deal 178 with involves having someone impersonate Bob's IP address and 179 discover the identities of parties that attempt to communicate with 180 that IP address. This attack is more difficult to mount (than the 181 polling attack described above) and it is not obvious what benefit it 182 would provide the active attacker. Alice has only initiated a 183 connection to an IP address. If she is not speaking to the real Bob, 184 she will discover this and break the connection. So the active 185 attacker cannot prove she intended to speak to Bob; merely that she 186 initiated an IPsec connection to a particular IP address. 188 2.3 Plausible Deniability 190 This feature enables Alice and Bob to communicate, leaving no ability 191 for anyone to prove that they did have a conversation, even with the 192 collusion of one of the parties. Alice does indeed sign a message 193 proving she is Alice, but she does not sign Bob's name or IP address. 194 The only thing she signs that belongs to Bob is his nonce, but anyone 195 could have generated that nonce. It is sent in the clear, and so the 196 fact that Bob generated that nonce certainly does not imply that 197 nobody else could have generated that nonce. The fact that Alice 198 carried on an IPsec connection with someone that used that nonce does 199 not prove she talked to Bob. 201 In the first draft of IKEv2, we had Alice sign the entire contents of 202 messages 1 and 2. This meant that all fields would be integrity 203 protected, either through Alice's signature (and Bob also signed both 204 messages), or through the integrity protection that all packets 205 beyond the first two automatically had through IKE's integrity 206 protection. Sara Bitan suggested a modification so that each side 207 only signs the fields it generates, plus the other side's nonce. This 208 still protects all fields, either through Bob's signature or Alice's. 209 It also makes it more obvious that the protocol provides plausiable 210 deniability. Some people argue that having Alice additionally sign 211 Bob's Diffie-Hellman value proves she talked to Bob, because only Bob 212 can produce the private exponent associated with that Diffie-Hellman 213 number. However, all it proves is that Alice talked to someone who 214 presented that Diffie-Hellman number. The fact that Bob knows the 215 private exponent does not mean that it was Bob. Instead, it could be 216 someone else that told Bob the Diffie-Hellman parameters. 218 2.4 Cookies 220 Although in [PK01] we explained how to effect a stateless cookie 221 exchange without adding messages (by having Alice repeat, in message 222 3, what she said in message 1, in IKEv2 we chose to have Bob request 223 stateless operation with an extra round trip, so the exchange in this 224 case would be 6 messages. The reasons for this: 226 - Having the message be 4 exchanges does not come for free. Repeating 227 everything in message 3 makes message 3 longer. 229 - Message 3 is likely to be large (it can contain Alice's 230 certificate). If message 3 needs to be fragmented, then Bob cannot 231 be stateless. He has to reassemble message 3 before he can determine 232 if the cookie is correct. Therefore, it was simpler to ensure that 233 all the messages before Bob starts needing to keep state are 234 sufficiently small as not to require fragmentation. 236 2.5 Cryptographic Negotiation 238 In IKEv2, Alice proposes a set of potential cryptographic algorithms, 239 and Bob chooses. Why is it necessary to negotiate? Why not let one 240 side or the other choose? Suppose IPsec just agreed upon a particular 241 set of cryptographic algorithms, and, say, Bob told Alice what 242 cryptographic algorithms to use. The problem with this is that if the 243 world ever wanted to phase in a new cryptographic algorithm, there 244 would be no way to do it until Bob could be assured that all the 245 clients had upgraded to support it. 247 In SSL, cryptographic negotiation is based on complete suites rather 248 than, as in IKEv1, individually negotiating each cryptographic 249 algorithm. In the first draft of IKEv2 we cleaned up the syntax 250 somewhat to avoid exponential explosion if many of one type of 251 algorithm can work with any of a number of choices for some other 252 type of algorithm. We argued on the list and during the meeting for 253 moving towards suites. 255 We considered switching over to suites in this draft of IKEv2, but we 256 got a surprising amount of feedback that people prefer negotiating 257 individual algorithms. Since there was no compelling reason to 258 change, and most opinions we heard were in favor of individual 259 algorithm negotiation, we kept it the way it was. If there were 260 working group consensus to move to suites, we would be delighted to 261 make the change. 263 3.0 Changes in this version of the draft 265 Very little needed to be changed from the previous draft of IKEv2. 266 In this section we describe the changes we considered making, but 267 decided against, and the changes we did decide to make. 269 3.1 Changes we considered and rejected 271 We considered making the following changes, but decided against them: 273 - negotiating cryptography with suites rather than individual 274 algorithms 276 - changing the encoding to "type of this payload" rather than "type 277 of next payload". We find the "type of next payload" harder to 278 understand, and if we had been laying out the packet formats from 279 scratch, we would have argued for that encoding. However, there is no 280 compelling reason in terms of compactness or parsing efficiency to 281 change it, and one of our stated goals in IKEv2 was not to make 282 "gratuitous changes" so that implementers might be able to reuse 283 code. This change would have been totally a subjective preference. 285 - changing to an exchange that allows Bob to have stateless operation 286 and still have the exchange fit within 4 messages. As we explained 287 above, we decided the exchange was better the way it is; 4 messages 288 with an extra round trip if Bob wants Alice to return his stateless 289 cookie before the exchange begins in earnest. It seemed like fitting 290 within 4 messages in this case was only motivated by "bragging 291 rights", and the downside was making message 3 bigger all the time, 292 and the issue that if message 3 is sufficiently large to need 293 fragmentation, then Bob would not be able to do stateless operation. 295 - adding in Bill Sommerfeld's "birth certificate" idea. In this idea 296 Bob keeps a number in nonvolatile memory that increments each time 297 the node restarts. When Bob restarts, he signs a "birth certificate" 298 stating what the value of that counter is. This birth certificate is 299 transmitted as a payload in message 4. Alice keeps this value. If Bob 300 ever receives an ESP packet that doesn't decrypt properly or with an 301 unknown SPI, he responds to that packet with his birth certificate. 302 If the recipient has an SA for Bob with an older birth certificate, 303 this lets them know Bob has restarted and forgotten state for that 304 SA. We decided not to add that to this version of the draft, although 305 we think it is a good idea, until it's been written up in a separate 306 draft and there has been an opportunity for people to understand it 307 and give feedback. 309 - adding an option of having Bob include, in message 2, a signed g^b 310 value, his name (in the clear), and his certificate. This is the JFK 311 [Aie01] idea, and our motivation for considering it was to come up 312 with a document that incorporated good ideas from everyone. If this 313 would have resulted in a single document, we felt it was worth doing, 314 but technically it seemed like adding this as an option would add 315 more complexity than any functionality gained. As explained in the 316 section on identity hiding, if a choice were made to do one mechanism 317 or the other, we felt the IKEv2 mechanism that avoided a polling 318 attack and hid both identities from passive attackers was preferable. 320 - Some people suggested that our choice of the name IKEv2 was 321 unfortunate for two reasons. Some people thought it was 322 "presumptious" to call it IKEv2 when there were other contenders. 323 However, at the time, Dan Harkins was tasked to come out with a 324 cleaned up and document-merged version of IKEv2. The other contenders 325 appeared simultaneously with the IKEv2 draft. Other people thought 326 the name was unfortunate because many people concluded, without even 327 looking at the draft, that anything named IKEv2 would just be 328 patching IKEv1, and everyone agreed that IKEv1 was terminally 329 complex. The confusion was exacerbated by naming the document the 330 same name (The Internet Key Exchange) as IKEv1, so many people 331 couldn't even find "IKEv2" listed in the drafts. We considered 332 changing the name, but given that the only cute name any of the 333 authors could come up with was "DOI" (daughter of IKE), and given 334 that IKEv2 by now had "brand recognition", we decided to stick with 335 the name IKEv2. However, we changed the title of the draft to 336 "Proposal for the IKEv2 Protocol". 338 3.2 Changes we decided to make 340 - We added support for preshared keys. Many people were against 341 preshared keys because they were so awkwardly supported in IKEv1. In 342 particular, in main mode, the ID had to be the IP address in order 343 for Bob to look up the relevant key and decrypt Alice's identity. And 344 they assumed that having multiple authentication methods was one of 345 the reasons IKEv1 became so complex. However, other people like the 346 performance advantage and configuration ease of preshared keys. Given 347 the structure of the IKEv2 exchange, it was trivial to support 348 preshared keys, and in a way that allowed arbitrary identities. The 349 only change is that the proof of identity, instead of being a 350 signature on what you sent plus the other side's nonce, becomes an 351 HMAC of the preshared key with what you sent plus the other side's 352 nonce. 354 - We added the option of having Alice specify, in message 1, Bob's 355 identity. This facilitates having multiple services co-located at an 356 address. The idea had come up before, and was suggested in [Ker01]. 357 This did require us to explicitly say that this field, if present, 358 should be excluded from what Alice signs. 360 - We added explicit instructions for the syntax of integrity 361 protection and encryption rather than pointing to the syntax in the 362 ESP spec. Our laziness in the first draft of IKEv2 caused confusion 363 because people assumed there was some dependency of IKEv2 on ESP. 364 [Note from CWK: I would characterize this as an attempt to minimize 365 redundant specification rather than laziness, but in any case it is 366 now fixed]. 368 - We changed what each side signs to be what they send in the first 369 pair of messages (minus Bob's name, if Alice sends that), plus the 370 other side's nonce. 372 - We added the ability to provide IDs in phase 2, so that IKE can set 373 up process-to-process IPsec SAs. 375 - We believe IKEv2's switch from random message IDs to sequence 376 numbers, and changing the cookies to recipient-specified SPIs fixes 377 the reflection and replay attacks in IKEv1. However, just because it 378 is "good cryptographic hygiene", we computed different cryptographic 379 keys in the two directions of the IKE-SA. 381 - We added the nonces into the SKEYSEED_a, SKEYSEED_d, and SKEYSEED_e 382 stew. Again this is "good cryptographic hygiene", and certainly is at 383 least as good as what was there. It might count as a "gratuitous 384 change", and can be changed back to what it was with minimal effort. 385 This addition was suggested by Tero Kivinen. 387 - We allow the port number of the other end to be something other 388 than 500, so that the protocol would work through NAT. 390 - We made some clarifications. We noted that the INITIAL-CONTACT 391 message should affect SAs only from the same IP address. We specified 392 the order of the fields, as being required to always be in the same 393 order. We specified that, after rekeying, the sequence numbers start 394 again at 1. 396 - All previous proposals (IKEv1, IKEv2, JFK, and SIGMA) were 397 vulnerable to an active attacker answering Alice's message with bogus 398 information. Alice cannot distinguish a legitimate message 2 from a 399 bogus message 2. In this draft we explain how Alice can protect 400 herself from this attack, which is to be willing to continue 401 negotiation with every reply she receives. Only the legitimate Bob 402 will be able to send an acceptable message 4, so the multiple SA's- 403 in-progress will only last until the SA is set up. 405 [Aie01] Aiello, W., Bellovin, S., Blaze, M., Canetti, R., 406 Ioannidis, J., Keromytis, A., Reingold, O., 407 "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk-00.txt 409 [Bra96] Bradner, S., "The Internet Standards Process -- 410 Revision 3", BCP 9, RFC 2026, October 1996. 412 [Har01] Harkins, D., Kaufman, C., and Perlman, R., "The Internet 413 Key Exchange (IKE) Protocol, draft-ietf-ipsec-ikev2-00.txt 415 [Ker01] Keromytis, A., and Sommerfeld, B., "The 'suggested ID' 416 extension for IKE, draft-keromytis-ike-id-00.txt. 418 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key 419 exchange Standard", WET-ICE Security Conference, MIT, 2001, 420 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. 422 Authors' Addresses 424 Dan Harkins 425 dharkins@tibernian.com 426 Tibernian Systems 428 Charlie Kaufman 429 ckaufman@notesdev.ibm.com 430 IBM 432 Tero Kivinen 433 kivinen@ssh.fi 434 SSH Communications Security Crop 435 Fredrikinkatu 42 436 FIN-00100 Helsinki 437 Finland 439 Stephen Kent 440 kent@bbn.com 441 BBN Corporation 443 Radia Perlman 444 radia.perlman@sun.com 445 Sun Microsystems