Zusammenfassung

  • RFC 3129 wollte Sitzungsschlüssel aus Kerberos-Tickets als Grundlage für IPsec-Security-Associations verwenden und so dauerhafte Geheimnisse zwischen jedem Peer-Paar verringern.
  • KINK war ausdrücklich kein Ersatz für IKE: zentrale Verwaltung und weniger wiederholte Public-Key-Arbeit wurden mit der Abhängigkeit von einem aktiven vertrauenswürdigen Dritten bezahlt.
  • Die Komplexität wanderte zum KDC, zu Realms, Uhren und Namen; die Autorisierung von Tunneln und Selektoren blieb bei den IPsec-Peers.

Die prägnanteste Rechnung in RFC 3129 betraf keine Schlüssellänge. Sie zählte Beziehungen. Erhält jedes Paar von IPsec-Peers ein eigenes vorab geteiltes Geheimnis, beschreibt das Dokument die Verteilung als O(n²). In Kerberos unterhält jedes Principal eine langfristige Beziehung zum Key Distribution Center. Das KDC stellt Service-Tickets mit Sitzungsschlüsseln aus. Im vereinfachten Vergleich nähert sich die Zahl langfristiger Schlüssel O(n).

Das ist keine vollständige Betriebskostenrechnung. Es macht aber sichtbar, dass ein Sicherheitssystem administrativ scheitern kann, obwohl die Chiffren halten. Geheimnisse müssen inventarisiert, verteilt, gedreht, gesperrt und nach einem Vorfall erklärt werden.

IPsec hatte Schutz und Aushandlung bereits getrennt. RFC 2401 beschrieb Security Associations sowie AH und ESP. RFC 2409 definierte IKE, mit dem zwei Peers einander authentisierten, Parameter aushandelten und Schlüsselmaterial erzeugten. Die Unabhängigkeit war eine Stärke: Während des Austauschs musste keine zentrale Instanz aktiv teilnehmen.

Diese Unabhängigkeit verteilte Arbeit an den Rand. Skalierbare Authentisierung mit X.509 brachte Zertifikate, Vertrauenspfade und Signaturprüfungen. Diffie–Hellman erzeugte ein gemeinsames Geheimnis, kostete aber Rechenleistung und bot Angriffsfläche für Denial of Service. Vorab geteilte Schlüssel umgingen Zertifikate, bauten jedoch das paarweise Verteilungsproblem wieder auf. Auch die Site-Policy musste auf Geräten leben, denen eine Organisation nicht gleichermaßen vertrauen konnte.

Kerberos ordnete Vertrauen anders. Nach RFC 1510 authentisierte sich ein Client beim KDC, erhielt ein Ticket für einen Dienst und bekam einen Sitzungsschlüssel. Der Dienst konnte denselben Schlüssel aus dem Ticket gewinnen. KINK sollte diesen Sitzungsschlüssel zur Grundlage der IPsec-SA-Schlüssel machen.

Damit wurde nicht bloß ein Handshake ersetzt. Langfristige Geheimnisse konnten Principal und KDC verbinden, statt jedes mögliche Peer-Paar. Eine anfängliche Public-Key-Authentisierung über PKINIT ließ sich auf Tickets für viele Dienste verteilen. Ein Teil der Policy konnte dort verwaltet werden, wo der Realm-Administrator Kontrolle hatte, statt nur darauf zu hoffen, dass jeder entfernte Peer dieselbe Absicht richtig umsetzte.

RFC 3129 benannte den Preis ausdrücklich: KINK war kein Ersatz für IKE. IKE konnte zwei Peers ohne aktiv beteiligten Dritten authentisieren und Schlüssel austauschen lassen. KINK konnte diese Eigenschaft nicht nachbilden. Das Modell passte nur dort, wo eine vertrauenswürdige Instanz vorhanden und ihre Rolle erwünscht war.

Zentralisierung bedeutete deshalb die Wahl einer Fehlerdomäne. Das KDC reduzierte paarweise Provisionierung und wiederholte asymmetrische Arbeit auf Servern. Dafür hingen Ticket-Ausgabe, Principal-Namen, Realm-Vertrauen, Zeit und der Beginn neuer Beziehungen von einer gemeinsamen Autorität ab.

Die Anforderungen begrenzten deren Teilnahme. Jeder IPsec-Peer musste initiieren können, ob er als Kerberos-Client nur ein TGT oder als Dienst ein Keytab besaß. User-to-User-Kerberos sollte Fälle abdecken, in denen der Responder kein gewöhnliches Service-Ticket entschlüsseln konnte. Mehrere Realms und der Umgang mit absoluter Uhrabweichung gehörten ebenfalls dazu.

Besonders aufschlussreich war Rekeying. Solange das Kerberos-Sitzungsticket gültig blieb, mussten Peers ohne Hilfe des KDC neue Schlüssel bilden können. Die Zentrale sollte weder im Datenpfad stehen noch jeden Schlüsselwechsel genehmigen. Sie gab zeitlich begrenztes gemeinsames Material aus; innerhalb dieses Fensters arbeiteten die Peers weiter.

Viel Verantwortung blieb lokal. KINK musste SAs anlegen, ändern, erneuern und löschen, Cipher Suites und Flow Selectors aushandeln, Transport- und Tunnelmodus, AH und ESP sowie IPv4 und IPv6 unterstützen. Eine durch Kerberos bestätigte Identität bestimmte nicht automatisch, welche Netze sie vertreten durfte. Diese Autorisierung blieb in der lokalen IPsec-Policy.

Die Unterscheidung ist praktisch entscheidend. Ein gültiges Ticket belegt eine Identität und liefert geteiltes Material. Es gewährt nicht selbst das Recht, einen Tunnel für ein bestimmtes Präfix aufzubauen. Verknüpft eine lokale Regel eine echte Identität mit einem zu breiten Selektor, macht zentrale Authentisierung den falschen Beschluss lediglich glaubwürdiger.

RFC 3129 war auch noch nicht das fertige KINK-Protokoll. Das Informational-Dokument formulierte Anforderungen. Erst RFC 4430 spezifizierte KINK 2006 als Proposed Standard und verwies auf RFC 3129 als Grundlage. Die Trennung verhindert, Anforderungen als Einsatznachweis zu lesen. Keine Veröffentlichung beweist, dass KINK IKE im Betrieb verdrängte.

Die benachbarten Standards entwickelten sich weiter. RFC 4120 ersetzte die frühere Kerberos-V5-Spezifikation, RFC 3961 strukturierte Verschlüsselungs- und Prüfsummenprofile, RFC 4556 standardisierte PKINIT und RFC 6113 verallgemeinerte Pre-Authentication. IKE wurde durch RFC 4306 zu IKEv2 und später in RFC 7296 fortgeschrieben. Das Internet behielt mehrere Vertrauensmodelle, weil nicht jede Umgebung denselben Ausfall akzeptiert.

O(n) gegen O(n²) darf daher kein vollständiges Versprechen werden. Ein KDC reduziert im Modell paarweise Langzeitgeheimnisse, beseitigt aber nicht Master-Key-Schutz, Keytab-Rotation, Wiederherstellung, Cross-Realm-Vertrauen, Zeitsynchronisierung, Audit oder Kapazitätsplanung. Viele kleine Verpflichtungen werden gegen wenige, folgenreiche Institutionen getauscht.

Ein Ausfall verläuft gestuft. Bestehende SAs können weiterarbeiten; ein gültiges Ticket kann lokales Rekeying erlauben. Frische Credentials, abgelaufene Tickets und neue Service-Beziehungen benötigen die Zentrale früher. Die Grenze ist nicht „KDC weg, IPsec weg“, sondern das Zusammenspiel von Ticket-Laufzeit, SA-Laufzeit, Cache und nächstem Kontaktpunkt.

Bei einer Kompromittierung wächst der Radius. Zentrale Protokolle können Principal, Ticket und Zeitpunkt gut verbinden. Ein kompromittiertes KDC kann jedoch glaubwürdiges Vertrauen in großem Umfang ausstellen. Nachvollziehbarkeit und Schadenspotenzial steigen gemeinsam.

Die Security Considerations von RFC 3129 blieben nüchtern: Die erzeugten SAs würden die Vereinigung der Schwächen von IPsec und Kerberos erben. Zwei ausgereifte Systeme heben ihre Fehler nicht gegenseitig auf; ihre Nahtstelle kann neue erzeugen.

Historisch wichtig ist genau diese Sicht. Der Betrieb wurde Teil der kryptografischen Anforderung. Es genügte nicht, dass zwei Maschinen denselben Schlüssel berechnen. Entscheidend waren die Zahl der Beziehungen, der Ort der Policy, die Wiederholung teurer Arbeit und die Institution, die ein großes Netz regierbar machte.

Das KDC beseitigte Vertrauen nicht. Es machte Vertrauen wiederverwendbar, sichtbar und konzentriert. Darin lagen Betriebsgewinn und systemisches Risiko zugleich. RFC 3129 schrieb beide Seiten fest, bevor das Protokoll fertig war.

Quellen