IKE/ISAKMP
considered harmful

by William Allen Simpson
<[email protected]>

William Allen Simpson is a very independent consultant, involved in wireless, IP router, network design, game networking, real-time data collection and distribution, and many other projects. He has been known as "The DayDreamer" on networks for over 20 years.



This article may be seen as quite controversial. Some people are sure to object to the tone. Publishing (or even pointing to) code that exploits security problems is always touchy. However, it is undeniable that Denial-of-Service attacks are real and important in the day-to-day work of many USENIX members. The USENIX Association is not directly involved in the IETF processes, although obviously many of our members are. The USENIX Association does not endorse the contents of this article, but we thought it important that it be given public scrutiny.

Greg Rose, Vice-President, USENIX Board of Directors


After enduring seven years of political and marketing maneuvering, the Internet Engineering Task Force (IETF) has adopted a Proposed Standard for generating dynamic security session-keys between users. Unfortunately, the IKE/ISAKMP combination is fraught with egregious fundamental design flaws. This document details a few of the more easily exploitable problems.

The Internet Security Association and Key Management Protocol (ISAKMP) [RFC-2408] framework was originally developed by the United States National Security Agency (NSA) with an ASN.1 syntax from the initial Fortezza (used in the nefarious Clipper chip). The Internet Key Exchange (IKE) [RFC-2409] is a session-key exchange mechanism that fits alongside Fortezza under its own "Domain of Interpretation" (DOI).

Rather than protecting network resources from attack, IKE/ISAKMP can actually expose the network to danger. This article details a few of the more easily exploitable problems, including severe denial-of-service attacks, interoperability issues, privacy-information leaking, and other egregious fundamental design flaws.

The author was administratively prevented from publishing this information — as well as the earlier, more robust, Photuris specification [RFC-2522] — in the IETF, until after publication of IKE/ISAKMP. In the meantime, vast sums of money have been wasted implementing and testing the overly complicated and poorly specified IKE/ISAKMP.

It is hoped that this document will stimulate discussion.

Security Summary

Any site that has deployed IKE/ISAKMP should revert to manual keying (or to Photuris where available) to prevent the denial-of-service attacks described.

The egregious flaws discussed were observed by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. It is anticipated that flaws will be more thoroughly analyzed in subsequent papers.

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 design criteria 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]

Cookie Crumb Attack

ISAKMP replaces the time-variant secret of Photuris with a date and time stamp [RFC-2408, page 20]. This requires state in the Responder and leaves a "cookie crumb" for every connection attempt.

Many implementations simply ignore (zero out) the Initiator cookie and depend on the stateful Responder cookie.

The cookie crumb attack is belatedly acknowledged in the specification, but is described with inadequate hand-waving:

. . . 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]

That text demonstrates utter failure to understand the rationale for the Photuris anti-clogging mechanism design, despite several repetitions in the Photuris specification: prevent the creation of state during a resource clogging attack.

Tests demonstrate that garbage collection is not sufficient. One common IKE/ISAKMP implementation used over 50MB of memory during a one-minute test. Moreover, a simple exploit program can consume 100% of the CPU, degrading performance to the extent that outgoing packets stop entirely. See Appendix B, "Cookie Crumbs (Exploit)."

Furthermore, the problem is not limited to "bogus IP addresses." Valid IP addresses cause the same symptoms.

Surprisingly, during testing, 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 remediation will require significant protocol changes.

Cookie Jar Attack

Another significant problem is the lack of any resource-limitation feature, such as is found in Photuris. In particular, an adversary 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 with apparently valid cookie values.

The Responder is swamped by simultaneously calculating the shared-secrets and/or decrypting the nonces and/or verifying the identities. These operations are computationally expensive.

Note that the adversary 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 interloper in the path between a legitimate Initiator and Responder. The interloper 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.

Cookie Race Attack

A more subtle problem is a race condition between the phases after the initial exchange of cookies. A Monkey in the Middle (MITM) 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, since there is no requirement that the Responder send any message to signal verification failures. The Initiator will futilely retransmit.

This is a serious specification error that affects interoperability and makes conformance testing much more difficult.

Aggressive Denial of Service

The "Aggressive" mode provides far worse security than the "Main" mode of operation. Indeed, it allows more aggressive denial-of-service attacks. Fortunately, fewer implementations have included the aggressive mode.

Cookie Deficiency

Unlike main mode, aggressive mode eliminates the cookie exchange. In the Internet threat environment, this opens the protocol to numerous failures associated with normal datagram delivery, such as reordered and duplicated datagrams.

Resource-clogging and -flooding attacks are extremely easy and may be mounted from anywhere in the Internet. The adversary can use bogus IP Source addresses and will be difficult to track. Blocking the attack with standard traffic-limitation techniques will not be effective, since the attacks do not need a high volume of messages.

The Responder is swamped by simultaneously verifying the signatures and/or decrypting the nonces. These operations are computationally expensive.

Note that the adversary does not need to make any computations itself. The key-exchange, signature, and nonce payloads can be properly formatted garbage.

This fundamental design flaw is inherent in the specification, and remediation will require removal of the aggressive mode feature.

Revealed Identities

Aggressive mode does not usually provide identity protection, as this option is not required to be implemented. The identities can be exchanged in the clear, before a common shared-secret has been established.

This is considered a feature for mobile users. Yet it is mobile users who are most likely to be affected by eavesdropping on wireless links.

Such revealed identities are long-term liabilities. Compromised identities continue to be useful to an adversary until all participants have revoked the associated permissions. Identity attacks are extremely easy and may be mounted from anywhere on the Internet.

Moreover, the revealed identities might be encrypted in other exchanges. This provides a ripe opportunity for cryptanalysis of those exchanges.

This fundamental design flaw is inherent in the specification, and remediation will require removal of the aggressive mode feature.

Futile Filters

Filtering the incoming messages on the basis of IP Source or Initiator Identity has been suggested for ameliorating the aggressive-mode vulnerabilities. This is quite ineffective against a determined adversary.

Note that filtering is not required by the specification and cannot be depended upon as a security feature.

Filtering based on IP Source is undesirable, since this would exclude mobile and DHCP users. Moreover, IP addresses have constrained ranges and are easily guessable. This is far easier than the well-known TCP-sequence-number guessing attack.

Once an identity has been revealed to an eavesdropper, that identity can be used from anywhere, without any more work. Using an identity seen on a mobile unit in just one place could doom the whole network behind the security firewall accessed by that mobile user (at least until new identities are generated and old ones filtered).

This whole approach violates the fundamental principle set forth in Photuris:

Internet Security does not place any significance on easily forged IP Source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key. [Photuris-01, page 1]

Quick Denial of Service

Although the "Quick" mode relies on the security of the "Main" mode of operation, the optional form providing forward secrecy isn't very quick, since it includes a computationally expensive exchange of new key material. Unfortunately, implementation of quick mode with forward secrecy is required. [RFC-2409, page 17]

An interloper can simply record the packets and replay them later. The peer is swamped by simultaneously calculating the shared-secrets and/or decrypting the nonces and/or verifying the identities.

This serious design flaw can be ameliorated by removal of the quick mode with its (imperfect) forward secrecy feature.

More Obvious Flaws
Poor Specification

A great many of the problematic specifications are due to the IKE/ISAKMP framework. This is not surprising, since the early drafts used ASN.1 and were fairly clearly ISO-inspired. The observations of another ISO implementor (and security analyst) appear applicable:

The specification was so general, and left so many choices, that it was necessary to hold "implementor workshops" to agree on what subsets to build and what choices to make. The specification wasn't a specification of a protocol. Instead, it was a framework in which a protocol could be designed and implemented. [Folklore-00]

The IKE/ISAKMP framework relies on a "Domain Of Interpretation" (DOI) for the actual details. IKE/ISAKMP has required numerous implementation workshops to reach agreement on the interpretation of the specifications. Implementation and testing has already taken several years.

Contrast with Photuris, where an undergraduate and a graduate student, working separately in their spare time, achieved international interoperability of independent implementations on different platforms in under two months.

Option Overload

A distinguishing characteristic of IKE/ISAKMP is the addition of new modes and options to the underlying framework. Yet important features such as forward secrecy, identity-privacy protection, and resource-clogging defenses are merely optional.

Scalability is never considered. Simplicity is utterly disregarded.

The plethora of options severely complicates protocol implementation and makes conformance testing much more difficult.

Error (Non-)Reporting

Inclusion of error-notification payloads can be anywhere within various modes and phase exchanges, or in a separate "Informational Exchange," or may not be included at all. There are no specified actions to be taken when such a notification is received. "Local security policy dictates the action if an error occurs during these messages" [RFC-2408, pages 52,53,54,55,57,74].

This inadequate and inconsistent error reporting is inexcusable, especially in a security specification:

The standard should describe responses to behavior explicitly forbidden or out of the boundaries described by the specification....

The specification should describe actions taken when a critical resource or a performance-scaling limit is exceeded. This is necessary for cases where a risk of network degradation or operational failure exists. In such cases, a consistent behavior between implementations is necessary. [RFC-2360, pages 6—7]

This is a serious specification error that affects interoperability and makes conformance testing much more difficult.

Revealing Field Sizes

Another serious specification flaw may make hiding of various identifying message fields less effective. Although the "payload chaining" framework obscures the field relationships from reviewer scrutiny, it appears that only the contents of these protected fields are opaque. The size of the fields is transparent (transmitted in the clear).

In particular, the lengths of user identities are revealed. Where IP addresses are used, the four-byte length is a dead giveaway.

This has the obvious benefit to an adversary that knowing the lengths allows targeting of attacks and eases verification of success.

Unverified Fields

Many parts of the message exchanges are not authenticated. The field sizes are not always verified. Some fields are authenticated in some phases but not in others. The ordering of fields can vary.

Although the "payload chaining" framework obscures the field relationships from reviewer scrutiny, it appears that such fields are vulnerable to reflection, reordering, and replay attacks.

Subliminal Channels

Where message fields are not authenticated, an unscrupulous implementer or trojan-horse implementation can transmit secret information in those fields.

Publication Delay

Since December 1995, a number of Internet drafts related to Internet Protocol Security have been awaiting official publication. 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 its 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 these 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 allowed. See Appendixes A.2 and A.3.

Finally, on 1 April 1999 a draft of this paper was posted to internet-drafts (including the above paragraphs verbatim), with a followup revision on 21 June 1999. The paper was summarily removed from the repositories and mirrors by executive order. On 26 June 1999, Fred Baker, Chair of the IESG/IETF, explained:

So it's not actually the text at the top of the document we're concerned about as much as it is the pattern of behavior . . . in the context of saying so took the opportunity to slam the organization and the process. He's welcome to his opinions of the people and the process, and he's welcome to express them. The place he chose to do so seems in poor taste.

The publication delays and refusal to publish appear directly contradictory to the formal requirements of the IETF Standards Process:

The IESG shall review such a referred document within a reasonable period of time, and recommend either that it be published as originally submitted or referred to the IETF as a contribution to the Internet Standards Process:

 If (a) the IESG recommends that the document be brought within the IETF and progressed within the IETF context, but the author declines to do so, or (b) the IESG considers that the document proposes something that conflicts with, or is actually inimical to, an established IETF effort, the document may still be published as an Experimental or Informational RFC. [RFC-2026, pages 15-16]

It is left to the gentle reader to decide whether it was "poor taste" to publish criticism of the IETF within the IETF.

Appendix A. Responses to Appeals

Appendix A.1 Publication Delayed

Date: Fri, 25 Jul 1997 19:16:25 -0700

To: "William Allen Simpson" <[email protected]>

From: Fred Baker <[email protected]>

Subject: Response to Appeal

Cc: [email protected]

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.

. . .

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.

Appendix A.2. Publication Granted

Date: Tue, 16 Feb 1999 16:31:18 -0500 (Eastern Standard Time)

From: Steve Coya <[email protected]>

To: RFC Editor <[email protected]>

cc: [email protected], [email protected]

Subject: Photuris and ICMP documents

The IESG has no problem with the publication of the following documents as Experimental RFCs: