This post is the result of a “bug in my ear” placed there by a colleague after discussions between fellow instructors. I will attempt to conduct a brief explanation of the highlights of Internet Key Exchange version 2 (IKE v2). This first part summarizes the enhancements to the protocol; the second part covers its implementation on Cisco security devices.
As anyone who has configured IPSec knows, the initiator is encryption endpoint which receives the “interesting traffic” (i.e. that which qualifies for encryption) first and hence starts the two-phase negotiation process. While RFC2408 allows flexibility in the Minor Version used for IKEv1; RFC4306 requires this field to be set to zero. RFC4306 introduces 4 new exchange types, IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, and INFORMATIONAL starting at a value of 34 which are unused by IKEv1.
Several improvements to the protocol are noteworthy. First, the Message ID in version 2 was adapted for using sequence and acknowledgment numbers for more reliable delivery. As the RFC describes, this exchange is “full duplex” meaning that each end-point must keep track of both the Message ID it expects to receive from the peer as well as the next one it will send.
A second significant improvement in IKEv2 is the support for additional encryption, message hash, Diffie-Hellman groups, and authentication methods. Advanced Encryption Standard Counter Mode (AES-CTR) mode as an encryption algorithm is now supported, a stream cipher whose specifics are referenced below. The additional hash function, AES-XCBC-PRF-128 is included. IKEv2 also supports Diffie-Hellman Group 14, using 2048-bit values (vs. Group 5 at 1536 bits, the strongest supported in IKEv1.) RFC3526 provides the specifics for these groups, while RFC5114 presents even stronger possibilities which can optionally be implemented in IKEv2. Finally, Extensible Authentication Protocol (EAP) authentication methods are supported as defined in RFC3748.