Passwort -Authentisierungsprotokolle

PAP - PPP Authentication Protocol

Das Password Authentication Protocol (PAP) ist im RFC 1334 beschrieben und setzt auf PPP auf. PAP ist ein Klartextpasswortsystem, wo Benutzername und Passwort solange gesendet werden, bis die Authentifizierung bestätigt oder die Verbindung abgebrochen wird. Problem ist, dass keine Verschlüsselung eingesetzt wird, die Zahl der möglichen Versuche unbegrenzt ist und dadurch eigentlich auch für DoS genutzt werden kann.

=

CHAP - Challenge Handshake Authentication Protocol

Das PPP Challenge Handshake Authentication Protocol (CHAP) ist im RFC 1994 beschrieben und stellt das klassische Challenge-Response-Verfahren mit einem Hash-Algorithmus dar. Der Authentifizierer sendet einen beliebigen Wert zum Authentisierenden, der mit einem Hash-Wert über den Benutzernamen, seinem Geheimnis und der gestellten Challenge antwortet. Zu beachten ist hier, dass bei CHAP der Authentifizierer das Geheimnis im Klartext kennen muss und keine Mechanismen für einen Passwortwechsel definiert werden.

=

MS - CHAPv2

Microsofts verwandte Realisierung von CHAP ist das Microsoft Challenge Handshake Authentication Protocol, MS-CHAPv1 (RFC 2433) ist dabei zu MS-CHAP v2 (RFC 2759) inkompatibel. Die beiden Verfahren sind Lan Manager Passwort kompatibel und verwenden daher auch MD4 und Single DES und sollten nicht verwendet werden.

=

802.1X - EAPoL

802.1X
802.1X

Bei 802.1X handelt es sich um ein Verfahren zur Port-basierten Zugangskontrolle und dient zur Absicherung eines LAN, besonders wenn (halb)öffentliche RJ45 Steckdosen im Geschäftslokal existieren, und WLAN. Es gestattet nur authentifizierten Clients (Supplicants) einen Zugang zum Netzwerk und für WEP sogar dynamische Schlüsselerstellung. Eine auf Layer 2 arbeitende Ethernet-Bridge oder WLAN-Access Point (Authenticator) exekutiert den Zugang von Clients über WLAN oder halböffentlichem Ethernet. Der Authenticator ist aber nicht der Authentication Server, der über den Zugang entscheidet.

EAP ist dabei das Framework für die Authentifizierung und man spricht, je nach Medientyp von EAPoL (EAP over LAN) oder von EAPoW (EAP over Wireless). Als Authentication Server wird RADIUS eingesetzt und zwischen Authenticator und Authentication Server kommt EAP over RADIUS zum Einsatz. Der Authenticator verhält sich dabei wie ein RADIUS-Client. Bei den EAP-Authentifizierungstypen, wo Schlüsselmaterial generiert wird, kann dieses als (Unicast-) Verteilungsschlüssel für (WEP-) Schlüssel fungieren. Erst nach erfolgreicher Authentisierung gibt der Authenticator alle Ports - und somit den Zugriff auf das dahinter liegende LAN frei.

=

EAP

EAP
EAP

Das PPP - Extensible Authentication Protocol, beschrieben im RFC 2284, ist ein Transportmechanismus für verschiedene zusätzliche Authentifizierungsvarianten über PPP, aufgeführt sind MD5-Challenge (CHAP mit MD5), One-Time Password (OTP) gemäß RFC 1938 und "Generic Token Card" (GTC) die eine allgemeine Erweiterungsmöglichkeit darstellt.

Aber nicht alle EAP Typen bieten die Möglichkeit Schlüsselmaterial auszutauschen, eine Erweiterung um solche Vertraulichkeitssicherung bieten PPP-EAP-TLS Authentication Protocol RFC 2716 wo EAP mit Mechanismen von TLS zur Session Key Generation und dem Einsatz von Zertifikaten beim Server und Client, kombiniert werden. Ebenso ist PEAP eine Möglichkeit und EAP-TTLS (EAP-tunneled TLS Authentication Protocol), dass mit einigen Erweiterungen für WLAN und der fehlenden Notwendigkeit Clientzertifikate zu benutzen auch andere Authentifizierungsmechanismen möglich macht und somit zu PEAP sehr ähnlich ist.

Bei EAP-MD5, EAP-OTP und EAP-GTC wird kein Schlüsselmaterial ausgetauscht. Mittlerweile gibt es auch EAP-SIM, welche die SIM-Karte eines Mobiltelefons benutzt. Manche Hersteller von WLAN Produkten implementieren auch EAP- SPEKE . LEAP (Lightweight EAP) von CISCO ist ein weiterer Typ aber nicht ganz EAP-konform.

=

Protected EAP

Protected EAP (PEAP) ist eine EAP Erweiterung von Cisco, Microsoft und RSA, bei der zuerst eine TLS-Verbindung aufgebaut wird und erst danach die Authentifizierung über EAP stattfindet. Dafür kann natürlich wiederum jeder EAP Typ eingesetzt werden. Vorteil ist, dass die Identitätsinformation bei der Übertragung geschützt ist. Natürlich ist wiederum auch Authentifizierung über TLS-Clientzertifikat möglich.

Für MS - Umgebungen kann auch auf MS-CHAP v2 über PEAP zurückgegriffen werden.

EAP und PEAP dienen eigentlich zur Authentifizierung von Rechnern in einem LAN, sind also von Bedeutung wenn der physische Netzwerkzugang nicht gesichert werden kann, wie öffentlich zugängliche Geschäftsstellen und wird immer wichtiger bei WLAN und RADIUS - Remote Authentication Dial In User Service RFC 2865 / RFC 3579 (RADIUS for EAP).

=

Radius

Im RFC 2865 und folgenden, ist das Remode Authentication Dial In User Service Protokoll beschrieben, welches für den Transport von Informationen über Authentifizierung, Autorisation und Konfiguration zwischen einem NAS (Network Access Server) als "Einwählpunkt" und einem Authentication Server im Hintergrund. Authentifizierungsmechanismus ist neben PAP und CHAP, wo der NAS eine aktive Aufgabe, wie das Stellen der Challenge, zu erfüllen hat, durch die RADIUS Extensions (RFC 2869 bzw. RFC 3579) auch EAP, und damit werden flexible Authentifizierungsarten möglich, wobei der NAS nur noch das Routing zum Authentication Server übernimmt.

=

Kerberos

Kerberos: http://web.mit.edu/kerberos/
Kerberos

Das Authentifizierungs- und Schlüsselverteilsystem Kerberos basiert auf den Protokollen von Needham und Schroeder und ist am MIT (Massachusetts Institute of Technology) entwickelt worden. Die aktuelle Version Kerberos V5 ist auch als RFC 1510 standardisiert.

Dreh- und Angelpunkt bei Kerberos ist das Key Distribution Center (KDC) welches das Authentication Service und das Ticket Granting Service betreibt und als Trusted Third Party fungiert.

=

Kerberos Terminologie

  • Ticket: serverbezogener Berechtigungsnachweis, den ein Client benutzt um sich bei einem Server zu authentisieren.
  • Ticket Granting Ticket: besonderes Ticket vom Authentication Service ausgestellt um das Ticket Granting Service nutzen zu können.
  • Principal: eine Einheit, der ein Ticket zugewiesen werden kann, was sowohl ein Benutzer als auch ein Dienst sein kann.
  • Authenticator: ein mit Session Key verschlüsselter Zeitstempel, um Replay-Attacken zu verhindern und den Besitz des Session Keys nachzuweisen.

=

Funktionsprinzip

Das Authentication Service kennt die Master Secrets (Schlüssel) der einzelnen Principals. Bei der Authentifizierung bekommt der Principal den Session Key für die Kommunikation mit dem Ticket Granting Service (TGS), mit diesem Master Secret verschlüsselt, übermittelt. Bei Passwort basiertem Kerberos wird dieses Secret aus dem Passwort abgeleitet.

Gleichzeitig erhält man ein Ticket Granting Ticket (TGT) für die Nutzung des Ticket Granting Service - dieses Ticket beinhaltet ebenfalls diesen Session Key, das Ticket ist aber mit dem Master Secret des Ticket Granting Service verschlüsselt.

Für die Kommunikation mit dem Ticket Granting Service übermittelt der Principal ebendieses TGT und einen Authenticator (Session Key verschlüsselter Zeitstempel). Das Ticket Granting Service kann das TGT mit seinem eigenen Master Secret entschlüsseln und mit dem erhaltenen Session Key den Zeitstempel prüfen - damit erkennt das TGS das der Principal vom Authentication Service erfolgreich authentifiziert worden ist.

Will Principal Alice mit Principal Bob authentifiziert und vertraulich kommunizieren, fordert Sie vom TGS ein entsprechendes Ticket an. Das TGS schickt an Alice einen Session Key für die Kommunikation mit Bob, und ein Ticket, das mit dem Master Secret von Bob verschlüsselt ist, das ebenso diesen Session Key beinhaltet.

Für die Kommunikation mit Bob übermittelt Alice ebendieses Ticket an Bob und einen Authenticator (Session Key verschlüsselter Zeitstempel). Bob kann dieses Ticket mit seinem eigenen Master Secret entschlüsseln und mit dem erhaltenen Session Key den Zeitstempel prüfen - damit erkennt Bob, dass Alice vom Authentication Service erfolgreich authentifiziert worden ist.

=

PKinit

In den Anfangszeiten von Kerberos war alles auf symmetrischer Verschlüsselung aufgebaut. Erst später wurde Kerberos um asymmetrische Kryptographie, vor allem bei der initialen Authentisierung, erweitert. Mit Protokollerweiterungen namens PKinit wurde die Verwendung von Zertifikaten in Kerberos integriert. Eine weitere Erweiterung existiert mit PKCross für die Cross-Realm Authentifizierung mittels Zertifikaten.

Bei PKinit wird ein signierter Authenticator vom Kerberos Client (Principal) zusammen mit seinem Zertifikatsdaten an das Authentication Service übermittelt. Nach erfolgreicher Verifizierung antwortet das Authentication Service in üblicher Weise, die Verschlüsselung der Antwort unterscheidet sich aber etwas. Bei der Verwendung von Diffie Hellman wird ein ephemeral - ephemeral Diffie Hellman Schlüssel verwendet, ansonsten wird ein zufällig generierter Schlüssel verwendet, der mit dem öffentlichen Schlüssel des Principal verschlüsselt, und mit dem privaten Schlüssel des Authentication Service, bzw. KDC signiert ist.

=