idnits 2.17.1 draft-ietf-ipsec-soi-features-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1297 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. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (May 31, 2002) is 8001 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CK02' -- Possible downref: Non-RFC (?) normative reference: ref. 'PK00' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Paul Hoffman 2 draft-ietf-ipsec-soi-features-01.txt VPN Consortium 3 May 31, 2002 4 Expires in six months 6 Features of Proposed Successors to IKE 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes many features of the proposals for the successor 31 to IKEv1. The purpose of the document is to help the IPsec Working Group 32 decide which features they want for the next protocol. The document 33 focuses on how those features are instantiated in two proposals, IKEv2 34 and JFK, but other ideas for features and options are also included. 35 Most of the material in this document comes from many of the authors of 36 the JFK and IKEv2 proposals. 38 This document is meant to help the Working Group choose which features 39 it finds important for the successor to IKE. It should be short-lived 40 and is not expected to become an RFC. 42 1. Introduction 44 The IPsec Working Group is actively considering the successor to IKE 45 (also known as "son of IKE"). The Working Group is evaluating the 46 requirements for keying IPsec, as well as looking at the positive and 47 negative lessons learned from many years of IKE development and 48 deployment. 50 Many of the categories of features described in this document overlap, 51 so it is not always possible to cleanly break out the features into 52 stand-alone units. 54 In this document, the terms "Alice" and "the initiator" are used 55 interchangeably, as are "Bob" and "the responder". 57 A summary of the features covered is listed near the end of this 58 document. 60 1.1 Selecting features for the successor to IKE 62 At this point, two proposals for the successor to IKE have been 63 discussed most heavily: IKEv2 and JFK. Each proposal has a myriad of 64 features. In many cases, the two proposals have chosen to address a 65 particular feature the same way; for many other features, the two 66 proposals differ. 68 It is important to note that this document describes the features of the 69 two protocols today, as well as features and options that are not 70 described in either protocol. Most of the features listed here could be 71 added (or removed) from either protocol. Thus, if a particular feature 72 is important to you and it exists in one protocol but not the other, you 73 should not assume that the other protocol cannot include the feature. 75 It is also important to note that there are often more than two choices 76 for a particular feature. For example, there are many different ways 77 that identity protection could be done, not just the two ways described 78 in the current proposals. The Working Group is free to consider all 79 options, not just those embodied in the current proposals. 81 This document attempts to list as many sensible options as possible for 82 the features listed. Some sensible options may have been inadvertently 83 omitted. 85 For some features, the description is just an exposition about how the 86 two protocols differ. This does not mean that "JFK will always do this" 87 or "IKEv2 will always do that". Instead, it is just a shorthand way of 88 describing two views of the feature. In most cases, either protocol 89 could be changed to work differently. 91 When this document talks about how either of the two proposals deals 92 with a feature, that discussion is based on the latest drafts of the two 93 proposals: draft-ietf-ipsec-ikev2-02.txt and 94 draft-ietf-ipsec-jfk-03.txt. JFK has two variants: JFKr and JFKi. When 95 the features in them differ, this document discusses the particular 96 variant. Note that the two proposals have made significant changes in 97 they way they approach some of the features. 99 1.2 Choosing a starting point 101 As discussed above, most of the features in this document can be 102 implemented in different ways. Once the IPsec Working Group has picked 103 the features it wants, it then must decide how to move forward and 104 create a protocol. The three likely choices are to start with IKEv2, 105 start with JFK, or start from scratch. 107 The authors of JFK and IKEv2 have stated that they are quite open to adding 108 or changing major parts of their protocols. Some features are so much part 109 of the core of a protocol that the cannot be changed, however. The features 110 that are core differences between the two protocols are: 112 - Whether the protocol has one phase or two phases 114 - How DoS attacks are thwarted 116 - The use of shared secret authentication 118 Thus, the Working Group may have to select the protocol to work from 119 based on these features, and can mix and match the other features 120 from that starting point. 122 2. Cryptographic features 124 2.1 Identity protection: who is protected, kinds of attacks 126 There are two types of attacks that can mounted to find out the identity 127 of one or both of the parties in a key exchange protocol: 129 - Passive attacks look for identities that passed in the clear during 130 the negotiation. In a passive attack, neither party can detect that the 131 identity is being seen. 133 - Active attacks find identities by being a man-in-the-middle or by 134 replacing the initiator or responder in the negotiation. The attacker 135 proceeds through the key negotiation with the attackee until the 136 attackee has revealed its identity. In a well-designed system, the 137 negotiation will fail after the attackee has revealed its identity 138 because the attacker cannot spoof the identity of the 139 originally-intended system. The attackee might then suspect that there 140 was an attack because the other side failed before it gave its identity. 141 Therefore, an active attack cannot be persistent because it would 142 prevent all legitimate access to the desired IPsec system. 144 In key negotiations, the IP address of each IPsec system is always known 145 to a passive or active attacker. The identities being protected by the 146 key negotiation system are those in the certificates or identification 147 payloads. 149 Typically, an IPsec system that is at the same IP address over a long 150 period of time does not need identity protection because an attacker can 151 use other means (such as traceroute and reverse DNS lookup) to determine 152 its identity. Identity protection is most useful to users with dynamic 153 IP addresses, usually users whose IP address is assigned by DHCP or by a 154 variety of different ISPs. 156 The four cases for a negotiation are: 158 Stationary initiator, stationary responder: This is typical of 159 gateway-to-gateway VPNs. Identity protection would not achieve much 160 here. 162 Mobile initiator, stationary responder: This is a typical remote-access 163 scenario. Even though the responder's identity can probably be 164 determined by other means, the initiator can get value from identity 165 protection. 167 Stationary initiator, mobile responder: For the initiator to be able to 168 find the responder, there must have been some recent prior contact 169 between the two parties (or other out-of-band mechanisms for location). 170 This could, for example, be a rekeying of an existing SA. In this case, 171 the responder would want its identity protected. 173 Mobile initiator, mobile responder: For the initiator to be able to find 174 the responder, there must have been some recent prior contact between 175 the two parties (or other out-of-band mechanisms for location). This 176 could, for example, be a rekeying of an existing SA. In this case, each 177 side would want its identity protected. 179 2.1.1 Proposals for protection 181 In IKEv2 and JFKr, there is no passive attack possible, and an active 182 attack is possible against the initiator's identity. Such an attack will 183 reveal the identity but will cause the negotiation to fail in the next 184 message. 186 In JFKi, there is a passive attack on the responder's identity, but no 187 active attack possible on the initiator. 189 It has also been proposed that the protocol allow no passive attack, and 190 allow an active attack on the responder's identity. This can be done 191 in many ways, such as extending message 2 to have encrypted and unencrypted 192 parts (making the entire protocol three messages), by having message 193 3 come from the responder instead of from the initiator, or by making 194 the protocol five messages long, with message 3 being a place-holder. 196 2.2 Perfect forward secrecy (PFS) 198 "Perfect forward secrecy" is the property that in the event of a compromise 199 of the system, past conversations recorded by the attacker cannot be 200 decrypted. 202 JFK incorporates "imperfect forward secrecy" into its base protocol. 203 That is, the essential component (a Diffie-Hellman exchange) is not 204 optional. However, as part of its DoS-resistance capability, the server 205 may reuse its exponential as often as it wants. The degree of perfection 206 of the forward secrecy, then, is dependent on the frequency of 207 generation of new exponentials, which in turn is dependent on details of 208 the implementation, the intensity of any DoS attack, and policy as set 209 by the site administrator. 211 IKEv2 uses a mandatory Diffie-Hellman exchange in Phase 1. Assuming that 212 both parties choose new Diffie-Hellman exponentials each time they do 213 Phase 1, there will be forward secrecy between IKE SAs. In addition, 214 IKEv2 allows perfect forward secrecy for Phase 2 SAs by allowing an 215 optional Diffie-Hellman exchange during rekeying of IPsec SAs in Phase 216 2. Performance can be traded off against PFS in IKEv2 as well. The IKEv2 217 specification describes how to reuse Diffie-Hellman exponents across 218 Phase 1 sessions, and change them periodically for imperfect forward 219 secrecy. 221 A protocol could always insist on doing PFS every time. 223 2.3 Authentication styles 225 IKEv2 supports two forms of authentication: certificates and shared 226 secret. JFK supports one form of authentications: certificates. 228 Any protocol that supports certificates also supports identification of 229 individuals without certificate hierarchies through the use of 230 self-signed certificates. If the receiving system loads a self-signed 231 certificate based on out-of-band communications, the party that has 232 the private key associated with the public key in the certificate 233 can authenticate to the receiving system. 235 IKEv2 indirectly supports non-certificate, non-shared-secret 236 authentication (commonly called "legacy authentication") though the use 237 of the ID_KEY_ID identity type and the shared secret authentication. The 238 authentication system must create two temporary tokens, one of which is 239 used as the identity and the other is used as the secret. The IKEv2 240 system must have some way of securely querying the authentication system 241 with the identity token and receiving back the secret token. 243 2.4 Number of crypto operations 245 2.4.1 JFKr 247 In JFKr, the following crypto operations occur: 249 Message 1: 250 - Choose a Diffie-Hellman exponential 252 Message 2: 253 - Choose a Diffie-Hellman exponential 254 - Create an HMAC 256 Message 3: 257 - Compute Diffie-Hellman shared secret 258 - Sign 259 - Encrypt 260 - Create an HMAC 262 Message 4: 263 - Compute Diffie-Hellman shared secret 264 - Validate the first HMAC 265 - Decrypt 266 - Validate signature 267 - Sign 268 - Encrypt 269 - Create an HMAC 270 - Validate the second HMAC 272 The initiator then has to: 273 - Decrypt 274 - Validate a signature 275 - Validate an HMAC 277 The initiator and responder can each choose to reuse a 278 Diffie-Hellman exponential if they want to extend the forward secrecy 279 window. 281 2.4.2 JFKi 283 In JFKi, the following crypto operations occur: 285 Message 1: 286 - Choose a Diffie-Hellman exponential 288 Message 2: 289 - Choose a Diffie-Hellman exponential 290 - Sign 291 - Create an HMAC 293 Message 3: 294 - Compute Diffie-Hellman shared secret 295 - Validate a signature 296 - Sign 297 - Encrypt 298 - Create an HMAC 300 Message 4: 301 - Compute Diffie-Hellman shared secret 302 - Validate HMAC 303 - Decrypt 304 - Validate signature 305 - Encrypt 307 The initiator then has to: 308 - Decrypt 309 - Validate a signature 311 The initiator and responder can each choose not to choose a 312 Diffie-Hellman exponential if they want to extend the forward secrecy 313 window. 315 2.4.3 IKEv2 317 In Phase 1 of IKEv2, the following crypto operations occur: 319 Phase 1, message 1: 320 - Choose a Diffie-Hellman exponential 322 Phase 1, message 2: 323 - Choose a Diffie-Hellman exponential 325 Phase 1, message 3: 326 - Compute Diffie-Hellman shared secret 327 - Sign (for certificates) or HMAC (for shared secret) 328 - Encrypt 329 - Create an HMAC 331 Phase 1, message 4: 332 - Compute Diffie-Hellman shared secret 333 - Validate an HMAC 334 - Decrypt 335 - Validate signature (for certificates) or HMAC( for shared secret) 336 - Sign (for certificates) or HMAC (for shared secret) 337 - Encrypt 338 - Create an HMAC 340 The initiator then has to: 341 - Validate an HMAC 342 - Decrypt 343 - Validate signature (for certificates) or HMAC( for shared secret) 345 In Phase 2 of IKEv2, when creating a new IPsec SA, the following crypto 346 operations occur: 348 Phase 2, message 1: 349 - Optionally choose a Diffie-Hellman exponential 350 - Encrypt 351 - Create an HMAC 353 Phase 2, message 1: 354 - Decrypt 355 - Optionally choose a Diffie-Hellman exponential 356 - Encrypt 357 - Create an HMAC 359 The initiator then has to: 360 - Validate an HMAC 361 - Decrypt 363 In IKEv2 Phase 2, the Diffie-Hellman exponentials must be given if they 364 were negotiated in Phase 1. 366 2.4.4 Summary of the number of crypto operations 368 In all of the proposals, each side must choose a Diffie-Hellman 369 exponential and compute the Diffie-Hellman shared secret. In the tables 370 below, the first number is for the initiator, the second number is for 371 the responder. 373 | Sign | Validate | Symmetric | Hash 374 | | signature | crypt | 375 -------+---------+-----------+-----------+-------- 376 JFKr | i:1 r:1 | i:1 r:1 | i:2 r:2 | i:2 r:4 377 -------+---------+---------- +-----------+-------- 378 JFKi | i:1 r:1 | i:2 r:1 | i:2 r:2 | i:1 r:2 379 -------+---------+---------- +-----------+-------- 380 IKEv2 | i:1 r:1 | i:1 r:1 | i:2 r:2 | i:2 r:2 381 sig | | | | 382 -------+---------+---------- +-----------+-------- 383 IKEv2 | i:0 r:0 | i:0 r:0 | i:2 r:2 | i:3 r:3 384 secret | | | | 386 In other words, the basic difference between JFKr and IKEv2 in signature 387 mode is that JFKr requires two more hashes for the responder. 389 For rekeying an existing IPsec SA, the summary looks like: 391 | Sign | Validate | Symmetric | Hash 392 | | signature | crypt | 393 -------+---------+-----------+-----------+-------- 394 JFKr | i:1 r:1 | i:1 r:1 | i:2 r:2 | i:2 r:4 395 -------+---------+---------- +-----------+-------- 396 JFKi | i:1 r:1 | i:2 r:1 | i:2 r:2 | i:1 r:2 397 -------+---------+---------- +-----------+-------- 398 IKEv2 | i:0 r:0 | i:0 r:0 | i:2 r:2 | i:2 r:1 400 In other words, for rekeying, JFKr requires two more signatures, two 401 more signature validations, and three more hashes. 403 2.5 Plausible deniability 405 If Alice and Bob are using a public key cryptosystem that supports 406 digital signatures (such as RSA or DSA) as part of their authentication 407 and key establishment protocol, it may be possible for Alice to prove to 408 a third party, Carol, that Bob did indeed participate in a protocol 409 exchange with her. If Alice can do so, the exchange is said to be 410 "non-repudiable" (that is, Bob cannot repudiate having done it). 412 On the other hand, it is possible to construct the protocol in such a 413 way that, while both parties are convinced at the end of the protocol 414 exchange that the other is present and has authenticated, they cannot 415 prove this to a third party; that is, Carol cannot determine whether Bob 416 really did participate in the exchange or Alice constructed the 417 evidence. Bob is then said to have "plausible deniability" in having 418 participated in the exchange with Alice, as far as anyone else can 419 discern. 421 Both IKEv2 and JFKr provide plausible deniability to both Alice and Bob, 422 since in neither protocol is the identity of the peer signed by either 423 party. Notice that shared-secret authentication schemes are by nature 424 repudiable because either party can impersonate the other). 426 JFKi does not provide plausible deniability to either Alice or Bob, 427 because each must sign with their private key with a quantity which 428 includes the other's name. 430 2.6 Formal proofs of security 432 JFK has an extensive cryptographic proof section in the specification. 433 IKEv2 doesn't contain any cryptographic proof. The signature mode of 434 IKEv2 is similar to the signature mode of IKEv1; IKEv1 was analyzed and 435 proven secure in [CK02]. 437 3. Protocol mechanics 439 3.1 DoS protection 441 Each protocol uses an anti-clogging token as a DoS protection mechanism. 442 The responder (if under attack in IKEv2, and always in JFK) computes the 443 token using something known only to him and other things the initiator 444 provided in the request. This binds Alice to the exchange and if the 445 initiator can produce the token again in a subsequent message along with 446 the information that is bound in the token then the responder has a 447 strong reason to believe the initiator is a real, live, peer and not a 448 scripted attack. 450 Two different types of DoS attacks are thwarted by JFK and IKEv2: 451 attacks that would cause the protocol itself to exhaust memory or CPU, 452 and attacks that could cause the lower-level packet handler in the 453 implementation to exhaust memory by sending incomplete UDP packet 454 fragments. 456 For basic DoS attacks that would cause the protocol itself to exhaust 457 memory or CPU, the difference in approach between the two protocols is 458 that JFK tries to be completely stateless after sending message 1 and is 459 always a 4 message exchange, while IKEv2 can be "stateless" in six 460 messages or "stateful" in four messages. In IKEv2, the decision of when 461 to switch from stateful to stateless is at the discretion of the 462 implementation when it feels it has too many outstanding, larval 463 exchanges, or when it feels it is "under attack". 465 In the UDP fragmentation attacks, the lower-level UPD fragment handler 466 must have some way of being smart when its fragment buffer gets nearly 467 full. Note that in both protocols, message 3 can be legitimately 468 fragmented. JFK specifies a method where the lower-level system checks 469 for a value in the ip_id field of the UDP packets. In IKEv2, the IKEv2 470 system informs the lower-level system to only accept UDP fragments from 471 IP addresses from which it has received a valid cookie, and to refuse to 472 accept UDP fragments from all other IP addresses. 474 3.1.2 Commentary on IKEv2 stateless cookies 476 [PK00] explains how to do stateless cookies without adding additional 477 messages, by repeating information from message 1 in message 3. It is 478 possible to do stateless cookies without adding an additional two 479 messages. However, IKEv2 says instead that if Bob feels he is under 480 attack and would like to use a stateless cookie mechanism, he rejects 481 message 1 and sends a stateless cookie, and Alice repeats message 1, 482 this time with the stateless cookie. 484 The reasons for doing this rather than the mechanism proposed in [PK00], 485 adopted by JFK, which avoids the extra 2 messages are: 487 - This makes message 3 shorter. If Bob does not need the stateless 488 cookie mechanism, there will be fewer bits transmitted 490 - It is complex and implementation-costly to have message 3 be partly 491 encrypted and partly unencrypted, as would be necessary to do the [PK00] 492 mechanism. 494 - Keeping message 1 (and the repeated message 1 plus the cookie) small 495 enough not to require fragmentation avoids a fragmentation DOS attack. 496 Bob needs to keep state to reassemble fragmented packets. Using the 497 stateless cookie mechanism with small messages until a cookie is 498 returned allows an implementation to defend against fragmentation DoS 499 attack. For this to work, IKEv2 gives hints to the reassembly code about 500 which IP addresses should be preferred for state. Since IKEv2 will not 501 require fragmentation until the cookie is returned and Alice's IP 502 address can be added to the preferred category, the limited reassembly 503 buffers can be reserved for reassembling packets from IP addresses which 504 have returned valid cookies. 506 3.1.2 Commentary on JFK's reuse of exponentials 508 JFK's DoS-resistance is, more generally, a mechanism for limiting the 509 CPU consumption of the participants at the time of SA creation. An 510 implementation can have a low-priority background process that generates 511 a queue of exponentials. When creating an SA, the process can use an 512 exponential from the queue. If the queue is empty, either a new 513 exponential is generated or the system reuses an existing exponential, 514 based on a limit set by the administrator. This avoids the necessity to 515 make an explicit determination that there is an attack in progress; 516 additionally, it is well-suited to situations where there may be a 517 sudden surge of new SAs, such as when a security gateway reboots. 519 3.2 Number of messages in all scenarios 521 As described in section 2.1, the anti-DoS mechanism in JFK requires no 522 additional messages, while the anti-DoS mechanism in IKEv2 requires an 523 additional round-trip when the responder believes it is under attack. 524 Thus, the number of messages for a normal JFK setup is four, and the 525 number for a normal IKEv2 setup is four or six. However, these numbers 526 assume that the cryptographic suites are agreed to by both parties on 527 the first try. 529 IKEv2 and JFK both use 4 messages as the base operation. In messages 1 530 and 2 there is a Diffie-Hellman exchange. In messages 3 and 4 identities 531 are exchanged, along with proof of knowledge of the private key, 532 encrypted and integrity protected with a function of the Diffie-Hellman 533 key. 535 In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in message 536 1. In IKEv2, if she chooses a group that Bob does not support, the 537 protocol fails and Alice must start again, causing the use of an extra 538 two messages. In JFK, if she chooses a group that Bob does not support, 539 but can use the one Bob suggested (in g^r), she can proceed directly to 540 message 3 by using the same Ni and a new g^i; otherwise, the protocol 541 fails and Alice must start again, causing the use of an extra two 542 messages. 544 3.3 Size of messages 546 In both protocols, each message is fairly small unless it contains a 547 certificate. The differences in the size of the messages is small 548 relative to items that are inherently long, such as Diffie-Hellman 549 exponentials. 551 3.4 Preferred ID for responder 553 In JFK and IKEv2, the initiator can include a payload is an indication 554 to the responder as to what identity (and corresponding key material) 555 the responder should use to authenticate to the initiator. The responder 556 may ignore this hint. In JFKr and IKEv2, this value is encrypted in 557 message 3; in JFKi, it is sent in the clear in message 1, thereby 558 allowing a passive attack on the responder's likely identity. 560 3.5 Birth certificates 562 Assume Alice and Bob have an SA established, and that Bob crashes and 563 restarts. Alice will send a packet into an SA that Bob doesn't know 564 about. Birth certificates are a method for letting Alice know that the 565 SA is no longer alive. 567 It is desirable that such a mechanism be inexpensive for Bob. If a 568 mechanism required a lot of computation, for instance, having Bob sign a 569 customized message saying, "This SA didn't decrypt properly. Perhaps 570 it's because it's a reused SA number from before I crashed" or "unknown 571 SPI", then there is an easy DOS attack on Bob's limited computation by 572 sending him bogus messages. If Bob sends totally unauthenticated 573 messages, it is difficult for Alice to act on them, since an active 574 attacker could send her "no such SPI" messages to cause her to close 575 connections. 577 The idea of a birth certificate, originated in the IPsec Working 578 Group by Bill Sommerfeld, is that Bob should have a monotonically 579 increasing number that increases each time Bob restarts. When Bob 580 restarts, he signs a message saying, "this is my incarnation number". 581 When Bob creates an SA, Bob optionally sends his birth certificate. 582 Alice can optionally keep this certificate with her SA. Then, if Alice 583 ever receives an error message from Bob with a birth certificate with a 584 higher incarnation number, she can remove all SAs associated with Bob's 585 previous incarnation. 587 This mechanism is somewhat overlapping with the "initial-contact" 588 mechanism in IKEv2. Discussion in the WG suggested that birth 589 certificates could replace initial-contact, but some people said that 590 both were valuable. 592 Neither IKEv2 nor JFK have this feature. 594 4. One or two phases 596 4.1 Control channel vs. separate protocols 598 In IKEv2, Phase 1 is used as a control channel for IPsec SAs. After 599 the Phase 1 has been set up, it can be used to: 601 - create new IPsec SAs 603 - delete existing IPsec SAs 605 - rekeying existing IPsec SAs 607 - send protected notifications 609 - perform dead peer detection 611 In JFK, there is no Phase 2, and separate protocols are specified for 612 the control functions. The JFK proposal describes the following: 614 - using JFK again to create new IPsec SAs 616 - deleting existing SAs by rekeying an existing SA with AH_BYPASS or 617 ESP_BYPASS 619 - there is no need to rekey existing SAs because new ones are created 621 - no protected notifications are specified in JFK 623 - dead peer detection is done by noting the time of the last packet 624 received 626 Proposals have also been made for additional SA control functions such 627 as keep-alives. 629 4.2 Creating multiple SAs for a single pair of entities 631 In JFK, each SA is created and managed independently. A pair of entities 632 can have multiple SAs by running the JFK protocol multiple times, each 633 time picking a new SA identifier. 635 In IKEv2, a single IKE SA can be used to create multiple IPsec SAs for 636 the same pair of entities if the IPsec SAs use the same credentials; if 637 different credentials are needed for some IPsec SAs, new IKE SAs must be 638 created. In addition, a pair of entities can have multiple SAs by 639 creating new IKE SAs (that is, by creating a new Phase 1). 641 4.3 Dead peer detection 643 JFK does not incorporate any intrinsic facilities for dead peer 644 detection. Instead, the draft suggests an outboard approach. A dead peer 645 is defined as one from which no packets have been received successfully 646 for some site-dependent length of time. An IPsec node may attempt to 647 elicit a packet by sending one of its own, such as an ICMP "Echo 648 Request" message. To enable this, it is entitled to request an SA that 649 permits such messages, and to decline any SA that does not include such 650 permission. 652 IKEv2 relies on a similar strategy. However, instead of relying on 653 ordinary SA traffic, it uses responses (or the lack thereof) from 654 authenticated Phase 1 traffic. IKEv2 explicitly allows a peer to decide 655 that other peer has died because of lack of responses to lack of 656 acknowledgment to a Phase 1 message, even an empty informational 657 exchange. 659 4.4 SA deletion 661 In JFK, a new IPsec SA that specifies an SPD identical to the SPD of an 662 existing SA overwrites the old one. To delete an SA, create a new one 663 with the ESP_BYPASS or AH_BYPASS ciphersuites. 665 In IKEv2, both IPsec SAs and IKE SAs are deleted with a delete payload. 667 4.5 SA rekeying 669 In IKEv2 and JFK, each end of the SA is responsible for enforcing its 670 own lifetime policy on the SA and rekeying the SA when necessary. In 671 both protocols, SAs are rekeyed by creating a new equivalent SA, then 672 deleting the old SA. In IKEv2, this applies to both IKE SAs and the 673 IPsec SAs. 675 4.6 Authenticated error messages 677 In some situations, either of the protocol participants may detect an 678 error that can be recovered from if the peer modifies its behavior. 679 (Errors that are non-recoverable include implementation failures, such 680 as a mis-formatted message and so on.) Even for non-recoverable errors, 681 it is sometimes desirable to send an error indication to the peer, so 682 the recipient can take some kind of corrective action (or at least not 683 keep doing whatever is causing the error). In those situations, the 684 protocol may support the transmission of error messages. The question is 685 whether these messages need to be cryptographically protected. 687 There are three types of attacks on error messages: 689 a) Information leakage: if the error message includes information 690 identifying one of the protocol participants, and identity protection is 691 desired, the error message should obviously be encrypted. Likewise, 692 receipt of an error message should not cause the receiving party to 693 perform an action that discloses either party's identity. 695 b) Downgrade attacks: if the error message indicates a choice in 696 encryption algorithms (or otherwise protocol "strength") and the message 697 is not authenticated, it may be possible for an active attacker to cause 698 a weaker cipher (or other protocol parameter) to be used, making it 699 easier to mount a cryptographic attack. This particular attack is 700 possible against version 2 of the SSL protocol. 702 c) Denial of service attacks: error messages that cause an otherwise 703 valid exchange to be dropped (perhaps with catastrophic consequences, 704 such as a black-hole SPD entry to be installed). 705 An attacker that sits in the 706 middle of the network can always deny service simply by dropping 707 packets. Of more interest are situations where an attacker that is not 708 on the direct communication path (and thus cannot directly perform a 709 protocol DoS attack) can nonetheless cause protocol failure by sending 710 fake error messages, perhaps after some minimal guessing or 711 precomputation. 713 There are, generally, two kinds of error messages: 715 - Error messages exchanged in the course of the key exchange protocol 716 itself. If these are "fatal" for the protocol, the messages should 717 either contain enough randomness (such as in the form of cookies) to 718 avoid blind attacks, or the messages should be authenticated if they 719 occur late enough in the protocol exchange that key material has been 720 established. If they are not fatal (such as if they indicate a set of 721 acceptable options), the same options as above are available; 722 alternatively, it is acceptable that these messages are not strongly 723 protected if their contents are included in some integrity verification 724 later on (such as the JFKr authentication of GRPINFOr which is sent in 725 message 2, but is included in the signature of message 3 in the 726 protocol). 728 - Error messages having to do with events after the protocol exchange 729 has been completed (such as an "SA delete" message). Because the 730 authentication has been completed, it is fairly straightforward to 731 provision for some kind of protected control channel between the two 732 peers, using key material and other parameters already negotiated. 733 Whether this control channel is provided as part of the base protocol, 734 or it's implemented as a separate protocol is a protocol design 735 decision. 737 In IKEv2, most error messages and notifications are protected under an 738 IKE SA, and their delivery is confirmed. There are two error messages 739 that are not (and cannot be) protected in this way: errors in response 740 to the message 1 in the exchange (requesting a cookie, or indicating an 741 unacceptable SA payload), and notifications sent when a host receives an 742 ESP or AH packet with an unknown SPI (possibly because of a reboot). In 743 the former case, an attacker would need to know (or predict) the 744 Initiator cookie, before he can fool the Initiator into accepting an 745 error message. As an additional precaution, the Initiator may wait for a 746 short period of time (e.g., the retransmission timer) before dropping 747 the exchange (or modifying his behavior), in case another packet (not an 748 error message) arrives. This situation may arise when an attacker can 749 observe traffic between two parties but cannot prevent messages from 750 going through (such as on a wireless link). In the latter case (sending 751 a notification in response to an unknown SPI), care must be taken in how 752 the recipient responds: simply re-negotiating a new SA pair can lead to 753 a blind DoS attack. One solution is to examine the last time an ESP/AH 754 packet was received from the peer that purportedly send the "unknown 755 SPI" message, as well as invoke any keep-alive mechanism. (Notice that 756 this last item argues for a keep-alive mechanism that is outside the key 757 exchange protocol and is protected by ESP/AH; otherwise, the same 758 potential for a DoS attack exists.) 760 The exact same considerations are present in JFK; an error notification 761 returned as a response to message 1 cannot be protected. Errors in 762 message 3 (errors sent from the Initiator to the Responder) can be 763 protected, unless they indicated a failure in the key exchange itself 764 (such as a shared key cannot be computed). Errors in message 4 are 765 authenticated under key material already exchanged. JFK itself does not 766 provide for any other error or notification messages. Peer keep-alives 767 or other similar notifications must be implemented as protocols using 768 the ESP/AH SAs already established, or their own separate mechanisms (if 769 appropriate). In the former case, those messages are protected under the 770 IPsec SAs established. 772 4.7 Authenticated informational messages 774 JFK has no authenticated informational messages. IKEv2 has 775 authenticated informational messages after an IKE SA has been set up. 777 5. SA creation style 779 5.1 Cryptographic agreement 781 In order to set up an IPsec SA, the two parties have to agree on two 782 separate cryptographic suites: one suite for key exchange, another for 783 use in the IPsec SA itself. In both protocols, agreeing on a 784 Diffie-Hellman group used for key exchange is different than agreeing on 785 the cryptographic material used in the IPsec SA. In both protocols, the 786 two peers want to agree on a single suite of security parameters for the 787 key negotiation, and a single set of security parameters for IPsec; the 788 two sets might be very different. 790 5.1.1 Agreement of key exchange keys 792 In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in message 793 1. 795 IKEv2 provides a form of negotiation for keys that allows the two 796 parties to agree on the most preferred parameters. If both can do AES 797 and 3DES but one is preferred (for instance if 3DES had hardware 798 acceleration while AES did not), then they can agree on the preferred 799 parameter. If Alice chooses a group that Bob does not support, the 800 protocol fails and Alice must start again. In this failure case, Bob 801 does not tell Alice what groups he accepts. 803 In JFK, Bob states one crypto suite that contains a single encryption 804 algorithm, a single hash algorithm, and one or more Diffie-Hellman 805 groups. If Alice doesn't accept Bob's suite, Alice will give up and end 806 the communication. In message 1, if Alice chooses a group that Bob does 807 not support, but she can use the one Bob suggested (in his g^r), she can 808 proceed directly to message 3 by using the same Ni and a new g^i. Even 809 if Alice can't use the group from Bob's g^r, Bob tells Alice which group 810 he supports in his failure notification to her. 812 The difference in styles between IKEv2 and JFK affects changing 813 encryption and hash algorithms used in key exchange. In IKEv2, Alice can 814 add this algorithm to her list offered to Bob; if Bob doesn't know about 815 it yet, he will use one of the older, less-wonderful algorithms. JFK 816 assumes that no different algorithm will be needed for key exchange; if 817 it is, Bob must communicate this change out-of-band to all of the 818 parties that initiate to him. In this respect, IKEv2 is meant to allow 819 negotiation; JFK is meant to allow simplicity. 821 5.1.2 Agreement of IPsec SA cryptographic algorithms 823 If one peer is only willing to accept a single suite in JFK or only one 824 option of each of the parameters in IKEv2, then that peer is said to be 825 "demanding". In JFK, Bob "proposes/demands" a single suite; in IKEv2, 826 Alice "proposes/demands" one or more options for each part of the set of 827 parameters. 829 IKEv2 SA negotiation allows the two parties to agree on the most 830 preferred parameters, the same as it does for key negotiation. 832 In JFK SA negotiation, Alice states one crypto suite; if Bob doesn't 833 accept that suite, he rejects it and Alice can send another message 3 834 with a different crypto suite. JFK's SA negotiation uses pre-defined 835 suites. 837 5.2 Scope of proposals 839 If a protocol supports different options for different algorithms, the 840 combinations can be stated either as independent choices (if Alice 841 supports three options for encryption and four options for integrity 842 protection, she sends a list of three and a list of four proposals) or 843 as complete suites (in the above case, Alice would send 3*4=12 844 proposals). 846 The not-so-hidden agenda in deciding which format to use is trying to 847 avoid the explosion of useless options - all of which should be tested. 848 In the example above, making the choices independent makes the 849 specification and the protocol messages shorter, but it does not reduce 850 the testing effort. Suites are desirable where we expect to *not* 851 support all combinations of algorithms, but only a small subset. If 852 someone demands that the protocol support the new HMAC-SHA2-256 853 integrity protection algorithm, we would specify suites combining it 854 only with encryption algorithms we would expect to have supported (e.g. 855 AES) rather than all the existing encryption algorithms. 857 The experience of TLS in this space has been mixed. TLS specifies 858 suites, and the number has grown cumbersome because we were unable to 859 resist requests for lots of questionable combinations. But IKEv1 has its 860 own problems with large numbers of individual choices. In IKEv1, a 861 proposal consisted of a complete set of cryptographic options. This 862 created the opportunity for an exponential explosion of proposals, 863 assuming many of one type of algorithm worked with many of another type 864 of algorithm. 866 Proposing suites is simpler to encode. The downside of suites are that 867 in practice, it will be less flexible because people will not define 868 suites for every possible combination, and that the specification will 869 be larger because practice with SSL indicates that people will define 870 lots of combinations. 872 The disadvantage of the flexibility of individual algorithm negotiation 873 is that implementations are likely in practice to support large numbers 874 of combinations without testing them (which works only to the degree 875 that the algorithms don't interact). 877 Without losing flexibility, IKEv2 allows choices within a proposal, so 878 that if any of several algorithms of type 1 can be used with any of 879 several algorithms of type 2, then the proposal can say "I will do any 880 of these in conjunction with any of those" and the responder selects a 881 single choice for each algorithm. JFK, on the other hand, uses a single 882 suite that is given by the responder as a take-it-or-leave-it offer. 884 In JFK key agreement, the responder states a single set of individual 885 algorithms that is not negotiable; in JFK SA negotiation, the 886 initiator states a single set of individual algorithms that is not 887 negotiable. In IKEv2, the initiator can propose many options for 888 different algorithms. 890 5.3 SPD entries 892 In IKEv2, the TS payload consists of a set of individual traffic 893 selectors. Each selector has a source port; a destination port; and 894 either a range or addresses, a subnet, or a single address. The 895 Responder is allowed to narrow the choices by selecting a subset of the 896 traffic. 898 In JFK, the initiator proposes an SA; the responder may either accept it 899 or reject it with a reason. The SA offered can have multiple address 900 ranges and multiple port ranges. 902 6. Wire protocol issues 904 6.1 Message encoding 906 IKEv2 uses approximately the same message encoding as IKEv1, using 907 similar payload headers. The main difference is that IKEv2 has a 908 critical bit. IKEv2 adds some new payload types to IKEv1, and uses a 909 completely different encryption and authentication format than was used 910 in IKEv1. It also adds new header flags (initiator and version). The SA 911 payload is also different from IKEv1. 913 IKEv2 has 4 bit major version number and 4 bit minor version number and 914 cookies to identify the IKE SA and message id to identify the message 915 inside the IKE SA 917 The JFK message format is simply TLV (tag-length-value) encoding without 918 any generic header. It does not include any kind of version numbers or 919 exchange identifiers. 921 One feature of the message encoding format that affects speed of 922 execution on many platforms is whether or not the messages and parts of 923 messages align on two- and four-octet boundaries. 925 6.2 Port number 927 When a new version of a protocol occurs, the reasons for keeping the 928 same port and simply changing the version number are: 930 - to avoid the necessity of obtaining a new port 932 - to avoid the necessity for configuring firewalls to treat the new port 933 like it treated the old port 935 - to allow implementations of both versions of the protocol in a single 936 software module to send and listen on a single port 938 - to avoid timeouts when a system that speaks both the new and the 939 old version initiates to a system that only speaks the old version 941 The reasons to get a new port number for a new version of a protocol 942 are: 944 - to eliminate the possibility that implementations of the new protocol 945 will interact badly (such as causing a crash) with buggy or 946 not-forward-looking implementations of the old one 948 - to give the new version total freedom in its choice of wire formats 949 (for example, it is not constrained to put a "version number" in the 950 same place as the old protocol) 952 - to allow implementations of both versions of the protocol in separate 953 software modules to avoid having to negotiate ownership of the port 955 JFK proposes assignment of a new port and a wire format that does not 956 place version numbers in compatible places. It does not specify a way 957 for future versions of the protocol to share the new port (assuming that 958 a future version would get another new port). 960 IKEv2 proposes reusing port 500 and explicitly planning for future 961 versions of the protocol to also share port 500. 963 6.3 Future versions of the protocols 965 IKEv2 specifies a method for demanding/requesting that a peer use a 966 particular version of IKE. JFK has no version number and therefore no 967 way of demanding/requesting a particular version. 969 6.4 Code-preservingness 971 IKEv2 is clearly based on IKEv1 so a great deal of IKEv1 code can be 972 reused when creating an IKEv2 implementation. Note, however, that IKEv2 973 changes many parts of IKEv1, so the code reuse must be done very 974 carefully. In a reasonably modular code-base, this might be fairly 975 straightforward. A great deal of torture testing of the new code will 976 have to be done to make sure that the large removals of features no 977 longer in IKEv2 (such as aggressive mode) don't have unexpected 978 side-effects. 980 JFK doesn't preserve any code from IKEv1. 982 6.5 Extensibility of the protocols 984 IKEv2 allows private extensions and mechanisms (in the form of critical 985 and non-critical extensions and version numbers) for future versions of 986 the protocol to interoperate with the current version. 988 JFK has no extension mechanism and thus no notion of critical 989 extensions. 991 7. References 993 [CK02] Canetti and Krawczyk, "Security Analysis of IKE's Signature-based 994 Key-Exchange Protocol", Manuscript, 2002. 996 [PK00] Perlman and Kaufman, "Key Exchange in IPsec: Analysis of IKE", 997 IEEE Internet Computing Journal special issue on security solutions, Nov 998 2000. 1000 8. Summary of features 1002 8.2. Cryptographic features 1004 8.2.1 Identity protection: who is protected, kinds of attacks 1005 - No passive attack, allow active attack against initiator 1006 - Passive attack against responder, no active attack against initiator 1007 - No passive attack, allow active attack against responder 1009 8.2.2 Perfect forward secrecy (PFS) 1010 - Do PFS only when desired (to reduce computational overhead) 1011 - Always do PFS 1013 8.2.3 Authentication styles 1014 - Certificates 1015 - Shared secrets 1016 - Legacy authentication 1017 - Combination of the above 1019 8.2.4 Number of crypto operations 1020 - Different protocols require different numbers of different types of 1021 crypto operations to set up IPsec SAs and to rekey existing IPsec SAs 1023 8.2.5 Plausible deniability 1024 - Some protocols can make an exchange non-repudiable, others cannot 1026 8.2.6 Formal proofs of security 1027 - Some protocols have formal proofs of security, others do not 1029 8.3. Protocol mechanics 1031 8.3.1 DoS protection 1032 - Protect from clogging DoS attacks by verifying the initiator's 1033 existence with an extra round trip 1034 - Protect from clogging DoS attacks by forcing repetition of material 1035 in messages 3 and 4 while avoiding the "cookie jar attack" 1036 - Protect from UDP fragmentation attack by having lower-level system 1037 check for a value in the ip_id field of the UDP packets 1038 - Protect from UDP fragmentation attack by having lower-level system 1039 only accept UDP fragments from IP addresses from which it has received 1040 a valid cookie 1042 8.3.2 Number of messages in all scenarios 1043 - Different protocols require different numbers of messages in 1044 different scenarios 1046 8.3.3 Size of messages 1047 - Messages are fairly small unless they contain certificates 1049 8.3.4 Preferred ID for responder 1050 - Give an indication by the initiator to the responder as to what 1051 identity the responder should use to authenticate to the initiator 1052 - Don't do this 1054 8.3.5 Birth certificates 1055 - Let the other party know that you have crashed and restarted, 1056 forgetting all current SAs 1057 - Don't do this 1059 8.4. One or two phases 1061 8.4.1 Control channel vs. separate protocols 1062 - Have a second phase that is an explicit control channel for 1063 IPsec SAs 1064 - Control IPsec SAs through other mechanisms 1066 8.4.2 Creating multiple SAs for a single pair of entities 1067 - Create multiple IPsec SAs using only one Diffie-Hellman exchange and 1068 one authentication 1069 - Require a Diffie-Hellman exchange and authentication for each IPsec 1070 SA created 1072 8.4.3 Dead peer detection 1073 - Look at the last time the SA was used, and possibly send test traffic 1074 over the SA if it has timed out 1075 - Send an authenticated message in the SA and wait for the mandatory 1076 response 1078 8.4.4 SA deletion 1079 - Negotiate a new SA with an indicator that the SA cannot be used for 1080 IPsec traffic 1081 - Send a delete notification 1083 8.4.5 SA rekeying 1084 - Replace an old SA with a new one that has different keys 1086 8.4.6 Authenticated error messages 1087 - Protect error messages during SA setup when possible 1089 8.4.7 Authenticated informational messages 1090 - Allow informational messages to be authenticated when possible 1091 - Don't specify informational messages 1093 8.5. SA creation style 1095 8.5.1 Cryptographic agreement 1097 8.5.1.1 Agreement of key exchange keys 1098 - Offer many options and allow the other party to pick the options 1099 it likes best 1100 - Offer only one option and fail if the other side doesn't like it 1102 8.5.1.2 Agreement of IPsec SA cryptographic algorithms 1103 - Offer many options and allow the other party to pick the options 1104 it likes best 1105 - Offer only one option and renegotiate if the other side doesn't like 1106 it 1108 8.5.2 Scope of proposals 1109 - Offer multiple defined suites 1110 - Offer sets of individual options 1112 8.5.3 SPD entries 1113 - Offer multiple selectors, with each selector has a source port; a 1114 destination port; and either a range or addresses, a subnet, or a 1115 single address 1116 - Offer a single selector, with the selector having multiple address 1117 ranges and multiple port ranges 1119 8.6. Wire protocol issues 1121 8.6.1 Message encoding 1122 - Encode similar to IKEv1 1123 - Use tag-length-value encoding 1125 8.6.2 Port number 1126 - Reuse port 500 from IKEv1 1127 - Use a different port 1129 8.6.3 Future versions of the protocols 1130 - Specify version numbers to allow upgrading of versions 1131 - Only allow one version 1133 8.6.4 Code-preservingness 1134 - Base the protocol on IKEv1 1135 - Create an entirely new protocol 1137 8.6.5 Extensibility of the protocols 1138 - Allow extensions 1139 - Allow extensions and allow some of them to be marked as critical 1140 - Don't allow extensions 1142 9. Features in the IKE requirements document 1144 draft-ietf-ipsec-sonofike-rqts-00.txt describes the requirements for 1145 the successor to IKE. A large part of that document is a description of 1146 the scenarios in which IKE is used. The scenarios highlight some 1147 of the items to be considered during protocol design. 1149 The highlights from that document are quoted here linked to the relevant 1150 features from above. The highlights appear bracketed with "<<< >>>", and 1151 the links to the features in this document are bracketed with "[[[ ]]]". 1152 This section assumes that the reader has read 1153 draft-ietf-ipsec-sonofike-rqts-00.txt and is matching the text here from 1154 the scenarios there. 1156 9.1 Virtual Private Network Site-to-Site Tunnels 1158 <<>> [[[4.1]]] 1163 <<>> [[[4.2]]] 1170 <<>> [[[5.3]]] 1175 <<>> 1177 [[[6.5]]] 1179 <<>> [[[4.2]]] 1184 <<>> [[[2.3]]] 1189 <<>> [[[2.1]]] 1192 9.2 Secure Remote Access 1194 <<>> [[[3]]] 1200 <<>> [[[4.2]]] 1205 <<>> [[[4.2]]] 1209 <<>> [[[none]]] 1214 <<>> 1216 [[[6.5]]] 1218 <<>> [[[4.2]]] 1223 <<>> [[[2.3]]] 1226 <<>> [[[2.3]]] 1230 <<>> [[[2.3]]] 1237 9.3 End-to-End Security 1239 <<>> 1241 [[[6.5]]] 1243 <<>> [[[4.2]]] 1248 <<>> 1249 [[[2.1]]] 1251 9.4 IP Storage 1253 <<<[ietf-ips-security-xx.txt] discusses resource constraints, calling 1254 out the size for both code footprint and data as the most important 1255 criteria.>>> [[[6]]] 1257 <<>> [[[6.5]]] 1263 9.5 PPVPN/MPLS 1265 <<>> [[[6.5]]] 1269 10. Acknowledgements 1271 Most of the material in this document comes from many of the authors of 1272 the JFK and IKEv2 proposals, and from the current versions of the 1273 proposals themselves. Although many of these people reviewed earlier 1274 versions of this document, all errors in the document are the 1275 responsibility of the editor. 1277 11. Editor's Address 1279 Paul Hoffman 1280 VPN Consortium 1281 127 Segre Place 1282 Santa Cruz, CA 95060 USA 1283 paul.hoffman@vpnc.org