Résumé

  • RFC 5349 permet au KDC de répondre à des paramètres ECDH refusés par KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED et une liste TD-DH-PARAMETERS classée par préférence. Le client peut relancer l’échange, mais la liste voyage dans une erreur Kerberos non protégée en intégrité.
  • Une politique locale doit donc borner le choix des deux côtés. La relance peut prouver qu’un paramètre appartient à l’intersection acceptable du client et du KDC ; elle ne peut pas authentifier rétroactivement la liste ni son ordre.
  • L’acceptation d’un certificat ne remplace pas la validation du point public sur la bonne courbe. Avec une clé privée ECDH durable, des points invalides soumis à répétition peuvent transformer une omission de contrôle en extraction progressive de la clé.

Deux vérités différentes dans une même réussite

Le scénario rassurant est simple : le client propose une courbe, le KDC la refuse, fournit plusieurs paramètres, le client en retient un, puis l’authentification aboutit. Un tableau de bord qui ne conserve que le résultat final affichera une opération verte.

Mais deux propositions distinctes se cachent dans ce vert. La première est que la courbe finalement utilisée était permise et que les calculs ultérieurs ont fonctionné. La seconde serait que la liste initiale et son ordre provenaient bien du KDC. RFC 5349 ne permet pas de déduire la seconde de la première.

Un intermédiaire peut retirer le premier choix commun et laisser un second choix que la politique locale autorise encore. La relance reste sûre au sens où le client n’a pas franchi sa limite. Pourtant, le chemin de négociation ne reflète plus la préférence réelle du KDC.

L’exploitation doit donc enregistrer séparément la conformité du résultat et la provenance du conseil. Une réussite est un reçu de résultat borné, pas une signature rétrospective apposée sur tous les messages précédents.

Le message conseille ; la politique décide

TD-DH-PARAMETERS est utile parce qu’il évite des tentatives aveugles. Son ordre exprime ce que le KDC affirme préférer. Cette information peut réduire l’espace de recherche du client.

Elle ne doit jamais élargir l’espace autorisé. Le client possède un ensemble local de paramètres admissibles. Il calcule l’intersection avec la liste reçue, puis choisit à l’intérieur de cette intersection. Si elle est vide, l’échec est la décision de contrôle correcte.

Choisir malgré tout la première valeur décodable reviendrait à déléguer la politique cryptographique à un message non authentifié. La bibliothèque pourrait qualifier le comportement d’« interopérable » ; l’organisation aurait en réalité laissé une entrée distante créer une permission locale.

Le KDC est soumis au même principe. La présence d’une courbe dans une bibliothèque, ou sa conformité syntaxique, ne suffit pas à l’autoriser. Implémenté, configuré, offert, accepté et exécuté sont cinq états différents.

L’ordre mérite sa propre preuve

Une liste de préférences ne contient pas seulement des membres ; elle contient une décision d’ordre. Deux listes composées des mêmes courbes peuvent conduire à des choix différents. Conserver uniquement l’ensemble efface donc un élément de gouvernance.

Une trace exploitable devrait garder la proposition initiale, le code d’erreur, la liste reçue dans son ordre exact, l’ensemble local au moment de la décision, l’intersection calculée, la valeur retenue et le résultat de la relance. Elle devrait aussi indiquer si la négociation était permise.

Si la configuration locale évolue après l’incident, relire seulement la politique actuelle ne reconstitue pas la décision passée. Le reçu doit figer la version de politique qui a produit le choix.

Cette discipline permet de répondre à une question subtile : le résultat était-il acceptable malgré une provenance inconnue, ou la préférence distante a-t-elle effectivement déterminé une valeur que l’organisation n’aurait pas choisie autrement ?

Un certificat valide n’est pas un point valide

RFC 5349 inscrit certificats ECC, signatures et échange ECDH dans les structures PKINIT et CMS existantes. La validation X.509 traite la chaîne, les usages, les contraintes, la période de validité et les signatures. L’identifiant d’algorithme rattache l’encodage à un mécanisme attendu.

Le point public reçu exige néanmoins un contrôle mathématique distinct. Il faut établir qu’il appartient bien à la courbe correcte et qu’il satisfait les conditions nécessaires avant de l’utiliser avec la clé privée.

Dire « certificat accepté » fusionne des contrôles qui répondent à des questions différentes. Un conteneur peut être bien signé et contenir une donnée qui ne doit pas atteindre la multiplication scalaire. La chaîne de certification n’exécute pas à la place de la bibliothèque la validation du point.

Le journal doit donc distinguer l’analyse de l’encodage, la construction du chemin de certification, la vérification de signature, la décision de politique d’algorithme et la validation du point public.

La durée de la clé transforme la gravité

RFC 5349 avertit qu’un destinataire utilisant une clé privée ECDH de longue durée risque de révéler des informations sur cette clé s’il accepte un point qui n’est pas valide sur la bonne courbe. Des essais répétés peuvent finir par l’exposer entièrement.

Le défaut n’est donc pas seulement « une mauvaise entrée ». Sa gravité dépend du nombre d’entrées adverses qui rencontrent la même valeur privée, de la possibilité d’observer les réponses et du temps pendant lequel la clé reste active.

Une clé éphémère et une clé durable ne créent pas le même rayon d’impact. De même, une validation correcte avant tout calcul vaut davantage qu’une limitation de débit placée après. Le débit peut ralentir une extraction ; il ne transforme pas un point invalide en point sûr.

Les opérations devraient relier chaque tentative à l’identité de la clé, sa date de création, son compteur de réutilisation, la courbe attendue, le résultat de validation, le motif de rejet et la date de retrait.

Les nonces portent l’autorisation de réutiliser

Le mécanisme de RFC 4556, conservé par RFC 5349, permet au client et au KDC d’autoriser la réutilisation des clés ECDH grâce à clientDHNonce et serverDHNonce. Cette possibilité n’équivaut pas à une permission générale de conserver une clé aussi longtemps que le logiciel le souhaite.

Les nonces appartiennent au contexte qui rend la réutilisation admissible. Perdre ce contexte et ne garder que le secret partagé efface le fait que les deux parties ont dû participer à cette décision.

La réutilisation peut réduire le coût de calcul et la latence. Elle augmente aussi le nombre de messages qui peuvent solliciter la même clé privée. Le contrôle du point devient alors une frontière répétée, et une seule omission peut se reproduire.

Un reçu complet relie les nonces, la décision locale, la paire de clés, la durée, le nombre de tentatives, les rejets et la destruction finale. « ECDH terminé » ne couvre aucune de ces dimensions.

La petite taille ne mesure pas le coût d’exploitation

Le document présente l’ECC comme un moyen d’obtenir, avec des clés plus petites, une sécurité comparable aux mécanismes RSA ou DSA courants à l’époque. Il fournit un tableau d’équivalences approximatives fondé sur les recommandations historiques citées.

Cette comparaison éclaire le choix de conception de 2008. Elle ne mesure pas, à elle seule, le coût contemporain d’une migration : certificats, modules matériels, comportements de bibliothèques, résistance aux canaux auxiliaires, inventaire des courbes, tests de négociation et capacité de remplacement restent hors du tableau.

Une clé plus courte peut réduire certaines tailles et certains calculs. Elle peut aussi ajouter de nouveaux parseurs, identifiants et chemins de panne. Le bilan doit venir de mesures de déploiement, pas d’une conversion de longueur.

Il serait tout aussi imprudent de transformer le tableau historique en politique d’achat actuelle. Les normes, les plateformes et les menaces doivent être vérifiées dans leur état présent.

P-256 et P-384 forment un plancher de capacité

RFC 5349 exige la prise en charge de P-256 et P-384 par les implémentations conformes. Cette exigence établit un terrain commun pour l’interopérabilité du document.

Elle ne prouve pas qu’une courbe est activée dans un déploiement, proposée par un client, autorisée par une politique, renvoyée par un KDC, choisie lors de la relance ou réellement exécutée. Le même raisonnement vaut pour la prise en charge obligatoire de ecdsa-with-Sha256 dans le texte historique.

Un audit qui coche « supporté » ne peut pas conclure « utilisé ». Pour passer d’un état à l’autre, il faut des observations de configuration et d’exécution.

L’inventaire devrait afficher une progression explicite : disponible dans le logiciel, activé, proposé, reçu, permis, sélectionné, validé et exécuté. Les trous deviennent alors visibles au lieu d’être absorbés dans une seule colonne.

Courbes nommées : interopérabilité et concentration

Les courbes nommées condensent les paramètres dans un identifiant partagé et réduisent les divergences de configuration. Les structures de RFC 4556 peuvent aussi porter des paramètres explicites pour des courbes personnalisées.

La normalisation d’une courbe simplifie tests, certificats et matériel. Elle concentre parallèlement de nombreuses clés sur la même hypothèse cryptographique et le même chemin d’implémentation. Une faiblesse future peut alors avoir une portée collective.

Multiplier les courbes n’est pas une réponse gratuite : davantage de code, de branches de négociation et de configurations offrent davantage d’occasions de faute. Le choix oppose concentration et complexité, non sécurité et insécurité abstraites.

Une décision responsable exige le nombre de clés, la diversité des bibliothèques, la qualité de validation, les dépendances matérielles, le temps de remplacement et les choix réellement observés.

Les paramètres de certificat déplacent la garde

Des paramètres ECDH portés par un certificat ECC peuvent éviter une configuration préalable distincte. Cette économie est réelle, mais elle ne supprime pas l’autorité : elle la déplace vers l’émission du certificat, le chemin de confiance, les contraintes d’algorithme et la politique d’acceptation locale.

L’organisation doit savoir d’où venait le paramètre utilisé : fichier local, certificat, erreur du KDC ou autre mécanisme. Sans cette provenance, une réduction du nombre de fichiers peut être prise à tort pour une réduction de la gouvernance.

Un paramètre inclus dans un certificat n’est pas automatiquement autorisé pour tout usage. La confiance accordée à l’émetteur, l’usage de clé, la courbe et le contexte PKINIT doivent tous converger.

La meilleure simplification conserve donc une preuve plus précise, non une preuve plus pauvre.

Le secret partagé n’est pas l’autorisation applicative

Après validation et acceptation, les parties calculent un point elliptique ; la coordonnée x devient la matière DHSharedSecret utilisée par le flux RFC 4556. Ce calcul constitue encore un reçu borné.

Il ne prouve pas l’identité organisationnelle complète, l’émission d’un ticket, l’obtention d’un ticket de service, l’autorisation applicative ni l’exécution de l’action demandée. Chacune de ces étapes peut refuser ce que la précédente a produit.

Promouvoir l’accord cryptographique en autorité métier supprime plusieurs points de décision. Une chaîne d’audit utile les maintient distincts : certificat, point, intersection de politique, secret partagé, ticket et résultat applicatif.

Le statut historique renforce cette prudence. RFC 5349, publié en septembre 2008, est Informational et n’apporte aucune modification syntaxique ou sémantique aux messages RFC 4556. L’absence d’erratum affiché dans la capture RFC Editor est une observation datée, non une garantie d’implémentation.