5.2. Basic Kerberos Types (Grundlegende Kerberos-Typen)

Dieser Abschnitt definiert mehrere Basistypen, die im gesamten Kerberos-Protokoll verwendet werden können.

5.2.1. KerberosString

Die ursprüngliche Spezifikation des Kerberos-Protokolls in RFC 1510 verwendet an mehreren Stellen GeneralString für menschenlesbare Zeichenketten. Historische Kerberos-Implementierungen konnten nicht den vollen Funktionsumfang von GeneralString nutzen. Dieser ASN.1-Typ erfordert Designierungs- und Invokations-Escape-Sequenzen gemäß ISO-2022/ECMA-35 zum Umschalten von Zeichensätzen; als G0 vorgegebener Standardzeichensatz ist ISO-646/ECMA-6 IRV (auch US-ASCII genannt) festgelegt, was in den meisten Fällen ausreicht.

ISO-2022/ECMA-35 definiert vier Zeichensatz-Codeelemente (G0..G3) und zwei Steuerfunktions-Codeelemente (C0..C1). DER verbietet die Designierung von Zeichensätzen außer den G0- und C0-Sätzen. Unglücklicherweise scheint dies die Nebenwirkung zu haben, ISO-8859 (ISO Latin) oder andere 96-Zeichen-Sätze zu verbieten, da ISO-2022/ECMA-35 deren Designierung als G0-Codeelement untersagt. Die ASN.1-Standardisierungsgemeinschaft prüft diese Nebenwirkung.

In der Praxis behandeln viele Implementierungen GeneralString als 8-Bit-Zeichenkette in einem beliebigen, implementierungsabhängigen Standardzeichensatz, ohne Escape-Sequenzen korrekt zu verwenden. Der Standardzeichensatz wird oft durch die Locale des aktuellen Benutzers bestimmt. Mindestens eine große Implementierung legt in GeneralString unescaped UTF-8-kodiertes Unicode ab. Diese Missachtung der GeneralString-Spezifikation führt zu Interoperabilitätsproblemen, wenn Client, Dienst und KDC widersprüchliche Zeichenkodierungen verwenden.

Diese unglückliche Situation resultiert aus unzureichender Dokumentation der Einschränkungen des ASN.1-Typs GeneralString in früheren Kerberos-Spezifikationen.

Der neue (nach RFC 1510) Typ KerberosString ist wie folgt definiert: ein GeneralString, der auf Zeichen aus IA5String beschränkt ist.

KerberosString  ::= GeneralString (IA5String)

US-ASCII-Steuerzeichen sollten in KerberosString in der Regel nicht verwendet werden. Steuerzeichen sollten nicht in Principal- oder Realm-Namen vorkommen.

Zur Kompatibilität dürfen Implementierungen GeneralString-Werte akzeptieren, die Zeichen außerhalb von IA5String enthalten; sie sollten sich bewusst sein, dass Zeichensatz-Designierungscodes fehlen können und die Kodierung fast immer als locale-spezifisch zu betrachten ist. Implementierungen dürfen auch GeneralString-Werte senden, die über IA5String hinausgehen, sollten sich aber bewusst sein, dass dies aus Interoperabilitätssicht stark riskant ist.

Einige bestehende Implementierungen kodieren locale-spezifische Zeichen unescaped in GeneralString. Das verletzt ASN.1. Die meisten kodieren US-ASCII in der linken Hälfte, sodass bei reiner US-ASCII-Übertragung ASN.1 nicht verletzt wird. Sobald solche Implementierungen unescaped locale Zeichen mit gesetztem High-Bit kodieren, verletzen sie ASN.1.

Andere Implementierungen verwenden GeneralString für UTF-8. Auch das verletzt ASN.1, weil UTF-8 eine andere Kodierung ist und keine von ISO 2022 definierten 94- oder 96-Zeichen-„G“-Sätze. Diese Implementierungen nutzen vermutlich nicht einmal ISO-2022-Escapes zum Wechsel der Kodierung. Selbst wenn eine Implementierung per Escape eine Kodierungsänderung ankündigt, verbietet ASN.1 Escape-Sequenzen außer denen zum Designieren/Aufrufen der für GeneralString zulässigen „G“- oder „C“-Sätze.

Künftige Protokollrevisionen werden höchstwahrscheinlich interoperablere Principal-Namensdarstellungen erlauben, möglicherweise einschließlich UTF8String.

Hinweis: Neue Constraints auf einen zuvor unconstrained Typ erzeugen einen neuen ASN.1-Typ. In diesem Fall ändert sich die Kodierung unter DER nicht.

5.2.2. Realm und PrincipalName

Realm           ::= KerberosString

PrincipalName   ::= SEQUENCE {
        name-type       [0] Int32,
        name-string     [1] SEQUENCE OF KerberosString
}

Kerberos-Realm-Namen werden als KerberosString kodiert. Realms dürfen kein Zeichen mit Code 0 (US-ASCII NUL) enthalten. Die meisten Realms bestehen aus mehreren durch Punkt (.) getrennten Komponenten im Internet-Domain-Stil oder durch Schrägstrich (/) getrennt im X.500-Namensstil. Abschnitt 6.1 legt akzeptable Realm-Namensformen fest. PrincipalName ist eine typisierte Sequenz von Komponenten mit folgenden Teilfeldern:

name-type
Dieses Feld gibt den Typ des folgenden Namens an. Vordefinierte Werte stehen in Abschnitt 6.2. name-type ist als Hinweis zu verstehen. Unabhängig vom Namenstyp dürfen zwei Namen nicht identisch sein (mindestens eine Komponente oder das Realm muss sich unterscheiden).

name-string
Dieses Feld kodiert die Sequenz von Komponenten des Namens, jede als KerberosString. PrincipalName und Realm bilden zusammen die Principal-Kennung. Die meisten PrincipalName haben nur wenige Komponenten (typischerweise ein oder zwei).

5.2.3. KerberosTime

KerberosTime    ::= GeneralizedTime -- with no fractional seconds

In Kerberos verwendete Zeitstempel werden als GeneralizedTime kodiert. KerberosTime-Werte dürfen keinen Bruchteil von Sekunden enthalten. Gemäß DER dürfen sie keine Trennzeichen enthalten und müssen die UTC-Zeitzone (Z) angeben. Beispiel: Der einzig gültige Wert für den 6. November 1985, 21:06:27 UTC ist 19851106210627Z.

5.2.4. Eingeschränkte Integer-Typen

Bestimmte Integer-Mitglieder von Typen sollten auf in 32 Bit darstellbare Werte beschränkt sein, um mit sinnvollen Implementierungsgrenzen vereinbar zu sein.

Int32           ::= INTEGER (-2147483648..2147483647)
                    -- signed values representable in 32 bits

UInt32          ::= INTEGER (0..4294967295)
                    -- unsigned 32 bit values

Microseconds    ::= INTEGER (0..999999)
                    -- microseconds

Obwohl sich dadurch der abstrakte Typ gegenüber RFC 1510 ändert, sollte die Kodierung in DER unverändert bleiben. Historische Implementierungen sind typischerweise auf 32-Bit-Integer beschränkt; zugewiesene Nummern sollten im 32-Bit-Raum liegen, um Interoperabilität zu fördern.

Mehrere Integer-Felder in Nachrichten sind auf feste Werte beschränkt.

pvno
Auch TKT-VNO oder AUTHENTICATOR-VNO genannt, ist dieses wiederkehrende Feld stets die Konstante 5. Es gibt keinen einfachen Weg, dieses Feld zu einer nützlichen Protokollversionsnummer zu machen; daher ist der Wert fixiert.

msg-type
Dieses Integer-Feld entspricht üblicherweise der Application-Tag-Nummer des Nachrichtentyps.

5.2.5. HostAddress und HostAddresses

HostAddress     ::= SEQUENCE  {
        addr-type       [0] Int32,
        address         [1] OCTET STRING
}

-- NOTE: HostAddresses is always used as an OPTIONAL field and
-- should not be empty.
HostAddresses   -- NOTE: subtly different from rfc1510,
                -- but has a value mapping and encodes the same
        ::= SEQUENCE OF HostAddress

Eine Hostadresse besteht aus zwei Feldern:

addr-type
Gibt den Typ der folgenden Adresse an. Vordefinierte Werte stehen in Abschnitt 7.5.3.

address
Kodiert eine einzelne Adresse vom Typ addr-type.

5.2.6. AuthorizationData

-- NOTE: AuthorizationData is always used as an OPTIONAL field and
-- should not be empty.
AuthorizationData       ::= SEQUENCE OF SEQUENCE {
        ad-type         [0] Int32,
        ad-data         [1] OCTET STRING
}

ad-data
Enthält Autorisierungsdaten, die gemäß dem Wert des zugehörigen ad-type-Felds zu interpretieren sind.

ad-type
Legt das Format des ad-data-Teilfelds fest. Alle negativen Werte sind für lokale Verwendung reserviert; nicht negative Werte sind für registrierte Verwendung reserviert.

Jede Typ- und Daten-Sequenz heißt Autorisierungselement. Elemente können anwendungsspezifisch sein; es gibt jedoch eine Menge rekursiver Standardelemente, die jede Implementierung verstehen sollte. Diese enthalten weitere eingebettete Elemente; die Interpretation des umschließenden Elements bestimmt, welche eingebetteten Elemente interpretiert werden müssen und welche ignoriert werden dürfen.

Diese generischen Autorisierungsdaten-Elemente sind rekursiv definiert: ad-data dieser Typen enthält wieder eine AuthorizationData-Sequenz, deren Interpretation vom umschließenden Element abhängt. Je nach Bedeutung des umschließenden Elements können eingebettete Elemente ignoriert werden, als direkt vom KDC ausgestellt interpretiert oder im separaten Klartextteil eines Tickets gespeichert werden. Die Typen der umschließenden Elemente sind Teil der Kerberos-Spezifikation, damit das Verhalten implementierungsübergreifend konsistent ist; andere Elemente müssen nur von betroffenen Anwendungen verstanden werden.

Liegen Autorisierungsdaten-Elemente in einem Ticket oder Authenticator vor, gelten sie als kritisch. Empfängt ein Server in einem AP-REQ oder im Ticket eines AP-REQ einen unbekannten Autorisierungsdaten-Typ, muss die Authentifizierung fehlschlagen, sofern das Element nicht in einem bekannten Autorisierungsdaten-Element gekapselt ist, das die Kritikalität der enthaltenen Elemente ändert. Autorisierungsdaten sollen die Ticketnutzung einschränken. Kann der Dienst nicht feststellen, ob eine Einschränkung für ihn gilt, kann die Annahme des Tickets eine Schwachstelle erzeugen. Optionale Autorisierungselemente können in einem AD-IF-RELEVANT-Element gekapselt werden.

In den folgenden Definitionen wird der ad-type-Wert als niederwertiger Teil der Unterabschnittsnummer angegeben; ad-data entspricht der ASN.1-Struktur nach der Überschrift.

Inhalt von ad-data	ad-type
DER-Kodierung von AD-IF-RELEVANT	1
DER-Kodierung von AD-KDCIssued	4
DER-Kodierung von AD-AND-OR	5
DER-Kodierung von AD-MANDATORY-FOR-KDC	8

5.2.6.1. IF-RELEVANT

AD-IF-RELEVANT          ::= AuthorizationData

In einem IF-RELEVANT-Element gekapselte AD-Elemente sollen nur von Anwendungsservern interpretiert werden, die den spezifischen ad-type des eingebetteten Elements verstehen. Server, die den Typ nicht verstehen, dürfen nicht interpretierbare Elemente ignorieren. Das Element erleichtert Interoperabilität zwischen Implementierungen mit lokalen Autorisierungserweiterungen. Der ad-type von AD-IF-RELEVANT ist (1).

5.2.6.2. KDCIssued

AD-KDCIssued            ::= SEQUENCE {
        ad-checksum     [0] Checksum,
        i-realm         [1] Realm OPTIONAL,
        i-sname         [2] PrincipalName OPTIONAL,
        elements        [3] AuthorizationData
}

ad-checksum
Kryptografische Prüfsumme über die DER-Kodierung von elements in AuthorizationData, berechnet mit dem Session Key. Der checksumtype ist der für den Verschlüsselungstyp des Session Keys verpflichtende Prüfsummen-Typ; die Key-Usage ist 19.

i-realm, i-sname
Falls abweichend vom Namen des KDC selbst, der ausstellende Principal. Wenn der KDC die Authentizität vom ausstellenden Principal signierter Elemente verifizieren kann, informiert dies den Anwendungsserver über die Gültigkeit der Elemente.

elements
Sequenz von Autorisierungsdaten-Elementen, die vom KDC ausgestellt wurden.

Das vom KDC ausgestellte ad-data-Feld soll Privilegienattribute und andere positive Autorisierungsmechanismen in Kerberos-Principal-Credentials einbetten und damit über ein Ticket ohne solche Daten hinausgehen.

Ohne dieses Element wäre das nicht möglich: Die Definition von authorization-data erlaubt es TGT-Inhabern, bei Dienstticket-Anfragen beliebig Elemente hinzuzufügen, und über den Authenticator auch bei delegierten Tickets.

Bei KDC-ausgestellten Elementen wird das verhindert, weil der KDC die Elemente signiert, indem er die Prüfsumme mit dem Server-Schlüssel (oder davon abgeleitet) verschlüsselt. Fehlt diese „Signatur“, muss der Anwendungsserver in KDC-ausgestellten Elementen eingebettete Elemente ignorieren. Aus dem TGT stammende, hier gekapselte Elemente kann der KDC gemäß Policy interpretieren und als Grundlage für neue signierte Elemente in abgeleiteten Tickets nutzen, werden aber nicht unverändert kopiert. Kopiert ein KDC ohne Kenntnis dieses Elements sie direkt, ist die Signatur für die Anwendung falsch und der Server ignoriert das Feld.

Anwendungen, Anwendungsserver und KDC ohne dieses Element können es und seine Inhalte gefahrlos ignorieren.

Der ad-type von AD-KDCIssued ist (4).

5.2.6.3. AND-OR

AD-AND-OR               ::= SEQUENCE {
        condition-count [0] Int32,
        elements        [1] AuthorizationData
}

Ist ein restriktives AD-Element in einem AND-OR-Element gekapselt, gilt das AND-OR-Element als erfüllt genau dann, wenn mindestens so viele der gekapselten Elemente wie in condition-count angegeben erfüllt sind. Mit condition-count = 1 lässt sich ein logisches OR abbilden; mit condition-count gleich der Anzahl eingebetteter Elemente ein AND. Anwendungsserver ohne dieses Element müssen Tickets mit solchen Autorisierungsdaten ablehnen.

Der ad-type von AD-AND-OR ist (5).

5.2.6.4. MANDATORY-FOR-KDC

AD-MANDATORY-FOR-KDC    ::= AuthorizationData

In MANDATORY-FOR-KDC gekapselte AD-Elemente interpretiert der KDC. Ein KDC, der den eingebetteten Typ nicht versteht, muss die Anfrage ablehnen.

Der ad-type von AD-MANDATORY-FOR-KDC ist (8).

5.2.7. PA-DATA

Historisch hieß PA-DATA „Pre-Authentication Data“ und diente der Verstärkung der Erstauthentifizierung gegenüber dem KDC. Seither dienen die Felder auch als typisierte Erweiterungspunkte für den Austausch mit dem KDC.

PA-DATA         ::= SEQUENCE {
        -- NOTE: first tag is [1], not [0]
        padata-type     [1] Int32,
        padata-value    [2] OCTET STRING -- might be encoded AP-REQ
}

padata-type
Gibt an, wie padata-value zu interpretieren ist. Negative Werte von padata-type sind für nicht registrierte Verwendung reserviert; nicht negative Werte für registrierte Typen.

padata-value
Enthält typischerweise eine weitere DER-kodierte Struktur; padata-type identifiziert den Typ.

padata-type	Name	Inhalt von padata-value
1	pa-tgs-req	DER-kodiertes AP-REQ
2	pa-enc-timestamp	DER-kodiertes PA-ENC-TIMESTAMP
3	pa-pw-salt	salt (nicht ASN.1-kodiert)
11	pa-etype-info	DER-kodiertes ETYPE-INFO
19	pa-etype-info2	DER-kodiertes ETYPE-INFO2

Das Feld kann auch Informationen für Kerberos-Erweiterungen enthalten, z. B. zur ersten Identitätsprüfung des Clients vor jeder Antwort.

padata kann ferner Informationen enthalten, die KDC oder Client bei der Schlüsselwahl oder Entschlüsselung der Antwort unterstützen. Das ist nützlich für Token-Karten mit Kerberos. Details solcher Erweiterungen stehen in separaten Dokumenten. Weitere Verwendungen siehe [Pat92].

5.2.7.1. PA-TGS-REQ

Bei Anforderung zusätzlicher Tickets (KRB_TGS_REQ) enthält padata-value ein kodiertes AP-REQ. Die Prüfsumme im Authenticator (kollisionsresistent) wird über die Kodierung von KDC-REQ-BODY berechnet.

5.2.7.2. Verschlüsselter Zeitstempel (Pre-Authentication)

Es gibt Pre-Authentication-Typen, mit denen ein Client mittels verschlüsseltem Zeitstempel vorgezogen authentifiziert werden kann.

PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC

PA-ENC-TS-ENC           ::= SEQUENCE {
        patimestamp     [0] KerberosTime -- client's time --,
        pausec          [1] Microseconds OPTIONAL
}

patimestamp enthält die Client-Zeit, pausec die Mikrosekunden; pausec kann entfallen, wenn der Client nicht mehr als eine Anfrage pro Sekunde erzeugt. Der Ciphertext (padata-value) ist die PA-ENC-TS-ENC-Kodierung, verschlüsselt mit dem Geheimnis des Clients und Key Usage 1.

Dieser Pre-Authentication-Typ fehlte in RFC 1510, wird aber von vielen Implementierungen unterstützt.

5.2.8. KerberosFlags

Für mehrere Nachrichtentypen wird der eingeschränkte Bitstring-Typ KerberosFlags verwendet.

KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
                    -- minimum number of bits shall be sent,
                    -- but no fewer than 32

Kompatibilitätshinweis: Der folgende Absatz beschreibt eine Änderung gegenüber RFC 1510, die bei strikter Einhaltung von ASN.1 DER und RFC 1510 zu Inkompatibilität führen kann.

ASN.1-Bitstrings haben vielfältige Verwendungen. Die einfachste ist ein Bitvektor ohne semantische Bedeutung einzelner Bits; die Länge muss kein Vielfaches von acht sein. Die Verwendung als kompakter Boolescher Vektor (jedes Bit hat Bedeutung) wirft Probleme auf. Die natürliche Darstellung wäre ASN.1 „NamedBit“; DER verlangt bei NamedBit, dass nachfolgende Nullbits abgeschnitten werden. Das wird leicht übersehen, zumal C-Implementierungen Flags oft als 32-Bit-Integer speichern.

Hätte KDCOptions NamedBits wie in RFC 1510 und wäre nur „forwardable“ (Bit 1) gesetzt, müsste die DER-Kodierung nur zwei Bits enthalten: reserviertes Bit 0 mit Wert 0 und „forwardable“ mit Wert 1.

Die meisten Kerberos-Implementierungen senden für solche Flag-Bitstrings jedoch bedingungslos 32 Bit. Das verstößt gegen die RFC-1510-ASN.1-Syntax, ist aber so weit verbreitet, dass die Protokollbeschreibung angepasst wird.

Daher entfernt dieses Dokument die NamedBit-Notation für einzelne Bits und führt sie nur noch als Kommentar. KerberosFlags verlangt mindestens 32 kodierte Bits; liberale Implementierungen dürfen weniger als 32 Bit akzeptieren und fehlende Bits als Null lesen.

Derzeit sind in KerberosFlags keine Flags über Bit 31 definiert; künftige Revisionen könnten das ändern. Bei mehr als 32 Bits könnte eine Revision festlegen, dass mindestens so viele Bits gesendet werden, wie für das höchste gesetzte Bit nötig sind, analog zur DER-Kodierung von NamedBit-Bitstrings.

5.2.9. Verschlüsselungsbezogene Typen

Viele Kerberos-Nachrichten enthalten EncryptedData als Behälter für beliebige verschlüsselte Daten, meist eine verschlüsselte Kodierung eines anderen Typs. Die Felder in EncryptedData helfen dem Empfänger, den Entschlüsselungsschlüssel zu wählen.

EncryptedData   ::= SEQUENCE {
        etype   [0] Int32 -- EncryptionType --,
        kvno    [1] UInt32 OPTIONAL,
        cipher  [2] OCTET STRING -- ciphertext
}

etype
Identifiziert den Verschlüsselungsalgorithmus für cipher.

kvno
Schlüsselversionsnummer des für die Verschlüsselung verwendeten Schlüssels; nur bei Nachrichten mit Langzeitschlüssel (z. B. Principal-Schlüssel).

cipher
Der Ciphertext als OCTET STRING. (Mechanismen gemäß [RFC3961] müssen Integritätsschutz bieten; eine zusätzliche Prüfsumme ist nicht erforderlich.)

EncryptionKey transportiert einen kryptografischen Schlüssel für Verschlüsselungszwecke.

EncryptionKey   ::= SEQUENCE {
        keytype         [0] Int32 -- actually encryption type --,
        keyvalue        [1] OCTET STRING
}

keytype
Gibt den Verschlüsselungstyp des Schlüssels in keyvalue an. Trotz des Namens „keytype“ handelt es sich um den Encryption Type. Früher teilten sich mehrere Systeme mit unterschiedlicher Verschlüsselung aber kompatiblen Schlüsseln dieselbe Nummer; diese Nutzung ist veraltet.

keyvalue
Der Schlüssel als Oktettfolge.

Nachrichten mit zu authentifizierenden Klartextdaten verwenden oft Checksum. Die meisten Instanzen nutzen keyed Hashing, sofern nicht anders vermerkt.

Checksum        ::= SEQUENCE {
        cksumtype       [0] Int32,
        checksum        [1] OCTET STRING
}

cksumtype
Algorithmus zur Erzeugung der Prüfsumme.

checksum
Die Prüfsumme als Oktettfolge.

Kurzüberblick zu Verschlüsselung und Prüfsummen in Kerberos siehe Abschnitt 4.