Tiefergelegt MACSec: Security-Mechanismen in den ersten OSI-Schichten

Ordnungsmerkmale

erschienen in: <kes> 2007#2, Seite 18

Rubrik: Management und Wissen

Schlagwort: Netzwerksicherheit

Zusammenfassung: Die beiden IEEE-Standards 802.1AE und 802.1af behandeln Sicherheitsmechanismen in der Media-Access-Control-Schicht. Drahtgebundene lokale Netze (LAN) und Metropolitan Area Networks (MAN) erhalten damit Möglichkeiten zur Verschlüsselung und Authentifizierung am Switch.

Autor: Von Markus Nispel, Frankfurt

Kaum hatte der Standard 802.1X "Port based Authentication mit EAP" (Extensible Authentication Protocol) begonnen die LAN- und WLAN-Welt als sichere Authentifizierungsmethode und Verteiler von Schlüsselmaterial zu erobern, hat das Institute of Electrical and Electronics Engineers (IEEE) auch schon nachgelegt: Mitte 2006 wurde 802.1AE "Media Access Control (MAC) Security" verabschiedet, der Verschlüsselung für drahtgebundene Netze beschreibt (wired LAN/MAN). Das dazu notwendige Schlüsselmanagement definiert IEEE 802.1af "MAC Key Security" als Erweiterung des 802.1X – dieser Standard befindert sich jedoch noch im Entwurfsstadium.

Der MAC-Security-Standard dient in LANs/MANs zur Sicherung der Integrität und Authentizität übertragener Datenpakete sowie zur Abwehr von Lauschangriffen auf die transportierten Daten. Der Standard definiert hierzu "Hop by Hop"-Verschlüsselung, -Authentifizierung und -Integritätsprüfung und wird zwischen Endsystemen und Netzwerk-Switch oder auch (wohl eher selten) zwischen verschiedenen Switches zum Einsatz kommen. Die hierfür benötigte Netzwerkhardware mit komplexeren Chips (inkl. Kryptofunktionen) ist zwar im Prinzip teurer als bisherige Systeme – andererseits ist davon auszugehen, dass eine breitere Anwendung erst dann stattfindet, wenn die Preise auf das gewohnte Niveau sinken.

Die potenziellen Anwendungsbereiche reichen von der sicheren Trennung verschiedener Kunden in derselben Layer-2-Domain eines Service-Providers (Ethernet First Mile etc.) über die Sicherung von Metro-Netzen (MANs) zwischen Unternehmensteilen bis hin zur erweiterten Sicherung heutiger 802.1X-Installationen mit Verschlüsselung und Integritätswahrung vom Endgerät zum Switch (wie z. B. schon in drahtlosen 802.11-WLANs vorgesehen) und der Sicherheit, dass man nur Verbindungen zu Geräten erstellt, die einem gewissen Trust-Level entsprechen.

Überblick 802.1AE

Die MACSec-Services werden zwischen so genannten MAC Security Entities (SecYs) aufgebaut. Gesteuert wird dies durch MACSec Protocol Data Units (MPDU) innerhalb des MAC-Layers (ISO/OSI Layer 2). Bevor zwischen verschiedenen SecYs ein gesicherter Datenaustausch stattfinden kann, ist zudem eine Kommunikation zur jeweiligen MAC Security Key Agreement Entity (KaY) notwendig, die IEEE 802.1af beschreibt (vgl. Abb. 1).

[Illustration]
Abbildung 1: Arbeitsweise eines Ports mit gesicherter und ungesicherter Kommunikation

Zur Verwaltung der Systemknoten (SecYs und KaYs) wird für Abfragen und Konfiguration die Version 3 des Simple Network Management Protocol (SNMPv3) empfohlen. Die dazu notwendige Management Information Base (MIB) ist sowohl im 802.1AE als auch im 802.1af spezifiziert.

Für die eigentliche Verschlüsselung schreibt die IEEE den Einsatz des 128-Bit Advanced Encryption Standard im Galois/Counter Mode vor (GCM-AES 128). Damit lassen sich jeweils auch nur Encryption- oder nur Integrity-Funktionen realisieren.

Beim Einsatz von MACSec reduziert sich die effektiv verfügbare Größe eines Datenpaketes um jeweils 8 bis 16 Octets, da das Datensegment (MAC Service Data Unit, MSDU) um Security Tag (SecTag) und Integrity Check Value (ICV) ergänzt wird (vgl. Abb. 2). Insgesamt stehen daher pro Paket bis zu 32 Octets weniger zur Verfügung, sofern das Medium keine größeren Frames zulässt.

Der ICV wird durch MACSec-Systeme zum Integritätsschutz über den kompletten Frame inklusive MAC-Adressen berechnet. Dabei ist – wie schon erwähnt – optional auch eine Verschlüsselung der übertragenen Daten möglich. Der SecTag umfasst neben dem MACSec Ethertype noch die folgenden Daten:

Alle bekannten Protokolle wie Rapid Spanning Tree (802.1w), VLAN Trunking (802.1Q), Link Aggregation (802.3ad) und Multiple Spanning Tree (802.1s) sind übrigens weiterhin nutzbar und gültige Optionen. Auch wird der neue Standard 802.1ad "Provider Bridging" unterstützt, da MACsec ja insbesondere im Service-Provider-Umfeld zum Einsatz kommen soll. Dabei kann auch mit unverschlüsselten Systemen innerhalb desselben LAN kommuniziert werden; ein fast beliebiger Mischbetrieb ist somit ohne Weiteres möglich. Zu erwarten ist jedoch eine Änderung der Ethernet-Framesize – die IEEE hat eine Taskforce "802.3as Frame Expansion" gegründet, welche die entsprechenden Anforderungen kanalisieren soll. Ihre Ziele lauten:

[Illustration]
Abbildung 2: Aufbau eines MACSec-Pakets

Überblick 802.1af

Key-Management und Authentifizierung für MACSec werden – wie eingangs erwähnt – durch den noch zu verabschiedenden Standard 802.1af abgedeckt, der eine Erweiterung des schon bekannten 802.1X-Standards darstellt. Zur Verdeutlichung soll daher im Folgenden zunächst nochmals der Ablauf einer 802.1X-Authentifizierung mittels Extensible Authentication Protocol via Transport Layer Security erläutert werden (EAP-TLS – Details siehe bspw. <kes> 2002#5, S. 61).

Die meisten SSL/TLS-Authentifizierungen, etwa beim Aufbau einer https-Verbindung, führen nur eine serverseitige Oneway-Authentication durch, bei der sich der Server gegenüber dem Client "ausweist". Der Client überprüft die Identität der Servers – genauer: seines SSL-Zertifikats – durch den Vergleich der ausstellenden Certificate Authority (CA) mit einer lokalen Liste "vertrauenswürdiger" CAs (Trusted Root CAs). Diese Liste, die im Falle einer https-Verbindung typischerweise im Browser des Clients gepflegt wird, heißt auch Certificate Trust List (CTL). Der SSL/TLS-Handshake wird hier über TCP durchgeführt.

Der Ablauf ist bei EAP-TLS ähnlich, jedoch erfolgt der Handshake über EAP beziehungsweise EAP over LAN (EAPoL). EAP-TLS führt darüber hinaus auch eine Authentifizierung des Clients gegenüber dem Server durch – genauer gesagt: gegenüber einem Authentication-Server, der oft als Radius-Server vorgesehen ist (vgl. Abb. 3). Zudem verwendet EAP abweichende Begriffe für die beteiligten Instanzen:

[Illustration]
Abbildung 3: Logische Abfolge einer EAP-Authentifizierung

Im Beispiel von Abbildung 3 stellt der Authenticator, ein WLAN Access Point, nach dem EAPoL-Start einen Identity Request an den Supplicant; dieser antwortet mit seiner UserID. Der Authenticator leitet dies innerhalb eines Radius Access Requests an den Authentication-Server weiter. Danach erfolgt die eigentliche TLS-Authentifizierung: Der Server sendet sein Zertifikat an den Supplicant (Client) und fordert von diesem ebenfalls ein Zertifikat. Nachdem jener das Server-Zertifikat geprüft hat, sendet er sein eigenes an den Server, wo wiederum eine Überprüfung erfolgt.

Zudem werden Session-spezifische Parameter ausgehandelt. Supplicant und Authentication-Server ermitteln parallel und unabhängig voneinander den Session-Key. Dieser wird vom Authentication-Server in Verbindung mit einer Radius-Access-Success-Meldung an den Authenticator weitergegeben – soweit der Rückblick auf EAP-TLS.

[Illustration]
Abbildung 4: Bei einer MACSec-Kommunikation verwendet jeder Knoten (Security Entities – SecYs und Key Agreement Entities – KaY) seinen eigenen unidirektionalen Secure Channel (SC).

Um nun eine MACSec-Kommunikation in einem LAN zu etablieren, müssen die jeweiligen SecYs und KaYs eine so genannte Connectivity Association erstellen (häufig ebenfalls CA abgekürzt). Diese besteht aus unidirektionalen, "absenderspezifischen" Point-to-Multipoint Secure Channels (SC, vgl. Abb. 4), die für die eigentliche Verschlüsselung (usw.) zuständig sind; hier zeigen sich deutliche Ähnlichkeiten zu IPSec (IETF RFC 2406).

Innerhalb der SCs bestehen Sequenzen von überlappenden Security Associations (SA), die mit periodisch wechselnden Kryptoschlüsseln (SA Keys, SAK) arbeiten. Die SecYs nutzen die SC-Information zur gesicherten Datenübertragung. Dafür sollten pro Endsystem 16 Bit als Port Identifier zur Verfügung gestellt werden, womit 65 000 verschiedene SCs nutzbar sind.

Die notwendigen Connectivity Associations können sowohl in einem Point-to-Point LAN als auch in einem Shared Media LAN aufgebaut werden, wobei dort pro Endsystem verschiedene Assoziationen möglich sind und Endsysteme auch unverschlüsselt miteinander kommunizieren können.

Die in Abbildung 5 vereinfacht dargestellte Gesamtarchitektur besteht somit zunächst aus dem Controlled Port (a), der die gesamte Kommunikation sichert und kontrolliert, sowie dem angeschlossen LAN (b) für den MAC-Service. Hinzu kommt ein Mechanismus zur Definition einer Connectivity Association (c) für jeden "Peer", der gültige Credentials (d) besitzt und die erfolgreiche gegenseitige Authentifizierung ermöglicht (e). Die daraus resultierende Autorisierung (e3) und anderes kryptographisches Material (e1, e2) können dann für das eigentliche Bestimmen der Kryptoschlüssel (f) für die sichere Kommunikation in einem gesicherten Kanal (SC, g) durch die einzelnen SAs herangezogen werden.

[Illustration]
Abbildung 5: Komponenten und Ablaufschema für eine MACSec-Authentifizierung

Fazit

IEEE 802.1AE und 802.1af bieten in ihrer Kombination völlig neue Möglichkeiten der Security auf den unteren Ebenen des ISO/OSI-Schichtenmodells und sind sowohl für LAN- als auch für MAN-Konzepte geeignet. Durch die Nähe zu bestehenden Protokollen und Architekturen sollten die neuen Protokolle vergleichsweise leicht verständlich und gut adaptierbar sein. Die ersten LAN-Produkte dürften allerdings noch ein bis zwei Jahre auf sich warten lassen. Die Akzeptanz im Markt wird dann sicher auch wesentlich vom Preis der verfügbaren MACSec-Chips abhängen.

Letztlich liefern die neuen Standards einen weiteren Baustein für eine sichere Infrastruktur, der dort ansetzt, wo Sicherheit heute am wenigsten Beachtung findet: Denn viele Sicherheitskonzepte auf höheren Ebenen sind sich oft nicht der Tatsache bewusst, dass sie auf sehr schwachen Fundamenten aufbauen. MACSec könnte das ändern.

Dipl.-Ing. Markus Nispel (markus.nispel@enterasys.com) ist Director Solutions Architecture bei Enterasys Networks Germany GmbH.