1.5. Extending Kerberos without Breaking Interoperability (Erweiterung von Kerberos ohne Interoperabilitätsbruch)

Überblick

Mit wachsender Verbreitung von Kerberos-Implementierungen wird die Erweiterbarkeit von Kerberos wichtiger. Dieser Abschnitt enthält Richtlinien, damit künftige Implementierungen die Interoperabilität wahren können.

Erweiterungsmechanismus

Kerberos stellt einen allgemeinen Mechanismus für Protokollerweiterbarkeit bereit:

Protokollnachrichten enthalten typisierte Lücken (typed holes)
Unternachrichten enthalten einen Octet-String mit einer Ganzzahl, die die Interpretation festlegt
Ganzzahltypen sind zentral registriert
Kann für Herstellererweiterungen und IETF-Standardisierungen genutzt werden

Definition: In diesem Dokument bezeichnet "Extension" (Erweiterung) das Festlegen eines neuen Typs zum Einfügen in eine bestehende typisierte Lücke, nicht das Hinzufügen neuer Felder zu ASN.1-Typen (sofern nicht ausdrücklich anders angegeben).

1.5.1. Kompatibilität mit RFC 1510

Einschränkungen

Bestehende Kerberos-Nachrichtenformate lassen sich nicht einfach erweitern, indem Felder zu ASN.1-Typen hinzugefügt werden:

Zusätzliche Felder führen oft dazu, dass die gesamte Nachricht verworfen wird
Es wird kein Fehlerhinweis geliefert

Anforderungen an Implementierungen

Alle neuen oder geänderten Implementierungen, die eine unbekannte Nachrichtenerweiterung empfangen:

SOLLEN: die Kodierung der Erweiterung beibehalten
SOLLEN: ihre Anwesenheit ignorieren
DÜRFEN NICHT: eine Anfrage allein deshalb ablehnen, weil eine Erweiterung vorhanden ist

Ausnahme: Authorization Data

Wenn ein unbekannter Authorization-Data-Elementtyp von einem Server (außer dem Ticket-Granting Service) empfangen wird:

entweder in einer AP-REQ
oder in einem Ticket, das in einer AP-REQ enthalten ist

dann MUSS die Authentifizierung fehlschlagen.

Begründung: Authorization Data schränken die Ticketnutzung ein. Kann der Dienst nicht feststellen, ob eine Einschränkung gilt, kann eine Sicherheitsschwäche entstehen.

Best Practice: Optionale Authorization-Elemente SOLLEN in ein AD-IF-RELEVANT-Element eingeschlossen werden.

Verhalten des Ticket-Granting Service

Der TGS:

MUSS unbekannte Authorization-Data-Typen ignorieren, sie aber in abgeleitete Tickets weiterreichen
Ausnahme: Sind die Datentypen in einem MANDATORY-FOR-KDC-Element eingebettet, wird die Anfrage abgelehnt

1.5.2. Senden erweiterbarer Nachrichten

Kernprinzip

Es ist Vorsicht geboten, damit alte Implementierungen Nachrichten verstehen, die an sie gesendet werden, auch wenn sie eine verwendete Erweiterung nicht verstehen.

Regel: Sofern der Sender nicht weiß, dass eine Erweiterung unterstützt wird, darf die Erweiterung die Semantik der Kernnachricht oder zuvor definierter Erweiterungen nicht ändern.

Beispielszenario

Eine Erweiterung, die Schlüsselinformationen enthält, die zum Entschlüsseln des verschlüsselten Teils von KDC-REP nötig sind:

darf nur verwendet werden, wenn der Empfänger die Erweiterung unterstützt
der Client könnte die Unterstützung über ein padata-Element in der AS-REQ-Sequenz signalisieren
der KDC sollte die Erweiterung nur nutzen, wenn das padata-Element vorhanden ist

Best Practice: Wenn die Richtlinie die Erweiterung verlangt, soll ein Fehler zurückgegeben werden, der angibt, dass die Erweiterung erforderlich ist, statt sie zu verwenden, wenn der Empfänger sie möglicherweise nicht unterstützt. Das erleichtert die Fehlersuche.

Referenz

Vollständige technische Details finden sich im Original RFC 4120, Abschnitt 1.5.