Résumé

  • Dans la RFC 3520, l’élément AUTH_SESSION transporte une autorisation de session vers le contrôle de ressources. Une signature correcte et des champs concordants permettent une décision; ils ne prouvent ni la réservation de bout en bout, ni le passage des médias, ni la réussite du service.
  • Le reçu défendable sépare l’émetteur, la portée du droit, les octets exacts, la fraîcheur, la comparaison des champs, la politique locale, l’application par le PEP, l’état RSVP, les préconditions SIP et le résultat authentifié de l’application.

Le premier serveur connaissait l’abonné et le service demandé. Il avait donc émis un jeton. Le second administrait les ressources du réseau et n’avait aucune raison de confondre cette connaissance avec sa propre compétence. C’est précisément dans cet intervalle que se trouve la question intéressante: comment une affirmation provenant d’un domaine devient-elle une permission exécutable dans un autre?

Publiée en avril 2003 sur la voie des normes et toujours répertoriée comme Proposed Standard, la RFC 3520 définit un Session Authorization Policy Element. L’hôte le reçoit au cours de la signalisation de session, puis le copie sans le modifier dans l’objet RSVP POLICY_DATA. Le transport d’une affirmation est ainsi normalisé. Son acceptation ne l’est pas entièrement: le domaine de ressources conserve sa politique.

Le mot autorisation doit rester étroit. Il décrit la portée d’une décision antérieure. Il ne signifie pas que le chemin a réservé la capacité, que les préconditions ont été levées, que des paquets ont atteint leur destination ou que l’utilisateur a obtenu le résultat promis.

Le modèle associé expose la frontière administrative

Dans le modèle couplé, un même serveur de politique peut participer à la décision de service et à celle de ressources. Un SESSION_ID suffit alors à retrouver l’état conservé. Le modèle associé est différent: le jeton indique également l’entité d’autorisation, afin que le bord localise le serveur qui détient la décision relative au média.

Cette identité ne doit pas devenir une redirection aveugle. Si le routeur ne sait pas indépendamment que l’entité nommée est un serveur de politique légitime dans son domaine, la RFC exige des données d’authentification. Dans la variante à deux serveurs, le serveur du domaine de ressources interroge celui du domaine de service. La réussite de cet échange est un maillon du reçu, et non un détail invisible.

Le modèle non associé va plus loin. Le vérificateur peut ne disposer d’aucun état partagé avec l’émetteur. Le jeton doit alors emporter la source, la destination, les ressources, l’heure de début, l’identité ou le certificat de l’émetteur et les données d’authentification. Les ports et l’heure de fin peuvent encore réduire le droit.

Ces architectures ne produisent pas la même preuve. Un écran qui affiche seulement «jeton valide» efface l’endroit où la confiance a été établie, la dépendance extérieure utilisée et la politique qui a transformé l’affirmation en décision.

Les champs sont la limite du mandat

AUTH_SESSION n’est pas un laissez-passer général. Ses attributs peuvent contenir AUTH_ENT_ID, SESSION_ID, SOURCE_ADDR, DEST_ADDR, START_TIME, END_TIME, RESOURCES et AUTHENTICATION_DATA. La ressource peut être exprimée par un débit maximal, un flow spec RSVP, une description de média SDP ou un DSCP.

Dans le modèle non associé, tous les champs doivent correspondre à la demande de ressources. Une destination correcte avec un port différent est un écart. Un débit demandé au-delà du plafond est un écart. Une signature parfaite ne corrige aucune de ces différences; la demande doit être refusée.

L’absence elle-même a une signification. Lorsqu’aucune liste de ports n’est présente pour une adresse, tous les ports sont considérés comme valides selon les règles du document. Il faut donc conserver le jeu d’attributs exact, sa normalisation et le résultat de chaque comparaison. La formule «QoS autorisée» ne permet pas de savoir si le mandat était étroit ou involontairement large.

Authentifier l’émetteur n’oblige pas le domaine local

AUTHENTICATION_DATA protège les données qui le précèdent. La RFC décrit les mécanismes historiques à clé partagée, Kerberos et clé publique. Dans ce dernier cas, la chaîne de certificats, la révocation et la signature participent à la vérification de l’origine et de l’intégrité.

Après cette étape, le routeur ou le Policy Decision Point doit pourtant consulter ses tables de politique locale. Leur contenu est explicitement une affaire locale. Une information complémentaire qui influe sur la décision doit, elle aussi, être obtenue de manière sûre.

La cryptographie répond à «cette clé a-t-elle protégé ces octets?». La gouvernance répond à «cette identité peut-elle engager cette ressource, ici et maintenant?». Mélanger les réponses transforme une preuve d’origine en délégation illimitée. Les algorithmes cités en 2003 décrivent le document historique; ils ne constituent pas une recommandation cryptographique actuelle.

La fraîcheur appartient aux opérations

Pour empêcher le rejeu, la construction de l’élément exige soit START_TIME, soit SESSION_ID. Le premier choix dépend d’une fenêtre temporelle. Dans le modèle non associé, les serveurs de politique doivent prendre en charge la synchronisation NTP, et le texte avertit qu’un défaut de synchronisation peut permettre le rejeu.

Le second choix dépend d’un état durable: quand l’identifiant a-t-il été créé, a-t-il déjà servi, et cet état a-t-il survécu au redémarrage ou au basculement? Une signature reste mathématiquement correcte quand les mêmes octets sont rejoués. Elle ne contient pas spontanément une horloge fiable ni la mémoire du premier usage.

Le reçu doit donc conserver la source de temps, le décalage observé, la fenêtre d’acceptation et la décision du cache anti-rejeu, ou bien l’historique durable de l’identifiant. La RFC 5905 apporte un contexte NTP ultérieur, pas la preuve qu’un déploiement donné maîtrisait son temps.

Le chemin peut contenir des nœuds qui ignorent la politique

Un routeur RSVP conscient de la politique transmet le message au PDP et attend une réponse. Un routeur qui ne l’est pas ignore les objets de données de politique et poursuit le traitement RSVP. La présence du jeton sur le chemin ne prouve donc pas sa mise en œuvre sur chaque saut.

Il faut relever les PEP, le PDP consulté par chacun, les nœuds qui ont ignoré l’objet et l’état de réservation effectivement installé. La traversée du jeton et l’étendue de l’application sont deux faits distincts.

Si la vérification échoue, la RFC 3520 prévoit une défaillance de contrôle de politique, Error Code 02, et recommande un objet AUTH_DATA plus précis. Ce code délimite un échec de vérification. Son absence ne certifie ni l’acceptation locale, ni la disponibilité de la ressource, ni l’achèvement du chemin.

Une réservation ne parle pas à la place du média

Le scénario de la RFC 3521 avance par étapes. La signalisation peut être terminée ou encore en cours. Le PATH transporte le jeton. Le bord consulte la politique. Celle-ci peut modifier la ressource. Le RESV peut ensuite annoncer que la réservation est terminée ou progresse encore.

La RFC 3312 conserve, côté SIP, un état souhaité et un état courant pour les préconditions de QoS. Tant qu’une précondition obligatoire n’est pas satisfaite, l’établissement reste suspendu et les médias ne devraient pas circuler. Même après une mise à jour positive, il reste à observer le trafic, son traitement et le résultat applicatif.

Une file réservée n’est pas une conversation intelligible. Une admission n’est pas le consentement d’un utilisateur. Une réponse SIP n’est pas un reçu de continuité du service. Le dernier maillon doit correspondre à la promesse commerciale ou opérationnelle réellement faite.

Construire un reçu qui traverse les domaines

Conserver la demande initiale, l’acteur authentifié et le principal au nom duquel il agit. Archiver l’identité de l’autorité, sa portée, la version de décision et le hachage des octets exacts du jeton. Garder les références de clé, les résultats de validation et la décision anti-rejeu.

Comparer source, destination, ports, ressources et durée entre le jeton et la réservation. Enregistrer toute modification du PDP. Relier le PATH, le RESV et les erreurs au même identifiant de transaction. Cartographier le PDP, les PEP et les nœuds ignorants de la politique. Ajouter l’état souhaité/courant des préconditions, le transport observé et l’accusé authentifié de l’application.

Le reçu doit survivre au basculement. Un serveur de remplacement ne doit pas accepter un rejeu parce que son prédécesseur détenait seul l’état. Un changement de topologie ne doit pas conserver le mot «admis» tout en déplaçant le flux hors de la zone d’application connue.

Limite des éléments probants

Cet Article ne désigne aucun produit, fournisseur, opérateur, routeur, serveur de politique, client, utilisateur, session, flux média, incident ou déploiement. Il ne conclut rien sur l’usage actuel, la conformité, la sécurité, la performance ou le résultat commercial d’un système réel.

La RFC 3520 est lue comme un travail Standards Track d’avril 2003 actuellement Proposed Standard. Les RFC 3521, 3313 et 5866 gardent leurs statuts et leurs périmètres propres. Le domaine spécialisé de la RFC 3313 n’est pas généralisé à l’Internet public. Les textes plus récents sur NTP et Diameter servent seulement de comparaison.

Les notes de Heng Lu sur l’autorité et le running code sont des angles éditoriaux déclarés. Elles éclairent la différence entre une affirmation formelle et un contrôle observable; elles ne documentent pas l’intention de l’IETF.

La conclusion reste mesurée: un jeton peut être authentique, frais, concordant et admis alors que le résultat de la session demeure sans preuve.

Sources