Zusammenfassung

  • Lehnt ein KDC die ECDH-Parameter des Clients ab, kann es mit KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED eine geordnete Liste TD-DH-PARAMETERS zurückgeben. Die Kerberos-Fehlermeldung ist nicht integritätsgeschützt; ihre Reihenfolge ist Verhandlungseingabe, keine Vollmacht.
  • Benannte Kurven schaffen kompakte, gemeinsame Parameter und erleichtern Interoperabilität. Breite Vereinheitlichung bündelt zugleich Schlüssel, Hardware und Implementierungspfade, während unkontrollierte Vielfalt zusätzliche Fehler- und Downgrade-Flächen schafft.
  • Zertifikatspfad, öffentlicher Punkt, lokale Parameterpolitik, gemeinsames Geheimnis, Kerberos-Ticket und Anwendungsergebnis sind getrennte Prüfschritte. Bei langfristigen ECDH-Schlüsseln kann eine unterlassene Punktprüfung durch wiederholte Eingaben bis zur Offenlegung des privaten Schlüssels eskalieren.

Standardisierung ist zugleich technische Konzentration

Eine benannte Kurve lässt sich durch einen gemeinsamen Objektbezeichner ausdrücken. Sie reduziert die Größe der Darstellung und verhindert, dass jede Seite dieselben Domänenparameter separat beschreiben muss.

Der betriebliche Nutzen ist erheblich: Zertifikate, Kryptobibliotheken, Beschleuniger und Tests können sich auf wenige bekannte Profile einigen. Gleichzeitig hängen viele Schlüssel von derselben mathematischen Annahme und oft von denselben Implementierungspfaden ab.

Eine künftige Schwäche einer Kurve oder eines verbreiteten Codepfads kann deshalb einen großen Bestand gleichzeitig betreffen. Konzentration ist nicht automatisch falsch, sie muss aber als Portfoliorisiko sichtbar sein.

Mehr Vielfalt ist kein kostenloses Gegenmittel. Zusätzliche Kurven erweitern Parser, Konfiguration, Testmatrix, Aushandlung und Downgrade-Fläche. Die Entscheidung verlangt Daten über Schlüsselbestände, Bibliotheken, Hardware, Validierungsabdeckung und Austauschdauer.

Die KDC-Reihenfolge besitzt keine eigene Vertrauensbasis

RFC 5349 erlaubt dem KDC, ungeeignete Client-Parameter abzulehnen und Alternativen nach eigener Präferenz zu sortieren. Der Client kann eine Alternative auswählen und den PKINIT-Vorgang wiederholen.

Die Nachricht, die diese Empfehlung trägt, ist jedoch nicht integritätsgeschützt. Ein Angreifer kann Einträge entfernen oder umsortieren. Die Liste kann Verhalten beeinflussen, ohne dadurch Entscheidungsrecht zu erhalten.

Lokale Politik muss zuerst festlegen, welche Parameter überhaupt zulässig sind. Die empfangene Liste darf diese Menge nur einschränken. Ist die Schnittmenge leer, ist Abbruch das korrekte Kontrollergebnis.

Würde eine Bibliothek stattdessen den ersten technisch unterstützten Eintrag wählen, verwandelte sie Fähigkeit in Erlaubnis und eine entfernte Eingabe in lokale Kryptopolitik.

Ein erfolgreicher zweiter Versuch beweist nicht die erste Nachricht

Ein Vermittler könnte die höchste gemeinsame Präferenz entfernen und eine weitere, lokal noch erlaubte Kurve stehen lassen. Der zweite Versuch kann mit korrekter Kryptographie und gültigem Ticket enden.

Der Erfolg zeigt dann eine zulässige Schnittmenge. Er zeigt nicht, dass die ursprüngliche Liste authentisch war oder dass die Auswahl der tatsächlichen KDC-Präferenz entsprach.

Prüfung muss daher Ergebnis und Herkunft trennen. War der ausgeführte Parameter erlaubt und korrekt verarbeitet? War der Aushandlungsweg unverändert? Die erste Frage kann mit Ja beantwortet sein, während die zweite offen bleibt.

Ein Protokoll nur der Endkurve löscht diesen Unterschied. Erforderlich sind Erstvorschlag, Fehlercode, empfangene Reihenfolge, lokale Policy-Version, Schnittmenge, Auswahl und Wiederholungsergebnis.

Die Reihenfolge ist ein eigenes Steuerungsdatum

TD-DH-PARAMETERS ist keine ungeordnete Menge. Identische Mitglieder in anderer Reihenfolge können eine andere Auswahl hervorrufen.

Roh empfangene und lokal gefilterte Liste müssen getrennt gespeichert werden. Überschreibt die Filterung die Eingabe, ist später nicht mehr sichtbar, welche Werte und Prioritäten Einfluss nehmen sollten.

Auch die lokale Politik muss zeitlich gebunden werden. Eine aktuelle Konfiguration kann eine historische Entscheidung nicht erklären, wenn sich Regeln inzwischen geändert haben.

Mit vollständigen Belegen lässt sich eine manipulierte Präferenz innerhalb einer sicheren Grenze von einer tatsächlich unzulässigen Ausführung unterscheiden.

Zertifikatsprüfung und Punktprüfung sind verschiedene Grenzen

RFC 5349 nutzt bestehende PKINIT- und CMS-Strukturen für ECC-Zertifikate und Signaturen. X.509-Prüfung behandelt Aussteller, Vertrauenskette, Namen, Gültigkeit, Einschränkungen und Signaturen.

Der öffentliche ECDH-Punkt braucht zusätzlich eine mathematische Prüfung. Er muss ein gültiger Punkt auf der richtigen Kurve sein, bevor er den privaten Schlüssel in einer Berechnung berührt.

Ein signierter Behälter macht nicht jede darin decodierbare Bitfolge zu einer sicheren Gruppeneingabe. „Zertifikat gültig“ ist deshalb kein Beleg für ausgeführte Punktprüfung.

Nachweise sollten Parsing, Pfadbildung, Signatur, Algorithmuspolitik, Punktvalidierung und private Berechnung als einzelne Zustände ausweisen.

Langlebigkeit macht aus einem Fehler eine Serie

RFC 5349 warnt ausdrücklich: Wird ein langfristiger privater ECDH-Schlüssel mit einem Punkt verwendet, der nicht gültig auf der richtigen Kurve ist, können Informationen über den Schlüssel austreten. Wiederholung kann den Schlüssel vollständig offenlegen.

Das Risiko hängt von Schlüssellebensdauer, Anzahl gegnerischer Eingaben und beobachtbaren Reaktionen ab. Eine erfolgreich abgeschlossene Anmeldung belegt nicht, dass alle früheren ungültigen Punkte vor der Berechnung verworfen wurden.

Ratenbegrenzung verlangsamt Versuche, ersetzt aber keine Validierung. Kürzere Schlüsselrotation begrenzt Ansammlung, macht ungültige Punkte aber nicht zulässig. Die wesentliche Kontrolle liegt vor der Skalarmultiplikation.

Jeder Versuch sollte Quelle, Kurve, Validierungsergebnis, Schlüsselidentität und -alter, Ablehnungsgrund, Wiederverwendungszahl und beobachtbare Antwort verbinden.

Nonces tragen die begrenzte Wiederverwendungserlaubnis

RFC 4556 sieht clientDHNonce und serverDHNonce vor, damit Client und KDC die Wiederverwendung von Schlüsseln erlauben können; RFC 5349 bewahrt diesen Mechanismus für ECDH.

Das ist keine allgemeine Genehmigung, einen privaten Wert aus Leistungsgründen beliebig lange zu behalten. Die Nonces gehören zum Kontext, in dem beide Seiten Wiederverwendung akzeptiert haben.

Wiederverwendung kann Rechenkosten und Latenz senken. Sie erhöht zugleich die Zahl äußerer Eingaben, die denselben privaten Wert erreichen. Jede ausgelassene Punktprüfung wird dadurch wiederholbar.

Ein belastbarer Beleg verbindet Nonces, Policy-Entscheid, Schlüsselpaar, Zeitraum, Nutzungszahl, Validierung, Ablehnungen und Vernichtung. Das Endergebnis allein enthält diese Erlaubnis nicht.

Kleinere Schlüssel beantworten keine Betriebsfrage

Das Dokument beschreibt ECC als attraktiv, weil im Vergleich zu damals verbreiteten RSA- oder DSA-Verfahren ähnliche Sicherheit mit kleineren Schlüsseln erreichbar sei. Eine historische Tabelle ordnet ungefähre Größen ein.

Die Tabelle misst weder Zertifikatslebenszyklus noch Hardwareunterstützung, Seitenkanäle, Bibliotheksqualität, neue Policy, Aushandlungstests oder Migrationsrisiko. Sie erklärt den Entwurf, nicht die heutigen Gesamtkosten.

Kürzere Codierung kann Bandbreite und Speicher sparen. Neue Algorithmuskennungen, Parser, Kurvenpfade und Fehlerfälle können gleichzeitig Aufwand hinzufügen.

Aktuelle Beschaffung braucht aktuelle Standards, Plattformmessungen und Bedrohungsanalyse. Eine historische Schlüssellängenumrechnung ist kein gegenwärtiges Urteil.

P-256 und P-384 sind eine Fähigkeitsuntergrenze

Konforme Implementierungen müssen nach RFC 5349 P-256 und P-384 unterstützen. Das schafft einen gemeinsamen Ausgangspunkt.

Es beweist nicht, dass eine Kurve in einer konkreten Installation aktiviert, vorgeschlagen, erlaubt, vom KDC zurückgegeben, ausgewählt, validiert oder ausgeführt wurde. Dasselbe gilt für die historische Unterstützung von ecdsa-with-Sha256.

Inventare sollten implementiert, konfiguriert, angeboten, empfangen, erlaubt, ausgewählt, geprüft und ausgeführt getrennt führen. Produktdokumentation trägt nur den ersten Zustand.

Wer Unterstützung als Nutzung ausgibt, ersetzt Beobachtung durch Konformitätsannahme und unterschätzt seine reale Kryptofläche.

Zertifikatsparameter verlagern Verantwortung

ECDH-Parameter können aus einem ECC-Zertifikat stammen und eine getrennte Vorabkonfiguration überflüssig machen. Das kann Betrieb vereinfachen.

Die Autorität verschwindet dabei nicht. Sie wandert zu Zertifikatsausstellung, Pfadprüfung, Algorithmusbeschränkungen, Schlüsselanalyse und lokaler Annahmepolitik.

Ein Parameter ist nicht allein deshalb für jede Nutzung erlaubt, weil er in einem signierten Zertifikat steht. Herkunft sollte als lokale Konfiguration, aktuelles Zertifikat, KDC-Fehlerliste oder anderer Mechanismus vermerkt werden.

Weniger Konfigurationsdateien können weniger Aufwand bedeuten. Ohne Herkunftsnachweis können sie fälschlich wie weniger Governance aussehen, obwohl sich nur deren Ort geändert hat.

Das gemeinsame Geheimnis ist nicht die Geschäftsentscheidung

Nach Annahme berechnen beide Seiten einen elliptischen Kurvenpunkt. Dessen x-Koordinate wird als Oktettfolge zum DHSharedSecret für den Ablauf nach RFC 4556.

Die erfolgreiche Ableitung belegt ein kryptographisches Zwischenergebnis. Sie belegt nicht vollständig organisatorische Identität, Ticketausgabe, Dienstticket, Anwendungsberechtigung oder ausgeführte Handlung.

Jede folgende Stufe kann trotz Erfolg der vorherigen ablehnen. Kryptographische Einigung darf nicht zur geschäftlichen Vollmacht hochgestuft werden.

RFC 5349 erschien im September 2008 als Informational und ändert laut Text weder Syntax noch Semantik der RFC-4556-Nachrichten. Die erfasste Errata-Suche zeigte keinen Eintrag; das ist eine zeitgebundene Dokumentbeobachtung, keine Fehlerfreiheitsgarantie.