4. Encryption and Checksum Specifications (Verschlüsselungs- und Prüfsummenspezifikationen)
4. Encryption and Checksum Specifications (Verschlüsselungs- und Prüfsummenspezifikationen)
Die in diesem Dokument beschriebenen Kerberos-Protokolle sind darauf ausgelegt, Nachrichten beliebiger Größe unter Verwendung von Stream- oder Block-Verschlüsselungs-Chiffren zu verschlüsseln. Verschlüsselung wird verwendet, um die Identitäten der an Nachrichtenaustauschen beteiligten Netzwerk-Entitäten zu beweisen. Das Key Distribution Center für jeden Realm wird von allen in diesem Realm registrierten Principals als vertrauenswürdig angesehen, einen geheimen Schlüssel vertraulich zu speichern. Der Nachweis der Kenntnis dieses geheimen Schlüssels wird verwendet, um die Authentizität eines Principals zu verifizieren.
Das KDC verwendet den geheimen Schlüssel des Principals (im AS-Austausch) oder einen gemeinsamen Session Key (im TGS-Austausch), um Antworten auf Ticket-Anfragen zu verschlüsseln; die Fähigkeit, den geheimen Schlüssel oder Session Key zu erhalten, impliziert die Kenntnis der entsprechenden Schlüssel und die Identität des KDC. Die Fähigkeit eines Principals, die KDC-Antwort zu entschlüsseln und ein Ticket sowie einen ordnungsgemäß geformten Authenticator (generiert mit dem Session Key aus der KDC-Antwort) einem Dienst zu präsentieren, verifiziert die Identität des Principals; ebenso verifiziert die Fähigkeit des Dienstes, den Session Key aus dem Ticket zu extrahieren und seine Kenntnis davon in einer Antwort zu beweisen, die Identität des Dienstes.
[RFC3961] definiert ein Framework zur Definition von Verschlüsselungs- und Prüfsummenmechanismen für die Verwendung mit Kerberos. Es definiert auch mehrere solcher Mechanismen, und weitere können in zukünftigen Updates dieses Dokuments hinzugefügt werden.
Die von [RFC3961] bereitgestellte String-to-Key-Operation wird verwendet, um einen langlebigen Schlüssel für einen Principal (im Allgemeinen für einen Benutzer) zu erzeugen. Der Standard-Salt-String, falls keiner über Pre-Authentication-Daten bereitgestellt wird, ist die Verkettung des Realms und der Namenskomponenten des Principals in Reihenfolge ohne Trennzeichen. Sofern nicht anders angegeben, wird der in [RFC3961] definierte Standard-String-to-Key-opaque-Parameter verwendet.
Verschlüsselte Daten, Schlüssel und Prüfsummen werden unter Verwendung der in Abschnitt 5.2.9 definierten EncryptedData-, EncryptionKey- und Checksum-Datenobjekte übertragen. Die in diesem Dokument beschriebenen Verschlüsselungs-, Entschlüsselungs- und Prüfsummenoperationen verwenden die entsprechenden in [RFC3961] beschriebenen Verschlüsselungs-, Entschlüsselungs- und get_mic-Operationen mit impliziter "spezifischer Schlüssel"-Generierung unter Verwendung der "Key Usage"-Werte, die in der Beschreibung jedes EncryptedData- oder Checksum-Objekts angegeben sind, um den Schlüssel für jede Operation zu variieren. Beachten Sie, dass in einigen Fällen der zu verwendende Wert von der Methode der Schlüsselauswahl oder dem Kontext der Nachricht abhängig ist.
Key Usages sind vorzeichenlose 32-Bit-Ganzzahlen; Null ist nicht erlaubt. Die Key-Usage-Werte für die Verschlüsselung oder Prüfsummenbildung von Kerberos-Nachrichten werden in Abschnitt 5 zusammen mit den Nachrichtendefinitionen angegeben. Die Key-Usage-Werte 512-1023 sind für interne Verwendungen einer Kerberos-Implementierung reserviert. (Beispielsweise das Seeding eines Pseudo-Zufallszahlengenerators mit einem Wert, der durch Verschlüsselung von etwas mit einem Session Key und einem Key-Usage-Wert erzeugt wird, der für keinen anderen Zweck verwendet wird.) Key-Usage-Werte zwischen 1024 und 2047 (einschließlich) sind für Anwendungszwecke reserviert; Anwendungen SOLLTEN gerade Werte für Verschlüsselung und ungerade Werte für Prüfsummen in diesem Bereich verwenden. Key-Usage-Werte sind auch in einer Tabelle in Abschnitt 7.5.1 zusammengefasst.
Es könnten andere Dokumente existieren, die Protokolle in Bezug auf die RFC 1510-Verschlüsselungstypen oder Prüfsummentypen definieren. Diese Dokumente würden nichts über Key Usages wissen. Damit diese Spezifikationen weiterhin sinnvoll bleiben, bis sie aktualisiert werden, müssen, wenn keine Key-Usage-Werte angegeben sind, die Key Usages 1024 und 1025 verwendet werden, um Schlüssel für Verschlüsselung bzw. Prüfsummen abzuleiten. (Dies gilt nicht für Protokolle, die ihre eigene Verschlüsselung unabhängig von diesem Framework durchführen, indem sie direkt den aus dem Kerberos-Authentifizierungsaustausch resultierenden Schlüssel verwenden.) Neue Protokolle, die in Bezug auf die Kerberos-Verschlüsselungs- und Prüfsummentypen definiert werden, SOLLTEN ihre eigenen Key-Usage-Werte verwenden.
Sofern nicht anders angegeben, wird keine Cipher-State-Verkettung von einer Verschlüsselungsoperation zur nächsten durchgeführt.
Implementierungshinweis: Obwohl es nicht empfohlen wird, werden einige Anwendungsprotokolle weiterhin die Schlüsseldaten direkt verwenden, selbst wenn dies nur in derzeit existierenden Protokollspezifikationen der Fall ist. Eine Implementierung, die allgemeine Kerberos-Anwendungen unterstützen soll, muss daher möglicherweise Schlüsseldaten verfügbar machen sowie die in [RFC3961] beschriebenen Attribute und Operationen. Einer der häufigeren Gründe für die direkte Durchführung von Verschlüsselung ist die direkte Kontrolle über die Verhandlung und Auswahl eines "ausreichend starken" Verschlüsselungsalgorithmus (im Kontext einer gegebenen Anwendung). Obwohl Kerberos keine Einrichtung zur Verhandlung von Verschlüsselungstypen zwischen dem Anwendungs-Client und -Server direkt bereitstellt, gibt es Ansätze zur Verwendung von Kerberos, um diese Verhandlung zu erleichtern. Beispielsweise kann ein Client nur "ausreichend starke" Session-Key-Typen vom KDC anfordern und erwarten, dass jeder vom KDC zurückgegebene Typ vom Anwendungsserver verstanden und unterstützt wird.