ࡱ> 7 bjbjUU &~7|7|lfffffffziiii"jz.mpmmmmananan$$ Dfan]nanananpffmmpppanfmfmpanppqqffmm viz$gian5> 0.s.anzpzzffff Vorbereiten des Einsatzes von IEEE 802.11-Netzwerken in Unternehmen (Engl. Originaltitel:  HYPERLINK "http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/ieee802.asp" Making IEEE 802.11 Networks Enterprise-Ready) Von Tom Fout Microsoft Corporation Verffentlicht: April 2001 Zusammenfassung Der Wunsch nach unbegrenzter Mobilitt und die verbesserten Features, die durch drahtlose Konnektivitt bereitgestellt werden, tragen dazu bei, dass IEEE802.11 als einer fr den Einsatz in Unternehmen geeigneten Technologie immer mehr Aufmerksamkeit zuteil wird. Bevor jedoch die drahtlose Kommunikation flchendeckend genutzt werden kann, muss eine weitere Konzentration auf die einfachere Handhabung, die Konfiguration und Verwaltung sowie Fragen der Sicherheit erfolgen. In diesem Dokument werden diese Aspekte der drahtlosen Kommunikation anhand der Errterung der Anforderungen fr RADIUS-Server, drahtlose Zugriffspunkte (Access Points, AP) und drahtlose Netzwerkkarten (Network Interface Cards, NICs) behandelt. Viele diese Technologien betreffen auch verkabelte Netzwerke, und ihre Verwendung kann zu einer Erhhung der Sicherheit in Netzwerken beitragen, die auf Ethernet oder vergleichbaren Technologien basieren. Abschlieend werden in diesem Artikel einige der Verfahren erlutert, durch die Windows2000 die auf dem Standard 802.11 basierenden drahtlosen Technologien untersttzt und erweitert. Einfhrung Dieses Whitepaper stellt technische Detailinformationen zu IEEE802.11 als einem gemeinsamen Standard fr drahtlose lokale Netzwerke (Local Area Networks, LANs) zur Verfgung. Dieses Dokument behandelt schwerpunktmig die folgenden Themen: Sicherheitsaspekte, Bereitstellungsaspekte, drahtlose Authentifizierung, Netzwerkkarten, Anforderungen fr Zugriffspunkte und RADIUS-Server, Roaming, nicht authentifizierter Zugriff und Ad-hoc- IEEE802.11. Der Standard IEEE802.11 IEEE 802.11 ist ein gemeinsamer Standard fr drahtlose LANs. Er verwendet das Protokoll CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance, Vielfachzugriff mit Trgerkennung und Kollisionsvermeidung) auf MAC-Ebene (Media Access Control). Dieser Standard ermglicht auf der Bitbertragungsschicht (physische Schicht) bertragungen sowohl mithilfe des DS-Spreizverfahrens (Direct-Sequency) als auch mithilfe des FH-Spreizverfahrens (Frequency-Hopping). Die maximale Datenrate, die von diesem Standard ermglicht wurde, lag ursprnglich bei 2Mbit/s. Eine schnellere Version mit einer Definition der physischen Schicht gem der IEEE802.11b-Spezifikation ermglicht anhand von bertragungen mittels DS-Spreizverfahren eine Datenrate von bis zu 11Mbit/s. Das Komitee fr IEEE-Standards hat mit der IEEE802.11a-Spezifikation zudem Kriterien fr die physische Schicht definiert. Diese Definition basiert auf einem Mehrtrgerverfahren (Orthogonal Frequency Division Multiplexing, OFDM), das Datenbertragungsraten von bis zu 54Mbit/s ermglicht. Sicherheitsaspekte Whrend IEEE802.11 in drahtlosen LAN-Umgebungen bereits eine weite Verbreitung erfahren hat, wurden bezglich der Sicherheit drahtloser Netzwerke im Allgemeinen eine Reihe von Bedenken laut. Der Standard IEEE802.11 fr drahtlose LANs definiert Authentifizierungs- und Verschlsselungsdienste basierend auf dem WEP-Algorithmus (Wired Equivalent Privacy). Der WEP-Algorithmus sieht fr die Authentifizierung und Verschlsselung die Verwendung eines geheimen 40-Bit-Schlssels vor. Viele IEEE802.11-Implementierungen ermglichen darber hinaus die Verwendung geheimer 104-Bit-Schlssel. Der Standard definiert jedoch kein Schlsselverwaltungsprotokoll und geht davon aus, dass die geheimen, gemeinsamen Schlssel ber einen sicheren, von IEEE802.11 unabhngigen Kanal an die drahtlose IEEE802.11-Station (STA) bermittelt werden. Das Fehlen eines WEP-Schlsselverwaltungsprotokolls stellt eine grundstzliche Einschrnkung fr die Gewhrleistung der Sicherheit beim Einsatz von IEEE802.11 dar, insbesondere in drahtlosen Infrastrukturnetzwerken, die eine groe Anzahl von Stationen aufweisen. Beispielhaft hierfr sind Unternehmensgelnde und ffentliche Orte wie Flughfen und Einkaufszentren. Das Fehlen von Authentifizierungs- und Verschlsselungsdiensten wirkt sich auch auf den Betrieb in drahtlosen Ad-hoc-Netzwerken aus, die sich durch die Peer-zu-Peer-Kommunikation zwischen Benutzern auszeichnen, z.B. in einem Tagungsraum. Dies alles macht deutlich, dass aufgrund der noch greren Bedeutung von Authentifizierung und Verschlsselung in drahtlosen Umgebungen Zugriffssteuerungs- und Sicherheitsmechanismen notwendig sind, die das in IEEE802.11 angegebene Schlsselverwaltungsprotokoll umfassen. Bereitstellungsaspekte Aspekte, die die Bereitstellung von IEEE802.11 betreffen, lassen sich in drei Hauptgruppen unterteilen: Benutzerverwaltung, Schlsselverwaltung und Sicherheit. Benutzerverwaltung Die Anbindung an bestehende Tools zur Benutzerverwaltung ist unverzichtbar [RADIUS (Remote Authentication Dial-In User Service) und LDAP-basierte Verzeichnisse (Lightweight Directory Access Protocol)]. Ein Beispiel hierfr wre die Erstellung einer Gruppe, der der Zugriff ber eine drahtlose Verbindung ermglicht wird. Sobald diese Gruppe einschlielich der entsprechenden Zugriffsberechtigungen eingerichtet wurde, wird jedem Benutzer, der Mitglied der Gruppe ist, der Zugriff ber eine drahtlose Verbindung gestattet. In groen Netzwerkumgebungen kann die Identifizierung anhand des Benutzernamens leichter verwaltet werden als der derzeit verwendete Identifizierungsmechanismus mittels MAC-Adresse. Die Identifizierung des Benutzers anhand seines Namens bietet darber hinaus die Vorteile der Nutzung auf Benutzerebene, der Kontenverwaltung und der berwachung. Schlsselverwaltung Die Verwaltung statischer Schlssel auf Stationen und Zugriffspunkten (Access Points, APs) gestaltet sich problematisch. Darber hinaus sind fr Lsungen, die die proprietre Schlsselverwaltung einsetzen, getrennte Benutzerdatenbanken erforderlich. Sicherheit Fr 802.11 gelten die folgenden Sicherheitseinschrnkungen: Keine Authentifizierung auf Paketebene Anflligkeit fr unberechtigte Zugriffe, die den Abbruch einer Funkverbindung herbeifhren knnen Keine Benutzeridentifikation und -authentifizierung Keine Untersttzung fr zentrale Authentifizierung, Autorisierung und Kontenverwaltung Die RC4-Streamverschlsselung ist anfllig fr Klartextangriffe Einige Implementierungen leiten WEP-Schlssel von Kennwrtern ab Keine Untersttzung fr erweiterte Authentifizierung, z.B. durch Tokenkarten, Zertifikate, Smartcards, One-Time-Kennwrter, biometrische Sicherheitsvorrichtungen usw. Probleme der Schlsselverwaltung, z.B. erneute Verwendung globaler Schlssel und keine dynamische, auf STA-Unicast-Sitzungen basierende Schlsselverwaltung Derzeitige Sicherheitsoptionen fr IEEE802.11 Die von IEEE802.11 bereitgestellten Sicherheitsoptionen umfassen Authentifizierungs- und Verschlsselungsdienste, die auf dem WEP-Algorithmus basieren. Der WEP-Algorithmus sieht fr die Authentifizierung und Verschlsselung die Verwendung eines geheimen 40-Bit-Schlssels vor. Ergnzend zu dem geheimen 40-Bit-Schlssel ermglichen zahlreiche IEEE802.11-Implementierungen die Verwendung von geheimen 104-Bit-Schlsseln. Beim Einsatz von IEEE802.11 ist es nicht erforderlich, dass alle Stationen dieselben WEP-Schlssel verwenden. Zudem ist es mglich, dass eine Station zwei Stze gemeinsamer Schlssel verwendet: einen stationsspezifischen Unicast-Sitzungsschlssel und einen Multicast- oder globalen Schlssel. Aktuelle IEEE802.11-Implementierungen untersttzen in erster Linie Multicast- oder globale Schlssel; in absehbarer Zeit kann jedoch auch mit der Untersttzung von stationsspezifischen Unicast-Sitzungsschlsseln gerechnet werden. Authentifizierungsdienste: Open System und Shared Key IEEE802.11 untersttzt zwei Arten von Authentifizierungsdiensten: Open System und Shared Key. Die Art der "aufgerufenen" Authentifizierung wird durch den AuthenticationType-Parameter gesteuert, whrend die Art der von einer Station "akzeptierten" Authentifizierung von Sicherheitsmechanismen gesteuert wird, die durch das MIB-Attribut (Management Information Base) dot11AuthenticationType definiert werden. Open System ist ein Standardalgorithmus fr die Null-Authentifizierung, der einen aus zwei Schritten bestehenden Prozess die Identittsassertion und eine Authentifizierungsanforderung gefolgt von dem Authentifizierungsergebnis umfasst. Shared Key untersttzt die Authentifizierung einer Station entweder als Mitglied derjenigen Stationen, denen ein gemeinsamer, geheimer Schlssel bekannt ist, oder als Mitglied der Stationen, denen dieser Schlssel nicht bekannt ist. Der Standard setzt derzeit voraus, dass der gemeinsame Schlssel ber einen sicheren, von IEEE802.11 unabhngigen Kanal an die teilnehmenden Stationen bermittelt wird. WEP stellt Verschlsselungsdienste bereit, um autorisierte Benutzer eines drahtlosen LANs vor Abhrversuchen zu schtzen, und stellt Attribute zur Gewhrleistung der physischen Sicherheit bereit, die denen eines verkabelten LANs vergleichbar sind. WEP ist ein symmetrischer Algorithmus, in dem derselbe Schlssel fr die Ver- und Entschlsselung verwendet wird. Der geheime Schlssel wird mit einem Initialisierungsvektor (IV) verknpft, was zu einem Anfangswert fhrt, der als Eingabe fr einen Pseudozufallszahlen-Generator (Pseudo-Random Number Generator, PRNG) verwendet wird. Mithilfe des PRNGs wird die Schlsselfolge generiert, die mathematisch mit dem Nachrichtentext kombiniert und mit dem Integrittsprfwert (Integrity Check Value, ICV) verknpft wird. Das Triplett {IV, Nachrichtentext, ICV} bildet die tatschlichen Daten, die in einem IEEE802.11-Datenrahmen gesendet werden. Whrend der geheime Schlssel ber lngere Zeit konstant bleibt, wird der IV regelmig, und zwar so hufig wie jede MAC-Protokolldateneinheit (MAC Protocol Data Unit, MPDU), gendert. Die Hufigkeit, mit der IV-Werte gendert werden, hngt vom Grad der Vertraulichkeit ab, die vom WEP-Algorithmus angefordert wird. Die nderung des IVs nach jedem MPDU ist die optimale Methode zur Aufrechterhaltung der Wirksamkeit von WEP. Fehlen eines WEP-Schlsselverwaltungsprotokolls Das Fehlen eines WEP-Schlsselverwaltungsprotokolls stellt eine Einschrnkung fr die Bereitstellung von IEEE802.11-Sicherheitsdiensten dar, insbesondere in drahtlosen Infrastrukturnetzwerken, die eine groe Anzahl von Stationen aufweisen. Das Fehlen von Authentifizierungs- und Verschlsselungsdiensten wirkt sich zudem auf den Betrieb in drahtlosen Ad-hoc-Netzwerken aus. Die derzeit von IEEE802.11 bereitgestellte Sicherheitsoption fr die Zugriffssteuerung passt sich nicht angemessen an ausgedehnte Infrastrukturnetzwerke (z.B. Unternehmensgelnde oder ffentliche Orte) oder an Ad-hoc-Netzwerke an. Beim Roaming von Stationen von einem Zugriffspunkt zu einem anderen fhrt das Fehlen eines zugriffspunktbergreifenden Protokolls (Inter-Access Point Protocol, IAPP) darber hinaus zu weiteren Problemen hinsichtlich der Schlsselverwaltung. IEEE802.1X IEEE802.1X ist der Entwurf fr einen Standard fr die anschlussbasierte Netzwerkzugriffssteuerung. Mithilfe dieses Standards soll der authentifizierte Netzwerkzugriff fr Ethernet-Netzwerke ermglicht werden. Die anschlussbasierte Netzwerkzugriffssteuerung verwendet die physischen Merkmale vermittelter LAN-Infrastrukturen, um eine Methode zur Authentifizierung von Gerten bereitzustellen, die an einen LAN-Anschluss angeschlossen sind, und um den Zugriff auf den Anschluss zu verhindern, falls der Authentifizierungsprozess fehlschlgt. Authentifikator oder Endsystem (Supplicant) Ein LAN-Anschluss, auch als Anschlusszugriffsentitt (Port Access Entity, PAE) bezeichnet, kann im Rahmen der Interaktion zum Zwecke der Zugriffssteuerung eine von zwei Funktionen bernehmen: die des Authentifikators oder die des Endsystems. Ein Authentifikator ist ein Anschluss, der die Authentifizierung "erzwingt", bevor er den Zugriff auf die ber diesen Anschluss verfgbaren Dienste zulsst. Das Endsystem ist ein Anschluss, der den Zugriff auf die ber den Anschluss des Authentifikators verfgbaren Dienste "anfordert". Darber hinaus bernimmt der Authentifizierungsserver ebenfalls die Authentifizierungsfunktion. Er berprft die Anmeldeinformationen des Endsystems anstelle des Authentifikators und antwortet dem Authentifikator, indem er ihm mitteilt, ob das Endsystem befugt ist, auf die Dienste des Authentifikators zuzugreifen. Bei dem Authentifizierungsserver kann es sich um eine separate Entitt handeln, seine Funktionalitt kann sich jedoch auf derselben Entitt wie der Authentifikator befinden. Kontrollierte und nicht kontrollierte Anschlsse Die portbasierte Zugriffssteuerung des Authentifikators definiert ber einen einzelnen physischen LAN-Anschluss zwei logische Zugriffspunkte fr das LAN, wie in Abbildung1 veranschaulicht wird.  Abbildung1: Kontrollierte und nicht kontrollierte Anschlsse Der erste logische Zugriffspunkt (der als "Nicht kontrollierter Anschluss" bezeichnete Anschluss) ermglicht den unkontrollierten Austausch zwischen dem Authentifikator und anderen Systemen im LAN, unabhngig vom Autorisierungsstatus des jeweiligen Systems. Der zweite logische Zugriffspunkt (der als "Kontrollierter Anschluss" bezeichnete Anschluss) ermglicht den Austausch zwischen einem System im LAN und den Diensten des Authentifikators nur dann, wenn das jeweilige System befugt ist, auf die Dienste zuzugreifen. Verwenden von IEEE802.1X fr die drahtlose Authentifizierung Mithilfe eines RADIUS-Servers (Remote Authentication Dial-In Service) fr die Authentifizierung von Clientanmeldeinformationen kann IEEE802.1X fr die drahtlose Authentifizierung verwendet werden. Damit Datenpakete eines bestimmten Clients zuverlssig von einem drahtlosen Zugriffspunkt identifiziert werden knnen, ist eine Erweiterung des IEEE802.1X-Basisprotokolls erforderlich. Die Erweiterung erfolgt, indem dem Client und dem drahtlosen Zugriffspunkt im Rahmen des Authentifizierungsverfahrens ein Authentifizierungsschlssel bergeben wird. Nur authentifizierte Clients kennen den Authentifizierungsschlssel, mit dem smtliche von einem Client gesendeten Pakete verschlsselt werden. Authentifizierung: Das Verfahren im berblick Die folgenden Schritte stellen berblicksartig das Verfahren dar, das von einem Zugriffspunkt und einem RADIUS-Server zur Authentifizierung einer Station verwendet wird. Ohne einen gltigen Authentifizierungsschlssel unterbindet ein Zugriffspunkt den gesamten Datenfluss, der ber ihn erfolgt. Wenn eine drahtlose Station (ein Endsystem) in den Funkbereich eines drahtlosen Zugriffspunktes eintritt, gibt der drahtlose Zugriffspunkt eine Herausforderung an die drahtlose Station aus. Bei Erhalt der Herausforderung vom Zugriffspunkt antwortet die Station mit ihrer Identitt. Der Zugriffspunkt leitet die Identitt der Station dann an den RADIUS-Server (den Authentifizierungsserver) weiter, um die Authentifizierungsdienste aufzurufen. Anschlieend fordert der RADIUS-Server die Anmeldeinformationen fr die Station an, wobei er den Typ der Anmeldeinformationen angibt, die erforderlich sind, um die Identitt der Station zu besttigen. Die Station sendet ihre Anmeldeinformationen an den RADIUS-Server. Werden die Anmeldeinformationen der Station validiert, bermittelt der RADIUS-Server einen Authentifizierungsschlssel an den Zugriffspunkt. Der Authentifizierungsschlssel ist verschlsselt, so dass nur der Zugriffspunkt darauf zugreifen kann. (Beachten Sie, dass Anforderungen, die zwischen der Station und dem RADIUS-Server gesendet werden, den "nicht kontrollierten Anschluss" des Zugriffspunktes passieren, da die Station nicht direkt mit dem RADIUS-Server kommunizieren kann. Der Zugriffspunkt lsst die Kommunikation ber den "kontrollierten" Anschluss nicht zu, da die Station nicht ber einen Authentifizierungsschlssel verfgt.) Der Zugriffspunkt verwendet den vom RADIUS-Server erhaltenen Authentifizierungsschlssel, um stationsspezifische Unicast-Sitzungsschlssel und Multicast- bzw. globale Authentifizierungsschlssel an die Station zu bermitteln. Der globale Authentifizierungsschlssel muss verschlsselt sein. Um dies zu gewhrleisten, muss die verwendete EAP-Methode (Extensible Authentication Protocol) in der Lage sein, im Rahmen des Authentifizierungsprozesses einen Verschlsselungsschlssel zu generieren. Transportschichtsicherheit (Transport Level Security, TLS) Transportschichtsicherheit (Transport Level Security, TLS) ermglicht die gegenseitige Authentifizierung, die Aushandlung der verwendeten Verschlsselungsmechanismen bei Gewhrleistung der Integritt und den Schlsselaustausch zwischen zwei Endpunkten. Vor diesem Hintergrund empfiehlt sich die Verwendung von EAP-TLS, um die TLS-Mechanismen innerhalb von EAP bereitzustellen. Im Anschluss an die Authentifizierung sollte das Protokoll IEEE802.1X so konfiguriert werden, dass die erneute Authentifizierung der Station in regelmigen, festgelegten Abstnden angefordert wird. Authentifizierung: Das Verfahren im Detail Der drahtlose Zugriffspunkt ist so konfiguriert, dass ohne gltige Authentifizierungsschlssel keine Datenpakete an ein verkabeltes Netzwerk, z.B. ein Ethernet-Netzwerk, oder an eine andere drahtlose Station weitergeleitet werden. Der drahtlose Zugriffspunkt und die drahtlose Station mssen einen Multicast- bzw. globalen Authentifizierungsschlssel untersttzen und knnen darber hinaus die Untersttzung fr einen stationsspezifischen Unicast-Sitzungsschlssel bieten. Der drahtlose Zugriffspunkt verfgt ber einen Prozess, der Abfragen im Hinblick auf IEEE802.1X-Verkehr mit oder ohne Authentifizierungsschlssel durchfhrt. Wenn der Zugriffspunkt eine neue Station ermittelt, die eine Funkverbindung herstellen mchte, bermittelt der IEEE802.1X-Prozess des Zugriffspunktes eine EAP-Request-Nachricht (Identity) an die neue Station. Wenn der IEEE802.1X-Prozess des Zugriffspunktes eine EAP-Start-Nachricht von einer Station empfngt, bermittelt der IEEE802.1X-Prozess eine EAP-Request-Nachricht (Identity) an die entsprechende Station. Wenn eine Station eine Funkverbindung zu einem neuen Zugriffspunkt aufbauen mchte, bermittelt sie eine EAP-Start-Nachricht. Falls kein Benutzer an das Gert angemeldet ist, bermittelt eine Station als Antwort auf eine EAP-Request-Nachricht (Identity) eine EAP-Response-Nachricht (Identity) mit dem Namen des Gerts. Falls ein Benutzer an das Gert angemeldet ist, bermittelt eine Station als Antwort auf eine EAP-Request-Nachricht (Identity) eine EAP-Response-Nachricht (Identity) mit dem Namen des Benutzers. Der drahtlose Zugriffspunkt leitet die EAP-Response-Nachricht (Identity) an einen RADIUS-Server weiter. Als Antwort auf die EAP-Response-Nachricht (Identity) der Station sendet der RADIUS-Server eine EAP-Request-Nachricht (entweder MD5 Challenge oder TLS). (TLS ist fr die drahtlose Kommunikation erforderlich. Andernfalls ist der RADIUS-Server nicht in der Lage, die sichere bertragung der Multicast- bzw. globalen Authentifizierungsschlssel und, falls erforderlich, der stationsspezifischen Sitzungsschlssel an die Station zu gewhrleisten). Der drahtlose Zugriffspunkt leitet die EAP-Request-Nachricht vom RADIUS-Server an die Station weiter. Die Station bermittelt eine EAP-Response-Nachricht mit ihren Anmeldeinformationen ber den drahtlosen Zugriffspunkt an den RADIUS-Server. Der drahtlose Zugriffspunkt leitet die Anmeldeinformationen der Station an den RADIUS-Server weiter. Der RADIUS-Server berprft die Anmeldeinformationen der Station und generiert eine Erfolgsnachricht fr die Station. Die Antwort des RADIUS-Servers an den drahtlosen Zugriffspunkt enthlt die Stationsnachricht und den Verschlsselungsschlssel, der vom EAP-TLS-Sitzungsschlssel abgeleitet wurde. Der drahtlose Zugriffspunkt generiert den Multicast- bzw. globalen Authentifizierungsschlssel, indem er eine Zufallszahl generiert oder ihn aus zuvor festgelegten Werten auswhlt. Sobald der drahtlose Zugriffspunkt die Nachricht des RADIUS-Servers erhlt, leitet er die Erfolgsnachricht an die Station weiter. Der drahtlose Zugriffspunkt bermittelt eine EAP-Key-Nachricht an die Station, die den Multicast- bzw. globalen Authentifizierungsschlssel enthlt, der mithilfe des sitzungsspezifischen Verschlsselungsschlssels verschlsselt wurde. Wenn der drahtlose Zugriffspunkt und die drahtlose Station stationsspezifische Unicast-Sitzungsschlssel untersttzen, verwendet der Zugriffspunkt den vom RADIUS-Server gesendeten Verschlsselungsschlssel als stationsspezifischen Unicast-Sitzungsschlssel. Wenn der drahtlose Zugriffspunkt den Multicast- bzw. globalen Authentifizierungsschlssel ndert, generiert er EAP-Key-Nachrichten: Jede Nachricht enthlt den neuen Multicast- bzw. globalen Authentifizierungsschlssel, der mit dem stationsspezifischen Unicast-Sitzungsschlssel der jeweiligen Station verschlsselt wurde. Falls die entsprechende Untersttzung vorhanden ist, fgt der drahtlose Zugriffspunkt den stationsspezifischen Unicast-Sitzungsschlssel zur stationsspezifischen Liste der Unicast-Sitzungsschlssel hinzu. Bei Erhalt der EAP-Key-Nachricht verwendet die Station den stationsspezifischen Unicast-Sitzungsschlssel, um den Multicast- bzw. globalen Authentifizierungsschlssel zu entschlsseln. Wenn der drahtlose Zugriffspunkt und die drahtlose Station stationsspezifische Unicast-Sitzungsschlssel untersttzen und ein Multicast- bzw. globaler Authentifizierungsschlssel empfangen wurde, wird der vom EAP-TLS-Sitzungsschlssel abgeleitete Sitzungsschlssel als stationsspezifischer Unicast-Sitzungsschlssel an die drahtlosen Station bergeben. Bei Erhalt der Authentifizierungsschlssel muss der Treiber der drahtlosen Netzwerkkarte die Netzwerkkarte der drahtlosen Station programmieren. Sobald die Programmierung der Authentifizierungsschlssel abgeschlossen ist, ruft die Station DHCP (Dynamic Host Configuration Protocol) auf, um den DHCP-Prozess neu zu starten. Anforderungen fr Netzwerkkarten Die Einbeziehung von IEEE802.11 sowohl im Infrastruktur- als auch im Ad-hoc-Netzwerkmodus kann durch die Reduktion der Komplexitt der NIC-Konfiguration erheblich verbessert werden. Es wird empfohlen, die NIC-Konfiguration zu automatisieren, um eine Benutzerintervention so weit wie mglich zu vermeiden. Aspekte der NIC-Konfiguration Die zentralen Aspekte der NIC-Konfiguration, die besondere Beachtung erfordern, sind die folgenden: Konfiguration des Clients unter unterschiedlichen Betriebsszenarien Neukonfiguration des Clients beim Wechsel zwischen Betriebsszenarien Konfiguration des Clients zur Sicherung des Zugriffs auf drahtlose LANs Erweiterungen fr IEEE802.11-NICs Ergnzend zu den zuvor aufgefhrten Konfigurationsaspekten sollte die IEEE802.11-NIC die folgenden Erweiterungen umfassen: WEP-Authentifizierung (Wireless Equivalent Privacy) Ergnzend zu den Authentifizierungsdiensten Open System und Shared Key sollte die IEEE802.11-NIC in der Standardeinstellung eine dritte Authentifizierungsmethode untersttzen. Wenn die NIC vorab mit einem gemeinsamen WEP-Schlssel konfiguriert wurde, versucht der Standard-Authentifizierungsalgorithmus zuerst die Shared Key-Authentifizierung von IEEE802.11 durchzufhren. Falls diese Authentifizierung fehlschlgt oder die NIC nicht vorab mit einem gemeinsamen WEP-Schlssel konfiguriert wurde, sollte die NIC auf die Open System-Authentifizierung zurckgreifen. Stromversorgungsmodi Eine IEEE802.11-NIC sollte zwei Einstellungen fr die Stromversorgung untersttzen: eine fr Gerte, die an eine Wechselstromquelle angeschlossen sind, und eine zweite Einstellung fr Gerte, die eine Batterie verwenden. Der Standardmodus (Wechselstrom) sollte so konfiguriert sein, dass die Betriebsgeschwindigkeit des Gerts maximiert wird; die Einstellung fr die Stromzufuhr mittels Batterie sollte so konfiguriert sein, dass der Stromverbrauch des Gerts minimiert wird. Clientname Der Clientname wird an die IEEE802.11-NIC bergeben und zu unterschiedlichen Zwecken eingesetzt. Viele Anbieter von 802.11-NICs und Zugriffspunkten verwenden diese Informationen, um Clientinformationen am Zugriffspunkt zu melden und auf diesem zu verwalten. Standardmig wird als Clientname der Name des Gerts verwendet. Medienerkennung Die IEEE802.11-NIC muss die Medienerkennung untersttzen und ein Medienverbindungsereignis anzeigen, sobald eine Funkverbindung zu einem neuen Zugriffspunkt aufgebaut wird. Das Verbindungsereignis weist den Transport darauf hin, dass er auf einen mglichen Subnetzwechsel achten muss. Ein Trennereignis ist nur dann erforderlich, wenn die NIC ber keinerlei Konnektivitt mehr verfgt. NDIS-nderungen Im Folgenden werden die nderungen umrissen, die an der Spezifikation fr Netzwerkgerte-Schnittstellen (Network Device Interface Specification, NDIS) vorgenommen wurden, um die zuvor beschriebenen NIC-Erweiterungen zu untersttzen. Der Gertename wird whrend des Systemstarts an den NIC-Treiber bergeben. Diese Informationen werden von einigen NICs und Zugriffspunkten zu unterschiedlichen Verwaltungszwecken verwendet. Der Stromversorgungsstatus wird whrend des Systemstarts und bei jeder Statusnderung an den NIC-Treiber bergeben. Als Minimalanforderung muss erfllt sein, dass dem NIC-Treiber ein Wechsel zur Wechselstromeinstellung oder zur Batterieeinstellung angezeigt wird. NDIS ruft PnPEventNotifyHandler() des Miniports auf, wodurch der Miniport bei Profilnderungen mit dem Stromversorgungsstatus D0 initialisiert oder auf diesen festgelegt wird. Der PnPEvent-Parameter entspricht NdisDevicePnPEventPowerProfileChanged, und InformationBuffer zeigt auf eine ULONG-Variable mit folgendem Inhalt: typedef enum _NDIS_POWER_PROFILE { NdisPowerProfileBattery, NdisPowerProfileAcOnLine } NDIS_POWER_PROFILE, *PNDIS_POWER_PROFILE; NDIS-Objektkennungen (Object Identifiers, OIDs) Um die zuvor beschriebene neue Funktionalitt zu ermglichen, muss der IEEE802.11-NDIS-Treiber eine Reihe neuer OIDs bereitstellen. Diese OIDs sind ber Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) verfgbar und mssen untersttzt werden. Diese Anforderung kann nur erfllt werden, wenn die fr das drahtlose LAN (Wireless LAN, WLAN) verwendete NIC-Hardware die entsprechende Funktionalitt untersttzt. In der folgenden Tabelle finden Sie eine Zusammenfassung der abhngigen Objekte fr die drahtlose Kommunikation. Die NDIS-Typen, die mit diesen WLAN-OIDs verwendet werden, finden Sie in AnhangA. WLAN-abhngige Objekte fr die drahtlose Kommunikation OID (Hexa-dezimalwert) OID-NameStatus-anzeige Abfragen Festlegen Obligatorisch0D010101OID_802_11_BSSIDXXX0D010102OID_802_11_SSIDXXX0D010203OID_802_11_NETWORK_ TYPES_SUPPORTEDX0D010204OID_802_11_NETWORK_ TYPE_IN_USEXXX0D010205OID_802_11_TX_POWER_LEVELXX0D010206OID_802_11_RSSIXXX0D010207OID_802_11_RSSI_TRIGGERXXOID (Hexa-dezimalwert) OID-NameStatus-anzeige Abfragen Festlegen Obligatorisch0D010108OID_802_11_INFRASTRUCTURE_ MODEXXX0D010209OID_802_11_FRAGMENTATION_ THRESHOLDXX0D01020AOID_802_11_RTS_THRESHOLDXX0D01020BOID_802_11_NUMBER_OF_ ANTENNASX0D01020COID_802_11_RX_ANTENNA_ SELECTEDXX0D01020DOID_802_11_TX_ANTENNA_ SELECTEDXX0D01020EOID_802_11_SUPPORTED_ RATESXX0D010210OID_802_11_DESIRED_RATESXX0D010211OID_802_11_CONFIGURATIONXXX0D020212OID_802_11_STATISTICSX0D010113OID_802_11_ADD_WEPXX0D010114OID_802_11_REMOVE_WEPXX0D010115OID_802_11_DISASSOCIATEXX0D010216OID_802_11_POWER_MODEXX0D010217OID_802_11_BSSID_LISTXX0D01011AOID_802_11_BSSID_LIST_SCANXX0D010118OID_802_11_AUTHENTICATION_ MODEXXX0D010119OID_802_11_PRIVACY_FILTERXXSSID-Verbindungsanforderung/-algorithmus (Service Set Identifier, Dienstsatzidentifizierung) Die NIC sollte standardmig ohne Konfiguration eines Netzwerknamens installiert werden. Diese Konfiguration sollte den nachfolgend aufgefhrten Algorithmus einhalten: Falls keine Funkverbindung zu einem Netzwerk besteht, sollte die NIC eine Funkverbindung zu jeder Netzwerkinfrastruktur aufbauen, die ihren Netzwerknamen mittels Beacon-Nachricht signalisiert. Falls der Verbindungsaufbau fehlschlgt, muss der Versuch unternommen werden, eine Funkverbindung zu einer anderen Netzwerkinfrastruktur, falls verfgbar, aufzubauen. Diese Vorgehensweise wird wiederholt, bis keine Infrastrukturen mehr verfgbar sind. Falls keine Funkverbindung aufgebaut werden konnte, sollte die NIC, falls zulssig, in den Ad-hoc-Netzwerkmodus wechseln, bis eine neue Infrastruktur verfgbar wird. Wenn bei bestehender Funkverbindung zu einem Netzwerk die festgelegte Dienstsatzidentifzierungs-OID aufgerufen wird, verhlt sich die NIC so, als ob der Verbindungsaufbau zu diesem Netzwerk fehlgeschlagen wre. Durch Festlegen der Dienstsatzidentifizierung oder durch einen Aufruf von OID_802_11_INFRASTRUCTURE_MODE sollte diese Verbindungsanforderung/dieser Algorithmus zurckgesetzt werden. Anforderungen fr Zugriffspunkte Fr die Einbindung von Sicherheitsdiensten in Zugriffspunkte bentigt IEEE802.1X zustzliche Tools. Bei diesen Tools handelt es sich um Verwendung der SSID als EAP-Identity-Text und die RADIUS-Untersttzung. SSID als EAP-Identity-Text Die IEEE802.11-SSID sollte in das EAP-Identity/Request-Nachrichtenfeld kopiert werden. (Detailinformationen zur Verwendung der EAP-Request-Nachricht (Identity) wurden bereits zuvor in diesem Dokument bereitgestellt. Detailinformationen zur Verwendung der EAP-Identity/Request-Zeichenfolge finden Sie in AnhangB.) RADIUS-Untersttzung Der RADIUS-Client des Zugriffspunktes sollte die erneute bertragung verloren gegangener Pakete implementieren. In Umgebungsszenarien (mittels EAP-TLS) mit hohem Strpegel, die zahlreiche Phasen des Datenaustauschs durchlaufen, wird es empfohlen, fr den RADIUS-Client die erneute bertragung basierend auf einem Timeout zu implementieren. (Der Timeout kann in Abhngigkeit von den Besonderheiten des Netzwerkes gendert werden). Hierfr ist es erforderlich, dass der RADIUS-Server den Status aufrecht erhlt und in der Lage ist, erneuten bertragungen Rechnung zu tragen. Failoverschutz Der RADIUS-Client des Zugriffspunktes sollte darber hinaus den Failoverschutz implementieren. Dies erhht die Zuverlssigkeit des Zugriffs des RADIUS-Clients auf den RADIUS-Server, indem es dem RADIUS-Client ermglicht wird, seine Transaktionen an einen anderen RADIUS-Server zu richten, falls der primre RADIUS-Server ausfllt. Hierdurch wird ein Einzelpunktversagen verhindert. WEP-Schlssel Der WEP-Schlssel kann im Zugriffspunkt konfiguriert oder vom Zugriffspunkt mithilfe eines Zufallszahlengenerators generiert werden. Durch die Konfiguration desselben WEP-Schlssels in mehreren Zugriffspunkten kann jeder Zugriffspunkt eine Station sofort authentifizieren, sobald der Zugriffspunkt eine IEEE802.11-Authentifizierung mit dem korrekten WEP-Schlssel durchfhrt. IEEE802.1X-Schlsselnachricht Durch die Einbindung einer IEEE802.1X-Schlsselnachricht stellt IEEE802.1X einen besser skalierbaren und verwaltbaren Mechanismus fr die Zugriffssteuerung zur Verfgung. Nachdem die IEEE802.1X-Authentifizierung erfolgreich abgeschlossen wurde, wird der EAPOL-Schlssel (EAP-over-LAN) vom Zugriffspunkt an die Station gesendet. Diese Nachricht enthlt einen WEP-Schlssel, mit dessen Hilfe der von IEEE802.11 verwendete Verschlsselungsschlssel generiert wird. Fr diese Nachricht ist jedoch eine EAP-Authentifizierungsmethode, wie z.B. EAP-TLS, erforderlich. Mithilfe dieses vom RADIUS-Server erstellten sitzungsspezifischen Schlssels wird ein sitzungsspezifischer Verschlsselungsschlssel generiert, mit dem der WEP-Schlssel verschlsselt wird. Der RADIUS-Server berechnet den sitzungsspezifischen Verschlsselungsschlssel und bergibt ihn in der Erfolgsnachricht an den Zugriffspunkt. Der verschlsselte WEP-Schlssel wird dann vom Zugriffspunkt an die Station bermittelt. Wird IEEE802.1X und WEP verwendet, ermglichen Stationen und Zugriffspunkte den Empfang verschlsselter und nicht verschlsselter Datenpakete (wie im Standard IEEE802.11 festgelegt). Wenn die WEP-Schlsselverteilung aktiviert ist, sollte der Zugriffspunkt eine weitere berprfung durchfhren und alle nicht verschlsselten Nicht-IEEE802.1X-Datenpakete verwerfen. Es wird empfohlen, dass Zugriffspunkte diese zustzliche Filterung vornehmen, um das Ma an Sicherheit ber die Standardfilterung anhand von MAC-Adressen (Media Access Control) hinaus zu verbessern. EAPOLKey Die EAPOL-Key-Nachricht (EAP-over-LAN) betrifft nur IEEE802.11-Netzwerke. Sie ermglicht es dem drahtlosen Zugriffspunkt, einen oder mehrere WEP-Schlssel vom Zugriffspunkt an die Station zu senden. Zur Untersttzung der Vertraulichkeit bentigt jeder Zugriffspunkt einen einzelnen globalen WEP-Schlssel. Dieser WEP-Schlssel kann zufllig vom Zugriffspunkt generiert oder konfiguriert und mittels der EAPOL-Key-Nachricht an eine Station bergeben werden. Der Zugriffspunkt sollte zwei globale Schlssel verwenden, zwischen denen er wechselt, wenn der Schlssel gendert wird. Nach der Authentifizierung knnen Zugriffspunkte jederzeit eine EAPOL-Key-Nachricht senden, um die WEP-Schlssel auf den Stationen zu aktualisieren. Der stationsspezifische Unicast-Sitzungsschlssel wird erhalten, indem frhere Benutzerauthentifizierungsschlssel wiederverwendet werden. Dies ist gem RFC2548 zulssig, in der die Microsoft-Herstellerattribute definiert sind, die der RADIUS-Server an den RADIUS-Client des Zugriffspunktes sendet. Der Zugriffspunkt kann den WEP-Schlssel senden, um eine Datenbertragung von der Station zum Zugriffspunkt zu ermglichen. Es ist jedoch mglich, dass der Zugriffspunkt den WEP-Schlssel nicht sendet. Falls der Zugriffspunkt den WEP-Schlssel nicht sendet, sollte die Station das MS-MPPE-Send-Key-Attribut als WEP-Schlssel verwenden, um Datenbertragungen von der Station zum Zugriffspunkt zu ermglichen. AnmerkungDie Hersteller-ID von Microsoft ist 311. Weitere Informationen finden Sie in RFC2548. Wechseln zwischen Zugriffspunkten Beim Wechsel zwischen Zugriffspunkten wird die Adresse des vorherigen Zugriffspunktes von der Station an den neuen Zugriffspunkt bergeben. Wenn die Zugriffspunkte keine zugriffspunktbergreifende Untersttzung bereitstellen, wird die Station fr den neuen Zugriffspunkt mithilfe einer EAP-Start-Nachricht vom Zugriffspunkt erneut authentifiziert. Es kann jedoch ein zugriffspunktbergreifendes Protokoll (Inter-Access Point Protocol, IAPP) definiert werden, das es dem neuen Zugriffspunkt ermglicht, die Authentifizierungsinformationen von dem alten Zugriffspunkt zu erhalten und eine neue EAPOL-Key-Nachricht mit einem neuen Satz an WEP-Schlsseln an die Station zu senden. Durch das IAPP sollten zudem ausreichende RADIUS-Server-Kontoinformationen an den neuen Zugriffspunkt bermittelt werden, damit der Zugriffspunkt weiterhin dieselben Kontendatenstze verwenden kann und keine neuen anlegen muss. Verwendung der WEP-Authentifizierung Wenn mehrere Zugriffspunkte mit demselben WEP-Schlssel konfiguriert wurden, implementiert der Zugriffspunkt einen weiteren Optimierungsmechanismus. Die NIC versucht, mithilfe des WEP-Schlssels, der von dem alten Zugriffspunkt als gemeinsamer Schlssel erhalten wurde, eine IEEE802.11-Authentifizierung durchzufhren. Ist diese Authentifizierung erfolgreich, fgt der Zugriffspunkt die Station sofort zur Liste der authentifizierten Stationen hinzu. Schlgt die Authentifizierung fehl, nimmt die NIC eine Open System-Authentifizierung am Zugriffspunkt vor, und es erfolgt eine vollstndige IEEE802.1X-Authentifizierung. Der Zugriffspunkt muss unterscheiden knnen, ob eine Station mittels Open System oder unter Verwendung der Shared Key-Methode authentifiziert wurde. Wird der Station unter Verwendung der Shared Key-Methode der Zugriff auf den neuen Zugriffspunkt gestattet, wird von dem neuen Zugriffspunkt weiterhin die IEEE802.1X-Authentifizierung gestartet, um Kontendatenstze zu aktualisieren. Indem die Stations-Netzwerkkonnektivitt mittels Shared Key-Authentifizierung ermglicht wird, whrend der neue Zugriffspunkt IEEE 802.1X ausfhrt, wird sichergestellt, dass an der Station keine Unterbrechung der Netzwerkkonnektivitt auftritt. Wenn die IEEE802.1X-Authentifizierung der Station am neuen Zugriffspunkt nicht erfolgreich abgeschlossen werden kann, wird die Netzwerkverbindung zu der Station ber den kontrollierten Port des Zugriffspunktes beendet. Auf diese Weise wird die Sicherheit des Netzwerkes gewhrleistet. Anforderungen fr den RADIUS-Server Die Anforderungen fr den RADIUS-Server lassen sich in zwei Kategorien unterteilen: Kontenverwaltung und Authentifizierung. AnmerkungDie Zahlen in eckigen Klammern [ ] verweisen auf die Artikel, die weiter unten im Abschnitt "Referenzinformationen" aufgefhrt sind; die Zahlen in runden Klammern ( ) verweisen auf bestimmte Attribute, Typen und Fehler, die in diesen Artikeln definiert sind. Attribute der RADIUS-Kontenverwaltung Bis auf wenige Ausnahmen haben die in [5] und [6] definierten Attribute der RADIUS-Kontenverwaltung innerhalb von IEEE802.1X-Sitzungen und in Einwhlsitzungen dieselbe Bedeutung, so dass keine weiteren Erluterungen notwendig sind. Die folgenden Attribute mssen jedoch genauer betrachtet werden: Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count Acct-Terminate-Cause Wie in [5] beschrieben, zeigt dieses Attribut an, wie die Sitzung beendet wurde. Wenn dieses Attribut verwendet wird, entspricht die Abbruchsursache User Request (1) der Situation, in der die Sitzung aufgrund einer vom Endsystem erhaltenen EAPOL-Logoff-Nachricht beendet wurde. Die Abbruchsursache Lost Carrier (2) weist darauf hin, dass die Sitzung aufgrund des Verlusts der physischen Verbindung, der jedoch nicht durch Roaming herbeigefhrt wurde, beendet wurde. Wenn das Endsystem z.B. eine Point-to-Point-LAN-Verbindung trennt oder aus dem Funkbereich eines 802.11-Zugriffspunktes heraustritt, wird diese Abbruchsursache verwendet. Tritt fr eine Sitzung ein Timeout aufgrund des Ablaufs eines Zeitgebers fr Leerlaufzeit auf, wird die Abbruchsursache Idle Timeout (4) verwendet. Tritt der Timeout aufgrund des Ablaufs eines Sitzungszeitgebers auf, wird die Ursache Session Timeout (5) angezeigt. Wenn eine Sitzung aufgrund von Roaming verlagert wird, wird die Abbruchsursache NAS (Network Access Server) Request (10) verwendet. Wird die Sitzung beendet, weil eine erneute Authentifizierung fehlgeschlagen ist, wird die Abbruchsursache User Error (17) angezeigt. Acct-Multi-Session-Id Dieses Attribut ermglicht es, mehrere in Beziehung stehende Sitzungen miteinander zu verknpfen. Whrend es innerhalb von IEEE802.1X nicht mglich ist, Mehrfachverbindungsbndel zu erstellen, kann ein Endsystem, das mittels Roaming zwischen IEEE802.11-Zugriffspunkten wechselt, veranlassen, dass mehrere Accounting-Stop-Pakete gesendet werden. Sofern dies vom Zugriffspunkt untersttzt wird, wird das Acct-Multi-Session-Id-Attribut verwendet, um mehrere in Beziehung stehende Sitzungen eines das Roaming nutzenden Endsystems zu verknpfen. Hierfr ist es erforderlich, dass das Acct-Multi-Session-Id-Attribut fr alle Zugriffspunkte, Endsysteme und Sitzungen eindeutig ist. Um diese Eindeutigkeit sicherzustellen, wird empfohlen, dass Acct-Multi-Session-Id die folgende Form aufweist: MAC-Adresse des ursprnglichen Zugriffspunktes | MAC-Adresse des Endsystems | NTP-Timestamp Die MAC-Adresse des ursprnglichen Zugriffspunktes entspricht der MAC-Adresse des Zugriffspunktes (in Hexadezimaldarstellung), bei dem die Sitzung begonnen wurde. Der NTP-Timestamp kennzeichnet den Beginn der ursprnglichen Sitzung. Um die Einheitlichkeit des Acct-Multi-Session-Id-Attributs zwischen IEEE802.11-Roamingsitzungen sicherzustellen, kann die Multisitzungs-ID als Teil eines IAPPs zwischen den Zugriffspunkten verschoben werden. Diese Form des Acct-Multi-Session-Id-Attributs stellt die Eindeutigkeit der ID fr alle Zugriffspunkte, Endsysteme und Sitzungen sicher. Da der NTP-Timestamp nicht vom Systemstart ausgehend berechnet wird, besteht keine Mglichkeit, dass ein erneut gestarteter Zugriffspunkt einen Wert fr Acct-Multi-Session-Id whlt, der mit dem Wert einer vorherigen Sitzung verwechselt werden kann. Acct-Link-Count Das Erstellen von Mehrfachverbindungsbndeln innerhalb von IEEE802.1X ist nicht mglich. Dieses Attribut bietet somit keine Vorteile fr IEEE802.1X-Authentifikatoren. RADIUS-Authentifizierung Die folgenden in [8] und [10] definierten Attribute sind fr IEEE802.1X-Authentifikatoren relevant, die als RADIUS-Clients fungieren: User-Name User-Password, CHAP-Password, CHAP-Challenge NAS-IP-Address NAS-Port Service-Type Framed-Protocol Framed-IP-Address, Framed-IP-Netmask Framed-Routing Filter-Id Framed-MTU Framed-Compression Reply-Message Callback-Number, Callback-ID Framed-Route State Class Vendor-Specific Proxy-State Session-Timeout Idle-Timeout Termination-Action Called-Station-ID Calling-Station-ID NAS-Identifier NAS-Port-Type Port-Limit Password-Retry Connect-Info EAP-Message Message-Authenticator NAS-Port-Id Framed-Pool Tunnel-Medium-Type Tunnel-Assignment-Id User-Name In IEEE802.1X gibt das Endsystem seine Identitt blicherweise mittels einer EAP-Response/Identity-Nachricht an. Die Identitt des Endsystems wird sowohl in das User-Name-Attribut als auch in die RADIUS-Access-Request- und Access-Reply-Nachrichten eingeschlossen. In dem weiter unten in [8] aufgefhrten Dokument wird dies nher angegeben. Falls Service-Type dem Wert Call Check entspricht, enthlt das User-Name-Attribut den Wert fr Calling-Station-ID; dieser Wert wird auf die MAC-Adresse des Endsystems eingestellt und als ASCII-Wert ausgedrckt. User-Password, CHAP-Password, CHAP-Challenge Da IEEE802.1X keine Untersttzung fr PAP (Password Authentication Protocol) oder CHAP (Challenge Handshake Authentication Protocol) fr das Benutzerkennwort bietet, werden die Attribute CHAP-Password oder CHAP-Challenge nicht von IEEE802.1X-Authentifikatoren verwendet, die als RADIUS-Clients fungieren. NAS-IP-Address Bei Verwendung von IEEE802.1X enthlt das NAS-IP-Address-Attribut die IP-Adresse der Brcke oder des Zugriffspunktes, die bzw. der als RADIUS-Client fungiert. NAS-Port Bei Verwendung von IEEE802.1X, enthlt das NAS-Port-Attribut ggf. die Anschlussnummer der Brcke oder des Zugriffspunktes. Da in IEEE802.11 keine physischen Anschlsse vorgesehen sind, wird dieses Attribut nicht von Zugriffspunkten gesendet. Service-Type Bei Verwendung von IEEE802.1X haben nur die Werte Framed (2), Authenticate-Only (8) und Call-Check (10) eine Bedeutung. Framed weist darauf hin, dass fr die Verbindung entsprechende 802-Rahmen verwendet werden sollen. Authenticate-Only (8) weist darauf hin, dass im Access-Accept-Paket keine Autorisierungsinformationen zurckgegeben werden mssen. Call-Check, wie in [8] beschrieben, wird in eine Access-Request-Paketanforderung an den RADIUS-Server eingebunden, um den Verbindungsversuch zuzulassen oder zurckzuweisen. Dies basiert blicherweise auf dem Called-Station-ID-Attribut (das auf die MAC-Adresse der Brcke oder des Zugriffspunktes einstellt wird) oder auf dem Calling-Station-ID-Attribut (das auf die MAC-Adresse des Endsystems eingestellt wird). Wie in [8] aufgezeigt, wird in diesem Fall empfohlen, dass das User-Name-Attribut den Wert von Calling-Station-ID erhlt. Framed-Protocol Da es keinen Wert fr 802-Medien gibt, wird das Framed-Protocol-Attribut nicht von IEEE802.1X-Authentifikatoren verwendet. Framed-IP-Address, Framed-IP-Netmask Da IEEE802.1X keinen Mechanismus zur Zuweisung von IP-Adressen bereitstellt, werden die Attribute Framed-IP-Address und Framed-IP-Netmask nicht von IEEE802.1X-Authentifikatoren verwendet. Framed-Routing Das Framed-Routing-Attribut gibt die Weiterleitungsmethode fr das Endsystem an. Es betrifft somit nur IEEE802.1X-Authentifikatoren, die als Gerte der Ebene3 fungieren und die nicht von einer Brcke oder einem Zugriffspunkt verwendet werden knnen. Filter-ID Dieses Attribut gibt den Namen der Filterliste fr das Endsystem an. Es wird von einem IEEE802.1X.-Authentifikator verwendet und kann entweder auf Filter der Ebene2 oder auf Filter der Ebene3 hinweisen. Framed-MTU Dieses Attribut gibt die maximale bertragungseinheit (Maximum Tranmission Unit, MTU) an. IEEE802.1X-Authentifikatoren legen das Framed-MTU-Attribut auf den Wert der MTU des relevanten 802-Mediums fest und schlieen es in das RADIUS-Access-Request-Paket ein. Framed-Compression IEEE802.1X bietet keine Untersttzung fr die Komprimierung, so dass dieses Attribut von 802.1X-Authentifikatoren nicht interpretiert werden kann. Reply-Message Dieses Attribut wird verwendet, um Text zu kennzeichnen, der dem Benutzer angezeigt wird. Ein IEEE802.1X-Authentifikator, der dieses Attribut erhlt, schliet die Zeichenfolge in eine EAP-Request/Notification-Nachricht ein, die an das Endsystem gesendet wird. Callback-Number, Callback-ID Diese Attribute knnen von IEEE802.1X-Authentifikatoren nicht interpretiert werden. Framed-Route Das Framed-Route-Attribut stellt Routen bereit, die fr das Endsystem konfiguriert werden. Es betrifft nur IEEE802.1X-Authentifikatoren, die als Gerte der Ebene3 fungieren. Brcken oder Zugriffspunkte knnen Framed-Route nicht interpretieren. State, Class, Vendor-Specific, Proxy-State Diese Attribute erfllen denselben Zweck (vgl. das unter [8] angegebene Dokument). Session-Timeout Dieses Attribut gibt an, wie lange (in Sekunden) ein Dienst maximal bereitgestellt wird, bevor die Sitzung beendet wird. Welche Aktion bei Beendigung eingeleitet werden muss, wird im Termination-Action-Attribut festgelegt. Ein IEEE802.1X-Authentifikator verwendet diesen Wert zum Auslsen einer regelmigen Neuauthentifizierung in den durch das Sitzungstimeout festgelegten Intervallen, um erfolgreich authentifizierte, anhaltende Sitzungen zu gewhrleisten. Idle-Timeout Mit diesem Attribut wird festgelegt, wie lange (in Sekunden) ein Endsystem eine Verbindung im Leerlauf aufrechterhalten darf, bevor die Sitzung beendet wird. Sobald der durch Idle-Timeout angegebene Zeitraum verstrichen ist, wechselt eine IEEE802.1X-Authentifikator-PAE (Port Access Entity, Anschlusszugriffseinheit) zum unverbundenen Status. Termination-Action Dieses Attribut gibt die Aktion an, die bei Beendigung der Bereitstellung des Dienstes erfolgen soll. Der Wert Default (0) gibt an, dass die Authentifikator-PAE zum unverbundenen Status wechselt. Der Wert RADIUS-Request (1) gibt an, dass die Authentifikator-PAE zum Neuauthentifizierungsstatus wechselt. Called-Station-ID Bei Verwendung durch IEEE802.1X-Authentifikatoren wird in diesem Attribut die MAC-Adresse der Brcke oder des Zugriffspunktes im ASCII-Format gespeichert, wobei die Oktettwerte durch einen Bindestrich (-) getrennt sind. (Beispiel: "00-10-A4-23-19-C0") Calling-Station-ID Bei Verwendung durch IEEE802.1X-Authentifikatoren wird in diesem Attribut die MAC-Adresse des Endsystems im ASCII-Format gespeichert, wobei die Oktettwerte durch einen Bindestrich (-) getrennt sind. NAS-Identifier Dieses Attribut enthlt eine Zeichenfolge zur Identifizierung des IEEE802.1X-Authentifikators, von dem das Access-Request-Paket stammt. NAS-Port-Type Bei Verwendung von IEEE802.1X werden die NAS-Port-Type-Werte Ethernet (15) oder Wireless - IEEE 802.11 (19) verwendet. Bei der Verwendung von IEEE802.1X ber Token Ring gibt es keinen entsprechenden Wert. Port-Limit Da IEEE802.1X keine Untersttzung fr Mehrfachverbindungsbndel bietet, hat dieses Attribut keinerlei Auswirkung, wenn es an einen IEEE802.1X-Authentifikator gesendet wird. Password-Retry Dieses Attribut kann in ein Access-Reject-Paket eingebunden werden, um anzuzeigen, wie viele Authentifizierungsversuche ein Benutzer durchfhren kann, bevor die Verbindung getrennt wird. Bei IEEE802.1X-Systemen sollte dieses Attribut verwendet werden, um zu steuern, wann die Authentifikator-PAE zum Haltestatus wechselt. Connect-Info Dieses Attribut wird von einer Brcke oder einem Zugriffspunkt gesendet, um die Art der Verbindung des Endsystems anzuzeigen. Wird dieses Attribut in einem Access-Request-Paket gesendet, empfiehlt es sich, dass das Attribut Informationen zur Geschwindigkeit der Verbindung des Endsystems enthlt, z.B. CONNECT 11 Mbps IEEE 802.11a. Wird das Attribut in einer Accounting-Stop-Nachricht gesendet, kann es verwendet werden, um statistische Angaben zur Sitzungsqualitt zusammenzufassen. In IEEE802.11 kann das Connect-Info-Attribut beispielsweise Informationen zur Anzahl der erneuten bertragungen ber die Sicherungsschicht enthalten. Das genaue Format dieses Attributs hngt von der jeweiligen Implementierung ab. EAP-Message Da IEEE802.1X wie in [2] und [3] beschrieben die Kapselung von EAPOL (EAP-over-LAN), bereitstellt, wird das EAP-Message-Attribut zur Kapselung von EAP-Paketen verwendet, die vom IEEE802.1X-Authentifikator an den Authentifizierungsserver gesendet werden. Da das IEEE keinen Ethernet-Typ fr EAPOL-Rahmen verffentlicht hat, werden die MAC-Adresse und der Ethernet-Typ zu Testzwecken derzeit folgendermaen definiert: BYTE Def_dest_mac_addr[]={0x01, 0x80, 0xc2, 0x00, 0x00, 0x0f}; BYTE Def_ethernet_type[]={0x81, 0x80}; Message-Authenticator Wie in [10] aufgezeigt, muss das Message-Authenticator-Attribut verwendet werden, um alle Pakete zu schtzen, die ein EAP-Message-Attribut enthalten. NAS-Port-Id Mithilfe dieses Attributs wird der IEEE802.1X-Authentifikatoranschluss identifiziert, der das Endsystem authentifiziert. Da in IEEE802.11 keine physischen Anschlsse vorgesehen sind, wird dieses Attribut nicht von Zugriffspunkten gesendet. Framed-Pool Da IEEE802.1X keine Untersttzung fr die Adresszuweisung bietet, hat dieses Attribut keinerlei Bedeutung fr einen IEEE802.1X-Authentifikator. Tunnel-Medium-Type Falls die Zuweisung einer VLANID (Virtual Local Access Network ID) zum Anschluss eines IEEE802.1X-Endsystems gewnscht ist, wird fr das Tunnel-Medium-Type-Attribut der Wert 802 (6) verwendet. Tunnel-Assignment-Id In Kombination mit dem Tunnel-Medium-Type-Wert802 dient dieses Attribut zum Senden der VLANID. Roaming Es gibt zwei Mglichkeiten zur Bereitstellung von Sicherheitsdiensten, wenn eine Station von einem Zugriffspunkt zum anderen wechselt. Keine Koordination der Zugriffspunkte Der erste Ansatz geht davon aus, dass die Zugriffspunkte die bergaben der Station zwischen dem alten und dem neuen Zugriffspunkt nicht koordinieren. In diesem Fall muss die Station im Anschluss an die bergabe smtliche Phasen zum Aufbauen einer IEEE802.11-Funkverbindung durchlaufen, an die sich die erneute IEEE802.1X-Authentifizierung anschliet. Whrend dieses Zeitraums, also des erneuten Verbindungsaufbaus und der erneuten Authentifizierung, ist der Zugriff der Station auf das Netzwerk unterbrochen. Auch wenn davon ausgegangen werden kann, dass dieser Prozess unter normalen Bedingungen nur wenige Sekunden in Anspruch nimmt, sind bestimmte Anwendungsbereiche vorstellbar, z.B. die Wiedergabe von Audio- oder Videostreams, in denen dies zu einer Leistungsbeeintrchtigung fhrt. Ein Vorteil dieses Ansatzes liegt jedoch darin, dass im Anschluss an die bergabe der Station vom alten zum neuen Zugriffspunkt keine nderungen am Stations- und Zugriffspunktbetrieb notwendig sind. Koordination der Zugriffspunkte Der zweite Ansatz geht davon aus, dass die Zugriffspunkte die bergaben der Station koordinieren. Hierdurch wird eine schnelle bergabe ermglicht. Zudem werden Unterbrechungen der Netzwerkkonnektivitt der Station whrend anhaltender Sitzungen vermieden. Hierfr ist die Definition eines IAPPs erforderlich, damit der alte und der neue Zugriffspunkt die bergabe der Station koordinieren knnen. Mithilfe eines IAPPs knnen im Anschluss an die bergabe einer Station stationsspezifische Unicast-Schlssel vom alten an den neuen Zugriffspunkt bermittelt werden. Darber hinaus wrde eine EAPOL-Key-Nachricht verwendet, um den gemeinsamen Schlssel zu aktualisieren. Zustzliche Optimierung Wenn mehrere Zugriffspunkte mit demselben WEP-Schlssel konfiguriert wurden, kann der Zugriffspunkt einen zustzlichen Optimierungsmechanismus nutzen. Die NIC sollte mithilfe des WEP-Schlssels, der von dem alten Zugriffspunkt als gemeinsamer Schlssel erhalten wurde, versuchen, eine IEEE802.11-Authentifizierung durchzufhren. Ist diese Authentifizierung erfolgreich, sollte der Zugriffspunkt die Station sofort zur Liste der authentifizierten Stationen hinzufgen. Wird der Station unter Verwendung der Shared Key-Methode der Zugriff auf den neuen Zugriffspunkt gestattet, wird von dem neuen Zugriffspunkt weiterhin die IEEE802.1X-Authentifizierung gestartet, um die Kontendatenstze zu aktualisieren. Indem die Stations-Netzwerkkonnektivitt mittels Shared Key-Authentifizierung ermglicht wird, whrend der neue Zugriffspunkt IEEE 802.1X ausfhrt, wird sichergestellt, dass an der Station keine Unterbrechung der Netzwerkkonnektivitt auftritt. Mehrere Zertifikate Die EAP-TLS-Implementierung von RAS (Remote Access Server) ermglicht beim ersten Mal die Auswahl eines Zertifikats; dieses Zertifikat wird anschlieend wiederverwendet. Wird IEEE802.1X in einem Szenario verwendet, in dem vom Roaming Gebrauch gemacht wird, wirft dieser Prozess einige Probleme auf. Bei RAS gibt es fr jedes Ziel eine einzelne Verbindung. Bei IEEE802.1X kann eine LAN-Verbindung an mehreren Standorten verwendet werden. Verwenden mehrerer Standorte Es kann durchaus begrndet sein, an unterschiedlichen Standorten unterschiedliche Anmeldeinformationen anzugeben; um dies zu ermglichen, muss ein Mechanismus zur Verfgung stehen, mit dessen Hilfe der jeweilige Standort erkannt werden kann. Bei IEEE802.11 kann der Netzwerkname bzw. die Dienstsatzidentifizierung zur Standortidentifikation verwendet werden. Beim Einsatz von Ethernet gibt es keine Mglichkeit, den Standort zu ermitteln, es sei denn, es wrden nderungen an IEEE802.1X vorgenommen. (In Organisationsnetzwerken, z.B. Unternehmen und Universitten, ist die Verwendung von IEEE802.1X und Ethernet wahrscheinlich, da auf diese Weise die sichere Netzwerkkonnektivitt bereitgestellt werden kann.) Standardzertifikat fr jedes Netzwerk Drahtlose Netzwerke werden zudem sehr hufig an ffentlichen Orten, z.B. an Flughfen oder in Einkaufszentren, verwendet. ffentliche Orte knnen die Verwendung von querverweisenden Anmeldeinformationen ermglichen, in vielen Fllen ist jedoch die Verwendung anderer Anmeldeinformationen, z.B. eines Standardzertifikats fr jedes Netzwerk, erforderlich. Verwendung der EAP-Identity/Request-Zeichenfolge Vorzuziehen ist, dass sowohl Ethernet- als auch IEEE802.11-Netzwerke in der Lage sind, dem Client/der Station ihre aktuellen Standorte anzuzeigen, indem sie der EAP-Identity-Nachricht ein Attribut hinzufgen. Diese Nachricht knnte den Dienst angeben, der vom Netzwerk bereitgestellt wird. Falls dieses Attribut in IEEE802.11-Netzwerken nicht verfgbar ist, sollte stattdessen standardmig die Dienstsatzidentifizierung verwendet werden. Fr die anzuzeigende nullterminierte Zeichenfolge und den durch Kommas getrennten Abschnitt der EAP-Identity-Nachrichtenzeichenfolge wird daher folgendes Format empfohlen: Dies ist eine Anzeigenzeichenfolge\0networkid=,nasid=,portid= Wobei gilt: = :SSID fr IEEE802.11, jedoch eine beliebige Zeichenfolge fr Ethernet. = : Name des IEEE802.11-Zugriffspunktes oder Ethernet-Switches; falls kein Name verfgbar ist, die MAC-Adresse des Zugriffspunktes oder Ethernet-Switches. = : Anschlusskennung, ber die diese IEEE802.1X-Sitzung erfolgt. Das IEEE802.1X-Endsystem (Station) wrde diese Zeichenfolge vor dem Null-Terminierungszeichen (\0) anzeigen, um Administratoren die Anzeige von Netzwerk-Identifikationsnachrichten zu ermglichen. Weitere Informationen zur Angabe der Identittszeichenfolge in einer EAP-Identity-Request-Nachricht finden Sie in AnhangB. Nicht authentifizierter Zugriff  Abbildung2: Typisches Netzwerkszenario fr den nicht authentifizierten Zugriff Die Verwendung von IEEE802.11 an ffentlichen Orten, wie z.B.Flughfen oder Einkaufszentren, wrde eine zustzliche Erweiterung des Standards IEEE802.1X erforderlich machen. Derzeit erfolgt der IEEE802.1X-Authentifizierungsprozess im Anschluss an den IEEE802.11-Verbindungsaufbau. Abbildung2 zeigt ein typisches Netzwerkszenario fr nicht authentifizierten Zugriff. Der nicht authentifizierte Zugriff durch Benutzer an ffentlichen Orten lsst sich in zwei Kategorien unterteilen: Kunden mit einem bevorzugten Dienstanbieter, wie z.B. Benutzer in Unternehmen, die ber ein Standard-VLAN den Zugriff auf das Internet erhalten. Kunden, die beabsichtigen, sich bei dem Dienstanbieter anzumelden, um ber ein VLAN den Zugriff auf das Internet zu erhalten. Standard-VLANs Benutzer in Unternehmen, die eine Verbindung zum Netzwerk herstellen, wrden zuerst eine IEEE802.11-Funkverbindung zwischen der Station und dem Zugriffspunkt herstellen. Im Anschluss an den Aufbau der IEEE802.11-Funkverbindung folgt die IEEE802.1X-Authentifizierung mithilfe des Proxy-RADIUS-Servers. Anschlieend wird den authentifizierten Benutzern im Unternehmen der Netzwerkzugriff ber das Standard-VLAN ermglicht. Dieser Ansatz ist mit der Methode vergleichbar, die derzeit eingesetzt wird, um Clients den Netzwerkzugriff ber den Netzwerkzugriffsserver (Network Access Server, NAS) zu ermglichen. Benutzer in Unternehmen, die eine Verbindung zu ihrem Intranet herstellen mchten, wrden nun mithilfe eines Verfahrens zur Verwendung eines sicheren Tunnels, wie z.B. PPTP (Point-to-Point Tunneling Protocol), eine Verbindung zum Unternehmensfirewall aufbauen. ffentliche Internetszenarien Benutzer, die beabsichtigen, einen Internetdienst zu abonnieren, mssten sich vor der Authentifizierung fr den Netzwerkzugriff anmelden und registrieren. Aus diesem Grund msste IEEE802.1X so konzipiert sein, dass es den Zugriff auf die Anmeldungs- und Registrierungsserver ermglicht, indem die Benutzerkommunikation an das entsprechende VLAN gelenkt wird. Mithilfe einer EAP-Notification-Nachricht kann der Benutzer darber informiert werden, bei welchem Server die Anmeldung und Registrierung zum Zweck der Kontoverwaltung und Abrechnung erfolgen muss. Die Anmeldung und Registrierung muss stattfinden, bevor der Zugriff auf das Netzwerk gewhrt wird. Clientanforderungen Fr einen nicht authentifizierten Benutzer sollte ein IEEE802.1X-Client in der EAP-Response/Identity-Nachricht eine Nullzeichenfolge als Identittsangabe bermitteln. Als nicht authentifizierter Benutzer wird ein Benutzer bezeichnet, der auf dem Clientgert nicht die erforderlichen Anmeldeinformationen bereitstellen kann, also z.B. ein Benutzer, der nicht ber die erforderlichen Benutzerzertifikate fr das Netzwerk verfgt, auf das er zuzugreifen versucht. Anforderungen fr Zugriffspunkte Verarbeiten eines nicht authentifizierten Benutzers Wenn der Zugriffspunkt eine EAP-Response/Identity-Nachricht von einem nicht authentifizierten Benutzer erhlt, bermittelt er im Rahmen der Kommunikation mit dem RADIUS-Server die im Folgenden beschriebenen Informationen: Der RADIUS-Client des Zugriffspunktes gibt im RADIUS-Access-Request-Paket nicht das RADIUS-Attribut User-Name (Nummer 1) an. Der RADIUS-Client des Zugrifsspunktes gibt im RADIUS-Access-Request-Paket nicht das RADIUS-Attribut EAP-Message (Nummer 79) an. Drei Ebenen des Netzwerkzugriffs Ein Zugriffspunkt bietet dem Client drei Ebenen des Netzwerkzugriffs, die von der Authentifizierungsantwort des RADIUS-Servers abhngen. Es handelt sich um die folgenden drei Ebenen: Vollstndiger Netzwerkzugriff. Dem Client wird der vollstndige Zugriff auf alle Netzwerkressourcen ermglicht, die fr einen authentifizierten Benutzer verfgbar sind. Beschrnkter Netzwerkzugriff. Dem Client wird der beschrnkte Zugriff auf Netzwerkressourcen ermglicht. So knnen z.B. bertragungen vom Client auf eine bestimmte Gruppe von Zieladressen begrenzt sein, whrend bertragungen zu anderen Zieladressen durch den Zugriffspunkt unterbunden werden. Unterbinden des Netzwerkzugriffs. Der Client kann auf keine Netzwerkressource zugreifen. Authentifizierungsantworten Bei Erhalt einer Authentifizierungsantwort vom RADIUS-Server wendet der Zugriffspunkt eines der folgenden Netzwerk-Autorisierungsverfahren an: Access-Accept-Paket mit EAP-Success-Nachricht (RADIUS-Paket enthlt ein EAP-Message-Attribut) Vollstndiger Netzwerkzugriff wird ermglicht Bereitstellung des beschrnkten Netzwerkzugriffs wird aufgehoben Access-Reject-Paket mit EAP-Failure-Nachricht (RADIUS-Paket enthlt ein EAP-Message-Attribut) Bereitstellung des vollstndigen Netzwerkzugriffs wird aufgehoben Bereitstellung des beschrnkten Netzwerkzugriffs wird aufgehoben Access-Reject-Paket mit EAP-Success-Nachricht (RADIUS-Paket enthlt ein EAP-Message-Attribut) Bereitstellung des vollstndigen Netzwerkzugriffs wird aufgehoben Bereitstellung des beschrnkten Netzwerkzugriffs wird aufgehoben Access-Accept-Paket (RADIUS-Paket enthlt kein EAP-Message-Attribut) Bereitstellung des vollstndigen Netzwerkzugriffs wird aufgehoben Bereitstellung des beschrnkten Netzwerkzugriffs wird aufgenommen Access-Reject-Paket (RADIUS-Paket enthlt kein EAP-Message-Attribut) Bereitstellung des vollstndigen Netzwerkzugriffs wird aufgehoben Bereitstellung des beschrnkten Netzwerkzugriffs wird aufgehoben IEEE 802.11 im Ad-hoc-Modus Im Ad-hoc-Netzwerkmodus von IEEE802.11 knnen Stationen innerhalb eines Basisdienstsatzes (Basic Service Set, BSS) direkt mit Peer-Stationen innerhalb desselben BSS kommunizieren. Das IEEE802.1X-Authentifizierungsprozess wird von Peer-Stationen mithilfe einer EAPOL-Interaktion ausgelst. Alle Stationen innerhalb des BSS mssen sich untereinander gegenseitig authentifizieren. Hierfr ist ein Algorithmus erforderlich, um einen Authentifikator auszuwhlen. Gegenseitige Authentifizierung Da im Ad-hoc-Netzwerkmodus kein RADIUS-Server fr die Authentifizierung verwendet wird, mssen die Anmeldeinformationen der Benutzer auf den Stationen gespeichert werden. Dies hat zur Folge, dass fr die Schlsselverwaltung im Ad-hoc-Netzwerkmodus eine kennwortgesttzte gegenseitige Authentifizierung und eine sichere Schlsselgenerierung erforderlich sind. Zwei Anstze Derzeitige EAP-Methoden stellen zwei Anstze fr die gegenseitige Authentifizierung zur Verfgung: EAP-TLS untersttzt die gegenseitige Authentifizierung und die Schlsselgenerierung, geht jedoch davon aus, dass beide Benutzer ber ein Zertifikat verfgen. EAP-GSS untersttzt die gegenseitige Authentifizierung, geht jedoch davon aus, dass die Serverseite mit einem Schlsselverteilungscenter (Key Distribution Center, KDC) in Verbindung steht. Im Ad-hoc-Netzwerkmodus kann IEEE802.1X nur mit der Shared Key-Authentifizierung verwendet werden. In einige Szenarien wird die gegenseitige Authentifizierung bevorzugt, es drfte jedoch eine neue EAP-Methode notwendig sein, um dieser Anforderung angemessen gerecht zu werden. Untersttzung drahtloser LANs durch Windows2000 und WindowsXP Windows2000 bietet zahlreiche wichtige Funktionen zur Untersttzung und Erweiterung des drahtlosen Einsatzes von Computern. Die neuen Medienerkennungsfunktionen im TCP/IP-Stack erleichtern das Roaming von einem Zugriffspunkt zum nchsten, ohne dass die Gefahr besteht, dass Verbindungen unterbrochen oder Daten ausgespht werden. Die NDIS-Schnittstelle von Windows2000 untersttzt drahtlose Netzwerkadapter und die zugehrigen Treiber. Im Lieferumfang von Windows2000 sind zahlreiche Treiber fr Karten fr drahtlose LANs enthalten. Zudem stellen die meisten Gerte fr drahtlose LANs Treiber fr Windows2000 zur Verfgung, so dass das Einrichten und Verwenden drahtloser Gerte fr das bzw. mit dem Betriebssystem vllig unproblematisch ist. Die meisten der drahtlosen Gerte, die in Windows2000 untersttzt werden, implementieren Sicherheitsmechanismen, indem sie einen gemeinsamen Schlssel oder WEP (Wired Equivalent Privacy) verwenden. Durch die Erweiterung des Betriebssystems um IEEE802.11 sowie verbesserte konfigurationsfreie Verbindungen und Roamingfunktionalitt vereinfacht WindowsXP die Verwaltung drahtloser Gerte. Zusammenfassung Durch die Unabhngigkeit von Kabelverbindungen und die einfachere Netzwerkinstallation stellen IEEE802.11-basierte, drahtlose Netzwerke eine ausgesprochen attraktive Lsung dar. Aufgrund unterschiedlicher Beschrnkungen, vor allem jedoch aufgrund von Sicherheitsbedenken, waren Administratoren von Unternehmensnetzwerken bei der Bereitstellung drahtloser Netzwerke bislang eher zurckhaltend. Durch die Erweiterung von IEEE802.11-basierten Netzwerken um IEEE802.1X-Standards wird die Sicherheit jedoch sogar ber das in verkabelten Netzwerken bliche Ma hinaus erweitert, so dass dem Einsatz im Unternehmen nichts mehr im Wege steht. Diese Sicherheitsfeatures knnen auch fr andere IEEE802-Netzwerke, z.B. in 802.3Ethernet-Netzwerken, verwendet werden, um die netzwerkweite Zugriffssicherheit zu verbessern. Weitere Informationen Aktuelle Informationen zu Windows2000 und WindowsXP finden Sie unter  HYPERLINK "http://www.microsoft.com/germany/ms/windows2000/" http://www.microsoft.com/germany/ms/windows2000/ oder unter  HYPERLINK "http://www.microsoft.com/windows2000/" http://www.microsoft.com/windows2000/ (englischsprachig) sowie unter  HYPERLINK "http://www.microsoft.com/germany/ms/windowsxp/" http://www.microsoft.com/germany/ms/windowsxp/ oder unter  HYPERLINK "http://www.microsoft.com/windowsxp/" http://www.microsoft.com/windowsxp/ (englischsprachig). Aktuelle Informationen zu IEEE802.11-Standards finden Sie unter  HYPERLINK "http://standards.ieee.org/wireless/" http://standards.ieee.org/wireless/ (englischsprachig) Referenzinformationen Teil 11: Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specifications, Draft International Standard ISO/IEC 8802-11, IEEE802.11/D10, 14.Januar1999 (englischsprachig). Standards for Local and Metropolitan Area Networks: Port-based Network Access Control, Draft International Standard ISO/IEC 8802-11, IEEE Draft P802.1X/D8, 16.Oktober2000 (englischsprachig). L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", IETF RFC2284, Mrz1998 (englischsprachig). B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", IETF RFC2716, Oktober1999 (englischsprachig). C. Rigney, A. Rubens, W. A. Simpson, S. Willens, "Remote Authentication Dial-In User Service (RADIUS)", IETF RFC2138, April1997 (englischsprachig). C. Rigney, "RADIUS Accounting", IETF RFC2139, April1997 (englischsprachig). G. Zorn, "Microsoft Vendor-specific RADIUS Attributes", IETF RFC2548, Mrz1999 (englischsprachig). C. Rigney, S. Willens, A. Rubens, W. A. Simpson, "Remote Authentication Dial-In User Service (RADIUS)", IETF RFC2865, Juni2000 (englischsprachig). C. Rigney, "RADIUS Accounting", IETF RFC2866, Juni2000 (englischsprachig). C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", IETF RFC2869, Juni2000 (englischsprachig). G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", IETF RFC2868, Juni2000 (englischsprachig). G. Zorn, D. Mitton, B. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support", IETF RFC2867, Juni2000 (englischsprachig). J. Linn, "Generic Security Service Application Program Interface, Version2, Update1", IETF RFC2743, Januar2000 (englischsprachig). G. Zorn, "Microsoft Vendor-specific RADIUS Attributes", IETF RFC2548, Mrz1999 (englischsprachig). AnhangA: NDIS-Definitionen und Objektkennungen Im Folgenden finden Sie eine kurze Beschreibung der NDIS-Definitionen, die mit den neuen NDIS-OIDs fr die Untersttzung drahtloser LANs verwendet werden. Diese Typen finden Sie auch in den Headerdateien und in der Dokumentation zum Windows DDK (Driver Developers Kit). NDIS-Definitionen typedef enum _NDIS_802_11_NETWORK_TYPE { Ndis802_11FH, Ndis802_11DS, Ndis802_11NetworkTypeMax // kein echter Typ, ist als oberer Grenzwert definiert } NDIS_802_11_NETWORK_TYPE, *PNDIS_802_11_NETWORK_TYPE; typedef struct _NDIS_802_11_NETWORK_TYPE_LIST { ULONG NumberOfItems; // gem nachfolgender Liste, mindestens 1 NDIS_802_11_NETWORK_TYPE NetworkType [1]; } NDIS_802_11_NETWORK_TYPE_LIST, *PNDIS_802_11_NETWORK_TYPE_LIST; typedef enum _NDIS_802_11_POWER_MODE { Ndis802_11PowerModeCAM, Ndis802_11PowerModeMAX_PSP, Ndis802_11PowerModeFast_PSP, Ndis802_11PowerModeMax // kein echter Modus, ist als oberer Grenzwert definiert } NDIS_802_11_POWER_MODE, *PNDIS_802_11_POWER_MODE; typedef ULONG NDIS_802_11_TX_POWER_LEVEL; // in Milliwatt // // Anzeige fr die Strke des empfangenen Signals (Received Signal Strength Indication, RSSI) // typedef LONG NDIS_802_11_RSSI; // RSSI in dBmW typedef struct _NDIS_802_11_CONFIGURATION_FH { ULONG Length; // Lnge der Struktur ULONG HopPattern; // gem Definition in 802.11, MSB festgelegt ULONG HopSet; // entspricht 1 bei Nichtbereinstimmung mit 802.11 ULONG DwellTime; // Einheiten sind in Kusec angegeben } NDIS_802_11_CONFIGURATION_FH, *PNDIS_802_11_CONFIGURATION_FH; typedef struct _NDIS_802_11_CONFIGURATION { ULONG Length; // Lnge der Struktur ULONG BeaconPeriod; // Einheiten sind in Kusec angegeben ULONG ATIMWindow; // Einheiten sind in Kusec angegeben ULONG DSConfig; // Frequenz, Einheiten sind in KHz angegeben NDIS_802_11_CONFIGURATION_FH FHConfig; } NDIS_802_11_CONFIGURATION, *PNDIS_802_11_CONFIGURATION; typedef struct _NDIS_802_11_STATISTICS { ULONG Length; // Lnge der Struktur LARGE_INTEGER TransmittedFragmentCount; LARGE_INTEGER MulticastTransmittedFrameCount; LARGE_INTEGER FailedCount; LARGE_INTEGER RetryCount; LARGE_INTEGER MultipleRetryCount; LARGE_INTEGER RTSSuccessCount; LARGE_INTEGER RTSFailureCount; LARGE_INTEGER ACKFailureCount; LARGE_INTEGER FrameDuplicateCount; LARGE_INTEGER ReceivedFragmentCount; LARGE_INTEGER MulticastReceivedFrameCount; LARGE_INTEGER FCSErrorCount; } NDIS_802_11_STATISTICS, *PNDIS_802_11_STATISTICS; typedef ULONG NDIS_802_11_KEY_INDEX; typedef struct _NDIS_802_11_WEP { ULONG Length; // Lnge der Struktur ULONG KeyIndex; // 0 ist der clientspezifische Schlssel, 1-N sind die // globalen Schlssel ULONG KeyLength; // Lnge des Schlssels in Bytes UCHAR KeyMaterial[1]; // variable Lnge in Abhngigkeit von dem vorherigen Feld } NDIS_802_11_WEP, *PNDIS_802_11_WEP; typedef UCHAR NDIS_802_11_MAC_ADDRESS[6]; typedef struct _NDIS_802_11_SSID { ULONG SsidLength; // Lnge des SSID-Informationsfeldes in Oktetten UCHAR Ssid[32]; // SSID-Informationsfeld, umfasst 0 bis 32Byte } NDIS_802_11_SSID, *PNDIS_802_11_SSID; typedef struct _NDIS_WLAN_BSSID { ULONG Length; // Lnge der Struktur NDIS_802_11_MAC_ADDRESS MacAddress; // BSSID UCHAR Reserved[2]; NDIS_802_11_SSID Ssid; // SSID ULONG Privacy; // erforderliche WEP-Verschlsselung NDIS_802_11_RSSI Rssi; // RSSI // in dBmW NDIS_802_11_NETWORK_TYPE NetworkTypeInUse; // Network_Type_In_Use NDIS_802_11_CONFIGURATION Configuration; // Konfiguration NDIS_802_11_NETWORK_INFRASTRUCTURE InfrastructureMode; // Infrastructure_Mode NDIS_802_11_RATES SupportedRates; // Supported_Rates } NDIS_WLAN_BSSID, *PNDIS_WLAN_BSSID; typedef struct _NDIS_802_11_BSSID_LIST { ULONG NumberOfItems; // gem nachfolgender Liste, mindestens 1 NDIS_WLAN_BSSID Bssid[1]; } NDIS_802_11_BSSID_LIST, *PNDIS_802_11_BSSID_LIST; typedef enum _NDIS_802_11_NETWORK_INFRASTRUCTURE { Ndis802_11IBSS, Ndis802_11Infrastructure, Ndis802_11AutoUnknown, Ndis802_11InfrastructureMax // kein echter Wert, ist als oberer Grenzwert definiert } NDIS_802_11_NETWORK_INFRASTRUCTURE, *PNDIS_802_11_NETWORK_INFRASTRUCTURE; typedef enum _NDIS_802_11_AUTHENTICATION_MODE { Ndis802_11AuthModeOpen, Ndis802_11AuthModeShared, Ndis802_11AuthModeAutoSwitch, Ndis802_11AuthModeMax // kein echter Modus, ist als oberer Grenzwert definiert } NDIS_802_11_AUTHENTICATION_MODE, *PNDIS_802_11_AUTHENTICATION_MODE; typedef ULONG NDIS_802_11_FRAGMENTATION_THRESHOLD; typedef ULONG NDIS_802_11_RTS_THRESHOLD; typedef ULONG NDIS_802_11_ANTENNA; typedef UCHAR NDIS_802_11_RATES[8]; // Satz aus 8Raten, wobei jeder Oktettwert eine Datenrate darstellt typedef enum _NDIS_802_11_PRIVACY_FILTER { Ndis802_11PrivFilterAcceptAll, Ndis802_11PrivFilter8021xWEP } NDIS_802_11_PRIVACY_FILTER, *PNDIS_802_11_PRIVACY_FILTER; NDIS-Objektkennungen (Weiter oben finden Sie eine Liste der WLAN-abhngigen Objekte fr die drahtlose Kommunikation.) OID_802_11_BSSID Dieses Objekt entspricht der MAC-Adresse des verbundenen Zugriffspunktes. Diese Einstellung kann im Rahmen von Scanvorgngen hilfreich sein. Datentyp:NDIS_802_11_MAC_ADDRESSAbfrage: Gibt die MAC-Adresse des aktuellen Zugriffspunktes zurck.Festlegen:Legt die MAC-Adresse des gewnschten Zugriffspunktes fest.Statusanzeige:Nicht untersttztOID_802_11_SSID Dieses Objekt definiert die Dienstsatzidentifizierung (Service Set Identifier, SSID). Die Dienstsatzidentifizierung ist eine maximal 32Zeichen umfassende Zeichenfolge. Sie identifiziert einen Satz untereinander verbundener Basisdienststze (Basic Service Sets, BSS). Wird in dieser OID-Anforderung eine leere Zeichenfolge bergeben, wird der NIC hierdurch mitgeteilt, dass mit dem Verbindungsaufbau nicht die Verfgbarkeit eines bestimmten Zugriffspunktes abgewartet, sondern eine Verbindung zu einem beliebigen Zugriffspunkt aufgebaut werden soll. Das Festlegen einer Dienstsatzidentifizierung fhrt zur Aufhebung der Verbindung, wenn diese Dienstsatzidentifizierung bereits anderweitig vergeben ist. Die Aufhebung der Verbindung kann Folgendes bewirken: Aktivieren des Transceivers, wenn dieser bislang deaktiviert war, Festlegen der Dienstsatzidentifizierung auf den angegebenen Wert oder Festlegen der Dienstsatzidentifizierung auf einen beliebigen Wert (falls kein Wert angegeben wurde) und Versuch des Verbindungsaufbaus zur angegebenen Dienstsatzidentifizierung. Datentyp:NDIS_802_11_SSIDAbfrage: Gibt die SSID zurck.Festlegen:Legt die SSID fest.Statusanzeige:Nicht untersttztOID_802_11_NETWORK_TYPES_SUPPORTED Datentyp:NDIS_802_11_NETWORK_TYPE_LISTAbfrage:Gibt ein Array aller vom Treiber und Gert untersttzten NDIS_802_11_NETWORK_TYPE(s) zurck.Festlegen:Nicht untersttztStatusanzeige:Nicht untersttzt OID_802_11_NETWORK_TYPE_IN_USE Datentyp:NDIS_802_11_NETWORK_TYPEAbfrage:Gibt den momentan vom Gert verwendeten NDIS_802_11_NETWORK_TYPE zurck.Festlegen:Legt den Netzwerktyp fest, der fr den Treiber verwendet werden soll.Statusanzeige:Nicht untersttztOID_802_11_TX_POWER_LEVEL bertragungspegel in mW Datentyp:NDIS_802_11_TX_POWER_LEVELAbfrage:Gibt den aktuellen NDIS_802_11_TX_POWER_LEVEL-Wert zurck.Festlegen:Legt den aktuellen NDIS_802_11_TX_POWER_LEVEL-Wert fest. Kontrollpegel werden vom Gert nicht berschritten.Statusanzeige:Nicht untersttztOID_802_11_RSSI Gibt die RSSI (Received Signal Strenght Indication) in dBmW zurck. Datentyp:NDIS_802_11_RSSIAbfrage:Gibt den aktuellen RSSI-Wert zurck.Festlegen:Nicht untersttztStatusanzeige:Wenn die Statusanfrage aktiviert ist, wird, basierend auf dem festgelegten Wert, ein Ereignis ausgelst.OID_802_11_RSSI_TRIGGER Diese OID fragt einen Triggerwert fr das RSSI-Ereignis ab oder legt einen entsprechenden Wert fest. Wenn der Triggerwert den aktuellen RSSI-Wert unterschreitet (<), erfolgt die Statusanzeige, sobald der aktuelle Wert grer oder gleich (>=) dem Triggerwert ist. Wenn der Triggerwert den aktuellen RSSI-Wert berschreitet (>), erfolgt die Statusanzeige, sobald der aktuelle Wert kleiner oder gleich (<=) dem Triggerwert ist. Wenn der Triggerwert dem aktuellen Wert entspricht, erfolgt die Statusanzeige sofort. NdisMIndicateStatus wird aufgerufen, wobei der GeneralStatus-Parameter auf NDIS_STATUS_MEDIA_SPECIFIC_INDICATION festgelegt wird und StatusBuffer auf einen NDIS_802_1_RSSI-Puffer zeigt. Datentyp:NDIS_802_11_RSSIAbfrage:Gibt den aktuellen RSSI-Triggerwert zurck.Festlegen:Legt den RSSI-Triggerwert fr ein Ereignis fest.Statusanzeige:Nicht untersttztOID_802_11_INFRASTRUCTURE_MODE Diese OID fragt ab oder legt fest, wie eine 802.11-NIC eine Verbindung zum Netzwerk herstellt. Sie bewirkt darber hinaus das Zurcksetzen des Netzwerkverbindungsalgorithmus. Datentyp:NDIS_802_11_NETWORK_INFRASTRUCTUREAbfrage:Gibt den Wert fr einen der Modi Infrastruktur, IBSS (Independent Basic Service Set, Unabhngiger Basisdienstsatz) oder Unbekannt zurck.Festlegen:Legt den Modus Infrastruktur oder IBSS fest oder wechselt automatisch zwischen diesen beiden Modi.Statusanzeige:Nicht untersttztOID_802_11_FRAGMENTATION_THRESHOLD Pakete, die diesen Schwellenwert berschreiten, werden vom WLAN fragmentiert. Durch die Einstellung Null wird die Fragmentierung beseitigt. Datentyp:NDIS_802_11_FRAGMENTATION_THRESHOLDAbfrage:Gibt den aktuellen Schwellenwert fr die Fragmentierung zurck.Festlegen:Legt den Schwellenwert fr die Fragmentierung fest.Statusanzeige:Nicht untersttztOID_802_11_RTS_THRESHOLD Pakete, deren Gre diesen Schwellenwert berschreiten, fhren zum Aufrufen des RTS/CTS-Mechanismus durch das WLAN. Der Wert Null bedeutet, dass RTS/CTS fr alle Pakete angewendet wird. Datentyp:NDIS_802_11_RTS_THRESHOLDAbfrage:Gibt den aktuellen RTS-Schwellenwert zurck.Festlegen:Legt den RTS-Schwellenwert fest.Statusanzeige:Nicht untersttzt OID_802_11_NUMBER_OF_ANTENNAS Gibt die Anzahl der Antennen des Transceivers zurck. Datentyp: Abfrage:ULONG Gibt die Anzahl der Antennen des Transceivers zurck.Festlegen:Nicht untersttztStatusanzeige:Nicht untersttztOID_802_11_RX_ANTENNA_SELECTED Gibt die Antenne zurck, die am Transceiver fr den Empfang ausgewhlt wurde. Datentyp:NDIS_802_11_ANTENNAAbfrage:Gibt die Antenne zurck, die fr den Empfang ausgewhlt wurde.Festlegen:Legt die Antenne fest, die fr den Empfang verwendet wird.Statusanzeige:Nicht untersttztAnmerkungDer Wert -1 ist gleichbedeutend mit der Auswahl aller Antennen, also der Einstellung Diversity (Vielfalt).] OID_802_11_TX_ANTENNA_SELECTED Gibt die Antenne zurck, die am Transceiver fr die bertragung ausgewhlt wurde. Datentyp:NDIS_802_11_ANTENNAAbfrage:Gibt die Antenne zurck, die fr die bertragung ausgewhlt wurde.Festlegen:Legt die Antenne fest, die fr die bertragung verwendet wird.Statusanzeige:Nicht untersttztAnmerkungDer Wert -1 ist gleichbedeutend mit der Auswahl aller Antennen, also der Einstellung Diversity (Vielfalt).] OID_802_11_SUPPORTED_RATES Hierbei handelt es sich um einen Satz untersttzter Datenraten, mit denen der Transceiver betrieben werden kann. Datenraten werden in Form von 8Oktetten codiert, wobei jedes Oktett eine einzelne untersttzte Rate in Einheiten von 0,5Mbit/s definiert. Untersttzte Raten, die zum Satz der Basisraten des BSS (BSSBasicRateSet) gehren, werden fr Rahmen, wie z.B. Steuerungs- und Broadcastrahmen, verwendet. Jede untersttzte Rate, die zum BSSBasicRateSet gehrt, wird als Oktett codiert, wobei das MSB (Bit7) auf 1 festgelegt wird. So wird beispielsweise eine Rate von 1Mbit/s, die zum BSSBasicRateSet gehrt, als 0x82 codiert. Raten, die nicht zum BSSBasicRateSet gehren, werden codiert, indem das MSB auf 0 festgelegt wird. So wird beispielsweise eine Rate von 2Mbit/s, die nicht zum BSSBasicRateSet gehrt, als 0x04 codiert. Datentyp:NDIS_802_11_RATESAbfrage:Gibt den Satz der untersttzten Datenraten zurck, mit der der Transceiver betrieben werden kann.Festlegen:Nicht untersttztStatusanzeige:Nicht untersttztOID_802_11_DESIRED_RATES Hierbei handelt es sich um einen Satz von Datenraten, die fr den Betrieb des Transceivers gewnscht sind. Datenraten werden in Form von 8Oktetten codiert, wobei jedes Oktett eine einzelne Rate in Einheiten von 0,5Mbit/s definiert. Rahmen, die an den Transceiver gerichtet werden, knnen mit anderen als den untersttzten Raten, die zum BSSBasicRateSet gehren, gesendet werden. Datentyp:NDIS_802_11_RATESAbfrage:Gibt den Satz der Datenraten zurck.Festlegen:Legt den Satz der Datenraten fest.Statusanzeige:Nicht untersttztOID_802_11_CONFIGURATION Konfiguriert die Parameter des Transceivers. Datentyp:NDIS_802_11_CONFIGURATIONAbfrage:Gibt die aktuelle Konfiguration des Transceivers zurck.Festlegen:Legt die Konfiguration des Transceivers fest.Statusanzeige:Nicht untersttztOID_802_11_STATISTICS Ruft die aktuellen statistischen Informationen ab. Datentyp:NDIS_802_11_STATISTICSAbfrage:Gibt die aktuellen statistischen Informationen zurck.Festlegen:Nicht untersttztStatusanzeige:Nicht untersttzt OID_802_11_ADD_WEP Der WEP-Schlssel sollte nicht im permanenten Speicher abgelegt werden. Er sollte nicht mehr verfgbar sein, sobald die Karte die Funkverbindung zu allen BSSIDs trennt oder wenn die Shared Key-Authentifizierung mithilfe des WEP-Schlssels fehlschlgt. Durch einen zweiten Aufruf desselben Indexes muss der vorherige Wert berschrieben werden. Datentyp:NDIS_802_11_WEPAbfrage: Nicht untersttztFestlegen:Legt den gewnschten WEP-Schlssel fest.Statusanzeige:Nicht untersttztOID_802_11_REMOVE_WEP Der WEP-Schlssel sollte nicht im permanenten Speicher abgelegt werden. Er sollte nicht mehr verfgbar sein, sobald die Karte die Funkverbindung zu allen BSSIDs trennt. Datentyp:NDIS_802_11_KEY_INDEXAbfrage: Nicht untersttztFestlegen:Entfernt den gewnschten WEP-Schlssel.Statusanzeige:Nicht untersttztOID_802_11_DISASSOCIATE Trennt die Funkverbindung zur aktuellen Dienstsatzidentifizierung und deaktiviert den Transceiver. Datentyp:Diesem Satz ist kein Datentyp zugeordnet.Abfrage: Nicht untersttztFestlegen:Trennt die Funkverbindung zur aktuellen Dienstsatzidentifizierung und deaktiviert den Transceiver.Statusanzeige:Nicht untersttztOID_802_11_POWER_MODE Datentyp:NDIS_802_11_POWER_MODEAbfrage:Gibt den aktuellen NDIS_802_11_POWER_MODE-Wert zurck.Festlegen:Legt den aktuellen NDIS_802_11_POWER_MODE-Wert fest. Statusanzeige:Nicht untersttzt OID_802_11_BSSID_LIST Diese OID gibt die Liste aller ermittelten BSSIDs einschlielich ihrer in der Datenstruktur angegebenen Attribute zurck. Die zurckgegebene Liste der BSSIDs entspricht der zwischengespeicherten Liste, die in der Datenbank der IEEE802.11-NIC gespeichert wird. Die Liste der BSSIDs in der Datenbank der IEEE802.11-NIC entspricht dem Satz der BSSs, die von der IEEE802.11-NIC whrend des letzten Scanvorgangs im Hinblick auf mgliche BSSs ermittelt wurden. Ein Aufruf dieser OID sollte zu einer sofortigen Rckgabe der Liste der BSSIDs in der Datenbank der IEEE802.11-NIC fhren. Wenn diese OID ohne vorherigen Aufruf von OID_802_11_BSSID_LIST_SCAN aufgerufen wird und die IEEE802.11-NIC aktiv ist, kann eine Liste mit BSSIDs zurckgegeben werden, die auf diejenigen BSSIDs beschrnkt ist, die gem der aktuellen Konfiguration der IEEE802.11-NIC als gltig angesehen werden. Wenn diese OID jedoch direkt auf einen Aufruf von OID_802_11_BSSID_LIST_SCAN folgt, sollte die Liste der BSSIDs smtliche BSSIDs umfassen, die von OID_802_11_BSSID_LIST_SCAN ermittelt wurden. Datentyp:NDIS_802_11_BSSID_LISTAbfrage:Gibt die NDIS_802_11_BSSID_LIST-Struktur zurck.Festlegen:Nicht untersttztStatusanzeige:Nicht untersttztOID_802_11_BSSID_LIST_SCAN Ein Aufruf dieser OID fhrt dazu, dass die IEEE802.11-NIC einen Scanvorgang im Hinblick auf mgliche BSSs anfordert. Hierbei werden die folgenden Parameter verwendet: BSSType = sowohl Infrastruktur-BSSs als auch unabhngige BSSs BSSID = Broadcast-BSSID SSID = Broadcast-SSID ScanType = entweder aktiv, passiv oder eine Kombination aus dem passiven und dem aktiven Scanverfahren ChannelList = alle zugelassenen Frequenzkanle Beim Aufruf dieser OID fhrt die IEEE802.11-NIC einen Scanvorgang aus (wobei das aktive oder passive Scanverfahren oder eine Kombination aus aktivem und passivem Scanverfahren zum Einsatz kommt), um die Liste der BSSIDs in der Datenbank der IEEE802.11-NIC zu aktualisieren. Um einen Aufruf dieser OID abzuschlieen, ist das aktive Scannen vorzuziehen, da es das schnelle Auffllen der von der NIC gefhrten Datenbank ermglicht. Das passive Scannen fhrt zu Verzgerungen, da der Eingang von Ankndigungen abgewartet werden muss. Wenn die IEEE802.11-NIC momentan mit einer bestimmten BSSID und SSID verbunden ist, die nicht in der von diesem Scan generierten Liste der BSSIDs enthalten sind, sollte die Beschreibung der momentan verbundenen BSSID und SSID zur Liste der BSSIDs in der Datenbank der IEEE802.11-NIC hinzugefgt werden. Antworten smtlicher BSSs auf Frequenzkanlen, die in dem jeweiligen Funkbereich, in dem die IEEE802.11-NIC momentan betrieben wird, zulssig sind, sollten in die Liste der BSSIDs in der Datenbank der IEEE802.11-NIC aufgenommen werden. Datentyp:Diesem Satz ist kein Datentyp zugeordnet.Abfrage: Nicht untersttztFestlegen:Fhrt einen Scanvorgang im Hinblick auf mgliche BSSs durch.Statusanzeige:Nicht untersttzt OID_802_11_ AUTHENTICATION _MODE Legt den IEEE802.11-Authentifizierungsmodus fest. Datentyp:NDIS_802_11_AUTHENTICATION_MODEAbfrage:Aktueller ModusFestlegen:Legt den Authentifizierungsmodus Open System oder Shared Key oder den automatischen Wechsel zwischen diesen beiden Modi fest.Statusanzeige:Nicht untersttztOID_802_11_PRIVACY_FILTER Legt den IEEE802.1X-Vertraulichkeitsfilter fest. Datentyp:NDIS_802_11_PRIVACY_FILTERAbfrage:Aktueller ModusFestlegen:Legt den offenen Filtermodus oder die 802.1X-Filterung fest (0 entspricht der offenen, 1 der 802.1X-Filterung).Statusanzeige:Nicht untersttztAnhangB: Angabe einer Identittszeichenfolge in einer EAP-Identity-Request-Nachricht Die im Folgenden beschriebenen Informationen wurden einem von Microsoft verfassten Internetentwurf entnommen, der im Jahr2000 beim IETF eingereicht wurde. In diesem Anhang wird definiert, wie die Zeichenfolge in einer EAP-Identity-Nachricht zum Bereitstellen der Informationen verwendet werden muss, die ein Client bentigt, um zu entscheiden, welche Anmeldeinformationen er angeben muss. bersicht EAP ist ein erweiterbares Authentifizierungsprotokoll, das im Rahmen der PPP-Authentifizierung (Point-to-Point Protocol) und der IEEE802.1X-Authentifizierung verwendet wird. IEEE802.1X ermglicht den authentifizierten Zugriff auf die folgenden LANs: Ethernet, Token Ring und IEEE802.11. Wenn PPP verwendet wird, ist das Ziel normalerweise bekannt, so dass die zu verwendenden Anmeldeinformationen ebenfalls bekannt sind. Wird IEEE802.1X verwendet, ist das Ziel nicht im Voraus bekannt, so dass die erforderlichen Anmeldeinformationen ebenfalls nicht bekannt sind. EAP-Identittszeichenfolge EAP ermglicht es, eine Zeichenfolge zur EAP-Identity-Request-Nachricht hinzuzufgen; diese Zeichenfolge wird jedoch nicht auf die bliche Weise verwendet. Mit IEEE802.1X knnen, basierend auf dem Inhalt dieser Zeichenfolge, einige ntzliche Ergebnisse erzielt werden; so knnte z.B. eine Netzwerkbezeichnung gesendet werden, der die Auswahl der geeigneten Anmeldeinformationen ermglicht. Auf diese Weise wird das Roaming ermglicht, ohne dass paarweise bereinstimmungen erforderlich sind. Verwenden von EAP Als Antwort auf eine Identittsanforderung wird eine Nachricht gesendet, die den Namen des Benutzers enthlt, der den Zugriff auf das Netzwerk anfordert. Format der EAP-Identittszeichenfolge Diese Zeichenfolge sollte das folgende Format aufweisen: Eine durch Null beendete, anzuzeigende Zeichenfolge die Anzeige fr den Benutzer. Eine durch Kommas getrennte Liste mit Namen die Wertepaare. NetworkID-Name Bei dem Wert von NetworkID kann es sich z.B. um einen RADIUS-Bereich handeln. Die folgende Zeile enthlt ein Beispiel fr eine mgliche Anzeige: Zeichenfolge\0networkid=Microsoft.com,networkid=exchange.Microsoft.com,foo=bar. Sicherheitsaspekte Die Nachrichtenformatierung und die Verwendungsregeln werfen keine neuen Sicherheitsprobleme auf. IANA-berlegungen Hinsichtlich der IANA (Internet Assigned Numbers Authority) mssen keine besonderen Aspekte beachtet werden. Weitere Informationen Eine ausfhrliche Darstellung von EAP finden Sie in: Blunk, L. und J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC2284, Mrz1998. MS-MPPE-Send-Key Beschreibung Das MS-MPPE-Send-Key-Attribut enthlt einen Sitzungsschlssel fr die Verwendung durch das MPPE-Protokoll (Microsoft Point-to-Point Encryption). Wie der Name schon andeutet, dient der Schlssel zur Verschlsselung von Paketen, die vom NAS an den Remotehost gesendet werden. Dieses Attribut wird nur in Access-Accept-Pakete eingebunden. Im Folgenden finden Sie eine Zusammenfassung des Formats des MS-MPPE-Send-Key-Attributs. Die Felder werden von links nach rechts bertragen. 0 1 2 3 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Salt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 16 fr MS-MPPE-Send-Key. Vendor-Length > 4 Salt Die Lnge des Salt-Feldes betrgt zwei Oktette. Das Feld stellt die Eindeutigkeit der Schlssel sicher, die verwendet werden, um jedes der in einem Access-Accept-Paket verwendeten verschlsselten Attribute zu verschlsseln. Das MSB (Most Significant Bit, werthchstes Bit), also das am weitesten links befindliche Bit des Salt-Feldes, muss auf (1) festgelegt werden. Der Inhalt jedes Salt-Feldes in einem Access-Accept-Paket muss eindeutig sein. String Das Klartextfeld String setzt sich aus drei logischen Unterfeldern zusammen: den Feldern Key-Length und Key (beide erforderlich) und dem optionalen Padding-Unterfeld. Das Key-Length-Unterfeld ist ein Oktett lang und gibt die Lnge des unverschlsselten Key-Unterfeldes an. Das Key-Unterfeld enthlt den eigentlichen Verschlsselungsschlssel. Wenn die zusammengefasste Lnge (in Oktetten) der unverschlsselten Unterfelder Key-Length und Key kein gerades Mehrfaches von 16 ist, muss das Padding-Unterfeld vorhanden sein. Wenn diese Feld vorhanden ist, ist seine Lnge variabel und beluft sich auf einen Wert zwischen 1 und 15Oktetten. Vor der bertragung muss das String-Feld folgendermaen verschlsselt werden: Bilden Sie eine Klartextversion des String-Feldes, indem Sie die Unterfelder Key-Length und Key verketten. Fllen Sie gegebenenfalls die sich daraus ergebende Zeichenfolge auf, bis ihre Lnge (in Oktetten) ein gerades Vielfaches von 16 ergibt. Es wird empfohlen, fr das Auffllen Null-Oktette (0x00) zu verwenden. Nennen Sie diese Klartextversion P. Nennen Sie den gemeinsamen geheimen Schlssel S, den aus einer 128-Bit-Pseudo-Zufallszahl bestehenden Request Authenticator (aus dem entsprechenden Access-Request-Paket) R und den Inhalt des Salt-Feldes A. Unterteilen Sie die Klartextversion in 16-Oktett-Blcke p(1), p(2)...p(i), wobei i = Lnge(P)/16. Nennen Sie die Blcke mit verschlsseltem Text c(1), c(2)...c(i) und den endgltigen verschlsselten Text C. Die Zwischenwerte b(1), b(2)...c(i) sind erforderlich. Die Verschlsselung erfolgt folgendermaen ('+' kennzeichnet eine Verkettung): b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) Das resultierende verschlsselte String Feld enthlt Folgendes: c(1)+c(2)+...+c(i). Beim Empfang wird dieser Prozess umgekehrt, um die Klartextversion der Zeichenfolge zu erhalten. Hinweise zur Implementierung Es ist mglicht, dass der zurckgegebene Schlssel lnger ist, als fr das verwendete Verschlsselungsschema erforderlich ist. In diesem Fall muss der RADIUS-Client die erforderliche Krzung vornehmen. Mithilfe dieses Attributs kann ein Schlssel von einem externen Server (z.B. EAP) an den RADIUS-Server bergeben werden. In diesem Fall ist es dem externen Server eventuell nicht mglich, den Schlssel korrekt zu verschlsseln, da der gemeinsame geheime RADIUS-Schlssel mglicherweise nicht verfgbar ist. Der externe Server sollte das Attribut dennoch wie zuvor definiert zurckgeben; das Salt-Feld sollte mit Nullen ausgefllt und das String-Feld wie erforderlich aufgefllt werden. Wenn der RADIUS-Server das Attribut vom externen Server empfngt, muss er das Salt-Feld korrekt festlegen und das String-Feld verschlsseln, bevor er das Attribut an den RADIUS-Client bermittelt. Wenn der fr die bermittlung des MS-MPPE-Send-Key-Attributs verwendete Kanal nicht abhrsicher ist, muss das Attribut durch Verschlsselung geschtzt werden. MS-MPPE-Recv-Key Beschreibung Das MS-MPPE-Recv-Key-Attribut enthlt einen Sitzungsschlssel fr die Verwendung durch das MPPE-Protokoll (Microsoft Point-to-Point Encryption). Wie der Name schon andeutet, dient der Schlssel zur Verschlsselung von Paketen, die der NAS vom Remotehost erhlt. Dieses Attribut wird nur in Access-Accept-Pakete eingebunden. Im Folgenden finden Sie eine Zusammenfassung des Formats des MS-MPPE-Recv-Key-Attributs. Die Felder werden von links nach rechts bertragen. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Salt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 17 fr MS-MPPE-Recv-Key. Vendor-Length > 4 Salt Die Lnge des Salt-Feldes betrgt zwei Oktette. Das Feld stellt die Eindeutigkeit der Schlssel sicher, die verwendet werden, um jedes der in einem Access-Accept-Paket verwendeten verschlsselten Attribute zu verschlsseln. Das werthchste Bit (Most Significant Bit, MSB), also das am weitesten links befindliche Bit des Salt-Feldes, muss auf (1) festgelegt werden. Der Inhalt jedes Salt-Feldes in einem Access-Accept-Paket muss eindeutig sein. String Das Klartextfeld String setzt sich aus drei logischen Unterfeldern zusammen: den Feldern Key-Length und Key (beide erforderlich) und dem optionalen Padding-Unterfeld. Das Key-Length-Unterfeld ist ein Oktett lang und gibt die Lnge des unverschlsselten Key-Unterfeldes an. Das Key-Unterfeld enthlt den eigentlichen Verschlsselungsschlssel. Wenn die zusammengefasste Lnge (in Oktetten) der unverschlsselten Unterfelder Key-Length und Key kein gerades Mehrfaches von 16 ist, muss das Padding-Unterfeld vorhanden sein. Wenn dieses Feld vorhanden ist, ist seine Lnge variabel und beluft sich auf einen Wert zwischen 1 und 15Oktetten. Vor der bertragung muss das String-Feld folgendermaen verschlsselt werden: Bilden Sie eine Klartextversion des String-Feldes, indem Sie die Unterfelder Key-Length und Key verketten. Fllen Sie gegebenenfalls die sich daraus ergebende Zeichenfolge auf, bis ihre Lnge (in Oktetten) ein gerades Vielfaches von 16 ergibt. Es wird empfohlen, fr das Auffllen Null-Oktette (0x00) zu verwenden. Nennen Sie diese Klartextversion P. Nennen Sie den gemeinsamen geheimen Schlssel S, den aus einer 128-Bit-Pseudo-Zufallszahl bestehenden Request Authenticator (aus dem entsprechenden Access-Request-Paket) R und den Inhalt des Salt-Feldes A. Unterteilen Sie die Klartextversion in 16-Oktett-Blcke p(1), p(2)...p(i), wobei i = Lnge(P)/16. Nennen Sie die Blcke mit verschlsseltem Text c(1), c(2)...c(i) und den endgltigen verschlsselten Text C. Die Zwischenwerte b(1), b(2)...c(i) sind erforderlich. Die Verschlsselung erfolgt folgendermaen ('+' kennzeichnet eine Verkettung): b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) Das resultierende verschlsselte String-Feld enthlt Folgendes: c(1)+c(2)+...+c(i). Beim Empfang wird dieser Prozess umgekehrt, um die Klartextversion der Zeichenfolge zu erhalten. Hinweise zur Implementierung Es ist mglicht, dass der zurckgegebene Schlssel lnger ist, als fr das verwendete Verschlsselungsschema erforderlich ist. In diesem Fall muss der RADIUS-Client die erforderliche Krzung vornehmen. Mithilfe dieses Attributs kann ein Schlssel von einem externen Server (z.B. EAP) an den RADIUS-Server bergeben werden. In diesem Fall ist es dem externen Server eventuell nicht mglich, den Schlssel korrekt zu verschlsseln, da der gemeinsame geheime RADIUS-Schlssel mglicherweise nicht verfgbar ist. Der externe Server sollte das Attribut dennoch wie zuvor definiert zurckgeben; das Salt-Feld sollte mit Nullen ausgefllt und das String-Feld wie erforderlich aufgefllt werden. Wenn der RADIUS-Server das Attribut vom externen Server empfngt, muss er das Salt-Feld korrekt festlegen und das String-Feld verschlsseln, bevor er das Attribut an den RADIUS-Client bermittelt. Wenn der fr die bermittlung des MS-MPPE-Recv-Key-Attributs verwendete Kanal nicht abhrsicher ist, muss das Attribut durch Verschlsselung geschtzt werden. MS-MPPE-Encryption-Policy Beschreibung Mithilfe des MS-MPPE-Encryption-Policy-Attributs kann gekennzeichnet werden, ob die Verwendung der Verschlsselung zulssig oder erforderlich ist. Wenn das Policy-Feld dem Wert 1 entspricht (Encryption-Allowed) kann eine beliebige oder keine der im MS-MPPE-Encryption-Types-Attribut angegebenen Verschlsselungsarten verwendet werden. Wenn das Policy-Feld dem Wert 2 entspricht (Encryption-Required) kann eine beliebige der im MS-MPPE-Encryption-Types-Attribut angegebenen Verschlsselungsarten verwendet werden; die Verwendung einer dieser Verschlsselungsarten ist jedoch erforderlich. Im Folgenden finden Sie eine Zusammenfassung des Formats des MS-MPPE-Encryption-Policy-Attributs. Die Felder werden von links nach rechts bertragen. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Policy +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Policy (Fortsetzung) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 7 fr MS-MPPE-Encryption-Policy. Vendor-Length 6 Policy Die Lnge des PolicyFeldes betrgt vier Oktette. Folgende Werte sind definiert: Encryption-Allowed Encryption-Required Zum Entschlsseln des Radius-Attributs wird folgender Code verwendet: DWORD DecryptMPPESendRecvKeys( IN RADIUSSERVER UNALIGNED * pRadiusServer, IN PBYTE pRequestAuthenticator, IN DWORD dwLength, IN OUT PBYTE pEncryptionKeys ) { BYTE * pbValue = (BYTE *)pEncryptionKeys + 2; BYTE abCipherText[16]; struct MD5Context MD5c; struct MD5Digest MD5d; DWORD dwIndex; DWORD dwBlock; DWORD dwNumBlocks; dwNumBlocks = ( dwLength - 2 ) / 16; // // Durchlaufen der Blcke // for ( dwBlock = 0; dwBlock < dwNumBlocks; dwBlock++ ) { MD5Init( &MD5c ); MD5Update( &MD5c, (PBYTE)(pRadiusServer->szSecret), pRadiusServer->cbSecret); if ( dwBlock == 0 ) { // // Verwenden des Request Authenticators und des Salt-Feldes fr den ersten Block // MD5Update( &MD5c, pRequestAuthenticator, 16 ); MD5Update( &MD5c, pEncryptionKeys, 2 ); } else { // // Verwenden des vorherigen Blocks mit verschlsseltem Text // MD5Update( &MD5c, abCipherText, 16 ); } MD5Final( &MD5d, &MD5c ); // // Speichern des verschlsselten Textes aus diesem Block. // CopyMemory(abCipherText, pbValue, sizeof(abCipherText)); for ( dwIndex = 0; dwIndex < 16; dwIndex++ ) { *pbValue ^= MD5d.digest[dwIndex]; pbValue++; } } return( NO_ERROR ); } Generieren der EAPOL-Key-Nachricht Zum Generieren der EAPOL-Key-Nachricht mssen Sie Folgendes verwenden: Recvkey fr die md5-Signatur und IV+sendkey fr die rc4-Verschlsselung. (Beachten Sie, dass die Schlssel MPPE-Send und Recv lnger als notwendig sein knnen. In diesem Fall verwenden Sie die ersten XByte, die Sie bentigen.) RC4_KEYSTRUCT rc4key BYTE keybuffer[48] memcpy(keybuffer, IV, 16) memcpy(&keybuffer[16], mppesendkey, 32); rc4_key(&rc4, 48, keybuffer) rc4(&rc4, KeyLength, KeyMaterial); Generieren der MD5-Signatur Zum Generieren der MD5-Signatur mssen Sie Folgendes verwenden: Das Paket, das bei der EAPOL-Protokollversion beginnt und diese umfasst, bis zum Ende des Pakets, einschlielich des ENCRYPTED-Schlsselmaterials; Beispiel: das Paket nach dem Ethernet-Header, wie er mit Signatur0 gesendet wird. Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Verffentlichung dar. Da Microsoft auf sich ndernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Verffentlichung nicht garantieren. Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT SCHLIESST FR DIESES DOKUMENT JEDE GEWHRLEISTUNG AUS, SEI SIE AUSDRCKLICH ODER KONKLUDENT. Die Benutzer sind verantwortlich fr die Einhaltung aller anwendbaren Urheberrechtsgesetze. Unabhngig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrckliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments fr irgendwelche Zwecke vervielfltigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhngig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht. Es ist mglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrcklich in den schriftlichen Lizenzvertrgen von Microsoft eingerumt. 2001 Microsoft Corporation. Alle Rechte vorbehalten. Microsoft, BackOffice, Windows und WindowsNT sind entweder eingetragene Warenzeichen oder Warenzeichen der Microsoft Corporation in den Vereinigten Staaten und/oder anderen Lndern. Weitere in diesem Dokument aufgefhrte Produkt- oder Firmennamen knnen geschtzte Marken ihrer jeweiligen Inhaber sein. Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA 4/2001 EG]^,;_ y no`x""##W$n$,,\,--//1266666697;7<7E99<<j<DѸj#CJUaJmHsHCJmHsH CJmHsH CJ mHsH5CJ\aJmHsHCJaJmHsH 0JCJaJjCJUaJCJaJCJ$aJmHsH5CJ$\aJmHsH5CJ\aJj5CJU\aJ2G,= _ y nN`x.9 & F dd[$\$ & Fdd[$\$ & Fdd[$\$xwE0 ""$s%'*,,\,-//12246 & F dd[$\$66666;7E99K:<<j<==R>>Q?@_@UABCD EFOGzG & Fdd[$\$ & Fdd[$\$ & Fdd[$\$DD EOGzGZ[7\U\]].^a^``bbccyeeEh\hhh i2i8iIiiiiiiiiiiij0jlm7m8mAmYmZmzm{mmmmmn n)n*nQnRnsnnnͻ貨衞CJ CJmHsH5CJ\mHsH 5CJ\CJCJaJCJOJPJQJ^JaJ0JmHsH5CJ\aJmHsH CJ mHsHCJaJmHsH CJmHsH5\mHsH>zGUIIJKLMNO,PPQIRRSnTqUVWo]o^o`oaobo$Ifbocolooo2,,,$If$$IfKֈq#BK0X34Kabooooo,$$IfKֈq#BK0X34Kab$Ifooooooo$Ifooooo2,,,$If$$IfKֈq#BK0X34Kabooooo,$$IfKֈq#BK0X34Kab$Ifooppppp$Ifpp!p:p;p2,,,$If$$IfKֈq#BK0X34Kab;p=p?pApBp,$$IfKֈq#BK0X34Kab$IfBpKpapbpdpepfp$Iffpgppppp2,,,$If$$IfKֈq#BK0X34Kabppppp,$$IfKֈq#BK0X34Kab$Ifppppppp$Ifppppp2,,,$If$$IfKֈq#BK0X34Kabppppp,$$IfKֈq#BK0X34Kab$Ifppppppp$Ifppqqq2,,,$If$$IfKֈq#BK0X34Kabq q!q#q$q,$$IfKֈq#BK0X34Kab$If$q-qHqIqJqLqNq$IfNqOqXqxqyq2,,,$If$$IfKֈq#BK0X34Kabyq{q}qqq,$$IfKֈq#BK0X34Kab$Ifqqqqqqq$Ifqqrr20.$$IfKֈq#BK0X34Kabrrstptuuvvww xxyB{Q{||X~x~ap7 & F$dd[$\$Hm2s^r$J4vɗR]tН$ & F'dd[$\$̚2AśAK]t ϞWlšâآ$4ޣĦΦpy*6@Jcl%Yh >FGMSdmwvGXήR[rίݯCJaJ CJmHsH CJmHsH 0JmHsHCJ5CJ\aJmHsHCJaJmHsHQ$4ޣȤҤ'2>Raʥإ & F*dd[$\$#2>N\iĦΦ$%Yh v & F-dd[$\$ & F*dd[$\$@ ͵#0'R.@>Qݯ@ʰ q{͵#04@'Rm@LκϺlsʻػ.@>Q)(L\{+ijCJaJCJOJPJQJ^JaJ0JCJaJmHsH CJmHsH5CJ\aJmHsHCJCJaJmHsHM)L\{+>J=I(1(>J=Iy(1}Pd:,)$FGH *9B̻̻̻̻ڮmHsHj33CJUaJmHsH CJOJPJQJ^JaJmHsH 0JmHsH CJmHsH CJ mHsH CJmHsH5CJ\aJmHsHCJaJmHsHCJBAn}-lPd:,|)$FHL *SW~^ & F6dd[$\$ & F3dd[$\$ & F0dd[$\$Ws~T8e/FJKVb".%25< K^_0JCJaJmHsH>*CJaJmHsHj>*CJUaJ CJ mHsH CJmHsHCJ 6CJ]aJCJaJ5CJ\aJ5CJ\aJmHsH CJmHsHCJaJmHsH>T8b.q%25 K & F@dd[$\$^ & F9dd[$\$K<  c  I  E    &ETg & FCdd[$\$567VW%&'}~ETgizYmE%!k* ,  _!!""~""#?#@#ֶֹCJ CJmHsH CJmHsH CJ mHsHCJaJCJ CJaJmHsH0JCJaJmHsHj>*CJUaJ>*CJaJmHsHE:ilAD]zY]!FBBmpEm!Pl .TB%Lw!Jkn*JV#Y<<nq W, s    _!!!!!""~""#'#$If'#?#@#J##########&&0(u$$IfK0 q# 0'634KaZb$If@########0(K(L(l(m(((((((())a)b))))))))))9*:********++K+L++++++<,W,X,,,,,--6-9/M/i/v////00F0G000000u1115CJ\aJmHsH5CJ\mHsHCJaJCJCJ CJmHsHCJaJmHsH CJmHsHO0(:(K(L(V(l(m(x(((((((((u$$IfK0q#>J 0'634KaZb$If(()a)b)m))))))))))x$Ifu$$IfK0q#>J 0'634KaZb)))9*:*E*********+LH$Ifu$$IfK0/ q# 0'634KaZb+++K+L+W+++++++<,F,W,$Ifu$$IfK0/ q# 0'634KaZbW,X,a,,,,,,,--6--?..x$Ifu$$IfK0/ o# 0&634KaZb.9///000F0G0R000000u$$IfK0q# 0'634KaZb$If00u111116272B222222Pu$$IfK0 q#~ 0'634KaZb$If11111$2-26272Q2^2d2h222222x333330414R4S4l444'5K5L555555555(6w6x666666&7D7E77777778 88X8a8p88899M9N99999999:%:4:CJ5CJ\aJmHsHCJaJCJ CJmHsHCJaJmHsH5CJ\mHsH CJmHsHO22x333333330414@4R4S4(u$$IfK0q#0'634KaZb$IfS4l4'515K5L5U555555555u$$IfK0q# 0'634KaZb$If55(6;6w6x66666666&707xu$$IfK0 q#~ 0'634KaZb$If07D7E7N777777777p888$u$$IfK0 q#~ 0'634KaZb$If8899 9M9N9Y9999994:O:4,u$$IfK0q#0'634KaZb$If4:O:===>>:>;>\>]>v>?@@?@@@n@o@@@@@@@?A@AyAzAAAAABBHBIBfBgBBBBCDD,D-DaDbDDDDDEdEeEEEEEEEETFFFFFGG6G7GMGnGoGGGGGHH,H^LLLLLLLLCJ CJmHsHCJaJCJCJaJmHsH CJmHsHXO:M;<=====>>(>:>;>J>\>]>xu$$IfK0Oq#0'634KaZb$If]>v>??@@@?@@@K@n@o@~@@@u$$IfK0q# 0'634KaZb$If@@@@@@A?A@AKAyAzAAAA u$$IfK0 q#i 0'634KaZb$IfAAAABBBHBIBTBfBgBvBBBxu$$IfK0 q#i 0'634KaZb$IfBBCCDDD,D-D8DaDbDqDDDtu$$IfK0q# 0'634KaZb$IfDDDENEdEeEoEEEEEEEEEtu$$IfK0q# 0'634KaZb$IfEETF^FFFFFFFGG$G6G7Gtu$$IfK03o#0&634KaZb$If7GMGWGnGoGxGGGGGGHHHH,Hu$$IfK04q#0'634KaZb$If,HsJ^LhLLLLLLLLLLLLxu$$IfK0q# 0'634KaZb$IfLLMM.NR/S0SLSMSSSSSSST8T9TRTSTTTTTULUqUrUUUVV)V*VV XXLZgZV\W\i\]*]]^^!^^^^^`_r___`````:bJbbcccccccc%e)e0J5CJ\aJmHsH CJmHsH CJ mHsHCJ CJmHsHmHsH CJmHsHCJaJCJCJaJmHsHJLMMMN.NNNPRS/S0S:Sttu$$IfK0 o#i 0&634KaZb$If & FFdd[$\$ :SLSMSXSSSSSSSTT8T$u$$IfK0 o#i 0&634KaZb$If 8T9TBTRTST^TTTTTTULUVUqUh($Ifu$$IfK0J o#S5 0&634KaZbqUrU{UUUUVVV)V*VVW XXh~$Ifu$$IfK0q#>J 0'634KaZbXLZgZV\i\]*]d]]]^^^^`_r___```abbbbcWc & FIdd[$\$Wcbccccccceeuhikk.lelilmlqllllam~mIn1pq^ & FLdd[$\$)ecegeeeeef fff=fDfTf^fffffPgZg_gbgggChIhhhhhhhjjklllllam~mooppppppq(qqqqqq6sFssttttu uuuKvOvvvvvvv(w2w7w:wcwjwzwwwwCJCJCJaJ CJmHsH5CJ\aJmHsHCJaJmHsHVqqqrssst:t}ttttttu uvvyz }T}}}}}^ & FOdd[$\$wwwvxxxxxxjypyyyyyyy{{ }}}}~%~~~&,Ɂρ>Nւ ܃;APQ^qmDž(69@NTЇև 0JmHsHCJ CJmHsHCJ CJmHsHCJaJ5CJ\aJmHsHCJaJmHsHJ}}~%~~~oWւ0DžЅT|׆(69@ & FRdd[$\$^b͌ȍ܍!?cŽV & FXdd[$\$ & FUdd[$\$ & FRdd[$\$ KLkl~͈Έ"#12DEijlm‰Ӊԉ!"5678:;ko-.01VWXYrsuv0J5\mHsH 0JmHsH CJOJPJQJ^JaJmHsHX<=GHIJKL_`ab͌Ԍ8AFJcLNĕƕ-/wy߻߻߻߻߻߻߳dz6CJ]aJ6CJ]aJmHsHCJaJ5CJ\aJmHsH CJmHsHCJaJmHsH 0JmHsH CJOJPJQJ^JaJmHsH*Nƕ/y$1h/R . A!"#$n%#Dd0*HH  C vA^..\..\..\..\..\Eigene Dateien\technet_logo.gifb"ꪵd0KLk9漋 "Dn"ꪵd0KLk9漋 PNG  IHDR<x}~PLTE$+$$6N<<<8MknX__cNip |{L}~a^^mi]_cgegdfikagaqgqiө$pq}ψѭyڳ¹iֺ3CUU 8D(4D6df')vDLf R0%}wgUS-aNmQfusﭮN-wg'LJe;vvzZH>8z}vvz|#O?ۗw4`g'`ic`he2l!p; ӊh1qkzUWKl?lO&-_}w€&4tDή;o{5ކhby\q?a/ussNЪAָgЊtEU 8Ϋ(/ 4-a@4trC=;cKnZ܆W**UVU@8+6v+ #9гA2x_0/ 'O^k K >"h| 1gElqV#|*ϲ%d04gfa -r_  pc~ +n{/oqj>)-cyF`iU^\!@4HYPo`lnZOE{ŧoFg*%u3CwM Irt3/'+)1VWN_鸬H@C0v\Uьh :T~]Hp$|=E;޺4| } $yBxL۲x7 ʒ%eCiEzGp4ǪٲQUŦ')Ek%+eٕ|} o>%nwBp3C')Mࢮ6탽A}4:ixM:~t8Ч|4y̪'_0/bhCT(C!JCW_!F 0 ~rY %tֵ!-~6ɑ 6Ism Iټ:I2$[I;t6ު%`~~+"C YiF=]կ!.<3aɔʎ:5:w!vvGIo!/PN(s$<($mT^9֠kQ*u_& ʍ:7l8q)m: v]NxW| Rߢݭg8uDǀȃ6*oc@U1u@=(e #TIDjY\Q@#4ȴkWpsF\R3rS)Di y|lvѿz|ww+s:C'?ItՁT @/Wrѫ^7IqCW9f[Q#;<lBBp4mќe*& F?j`J,?]i&'GwV=q偿''ogEI 1TCC5uH!dv {)Iwz;Gj,yR:eՁDܽbD7hd"kԁ0UƱ{\"$#DyNE=+k+۲e {h@߼܆|F!ê=M;)BtőkDИA:NA`VɡuBF3GF mTFm+d?7z]Ne` ToDG3}[`׽-W5t:tB;Bx /Y WZN&4N`촗͗ EC庈6֐P! TaUު,nfVhFaSzGSO5(TqűXpPnMLj8I=e+В䠹K=Ĕ|BVp}4{eWqPU19 icJF'92_6W̐*9l(ډlA]\ 6 Xjf=e= HtYTGjBT\bNtѱ قJ,?:'O1)ʾ:ytWi4tT?h ꄀ;?|W |S!cYT+zK}rK$]# ̩E w:ji}mE4Qp+wKعgY ^՘ :MY)#DZ,-'XfRR̉. C*L)>8-Ӣ&Wji%F2'?/$Z)2&{Kp)x=לx'4 -YǾ;$4dg2]A BS`ƯiuIWr>/ z&ib/+?.vxogqrloەStgE%~rh+ AϪ<뿶"]$1B[u@ɝL߽+O@it":,LivDN7~CT\V},9V9mEX Qt;~4#JC~ qhem3@4E2zOq molۅ}"ejkNl|^CƌuIs y8bQ.wRʁ LS.wJsnE`$e9[Nݴ3ACgTZYq0na!W,"7z yQJ.ΥL~Zet%f9y΂6nvqfڃ9(H, ~CzM^R餺o0}YNvߗB{E b]5/"尋6yTz  H=f5-GC7%9kg~l^g(ck`#atZ&Q&{*ǍU9}uUOWHk@Gb̌):>vQo,1ݿ2 e.ƨ$E 4l몃Q%ʲ{^)+4#*ГjZ#)sm;eGfwҌx`R0[OGlCB3ե ,9sW;y|HcQlZ_z؂9h6p(S@HD $k 4 y\wYL͎ܲq9cP["!ֶ 7/BDOKA)GzR:\< ͑J(ro1% ^] 1=Nw&ZlQU =*G5fbN5Dʤ;tgX_iTu̝L7d""#͟՜ry`P&7FM#lE6x-PɺSK}W#GsH|~7Cpw(a/.Sa\ 44&݃q!HL8bgӃ9}ە O{Bه(_-iQ-2I?GX|m;% $1js݄NӴ(~r_le`hhf9hot'3Ws Dɏ\Wy1e r7f=HV~tOs,T _z00ʕV(GJA!q>8Bgپse ܪﲋթSB]wguQv c 9H+/d F^NӔ]YN {s92(Ra4Uo㳒p>srCPNQv-Og:^>;72aNYX~(6nɎ %}~Ѩ%VDaQ,t!tN84Β-h()V0 \2$ݱZ9ߌbcNGQaAyHO|O6!+ R:2hg$<(P$4kw)fƑ҉Z4:VtWSF̒F BmE,tUa$qg:p7s5hlwch4MW < ߴfc̥#ST[XM}:JY}^^;J]mizH}4CX.(#QNp,Q_,O.?Ϟ}ųCK/MXzˊ`+4!.GE\g)8hATJ:쓁Tu(I,K=j0QfQ3$8;XRv>6}1KAch"rʈ+|TIK𢼈Уթ>F_Q^ƀU0l5s!iX4K/RX HE5%77ħ |l'he%A:N.K q#3a}?bT坲HS\Fmi Q#a!i+|#.Ba[->IxeHWo м}'j/- 0yDKD|M)ψ"{r$_]́&y?B,ɰwmP KuDQгKzPf 7geYRXFO'^Q}N6i=?vXHּlR* :9.#ۥ2xKDB!PgLkBڲVZo3Sc aYƛ;+k"-!H?(E/ jfyB|Z AVXQG`}y;͛&``R)Q4=0ŔZ?E쌟!Z"vm%h΄6O0%\z!!˽0 N' -FCb_gjg̅;4n2g8̭,J2e'@YfA,ʅ'J<`<@Geko,N /߯&ֶ3 MB[_*:7qiѸ쐒OѲ+[C M6۩-s*( b#F11&Z)J5CZ+ hg^nL+.E Z/ yI⤝ z3MXh0Jp0m$ń73-~M6LH\cZ lψ&hUV+Vq kgh"|"iYwu)=|0)qܡ}beF9l H{X.#D.^6<z>YCc5ݵ,0t"YLk ;^!Jέ6UBX-/40D 1mGayNblng-)N.{N´v,w/SXvJ t MJx cLC9~8'k2?$k|sLh:EuF*Iш yȬȒ@&(ZS?\7blҏR2+g,CUy"@;1 l9*05>Qjdj+o ߪ)3zow >~ZK~:[9ł@IWPY;QC0F5u8IjUiPɯs|#aJR~1SY86cha|#⥎CnK1%NLLIegeCWlq*k.GP˷Uo^JiR434WTM[a9jQ^'ctJnw`-uƺFP9HP:X15B@gOv_@EWoG[5B9 =Cjo&"0׺\'*r}Z[3Z[GoI,v}n5ag{e˨PckͿ#$w*\)4gŎ3<Q4Vԇ=9X|xCb&cBĥڽ1BKbZ#B@SmQ[J/_IENDB`lDdhd  C @A(images\IEEE0101.GIFbI8.m-/' $nI8.m-/'PNG  IHDR9LPLTE """)))UUUMMMBBB999|PP֭3f333f3333f3ffffff3f̙3ff333f333333333f33333333f33f3ff3f3f3f3333f33̙33333f333333f3333f3ffffff3f33ff3f3f3f3fff3ffffffffff3ffff̙fff3fffff3fff333f3f3ff3ff33f̙̙3̙ff̙̙̙3f̙3f̙333f3̙333f3ffffff3f̙̙3f̙3f3f333f3333f3fff̙fff3f̙3f3f̙fffffffff!___www˲𠠤X"NbKGDH cmPPJCmp0712Hs IDATx^햣 D{}wD|mSR9g^@gnO$zbԧ>RK]>:m,RkqFJ++*k?g=Nz0qɮd.|đlP*?hg[8뻏2KiAO}v_~ܤ:o^[a\]ikIFXa&|8i^^d^M0EM ;5'@9JBs9ɾk{a,F:|7G7W+\q B+\spsŻy5 FEFYk\sr"Wℕӱe3%.ۺ{Jg|u4U(Ծ:sPyF%Dg|e@J˰qT1Rx= ׫+uľ7&,r.;1SYfΞ5^}}q'cBs[|H˫W.$X2_iװ~]\-.]3}(X&.Cy޼uuej{ a:;z_m:_oO^/ӟ {ݟ7-h5?|m s:03^gmԕf)46 Wv|><^>-USoi{SǼ}k^08&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8+8&b8576׸ᾼ>nP㔆3|5U^::mZU*l8}}>84{3W&Fȷ+mZ{MvC52I^Iډ4h'k'"ӐWg4'pNC^vҜv"9 yuIsډ4h'k'"ӐWg4'pNC^vҜv"9 yuIsډ4h'͍uKdD[z}p:K׎ƣ5$qjY٪ڙ#K:k%X^-ܩ<&4ySWWǐ6_qd˿UtymEۮr.rەW.VYn*"mW^[EVd+ڊ,]yo]^[ {TʟB?U/IENDB`Dd{ d  C @A(images\IEEE0102.GIFbMB@mY=aw3nMB@mY=aPNG  IHDRĐ*?PLTE """)))UUUMMMBBB999|PP֭3f333f3333f3ffffff3f̙3ff333f333333333f33333333f33f3ff3f3f3f3333f33̙33333f333333f3333f3ffffff3f33ff3f3f3f3fff3ffffffffff3ffff̙fff3fffff3fff333f3f3ff3ff33f̙̙3̙ff̙̙̙3f̙3f̙333f3̙333f3ffffff3f̙̙3f̙3f3f333f3333f3fff̙fff3f̙3f3f̙fffffffff!___www˲𠠤X"NbKGDH cmPPJCmp0712Hs -IDATx^v( $ n6vgi]@˜X||.m٣ѯ^3_k{sLBoLBoLBoLBoջ[&pj֜g`S+s;!q N`sU` HTmZljs͑*"+؜ _V[B)Qo߃P9@LA-*v7U#U-BןxP9v9Ы&\"\}Gu*4$\2xSIHRj7pm*$sA6ssUU܅C$`sWME+7xP9v9Ы&s5#ӹ0+Wɖ[zϋp@)rVۮ3o)bVQBVyژ*VSie04cUP0d턪T0>FuKMRFpI({չN-\px(*#;ճXy:Y+f RNZt]O׊ᮒEj9Gz[?g ܊q%;t$ڃsrԝ~6պLWK].UOkYSuTT/pY4T?]zpkvKR1N4y1(K)q \m Yջ(i-Hc Ju*z=XfIUµxfUoU)0Tu҇mR"G3j*9^⓹:37L5pT̔ͰuU>z^W.b`m|Z=80Y)[\ҪM+3?JyR jt( n s#LT aB1 bT(A2ѡ΅F*nJGH<^WSâq?):`궡t4Tuo^WgQ$!fVKSa9phbEsRϠ= y0`sNT@/~m!h۫ $UCжW!HmTn;2poP̊#}5p;uN9:!ii5Ro }P5VV+akU.t w^<1PrV7CE*V*i{fUqbvS9W:,\(Be(eCc#I3W?1jo c p {tKmPt-WGOڈ)ڃI9W 2Yο;!U"U1Y(=v2Z\AFM',Nxj7>?O5gxDJ?5iNn锃Yݏo2pEUlo-߼N4w:[مj ,Douh:y,?ꉆmVFUQřl#TmmTP $Tߦ>H=qJC)PNl(ӵW/x9QN_>wʼnzKjr;?52c6ԕsa/_v0`sAdIic6I/_v0`sAdIic6/>#r`{[$dAr`ͅF1z*"C%l.؍1*sIhҠrO%*s4Q9's A  L G9C$xA>Ä8sF:Q9'g`8 t0!q؅aA庴Ckfn5w+ZK:'J|phrRvXvC4sQ%P'cphrGJ75sQ%S=;U0*Jl1IENDB` i8@8 NormalCJ_HaJmH sH tH J@J Heading 1dd@&[$\$5CJ0KH$\aJ0F@"F Heading 2dd@&[$\$5CJ$\aJ$F@2F Heading 3dd@&[$\$5CJ\aJ<A@< Default Paragraph Font.U@. Hyperlink >*B*ph>V@> FollowedHyperlink >*B* ph:b@: HTML CodeCJOJPJQJ^JaJ:^@": Normal (Web)dd[$\$~G,=_y n N`x.9wE0 s!#&,(\()++-..026222;3E55K6<8j899R::Q;<_<U=>?@ ABOCzCUEEFGHIJK,LLMINNOnPqQRSk]k^k`kakbkcklkkkkkkkkkkkkkkkkkkkkkkllllll!l:l;l=l?lAlBlKlalbldlelflglpllllllllllllllllllllllllllllmmm m!m#m$m-mHmImJmLmNmOmXmxmym{m}mmmmmmmmmmnnropppqqrrss ttuBwQwxxXzxz|ap7Hm2s^r$J4vɓR]tЙ$4ޟȠҠ'2>Raʡء#2>N\iĢ΢$%Yh v@ ͱ#0'R.@>Q)L\{+>J=I(1An}-lPd:,|)$FHL *SW~T8b.q%25 K<cIE &   E T g      : i l   AD]zY]!FBmpEm!Pl .TB%Lw!Jkn*JV#Y<nq W,s_~'?@J&"0$:$K$L$V$l$m$x$$$$$$$$$$%a%b%m%%%%%%%%%%%%9&:&E&&&&&&&&&'''K'L'W'''''''<(F(W(X(a((((((())6))?**9+++,,,F,G,R,,,,,,,u-----6.7.B.......x////////0010@0R0S0l0'111K1L1U1111111111(2;2w2x22222222&303D3E3N333333333p444455 5M5N5Y55555546O6M7899999::(:::;:J:\:]:v:;;<<<?<@<K<n<o<~<<<<<<<<=?=@=K=y=z=======>>>H>I>T>f>g>v>>>>??@@@,@-@8@a@b@q@@@@DANAdAeAoAAAAAAAAAATB^BBBBBBBCC$C6C7CMCWCnCoCxCCCCCCDDDD,DsF^HhHHHHHHHHHHHHIIIJ.JJJLNO/O0O:OLOMOXOOOOOOOPP8P9PBPRPSP^PPPPPPQLQVQqQrQ{QQQQRRR)R*RRS TTLVgVVXiXY*YdYYYZZZZ`[r[[[\\\]^^^^_W_b_______aaudegg.hehihmhqhhhhai~iIj1lmmmnooop:p}ppppppq qrruv yTyyyyyyz%zzzo{W}~~~0ǁЁT|ׂ(69@b͈ȉ܉!?cŠVNƑ/y00000000000_0_0 0 0 0 00` 0`0`0` 0`0` 0`0` 0` 0` 0` 0` 0` 0` 0` 0`00000000000,(0,(00+0+0-0-0-0+0202020200E50E50E50<80<8 0<8 0<8 0<80<8 0<8 0<80<8 0<80<80E50@0@0E5 0OC 0OC 0OC 0OC 0OC 0OC 0OC 0OC 0OC 0 OC 0 OC 0 OC 0 OC 0 OC 0OC 0OC 0OC 0OC 0OC 0OC 0OC00V0V07X 07X 07X 07X0V0Y 0Y 0Y 0Y 0Y0V0ya! 0ya! 0ya! 0ya0ya0V0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0V0m$ 0m$ 0m$ 0m$ 0m$ 0m0m00r0r0s0s0r0t(0t0Bw(0t0x(0t0Xz0Xz0Xz(0t00000(0t00(0t0H0H0H0H00r0r0r0$0$' 0$' 0$' 0$(0$000(0$0]0]0]0]0](0$0$0r0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0 ޟ* 0 ޟ* 0 ޟ* 0 ޟ* 0 ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0ޟ* 0 ޟ* 0!ޟ(0ޟ0Ģ0Ģ(0ޟ0(0ޟ0Y(0ޟ0 (0ޟ0- 0- 0- 0(0ޟ0(0ޟ0(0ޟ0(0ޟ0 (0ޟ0(0ޟ0(0ޟ0(0ޟ0(0ޟ0#(0ޟ0'(0ޟ0(0ޟ0(0ޟ0(0ޟ0.(0ޟ0>(0ޟ0(0ޟ0(0ޟ0(0ޟ0L(0ޟ00(0ޟ0{0{0{(0ޟ0(0ޟ0>(0ޟ0=(0ޟ0(0ޟ000(0(00(000(00}0}0}0(0P(0P000(00(0000000$0$0$0$0 0$0 0$0$000$0 0$00$(003 03 0(006 06 06 0(0009 09 009 09 009 09 009 09 009 09 0 00000(00%@ 0%@ 0%0%00 0 0 000000C 0C 0C 0C 0C 0C 0C 0C 0C 0C 0 C 0 C 0 C 0 C 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0(00>0>0>0>0>0>0>0>0>0>0>0>0>(000000000000000(00o#0o#0o#0o#0o#0o#0o#0o#0o#0o#0o#0o#(0(00c$0c$0c$0c$0c$0c$0c$0c$0c$0c$0c$0c$(00n%0n%0n%0n%0n%0n%0n%0n%0n%0n%0n%0n%0n%(00&0&0&0&0&0&0&0&0&0&0&0&0&(00'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'0'(00f+0f+0f+0f+0f+0f+0f+0f+0f+0f+0f+0f+0f+(00-0-0-0-0-0-0-0-0-0-0-0-0-(00/0/0/0/0/0/0/0/0/0/0/0/0/(000000000000000000000(00x10x10x10x10x10x10x10x10x10x10x10x10x10x1(0003003003003003003003003003003003003003003(0040404040404040404040404040404(009090909090909090909090909(00Q;0Q;0Q;0Q;0Q;0Q;0Q;0Q;0Q;0Q;0Q;0Q;0Q;(00\<0\<0\<0\<0\<0\<0\<0\<0\<0\<0\<0\<0\<(00I=0I=0I=0I=0I=0I=0I=0I=0I=0I=0I=0I=0I=(00D?0D?0D?0D?0D?0D?0D?0D?0D?0D?0D?0D?0D?(00@0@0@0@0@0@0@0@0@0@0@0@0@(00A0A0A0A0A0A0A0A0A0A0A0A(0(00B0B0B0B0B0B0B0B0B0B0B0B0B0B(00GF 0GF 0GF 0GF 0GF 0G0G0G0G0G0G0G0G0G0G0G0G0G0G0G(00xN0xN0xN0xN0xN0xN0xN0xN0xN0xN0xN0xN0xN(00O0O0O0O0O0O0O0O0O0O0O0O0O00P0P0P0R0P0 U0P0W(0W0WI 0WI 0W(0W0X0X0P0Y0P0 Z0P0Z0P(0N[0_[0_[0_[0_[0_[0_[0_[0_[0_[(0N[0e^(0N[0^(0N[0^(0N[0b`L 0b`0b`0b`0b`0b`0b`0b`0b`0b`0b`0b`0b`(0N[0!h0!h0!h0P(0Vl0gl0gl0gl0gl0gl0gl0gl0gl0gl(0Vl0o(0Vl0o(0Vl0o(0Vl0qO 0q0q0q0q0q0q0q0q0q0q0q0P0Gy0Gy0Gy0P(0|}0}0}0}0}0}0}0}0}0}(0|}0(0|}0(0|}0R 0R 000(0|}0"U 0"U 0"U 0"U 0"U 0"U 0"U 0"(0|}0#X 0#X 0#00000000000000000Dnݯ@#14:L)ew   &079<=6zG\m8mYmtm{mmmmn$n*nQnsnnnn o/o5oboooooop;pBpfpppppppq$qNqyqqqr$KB<'#0(()+W,.02S45078O:]>@ABDE7G,HL:S8TqUXWcq}   !"#$%'()*+,-./1234568:;>]^5V%}XXXXXX8@0(  B S  ?hiiii(i)iAiZici{iiiiii jj*j3jRjijjjsjjjjjjjjj kk5k>kcklkkkkkkkl!lBlKlglpllllllllm$m-mOmXmmmrr7K':j}M`3F/B}   #     Ry thorstenl8D:\_work\Technet2002\02\final\ieee802_155871\ieee802.doc Claudia Sca+J:\ToSub\2002_02\ieee802_155871\ieee802.docxx8Hx"LO`E9V ^T|9t}7lJ L- (D&((aaJ\1Uy;7.6>`:>cPGJz=X}NJE TR6 bYb_Z(QO[&o%I\ns~b ʐnhؒh>kXθ-l\6?o6yCu><kby R|^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`.^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`CJOJQJ^Jo(opp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.^`CJOJQJo(^`.pp^p`.@ @ ^@ `.^`.^`.^`.^`.PP^P`.Xx"x" y;7y;7 ?o?o _Z_Zd -l-l yCuyCu ((H J J  V V  :>:>, aJ\1aJ\1x - (- ( PGJPGJ s~bs~b\ &(&( bYbY kbykby@ }} nhnh .6>.6>$ p O[O[ h>kh>k E TE TT =X}N=X}N o%I\o%I\ E9E98 xxxx X50staQspeRcheSzunTlsUn dVatiW geXeisb 4 |J2* .h蠢H VӂjʮO0a`u2F]Jc0#>:n r N~xږJs &ʿQtp`,n.P~`0 ::F{>2;f;o0τ.wprt3X ,it?hw8_n.0EX`QpZC$3&)iZڄ.-E tR䀾>؟rQTDZNGDЄZ`bgM.lX1 > f?H|VmZpDfM,G.Hh#w|JķCrGG,q2}Ә $,X |^VHLlpҬ&tQP$ :#}42 ,KNzVƔ02n~@.ν,& *t"1lW BɶVR^JdH,lDˬ, CNOX(ࢥ*eYrG&:ȿ GIܼ|8p즬k]k^k`kakbkcklkkkkkkkkkkkkkkkkkkkkkkllllll!l:l;l=l?lAlBlKlalbldlelflglpllllllllllllllllllllllllllllmmm m!m#m$m-mHmImJmLmNmOmXmxmym{m}mmmmmmmmmm'?@J0$:$K$L$V$l$m$x$$$$$$$$$$%a%b%m%%%%%%%%%%%9&:&E&&&&&&&&'''K'L'W''''''<(F(W(X(a((((((())++,,,F,G,R,,,,,,u-----6.7.B......x////////0010@0R0S0'111K1L1U111111111(2;2w2x2222222&303D3E3N3333333334455 5M5N5Y55555599999::(:::;:J:\:]:;;<<<?<@<K<n<o<~<<<<<<<=?=@=K=y=z======>>>H>I>T>f>g>v>>>??@@@,@-@8@a@b@q@@@DANAdAeAoAAAAAAAAATB^BBBBBBBCC$C6C7CMCWCnCoCxCCCCCCDDD^HhHHHHHHHHHHHHNO/O0O:OLOMOXOOOOOOPP8P9PBPRPSP^PPPPPPLQVQqQrQ{QQQQRRR)R*R@0+P@UnknownGz Times New Roman5Symbol3& z Arial?5 z Courier New"1h+[&J[-^:L0d 2CVorbereiten des Einsatzes von IEEE 802.11-Netzwerken in Unternehmen thorstenl Claudia ScaOh+'00 DP l x DVorbereiten des Einsatzes von IEEE 802.11-Netzwerken in Unternehmenorb thorstenln horhor Normal.dot  Claudia Sca6auMicrosoft Word 9.0s@NSI@f f@ni^:L՜.+,D՜.+,x4 hp   LocatechE DVorbereiten des Einsatzes von IEEE 802.11-Netzwerken in Unternehmen Title 8@ _PID_HLINKSA6*9$http://standards.ieee.org/wireless/2* $http://www.microsoft.com/windowsxp/= /http://www.microsoft.com/germany/ms/windowsxp/HZ&http://www.microsoft.com/windows2000/G1http://www.microsoft.com/germany/ms/windows2000/.|Ohttp://www.microsoft.com/technet/itsolutions/network/deploy/depovg/ieee802.aspMi/..\..\..\..\..\Eigene Dateien\technet_logo.gifV26images\IEEE0101.GIFU2Fimages\IEEE0102.GIF  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`acdefghijklmnopqrstuvwxyz{|}~Root Entry FPYiData @C1TablebWordDocument&~SummaryInformation(DocumentSummaryInformation8CompObjjObjectPoolPYiPYi  FMicrosoft Word Document MSWordDocWord.Document.89q