Résumé

  • Le RFC 5349 décrit l’emploi des certificats ECC, des signatures ECC et d’ECDH dans PKINIT. Si le KDC refuse les paramètres proposés, il peut retourner l’erreur 65 avec une séquence TD-DH-PARAMETERS classée selon sa préférence décroissante.
  • Ce classement n’est pas authentifié. Un intermédiaire peut présenter une sélection plus faible ou qui n’était pas la préférence commune. Le client et le KDC doivent donc chacun disposer d’une politique locale des paramètres acceptables ; la liste reçue ne peut qu’aider à découvrir leur intersection.
  • Un identifiant de courbe reconnu ne valide ni le point public reçu, ni le certificat, ni l’identité du KDC, ni l’émission d’un ticket, ni l’autorisation du service. La preuve opérationnelle doit conserver chaque transition séparément.

Un ordre plausible peut être un ordre falsifié

Dans PKINIT, le client peut placer une valeur publique ECDH et ses paramètres de domaine dans PA-PK-AS-REQ. Le KDC compare la proposition à sa politique. S’il la refuse, KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED lui permet d’expliquer ce qu’il affirme accepter.

La réponse contient une suite d’AlgorithmIdentifier. Le premier élément exprime la préférence la plus élevée du KDC, puis viennent les suivants. Ce mécanisme évite une suite aveugle d’essais et réduit le coût de l’interopérabilité.

Mais l’élégance de la structure masque une absence : l’erreur Kerberos n’a pas de protection d’intégrité. Le RFC 5349 explique qu’un attaquant peut modifier la liste afin de conduire le client vers des paramètres plus faibles ou simplement différents de la préférence mutuelle réelle.

Il ne faut donc pas journaliser seulement « courbe négociée ». Il faut conserver la proposition initiale, l’octet exact de l’erreur, l’ordre reçu, le choix du nouvel essai, la règle locale qui l’a admis et la réponse authentifiée ultérieure. Sans cette chaîne, l’ordre paraît avoir été choisi par le KDC alors qu’il peut avoir été réécrit en route.

La politique locale ferme la frontière

Le document impose une politique locale aux deux parties lorsqu’elles ne connaissent pas déjà les paramètres. Ce point est plus important que la liste elle-même. Il signifie que le protocole ne délègue pas au réseau le droit d’agrandir l’ensemble acceptable.

Le client possède son ensemble autorisé. Le KDC possède le sien. La négociation cherche un élément commun ; elle ne doit pas créer un troisième ensemble durable à partir du trafic observé. Une implémentation qui ajoute automatiquement une courbe à sa configuration après un essai réussi transforme une indication non authentifiée en règle permanente.

Les politiques peuvent légitimement différer. Un environnement cherche la compatibilité avec un parc ancien. Un autre protège une identité à forte assurance. Un dispositif matériel ne sait traiter qu’un sous-ensemble. Un service réglementé applique une date de retrait plus stricte. La capacité technique de décoder une courbe ne dit pas qu’elle est autorisée pour chaque principal.

La version de politique doit donc être une donnée d’audit. « Autorisé aujourd’hui » n’explique pas pourquoi l’essai d’hier a été accepté. Sans historique, une équipe ne peut pas distinguer une exception alors valide d’une dérive silencieuse.

Le nom de la courbe et le point sont deux preuves

Après l’accord sur les paramètres, le destinataire reçoit encore une valeur publique. Le RFC 5349 recommande les vérifications d’IEEE P1363 et insiste sur un cas dangereux : avec une clé privée ECDH de longue durée, accepter un point invalide ou situé sur la mauvaise courbe peut révéler progressivement des informations sur la clé, jusqu’à l’exposer.

Une interface qui affiche uniquement P-256 peut donc être trompeuse. Elle confirme l’identifiant des paramètres, pas l’appartenance du point au groupe attendu. Le contrôle doit produire son propre résultat : point encodé, courbe attendue, validation réussie ou motif de rejet, instance de clé privée utilisée et état de réutilisation.

La temporalité modifie le risque. Une clé éphémère borne davantage l’exposition d’une interaction. Une clé longue durée offre à l’attaquant plusieurs réponses portant sur le même secret. Le journal doit permettre de regrouper les tentatives par clé, pas seulement par session.

Les publications actuelles capturées de NIST — SP 800-56A Rév. 3, SP 800-186 et FIPS 186-5 — fournissent le contexte contemporain pour l’établissement de clés, les paramètres de courbes et les signatures. NIST a annoncé une mise à jour de SP 800-56A, pas son retrait. Le tableau de 2008 du RFC 5349 reste un fait historique ; il ne remplace pas une politique cryptographique de 2026.

Le secret partagé n’est qu’un état intermédiaire

Si les paramètres sont acceptés, le KDC renvoie sa valeur publique ECDH dans PA-PK-AS-REP. Les deux parties calculent un point partagé, convertissent sa coordonnée x en chaîne d’octets et l’emploient comme DHSharedSecret avant de poursuivre selon les RFC 4556 et 4120.

Cette opération prouve qu’un calcul compatible a été obtenu avec les entrées utilisées. Elle ne prouve pas à elle seule que la chaîne de certificat correspond au client attendu, que le rôle de clé convient, que le KDC appartient au bon domaine administratif, que la requête est fraîche, qu’un ticket a été émis, que le service l’a accepté ou que l’utilisateur a ouvert la session voulue.

Le résultat final doit être décomposé : paramètres proposés, décision locale, certificat, validation du point, calcul ECDH, dérivation de clé, réponse authentifiée, ticket initial, ticket de service et résultat applicatif. Une coche verte placée au niveau de PKINIT ne peut pas répondre à toutes ces questions.

Le certificat simplifie la distribution, pas l’autorité

Le RFC 5349 observe que les paramètres ECC présents dans les certificats du client ou du KDC peuvent éviter une préconfiguration distincte. C’est un gain opérationnel réel : une surface de configuration disparaît.

Mais le certificat ne devient pas pour autant une politique universelle. Il faut encore valider sa chaîne, son usage, sa période et son rattachement au principal. La courbe qu’il porte doit rester acceptable localement. La valeur publique de l’échange doit être vérifiée. Un certificat peut proposer un paramètre sans donner à tout service le droit de l’utiliser.

Cette nuance prévient une erreur fréquente de l’automatisation : confondre « aucune saisie manuelle supplémentaire » avec « aucune décision locale ». Le document exige précisément cette décision lorsque la connaissance préalable manque.

L’interopérabilité concentre aussi le risque

Les implémentations conformes au RFC 5349 doivent prendre en charge P-256 et P-384. Le document compare également courbes nommées et courbes personnalisées, structures conservatrices et efficacité, diversité et compatibilité.

Une petite base commune réduit les erreurs et les coûts de test. Elle concentre aussi les conséquences d’une défaillance de mise en œuvre ou d’une évolution cryptanalytique. La diversité limite certains risques communs tout en multipliant les parseurs, les variantes et les désaccords de validation.

Le choix ne se résume pas à un slogan. Il faut définir la population qui doit interopérer, les paramètres obligatoires, les exceptions locales, leur date d’expiration et l’inventaire des clés concernées par un retrait.

Le RFC 8636 confirme plus tard la permanence de cette frontière. L’absence d’une information de KDF peut indiquer un ancien KDC ou une attaque de downgrade ; c’est encore la politique locale du client qui décide si la compatibilité justifie de continuer.

Le projet PKINIT post-quantique capturé en 2026 reprend des mécanismes de suggestion et de nouvel essai, mais il reste un travail en cours. Il éclaire un signal à surveiller, pas un comportement déployé à déclarer.

Une norme informative ne mesure pas le parc réel

Le RFC 5349 est informatif. Le registre IANA confirme les numéros attribués aux mécanismes Kerberos, non leur activation actuelle. Aucune source gelée ne mesure le nombre de KDC qui acceptent ECC PKINIT, réutilisent des clés ou appliquent une validation donnée.

La Minimum Initial Specification de Lu Heng sert ici d’analogie déclarée : le langage commun peut rendre les options interopérables sans absorber les décisions futures de l’opérateur. Ses Reality Layers rappellent qu’un symbole de courbe, une préférence documentaire, une validation cryptographique et un accès réel appartiennent à des couches de preuve différentes. Ces notes, postérieures, n’ont ni causé ni approuvé le RFC.