5. Security Considerations
5. Security Considerations
Bien que ce protocole soit conçu pour limiter la divulgation d'informations de configuration aux pairs non authentifiés, une telle divulgation ne peut être totalement évitée. L'un des pairs doit s'identifier et prouver son identité en premier. Pour éviter le sondage, l'initiateur d'un échange doit s'identifier en premier et en général s'authentifier en premier. L'initiateur peut toutefois apprendre que le répondeur prend en charge IKE et quels protocoles cryptographiques il accepte. Le répondeur (ou un usurpateur) peut non seulement sonder l'initiateur pour son identité, mais aussi, au moyen de charges utiles CERTREQ, déterminer quels certificats l'initiateur est prêt à utiliser.
L'utilisation de l'authentification EAP modifie quelque peu les possibilités de sondage. Avec EAP, le répondeur prouve son identité avant l'initiateur ; un initiateur connaissant le nom d'un initiateur valide pourrait donc sonder le répondeur sur son nom et ses certificats.
Des renégociations répétées via CREATE_CHILD_SA sans échanges Diffie-Hellman supplémentaires exposent toutes les SA à la cryptanalyse d'une seule clé. Les implémentateurs doivent en tenir compte et fixer une limite aux échanges CREATE_CHILD_SA entre deux exponentiations. Le présent document ne prescrit pas une telle limite.
La robustesse d'une clé dérivée d'un échange Diffie-Hellman avec l'un des groupes définis ici dépend de la force intrinsèque du groupe, de la taille de l'exposant et de l'entropie fournie par le générateur aléatoire. Il est donc difficile d'évaluer la force pour chaque groupe. Le groupe Diffie-Hellman numéro deux, avec un générateur aléatoire solide et un exposant d'au moins 200 bits, est couramment utilisé avec 3DES. Le groupe cinq offre une sécurité supérieure au groupe deux. Le groupe un est uniquement historique et n'offre pas une force suffisante sauf avec DES, lui aussi historique. Les implémentations doivent tenir compte de ces estimations lors de la définition des politiques et de la négociation des paramètres de sécurité.
Ces limites concernent les groupes Diffie-Hellman eux-mêmes. Rien dans IKE n'interdit des groupes plus forts ni ne réduit la force obtenue (bornée par celle des autres algorithmes négociés, dont le PRF (Pseudorandom Function)). Le cadre extensible d'IKE encourage au contraire la définition de nouveaux groupes ; les courbes elliptiques peuvent fortement augmenter la force avec des nombres bien plus petits.
On suppose que tous les exposants Diffie-Hellman sont effacés de la mémoire après usage.
Les échanges IKE_SA_INIT et IKE_AUTH ont lieu avant l'authentification de l'initiateur. Une implémentation doit donc être parfaitement robuste sur tout réseau non sécurisé. Des vulnérabilités d'implémentation, en particulier des attaques par déni de service, peuvent être exploitées par des pairs non authentifiés. La question est d'autant plus préoccupante qu'il n'y a pas de limite au nombre de messages dans l'authentification EAP.
La robustesse de toutes les clés est limitée par la taille de sortie du PRF négocié. Pour cette raison, un PRF dont la sortie fait moins de 128 bits (par ex. 3DES-CBC) NE DOIT PAS être utilisé avec ce protocole.
La sécurité du protocole dépend de manière critique du caractère aléatoire des paramètres choisis au hasard. Ils doivent être produits par une source aléatoire forte ou pseudo-aléatoire correctement amorcée (voir [RANDOMNESS]). Les implémentateurs doivent veiller à ce que l'emploi des nombres aléatoires pour les clés et les nonces ne compromette pas la sécurité des clés.
Pour la justification de nombreux choix de conception cryptographique, voir [SIGMA] et [SKEME]. Bien que la sécurité des Child SA négociées ne dépende pas de la force du chiffrement et de l'intégrité négociés dans la SA IKE, les implémentations NE DOIVENT PAS négocier NONE comme algorithme d'intégrité IKE ni ENCR_NULL comme algorithme de chiffrement IKE.
Avec des clés pré-partagées, il est essentiel d'assurer leur caractère aléatoire. La meilleure pratique est que toute clé pré-partagée contienne autant d'aléa que la clé la plus forte négociée. Dériver un secret partagé à partir d'un mot de passe, d'un nom ou d'une autre source à faible entropie n'est pas sûr. Ces sources sont vulnérables aux attaques par dictionnaire et d'ingénierie sociale, entre autres.
Les notifications NAT_DETECTION_*_IP contiennent un hachage des adresses et ports pour tenter de masquer les adresses IP internes derrière un NAT. Comme l'espace d'adressage IPv4 n'a que 32 bits et est en général très clairsemé, un attaquant pourrait retrouver l'adresse interne derrière le NAT en essayant toutes les adresses IP et en comparant le hachage. Les numéros de port sont en général fixés à 500 et les SPI peuvent être extraits du paquet, ce qui ramène le travail à 2^32 calculs de hachage. Avec une hypothèse raisonnable sur l'espace d'adressage privé, le nombre de calculs est bien moindre. Les concepteurs ne doivent donc pas présumer que l'usage d'IKE ne divulgue pas d'informations sur les adresses internes.
Avec une méthode EAP qui ne produit pas de clé partagée pour protéger une charge utile AUTH ultérieure, certaines attaques par interposition et usurpation de serveur sont possibles [EAPMITM]. Ces faiblesses apparaissent lorsque EAP est aussi utilisé dans des protocoles non protégés par un tunnel sécurisé. Comme EAP est un protocole d'authentification général, souvent utilisé pour l'authentification unique, une solution IPsec déployée qui repose sur une méthode EAP sans génération de clé (méthode EAP non génératrice de clé) peut être compromise par le déploiement d'une application sans rapport qui utilise la même méthode sans protection. Cette vulnérabilité ne se limite pas à EAP et peut survenir lorsque une infrastructure d'authentification est réutilisée. Par exemple, si le mécanisme EAP utilisé par IKEv2 s'appuie sur un authentificateur à jeton, un attaquant interposé peut usurper le serveur Web, intercepter l'échange par jeton et l'utiliser pour ouvrir une session IKEv2. Pour cette raison, l'usage des méthodes EAP non génératrices de clé DEVRAIT être évité lorsque c'est possible. Lorsqu'elles sont employées, il est extrêmement important que tous les usages de ces méthodes DEVRAIENT utiliser un tunnel protégé où l'initiateur valide le certificat du répondeur avant de lancer l'authentification EAP. Les implémentateurs DEVRAIENT décrire dans la documentation les risques liés aux méthodes EAP non génératrices de clé afin que les administrateurs en soient conscients.
Une implémentation utilisant EAP DOIT également employer une authentification du serveur vers le client basée sur clé publique avant le début de l'authentification EAP, même si la méthode EAP offre une authentification mutuelle. Cela évite des variantes supplémentaires du protocole IKEv2 et protège les données EAP contre les attaquants actifs.
Si les messages IKEv2 sont assez longs pour nécessiter une fragmentation IP, des attaquants pourraient empêcher l'achèvement de l'échange en saturant les tampons de réassemblage. On peut réduire ce risque en utilisant les encodages Hash and URL au lieu d'envoyer les certificats (voir la section 3.6). D'autres mesures sont discutées dans [DOSUDPPROT].
Le contrôle d'admission est crucial pour la sécurité du protocole. Par exemple, les ancres de confiance pour identifier les pairs IKE devraient probablement différer de celles utilisées pour d'autres formes de confiance, comme les serveurs Web publics. De plus, bien qu'IKE laisse une grande liberté pour définir la politique de sécurité liée à l'identité, aux justificatifs et à leur corrélation pour un pair de confiance, la définition explicite de cette politique est indispensable à une implémentation sûre.