Résumé

  • RIPE NCC a commencé à intégrer son tableau de bord RPKI à OpenID Connect et à remplacer les clés d’API actuelles par des clés liées à son système SSO. Le chantier est encore « en cours ».
  • L’organisme a parallèlement refusé une API de balise RPKI capable de modifier les ROA de tout son espace. Ce refus rappelle qu’une identité mieux établie n’est pas encore une autorité correctement bornée.

Dans une infrastructure critique, la question la plus utile n’est pas toujours de savoir si une personne peut se connecter. Il faut savoir jusqu’où l’action déclenchée par cette personne — ou par un automate parlant en son nom — peut se propager.

RIPE NCC vient de fournir un cas d’école. Dans son plan RPKI du quatrième trimestre 2026, mis à jour le 17 septembre, l’organisme indique que le tableau de bord utilisera OpenID Connect via RIPE NCC Access. Il a aussi commencé à remplacer les clés de l’API RPKI par des clés fondées sur OIDC et intégrées au SSO. Une section du tableau de bord doit faciliter leur gestion. Les détails d’implémentation et le calendrier sont annoncés pour une prochaine réunion RIPE. À ce stade, le statut reste « en cours ».

Le mouvement a du sens. RIPE NCC Access impose déjà l’authentification à deux facteurs. La politique de sécurité publiée par l’organisme donne aux clés d’API une durée maximale d’un an, les lie au compte d’un utilisateur et prévoit leur désactivation quand ce compte ou le rôle de mainteneur disparaît. Une intégration plus cohérente peut donc rendre la propriété, la révocation et l’expiration moins opaques.

Mais OIDC répond d’abord à une question d’identité. Le standard se définit comme une couche d’identité au-dessus d’OAuth 2.0 : il permet de vérifier une authentification et de recevoir des attributs. Il ne détermine pas, par son seul usage, quels préfixes un client peut toucher, s’il peut seulement lire ou aussi publier, ni si un traitement non humain dépend silencieusement du compte d’un salarié.

Les mécanismes OAuth apportent des briques complémentaires. Un indicateur de ressource désigne le serveur protégé auquel un jeton est destiné ; les portées décrivent les accès demandés. Les recommandations de sécurité préconisent des jetons restreints à un public précis. Pourtant, même un jeton parfaitement limité au serveur RPKI pourrait encore disposer de droits trop larges à l’intérieur de ce serveur. La frontière d’un LIR, d’un certificat ou d’un ensemble de préfixes relève de la politique métier.

C’est ici que le second élément du plan devient décisif. Des chercheurs souhaitaient une balise dont la validité RPKI puisse varier. RIPE NCC précise ne pas l’avoir ajoutée, car l’API utilisée aurait permis de modifier des ROA concernant tout l’espace RIPE NCC. Cette capacité a été jugée inacceptable ; une autre solution doit être étudiée avec l’équipe RIS.

Il ne faut pas extrapoler. Cette API de balise n’est pas présentée comme l’architecture des futures clés destinées aux membres. Rien ne permet d’affirmer que celles-ci seront excessivement puissantes. En revanche, le refus révèle un critère sain : la commodité opérationnelle ne justifie pas une surface de modification disproportionnée.

Les conséquences d’une erreur RPKI expliquent cette prudence. Une ROA autorise cryptographiquement un AS d’origine pour un préfixe, éventuellement jusqu’à une longueur maximale. Dans le service hébergé, RIPE NCC transforme une configuration en objets signés, les publie et les renouvelle. L’API actuelle peut ajouter ou supprimer plusieurs ROA lors d’un même appel de publication.

La documentation montre aussi des garde-fous qu’il serait utile de préserver et de rendre plus explicites. Une tentative visant un préfixe non détenu doit renvoyer une interdiction. Le tableau de bord permet de garder des changements en attente, d’examiner les annonces affectées, puis d’appliquer un ensemble de façon atomique. Une requête permet d’estimer l’effet d’une ROA encore hypothétique.

Ces fonctions dessinent une chaîne de preuves. Il faut authentifier le principal, limiter le jeton au bon service, limiter les actions, limiter les ressources, enregistrer la mutation acceptée, constater la publication de l’objet, puis distinguer ce que les validateurs voient, ce que les routeurs décident et ce que le BGP montre réellement. Une réussite de connexion ne prouve aucune des étapes en aval.

La grille de lecture employée ici vient des notes de Heng Lu sur la spécification initiale minimale, les couches de réalité et le problème d’agence dans la gouvernance de l’Internet. Elle conduit à préférer une autorité initiale étroite et des décisions futures locales aux ressources concernées. Il s’agit d’un cadre éditorial, non d’une position attribuée à RIPE NCC.

Sources