Résumé

  • La RFC 2989 évaluait les capacités des propositions AAA ; une fonction obligatoire dans le protocole n’était pas nécessairement utilisée par chaque échange.
  • Les colonnes NASREQ, ROAMOPS et Mobile IP conservaient des exigences différentes au lieu d’imposer une politique d’exploitation universelle.
  • Livraison de transport, validation syntaxique, décision sémantique, prise en charge comptable, effet d’autorisation et service obtenu formaient des preuves distinctes.

Une matrice, pas un déploiement

La RFC 2989 ne définit pas un nouveau protocole AAA. Elle synthétise les exigences issues de NASREQ, ROAMOPS, MOBILEIP et TIA 45.6 afin d’évaluer les propositions. Ses tableaux couvrent les propriétés générales, l’authentification, l’autorisation, la comptabilité et des besoins propres à Mobile IP.

Chaque colonne garde la provenance de la demande. Chaque cellule emploie M, S, O, N ou B pour MUST, SHOULD, MAY, MUST NOT et SHOULD NOT. Cette conservation des différences était essentielle : une fonction jugée obligatoire pour un serveur d’accès n’avait pas automatiquement le même rang dans une fédération d’itinérance.

La section 1.1 fixe la juridiction de la matrice. Les mots normatifs portent sur les capacités du protocole. Une proposition qui manque un MUST pour une capacité qu’elle met en œuvre n’est pas conforme. Celle qui satisfait les obligations mais pas toutes les recommandations est « conditionnellement conforme » ; celle qui satisfait aussi les SHOULD est « inconditionnellement conforme ».

Ces qualifications appartiennent à une proposition. Elles ne décrivent ni une version binaire, ni un profil de configuration, ni un paquet observé.

L’exemple choisi par le document est décisif. Exiger que le protocole prenne en charge la confidentialité ne signifie pas que tout son trafic doive être chiffré. La présence d’un mécanisme permet au réviseur de valider une aptitude. Elle ne révèle pas quel opérateur l’a activé, quel objet a été protégé, quelle clé a servi ou quel pair a accepté le mode.

Le MUST ne change pas silencieusement de sujet

La RFC 2119 donne de la force aux mots normatifs, mais cette force reste attachée au sujet défini. Dans la RFC 2989, le sujet est la capacité exigée d’une proposition de protocole.

Le glissement vers l’exploitation est tentant. Une fiche produit annonce la conformité ; un appel d’offres transforme l’annonce en garantie de chiffrement ; un tableau de bord transforme une connexion en service réussi. À chaque étape, un nouveau fait est supposé sans reçu.

La grille permettait pourtant une lecture plus rigoureuse. L’évolutivité était obligatoire dans les trois colonnes. La reprise apparaissait comme MUST pour NASREQ et Mobile IP. IPv4 était communément obligatoire ; IPv6, le transport de certificats et l’auditabilité avaient des forces différentes. Une case vide ne déclarait pas la fonction inutile. Une case M ne commandait pas son emploi dans chaque transaction.

La spécification initiale commune restait mince : assez précise pour comparer les architectures, pas assez autoritaire pour décider de toute politique locale future.

La sécurité par saut et la sécurité de l’objet

La RFC 2989 distinguait deux enveloppes de sécurité.

La sécurité de transmission était de pair à pair. Deux entités AAA pouvaient authentifier leur relation, assurer l’intégrité et chiffrer le canal. Lorsque l’entité destinataire traitait le message, cette protection était retirée. Le saut suivant créait une autre association.

La confidentialité au niveau de l’objet visait au contraire un ou plusieurs attributs pour leur destinataire final, même à travers des mandataires ou courtiers. L’authentification et l’intégrité de l’objet devaient persister dans la chaîne ; les données couvertes ne pouvaient pas être modifiées par l’intermédiaire.

Un protocole capable des deux ne prouvait pas leur emploi conjoint. Il fallait encore connaître la configuration, les clés, les attributs couverts, le comportement du proxy et le verdict du vérificateur. Le code disponible n’était qu’une condition antérieure.

Le reçu de transport s’arrêtait avant le sens

La clarification sur le transport fiable formule la frontière la plus nette du document.

La résilience devait inclure retransmission et bascule saut par saut, contrôle des reprises par l’application AAA, réponses en temps utile et accusés éventuellement incorporés aux messages. La RFC nommait aussi l’accusé du transport indiquant qu’un message avait été livré.

Elle précisait immédiatement que cet accusé était séparé de l’évaluation de la syntaxe et de la sémantique.

Un serveur pouvait recevoir le message puis refuser son encodage, ses attributs ou sa transition d’état. Un proxy pouvait accepter un saut tandis que le suivant échouait. Le serveur de secours pouvait être joignable mais ignorer les sessions récentes. Une réponse rapide pouvait être un rejet.

La fiabilité n’était donc pas un bit global. Elle exigeait l’identité de la tentative, le saut, la reprise, le choix de secours, le reçu de transport, le résultat d’analyse, la décision et l’action du NAS.

Accepter la responsabilité comptable

Dans le tableau de comptabilité, la livraison garantie utilisait un autre accusé. Celui-ci appartenait à l’application et était envoyé lorsque le serveur destinataire acceptait de prendre la responsabilité des données du message.

Ce reçu allait plus loin que l’arrivée au transport. Il ne prouvait toujours ni réplication durable, ni rapprochement, ni tarification correcte, ni facture, ni paiement.

La RFC définissait d’ailleurs séparément la comptabilité — collecte d’usage pour analyse, audit, facturation ou affectation des coûts — et la facturation, acte de préparer une facture. Une même session pouvait produire plusieurs enregistrements après une autorisation dynamique.

Prise en charge, stockage, rapprochement, notation, facture et résultat client demeuraient des étapes distinctes.

L’audit retraçait l’action, pas sa justesse

Pour la RFC 2989, un processus auditable permettait de déterminer définitivement les actions effectuées sur les paquets AAA entre le serveur d’origine et l’équipement réseau, aller et retour.

La topologie donnait du poids à cette exigence. Un proxy local pouvait appliquer une politique. Un proxy transparent était défini par l’absence d’ajout, de suppression ou de modification. Un courtier pouvait se placer dans le chemin, ou fournir hors chemin les informations permettant un contact direct.

Un journal pouvait montrer quelle transformation avait eu lieu. Il ne prouvait pas que la transformation était autorisée, que l’identité était correcte, que le NAS avait exécuté la réponse ou que l’utilisateur avait reçu le service.

L’auditabilité était une preuve de garde et de mutation, non un certificat universel de vérité.

Trois A, trois pouvoirs

L’authentification vérifiait une identité revendiquée comme origine d’un message ou extrémité d’un canal. L’autorisation décidait si un droit pouvait être accordé. La comptabilité collectait l’usage.

Le document exigeait même que l’autorisation puisse fonctionner sans exiger à nouveau les justificatifs de l’utilisateur : une identification ou une assertion pouvait transporter la décision. Cela ne rendait pas l’assertion auto-authentifiante ; cela reconnaissait qu’une preuve pouvait avoir été établie ailleurs.

Rejet, règles d’accès, réautorisation, réconciliation d’état et demande de déconnexion étaient des capacités de contrôle. Aucune ne prouvait à elle seule l’effet sur le réseau.

Ce que la grille a conservé

La réussite historique de la RFC 2989 tient à sa modestie. Elle a rendu comparables des besoins hétérogènes sans transformer le document en télémétrie imaginaire.

Capacité n’était pas activation. Livraison n’était pas interprétation. Garde comptable n’était pas facture. Audit n’était pas correction. Autorisation n’était pas accès obtenu.

La lecture par couches de réalité de Lu Heng rend la chaîne explicite : exigence, texte, capacité, implémentation, configuration, message, action intermédiaire, décision, effet et résultat. La vérité d’une couche ne lui donne pas mandat pour témoigner à la place des suivantes.

Le code en fonctionnement fournit les reçus manquants. La matrice évaluait le candidat. Le réseau devait encore montrer ce qu’il avait fait.

Sources