IKE/ISAKMP considered harmful

[Du Jinsong <jinsong@internetappliance.com>]

Hi, take a look at this article at:
http://www.screaming-penguin.com/main.php3?storyid=782
or the text I attached

It seems now that luckily OpenBSD implemented both IKE and Photuris.
Actually I am curious about why OpenBSD chose to implement both of them.

 IKE/ISAKMP considered harmful

              by William Allen Simpson
              wsimpson@greendragon.com


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 andtesting 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, suchas 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 protocolchanges.


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 exchangeand nonce payloads can be properly formatted garbage.

This attack is especially effective for an interloper in the path
between a legitimate Initiatorand 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 requiresignificant 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 isnt 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 wasnt 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 outof 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-horseimplementation 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 its not actually the text at the top of the document were 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.
Hes welcome to his opinions of the people and the process, and hes
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.

Wow, thorough indeed. Check the USENIX pages for responses and
appendices. (Note, you must be a SAGE or USENIX member to gain full
access.)