ACP/WG N/SG N4 WP0902
(WP0804)
AERONAUTICAL COMMUNICATIONS PANEL(ACP)
WORKING GROUP N - NETWORKING
SUBGROUP N4 – Security Services
8th Meeting
Montreal, Canada
25-29 September 2006
Use of the Internet Key Exchange Version 2 in the ATN
Presented by FAA
This paper provides a high-level analysis for using the Internet Key Exchange Version 2 (IKEv2)
protocol for key agreement in the ATN Security Solution.
Page 1 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
1.
Introduction
At the combined SGN2/4 meeting held March 6-10, 2006 at the FAA William J. Hughes
Technical Center (WJHTC) in Atlantic City, NJ, USA, a proposal was made to investigate
removing the dependency upon CM by the Aeronautical Telecommunications Network (ATN)
security solution. The ATN security solution documented in ICAO Doc 9705 Edition 3 relies
upon Context Management (CM) to exchange public keys and uses the CM dialogue to establish
the shared public value that is used to derive session keys for all other applications. One method
for achieving this is to use a separate application for key exchange. This method should achieve
the following goals:
Goal 1: Be able to remove the dependency on CM for key agreement;
Goal 2: Be able to remove the dependency on CM for key exchange for other
applications;
Goal 3: Be bandwidth-efficient for use in bandwidth-constrained environments; and
Goal 4: Support existing Open Systems Interconnect (OSI)-based ATN applications as
well as future IP-based applications.
This paper investigates the use of the Internet Key Exchange (IKE) Version 2 (IKEv2)
[RFC4306] as a separate application for key agreement.
The rest of this paper is organized as follows. Section 2 gives a brief history of IKE and a highlevel description of IKE Version 1 (IKEv1) and IKEv2. Section 3 presents a typical IKEv2
Security Association (SA) negotiation. Section 4 presents conclusions associated with the
applicability of using IKE in the ATN. Section 5 provides references used to develop this paper.
2.
Brief Overview of IKE
IKE is used to negotiate security associations between a pair of communicating peers. It is
defined as part of Internet Protocol Security (IPSec). IPSec is currently in its third generation of
specification. The first generation (RFCs 1825-1829) did not specify a specific key management
protocol. IKEv1 was included in the second generation of specification (RFCs 2401-2412).
Specifically, IKEv1 was specified in RFCs 2407, 2408, and 2409. It was considered complex
and had some ambiguities that have led to interoperability problems. The third generation (RFCs
4301-4309) introduced IKEv2 (RFC 4306). IKEv2 attempts to address the specification
difficulties, security issues, and protocol inefficiencies of IKEv1.
IKEv1 is more mature and more widely deployed than IKEv2; however, IKEv2 is meant to
replace IKEv1. Therefore, the following subsections describe IKEv1 and IKEv2, although only
IKEv2 is investigated for use with ATN applications.
Page 2 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
2.1
IKE Version 1
IKEv1 combines features of the Internet Security Association and Key Management Protocol
(ISAKMP) and Oakley Key Determination Protocol in order to negotiate the Security
Associations for two communicating peers. IKEv1 also provides for key agreement using DiffieHellman and for key exchange.
IKEv1 uses two phases. Phase 1 is used to establish an ISAKMP Security Association for
IKEv1 itself. Phase 1 negotiates the authentication method to be used and the symmetric
encryption algorithm to be used, if any. Phase 1 is accomplished in either six messages (main
mode) or three messages (aggressive mode).
Phase 2 negotiates the Security Association for two IPsec peers and is accomplished with three
messages. IKEv1 is flexible enough that one Phase 1 negotiation may be used for multiple Phase
2 negotiations. In this manner, IKEv1 need not be performed by the IPsec peers themselves, but,
instead, may be performed on behalf of the IPsec peers. With this approach, anonymity can be
achieved, if necessary.
2.2
IKE Version 2
The IKEv2 specification is self-contained. It maintains the flexibility of IKEv1 and may be
somewhat less complex. IKEv2 continues to use two phases – IKE_SA_INIT and IKE_AUTH –
for the negotiation of security associations. Each phase consists of a request and a response;
therefore, four messages are required to establish the IKE_SA. In addition, the first child SA is
negotiated during the IKE_AUTH exchange.
In the IKE_SA_INIT exchange, the two peers negotiate the use of cryptographic algorithms and
exchange information used for key agreement. After this exchange, each peer generates the key
material used to derive the shared symmetric keys for authentication and encryption. These keys
are associated with the IKE_SA, which is bi-directional. At this point, the two peers have agreed
on cryptographic keys but they have not authenticated each other. These keys are used to protect
the IKE_AUTH exchange.
The IKE_AUTH exchange is used to provide mutual peer authentication and to establish the
security association for the use of IPSec between the two IKEv2 peers. Each peer asserts its
identity (e.g., IP address, fully-qualified domain name) and uses an authentication mechanism to
prove the assertion. This authentication mechanism may use digital signatures, Extensible
Authentication Protocol (EAP), or pre-shared keys. Each peer verifies the other peer’s assertion.
Once verified, mutual entity authentication is provided. If the verification fails, then the security
association negotiation fails and the IKE_SA negotiated in the IKE_SA_INIT exchange is
terminated.
The two peers negotiate the cryptographic algorithms to use, what traffic between the peers to
protect, and may optionally exchange additional key agreement material in the IKE_AUTH
Page 3 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
exchange. Certificates may also be exchanged. In this exchange, two unidirectional security
associations are created.
Once the IKE_AUTH exchange is completed, the two peers may negotiate additional security
associations using CREATE_CHILD_SA exchanges (two messages) or may participate in
INFORMATIONAL exchanges concerning the state of any of the security associations.
CREATE_CHILD_SA exchanges can be preformed to protect additional traffic between the two
IKE peers or can be conducted on behalf of other entities associated with the IKE peers (e.g., end
system applications behind an IPSec-capable router).
2.3
Comparison of IKEv1 and IKEv2
Some of the major similarities and differences between IKEv1 and IKEv2 are identified below.











3.
Both protocols utilize two phases. The first phase in each is used to create the IKE_SA. The
second phase is used to establish child SAs using the IKE_SA. In IKEv2, the first child SA
is piggybacked on the IKE_AUTH exchange that is used to complete the mutual peer
authentication.
Both protocols provide identify protection, denial-of-service protection mechanism, and
perfect forward secrecy.
Negotiation of the IKE_SA required 6 messages in IKEv1 and 4 messages in IKEv2. When
EAP is used in IKEv2, an additional 2 messages may be required.
Negotiation of the first CHILD_SA required 3 messages in IKEv1 and no messages in IKEv2
since it is piggybacked onto the negotiation of the IKE_SA.
Subsequent CHILD_SAs require 3 messages in IKEv1 and 2 messages in IKEv2.
IKEv1 and IKEv2 run over UDP port 500.
IKEv2 supports NAT traversal using UDP port 4500.
IKEv2 introduces retransmission and acknowledgement functions.
IKEv1 uses the more generic ISAKMP protocol specification so support for protocols other
than IPSec is more evident.
IKEv2 is written specifically for IPSec. However, it maintains support for other protocols by
allowing for the private specification of SA payloads between peers.
Security Association lifetimes were explicitly negotiated in IKEv1 but are not in IKEv2.
Each peer in IKEv2 maintains its own local policy for Security Association lifetime. When
the lifetime is about to expire, a rekeying operation is initiated.
IKEv2 Protocol Exchanges
This section identifies the typical IKEv2 protocol exchanges. It does not address exceptional
circumstances. Optional features of IKEv2 may also be used to alter the exchanges presented
here. These are also not addressed.
Page 4 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
3.1
IKE_SA_INIT
To begin the creation of the IKE_SA, the initiator sends the IKE_SA_INIT request to responder.
Initiator
HDR, SAi1, KEi, Ni
Responder

The header (HDR) identifies the initiator’s Security Parameter Index (i.e., the initiator’s
reference for the IKE_SA to be established), the IKE version number, flags specific to the
message, and a message identifier that is used for retransmissions and matching responses to
requests. The SAi1 payload includes the supported cryptographic algorithms for the IKE_SA.
The SAi1 payload identifies at least one proposal that contains algorithms for encryption, the
pseudorandom function, and integrity, and the proposed Diffie-Hellman group. The KEi payload
includes the initiator’s Diffie-Hellman value. The Ni payload contains the initiator’s nonce,
which is used to protect against replay attacks.
The following table identifies the typical size of an IKE_SA_INIT request message.
Payload
HDR (fixed size)
SAi1 (1proposal, 4 transforms)
KEi
Ni
Total
Size (octets)
28
48
8 + a (size of the Diffie-Hellman group)
4 + b (size of the nonce chosen by the initiator)
88 + a + b
To complete the creation of the IKE_SA, the responder sends the IKE_SA_INIT response to
initiator.
Initiator

Responder
HDR, SAr1, KEr, Nr,
[CERTREQ]
The header (HDR) includes the initiator’s Security Parameter Index, the responder’s Security
Parameter Index (i.e., the responder’s reference for the IKE_SA to be established), the IKE
version number, flags specific to the message, and the same message identifier as was used in the
IKE_SA_INIT request. The responder agrees to a proposal for the cryptographic algorithms and
identifies this in the SAr1 payload. The KEr payload includes the responder’s Diffie-Hellman
value. The Nr payload contains the responder’s nonce. Optionally, the responder may include
the CERTREQ payload to request the information necessary from the initiator to verify the
AUTH field that will be included in the IKE_AUTH exchange. This may be an X.509 certificate
or a number of other pre-defined values.
The following table identifies the typical size of an IKE_SA_INIT response message.
Page 5 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
Payload
HDR (fixed size)
SAr1 (1proposal, 4 transforms)
KEr
Nr
[CERTREQ]
Total
Size (octets)
28
48
8 + a (size of the Diffie-Hellman group)
4 + b (size of the nonce chosen by the initiator)
5 + c (size determined by what was requested)
88 + a + b
OR
93 + a + b + c
After the IKE_SA_INIT exchange, the IKE_SA is established and both parties can derive the
seed (SKEYSEED) from which all keys are derived. Seven keys are established from this seed.
One is used to derive keys for all CHILD_SAs associated with the IKE_SA. An encryption and
authentication (integrity protection) key are generated for each direction (4 keys). A key used
for the determination of an AUTH payload in the subsequent IKE_AUTH exchanges is
computed for each direction.
3.2
IKE_AUTH
To begin the creation of the IKE_SA, the initiator sends the IKE_SA_INIT request to responder.
Initiator
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr}
Responder

The header (HDR) includes the initiator’s Security Parameter Index, the responder’s Security
Parameter Index, the IKE version number, flags specific to the message, and the same message
identifier as was used in the IKE_SA_INIT request. The SK {…} notation indicates the
payloads within the curly braces are encrypted and integrity-protected using keys and algorithms
negotiated in the IKE_SA_INIT exchange. The initiator asserts its identity with the IDi payload.
The initiator includes its certificate in the CERT payload if it was requested in the IKE_SA_INIT
message from the responder. Optionally, the responder may include the CERTREQ payload to
request the information necessary from the initiator to verify the AUTH field that will be
included in the IKE_AUTH exchange. This may be an X.509 certificate or a number of other
pre-defined values. The responder may have more than one identify at a given address;
therefore, the initiator may optionally specify the identity with which it wishes to communicate.
The AUTH field is used to provide entity authentication to the responder. It is computed over
the first message sent by the initiator (the IKE_SA_INIT request), the responder’s nonce Nr, and
a value that is computed using the shared authentication key that is derived from SKEYSEED
after the IKE_SA_INIT exchange.
The SAi2 payload initiates the negotiation of the first non-IKE security association. The SAi2
payload identifies the protocol to be negotiated (e.g, Encapsulating Security Payload (ESP) or
Page 6 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
Authentication Header (AH)) and at least one proposal that contains algorithms for the specified
protocol. The TSi payload proposes what traffic from the initiator to the responder that is to be
protected. The TSr payload proposes what traffic from the responder to the initiator that is to be
protected.
The following table identifies the typical size of an IKE_AUTH request message. It assumes
negotiation of ESP with integrity protection using the same Diffie-Hellman group for key
agreement as was used in the IKE_SA_INIT exchange.
Payload
HDR (fixed size)
SK {
Initialization Vector
IDi
[CERT]
[CERTREQ]
[IDr]
AUTH
SAi2 (1proposal, 3 transforms)
TSi
TSr
Padding
Integrity Checksum Data
}
Total
Size (octets)
28
16
8 + a (size of identity)
[5 + b] (size of certificate data)
[5 + c] (size determined by what was
requested)
[8 + d] (size of identity)
8 + e (size of authentication data)
40 (assume ESP with integrity protection, same
Diffie-Hellman group as IKE)
8 + f (size of traffic selector data)
8 + g (size of traffic selector data)
1 + y (where y is 0 to 15 octets)
z
117 + a + e + f + g + y + z + [5 + b] + [5 + c] +
[8 + d]
To complete the IKE_AUTH exchange, the responder sends the IKE_AUTH response to the
initiator.
Initiator

Responder
HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The header (HDR) includes the initiator’s Security Parameter Index, the responder’s Security
Parameter Index, the IKE version number, flags specific to the message, and the same message
identifier as was used in the IKE_AUTH request. The SK {…} notation indicates the payloads
within the curly braces are encrypted and integrity-protected using keys and algorithms
negotiated in the IKE_SA_INIT exchange. The responder asserts its identity with the IDr
payload. When the initiator includes the IDr in the IKE_AUTH request, this value must be the
same. The responder includes its certificate in the CERT payload if it was requested in the
IKE_AUTH request message from the initiator. The AUTH field is used to provide entity
authentication to the initiator. It is computed over the first message sent by the responder (the
Page 7 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
IKE_SA_INIT response), the initiator’s nonce Ni, and a value that is computed using the shared
authentication key that is derived from SKEYSEED after the IKE_SA_INIT exchange.
The SAr2 payload completes the negotiation of the first non-IKE security association. The SAr2
payload identifies the negotiated protocol (e.g, Encapsulating Security Payload (ESP) or
Authentication Header (AH)) and accepts one proposal that contains algorithms for the specified
protocol. The TSi payload specifies the traffic from the initiator to the responder that is to be
protected. The TSr payload specifies the traffic from the responder to the initiator that is to be
protected.
The following table identifies the typical size of an IKE_AUTH response message. It assumes
negotiation of ESP with integrity protection using the same Diffie-Hellman group for key
agreement as was used in the IKE_SA_INIT exchange.
Payload
HDR (fixed size)
SK {
Initialization Vector
IDr
[CERT]
AUTH
SAr2 (1proposal, 3 transforms)
TSi
TSr
Padding
Integrity Checksum Data
}
Total
4.
Size (octets)
28
16
8 + a (size of identity)
[5 + b] (size of certificate data)
8 + e (size of authentication data)
40 (assume ESP with integrity protection, same
Diffie-Hellman group as IKE)
8 + f (size of traffic selector data)
8 + g (size of traffic selector data)
1 + y (where y is 0 to 15 octets)
z
117 + a + e + f + g + y + z + [5 + b]
Analysis
This section identifies the advantages and disadvantages with using IKEv2 in an ATN
environment. It also presents conclusions of the analysis of IKEv2 and its ability to support OSIbased applications.
4.1
Advantages
1. Goal 1: It achieves the first goal of removing the dependency on CM for key agreement.
2. Goal 2: IKEv2 can be used to perform key agreement exchanges on behalf of other
entities, thus removing the dependency for key exchange from CM. In fact, other
applications would not require their own key pairs since IKE derives a shared key
agreement key between the communicating peers.
Page 8 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
3. Goal 4: With modifications, IKEv2 can be used to support both OSI-based and IP-based
applications. IKEv2 can be used as-is for any IP-based applications.
4. IKEv1 is a proven solution, though with interoperability problems. IKEv2 streamlined
IKEv1 and corrected the known interoperability problems.
4.2
Disadvantages
1. Goal 4: IKEv2 as currently defined does not support OSI-based applications. Additional
standardization work is required to define operating over an OSI protocol stack and to
define OSI-specific payloads (e.g., ATN identities, OSI addresses, OSI traffic selectors,
ATN compressed certificates).
2. Goal 3: IKEv2 has large message sizes. IKEv2 messages contain reserved octets to retain
consistency with IKEv1.
3. Goal 3: Encryption in IKEv2 results in message expansion. Each encrypted payload is
prepended with an initialization vector that is the same size as the block size of the
negotiated encryption algorithm. Additionally, each message is padded to be multiple of
the block size. Each message contains a mandatory pad length field, so every message
contains some amount of padding. The method for determining these values could have
been specified rather than explicitly including them in exchanged messages. In the case
of AES, the initialization vector will be 16 octets. The pad length is 1 octet. The padding
will be from 0 to 15 octets. This results in a message expansion of 17-32 octets per
message.
4.3
Conclusions
Although IKEv2 achieves Goals 1 and 2, it does not fully meet Goals 3 and 4. IKEv2 can easily
be used to secure IP-based ground-ground communications. Additional standardization work
should result in a solution that easily supports IP-based and OSI-based ground-ground
communications. However, the protocol exchanges in IKEv2 are too inefficient for use in
bandwidth-constrained environments.
Page 9 of 10
ACP/WG N/SG N4 WP0902
(WP0804)
5.
References
[KGP06]
[RFC4306]
[RFC2407]
[RFC2408]
[RFC2409]
Paterson, Kenneth G., A Cryptographic Tour of the IPsec Standards. Currently
available at: http://eprint.iacr.org/2006/097.
C. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December
2005. Currently available at: http://www.ietf.org/rfc/rfc4306.txt.
D. Piper, “The Internet IP Security Domain of Interpretation for ISAKMP." RFC
2407, Nov. 1998. Currently available at: http://www.ietf.org/rfc/rfc2407.txt.
D. Maughan, M. Schertler, M. Schneider and J. Turner, “Internet Security
Association and Key Management Protocol (ISAKMP)." RFC 2408, Nov. 1998.
Currently available at: http://www.ietf.org/rfc/rfc2408.txt.
D. Harkins and D. Carrel, “The Internet Key Exchange (IKE)." RFC 2409, Nov.
1998. Currently available at: http://www.ietf.org/rfc/rfc2409.txt.
Page 10 of 10