7.2. KDC Messaging: IP Transports (KDC-Nachrichtenübertragung: IP-Transporte)

Kerberos definiert zwei IP-Transportmechanismen für die Kommunikation zwischen Clients und Servern: UDP/IP und TCP/IP.

7.2.1. UDP/IP transport (UDP/IP-Transport)

Kerberos-Server (KDCs), die IP-Transporte unterstützen, MÜSSEN UDP-Anfragen annehmen und SOLLEN auf Port 88 (dezimal) lauschen, sofern nicht ausdrücklich ein alternativer UDP-Port konfiguriert ist. Alternative Ports KÖNNEN verwendet werden, wenn mehrere KDCs für mehrere Realms auf demselben Host betrieben werden.

Kerberos-Clients, die IP-Transporte unterstützen, SOLLEN das Senden von UDP-Anfragen unterstützen. Clients SOLLEN die KDC-Auffindung [7.2.3] nutzen, um die IP-Adresse und den Port zu ermitteln, an die bzw. den sie ihre Anfrage senden.

Wenn ein Client einen KDC für eine KRB_KDC_REQ-Anfrage per UDP/IP-Transport kontaktiert, sendet er ein UDP-Datagramm, das ausschließlich eine Kodierung der Anfrage enthält. Der KDC antwortet mit einem Antwort-Datagramm, das ausschließlich eine Kodierung der Antwortnachricht (entweder KRB_ERROR oder KRB_KDC_REP) enthält, an den sendenden Port unter der IP-Adresse des Absenders. Die Antwort auf eine per UDP/IP-Transport gestellte Anfrage MUSS ebenfalls UDP/IP-Transport verwenden. Wenn die Antwort nicht per UDP verarbeitet werden kann (z. B. weil sie zu groß ist), MUSS der KDC KRB_ERR_RESPONSE_TOO_BIG zurückgeben und den Client zwingen, die Anfrage mit TCP erneut zu senden.

7.2.2. TCP/IP Transport (TCP/IP-Transport)

Kerberos-Server (KDCs), die IP-Transporte unterstützen, MÜSSEN TCP-Anfragen annehmen und SOLLEN auf Port 88 (dezimal) lauschen, sofern nicht ausdrücklich ein alternativer TCP-Port konfiguriert ist. Alternative Ports KÖNNEN verwendet werden, wenn mehrere KDCs für mehrere Realms auf demselben Host betrieben werden.

Clients MÜSSEN das Senden von TCP-Anfragen unterstützen, KÖNNEN aber versuchen, eine Anfrage zunächst per UDP zu senden. Clients SOLLEN die KDC-Auffindung [7.2.3] nutzen, um die IP-Adresse und den Port zu ermitteln, an die bzw. den sie ihre Anfrage senden.

Hinweis für Implementierer: Einige Erweiterungen des Kerberos-Protokolls schlagen fehl, wenn ein Client oder KDC ohne TCP-Transport-Unterstützung beteiligt ist. Implementierungen von RFC 1510 mussten TCP/IP-Transporte nicht unterstützen.

Wenn die KRB_KDC_REQ-Nachricht über einen TCP-Stream an den KDC gesendet wird, MUSS die Antwort (KRB_KDC_REP- oder KRB_ERROR-Nachricht) dem Client auf demselben TCP-Stream zurückgegeben werden, der für die Anfrage aufgebaut wurde. Der KDC KANN den TCP-Stream nach dem Senden einer Antwort schließen, KANN ihn aber auch für eine angemessene Zeit offen lassen, wenn er mit Folgeverkehr rechnet. Bei der Verwaltung von TCP/IP-Verbindungen auf dem KDC ist Vorsicht geboten, um Denial-of-Service-Angriffe aufgrund der Anzahl offener TCP/IP-Verbindungen zu verhindern.

Der Client MUSS damit rechnen, dass der KDC den Stream jederzeit nach Empfang einer Antwort schließt. Ein Stream-Schließen SOLLTE nicht als fataler Fehler behandelt werden. Sind stattdessen mehrere Austausche erforderlich (z. B. bestimmte Formen der Pre-Authentifizierung), muss der Client möglicherweise eine neue Verbindung aufbauen, wenn er bereit ist, nachfolgende Nachrichten zu senden. Ein Client KANN den Stream nach Empfang einer Antwort schließen und SOLLTE den Stream schließen, wenn er keine Folgenachrichten erwartet.

Ein Client KANN mehrere Anfragen senden, bevor Antworten eintreffen, muss aber damit rechnen, dass die Verbindung nach der ersten Antwort geschlossen wird.

Jede Anfrage (KRB_KDC_REQ) und jede Antwort (KRB_KDC_REP oder KRB_ERROR), die über den TCP-Stream gesendet wird, wird von der Länge der Anfrage als 4 Oktette in Netzwerk-Byte-Reihenfolge vorangestellt. Das höchstwertige Bit der Länge ist für künftige Erweiterungen reserviert und MUSS derzeit auf Null gesetzt sein. Empfängt ein KDC, der ein gesetztes höchstwertiges Bit der Längenkodierung nicht interpretieren kann, eine Anfrage mit gesetztem höchstwertigem Bit der Länge, MUSS er eine KRB-ERROR-Nachricht mit dem Fehler KRB_ERR_FIELD_TOOLONG zurückgeben und den TCP-Stream schließen.

Werden mehrere Anfragen über eine einzelne TCP-Verbindung gesendet und sendet der KDC mehrere Antworten, ist der KDC nicht verpflichtet, die Antworten in der Reihenfolge der zugehörigen Anfragen zu senden. Das kann es einigen Implementierungen erlauben, jede Antwort zu senden, sobald sie fertig ist, auch wenn frühere Anfragen noch bearbeitet werden (z. B. während auf eine Antwort von einem externen Gerät oder einer Datenbank gewartet wird).

7.2.3. KDC Discovery on IP Networks (KDC-Auffindung in IP-Netzwerken)

Kerberos-Client-Implementierungen MÜSSEN ein Verfahren bereitstellen, mit dem der Client den Standort der Kerberos Key Distribution Centers (KDCs, Schlüsselverteilungszentren) ermitteln kann. Üblicherweise haben Kerberos-Implementierungen solche Konfigurationsinformationen in einer Datei auf jedem Client-Rechner gespeichert. Die Erfahrung zeigt, dass diese Art der Speicherung von Konfigurationsinformationen Probleme mit veralteten Daten und Skalierung mit sich bringt, insbesondere bei realm-übergreifender Authentifizierung. Dieser Abschnitt beschreibt ein Verfahren zur Speicherung von KDC-Standortinformationen im Domain Name System [RFC1035].

7.2.3.1. DNS vs. Kerberos: Case Sensitivity of Realm Names (DNS vs. Kerberos: Groß-/Kleinschreibung von Realm-Namen)

In Kerberos sind Realm-Namen case-sensitiv. Obwohl dringend empfohlen wird, dass alle Realm-Namen vollständig in Großbuchstaben angegeben werden, haben sich nicht alle Standorte daran gehalten. Einige verwenden nur Kleinbuchstaben, andere gemischte Schreibweise. DNS hingegen ist bei Abfragen case-insensitiv. Da die Realm-Namen „MYREALM“, „myrealm“ und „MyRealm“ unterschiedlich sind, im Domain-Name-System aber gleich aufgelöst werden, ist es erforderlich, dass nur eine der möglichen Kombinationen aus Groß- und Kleinbuchstaben in Realm-Namen verwendet wird.

7.2.3.2. Specifying KDC Location Information with DNS SRV records (Angabe von KDC-Standortinformationen mit DNS-SRV-Records)

KDC-Standortinformationen werden mit dem DNS-SRV-RR [RFC2782] gespeichert. Das Format dieses RR lautet:

_Service._Proto.Realm TTL Class SRV Priority Weight Port Target

Der Service-Name für Kerberos ist stets kerberos.

Proto kann entweder udp oder tcp sein. Werden diese SRV-Records verwendet, MÜSSEN sowohl udp- als auch tcp-Records für alle KDC-Bereitstellungen angegeben werden.

Realm ist der Kerberos-Realm, dem dieser Record entspricht. Der Realm MUSS ein domain-style Realm-Name sein.

TTL, Class, SRV, Priority, Weight und Target haben die in RFC 2782 definierte übliche Bedeutung.

Gemäß RFC 2782 SOLL die Portnummer für _udp- und _tcp-SRV-Records der von der Internet Assigned Numbers Authority für kerberos zugewiesene Wert sein: 88 (dezimal), sofern der KDC nicht für einen alternativen TCP-Port konfiguriert ist.

Hinweis für Implementierer: Viele bestehende Client-Implementierungen unterstützen keine KDC-Auffindung und sind so konfiguriert, dass Anfragen an den von IANA zugewiesenen Port (88 dezimal) gesendet werden; daher wird dringend empfohlen, KDCs so zu konfigurieren, dass sie auf diesem Port lauschen.

7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks (KDC-Auffindung für Domain-Style-Realm-Namen in IP-Netzwerken)

Dies sind DNS-Records für einen Kerberos-Realm EXAMPLE.COM. Es gibt zwei Kerberos-Server, kdc1.example.com und kdc2.example.com. Abfragen sollten gemäß der angegebenen Priorität zuerst an kdc1.example.com gerichtet werden. Gewichtungen werden in diesen Beispiel-Records nicht verwendet.

_kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.