5.3. Tickets

Dieser Abschnitt beschreibt Format und Verschlüsselungsparameter von Tickets und Authenticators. Sind Ticket oder Authenticator in einer Protokollnachricht enthalten, gelten sie als opake Objekte. Ein Ticket ist ein Datensatz, der dem Client hilft, sich gegenüber einem Dienst zu authentifizieren.

Ticket-Struktur

Ticket          ::= [APPLICATION 1] SEQUENCE {
        tkt-vno         [0] INTEGER (5),
        realm           [1] Realm,
        sname           [2] PrincipalName,
        enc-part        [3] EncryptedData -- EncTicketPart
}

Feldbeschreibung

tkt-vno
Versionsnummer des Ticketformats. Dieses Dokument beschreibt Version 5.

realm
Realm, das das Ticket ausgestellt hat; identifiziert auch den Realm-Teil des Server-Principals. Da Kerberos-Server nur für Server ihres Realms Tickets ausstellen, sind beide stets gleich.

sname
Alle Namenskomponenten des Server-Principals, einschließlich der die Dienstinstanz identifizierenden Teile.

enc-part
Verschlüsselte Kodierung der Sequenz EncTicketPart. Verschlüsselt mit dem vom Kerberos und dem Zielserver geteilten Schlüssel (Server-Schlüssel); Key Usage 2.

Verschlüsselter Ticketteil (EncTicketPart)

EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
        flags                   [0] TicketFlags,
        key                     [1] EncryptionKey,
        crealm                  [2] Realm,
        cname                   [3] PrincipalName,
        transited               [4] TransitedEncoding,
        authtime                [5] KerberosTime,
        starttime               [6] KerberosTime OPTIONAL,
        endtime                 [7] KerberosTime,
        renew-till              [8] KerberosTime OPTIONAL,
        caddr                   [9] HostAddresses OPTIONAL,
        authorization-data      [10] AuthorizationData OPTIONAL
}

-- Kodiertes transited-Feld
TransitedEncoding       ::= SEQUENCE {
        tr-type         [0] Int32 -- must be registered --,
        contents        [1] OCTET STRING
}

TicketFlags     ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- may-postdate(5),
        -- postdated(6),
        -- invalid(7),
        -- renewable(8),
        -- initial(9),
        -- pre-authent(10),
        -- hw-authent(11),
-- Neue Flags seit 1510
        -- transited-policy-checked(12),
        -- ok-as-delegate(13)

Ticket-Flags (TicketFlags)

Dieses Feld zeigt an, welche Optionen bei Ausstellung oder Anforderung des Tickets gesetzt wurden oder angefordert wurden. Bedeutung der Bits:

Bit	Name	Beschreibung
0	reserved	Für künftige Erweiterungen reserviert
1	forwardable	Wird üblicherweise nur vom TGS ausgewertet, der Zielserver kann es ignorieren. Gesetzt: Der Ticketvergabeserver darf auf Basis dieses Tickets ein neues TGT mit anderen Netzadressen ausstellen
2	forwarded	Gesetzt: Ticket wurde weitergeleitet oder basiert auf Authentifizierung mit weitergeleitetem TGT
3	proxiable	Wie FORWARDABLE, aber der TGS darf nur Nicht-TGT-Tickets mit anderen Adressen ausstellen
4	proxy	Gesetzt: Ticket ist ein Proxy-Ticket
5	may-postdate	Üblicherweise nur TGS; Zielserver kann ignorieren. Erlaubt dem TGS, auf Basis dieses TGT ein postdated Ticket auszustellen
6	postdated	Ticket ist postdated; der Dienst kann authtime prüfen, wann die Erstauthentifizierung stattfand
7	invalid	Ticket ungültig, muss vor Nutzung vom KDC validiert werden. Anwendungsserver müssen Tickets mit diesem Flag ablehnen
8	renewable	Üblicherweise nur TGS; vorsichtige Server können erneuerbare Tickets ablehnen. Ermöglicht Ersatzticket mit späterem Ablauf
9	initial	Ticket wurde per AS-Protokoll ausgestellt, nicht aus einem TGT abgeleitet
10	pre-authent	Client wurde vor Ticketausstellung vom KDC authentifiziert; Stärke der Methode ist nicht angegeben
11	hw-authent	Erstauthentifizierung erforderte Hardware, die nur dem genannten Client zugeordnet ist; Methode und Stärke wählt der KDC
12	transited-policy-checked	Realm-KDC hat transited gemäß vertrauenswürdiger Transiter-Policy geprüft. Bei 0 muss der Anwendungsserver transited selbst prüfen oder ablehnen. Bei 1 darf er auf die KDC-Prüfung vertrauen, kann aber zusätzlich eigene Policy anwenden. Neu seit RFC 1510
13	ok-as-delegate	Der im Ticket genannte Server (nicht der Client) ist laut Realm-Policy für Delegation geeignet. Der Client kann das Flag bei der Entscheidung nutzen, Credentials (Proxy oder weitergeleitetes TGT) zu delegieren, darf es aber ignorieren. Admins sollten Sicherheit und Standort des Servers bedenken. Neu seit RFC 1510
14-31	reserved	Für künftige Verwendung reserviert

Weitere Felder

key
In Ticket und KDC-Antwort: transportiert den Session Key von Kerberos zum Anwendungsserver und Client.

crealm
Realm, in dem der Client registriert ist und die Erstauthentifizierung stattfand.

cname
Namensteil der Client-Principal-Kennung.

transited
Listen Kerberos-Realms, die an der Authentifizierung des Ticketinhabers beteiligt waren. Die Reihenfolge der Durchquerung ist nicht angegeben. Kodierung siehe Abschnitt 3.3.3.2. Soll ein CA-Name eingetragen werden (Erweiterungen), ist der X.500-Name der CA gemäß RFC 2253 auf Einträge in transited abzubilden.

authtime
Zeitpunkt der Erstauthentifizierung des genannten Principals; Ausstellungszeit des ursprünglichen Tickets, auf dem dieses Ticket basiert. Dient dem Zieldienst als Zusatzinformation und KDCs für „Hot-List“-Dienste. Sehr vorsichtige Dienste können Tickets mit zu alter Erstauthentifizierung ablehnen. Wird auch in KDC-Antworten zurückgegeben; bei KRB_AS_REP entspricht es der aktuellen KDC-Zeit. Diesen Wert zur Uhrenkorrektur zu verwenden ist nicht ratsam, da die Echtheit und Aktualität der KRB_AS_REP nicht zuverlässig feststeht.

starttime
Beginn der Gültigkeit des Tickets. Zusammen mit endtime definiert es die Lebensdauer. Fehlt starttime, gilt authtime als Ersatz für die Lebensdauerberechnung.

endtime
Zeitpunkt, ab dem das Ticket nicht mehr akzeptiert wird. Einzelne Dienste können kürzere Gültigkeiten erzwingen und noch gültige Tickets ablehnen; endtime ist also eine Obergrenze.

renew-till
Nur bei gesetztem RENEWABLE-Flag: maximal mögliches endtime nach Erneuerungen; absolute Obergrenze inklusive aller Renewals.

caddr
Null (feld fehlt) oder eine oder mehrere Hostadressen, von denen aus das Ticket nutzbar ist. Ohne Adressen: Nutzung von überall möglich. Ausstellung oder Annahme adressloser Tickets ist Policy-Sache; wegen NAT wird empfohlen, sie zu erlauben.

Adressen im Ticket erschweren Missbrauch gestohlener Credentials: Der Session Key wird nicht im Klartext übertragen, daher reicht Abhören allein nicht; ein Angreifer braucht Zugriff auf den Session Key.

Die Netzadresse der eingehenden Verbindung ist nicht zuverlässig bestimmbar. Ein Angreifer mit Kontrolle über den Client kann Credentials dort nutzen. Adressen erschweren nur Diebstahl und Nutzung von einem „sicheren“ Ort, sie verhindern ihn nicht.

authorization-data
Transportiert Autorisierungsdaten vom ausstellenden Principal zum Anwendungsdienst. Fehlt Autorisierungsdaten, entfällt das Feld. Der Feldname ist irreführend; „Einschränkungen“ wäre treffender, ist aber nicht änderbar.

Das Feld enthält Einschränkungen der Rechte aus ticketbasierter Authentifizierung. Jeder Inhaber des Credentials kann Einträge hinzufügen, die die erlaubten Aktionen weiter einschränken, z. B. bei TGS-Austausch oder bei verketteter Delegation über den Authenticator.

Da Inhaber Einträge hinzufügen können, dürfen Einträge ohne separate Authentifizierung (z. B. in KDC-ausgestellten Elementen) die Privilegien nicht über das hinaus erweitern, was das Ticket allein gewähren würde.

Inhalt kann dienstspezifisch sein (Objektnamen und Rechte). Format der Struktur siehe Abschnitt 5.2.6; Kerberos definiert nur die Typinformation (ad-type).

Über authorization_data kann ein Principal einen Proxy für einen bestimmten Zweck ausstellen: Ein Client erhält z. B. einen Proxy des Dateiservers für den Druckdienst; durch Dateinamen im Feld weiß der Dateiserver, dass der Druckserver nur für diese Datei die Client-Rechte nutzen darf.

Damit lassen sich separate Dienste für Autorisierung oder Gruppenmitgliedschaft aufbauen: Die autorisierende Instanz (nicht der Authorization Server) kann ein Ticket auf eigenen Namen holen, Rechte einschränken und delegiert sie per Proxy an den Client, der die Autorisierung getrennt vom Authentifizierungsaustausch vorlegt. Alternativ können bei KDC-signierten Autorisierungsdaten (5.2.6.2) solche Credentials in das Ticket des autorisierenden Principals eingebettet werden.

Leeres caddr zusammen mit Proxy in authorization-data kann Ticket und Session Key als Capability behandeln. Weitere Anwendungsideen siehe [Neu93].

authorization-data ist optional.

5.3. Tickets​

Ticket-Struktur​

Feldbeschreibung​

Verschlüsselter Ticketteil (EncTicketPart)​

Ticket-Flags (TicketFlags)​

Weitere Felder​