Information Security

Demystifying IKE/IKEv2

Demystifying IKE/IKEv2

IKEv2 is a security protocol that facilitates cryptographic symmetric key exchanges between endpoints.


IKEv2 replaced IKE in late 2005, and is not backward compatible with IKE. Originally defined in RFC 4306, the latest version of IKEv2 is split between RFC 7296, 7427, 7670, and 8247.

Some Internet forums and articles describe IKE/IKEv2 as a VPN protocol. This is a misnomer.

Built into IPsec, IKEv2 is defined as a secure key exchange protocol (a type of security protocol). IPsec uses IKEv2 to establish a temporary secure tunnel for the purpose of securely exchanging Security Association parameters and Diffie-Hellman cryptographic session keys between two IPsec endpoints. However, it should really be treated as a security framework. IKEv2 is fundamentally an amalgamation of three (3) other security protocols: ISAKMP, OAKLEY, and SKEME.

IKEv2 is an IPsec protocol that derives its behavior from other, non-IPsec specific protocols: ISAKMP, OAKLEY, and SKEME


IKEv2 is not a tunneling protocol for exchanging data. It is a security protocol that establishes an ephemeral secure tunnel for the sole purpose of securely exchanging encryption keys. IKE/IKEv2 was conceived and designed specifically for implentation with IPsec. It defines how endpoints using IPSec will authenticate one another through Security Associations (SAs), and executes the parameters of those SAs by facilitating security key computations, assignments, exchanges, replacements, and revocations.

IKE's methodologies have been copied and implemented in other VPN protocols (e.g. OpenSwan, StrongSwan).

OpenIKE, OpenIKEv2, Racoon, and Racoon2 are examples of alternative, open source IKE/IKEv2 solutions that may be implemented by other processes to take advantage of IKE/IKEv2's robust key exchange architecture.

Selected characteristics of IKE:

  • Manages IPsec Authentication, Keys, and Security Associations (SAs)
  • 2 phase operation
    • Phase 1: Mutual authentication using pre-shared X.509 keys (encryption and integrity) and setup Phase 2 communication
    • Phase 2: Negotiates methods used to encrypt information from both IPSec endpoints; Security association (SA) for IPsec tunnel is established
  • Supports MOBIKE (Mobility and Multihoming IKE) protocol
  • NAT traversal1
  • SCTP support (TCP only over ports 1021, 1022)2
  • Uses port 500 (UDP)

While the IKE/IKEv2 processes may be called by virtually any tunneling or VPN process, they are almost always called by IPsec.

IKEv2 and IPsec

The primary purpose of IKE/IKEv2 is to provide a modular key association framework for IPsec. IKE was purpose-built to address shortcomings in IPsec's management of keying material. IKEv2 is an evolution of IKE.

IPsec may (and often does) utilize IKEv2 to manage cryptographic keys. When it does, IKEv2 is called indirectly via IPsec security associations. IKEv2 in turn calls ISAKMP, passing it instructions from the IKEv2 SA (which has in turn been built according to the IPsec SA).

IPsec/IKEv2 Process Flow Breakdown

IKE's 2-Phase Methodology

IKE's philosophy boils down to compartmentalization. You can think of it like a nuclear missile silo. No one person can trigger a launch by themselves. Safeguards are built-in that mean a collective process is required. Consensus must occur or nothing happens.

Remember, the desired end result of IKEv2 is to securely share a symmetric key between two (2) network peers who want to communicate via an IPsec VPN.3 To accomplish this, IKEv2 utilizes a 2-phase process that presumes the starting point of the key negotiation is occcurring over an insecure network connection. Thus, Phase 1 establishes a secure tunnel through which Phase 2 is channeled. Phase 1 authenticates the network peers and negotiates an IPsec-style SA (Security Association) for Phase 2, when the real key exchange takes place.

IKEv2 Phase 1

Phase 1 is a negotiation process that establishes a secure, authenticated IKEv2 Security Association (IKEv2 SA) between two (2) network peers. Phase 1 manages the authentication of both network peers and establishes an agreement on which encryption methods will be used for Phase 2. A separate security policy (in the form of an IKEv2 SA) is implemented for each IKEv2 peer. Normally, there are only two (2) peers.

Phase 1 uses X.509 certificates for authentication and Diffie-Hellman key exchanges for encryption. The X.509 certificates must be either arranged ahead of time (pre-shared) or may be exchanged via DNS or DNSSEC.

Phase 1 defines:

  • Global parameters, such as the names of public key certificates
  • Whether perfect forward secrecy (PFS) is to be used
  • Network interfaces affected
  • Security protocols and their algorithms
  • Authentication method

Phase 1 has two (2) different implementation methods. "Main Mode" is the default configuration and uses cryptographic keys to protect the transmission between the two (2) network peers. "Aggressive Mode" is optional, and sacrifices security for speed. The latter should never be used across the Internet.

Main Mode

IKEv2 Phase 1 Main Mode (default) uses PKI-based keys to authenticate both network peers.

Aggressive Mode

The sanctity of the IKEv2 Phase 2 cryptographic keys is critical in preventing a cascade effect of key compromises.

IKEv2 Phase 1 should not be run in Aggressive Mode over an insecure network, such as the Internet.

IKEv2 Phase 1 Aggressive Mode is faster than the default Main Mode, but transmits all information in the clear (plain text) with no authentication protection. Aggressive Mode should be avoided when possible as it is particularly vulnerable to Man-in-the-Middle (MitM) attacks, providing an attacker with the opportunity to alter the security association parameters for Phase 2. For example, allowing an attacker the opportunity to force a lower-level encryption method that is substantially easier to break.

IKEv2's design presumes operation in a hostile environment where it is vulnerable to Man-in-the-Middle (MitM) and similar attack vectors.
The primary goal of Phase 1 is to delay an attacker long enough to execute Phase 2.4

IKEv2 Phase 2

IKEv2 Phase 2 negotiates and implements the parameters for a new IKEv2 Security Association, managed by ISAKMP (ISAKMP SA). Phase 2 is where the negotiation of the underlying SA takes place (the SA that invoked IKEv2 to begin with; normally, IPsec).

Some portions of this document refer to the IKEv2 Phase 2 SA as the ISAKMP SA.
Regardless, Phase 2 of IKEv2 embodies the implementation of the parent process SA (normally IPsec).

The Phase 1 IKEv2 SA and connection are abandoned once Phase 2 is established. Phase 2's security policies and cryptographic keys are independent of those implemented in Phase 1. Implementation of the Phase 2 SA is managed by ISAKMP, which hands-off various security parameters to OAKLEY and SKEME.

The Three Musketeers: ISAKMP, OAKLEY, and SKEME

Protocol IKE/IKEv2
ISAKMP 1 Sets SA policies
OAKLEY 1 + 2 Facilitates key distribution
SKEME 1 + 2 Manages key creation

If you've researched IKE or IKEv2 before, you likely noticed these acronyms appear frequently in IKE/IKEv2 documentation. This is because IKE/IKEv2 is a coalescence of security frameworks and protocols; an uber framework comprised of three (3) related and inter-dependent security protocols.

ISAKMP manages Security Associations (SAs). OAKLEY manages key parameters and facilitates key disbursement. SKEME creates keys and manages key refresh tasks.

ISAKMP coordinates... OAKLEY acts as middleware between ISAKMP and SKEME... and SKEME generates new keys.

Keying material is provided by OAKLEY, and passed to SKEME, which generates new keys. The keys are returned from SKEME to OAKLEY, which assigns IDs to the keys (called KEYIDs) and facilitates distributing the keys to the network peers via ISAKMP, per the corresponding IKEv2 security association.

ISAKMP is the conduit process that establishes secure communication channels in both IKEv2 Phases. Through ISAKMP, Phase 1 establishes the SA for IKEv2 (IKEv2 SA) and sets up the bi-directional channel parameters necessary for the creation of IKEv2 Phase 2.

During Phase 2, ISAKMP creates its own SA (ISAKMP SA) responsible for coordinating creation and implementation of the SA of the process calling IKEv2 (normally, IPsec). Both Phase 1 and Phase 2 rely on OAKLEY to distribute cryptographic keys, manage KEYIDs for the ISAKMP SA, dictate keying material for Diffie-Hellman (D-H) keys, and keep track of any pre-shared keys. OAKLEY in turn requests creates new DH keys and provides Public Key Infrastructure (PKI) key information from SKEME.

IKEv2 Process Flow Breakdown


ISAKMP manages security associations (creation, negotiation, modification, and removal), cryptographic key management, and peer device authentication.

ISAKMP (Internet Security Association and Key Management Protocol) guides the creation and settlement (agreement process between network peers) of Security Associations (SAs). As a framework for authentication and cryptographic keys, when triggered, it establishes its own Security Association (SA). ISAKMP's SAs are different from IPsec SAs. An ISAKMP SA is a secure channel for negotiating keying material, although the essence of the IPsec SA does trickle down to ISAKMP via the IPsec and IKEv2 SAs. They are all effectively handled by ISAKMP.

ISAKMP was originally defined independently under RFC 2408. When IKEv2 replaced IKE (via RFC 4306 in late 2005) several RFC's - including RFC 2408 - were incorporated into one. The current version of the IKEv2 framework is RFC 7296, and includes ISAKMP functionality. As a framework, ISAKMP defines procedures and packet formats to establish, negotiate, modify and delete Security Associations. It requires keying material as input, which must be derived from another process, such as IKEv2, KINK, or a similar key agreement security protocol.

Utilized by IKE/IKEv2 and KINK, ISAKMP requires neither. It is, in fact, key exchange independent. Likewise, ISAKMP is not limited in scope to IPsec. It is agnostic toward security protocols. Being unbound to any specific cryptographic algorithm, key generation technique, or security mechanism, ISAKMP may update algorithms and mechanisms without changing its front hooks connected to by other processes (e.g. IKEv2).

ISAKMP has a specific attachment to port 500. It requires bi-directional data exchange via UDP packets over port 500 (both source and target hosts use port 500), though this may be implemented over any transport protocol.5

ISAKMP and IKEv2 security associations are independent of one another.


ISAKMP (Internet Security Association and Key Management Protocol) is an independent process. However, IKEv2 relies heavily upon it as a gatekeeper. ISAKMP plays a central role in coordinating the management of IKEv2 security associations.

Invoked during IKEv2's peer authentication process (IKEv2 Phase 1), ISAKMP creates a secure channel using public key encryption methods to authenticate the opposing IKEv2 peer and negotiate a new security association (ISAKMP SA). IKEv2 then negotiates keying material for its IP datagrams - based on IKEv2's SA - and incorporates that into the ISAKMP SA. Subsequently, IKEv2 Phase 2 begins, and a secure bi-directional channel is established based on the parameters agreed to during Phase 1. ISAKMP again plays the center role during Phase 2. This time, ISAKMP invokes OAKLEY to create security keys based on the parameters specified in the ISAKMP SA. OAKLEY works with SKEME, and returns the results to ISAKMP, which then completes the secure channel configuration, establishing a new secure channel, and returns control to its parent process (IKEv2). IKEv2 in turn returns control up the chain of command back to the process that called it (e.g., IPsec).


OAKLEY is a key determination protocol: a security protocol that negotiates, distributes, exchanges, and monitors cryptographic keys between network peers.

OAKLEY is the Swiss Army Knife of cryptographic key management for IKEv2. It coordinates key generation and key authentication. While not responsible for key generation, OAKLEY manages the provisioning of keys. It is the go-to process when a parent process (e.g. ISAKMP) needs a key. OAKLEY is expected to go and get it. You may think of OAKLEY as a bridge process or middleware. Within IKEv2's Phase 2 order-of-operations, OAKLEY sits between ISAKMP and SKEME, and its output messages are encoded into ISAKMP payloads.

As middleware (e.g. between ISAKMP and SKEME), OAKLEY defines:

  • Encryption method
  • Key derivation method
  • Authentication method

OAKLEY's core functions are:

  • Facilitating negotiation of key algorithms between two (2) network peers
  • Acting as middleware to facilitate the transfer of security keys between a parent process (such as ISAKMP) requesting a key and a child process that provides keys (such as SKEME)
  • Performing a transform operation on key algorithm criteria
  • Incorporating key ID metadata into the message returned to the requesting process, which can be tracked by IPsec-type Security Associations (e.g. AH or ESP protocols)

Cryptographic Key Provisioning

OAKLEY is capable of provisioning a variety of crytographic key categories: pre-shared, DNS public, RSA public, RSA self-signed, and X.509 (3rd-party Certificate Authority) keys. Defined by RFC 2142 [1998], OAKLEY does not create new keys. Rather, it facilitates their creation and transfer, including the specification of keying material.

Why OAKLEY? IKE/IKEv2 were modeled based on shortcomings in IPsec, and since IPsec uses symmetric keys, the IKE/IKEv2 Phase 2 presumes the use of symmetric keys. Fallback behavior in OAKLEY and SKEME allow the use of non-Diffie-Hellman (D-H) symmetric keys, but the IKE/IKEv2 protocol is most secure when DH keys are applied. What about the actual key generation process? That is SKEME's job.

Characteristics of OAKLEY

OAKLEY's responsibilities include:

  • Authenticating network peers and acting as messenger delivery service
  • Managing distribution (but not creation) of keys for authentication and encryption
  • Establishing parameters by which cryptographic keys are chosen
  • Middleware between key creation (e.g. SKEME) and key request (e.g. ISAKMP)
  • Directing selection of secret keying material when new Diffie-Hellman (D-H) keys are requested
  • Facilitating Perfect Forward Secrecy (PFS)
  • Assigning ID to each new key (KEYID)
  • Negotiating key exchanges
  • Updating existing keys for parent process

IKEv2 SAs specify that OAKLEY requests keys from SKEME and distributes them to ISAKMP


IKEv2 uses ISAKMP to call OAKLEY during Phase 2, where it is expected to coordinate input to SKEME (keying material) and return output to ISAKMP (keys). Why doesn't ISAKMP simply communicate with SKEME directly? Why isn't there a single process that takes care of all these steps at once? Three words: Perfect Forward Secrecy (PFS).

IKEv2 Phase 2

The ISAKMP, OAKLEY, and SKEME security protocols are designed to be modular, with purposefully narrow focus. While SKEME can technically generate symmetric keys using the Diffie-Hellman (D-H) algorithm by itself, it can do so only with a default exponent class, which yields a relatively poor level of security and should be considered a stopgap measure only. Meanwhile, OAKLEY cannot generate keys at all, but is able to assign built-in or custom DH exponent groups to SKEME based on the level of security indicated by ISAKMP. Last but not least, ISAKMP can do neither. ISAKMP gets its marching orders from the IKEv2 SA, derived from its parent process (usually IPsec), which was in turn determined by the parent SA (e.g. IPsec SA).

PFS would not be possible without a division of powers between ISAKMP, OAKLEY, and SKEME. For example, key transformation is isolated between OAKLEY and SKEME (which prevents ISAKMP from knowing the details; it can only see the results). Likewise, ISAKMP and OAKLEY are both aware of the factors contributing to OAKLEY's DH group assignment to SKEME, yet SKEME has no knowledge and only sees the end result (the actual group assignment instruction). SKEME is not privy to whatever factors influenced the DH group number assigned to it. Preventing any single process from having all the information assures PFS.

Non-DH Key Management

OAKLEY only governs Diffie-Hellman (D-H) symmetric keys. What happens when ISAKMP requests a non-DH key type from OAKLEY?

  1. OAKLEY passes the non-DH key request to SKEME without modification
  2. SKEME attempts to fulfill the request
  3. SKEME passes the result to OAKLEY (key or null)
  4. If not null, OAKLEY assigns KEYID to the key
  5. OAKLEY returns result to ISAKMP

Remember, OAKLEY is never involved in key generation. It only facilitates key transfers and provides mathematical keying material for symmetric keys. SKEME is the workhorse for cryptographic keys.

OAKLEY Key Transformation Operations

As a process, OAKLEY is able to perform a transform operation on Diffie-Hellman group and exponent criteria. Transforming means providing details on how an algorithm is to be applied to data (thus transforming the data). So, in OAKLEY's case it means OAKLEY controls the DH group and exponent criteria as it is presented to the child process which creates the DH key.

Using IKEv2 as a process example, ISAKMP's SA must contain information specifying the required level of encryption and type of keys required for the secure tunnel established by IKEv2 Phase 2. This will not necessarily consist of a request for symmetric keys. Let's take a look at the logic process of three possible scenarios for key requests to OAKLEY via IKEv2. The key request will arrive to OAKLEY via an ISAKMP SA, which will contain the relevant requirements that ISAKMP derived from the IKEv2 Phase 2 SA.

OAKLEY's message fields correspond to ISAKMP message payloads or payload components.

Relevant payload fields are the SA, AUTH, Certificate(s), and Key Exchange Payloads.

Scenario #1: Create a New Symmetric Key Using Diffie-Hellman Algorithm

This is the scenario where OAKLEY provides the greatest benefit.

  1. OAKLEY takes on the task of selecting keying material for the DH algorithm.
  2. OAKLEY provides the DH group or exponent information to SKEME.
  3. SKEME creates the symmetric key and returns it to OAKLEY.
  4. OAKLEY assigns a KEYID to the key.
  5. OAKLEY forwards the new DH key and KEYID to ISAKMP.
  6. ISAKMP provides the key and KEYID to IKEv2.

Scenario #2: Retrieve a Pre-Shared Symmetric Key

In this scenario, IKEv2 instructs ISAKMP to use a pre-shared key, and provides a reference token for the key.

  1. OAKLEY passes the reference token for the pre-shared key to SKEME.
  2. SKEME retrieves the pre-shared key and returns it to OAKLEY.
  3. OAKLEY assigns a KEYID to the key.
  4. OAKLEY forwards the key and KEYID to ISAKMP.
  5. ISAKMP provides the key and KEYID to IKEv2.

Scenario #3: Retrieve a Public Key

In this scenario, IKEv2 instructs ISAKMP to retrieve a public PKI certificate. ISAKMP passes the request on to OAKLEY, which uses SECDNS (SECure DNS) to retrieve the public key. The result is returned to ISAKMP.

Scenario #4: Retrieve an X.509 Certificate Key

When OAKLEY receives a request for an X.509 certificate based key, it is retrieved and validated before assigning a KEYID and returning the key information to the parent process. OAKLEY also retrieves auxiliary certificates for certifying authorities or co-signers based on the web of trust for the requested certificate authority.

If ISAKMP is the parent process requesting OAKLEY (e.g. IKEv2), ISAKMP will provide useful certificate info to OAKLEY. This helps to minimize OAKLEY collecting and returning extraneous certificate authority information that is not necessary because ISAKMP and its parent process are already aware of them, though it can be helpful to OAKLEY during the certificate validation process.

Time: The Nemesis of Symmetric Keys

The most challenging aspect of symmetric key creation (e.g. DH keys) is the computational time required. For example, Diffie-Hellman uses large integer exponentiations as a primary function of its algorithm. This process takes time. During this "gap," OAKLEY must wait for another process to complete the computation. In order to safeguard against a malicious process masquerading as the other process, OAKLEY employs a weak form of source authentication using tokens (referred to as "cookies") while waiting for the child process (e.g. SKEME) to complete and return a result. For instance, imagine while OAKLEY is waiting for SKEME to complete creating a DH symmetric key, that a malicious process attempts to masquerade as the replying SKEME process and provide a DH key to OAKLEY that is known to a bad actor monitoring an IKEv2 connection. If OAKLEY has no reason to suspect the SKEME process has been compromised, it will accept the key from SKEME and pass it back to ISAKMP, which hands it to the requesting (parent) process (e.g. IKEv2). While this scenario may be highly unlikely, at least OAKLEY's rudimentary authentication method provides some confidence such a scenario is even less likely to be successful.


SKEME is an independent key exchange protocol responsible for creating, sharing, and refreshing cryptographic keys.

The most complicated of the three (3) protocols that comprise IKEv2 and at the heart of its robustness, SKEME is a key generation module independent of ISAKMP and OAKLEY.

IKE/IKEv2 depend on SKEME for creating symmetric keys and fetching non-symmetric keys. Some publications refer to SKEME as more versatile than OAKLEY. However, that comparison should largely be ignored. While it's true in the sense SKEME is not restricted to symmetric keys, such comparisons muddy the waters unnecessarily. OAKLEY and SKEME have different jobs to do. Under IKE, SKEME is dependent upon the successful completion of OAKLEY's processes beforehand.

SKEME does not validate keys, though it applies anonymity and non-repudiation to the key generation and exchange processes.

SKEME Overview

Here are some quick facts about SKEME to help you better understand what it is responsible for:

  1. Builds symmetric keys using Diffie-Hellman algorithms and SHA/MD5 hashes
  2. Manages key refreshment/replacement
  3. Promotes Perfect Forward Secrecy (PFS) in IKE/IKEv2
  4. Looking up PKI and X.509 keys

SKEME also works with Kerberos and KINK.

Kerberos environments have a higher risk of the SKEME key exchange being compromised (compared to IKEv2)

SKEME Process Flow

SKEME comprises a 3-step process, broken down by phases. Its three (3) phases are: Share, Exchange, and Authenticate.

Phase 1 (SHARE)

The network peers create a shared key together, with keying material provided by both peers.

SKEME Phase 1

The peers begin with a mutual PKI key exchange. Corresponding keys are used to encrypt subsequent messages passed back and forth between the peers, which are used to jointly build a symmetric (shared) key.

Each peer supplies 1/2 of the final key components, which are combined with a unique identifier of the peer (previously exchanged security association identifier from ISAKMP, IP address, or the peer's public PKI certificate key; e.g. the one used in IKE/IKEv2 Phase 1), and hashed using a one-way hash function (MD5 or SHA) to produce the final symmetric key.6

Phase 1 steps:

  1. Each network peer provides their public key to the other peer.
  2. The peers establish a secure connection to one another (two one-way channels).
  3. Each peer creates a new cryptographic key, but does not share it.
  4. Each peer parses 1/2 of their new key and encrypts the 1/2 key in conjunction with each peer's identifier, using their private PKI key, and sends it to the opposing peer.
  5. The opposing peer decrypts the 1/2 key and opposing peer ID they just received with the public key of the other peer.
  6. Peer A creates the hash and delivers it to Peer B over the (PKI) encrypted connection.
  7. Each peer combines their copies of the two key halves. Peer A's 1/2 key is used as the first 1/2 of the key. Peer B's 1/2 key is the second half.
  8. Each peer independently applies the hash provided by Peer A to the combined key, resulting in the final symmetric key.

End Result: At the end of Phase 1, each peer joins both key halves to assemble the full key and runs a hash on it (provided by Peer A). The result is the final key derived in Phase 1.

Peer "A" always refers to the network peer initiating the SKEME process

Phase 2 (EXCH)

Diffie-Hellman component exchange.

SKEME Phase 2 - the EXCHange phase - exchanges Diffie-Hellman exponents. The exchange is not authenticated, but as you will see this concern is addressed in Phase 3. The DH components in Phase 2 may be computed ahead of time. When SKEME is called as part of IKE/IKEv2, this is exactly what happens. The OAKLEY process is run prior to SKEME, and the output from OAKLEY is the DH exponents required for SKEME Phase 2.

Phase 3 (AUTH)

Phase 3 uses the key from Phase 1 to authenticate the Diffie-Hellman key exponents derived from Phase 2.

This is where things get interesting and is the crux to SKEME's clever authentication logic. Phase 3 provides message authentication and is designed to expose the presence of an MitM attacker and/or attempts at key manipulation. If one or both private keys from Phase 1 were compromised during the key exchange, this fact will be revealed in Phase 3. How does SKEME accomplish this?

Session Key Creation (Post-Phase 3)

Generating the actual session key is the final step in SKEME.

It might seem odd, but the actual key generation process is outside SKEME's phased approach. SKEME's phases don't actually create the session keys. Rather, they accumulate the information necessary for a new session to key to be created. This allows the session key generation and key exchanges to occur - on a time basis - indpendently of the validation phases, while still running under SKEME's umbrella. Meanwhile, the actual session key generation process - which at that point is just mathematical - can be performed in parallel with other functions.

In a sense, the key generation process can be viewed as the output of SKEME. After Phase 3, the key exchange material and components required to generate a symmetric session key are all validated. The only thing left to do is run SKEME's proprietary algorithm to create the key. That final step is outside the validation phases (but part of SKEME).

Importantly, session key generation may be run in parallel with other processes, and it is certainly possible for any given host to have more than one SKEME process running. Session key creation is often the laggard when it comes to establishing and validating new connections. Furthermore, a host may process a new session key more rapidly than its peer. If the session keys are created in realtime, there may be a delay while the faster network peer waits for the slower peer to catch up, placing the connection in suspended animation until the two peers are able to synchronize.

This flexibility in time management is particularly important for mobile connections and low latency applications. It allows, for example, SKEME to generate the next session key well before the current session expires. The key generation algorithm can be taxing on the host device. This allows SKEME to prepare for a key exchange before it is actually needed, preventing undesirable effects such as suspending a connection because the timer ran out but a new key isn't computed yet. Since SKEME is responsible not just for generating the session key but also for the key exchange process in IKE, it makes sense. Pre-configured keys allow more efficient handling of connections and resource management of the host device. Furthermore, IKEv2 (and by definition SKEME) is often responsible for multiple simultaneous connections. Permitting flexibile key management yields a more fluid experience all the way around.

Perfect Forward Secrecy in SKEME

The combination of SKEME Phase 1 and Phase 2 provides Perfect Forward Secrecy (PFS).

Phase 3 uses the ID of the opposing peer to generate its copy of the symmetric key; thus if that ID is wrong (not same as what opposing peer thinks it's ID is), the final key validation will fail. Both peers must derive the same keys in Phase 1 AND Phase 2. Otherwise, one or the other (or both) peers will fail to authenticate the keys correctly in Phase 3. The shared key from Phase 1 is used to validate the DH key created in Phase 2. Phase 3 basically validates that Phases 1 and 2 were successful and a middle-man attacker is not present.

Presuming one or the other private PKI keys in Phase 1 are not compromised by a MitM attacker, the two (2) network peers will be the only hosts capable of knowing the complete key from Phase 1. Phase 2 won't result in a correct outcome unless Phase 1 was successful.

Phase 3 authenticates the origin, freshness, and values of the Diffe-Hellman exponents.

SKEME does not provide device authentication of any kind, other than to verify the two devices exchanging key data are consistent throughout each phase. SKEME does not use digital signatures, and its authentication processes are limited to message authentication only. SKEME validates its data components are known only to the two (2) network peers involved in the exchange, and those devices have not changed from start to finish of SKEME's process.

SKEME Phase 1 is Vulnerable

From a vulnerability perspective, SKEME's Phase 1 is its weak spot. Phases 2 and 3 are not vulnerable to attack unless Phase 1 has been compromised.

How do we know?

  1. The key in Phase 3 cannot be calculated without both 1/2 keys obtained during Phase 1.
  2. Phase 2 can only be compromised if Phase 1 is compromised.

Analysis: SKEME Key Exchange Vulnerabilities

The final symmetric key generated by SKEME is its output: the session key. Creating it requires the combination of six (6) elements derived from Phases 1 and 2:

  • Hashed symmetric key (Phase 1)
  • Peer A's DH exponent (Phase 2)
  • Peer B's DH exponent (Phase 2)
  • Identity of Peer A (Phase 1)
  • Identity of Peer B (Phase 1)
  • The message hash value (Phase 1)

Both peers A and B independently validate these values in Phase 3. If something went wrong in Phase 1 or 2, the final key will not be symmetrical and the connection will fail.

The session key formula is proprietary to SKEME. It requires each peer to transpose values received from the other in such a way that if the peers failed to properly exchange identical details in Phases 1 and 2 (such as if one or both of the peer streams were compromised in transit), their values for the computation in Phase 3 will be different. This will result in the keys failing to be symmetric. If this happens, the process aborts before the session key generation stage, the communication attempt fails and/or the connection will be dropped.

One of the interesting nuances to SKEME's approach is a component of the key generation process consists of each peer's own unique identifier. Thus, if an incorrect identifier is used by one peer or the other (such as if an attacker modified one of the key exchanges in transitu), the authentication process in Phase 3 will fail regardless of whether the attacker attempts to allow the peers to complete the process, or if the attacker attempts to intercept one peer and masquerade as it. Either way, the symmetry of the final validation will fail and the presence of the attacker will be discovered through inference.

Another interesting aspect of SKEME's technique is the message hash. Recall the hash is generated by Peer A, which then shares it with Peer B over the PKI channel created in Phase 1. This means Peer A knows for certain what the correct hash is. It also means if the hashed communciations from Peer A to Peer B were modified en route, then Peer B's final key will always fail to match Peer A's. It would also likely indicate either the Peer B host has been compromised by an attacker or a MitM attacker has intercepted Peer B's private key from the Phase 1 PKI process.

The beauty of SKEME's approach is only legitimately authenticated network peers (A and B) will be capable of reaching the final step and creating identical symmetric session keys. All three (3) pieces of information in Phase 1 are required to generate the correct symmetric key in Phase 3: both key halves present, assembled in the correct order, and Peer A's hash. And as a bonus, under the auspice of IKE, Phase 2 bonds SKEME to OAKLEY's output. Phase 2's Diffie-Hellman exchange relies upon the output from the OAKLEY process that precedes SKEME, adding a variable that is completely outside the SKEME protocol. If OAKLEY is not in play (e.g. SKEME not called via IKE), SKEME has a built-in mechanism to choose the DH exponents.

Discovery of other attack vectors is possible thanks to IKEv2's sequential implementation of its underlying security protocols (ISAKMP/OAKLEY/SKEME). As mentioned above, if the OAKLEY process is compromised for either Peer A or B, SKEME's output is very likely to be impacted; even if the SKEME process is not compromised (due to mis-match of the DH exponents derived from OAKLEY). Likewise, OAKLEY is connected to ISAKMP, though only in the sense OAKLEY is not triggered unless the ISAKMP device authentication process succeeded. If any of these components were changed mid-stream between peers, such as by a MitM attacker, the new symmetric key generated in Phase 3 by either peer will not match, and when IKEv2 attempts to process a data exchange, the process will fail due to mis-matched symmetric keys between the network peers.

Diminishing SKEME's Vulnerability Exposure

SKEME's innovative 3-phase approach to key generation is similar to IKE/IKEv2's philosophy. SKEME presumes the current communication channel is insecure and a MitM attacker is present between peers. It provides partial information between peers, relies on a trusted third-party (CA server), and in its last step completes an authentication phase designed such that only the intended network peers will have all the information to be able to correctly validate the final shared key.

Every approach to security has potential vulnerabilities, and in spite of its intelligent design, SKEME is no different. The most significant potential weaknesses of SKEME pertains to its reliance on PKI keys in Phase 1. This is the linchpin in its design. Granted, the possibility is exceedingly rare, as a MitM attacker would need to gain BOTH private keys (for each peer) in order to hijack the connection and have any possibility of hacking Phase 2.

The sanctity of the peers' private keys is SKEME's Achilles Heel. Although they are highly unlikely, there are two (2) particularly vulnerable attack vectors should circumstances warrant:

  1. Weak or common private keys
  2. Compromised trusted 3rd-party CA server

A productive method of guarding against both is for both peers to implement single-use self-signed PKI certificates in Phase 1. This eliminates the risk of a MitM attacker using a dictionary attack of known private keys correlated with the peers, and the possibility of a compromised trusted CA server.

The first risk is of particular concern if both peers are high traffic, public facing servers such as those used in e-commerce. Various studies have shown a veritable small number of keys are used repeatedly on many public-facing Web servers. An astute hacker with a well placed MitM attack could deduce a private key by collecting and reverse engineering a large number of transactions over an extended period of time. This is well within the realm of modern computers, given enough time and raw data. If either host were to improve this process, it would significantly reduce the risk of a successful MitM attack against peers exchanging keys via SKEME.

The second scenario is most likely to be a threat when a Kerberos server is acting as the trusted 3rd-party CA server. In that scenario, it is likely both peers are deriving their private PKI keys from the same server. This makes the use of SKEME in a Kerberos environment a higher risk than other implementations, because the threat posed by a compromised Kerberos key exchange server is static.