Résumé

  • RFC 3012 permit à l’agent étranger Mobile IPv4 d’émettre un défi récent et de distinguer sa présence, sa réutilisation et son absence de la fenêtre connue avant la fin de l’authentification AAA.
  • La bonne valeur ne prouvait ni l’identité ni l’autorisation : elle devait encore être liée à une extension d’authentification, à une décision distante, à une inscription acceptée et à un trafic réellement acheminé.

Le roaming créait une dissymétrie simple. L’appareil se trouvait devant l’agent étranger, mais le secret capable de l’identifier pouvait rester dans son domaine d’origine. Le réseau visité devait recevoir une demande d’inscription sans nécessairement disposer d’une association de sécurité directe avec le demandeur.

Reporter toute décision vers une infrastructure distante ne résolvait pas le premier risque. Une ancienne demande pouvait être rejouée avant même que l’Authentication, Authorization and Accounting ait répondu. L’agent étranger avait besoin d’un élément qu’il contrôlait lui-même.

Publié en novembre 2000, RFC 3012 lui donna cet élément. Une extension Challenge pouvait être insérée dans l’Agent Advertisement. La valeur, aléatoire et d’au moins 32 bits en principe, était ensuite recopiée par le mobile dans une extension MN-FA Challenge de sa Registration Request.

Le détail décisif était l’émetteur. Le défi provenait de la passerelle du réseau visité. Celle-ci pouvait donc constater qu’une demande répondait à son propre état récent, même si elle ignorait encore qui détenait les justificatifs du mobile. La fraîcheur devenait locale ; la confiance restait distribuée.

RFC 3012 refusa aussitôt d’élever le défi au rang de preuve autonome. Après l’extension MN-FA Challenge devait venir soit Mobile-Foreign Authentication, soit MN-AAA Authentication. Un message portant le défi sans l’une de ces deux liaisons devait être abandonné silencieusement.

Avec une association de sécurité directe, l’authentification Mobile-Foreign pouvait couvrir la requête. Sans elle, le mobile devait fournir MN-AAA et était invité à inclure le Network Access Identifier de RFC 2794. Le realm de ce nom aidait à diriger la vérification vers le bon domaine administratif ; il ne démontrait pas que l’émetteur possédait l’identité annoncée.

L’ordre des extensions dessinait ainsi une hiérarchie de faits. Le défi disait quelle valeur récente était invoquée. L’authenticator liait les données à un secret et à un algorithme choisi par un SPI. L’infrastructure distante jugeait les justificatifs. La politique décidait ensuite si une inscription pouvait être autorisée.

Trois codes rendaient l’histoire locale observable. MISSING_CHALLENGE signalait l’absence d’un champ exigé. STALE_CHALLENGE désignait une valeur déjà employée par ce mobile. UNKNOWN_CHALLENGE couvrait une valeur qui n’était ni celle renvoyée lors du dernier succès, ni l’une des annonces récentes dans CHALLENGE_WINDOW. Le registre IANA Mobile IPv4 conserve ces affectations.

Les trois résultats ne signifiaient pas simplement « mauvais mot de passe ». Ils localisaient une rupture différente : forme incomplète, historique de réemploi ou absence de provenance récente chez cet agent. Un journal qui les ramène tous à « échec d’authentification » détruit précisément l’information que le protocole avait séparée.

La retransmission formait l’exception indispensable. Si le mobile renvoyait la même requête avec le même champ Identification de 64 bits et le même défi, tandis que l’agent étranger conservait encore l’enregistrement correspondant comme pending, la requête pouvait être transmise de nouveau. En dehors de cet état vivant, la réutilisation devenait normalement stale.

Cette exception révèle le vrai matériau de la protection contre le rejeu : la mémoire. Il faut savoir quelle valeur fut émise, pour quel mobile, quel Identification l’accompagnait, si la transaction attend encore une réponse et quand son état expire. Interdire toute répétition casserait les pertes réseau ; tolérer toute valeur récente ouvrirait la fenêtre.

La réponse du Home Agent devait elle aussi être rattachée à la transaction. Lorsque le défi restait dans la requête transmise, l’agent étranger devait le conserver avec son état pending. Une Registration Reply dépourvue de la même valeur devait être rejetée. Cette égalité ne prouvait pas que l’utilisateur disposait d’un service ; elle prouvait seulement que le résultat distant correspondait à la demande locale observée.

Dans le cas d’une association MN-FA directe, l’agent pouvait vérifier puis retirer son défi avant le transfert. Il devait alors garder l’Identification de la requête dans ses propres données. L’encodage changeait, pas l’obligation de préserver la frontière de rejeu.

L’infrastructure AAA demeurait volontairement hors du protocole. L’annexe de RFC 3012 parlait de « verification infrastructure ». L’agent pouvait lui remettre le matériau d’authentification et attendre un résultat protégé, mais la norme ne fixait ni le protocole utilisé ni l’entité qui réalisait la vérification.

Ce choix maintenait une couche commune mince. Mobile IPv4 précisait la forme de l’échange et les contrôles disponibles à la périphérie. Les systèmes administratifs conservaient leurs secrets, comptes et politiques. La norme reliait les responsabilités sans transformer un fournisseur AAA en constitution du roaming.

Pour rejoindre les installations de l’époque, le SPI réservé CHAP_SPI 2 décrivait un calcul MD5 de style CHAP cohérent avec les usages RADIUS. La section de sécurité avertissait toutefois que cette construction était moins sûre que HMAC-MD5 et devait être évitée lorsque c’était possible. La compatibilité était une passerelle, non une promesse d’éternité cryptographique.

Le texte reconnaissait aussi un risque de déni de service. Une requête rejouée pouvait provoquer une réponse donnant l’apparence d’un rejet, alors qu’une acceptation légitime était encore en route. Le mobile pouvait réagir au premier signal sans voir que deux transactions temporelles se croisaient. La fraîcheur bornait un problème ; elle n’abolissait ni la course ni l’épuisement d’état.

Un défi plus court que quatre octets exigeait même de conserver l’Identification pour renforcer l’assurance d’unicité. Qualifier une valeur de « random » ne créait pas l’entropie manquante. Taille, historique et identité de transaction se complétaient selon des règles explicites.

En 2007, RFC 4721 remplaça RFC 3012. La révision imposa un suivi des défis applicables à chaque mobile et interdit de revenir à une valeur annoncée avant celle déjà utilisée avec succès. Elle clarifia les annonces et les réponses, ajouta des protections contre des messages factices et proposa HMAC-MD5.

Ces corrections ne démontrent aucun incident particulier. Elles démontrent que la fraîcheur réside dans une chronologie ordonnée : émetteur, destinataire, dernière valeur acceptée, demande pending et authenticator qui couvre l’échange. Hors de ce contexte, quatre octets aléatoires ne savent rien.

Le sujet reste distinct de RFC 2002. Le Mobile IPv4 de base organisait le binding temporaire entre une home address stable et une care-of address. RFC 3012 examinait une étape antérieure, au bord du réseau visité : la demande pouvait-elle être rattachée à une sollicitation récente avant que l’autorité distante ne statue ?

Il ne répète pas non plus PPP CHAP, RFC 1994. CHAP appartenait à l’authentification d’un lien PPP. Ici, une technique compatible était logée dans une inscription Mobile IPv4, entre un agent étranger et une infrastructure AAA séparée. La ressemblance du digest ne fusionne pas les autorités.

La lecture de Lu Heng sur la spécification initiale minimale éclaire cette retenue : standardiser uniquement le jeton, son ordre, son historique admissible et ses erreurs, puis laisser la décision future aux opérateurs et aux systèmes remplaçables. Running-Code Primacy interdit ensuite de confondre la norme publiée avec ce qui fonctionnait réellement sur un réseau précis.

Une capture peut montrer un défi émis et renvoyé. Un journal cryptographique peut montrer un authenticator valide. Un moteur de politique peut montrer une autorisation. Un Home Agent peut montrer un binding accepté. Une observation de trafic peut montrer l’acheminement. Aucune de ces pièces ne doit parler au nom des autres.

La passerelle lança un défi parce qu’elle pouvait établir ce fait-là, immédiatement et localement. La confiance devait encore traverser d’autres systèmes. L’honnêteté de RFC 3012 fut de ne pas cacher cette attente derrière l’apparence rassurante d’un challenge-response.

Sources