Résumé

  • La mise en production du 28 juillet 2026 a ajouté l’envoi de la clé Reg-RWS dans l’en-tête Authorization comme méthode privilégiée. Le guide de démarrage d’ARIN qualifie pourtant encore la méthode par URL de Supported, sans annoncer de date de retrait.
  • Une clé placée dans l’URL peut se propager dans l’historique, les journaux de serveurs et de mandataires, les diagnostics ou les renvois. L’en-tête réduit fortement cette propagation accidentelle, mais aucun nom d’en-tête ne rend un secret techniquement impossible à enregistrer.
  • L’enjeu est opérationnel : Reg-RWS permet de consulter et de modifier des données d’enregistrement, de soumettre des ROA et d’éditer des objets IRR. Les sources ne prouvent toutefois aucune fuite, aucun vol et aucun usage abusif d’une clé.
  • La migration devrait être démontrée par un reçu public respectueux de la confidentialité : état de chaque canal, adoption agrégée, périmètre de masquage, calendrier de notification, règle de retrait, comportement de rejet et consignes de rotation.

Deux formes d’une même requête coexistent désormais dans la documentation publique d’ARIN. La première place un secret expurgé dans Authorization: ApiKey […]. La seconde ajoute ?apikey=[…] à l’adresse demandée. Dans les deux cas, le service reçoit un justificatif d’accès. Mais l’environnement technique ne traite pas une URL et un en-tête comme deux objets ayant la même capacité de circulation.

L’URL est une unité que les outils copient volontiers. Elle apparaît dans les historiques, les lignes de commande, les journaux d’accès, certains relevés de proxy, les captures d’écran et les demandes d’assistance. Un développeur peut croire qu’il transmet seulement l’adresse d’une ressource alors qu’il transporte aussi le secret qui autorise l’opération. Le billet publié par ARIN le 11 août désigne précisément l’historique du navigateur, les journaux du serveur et ceux du proxy comme des lieux où une clé intégrée à l’URL peut être conservée.

L’en-tête sépare au contraire la destination de la preuve d’autorisation. Les bibliothèques HTTP, passerelles et outils de sécurité savent plus souvent qu’un champ Authorization exige un traitement particulier. Cette séparation n’est pas décorative : elle diminue le nombre de mécanismes ordinaires susceptibles de recopier la clé sans que l’opérateur l’ait voulu.

Il faut donc reconnaître la portée du changement. Le 28 juillet, ARIN a annoncé que la nouvelle méthode était disponible et privilégiée, que la mise en production était terminée et que les systèmes fonctionnaient normalement. La suggestion 2022.5 a été close. Les opérateurs disposent enfin d’une forme de requête qui ne confond plus l’identité de la ressource demandée avec le secret permettant d’y agir.

Mais le mot « terminé » recouvre ici un objet précis : la livraison de la fonctionnalité. Il ne dit rien, à lui seul, sur le déplacement des clients. Il ne prouve pas que les anciennes URL ont disparu des scripts, des produits de gestion d’adresses ou des journaux conservés. Il ne ferme pas davantage le canal historique.

Le guide de démarrage rend cette distinction visible. Pour les exemples GET, POST et PUT, l’en-tête est Recommended tandis que le paramètre d’URL reste Supported. Le texte du 11 août indique que cette prise en charge sera retirée à terme, mais les cinq sources gelées ne donnent aucune date. Il existe donc trois états différents : la capacité plus sûre est livrée ; la migration peut commencer ; le rejet de l’ancienne forme reste une décision future.

Cette période de compatibilité n’est pas nécessairement une faiblesse de gestion. Des appels Reg-RWS peuvent être intégrés à des automatismes anciens, à des plateformes IPAM, à des procédures internes ou à des produits que leur utilisateur ne peut pas corriger en une journée. Une rupture immédiate pourrait empêcher une mise à jour d’enregistrement ou une opération de sécurité du routage. Maintenir temporairement les deux canaux donne le temps de mettre à niveau les clients, de vérifier les erreurs et de renouveler les clés concernées.

La contrepartie est simple : tant que l’ancien canal fonctionne, la surface que la nouvelle méthode cherche à réduire subsiste. La sécurité réelle dépend donc de l’adoption, pas seulement de la disponibilité. Fermer une suggestion prouve qu’ARIN a répondu à la demande de fonctionnalité. Cela ne mesure pas la part des appels ayant migré et ne montre pas encore à quelle condition le serveur pourra refuser le paramètre d’URL sans casser les opérations courantes.

Une phrase du guide appelle en outre une précision. La page affirme que la méthode par en-tête est conçue de façon à ne pas permettre que la clé soit captée « à aucun moment du processus ». Le billet d’ARIN emploie une formulation plus étroite : l’en-tête réduit sensiblement le risque d’exposition accidentelle. C’est cette seconde proposition que les éléments techniques permettent de soutenir.

Un en-tête Authorization demeure une partie de la requête HTTP. Une bibliothèque peut l’exposer dans son mode de débogage. Un proxy inverse ou un serveur applicatif peut être configuré pour journaliser les en-têtes. Un système de traçage peut collecter trop de métadonnées. Une archive de diagnostic, la mémoire d’un processus ou une machine compromise peuvent contenir la clé. TLS protège le transport entre les extrémités authentifiées ; il ne supprime pas le secret des systèmes qui doivent légitimement le manipuler.

Le RFC 6819 de l’IETF établit exactement cette hiérarchie de risque. Il avertit que les jetons placés dans la requête URI peuvent fuir vers les journaux et les informations de renvoi, et recommande l’en-tête d’autorisation. Il présente ce choix comme une réduction de la probabilité de fuite ou de stockage involontaire. Il exige séparément une configuration correcte des journaux et une limitation de leur accès. La norme ne transforme pas le nom du champ en propriété cryptographique.

Rien de cela ne permet d’affirmer qu’ARIN enregistre actuellement ces en-têtes. Rien ne montre qu’un client a exposé sa clé, qu’un tiers l’a rejouée ou qu’une opération non autorisée a eu lieu. La critique porte sur la précision de la documentation. Une amélioration réelle n’a pas besoin d’une promesse absolue ; au contraire, une promesse trop large peut pousser les équipes à négliger le masquage, la rotation ou la réduction des privilèges.

La portée fonctionnelle de Reg-RWS explique pourquoi cette exactitude compte. La documentation décrit des opérations sur les délégations, les réseaux, les organisations, les points de contact et les clients. Le service peut aussi servir à soumettre des autorisations d’origine de route, à éditer des objets de registre de routage et à demander des rapports. Les droits effectifs dépendent du compte et des enregistrements auxquels il est relié, mais la clé n’est pas un simple identifiant de lecture publique.

Le contrôle utile n’est donc pas une nouvelle déclaration générale de sécurité. C’est un reçu de migration. Celui-ci peut rester entièrement agrégé. Il devrait identifier la version de la mise en production et de la documentation, les familles d’opérations concernées, les deux canaux acceptés et leur état — recommandé, pris en charge, déprécié ou rejeté — ainsi que la part agrégée des appels utilisant encore la requête URL sur une période définie.

Le même reçu devrait préciser le périmètre de masquage : URL, en-têtes, serveur applicatif, proxy, diagnostic et assistance. Il devrait publier les étapes de notification, la période de soutien, le seuil autorisant le retrait, la date annoncée et la règle de retour en arrière. Après la bascule, une requête ancienne doit échouer de façon prévisible sans recopier le secret dans une réponse, une redirection ou un nouveau journal d’erreur.

Aucun de ces indicateurs n’exige de nommer un client ni de révéler une clé. ARIN peut publier une proportion, une tendance et le nombre de familles d’opérations où subsiste l’ancien format. Si une cohorte est trop petite, les chiffres peuvent être regroupés ou différés. L’objet du reçu n’est pas de désigner les retardataires ; il est de prouver que l’ancienne voie peut se fermer sans transformer la télémétrie en nouvelle fuite.

Le registre public contient déjà le début de cette chaîne d’état. La méthode par en-tête existe depuis le 28 juillet. Elle est recommandée. La requête par URL demeure prise en charge. Son retrait est promis sans échéance. Il manque maintenant la jonction vérifiable entre ces faits : comment l’adoption sera mesurée, quelles protections couvrent les traces, quel seuil définit la fin de la migration et à quel moment le service cessera d’accepter un secret dans la partie de la requête qui voyage le plus facilement.

Sources