Application of IEEE 802.1X in HiperLAN type 2

Table of contents

ABSTRACT

ACKNOWLEDGEMENT

TABLE OF CONTENTS

PART 1: IEEE 802.1X AND RELATED PROTOCOLS
1 INTRODUCTION
1.1 WIRELESS LANS
1.2 SECURITY
1.3 METHODOLOGY AND ACHIEVED RESULTS FOR THE THESIS WORK
1.4 TYPICAL OPERATIONAL ENVIRONMENT
2 HIPERLAN 2
2.1 OVERVIEW
2.2 PROTOCOL ARCHITECTURE
2.2.1 The Physical layer
2.2.2 The DLC layer: basic data transport function
2.2.3 The DLC layer: RLC sublayer
2.2.4 The packet based convergence layer
2.3 HIPERLAN 2 SECURITY FEATURES
2.3.1 Key exchange
2.3.2 Encryption
2.3.3 Authentication
3. IEEE 802.1X
3.1 GENERAL CONCEPTS AND ARCHITECTURAL FRAMEWORK
3.2 PACKET FORMAT AND PROTOCOL EXCHANGE
3.3 IMPLEMENTATION ISSUES
3.4 DEPLOYMENT OF IEEE 802.1X IN WIRELESS LANS
4 EAP
4.1 EAP-TLS
4.2 EAP-GSS AND OTHER EXTENSIONS
5 RADIUS
5.1 RADIUS’S GENERAL FEATURES
5.2 BASIC OPERATIONS
5.3 RADIUS PACKETS
5.4 RADIUS ATTRIBUTES
5.4.1 User related attributes
5.4.2 NAS related attributes
5.4.3 Service related attributes
5.4.4 Session specific attributes
5.5 RADIUS EAP EXTENSIONS
5.5.1 EAP-Message
5.5.2 Message-Authenticator
5.6 RADIUS AND IEEE 802.1X

PART 2: APPLICATION OF IEEE 802.1X IN HIPERLAN 2
6 ANALYSIS METHODOLOGY
6.1 THE PROTOCOLS
6.2 THE OPERATION
6.3 THE PROTOCOL EXCHANGE AND THE AUTHENTICATION METHODS
6.4 THE SOFTWARE REQUIREMENTS
6.5 WHY IEEE 802.1X AND HIPERLAN/2
7 IEEE 802.1X AND HIPERLAN/2: THE PROTOCOLS
7.1 IEEE 802.1X AS A PART OF THE HL/2 PROTOCOL ARCHITECTURE
7.2 INTERACTION BETWEEN THE HL/2 AND IEEE 802.1X
7.2.1 First Step: basic assumptions
7.2.2 Second step: interface to the protocols
7.2.3 Third step: using LLC
7.2.4 Fourth step: completing the model
7.2.5 Complete model
8 IEEE 802.1X AND HIPERLAN/2: THE OPERATION
8.1 THE ASSOCIATION PROCEDURE
8.2 THE CONTROLLED AND UNCONTROLLED PORT
8.2.1 Management operations
8.2.2 Solution
9 IEEE 802.1X AND HIPERLAN/2: PROTOCOL EXCHANGE AND AUTHENTICATION
METHODS
9.1 AUTHENTICATION METHODS: BASIC ISSUES
9.1.1 Challenge-response
9.1.2 Mutual authentication
9.2 BASIC AUTHENTICATION SCHEMAS
9.2.1 Strong participation of the authenticator
9.2.2 Less participation of the authenticator
9.2.3 Minimal participation of the authenticator
9.3 AUTHENTICATION EXCHANGE
9.4 A CERTIFICATE-BASED AUTHENTICATION METHOD: A MODEST PROPOSAL
9.4.1 The protocol exchange
9.4.2 The format of the EAP packet
9.4.3 Issues
10 THE SOFTWARE REQUIREMENTS AND ARCHITECTURE
10.1 GENERAL ISSUES
10.2 SOFTWARE ARCHITECTURE ON THE MT-SIDE
10.2.1 A simple software architecture for the MT
10.2.2 A complete architecture for the MT
10.3 SOFTWARE ARCHITECTURE ON THE AP-SIDE

PART 3: IMPLEMENTATION AND TESTING
11 THE IMPLEMENTATION
11.1 BASIC FEATURES OF THE PROTOTYPE
11.2 THE MT-SIDE IMPLEMENTATION
11.3 THE AP-SIDE IMPLEMENTATION
12 TESTING
12.1 THE TESTBED
12.2 THE TESTING METHODOLOGY AND RESULTS
12.2.1 The RADIUS communication
12.2.2 Communication between supplicant and authenticator
12.2.3 Testing of the state machines
12.2.4 Testing results: summary

PART 4: CONCLUSIONS AND FINAL REMARKS
13 CONCLUSIONS AND FINAL REMARKS
13.1 SUMMARY
13.2 ACHIEVED RESULTS
13.3 FUTURE WORK
REFERENCES
TABLES OF FIGURES
BIBLIOGRAPHY
APPENDIX A: THE AUTHENTICATION PROCESS
APPENDIX B: STRUCTURE OF THE IMPLEMENTATION
B.1 FILES COMMON TO BOTH AP AND MT
B.1.1 802_1Xv9.h
B.1.2 timer.cpp
B.1.3 generalFunc.cpp
B.1.4 globalFunc.cpp
B.1.5 keyreceive.cpp
B.2 FILES ONLY INCLUDED IN THE MT
B.2.1 supplicant.h
B.2.2 supplicant.cpp
B.2.3 maindll.cpp
B.2.4 eapFunction.cpp
B.2.5 supp_key_tran.cpp
B.3 FILES ONLY INCLUDED IN THE AP
B.3.1 authenticator.h
B.3.2 maindll.cpp
B.3.3 authenticator.cpp
B.3.4 authKeytrans.cpp
B.3.5 backend.cpp
B.3.6 contrDir.cpp
B.3.7 reauthen.cpp
B.3.8 RADIUSfuncs.cpp
APPENDIX C: THE USAGE OF THE MICROSOFT EAP APIS
C.1 LOOKING UP IN THE REGISTRY
C.2 SETTING UP THE EAP APIS
C.3 CONFIGURATION AND START UP
C.4 MESSAGE EXCHANGE

Abstract

The research within Information Technology has been subject to a tremendous speed-up in the latest years, mainly due to the reduced prices of the related technology and, consequently, to a strongly increased interest of the users. This causes a positive feedback loop, since many companies decide to invest more money in such area, reducing further the prices and accelerating this process.

One of the major issues in this big race has been the concept “Be connected always and everywhere”, which translated in an increased development of public networks on one side and in a further growth of big corporation networks on the other side. The common factors of these big areas are mobility, which implies wireless networks, and availability of services, which also means access to more or less important information.

Increased size, mobility and availability of services on networks that become bigger and bigger increases tremendously the importance of data-security. Trust, authentication, and authorization have become vital key words within the design of big, mobile networks.

IEEE 802.1X, also known as “Port Based Network Access Control” is a means for providing authentication and authorization for big networks that offer the possibility to many devices to attach to them, making their services available.

This master thesis work, carried out at Ericsson Enterprise AB, Wireless LAN Systems in Sundbyberg (Sweden), had as a primary objective to study the authentication and authorization standard IEEE 802.1X (Draft version 11, released March 27th 2001) and its integration in HIPERLAN type 2 (HIPERLAN/2), which is a standard for wireless LAN. The project has been accomplished for the Department of Signals and Systems at the Chalmers University of Technology in G ö teborg, Sweden. The goals of the thesis work were to analyze the current version of the standards and other related protocols in order to gain competence in the area of the study how IEEE 802.1x could be integrated in HIPERLAN/2 based network. In this work we propose a solution for the implementations problem and design, develop and test a basic prototype.

The result shows that IEEE 802.1x can be deployed within a wireless network based on HIPERLAN/2 by adapting certain features of the two standards and by adopting certain rationale while developing an architecture based on them.

This report is structured in such a way to mirror the different goals of the thesis.

Part 1: Contains a description of the current version of the standard and of other related protocols that collaborate and participate in enhancing security in a typical LAN environment.

Part 2: Illustrates the methodology that has been used and the achieved results in order to integrate IEEE 802.1X and an HIPERLAN/2-based network.

Part 3: Describes roughly the implementation of the prototype, its limitations and further work to make it usable in a professional and non-experimental environment; furthermore, it describes the result of the testing operation.

Part 4: Concludes the report by summarizing the whole work, by illustrating the achieved results and by giving some suggestions for a follow-up of this thesis work.

Acknowledgement

I am very much grateful to my supervisor Yi Cheng at Ericsson Enterprise AB for her valuable consultation and support throughout this thesis work.

I would also like to sincerely thank my examiner at Chalmers, Prof. Arne Svensoon. I take this opportunity to express my sincere thanks to:

Associate Prof. Eric Str ö m, Program Director Digital Communication and Systems Technology at Chalmers, for his administrative help, his directions, for the opportunity he gave me to continue my studies and to join Ericsson for my degree project.

Ann-Marie Danielsson Alatalo, Study Counsellor of Electrical and Computer Engineering at Chalmers University of Technology, who encouraged me with her advice and guidance through out my studies at Chalmers including here her frequent follow up.

Mikael Larsson, for the administrative help he gave me at Ericsson Enterprise AB.

Marco Casole, my partner in this thesis project at Ericsson Wireless LAN Systems, for his significant help in understanding many security issues and his co-operation in many aspects through out the project.

As well as all people at Ericsson Enterprise, Wireless LAN Department, that helped me in many practical matters.

Finally, very special thanks to Alem Tekeste, my husband who has been always supporting my choices; and to my sweet son Yonathan who has made his personal sacrifices on his own way.

PART 1: IEEE 802.1X and related protocols

The basic understanding of the concepts of this thesis project are described in this part of the report.

- Chapter 1: States a short introduction

- Chapter 2: The basic concepts concerning HIPERLAN 2 are illustrated

- Chapter 3: Describes the IEEE 802.1X standard

- Chapter 4: Deals with the Extensible Authentication Protocol (EAP), which is a fundamental part of the IEEE 802.1X standard and with two of its extensions, EAP-TLS and EAP-GSS.

- Chapter 5: A brief description of RADIUS is given, with particular emphasis on the extensions that allow the use of EAP within RADIUS.

1 Introduction

This chapter aims to give a general overview of the topics of this master thesis, which are wireless LANs, security, and their integration. Furthermore, the last two Sections will depict how the project has been developed, which results have been achieved, and in which environment it will fit.

1.1 Wireless LANs

A Wireless local area network (WLAN) is a flexible data communication system implemented as an extension to or as an alternative for a wired LAN. Using radio frequency (RF) technology, wireless LANs transmit and receive data over air, minimizing the need for wired connection. Thus, wireless LANs combine data connectivity with user mobility.

Wireless LANs have gained strong popularity in a number of vertical markets, including health-care, retail, manufacturing, warehousing, and academia. These industries have profited from the productivity gains of using hand-held terminals and notebook computers to transmit real-time information to centralized hosts for processing. Today’s wireless LANs is becoming more widely recognized as a general-purpose connectivity alternative for a broad range of business customers.

A WLAN connects users within a local area, which might be a building or campus, using radio signals to send data. The basic issues, which differentiate WLANs from telephone cellular networks or satellite networks, are frequencies, data rates, coverage area and legal issues. The emphasis of the wireless LANs environments is driven by the strong efforts spent by companies in order to improve data rates, reliability, and quality of service of such networks. Current available standards have data rates up to 11 Mb/s; there are other standards, such as 802.11a and HiperLan2, which will reach data rates up to 54 Mb/s and products based on them are in a development phase. The standardization and availability of such networks will easily pave the way to their adoption and wide spreading.

The possibility to use such networks without having any cable to connect to a plug and the increased user mobility will definitely encourage its use by corporations and public place administrators. The following list describes some of the many applications of wireless LANs:

- Corporate

With a wireless LAN, corporate employees can take advantage of mobile networking for e-mail, file sharing, and web browsing regardless of where they are in the office.

- Education

Academic institutions leverage the benefits of mobile connectivity be enabling users with notebook computers to connect to the university network for collaborative class discussions and to the Internet for e-mail and web browsing.

- Finance

By carrying a handheld PC with a wireless LAN adapter, financial traders can receive pricing information from a database in real-time and improve the speed and quality of trades. Accounting audit teams increase productivity with quick network setup.

- Healthcare

Using wireless handheld computers to access real-time information, healthcare providers increase productivity and quality of patient care by eliminating patient treatment delays, redundant paperwork, potential transcription errors, and billing cycle delays.

- Hospitality and Retail

Hospitality services can use wireless LANs to directly enter and send food orders from the table. Retail stores can use wireless LANs to set up temporary registers for special events.

- Manufacturing

Wireless networking helps link factory floor workstations and data collection devices to a company's network.

- Warehousing

In warehouses, handheld and forklift-mounted data terminals with barcode readers and wireless data links are used to enter and maintain the location of pallets and boxes. Wireless improves inventory tracking and reduces the costs of physical inventory counts.

Wireless networks may even be used in so-called ad-hoc networks, where no central entity provides for access control or authentication. Usually one entity may be elected as a traffic controller or a resource manager. Examples may be in conference rooms, where participants want to exchange information, or home environments, in order to achieve as sometimes addressed as “the wired home” or the “connected home”.

1.2 Security

Nowadays Security becomes a very important issue. One consequence is that many existing protocols, which were not originally endowed with security facilities, have now been added with further protocol layers and add-ons, in order to allow their use in hostile environments.

The expansion of open networks, such as the Internet, makes data communications more subject to threats; the probability of an attack grows as the importance and the amount of data travelling on networks increases.

Security is today mainly perceived as a feature, which endow higher-level protocols with, although sometimes it is required to protect communication on the lower level.

Security services on high-level protocols imply a bigger awareness of the user and the necessity to adapt applications. On the other hand a finer granularity can be obtained, up to be able to protect data on a per- document basis, such adapting the cost of the security algorithm to the actual value of the data being transmitted. Furthermore, the protection is ensured from source to destination, thus obtaining an end-to-end protection.

IEEE 802.1X, which is one of the main topics of this thesis, defines a protocol to achieve authentication before allowing access to network services. The authentication occurs at the first point of attachment to a LAN and not somewhere in the core of it. This has implication in terms of increased security, reduced complexity, greater scalability and availability.

Security is a common and very important issue of wireless LAN; users perceive a connection without wires as particularly unsecured, although the real difference from normal wired networks lies at the physical layer. As previously hinted at, the medium through which a WLAN sends data is the air, which means that it has non-defined boundaries and that it is unprotected from outside signals. These features lead basically to two kinds of attack, which are typical of the wireless medium.

Eavesdropping is a kind of passive attack that consists in listening to the communication that is happening on the medium. Because there are no real boundaries of the wireless medium, this kind of attack can be easily performed by having a transceiver, which is able to demodulate correctly the signals being transmitted on the network. This kind of attack can be avoided by using particular kinds of modulations (Frequency Hopping Spread Spectrum or Dynamic Selection Spread Spectrum) which make the attacker need to know other parameters than the transmission frequency, or by encrypting the session.

Denial of service is a kind of active attack that aims to prevent a user to have access to certain or all services. It can be achieved in several ways; on the physical level, it consists in sending burst of signals with no meaning. This prevents users to send signals, since the medium results busy, or to understand the signals being sent.

1.3 Methodology and achieved results for the thesis work

The thesis work has gone through different stages, which were necessary in order to achieve the goal that has been proposed. The whole work started with an intensive study work, whose aim was to gain a deep knowledge of the subject. This was necessary to pass to the next stage and to create a competence in the area, which was actually one of the main goals of the master thesis.

After this preliminary study-phase, the second goal was to propose a model of integration between IEEE 802.1X and HIPERLAN/2. The basic question that needed an answer was: “How can a network, based on the HIPERLAN/2 standard, use IEEE 802.1X to perform authentication and access control”. In order to provide for a solution to this problem the following aspects have been considered:

- How these two standards integrate on a protocol point of view.
- How the operation of the HIPERLAN/2 standard needs to be modified or adapted in order to be used with IEEE 802.1X.
- How a protocol exchange can look like and which authentication methods could be used.
- What the requirements and the possible software architecture for a complete implementation are.

Part 2 of the report illustrates how these aspects have been analyzed and what kind of solution has been proposed for each of those problems.

The next step was to build a prototype of the IEEE 802.1X standard, in order to evaluate its feasibility and how it can be deployed in a complete environment. Unfortunately, there are no HIPERLAN/2 complete product available on the market and it was therefore necessary to implement the prototype on a different kind of network. Many of the conclusions of the previous step were nonetheless still applicable. The prototype was then tested in a complete environment: the basic protocol exchange was tried out and some other additional features were added. Part 3 describes and summarizes the work that has been done. Part 4 of this report depicts the conclusions that might be drawn from the thesis and tries to outline some basic concepts that result form the whole project. Furthermore, it gives some guidelines for continuing the work that has started here.

1.4 Typical operational environment

IEEE 802.1X was designed in order to provide a means of authenticating devices being attached to a port of a network access point and willing to have access to the network infrastructure services. Typically, this is needed in environments where the access to the network is publicly available, or within networks with many point of attachments, thus making it difficult to check each of them without having any precise security and administration policy. Such environments may be big corporations’ LANs, possibly with areas where the network is publicly available, technology or business parks, conference rooms, airports or train stations, malls, and even some open-air environments with public network access.

The focus of this thesis is a business wireless environment with a relatively high number of points of attachments but no public access. An example of this is given in Figure 1.

illustration not visible in this excerpt

Figure 1: A typical operating environment.

The corporate network is mainly based on a fixed Ethernet network, fully or almost fully switched. Within this network it is possible to have wireless access through some wireless protocol, let’s say HiperLAN2. The access points to the wireless network are connected to the fixed network and act as bridges to it. They are therefore endowed at least with the Ethernet Service Specific Convergence Sublayer (SSCL) [HL2ETSSCL] in order to match different kind of services and adapt PDUs of the different networks. Each mobile terminal will be identified, within the global corporation network, by its 48 bits IEEE MAC address, while within the HiperLAN2 segment it will be only addressed by its 8 bits MAC ID.

The authentication of the mobile terminals in order to grant them access to the network resources will be achieved through IEEE 802.1X. The authentication server will be a RADIUS server located on the fixed network and accessible through it. In order to get information, the RADIUS server will have access to a WINDOWS 2000 Active Directory through the Lightweight Directory Access Protocol (LDAP). Mobile terminals will be based on Windows 98, Windows 98 Second Edition or Windows 2000 Professional as operating systems. Servers on the network will be based on Windows 2000 Server or on Windows NT 4 as operating system. The business environment now described is mainly characterized by the following features:

- Host can access all or almost all resources locally available.
- No charging is required.
- Hosts are subject to administration and management.
- The environment can be assigned a certain level of trust.
- Key and certificate distribution is not so difficult.

This environment can somehow be considered as experimental, since the Windows 2000 based environments are still on a way to be better defined and it is still not possible, at the current time, to have a complete working HiperLAN2-based network.

Figure 2 provides another view of the described environment.

illustration not visible in this excerpt

Figure 2: A working operative environment.

To summarize, the focus of the thesis is business environment with wireless access to the network. The deployed wireless standard will be HIPERLAN/2 in the business configuration ([HL2BUE]), which means configured to work in the centralized mode, i.e. with Access Points controlling the communication, allowing the flow of packets to the wired network and allocating resources. Authentication and access control will be based on IEEE 802.1X; t r will be placed on the fixed network. It will likely be a Windows 2000 Server machine; acting as Internet Access Server (IAS), which incorporates a RADIUS server. The RADIUS server will retrieve user and access information from a Windows 2000 Active Directory.

2 HIPERLAN 2

The European Telecommunications Standards Institute (ETSI) has started the Broadband Radio Access Network (BRAN) project, which aims to develop a set of standard for broadband wireless networks. The categories of systems covered by the BRAN project are summarized as follows:

- The first result of this project was a standard called High Performance Radio Local -Area Network, type 1 (HIPERLAN 1) are compatible with wired LANs based on Ethernet and Token Ring standards. This system is intended to be operated in the 5GHz band.
- The following standard was HIPERLAN 2, which provides high speed radio communications system with typical data rate from 6 MHz to 54 Mbits /s. It can access to different broad-band core networks and moving terminals, with QoS support.
- The recent projects, which have planned but not started yet, are HIPERACCESS, which will provide outdoor, high speed (25 Mb/s), fixed radio access, and HIPERLINK, which will provide extremely high-speed (up to 155 Mb/s) radio links for static interconnections.

2.1 Overview

The standardization activity of HIPERLAN 2 gave its first result in 1999. HIPERLAN 2 [HL2OV] operates within the 5 GHz spectrum, in Europe it will be placed in the ranges between 5.15 and 5.30 GHz, and between 5.470 and 5.725, for a 455 MHz wide spectrum. In USA and Japan, it will be allocated different intervals, according to local policy rules.

The topology of a typical HIPERLAN 2 based network is illustrated in Figure 3, it has Access Points (APs), which provide for access to the wireless network, and Mobile Terminals (MTs), which are the devices willing to have access to the network. The APs will typically be attached to a fixed network. This operating way is called centralized mode since all traffic passes through the access point, even if it is directed from one MT to another MT that is connected to the same AP. The AP is in charge of allocating resources, giving access to a fixed network, and other administrative tasks. All MTs, before operating, need to establish an association with an AP, in order to be allowed to operate on the HIPERLAN 2 network; an association procedure consists of link and capabilities negotiation, and of the establishment of user connections. In order to start to send and receive data, it is necessary to open a DLC user connection (DUC), which defines the features of the data transfer.

It may happen that there is no AP in charge with providing access to a fixed network. In this situation the network will operate in direct mode; the communication between MTs will occur directly from the source to the destination MT, but there is still need of a Central Controller (CC) in charge with allocating resources to the terminals. The result will be an ad-hoc network, whose applications vary form homeenvironments to military infrastructures.

illustration not visible in this excerpt

Figure 3: HIPERLAN 2 centralized mode.

2.2 Protocol architecture

The HIPERLAN 2 protocol has three basic layers. It defines a Physical layer (PHY), with the same semantic of the ISO/OSI layer, while the link level is constituted by different sublayers: the Data Link Control (DLC) layer and the Convergence Layer (CL), which is in charge with providing interoperability with different higher layers (HL) or link layers. The whole protocol stack can be considered divided vertically in two parts: a control plane part, for administrative and control operations, and a user plane part, for the transmission of traffic over the established connections. A complete view is given in Figure 4. The DLC layer, in charge with functions for medium access and transmission as well as connection handling, is made up of a set of sublayers:

- Medium Access Control (MAC) protocol.
- Error Control (EC) protocol
- Radio Link Control (RLC) protocol with the associated signaling entities DLC Connection Control (DCC), the Radio Resource Control (RRC) and the Association Control Function (ACF).

The MAC protocol and the EC protocol constitute the basic data transport functions for the DLC layer.

illustration not visible in this excerpt

Figure 4: HIPERLAN 2 protocol Stack (Source: [HL2DLC]).

2.2.1 The Physical layer

OFDM, the modulation scheme chosen for the HIPERLAN 2 [HL2PHY] standard is very effective in high dispersive environments. The different channels, each of them assigned automatically and dynamically to an AP, are 20 MHz wide. Each channel is further divided into 52 subcarriers; 48 of them are actually used to carry data while the other four are pilots, which facilitate phase tracking for coherent demodulation. The entire bit stream coming from the upper level is divided into different parallel interleaved bit streams and each of them will modulate a subcarrier of a channel. Within a channel, many modulation schemes are possible, such as Binary Phase-Shift Keying (BPSK), Quadrature Phase-Shift keying (QPSK), and Quadrature Amplitude Modulation (QAM), up to 64 QAM, which provides for the maximum data rate of 54 MB/s. A modulation scheme is chosen according to what has been negotiated in the association phase and to local radio conditions. OFDM allows a very robust transmission but needs a well-designed system.

2.2.2 The DLC layer: basic data transport function

The basic data transport functions of the DLC layer [HL2DLC] are made up of the MAC protocol and the EC protocol. As previously hinted, they both have a user panal and a control panal for simple data transmission functions and control functions.

The Medium Access Control (MAC) protocol is in charge of regulating the access to the air interface. The air interface is based on Time-Division Duplex (TDD) and Time-Division Multiple Access (TDMA). This means that within the same time frame, multiple communications are allowed in both downlink (from the AP to the MTs) and uplink (from the MTs to the APs) directions. Time slots are allowed dynamically depending on the current traffic load and different requirements for each connection. Within an HIPERLAN 2 network, an MT is identified uniquely in each cell, i.e. in the area covered by one AP, by its MAC ID, assigned at association time and whose scope is limited to each AP. Since an AP will usually act as a bridge to a fixed network, an MT is likely to be identified by an IEEE MAC address within this broader scope. On higher levels, an MT is likely to be identified by an IP address, and hence mobility issues should be considered as well, especially in handovers, i.e. the operation of association to another AP. In case of multicast data transfer there are two ways to handle this situation: N-Multicast, where it is dealt as N unicast connection, with good reliability but bad bandwidth consumption, or MAC Multicast, where a MAC ID is assigned to each multicast group, saving bandwidth but loosing reliability.

The basic MAC frame structure on the air interface has a fixed duration of 2 ms, repeated every time, and comprises different phases, i.e. part of the frame are devoted to different uses, with fixed or variable length. The Broadcast phase (BC) contains information broadcast to all MTs associated with that AP; the Downlink phase (DL) transports data from the AP to the MTs, while the Uplink phase (UL) is used for data transfer from the MTs to the AP. If direct mode is available, a Direct phase (DiL) is inserted between DL and UL. At the end of the MAC frame, the Random phase (RA) is used by the MT to ask for resources or to start a new association. It is the only phase where contention is possible. Figure 5 depicts the MAC frame.

illustration not visible in this excerpt

Figure 5: HIPERLAN 2 MAC frame (Source: [HL2DLC]).

The DL, DiL and UL phases consist of two types of Protocol Data Units (PDUs): long PDUs and short PDUs. Long PDUs have a fixed size of 54 bytes and contain user data and control data. Short PDUs are 9 bytes long and contain only control data.

Within the different phases, the HIPERLAN 2 standard places the so-called transport channels, which describe the basic message format. They are used to carry different kinds of data, depending on the logical channels, which are mapped onto them.

A logical channel is any distinct path of data; a set of logical channel is defined for different kinds of data transfer services as offered by the MAC entity. Each logical channel is defined by the type of information it carries and the interpretation of the values in the corresponding messages. A logical channel can be considered to operate between logical connections end points and, hence, between logical entities.

The following transport channels are defined:

- Broadcast Channel (BCH). It conveys control information (about transmission power, starting and finishing point of the FCH and RCH (see next paragraph), and identifiers) directed to all MTs.
- Frame Channel (FCH). Contains an exact description of how resources have been allocated within the current MAC frame.
- Access Feedback Channel (ACH). Conveys information on previous access attempts to the RCH.
- Long Transport Channel (LCH). Is used to transport user data that is sent as unicast, multicast or broadcast data, and signaling information for the user connection. Contains long PDUs.
- Short Transport Channel (SCH). Transports control information encapsulated in short PDUs.
- Random Channel (RCH). It is used by the MTs to request transmission resources. It is the only channel where contention is possible. An MT sends a Resource Request (RR) indicating how much and what kind of data it needs to transmit.

The following logical channels have been defined:

- Broadcast Control Channel (BCCH). Contains broadcast control channel information concerning the whole radio cell. Used for sending identifiers of the AP and the net and other information that sometimes is used as beacon.
- Frame Control Channel (FCCH). Describes exactly how resources are allocated within the current frame.
- Random Access Feedback Channel (RFCH). The purpose is to inform those MTs that have used the RCH in the previous frame, about their result of their access attempts. Resources are granted by the AP through Resource Grants (RGs).
- RLC Broadcast Channel (RBCH). Contains broadcast control information concerning the whole cell. It is used to transmit broadcast RLC messages, a MAC ID to a non-associated terminal and convergence layer information.
- Dedicated Control Channel (DCCH). Contains signaling information needed for the user connection and can be used both in the uplink and in the downlink phase. It is established implicitly during the establishment of an association.
- User Broadcast Channel (UBCH). Carries user data coming from the upper convergence layer but directed to all MTs of a cell.
- User Multicast Channel (UMCH). Contains user data coming from the convergence layer, directed to those MTs that joined a multicast group.
- User Data Channel (UDCH). Contains user data directed to an MT.
- Link Control Channel (LCCH). Bi-directional channel used to carry error control messages.
- Association Control Channel (ASCH). Used only to convey information needed for the establishment of a new association.

How the different logical channels are mapped onto transport channels is shown in Figure 6 (downlink) and Figure 7 (uplink).

illustration not visible in this excerpt

Figure 6: Mapping of logical channel to transport channels (downlink) (Source: [HL2DLC]).

illustration not visible in this excerpt

Figure 7: Mapping of logical channels to transport channels (uplink) (Source: [HL2DLC]).

2.2.3 The DLC layer: RLC sublayer

The Radio Link Control (RLC) sublayer [HL2RLC] provides for a transport service for the signaling entities Association Control Function (ACF), Radio Resource Control function (RRC), and the DLC user connection control function (DCC).

Before an MT is allowed to have access to the HIPERLAN 2 network, it must establish an association with the AP or the CC. The MT starts with listening to the BCH of different APs in order to decide where to establish an association, according to the net operator identifier and the best signal. Association requests are conveyed in the Association Control Channel (ACH).

Before starting to transmit traffic, an MT has to establish at least one DLC user connection (DCC). The DCC control signaling is transmitted over the DCCH, in order to control the resources for each MAC entity. The characteristics of each connection may be exchanged during the connection.

The Radio Resource Control (RRC) functions are in charge with the radio link quality operations, which might result in a handover, i.e. an association with a new AP with a better radio signal. In order to avoid a complete disassociation and reassociation, HIPERLAN 2 supports the exchange of information over the fixed network in order to minimize the impact of a handover.

The RRC functions deal also with the Dynamic Frequency Selection (DFS) algorithm, the Power Save features and the MT Alive operations, which supervise if an MT is currently inactive.

2.2.4 The packet based convergence layer

In order to allow interoperability with other kinds of network and higher-level protocols, the HIPERLAN 2 standard defines what is called Convergence Layer (CL). A convergence layer has basically two functions:

- To adapt service requests from higher levels or other kinds of networks to those that are available on the HIPERLAN 2 DLC layer.
- To convert the different format of other protocol, of fixed or variable length, into the format accepted by the DLC layer.

The padding, segmentation and reassemble function of the fixed size DLC Service Data Units (SDU) is one key issue that makes it possible to standardize and implement a DLC and a PHY that is independent of the fixed network to which the HIPERLAN 2 network is connected to.

There are currently two convergence layers defined within the HIPERLAN 2 standard, as depicted in Figure 8. The Cell based CL aims to provide for an interface towards protocols with fixed size PDUs. An example of this is ATM. The Packet based CL provides for an interface towards all those network, which have a variable size PDU. Examples of such networks are UMTS, PPP, Ethernet and IEEE 1394 “Firewire”. The architecture of the Packet based convergence layer is depicted in Figure 9.

illustration not visible in this excerpt

Figure 8: HIPERLAN 2 convergence layers.

illustration not visible in this excerpt

Figure 9: Packet based convergence layer (Source [HL2PBCL]).

The Packet based convergence layer [HL2PBCL] is made up of two parts, a Common Part and a Service Specific Convergence sublayer (SSCS). The common part performs the same kinds of operations for every sort of packet based network, while the service specific part is dependant on the overlying network and allows easy adaptation of higher level services to the DLC services.

The common part is further divided into two sublayers: the Common Part Convergence Sublayer (CPCS), and the Segmentation and RE-assembly (SR) part.

The function of the CPCS is to take packets received from the overlying SSCS, to add padding and additional information and to pass it to the SR part. It has furthermore to remove and interpret padding and information from the packets received from the underlying level, and passes them to the SSCS. The SR part takes packets from the CPCS, segments them into fixed size data unit and passes them to the DLC layer; it also performs the reverse operation, taking packets from the DLC, reassembling them and passing them to the CPCS. It performs an in-order delivery of packets for the CPCS.

Following the general HIPERLAN 2 semantic, even the CL is divided vertically into two parts: a user plane and a control plane, which allow different types of operations.

The Ethernet SSCS [HL2ETSSCS] makes the HIPERLAN 2 look like the segment of a switched Ethernet. Its main functions are to preserve the original frames and to map the services available on an Ethernet-based network to an HIPERLAN 2 network, in terms of QoS and traffic types.

Ethernet SSCS offers basically two different types of QoS:

- The best effort scheme, which is mandatory. It is the default QoS type and all traffic is treated in the same way, without any guarantee of QoS parameters.
- The IEEE 802.1p based priority scheme, which is optional and separates different types of traffic in different priority queues. There are eight different priority levels, mapped to eight (or less, dependant on the system) different system queues. Each queue is then mapped to a DLC user connection (DUC), according to its priority, and, naturally, to its destination MAC addresses. In the Ethernet frame, the priority is indicated by a tag placed after the source and the destination address. In HIPERLAN/2 the Quality of Service parameters are negotiated at association time.

As hinted in the previous paragraph, it is up to the SSCS (control plane) to map the different addresses of the higher level to DUCs of the DLC level, since it is able to identify destination MTs only in this way. The SSCS of the AP is actually different form the MT’s SSCS: the latter will send all data to the AP, while the former has to decide whether send data back to the HIPERLAN 2 network or forward it to the fixed Ethernet network.

2.3 HIPERLAN 2 security features

The HIPERLAN 2 standard provides for its own security features, in order to guarantee authentication and confidentiality of the data being exchanged on the air interface. The following Subsections give an overview of how the standard confronts with the security problem.

2.3.1 Key exchange

The key exchange procedure will occur during the association time. It will also happen before authentication, in order to have the identities exchanged during the association procedure. The exchange of the keys is based on a Diffie-Hellman procedure. The two entities being involved in the protocol, i.e. the AP and the MT, exchange their public DH values and, starting from them, they will work out the keys used for encryption.

The encryption keys, also denoted as Session Secret Keys (SSKs), are valid only for one session, and may be refreshed during one session. They are known only to the AP and the specific MT. In order to exchange encrypted multicast and broadcast data, AP and MTs of the same cell share common keys, univocally identified by an ID. These keys are exchanged first at association time (distributed by the AP) and even during the session in order to refresh them.

2.3.2 Encryption

The HIPERLAN 2 standard considers two different encryption algorithms, which is possible to choose between the DES algorithm and the triple DES algorithm. The encryption keys are derived from operations made on the DH keys exchanged before; the actual encryption operations start as soon as the AP and MT have exchanged and calculated their keys.

In order to increase the effectiveness of the algorithm, HIPERLAN 2 makes use of the Output FeedBack (OFB) operation mode (Figure 10), and for this reason an Initialization Vector (IV) is needed. The seed for the IVs, i.e. the value starting from which the IVs are generated, are periodically sent to the MTs in the RBCH logical channel, starting from association time as soon as the DH values have been exchanged and before encryption actually starts. To obtain the IVs, a function cycles stepwise in order to produce a set of non-repeating values; every LCH is encrypted with a different IV.

illustration not visible in this excerpt

Figure 10: DES OFB mode.

2.3.3 Authentication

The HIPERLAN 2 standard allows two different authentication mechanisms, which are negotiated at association time:

- Pre-shared key based.
- RSA signature based.

Regardless of the authentication mechanism being used, the scheme is always based on challenge and response. After having decided which mechanism to use at the beginning of the association phase, the MT receives a challenge from the AP, and sends back a response, together with a new challenge, in order to perform mutual authentication. The AP decides about the correctness of the response sent by the MT and works out its response to the received challenge. Then it is the MT’s turn to decide whether the AP has successfully authenticated.

In the pre-shared key mechanism, the response is calculated by applying the MD5 algorithm [MD5] and the HMAC [HMAC] algorithm to the authentication string given by the concatenation of the challenge, the DH public values, the list of the proposed authentication/encryption mechanisms and the selected mechanism. The keys being used are pre-shared, long term, authentication key, known both to the AP and to the MT. HIPERLAN 2 does not specify how such keys are distributed between the entities being involved in the authentication procedure. Such keys are not supposed to be transferred on the HIPERLAN 2 network and are not the keys exchanged with the DH procedure, which are used only for encryption. This kind of mechanism suits to environments with a limited number of MTs, without key distribution problems.

The RSA signature based mechanism calculates the challenge as a signature of the authentication string as described in the previous paragraph, using the private key of the entity working out the response. The HIPERLAN 2 standard does not specify which binding should exist between a public key, necessary to decide about the correctness of the signature, and the entity being authenticated. A digital certificate seems to be the best solution, but this will be implementation dependent, since it is not specified how this should happen. There are three different key lengths that are allowed in this mechanism: 512, 768 or 1024 bits.

3. IEEE 802.1X

This chapter gives a detailed description of the IEEE 802.1X Port Based Network Access Control standard, in which the draft in use is the version 11, released on March 27th, 2001.

3.1 General concepts and Architectural framework

The aim of IEEE 802.1X [8021X9], known as Port based Network Access Control, is to provide a means of authenticating devices attached to a LAN port, that has point-to-point characteristics, and preventing unauthorized devices to have access to the services available on that network, by making use of the physical access characteristics of IEEE 802 LAN infrastructures. A port is a single point of attachment to the LAN infrastructure.

The typical environment of such a protocol is a public LAN infrastructure or a corporation LAN, where users can be physically connected or create associations (in case of wireless LANs) thus obtaining access to resources and services, which might be available. Ad-hoc networks may also need to perform authentication, in order to determine a trusted network; all entities, in this case, should be able to ask for and perform the authentication function and to be authenticated as well.

The access point to the network, called Authenticator, asks the device that is willing to have access to the network services, called the Supplicant, to authenticate itself. The authentication function occurs usually in another system, called the Authentication Server, likely to be a RADIUS server. The authenticator, i.e. the access point, is not requested to understand the nature of the authentication information exchanged between supplicant and authentication server; it simply controls the state of its port. For additional features like encryption features negotiation and key-exchange, this might be a problem. In certain circumstances, the authenticator must understand the information, which it actually simply forwards to the authentication server during the protocol exchange.

The typical architecture framework of an environment based on IEEE 802.1X may be depicted as in Figure 11.

illustration not visible in this excerpt

Figure 11: General architecture of an IEEE 802.1X system.

A wireless station, i.e. the supplicant, wishes to use the services offered by a wireless LAN infrastructure through an Access Point (AP), which gives access to the LAN. To achieve this, it creates an association with the AP and asks, or typically will be asked, to perform authentication. The AP will act as an authenticator; i.e. it will be the point where authentication is requested. The authentication function, as previously hinted at, will be performed by an authentication server , which will usually be located on another machine. A typical situation is to have a RADIUS server acting as an authentication server, and the RADIUS server accessing an Active Directory, using the Lightweight Directory Access Protocol (LDAP) to retrieve information in order to perform the authentication function (using LDAP to access Active Directory for information is a solution for Windows 2000 environments, it cannot be called a typical situation). The authenticator will control the access status of its port basing on the outcome of the authentication process.

The effect of the IEEE 802.1X is to create two distinct points of access to the point of attachment of the authenticator’s system, as illustrated in Figure 12 and Figure 13.

- The uncontrolled port : Is the point of access, through which PDUs can pass without being blocked; this access point is usually used to transmit authentication information. This is needed since the mobile terminal has not access to the network and it would otherwise be impossible for it to exchange authentication information with the authentication server.
- The controlled port: is the second point of access, which allows information to flow through it only when its status is authorized.

Both ports are to be considered as part of the same point of attachment; furthermore, any frame received on the physical port will be available on both the controlled and the uncontrolled port.

illustration not visible in this excerpt

Figure 12: Authorized state (Source: [8021X11]).

illustration not visible in this excerpt

Figure 13: Unauthorized state (Source: [8021X11]).

The controlled port is set to an unauthorized state before starting operation, and as soon as a device is attached to the port, the AP asks for authentication. With a successful process, the state of the port will be set to authorized. The state of the controlled port can be controlled externally by management operations and can be forced to be unconditionally authorized or unauthorized (that is without considering the result of the authentication function), or can be set according of the outcome of the authentication operations.

The control performed over the frames passing through the port may be executed only for frames flowing in one direction, i.e. incoming frames, or flowing in both directions. This allows relaxing the access control in order to send out diagnostic or management packets. There are different scenarios in which this feature can be quite useful and prevent different facilities to be completely disabled.

3.2 Packet format and Protocol exchange

IEEE 802.1X defines the encapsulation technique that allows to transport Extensible Authentication Protocol (EAP) [EAP] packets between a supplicant and an authenticator through LAN environment. This technique is known as EAP over LAN (EAPOL). In the following description, the encapsulation technique into IEEE 802.3 frames will be described as an example, but other kinds of encapsulation will be quite similar. A typical format of the packet will be like in Figure 14.

There are currently five different types of packets:

- EAP packet. This packet encapsulates an EAP packet used to perform authentication.
- EAPOL-Start packet. It is sent by the supplicant to indicate that it wishes to be authenticated.
- EAPOL-Logoff packet. Sent by supplicant to indicate that it is willing to terminate the current session.
- EAPOL-Encapsulated-AFS-Alert packet. Used for traffic like SNMP traps. The format is not defined.
- EAPOL-Key packet. Sent by the authenticator to the supplicant in order to send an encryption key.

illustration not visible in this excerpt

Figure 14: EAPOL packet format.

The EAPOL-Key packet contains a descriptor of a key to be used for encryption, authentication or signature. It is used by the authenticator to send information about a key to the supplicant or by the supplicant to send a key to the authenticator.

The format of the EAP packet is depicted in Figure 17.

To start the protocol exchange the authenticator will send an EAP-Request/Identity packet, and an association is established between a wireless station and an access point. Then the supplicant replies by sending an EAP-Response/Identity packet, by which it communicates its credentials to the authenticator. There may be times that the supplicant starts the protocol by sending an EAPOL-Start to the authenticator, who then replies with an EAP-Request/Identity packet..

The authenticator forwards this packet to the authentication server, usually a RADIUS server, who replies by sending a challenge or by asking the supplicant to provide a password or something else to confirm its identity. This phase is strictly dependent on what authentication mechanism will be used by the entities being involved in the process. The current version of EAP defines three different authentication schemes, MD5 [MD5] challenge, One Time Password [OTP] and Generic Token Card, but it will probably be enhanced with different and stronger mechanism. A typical protocol exchange by using One Time Password is illustrated in Figure 15.

The forwarding task performed by the authenticator, may be either achieved by encapsulating EAP packets into RADIUS packets exploiting the EAP RADIUS extensions (see Chapter 5), or by extracting the information out of the packet and putting them into normal RADIUS attributes. The first solution allows a simplification of the authenticator (or better of the Backend authentication state machine, as depicted in Section 3.5) but needs the RADIUS server to support the EAP-extensions. The second solution needs the authenticator (backend authentication) to extract the information from an EAP-Response packet and to prepare a RADIUS packet, but allows dealing with a normal RADIUS server.

When the supplicant wishes to end the session and close the connection, it sends an EAPOL-Logoff packet to signal the authenticator and in this case the port should be set to unauthorized, in order to avoid attacks that might be exploit to an open authenticated session.

If the authentication process fails, the authentication server sends an EAP-Failure packet to the authenticator, who forwards it to the supplicant and keeps the controlled port in the unauthorized state. All the decisions made by the authenticator are based on the outcome of the authenticator server. If the it is the RADIUS server, as it likely to be, the authenticator will look only the RADIUS return code, neglecting the EAP packet that might be included in the response.

Since IEEE 802.1X is to be considered a link-level security protocol, it has to deal with retransmission, as the underlying protocol may not reliably guarantee the deliverance of the frames. IEEE 802.1X states that the authenticator is in charge of the retransmission of frames. If the authenticator does not receive the response to a request it has sent, it must retransmit the request. A supplicant, on the other hand, has to send a response every time it receives a request, even if a response has already been sent. The supplicant retransmits only EAPOL-Start packets. EAPOL-Logoff Packet is never retransmitted. It has to be pointed out that a typical LAN environment has an error-rate that is usually quite low; wireless LAN might indeed have a lower reliability.

It may happen that either the authenticator or the supplicant is not capable of authentication. The protocol has been designed in a way to deal with such situations. If the supplicant does not support authentication it will not respond to the authenticator’s EAP-Request/Identity packet; the authenticator will retransmit but the port will never be released. If the authenticator does not support authentication, the supplicant will send EAPOL-Start packets and never receive an answer. After a certain amount of times it has retransmitted its packet, it will assume that the authenticator does not support authentication and starts to send higher level traffic, considering the port set to the authorized state.

illustration not visible in this excerpt

Figure 15: IEEE 802.1X basic protocol exchange.

3.3 Implementation issues

In order to have a clear idea about how the different parts of a security system based on IEEE 802.1X should fit each other, it is worth to define roughly which modules should be present and how they should communicate. Figure 16 depicts this architecture.

illustration not visible in this excerpt

Figure 16: Software architecture.

The IEEE 802.1X module sends messages over the network through the user access point of the network interface and may set administrative variables through the control access point. This is very important in the case of the authenticator, because it needs to have control over the network interface in order to deny access to the supplicant, if authentication fails. It communicates also with the EAP module and, indirectly, with the EAP extensions module: they will be responsible for the EAP conversation.

The DHCP module has access to the network interface and may even be triggered by the IEEE 802.1X module: this is the case that the DHCP module should receive a timeout error message, because authentication took too long and DHCP packets couldn’t flow through the network. This architecture is quite general and can be applied to both the supplicant and the authenticator. The DHCP module needs to be triggered in the supplicant to send a request again, if it has failed because authentication has not yet completed. Furthermore, the IEEE 802.1X needs to have a strong control over the network interface in the case of the authenticator.

The standard specifies nine different state machines that model the behavior of the IEEE 802.1X protocol. Not all of them should be present in a system: it depends on what functionality that system wishes to implement. The state machines are:

- The Port Timers state machine.
- The Authenticator PAE state machine
- The Authenticator Key Transmit state machine
- The Supplicant Key Transmit state machine
- The Reauthentication Timer state machine
- The Backend authentication state machine
- The Controlled Directions state machine
- The Supplicant PAE state machine
- The Key Receive state machine

The Port Timers state machine is in charge of decrementing every second their value until they arrive zero. They are set, read, and initialized by the different state machines.

The Authenticator state machine’s role is to enforce authentication by sending EAP-Request/Identity to the supplicant and to realise the function to set the status of the controlled port according to the outcome of the authentication exchange. It has to perform the access control function.

The Authenticator Key Transmit and the Supplicant Key Transmit state machines are in charge to send a key to the supplicant or to the authenticator if such a key is available.

The Reauthentication Timer state machines is in charge to check if the reauthentication timer expired, which means that the supplicant needs to reauthenticate. This timer is usually set to an initial value of 3600 seconds, but can be set to other values according to local policies.

The Backend Authentication state machine is responsible with communicating with the authentication server and is located on the same system as the authenticator state machine. It forwards responses to the authentication server and receives requests from it. Its presence allows the separation of the authentication function from the authenticator.

The Controlled Directions state machine is responsible to ensure the correct values of the parameters that regulate if control should be performed only on incoming packets or on packets flowing in both directions. It actually does not make sense to control only outgoing traffic.

The Supplicant state machine communicates with the authenticator state machine and waits for a response. It may happen that a supplicant starts to send packets before having received the response of the authentication process. If the access point does not support authentication, this turns out to be a gain of time.

The Key Receive state machine is in charge of receiving a key and processing it. The standard does not specify how to process a key. It is system and implementation dependent.

The standard defines a set of managed objects and management functions on such objects. The aim is to provide for facilities that support the planning, organization, supervision, control, protection, and security of communication resources, and account for their use. It also defines a single Management Information Base (MIB) module, containing the managed objects, divided into groups, and their relationships with variables, parameters and counters defined together with the state machines.

[...]