8.4.3. SRA - Secure RPC Authentication

Bei den meisten Implementierungen von Telnet und FTP erfolgt die Authentifizierung der Nutzer auf der Basis eines im Klartext übertragenen Paßworts, so daß ein Angreifer durch Abhören des Netzes sehr leicht in den Besitz fremder Paßwörter gelangen kann. Dieser Zustand ist vielfach inakzeptabel, da die Authentifizierungsinformationen in der Regel längere Zeit gültig sind und deshalb in einer Replay-Attacke erfolgreich verwendet werden können.

Um diesem Problem zu begegnen, wurden verschiedene, unterschiedlich komplexe Erweiterungen des Telnet- und FTP-Protokolls vorgeschlagen, die je nach Verfahren eine sichere Authentifizierung sowie ggf. zusätzlich die Integrität und Vertraulichkeit aller ausgetauschten Informationen gewährleisten.

Einer dieser Vorschläge ist SRA. Er wurde von David R. Safford, David K. Hess und Douglas Lee Shales in dem Paper Secure RPC Authentication (SRA) for Telnet und FTP [ftp://ftp.cert.dfn.de/pub/docs/net/sra.ps.gz] beschrieben und auch praktisch implementiert. SRA basiert auf Techniken, die beim Secure RPC von Sun (s. RFC 1057) verwendet werden, woher auch der Name kommt.

Obwohl SRA bisher nur im Zusammenhang mit Telnet und FTP eine praktische Bedeutung erlangt hat, wäre dieses Verfahren prinzipiell auch für andere Protokolle nutzbar, z.B. bei HTTP an Stelle der Basic-Authentifizierung, bei der ja bekanntlich das Nutzerpaßwort im Klartext (wenn auch gemäß MIME-Base64 kodiert) übertragen wird.

Die Grundidee von SRA ist schnell erläutert. Zu Beginn jeder Verbindung wird mittels des Diffie-Hellman-Protokolls ein Sitzungsschlüssel ausgetauscht, wobei jeder Partner pro Sitzung ein neues Paar aus privatem und öffentlichem Schlüssel zufällig erzeugt. Mit dem Sitzungsschlüssel werden nachfolgend die für die Authentifizierung relevanten Informationen (bei SRA-Telnet und SRA-FTP konkret das Nutzerkennzeichen sowie das Paßwort) unter Verwendung von DES verschlüsselt. Einige SRA-Telnet-Implementierungen nutzen den Sitzungsschlüssel zusätzlich zur Chiffrierung des gesamten Datenstroms.

SRA hat verschiedene Vorteile:

Die in einem Beispiel-Dialog des Abschnitts 6.2.2 gezeigten Zeilen

SENT IAC SB AUTHENTICATION IS 6 CLIENT|ONE-WAY KEY  99 50 97 101 98 101 49 56 
    55 55 98 99 57 48 55 49 57 53 56 57 56 97 53 48 102 53 48 50 52 48 49 102
    97 101 50 52 102 51 49 97 48 49 55 99 97 99 102 98
sowie
RCVD IAC SB AUTHENTICATION REPLY 6 CLIENT|ONE-WAY KEY  51 54 57 50 54 99 54
     55 48 56 98 52 53 55 52 101 99 97 49 98 100 98 48 52 99 99 53 101 51
     56 53 52 49 56 97 51 48 100 101 49 97 101 101 50 49 99 100 53
enthalten die öffentlichen Diffie-Hellman-Schlüssel. Der obere gehört dem Telnet-Klienten, der untere dem Server. Beide sind wegen des 192-Bit-Moduls intern 24 Byte lang. Da es bei Telnet nicht möglich bzw. ratsam ist, beliebige 8-Bit-Daten zu übertragen, werden die Keys mit 48 ASCII-Zeichen kodiert, und zwar halbbyteweise. Den 16 möglichen Werten jeder Tetrade ordnet man die ASCII-Zeichen 0 bis 9 und a bis f zu. So entstehen z.B. aus dem Byte mit dem hexadezimalen Wert 8F die Zeichen 8 und F. In der obigen Ausgabe sehen wir allerdings nicht diese ASCII-Zeichen, sondern deren Dezimalwerte (99 für c, 50 für 2 usw.).


Frage 8.4.3.1:

Welchen Sinn hat es, die Diffie-Hellman-Keys für jede Verbindung zufällig zu wählen? Wie könnte man den dadurch erreichten Effekt auch mit über längere Zeit konstanten Schlüsselpaaren erzielen?


Als Nachteile von SRA wären zu nennen:

Implementierungen von SRA-Telnet und SRA-FTP finden Sie z.B. auf dem FTP-Server des CERT unter ftp://ftp.cert.dfn.de/pub/tools/net/sra/TUC. Bei den mit tucif- beginnenden Paketen handelt es sich um eine an der TU Chemnitz modifizierte und dort auch praktisch genutzte Implementierung von SRA-Telnet bzw. -FTP. Sie ersetzt auf verschiedenen Plattformen die vom Hersteller gelieferten Klienten und Server.

Neben dem SRA-typischen Schutz der Authentifizierungsinformationen bietet tucif-esra-Telnet zusätzlich die Verschlüsselung der kompletten Sitzung auf der Basis von DES und ab Version 1.4 zusätzlich auch von IDEA. Die Nutzung des IDEA an Stelle von DES bringt vermutlich keinen Sicherheitsgewinn, da nicht DES, sondern das konkret eingesetzte Diffie-Hellman-System mit seinem zu kurzen Modul das schwächste Glied der Kette sein dürfte.

Auf Grund der zeichenorientierten Arbeitsweise von Telnet kommt einer der Modi 64-Bit CFB (Cipher Feedback) oder 64-Bit OFB (Output Feedback) zur Anwendung, wobei CFB den Default-Modus darstellt.

Im C-Quelltext findet sich folgender Kommentar zur Arbeitsweise des 64-Bit CFB:

/*
 * DES 64 bit Cipher Feedback
 *
 *     key --->+-----+
 *          +->| DES |--+
 *          |  +-----+  |
 *          |           v
 *  INPUT --(--------->(+)+---> DATA
 *          |             |
 *          +-------------+
 *
 *
 * Given:
 *      iV: Initial vector, 64 bits (8 bytes) long.
 *      Dn: the nth chunk of 64 bits (8 bytes) of data to encrypt (decrypt).
 *      On: the nth chunk of 64 bits (8 bytes) of encrypted (decrypted) output.
 *
 *      V0 = DES(iV, key)
 *      On = Dn ^ Vn
 *      V(n+1) = DES(On, key)
 */

Der Benutzer von SRA-Telnet und -FTP wird jeweils über die stattfindende sichere Authentifizierung und anschließende Verschlüsselung informiert. Hier zwei Beispiele:

Abschließend läßt sich einschätzen, daß mit der zunehmenden Verbreitung der Secure Shell SRA-Telnet an Bedeutung verloren hat, da die SSH sowohl ein deutlich höheres Sicherheitsniveau als auch einen wesentlich größeren Funktionsumfang bietet. Dazu kommt, daß SRA-Implementierungen nach unserem Kenntnisstand nur für UNIX-Systeme zur Verfügung stehen, wogegen die SSH (zumindest der Klient) auch auf anderen Plattformen (u.a. Windows) existiert.


Vertiefung:

Falls Sie Administrator einer UNIX-Maschine sind und SRA nutzen möchten, sollten Sie sich die Quellen beschaffen und versuchen, die Klienten sowie Server zu generieren und zu installieren. Je nach System gelingt dies mehr oder weniger schnell. Das Makefile enthält Angaben zu verschiedenen Plattformen. Da allerdings die Vielfalt der UNIX-Derivate recht beachtlich ist und die Software nicht für alle angepaßt wurde, muß man immer mit Problemen rechnen. Mitunter lassen sie sich durch (marginale) Quelltext-Modifikationen beheben. Das völlige Fehlschlagen der Generierung ist jedoch keineswegs auszuschließen.

Wie bereits gesagt, gibt es bei SRA keinerlei Konfigurationsaufwand. Man ersetzt nur die bisher genutzten Werkzeuge gegen die SRA-fähigen Versionen.

Da die SRA-Distributionen nur C-Quelltexte, aber keine fertigen Maschinenprogramme enthalten, benötigen Sie einen C-Compiler sowie einige Zusatzwerkzeuge (z.B. make), um die Binaries selbst aus den Quellen generieren zu können. Außerdem sind zwei Zusatzbibliotheken erforderlich: eine DES- sowie eine Langzahl-Arithmetik-Library. Beide sind kostenfrei erhältlich. Lesen Sie bitte dazu die Datei README.


© Holger Trapp, 1.7.1999