Sicherer Kanal: von Alice zu Bob Protokolle II: SSL/TLS, …

VLAN Virtuelles LAN, logisch getrennt, aber physisch auf dem gleichen Medium (Draht) IEEE 802.1q, Layer 2 Beispiel-Architektur Gruppe Ports in der selben Broadcast Domain Basierend auf Port, MAC Adresse, Protokoll oder Applikation Datenpakete evtl. mit einer VLAN-ID versehen

VLAN: Gründe Abbildung der Organisationsstruktur  Netzwerkstruktur Vereinfachung von Änderungen Virtuelles Patchen (Umzug von Mitarbeitern) Verringerung der Administrationskosten Bessere Kontrolle von Broadcasts. (ohne VLAN, mit VLAN) Erhöhte Netzwerksicherheit?

VLAN: portbasiert VLAN  Switch Port Eigenschaften Zuordnung eines Endgeräts zu einem VLAN erfolgt durch die Konfiguration des Switch-Ports an dem Gerät verbunden ist. Eigenschaften Statisch Einfache Administration Relativ geringe Sicherheit Port VLAN 1 1 2 1 3 2 4 2 Port 1 Port 4 Port 2 Port 3

MAC basierende VLANs VLAN  Gruppe von MAC Adressen Zuordnung eines Endgeräts zu einem VLAN erfolgt aufgrund seiner MAC Adresse statisch / dynamisch + etwas höhere Sicherheit aufwendige Administration selten implementiert MAC Adresse VLAN 00-E0-7D-86-73-26 1 00-E0-7D-86-73-27 1 00-E0-7D-86-73-28 2 00-E0-7D-86-73-29 2 00-E0-7D-86-73-26 00-E0-7D-86-73-29 00-E0-7D-86-73-27 00-E0-7D-86-73-28

VLAN: Policy basiert VLAN = Policy (regelbasiert) Dynamisch + flexibel Layer 3 Protokoll des Endgeräts Layer 3 Netzadresse des Endgeräts Dynamisch + flexibel + Endgerät in mehreren VLANs möglich - je nach Regel einfache bis sehr schwierige Administration Subnetz VLAN 192.168.1.0 1 192.168.2.0 2 Subnetzmaske 255.255.255.0 192.168.1.1 192.168.2.2 192.168.1.2 192.168.2.1

VLAN: Switch-übergreifend Verbindung von mehreren Switches über den Backbone Identifikationsmöglichkeiten: Implizierte Markierung Im Frame enthaltenes Merkmal zur Zuordnung benutzt. Beispiele: IP-Adresse, MAC-Adresse Explizierte Markierung (Tag) Frame für Transport über Backbone ein identifizierendes Feld hinzugefügt. Beispiel: Tagging nach IEEE 802.1q

VLAN: IEEE 802.1q Tagging Frame wird erweitert um: ET (Ether Type 802.1Q) Priority (User Priority Field) CFI (Canonical Format Indicator) VLAN ID (VLAN Identifier) Maximale Framelänge (1518 Bytes) darf überschritten werden. IEEE 802.3ac

VLAN: Uplink-Ports Uplink-Port Uplink-Ports haben default-mäßig Zugriff zu allen VLANs Werden benutzt, um mehrere VLANs über gleichen physische Verbindung (zwischen Switchen) zu transportieren.

VLAN: Hopping Attack Uplink-Port Uplink-Port Station kann sich als Switch mit 802.1Q ausgeben (Spoofing) Angreifer ist dann Mitglied aller VLANs. Voraussetzung: Port ist für Uplinking freigegeben. http://www.sans.org/newlook/resources/IDFAQ/vlan.htm

VLAN: Double Encapsulated 802.1Q Hopping Attack Senden von doppelt gekapselten 802.1Q Frames. Switch entfernt jeweils nur ein Tag. Nur unidirektionaler Verkehr. Funktioniert auch, wenn Uplink-Funktionalität für diesen Port ausgeschaltet ist. Entfernen des 1. Tags, und weiterschicken. 802.1q, 802.1q Angreifer 802.1q, Frame Frame Opfer Funktioniert nur, wenn Uplink im gleichen VLAN wie Angreifer.

VLAN: Fazit Geeignet für Keine harte Authentifizierung  Spoofing Bequemlichkeit Reduzierung von Broadcast- und Kollisionsdomänen Keine harte Authentifizierung  Spoofing Port IP Ethernetaddresse Keine weitere Sicherung (Kryptografie) Keine Authentizität Keine Vertraulichkeit Alternativen ? Dr. Wolf Müller

VPN: Virtual Private Network Alternative zu „privatem Netzwerk“ Keine Standleitungen / Framerelay nötig. Internet als Transportmedium Alternative zu Remote Access-Lösungen Geringer Aufwand Flexibel Layer 4 als Transportmedium. Logische Verbindung auf Layer 2. Anforderungen: Access Control Authentizität Vertraulichkeit Integrität Etablierung des Tunnels Verschlüsselter Tunnel

VPN: Ablauf Verbindung zum Internet Verbindung durchs Internet vom VPN-Client (Notebook) zum VPN-Server wird hergestellt. Authentifizierung (Identität) beim VPN-Server Sichere Datenverbindung (z.B. mit IPSec, SSL/TLS) wird etabliert. Gesicherte Verbindung, durch das Internet, in das Firmennetz ist nun möglich.

VPN: Konfigurationen Site-To-Site: (Bridging) Site-To-End Verbindung zweier Gateways über das Internet mit dynamischen oder festen IP-Adressen. Gängigste und sicherste Methode, um zwei entfernte Netze zu verbinden. Filialen von Unternehmen Site-To-End Verbindung eines Gateways mit einem Endpunkt(PC) Außendienstmitarbeiter, Zugriff auf Unternehmensnetz End-To-End (Computer zu Computer) Verbindung zweier Computer miteinander QoS

VPN: Architektur

VPN: Protokolle Tunnel: Authentifizierung: Point-to-Point Tunneling Protocol (PPTP) Veraltet, Windows 2000, XP Durch IPSec ersetzt. Layer 2 Tunneling Protocoll (L2TP) PPP-Frames gekapselt nicht nur für IP, sondern auch ATM … IPSec SSL/TLS (OpenVPN) Authentifizierung: Password Authentication Protocol (PAP) Password im Klartext Challenge-Handshake Authentication Protokoll (CHAP) Extensible Authentication Protocol (EAP) Abstraktes Protokoll. EAP-MD5 CHAP EAP-TLS Zertifikate (IPSec,SSL) Dr. Wolf Müller

Übersicht Tunneling-Protokolle Eigenschaft PPTP L2F L2TP IPsec Protokoll-Ebene Layer 2 Layer 3 Standard Nein Ja Paket-Authentifizierung Benutzer-Authentifizierung Datenverschlüsselung Schlüsselmanagement (keine Verschlüsselung) Ja (IKE) QoS andere Protokolle (neben IP) tunnelbar End-To-End-Security Nein (Providerenterprise)

VPN: Fazit Verbindung immer pro Client (PC) Schnelle und sichere Lösung, um Netze zu verbinden Verbindung immer pro Client (PC) Keine Unterscheidung nach Nutzern Vorsicht beim setzen der Route, Route zum VPN-Gateway durch „öffentliches Internet“ Route über Tunneldevice für andere Pakete. Kein IP-forwarding zwischen Externem und Tunneldevice Verschlüsselung und MAC sichern Vertraulichkeit und Integrität. Firewalls können nicht in VPN-Verbindungen hineinsehen! Verfügbarkeit?

SSL/TLS: Problem Vertraulichkeit? Authentizität? Server Alice Internet Malloy Vertraulichkeit? Authentizität?

SSL/TLS: Geschichte 1993 Webbrowser Mosaic 1.0 vom NCSA (National Center for Supercomputing Applications) 1994 SSL 1.0 von Netscape Communications Corp. 01/1995 Netscape Navigator, SSL 2.0 Netscape Navigator, SSL 2.0 1996 SSL 3.0 und Übergabe an die IETF (Internet Engineering Task Force) 01/1999 SSL 3.1 als Standard durch die IETF festgelegt und umbenannt in TLS 1.0 (Transport Layer Security) 06/2003 TLS Extensions: SNI, … , RFC 3546 04/2006 TLS 1.1 und TLS Extensions RFC 4346, RFC 4366 08/2008 TLS 1.2 veröffentlicht durch die IETF: RFC 5246

SSL/TLS: Referenzmodellen SSL/TLS zwischen Anwendungsschicht und Transportschicht Aufbau eines sicheren SSL/TLS Kanals (Socket) oberhalb der TCP-Verbindung OSI TCP/IP 7 Anwendungsschicht Internet Anwendungs-schicht Host-zu-Netz Transportschicht HTTP, SMTP, FTP 6 Darstellungsschicht 5 Sitzungsschicht SSL/TLS 4 Transportschicht TCP 3 Vermittlungsschicht IP 2 Sicherungsschicht ATM, PPP, Ethernet 1 Bitübertragungsschicht

SSL/TLS: Überblick Etablierung einer Session Aushandlung der Algorithmen Austausch geheimer Schlüssel Authentifizierung Übertragung der Anwendungsdaten Sichert Vertraulichkeit und/oder Integrität Jede Verbindung gehört zu einer Session. Session kann mehrere Verbindungen enthalten. RFC 4492, RFC5246: „The Transport Layer Security (TLS) Protocol Version 1.2”

SSL/TLS: Protokollbestandteile HTTP (oder andere Anwendungsprotokolle) Hand- shake Change Chipher Alert Record Layer TCP

SSL/TLS: Vertraulichkeit Verschlüsselung der Nachricht, so kann sie nicht abgehört werden. Verwendung bekannter symmetrischer Verschlüsselungsverfahren DES, 3DES RC2, RC4 IDEA AES, CAMELLIA Key Exchange: Verwendung von „public-key“-Verschlüsselung RSA, DSA oder (EC)Diffie-Hellman (anonym, aber MitM) Zusätzlich: „pre shared key“ PSK möglich Alice Nachricht Bob $%&#!@ Most block ciphers (64 bit blocks) except for RC4 stream cipher CBC cipher block chaining use IV (initialization vector) XOR previous encrypted block with block then encrypt …

SSL/TLS: Integrität Message Authentication Code (MAC) fester Länge, beinhaltet: Hash der Nachricht Gemeinsames Geheimnis Sequenznummer Übermittlung des MAC zusammen mit der Nachricht. Empfänger berechnet eigenen MAC Sollte mit übermitteltem MAC übereinstimmen. SSL/TLS erlaubt MD5, SHA-*, … Secret is used so that someone cannot replace both message and MAC, putting a new matching MAC in place of the original Bob Alice MAC Message MAC Message’ MAC’ =?

TLS: Authentifizierung Überprüfung der Identitäten der Teilnehmer. Client-Authentifizierung ist optional. Zertifikat, um Identität mit öffentlichen Schlüssel und anderen Attributen zu assoziieren. Ggf. PSK zum Verschränken verschiedener TLS-Kanäle Alice Zertifikat Bob

SSL/TLS: Record Layer Neue Ebene in Protokollhierarchie. Akzeptiert Folge von Bytes (Bytestrom) von der Anwendung. Fragmentierung des Bytestroms der Applikation in Blöcke (Records). Komprimierung der Applikationsdaten (optional). Authentifizierung der Daten durch MAC (Message Authentication Code). Ver-/Entschlüsselung Mit dem Handshake wird das Schlüsselmaterial zwischen den Partnern vereinbart. HTTP Record Layer TCP IP Netzwerk-schicht

SSL/TLS: Record Layer Applikationsdaten Fragmentierung Komprimierung Authentifizierung MAC MAC Padd. P. Länge Verschlüsselung Anhängen des Record Headers MAC Padd. P. Länge H

SSL/TLS: Handshake Protokoll (1) Webserver Alice ClientHello Höchste beherrschte SSL/TLS Version Liste von Algorithmen die Client beherrscht (Cipher Suites) Session ID 0  neue Session int  Wiederaufnahme bereits etablierter Session. Zufallszahl RC

SSL/TLS: Handshake Protokoll (2) Webserver Alice ClientHello ServerHello Zertifikat ServerHelloDone Server wählt: Zu verwendende SSL/TLS Version Falls Session fortgesetzt werden kann, Session ID 0  neue Session int  Wiederaufnahme gewünschter Session. Zu verwendende Cipher Suite. Zufallszahl RS Server sendet sein Zertifikat. „ServerHelloDone“  Ende

SSL/TLS: Handshake Protokoll Webserver Alice ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange Klient erzeugt Zufallszahl (Premaster Secret) Verschlüsselt diese mit Public Key des Servers Sendet verschlüsseltes Premaster Secret an Server. Bei DH sendet Client nur öffentlichen DH-Schlüssel

SSL/TLS: Schlüsselerzeugung Aus RC, RS und Premaster Secret Pre wird Master Secret errechnet: Master Secret = MD5( Pre | SHA( 'A' | Pre | RC | RS)) | MD5( Pre | SHA( 'BB' | Pre | RC | RS)) | MD5( Pre | SHA( 'CCC' | Pre | RC | RS))| … Iteration, bis genügende Länge für insgesamt 4 Schlüssel: 2 Schlüssel zur symmetrischen Verschlüsselung 2 Schlüssel für (H)MACs Schlüssel werden unidirektional verwendet.

SSL/TLS: Handshake Protocol ClientHello ServerHello Webserver Alice Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ChangeCipherSpec ist eigenes Protokoll Wird durchgeführt wenn: Überlauf der Sequenznummern Alert Meldungen ChangeCipherSpec Nachricht: Alle folgenden Nachrichten mit neuer CipherSuite. Finished Nachricht: MAC über alle bisher erhaltenen Nachrichten.

SSL/TLS: Optionale Phasen Server sendet kein Zertifikat, sondern temporären öffentlichen Schlüssel (schwach, wegen Exportbeschränkungen) ClientHello Webserver Alice ServerHello Certificate ServerKeyExchange ServerHelloDone

Optionale Phasen Server kann vom Client ein Zertifikat verlangen ServerHello Webserver Alice Certificate Certificate Request ServerHelloDone Certificate ClientKeyExchange CertificateVerify Handshake - Protokoll

SSL/TLS: CertificateVerify Nachricht Falls Client Zertifikat vorweisen muss: Sendet Alice CertificateVerify Nachricht an Bob. Nachricht ist MD5-MAC und SHA-MAC über bisher ausgetauschte Nachrichten mit Master Secret als Schlüssel: MD5(master_secret|pad2|MD5(handshake_messages|master_secret|pad1)); SHA(master_secret|pad2|SHA(handshake_messages|master_secret|pad1)) Pad1: MD5: 48 x Muster 0x36, SHA: 40 x “” Pad2: “” 0x5c

SSL 3.0  TLS 1.0 TLS 1.0 Internetstandard der IETF Änderungen: Versionsfeld der SSL-Nachrichten 3.1 Änderungen: Nachrichten-Authentifikation Erzeugung des Schlüsselmaterials CertificateVerify (CV) Berechnung stark vereinfacht Nachricht = signierter Hashwert aller ausgetauschten Handshake-Nachrichten (ClientHello bis CV-Nachricht) Finished-Nachricht Fortezza-Ciphersuites nicht mehr zwingend in Ciphersuites 12 neue Alert-Nachrichten Authentifikation Kryptografisch stärkere HMAC-Verfahren

SSL 3.0  TLS 1.0 TLS Ciphersuites Neu definierte Ciphersuites haben eindeutigen Namen von IETF 2-Byte-Wert Bei SSL Namensvergabe Problem Nicht eindeutig geregelt (Bytewerte zum Teil doppelt belegt) http://www.iana.org/assignments/tls-parameters/tls-parameters.xml TLS Cipher Suite Registry - per [RFC4346] 0x00,0x00 TLS_NULL_WITH_NULL_NULL [RFC4346] 0x00,0x01 TLS_RSA_WITH_NULL_MD5 [RFC4346] 0x00,0x02 TLS_RSA_WITH_NULL_SHA [RFC4346] 0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346] 0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC4346] … 0x00,0x38 TLS_DHE_DSS_WITH_AES_256_CBC_SHA [RFC3268] 0x00,0x39 TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC3268] Algorithmen für digitale Signatur und Schlüsselaustausch während des Handshakes Algorithmen für symmetrische Verschlüsselung (Stromchiffre) und (H)MAC

SSL/TLS: Für begrenzte Ressourcen MaximumFragmentSize: Aushandeln der Fragmentgröße bei Bandbreiten- oder Speicherbegrenzung ClientCertificateURLs: Übermittlung einer URL zum Zertifikat, statt Zertifikat selbst CA Root Keys: Übermittlung, welche Root CA Keys der Client besitzt Truncated MAC: HMAC wird auf 80 Bit gekürzt um Bandbreite zu sparen Client Certificate Status Information: Certficate Revocation List muss nicht gesendet werden

SSL/TLS: Fazit Vertraulichkeit: Authentizität: Authentifikation: Symmetrische Verschlüsselung im Record Layer Authentizität: (H)MAC-Bildung im Record Layer Authentifikation: Austausch von X.509 Zertifikaten im Handshake-Protokoll Zweiseitig oder auch anonym möglich. Probleme: MD5HMAC Aufbewahrung des privaten Schlüssels. Keine Verbindlichkeit. Verkehrsflussanalysen. Nicht für Firewall zugänglich. Man-in-the-Middle? Zertifikatsprüfung, UI, Trustlists

SSL/TLS: „Alternativen” S-HTTP: secure HTTP Protokoll, shttp:// IPSec: secure IP SET: Secure Electronic Transaction Protokoll und Infrastruktur für Bankkartenzahlungen SASL: Simple Authentication and Security Layer (RFC 2222) S-HTTP inter-operates with http signature authentication encryption public key key exchange, & externally arranged Secure * Secure-HTTP/1.4 : Request URI Secure-HTTP/1.4 200 OK response header lines convey information e.g. Certificate-Info: has cert, Encryption-Identity: x500 name ------------ IPSec RFC 1825-1829 required for IPv6, optional for IPv4 transport mode - protect contents of IP packet tunnel mode - protect entire IP packet encryption, MAC SASL Means to add authentication to connection-based protocol Variety of mechanisms Kerberos V4, GSSAPI, “External” Allows separation of authorization identity from client identity in credentials Permits authenticated state in protocol

Kerberos Name des dreiköpfigen Hund Zerberus (bewacht den Eingang zur Unterwelt) Basiert auf Needham-Schroeder-Protokoll für symmetrische Kryptosysteme Um Zeitstempel erweitert. Ursprünglich auf asymmetrisch Kryptografie verzichtet (Patentrechtliche Beschränkungen zur Entwicklungszeit in den USA) Microsoft hat dies in proprietäre Kerberos-Version implementiert. Dr. Wolf Müller

Ziele von Kerberos Fälle die behandelt werden sollen: Angreifer erhält Zugriff auf einen Server und gibt vor, ein anderer Anwender zu sein. Angreifer verändert die Netzwerkadresse eines Rechners und täuscht einen anderen Rechner vor. Angreifer hört den Netzwerkverkehr ab und verschickt Nachrichten erneut (z.B. um eine Systemanmeldung nachzuvollziehen) – „replay attack“ Dr. Wolf Müller

Kerberos Kerberos setzt auf einem zentralen Authentifizierungs-Server auf Authentifizierung von Rechnern und Usern Basiert auf symmetrischer Verschlüsselung, d.h. keine „public key“-Verfahren Kerberos 4: für abgeschlossene Vertrauensbereiche Kerberos 5: Erweiterung, um auch organisationsübergreifende Authentifizierung zu erreichen. Hook für Benutzung alternativer (auch asymmetrischer) Kryptoverfahren: AES, RSA, … Dr. Wolf Müller

Komponenten Client (Alice) Server (Bob) KDC Key Distribution Center Client und Server haben jeder eigene Passwörter, die jeweils auch dem KDC bekannt sind. Ziel: Aufbau einer sicheren Verbindung zwischen Client und Server. Dr. Wolf Müller

Session Key und Tickets Geheimnis zwischen Client und Server Für vertrauenswürdigen (confidence) und unveränderten (integrity) Nachrichtenaustausch. Ticket Enthält transaktionsspezifische Daten. Zeitstempel der Erstellung und Gültigkeitsdauer. Ermöglicht anfragenden Zugriff auf andere Rechner. Dr. Wolf Müller

Gegenseitige Authentifizierung KDC Ziel: Alice soll sicher sein, dass sie mit Bob kommuniziert und umgekehrt Alice Bob Dr. Wolf Müller

Kerberos KDC Alice Bob Überprüfen bestimmt KA (Schlüssel) Login von (Passwort) Alice Bob Dr. Wolf Müller

Kerberos KDC Alice Bob KA SA TGT zweite Kopie von SA Name von Alice Ablaufdatum verschlüsselt mit KKDC Session Key (SA) und TGT KDC Dann wird nur noch SA und TGT verwendet! TGT SA Alice Bob KA kann (über Hash-Funktion) aus dem Passwort gewonnen werden, sodass die Entschlüsselung möglich ist SA ist Session-Key KA ist Schlüssel von Alice Dr. Wolf Müller

Kerberos KDC Alice Bob „möchte mit Bob sprechen“ TGT <authenticator> Alice Bob = Zeitstempel verschlüsselt mit SA  Synchronisation von Alice und KDC nötig Dr. Wolf Müller

Kerberos KDC Alice Bob entschlüsseln von TGT mit KKDC Authentikator mit SA KDC TicketAlice Erstellt zwei Tickets (für Bob und Alice), diese enthalten: Name des jeweiligen Prinzipals Zeitstempel Gültigkeitsdauer Schlüssel KAB, zwischen Alice und Bob Ticket von Bob wird mit KB verschlüsselt und in Ticket für Alice eingefügt Ticket für Alice wird mit SA verschlüsselt -> TicketAlice Alice Bob Dr. Wolf Müller

Kerberos KDC Alice Bob TicketAlice wird mittels SA ent- schlüsselt legt KAB offen und TicketBob Alice Bob Authentikator verschlüsselt mit KAB und TicketBob Dr. Wolf Müller

Kerberos KDC Alice Bob TicketBob wird legt KAB offen mittels SB ent- schlüsselt legt KAB offen Alice Bob entschlüsseln von Authentikator mit KAB Dr. Wolf Müller

Kerberos KDC Alice Bob Alice und Bob haben beide KAB Alice kennt Bob Bob kennt Alice Dr. Wolf Müller

Einfaches Authentifizierungs-Beispiel C Client AS Authentifizierungs-Server V Server IDC Identität des Anwenders an C IDV Identität von V PC Passwort des Users auf C ADC Netzwerkadresse von C KV (geheimer) Schlüssel, zwischen AS und V || Anhängen EKv Verschlüsselung mit KV. Dr. Wolf Müller

Beispiel Ticket = EKv [ IDc || ADC || IDv ] AS (authentication server) (1) C ? AS: IDC || PC || IDV (2) AS ? C: IDC || Ticket Client C Server V (3) C ? V: Ticket Ticket = EKv [ IDc || ADC || IDv ] Dr. Wolf Müller

Beispiel Anwender loggt sich auf C ein und fordert Zugriff auf Server V an. Dazu wird die Nachricht IDC || PC || IDV an AS geschickt. AS überprüft Benutzername und Passwort Falls Login korrekt: AS erzeugt Ticket bestehend aus EKv [ IDC || ADC || IDV ], dass der Anwender zum Zugriff auf V verwenden kann. Ticket ist verschlüsselt IDC: Ticket wurde für C erstellt ADC: um Netzwerkadressenveränderungen nachvollziehen zu können IDV: ermöglicht es V herauszufinden, ob die Nachricht korrekt verschlüsselt war. Nachteile User muss sich jedes Mal erneut anmelden, wenn er auf V zugreift Unverschlüsselte Übertragung des Passworts. Dr. Wolf Müller

Ticket Granting Services TGS erstellt für den User, der von AS authentifiziert ist, ein Ticket T1 mit einer bestimmten Lebensdauer (lifetime). Ticket kann der User mehrmals verwenden, um von TGS sog. „service granting tickets“ T2 anzufordern Mit T2 kann der User (bzw. der Client anstelle des Users) die Ausführung eines Dienstes auf V initiieren. Dr. Wolf Müller

Kerberos: Ablauf Dr. Wolf Müller

Kerberos Realms (Verantwortungsbereiche) Voraussetzungen Kerberos-Server kennt die IDs und (Hashwerte der) Passwörter jedes Users. Jeder User ist beim Kerberos-Server registriert. (Windows-Domäne) Geheimer Schlüssel zwischen dem Kerberos- Server und jedem Server. Alle Server sind beim Kerberos-Server registriert. Für Authentifizierung zwischen zwei Kerberos Realms wird benötigt: Kerberos-Server jedes Realms haben einen gemeinsamen geheimen Schlüssel, und jedes Kerberos-Server-Paar kennt sich. Dr. Wolf Müller

Ablauf Dr. Wolf Müller

Unterschiede Kerberos 4 und Kerberos 5 Version 4 war für abgeschlossene Systeme. Version 5 zielt auf einen allgemeineren Einsatz ab. Unterschiede V4 verwendet DES – V5 lässt allgemeine Verschlüsselungsverfahren zu V4 benötigt Internet Protokoll – V5 lässt allgemeinere Netzwerkprotokolle zu V5 unterstützt, dass ein Server auf andere Server unter der Kennung eines Users zugreifen kann (Ticket-forwarding) Authentifizierung über N Realm-Grenzen hinweg: V4 benötigt N2 Beziehungen zw. Kerberos-Servern, V5 stellt Verfahren bereit, die diesen Aufwand reduzieren. Dr. Wolf Müller

Kerberos: Sicherheitsprobleme Verwahrung von Sitzungsschlüsseln in Mehrbenutzersystemen z.B. als Dateien in /tmp Passworte für initiale Vergabe von Tickets (Passwort-Cracking-Angriffe) Vertrauenswürdige Zeit nötig. Gültigkeit der Sitzungsschlüssel Version 4: max. 21h Version 5: max. bis 31.12.9999, aber Option, zum Rückruf bzw. zur Erneuerung des Sitzungsschlüssels Version 4: kein forwarding, Tickets nur im Bereich des ausstellenden TGS gültig Wird Ressource außerhalb benötigt, muss Passwort übertragen werden. Keine Maßnahmen zur Gewährleistung der Integrität und Nichtabstreitbarkeit von Nachrichten. Ersetzung des Passworts durch smartcardbasiertes Challenge-Response wünschenswert. Dr. Wolf Müller

Kerberos: Implementierungen MIT: Freie Implementierung des Kerberos-Protokolls für Unix und Linux Version 4 und 5 Verschlüsselungsverfahren: DES, 3DES, AES und RC4 Prüfsummenverfahren MD5, SHA-1, HMAC und CRC32 Heimdal Kerberos MIT Kerberos Microsoft Kerberos als Standard-Protokoll für die Authentifizierung unter Windows 2000/2003 basierten Netzwerken, sowie für Windows XP-Client. Kerberos-Schlüssel im Verzeichnis gespeichert. Unter Windows 2000 wurden nur RC4 und DES Verschlüsselung Active Directory verwundbar für Brute Force Angriffe Windows Server 2003 und Windows XP ab SP1 Erweiterungen implementiert, die das System gegen solche Angriffe stärker absichern. Dr. Wolf Müller