1. Introduction
1. Introduction
Das Point-to-Point Protocol (PPP) [RFC1661] stellt ein erweiterbares Link Control Protocol (LCP) bereit, um Optionen der Verbindungsschicht zu verhandeln, einschließlich Authentifizierungsprotokollen. Durch die LCP-Optionsverhandlung kann das zu verwendende Authentifizierungsprotokoll (z. B. Password Authentication Protocol (PAP) [RFC1661] oder Challenge Handshake Authentication Protocol (CHAP) [RFC1994]) vor der Authentifizierungsphase bestimmt werden.
PPP-Authentifizierungsprotokolle (wie CHAP) eignen sich, wenn nur ein einzelner Authentifizierungsmechanismus verfügbar ist. Dieser Mechanismus wird in Einwahl-ISP-Bereitstellungen weit verbreitet eingesetzt, bei denen nur ein Mechanismus (CHAP) verwendet wird, es kann jedoch mehrere verfügbare Mechanismen geben, wie in drahtlosen Netzwerken, wo EAP größere Flexibilität bietet.
In einigen Bereitstellungen ist der verfügbare Authentifizierungsmechanismus vor der Authentifizierungsphase jedoch nicht bekannt. Eine Möglichkeit besteht darin, dass die Authentifizierung von einem Backend-Sicherheitsserver (z. B. RADIUS [RFC2865]) durchgeführt werden muss, wobei der Network Access Server (NAS) selbst keinen bestimmten Mechanismus implementiert. Eine weitere Möglichkeit besteht darin, dass der zu verwendende Authentifizierungsmechanismus vor der Authentifizierungsphase nicht bestimmt werden kann, wodurch der Authenticator zusätzliche Informationen anfordern kann, bevor er den geeigneten Authentifizierungsmechanismus festlegt.
Das Extensible Authentication Protocol (EAP) [RFC2284] unterstützt die Authentifizierung über der Verbindungsschicht (z. B. PPP [RFC1661], IEEE-802-Drahtnetzwerke [IEEE-802.1X] und IEEE-802.11-Drahtlos-LANs [IEEE-802.11]) und kann im "Pass-Through"-Betrieb über einen Backend-Authentifizierungsserver betrieben werden.
1.1. Designziele
Die Designziele von EAP umfassen die folgenden Aspekte:
[1] Allgemeingültigkeit. Der Authentifizierungsmechanismus sollte unabhängig von der verwendeten Verbindungsschicht sein und über mehrere Verbindungsschichten hinweg verwendet werden können.
[2] Erweiterbarkeit. Neue Authentifizierungsmechanismen sollten definiert werden können, ohne bestehende Verbindungsschicht-Implementierungen zu ändern.
[3] Flexibilität. Der zu verwendende Authentifizierungsmechanismus muss nicht vor Beginn der Authentifizierungsphase vorab festgelegt werden. Dies ermöglicht es dem Authenticator, Identitätsinformationen anzufordern, bevor der zu verwendende Authentifizierungsmechanismus bestimmt wird.
[4] Anpassungsfähigkeit. Unterstützung des Betriebs über mehrere Verbindungsschichten, einschließlich PPP, IEEE-802-Draht und IEEE-802.11-Drahtlos-LANs.
1.2. Terminologie
Dieses Dokument verwendet die folgenden Begriffe:
Authenticator Die Entität, die den Port (wie in [IEEE-802.1X] definiert) oder Kanal (wie in [RFC1661] definiert) am Ende des Authentifizierungsaustauschs steuert. Der Authenticator versucht, die Identität des Peers zu überprüfen, indem er die Authentifizierung erzwingt.
Backend Authentication Server Eine Entität, die mit dem Authenticator kommuniziert und die Authentifizierungsberechnungen für den Authenticator ausführt oder unterstützt. Wenn der Authenticator ein "Pass-Through"-Authenticator ist, führt der Backend-Authentifizierungsserver die Authentifizierungsmethode tatsächlich aus, während der Authenticator den Authentifizierungsaustausch lediglich weiterleitet.
Peer Die Entität im Authentifizierungsaustausch, für die vom Authenticator die Authentifizierung erzwungen wird.
EAP Method Ein Authentifizierungsmechanismus, der einen EAP-Authentifizierungsalgorithmus implementiert. In EAP werden Authentifizierungsmethoden nach Typ verhandelt, wie in Abschnitt 5 beschrieben.
EAP Peer Layer Der Teil des EAP-Protokolls, der auf dem EAP-Peer implementiert ist und für das Senden von EAP-Paketen, die sich auf die EAP-Methode beziehen, an die EAP-Methodenschicht und das Zurücksenden von EAP-Methodenantworten an die EAP-Schicht zuständig ist.
EAP Authenticator Layer Der Teil des EAP-Protokolls, der auf dem EAP-Authenticator implementiert ist und für das Senden von EAP-Paketen, die sich auf die EAP-Methode beziehen, an die EAP-Methodenschicht und das Zurücksenden von EAP-Methodenantworten an die EAP-Schicht zuständig ist.
EAP Method Layer Die Schicht, die den Authentifizierungsalgorithmus implementiert und EAP-Nachrichten über die EAP-Peer- und Authenticatorschichten sendet und empfängt.
EAP Layer Der Teil des EAP-Protokolls, der für das Senden und Empfangen von EAP-Paketen, die Implementierung von Duplikaterkennung und Retransmission sowie die Zustellung von EAP-Nachrichten an die EAP-Peer- und Authenticatorschichten zuständig ist.
Lower Layer Die Schicht, die für den Transport und Empfang von EAP-Rahmen zwischen Peer und Authenticator zuständig ist. EAP läuft über mehrere untere Schichten, einschließlich PPP, IEEE-802-Draht-LANs, IEEE-802.11-Drahtlos-LANs, UDP (L2TP [RFC2661] und IKEv2 [IKEv2]) und TCP [PIC].
Pass-Through Authenticator Der Authenticator, der EAP-Pakete, die vom Peer empfangen wurden, an den Backend-Authentifizierungsserver weiterleitet und EAP-Pakete, die vom Backend-Authentifizierungsserver empfangen wurden, an den Peer weiterleitet.
1.3. Anwendbarkeit
EAP eignet sich zur Bereitstellung von Authentifizierung über der Verbindungsschicht (wie PPP oder IEEE 802) und kann auch zur Bereitstellung von Netzwerk- oder Anwendungsschichtauthentifizierung verwendet werden, wenn EAP in höheren Protokollen (wie UDP, TCP oder RADIUS) getunnelt wird.
EAP ist darauf ausgelegt, einen allgemeinen Rahmen für die Netzwerkzugriffsauthentifizierung der Verbindungsschicht bereitzustellen. Es eignet sich nicht für einen allgemeinen Authentifizierungsrahmen wie SASL [SASL] für die Anwendungssichtauthentifizierung, wo zusätzliche Funktionen (wie Aushandlung, Sicherheitsschicht usw.) erforderlich sein können.
EAP eignet sich auch nicht zur Bereitstellung von Authentifizierung vor dem Verbindungsaufbau, da es auf den vom unteren Layer bereitgestellten Reihenfolgegarantien beruht und normalerweise eine vorherige Zuordnung zum Peer (wie eine PPP-Verbindung oder ein IEEE-802-Port) benötigt, um die Identität zu bestimmen.
Da EAP ein "Lock-Step"-Protokoll (lock step) ist, ist es bei der Verarbeitung von Fragmentierung und Reassemblierung ineffizient. Daher ist es im Allgemeinen vorzuziehen, dass Fragmentierung und Reassemblierung in der unteren Schicht (nicht in EAP) erfolgen, wenn die untere Schicht Fragmentierung und Reassemblierung unterstützt (z. B. wenn EAP über IP transportiert wird).