IKE is the protocol used to set up a security
association (SA) in the IPsec protocol suite. IKEv2 is the second and latest
version of the IKE protocol. Adoption for this protocol started as early as
2006.
IKE builds upon the Oakley protocol and
ISAKMP. IKE uses X.509 certificates for authentication - either pre-shared or
distributed using DNS (preferably with DNSSEC) and a Diffie–Hellman key
exchange - to set up a shared session secret from which cryptographic keys are
derived.
History
The Internet Engineering Task Force (IETF)
originally defined IKE in November 1998 in a series of publications (Request
for Comments) known as RFC 2407, RFC 2408 and RFC 2409:
- RFC 2407 defined The Internet IP Security Domain of Interpretation for ISAKMP.
- RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP).
- RFC 2409 defined The Internet Key Exchange (IKE).
IKE was updated to version two (IKEv2) in
December 2005 by RFC 4306. Some open details were clarified in October 2006 by
RFC 4718. These two documents plus additional clarifications were combined into
the updated IKEv2 RFC 5996 which was published in September 2010. A later
update upgraded the document from Proposed Standard to Internet Standard, and
was published as RFC 7296 in October 2014.
Problems with IKE
Originally, IKE had numerous configuration
options but lacked a general facility for automatic negotiation of a well-known
default case that is universally implemented. Consequently, both sides of an
IKE had to exactly agree on the type of security association they wanted to
create — option by option — or a connection could not be established. Further
complications arose from the fact that in many implementations the debug output
was difficult to interpret, if there was any debug routine at all.
The IKE specifications were open to a
significant degree of interpretation, bordering on design faults
(Dead-Peer-Detection being a case in point), giving rise to different IKE
implementations not being able to create an agreed-upon security association at
all for many combinations of options, however correctly configured they might
appear at either end.
Improvements with IKEv2
The need and intent of an overhaul of the IKE
protocol was described in Appendix A of RFC 4306. The following issues were
addressed:
- Fewer RFCs: The specifications for IKE were covered in at least three RFCs, more if one takes into account NAT traversal and other extensions that are in common use. IKEv2 combines these in one RFC as well as making improvements to support for NAT traversal and firewall traversal in general.
- Standard Mobility support: There is a standard extension for IKEv2 (named MOBIKE) used to support mobility and multihoming for it and ESP. By use of this extension IKEv2 and IPsec can be used by mobile and multihomed users.
- NAT traversal: The encapsulation of IKE and ESP in UDP port 4500 enables these protocols to pass through a device or firewall performing NAT.
- SCTP support: IKEv2 allows for the SCTP protocol as used in Internet Telephony VoIP.
- Simple message exchange: IKEv2 has one four-message initial exchange mechanism where IKE provided eight distinctly different initial exchange mechanisms, each one of which had slight advantages and disadvantages.
- Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets that are very similar to what IPsec Encapsulating Security Payload (ESP) uses to protect the IPsec packets. This led to simpler implementations and certifications for Common Criteria and FIPS 140-2, which require each cryptographic implementation to be separately validated.
- Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management. IKE could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated. Work arounds (such as Dead-Peer-Detection) were developed but not standardized. This meant that different implementations of work-arounds were not always compatible.
- Denial of Service (DoS) attack resilience: IKEv2 does not perform much processing until it determines if the requester actually exists. This addressed some of the DoS problems suffered by IKE which would perform a lot of expensive cryptographic processing from spoofed locations.
Vulnerabilities
Leaked NSA presentations released by 'Der
Spiegel' indicate that IKE is being exploited in an unknown manner to decrypt
IPSec traffic.
Initial Phases in IKEv2 Exchange
In effect, IKEv2 has only two initial phases
of negotiation:
- IKE_SA_INIT Exchange
- IKE_AUTH Exchange
IKE_SA_INIT Exchange
IKE_SA_INIT is the initial exchange in which
the peers establish a secure channel. After it completes the initial exchange,
all further exchanges are encrypted. The exchanges contain only two packets
because it combines all the information usually exchanged in MM1-4 in IKEv1. As
a result, the responder is computationally expensive to process the IKE_SA_INIT
packet and can leave to process the first packet; it leaves the protocol open
to a DOS attack from spoofed addresses.
In order to protect from this kind of attack,
IKEv2 has an optional exchange within IKE_SA_INIT to prevent against spoofing
attacks. If a certain threshold of incomplete sessions is reached, the
responder does not process the packet further, but instead sends a response to
the Initiator with a cookie. For the session to continue, the Initiator must
resend the IKE_SA_INIT packet and include the cookie it received.
The Initiator resends the initial packet
along with the Notify payload from the responder that proves the original
exchange was not spoofed. Here is a diagram of IKE_SA_INIT exchange with cookie
challenge:
 |
| IKE_SA_INIT Exchange |
IKE_AUTH Exchange
After the IKE_SA_INIT exchange is complete,
the IKEv2 SA is encrypted; however, the remote peer has not been authenticated.
The IKE_AUTH exchange is used to authenticate the remote peer and create the
first IPsec SA.
The exchange contains the Internet Security
Association and Key Management Protocol (ISAKMP) ID along with an
authentication payload. The contents of the authentication payload is dependent
on the method of authentication, which can be Pre-Shared Key (PSK), RSA
certificates (RSA-SIG), Elliptic Curve Digital Signature Algorithm certificates
(ECDSA-SIG), or EAP. In addition to the authentication payloads, the exchange
includes the SA and Traffic Selector payloads that describe the IPsec SA to be
created.
Later IKEv2 Exchanges
- CREATE_CHILD_SA Exchange
If additional child SAs are required, or if
the IKE SA or one of the child SAs needs to be re-keyed, it serves the same
function that the Quick mode exchange does in IKEv1. As shown in the this
diagram, there are only two packets in this exchange; however, the exchange
repeats for every rekey or new SA:
 |
| Child_SA Exchange |
- INFORMATIONAL Exchange
As it is in all IKEv2 exchanges, each
INFORMATIONAL Exchange request expects a response. Three types of payloads can
be included in an INFORMATIONAL exchange. Any number of any combination of
payloads can be included, as shown in the this diagram:
 |
| INFORMATIONAL Exchange |
- The Notify payload (N) has already been seen in conjunction with cookies. There are several other types as well. They carry error and status information, as they do in IKEv1.
- The Delete payload (D) informs the peer that the sender has deleted one or more of its incoming SAs. The responder is expected to delete those SAs and usually includes Delete payloads for the SAs that correspond in the other direction in its response message.
- The Configuration payload (CP) is used to negotiate configuration data between the peers. One important use of the CP is to request (request) and assign (response) an address on a network protected by a security gateway. In the typical case, a mobile host establishes a Virtual Private Network (VPN) with a security gateway on its home network and requests that it be given an IP address on the home network.
(Note: This eliminates one of the problems
that the combined use of Layer 2 Tunneling Protocol (L2TP) and IPsec is
intended to solve.)
Differences between IKEv1 and IKEv2
 |
| Differences between IKEv1 and IKEv2 |
IKEv1
|
IKEv2
|
IPsec SA
|
Child SA
(Changed)
|
Exchange modes:
# Main mode
# Aggressive mode
|
Only one
exchange procedure is defined.
Exchange modes
were obsoleted.
|
Exchanged
messages to establish VPN.
# Main mode: 9
messages
# Aggressive
mode: 6 messages
|
Only 4
messages.
|
Authentication
methods ( 4 methods ):
# Pre-Shared Key
(PSK)
# Digital
Signature (RSA-Sig)
# Public Key
Encryption
# Revised Mode of
Public key Encryption
|
Only 2 methods:
# Pre-Shared Key
(PSK)
# Digital
Signature (RSA-Sig)
|
Both peers must
use the same authentication method.
|
Each peer can
use a different authentication method (Asymmetrical authentication).
(e.g.
Initiator: PSK and Responder: RSA-Sig)
|
Traffic
selector:
# Only a
combination of a source IP range, a destination IP range, a source port and a
destination port is allowed per IPsec SA.
# Exact agreement
of the traffic selector between peers is required.
|
# Multiple
combinations of a source IP range, a destination IP range, a source port
range and a destination port range are allowed per Child SA. Of course, IPv4
and IPv6 addresses can be configured for the same Child SA.
# Narrowing
traffic selectors between peers is allowed.
|
Lifetime for
SAs:
Agreement
between peers is required.
|
NOT negotiated.
Each peer can delete SAs anytime by exchanging DELETE payloads.
|
Multi-hosting:
Basically, NOT
supported.
|
Supported by
using multiple IDs on a single IP address and port pair.
|
Rekeying:
NOT defined.
|
Defined.
|
NAT Traversal:
Defined as an
extension.
|
Supported by
default.
|
Dead Peer
Detection / Keep-alive for SAs:
Defined as an
extension.
|
Supported by
default.
|
Remote Access
VPN:
NOT defined.
Supported by vender-specific implementations:
# Mode config
# XAUTH
|
Supported by
default:
# Extensible
Authentication Protocol (EAP)
# User
authentication over EAP is associated with IKE's authentication.
# Configuration
payload (CP)
|
Multi-homing:
Basically, NOT
supported.
|
Supported by
MOBIKE (IKEv2 Mobility and Multihoming Protocol: RFC 4555).
|
Mobile Clients:
Basically, NOT
supported.
|
Supported by
MOBIKE (IKEv2 Mobility and Multihoming Protocol: RFC 4555).
|
DoS
protections:
Basically, NOT
supported.
|
# Anti-replay
function is supported.
# 'Cookies' is
supported for mitigating flooding attacks.
# Many
vulnerabilities in IKEv1 were fixed.
|
Less reliable
than IKEv2.
|
More reliable.
# All message
types are defined as Request and Response pairs.
# A procedure to
delete SAs is defined.
# A procedure to
retransmit a message is defined.
|
Extensions are
very poor.
|
Useful
extentions in actual network environment.
# "Redirect
Mechanism for IKEv2 (RFC5685)"
# "IKEv2
Session Resumption (RFC5723)"
# "An
Extension for EAP-Only Authentication in IKEv2 (RFC5998)"
# "Protocol
Support for High Availability of IKEv2/IPsec (RFC6311)"
# "A Quick
Crash Detection Method for the Internet Key Exchange Protocol (IKE)
(RFC6290)"
|
Example S2S VPN using IKEv2
 |
| Topology |
Peer1 (Router)
crypto ikev2 proposal 10
encryption
aes-cbc-256
integrity sha256
group 5
exit
crypto ikev2 policy 1
proposal 10
exit
crypto ikev2 keyring KEY1
peer peer2
address
102.1.1.100
pre-shared-key
cisco
exit
exit
crypto ikev2 profile IKEV2
match identity
remote add 102.1.1.100
identity local add
101.1.1.100
keyring local KEY1
authentication
local pre-share
authentication
remote pre-share
exit
ip access-list extended VPN
permit ip host
192.168.1.100 host 192.168.2.100
exit
crypto ipsec transform-set esp-aes esp-sha-hmac
exit
crypto map CMAP 10 ipsec-isakmp
set transform-set
tset
set ikev2-profile
IKEV2
match address VPN
set peer
102.1.1.100
exit
int f0/0
crypto map CMAP
exit
Peer2 (ASA)
crypto ikev2 policy 10
encryption aes-256
integrity sha256
prf sha256
group 5
exit
tunnel-group 101.1.1.100 type ipsec-l2l
tunnel-group 101.1.1.100 ipsec-attributes
ikev2
local-authentication pre-share-key cisco
ikev2
remote-authentication pre-share-key cisco
exit
crypto ipsec ikev2 ipsec-proposal Prop1
protocol esp
encryption aes
protocol esp
integrity sha-1
exit
access-list VPN permit ip host 192.168.2.100 host
192.168.1.100
crypto map CMAP 10 set ikev2 ipsec-proposal Prop1
crypto map CMAP 10 set peer 101.1.1.100
crypto map CMAP 10 match address VPN
crypto map CMAP interface outside
crypto ikev2 enable outside
----
No comments:
Post a Comment