Kerberos. Single Sign On. Benutzerauthentisier ung. 10. Jan 2002 Holger Zuleger 1/28. > c

Transkript

1 Kerberos Single Sign On Benutzerauthentisier ung 10. Jan 2002 Holger Zuleger 1/28 > c

2 Was ist Kerberos? a. Dreiköpfiger Höllenhund aus der griechischen Mythologie b. "Third party" Authentication System entwickelt am MIT Ursprünglich auch für Author ization und Accounting gedacht (Daher die 3 Köpfe) 10. Jan 2002 Holger Zuleger 2/28

3 Was ist Kerberos? (2) Basier t auf symmetrischen Schlüsseln (DES, 3DES, u.a.) schnell Keine Über tragung von Passwör tern sicher Er laubt Single Sign On praktisch Über 15 Jahre alt bewähr t Wird stetig weiterentwickelt (KerberosV, GSSAPI, KINK) aktuell Anwendungsbeispiele: Athena Benutzerauthentisier ung bei Cisco Router und Switchen Windows 2000 Benutzerauthentisier ung ssh 10. Jan 2002 Holger Zuleger 3/28

4 Überblick Ke ytab Ser vtab Kerber ized Application Ser ver KDC TGS AS Ke y, "HostA" Ke y, "hoz" Ser vice Ticket TGT Ser vice Ticket realm.db Ticket Cache Kerber ized Client KDC AS TGS Ke y Distr ibution Center Authentication Server Ticket Granting Server Ticket Cache Er möglicht Single Sign On Keytab File Speicher t Anwendungsschlüssel Kerberiz ed Application z.b. POP3-Ser ver, Telnet-Ser ver, SSH-Ser ver, alle Dienste mit GSS-API Benutzerauthentisier ung 10. Jan 2002 Holger Zuleger 4/28

5 Funktionsweise Ticket-Granting-Ticket (1) 4 Client KDC 2 password Ticket Cache realm.db Ke y, "HostA" Ke y, "hoz" 1. Ticket Request an das Key Distr ibution Center: "Ich bin hoz@hznet.de"! Gib mir ein Ticket Granting Ticket. 2. Holen des Benutzerschlüssels und des KDC-Serverkeys aus der Datenbank. Generieren eines SessionKeys. 3. Antwor t vom KDC enthält zwei Infor mationen: a. Key: SessionKey + Ser verid von KDC, verschl. mit Userpassword b. Ticket-Granting-Ticket zur Vor lage gegenüber KDC: Session Key + UserID von "hoz" verschlüsselt mit ServerKey 10. Jan 2002 Holger Zuleger 5/28

6 Funktionsweise Ticket-Granting-Ticket (2) 4 Client KDC 2 password Ticket Cache realm.db Ke y, "HostA" Ke y, "hoz" 4. Eingabe des Benutzer passwortes und entschlüsseln des Key- Paketes. Der Client ist im Besitz des Sessionkeys. 5. Speichern des Ticket-Granting-Ticket im Ticket Cache. Ab diesem Zeitpunkt wird keine Passworteingabe mehr benötigt! 10. Jan 2002 Holger Zuleger 6/28

7 Funktionsweise Service-Ticket (1) HostA KDC keytab Client Ke y, "HostA" Ke y, "hoz" 4 realm.db Ticket Cache 1. Ticket Request an Key Distr ibution Center mit Vor lage des TGT: Gib mir Ticket "ser vice/hosta.hznet.de" 2. Suchen des Benutzer- und Serverschlüssels in Datenbank Gener ieren eines SessionKeys 10. Jan 2002 Holger Zuleger 7/28

8 Funktionsweise Service-Ticket (2) HostA KDC keytab Client Ke y, "HostA" Ke y, "hoz" 4 realm.db Ticket Cache 3. Antwor t vom KDC mit zwei Infor mationen: a. Key: SessionKey + Ser verid "HostA", verschl. mit TGT-Sessionkey b. Ticket zur Vor lage gegenüber "HostA": Session Key + UserID von "hoz" verschl. mit ServerKey 4. Entschlüsseln des Key-Paketes mit Hilfe des TGT-Sessionkeys Der Client ist im Besitz des Sessionkeys. Speicher n des Tickets im Ticket Cache. 10. Jan 2002 Holger Zuleger 8/28

9 Funktionsweise Service-Ticket (3) HostA KDC keytab Client Ke y, "HostA" Ke y, "hoz" 4 realm.db Ticket Cache 5. Bilden eines Authentication credentials (Ticket + Authenticator) zur Authentisier ung gegenüber dem Host. 6. Holen des Serverkeys aus der Keydatei und entschlüsseln des Ticket. Der Server ist im Besitz des Sessionkeys. 7. Überprüfung des Authenticators anhand des Sessionkeys. Client und Server besitzen jetzt einen Sessionkey! Mit diesem wird die weitere Kommunikation verschlüsselt abgewickelt 10. Jan 2002 Holger Zuleger 9/28

10 Kerberos Realm Ein administrativer Bereich zur Verwaltung von Benutzer kennungen Ser vices auf Rechnern Benutzer ID s und Service ID s werden auch Pr incipals genannt Eine Realm kann hierarchisch struktur iert sein Jede REALM hat einen eindeutigen Namen, angelehnt an DNS- Domainnamen Der Name der Realm wird per Übereinkunft in Großbuchstaben notiert HZNET.DE 10. Jan 2002 Holger Zuleger 10/28

11 Pr incipals Pr incipals sind Teilnehmer des Kerberos Authentisier ungssystems Eindeutige Identifikation eines Benutzers oder eines Dienstes innerhalb einer REALM Muß vor der Nutzung in der REALM-Datenbank angelegt werden Besitzt eine ID und ein Geheimnis Geheimnis ist nur dem Principal und dem KDC bekannt Pr incipals werden durch kadmin erzeugt und in der KDC Datenbank gespeicher t 10. Jan 2002 Holger Zuleger 11/28

12 User principals Die ID besteht aus einem Namen, und einer REALM. Als "Geheimnis" wird ein Passwort verwendet. Passwort muß vom Benutzer geändert werden können (kpasswd) BenutzerID kann eine Instance beinhalten (durch Slash getrennt) Instanzen weisen Benutzer unterschiedliche Rollen zu 10. Jan 2002 Holger Zuleger 12/28

13 Ser viceprincipals Die ID besteht aus einer Serviceangabe, gefolgt von einem Slash sowie dem vollqualifizier ten Rechner namen des Servers (FQDN). Als Serviceangabe sind u.a. host, ftp oder z.b. pop er laubt. Als "Geheimnis" wird ein Zufallswert verwendet. Das "Geheimnis" eines Servicepr incipals muß auf dem Server in der Datei /etc/keytab hinter legt werden. Der Schlüssel eines Servers kann nicht geänder t, sonder n lediglich neu erzeugt werden. 10. Jan 2002 Holger Zuleger 13/28

14 KDC (Key Distr ibution Center) KDC besteht aus authentication Server (AS) und Ticket granting Ser ver (TGS) KDC muß besonders geschützt werden Enthält die Datenbank mit den User- und Serverprincipals der Realm Aus Redundanzgründen auch weitere KDC-Server (Slaves) möglich Die Slaves gleichen die Datenbank über ein Protokoll mit dem Master KDC ab. 10. Jan 2002 Holger Zuleger 14/28

15 Ticket Gegenseitige Authentisier ung von Benutzer und Dienst Mutual Authentication Enthält SessionKey, UserPr incipal, und Lebensdauer (Gültigkeit) Das Ticket ist verschlüsselt mit dem Serviceschlüssel des Servers SessionKey User principal Lifetime Checksum Ser vicekey Wird vom Client beim KDC für einen bestimmten Dienst angeforder t Wird in einem lokalen Ticketcache befristet gespeichert Wird vor der Authentisier ung um Zeitstempel (Authenticator )ergänzt. Ticket plus Authenticator ist ein Authentication credential Ticket Ser vicekey Authenticator SessionKey 10. Jan 2002 Holger Zuleger 15/28

16 Ticket Granting Ticket (TGT) TGT wird einmal beim Authentication Server (AS) angeforder t Benutzer authentisiert sich durch Passwort TGT ist ein Service-Ticket für den Ticket Granting Server (TGS) Automatische Beantragung beim Anmelden oder manuell durch kinit TGT hat default Lifetime von 8 Stunden (änderbar) Wird im Ticketcache des Client gespeichert Für Authentisier ung bei Anforder ung von Ser vicetickets am TGT Der Benutzer muß sein Passwort nicht noch einmal eingeben Single-Sign-On Beim Abmelden wird der Ticketcache automatisch gelöscht. 10. Jan 2002 Holger Zuleger 16/28

17 Beispiele (Anmelden) Holen eines Ticket-Granting-Ticket $ kinit hoz Password for hoz@hznet.de:<password> Anzeige des Ticket Cache $ klist -f Ticket cache: FILE:/tmp/krb5cc_3157 Default principal: hoz@hznet.de Valid starting Expires Service principal 12/20/01 12:48:29 12/20/01 22:48:29 krbtgt/hznet.de@hznet.de Flags: FI 10. Jan 2002 Holger Zuleger 17/28

18 Beispiele (telnet) Telnetverbindung zu einem Rechner aufbauen $ telnet -a xt4.hznet.de Trying Connected to xt4.hznet.de ( ). Escape character is ˆ]. [ Kerberos V5 accepts you as hoz@hznet.de ] Welcome to SuSE Linux 7.3 (i386) - Kernel %r (%t). *** Connection not encrypted! Communication may be eavesdropped. hoz@hma: > exit Jetzt das ganze mit verschlüsselter Datenkommunikation: $ telnet -x -a xt4.hznet.de Trying Connected to xt4.hznet.de ( ). Escape character is ˆ]. Waiting for encryption to be negotiated... [ Kerberos V5 accepts you as hoz@hznet.de ] done. Welcome to SuSE Linux 7.3 (i386) - Kernel %r (%t). hoz@hma: > exit 10. Jan 2002 Holger Zuleger 18/28

19 Anzeige des Ticketcache Beispiele (Ticketcache) $ klist -f Ticket cache: FILE:/tmp/krb5cc_3157 Default principal: hoz@hznet.de Valid starting Expires Service principal 12/20/01 12:48:29 12/20/01 22:48:29 krbtgt/hznet.de@hznet.de Flags: FI 12/20/01 12:54:27 12/20/01 22:48:29 host/xt4.hznet.de@hznet.de Flags: F Ticket cache leeren $ kdestroy $ klist -f 10. Jan 2002 Holger Zuleger 19/28

20 Voraussetzungen für den Einsatz von Kerberos Zeitsynchronisier te Systeme (max. 5 Minuten Differenz) Client- und Serversysteme müssen korrekt im DNS eingetragen sein KDC s müssen speziell gesicherte Systeme sein Mindestens zwei KDC s (Master, Slave). Ausschließlich Kerberos V verwenden Anforder ungen für Cisco Router IOS-Image mit Kerberos Support (Enter prise, IPsec oder Telco Feature Set) DES oder 3DES notwendig für verschlüsselte Telnetverbindung (Authentisier ung auch ohne DES-Image). Backupkonzept für REALM Datenbank! 10. Jan 2002 Holger Zuleger 20/28

21 CONTENTS... 1 Was ist Kerberos?... 2 Was ist Kerberos? (2)... 3 Überblick... 4 Funktionsweise Ticket-Granting-Ticket (1)... 5 Funktionsweise Ticket-Granting-Ticket (2)... 6 Funktionsweise Service-Ticket (1)... 7 Funktionsweise Service-Ticket (2)... 8 Funktionsweise Service-Ticket (3)... 9 Kerberos Realm Pr incipals User principals Ser viceprincipals KDC (Key Distr ibution Center) Ticket Ticket Granting Ticket (TGT) Beispiele (Anmelden) Beispiele (telnet) Beispiele (Ticketcache) Voraussetzungen für den Einsatz von Kerberos <