idnits 2.17.1 draft-ietf-ipsec-properties-02.txt: -(273): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(277): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(710): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 11 instances of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2002) is 7971 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: 'ISAKMP' is mentioned on line 96, but not defined == Missing Reference: 'Fluhrer' is mentioned on line 211, but not defined ** Obsolete normative reference: RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'Beaulieu' -- Possible downref: Non-RFC (?) normative reference: ref. 'Counterpane' -- Possible downref: Non-RFC (?) normative reference: ref. 'Huttunen' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'Krawczyk' == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-02 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Andrew Krywaniuk 3 IP Security Working Group Alcatel 4 Internet Draft June 30, 2002 6 Security Properties of the IPsec Protocol Suite 7 9 Status of this Memo 11 This document is a submission to the IETF Internet Protocol Security 12 (IPsec) Working Group. Comments are solicited and should be addressed 13 to the working group mailing list (ipsec@lists.tislabs.com) or to the 14 editor. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or made obsolete by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 This document is a product of the IETF's IPsec Working Group. 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document describes the "security properties" of the IPsec 42 architecture and protocols, including ESP, AH, and IKE. 44 By documenting these properties, we aim to provide a guide for users 45 who wish to understand the abilities and limitations of the IPsec 46 protocol suite. We also hope to provide motivation for future work in 47 this area. 49 Table of Contents 51 1. Introduction.................................................4 52 2. Specification of Requirements................................4 53 3. General Approach.............................................4 54 3.1 Terminology...................................................5 55 4. Confidentiality..............................................5 56 4.1 Encryption Coverage...........................................5 57 4.2 Traffic Flow..................................................6 58 4.3 Cryptographic Mumbo-Jumbo.....................................6 59 4.4 Identity Protection...........................................7 60 5. Authentication...............................................8 61 5.1 Authentication Coverage.......................................8 62 5.2 Cryptographic Mumbo-Jumbo.....................................9 63 5.3 Host Authentication...........................................9 64 5.4 User Authentication..........................................10 65 6. Key Generation..............................................10 66 6.1 Rekeying.....................................................10 67 6.2 Independence of Keying Material..............................11 68 6.3 Cryptographic Mumbo-Jumbo....................................11 69 6.4 Perfect Forward Secrecy......................................12 70 6.5 Weak Keys....................................................13 71 6.6 Ad Hoc Groups................................................13 72 6.7 Key Strength.................................................14 73 7. Denial of Service...........................................14 74 7.1 ESP Packet Spoofing..........................................14 75 7.2 Memory Consumption...........................................15 76 7.3 Time Consumption.............................................15 77 7.4 Synchronization..............................................16 78 8. Miscellaneous...............................................16 79 8.1 Replay.......................................................16 80 8.2 Repudiation..................................................17 81 9. IANA Considerations.........................................18 82 10. Security Considerations.....................................18 83 11. Notes.......................................................18 84 12. References..................................................18 86 1. Introduction 88 Before you can know where you are going, you must first know where 89 you have been. 91 An analysis of IPsec by Counterpane researchers [Counterpane] 92 complained that IPsec has a lack of clearly expressed design goals, 93 and shows evidence of design by committee. We concur with these 94 observations, in the sense that some features appear incomplete or 95 are not used for the purpose for which they were intended. Part of 96 the confusion comes from the fact that [ISAKMP] defines a large set 97 of features; [IKE] only uses a subset of these features, but it does 98 not clearly state which ones. 100 The IPsec working group has undertaken a project to redesign the IKE 101 protocol in order to "simplify" it; there has also been talk of 102 reducing the number of IPsec usage permutations by deprecating AH 103 and/or tunnel mode. We believe that it is inappropriate to redesign a 104 protocol until the existing protocol is well documented. 106 Perhaps IPsec is well understood by some, but frequent questions on 107 the developers' mailing list confirm that one cannot become an IPsec 108 expert merely by reading the RFCs. Much valuable information is 109 buried deep in the list archives or in the minds of its designers. 111 Other protocol designers depend on IPsec for transport security; if 112 they cannot clearly understand what security properties IPsec 113 provides, they may use it incorrectly. The same could be said for 114 IPsec users. 116 2. Specification of Requirements 118 This document shall use the keywords "MUST", "MUST NOT", 119 "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 120 "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They 121 are to be interpreted as described in [Bradner]. 123 3. General Approach 125 This document is not an introduction to IPsec, nor is it cryptography 126 101. It is merely a description of the security properties associated 127 with one particular suite of security protocols. 129 Our intention is merely to document what exists today. In the few 130 places where we discuss alternatives, they relate specifically to 131 known issues concerning the security properties of IPsec. 133 Some of this information in this memo is already available in the 134 RFCs, some is not; this document collects it all into one place. 135 Sometimes the RFCs are ambiguous, for example in the case where a 136 feature is described in ISAKMP, but not used in IKE; here, we attempt 137 to resolve that ambiguity. 139 The amount of space devoted to a particular property does not 140 necessarily reflect on the importance of that property in the context 141 of IPsec. For example, identity protection is discussed in some 142 detail, even though its applicability is limited, precisely because 143 the issues are complicated. 145 3.1 Terminology 147 For the purposes of this document, "the IPsec protocol suite" shall 148 consist of RFCs 2401 through 2412, plus any other documents which we 149 consider relevant. We assume the use of ESP and/or AH SAs, negotiated 150 by IKE, and used according to the rules prescribed by [ARCH]. We do 151 not cover specialized applications, such as multicast and alternate 152 key exchange protocols. 154 The "security properties" we discuss include properties such as 155 confidentiality, authentication, and resistance to Denial of Service 156 (DoS). We only attempt to define properties that can be measured 157 objectively. As such, we do not discuss such issues as technical 158 merit, ease of use, or level of complexity. The document focuses more 159 on IKE than on ESP/AH, since IKE appears to have more intricate 160 security properties. 162 4. Confidentiality 164 Traffic confidentiality is one of the main reasons for using IPsec. 165 For better or for worse, IPsec provides two completely independent 166 implementations of encryption: one in IKE and one in ESP. 168 Obviously, in a network scenario not all data can be encrypted. 169 Otherwise, it would be impossible to create SAs and route traffic. 170 What data is encrypted and what data is not is a matter of some 171 interest. 173 4.1 Encryption Coverage 174 ESP encryption covers protocol layers 4 and above (and, potentially, 175 some of the so-called layer 3.5 protocols). The IP header and any 176 additional lower-level headers are sent in the clear. If tunnel mode 177 is used, the data in the inner header can be concealed, but some of 178 that information will be copied into the outer header anyway, since 179 it is needed for routing. 181 In IKE, a large portion of the data must be sent in the clear, simply 182 to bootstrap the negotiation. For example, an attacker can see which 183 transforms are being used in IKE. (Modern cryptological thinking 184 postulates that revealing this kind of data is not a security 185 weakness.) Once the key exchange is complete, subsequent IKE data is 186 encrypted. 188 4.2 Traffic Flow 190 ESP hides such information as the layer 4 port and protocol, however 191 some information about the traffic flow is leaked due to packet 192 sizes. ESP allows an implementation to add padding to packets in 193 order to conceal packet lengths; this is constrained to a maximum of 194 255 bytes. A future version of ESP may allow extra padding, and even 195 completely bogus packets. 197 In tunnel mode, when an edge device is applying the encryption, a 198 snooper is generally unable to determine which end nodes the router 199 is proxying for. This situation is improved if a single tunnel mode 200 SA is used to carry all traffic between two protected networks, 201 rather than using separate SAs for each traffic flow. 203 Sending multiple traffic flows on a single SA allows a privileged 204 attacker who is behind one of the IPsec gateways to launch an 205 adaptive chosen plaintext attack against the encryption key, thus 206 compromising all traffic sent between the two networks. However, 207 modern ciphers are assumed to be resistant to this type of 208 cryptanalysis. The IPsec RFCs (e.g. [DES]) suggest that you may reuse 209 a block of ciphertext from another packet as an IV, but it is better 210 to use a completely random IV for each packet because of the attack 211 described in [Fluhrer]. 213 4.3 Cryptographic Mumbo-Jumbo 215 Encryption in ESP and ISAKMP is typically deployed using the CBC 216 (Cipher Block Chaining) mode of operation. CBC uses the previous 217 block as an IV to the next block, which ensures that the IV is always 218 pseudorandom. A random IV makes it next to impossible that two blocks 219 of ciphertext will be the same. 221 CBC does not have the infinite error propagation property, which 222 means that it does not protect against known-plaintext analysis. This 223 is not to say that IPsec is vulnerable to known-plaintext attacks; 224 all it means is that the chosen cipher must itself be secure against 225 these attacks (as all modern ciphers are). Other modes of operation 226 could be used and they would have different security properties. 228 In general, encryption should not be used as a substitute for 229 authentication, although some new modes propose to combine the two. 230 With block ciphers, an attacker is generally prevented from making a 231 predictable change to the plaintext. This is not necessarily true for 232 other types of ciphers, such as stream ciphers. 234 4.4 Identity Protection 236 IKE main mode purports to deliver a feature called identity 237 protection, which means that the identities are not sent in the 238 clear. This it does, but with some caveats. In order to complete the 239 authentication, one side must reveal its identity first. In main mode 240 with public key signatures, the initiator reveals his identity first; 241 therefore, an active attacker who impersonates the responder can 242 determine the initiator�s identity. 244 Even when the identity is protected, a host may need to send a 245 "certificate request" in order to force the sender to include a 246 certificate in a later message. The certificate request payload 247 typically contains the name of the CA to be used, which reveals some 248 limited information about the sender's identity to a passive snooper. 250 This limited form of identity protection can only be used with public 251 key signature authentication. Due to the particular construction of 252 SKEYID_e in the case of preshared keys, the identity must be sent in 253 the clear in order to generate the encryption key. The drawback is 254 that mobile clients using preshared keys don�t get identity 255 protection. We recommend that this be fixed in a future version of 256 IKE. 258 In the case of public key encryption, both identities are protected, 259 but protection for the responder is weak for two reasons: Firstly, in 260 order for the initiator to know where to send the packet, the 261 responder's identity must be linked to an IP address (this is true of 262 all the authentication methods). Secondly, in the case where the 263 initiator sends a hash of the identity, this hash is an identity- 264 equivalent, in the sense that it uniquely correlates to an identity. 265 This means that a snooper can correlate multiple SAs negotiated with 266 the same identity because the hash will be the same. Also, if the 267 snooper can guess which possible identities might correspond to the 268 responder, he can test his assumption because the hash does not 269 contain any secret material. 271 In many cases, the IP address of the host implicitly describes the 272 identity (e.g. the identity can be found by a DNS lookup); in these 273 cases, identity protection is moot. Since the initiator�s identity is 274 less likely to be implicit from an IP address than the responder�s 275 is, it�s a shame that signature-based authentication provides higher 276 protection to the responder�s id. On the other hand, it is much 277 easier to mount an attack against the responder�s id than against the 278 initiator�s. 280 In the case where the identity is sent in the clear, it could be a 281 random binary string; IKE allows the transmission of unformatted 282 identities using the ID_KEY_ID type. However, it would be desirable 283 that the obfuscated identity not be an identity-equivalent, so that 284 multiple logins by the same user could not be correlated. IKE does 285 not provide this feature. 287 IKE also provides a feature called Identity PFS, in which every quick 288 mode exchange uses a new phase 1 SA. [IKE] doesn�t specify why one 289 might want to do this, but it does theoretically allow the host to 290 delete the identity of the peer from memory, thus ensuring that it is 291 not revealed even if the physical security of the box is compromised. 292 (Although it may be difficult to apply policy rules if the identity 293 of the peer is not remembered.) 295 5. Authentication 297 Traffic encryption is not much use if the user at the other end is 298 unknown or if the data could be forged. IPsec provides several types 299 of authentication: packet authentication, exchange authentication, 300 and host authentication. 302 5.1 Authentication Coverage 304 Each AH packet contains an HMAC; likewise for ESP, assuming that ESP 305 authentication is being used. ESP authentication covers the entire 306 payload of the IP packet. AH also covers the non-mutable fields in 307 the header. 309 When tunnel mode is being used, AH has the same effective coverage as 310 ESP, because the outer header is merely a transient routing header. 311 If AH is being used to ensure that the header of the IP packet 312 remains uncorrupted during transit, this is really only useful if any 313 of the intermediate routers which interpret the header are also privy 314 to the AH key. 316 The IKE phase 1 hash covers sufficient material to bind the identity 317 of the peer to unforgeable session data, such as the DH secret. 318 However, phase 1 does not have full authentication coverage (a 319 shortcoming which should be fixed in a future version of the 320 protocol). Consequently, optional payloads, such as notify messages 321 and vendor ids, are not authenticated by the exchange. Even if these 322 payloads are part of an encrypted message, an attacker can still 323 corrupt them without being detected. 325 Phase 2 messages are fully authenticated by an HMAC, with the 326 exception of the ISAKMP header. Modifying the commit bit (in the 327 header) is a potential DoS vulnerability. 329 5.2 Cryptographic Mumbo-Jumbo 331 The HMAC that is used for packet authentication is truncated. This 332 limits the amount of information an attacker can gather by analyzing 333 the output. 335 The HMAC functions that are used in IKE are also used as PRFs. 336 Therefore, the output of the HMAC should always appear statistically 337 random. Uri Blumenthal has stated that HMAC has never been proven to 338 be an adequate PRF, although we have no specific reason to believe it 339 isn't. [IKE] allows alternate PRFs to be used, but IANA has yet to 340 assign any. 342 5.3 Host Authentication 344 Depending on the chosen authentication method, the host is 345 authenticated in IKE phase 1 by the generation of a public key 346 signature, an HMAC signature, or by a proof of possession of a 347 decryption key. The obvious man in the middle attack is thwarted by 348 including the Diffie-Hellman public keys in the HASH_I/HASH_R values 349 which are generated, signed, or encrypted. 351 When authenticating with preshared keys, the strength of the 352 authentication is based on the effective entropy of the secret. When 353 authenticating with public key encryption, the strength of the 354 authentication is based on the length of the public key. Likewise for 355 public key signatures, but as an additional wrinkle the strength of 356 the MAC algorithm is also important. Since all the inputs to the MAC 357 are sent on the wire except possibly the IDs (which can be guessed), 358 the strength of the PK signature is limited by the difficulty of 359 finding a collision in the MAC function. 361 5.4 User Authentication 363 While IKE provides a number of ways to identity the peer, there is no 364 standardized interface to communicate this identity up to the 365 application layer. Ultimately, all traffic-level authorization must 366 be applied to IPs and ports. If an application doesn't have a 367 mechanism to extract the authenticated id from the IKE process then 368 the application layer will have to perform its own, separate 369 authentication stage. 371 The upside of this limitation is that a simple username/password 372 protocol is obviously more secure when it is sent across an ESP 373 tunnel than when it is performed in the clear, especially since the 374 use of IKE authentication rules out the possibility of a man-in-the- 375 middle attack. 377 6. Key Generation 379 Key generation is the most important function of the quick mode 380 exchange. Key generation is also part of phase 1, since ISAKMP needs 381 its own session keys. 383 The properties of key generation are more complicated and harder to 384 explain than most other security properties. Nonetheless, we will 385 make an attempt. 387 6.1 Rekeying 389 One purpose of rekeying is to thwart cryptanalysis by limiting the 390 amount of ciphertext that an attacker can examine, but the main 391 purpose is simply to limit the consequences of a compromised key. 393 [IKE] defines two different types of lifetimes: time-based and 394 traffic-based. Time-based lifetimes protect against the possibility 395 that a key will be compromised by brute force; traffic-based 396 lifetimes guard against attacks based on gathering ciphertext. Both 397 lifetimes limit the amount of data that is vulnerable if a key is 398 compromised. 400 [IKE] also proposes a third lifetime for phase 1 SAs, based on the 401 number of quick modes used with this SA. The justification given for 402 this lifetime is suspect because a PRF can provide keying material 403 for a large number of random keys, and these keys are not revealed to 404 an attacker for analysis. Nonetheless, this lifetime makes sense 405 because it correlates strongly with the volume of IPsec traffic. 407 When using strong ciphers with small block sizes (e.g. 3DES), the use 408 of rekeying to thwart cryptanalysis becomes more important. Due to 409 the birthday paradox, an attacker has a statistically significant 410 chance of detecting a collision in the output stream after he 411 collects about 2^(block size/2) blocks of encrypted data. If each 412 block is 64 bits, this works out to 32 gigabytes of encrypted 413 traffic. 415 6.2 Independence of Keying Material 417 The keys negotiated by IKE are derived from the Diffie-Hellman 418 secret, some random session data, and possibly a preshared key. This 419 information is run through a pseudo-random function in order to 420 generate a key. 422 The keys generated by IKE are not derived directly from each other, 423 nor are they reused for multiple purposes. Each encryption or 424 authentication key is created by an HMAC-based PRF, which is keyed by 425 a shared primitive key that is never sent on the wire. 427 The PRF used in IKE must be a strong one-way function. This means 428 that even if one key is compromised, other keys created from the same 429 DH secret cannot be cracked unless the PRF is reversed. 431 In all cases, entropy for the key derivation is added explicitly by 432 means of a random nonce. The size of the nonce is not all that 433 important, but it should be larger than the square of the number of 434 keys that will be derived from the raw key material. (It does no good 435 to make the nonce larger than the HMAC output.) 437 6.3 Cryptographic Mumbo-Jumbo 439 All the components of the key material, including the DH secret are 440 HMAC'ed before they are used. This ensures that any analytical attack 441 on the key exchange function will not directly translate into an 442 analytical attack on the key generation function. 444 Wherever possible, the SKEYID is derived from a secret value other 445 than g^xy (this is not possible in the case of public key 446 signatures). In the case where keys are generated from each other 447 (e.g. SKEYID_d -> SKEYID_a -> SKEYID_e), g^xy is reintroduced at 448 every stage so that the key is always directly based on a shared 449 primitive. One exception to this rule is noted below in section 6.7. 451 A more detailed description of the motivation for SKEYID construction 452 is given in [Krawczyk]. Whether or not this elaborate derivation was 453 entirely necessary is a contentious issue. 455 6.4 Perfect Forward Secrecy 457 The description of PFS in IKE is complicated because there are 458 actually two different types of forward secrecy. PFS of the first 459 kind means that compromise of the long-term credential (e.g. an RSA 460 key) will not reveal any session keys. PFS of the second kind means 461 that an active attack on the system (e.g. the box is hacked) will not 462 reveal all of the expired session keys. 464 The original requirement for the IPsec WG was PFS of the first kind 465 (an earlier protocol called SKIP did not have this property). IKE 466 phase 1 automatically provides this feature because the key is based 467 on a per-session DH secret. This is the most important type of 468 forward secrecy, and it is not optional in IKE. Therefore, in the 469 context of IKE, the term PFS usually refers to the second type of 470 forward secrecy. 472 PFS of the second kind can be used to reduce the window of 473 vulnerability even further. In the case of a break-in, it is 474 desirable that only a limited amount of data should be compromised; 475 we call this the forward secrecy window. If the forward secrecy 476 window is 1 hour, then no session key should ever be kept in memory 477 for more than 1 hour after it is first used (and this includes the 478 key material from which this session key was derived). 480 Unfortunately, [IKE] does not explain the intended usage of the PFS 481 feature. I suspect that the intention was that it should be off for 482 the first quick mode exchange(s) and on for subsequent exchanges 483 (e.g. rekeys). Why? Because you may have deleted SKEYID_D from memory 484 in order to reduce the consequences of a break-in. In practice, most 485 people implement PFS as an on/off setting, and the user must 486 configure which setting is to be used for each connection. 488 Note that PFS does not significantly increase the security of IKE 489 against long-term cryptanalysis. An attacker who can crack the phase 490 1 DH exchange can presumably crack a second DH exchange with 491 equivalent work. And deriving each session key from a separate shared 492 primitive is overkill because independence of keying material is 493 already guaranteed by using a strong PRF. If you want to increase 494 your resistance to cryptanalysis, a better solution would be to 495 lengthen the modulus of the phase 1 DH group and the block size of 496 the PRF. 498 What PFS does provide is a faster alternative to phase 1 rekeying. 499 Repetition of the authentication stage may detect if a user's 500 certificate is revoked, but this could be accomplished by other means 501 (e.g. periodic CRL retrieval). The only case where this would not be 502 possible is identity PFS, where the host deletes the peer's identity 503 after the SAs are created. IKE also specifies a method for bulk 504 negotiation of keys. This can be used to accomplish PFS without 505 further DH negotiations because it allows the peers to rekey even 506 after SKEID_D has been deleted. (In practice, this feature is not 507 widely implemented.) 509 Whether or not phase 1 rekeying actually provides any additional 510 security over PFS depends on how much information an attacker can 511 gather if the box is physically compromised or otherwise hacked into. 512 If the box is entirely compromised and the attacker can learn the 513 host's RSA private key (or preshared key table), then all is lost and 514 the host will be insecure until the private key is replaced. If the 515 compromise is less atomic, and the attacker merely discovers SKEYID 516 (or, more precisely, both SKEYID_E and SKEYID_A), then he can act as 517 a man in the middle during subsequent quick mode negotiations. 519 6.5 Weak Keys 521 IKE mandates the use of weak key checks. In practice, this does not 522 provide a significant benefit because weak keys are very unlikely to 523 be generated randomly (and an attacker won�t be able to detect them 524 if they are used). 526 6.6 Ad Hoc Groups 528 IKE allows the negotiation of ad hoc groups, either during phase 1, 529 or after phase 1 using new group mode. To use new group mode, an 530 implementation would have to trust the phase 1 group enough to use it 531 in the short term, but not trust it for long term security. 533 According to [IKE], implementations are meant to verify the primality 534 of a proposed group before using it. The implications of this 535 statement are interesting. Presumably, this is to detect 536 implementation errors in the peer, rather than malfeasance. 537 Otherwise, it would also be pertinent to send an attribute describing 538 the algorithm by which the group was chosen (e.g. a seed, which is 539 hashed, and then used as the starting point in a search for a prime). 541 New Group mode is not often used in practice, but it provides a 542 theoretical extra level of security. If everyone uses the same group, 543 then an attacker can build a large database of known keys for that 544 group, thus amortizing the cost of a brute force search over many 545 keys. In practice this attack is not as devastating as it sounds, 546 since Diffie-Hellman keys are already large enough to defend against 547 birthday attacks, such as the Pollard-Rho method. 549 6.7 Key Strength 551 All keys in IKE are derived from a PRF output. A PRF provides a 552 theoretically completely random key. Assuming that the cipher 553 algorithm is strong against analysis, the most significant attack is 554 brute force. Therefore, the strength of a key is approximately 555 proportional to the key length. 557 But the length of a key is not the only factor in determining its 558 strength. The length of the encryption key must be large enough to 559 thwart a direct attack, but the length of the DH secret used to 560 generate the key is also important, as described in [Orman]. 562 [Beaulieu] notes that a third factor comes into play if one attempts 563 to derive a large encryption key from a small hash output. As 564 described in [IKE], the key material for an ISAKMP SA may be 565 "stretched" using the following algorithm: 567 Ka = K1 | K2 | K3 569 and 571 K1 = prf(SKEYID_e, 0) 572 K2 = prf(SKEYID_e, K1) 573 K3 = prf(SKEYID_e, K2) 575 This definition does not fully utilize the entropy of the DH secret 576 and further constrains the strength of the key to the length of the 577 HMAC output. A similar limitation applies to the keys generated by 578 quick mode when PFS is not being used. 580 7. Denial of Service 582 IPsec provides some protection against denial of service attacks but 583 also creates some new holes. 585 7.1 ESP Packet Spoofing 587 IPsec ESP/AH authentication provides strong protection against DoS 588 because any spoofed packets will be identified and discarded. The 589 time lost to DoS is limited to the length of time required to verify 590 an HMAC. ESP without authentication has less DoS protection because 591 encryption is generally slower than authentication; also, with the 592 CBC mode of operation, it is quite easy to form a corrupt packet 593 which will pass ESP processing. 595 IKE does not dictate how SPI values should be chosen, but many 596 implementations choose SPIs randomly. The fact that SPIs are random, 597 and therefore unknown to an unprivileged attacker, provides 598 additional protection against spoofing. If an authenticated user 599 sends encrypted packets which cause DoS, the source of the attack 600 will be obvious. 602 However, packets that are sent in the clear can still cause DoS. 603 Obviously, some packets, most notably the first few packets of IKE, 604 must still be sent in the clear. 606 7.2 Memory Consumption 608 ISAKMP reuses the stateless cookie idea from Photuris, but IKE does 609 not provide a mode in which they can be used. (Anti-clogging cookies 610 are meant to prevent state clogging attacks akin to the TCP SYN 611 attack.) 613 There are multiple ways to extend IKE to allow stateless operation. 614 One method is to add an optional cookie exchange when a DoS attack is 615 detected. Another technique is to repeat the information from message 616 1 in message 3 of the exchange. [Huttunen] describes a proposal for 617 optimizing this technique with the use of an encrypted "state 618 payload." 620 7.3 Time Consumption 622 The key exchange and public key authentication operations of IKE 623 phase 1 provide the greatest vehicle for DoS. An attacker can 624 generate a fake key exchange or signature payload, forcing the 625 responder to perform a time-consuming modular exponentiation 626 operation (without significant work by the attacker). 628 IKE provides some protection against this attack in main mode by 629 requiring an initial cookie exchange. Even though the cookie cannot 630 be used for stateless operation, it performs a similar function as a 631 nonce, proving the liveness of the initiator. 633 Aggressive Mode is vulnerable because the signature must be generated 634 before the cookie exchange is complete. The DH exponentiation can be 635 delayed until the third packet is received, but at the cost of 636 latency. Quick mode with PFS has a similar vulnerability if the 637 exchange is replayed; again, the attack can be avoided (at the cost 638 of latency) by delaying the computation. 640 These comments mainly apply to cases where authentication is tightly 641 bound to authorization. In cases (e.g. a publicly accessible server 642 on the Internet) where authorization is not important and the 643 authentication stage is performed merely to ensure the 644 confidentiality of the negotiated key, the user is essentially 645 unauthenticated and he is free to launch any of a myriad of DoS 646 attacks which we won't describe here. 648 IKE does not provide explicit protection against DDoS zombies. 649 Countermeasures such as client puzzles exist, but there is no 650 mechanism for using them with IKE. 652 7.4 Synchronization 654 The lack of full authentication coverage in some IKE messages can 655 allow an active attacker to exploit synchronization issues. For 656 example, he can set the commit bit in the ISAKMP header, causing one 657 side to wait for a CONNECTED notification that may never come. 659 Alternately, he could add a vendor id to an IKE phase 1 message that 660 would cause one side to enable a non-standard behaviour. Since the 661 vendor id is not authenticated, this could cause one host to behave 662 in a non-interoperable manner. 664 An attacker can potentially prevent the delivery of delete 665 notifications or forge invalid SPI/cookie messages, which could cause 666 one side to delete an SA or to believe that an SA has been deleted by 667 the peer. By forcing a connection to be repeatedly torn down, the 668 attacker can cause a host to waste CPU in frequent renegotiations, to 669 deny service to a legitimate user, or to waste memory maintaining an 670 SA after the peer has disconnected. 672 8. Miscellaneous 674 There are a few additional security properties that do not fall into 675 the above categories. 677 8.1 Replay 678 Replay of ESP data is a vulnerability that depends on the upper layer 679 protocol. Many session-based protocols will reject replayed data. ESP 680 and AH packets contain an anti-replay counter which may optionally be 681 checked. This counter is not time-based, so it does not prevent an 682 attacker from intercepting all packets, storing them, and then 683 selectively delivering them at a future time. Replay protection can 684 only be used in conjunction with packet authentication. 686 ISAKMP does not provide explicit replay protection. Replay protection 687 is accomplished in some exchanges (main mode, aggressive mode, quick 688 mode) by sending a random value (e.g. a nonce) to the peer and having 689 them return that value in a subsequent message. This technique is not 690 possible with 1 or 2 message exchanges (new group mode, info mode). 691 Also, replaying a quick mode exchange with PFS can cause DoS, as 692 noted in section 7.3. 694 It has been suggested that an implementation needs to remember all 695 message ids it receives in order to avoid replayed messages; we 696 believe that a better general-purpose solution is to add a replay 697 counter to ISAKMP packets. A logical way to do this would be to 698 simply convert the random message id into a counter (the randomness 699 of the message id is only needed for collision-resistance, and not 700 for any essential security feature). 702 8.2 Repudiation 704 Authentication using either pre-shared keys or public key encryption 705 has the repudiation property. Either side is capable of forging the 706 entire exchange; therefore there is no reliable way to prove that the 707 transaction took place. 709 Authentication using public key signatures does not provide full 710 repudiation, but it doesn�t provide explicit non-repudiation either. 711 When Bob generates a signature, it proves that he talked to somebody, 712 but not necessarily Alice. It is possible for Alice to encode a 713 signed hash of her identity into a payload that will be signed by Bob 714 during the course of the exchange. This would prove that Bob talked 715 to Alice (or someone colluding with Alice), although not necessarily 716 on purpose. Note that this does not prove to a third party that any 717 data sent with the negotiated keys is genuine. 719 So for all intents and purposes, IKE provides repudiation of the 720 phase 1 exchange, no matter which mode of authentication you use. 722 9. IANA Considerations 724 This document does not require any assigned numbers. 726 10. Security Considerations 728 The focus of this document is security; hence security considerations 729 permeate this specification. 731 11. Notes 733 The authors would like to thank Radia Perlman, Olivier Paradiens, and 734 Angelos Kerymitis for their comments which were incorporated into 735 this draft. 737 12. References 739 [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the 740 Internet Protocol", RFC 2401, November 1998. 742 [Beaulieu] Beaulieu, S., "Generating 3DES keys from SKEYID_e", IPsec 743 mailing list, http://www.vpnc.org/ietf- 744 ipsec/00.ipsec/msg01288.html, July 2001. 746 [Bradner] Bradner, S., "Key Words for use in RFCs to indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [Counterpane] Ferguson, Niels, and Schneier, Bruce, "A Cryptographic 750 Evaluation of IPSec", http://www.counterpane.com, April 1999. 752 [DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher 753 Algorithm With Explicit IV", RFC 2405, November 1998 755 [Fluhrer]Fluhrer, S., "Suggested modification to AES privacy draft", 756 IPsec mailing list, http://www.vpnc.org/ietf-ipsec/mail- 757 archive/msg02598.html, January 2002. 759 [Huttunen] Huttunen, A., "Re: Future ISAKMP Denial of Service 760 Vulnerablity Needs Addressing", IPsec mailing list, 761 http://www.vpnc.org/ietf-ipsec/00.ipsec/msg00160.html, 762 January 2000. 764 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 765 RFC 2409, November 1998 767 [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and J. Turner, 768 "Internet Security Association and Key Management Protocol 769 (ISAKMP)", RFC 2408, November 1998. 771 [Krawczyk] Krawczyk, H., "Rationale for the definitions of SKEYID", 772 IPsec mailing list, http://www.vpnc.org/ietf-ipsec/mail- 773 archive/msg00844.html, June 2001. 775 [Orman] Orman, H., Hoffman, P., "Determining Strengths for Public 776 Keys Used For Exchanging Symmetric Keys", draft-orman-public- 777 key-lengths-02.txt, March 19, 2001 (work in progress) 779 Authors' Addresses 781 Andrew Krywaniuk 782 Alcatel Networks Corporation 783 600 March Road 784 Kanata, ON 785 Canada, K2K 2E6 786 +1 (613) 784-4237 787 E-mail: andrew.krywaniuk@alcatel.com 789 The IPsec working group can be contacted via the IPsec working 790 group's mailing list (ipsec@lists.tislabs.com) or through its chairs: 792 Theodore Y. Ts'o 793 tytso@MIT.EDU 794 Massachusetts Institute of Technology 796 Barbara Fraser 797 byfraser@cisco.com 798 Cisco Systems 800 Expiration 802 This document expires January 30th, 2003.