Résumé

  • RFC 5419 conserve le raisonnement en faveur de l’authentification des Binding Updates de Mobile IPv6 par le réseau AAA d’origine, mais son exemple ne transforme pas la remise de clé d’AAA au Home Agent en contrat général de l’IETF.
  • Le texte sépare l’échange RADIUS illustré d’un mécanisme normatif permettant de créer l’association MN–HA à partir de l’association MN–AAA.
  • RFC 4877 a ensuite proposé la voie IKEv2/IPsec et rendu certains arguments antérieurs moins pertinents ; le raisonnement de 2009 ne prouve rien sur le déploiement actuel.

Une décision AAA ne crée pas encore une association de sécurité

Mobile IPv6 permet à un nœud de conserver son adresse d’origine lorsqu’il se connecte ailleurs. Il adresse un Binding Update (BU) à un Home Agent (HA) pour annoncer son adresse temporaire ; le HA conserve cette liaison et peut lui acheminer les paquets par tunnel. Dans le modèle de base, la signalisation entre le nœud mobile (MN) et le HA est protégée par une association de sécurité IPsec. Les extrémités sont définies. La difficulté pratique est de leur fournir des informations cryptographiques compatibles quand l’autorité chargée des abonnés se trouve dans un autre système.

Publié en janvier 2009, RFC 5419 archive les raisons qui ont conduit à RFC 4285 et à son option d’authentification des messages de mobilité. C’est un document informatif ; il précise que cette solution ne déprécie pas la voie IPsec. Ses cas d’usage viennent des architectures CDMA2000 et WiMAX décrites à l’époque par ses auteurs. Ils cherchaient à réutiliser le système AAA d’origine pour authentifier les abonnés, consulter leurs profils et attribuer dynamiquement une adresse d’origine ou un HA. Il s’agit d’exigences historiques rapportées par le texte, pas de mesures des réseaux actuels. (RFC 5419, §§ 1 et 5)

RFC 4285 définit deux options utiles à cette histoire. L’option MN–AAA permet au nœud de protéger son BU à l’aide de l’association de sécurité partagée avec le serveur AAA du réseau d’origine. La réponse du HA, le Binding Acknowledgement, doit en revanche utiliser l’option MN–HA. Le RFC indique que le HA s’appuie sur l’authentification effectuée par une entité AAA externe, joignable sur un canal authentifié ; il laisse hors de son périmètre les détails de l’échange entre HA et AAA. L’authentification de la demande et la clé nécessaire à la réponse reposent donc sur des états liés, mais distincts. (RFC 4285, § 5.2)

La séquence RADIUS montre la jonction

RFC 5419 décrit un exemple CDMA2000. Le HA transmet à un serveur RADIUS les données d’authentification reçues. AAA vérifie le BU, calcule une clé de session à partir du secret partagé MN–AAA et de l’horodatage, puis renvoie la clé au HA dans un Access-Accept, au moyen d’un attribut spécifique à 3GPP2. Le HA l’associe à une SA MN–HA — l’exemple utilise le SPI 5 — puis authentifie le Binding Acknowledgement. Le nœud mobile calcule la clé correspondante afin de vérifier la réponse et de protéger les BU suivants. (RFC 5419, § 6.2)

Ce chemin met en lumière une frontière de contrôle. L’authentification de l’abonné commence avec un secret partagé entre MN et AAA. La signalisation ultérieure exige une clé utilisable entre MN et HA. L’exemple montre comment un profil de réseau particulier peut transférer le matériel de session entre ces rôles ; l’attribut RADIUS mentionné dépend de 3GPP2 et ne constitue pas un attribut universel défini par RFC 4285.

Le texte formule ensuite la limite sans détour : RFC 4285 ne spécifie pas de mécanisme permettant de créer la clé partagée et la SA MN–HA à partir de l’association MN–AAA. Il dépend de mécanismes propres au déploiement, non normalisés par l’IETF. RFC 5419 oppose ce point à RFC 3957, qui définit pour Mobile IPv4 une nonce de génération et des étapes de dérivation. Cela ne signifie pas que RFC 4285 ne puisse fonctionner. Cela précise l’endroit où s’arrête le contrat d’interopérabilité. Un schéma peut montrer une clé remise au HA ; il ne rend pas, à lui seul, la dérivation, la liaison à l’identité, la portée de la clé et sa livraison portables d’une implémentation à l’autre. (RFC 5419, § 7 ; RFC 3957, § 5)

La critique doit rester mesurée. L’option d’authentification de RFC 4285 n’est pas nécessairement une conception défectueuse, et un profil local peut préciser ce qui manque. Mais quand les détails sont locaux, l’opérateur doit savoir quels éléments les partagent : le nœud mobile, le service AAA, les attributs RADIUS, le HA et le mécanisme qui associe l’abonné à un HA choisi dynamiquement. Le format des messages ne certifie pas toute cette chaîne.

Le raisonnement a évolué pendant son archivage

RFC 5419 tient compte de sa propre chronologie. Publié en 2007, RFC 4877 spécifie le fonctionnement de Mobile IPv6 avec IKEv2 et l’architecture IPsec révisée. RFC 5419 dit que cette intégration avec le backend AAA a réduit certaines difficultés et rendu redondants plusieurs arguments initiaux. Il relève aussi que RFC 5026 et des travaux connexes ont traité l’amorçage avec adresse d’origine et HA dynamiques. Il ne faut donc pas citer le document de 2009 comme un verdict intemporel sur la seule architecture possible. (RFC 4877 ; RFC 5026 ; RFC 5419, §§ 1, 5 et 9)

Le cas qui subsistait était plus restreint. Les auteurs écrivaient que certains terminaux des environnements étudiés ne prendraient peut-être pas en charge IKEv2, que les échanges supplémentaires pouvaient compter sur une interface radio contrainte et que les opérateurs souhaitaient conserver la gestion des identités et des services dans leur modèle AAA. Ce sont des arguments datés, attribuables à ces auteurs. Ils ne disent pas combien de terminaux prennent aujourd’hui en charge IKEv2, si ces réseaux fonctionnent encore, ni quelle solution un opérateur devrait adopter maintenant.

La voie de l’option d’authentification comporte aussi des limites. RFC 5419 cite notamment les protections supplémentaires requises pour l’optimisation de route, l’absence de négociation d’algorithme dans l’option, la dépendance à des horloges suffisamment synchronisées pour la protection contre le rejeu, et les risques de confidentialité lorsque l’identifiant réseau de longue durée est visible. Le texte précise également que l’association MN–AAA est établie hors bande. Ces éléments définissent les conditions qu’un profil doit traiter ; ils ne suffisent pas à invalider la solution. (RFC 5419, § 7)

Lire chaque document à son niveau de preuve

Trois types d’éléments se côtoient ici. RFC 4285 définit les formats d’options et leur traitement. RFC 5419 conserve un raisonnement et un exemple RADIUS situé dans son époque. RFC 3957 fournit une comparaison de dérivation de clés pour Mobile IPv4, tandis que RFC 4877 décrit une autre voie avec IKEv2 et IPsec. Aucun de ces documents ne prouve quelle implémentation a été livrée dans un réseau donné ni quel profil y fonctionne aujourd’hui.

Dans une revue d’architecture, l’opérateur doit donc demander d’où vient le secret partagé, comment la clé de session est liée à l’abonné et au HA sélectionné, quel attribut RADIUS la transporte, comment les extrémités fixent sa durée de vie et l’état anti-rejeu, et que se passe-t-il si AAA accepte alors que le HA ne peut pas installer la SA attendue. Si ces réponses figurent dans un profil propriétaire, ce profil fait partie de la conception de sécurité et doit être versionné, testé et migré comme tel.

Si IKEv2 fournit l’association nécessaire, il faut démontrer son intégration AAA et sa prise en charge par les versions réellement déployées, au lieu de les déduire de la publication d’un RFC.

La leçon durable de RFC 5419 n’est pas qu’une option a gagné. Une décision centrale sur l’abonné et une relation cryptographique entre MN et HA sont deux pièces distinctes de l’infrastructure. Un échange normalisé, une extension documentée ou un autre protocole de gestion des clés peuvent les relier. Mais le mot « authentifié » ne prouve pas que la clé est arrivée au bon endpoint.

Sources