Zum Hauptinhalt springen

5.5. Client/Server (CS) Message Specifications (Client/Server-Nachrichtenspezifikationen)

5.5. Client/Server (CS) Message Specifications (Client/Server-Nachrichtenspezifikationen)​

Dieser Abschnitt spezifiziert das Format der Nachrichten zur Authentifizierung des Clients gegenüber dem Anwendungsserver.

5.5.1. Definition von KRB_AP_REQ​

Die KRB_AP_REQ-Nachricht enthält die Kerberos-Protokollversionsnummer, den Nachrichtentyp KRB_AP_REQ, ein Optionsfeld für aktive Optionen sowie Ticket und Authenticator. KRB_AP_REQ wird oft „authentication header“ genannt.

   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (14),
           ap-options      [2] APOptions,
           ticket          [3] Ticket,
           authenticator   [4] EncryptedData -- Authenticator
   }
   APOptions       ::= KerberosFlags
           -- reserved(0),
           -- use-session-key(1),
           -- mutual-required(2)

pvno und msg-type

Wie in Abschnitt 5.4.1 beschrieben. msg-type ist KRB_AP_REQ.

ap-options

Dieses Feld steht in der Anwendungsanfrage (KRB_AP_REQ) und beeinflusst die Verarbeitung. Es ist ein Bitfeld: gesetztes Bit (1) bedeutet gewählte Option, zurückgesetzte Bits (0) nicht gewählte oder reservierte Felder. Die Bitkodierung ist in Abschnitt 5.2 festgelegt. Bedeutung:

Bit(s) Name Beschreibung

0 reserved Für künftige Erweiterungen reserviert.

1 use-session-key USE-SESSION-KEY bedeutet, dass das vom Client vorgelegte Ticket mit dem Session Key aus dem TGT des Servers verschlüsselt ist. Ist die Option nicht gesetzt, ist das Ticket mit dem Geheimnis des Servers verschlüsselt.

2 mutual-required MUTUAL-REQUIRED teilt dem Server mit, dass der Client gegenseitige Authentifizierung verlangt und der Server mit KRB_AP_REP antworten muss.

3-31 reserved Für künftige Verwendung reserviert.

ticket

Ticket, mit dem sich der Client gegenüber dem Server authentifiziert.

authenticator

Enthält den verschlüsselten Authenticator einschließlich der Subkey-Wahl des Clients.

Der verschlüsselte Authenticator im AP-REQ belegt dem Server, dass der Sender aktuelle Kenntnis des Schlüssels im begleitenden Ticket hat, und hilft bei Replay-Erkennung sowie bei der Wahl eines „echten“ Session Keys für die Sitzung. Die DER-Kodierung der folgenden Struktur wird mit dem Session Key des Tickets verschlüsselt: Key Usage 11 in normalen Anwendungsaustauschen, oder 7 wenn als PA-TGS-REQ PA-DATA in einem TGS-REQ (siehe Abschnitt 5.4.1):

   -- Unencrypted authenticator
   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
           authenticator-vno       [0] INTEGER (5),
           crealm                  [1] Realm,
           cname                   [2] PrincipalName,
           cksum                   [3] Checksum OPTIONAL,
           cusec                   [4] Microseconds,
           ctime                   [5] KerberosTime,
           subkey                  [6] EncryptionKey OPTIONAL,
           seq-number              [7] UInt32 OPTIONAL,
           authorization-data      [8] AuthorizationData OPTIONAL
   }

authenticator-vno

Versionsnummer des Authenticator-Formats. Dieses Dokument spezifiziert Version 5.

crealm und cname

Wie für das Ticket in Abschnitt 5.3 beschrieben.

cksum

Prüfsumme über die zum KRB_AP_REQ gehörenden Anwendungsdaten: Key Usage 10 in normalen Anwendungsaustauschen, oder 6 im PA-TGS-REQ des TGS-REQ.

cusec

Mikrosekundenteil des Client-Zeitstempels (vor Verschlüsselung 0 bis 999999). Erscheint oft zusammen mit ctime; beide bilden einen hinreichend genauen Zeitstempel.

ctime

Aktuelle Zeit auf dem Host des Clients.

subkey

Vom Client gewählter Verschlüsselungsschlüssel für diese Anwendungssitzung. Sofern die Anwendung nichts anderes vorsieht und das Feld fehlt, gilt der Session Key aus dem Ticket.

seq-number

Optionales Anfangs-Sequenznummernfeld für KRB_PRIV oder KRB_SAFE bei Sequenznummern zum Replay-Schutz (auch anwendungsspezifisch nutzbar). Im Authenticator: Anfangssequenz für Nachrichten vom Client zum Server. Im AP-REP: Anfangssequenz vom Server zum Client. In KRB_PRIV/KRB_SAFE wird nach jeder gesendeten Nachricht um eins erhöht. Sequenznummern liegen in 0 .. 2^32 - 1 und wickeln nach 2^32 - 1 auf 0.

Damit Sequenznummern Replays zuverlässig erkennen, SOLLTEN sie sich nicht wiederholen, auch nicht über Verbindungsgrenzen hinweg. Die Anfangssequenz SOLLTE zufällig und gleichverteilt im gesamten Wertebereich sein, damit sie nicht erratbar ist und andere Sequenzen nicht wiederholt. Werden mehr als 2^32 Nachrichten in einer KRB_PRIV-/KRB_SAFE-Serie geplant, SOLLTE vor Wiederverwendung von Sequenznummern mit demselben Schlüssel ein Rekeying erfolgen.

Implementierungshinweis: Historisch senden manche Implementierungen vorzeichenbehaftete Zweierkomplement-Sequenznummern. Zur Kompatibilität DÜRFEN Implementierungen die äquivalente negative Zahl akzeptieren, wenn eine positive Zahl größer 2^31 - 1 erwartet wird.

Implementierungshinweis: Wie erwähnt, lassen manche Implementierungen die optionale Sequenznummer weg, wenn ihr Wert null wäre. Implementierungen DÜRFEN eine fehlende Sequenznummer als Null interpretieren und SOLLTEN keinen Authenticator mit Anfangssequenz null senden.

authorization-data

Wie für das Ticket in Abschnitt 5.3 beschrieben. Optional; nur wenn über die im Ticket selbst enthaltenen Einschränkungen hinaus weitere gelten sollen.

5.5.2. Definition von KRB_AP_REP​

Die KRB_AP_REP-Nachricht enthält die Kerberos-Protokollversionsnummer, den Nachrichtentyp und einen verschlüsselten Zeitstempel. Sie wird als Antwort auf KRB_AP_REQ gesendet, wenn in ap-options gegenseitige Authentifizierung verlangt wurde.

   AP-REP          ::= [APPLICATION 15] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (15),
           enc-part        [2] EncryptedData -- EncAPRepPart
   }
   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
           ctime           [0] KerberosTime,
           cusec           [1] Microseconds,
           subkey          [2] EncryptionKey OPTIONAL,
           seq-number      [3] UInt32 OPTIONAL
   }

Die kodierte EncAPRepPart wird mit dem gemeinsamen Session Key des Tickets verschlüsselt. Das optionale subkey-Feld kann bei anwendungsgesteuerter Aushandlung einen pro Assoziation gültigen Session Key festlegen.

pvno und msg-type

Wie in Abschnitt 5.4.1 beschrieben. msg-type ist KRB_AP_REP.

enc-part

Wie in Abschnitt 5.4.2 beschrieben; Key Usage 12.

ctime

Aktuelle Zeit auf dem Host des Clients.

cusec

Mikrosekundenteil des Client-Zeitstempels.

subkey

Verschlüsselungsschlüssel für diese Anwendungssitzung. Details zur Schlüsselaushandlung siehe Abschnitt 3.2.6. Sofern die Anwendung nichts anderes vorsieht: Fehlt das Feld, gilt der Subsession Key aus dem Authenticator; fehlt auch dieser, der Session Key aus dem Ticket.

seq-number

Wie oben in Abschnitt 5.3.2 beschrieben.

5.5.3. Fehlerantwort​

Tritt bei der Verarbeitung der Anwendungsanfrage ein Fehler auf, wird als Antwort KRB_ERROR gesendet. Format siehe Abschnitt 5.9.1. Die Felder cname und crealm DÜRFEN entfallen, wenn der Server sie aus der zugehörigen KRB_AP_REQ nicht bestimmen kann. War der Authenticator entschlüsselbar, enthalten ctime und cusec die Werte daraus.

Letztes Update am