Pour faire face à la complexité de configuration de IKEv1 et à son manque d'efficacité, une seconde version de IKE [Kau-id] a été définie dans le but d'être facilement utilisable sur des VPNs mettant en jeu des fournisseurs d'équipements différents. Pour faciliter sa lecture, le protocole IKEv2 se trouve décrit dans un document unique qui regroupe les informations précédemment réparties dans les RFC 2407 (domaine d'interprétation), RFC 2408 (ISAKMP), RFC 2409 (IKEv1), RFC 3947 RFC 3948 (NAT-traversal). Ce protocole n'a plus le caractère générique de IKEv1 et supprime donc la notion de domaine d'interprétation.

IKEv2 a été défini avec comme objectifs de simplifier le protocole IKEv1, d'enlever les conditions inutiles d'ISAKMP et IKEv1 et d'incorporer de nouvelles fonctionnalités dans le protocole IPsec. L'objectif général est de clarifier au maximum l'utilisation du protocole et de rendre son implémentation plus facile. A ce titre, IKEv2 est moins flexible que IKEv1 ; de plus, IKEv2 introduit une refonte importante, puisqu'il propose de passer à une négociation des phases 1 et 2 en quatre messages. De ce fait, le nouveau protocole apparaît tellement différent de l'actuel qu'il ne sera pas compatible, d'où le changement de numéro de version majeure.

IKEv2 est semblable à IKEv1 dans l'authentification mutuelle des entités et l'établissement des associations de sécurité ISAKMP et de clés partagées. Ainsi :

• les deux premiers messages de IKEv2 présentés à la figure Echanges de IKEv2 (main mode) sont équivalents aux quatre premiers messages de IKEv1 en Main Mode. Les SA ISAKMP unidirectionnels apparaissent sous la notation SAi1 et SAr1.

• Les deux derniers messages sont équivalents aux deux derniers messages de phase 1 de IKEv1 en Main Mode et aux deux messages de phase 2 de IKEv1 en Quick Mode. En particulier, les deux derniers messages permettent aux équipements IPsec de prendre connaissance de leurs identifiants respectifs (ce qui est particulièrement utile en cas d'entités multiples hébergées sur une même machine), de s'authentifier grâce au bloc AUTH, de négocier des associations de sécurité IPsec unidirectionnelles (SAi2 et SAr2) qui sont appelées dans IKEv2 CHILD_SA et d'identifier le trafic protégé par ces SA IPsec en précisant les sélecteurs choisis dans les blocs TSi et TSr (TS pour Traffic Selector).

Le bloc CERT consiste en une liste de certificats, avec le premier certificat de la liste utilisé pour générer le bloc AUTH. Le partenaire peut également forcer un équipement à retourner une liste de certificats en émettant un bloc CERTREQ contenant la liste des certificats préférés. Cette liste comprend en fait la liste des autorités de certification reconnues de confiance dont les identités sont hachées avant d'être placées dans le bloc CERTREQ.