5.4. Specifications for the AS and TGS Exchanges (Spezifikationen für AS- und TGS-Austausche)
5.4. Specifications for the AS and TGS Exchanges (Spezifikationen für AS- und TGS-Austausche)
Dieser Abschnitt spezifiziert das Format der Nachrichten im Austausch zwischen Client und Kerberos-Server. Mögliche Fehlernachrichten sind in Abschnitt 5.9.1 beschrieben.
5.4.1. Definition von KRB_KDC_REQ
Die Nachricht KRB_KDC_REQ hat keine eigene Application-Tag-Nummer. Sie ist in KRB_AS_REQ oder KRB_TGS_REQ eingebettet, die jeweils ein Application-Tag haben, je nachdem ob ein Erstticket oder ein Zusatzticket angefordert wird. In beiden Fällen sendet der Client die Nachricht an den KDC, um Credentials für einen Dienst zu erhalten.
Die Felder der Nachricht sind:
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ
KDC-REQ ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5) ,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData OPTIONAL
-- AuthorizationData --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty
}
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- opt-hardware-auth(11),
-- unused12(12),
-- unused13(13),
-- 15 is reserved for canonicalize
-- unused15(15),
-- 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
Die Felder dieser Nachricht:
pvno
In jeder Nachricht enthalten; gibt die Protokollversionsnummer an. Dieses Dokument spezifiziert Version 5.
msg-type
Gibt den Nachrichtentyp an. Entspricht fast immer dem einer Nachricht zugeordneten Application-Identifier und dient der leichteren Auswertung durch die Anwendung. Bei KDC-REQ ist der Typ KRB_AS_REQ oder KRB_TGS_REQ.
padata
Enthält Pre-Authentication-Daten. Anfragen nach Zusatztickets (KRB_TGS_REQ) MÜSSEN ein padata vom Typ PA-TGS-REQ enthalten.
Das Feld padata (Pre-Authentication Data) enthält eine Sequenz von Authentifizierungsinformationen, die vor Ausstellung oder Entschlüsselung von Credentials benötigt werden können.
req-body
Markiert den Umfang der übrigen Felder. Soll eine Prüfsumme über die Anfrage gebildet werden, bezieht sie sich auf die Kodierung der KDC-REQ-BODY-Sequenz innerhalb von req-body.
kdc-options
Steht in KRB_AS_REQ und KRB_TGS_REQ und gibt an, welche Flags der Client auf den Tickets gesetzt haben möchte sowie weitere Informationen zum KDC-Verhalten. Wo sinnvoll, kann der Optionsname mit dem durch die Option gesetzten Flag übereinstimmen. Meist stimmt das Optionsbit mit dem Flag-Feld überein, das ist aber nicht garantiert; ein blindes Kopieren von options nach flags ist daher unzulässig. Ohnehin sind vor der Berücksichtigung einer Option weitere Prüfungen nötig.
kdc_options ist ein Bitfeld: gewählte Optionen durch Bit 1, nicht gewählte und reservierte durch 0. Bitkodierung siehe Abschnitt 5.2. Ausführlicher in Abschnitt 2. Bedeutungen:
Bits Name Beschreibung
0 RESERVED Für künftige Erweiterungen reserviert.
1 FORWARDABLE Das auszustellende Ticket soll das forwardable-Flag tragen. Nur in der Erstanfrage oder in Folgeanfragen, wenn das zugrunde liegende TGT ebenfalls forwardable ist.
2 FORWARDED Nur in Anfragen an den Ticketvergabeserver; wird nur berücksichtigt, wenn das TGT FORWARDABLE gesetzt hat. Kennzeichnet eine Weiterleitungsanfrage. Die gültigen Hostadressen für das Ergebnisticket stehen im addresses-Feld.
3 PROXIABLE Das auszustellende Ticket soll proxiable sein. Nur Erstanfrage oder Folgeanfrage mit proxiablem TGT.
4 PROXY Proxy-Anfrage; nur wenn das TGT PROXIABLE hat. Adressen wie bei FORWARDED im addresses-Feld.
5 ALLOW-POSTDATE Auszustellendes Ticket soll MAY-POSTDATE tragen. Nur Erst- oder Folgeanfrage, wenn das TGT ebenfalls MAY-POSTDATE hat.
6 POSTDATED Anfrage nach postdated Ticket; nur wenn das TGT MAY-POSTDATE hat. Das Ergebnisticket hat INVALID; dieses Flag kann nach Erreichen von starttime durch spätere KDC-Anfrage zurückgesetzt werden.
7 RESERVED Derzeit unbenutzt.
8 RENEWABLE Auszustellendes Ticket soll RENEWABLE sein. Nur Erstanfrage oder wenn das zugrunde liegende TGT erneuerbar ist. Bei dieser Option enthält rtime die gewünschte absolute Ablaufzeit.
9 RESERVED Für PK-Cross reserviert.
10 RESERVED Für künftige Verwendung.
11 RESERVED Für opt-hardware-auth.
12-25 RESERVED Für künftige Verwendung.
26 DISABLE-TRANSITED-CHECK Standard prüft der KDC das transited-Feld eines TGT gegen die Policy des lokalen Realms, bevor abgeleitete Tickets ausgestellt werden. Ist dieses Flag gesetzt, entfällt die transited-Prüfung. Tickets ohne diese Prüfung werden durch TRANSITED-POLICY-CHECKED = 0 gekennzeichnet; der Anwendungsserver muss transited lokal prüfen. KDCs SOLLTEN DISABLE-TRANSITED-CHECK berücksichtigen, sind dazu aber nicht verpflichtet. Flag neu seit RFC 1510.
27 RENEWABLE-OK Ein erneuerbares Ticket ist akzeptabel, wenn kein Ticket mit der angeforderten Lebensdauer sonst möglich ist; dann darf ein erneuerbares Ticket mit renew-till gleich dem angeforderten endtime ausgestellt werden. renew-till kann weiter durch lokale oder principal-/serverbezogene Grenzen begrenzt sein.
28 ENC-TKT-IN-SKEY Nur für den Ticketvergabedienst. Das Ticket für den Zielserver wird mit dem Session Key aus dem zusätzlich gelieferten TGT verschlüsselt.
29 RESERVED Für künftige Verwendung.
30 RENEW Nur Ticketvergabedienst. Die Anfrage dient der Erneuerung. Das vorgelegte Ticket ist mit dem Geheimnis des Servers verschlüsselt, für den es gültig ist. Nur wenn das zu erneuernde Ticket RENEWABLE hat und renew-till noch nicht überschritten ist. Das zu erneuernde Ticket wird im padata-Feld im Authentifizierungsheader übergeben.
31 VALIDATE Nur Ticketvergabedienst. Validierung eines postdated Tickets; nur wenn das vorgelegte Ticket postdated ist, INVALID gesetzt hat und sonst jetzt nutzbar wäre. Validierung vor starttime unmöglich. Das Validierungsticket ist mit dem Schlüssel des Zielservers verschlüsselt und wird im padata-Feld im Authentifizierungsheader übergeben.
cname und sname
Wie für das Ticket in Abschnitt 5.3. sname darf nur fehlen, wenn ENC-TKT-IN-SKEY gesetzt ist; dann wird der Servername aus dem Client-Namen im als additional-tickets übergebenen Ticket entnommen.
enc-authorization-data
Wenn vorhanden (nur in TGS_REQ-Form), Kodierung der gewünschten authorization-data, verschlüsselt unter dem Subsession Key des Authenticators, falls vorhanden, sonst unter dem Session Key des TGT (Authenticator und TGT stammen aus padata in KRB_TGS_REQ). Key Usage 5 bei Subsession Key, 4 bei Session Key.
realm
Realm-Teil der Server-Principal-Kennung. Im AS-Austausch auch Realm-Teil des Clients.
from
In KRB_AS_REQ und KRB_TGS_REQ bei postdated gewünschtem Ticket: gewünschter starttime. Fehlt das Feld, SOLL der KDC die aktuelle Zeit verwenden.
till
Vom Client gewünschte Ablaufzeit; nicht optional. Spezialfall: endtime „19700101000000Z“ bedeutet maximale nach KDC-Policy erlaubte Lebensdauer. Implementierungshinweis: entspricht auf vielen Systemen UNIX time_t 0.
rtime
Optional: gewünschte renew-till-Zeit.
nonce
Teil von KDC-Anfrage und -antwort; vom Client erzeugte Zufallszahl. Wiederholung derselben Zahl in der verschlüsselten KDC-Antwort belegt Frische und schützt vor Replay. Nonces DÜRFEN NIEMALS wiederverwendet werden.
etype
Gewünschte Verschlüsselungsalgorithmen für die Antwort (Reihenfolge = Präferenz).
addresses
In der Erstanfrage enthalten; bei Zusatzticket-Anfragen optional. Gibt Adressen an, von denen das angeforderte Ticket gültig sein soll; üblicherweise Client-Host. Bei Proxy andere Adressen. Der KDC kopiert den Inhalt typischerweise nach caddr des Tickets.
additional-tickets
Optional in Anfragen an den Ticketvergabeserver. Bei ENC-TKT-IN-SKEY wird der Session Key aus dem Zusatzticket statt des Server-Schlüssels zur Verschlüsselung des neuen Tickets verwendet. Bei User-to-User darf das Zusatzticket ein lokales TGT oder ein Inter-Realm-TGT für das Realm des aktuellen KDC sein. Mehrere Optionen, die Zusatztickets erfordern: Reihenfolge der Nutzung entspricht der Bit-Reihenfolge in kdc-options (siehe oben).
Die Application-Tag-Nummer ist 10 (AS-REQ) oder 12 (TGS-REQ).
Die optionalen Felder addresses, authorization-data und additional-tickets werden nur aufgenommen, wenn sie für die in kdc-options beschriebene Operation nötig sind.
Hinweis: In KRB_TGS_REQ erscheinen die Protokollversionsnummer und zwei verschiedene Nachrichtentypen doppelt: in KRB_TGS_REQ und im in padata übergebenen Authentifizierungsheader (KRB_AP_REQ).
5.4.2. Definition von KRB_KDC_REP
KRB_KDC_REP formatiert die Antwort des KDC auf eine Erst-(AS)- oder Folge-(TGS)-Anfrage. Es gibt keinen separaten Typ KRB_KDC_REP; vielmehr KRB_AS_REP oder KRB_TGS_REP. Der Schlüssel für den Ciphertext hängt vom Typ ab: Bei KRB_AS_REP Verschlüsselung mit dem Geheimnis des Clients; die Schlüsselversionsnummer des Clients steht in den verschlüsselten Daten. Bei KRB_TGS_REP Verschlüsselung mit dem Subsession Key aus dem Authenticator; fehlt dieser, mit dem Session Key aus dem in der Anfrage verwendeten TGT. Dann entfällt die Versionsnummer in EncryptedData.
Felder von KRB_KDC_REP:
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
padata [2] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
-- EncASRepPart or EncTGSRepPart,
-- as appropriate
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
pvno und msg-type
Wie in Abschnitt 5.4.1. msg-type ist KRB_AS_REP oder KRB_TGS_REP.
padata
Ausführlich in 5.4.1. Mögliche Verwendung: alternativer „salt“-String für String-to-Key, nützlich bei Realm-Umbenennung (z. B. Unternehmensübernahme); bestehende passwortbasierte Einträge können bis zur nächsten Passwortänderung einen Sonder-Salt erfordern.
crealm, cname, srealm und sname
Wie für das Ticket in Abschnitt 5.3.
ticket
Neu ausgestelltes Ticket, siehe Abschnitt 5.3.
enc-part
Platzhalter für Ciphertext und zugehörige Metadaten des verschlüsselten Nachrichtenteils; die genaue Bedeutung folgt jeweils nach diesem Feld.
Key Usage für Verschlüsselung: 3 in AS-REP mit Langzeitschlüssel des Clients oder Schlüssel aus Pre-Auth; in TGS-REP 8 bei TGS-Session-Key, 9 bei Subkey des TGS-Authenticators.
Kompatibilitätshinweis: Manche Implementierungen senden stets verschlüsseltes EncTGSRepPart (Application-Tag 26) auch bei AS-REP. Zur Interoperabilität DÜRFEN Implementierungen die Tag-Prüfung des entschlüsselten ENC-PART lockern.
key
Wie für das Ticket in Abschnitt 5.3.
last-req
Vom KDC zurückgegebene Zeit(en) der letzten Anfrage eines Principals, je nach Verfügbarkeit z. B. letzte TGT-Anfrage, letzte erfolgreiche TGT-basierte Anfrage, realmweit oder nur für einen Server. Implementierungen DÜRFEN dies dem Benutzer anzeigen, um Missbrauch zu erkennen; vergleichbar mit „last login“.
lr-type
Legt fest, wie lr-value zu interpretieren ist. Negative Werte: nur der antwortende Server. Nicht negative: alle Server des Realms.
lr-type 0: lr-value trägt keine Information. Absolutwert 1: Zeit der letzten Erstanfrage nach TGT. 2: Zeit der letzten Erstanfrage. 3: Ausstellungszeit des neuesten verwendeten TGT. 4: Zeit der letzten Erneuerung. 5: Zeit der letzten Anfrage (beliebiger Typ). 6: Zeitpunkt des Passwortablaufs. 7: Zeitpunkt des Kontenablaufs.
lr-value
Zeit der letzten Anfrage; MUSS gemäß begleitendem lr-type interpretiert werden.
nonce
Wie in Abschnitt 5.4.1.
key-expiration
Teil der KDC-Antwort: Zeitpunkt, zu dem der Geheimschlüssel des Clients abläuft (Passwort- oder Kontenalterung). Wenn gesetzt, SOLL das frühere aus Schlüssel- und Kontenablauf gewählt werden. Feld deprecated; stattdessen SOLL last-req verwendet werden. In TGS-Antworten meist weggelassen, da verschlüsselt mit Session Key und keine KDC-Datenbankabfrage nötig. Der Anwendungsclient (z. B. Login) soll bei nahendem Ablauf reagieren (z. B. Hinweis).
flags, authtime, starttime, endtime, renew-till und caddr
Kopien der Felder aus dem verschlüsselten Teil des beigefügten Tickets (Abschnitt 5.3), damit der Client prüfen kann, ob sie zur Anfrage passen und das Caching erleichtert wird. Bei KRB_TGS_REP wird caddr nur gefüllt bei Proxy-, Forwarding-Anfrage oder wenn der Benutzer eine Teilmenge der TGT-Adressen setzt. Fehlen oder werden clientseitig angeforderte Adressen nicht genutzt, entsprechen die Ticket-Adressen denen im TGT.