5. Considérations de sécurité

Bien que ce protocole vise à minimiser la divulgation d'informations de configuration à une paire non authentifiée, une telle divulgation est inévitable. L'une ou l'autre partie doit d'abord s'identifier et d'abord prouver son identité. Pour éviter le sondage, l'initiateur de l'échange est tenu de s'identifier en premier, et est généralement tenu de s'authentifier en premier. Cependant, l'initiateur peut apprendre que le répondeur prend en charge IKE et quels protocoles cryptographiques il prend en charge. Le répondeur (ou quelqu'un se faisant passer pour le répondeur) peut, via le payload CERTREQ, non seulement sonder l'identité de l'initiateur, mais aussi déterminer les certificats que l'initiateur est disposé à utiliser.

L'utilisation de l'authentification EAP modifie quelque peu les possibilités de sondage. Lorsque l'authentification EAP est utilisée, le répondeur prouve son identité avant l'initiateur, de sorte qu'un initiateur connaissant un nom d'initiateur valide peut sonder à la fois le nom et le certificat du répondeur.

Le rekeying répété à l'aide de CREATE_CHILD_SA sans échange Diffie-Hellman supplémentaire rend toutes les SA vulnérables à l'analyse cryptographique contre une clé unique. Les implémenteurs doivent être conscients de ce fait et imposer une limite au nombre d'échanges CREATE_CHILD_SA entre les exponentiations. Ce document ne prescrit pas une telle limite.

La force des clés dérivées d'un échange Diffie-Hellman à partir de n'importe quel groupe défini ici dépend de la force intrinsèque du groupe lui-même, de la taille des exposants utilisés et de l'entropie fournie par le générateur de nombres aléatoires utilisé. En raison de ces entrées, il est difficile de déterminer la force des clés pour n'importe quel groupe défini. Lorsqu'il est utilisé avec un générateur de nombres aléatoires fort et que l'exposant n'est pas inférieur à 200 bits, le groupe Diffie-Hellman 2 est couramment utilisé avec 3DES. Le groupe 5 offre une meilleure sécurité que le groupe 2. Le groupe 1 n'est destiné qu'à des fins historiques et ne fournit pas une force suffisante, sauf pour être utilisé avec DES, qui est également destiné uniquement à des fins historiques. Les implémenteurs doivent prêter attention à ces estimations lors de l'établissement de politiques et de la négociation de paramètres de sécurité.

Notez que ces limitations concernent le groupe Diffie-Hellman lui-même. Rien dans IKE n'interdit l'utilisation d'un groupe plus fort, ni n'affaiblit la force obtenue à partir d'un groupe plus fort (sous réserve de la force des autres algorithmes négociés, y compris la PRF). En fait, le cadre extensible d'IKE encourage la définition de groupes supplémentaires ; l'utilisation de groupes à courbe elliptique peut grandement améliorer la force avec des nombres beaucoup plus petits.

On suppose que tous les exposants Diffie-Hellman sont effacés de la mémoire après utilisation.

Les échanges IKE_SA_INIT et IKE_AUTH se produisent avant que l'initiateur ne soit authentifié. Par conséquent, les implémentations de ce protocole déployées sur tout réseau non sécurisé doivent être totalement robustes. Les vulnérabilités d'implémentation, en particulier les attaques DoS, pourraient être exploitées par une paire non authentifiée. Ce problème est particulièrement préoccupant car le nombre de messages dans l'authentification basée sur EAP n'est pas limité.

La force de toutes les clés est limitée par la taille de sortie de la PRF négociée. Par conséquent, une PRF dont la sortie est inférieure à 128 bits (par exemple 3DES-CBC) NE DOIT PAS être utilisée avec ce protocole.

La sécurité de ce protocole dépend de façon critique de l'aléatoire des paramètres choisis aléatoirement. Ces paramètres doivent être générés par une source aléatoire forte ou pseudo-aléatoire correctement amorcée (voir [RANDOMNESS]). Les implémenteurs doivent veiller à ce que les nombres aléatoires utilisés à la fois pour les clés et les nonces ne compromettent pas la sécurité des clés.

Pour la justification de nombreux choix de conception cryptographique de ce protocole, voir [SIGMA] et [SKEME]. Bien que la sécurité d'une Child SA négociée ne dépende pas de la force du chiffrement et de la protection d'intégrité négociés dans la IKE SA, les implémentations NE DOIVENT PAS négocier NONE comme algorithme de protection d'intégrité IKE, ni ENCR_NULL comme algorithme de chiffrement IKE.

Lors de l'utilisation de clés pré-partagées, une considération clé est de garantir l'aléatoire de ces secrets. L'approche la plus forte consiste à s'assurer que toute clé pré-partagée contient autant d'aléatoire que la clé la plus forte négociée. Dériver un secret partagé à partir de mots de passe, de noms ou d'autres sources à faible entropie n'est pas sûr. Ces sources sont vulnérables aux attaques par dictionnaire et à l'ingénierie sociale, entre autres.

Les notifications NAT_DETECTION_*_IP contiennent un hachage de l'adresse et du port, tentant de masquer l'adresse IP interne derrière le NAT. Étant donné que l'espace d'adressage IPv4 n'a que 32 bits et est généralement très clairsemé, un attaquant pourrait découvrir l'adresse interne utilisée derrière la box NAT en essayant toutes les adresses IP possibles et en cherchant un hachage correspondant. Le numéro de port est généralement fixé à 500, et le SPI peut être extrait du paquet. Cela réduit le nombre de calculs de hachage à 2^32. En devinant judicieusement l'utilisation de l'espace d'adressage privé, le nombre de calculs de hachage est beaucoup plus petit. Par conséquent, les concepteurs ne doivent pas supposer que l'utilisation d'IKE ne divulgue pas d'informations sur l'adresse interne.

Lors de l'utilisation de méthodes d'authentification EAP qui ne génèrent pas de clé partagée pour protéger les payloads AUTH ultérieurs, certaines attaques de l'homme du milieu et d'usurpation de serveur peuvent se produire [EAPMITM]. Ces vulnérabilités surviennent lorsque EAP est également utilisé pour des protocoles non protégés par un tunnel sécurisé. Comme EAP est un protocole d'authentification générique, souvent utilisé pour fournir une fonctionnalité d'authentification unique, les solutions IPsec déployées s'appuyant sur des méthodes d'authentification EAP ne générant pas de clé (également appelées méthodes EAP non génératrices de clé) pourraient être compromises par le déploiement d'une application totalement non liée utilisant par hasard la même méthode EAP non génératrice de clé mais fonctionnant de manière insuffisamment protégée. Notez que cette vulnérabilité n'est pas limitée à EAP et peut également survenir dans d'autres scénarios où l'infrastructure d'authentification est réutilisée. Par exemple, si le mécanisme EAP utilisé par IKEv2 utilise un authentificateur à jeton, un attaquant de l'homme du milieu pourrait usurper l'identité d'un serveur Web, intercepter l'échange d'authentification par jeton et l'utiliser pour lancer une connexion IKEv2. Par conséquent, l'utilisation de méthodes EAP non génératrices de clé doit être évitée dans la mesure du possible. Lors de l'utilisation de ces méthodes, il est extrêmement important que toutes ces utilisations de méthodes EAP utilisent un tunnel protégé dans lequel l'initiateur vérifie le certificat du répondeur avant de démarrer l'authentification EAP. Les implémenteurs doivent décrire, dans la documentation de leur implémentation, les vulnérabilités liées à l'utilisation de méthodes EAP non génératrices de clé, afin que les administrateurs déployant des solutions IPsec soient conscients de ces dangers.

Les implémentations utilisant EAP DOIVENT également utiliser une authentification basée sur une clé publique serveur-client avant le début de l'authentification EAP, même si la méthode EAP fournit une authentification mutuelle. Cela évite des variantes supplémentaires du protocole IKEv2 et protège les données EAP contre les attaquants actifs.

Si un message IKEv2 est si long qu'il nécessite une fragmentation au niveau IP, un attaquant pourrait empêcher l'achèvement de l'échange en épuisant le tampon de réassemblage. L'utilisation du codage Hash and URL au lieu d'envoyer des certificats (voir section 3.6) permet de minimiser cette possibilité. D'autres atténuations sont discutées dans [DOSUDPPROT].

Le contrôle d'admission est crucial pour la sécurité du protocole. Par exemple, l'ancre de confiance utilisée pour identifier la paire IKE devrait probablement être différente de l'ancre de confiance utilisée pour d'autres formes de confiance (telle que l'identification des serveurs Web publics). De plus, bien qu'IKE offre une grande liberté dans la définition de politiques de sécurité pour l'identité, les informations d'identification et leur association entre les pairs approuvés, la définition explicite de telles politiques de sécurité est essentielle pour une implémentation sûre.