IPsec: a basis for IPv6 security (Part 2)
tags:
2004-07-22 00:00
Mitsuru Kanda
Toshiba Research and Development Center
In Part 2, we will discusses Internet Key Exchange (IKE), protocols for exchanging keys and other information necessary for IPsec. It also introduces revisions to IPsec standard underway at IETF IPsec Working Group.
Key Exchanges in IPsec
In Part 1, I explained AH and ESP, two security protocols for IPsec, tunnel mode/transport mode, and security policy (SP) and security association (SA) for configuring them.
AH and ESP need keys for setting up authentication algorithm and encryption algorithm. Keys for encryption algorithm are necessary for only ESP and keys for authentication algorithm may not be necessary for ESP. In both security protocols, algorithms used require secret keys shared with connection partners.
These keys can be exchanged by IPsec system administrators through memory cards and other means outside network to install them in each system, but such methods are too cumbersome for large installations. Therefore, some form of automatic key exchange system is necessary. IPsec offers a standard protocol called Internet Key Exchange (IKE) for this purpose.
IKE
In IKE, secret key and other parameters necessary for configuration of IPsec SA are negotiated, and the resulting values are configured in the system. IKE communication usually uses UDP port 500.
IKE Behavior
IKE is defined in RFC2407, 2408, 2409 and 2412. The protocols are basically classified into two "phases": Phase 1 and Phase 2.
Phase 1
Phase 1 negotiates SA (different from IPsec SA) for establishing secure communication path for IKE's own messages. It's called ISAKMP SA. This phase performs authentication of IKE itself and exchange keys for encrypting IKE messages.Phase 1 has two modes: main mode and aggressive mode. Either of the two is used.
Main mode establishes ISAKMP SA through 6 messages altogether (Figure 1).
Aggressive mode establishes ISAKMP SA through exchange of 3 messages, fewer than main mode (Figure 2). But this mode is subject to some restrictions. For example, when pre-shared key is used for authentication, the device cannot protect its own ID (IP address, subnet and other info).
IKE Authentication Method
There are four different authentication mechanisms alternatives for IKE authentication itself in Phase 1: pre-shared key authentication, digital signature authentication, and two types of public key authentications. The simplest method of all is pre-shared key. But, as the name suggests, it requires keys to be shared beforehand, lacking scalability. In comparison, digital signature authentication is much more scalable, because it can use Public Key Infrastructure (PKI). PKI process itself can be used for authentication, too.
Phase 2
Phase 2 exchanges SA used in IPsec on the secure communication path established by ISAKMP SA.
Phase 2 uses a mode called Quick Mode (Figure 3). This mode negotiates AH and ESP security protocols and algorithms as the original purpose of IKE, as well as lifetime and other information for IPsec SA itself.
Why IKE Protocols are in Two Phases
ISAKMP SA uses Diffie-Hellman key exchange, which requires a lot of calculation for getting secret key used. ISAKMP SA established in Phase 1 can be reused to reduce Diffie-Hellman key exchange calculation processing to accelerate the negotiation of plural pairs of IPsec SAs.
Figure 1 Main Mode (pre-shared key authentication)
Figure 2 Aggressive Mode (pre-shared key authentication)
Figure 3 Quick Mode
IPsec Revisions
Currently, IPsec standards are undergoing revisions at IETF IPsec WG. Current work includes revisions of AH and ESP security protocols, standardization of next-generation IKE, and revision of RFC2401, which defined the architecture of IPsec.
AH,ESP Revisions
Current AH and ESP have 32-bit sequence number fields. The value in this field is incremented every time a packet is transmitted, in order to protect from replay attack. But the field length is only 32-bit, which can easily overflow in the high-speed networking environment these days. The revision expands the field length to 64-bit, among others.
Next-generation IKE (IKEv2)
Current IKE (IKEv1) specification is complex (and it encompasses several RFCs), which has led to lower interoperability among various implementations. IKEv2 aims to offer simpler header format and message exchanges.
Below are the characteristics of IKEv2:
1The position of version number field is unchanged, so systems can determine which version a particular IKE message is.
2It doesn't preclude use of transport mode.
Toshiba Research and Development Center
In Part 2, we will discusses Internet Key Exchange (IKE), protocols for exchanging keys and other information necessary for IPsec. It also introduces revisions to IPsec standard underway at IETF IPsec Working Group.
Key Exchanges in IPsec
In Part 1, I explained AH and ESP, two security protocols for IPsec, tunnel mode/transport mode, and security policy (SP) and security association (SA) for configuring them.
AH and ESP need keys for setting up authentication algorithm and encryption algorithm. Keys for encryption algorithm are necessary for only ESP and keys for authentication algorithm may not be necessary for ESP. In both security protocols, algorithms used require secret keys shared with connection partners.
These keys can be exchanged by IPsec system administrators through memory cards and other means outside network to install them in each system, but such methods are too cumbersome for large installations. Therefore, some form of automatic key exchange system is necessary. IPsec offers a standard protocol called Internet Key Exchange (IKE) for this purpose.
IKE
In IKE, secret key and other parameters necessary for configuration of IPsec SA are negotiated, and the resulting values are configured in the system. IKE communication usually uses UDP port 500.
IKE Behavior
IKE is defined in RFC2407, 2408, 2409 and 2412. The protocols are basically classified into two "phases": Phase 1 and Phase 2.
Phase 1
Phase 1 negotiates SA (different from IPsec SA) for establishing secure communication path for IKE's own messages. It's called ISAKMP SA. This phase performs authentication of IKE itself and exchange keys for encrypting IKE messages.Phase 1 has two modes: main mode and aggressive mode. Either of the two is used.
Main mode establishes ISAKMP SA through 6 messages altogether (Figure 1).
Aggressive mode establishes ISAKMP SA through exchange of 3 messages, fewer than main mode (Figure 2). But this mode is subject to some restrictions. For example, when pre-shared key is used for authentication, the device cannot protect its own ID (IP address, subnet and other info).
IKE Authentication Method
There are four different authentication mechanisms alternatives for IKE authentication itself in Phase 1: pre-shared key authentication, digital signature authentication, and two types of public key authentications. The simplest method of all is pre-shared key. But, as the name suggests, it requires keys to be shared beforehand, lacking scalability. In comparison, digital signature authentication is much more scalable, because it can use Public Key Infrastructure (PKI). PKI process itself can be used for authentication, too.
Phase 2
Phase 2 exchanges SA used in IPsec on the secure communication path established by ISAKMP SA.
Phase 2 uses a mode called Quick Mode (Figure 3). This mode negotiates AH and ESP security protocols and algorithms as the original purpose of IKE, as well as lifetime and other information for IPsec SA itself.
Why IKE Protocols are in Two Phases
ISAKMP SA uses Diffie-Hellman key exchange, which requires a lot of calculation for getting secret key used. ISAKMP SA established in Phase 1 can be reused to reduce Diffie-Hellman key exchange calculation processing to accelerate the negotiation of plural pairs of IPsec SAs.
Figure 1 Main Mode (pre-shared key authentication)
;)
Figure 2 Aggressive Mode (pre-shared key authentication)
;)
Figure 3 Quick Mode
IPsec Revisions
Currently, IPsec standards are undergoing revisions at IETF IPsec WG. Current work includes revisions of AH and ESP security protocols, standardization of next-generation IKE, and revision of RFC2401, which defined the architecture of IPsec.
AH,ESP Revisions
Current AH and ESP have 32-bit sequence number fields. The value in this field is incremented every time a packet is transmitted, in order to protect from replay attack. But the field length is only 32-bit, which can easily overflow in the high-speed networking environment these days. The revision expands the field length to 64-bit, among others.
Next-generation IKE (IKEv2)
Current IKE (IKEv1) specification is complex (and it encompasses several RFCs), which has led to lower interoperability among various implementations. IKEv2 aims to offer simpler header format and message exchanges.
Below are the characteristics of IKEv2:
- IKEv2 uses UDP Port 500 just like IKE v1, but messages of the two are not compatible.1
- It puts more focus on VPN (tunnel mode)2, most apparent IPsec application at present.
- It adds to NAT traversal feature, although this is not so relevant in IPv6.
- It tries to ensure statelessness, to prevent DOS attacks.
- EAP (RFC2284) is added as an authentication method.
1The position of version number field is unchanged, so systems can determine which version a particular IKE message is.
2It doesn't preclude use of transport mode.