Zusammenfassung

  • RFC 5349 beschreibt ECC-Zertifikate, ECC-Signaturen und ECDH für PKINIT. Der Curve Identifier legt erwartete Domainparameter fest; der tatsächlich empfangene öffentliche Punkt muss dennoch unabhängig validiert werden.
  • Bei einem langlebigen ECDH-Privatschlüssel können wiederholte ungültige Punkte kumulativ Informationen offenlegen. Eine sessionweise Fehlermetrik verschleiert, dass mehrere Ereignisse denselben Schlüssel betreffen.
  • Auch die Kurvenauswahl selbst hat eine Vertrauensgrenze: Die Präferenzliste des KDC steht in einem nicht integritätsgeschützten Kerberos-Fehler. Lokale Politik, nicht der Draht, autorisiert den Retry. Punkt, Secret, KDC-Antwort, Ticket und Servicezugriff bleiben getrennte Belege.

Der Schlüssel verbindet Ereignisse, die das Dashboard trennt

Operations-Systeme zählen fehlgeschlagene Authentisierungen oft pro Request. Diese Sicht passt nicht zu einem Geheimnis, das Requests überlebt. Wenn derselbe private ECDH-Schlüssel hundertmal einen feindlichen Punkt verarbeitet, entstehen nicht hundert unabhängige Fehler.

RFC 5349 verweist auf die Public-Key-Prüfungen aus IEEE P1363 und betont die korrekte Kurve. Ohne diese Prüfung kann ein Angreifer aus den Antworten auf speziell gewählte Punkte schrittweise Information über den privaten Schlüssel gewinnen.

Der Audit-Key muss deshalb die private Schlüsselinstanz sein. Zu ihr gehören Empfangszeit, Punkt-Digest, erwartete Kurve, Validierungsergebnis, Nonces, Reuse-Zustand und nachfolgende Tickets. Erst diese Gruppierung zeigt, ob Rotation und Incident Scope eine Sitzung oder eine ganze Schlüsselperiode betreffen.

Der Kurvenname war nur die Erwartung

P-256 oder P-384 im AlgorithmIdentifier sagt, welche Gruppe die Implementierung erwartet. Es sagt nicht, dass die empfangenen Koordinaten darin liegen. Das sind verschiedene Kontrollen.

Eine Bibliothek kann die Kurve korrekt auswählen und trotzdem die Membership-Prüfung auslassen. Ein Telemetriesystem kann den OID erfassen und deshalb fälschlich „validated“ anzeigen. Beides erzeugt die gleiche Beobachtung: bekannter Name, unbekannte Punktqualität.

NIST SP 800-56A Rev. 3 ist der eingefrorene aktuelle Bezug für diskret-logarithmische Schlüsselerzeugung und Validierung. SP 800-186 und FIPS 186-5 liefern den gegenwärtigen Kurven- und Signaturkontext. NIST hat eine Aktualisierung angekündigt, nicht den sofortigen Wegfall der Revision. Die historische Tabelle des RFC ist kein vollständiger heutiger Baseline-Ersatz.

Reuse war ein eigener Policy-Zustand

RFC 5349 übernimmt aus RFC 4556 die Nonce-Logik, mit der Client oder KDC die Wiederverwendung von ECDH-Schlüsseln anzeigen oder zulassen können. Das ist kein unsichtbares Implementierungsdetail.

Reuse verändert die Risikokonzentration. Es kann Kosten sparen und Interoperabilität unterstützen; es bindet zugleich mehrere Exchanges an dasselbe private Material. Darum braucht es eine explizite lokale Regel, eine begrenzte Lebensdauer und ein Ereignis, das jede Nutzung belegt.

„Der Standard erlaubt Reuse“ beweist weder, dass die konkrete Implementierung ihn sicher durchführt, noch dass ein bestimmtes Assurance-Level ihn zulässt. Zulässigkeit, tatsächliche Nutzung und korrekte Validierung sind drei Felder.

Der Retry konnte vor dem Punkt bereits manipuliert sein

Wenn der KDC die angebotenen Parameter ablehnt, sendet er Error 65 und eine absteigend geordnete TD-DH-PARAMETERS-Liste. Der Client kann daraus eine Alternative wählen.

Kerberos-Fehler sind nicht integritätsgeschützt. Die Liste kann auf schwächere oder nicht gemeinsam bevorzugte Parameter umgeschrieben werden. RFC 5349 verlangt daher lokale akzeptable Mengen auf beiden Seiten.

Die Wire-Liste ist Discovery, kein administrativer Befehl. Ein Client darf nur innerhalb seiner versionierten Policy wählen. Wenn er eine erfolgreiche Alternative cached, muss der Cache als beobachteter Support markiert bleiben und darf nicht zur Allow-List werden.

Ein Incident braucht Originalangebot, Fehler-Digest, Reihenfolge, Retry, Policy-Regel und authentifiziertes Ergebnis. Nur so lässt sich ein alter Peer von Downgrade-Druck unterscheiden.

Ein gemeinsames Secret ist nicht das Ende von Kerberos

Nach Annahme sendet der KDC seinen öffentlichen Wert. Beide Seiten berechnen den gemeinsamen EC-Punkt und verwenden dessen x-Koordinate als DHSharedSecret.

Diese Übereinstimmung belegt nicht automatisch Zertifikatspfad, Client Principal, Intended Realm, Freshness, KDC-Authentizität, Ticketausgabe, Serviceberechtigung oder Benutzersitzung. Jeder Übergang kann separat scheitern.

Deshalb muss der Status nicht „PKINIT erfolgreich“, sondern eine Kette sein: Parameter erlaubt, Punkt gültig, Secret abgeleitet, KDF angewendet, Antwort verifiziert, Ticket ausgegeben, Service autorisiert, Sitzung hergestellt.

Das ist mehr als Logging-Feinheit. Ohne Trennung rotiert ein Team vielleicht Zertifikate, obwohl die Punktvalidierung defekt war, oder untersucht den Service, obwohl der KDC nie ein Ticket ausgab.

Zertifikatsparameter sparen Datei, nicht Verantwortung

ECC-Parameter aus Client- oder KDC-Zertifikaten können separate Vorkonfiguration ersetzen. Das reduziert Drift. Weiter nötig sind Pfad-, Zweck-, Gültigkeits- und Principal-Prüfung, lokale Curve Policy und Validierung des Session-Punkts.

Ein signiertes Objekt kann die Herkunft eines Parameters beweisen. Es entscheidet nicht für jeden Consumer, ob der Parameter in dessen Risiko- und Laufzeitkontext zulässig ist.

Gemeinsame Pflichtkurven schaffen gemeinsame Folgen

RFC 5349 verlangt P-256- und P-384-Support und diskutiert Named versus Custom Curves, Struktur, Effizienz und das Konzentrationsrisiko einer breit verwendeten Kurve. Es behauptet keinen eingetretenen Bruch.

Die gemeinsame Basis senkt Interoperabilitätskosten. Sie erhöht den gemeinsamen Blast Radius eines Implementierungsfehlers. Vielfalt kann Konzentration begrenzen und gleichzeitig Parser- und Testflächen vergrößern. Inventar, Exception Expiry und Retirement Plan sind daher wichtiger als ein abstraktes Bekenntnis zu Einheitlichkeit oder Vielfalt.

RFC 8636 zeigt dieselbe Grenze bei KDF-Agility: ein fehlendes Feld kann Legacy oder Downgrade bedeuten; lokale Politik entscheidet. Der 2026 eingefrorene Post-Quantum-PKINIT-Entwurf ist weiterhin Work in Progress.

Keine erfundene Einsatzstatistik

RFC 5349 ist Informational. IANA-Zuweisungen sind kein Nutzungszensus. Die Quellen belegen weder aktuelle Verbreitung noch einen konkreten Angriff oder einheitliches Herstellerverhalten.

Lu Hengs Minimum Initial Specification dient als spätere Analogie für gemeinsames Minimum und lokale Zukunftsentscheidung. Reality Layers trennt Symbol, Dokument, kryptografische Prüfung und Betriebsergebnis. Beide Texte sind keine historischen Quellen des RFC.