3.1. The Authentication Service Exchange (Der Authentication Service-Austausch)

Zusammenfassung

Nachrichtenrichtung	Nachrichtentyp	Abschnitt
1. Client zu Kerberos	`KRB_AS_REQ`	5.4.1
2. Kerberos zu Client	`KRB_AS_REP` oder `KRB_ERROR`	5.4.2, 5.9.1

Der Authentication Service (AS)-Austausch zwischen dem Client und dem Kerberos Authentication Server wird von einem Client initiiert, wenn er Authentifizierungs-Credentials für einen bestimmten Server erhalten möchte, aber derzeit keine Credentials besitzt. In seiner Grundform wird der geheime Schlüssel des Clients für Verschlüsselung und Entschlüsselung verwendet. Dieser Austausch wird typischerweise bei der Initiierung einer Login-Sitzung verwendet, um Credentials für einen Ticket-Granting Server zu erhalten, die anschließend verwendet werden, um Credentials für andere Server zu erhalten (siehe Abschnitt 3.3), ohne dass der geheime Schlüssel des Clients weiter verwendet werden muss. Dieser Austausch wird auch verwendet, um Credentials für Dienste anzufordern, die nicht durch den Ticket-Granting Service vermittelt werden dürfen, sondern vielmehr Kenntnis des geheimen Schlüssels eines Principals erfordern, wie z.B. der Passwort-Änderungsdienst (der Passwort-Änderungsdienst lehnt Anfragen ab, es sei denn, der Anfragende kann nachweisen, dass er das alte Passwort des Benutzers kennt; diese Kenntnisanforderung verhindert unbefugte Passwortänderungen durch jemanden, der zu einer unbeaufsichtigten Sitzung geht).

Dieser Austausch bietet für sich allein keine Gewähr für die Identität des Benutzers. Um einen Benutzer zu authentifizieren, der sich bei einem lokalen System anmeldet, können die im AS-Austausch erhaltenen Credentials zunächst in einem TGS-Austausch verwendet werden, um Credentials für einen lokalen Server zu erhalten; diese Credentials müssen dann von einem lokalen Server durch erfolgreichen Abschluss des Client/Server-Austauschs verifiziert werden.

Der AS-Austausch besteht aus zwei Nachrichten: KRB_AS_REQ vom Client zu Kerberos und KRB_AS_REP oder KRB_ERROR als Antwort. Die Formate für diese Nachrichten sind in den Abschnitten 5.4.1, 5.4.2 und 5.9.1 beschrieben.

In der KRB_AS_REQ-Nachricht identifiziert der Client den Server, für den er Credentials wünscht. Die Antwort enthält ein Ticket für den Server (verschlüsselt mit dem Langzeitschlüssel des Servers, so dass der Client es nicht lesen oder ändern kann) und Credentials, die mit dem Langzeitschlüssel des Clients verschlüsselt sind, so dass nur der Client in der Lage ist, die Credentials zu entschlüsseln. Die Credentials enthalten den vom KDC generierten Session Key, der von Client und Server geteilt werden soll, zusammen mit anderen Informationen. Um den Session Key zu erhalten, muss der Client seinen geheimen Schlüssel verwenden, um die Credentials zu entschlüsseln.

3.1.1. [Generation of KRB_AS_REQ Message (Generierung der KRB_AS_REQ-Nachricht)]

Der Client kann eine Reihe von Optionen in der anfänglichen Anfrage angeben. Zu diesen Optionen gehören, ob Vorauthentifizierung durchgeführt werden soll; ob das angeforderte Ticket erneuerbar, proxy-fähig oder weiterleitbar sein soll; ob es postdatiert werden sollte oder das Postdatieren von abgeleiteten Tickets erlauben sollte; und ob ein erneuerbares Ticket anstelle eines nicht erneuerbaren Tickets akzeptiert wird, wenn das angeforderte Ticket-Ablaufdatum aufgrund von Konfigurationsbeschränkungen nicht durch ein nicht erneuerbares Ticket erfüllt werden kann.

Der Client bereitet die KRB_AS_REQ-Nachricht vor und sendet sie an den KDC.

3.1.2. [Receipt of KRB_AS_REQ Message (Empfang der KRB_AS_REQ-Nachricht)]

Wenn alles gut läuft, führt die Verarbeitung der KRB_AS_REQ-Nachricht zur Erstellung eines Tickets für den Client, das er dem Server präsentieren kann. Das Format für das Ticket ist in Abschnitt 5.3 beschrieben.

Da Kerberos über unzuverlässige Transporte wie UDP laufen kann, MUSS der KDC darauf vorbereitet sein, Antworten im Falle eines Verlusts erneut zu übertragen. Wenn ein KDC eine Anfrage erhält, die mit einer kürzlich erfolgreich verarbeiteten identisch ist, MUSS der KDC mit einer KRB_AS_REP-Nachricht antworten und nicht mit einem Replay-Fehler. Um dem Ciphertext, der einem potenziellen Angreifer gegeben wird, zu reduzieren, KÖNNEN KDCs die gleiche Antwort senden, die generiert wurde, als die Anfrage zum ersten Mal bearbeitet wurde. KDCs MÜSSEN dieses Replay-Verhalten befolgen, auch wenn der tatsächlich verwendete Transport zuverlässig ist.

3.1.3. [Generation of KRB_AS_REP Message (Generierung der KRB_AS_REP-Nachricht)]

Der Authentifizierungsserver schlägt die in der KRB_AS_REQ benannten Client- und Server-Principals in seiner Datenbank nach und extrahiert ihre jeweiligen Schlüssel. Wenn der angeforderte Client-Principal, der in der Anfrage genannt ist, unbekannt ist, weil er nicht in der Principal-Datenbank des KDC existiert, wird eine Fehlermeldung mit KDC_ERR_C_PRINCIPAL_UNKNOWN zurückgegeben.

Wenn erforderlich, führt der Server eine Vorauthentifizierung der Anfrage durch, und wenn die Vorauthentifizierungsprüfung fehlschlägt, wird eine Fehlermeldung mit dem Code KDC_ERR_PREAUTH_FAILED zurückgegeben. Wenn Vorauthentifizierung erforderlich ist, aber in der Anfrage nicht vorhanden war, wird eine Fehlermeldung mit dem Code KDC_ERR_PREAUTH_REQUIRED zurückgegeben, und ein METHOD-DATA-Objekt wird im e-data-Feld der KRB-ERROR-Nachricht gespeichert, um anzugeben, welche Vorauthentifizierungsmechanismen akzeptabel sind. Normalerweise wird dies PA-ETYPE-INFO- und/oder PA-ETYPE-INFO2-Elemente enthalten, wie unten beschrieben. Wenn der Server keinen vom Client angeforderten Verschlüsselungstyp unterstützen kann, wird eine Fehlermeldung mit dem Code KDC_ERR_ETYPE_NOSUPP zurückgegeben. Andernfalls generiert der KDC einen 'zufälligen' Session Key, was bedeutet, dass es unter anderem unmöglich sein sollte, den nächsten Session Key basierend auf der Kenntnis vergangener Session Keys zu erraten. Obwohl dies in einem Pseudo-Zufallszahlengenerator erreicht werden kann, wenn er auf kryptographischen Prinzipien basiert, ist es wünschenswerter, einen wirklich zufälligen Zahlengenerator zu verwenden, wie einen, der auf Messungen zufälliger physikalischer Phänomene basiert. Siehe [RFC4086] für eine eingehende Diskussion über Zufälligkeit.

Als Antwort auf eine AS-Anfrage, wenn mehrere Verschlüsselungsschlüssel für einen Client in der Kerberos-Datenbank registriert sind, wird das etype-Feld aus der AS-Anfrage vom KDC verwendet, um die Verschlüsselungsmethode auszuwählen, die zum Schutz des verschlüsselten Teils der KRB_AS_REP-Nachricht verwendet wird, die an den Client gesendet wird. Wenn mehr als ein unterstützter starker Verschlüsselungstyp in der etype-Liste vorhanden ist, SOLLTE der KDC den ersten gültigen starken Etype verwenden, für den ein Verschlüsselungsschlüssel verfügbar ist.

Wenn der Schlüssel des Benutzers aus einem Passwort oder einer Passphrase generiert wird, wird die String-to-Key-Funktion für den bestimmten Verschlüsselungsschlüsseltyp verwendet, wie in [RFC3961] spezifiziert. Der Salt-Wert und zusätzliche Parameter für die String-to-Key-Funktion haben Standardwerte (spezifiziert durch Abschnitt 4 und durch die Verschlüsselungsmechanismus-Spezifikation), die durch Vorauthentifizierungsdaten überschrieben werden können (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc.). Da angenommen wird, dass der KDC nur eine Kopie des resultierenden Schlüssels speichert, sollten diese Werte für passwortbasierte Schlüssel nicht geändert werden, außer beim Ändern des Schlüssels des Principals.

Wenn der AS-Server Vorauthentifizierungsdaten in einen KRB-ERROR oder in einen AS-REP einfügen soll, MUSS er PA-ETYPE-INFO2 verwenden, nicht PA-ETYPE-INFO, wenn das etype-Feld der AS-REQ des Clients mindestens einen "neueren" Verschlüsselungstyp auflistet. Andernfalls (wenn das etype-Feld der AS-REQ des Clients keine "neueren" Verschlüsselungstypen auflistet), MUSS er sowohl PA-ETYPE-INFO2 als auch PA-ETYPE-INFO senden (beide mit einem Eintrag für jeden Enctype). Ein "neuerer" Enctype ist jeder Enctype, der zum ersten Mal offiziell gleichzeitig mit oder nach der Veröffentlichung dieses RFC spezifiziert wurde. Die Enctypes DES, 3DES oder RC4 und alle in [RFC1510] definierten sind keine "neueren" Enctypes.

Es ist nicht möglich, den Schlüssel eines Benutzers zuverlässig zu generieren, wenn eine Passphrase gegeben ist, ohne den KDC zu kontaktieren, da nicht bekannt sein wird, ob alternative Salt- oder Parameterwerte erforderlich sind.

Der KDC wird versuchen, den Typ des zufälligen Session Key aus der Liste der Methoden im etype-Feld zuzuweisen. Der KDC wird den geeigneten Typ unter Verwendung der Liste der bereitgestellten Methoden und Informationen aus der Kerberos-Datenbank auswählen, die akzeptable Verschlüsselungsmethoden für den Anwendungsserver anzeigen. Der KDC wird keine Tickets mit einem schwachen Session Key-Verschlüsselungstyp ausstellen.

Wenn die angeforderte Startzeit fehlt, eine Zeit in der Vergangenheit anzeigt oder innerhalb des Fensters der akzeptablen Uhrzeit-Skew für den KDC liegt und die POSTDATE-Option nicht angegeben wurde, wird die Startzeit des Tickets auf die aktuelle Zeit des Authentifizierungsservers gesetzt. Wenn sie eine Zeit in der Zukunft jenseits der akzeptablen Uhrzeit-Skew anzeigt, aber die POSTDATED-Option nicht angegeben wurde, wird der Fehler KDC_ERR_CANNOT_POSTDATE zurückgegeben. Andernfalls wird die angeforderte Startzeit gegen die Richtlinie des lokalen Realms geprüft (der Administrator könnte entscheiden, bestimmte Arten oder Bereiche von postdatierten Tickets zu verbieten), und wenn die Startzeit des Tickets akzeptabel ist, wird sie wie angefordert gesetzt, und das INVALID-Flag wird im neuen Ticket gesetzt. Das postdatierte Ticket MUSS vor der Verwendung validiert werden, indem es dem KDC nach Erreichen der Startzeit präsentiert wird.

Die Ablaufzeit des Tickets wird auf die frühere der angeforderten Endzeit und einer durch lokale Richtlinien bestimmten Zeit gesetzt, möglicherweise unter Verwendung realm- oder principal-spezifischer Faktoren. Beispielsweise KANN die Ablaufzeit auf die früheste der folgenden gesetzt werden:

Die in der KRB_AS_REQ-Nachricht angeforderte Ablaufzeit (endtime).
Die Startzeit des Tickets plus die maximal zulässige Lebensdauer, die mit dem Client-Principal aus der Datenbank des Authentifizierungsservers verbunden ist.
Die Startzeit des Tickets plus die maximal zulässige Lebensdauer, die mit dem Server-Principal verbunden ist.
Die Startzeit des Tickets plus die maximale Lebensdauer, die durch die Richtlinie des lokalen Realms festgelegt ist.

Wenn die angeforderte Ablaufzeit minus die Startzeit (wie oben bestimmt) kleiner als eine standortbestimmte Mindestlebensdauer ist, wird eine Fehlermeldung mit dem Code KDC_ERR_NEVER_VALID zurückgegeben. Wenn die angeforderte Ablaufzeit für das Ticket das überschreitet, was wie oben bestimmt wurde, und wenn die 'RENEWABLE-OK'-Option angefordert wurde, wird das 'RENEWABLE'-Flag im neuen Ticket gesetzt, und der renew-till-Wert wird gesetzt, als ob die 'RENEWABLE'-Option angefordert worden wäre (die Feld- und Optionsnamen werden vollständig in Abschnitt 5.4.1 beschrieben).

Wenn die RENEWABLE-Option angefordert wurde oder wenn die RENEWABLE-OK-Option gesetzt wurde und ein erneuerbares Ticket ausgestellt werden soll, KANN das renew-till-Feld auf die früheste der folgenden gesetzt werden:

Sein angeforderter Wert.
Die Startzeit des Tickets plus dem Minimum der beiden maximalen erneuerbaren Lebensdauern, die mit den Datenbankeinträgen der Principals verbunden sind.
Die Startzeit des Tickets plus der maximalen erneuerbaren Lebensdauer, die durch die Richtlinie des lokalen Realms festgelegt ist.

Das Flags-Feld des neuen Tickets wird die folgenden Optionen gesetzt haben, wenn sie angefordert wurden und wenn die Richtlinie des lokalen Realms es erlaubt: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. Wenn das neue Ticket postdatiert ist (die Startzeit liegt in der Zukunft), wird auch sein INVALID-Flag gesetzt.

Wenn all das oben Genannte erfolgreich ist, verschlüsselt der Server den Ciphertext-Teil des Tickets unter Verwendung des Verschlüsselungsschlüssels, der aus dem Datensatz des Server-Principals in der Kerberos-Datenbank extrahiert wurde, unter Verwendung des Verschlüsselungstyps, der mit dem Schlüssel des Server-Principals verbunden ist. (Diese Wahl wird NICHT durch das etype-Feld in der Anfrage beeinflusst.) Er formatiert dann eine KRB_AS_REP-Nachricht (siehe Abschnitt 5.4.2), kopiert die Adressen in der Anfrage in das caddr der Antwort, platziert alle erforderlichen Vorauthentifizierungsdaten in das padata der Antwort und verschlüsselt den Ciphertext-Teil mit dem Schlüssel des Clients unter Verwendung einer akzeptablen Verschlüsselungsmethode, die im etype-Feld der Anfrage angefordert wurde, oder in einem Schlüssel, der durch verwendete Vorauthentifizierungsmechanismen spezifiziert ist.

3.1.4. [Generation of KRB_ERROR Message (Generierung der KRB_ERROR-Nachricht)]

Es können mehrere Fehler auftreten, und der Authentifizierungsserver antwortet durch Rückgabe einer Fehlermeldung, KRB_ERROR, an den Client, wobei die Felder error-code und e-text auf entsprechende Werte gesetzt werden. Der Inhalt und die Details der Fehlermeldung sind in Abschnitt 5.9.1 beschrieben.

3.1.5. [Receipt of KRB_AS_REP Message (Empfang der KRB_AS_REP-Nachricht)]

Wenn der Antwort-Nachrichtentyp KRB_AS_REP ist, überprüft der Client, dass die Felder cname und crealm im Klartext-Teil der Antwort mit dem übereinstimmen, was er angefordert hat. Wenn padata-Felder vorhanden sind, können sie verwendet werden, um den richtigen geheimen Schlüssel zur Entschlüsselung der Nachricht abzuleiten. Der Client entschlüsselt den verschlüsselten Teil der Antwort unter Verwendung seines geheimen Schlüssels und überprüft, dass die Nonce im verschlüsselten Teil mit der Nonce übereinstimmt, die er in seiner Anfrage geliefert hat (um Replays zu erkennen). Er überprüft auch, dass sname und srealm in der Antwort mit denen in der Anfrage übereinstimmen (oder anderweitig erwartete Werte sind) und dass das Host-Adressfeld ebenfalls korrekt ist. Dann speichert er das Ticket, den Session Key, die Start- und Ablaufzeiten und andere Informationen für die spätere Verwendung. Das Feld last-req (und das veraltete Feld key-expiration) aus dem verschlüsselten Teil der Antwort KANN überprüft werden, um den Benutzer über das bevorstehende Ablaufen des Schlüssels zu informieren. Dies ermöglicht es dem Client-Programm, Abhilfemaßnahmen wie eine Passwortänderung vorzuschlagen.

Nach der Validierung der KRB_AS_REP-Nachricht (durch Überprüfung der zurückgegebenen Nonce gegen die in der KRB_AS_REQ-Nachricht gesendete) weiß der Client, dass die aktuelle Zeit auf dem KDC die ist, die aus dem authtime-Feld des verschlüsselten Teils der Antwort gelesen wurde. Der Client kann optional diesen Wert für die Uhrsynchronisation in nachfolgenden Nachrichten verwenden, indem er mit dem Ticket die Differenz (Offset) zwischen dem authtime-Wert und der lokalen Uhr aufzeichnet. Dieser Offset kann dann vom gleichen Benutzer verwendet werden, um die Zeit anzupassen, die von der Systemuhr gelesen wird, wenn Nachrichten generiert werden [DGT96].

Diese Technik MUSS verwendet werden, wenn für Uhrzeit-Skew angepasst wird, anstatt die Systemuhr direkt zu ändern, da die KDC-Antwort nur für den Benutzer authentifiziert ist, dessen geheimer Schlüssel verwendet wurde, aber nicht für das System oder die Workstation. Wenn die Uhr angepasst würde, könnten ein Angreifer und ein Benutzer, der sich bei einer Workstation anmeldet, sich auf ein Passwort einigen, was zu einer KDC-Antwort führen würde, die korrekt validiert würde, obwohl sie nicht von einem von der Workstation vertrauenswürdigen KDC stammt.

Die ordnungsgemäße Entschlüsselung der KRB_AS_REP-Nachricht ist nicht ausreichend für den Host, um die Identität des Benutzers zu verifizieren; der Benutzer und ein Angreifer könnten zusammenarbeiten, um eine Nachricht im KRB_AS_REP-Format zu generieren, die ordnungsgemäß entschlüsselt, aber nicht vom richtigen KDC stammt. Wenn der Host die Identität des Benutzers verifizieren möchte, MUSS er vom Benutzer verlangen, Anwendungs-Credentials zu präsentieren, die unter Verwendung eines sicher gespeicherten geheimen Schlüssels für den Host verifiziert werden können. Wenn diese Credentials verifiziert werden können, kann die Identität des Benutzers sichergestellt werden.

3.1.6. [Receipt of KRB_ERROR Message (Empfang der KRB_ERROR-Nachricht)]

Wenn der Antwort-Nachrichtentyp KRB_ERROR ist, interpretiert der Client ihn als Fehler und führt alle anwendungsspezifischen Aufgaben durch, die für die Wiederherstellung notwendig sind.