OUSPG

[This page is CSS2 enabled. Your browser might not fully support it]

PROTOS Test-Suite: c09-isakmp

$RCSfile: index.html,v $ $Revision: 1.29 $ $Date: 2005/11/14 13:11:36 $

Status: Release 1

ABSTRACT

The Internet Security Association and Key Management Protocol (ISAKMP), is designed to establish, negotiate, modify and delete Security Associations. ISAKMP provides a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism. Internet Key Exchange (IKE), a derivate of ISAKMP, is a key protocol in the Internet Security Architecture (IPsec). A subset of IKE Phase 1 negotiation was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. A survey of the related standards was made. Test-material was prepared and tests were carried out against a sample set of existing implementations. Results were gathered and reported. Some of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. Therefore, this robustness test-material should be adopted for evaluation and development of ISAKMP/IKE products.

Table of Contents

• ABSTRACT
• Table of Contents
• Introduction
• Test-Suite Design
  • Standard Survey
  • Subject Survey
  • Injection Vector Survey
    • About ISAKMP Message Exchanges
  • Specifications Design
  • Design of Exceptional Elements
  • Design of Test-Material
• Implementation
  • Injection
  • Instrumentation
  • Test-Runs
  • Results
  • Verification via Exploits
• Test-Material Package
  • Package Information
  • License and Copyright
  • Prerequisites
  • Usage
  • Download
    • Release 2
    • Release 1
• Conclusions
  • Acknowledgements
• Vulnerability Management
  • Prior Public Vulnerabilities
  • The Vulnerability Process
  • Advisories and Vendor Statements
• References
• Appendix A: Release Errata
• Appendix B: Test-Material Error Messages
• Appendix C: Related Test-Suites

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. [1] This test-suite covers a limited set of information security and robustness related implementation errors within the chosen focus area. Important: Background, goals, limitations, terminology and licensing for this test-suite release are explained in the "Test-suite releases in Theory and Practice" document. This test-suite covers a limited set of information security and robustness related implementation errors for a subset of the chosen protocol.

The purpose of this test-suite is to evaluate implementation level security and robustness of Internet Security Association and Key Management Protocol (ISAKMP) implementations. The initial scope of the test-suite was set to IPsec DOI (Internet IP Security Domain of Interpretation) version of ISAKMP, namely IKE (Internet Key Exchange). The factors behind chossing IKE included:

• IKE is an important part of IPsec which is used in critical infrastructure. When IKE is being used, the traffic (UDP/500) is usually not filtered until processed.
• There are plenty of implementations by several vendors available for testing. IKE has a history of interoperability problems.
• There are no free, publicly available robustness test suites to evaluate IKE implementations.

The scope was further narrowed to IKE phase 1 with pre-shared secret authentication. Rationale behind this selection was:

• IKE phase 1 does not require any special preconditions as phase 2 does. Additionally, phase 1 aggressive mode allows sending several payloads in the first packet.
• IKE phase 1 authentication with pre-shared secret is required from all ISAKMP/IKE implementations.

Potential IKE vulnerabilites in above scope can be roughly categorised based on the on the IKE identity and shared secret:

• A. Vulnerability does not require a valid identity nor a shared secret (greatest impact).
• B. Vulnerability requires a valid identity but not the shared secret.
• C. Vulnerability requires both a valid identity and the corresponding shared secret (smallest impact).

The peer source IP address may also affect on results depending on the setup. For example, a different security policy may be selected in the target implementation depending on whether the source IP is configured as an IPsec endpoint or not. Some policies accept aggressive mode exhcanges and some not.

The category C was chosen as the initial test-strategy. If possible, the test-suite and test-subject were configured as IKE peers. If a failure was discovered, it was verified within the other categories as well.

Test-Suite Design

Standard Survey

The available standards were studied and analysed. The relevant specifications are listed below.

• RFC 2407 - The Internet IP Security Domain of Interpretation for ISAKMP[2]
• RFC 2408 - Internet Security Association and Key Management Protocol (ISAKMP)[3]
• RFC 2409 - The Internet Key Exchange (IKE)[4]
• RFC 2412 - The OAKLEY Key Determination Protocol[5]

Subject Survey

A survey of available implementations is conducted. This should include a diverse selection of implementations in order to gain a better insight into the applications implementing the protocol, and to give a hint on the impact of potential vulnerabilities. A subset of the implementations is chosen to be tested during the test-suite creation and prerelease phases. Typically, not all implementations are available for testing.

Additional lists of vendors, specific implementations and related information may be found from the following resources:

• VPN Vendor and Service Provider Links [6]
• VPN Products and Services [7]

A subset of the implementations was chosen as a sample set to be tested during the test-suite creation and pre-release phases. Most likely reasons for omission of a specific product from the sample set include:

• no evaluation copy of the product was available
• or a restrictive licence prohibited evaluation
• or we were not aware of the product

Injection Vector Survey

In injection vector survey, different methods of delivering the test cases to the implementations under test are identified and analysed. Often, there are several injection methods and one test-suite cannot cover them all, or might miss some vectors not available in all implementations.

About ISAKMP Message Exchanges

ISAKMP consists of two phases. In phase 1 the two parties negotiate a security association (SA) to agree on how to protect the traffic in the next phase. In phase 2 keying material is derived and policy to share it is negotiated. In this way security associations for other security protocols are established. [3].

There are two ways to establish a phase 1 SA, main mode and aggressive mode. Both generate authenticated keying material from an ephemeral Diffie-Hellman exchange. Main mode as illustrated in figure 1, is required in every implementation whereas aggressive mode (figure 2) is optional. In main mode the identities of the parties are always protected but in aggressive mode only when public key encryption is used in authentication. [4]

Here are the abbreviations used in figures 1 and 2:

• i = initiator
• r = responder
• hdr = ISAKMP Header
• hdrc = ISAKMP Header followed by encrypted payloads
• sa = security association payload
• ke = key exchange payload
• nonce = nonce payload
• id = identification payload
• hash = hash payload

Figure 1: Sequence diagram of main mode

In the first message of main mode the initiator generates one or more proposals to protect neqotiations. It includes security association payload which encapsulates proposal and transform payloads. The responder chooses one of the proposals and sends it in the second message. In the next two messages the Diffie-Hellman public values are exchanged for common shared secret (key-exchange) and random information (nonce). Then the initiator and responder authenticate the Diffie-Hellman exchange. They exchange identification information (id) and the results of the agreed authentication function (hash) in the fifth and sixth messages. This information is encrypted by methods agreed in previous messages. [3] [4].

Figure 2: Sequence diagram of aggressive mode

In aggressive mode the first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange and identities. The second message also authenticates the responder when the third message authenticates the initiator and provides a proof of participation in the exchange. [3] [4].

Once phase 1 is completed, phase 2 exchange is accomplished by the quick mode. More than one phase 2 negotiations can be started on the base of one phase 1 SA. [4].

Specifications Design

Protocol data unit specifications are used as a basis for generating the test-cases. Starting point for the design of the test-suite is to acquire or create a machine-readable representation of the protocol specification. The test-tool in use utilises a custom dialect of BNF (Backus-Naur Form). BNF is capable of describing the context-free syntax of a specification, but is often insufficient for automated test-case generation. The specification is completed by rules which maintain semantic validity and provide communication channels necessary to simulate the protocol.

The following default values were used in the test-material:

• ISAKMP Security Association attributes:
  • Encryption algorithm: 3DES-CBC
  • Hash algorithm: HMAC-SHA-1
  • Authentication method: Pre-shared key
  • Group description: 1024 bit MODP (Oakley 2)
• Identification type:
  • ID_IPV4_ADDR

Design of Exceptional Elements

An exceptional element is a piece of data designed to provoke undesired behaviour of the test subject. A single test-case contains one or few exceptional elements. An exceptional element can violate the protocol specification, but often it is legal or in the hazy region between legal and illegal constructs. In a nutshell, an exceptional element is an input that might not have been considered properly when implementing the software.

The following table lists the categories of the exceptional elements designed for the test-material:

Design of Test-Material

The test-material consists of test-cases simulating hostile input to the implementation under test. A test-case contains one or more exceptional elements, other elements being in their default state. Cases are arranged into test-groups, each covering a certain part of PDUs or containing similar anomalies. Details for the test messages are presented in the table below.

Legend:

• "Name" column represents the tag-names of the test-groups. Tags reflect the field and element names in the protocol specification. Tags can be used to follow which parts of the PDUs are being tested.
• "Exceptional Elements" column describes which exceptional element categories are integrated in the test-group.
• "Test Cases", "First Index" and "Last Index" columns describe the the number of cases and the first and last test-case index in the test-group.

Implementation

Test-runs were conducted against the chosen sample of implementations. Specifications, exceptional elements, semantic rules, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests.

Injection

The test-tool provides communication rules for test-case injection. The test-tool was configured as the initiator of the IKE negotiation.

Instrumentation

The implementation under test is monitored for undesired behaviour that could have security implications. Instrumentation methods can roughly be divided to two categories.

Out-of-Band Instrumentation on the target platform includes debuggers, resource monitoring or custom made tools used to extract information from the implementation under test. Unfortunately, the modern trend of abusing the try-catch -type of constructs easily masks the exceptions generated by stack and memory corruption. Catching these hidden exceptions relies on the debugging skills of the developers themselves. Out-of-Band Instrumentation is often the preferred form of instrumentation.

In In-Band Instrumentation the implementation is monitored via the injection vector, ie. the same interface used to deliver the test-cases. While not necessarily checked for protocol conformance, absent or malformed responses can often reveal anomalous conditions such as denial of service. Also, the ability to accept subsequent test-cases indicates how they affect the performance of the target implementation. Especially with embedded devices, this form of instrumentation may be the only option easily available.

A valid case in-band instrumentation will be bundled with the test-material.

Test-Runs

Results

Results from the test-runs are summarised herein. Tables below represent the observations from feeding the test-material against the chosen subject software. Product names of the actual subjects are omitted to protect the innocent. Results are presented in a tabular form with test-cases divided into test-groups based on the exceptional element types utilised and PDU fields under examination.

Each failed test-case represents at minimum a denial of service type chance of exploiting the found vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error conditions. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.

The verdict failed is granted if any of the following criteria is met and a single test-case can be identified to be responsible:

• A device undergoes a fatal failure and stops functioning normally.
• A process or a device crashes or hangs and needs to be restarted manually.
• A process or a device crashes and restarts automatically.
• A process consumes CPU and/or memory resources for an exceptionally long or indefinite time thus causing at least a denial of service.

If no single test-case can be identified but similar effects are observed, the verdict is inconclusive.

Sometimes, a subject gets corrupted so badly or is fundamentally so unstable that there is no way to collect accurate test-results for the whole test-run. Untested regions are marked as unknown.

Otherwise, the verdict is passed.

Legend:

• nnn: Each different test-run (tr-nnn) represents a different tested implementation.
• X: Verdict is failed
• I: Verdict is inconclusive
• -: Verdict is passed
• ?: Verdict is unknown

Please note that if a subject fails in a format string (fmtstring) test-group, the failure may be caused by a buffer overflow condition with a very long format string as a trigger. Should an implementation have failed in a format string category, but not in previous overflow category, it is then likely to contain a format string type of vulnerability.

The results are further summarised in the table below.

Legend:

• N: We were unable to determine the exact number of failures. See the more detailed tables above.

Verification via Exploits

To support the vulnerability reporting process, typically one exploit per implementation is refined and included in the respective vulnerability report. The exploit is only intended for demonstration purposes and is harmless as it is. Simplest of them only executes some harmless commands in the target system, typically with the privileges of the vulnerable process. Some only provide a demonstration by causing a Denial of Service (DoS) against the software.

To support the vulnerability reports to the respective vendors, following exploits were developed:

• None as of 2005-08-19.

Test-Material Package

Package Information

The test-material is distributed as a JAR package. The package comprises of the following elements:

• Test-cases located in org/ouspg/testcases/ directory
• Codenomicon Toolkit Engine for feeding the test-cases against the system under test.
• LICENSE.TXT - License for the test-material package
• README.TXT - Very short instructions

License and Copyright

The license allows free use and redistribution of the test-material package. However, modifying the test-material package is not allowed without a permission. See the license file for more information.

We recommend some additional guidelines, although these do not restrict the test-material licence. These guidelines can be found from the "Test-suite releases in Theory and Practice" document.

Prerequisites

A prerequisite for using the test-material is a properly configured and started implementation, preferably not in an open network. The implementation should be configured to allow the following parameters:

• Encryption algorithm: 3DES-CBC
• Hash algorithm: HMAC-SHA-1
• Authentication method: Pre-shared key
• Group description: 1024 bit MODP (Oakley 2)

In addition, Java is required to execute the test-cases. The package has been tested on Java 2 Platform, Standard Edition (J2SE) versions 1.4.0 and 1.4.2. [8]

Usage

The test-material is used through a command line interface. The test-material is run with java, using the -jar switch.

The command java -jar c09-isakmp-r2.jar --help displays the built-in help for the available command line options:

--host host       Target hostname or IP (required)
--id id           Your ISAKMP identity IPv4 address (required)
--secret secret   Shared secret (required)
--port port       Target port (500)
--sourceport port Source port (500)
--index index     Test case index, e.g. 0,1-6,50-
--timeout timeout Timeout (ms) to wait for reply (2500)
--delay delay     Delay (ms) between test cases (1000)
--showsent        Show sent messages (off)
--showreceived    Show received messages (off)
--instrument      Use valid-case instrumentation (off)
--validcase case  Index to use in valid-case instrumentation (0)
--help            Show command line help

The minimal command line required to run all test-cases from host 10.10.10.1 against host 10.10.10.2 would then be java -jar c09-isakmp-r2.jar --host 10.10.10.2 --id 10.10.10.1 --secret deadbeef where deadbeef would be the shared secret.

Please see Appendix B for commonly encountered error messages when using the test-material.

Download

Use of latest release (highest number) is recommended. Older releases are provided for completeness and reproduction.

Release 2

• c09-isakmp-r2.jar (test-material)
• c09-isakmp-r2.jar.asc (PGP signature)

Release 1

• c09-isakmp-r1.jar (test-material)
• c09-isakmp-r1.jar.asc (PGP signature)

Conclusions

Although this test-suite only scratches the complex ISAKMP/IKE protocol, many of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. Therefore, this robustness test-material should be adopted for evaluation and development of ISAKMP/IKE products.

Acknowledgements

We wish to express our gratitude to individual vendors who worked with us to protect their customers. We are in debt to Sonera Corporation, CERT-FI and The Finnish Defence Forces for providing us facilities and support in determining the impact of the test-suite. Again, we thank CERT-FI and NISCC for their advice and active role during the vulnerability process.

Vulnerability Management

Prior Public Vulnerabilities

The most common sources for vulnerability information and exploits were covered and cross checked for potential and already known vulnerabilities in the implementations of the chosen protocol. Typical sources for finding out about existing vulnerabilities are databases and mailing-lists. Search-engines may also reveal information on past vulnerabilities.

Following prior vulnerabilities, in no particular order, were identified as ISAKMP/IKE related:

• "Cisco IOS Unauthorized Security Association Establishment Vulnerability" [9]
• "Cisco IOS Easy VPN Server XAUTH Authentication Bypass Vulnerability" [10]
• "KAME Racoon Malformed ISAKMP Packet Headers Denial of Service Vulnerability" [11]
• "OpenBSD ISAKMPD Kernel Heap Buffer Overflow Local Denial Of Service Vulnerability" [12]
• "Entrust LibKMP ISAKMP Library Remote IPsec/ISAKMP Buffer Overflow Vulnerability" [13]
• "OpenBSD ISAKMPD Security Association Piggyback Delete Payload Denial Of Service Vulnerability" [14]
• "Check Point VPN-1 ISAKMP Remote Buffer Overflow Vulnerability" [15]
• "KAME Racoon Malformed ISAKMP Packet Denial of Service Vulnerability" [16]
• "TCPDump ISAKMP Delete Payload Buffer Overrun Vulnerability" [17]
• "TCPDump ISAKMP Identification Payload Integer Underflow Vulnerability" [18]
• "OpenBSD ISAKMPD Zero Payload Length Denial Of Service Vulnerability" [19]
• "OpenBSD ISAKMPD Malformed IPSEC SA Payload Denial Of Service Vulnerability" [20]
• "OpenBSD ISAKMPD Malformed CERT Request Payload Denial Of Service Vulnerability" [21]
• "OpenBSD ISAKMPD Delete Payload Denial Of Service Vulnerability" [22]
• "OpenBSD ISAKMPD Memory Leak Denial Of Service Vulnerability" [23]
• "Check Point VPN-1/SecuRemote ISAKMP Large Certificate Request Payload Buffer Overflow Vulnerability" [24]
• "TCPDump ISAKMP Decoding Routines Denial Of Service Vulnerability" [25]
• "TCPDump ISAKMP Decoding Routines Multiple Remote Buffer Overflow Vulnerabilities" [26]
• "ISAKMPD "Initial Contact" Notification SA Deletion Vulnerability" [27]
• "ISAKMPD "Invalid SPI" SA Deletion Vulnerability" [28]
• "OpenBSD isakmpd Multiple IKE Payload Handling Security Weaknesses" [29]
• "TCPDump Malformed ISAKMP Packet Denial Of Service Vulnerability" [30]
• "Cisco VPN 3000 Series Concentrator ISAKMP Denial of Service Vulnerabilities" [31]
• "OpenBSD isakmpd IKE Payloads Denial Of Service Vulnerability" [32]
• "KAME Racoon Remote IKE Message Denial Of Service Vulnerability" [33]
• "Cisco IOS Malformed IKE Packet Remote Denial Of Service Vulnerability" [34]
• "Racoon IKE Daemon Unauthorized X.509 Certificate Connection Vulnerability" [35]
• "HP Tru64 UNIX Unspecified IPsec/IKE Remote Privilege Escalation Vulnerability" [36]
• "Multiple Vendor IKE Implementation Certificate Authenticity Verification Vulnerability" [37]
• "Multiple Vendor IKE Insecure XAUTH Implementation Vulnerabilities" [38]
• "OpenBSD isakmpd Multiple IKE Payload Handling Security Weaknesses" [29]
• "Check Point VPN-1 IKE Aggressive Mode Forcing Vulnerability" [39]
• "Netscreen-Remote VPN Client IKE Packet Excessive Payloads Vulnerability" [40]
• "PGPFreeware Malformed IKE Response Packet Buffer Overflow Vulnerability" [41]
• "Cisco VPN Client Zero Length IKE Packet Denial Of Service Vulnerability" [42]
• "Cisco VPN Client IKE Security Parameter Index Payload Buffer Overflow Vulnerability" [43]
• "Cisco VPN Client IKE Packet Excessive Payloads Vulnerability" [44]
• "OpenBSD isakmpd IKE Payloads Denial Of Service Vulnerability" [32]
• "IKE Aggressive Mode Shared Secret Hash Leakage Weakness" [45]

The Vulnerability Process

During the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports were tracked by CERT-FI and NISCC in the role of independent coordinators and advisors. An attempt was made to seek a channel to distribute the test material to vendors whose products we were not able to obtain for testing.

Advisories and Vendor Statements

Vendor statements or security advisories issued in order to address the vulnerabilities uncovered by this test-suite are collected. Advisories that we are aware of are listed here-in:

• NISCC advisory
• CERT-FI advisory
• As of 2005-11-14 not yet in NISCC/CERT-FI summaries (but apparently related): Cisco advisory

References

[1]

"PROTOS - Security Testing of Protocol Implementations". University of Oulu. http://www.ee.oulu.fi/research/ouspg/protos.

[2]

Piper. (1998). "RFC 2407 - The Internet IP Security Domain of Interpretation for ISAKMP". Network Working Group. http://www.ietf.org/rfc/rfc2407.txt. [Accessed: 2004-03-11].

[3]

Maughan, et. al.. (1998). "RFC 2408 - Internet Security Association and Key Management Protocol (ISAKMP)". Network Working Group. http://www.ietf.org/rfc/rfc2408.txt. [Accessed: 2004-03-10].

[4]

Harkins & Carrel. (1998). "RFC 2409 - The Internet Key Exchange (IKE)". Network Working Group. http://www.ietf.org/rfc/rfc2409.txt. [Accessed: 2004-03-11].

[5]

Orman. (1998). "RFC 2412 - The OAKLEY Key Determination Protocol". Network Working Group. http://www.ietf.org/rfc/rfc2412.txt. [Accessed: 2004-03-11].

[6]

Internetweek.com. "VPN Vendor and Service Provider Links". http://www.internetweek.com/VPN/links.htm.

[7]

VPNlabs. (2002). "VPN Products and Services". http://www.vpnlabs.org/vpn-categories/Products-Services/46/index.html.

[8]

"Java[tm] 2 Platform, Standard Edition v 1.4.2 Overview". Sun Microsystems. http://java.sun.com/j2se/1.4.2/.

[9]

Cisco. (2005). "Cisco IOS Unauthorized Security Association Establishment Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/13033.

[10]

Cisco. (2005). "Cisco IOS Easy VPN Server XAUTH Authentication Bypass Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/13031.

[11]

S. Krahmer. (2005). "KAME Racoon Malformed ISAKMP Packet Headers Denial of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/12804.

[12]

S. Miltchev. (2004). "OpenBSD ISAKMPD Kernel Heap Buffer Overflow Local Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/11928.

[13]

M. Dowd & N. Mehta. (2004). "Entrust LibKMP ISAKMP Library Remote IPsec/ISAKMP Buffer Overflow Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/11039.

[14]

T. Walpuski. (2004). "OpenBSD ISAKMPD Security Association Piggyback Delete Payload Denial Of Service Vulnerabilit". SecurityFocus. http://online.securityfocus.com/bid/10496.

[15]

Check Point Software. (2004). "Check Point VPN-1 ISAKMP Remote Buffer Overflow Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10273.

[16]

KAME. (2004). "KAME Racoon Malformed ISAKMP Packet Denial of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10172.

[17]

Rapid7. (2004). "TCPDump ISAKMP Delete Payload Buffer Overrun Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10003.

[18]

Rapid7. (2004). "TCPDump ISAKMP Identification Payload Integer Underflow Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10004.

[19]

OpenBSD. (2004). "OpenBSD ISAKMPD Zero Payload Length Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10028.

[20]

OpenBSD. (2004). "OpenBSD ISAKMPD Malformed IPSEC SA Payload Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10029.

[21]

OpenBSD. (2004). "OpenBSD ISAKMPD Malformed CERT Request Payload Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10030.

[22]

OpenBSD. (2004). "OpenBSD ISAKMPD Delete Payload Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10031.

[23]

OpenBSD. (2004). "OpenBSD ISAKMPD Memory Leak Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10032.

[24]

M. Dowd & N. Mehta. (2004). "Check Point VPN-1/SecuRemote ISAKMP Large Certificate Request Payload Buffer Overflow Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/9582.

[25]

G. Bakos. (2004). "TCPDump ISAKMP Decoding Routines Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/9507.

[26]

G. Bakos & J. Heusser. (2004). "TCPDump ISAKMP Decoding Routines Multiple Remote Buffer Overflow Vulnerabilities". SecurityFocus. http://online.securityfocus.com/bid/9423.

[27]

T. Walpuski. (2004). "ISAKMPD "Initial Contact" Notification SA Deletion Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/9334.

[28]

T. Walpuski. (2004). "ISAKMPD "Invalid SPI" SA Deletion Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/9333.

[29]

T. Walpuski. (2003). "OpenBSD isakmpd Multiple IKE Payload Handling Security Weaknesses". SecurityFocus. http://online.securityfocus.com/bid/8964.

[30]

A. Griffiths. (2003). "TCPDump Malformed ISAKMP Packet Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/6974.

[31]

Cisco. (2003). "Cisco VPN 3000 Series Concentrator ISAKMP Denial of Service Vulnerabilities". SecurityFocus. http://online.securityfocus.com/bid/5619.

[32]

OpenBSD. (2003). "OpenBSD isakmpd IKE Payloads Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5589.

[33]

J. Lampe. (2004). "KAME Racoon Remote IKE Message Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10296.

[34]

Cisco. (2004). "Cisco IOS Malformed IKE Packet Remote Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10083.

[35]

R. Spenneberg. (2004). "Racoon IKE Daemon Unauthorized X.509 Certificate Connection Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/10072.

[36]

HP advisory. (2004). "HP Tru64 UNIX Unspecified IPsec/IKE Remote Privilege Escalation Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/9803.

[37]

T.L. Simon. (2003). "Multiple Vendor IKE Implementation Certificate Authenticity Verification Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/9208.

[38]

T.L. Simon. (2003). "Multiple Vendor IKE Insecure XAUTH Implementation Vulnerabilities". SecurityFocus. http://online.securityfocus.com/bid/9209.

[39]

Check Point. (2002). "Check Point VPN-1 IKE Aggressive Mode Forcing Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5920.

[40]

Netscreen Security Advisory. (2002). "Netscreen-Remote VPN Client IKE Packet Excessive Payloads Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5668.

[41]

A. Rager. (2002). "PGPFreeware Malformed IKE Response Packet Buffer Overflow Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5449.

[42]

A. Rager. (2002). "Cisco VPN Client Zero Length IKE Packet Denial Of Service Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5440.

[43]

A. Rager. (2002). "Cisco VPN Client IKE Security Parameter Index Payload Buffer Overflow Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5441.

[44]

A. Rager. (2002). "Cisco VPN Client IKE Packet Excessive Payloads Vulnerability". SecurityFocus. http://online.securityfocus.com/bid/5443.

[45]

J. Pliam. (1999). "IKE Aggressive Mode Shared Secret Hash Leakage Weakness". SecurityFocus. http://online.securityfocus.com/bid/7423.

Appendix A: Release Errata

Erratum: The pr1 version of test-material contained the following bugs.

Exceptional element category ee-string included characters that were not encoded correctly in the test material. As a result, some test-cases were too large to send via UDP and the following kind of error messages were displayed:

ERROR error sending: Message too long
ERROR error sending: errno: 0, error: sendto failed

The size of the UDP socket input buffer was too small. The following kind of error message was shown:

ERROR decoded 4068 octet payload, but length was 4108

Informational exchange test-groups (prefix "info-") had a wrong ISAKMP major version number (0). Due the bug, some implementations may have ignored these test-groups.

The maximum amount of repeats in exceptional element category ee-repeat was too high.

Erratum: The pr2 and r1 versions of test-material contain the following bugs.

The Encryption bit in the hash-information message is incorrectly set to 0.

The test group phase1-aggr-hdr-sa-ke-nonce-id-i-identification-payload-protocol-id has 10 extraneous test cases.

Appendix B: Test-Material Error Messages

Many of the error messages are due to fact that IKE is communicated from port 500 to port 500. Therefore, port 500 sometimes receives packets not related to the current message exchange (test case).

ERROR error reading: Receive timed out

Explanation: Test suite did not receive a response within specified timeout (timeout command line option). May indicate an availability problem in test subject if the message is valid. For a malformed message, this error means probably that the test subject has decided not to respond.

ERROR Expected 0x00, got 0x4c (under <message-id>)

Explanation: Message-id in ISAKMP generic header is always zero (0x00) during phase 1 negotiation (ISAKMP SA negotiation). However, during phase 2 (quick mode) it is non-zero. This error message indicates that one or more phase 1 negotiations has been completed and the test subject tries to communicate with phase 2 messages. Can be mitigated by deleting ISAKMP SAs in test subject.

ERROR Expected (0x00 0x00 0x01 0x04 
0x37 0x80 0x5c 0x88), got (0x00 0x00 0x01 0x04 
0x37 0x80 0x4e 0xa6) (under <cookie-i>)

ERROR Expected (0xf5 0xea 0xb4 0xed
0x0e 0x72 0xfe 0x05), got (0x24 0x9c 0x7c 0x47 
0x90 0x3d 0x9a 0xcc) (under <cookie-r>)

Explanation: Either cookie field in the generic ISAKMP header is different than the one used in current phase 1 negotiation (test case). One or more phase 1 negotiations has been initiated but not finished. The test subject tries to finish one of these prior negotiations. Can be mitigated by removing outstanding phase 1 negotations or limiting the phase 1 timeout/retries in the test subject.

ERROR DESede/CBC/NoPadding decyption failed due illegal 
input block size

Explanation: Decryption error. Test suite expects a certain kind of encrypted packet but receives a unencrypted packet or packet encrypted with a different key.

ERROR detected a loop made up of repeats of <OCTET>,
out-of-memory would result (under <nonce-r-data-main>)

Explanation: Test suite did not receive responder's nonce data because the test subject did not send a Nonce payload. Might be because of a very malformed test case. Test suite tries to process the uninitialized value of responder's nonce data which is set to infinite amount of octets (because it is a variable length field).

Appendix C: Related Test-Suites

A survey of related ISAKMP/IKE test-suites was conducted.

http://www.codenomicon.com/products/internet/isakmp/

"Codenomicon ISAKMP/IKE Test Tool helps proactively eliminate security flaws in ISAKMP/IKE implementations."

http://www.rapid7.com

"Rapid7 Striker ISAKMP Protocol Test Suite is an ISAKMP packet generation tool that automatically produces and sends invalid and/or atypical ISAKMP packets."

[This page is CSS2 enabled. Your browser might not fully support it]