Framework for the Support of IPv6 Wireless LANs v2 · and would serve as an IPv6 WLAN design and...

32603 Deliverable D4.2.2 v2 Framework for the Support of IPv6 Wireless LANs

Project Number: IST-2001-32603

Project Title: 6NET

CEC Deliverable Number: 32603/ULANC/DS/4.2.2/A2

Contractual Date of Delivery to the CEC: June 30th 2004

Actual Date of Delivery to the CEC: October 8th 2004

Title of Deliverable: Framework for the Support of IPv6 Wireless LANs, Version 2

Work package contributing to Deliverable: WP4

Type of Deliverable*: R

Deliverable Security Class**: PU

Editors: Martin Dunmore

Contributors: Martin Dunmore, John Floroiu, Reinhard Ruppelt, Klaas Wierenga, Renzo Davoli

Reviewers:

* Type: P - Prototype, R - Report, D - Demonstrator, O - Other

** Security Class: PU- Public, PP – Restricted to other programme participants (including the Commission), RE – Restricted to a group defined by the consortium (including the Commission), CO – Confidential, only for members of the consortium (including the Commission)

Abstract:

This document aims to provide a framework for the support of wireless LANs (WLANs) in an IPv6-only environment. It is hoped that it will serve as an IPv6 WLAN design and implementation guide for readers that are unfamiliar with IPv6 and/or WLANs.

The original focus for this document was to be on access control solutions but we have now expanded the scope to include all aspects of deploying IPv6 WLANs. While authentication and access control still remain a significant part of this deliverable, we also look at the issues in designing and implementing the WLAN together with IPv6 or MIPv6 specific issues that should be taken into consideration. We have also added a section on hardware and software availability.

We also focus on IEEE 802.11 based WLANs since these are by far the most widely deployed and are certainly beginning to live up to the ‘wireless Ethernet’ tag.

This is the second version of the deliverable

Keywords: IPv6, Wireless LAN, WLAN, Wifi, 802.11, 802.1X, Access, Mobile IPv6.

32603 Deliverable D4.2.2v2 Framework for the Support of IPv6 Wireless LANs

Executive Summary

Within activity A4.2, the first deliverable D4.2.1 identified and discussed the important issues pertaining to IPv6 Wireless LAN access. This deliverable expands on these issues and provides a framework document for organisations wishing to deploy and operate Wireless LANs in an IPv6 environment.

In recent years there has been a rather dramatic growth in the WLAN market with 802.11 WLANs now beginning to appear in enterprise networks, public ‘hotspots’, campuses and small office and home (SOHO) networks. It is now becoming extremely common for business meetings, conferences, trade fairs and exhibitions to provide WLAN access to people attending those events. In the context of IPv6 this growth is somewhat important. Most WLANs are new network deployments, rather than to replace existing wired networks. Therefore, these new WLANs are beginning to eat into the dwindling IPv4 address space. Whilst solutions such as NAT can hide the address shortage, they are arguably only temporary solutions until the next generation IP, IPv6, becomes widely deployed. It is therefore important to arrive at a framework for the support of WLANs in IPv6-only environments to accommodate future growth in WLAN deployment.

The scope of this deliverable has been expanded to include all aspects of supporting IPv6-only WLANs rather than just access control solutions as was originally intended. We now also look at the issues in designing and implementing the WLAN together with IPv6 or MIPv6 specific issues that should be taken into consideration.

This is the second version of this deliverable. Originally this was intended to be the final version. However, there is still much work in progress on IPv6-only WLAN deployment, such as that occurring in the UK LIN trials and TF-Mobility effort. As such, this deliverable will be further updated with material from these and other efforts for the duration of the project lifetime.

2


Changes from 1st Version

Updated Sections:

• Introduction

• IEEE 802.11 Wireless LAN Technologies

• 802.11i

• Web based Authentication and Access Control

• Simple VPN Access Control Procedure

• Management of Access Points

New Sections:

• UK Location Independent Networking (LIN) Trials

• IPv6 Support in RADIUS Implementations

• IPv6 Capable Access Points

3


Table of Contents

1 Introduction................................................................................................................................7

2 IEEE 802.11 Wireless LAN Technologies................................................................................9 2.1 802.11b.................................................................................................................................9

2.2 802.11a.................................................................................................................................9

2.3 802.11g...............................................................................................................................10

3 Authentication, Security and Privacy ....................................................................................11 3.1 Wired Equivalent Privacy (WEP) ......................................................................................12

3.2 802.1x and EAP .................................................................................................................13

3.3 WPA (Wi-Fi Protected Access) .........................................................................................15

3.4 802.11i / WPA version 2....................................................................................................18

3.5 VPNs ..................................................................................................................................18

3.5.1 Advantages of VPN-based Solutions.....................................................................19

3.5.2 Shortcomings of existing Access Control Mechanisms (EAP-based) ...................20

3.5.3 EAP Integration with VPN-based Solutions..........................................................20

3.5.4 WAVEsec – A Linux VPN ....................................................................................20

3.6 Web-based Authentication and Access Control.................................................................21

3.7 Vite and dbind....................................................................................................................23

4 Lancaster University Access Control Architecture ..............................................................25

4.1.1 Requirements .........................................................................................................25

4.1.2 Network Infrastructure...........................................................................................25

4.1.3 Access Control Mechanism ...................................................................................27

4.1.4 Implementation ......................................................................................................32

5 Simple VPN-based Access Control Procedure ......................................................................36

5.1 Technologies Involved.......................................................................................................36

5.1.1 IPsec .......................................................................................................................36

5.1.2 IKE - Internet Key Exchange.................................................................................36

5.1.3 AAA Infrastructure ................................................................................................37

5.2 Proposed Protocol ..............................................................................................................43

5.2.1 General Description ...............................................................................................43

5.2.2 Data Exchange .......................................................................................................44

5.3 Implementation ..................................................................................................................48

5.3.1 DISC – Diameter Server/Client .............................................................................48

4


5.3.2 FreeS/WAN............................................................................................................50

5.3.3 OpenSSL ................................................................................................................51

5.3.4 AACP – Authenticated Access Control Protocol ..................................................51

5.4 Extensions ..........................................................................................................................61

5.4.1 Automatic Connection Re-establishment...............................................................61

5.4.2 Fast Hand-over.......................................................................................................61

5.4.3 Implementation Improvements ..............................................................................62

5.5 Conclusions........................................................................................................................62

6 WLAN Network Design and Deployment..............................................................................63 6.1 Conducting a site survey ....................................................................................................63

6.2 Choosing the 802.11 Network Type ..................................................................................63

6.3 Calculating the Number of Access Points..........................................................................64

6.4 Management of Access Points ...........................................................................................64

6.4.1 802.11f / IAPP........................................................................................................65

6.4.2 LWAPP and CAPWAP..........................................................................................65

7 Working with IPv6 / Mobile IPv6...........................................................................................67 7.1 Host Configuration.............................................................................................................67

7.2 Subnetting and Addressing ................................................................................................67

7.3 DAD considerations...........................................................................................................68

8 Available Hardware and Software .........................................................................................70 8.1 IPv6 capable Access Points................................................................................................73

8.1.1 Linksys Access Points............................................................................................73

8.1.2 OpenAP..................................................................................................................73

8.1.3 HostAP...................................................................................................................74

8.2 IPv6 Support in RADIUS Implementations.......................................................................74

9 UK Location Independent Networking Trials ......................................................................75

10 Conclusions ...........................................................................................................................78

References .........................................................................................................................................80

Abbreviations ...................................................................................................................................84

Glossary ............................................................................................................................................87

5


List of Figures

Figure 1 802.1x and EAP 13

Figure 2 VPN for Secure WLAN Access ..........................................................................................19

Figure 3 Web-based Redirection........................................................................................................22

Figure 4 Network Infrastructure (simplified).....................................................................................26

Figure 5 Access Control Protocol ......................................................................................................29

Figure 6 Access Control Extension Header .......................................................................................30

Figure 7: The message exchange .......................................................................................................44

Figure 8: Node- and Attendant components in an AACP context .....................................................52

Figure 9: Attendant- and Server components in an AACP context ...................................................52

Figure 10 LIN Participants and Connection to ERPS........................................................................76

Figure 11 RADIUS Proxy Hierarchy.................................................................................................77

6


1 Introduction This document aims to provide a framework for the support of wireless LANs (WLANs) in an IPv6-only environment. Since 6NET is an IPv6 project, the focus of the material in this document concerns IPv6. However, much of the material is also applicable to IPv4. This is not surprising considering that the wireless LAN (WLAN) is a layer 2 technology and is, in theory, independent of the network layer.

This is the second version of this deliverable. It was originally envisaged that this would be the final version and would serve as an IPv6 WLAN design and implementation guide for readers that are unfamiliar with IPv6 and/or WLANs. However, the current status is that there are many issues that are still ‘work in progress’, ranging from basic IPv6 support in commercial Access Points to issues with inter-organisational roaming. Moreover, research efforts such as TF-Mobility and the UK Wireless Advisory Group, which WP4 members are participating in, are still at preliminary stages with regards to investigating IPv6 WLAN access. Therefore, there will most likely be further updates to this deliverable for as long as the 6NET project continues.

The original focus for this document was to be on access control solutions but we have now expanded the scope to include all aspects of deploying IPv6 WLANs. While authentication and access control still remain a significant part of this deliverable, we also look at the issues in designing and implementing the WLAN together with IPv6 or MIPv6 specific issues that should be taken into consideration. We also focus on IEEE 802.11 based WLANs since these are by far the most widely deployed and are certainly beginning to live up to the ‘wireless Ethernet’ tag.

Since the original IEEE 802.11 WLAN specification, there are now a further three flavours of 802.11 WLAN types (named ‘b’, ‘a’ and ‘g’) available to deploy. In recent years there has been a rather dramatic growth in the WLAN market with 802.11 WLANs now beginning to appear in enterprise networks, public ‘hotspots’, campuses and small office and home (SOHO) networks. It is now becoming extremely common for business meetings, conferences, trade fairs and exhibitions to provide WLAN access to people attending those events. In the context of IPv6 this growth is somewhat important. Most WLANs are new network deployments, rather than to replace existing wired networks. Therefore, these new WLANs are beginning to eat into the dwindling IPv4 address space. Whilst solutions such as NAT can hide the address shortage, they are really only temporary solutions until the next generation IP, IPv6, becomes widely deployed. It is therefore important to arrive at a framework for the support of WLANs in IPv6-only environments to accommodate future growth in WLAN deployment.

The following chapter gives an overview of the different IEEE 802.11 WLAN types available; their characteristics, typical data rates and their expected coverage range. Chapter three investigates a number of solutions to authentication, access control and data privacy in a WLAN environment. This chapter looks at WEP, Wi-Fi Protected Access (WPA), 802.1x, 802.11i, VPNs and web-based authentication.

Chapter four and five describe novel approaches to deploying IPv6-only WLANs with access control from ULANC and FhG respectively. The ULANC approach for access control relies on packet marking and filtering while the FhG solution is a simple VPN-based access control protocol.

Chapter six looks at the design and deployment of WLANs and discusses the site survey, how to choose the 802.11 WLAN, type, how many Access Points will be required and the problems of configuring and managing a large number of APs.

Chapter seven explores some IPv6/MIPv6 specific issues when deploying a WLAN. These issues include how to configure hosts, how to subnet and address the wireless network and inconsistencies with IPv6 duplicate address detection (DAD). The sixth chapter gives some insight into available hardware and software for deploying WLANs and the final chapter draws some conclusions.

Chapter eight provides a list of available hardware and software for deploying IPv6 WLAN before conclusions are drawn and discussed in chapter ten.

7


Chapter nine describes some of the work being carried out in the UK Wireless Advisory Group (WAG), in particular the Location Independent Networking (LIN) trials and also the TF-Mobility working group in TERENA.

8


2 IEEE 802.11 Wireless LAN Technologies The base 802.11 specification consists of the 802.11 MAC (Medium Access Control) and two1 different PHY (physical) layers: frequency hopping spread spectrum (FHSS) and direct-sequence spread spectrum (DSSS), both of which operate at the 2.4GHz frequency band with a maximum data rate of 1 and 2Mbps respectively. This original standard ensured interoperability of communications equipment using the same PHY layer types but not between different PHY types. Since then, several standards have been developed under the 802.11 umbrella that allow much higher data rates.

2.1 802.11b

The 802.11b specification (aka Wi-Fi) is a revision to the 802.11 PHY that specifies a high-rate direct-sequence spread spectrum (HR/DSSS) with a maximum data rate of 11Mbps. Like the original specification, 802.11b operates in the 2.4 GHz band and has 13 operating channels in Europe, all 5 MHz wide from 2.412 – 2.472 GHz. Since these channels overlap with each other, it is only possible to choose a maximum of three separate channels within the same coverage area that do not overlap. This has a direct effect on AP (Access Point) density in a coverage area and thus maximum throughput. In other words, a maximum of three APs can be located in the same RF coverage area without causing interference with each other. Although the theoretical maximum data rate for 802.11b is 11Mbps, actual data rates are more likely to be in the range of 4 to 6Mbps depending on the physical environment. In typical office environments, an 802.11b AP has a maximum range2 of about 75 metres, but at the highest operating speed this range can be as low as 30 metres.

2.2 802.11a

The 802.11a specification (aka Wi-Fi5) is a revision to the 802.11 PHY that is based on orthogonal frequency division multiplexing (OFDM) operating at the 5GHz frequency band with a maximum data rate of 54Mbps. Actual data rates are likely to be in the range of 25 to 30 Mbps depending on the physical environment. In typical office environments, 802.11a has a maximum range of about 50 metres, but at the highest operating speed this can be as low as 23 metres. 802.11a therefore has less signal range than 802.11b and so will require more APs for the same RF coverage area. However, 802.11a can have more non-overlapping channels than 802.11b, with four, eight or more channels available depending on the country. Since it uses a different frequency band, the 802.11a standard is incompatible with both 802.11b and 802.11g. In other words, an 802.11a device is not able to associate with 802.11b or 802.11g APs.

The latest International Telecommunications Union's World Radiocommunication Conference3, held in June/July 2003 in Geneva, made significant progress in coordinating global rules for operating 802.11a wireless LANs in the 5 GHz frequency range. The ITU’s decisions increase the number of non-overlapping channels available for WLAN use, which will improve potential throughput and boost overall WLAN scalability. The WRC's delegates, who included industry vendors and national government bodies, agreed to allocate 455 MHz of unlicensed spectrum in the 5 GHz band for global WLAN use. Once the agreement achieves final approval, 100 MHz (5.150-5.250 GHz) will be allocated for indoor WLAN use, and an additional 355 MHz (5.250-5.350 GHz and 5.470-5.725 GHz) will be allocated for mixed indoor/outdoor use.

1 There is also a third PHY for infrared (IR) although this is largely irrelevant as infrared ports on laptops etc. are predominantly compliant with Infrared Data Association (IrDA) standards instead. 2 Assuming omnidirectional antennae. Higher ranges can be achieved with high-gain and/or directional antennae. 3 http://www.itu.int/ITU-R/conferences/wrc/wrc-03/index.asp

9

http://www.itu.int/ITU-R/conferences/wrc/wrc-03/index.asp


This will result in 24 non-overlapping 5 GHz channels in the U.S. with most member nations of the European Community reportedly opening 19 non-overlapping 5-GHz channels for 802.11h use (this is 802.11a with some extensions for avoiding military radar).

2.3 802.11g

The 802.11g specification achieved standard status in July 2003. This standard is another revision to the 802.11 PHY and like 802.11a, is also based on OFDM with a maximum data rate of 54 Mbps. However, 802.11g operates in the 2.4GHz waveband and is designed to be backward compatible with 802.11b. Thus, 802.11b devices can associate with 802.11g APs albeit at the lower data rate of 802.11b. As with 802.11b, 802.11g has a maximum of three non-overlapping channels.

10


3 Authentication, Security and Privacy With the advent of the mobile computing devices, the access control and data protection mechanisms have faced new challenges posed by the new nature of the terrestrial wireless communication and ensuing roaming scenarios. In short, by removing the burden of the binding to fixed physical locations, existing threats to the network exploitation and data security have become critical.

A number of elements decisively impact on the scope and shape of the access control and data protection schemes, among them, the ones enumerated below:

1. Physical access of the intruders cannot be limited in any way, which means that eavesdropping becomes trivial, increasing the exposure of the wireless networks to any kind of attacks. Encryption becomes therefore an essential feature wireless access technologies must support;

2. The authentication model must support roaming scenarios, which requires the definition of appropriate trust relationships and authentication schemes between client, access network, visited domain and a third trust party (client’s home entity);

3. It is always possible nodes originating from multiple administrative domains may be simultaneously located on the same link, which means that the security mechanisms must have a per-node rather than per-wireless domain or per-access point granularity.

4. When mobile nodes roam within the same domain, support must be provided to enable contexts associated to mobile nodes (including authentication credentials and data protection primitives) migrate from one access router to another without requiring low latency operations;

Wireless LAN technology on the basis of the IEEE 802.11 WLAN standard has become a key aspect of internetworking. The tremendous speed wireless LANs have spread across (still accelerating) at the same time has attracted the focus on the security potentialities of WLANs.

Already in the early stages IEEE’s WEP (Wired Equivalent Privacy) security standard which was designed to provide confidentiality for network traffic using the wireless protocol. turned out to be absolutely ineffective. Already in October 2000 Walker was one of the first people to identify several of the problems in WEP [10].

In January 2001 researchers1 at the University of California at Berkely independently released a paper describing the problems with WEP. Finally, in August 2001, Fluhrer, Mantin, and Shamir described several weaknesses in the key scheduling algorithm of RC4 and proposed attacks for exploiting those weaknesses [11]. The detection of this flaw in the RC4 key setup algorithm theoretically facilitates the total recovery of the secret key.

Shortly after, on August 21, 2001, Stubblefield, Ioannidis, and Rubin were the first to implement this attack. They published a technical report [12] describing the implementation with which it was possible to recover the 128 bit secret key used in a production network, with a passive attack exploiting a WEP design failure where the WEP standard uses RC4 initialization vectors (IV) improperly. They concluded that 802.11 WEP is totally insecure and provided recommendations.

At the same time open source crack tools AirSnort2,3 and WEPCrack4, were released as the first publicly available implementations of this attack.

1 http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html 2 http://airsnort.shmoo.com/ 3 http://sourceforge.net/projects/airsnort 4 http://sourceforge.net/projects/wepcrack

11

http://sourceforge.net/projects/wepcrack


3.1 Wired Equivalent Privacy (WEP)

The Wireless Equivalent Privacy algorithm (WEP) is IEEE802.11’s optional encryption standard [7]1 implemented in the MAC Layer which most radio network interface card- and access point vendors support. WEP has been part of the 802.11 standard since its initial ratification in September 1999. Originally, WEP was designed to provide eavesdrop-proof comparable to that of wired LANs. For this purpose WEP defines functions, based on the RC4 encryption mechanism, which aimed at supporting both data encryption and authentication / data integrity as well where the second function is not an explicit goal in the 802.11 standard.

The specification is based on the following major safety measures:

1. Data encryption using the stream cipher algorithm RC4,

2. Shared secret key,

3. CRC-32 Integrity Check (IC), and a

4. 24 Bit Initialization Vector (IV)

This security framework involves the following problems:

For every stream cipher algorithm it is essential to use a new key for each new data packet to be encrypted2. Otherwise an identical data stream would be coded into identical cipher data. In order to achieve this WEP defines variable initialization vectors (IV) which are used to modify the constant WEP key. These IVs are transmitted in the clear text part of the radio message. The problem with the IVs however is that the standard IV length is only 24 bit – too little for efficient data protection: For an access point which is continuously sending data frames at the latest after 5 hours the set of available IVs is exhausted. Worse still, in reality the use of the same effective key for different data frames happens more often3 considerably facilitating the detection of the constant WEP key by passive monitoring of the radio traffic.

Another approach (Known-Plaintext attack) uses pairs of encrypted data and the corresponding original data to record key streams which belong to different IVs. With the knowledge of IVs and the associated key streams it is possible, when later an already known IV is detected, to decrypt the respective stream cipher by simply XOR-ing the data with the key stream formerly registered for this IV.

The use of a CRC-32 integrity check presents another weakness of WEP as it is part of the encrypted payload of the packet, and it is linear, which means that it is possible to compute the bit difference of two CRCs based on the bit difference of the messages over which they are taken. This property can be used to by an skilful attacker to hide modifications made on the encrypted data by adjusting the checksum so that the resulting message appears valid.

Besides the WEP encryption part its authentication procedure is vulnerable as well. The Shared-Key-Authentication provides a known-plaintext to a potential attacker since the original and the encrypted data as well can be read from the authentication sequence.4

1 http://grouper.ieee.org/groups/802/11/is the official 802.11 site from the IEEE. Download of specs is now for free. 2 Note: The IEEE802.11 standard specifies that changing the IV with each packet is optional! 3 E. g. in case the same key is used by all mobile stations which is widely-used habit. 4 For further information see also the FAQ concerning the security of the WEP algorithm at http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

12


3.2 802.1x and EAP

As described above WEP was intended to provide security between communicating wireless peers by employing symmetric encryption keys. One limitation of WEP as we have seen has been the task of distributing and managing the encryption keys.

The IEEE has proposed the Robust Security Network (RSN) as a long term security architecture for the 802.11 standard.

In order to ease the control of such security scenarios IEEE developed the 802.1x standard (based on developments by Cisco, 3Com, Agere, Compaq und Dell and others), which is used in RSN to provide a means of effectively authenticating and authorizing devices attached to a LAN port. Specifically the 802.1x supplement1 defines a mechanism for port-based network access control that makes use of the physical access characteristics of an IEEE 802 LAN infrastructure. It also prevents access to that port in cases in which the authentication and authorization fails.

Employing these features the standard pledges to provide a central, scalable and easy to manage solution for the required authentication and access control purposes of WLAN clients attaching to wireless access points. For these purposes 802.1x implements the Extensible Authentication Protocol (EAP) [13] and adopts a central RADIUS server [14] for authentication.

The picture below illustrates the flow in an 802.1x authentication

Figure 1 802.1x and EAP

In this flow, the client submits credentials within an EAP on LAN (EAPOL) message; the AP transforms this into EAP over RADIUS and sends it to the Authentication Server that validates the credentials. Note that the AP in this scenario is almost transparent; its only task is to transform EAPOL messages into EAP over RADIUS messages. In 802.1x terminology the AP here is performing the role of the Authenticator sometimes referred to as the Network Access Server (NAS).

There are several 802.1x based security solutions on the market today, like:

1 ISO/IEC 15802-3:1998 (IEEE Std 802.1D-1998)

13


• Lightweight EAP (LEAP) a proprietary solution from Cisco

• Protected EAP (PEAP) [19] from Microsoft, Cisco, and RSA Security

• EAP TLS1 [20]

• EAP SKE2, [21]

• EAP TTLS3 [22]

• EAP MD5 [23]

• EAP SIM [24]

and others, which are to repair the weaknesses of 802.1x when using less secure EAP-types according to their manufacturers.

The main EAP solutions are compared in Table 14.

Topic EAP MD5 LEAP EAP TLS PEAP EAP TTLS Security Solution Standards-

based Proprietary Standards-

based Standards-based

Standards-based

Certificates – Client No n/a Yes No No Certificates – Server No n/a Yes Yes Yes Credential Security None Weak Strong Strong Strong Supported Authentication Databases

Requires clear-text database

Active Directory, NT Domains

Active Directory

Active Directory, NT Domains, Token Systems, SQL, LDAP etc.

Active Directory,NT Domains, Token Systems, SQL, LDAP

Dynamic Key Exchange

No Yes Yes Yes Yes

Mutual Authentication No Yes Yes Yes Yes

Table 1 Security features of different EAP solutions

In February 2002, Arbaugh and Mishra published the results of an investigation describing two scenarios showing how an attacker could misuse a successful authentication to gain unauthorized access [15].

In the first scenario (session hijacking) an attacker uses an already existent client / access point connection (after authentication has taken place) to take over the connection pretending to be a valid access point (AP). Afterwards the AP terminates the connection to the client by means of a 802.11-MAC-Disassociate message. The client now supposes to be disconnected while the attacker plays the role of the former client using its

1 EAP Transport Level Security 2 EAP Shared Key Exchange 3 EAP Tunneled TLS Authentication Protocol 4 based on http://www.funk.com/radius/Solns/EAP_type_chart.gif © Funk Software Inc.

14

http://www.funk.com/radius/Solns/EAP_type_chart.gif


MAC address and in so doing it gains network access. This session hijacking attack is possible because 802.11 doesn’t require authentication and integrity checks in case of management frames.

The second scenario (man-in-the-middle) is facilitated by the circumstance that the AP in fact authenticates the client but not vice versa. This allows an attacker to suitably tamper the message confirming a successful authentication (EAP success) sent by the AP to the WLAN client. From now on an attacker can impersonate himself as client against the AP and as AP against the client allowing him to inspect and consistently modify all passing messages. This manipulation is made possible because the EAP success message does not carry any integrity information.

Arbaugh and Mishra conclude that “the current RSN architecture does not provide strong access control and authentication due to a series of flaws in the composition of protocols that make up RSN.”

These scenarios illustrate the importance of selecting an EAP-type that supports dynamic key exchange and client authentication (EAP-MD5 is therefore not recommended). 802.1x was originally conceived as being an asymmetric solution with only client authentication and not AP authentication. However, all popular EAP methods (TLS, TTLS, PEAP) use mutual authentication of both the client (supplicant) and access point (authenticator) and are therefore not vulnerable to this kind of attacks. TTLS and PEAP build on the notion of first establishing a TLS connection to the Authenticator (the so-called Inner Authentication) followed by the actual authentication (the Inner Authentication) for instance PAP, while EAP-TLS uses a TLS connection with mutual authentication of client and server (thus requiring setting up a PKI for client certificates).

By using EAP the 802.1x architecture is easily extensible and can in fact support multiple authentication mechanisms at the same time. Upcoming standards like WPA and 802.11i build upon this framework.

3.3 WPA (Wi-Fi Protected Access)

Due to the obvious security shortcoming s with the WEP standard, there has been work in the IEEE on a new security standard for the 802.11 MAC in the form of task group 802.11i. The 802.11i standard is intended to solve the security flaws inherent in WEP without impacting too much on previously deployed APs. Most recent AP hardware should only require a firmware upgrade to become 802.11i compliant.

However, since the IEEE802.11 working group has only very recently (June 2004) ratified the 802.11i standard, the Wi-Fi1 Alliance2 announced a new security solution on October 31st, 2002, called Wi-Fi Protected Access (WPA) as a temporary replacement to the existing WEP standard WPA was essentially an interim solution until the 802.11i standard was ratified. Therefore, WPA shares many commonalities with 802.11i. At the time of writing almost all commercially available 802.11 hardware supports WPA.

For enterprise-class products, WPA specifies the following functions and technology components:

- User authentication and dynamic encryption-key distribution, two features missing from the original 802.11 standard. These are delivered through support for 802.1x and a choice of Extensible Authentication Protocol (EAP) algorithms. IEEE 802.1x specifies how EAP should be encapsulated in LAN frames. There are many EAP algorithms to choose from, depending on such factors as whether mutual authentication of both the user and the network is required. Some of the EAP flavours that support mutual authentication, albeit with different methods, are EAP-Transport Level Security (TLS), EAP-Tunnelled TLS (TTLS) and Protected EAP (PEAP).

- Encryption. A Temporal Key Integrity Protocol (TKIP) engine handles dynamic key distribution. In WEP, there was one static encryption key that had to be manually entered. So changing the key across many wireless devices was unwieldy and therefore was often not employed, leaving data

1 i. e. “Wireless Fidelity”, cf. http://www.wi-fi.org/ 2 The Wi-Fi Alliance is a nonprofit organization which promotes the 802.11 wireless LAN standard. Apple and more than 180 other companies are members, and more than 450 products have been certified.

15


vulnerable. TKIP is an interim solution to the major portion of 802.11i that is not required in WPA yet.

- Message Integrity Check (sometimes called ‘Michael’), a cryptographic checksum that is part of TKIP, to make sure packets have not been altered in transit.

Within an enterprise wireless infrastructure, access points run 802.1x and TKIP. The back-end authentication server runs your choice of EAP algorithm. Client devices run 802.1x, TKIP and an EAP supplicant.

For SOHO infrastructures, WPA specifies the same level of encryption as enterprise-class products, but the authentication process is simplified to what has been termed a pre-shared key (PSK), but which is in practice a simple password mechanism.

For the purpose of repairing WEP, WPA uses selected components of 802.11i, mainly based on the Temporal Key Integrity Protocol (TKIP) [16], [17]:

• An extended Initialization Vector, for 802.11, WEP encryption is optional. For WPA, encryption using TKIP is required. The TKIP protocol is part of the IEEE 802.11i encryption standard for wireless LANs. TKIP also provides per-packet key mixing. TKIP replaces WEP with a new encryption algorithm that is stronger than the WEP algorithm. WPA with TKIP, for example, uses 48-bit IVs (instead of the 24-bit WEP initialization vector) that greatly increase the number of possible shared keys and therefore significantly reduce IV reuse.

• Re-keying, In the 802.1x standard re-keying of unicast encryption keys is optional. Additionally, 802.11 and 802.1x provide no mechanism to change the global encryption key that is used for multicast and broadcast traffic. With WPA, re-keying of both unicast and global encryption keys is required. TKIP changes the unicast encryption key for every frame and each change is synchronized between the wireless client and the wireless AP. For the global encryption key, WPA includes a means for the wireless AP to advertise changes to the connected wireless clients.

• Message integrity check (MIC, sometimes referred to as ‘Michael’) Since the data integrity provided by the 32-bit integrity check in WEP can be compromised, WPA specifies a new algorithm that calculates an 8-byte message integrity code (MIC) using the calculation facilities available on existing wireless devices. The MIC is placed between the data portion of the IEEE 802.11 frame and the 4-byte integrity check value (ICV)1. The MIC field is encrypted together with the frame data and the ICV. The MIC also provides replay protection. A new frame counter in the IEEE 802.11 frame is used to prevent replay attacks.

In case of larger networks WPA in addition provides for

• authentication by means of IEEE 802.1x and EAP, which make use of a radius server for user administration.

The main 802.11i elements such as

• secure hand off,

• secure de-authentication and

• improved encryption procedures (AES CCMP) are not supported.

The key distinctions between WPA and WEP are listed in Table 2:

1 A mathematical algorithm which uses the plaintext message as input gives an ICV as output. The 802.11 standard specifies the use of the CRC-32 algorithm. CRCs (Cyclic Redundancy Check) had been primarily designed to detect random errors in transmitted messages. It is not cryptographically secure. Attackers can easily change packets and then change the ICVs appropriately.

16


WPA WEP

Fixes main WEP flaws CrackedRC4 RC4 128-bit encryption / 64-bit authentication 40/104-bit keys 48-bit IV 24-bit IV Dynamic session keys Static WEP keys Automatic EAP key management No key management Michael to check data integrity CRC-32 integrity check Michael to check header integrity No check for header

integrity Replay attack secure by IV sequence No replay attack protection

Encryption

DoS vulnerability Authentication User authentication, utilizing 802.1x authentication with one

oft the EAP implementations available (e.g. EAP-TLS1, EAP-TTLS2, PEAP3), and pre-shared key technology (PSK)

Flawed, WEP key itself was used for authentication

Table 2 WPA vs. WEP

Since WEP does not provide secure authentication or effective integrity checking, WPA was designed to upgrade WEP with respect to these functions by means of the Michael algorithm. Michael’s functionality was implemented in software and intended to be integrated into existing WLAN devices. Michael’s strength however is limited due to the restricted computing power of existing access points. Besides, Michael puts the entire WLAN adapter to sleep for the protection from brute force attacks for one minute, as soon as it discovers more than one potential attacker packets within one minute in order to discourage aggressors to send quickly successive forged packets. According to [17] “This level of protection is much too weak to afford much benefit by itself, so TKIP complements Michael with counter-measures. The design goal of the counter-measures is to throttle the utility of forgery attempts, limiting the knowledge the attacker gains about the MIC key. If a TKIP implementation detects two failed forgeries in a second, the design assumes it is under active attack. In this case, the station deletes its keys, disassociates, waits for a minute, and then re-associates. While this disrupts communications, it is necessary to thwart active attack. The countermeasures algorithm thus limits the expected number of undetected forgeries such an active adversary might generate to about one per year per station.”

On the face of it, this opens the door for malicious parties to initiate serious DoS attacks on any WPA enabled WLAN. However, according to Niels Ferguson, the designer of Michael, the WPA sleep does not open a substantially larger vulnerability than anyway already existed. In words of Ferguson4: “The Michael-countermeasures based DOS attack is not important for the following reason: there are other, more serious, DOS attacks in the basic 802.11 protocol. If we 'fix' the countermeasures to make the DOS attack more difficult the attacker will simply switch to one of the other DOS attack modes. The net gain is zero, so there is no reason not to use the countermeasures as specified.”

1 Transport Layer Security 2 Tunneled Transport Layer Security 3 Protected Extensible Authentication Protocol 4 Re: DOS attack on WPA 802.11?, The Mail Archive, http://www.mail-archive.com/[email protected]/msg03078.html

17


3.4 802.11i / WPA version 2

To address the WLAN security gaps, the IEEE 802.11 Working Group instituted Task Group i to produce a security upgrade for the 802.11 standard now also known as WPA2. 802.11i is building the standard around 802.1x port-based authentication for user and device authentication. It includes two main developments: Wi-Fi Protected Access (WPA), i.e. WPA is a subset of 802.11i, and Robust Security Network (RSN). With these developments 802.11i promises to plug the security holes in WEP and WPA as a self-contained IEEE standard. The 802.11i has only recently be ratified by the IEEE (June 2004) and so availability in commercial products is still somewhat hit and miss.

The key distinctions between WPA and WEP are listed in Table 3:

WPA2 WPA

Enhanced encryption protocol: the Advanced Encryption Standard (AES-CCMP) with variable key sizes of 128-, 192- or 256-bits

RC4

CCM1 integrity check Michael integrity check

Encryption

Hardware change necessary Software upgrade possible Secure de-authentication and disassociation2 Authentication Secure IBSS3 and secure fast handoff

Compatibility WPA2’s mixed mode supports both WPA and WPA2. WPA’s mixed mode supports both WEP and WPA.

Table 3 WPA2 vs WPA

3.5 VPNs

IEEE 802.1x is often regarded as the key technology for the purpose of authenticating distributed WLAN access points. However, a study of the Colorado State University [18] comes to a different conclusion as the authors recognize security lacks which lead to “less than an industrial strength authentication solution”. Thus, it was decided not to incorporate 802.1x into CSU’s wireless network. Currently at Colorado State University, the preferred means of achieving privacy and authentication on wireless LANs is through a virtual private network (VPN).

Especially for sites with the highest level of security concerns it is recommended to use Internet Protocol Security (IPSec4), as available with most VPN solutions.

VPN technology can provide industrial strength authentication and encryption. As 802.1x defines layer 2 authentication, a VPN based on IPsec acts as a layer 3 tunnelling protocol. It should be noted that a layer 2 protocol like 802.1x authenticates the user before he gains network access and therefore prevents attacks against the network infrastructure. IPsec in contrast does not protect the link layer. IPsec was originally

1 Counter with CBC (Cipher Block Chaining) MAC (Message Authentication Code). CCM provides both authentication and encryption in a single key. CCM has been submitted to the National Institute of Standards and Technology (NIST) for consideration as a standard mode for use with the Advanced Encryption Standard (AES). 2 Disassociation is the process of terminating the association of a client with a given access point in the WLAN whereas authentication denotes the process of verifying the credentials of a client desiring to join a WLAN. 3 The Independent Basic Service Set (IBSS) enables security between client workstations operating in ad hoc (peer-to-peer) mode. 4 http://www.ietf.org/html.charters/ipsec-charter.html

18


developed in the framework of IPv6 and now presents the standard for encrypted communication over the Internet. With its high-level security encryption and per-packet authentication IPsec meets the highest security requirements; and it is suitable for the protection of end-to-end communication.

A VPN is a secure virtual network which is built using an unsecured network connection. In order to gain access to the virtual network, authentication is required. Once access has been granted, subsequent data transfer on the virtual network is encrypted. Due to the fact that the communication is based on a secure virtual network a potential attacker with access to the link layer cannot eavesdrop or forge the data unnoticed.

In principle, the VPN consists of a gateway giving way to the local network and the WLAN clients. The AP(s) in this scenario only presents a component of the physical medium and does not make up a constituent part of the VPN itself. Accordingly, APs are not directly connected to the local network but only via the VPN gateway; which acts as a firewall giving access only to VPN secured traffic. Figure 2 depicts how secure communication is provided by VPN tunnels, which connect the WLAN clients with the trusted VPN gateway residing in the LAN.

Figure 2 VPN for Secure WLAN Access

3.5.1 Advantages of VPN-based Solutions VPN solutions typically operate in the ISAKMP/IKE framework and therefore provide the following advantages over other access control schemes:

• Derive strong cryptographic material by:

o Using Diffie-Hellman exchange;

o Providing a master SA (IKE SA) that protects actual SA negotiations (child SAs).

• Access technology independent.

19


3.5.2 Shortcomings of existing Access Control Mechanisms (EAP-based) • Protocols like EAP-TLS and PEAP establish a TLS session that protects the subsequent

authentication exchange between the client and the authentication server. This introduces the overhead of interacting with a PKI infrastructure (and the associated scalability issues, especially in the case of EAP-TLS). Moreover the client is exposed to computational DoS attacks (by malicious nodes posing as authentication servers and providing faked certificates for validation) while the authentication server itself may be victim of connection depletion attacks (by malicious nodes flooding it with fake authentication requests);

• EAP-SKE does not use TLS and therefore eliminates the associated overhead. The message exchange is instead authenticated using a HMAC computed with a symmetric key the supplicant and the access point share. In this case, however, perfect forward secrecy is not supported: once the master key is compromised, all deriving session keys are compromised as well and past traffic may be decrypted.

• The key management schemes supported by the current proposals are rather inflexible: they do not provide support for negotiating a number of parameters such as transforms, key strength and key lifetime between the peers.

• The “unicast WEP key” derived by the client and the authentication server upon successful client authentication is delivered by the authentication server to the access point possibly through a number of intermediate proxies. (The unicast WEP key is further used by the access point to encrypt the “broadcast WEP key” which is the key the traffic will be encrypted with over the wireless link). The transfer of a shared key otherwise than through an end-to-end secure channel is however insecure. On the other hand, the attempt to set up such end-to-end secure channels between access points and authentication servers easily runs into scalability problems, especially in an inter-domain scenario.

• Finally, a fast handover mechanism is missing and consequently the authentication process must be repeated each time the supplicant attaches to another access point. This is of course not the case when the link layer encryption key is the same throughout the entire wireless domain. Such a scenario however is not taken into consideration as it contradicts the high level requirement mentioned under point 3.

3.5.3 EAP Integration with VPN-based Solutions EAP seems to receive wider and wider acceptance as a generic link access protocol. IKEv2 has also introduced EAP as an alternative authentication mechanism to the already existent certificate- and shared secret-based solutions. Similar to the TLS based versions of EAP, the IKEv2’s IKE SA protects the actual EAP exchange.

3.5.4 WAVEsec – A Linux VPN WAVEsec1 is a way to authenticate and encrypt 802.11 traffic on its vulnerable hop between a WLAN client and a wired gateway using either KAME or Linux FreeS/WAN2 IPSec implementations. The novel thing about WAVEsec is how it arranges the trust required between the client notebook and the WAVEsec gateway. WAVEsec does it by exchanging public keys during the DHCP address assignment. The client can therefore be completely configured just by plugging an 802.11 interface in.

The client provides its forward hostname and public key in a DHCP request. The DHCP server then inserts both into the DNS server for the reverse zone (mapping of IP addresses to names) using Dynamic DNS update. The DHCP server responds giving the client needed information via three new DHCP options:

1 http://www.wavesec.org/ 2 FreeS/WAN (http://www.freeswan.org/) is an open source project and software package implementing IPsec / IKE VPNs for Linux machines.

20


• a WAVEsec gateway address

• the gateway’s mode (inline or appendix)

• the gateway’s public key

To support this functionality the DHCP server must be capable of taking a custom DHCP option containing a raw RSA key in DNS format and installing it into a DNS server using dynamic DNS updates. To set up a WAVEsec client, the following is required:

• to run Linux

• to install an extended DHCP client (dhclient), and configure it for WAVEsec

• to install and configure Linux FreeS/WAN

There are 5 logical entities involved in a WAVEsec scenario. They are:

• the WLAN client

• the WAVEsec access point

• the DHCP server

• the DNS server

• the Internet connected router

For SOHO networks and other small networks, all server- and routing functions might be combined into a single machine.

3.6 Web-based Authentication and Access Control

One relatively straightforward way of authenticating WLAN users is via a web-based authentication system. It does not require any special functionality to be present at the APs or client devices. A NAS (generally a router or intelligent switch) is located between the fixed network and the WLAN. This device will deny any traffic from/to unauthorised clients. For a client to be allowed to communicate over the fixed network, the user must be authenticated first. User authentication is achieved through a simple web interface.

When a client device enters the WLAN, it receives an initial IPv6 address via DHCPv6; but this address is blocked by the NAS from sending receiving traffic over the fixed network. The user of the device must launch their web browser and attempt to load an arbitrary webpage (step 1 in Figure 3) before authentication can take place. The NAS device redirects the user’s HTTP request to the authentication web server, which maybe located inside the NAS. In this way, the user does not need to know the web URL for the authentication service. The authentication web server returns a web page to the user (step 2) consisting of a form for the user to enter his or her credentials (e.g. username and password). The credentials returned by the user (step 3) will be sent to the authentication server for verification (step 4). Based on the reply from the authentication server (step 5) the NAS will either grant (by modifying the access control list on the NAS – step 6) or deny access to the IPv6 address assigned to the user’s client device (step 7).

Once the user is authenticated, communication over the fixed network may take place according to the user profile and the organisation’s policies. For example, the network provider may wish to continue to block some protocols (e.g. SMTP, or incoming FTP/HTTP requests) for some or all users.

The de-registration of a user may be performed via a ‘logout’ button on a pop-up window or more suitably (the user may not log-off or have pop-up windows disabled) via the timeout of ICMP echo requests sent by the access control device.

21


The level of security for this authentication mechanism depends on the particular implementation. Ideally, user credentials should never be sent as clear text via HTTP. Instead, HTTPS (secure HTTP) should be used between the web browser and the authentication server. The authentication server could employ the use of RADIUS or LDAP services at the backend.

It is important to note that the web-based redirection technique has a United States patent associated with it [72], which is owned by Acacia Technologies. It is not clear if this patent is valid outside of the US. However, Acacia Technologies have begun to issue requests for licensing payments to hotspot operators within the US that are using web redirection for WLAN access control [73].

The NAS must be enabled with an IPv6 capable WWW server and DHCPv6 server or be able to serve as a proxy for both these services.

Figure 3 Web-based Redirection

User authentication by web redirection is now a popular method of controlling access to a WLAN. It is especially convenient for short-lived network deployments such as those for conferences, meetings and trade fairs. Since

One recent deployment example of web-based access control is that of the 2003 IST Mobile and Wireless Communications Summit in Aveiro, Portugal. To prevent unauthorised access, each user had to enter login credentials (username and password) to an authentication web page that users were directed to automatically upon starting their web browser. Conference delegates had to obtain ‘access cards’ from the registration desk. Each card contained a username and password that was valid for 5 hours from the time of the first login. In this way, user authentication was achieved visually, by staff at the registration desk who checked that the requesting user was registered for the conference. Once the 5 hour time limit had expired, delegates had to return to the registration desk to obtain a new (with different username and password) access card.

This method worked well up to a point but it was rather inflexible, especially the 5 hour limit. This meant that users had to obtain an access card at least twice for each day of the conference. This was especially

22


irritating when the time limit expired while in the middle user checking email or downloading papers, presentations etc. All application connections were severed when the time limit expired and could not be re-established until the user logged in with a new access card. Thus, it was often many minutes before a user was able obtain a new access card from the registration desk and re-establish his application connections. Soon, many delegates were obtaining access cards in advance of their current one expiring to minimise the nuisance value. However, it was still not possible to move seamlessly from an existing user account to a new one without breaking existing application connections.

In hindsight, the time limit value could have been chosen in a more thoughtful way. For example, a 24-hour limit (so users only had to obtain a card once each morning) or even no limit at all (i.e. the duration of the conference).

3.7 Vite and dbind

Vite (the Italian word for ‘vine’ or ‘grapevine’) is an authorization service IPv4/IPv6 compatible. It has been used for years (IPv4) and at least 8 months (IPv6) at the Department of Computer Science, University of Bologna.

All the students' laptop networks and wireless networks use Vite to authenticate users. Vite in its current implementation uses NIS, ssh and a specific tool (fsh). When a user joins the network, plugs his/her laptop in a public LAN socket or get connected to an access point he/she is on a local LAN with no route to the Internet. The user gets an address through a DHCP service (IPv4) or by auto-reconfiguration (IPv6, router advertisements are sent on the net). If the user wants to be connected to the internet he opens an ssh connection to the vite server.

On vite the NIS service authenticates the user: fsh is started instead the standard user's shell. fsh uses a script to log the MAC address, to open the routing (by updating the iptables) and it waits until the TCP transport connection terminates.

Route path is deleted upon TCP end or abend.

There are several pros of Vite approach:

• It uses only well known standards

• The security of the authentication phase gets inherited from ssh and NIS

• Heartbeat is managed by ssh and TCP keep-alive signals

• It is lighter than VPN

Current implementation:

- Has been interfaced to our DDNS service named dbind

- Provides independent IPv4 and IPv6 authentication and routing (a user can decide weather to have V4only V6only or both routed to the Departmental network and the Internet. This is useful when testing one or the other protocol stack.)

dbind is a DDNS service. It is useful both for permanent workstations and for temporary address assignments.

Dbind has two main goals:

1. create and update DNS tables of permanent machines with no pain (a boot init.d script does all the work). When a workstation changes its address it is sufficient either to run the script (/etc/init.d/dbind restart) or to reboot.

2. manage the database of DHCP and dynamic reconfiguration/vite assigned address. When a new client joins the net and get authenticated its address is automatically updated on the DNS server.

23


The DNS server must be configured to have an account named dbind and an account for each permanent machine (for simplicity we have put the hostname as the username on the DNS server).

Each account has a home directory just for ssh dsa authentication and uses a specific bindsh program as login shell. When a remote machine is authorized to access as dbind it can add and remove entries from several domains, when it is authorized to login as a specific host it can just update the DNS data for that specific host.

The former is used for temporary addresses the latter for permanent machines. ssh is used to secure the remote invocation of the bindsh shell. bindsh invocations are idempotent (several invocations with the same data have the same effect as a single one).

The bindsh shell has very simple commands (add inet, add inet6, rm inet, rm inet6) and the DNS get updated using the callee address. The dbind script at the remote site executes:

ssh $DBIND_SERVER add inet

ssh $DBIND_SERVER add inet6

on start, and ssh $DBIND_SERVER rm inet

ssh $DBIND_SERVER rm inet6

on stop. When a remote machine has access as the user dbind it can specify also the name, the domain and the address of the DNS entry to be added.

Vite uses the dbind service.

24


4 Lancaster University Access Control Architecture The Mobile IPv6 testbed at Lancaster University and the city of Lancaster can employ a novel access control architecture designed specifically for an IPv6-based wireless architecture. Since the deployment of the wireless components of the testbed are in public places, there is a danger of unauthorised users gaining access to the network. Therefore, it is important to restrict access to the network only to authorised systems and users. A secure user authentication and authorisation and a reliable access control mechanism is vital – especially for the wireless LAN segments.

4.1.1 Requirements The requirements for the access control architecture are based primarily on the objectives of the Mobile IPv6 testbed:

Mobility – Without doubt mobility is the focal aspect of the research within the Mobile IPv6 Testbed. It is therefore crucial to design the access control architecture for a highly mobile network environment, where users frequently roam between wireless cells and networks.

Security – As the wireless network infrastructure is publicly available throughout large parts of the city centre, a secure access control mechanism is required to restrict services to authorised users only. In addition, the access control architecture must protect the network against internal and external security threats (for example, denial-of-service attacks).

Flexibility – One of the key requirements is flexibility. As we cannot foresee yet what services will be developed within the course of the Mobile IPv6 Testbed research, we require a maximum flexibility for the access control approach (for example, to support different granularities of control and a broad spectrum of access policies).

Extensibility – The access control architecture must be extensible to enable the integration of additional functionality or interaction with value-added services (such as accounting, QoS, etc.) in the future.

Transparency – The access control approach must be fully transparent to correspondent nodes (i.e., hosts to which a mobile node is conversing) external to our mobile network in order to ensure full interoperability with the standard Internet.

Usability – User access to the public network infrastructure should be as easy as possible (i.e., simple installation of software at the beginning and continued ease of use).

Scalability – The size of a public network spanning the city centre of Lancaster demands a scalable access control architecture in terms of number of users and end-terminals.

Manageability – In order to facilitate the manageability of user accounts and access policies, a comprehensive management system is required. The access control architecture should also be fairly universal (i.e., independent from the underlying technologies) to provide a uniform solution across the whole network (avoiding the need for administration of multiple systems).

4.1.2 Network Infrastructure The Mobile IPv6 Testbed is constructed along the wireless overlay network concept [5], [6] whereby a number of different wireless technologies (such as HSCSD, GPRS and Bluetooth) are used in combination with IEEE 802.11 wireless LANs, in order to provide the coverage and network performance required for future network services. This approach was chosen for two reasons. Firstly, it ensures that mobile users maintain access to network resources wherever and whenever possible, as the most appropriate connection

25


can be chosen at any given time. Secondly, it is likely to more accurately emulate the network topology of future public access wireless networks, thus providing us with a more realistic test environment.

Although many of the wireless technologies that will likely make up future overlay networks already have some form of access control (for example, WEP in 802.11 [7] or RLC/MAC in GPRS [8]), those access control mechanisms are often quite distinct from each other. As the Testbed is formed from a range of such layer 2 network technologies, the access control mechanism must therefore be independent of those underlying network types. The Testbed addresses this problem by adopting a layer 3 approach to access control.

AuthenticationServer

AccessRouter

Gateway

Main CampusRouter

Access Point

AccessRouter

Campus Backbone

Public Internet

AccessRouter

Access Point

Lancaster City Wireless Network

User TerminalUser Terminal

User Terminal

Base station

Figure 4 Network Infrastructure (simplified)

The logical network infrastructure for our wireless network is illustrated in Figure 4. As can be seen from the diagram, the network is formed from a number of over-lapping wireless cells, consisting of a variety of technology ‘flavours’. Adjacent cells of the same flavour can be merged together using layer two bridging in order to form a cell with a larger footprint. Although bridging is an effective means to interconnect a small number of homogenous cells, it is well understood that such architectures do not scale. In addition, when the case of a mobile device crossing between different flavours of network is considered, it becomes apparent that bridging provides little support. In order to address these issues, the Testbed network places layer 3 administrative boundaries between cells of different flavours, and optionally between cells of the same flavour. These boundaries separate logical areas of administrative control, called districts.

26


Each district within the Testbed consists of one IPv6 (sub) network. As can be seen from Figure 4, each district within the Testbed is served by an IPv6 access router. This access router is directly responsible for the management of that district, such as IPv6 routing, access control and billing. Access routers are interconnected and linked back to the campus backbone via a wired infrastructure, using SDH, DSL or over point-to-point microwave links.

Scalability

The use of individually managed IPv6 based cells gives many scalability advantages. Primarily, as there is a vast expanse of available IPv6 address space, it is perfectly feasible to uniquely address each cell within the Testbed as a separate IPv6 network, and still maintain scalability. This would be difficult to achieve with IPv4, even through the use of network address translators (NATs). Additionally, the auto-configuration support offered by IPv6 negates the need for services with higher administration costs, such as DHCP.

The architecture also provides scalability for larger networks. As the access control is enforced by the access router (at the first hop of the wireless network), this distributes the load of access control throughout the network.

Finally, the fact that the wireless cells are routed rather than bridged results in less broadcast traffic on those cells, thus improving network utilisation. In turn, this also improves the security of the network, as it makes it far more difficult for users to snoop packets or masquerade as other network nodes (in the case of a fully routed network, both the attacker and target must be co-located within the same cell, making the attacker much easier to discover and track).

Host Mobility

Although there are clearly many advantages to be gained from having a fully routed network, it does add more complexity to the mobility management subsystem of the network. Consider the case of a mobile device roaming between various flavours of network within the Testbed. As the mobile node crosses an administrative boundary between districts, it sees a change in its IPv6 point of attachment. We envision that these administrative boundaries will be highly commonplace, separating areas with differing access control settings. They could be as often as different offices/ laboratories within a building, and different shops within a city. It is therefore vital that the transition between districts is handled smoothly and quickly by the infrastructure. We use Mobile IPv6 [9] to enable this roaming between cells, which provides us with the necessary location independence and transparency, a distributed mobility management architecture and reasonable handoff performance1. However, this adds an additional requirement onto the access control architecture – any authentication or access control mechanisms must not interfere with the performance of the handoff between districts.

4.1.3 Access Control Mechanism The access control mechanism proposed for the Mobile IPv6 testbed is based on the principles of packet marking and packet filtering. Data packets are tagged on the client terminal through an extension to the network stack before they leave the node. Based on presence and credentials associated with the packet marking, access to the trusted network (i.e., public Internet or value-added service networks) is granted or denied.

The key components of our access control architecture are described here. Figure 4 illustrates how they are situated within our network infrastructure.

• The Authentication Server (AS) is responsible for the authentication and authorisation of clients on the access network. Upon successful authentication and authorisation of a user, the AS issues a limited lifetime access token to the user.

1 Handoff times with ‘normal’ Mobile IPv6 are not good enough for real-time applications. Further mechanisms to support faster handoffs for real-time applications will be studied in D4.1.3

27


• User end-terminals (i.e., handheld devices, laptops, etc.) request the authorisation of the node on behalf of the current user and perform the packet marking for outbound traffic. A valid access token is obtained from the AS upon successful authorisation of the user. The access token, in turn, provides the basis for the packet marking.

• Access Routers (ARs) control the access to the protected network. They block traffic originating from or sent to unauthorised end-terminals based on network-level packet filtering. Co-locating the ARs directly with the base stations enables highly flexible access control close to the user (thus minimizing the area which can be targeted by an unauthorized attacker).

• The Gateway connects the access network with the public Internet or a private Intranet (i.e., Campus network). It is concerned with external security threats from arbitrary nodes on the public network and is an extension of the firewall concept.

Account Creation

In order to access a publicly accessible network guided with our access control system, a user’s end-terminal requires our Mobile IPv6 stack extension. The user downloads and installs the extension at account setup time1. The user’s secret credentials (i.e., username and password) are created and registered with the authentication server. The user is also assigned a group, which defines the level of service granted to the user. For example, groups have individual access profiles in terms of which cells they can access (i.e., at what times, and how long or frequently).

In future, we plan to support service differentiation in terms of QoS (i.e., different priority levels, data rate limitations, payload volume restrictions) based on the group affiliation.

Session Initialisation

Before a user can access the network, the end-terminal requires a valid access token in order to tag packets for transit via the access routers. As a result, the user will be prompted to enter his username and password during session initialisation (e.g. when the device is turned on in a cell or at initial network entrance). This process occurs only once per login session as the credentials are cached for the duration of a session.

User Authentication

User authentication is carried out between the user’s end terminal (e.g. PDA or laptop) and the authentication server. The client software takes care of authentication of the user currently logged in. The authentication request sent from an end terminal to the authentication server includes the user’s username and password, the node’s MAC Address and IPv6 Address, and a secret session key. While the username and password are required to authenticate the user, the MAC and IP addresses are needed to authorise the client node on the access routers. As further discussed below, the session key is needed for the encryption of the access tokens, to avoid address spoofing attacks with the network.

In order to prohibit malicious users from spoofing the secret credentials of other users or a session key, the authentication request message must be encrypted. We use public key encryption based on the RSA algorithm [27] and the standard IPsec encryption header [28] in order to avoid the need for a secure key exchange mechanism and a special protocol extension. Public key encryption is advantageous as the client must know only the public key of the authentication server (which can be statically configured) and not vice versa.

Token Generation

Access tokens are the secret credentials that grant packets from authorised end terminals access to the protected network. The tokens are issued to particular users upon successful authentication and authorisation.

1 It should be noted here that our extension does not impact the “normal” use of the Mobile IPv6 stack in conventional networks.

28


However, passing the access tokens in clear text to the client would allow malicious users in the same cell to snoop valid tokens. Therefore, to secure the access control mechanism even against MAC address spoofing, the access token requires encryption. The shared session key passed within the authentication request is used for the encryption of the authentication response message.

In order to avoid brute force attacks on access tokens, we chose to restrict the lifetime of the access tokens to a configurable time interval, referred to as the expiration time of a token. Beyond this interval the extended protocol stack must refresh the node’s authorisation based on the cached user credentials to request a new token.

Figure 5 Access Control Protocol

Since the access token is simply a pseudo-random value that is large enough to make it hard to guess or discover by a brute force search within the lifetime of the token, the expiration time must reflect the size of the access token1. The refresh time of the authentication protocol must be sufficiently smaller than the expiration time2.

The main advantage of those short-lived access tokens is that they provide extra security and robustness. The fact that they change so frequently make them hard to crack.

Packet Marking

End terminals use packet marking as a technique to indicate authorised packets to the access routers. When the Mobile IPv6 stack forwards a packet, it includes our access control extension within the Hop-by-Hop Option extension header of the IPv6 packet as illustrated in Figure 6. This header contains the access token and a checksum besides usual housekeeping information (i.e., protocol version and encryption type). The token and checksum are both encrypted using the session key associated with the access token. The checksum is required as a measure against replay attacks. It prevents a potential attacker from simply snooping the extension header and adding it to their own data.

1 Since we encrypt the 32-bit access token together with a 96-bit checksum, we currently use a 10 minute expiration time. 2 We suggest a refresh time that equals to: Trefres = min{Texpiration – 2 X avg( Tauthentication ), 2/3 X Texpiration}

29


Since the extension header must be attached to all data packets, a very lightweight encryption mechanism is required. We therefore use a symmetric cipher in order to avoid the performance overhead of asymmetric cryptographic algorithms.

Figure 6 Access Control Extension Header

Packet Filtering

The access control mechanism described so far is based on network-level packet filtering. Access routers check packets sent to and from the end terminals for authorisation. While packets sent to the wireless network must have the destination address of an authorised end terminal, packets sent from a client node must carry a valid access token. For this, each access router maintains an access control list (ACL) that accommodates all the filter information required to identify ‘authorised’ packets, namely the MAC address, IPv6 address, access token, and session key for each authorised end terminal. The access routers receive this information from the authentication server when a user of the cell successfully authenticates with the network.

When a packet is received from the wireless network, the access router looks up the MAC address in the ACL. If an entry for the end-terminal exists, the access router verifies the IPv6 source address. In the case of a match, it decrypts the access token and checksum using the session key (held within the ACL) and validates its content against the ACL. When successful, the Hop-by-Hop Option containing the access control extension header is stripped off and the packet is passed on. Packets that fail any of those tests (e.g. due to an unknown MAC address, a wrong IPv6 address match, or an invalid or expired token) are dropped. One exception to this rule is that when a client is first seen in a cell, it is allowed to contact certain well-known IPv6 addresses; this allows nodes to initially communicate with the authentication server.

To quickly recover from missing ACL entries due to packet loss or a router crash, the access router indicates failure immediately, such that the client can re-authenticate right away. To prevent malicious users from trying to gain unauthorised access to the network, we plan to add a mechanism to black list malicious users who repeatedly send packets with invalid IP addresses or access tokens (e.g. example, through link-layer access restriction).

The soft-state authentication protocol facilitates fine-grained access control with respect to time and location. It allows end-terminals to be restricted to certain districts based on time. Furthermore, the soft-state approach eases the withdrawal of access privileges. For example, a user who is caught using the network in an inappropriate way or who runs out of online time credit can be denied access to the network by simply refusing further access tokens refreshes.

Roaming Support

30


In networks such as the Testbed, support for roaming users that frequently move between microcellular networks is crucial. From a network-level point of view, roaming support is provided through the Mobile IPv6 protocol. With respect to our access control architecture, we therefore focus on minimising the impact of access control on handoff performance. When a mobile node moves into a new network cell, it acquires a new care-of-address (CoA) to reflect its new physical network location1. As a result of the network handoff, the network access will also be controlled by a different access router, which may have no knowledge of previous authorisations for the mobile node. Unfortunately, it could take up to several minutes (i.e., until the next authentication refresh is carried out) before the mobile node would obtain access to the network again. Since service disruptions of this order are clearly not acceptable for networks such as the Mobile IPv6 Testbed, we introduced three special measures:

1. Mobile nodes immediately initiate a fresh authentication cycle for the node’s new IPv6 address immediately after a network handoff.

2. The authentication server sends the periodic ACL updates not only to the client’s access router, but also to the neighbouring access routers in order to ‘preheat’ their access control lists with authorisations for potential roaming clients. Note that with the emergence of the context transfer protocol [34] currently being discussed within the IETF, we consider using this ‘proactive’ means to transfer ACL state from previous to new access routers.

3. Access routers grant a short reprieve time for roaming nodes entering a cell, before they block traffic from the node. This technique preserves safety by granting access to packets based on a node’s previous authorisation. Due to the preheating of the neighbouring access routers, a node’s new access router will already have an entry in its access control list when the node moves into its coverage area. This allows packets with a valid MAC address and access token to pass for the period of the reprieve time. However, if the router does not receive a fresh access list update for the node’s new IPv6 address before the reprieve time expires, traffic will be blocked.

These extensions have the advantage that they do not interfere with or slow down network-level handoffs. The initial user authentication required when entering a new district is simply delayed (i.e. carried out in the background) to avoid extra latency. The reprieve time must be chosen carefully. On the one hand, the interval should be minimal as it gives provisional access to users based on their previous authorisation while, on the other hand, it must be long enough to complete a whole authorisation cycle2.

Core Network Protection

The design of our access control architecture assumes that the core network can be trusted. This assumption seems reasonable, since the access routers and the authentication server typically belong to the same administrative domain. In our network, for example, the access routers are physically protected by locked cabinets in buildings not open to the general public, and the physical links from the access routers back to the campus network are hard to intercept. However, in case we identify fraudulent misuse within the core network or in network segments that are not trusted, we fall back to use end-to-end encryption for communication between the authentication server and the access routers.

For this, standard public key encryption as supported by IPsec is recommended. In addition, we can also use the gateway router as a firewall for the core network. For security reasons and to avoid denial-of-service attacks, it can block remote traffic (sourced from the public network) directly sent to the access routers. To minimise the risk of denial-of-service attacks on the clients, the gateway could potentially rate-control transmissions to end-terminals.

Enhanced Security

1 This can be achieved either through DHCPv6 or the autoconfiguration mechanisms of IPv6. 2 We recommend a reprieve time of approximately 2-5 seconds depending on the network performance and authentication server.

31


In cases where users demand a high level of security (e.g. full privacy), the architecture supports an additional layer of protection based on full encryption of the payload on the wireless link (i.e., between the access router and client device). This offers an alternative to the IEEE 802.11 wired equivalent privacy (WEP) protocol, which has been shown to be vulnerable to attack [35]. We plan to allow the user to freely choose the level of security depending on the network use and the end-terminal at hand, as full payload encryption can be very heavyweight for low-performance mobile devices.

Finally, it is worth noting that standard IPsec authentication and encryption are entirely complementary to our access control architecture. They can be used in addition to achieve secure end-to-end communication.

4.1.4 Implementation This section outlines the implementation of the key components of our access control architecture for the wireless network around Lancaster. Due to the lack of space, we provide only a brief description here.

Client Software

According to our architecture the client software is responsible for user authentication and packet marking. User authentication is performed by a system service executed on the end-terminal. In order to gain access to the network, the user must first provide its username and password to the terminal. The credentials are then stored locally such that the actual authentication (and periodic re-authentication) with the authentication server can be performed by the service without user intervention. The authentication protocol used for client authentication with the AS is based on a lightweight request/response protocol. UDP is used for transport. Standard IPsec encryption is applied for end-to-end encryption of the authentication request1. The clients use RSA public-key encryption based on the public key of the authentication server (which can be pre-configured at the client to avoid the need for a key distribution service) to encrypt the authentication request.

As described earlier, the authentication request includes a new session key for the authentication server to establish a secure communication channel back to the client. For the encryption of the authentication response, we use symmetric encryption based on the shared session key. This is accomplished via the tiny encryption algorithm (TEA) [36].

In response to an authentication request, the server replies either with a new access token for the client or an error message. In the case of success, the client service decrypts the authentication response using the current session key and passes the token to the protocol stack for the packet marking.

As highlighted earlier, our extended protocol stack also performs the packet marking, including the most recent access token into every packet (see Figure 5) to indicate the client’s access credentials to the access routers. To prevent MAC address spoofing and replay attacks based on a spied access token, we encrypt the token along with a packet checksum (using the shared session key). The 96-bit checksum is computed from frequently changing protocol fields of the IPv6 header (namely the source and destination address, flow id, and, payload length), the transport protocol header (namely the source and destination port, and checksum), and limited data of the payload using MD5 [37]. In order to minimise the latency due to encryption of the access credentials, we use the fast block cipher TEA. The lightweight algorithm has no known cryptanalysis and is claimed to be at least as secure as the well-known IDEA cipher.

We have chosen to use the Mobile IPv6 protocol stack as a starting point to add the extra functionality required for packet marking because of the experience we have gained with this protocol stack in recent years. In particular, we support the protocol stacks for Microsoft Windows 2000/XP and Linux, since we have implemented both stacks within previous projects at Lancaster.

Authentication Server

1 For this to work in the absence of a global public key infrastructure, we statically configure the security association (SA) for the authentication server on the client. Based on this SA, IPv6 knows how to encrypt/decrypt data packets send to or received from the authentication server.

32


The authentication server runs a user-level application or service responsible for managing the user accounts, and the authentication and authorisation of the users and their terminals.

Upon receipt of an authentication request (on the well known server port), the authentication application tries to authenticate the user. On success, it sends the authentication response message including the access token back to the client and triggers the dissemination of the access control list update to the respective active router(s).

The authentication server uses a standard Mobile IPv6 stack with support for IPsec in order to provide the cryptographic means for the encrypted communication channel to the end-terminals (and potentially the access routers). A dynamic mechanism to add and remove IPsec security associations will be provided to allow the authentication service to flexibly define how authentication messages are encrypted (and decrypted respectively)1.

For the transport of our application-level authentication protocol we use UDP. Since the authentication protocol is fairly lightweight (i.e. only small amounts of data are exchanged), it does not justify the overhead of establishing separate TCP sessions for each authentication cycle. Reliability is achieved by means of a simple client driven retransmission strategy.

Although the use of UDP for the transport benefits scalability of the authentication server, the bottleneck in our architecture is still the centralised server. To overcome this limitation, we plan to exploit the new IPv6 feature anycast. This novel addressing scheme enables replication of servers behind a single anycast address to increase availability and redundancy.

Access Router and Gateway

The access routers and the gateway firewall are based on the LARA++ active router architecture [10]. LARA++ is a component-based active router platform that supports dynamic extensibility of the router functionality through remote loading and on-the-fly instantiation of active components. A sophisticated composition framework enables flexible integration of these components into the packet processing chain on the router, where they provide additional functionality.

The packet filtering and access control list management are implemented as active LARA++ components. The ACL management component listens for ACL updates (i.e., UDP datagrams sent to a well-known port on the router) and updates its access control list accordingly. The packet filter component in comparison intercepts inbound traffic (originating from the end-terminals) to verify their access credentials. If valid, the filter component removes the Hop-by-Hop Option including the access control extension header and forwards the packet; otherwise it drops the packets. Outbound traffic, in contrast, is intercepted to check whether or not it is destined to authorised clients. The gateway router will include a number of active components that attempt to secure the access network from malicious external nodes. These components will try to detect denial-of-service attacks (e.g. ping floods) by external nodes based on packet analysis (i.e., packet type, source address, data rate, etc.).

Comparisons with Other Approaches

The design of our architecture has drawn on the experience of earlier public access control research. In particular, we have combined a range of existing ideas with our own expertise in active and mobile networking and protocol design to develop a flexible, lightweight, scalable and secure access control solution with special support for mobile environments.

Two early access control systems, namely Carnegie Mellon’s NetBar system [39] and the public access system developed at UC Berkeley [40], use specialised hardware (i.e. hubs, switches) to control network access on a port basis. Both solutions dynamically enable or disable link layer access to network ports based on user authentication. While CMU’s NetBar system is based on a remote configurable VLAN switch,

1 More specifically, a global SA for datagrams received from any of the end-terminals is needed to instruct IPsec to decrypt the messageusing the server’s private key, whereas individual SAs for every client are required to define outbound message to be encrypted based on the current session key (shared between the client and AS).

33


Berkeley’s solution relies on an intelligent hub. Despite the fact that both solutions require expensive specialized hardware, they are not practical for wireless networks, where many end-terminals share the same base station and hence the same network port on the switch/hub.

A more promising hardware-centric approach was recently announced by the IEEE 802.1x standardisation body. The port-based network access control [41] performs layer 2 authentication of the host to obtain access to a switch LAN by means of the extensible authentication protocol (EAP). This approach provides per-port access control at the first point of attachment (the edge). The fact that our infrastructure is based on microcellular layer 3 networks, which can exactly correspond to the link-layer cells, allows our solution to support access control at the same granularity than port-based network access control.

The systems described above are all limited to address a single aspect, namely access control. Our architecture in comparison is provisioned to address supplementary aspects of a public access infrastructure, such as accounting, quality of service, monitoring, or detection of security attacks. Especially the use of dynamically extensible active routers inside the access network provides great flexibility for future integration of additional functionality and services as they are needed or being developed.

However, the major difference to the access control approach introduced so far is probably that our architecture performs access control at the network-layer rather than the link-layer. The advantage of layer 3 access control is that it can be used as a uniform mechanism across many link-layer technologies. Current link-layer access control solutions are still predominantly based on the idiosyncrasies of the technology at hand, although standardisation efforts are under way.

Two further network-level access control systems we are aware of are Standford’s SPINACH system [42] and Microsoft’s CHOICE [43]. Both have been fully deployed in a real environment. The early SPINACH system controls network access simply based on the address pair (IP, MAC) of successfully authenticated users. This approach cleverly reuses the existing infrastructure without the need for additional hardware or specialised client software, but at the cost of inferior security (i.e., no measures against MAC address spoofing). The more recent CHOICE system in comparison accomplishes a high-level of security through the concept packet marking and packet filtering. Successfully authenticated and authorised users receive a token at session initialisation time. A custom network device driver on the client attaches the tag to every outbound data packet to indicate its authorisations.

The architecture involves separate authoriser and verifier gateways in addition to a central authentication server. While the authoriser gateway enables restricted access to the authenticator only, the verifier gateway grants full access to the network based on the packet tags.

Although based on the same access control principles, our approach distinguishes itself from CHOICE in a number of ways. Three key differences are:

1. We introduce the concepts of short-lived access tokens and session keys, and a soft-state authentication protocol to enhance robustness and security. The fact that the user’s security credentials (tokens and keys) are frequently renewed enables the use of lighter weight crypto systems without sacrificing security.

2. Our access control architecture accounts for smooth handoffs between layer 3 networks. Our approach is therefore not restricted to link layer handoffs and a single layer 3 network, which makes our architecture more scalable than CHOICE.

3. We introduce the concept of microcellular administrations (referred to as districts) to enable fine-grained access control, accounting and monitoring, which considerably improves flexibility (for example, a wide range of access policies and accounting models can be implemented).

Furthermore, unlike CHOICE and SPINACH, our architecture does not rely on the availability of other higher level services, such as DHCP for auto-configuration of the client terminals and HTTP (and SSL) for Web-based user authentication. Instead, our clients use the standard IPv6 auto-configuration mechanism to obtain a network address, IPsec encryption to secure the authentication protocol, an extension to the Mobile

34


IPv6 stack to accomplish packet tagging, and a lightweight request/response authentication protocol (based on UDP).

35


5 Simple VPN-based Access Control Procedure The scope of this section includes the aspect of supporting IPv6-only WLANs along with access control solutions. In the first version of this deliverable, an access protocol was proposed aiming at achieving a high level of flexibility, scalability and robustness including the ability to operate over various access technologies, to negotiate strong security schemes, to operate in an inter-domain environment and to resist to a whole range of attacks. An implementation of the resulted protocol is presented. An analysis of the assets and drawbacks of this implementation with a discussion about further extensions in its functionality is given.

5.1 Technologies Involved

Before presenting the solution for a secured access control in a wireless environment a brief overview is given on the protocols and specifications that play a role in the solution.

5.1.1 IPsec IPsec provides encryption and authentication services at the IP level of the network protocol stack. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols.

These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations.

IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more „paths“ between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc. The IPsec DOI also supports negotiation of IP compression [45], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.

5.1.2 IKE - Internet Key Exchange The purpose of IKE is to negotiate, and provide authenticated keying material for security associations in a protected manner.

Processes which implement this can be used for negotiating virtual private networks (VPNs) and also for providing a remote user from a remote site (whose IP address need not be known beforehand) access to a secure host or network.

36


Client negotiation is supported. Client mode is where the negotiating parties are not the endpoints for which security association negotiation is taking place. When used in client mode, the identities of the end parties remain hidden.

IKE is a protocol using part of Oakley [47] and part of SKEME [48] in conjunction with ISAKMP [46] to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI [49].

The following attributes are used by IKE and are negotiated as part of the ISAKMP Security Association. (These attributes pertain only to the ISAKMP Security Association and not to any Security Associations that ISAKMP may be negotiating on behalf of other services.)

• encryption algorithm

• hash algorithm

• authentication method

• information about a group over which to do Diffie-Hellman.

5.1.3 AAA Infrastructure The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization and Accounting and roaming situations.

Network access requirements for AAA protocols [50] include:

• Failover. RADIUS does not define failover mechanisms, and as a result, failover behaviour differs between implementations. In order to provide well defined failover behaviour, Diameter supports application-layer acknowledgements, and defines failover algorithms and the associated state machine.

• Transmission-level security. RADIUS defines an application-layer authentication and integrity scheme that is required only for use with response packets. While [51] defines an additional authentication and integrity mechanism, use is only required during Extensible Authentication Protocol (EAP) sessions. While attribute-hiding is supported, RADIUS does not provide support for per-packet confidentiality. In accounting, [52] assumes that replay protection is provided by the backend billing server, rather than within the protocol itself.

• Reliable transport. RADIUS runs over UDP and does not define retransmission behaviour; as a result, reliability varies between implementations. As described in [53], this is a major issue in accounting, where packet loss may translate directly into revenue loss. In order to provide well defined transport behaviour, Diameter runs over reliable transport mechanisms (TCP, SCTP) as defined in[54].

• Agent support. RADIUS does not provide for explicit support for agents, including proxies, redirects and relays. Since the expected behaviour is not defined, it varies between implementations. Diameter defines agent behaviour explicitly; this is described in Section 5.1.3.1.

• Server-initiated messages. Server-initiated messages support is optional. This makes it difficult to implement features such as unsolicited disconnect or re-authentication / re-authorization on demand across a heterogeneous deployment. Support for server-initiated messages is mandatory in Diameter.

37


• Auditability. RADIUS does not define data-object security mechanisms, and as a result, untrusted proxies may modify attributes or even packet headers without being detected. Combined with lack of support for capabilities negotiation, this makes it very difficult to determine what occurred in the event of a dispute..

• Transition support. While Diameter does not share a common protocol data unit (PDU) with RADIUS, considerable effort has been expended in enabling backward compatibility with RADIUS, so that the two protocols may be deployed in the same network. Initially, it is expected that Diameter will be deployed within new network devices, as well as within gateways enabling communication between legacy RADIUS devices and s. This capability, enables Diameter support to be added to legacy networks, by addition of a gateway or server speaking both RADIUS and Diameter.

In addition to addressing the above requirements, Diameter also provides support for the following:

• Capability negotiation. RADIUS does not support error messages, capability negotiation, or a mandatory/non-mandatory flag for attributes. Since RADIUS clients and servers are not aware of each other's capabilities, they may not be able to successfully negotiate a mutually acceptable service, or in some cases, even be aware of what service has been implemented. Diameter includes support for error handling, capability negotiation, and mandatory/non-mandatory attribute-value pairs (AVPs).

• Peer discovery and configuration. RADIUS implementations typically require that the name or address of servers or clients be manually configured, along with the corresponding shared secrets. This results in a large administrative burden, and creates the temptation to reuse the RADIUS shared secret, which can result in major security vulnerabilities if the Request Authenticator is not globally and temporally unique as required in RADIUS. Through DNS, Diameter enables dynamic discovery of peers. Derivation of dynamic session keys is enabled via transmission-level security.

• Roaming support. The ROAMOPS WG provided a survey of roaming implementations [55], detailed roaming requirements, defined the Network Access Identifier (NAI) [56], and documented existing implementations (and imitations) of RADIUS-based roaming [57]. In order to improve scalability, [57] introduced the concept of proxy chaining via an intermediate server, facilitating roaming between providers. However, since RADIUS does not provide explicit support for proxies, and lacks auditability and transmission-level security features, RADIUS-based roaming is vulnerable to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. As a result, it is not suitable for wide-scale deployment on the Internet. By providing explicit support for inter-domain roaming and message routing, auditability [58], and transmission-layer security features, Diameter addresses these limitations and provides for secure and scalable roaming.

5.1.3.1 Diameter protocol The Diameter base protocol provides the following facilities:

• Delivery of AVPs

• Capabilities negotiation

• Error notification

• Extensibility, through addition of new commands and AVPs (required in [50]).

• Basic services necessary for applications, such as handling of user sessions or accounting

38


All data delivered by the protocol is in the form of AVPs. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs that are explicitly excluded are not included. AVPs are used by the base Diameter protocol to support the following required features:

• Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user.

• Transporting of service specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted.

• Exchanging resource usage information, which may be used for accounting purposes, capacity planning, etc.

• Relaying, proxying and redirecting of Diameter messages through a server hierarchy.

The Diameter base protocol provides the minimum requirements needed for an AAA protocol, as required by [50]. The base protocol may be used by itself for accounting purposes only, or it may be used with a Diameter application, or network access. It is also possible for the base protocol to be extended for use in new applications, via the addition of new commands or AVPs. At this time the focus of Diameter is network access and accounting applications. A truly generic AAA protocol used by many applications might provide functionality not provided by Diameter.

Any node can initiate a request. In that sense, Diameter is a peer-to-peer protocol. In this document, a Diameter Client is a device at the edge of the network that performs access control, such as a Network Access Server (NAS) or a Foreign Agent (FA). A Diameter client generates Diameter messages to request authentication, authorization, and accounting services for the user. A Diameter agent is a node that does not authenticate and / or authorize messages locally; agents include proxies, redirects and relay agents. A Diameter server performs authentication and / or authorization of the user. A Diameter node may act as an agent for certain requests while acting as a server for others.

The Diameter protocol also supports server-initiated messages, such as a request to abort service to a particular user.

5.1.3.2 Diameter Header A summary of the Diameter header format is shown below. The fields are transmitted in network byte order.

39


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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Version | Message Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| command flags | Command-Code |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Application-ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Hop-by-Hop Identifier |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| End-to-End Identifier |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Command flags: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R P E T r r r r| +-+-+-+-+-+-+-+-+

Table 4: Format of the Diameter header Fields:

• Version

o This Version field must be set to 1 to indicate Diameter Version 1.

• Message Length

o The Message Length field is three octets and indicates the length of the Diameter message including the header fields.

• Command Flags

o The Command Flags field is eight bits. The following bits are assigned:

R(equest) - If set, the message is a request. If cleared, the message is an answer.

P(roxiable) - If set, the message may be proxied, relayed or redirected. If cleared, the message must be locally processed.

E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF (augmented Backus-Naur form) described for this command. Messages with the 'E' bit set are commonly referred to as error messages. This bit must not be set in request messages.

T(Potentially re-transmitted message) - This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate due to a link failure. This bit must be cleared when sending a request for the first time, otherwise the sender must set this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request; retransmissions by other entities need not be tracked. Diameter agents that receive a request with the T flag set, must keep the T flag set in the forwarded request. This flag must not be set

40


if an error answer message (e.g. a protocol error) has been received for the earlier message. It can be set only in cases where no answer has been received from the server for a request and the request is sent again. This flag must not be set in answer messages.

r(eserved) - these flag bits are reserved for future use, and must be set to zero, and ignored by the receiver.

• Command-Code

o The Command-Code field is three octets, and is used in order to communicate the command associated with the message. The 24-bit address space is managed by IANA.

o Command-Code values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE -FFFFFF) are reserved for experimental use.

• Application-ID

o Application-ID is 4 octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application.

o The application-id in the header must be the same as what is contained in any relevant AVPs contained in the message.

• Hop-by-Hop Identifier

o The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) and aids in matching requests and replies. The sender must ensure that the Hop-by-Hop identifier in a request is unique on a given connection at any given time, and may attempt to ensure that the number is unique across reboots. The sender of an Answer message must ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request. The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier must be discarded.

• End-to-End Identifier

o The End-to-End Identifier is an unsigned 32-bit integer field (in network byte order) and is used to detect duplicate messages. Upon reboot implementations may set the high order 12 bits to contain the low order 12 bits of current time, and the low order 20 bits to a random value. Senders of request messages must insert a unique identifier on each message. The identifier must remain locally unique for a period of at least 4 minutes, even across reboots. The originator of an Answer message must ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request. The End-to-End Identifier must not be modified by Diameter agents of any kind. The combination of the Origin-Host (see section 6.3) and this field is used to detect duplicates. Duplicate requests SHOULD cause the same answer to be transmitted (modulo the hop-by-hop Identifier field and any routing AVPs that may be present), and must not affect any state that was set when the original request was processed. Duplicate answer messages that are to be locally consumed SHOULD be silently discarded.

• AVPs

41


o AVPs are a method of encapsulating information relevant to the Diameter message. See section 4 for more information on AVPs.

5.1.3.3 Diameter AVPs The fields in the AVP header must be sent in network byte order. The format of the header is:

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| AVP Code |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V M P r r r r r| AVP Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Vendor-ID (opt) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data ... +-+-+-+-+-+-+-+-+

Table 5: The format of the Diameter AVPs Fields:

• AVP Code

o The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA.

• AVP Flags

o The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. The 'P' bit indicates the need for encryption for end-to-end security.

o The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message must be rejected. Diameter Relay and redirect agents must not reject messages with unrecognized AVPs.

o The 'M' bit must be set according to the rules defined for the AVP containing it. In order to preserve interoperability, a Diameter implementation must be able to exclude from a Diameter message any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears.

o The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space.

• AVP Length

42


o The AVP Length field is three octets, and indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute length, the message SHOULD be rejected.

5.2 Proposed Protocol

It is assumed that extending the ISAKMP with an AAA based authentication scheme is likely to yield a close to the optimum solution. The protocol presented describes one possible way to achieve this. It reuses ISAKMP/IKE and runs in two phases:

The first phase is a typical AAA authentication request/reply that involves the mobile user, the attendant (NAS/VPN concentrator) and the user’s home AAA server entity (AAAH). The AAA exchange is also used to perform an authenticated exchange of IKE phase 1 messages in the form of a shortened aggressive mode exchange.

The second phase consists of a typical IKE Quick Mode exchange that takes place between the attendant and the mobile terminal. The SA negotiated during this phase (typically ESP in tunnel mode) will protect all subsequent data traffic.

The first phase exchange must take into account that because the nomadic node and the attendant do not share any pre-existent trust relationship, the impact of a number of attacks is exacerbated by the easiness an attacker can access the transmission medium. The proposed protocol guards against the following potential attacks:

• Computational DoS attacks—computationally expensive operations (asymmetric cryptographic operations including public Diffie-Hellman key generation and shared Diffie-Hellman key derivation) must be avoided as long as the nomadic node is not yet authenticated. Initial authentication would ideally be based on shared secrets;

• Resource depletion attacks—intermediate entities must avoid creating states as long as the nomadic node is not yet authenticated.

• Reply protection—replied control messages may have significant impact because they may:

o Produce alteration of the states in intermediate entities that are relevant to the victim in such a way that the victim cannot receive the service;

o Facilitate computational DoS attacks because the replied messages pass the first barrier of authentication.

• Man-in-the-middle attacks—intermediate entities substitute the security information (such as public keys) with the purpose of breaching the security mechanisms or stealing the secure connection set up on behalf of a legitimate nomadic node. Such attacks can be mounted on the access link by malicious visitors that poison the neighbour caches as well as by malicious AAA entities located on the bath between the access domain and home domain.

5.2.1 General Description Figure 7 illustrates the message exchange. The local AAA server (AAAL) has not been depicted, its functionality is reduced to forwarding AAA commands between the attendant and the home AAA server (AAAH).

43


It is assumed that the nomadic node and the AAAH share a secret denoted as SKNH. For location detection the nomadic node relies on the periodic router advertisement messages sent by the attendant.

RAdv

APReqAuthReq

AuthAnsAPAns

IKE_QMi1

IKE_QMr

Node Attendant AAAH

IKE_QMi2

Figure 7: The message exchange The protocol has the following properties:

• It substantially relies on ISAKMP/IKE exchanges, which enables the nomadic node and the attendant to negotiate strong security schemes and supports fast re-keying;

• No state is required to be maintained on the attendant until the authentication request is validated by the appropriate AAAH. This property has however a limited impact because in a typical configuration the attendant plays the role of an AAA client, and the Diameter protocol requires clients to maintain state. Nevertheless, the proposed protocol does not pose additional burden, should a resource depletion attacks occur;

• An end-to-end security association between the attendant and the AAAH is not required, while the protocol ensures robustness against man-in-the-middle attacks from malicious AAA entities located on the attendant-AAAH chain;

Timestamps are used in order to protect against replay attacks. A mechanism similar to the one used in Mobile IPv4 is used to synchronize the timers on the nomadic node and AAAH.

5.2.2 Data Exchange The VPN based access control protocol consists of the message exchanges depicted below where the following notations are used:

Encr{key}(data) Cipher representing “data” encrypted with “key”

HMAC{key}(data) Keyed-Hashing for Message Authentication: Keyed hash computed with “key” over “data”

Indices N, A, H Node, Attendant, Home

Indices i, r Denote initiator and responder, respectively, as defined in the IKE protocol

Tx Timestamp of entity x, in UTC format, stored in network order

44


Nx Nonce of entity x

SECx Security information for establishing ISAKMP SA

AUTHx Authentication information of entity x

NIDx The ID of hash algorithm as defined in OpenSSL

ADDRn The address of node stored in any convenient format for attendant

IP Internet Protocol address

KA Private key

KE Public Diffie-Hellman key as defined in the IKE protocol

MAC Media Access Control (layer 2) address

NAI Network Access Identifier [56]

SA Parameters associated to an IKE or CHILD security association, as defined in the IKE protocol

SKXY Key shared by X and Y

SPI Security Parameter Index (equivalent to IKE’s cookies)

HDR(x) or HDR(x, y) ISAKMP Message Header containing x as I-COOKIE and y as R-COOKIE, with their meaning as described in IKE

Table 6: Notations used in the message exchanges of the AACP The message exchange takes place between peers, as depicted in Figure 7. APReq, AuthReq, AuthAns and APAns denote the control messages exchanged by Node, Attendant and AAAH which are typically composed of a sequence of AVPs containing control information relevant to the AAA protocols. The set of existing AVPs is extended with a number of AVPs that encapsulate control information relevant to the SA and key management (a set of IKE payloads).

5.2.2.1 Message: Node → Attendant

APReq: NAI, TN, SECN, NN, AUTHN

Where

SECN: HDR(SPIi), SAi, KEI, Ni

AUTHN: NIDN, HMAC{SK’NH}(NAI, TN, SECN)

SK’NH: HMAC{SKNH}(NN)

Table 7: Message description Node → Attendant The message contains the nomadic node’s NAI, which is used by Attendant to set the domain part of it as Destination Realm (AAAH) when forwarding the request to AAAL.

45


A timestamp TN is used to protect against reply attacks and a nonce NN serves to derive the nomadic node-AAAH authentication key.

When the attendant receives this message, it will also record the node’s address (which typically should contain the IP and MAC) in ADDRN that will be forwarded in the next message. The same ADDRN will be brought back to attendant in the authentication response so that the node could be notified without maintaining states.

The nomadic node also includes an AVP containing an SECN encoded as an ISAKMP message with the note that SPIi will be put in the I-COOKIE field of HDR which is followed by the SA proposal, a public Diffie-Hellman key, and a nonce. And finally the message is completed with an authenticator that affords integrity protection to the whole message.

5.2.2.2 Message: Attendant → AAAH

AuthReq: NAI, TN, SECN, NN, AUTHN, SECA, AUTHA

Where:

SECA HDR(SPI , SPI ), SA , KE , Ni r r r r

AUTHA HMAC{K }( SEC , SEC ADDR , T )A N A, N A

Table 8: Message description Attendant → AAAH The attendant produces a response to the ISAKMP initiation message received from the nomadic node. This operation must involve minimal computational resources therefore the processing is limited to:

• Checking the nomadic node’s SAi proposal and compiling a response (SAr) indicating the accepted transforms, Oakley group and lifetime.

• Generating a nonce.

• Generating an incoming SPI for the IKE SA.

• Public Diffie-Hellman keys may be reused over multiple sessions therefore they may be periodically generated off-line, as they are time consuming operations.

• Additionally the attendant computes, using a key known only to itself, a keyed hash over the ISAKMP messages, the ADDRN of the supplicant and a local timestamp. The keyed hash must be echoed by the AAAH and it enables the attendant to check that the authentication answers it receives correspond to previous authentication requests.

5.2.2.3 Message: AAAH → Attendant

AuthAns: Success, NAI, ADDRN, TN, TA, TH, SECN, SECA, NH, AUTHA, AUTHH

Where:

AUTHH NID , HMAC{SK” }(NAI, T , T , SEC )H NH N H A

46


SK”NH MAC(SK | N )NH H

Table 9: Message description AAAH → Attendant The AAAH checks the authenticator provided by the nomadic node, and if the supplicant is authentic, the timestamp provided in the message is compared to the local time. If the two time values are not shifted beyond a pre-configured accepted value, then the AAAH generates a positive answer.

The AAAH provides its own timestamp, a nonce used to derive the authentication key from SKNH and authenticates the ISAKMP response message generated by the attendant.

Malicious AAA entities may attempt to fake authentication answers. However, the security scheme can only be breached when such an AAA entity conspires with malicious visitors. Otherwise an authentication answer cannot be replied nor can the public Diffie-Hellman key provided by a legitimate user be replaced. Such a collusion situation is however not typical to the proposed protocol and appropriate security measures must be taken to protect the AAA infrastructure against such attempts. In particular the AAA relay and proxy agents must be replaced with AAA redirect agents whenever this is possible, otherwise AAA servers that use their services must setup end-to-end security associations.

5.2.2.4 Message: Attendant → Node

APAns: NAI, TN, TH, NH, SECA, AUTHH

Table 10: Message description Attendant → Node The attendant checks the keyed hash computed with its private key and if the message proves to be authentic and timely the attendant creates a state, derives the shared secret from the public Diffie-Hellman exchange, forwards the relevant data to the nomadic node and waits for it to initiate the IKE quick mode exchange after it prepares the IPsec implementation with the now authenticated ISAKMP SA.

5.2.2.5 Timer Synchronisation or Authentication Method Rejection

AuthAns: Rejected, NAI, ADDRN, TN, TA, TH, SECN, SECA, NH, AUTHA, AUTHH

AUTHH NID , HMAC{SK” }(NAI, T , T )H NH N H

APAns: NAI, TN, TH, NH, AUTHH

Table 11: Timer Synchronisation or Authentication Method Rejection The difference from the successful authentication is that SECA is not included in AUTHH. This rejection occurs when either the time difference between TN and TH is too big, either the NIDN specified in AUTHN is not accepted by the AAAH because it is considered weak, in this case AUTHH containing a NIDH different from NIDN.

In this rejection scenario the attendant does not create any new state and does not modify any existing state. Upon receiving such a message, the nomadic node checks the authenticator and the timestamp before proceeding with the adjustment of the local timer. This ensures that a malicious AAA entity that replies such a message or creates a faked one cannot disturb in any way the service.

47


5.3 Implementation

This section provides the description of the main software components involved in the implementation of the protocol presented in Section 5.2.

5.3.1 DISC – Diameter Server/Client DISC is an extendible diameter AAA server / client. It is a free implementation for the AAA infrastructure developed under GPL (GNU Public License)1. As we have seen in section 5.1.3, the AAA infrastructure offers a framework for applications that run on top of it, using the messages and the conventions specified in the Diameter protocol.

This implementation can be executed either as a client or as a server, all its functionality being assured by the plug-able modules which will serve the applications for which the server or client is running.

The environment for building and executing DISC is any UNIX-Like Operating System. Tests proofed compatibility with Linux, FreeBSD and Solaris.

5.3.1.1 Configuration By means of a configuration file (typically located in /usr/local/etc/disc/) it is possible to set parameters using the following conventions:

config_option = value

command param1 [, param2 […]]

Table 12: The format to set parameters The main options fall into the following categories:

• Running as server or client

o aaa_status = AAA_SERVER

o aaa_status = AAA_CLIENT

• The AAA realm that will be served by the current client/server

o aaa_realm = realm-name

• The FQDN on the machine running DISC

o aaa_fqdn = FQDN

• Specifying the peers of the client/server

o peer aaa://FQDN:port;transport=protocol alias-name

• Specifying the routes for packets that reach the server (clients do not route packages)

o route partial-domain alias-name|host-name

1 http://developer.berlios.de/projects/disc/

48


o partial-domain can be an incomplete (in the left side) domain name (e.g. fraunhofer.de) or a wildcarded domain name (e.g. mobis.*, *fokus.fraunhofer.de)

• Setting a default path for modules

o module_path = path

• Specifying a module to be loaded (the loaded module must be of type AAA_SERVER or AAA_CLIENT accordingly to the aaa_status of the server)

o module = module-name

• Giving a parameter to a module

o set_mod_param module-name param-name value

5.3.1.2 Mode of Operation This section describes how DISC works as client or server in a AAA infrastructure.

5.3.1.2.1 Operating as AAA Server As we have seen in previous section 5.3.1.1, we must provide in the configuration file some peers which will represent other clients or servers in the AAA infrastructure. Packets received by this server will be routed towards the domain specified in the AVP_Destination_Realm.

If the destination matches the server’s realm then the server must solve the request specified in the received packet. This is done by searching a module among those loaded at initialization whose Application Id matches the one in the AAA Header of the packet. When the module is found, the message is passed to the module through the Diameter API. The module’s responsibility is to treat the message if it is a request and to generate a corresponding AAA response message to be passed back to the originating client.

The packets that do not have the destination set to current server will be routed accordingly to the routing rules in the configuration file. This requires that the routing table must be complete with regard to the AAA servers in the infrastructure, which is very much eased by the acceptance of the wildcard-ed domains in routing rules.

5.3.1.2.2 Operating as AAA client The client should have only one peer—the server from whose domain this client is. All the requests generated by this client will be sent through its corresponding server to the realm requested. Also there should be no routing rules in the configuration because packets are sent with the implicit rule explained above.

Normally, the modules loaded in the client will await requests using their specific protocol and when such a request is received they build an AAA message and send it using Diameter API in the AAA infrastructure to a server. When the response arrives back from the server, the corresponding client module is called with the response message as argument. Again, using application’s specific protocol, the authentication request is sent back to the node that called the AAA client.

The most common scenario is to unify the NAS (Network Access Server) with the AAA client, combination named Attendant, as described in earlier chapters.

49


5.3.2 FreeS/WAN FreeS/WAN1 is a Linux implementation of the IPsec protocols.

Note: In March 2004 the FreeS/WAN team announced2 to terminate further development of the FreeS/WAN project for several reasons. Due to the project’s time constraints alternative solutions could not be taken into account. The development of the proposed solution had been continued based on the FreeS/WAN software available.

Working at this level, IPsec can protect any traffic carried over IP, unlike other encryption which generally protects only a particular higher-level protocol, e.g. PGP for mail, SSH for remote login, SSL for web work, and so on. This approach has both considerable advantages and some limitations.

5.3.2.1 Goals The overall goal in FreeS/WAN is to make the Internet more secure and more private. This IPsec implementation supports VPNs and mobile nodes, as well.

More detailed objectives are:

• Extension of IPsec to do Opportunistic Encryption (OE) so that

o any two systems can secure their communications without a pre-arranged connection

o secure connections can be the default, falling back to unencrypted connections only if:

both the partner is not set up to co-operate on securing the connection, and

your policy allows insecure connections.

o a significant fraction of all Internet traffic is encrypted

o wholesale monitoring of the net (examples) becomes difficult or impossible

• help make IPsec widespread by providing an implementation with no restrictions:

o freely available in source code under the GNU General Public License

o running on a range of readily available hardware

o not subject to US or other nations’ export restrictions.

• provide a high-quality IPsec implementation for Linux

o portable to all CPUs Linux supports

o interoperable with other IPsec implementations

5.3.2.2 FreeS/WAN parts The main parts that constitute the FreeS/WAN project are the following:

• KLIPS: Kernel IPsec Support

1 FreeS/WAN official site: http://www.freeswan.org 2 http://www.freeswan.org/ending_letter.html

50


o KLIPS represents the modifications necessary to support IPsec within the Linux kernel. KILPS does all the actual IPsec packet-handling, including:

encryption

packet authentication calculations

creation of ESP and AH headers for outgoing packets

interpretation of those headers on incoming packets

o KLIPS also checks all non-IPsec packets to ensure they are not bypassing IPsec security policies.

• PLUTO: IPsec IKE daemon

o handles all the Phase One ISAKMP SAs

o performs host authentication and negotiates with other gateways

o creates IPsec SAs and passes the data required to run them to KLIPS

o adjust routing and firewall setup to meet IPsec requirements.

• ipsec command

o The ipsec command is a front end shell script that allows control over IPsec activity.

5.3.3 OpenSSL The OpenSSL1 Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation.

In this implementation of the proposed protocol only the crypto library part of OpenSSL is used. The OpenSSL crypto library implements a wide range of cryptographic algorithms used in various Internet standards. The services provided by this library are used by the OpenSSL implementations of SSL, TLS and S/MIME, and they have also been used to implement SSH, OpenPGP, and other cryptographic standards.

5.3.4 AACP – Authenticated Access Control Protocol This section describes the implementation of the protocol for the access control.

The implementation is done in a modular way to allow further extensions and to ease the complexity of modifying current layers to adapt to new environments. All programs use the standard C programming language.

Each logical entity involved in the proposed protocol is represented by a program with its correspondent tools or by a module.

1 http://www.openssl.org

51


As shown in the proposed protocol, the implementation must interact with the IPsec provider, i.e. FreeS/WAN. To enable the required interaction it was necessary to modify the standard FreeS/WAN with a proprietary interface located between AACP and FreeS/WAN named Quick Injector (the name will be explained below). However this modification can be enabled or disabled at the compile time, thus including the features necessary for the authenticated access control protocol or leaving FreeS/WAN exactly the way it was before.

During the first phase FreeS/WAN communicates with the Quick Injector through UNIX sockets. The Quick Injector acts as an “IKE proxy”. Messages produced by Pluto during this phase are not sent to the network but rather are piggybacked into the AACP messages.

A new type of IKE Phase 1 has been implemented in Pluto, which was called “Trivial” and takes only one round trip (as compared to one and a half for Aggressive mode and respectively three for the normal operation mode).

Following the IPsec tunnel establishment, the Phase 2 exchange (Quick Mode) takes place directly between Pluto entities.

All messages sent by AACP are encoded into AVP format.

Figure 8 depicts the components and relationships relevant in a Node-Attendant context.

NodeCommander

UDAC Quick Inj.

Diameter Msg. API

NACOM

FreeS/WAN

UDACQuick Inj.

Diameter Msg. API

NACOM

FreeS/WANDiameterProtocol

Node Attendant

AttendantList UDP

AACP

Figure 8: Node- and Attendant components in an AACP context

Figure 9 depicts the components and relationships relevant in an Attendant-Server context.

UDACQuick Inj.

Diameter Msg. API

NACOM

FreeS/WANDiameterProtocol

UDAC

DiameterProtocol

Attendant Server

UserCredentials

AACP

Diameter

Figure 9: Attendant- and Server components in an AACP context

52


5.3.4.1 Programs As explained earlier, each entity involved in the protocol has a separate program or module, because of the different tasks each one will have to accomplish and also because of the different locations of the entities.

In the following each entity is depicted with the programs that must be present on the respective machine:

• Node

o Daemon

This program must be running to listen for attendants in range and to communicate with them to establish the AACP-secured connection.

o Commander

To be able to command the Node Daemon to establish or disconnect us from an attendant Commander must be called.

o FreeS/WAN

It will assure the secured connection between the node and attendant.

When running properly there must be two components active: KLIPS (the kernel module which encrypts all traffic) and PLUTO (the keying daemon that establishes connections).

• Attendant

o AAA Client with AACP client module

This will enable the authenticated access control module to advertise in the environment expecting nodes, and will try to establish the connection with a node at its request.

o FreeS/WAN

Similar to node’s case, this will protect all the traffic with the node, after a successful negotiation through the authenticated access control protocol.

• Server

o AAA Server with AACP server module

It will serve the request from the attendants, authenticating the nodes and attendants reciprocal using the secret shared between him and the node.

5.3.4.2 Node Daemon

The Node Daemon has the task of listening for attendants and when it receives a connect command from its Commander (explained in the next section) to negotiate with the known attendants. Due to the security requirements we must pay attention to all the aspects of potential attacks especially because the initial negotiations are not protected by any authentication mechanism and there is no initial trust relationship between node and any attendant.

With respect to the modular program implementation approach, this daemon contains some components that operate stand-alone as functionality but are linked together in the node’s binary.

53


These components are:

• Main component

o Contains the execution entry, initialization code and the main functionality of the daemon.

o It uses the other components to achieve its purpose.

• Configuration interface

o Contains the standard functions to pass parameters to all components.

• NACOM

o Nacom contains the functions to handle the communication between node and attendant, in an abstract approach, transparent to the protocol or environment of communication.

o It is initialized in the NODE mode, which in some implementation may present differences to its peer mode.

• Diameter Messages API

o The packets sent through NACOM towards the attendant will respect the format of messages in AAA infrastructure for a more unitary view of the proposed protocol.

• AACP Messages API

o This is the higher level of message interface that contains the specific items of information exchanged in the authenticated access control protocol. Its use enables the node’s messages handling very clear and ease the implementation.

• Attendants Manager

o The „active” attendants to node’s perspective are available through this component, that can implement different approaches in storing information about attendants.

• Quick Injector

o This component represents the link to the IPsec implementation to feed the negotiation with security related information and to actually enable the secure tunnel with the attendant.

o It will be used to build an initiating connection protected with a negotiated ISAKMP SA.

When initializing, the node reads its configuration file (which is either the default configuration file – wrote in the binary at compile time, either a file specified in the command line, the second one being the primary option if available). After the configuration is parsed, the node initializes its listening connections and its components listed above. For the success of this initialization all components must return no error when initializing.

The behaviour of the daemon is determined by its state. At a particular time it can be only in one of the below states:

• PASSIVE

o It does not attempt to establish any connection, but it listens through NACOM for attendants in range.

54


• CONN

o It started the negotiation for establishing a secured connection, and is awaiting the result of the authentication

o If enough time elapses since the last successful sent request then it will attempt to retransmit the request.

• ACTIVE

o The secured connection is established.

• DISCONN

o This state is set when attempting to delete the secured channel with the attendant.

o In the current implementation this state is not actually used due to the uninterruptible nature of the disconnecting process, the daemon jumping directly from the ACTIVE state to the PASSIVE one.

In the main run phase of the execution the daemon waits for a packet from NACOM or from Node Commander, but until a time slice is elapsed (currently 1 s). This approach is used due to the need of doing maintenance for the pending connection request (if the current state is CONN) or for the Attendants Manager which may invalidate some expired attendants from its list.

When receiving a command from the Node Commander it checks to be one of the following:

• SHUTDOWN

o The daemon terminates its execution .

• CONNECT

o Enters the CONN state and will attempt to use the name and password given in the message to establish the tunnel.

• DISCONNECT

o Aborts the active connection and move back to the PASSIVE state.

As shown in the description of the protocol, the node knows the attendants in range due to the advertisements sent periodically by the attendants. When such a packet is received through the NACOM component, the node tells the name and address of the attendant to Attendants Manager component.

When attempting to establish a connection there are two possibilities:

1. There is no attendant in the Attendants Manager list, or

2. there is at least one attendant in that list.

If there is no attendant available, the request is postponed until there will be one. We must keep in mind that these advertisements are not authenticated in any way, thus facing the risk of encountering false attendant advertisements.

When there are attendants available, the node will simply try to send its request to all attendants. Due to the protocol’s conception, possible fake attendants cannot use the information revealed by the node, and if by

55


any chance there were more „legal” attendants that did receive the node’s request, only one will receive success from the home server of the node eliminating the risk of establishing redundant secured connections.

The information sent in the node’s request is shown as the first message in the proposed protocol. The node will send the NAI (in form user@realm), will add its time (in UTC format), the data needed to establish the ISAKMP SA (obtained from Quick Injector), a random number for its nonce and an authentication information that contains an identification for an algorithm and a HMAC computed with that algorithm over the previous items. The id of the algorithm is the one used by OpenSSL to identify that algorithm. The node use the algorithm that is specified in its configuration file in the section node at the option auth.

When the node receives the response to its request, it verifies the presence of the items as shown in message 4, but with the SECA item as optional. After having checked the NAI to be the one sent, it computes a HMAC with the algorithm specified in item AUTHH and checks if it matches the HMAC in that same item. If it doesn’t match then either somebody changed the packet or the password supplied in the CONNECT request from Node Commander is not the same with the one in the NAI’s home server. In these cases there will be no further processing of the message. If the HMAC matches, it means that our password is the same as server’s. However, if the SECA is missing from the reply message, it means that the server rejected the authentication. This can happen if our time is too different from his time (meaning the difference between the time on node’s machine when he built the packet and the time of processing on server’s machine is bigger than a limit value) or if the server does not allow the algorithm specified by the node in AUTHN. In the second case this can be observed by the difference between algorithm ids in AUTHN and AUTHH. However, for any successful signed message by the home server, the node will adjust its time based on the difference between his current time, TN and TH. The modification is local to daemon’s process to not interfere with other services on that machine.

Disconnecting consists mainly in sending through Quick Injector a message to FreeS/WAN’s daemon, PLUTO, to delete the Security Associations established with the attendant. This will cause Pluto to send messages to the attendant’s Pluto process with the Exchange Type set to Informational thus notifying it in an authenticated manner.

5.3.4.2.1 Node Commander This program is very simple and can be easily substituted by a 3rd party program with the equal functionality. Its purpose is to send commands to the Node Daemon.

The communication between the daemon and its commander is done by using UNIX (or otherwise named LOCAL) sockets. By default, the node binds the UNIX socket to the path /var/run/udac.node.commander.

The supported commands together with their specific parameters are:

• CONNECT:

o Command line: unc connect NAI password

o Functionality: sends to node daemon the connect request with user’s NAI and password specified

• DISCONNECT:

o Command line: unc disconnect

o Functionality: notifies the daemon that the user wants to destroy the connection established

56

mailto:user@realm


• SHUTDOWN:

o Command line: unc shutdown

o Functionality: command the node daemon to shutdown and to clear its resources

5.3.4.2.2 Attendant Module All the functionality of the attendant is accomplished by running an AAA client with AACP client module and also running FreeS/WAN. The communication channels used by the attendant are of 3 types:

• Unsecured link with nodes (used through the NACOM interface)

• AAA channel with the AAAL (Local server)

• Secured link with authenticated nodes (commanded through Quick Injector and established by FreeS/WAN)

The components used by our attendant implementation are:

• AAA client module

o The AAA client module initializes its components and waits for requests from the NACOM component to compute them into AAA requests

• Configuration interface

o The configuration interface contains the standard functions to pass parameters to all components

• NACOM

o NACOM contains the functions to handle the communication between node and attendant, in an abstract approach, transparent to the protocol or environment of communication

o It is initialized in the ATTD mode, which in some implementation model may present differences to its peer mode


o The packets sent to AAA servers are sent directly through Diameter API and the ones destined to nodes are parsed/built with Diameter’s message functions and sent with NACOM


o This is the higher level of message interface that contains the specific items of information exchanged in the authenticated access control protocol. Its use enables the attendant’s messages handling very clear toward both directions (nodes or servers)

• Quick Injector

o This component represents the link to the IPsec implementation to feed the negotiation with security related information and to actually enable the secure tunnel with the attendant

57


o It will be used to build a listening connection protected with a negotiated ISAKMP SA

As all DISC modules, this attendant exports a control structure which contains flags and functions for initialization, termination, message receiving and timeout handling.

At initialization time, after reading the configuration file and initializing components, it is created a thread for listening with NACOM. Also there is registered a timer to enable the attendant’s advertising periodically. When an authentication request arrives through NACOM, the packet is checked for all items as described in the previous chapter and an AAA request is sent to the server indicated by the NAI AVP in the domain side. When the response is received from the AAA Server, the appropriate module function is called with the result of the authentication. If the message contains an authenticator, the relevant part is forwarded through NACOM to the node, since the success/error is authenticated by the node’s home server. Otherwise, the unauthenticated error is silently dropped triggering a notification referring to this.

5.3.4.2.3 Server Module Similar to the previous module, this is based on the same conventions for DISC modules, only running in server mode.

The main components that together meet the AACP protocol’s home server requirements are:

• AAA server module

o Waits for messages from various attendants and authenticates their requests according to the user database component.

• Configuration


o The only communications involving the server are with attendants, completely inside the AAA infrastructure. Therefore, the Diameter API is fully used.


o This is the higher level of message interface that contains the specific items of information exchanged in the authenticated access control protocol.

o It eases the information computing done by the main module.

• User Database

o This component allows handling concurrent accesses to users, holding specific information as needed in the proposed authenticated access control protocol.

The initialization should leave the module with the user database ready for accessing.

When a request comes from an attendant, after it is validated through the AACP Message component, it is claimed the exclusive access to the user specified in the AVP containing the NAI. If the user does not exist, an error message is returned to attendant, but without authenticating AUTHH because there is no user for using its shared secret. Otherwise, this operation may block the processing thread until the other threads that served the same user finish their job. After gaining exclusive access, the AUTHN is checked, first to contain a valid NIDN and second to match the hash computed with the password returned by the USRDB component.

58


The TN data is checked to be close-enough to server’s UTC time and to be far-enough to the previous authentication time of that user. If these conditions are met, the SECA will be included in the hash computed in AUTHH, thus enabling the trust relationship between node and attendant.

5.3.4.3 Internal Structure The next sections will take an in-depth look into the components used in this implementation.

5.3.4.3.1 Configuration Interface First of all, the format of the configuration file:

# Lines beginning with ‘#’ are comments # The section groups several options that # typically are used by the same component [section] # parameter and value – represented on 1 line # the value is either integer, either string param1 any string value # the integer can be of any C-like convention param2 0x1234 [other-section] other-param another value

Table 13: The format of the configuration file The configuration interface offers functions for:

• Parsing a configuration file

• Freeing parsed info

• Search a section of a configuration

• Match a section’s parameters according to a table with parameter’s name, variable type (string or integer) and memory pointer. This function modifies the value at the given pointer with the encountered one.

5.3.4.3.2 NACOM – Node Attendant Communication This component realizes the transport between a node and attendant, in an abstractive view over the protocol and environment used to carry data packets. The communication functions are similar to connectionless models, using an extra parameter for the peer’s address. The format of the address is stored in a specific structure that offers storage for the most encountered addressing identifiers (IP address v4 or v6, port, MAC):

Typedef struct nacom_addr_s nacom_addr; struct nacom_addr_s { int type, mac_len, port; unsigned char addr[NACOM_ADDR_MAX_SIZE]; unsigned char mac[NACOM_MAC_MAX_SIZE]; };

Table 14: The format of the address structure

59


To enable a feedback mechanism for NACOM’s user when there is data received, it declares a public variable nacom_fd which represents a file descriptor whose state consistently modifies in a select call if data is available.

For this project, two implementations of the NACOM layer were completed, one based on IPv6 with ICMP, and the other on IPv4 with UDP.

The first one is the one that fully complies with the requirements of the authenticated access control proposed protocol, and uses information like MAC for addressing to minimize the spoofing attacks and to avoid ARP requests such as Neighbour Discovery which can be impersonated by poisoning entities.

The model developed on Ipv4 with UDP it is more an educational model and was easier to use during development process. Also it demonstrates the largeness of project’s applications in the field of access control.

5.3.4.3.3 AACP Messages API This layer of API functions allows a very simple handling of information items involved in the authenticated access control protocol. The list of functions is:

• um_alloc – to obtain space for the structure containing relevant items

• um_free – frees the memory of an allocated structure

• um_um2am – creates a AAA message from the given AACP message structure passed as input

• um_am2um – parses a AAA message and stores AACP relevant information into an allocated structure; this has the reverse functionality of the previous function

• um_check_map – this does a verification of what items are contained in an AACP message structure as specified in a special map structure; all AACP programs use this function to verify that received messages respect the protocol.

5.3.4.3.4 Attendants Manager for Node This component is used only by the Node Daemon, and must store the attendants given by the daemon when it receives advertisements. The implementation must not exhaust local resources when fake attendants pollute the NACOM environment with false advertisements. Of course, this can lead to forgetting some of the true attendants because there is no authentication possible at advertisement time.

5.3.4.3.5 Quick Injector – AACP – FreeS/WAN interface The most delicate component, named shortly QINJ, is actually built in to parts, one that modifies the FreeS/WAN keying daemon – PLUTO, and the other, the commanding interface included in node and attendant. The communication between these two parts is done through UNIX datagram sockets.

To respect protocol’s requirement against Computational DoS, the keys involved in ISAKMP SA negotiation must not be build for every exchange of node-attendant pair which is done by computing these keys periodically, using a period long enough not to load the computing processors but short enough to avoid breaking the secret. This period is configured in daemon or attendant’s module and when it elapses there should be a GEN_KE (Generate Keys) request sent through QINJ interface.

When the node attempts to send an authentication request, it first must fill the SECN field which is done by sending a GET_SEC_N message to QINJ and store the returned ISAKMP message inside SECN. Similarly, the attendant that receives a request from a node sends a GET_SEC_A message to his QINJ with node’s

60


address and SECN as parameters. The received ISAKMP message contains the chosen SA is the result of negotiations between both PLUTOs involved. If the home server authenticates the request, the attendant calls QINJ with the message LISTEN giving the addresses and SECN,A to build a proper connection and a state that claim a successful ISAKMP SA negotiation and computes the shared secret.

On the node’s side, when the successful message is received, the daemon sends to QINJ the IP addresses of his and attendant’s along with SECN, A in an INITIATE message. This will do the same actions as in LISTEN except it will mark the state and connection as initiator and command the initiation of the IKE phase 2, namely Quick Mode.

As explained above, it becomes clear the naming of this module Quick Injector as it injects states ready for Quick Mode.

5.3.4.3.6 User Database Another component that is used only in one program is the USRDB. Since the implementation can be done in many ways and with various models as databases, we designed a minimal interface that offers the functionality required to access users by name, read their password and read/write the last authentication time. The implementation must be thread-safe, as it will run in the context of DISC which uses worker threads to handle client requests.

The functions are:

• usrdb_lock – locks the access to all data of a given user

• usrdb_unlock – unlocks that user’s accesses

• usrdb_get_pwd – obtain user’s password

• usrdb_get_time – get the last authentication time

• usrdb_set_time – set the authentication time

5.4 Extensions

An important design issue of the protocol and its implementation was the extensibility of the project. There are several improvements possible both in the proposed protocol and implementation.

5.4.1 Automatic Connection Re-establishment The nomadic node is supposed to be able to move across different domains. However, when exiting the range covered by an attendant, the node should detect the broken link, and should attempt to establish the secured connection with an other attendant that is available. In the current implementation this was not available due to the absence of a dead peer detection capability of FreeS/WAN, which would be the mechanism for notifying the AACP program to attempt the reestablishment.

5.4.2 Fast Hand-over In completion to the previous section, switching to another attendant can be further optimized, to not involve the AAAH in the negotiation process. This could be achieved if the node’s context together with gained trust relationships are transferred to the new attendant. There are some issues regarding how this transfer could be done, especially because the two attendants do not share a secret key, even if they are part of the same “trusted” network.

61


5.4.3 Implementation Improvements Due to the modular conceptual design of AACP’s programs, each component can be separately modified or replaced without needing a general adjustment of the applications. This way, components such as an user database could be implemented to support storing information in, e. g. mySQL, databases, or NACOM can be developed for a new transport protocol.

5.5 Conclusions

The increased mobility of computing devices will lead to roaming scenarios that will require a strongly secured access control solution. The proposed Authenticated Access Control Protocol (AACP) addresses the issues related to inter-domain user authentication, strong security and robustness to DoS attacks.

AACP uses IKE for the management of the secure tunnels, AAA for inter-domain authentication and the concept of stateless connections [59] to postpone state creation until after successful authentication has been achieved. As a layer 3 protocol, AACP is link layer independent.

The prototype developed makes use of FreeSWAN, an IKE/IPsec open source implementation and DISC, an open source AAA framework implementation. FreeSWAN has been extended with a number of hooks that facilitate the exchange of cryptographic material with AACP and AACP application specific modules have been provided for DISC.

AACP incorporates in its design novel ideas of how technologies may be integrated towards flexibility and robustness.

62


6 WLAN Network Design and Deployment

6.1 Conducting a site survey

Conducting a site survey before installing a wireless network is a tedious but necessary process. In its simplest form, a network administrator installs an AP and walks around the coverage area with a WLAN-enabled laptop or PDA taking RF signal measurements at various points within the area. From the analysis of the signal measurements, it is possible to determine the optimum location of the AP according to the desired coverage area and data rate desired. However, there is a direct trade-off between coverage area and achieved data rates. Furthermore the entire process is somewhat cumbersome and very much trial and error. This hit-or-miss approach is worsens as the larger the network. Once the WLAN contains many, APs serving hundreds of users over a large area covering multiple floors and walls, the site survey becomes ever more complicated. To help with this, some WLAN vendors bundle basic site-survey tools with their APs and NICs. More sophisticated site survey software packages are available but they are often expensive and geared more towards the design of cellular networks.

It pays to follow a structured approach to the design of the WLAN network. First, the network designer must select the type of WLAN network most suitable for the requirements. From this, the number of APs needed and where they should be located can be approximated. Next, the correct channel selections for each AP should be determined to provide the maximum throughput possible with minimal co-channel interference. Finally, testing of the APs and user feedback should be used to fine-tune the location and configuration of the APs

6.2 Choosing the 802.11 Network Type

For owners of existing 802.11b Wi-Fi equipment, 802.11g promises to provide a smooth migration path to higher data rates. Since it uses the same 2.4GHz band and is backward-compatible with 802.11b, it has several benefits:

• Many vendors will be able to offer firmware and software upgrades to their existing devices

• Users with ‘legacy’ 802.11b cards will be able to use new 802.11g APs

• A new site-survey is not necessary

Thus, network managers can install new 802.11g access points in their existing 802.11b-based networks without affecting existing users. However, there are a couple of issues worth noting. The first is that, like 802.11b, 802.11g can use only three non-overlapping channels, making it difficult to avoid interference for medium to large WLANs. The second issue is that when an 802.11b device associates with an 802.11g AP the throughput for all the 802.11g clients also associated with that AP will be reduced. This is due to the relatively longer transmission times between the AP and the 802.11b client compared to that of the 802.11g clients. Once an 802.11b station associates with an 802.11g AP, realistic 802.11g transmission speeds fall from about 23Mbps to about 14Mbps - even if the 802.11b station is not transmitting. 802.11g networks slow down because they are designed to automatically go into protected mode in the presence of 802.11b stations. A special CTS (clear-to-send) header is appended to 802.11g frames so that 802.11b stations can detect and avoid collisions with 802.11g traffic; but this clutters up the network with additional overhead.

Alternatively, 802.11a offers higher data rates and more non-overlapping channels than 802.11b thus, giving potential for fewer APs for a given level of throughput. For network designers, this means that it will be easier to design 802.11a WLANs that avoid interference because at least 19 non-overlapping 5 GHz channels have been freed up for global use. However, RF coverage range is less than with 802.11b so this advantage is

63


alleviated slightly (i.e. more APs are needed for a given amount of RF coverage desired). Perhaps more importantly, the different ranges and frequency band that is used will require a site survey to determine the optimal number and positioning of APs according to network requirements. For an entirely new wireless network deployment, this is not really a problem as a site survey for whichever 802.11 type would be necessary anyway. However, for existing 802.11b based wireless networks, upgrading to 802.11a will almost certainly require existing (upgraded) APs to be moved and possibly new APs to be added if anywhere near optimal deployment is desired.

802.11a devices are generally more expensive than 802.11b but this will most likely change as more products are shipped. The incompatibility feature can be alleviated somewhat by deploying dual a/b devices and APs that many vendors are making available. Users with dual a/b cards will be able to associate with either type of AP depending on what is available. Similarly, dual APs can be configured to offer whichever of 802.11a/b according to the nature of the user base. Furthermore, products designed for use in North America and Canada (under FCC regulations) will eventually work in Europe and other parts of the world. Until the recent decisions from the WRC, the global 5 GHz spectrum allocation has been diverse, making consistency of 802.11a product design and usage inherently difficult.

The decision as to which WLAN type is to be used is based on the network requirements of the organisation and roughly comprises: area coverage, data capacity, and any existing network/user infrastructure. Of course, a/b/g WLAN types can be used to complement each other. For example, 802.11b can be used for blanket coverage with 802.11a used in areas where higher throughput is required.

6.3 Calculating the Number of Access Points

Depending on the requirements of the wireless network, a designer can plan for either maximum RF coverage or for maximum data capacity (throughput). Obviously, planning for maximum throughput will require a greater number of access points. If the required data capacity of the network is anticipated to be low compared to the achievable data rate of the network type (e.g. <5Mbps in 802.11b environment), the network designer can simply use a single AP to cover each cell. Conversely, maximising data capacity will require multiple APs in each ‘cell’ according to how many non-overlapping channels are available.

Designing simply for coverage one can simply set the radio on each AP to maximum to widen the signal’s reach. Yet, designing simply for coverage will often not provide users with an acceptable level of throughput (due to low signal quality) except in the most basic of circumstances. Instead, it is more beneficial to have smaller cell sizes (microcells) by reducing the power of the AP RF transmissions, although more APs are needed for a given coverage area. Such microcells increase overall network throughput because they share more bandwidth amongst relatively fewer stations. However, the network designer must be careful to plan the channel assignments so the there is no co-channel interference.

6.4 Management of Access Points

Most inter-AP management protocols are proprietary in that they will only work with APs from the same vendor. Currently, there is no standard inter-AP management protocol that will allow the management of multiple APs from arbitrary vendors. This means that a network designer must either 1) deploy APs from the same vendor and use a proprietary AP management protocol or 2) deploy heterogeneous APs and have to manually configure and manage them according to the network’s requirements. In light of this, recent effort in the IEEE (the 802.11f task force) has concentrated on the standardisation of a protocol to achieve multi-vendor interoperability of APs across a distribution system.

In addition, at the recent IETF 57 meeting in Vienna, there was a proposal to form an AP management working group called capwap (Control And Provisioning of Wireless Access Points) which would take the ‘Lightweight Access Point Protocol’ (LWAPP) from the seamoby working group as a starting point. The majority of the attendees voted in favour of forming the working group.

64


6.4.1 802.11f / IAPP The IEEE P802.11 specification details the MAC and PHY layers of a Wireless LAN system and includes the basic architecture of these systems, including the concepts of Access Points and distribution systems. Since there are many ways to create a WLAN network, the precise implementation of APs and distribution systems was not included in the specification. Furthermore, many of these implementation possibilities require concepts from higher layer entities and, as such, were considered out of scope for 802.11.

The drawback with this is that AP devices from different vendors are unlikely to inter-operate across a distribution system because of the different approaches taken to the design of the distribution system. Although 802.11 based systems have grown in popularity, this limitation is a direct impediment to the design and implementation of medium and large scale WLAN networks.

To address this problem, the IEEE 802.11f task group came up with the Inter-Access Point Protocol (IAPP) [61], which specifies the necessary information that needs to be exchanged between APs to support the 802.11 distribution system functions. The IAPP has been developed primarily for the environment of a distribution system consisting of IEEE 802 LAN components that are running IP; although other environments can be supported.

The IAPP specification is a “recommended practice” document that aims to achieve radio AP interoperability within a multi-vendor WLAN network. The specification defines the registration of APs within a network and also the interchange of information between APs points when a user/mobile station moves from one AP to another (handoff). Thus IAPP will help with fast hand-off from AP to AP with a distribution system.

IAPP packets can be carried in TCP or UDP and the Remote Authentication Dial-in User Service (RADIUS) is used so APs can obtain information about one another. In particular, an IAPP entity must be able to use a RADIUS server to discover the IP address of another AP in the ESS when given its BSSIDs. Also, an IAPP entity will use a RADIUS server to obtain security information to protect the content of certain IAPP packets. The IAPP is most likely to be implemented by APs, although other network devices such as bridges and switches may also be affected.

The APs function much the same as 802.1D bridges; the IAPP also support the following functions:

• distribution system services (as defined in ISO/IEC 8802-11:1999)

• mapping of AP MAC addresses to network layer (IP) addresses

• formation of a distribution system

• maintenance of a distribution system

• enforcement of the restriction that a station may only associate with one AP at any given time

• transfer of station context information between APs

6.4.2 LWAPP and CAPWAP As part of the seamboy (seamless mobility) IETF working group, there is work in progress to design a protocol that allows a router or switch to control and manage a group of APs in an interoperable fashion [61]. Although the intention is for this protocol to be layer 2 independent, the main focus is on an 802.11 binding. This Light Weight Access Point Protocol (LWAPP) is meant to provide a common way for wireless WLAN switches to communicate with any vendor's radio infrastructure. The aim is to allow for the decoupling of radio systems (i.e. the PHY and MAC functionality of an 802.11 AP) from their management systems. This will provide the flexibility to choose 802.11 radios from multiple vendors while being able to choose a centralised wireless configuration/security/management/monitoring system from another vendor. The protocol is being backed by several WLAN switch vendors such as Airespace, DoCoMo USA Labs and Legra Systems. In theory, different brands of WLAN switches and APs will be able to communicate over the

65


LAN making it possible to select any combination of 802.11 APs and switches while still being able to manage and control the network.

In such architecture, the APs are ‘lightweight’ in that they contain little or nothing else other than the 802.11 functionality. One analogy would be that 802.11 APs become like “disposable light bulbs” in that they can be swapped in and out without changing the operation of the wireless network.

Although it does not define specific management features, the LWAPP specification describes a common way for the two network entities (radio and management) to communicate. This effort has emerged, in part, because the thin access point (AP)/wireless switch architecture (which moves some, if not all, smarts from the infrastructure radios into a centralized controller) didn't exist at the time that 802.11 standards were created. Similarly, several of the functions (such as SNMP and DHCP) specified in LWAPP encroach on the Layer 3 services area; thus, the involvement of the IETF rather than the IEEE.

Although LWAPP is focused on 802.11 WLANs, a superset of the effort dubbed the ‘Control and Access Provisioning of Wireless Access Points’ (aka ‘capwap’) can be applied to any wireless network such as short-range, high-speed ultrawideband wireless networks and the emerging 802.16a and 802.16e standards for fixed and mobile metro-area wireless networking. At the 57th IETF meeting in Vienna, members voted in favour of creating a working group called capwap to address this very issue.

The main LWAPP and CAPWAP features include:

- independent of the wireless link type

- acquisition of APs by the management entity

- automatic discovery of the management entity

- configuration and management of the wireless link by the management entity

- control of AP host load

- security for LWAPP/CAPWAP signalling

- no changes to the 802.11 MAC

The AP and switch vendors that are adding wireless support into their existing product lines, should eventually include code for the LWAPP protocol in their products. Although the IETF ratification process could last well into 2004 (the target is to standardise within 12 months), vendors may begin to introduce early versions of LWAPP, or parts of it much earlier.

66


7 Working with IPv6 / Mobile IPv6

7.1 Host Configuration

When introducing an IPv6 host into a wireless network, the host must be able to obtain the necessary information to configure itself for network operation. In theory, this should not be too different in a wireless LAN than it would be in a wired LAN. If the WLAN APs are implemented as simple layer 2 devices, they take on a role analogous to Ethernet switches in a wired network.

In this way, IPv6 hosts can configure themselves via the usual methods of stateful address autoconfiguration using DHCPv6 [62] or stateless address autoconfiguration using Router Advertisements (RAs) and Neighbour Discovery [62],[63]). Both the stateless and stateful autoconfiguration methods provide a way for a fixed or mobile IPv6 host to autoconfigure itself with one or more IPv6 addresses, default gateway and other parameters.

Although present in DHCPv6, there is currently no DNS option in RAs. Since the availability of a DNS server is crucial for the support of Internet services such web, email and file transfer in all realistic network environments, RAs must be supplemented with DHCPv6 or static configuration in order for IPv6 hosts to obtain the address for their local DNS server.

Currently, there is some effort in the IETF to standardise a DNS discovery mechanism based on RAs which will remove this requirement [64]. This DNS discovery mechanism introduces two new RA options in Neighbour Discovery: the DNS Server option and the DNS Zone Suffix option. The DNS Server option contains the IPv6 address of the (recursive) DNS server and the DNS Zone Suffix option contains the suffix of the DNS zone where the subnet is located.

There is a general tradeoff between ‘lightweight’ and ‘heavyweight’ APs. In lightweight APs, there is little more than the 802.11 functionality inside the AP. Therefore, all higher layer functionality such as IPv6 routing, DHCPv6, Home Agent, RADIUS, SNMP etc. must be deployed elsewhere in the network, generally by the Access Router and the fixed network behind it. Conversely, heavyweight APs may contain some or all of these higher layer functions thus reducing the need for separate dedicated devices in the network. At the time of writing there are few APs available that contain such higher layer IPv6 features like DHCPv6 or MIPv6 Home Agent functionality. As mentioned earlier, deploying such heavyweight APs can make network configuration and management extremely laborious if they are from heterogeneous vendors. Hence, the trend towards lightweight APs using a common protocol to talk with a centralised management entity that controls the higher layer functions.

7.2 Subnetting and Addressing

A significant part of designing an IPv6 network (wired or wireless) is the subnetting and addressing plan. In wireless networks, IPv6 routing is rarely, if ever, available on the APs. Therefore, the ratio of APs per Access Router (AR) will greatly influence the subnetting and addressing plan (and vice versa). One extreme is to have an AR for every AP in the WLAN (or possibly using separate interfaces of the same router). Each WLAN cell will comprise a separate subnet and will receive separate IPv6 prefixes in RAs than other WLAN cells. This has the advantage that because the wireless cells are routed rather than bridged, there is considerably less broadcast traffic cluttering up the wireless link. This may be an important consideration when maximising available bandwidth is paramount. There is also an argument that if access control is enforced at each AR, this distributes the load of access control throughout the network.

67


However, this method is probably too costly in terms of router deployment for the general case. Of course, the other extreme is to have the entire WLAN hanging off one interface of the AR. Thus, all the WLAN cells belong to the same IPv6 subnet and receive the same IPv6 prefix in RAs. Depending on the size of the WLAN, this may or may not be a reasonable solution. Certainly, for small WLANs the overhead of broadcast traffic is not too severe and it is generally manageable; but for larger WLANs or where there are logical separations in the WLAN (e.g. different departments needing their own IPv6 subnets), separate routers (or separate interfaces on the same router) will be necessary. Note than in IPv6, broadcast traffic can be quite significant in large WLANs due to Neighbour Discovery and Router Advertisements.

Common practice would seem to be to assign a /64 prefix to each WLAN regardless of the ratio of APs to the AR. Unless some of the APs are ‘heavyweight’ and can participate in IPv6 routing, all the APs served by an AR interface should be seen as a logical link from the IPv6 point of view and thus should not be further subnetted (hence, no less than a /64). Thus, it is wise for network managers not to assign specific IPv6 subnets for a ‘WLAN testbed’ since this does not allow for the wireless network to cover departmental boundaries and the addressing can quickly become unsuitable as the wireless infrastructure grows. Instead, subnet and addressing policies should be governed by the needs of the organisation, not the link type.

7.3 DAD considerations

As part of the autoconfiguration process, each IPv6 node must perform duplicate address detection (DAD) when generating its IPv6 address. In general, a host’s IPv6 address is generated by concatenating a 64 bit interface identifier (based on its 48/64 bit MAC address) onto a 64 bit network prefix. Therefore, address duplication is most likely to occur when two hosts on the same link both own the same MAC address1.

If an IPv6 node detects address duplication when receiving a Neighbour Advertisement message from another node, the duplicated address must not be used for this IPv6 node and the node must generate its own address by another mechanism such as random Interface ID generation.

However, in 802.11 networks some inconsistency with DAD has been noted in [65]. If an IPv6 node in an 802.11 WLAN has the same MAC address as another node, it will not be detected using normal DAD.

This is due to the 802.11 MAC protocol, which stipulates that broadcast frames should be discarded by the originating station. If an IPv6 node in an 802.11 WLAN receives a broadcast frame whose source MAC address matches its own MAC address, the 802.11 MAC logic will discard the frame without it ever reaching the IPv6 layer inside the node. Thus, IPv6 DAD will not be able to detect a duplicate address in an 802.11 WLAN because the broadcast frame (which is what Neighbour Discovery uses) from the duplicated node will be discarded by the receiving node’s 802.11 MAC logic.

Therefore, IPv6 DAD will always succeed in an 802.11 WLAN even though there may be two hosts owning the same MAC address.

Note that this is inconsistent with the RFC on IPv6 Stateless Address Autoconfiguration.

Appendix A of RFC 2462 [63]:

“To perform Duplicate Address Detection correctly in the case where two interfaces are using the same link-layer address, an implementation MUST have a good understanding of the interface's multicast loopback semantics, and the interface cannot discard received packets simply because the source link-layer address is the same as the interfaces.

This particular problem can be avoided by temporarily disabling the software suppression of loopbacks while a node performs Duplicate Address Detection.”

1 In theory this should not occur since but it is possible for MAC addresses to be ‘spoofed’ or configured incorrectly.

68


Two possible solutions are described in [65], but they involve either the filtering or ignoring of broadcast frames at the 802.11 MAC. However, these solutions are possible with many of today’s 802.11 client NICs and APs.

69


8 Available Hardware and Software Over the last few years, hardware and software for the deployment of 802.11 WLANs has become readily available. The 802.11b market is already competitive enough that 802.11b WLAN deployment has become cost-effective enough to be a serious alternative to wired networks for both enterprise and SOHO networks.

The recent introduction of the high-rate 802.11a and 802.11g standards has not only seen the proliferation of associated single-mode devices, but also the emergence multi-mode devices that can operate at more than one 802.11 mode. The chipmaker Atheros Communications1 has recently introduced tri-mode chipsets with combined 802.11a/b/g support coupled with Advanced Encryption Standard (AES) hardware support for compliance with the forthcoming 802.11i security standard.

Cavium Networks2 has announced a new range of security processors for Wireless LAN applications and protocols. Cavium's NITROX Wireless Security Processors are designed to make it easier for equipment manufacturers to introduce support for emerging 802.11 security standards, such as Wi-Fi Protected Access (WPA) and 802.11i. For 802.11i, WLAN APs and NICs will benefit from security acceleration in hardware to achieve required performance, which is what Cavium's NITROX Wireless Processors aim to achieve. The WPA security specification is a cut-down version of what will become 802.11i and is beginning to make its way into 802.11 products. 802.11i is due to be ratified as a standard by the IEEE some time in 2004. Aruba Wireless Networks, a manufacturer of high-performance WLAN switching systems for enterprises and wireless ISPs , is the first company to publicly commit to Cavium's wireless technology.

There are now numerous available multimode 802.11 APs and client NICs available. Some are available as dualmode3 (e.g. 802.11b/a or 802.11b/g) or tri-mode (802.11b/a/g). Some examples of multimode 802.11 client NICs and their associated features are listed in Table 15. Table 16 lists some available multimode 802.11 APs and their associated features.

Product 802.11 modes

OS support Driver/client features

Security features

D-Link AirXpert ABG DWL-AG520 and DWL-AG650

b, a, g Windows 95/98/2000/ XP

Site survey tool, profile management, AP

scanning, link status meter, NIC diagnostics,

performance measurement utility

40 and 128-bit WEP, 802.1x, AES hardware

capable

D-Link AirPlus Xtreme G DWL-G520 and DWL-

G650

b, g Windows 95/98/2000/ XP


scanning, link status meter, NIC diagnostics,


40 and 128-bit WEP, 802.1x

Enterasys RoamAbout R2

b, a Windows 95/98/2000/ XP,

Linux, Mac, Pocket PC, Palm OS 4.x or

5.x

Site survey tool, profile management, firmware upgrade, AP scanning, link status meter, NIC

diagnostics,

40 and 128-bit WEP, 802.1x, AES hardware

capable

1 http://www.atheros.com 2 http://www.cavium.com 3 Dual-mode is not necessarily the same as ‘dual-band’, which refers to a device capable of operating on two different wavebands (e.g. a device capable of operating at 2.4GHz and 5Ghz would be dual-band).

70

http://www.atheros.com/

http://www.cavium.com/



Linksys Wireless-G WMP54G

b, g Windows 98/ME/2000/XP

Site survey tool, profile management, firmware

upgrade, link status meter, radio transmit

power control

40 and 128-bit WEP, AES hardware-capable

Linksys Dual-Band Wireless A+G WMP55AG

b, a, g Windows 98/ME/2000/XP

Site survey tool, profile management, firmware

upgrade, link status meter, radio transmit

power control

40 and 128-bit WEP, AES hardware-capable

Netgear WAG511 802.11a+g Dual-

Band Wireless PC Card

b, a, g Windows 95/98/ME/2000/ XP

Link status meter, NIC diagnostics

40 and 128-bit WEP

Netgear WAB501 802.11a+b Dual-Band Wireless

Adapter

b, a Windows 95/98/ME/2000/ XP

Site survey tool, link status meter, radio

transmit power control

40 and 128-bit WEP

Proxim Orinoco 11a/b/g ComboCard

b, a, g Windows 95/98/ME/2000/ XP


scanning, link status meter, radio transmit power control, NIC

diagnostics, performance

measurement utility

40 and 128-bit WEP, 802.1x, Cisco LEAP, AES

hardware-capable

Proxim Orinoco 11a/b ComboCard

b, a Windows 95/98/ME/2000/ XP

Profile management, AP scanning, link status meter, radio transmit power control, NIC


measurement utility

40 and 128-bit WEP, 802.1x, Cisco LEAP, AES

hardware-capable

SMC2336W-AG b, a, g Windows 95/98/2000/ XP


scanning, link status meter, radio transmit power control, NIC


measurement utility

40, 128 and 152-bit WEP, 802.1x, AES hardware-

capable

Table 15 Multimode NICs and associated features

71


Product 802.11

modes

Network Features Config and Management

Features

Security Features

3Com Wireless LAN AP 8200

b, a DHCP server, Power over Ethernet, radio

transmit power control.

HTTP, SNMP, TFTP 40 and 128-bit WEP, MAC address

filtering, 802.1x

3Com Wireless LAN AP 8500 and AP

8700

b, a, a* DHCP server, Power over Ethernet, VLAN tagging, Mobile IP,

radio transmit power control.

serial port, HTTP, SNMP, TFTP

40, 128 and 154-bit WEP, MAC address

filtering, 802.1x

D-Link AirPlus Xtreme G DWL-

2000AP High-Speed 2.4GHz Wireless AP

b, g DHCP server, PoE, radio transmit power

control

HTTP, central management console

for multiple APs

40 and 128-bit WEP, MAC address

filtering

D-Link AirPro DWL-6000AP

b, a DHCP server, PoE HTTP, central management console

for multiple APs


filtering, 802.1x

D-Link AirXpert DWL-7000AP

b, a, g DHCP server, PoE, radio transmit power

control

HTTP, central management console

for multiple APs


filtering, 802.1x

Enterasys RoamAbout R2

b, a, g DHCP server, broadcast and

multicast filters, protocol filtering,

PoE, Class of Service, Mobile IP

serial port, Telnet, HTTP, SNMP, TFTP, central

management console for multiple APs


filtering, 802.1x, integrated VPN

termination

Intermec MobileLAN access WA21 and

WA22

b, a DHCP server, broadcast and

multicast filters, protocol filtering,

PoE, VLAN tagging, Class of Service

Telnet, HTTP, TFTP, central management console for multiple

APs


filtering, 802.1x

Netgear WAB102 b, a DHCP server HTTP 40 and 128-bit WEP, MAC address

filtering

Proxim Orinoco AP-600, AP-2000 and

AP-2500

b, a, g DHCP server, broadcast and

multicast filtering, protocol filtering,

PoE, VLAN tagging, Class of Service,

radio transmit power control

serial port, Telnet, HTTP, SNMP, TFTP, central

management console for multiple APs


filtering, 802.1x

Table 16 Multimode APs and associated features * = 802.11a Turbo Mode, a proprietary scheme with theoretical data rates of 108Mbps

72


8.1 IPv6 capable Access Points

At present there are no commercial off the shelf 802.11 APs that support native IPv6. Most, if not all available APs will allow IPv6 traffic to pass through (after all the AP is essentially a L2 device) but they contain no IPv6 intelligence and are only aware of the IPv4 world.

More specifically there is no native IPv6 support for:

• Neighbour Discovery

• Router Advertisements (for APs that perform routing)

• DHCP

• HTTP server (for configuration and administration tasks)

• RADIUS

In theory, it is quite possible to deploy an IPv6 WLAN without having any IPv6 intelligence inside the APs. In this way, the APs are strictly L2 devices. Thus, all L3 intelligence must be provided elsewhere on the LAN (RAs, DHCP, NTP etc.) However, configuration and management of the APs over the network must still use IPv4, therefore an IPv4 infrastructure must exist, precluding the opportunity of IPv6-only WLAN deployment.

Although the commercial WLAN market is still lagging behind with respect to IPv6 support, it is possible to custom build an IPv6-only AP.

This can be achieved in two ways:

1. Upgrade the firmware of a commercial AP with compatible GPL firmware with IPv6 support compiled in.

2. Custom build a PC-based AP using open source software with IPv6 support compiled in.

8.1.1 Linksys Access Points The best example of the first approach is to upgrade an AP from Linksys. Some APs within the Linksys range run the Linux Operating System and can be flashed with GPL firmware that has had IPv6 support compiled in. Probably the most commonly upgraded Linksys AP is the WRT54G (which is also a DSL router) although there are other models that can have their firmware upgraded to support IPv6. Linksys offers the source code to all of its GPL firmware images at its website [74].

An alternative method for upgrading Linksys APs with custom built firmware can also be found at the OpenWRT website [75].

8.1.2 OpenAP Another choice for upgrading the firmware of a commercial AP with one of a custom built variety can be found in the OpenAP undertaking [76].

OpenAP is a complete distribution of open-source software that enables one to build a fully 802.11b compliant wireless access point. an interesting feature of an OpenAP access point is the ability to perform multipoint to multipoint wireless bridging, while simultaneously serving 802.11b stations.

The OpenAP website contains the complete source code, build environment, and instructions for flashing a commercial 802.11 access point with the Linux 2.4.17 kernel. The end product is a Linux-based AP providing full wireless services. Since the OpenAP source code is available, the AP can be custom built.

73


Thus it can be programmed to perform anything that Linux can do (within the memory constraints of the actual AP hardware) such as IPv6 routing, DHCPv6, HTTP server, IPv6 capable RADIUS, VPN etc.).

Obviously the OpenAP distribution will not work with just any commercial AP and in fact only a handful of commercial APs are compatible with the OpenAP distribution. Any AP based on the Eumitcom WL11000SA-N board should work with a custom built OpenAP distribution. Commercial APs based on this board include:

• US Robotics (USR 2450)

• SMC 2652W EZconnect Wireless AP

• Addtron AWS-100

8.1.3 HostAP HostAP [ref] is a Linux driver for WLAN cards that are based on the Intersils Prism2/2.5/3 chipset. The driver supports a Host AP mode. Essentially this mode allows a Linux host computer to act as an AP by taking care of all the 802.11 MAC management functions.

This is possible because the station firmware for Intersil Prism2 chipsets supports a so called Host AP mode. In this mode, the firmware takes care of time critical tasks such as beacon sending and frame acknowledgement, but leaves management tasks to host computer driver.

The combination of the HostAP driver and the HostAP daemon provides additional features. These include support for IEEE 802.1x and dynamic WEP re-keying, RADIUS, minimal IAPP (IEEE 802.11f), WPA, IEEE 802.11i/RSN/WPA2. Furthermore, since the host computer is a Linux OS, it is possible to compile in support for IPv6-specific features.

TNO Telecom have ported HostAP to work with IPv6. However, this was only a small scale project looking at 802.1x in an IPv6 environment so the port only consisted of modifying the HostAP daemon to send/receive RADIUS messages over IPv6 [78].

8.2 IPv6 Support in RADIUS Implementations

RADIUS is an important element in securing a WLAN. It can be used as the authentication backend for a variety of authentication methods including 802.1x and web-based redirection. Usually the RADIUS authentication requests will be between the NAS (e.g. an AP or L2 switch) and the RADIUS server (which may or may not have user credentials stored on the same host via e.g. an SQL database or LDAP) Thus to deploy an IPv6-only WLAN that employs RADIUS as an authentication backend, RADIUS server implementations that support native IPv6 are essential. Of course, the RADIUS client implementations on the NAS must also support native IPv6. We have seen in the previous section that this is currently a problem in commercial APs that may perform the role of a NAS. Furthermore, dedicated NAS commercial devices such as BlueSocket wireless gateways [ref] do not have native IPv6 support at the time of writing.

In terms of native IPv6 support for RADIUS there are essentially two features that must be supported.

1. Support for handling IPv6 information contained in RADIUS messages

2. Sending and receiving RADIUS messages over IPv6

At the time of writing only one RADIUS server implementation is know to be fully IPv6 capable. This RADIUS implementation is called Radiator [79] and is commercial software.

An open source RADIUS implementation called FreeRADIUS is available for Linux, FreeBSD, OpenBSD, OSF/Unix and Solaris platforms. The latest version, v1.0.1, is able to handle IPv6 information in RADIUS messages but it is not capable of sending/receiving RADIUS messages over IPv6.

74


9 UK Location Independent Networking Trials The UK Wireless Advisory Group (WAG) [69] was formed in May 2003, bringing together a wide range of expertise from across the JANET community to provide advice and guidance on wireless networking. One of the WAG activities was to make recommendations for a JANET Location Independent Networking (LIN) Trial Service [70].

This is a service where a guest user can authenticate from a visited organisation back to their home organisation. The visited organisation trusts the home organisation in its response to the authentication process so that if successful, the visited organisation will grant the guest user network access in accordance with its local site policy. Although the LIN Trial Service will serve roaming users utilising wired network access at visited institutions, the main focus of LIN is on wireless network access, especially 802.11 WLANs.

A LIN approach document was written and subsequently approved by the WAG. This document recommended that work be undertaken to build a National RADIUS Proxy Server (NRPS) hierarchy to support a LIN trial service as follows:

1. To test (with a small number of JANET organisations) the concept of a guest user being able to send their authentication credentials to their home organisation Authentication, Authorisation, Accounting (AAA) server to authenticate at home and then be granted network access by the visited organisation at that institution. This process must be scalable, secure and transparent to the guest user as is practically possible. The solution proposed is to utilise a RADIUS AAA back end in a proxy hierarchy structure to support secure web-based redirection roaming services, 802.1X with a variety of supported Extensible Authentication Protocol (EAP) authentication methods, Roamnode (developed at Bristol University) or other roaming services that rely on a RADIUS backend.

2. To conduct a national trial with a number of organisational level RADIUS proxy servers that would link to two national level RADIUS proxy servers via a RADIUS hierarchy to (1) assess the usability of RADIUS proxy server method at a variety of organisations, (2) assess the performance of service support mechanisms in support of the trial service and (3) assess the scalability of the RADIUS hardware and software.

3. When the national trial service is stable, to extend a link from the two national RADIUS proxy servers to a higher level (European level) RADIUS proxy server (hosted by SURFnet on behalf of TERENA). The link will establish an Inter-NREN (National Research and Education Network) roaming network that can be trialled to (1) assess the usability and scalability of the RADIUS hardware and software, (2) assess the performance of service support mechanisms and (3) identify any relevant policy issues for such a service.

4. To provide best practice and recommendations to JANET organisations and other NRENs in all areas related to LIN.

Members of the 6NET consortium, Lancaster University (ULANC) and the University of Southampton (UoS), are active members in the UK WAG and participated in the successful LIN proof of concept testing. Both ULANC and UoS have configured and located an Organisational RADIUS Proxy Server on the campus networks to be part of the LIN RADIUS hierarchy. They will both be prominent organisations in the LIN Trial Service. Moreover, ULANC and UoS will be spearheading the introduction of IPv6 into the LIN Trial Service.

The LIN proof of concept testing was completed at the end of August 2004 and the decision was made by the WAG to proceed to a full trial beginning in January 2005 to allow for the participation of other UK academic institutions. However the institutions involved in the proof of concept testing (illustrated in Figure 10) will be performing tests during the interim period.

75


ORPS

JANET

UK NRPS

Lancaster

ORPS

EdinburghORPS

Manchester

ORPS

Bristol

ORPS

Southampton

SURFNET

European LevelRadius Proxy Server

ORPS

Strathclyde

Figure 10 LIN Participants and Connection to ERPS

The LIN trial service will naturally complement the roaming services provided by other European NRENs1 via the RADIUS hierarchy implemented as a product of the TF Mobility work [71]. The UK NRPS on JANET is only one National RADIUS proxy in the hierarchy, peering with other NRENs via the Top level (European) RADIUS proxy hosted by SURFnet (see Figure 11).

1 See http://www.terena.nl/tech/task-forces/tf-mobility/eduroam/index.html

76

http://www.terena.nl/tech/task-forces/tf-mobility/eduroam/index.html


Top Level RADIUSProxy Server

National RADIUSProxy Server

OrganisationalRADIUS Proxy

ServerC




ServerD


ServerE


ServerF


ServerA


ServerB

Top levelforwarding

(.nl .de .uk etc)

National level forwarding(a.ac.uk b.ac.uk etc)

Figure 11 RADIUS Proxy Hierarchy

77


10 Conclusions It is clear that the popularity of 802.11 WLANs, coupled with well-documented security weaknesses in WEP, has lead to much thought on the problem of authentication, security and privacy in 802.11 WLANs.

At the time of writing, it is debatable whether there is a definite solution that can meet all requirements. Much depends on the nature of the WLAN, who the users are, the movement of the users, data sensitivity and other network conditions. From the material presented in chapter three, one can see that there are many security solutions to choose from, but there is no commonly accepted solution; at least, not yet. The 802.11i task force promises to bring about such a common solution although in some sense this can be misleading as it is really the use of EAP that makes it so flexible. Probably the most fool-proof security architecture will involve 802.1x and AES under the 802.11i umbrella.

A ‘one size fits all solution’ security solution may not be possible yet (if ever), although it is possible for any WLAN to be made secure provided that the security solution is designed to closely match the network requirements. Of course, there is a trade-off between security and management overhead. In theory combining authentication, encryption and certificates into a security solution should provide all the protection required. However, creating, distributing and maintaining certificates for users is not always a practical way of operating a network. Furthermore, there is a direct trade-off with security mechanisms and network performance. Encrypting and decrypting packets is a costly operation for network devices and usually requires hardware support for commercial networks. It is also a direct hindrance to user roaming in a real-time context. Having to authenticate via whichever security solution is implemented will use up valuable milliseconds, if not seconds, resulting in unacceptable delay and lost packets.

Therefore, it is more prudent to apply security solutions to fit the network usage. What is the main use WLAN? For example, a relatively open and insensitive WLAN can implement no or simple authentication, coupled with no encryption, or encryption via WEP. This might be reasonable for a free and public WLAN hotspot where there is little interest in authenticating users and if data sensitivity is required, it is up to the user to implement their own solution (e.g. an IPSec VPN connection). However, this would not suffice for an enterprise or commercial WLAN where authenticating users is imperative and sensitive data needs to be protected.

Thus, the applicability of security mechanisms to the wireless network in question must be considered. E.g.:

• Enterprise WLAN for corporate users

o this type has the most stringent requirements

o need secure access control and authentication of users

should use certificates

no unauthorised access

o privacy of data essential

need strong encryption (not standard WEP) for all users

o could use ‘temporary’ certificates or accounts for trusted visitors

• Campus based WLAN for students and staff.

o need authorisation and access control for registered students and staff

PKI is a possibility

but must be simple for users

o need to cater for visiting students and staff

78


roaming agreements?

temporary accounts?

restricted open access (web and email)?

o privacy of data could be important for many users

strong encryption according to user type

o accounting usually not needed but could be by some institutions

• Commercial Public WLAN

o public access but need to authenticate paying users

don’t care who as long as they pay (have paid)?

must be simple for users

o will need to grant access to ‘visitors’ from roaming agreements

o data sensitivity unknown

provider could offer default encryption level (e.g. 128 bit WEP)

users with sensitive data should use their own solution

o accounting backend linked to authentication servers and access routers

• Community Public WLAN

o free public access

no authorisation or access control?

depends on usage policy

o could have default WEP encryption

users with sensitive data should use the own solution

• Small Office / Home Network

o probably little need for access control

MAC address filtering may suffice

o encryption needs depends on use

office: default WEP or stronger

home: nothing or default WEP

79


References

[1] Geir, Jim, “Wireless LANs”, Second Edition, SAMS Publishing 2002.

[2] Schiller, Jochen, “Mobile Communicatons”, Addison Wesley, 2000.

[3] Stallings, William, “Wireless Comunications and Networks”, Prentice Hall, 2002.

[4] Intersil, “Wireless and Related Network Standards and Organizations”, 2001.

[5] M. Stemm, R.H. Katz, “Vertical Handoffs in Wireless Overlay Networks”, ACM Mobile Networking (MONET), 1997.

[6] T.S. Rappaport, “Wireless Communications – Principles and Practice”, Prentice Hall Publishings, 1996.

[7] LAN MAN Standards Committee of the IEEE Computer Society, “Wireless LAN medium access control (MAC) and physical layer (PHY) specifications”, IEEE Standard 802.11, 1999.

[8] Nokia, “General Packet Radio Service – GPRS – Nokia’s vision for a service platform supporting packet switched applications”, White Paper 1998.

[9] D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6” draft-ietf-mobileip-ipv6-24.txt, IETF Internet Draft, July 2003, work in progress.

[10] J. R. Walker, “Unsafe at any key size; An analysis of the WEP encapsulation”, IEEE document 802.11-00/362, October 27, 2000.

[11] S. Fluhrer, I. Mantin, and A. Shamir, “Weaknesses in the Key Scheduling Algorithm of RC4”, (undated, published in August 2001), presented at the Eighth Annual Workshop on Selected Areas in Cryptography (SAC 2001), Toronto, Canada, (August 16-17, 2001).

[12] A. Stubblefield, J. Ioannidis, and A. D. Rubin, “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP”, AT&T Labs Technical Report TD-4ZCPZZ, Revision 2, August 21, 2001.

[13] L. Blunk, J. Vollbrecht, “PPP Extensible Authentication Protocol (EAP)”, IETF RFC 2284, March 1998.

[14] C. Rigney, A. Rubens, W. Simpson, and S. Willens, “Remote Authentication Dial In User Service (RADIUS)”, IETF RFC 2138, April 1997.

[15] W. A. Arbaugh and A. Mishra, “An Initial Security Analysis of the IEEE 802.1x Standard“, CS-TR-4328, UMIACS-TR-2002-10, 6 February 2002.

[16] J. Walker, “Key Management for WEP and TKIP”, Intel, 802.11 Key Management Series: Part I (http://cedar.intel.com/media/pdf/wireless/80211_1.pdf).

[17] J. Walker, “The Temporal Key Integrity Protocol (TKIP)”, Intel, 802.11 Security Series: Part II (http://cedar.intel.com/media/pdf/security/80211_part2.pdf).

[18] S. Baily, “Is IEEE 802.1x Ready for General Deployment?”, GSEC Version 1.3, April 7, 2002.

[19] A. Palekar, D. Simon, G. Zorn, S. Josefsson, “Proptected EAP Protocol (PEAP)”, IETF Internet Draft draft-josefsson-pppext-eap-tls-eap-06.txt, March 2003.

[20] B. Aboba, D. Simon, “PPP EAP TLS Authentication Protocol”, IETF RFC 2716, October 1999.

[21] L. Salgarelli, Editor, “EAP SKE authentication and key exchange protocol”, IETF draft-salgarelli-pppext-eap-ske-02, November 1, 2002.

80


[22] P. Funk, S. Blake-Wilson, “EAP Tunneled TLS Authentication Protocol (EAP-TTLS)”, IETF draft-ietf-pppext-eap-ttls-02, November 2002.

[23] P. Funk , “The EAP MD5-Tunneled Authentication Protocol (EAP-MD5-Tunneled)”, IETF draft-funk-eap-md5-tunneled-00, March 2003.

[24] H. Haverinen (editor), J. Salowey (editor), “EAP SIM “, IETF draft-haverinen-pppext-eap-sim-10, February 2003.

[25] B. Aboba, “The Network Access Identifier”, IETF RFC 2486, January 1999

[26] H. Krawczyk, M. Bellare, R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, IETF RFC 2104, February 1997.

[27] B. Kaliski, J. Staddon, “PKCS #1: RSA Crytogrpahy Specifications”, IETF RFC 2437, October 1998.

[28] S. Kent, R. Atkinson, “Security Architecture for the Internet Protocol”, IETF RFC 2401.

[29] S. Kent, R. Atkinson, “IP Authentication Header,” IETF RFC 2402, November 1998.

[30] S. Kent, R. Atkinson, “IP Encapsulating Security Payload (ESP),” IETF RFC 2406, November 1998.

[31] Steven M. Bellovin, “Problem Areas for the IP Security Protocols,” Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.

[32] C. Rigney, A. Rubens, W. Simpson, S. Willens, “Remote Authentication Dial In User Service (RADIUS),” IETF RFC 2865, June 2000.

[33] W. Simpson, “The Point-to-Point Protocol (PPP),” IETF RFC 1661, STD 51, July 1994.

[34] J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, “Context Transfer Protocol”, IETF Internet Draft draft-ietf-seamoby-ctp-03.txt, June 2003

[35] W. Arbaug, N. Shankar, Y.C.J. Wan, “Your 802.11 Wireless Network has no Clothes”, Technical Report, Department of Computer Science, University of Maryland, March 2001.

[36] D. Wheeler, R. Needham, “TEA: a Tiny Encryption Algorithm”, Technical Report, Computer Laboratory, Cambridge University, UK.

[37] R. Rivest, “The MD5 Message-Digest Algorithm”, IETF RFC 1321, April 1992.

[38] S. Schmid, J. Finney, A.C. Scott, W.D. Shepherd, “Component-based Active Network Architecture”, in Proceedings of 6th IEEE Symposium on Computers and Communications (ISCC ’01), Hammamet, Tunisia, July 2001.

[39] E. A. Napjus, “NetBar – Carnegie Mellon’s Solutions to Authenticated Access for Mobile Machines”, CMU White Paper, http://www.net.cmu.edu/docs/netbar.html

[40] D. L. Wasley, “Authenticating Aperiodic Connections to the Campus Network”, June 1996, http://www.ucop.edu/irc/wp/wpReports/wpr005/wp005_Wasley.html

[41] LAN MAN Standards Committee of the IEEE Computer Society, “Port Based Network Access Control”, IEEE Standard 802.1x, June 2001.

[42] E. Poger, M. Baker, “Secure Public Internet Access Handlers (SPINACH)”, in Proceedings of the USENIX Symposium on Internet Technologies and Systems, 1997.

[43] A. Miu, P. Bahl, “Dynamic Host Configuration for Managing Mobility between Public and Private Networks”, in Proceedings of the 3rd Usenix Internet Technical Symposium, San Francisco, March 2001.

[44] J. Finney, G. O’Shea, “Mobile 4-in-6: A Novel Mechanism for IPv4/v6 Transitioning”, in Proceedings of Interactive Distributed Multimedia Systems (IDMS ’01), Lancaster, UK, September 2001.

81

http://www.net.cmu.edu/docs/netbar.html

http://www.ucop.edu/irc/wp/wpReports/wpr005/wp005_Wasley.html


[45] A. Shacham,B., Monsour, R. Pereira, M. Thomas, “IP Payload Compression Protocol (IPComp)” IETF RFC 3173, September 2001.

[46] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, “Internet Security Association and Key Management Protocol (ISAKMP)”, IETF RFC 2408, November 1998.

[47] Orman, H., “The Oakley Key Determination Protocol,” IETF RFC 2412, November 1998.

[48] Krawczyk, H., “SKEME: A Versatile Secure Key Exchange Mechanism for Internet,” from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security.

[49] Piper, D., “The Internet IP Security Domain Of Interpretation for ISAKMP,” IETF RFC 2407, November 1998.

[50] Aboba, B. et al., “Criteria for Evaluating AAA Protocols for Network Access,” IETF RFC 2989, November 2000.

[51] Rigney, C., Willats W., Calhoun P., “RADIUS Extensions,” IETF RFC 2869, June 2000.

[52] Rigney, C., “RADIUS Accounting,” IETF RFC 2866, June 2000.

[53] B. Aboba, J. Arkko, D. Harrington. “Introduction to Accounting Management,” IETF RFC 2975, October 2000.

[54] B. Aboba, J. Wood, “Authentication, Authorization and Accounting (AAA) Transport Profile,” IETF RFC 3539, June 2003.

[55] B. Aboba, et. Al. “Review of Roaming Implementations,” IETF RFC 2194, September 1997.

[56] Aboba, Beadles “The Network Access Identifier,” IETF RFC 2486. January 1999.

[57] Aboba, B. and J. Vollbrecht, “Proxy Chaining and Policy Implementation in Roaming,“ IETF RFC 2607, June 1999.

[58] Pat R. Calhoun, Stephen Farrell, William Bulley, “Diameter CMS Security Application,“ IETF ID draft-ietf-aaa-diameter-cms-sec-04.txt, March 2002.

[59] T. Aura, P. Nikander, “Stateless Connections,” International Conference on Information and Communications Security ICICS'97, Beijing, November 1997, pp. 87-97.

[60] LAN MAN Standards Committee of the IEEE Computers Society, “Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation”, IEEE 802.11f, 2003.

[61] P. Calhoun, B. O’Hara, S. Kelly, R. Suri, D. Funato, M. Vakulenko, “Light Weight Access Point Protocol (LWAPP)”, IETF Internet Draft draft-calhoun-seamoby-lwapp-03.txt, June 2003.

[62] R. Droms, J. Bound, B. Volz, T. Lemon, C.Perkins, M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, IETF RFC 3315, July 2003

[63] T. Narten, E. Nordmark and W. Simpson, “Neighbour Discovery for IP version 6”, IETF RFC 2461, December 1998.

[64] S. Thomson and T. Narten, “IPv6 Stateless Address Autoconfiguration”, IETF RFC 2462, December 1998.

[65] J. Jeong, S. Park, L. Beloeil, S. Madanapalli, “IPv6 DNS Discovery based on Router Advertisement”, IETF Internet Draft draft-jeong-dnsop-ipv6-dns-discovery-00.txt, July 2003.

[66] S. Park, S. Madanapalli, O.L.N. Rao, “IPv6 DAD Consideration for 802.11 Environment”, IETF Internet Draft, draft-park-ipv6-dad-problem-wlan-00.txt, July 2003.

[67] c. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, IETF Internet Draft draft-ipsec-ikev2-16.txt, September 2004.

82


[68] B. Aboba, G. Zorn, D. Mitton, “RADIUS and IPv6”, IETF RFC 3162, August 2001.

[69] The UK Wireless Advisory Group Homepage, http://www.ja.net/development/network_access/wireless/wag/wag.html

[70] The UK Location Independent Networking Homepage, http://www.ja.net/development/network_access/lin.html

[71] TF Mobility Homepage, http://www.terena.nl/tech/task-forces/tf-mobility/

[72] United States Patent number 6,226,677

[73] Wi-Fi Networking News article, http://wifinetnews.com/archives/004184.html

[74] Linksys GPL firmware source code, http://www.linksys.com/support/gpl.asp

[75] OpenWRT Homepage, http://www.openwrt.org/

[76] OpenAP Homepage, http://opensource.instant802.com/

[77] HostAP Homepage, http://hostap.epitest.fi/

[78] O.J. Schuring, H. Schotanus, “802.1x Authentication in an IPv6 Environment”, TNO Telecom Report, April 2004.

[79] Radiator Homepage, http://www.open.com.au/radiator/index.html

[80] FreeRADIUS Homepage, http://www.freeradius.org/

83

http://www.ja.net/development/network_access/wireless/wag/wag.html

http://www.ja.net/development/network_access/lin.html

http://www.terena.nl/tech/task-forces/tf-mobility/

http://wifinetnews.com/archives/004184.html

http://www.linksys.com/support/gpl.asp

http://www.openwrt.org/

http://opensource.instant802.com/

http://hostap.epitest.fi/

http://www.open.com.au/radiator/index.html

http://www.freeradius.org/


Abbreviations

AAA Authentication, Authorization and Accounting

AP Access Point

ATM Asynchronous Transfer Mode

AVP Attribute Value Pair

CCK Complementary Code Keying

CHAP Challenge Handshake Authentication Protocol

DFS/TPC Dynamic Frequency Selection and Transmit Power Control

DHCP Dynamic Host Configuration Protocol

DoS Denial of Service

DSSS Direct Sequence Spread Spectrum

EAP Extensible Authentication Protocol

ETSI European Telecommunications Standardization Institute

FCC Federal Communications Commission

FHSS Frequency Hopping Spread Spectrum

FPK Fast Packet Keying

FTP File Transfer Protocol

GPL General Public Licence

HMAC Hashed Message Authentication Code

HTTP Hyper Text Transfer Protocol

ICV Integrity Check Value

IEEE Institute of Electrical and Electronic Engineers

IKE Internet Key Exchange

IPsec IP Security Protocol

IR Infrared

ITU International Telecommunications Union

IV Initialisation Vector

LAN Local Area Network

LIN Location Independent Networking

LMDS Local Multipoint Distribution Service

MAC Medium Access Control

MD5 Message Digest 5

MIC Message Integrity Check

MMAC-PC Multimedia Mobile Access Communications Systems Promotion Council

84


MMDS Multichannel Multipoint Distribution Service

NAI Network Access Identifier

NAS Network Access Server

NASREQ Network Access Server Requirements

NIC Network Interface Card

NREN National Research and Education Network

NRPS National Radius Proxy Server

OE Opportunistic Encryption

OFDM Orthogonal Frequency Division Multiplexing

ORPS Organisational Radius Proxy Server

PAN Personal Area Network

PAP Password Authentication Protocol

PBCC Packet Binary Convolution Coding

PEAP Protected EAP

PHY Physical Layer

PKI Public Key Infrastructure

POP Post Office Protocol

PPP Point-to-point Protocol

PSK Pre-Shared Key

QoS Quality of Service

RADIUS Remote Authentication Dial-In User Service

RF Radio Frequency

ROAMOPS Roaming Operations

SA Security Association

SCTP Stream Control Transmission Protocol

SKE Shared Key Exchange

SLIP Serial Line IP

SPI Security Parameter Index

SSH Secure Shell

SSID Service Set Identifiers

SSL Secure Socket Layer

TCP Transmission Control Protocol

TDM Time Division Multiplexing

TKIP Temporal Key Integrity Protocol

TLS Transport Layer Security

TTLS Tunnelled TLS

85


UDP User Datagram Protocol

UNII Unlicensed National Information Infrastructure

VPN Virtual Private Network

WAN Wide Area Network

WECA Wireless Ethernet Compatibility Alliance

WEP Wireline Equivalent Privacy

WEP2 The first enhancement to the WEP protocol

Wi-Fi Wireless Fidelity

WISP Wireless Internet Service Provider

WLAN Wireless Local Area Network

WLANA Wireless Local Area Networking Association

WPA Wi-Fi Protected Access

WPAN Wireless Personal Area Network

86


Glossary

Access Protocol

The access protocol defines the control message exchange between the nomadic node and the attendant. It essentially exchanges AVP-packed data that is used to build the AAA commands, which are further transferred between the involved AAA entities.

Accounting The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing or cost allocation.

Accounting Record An accounting record represents a summary of the resource consumption of a user over the entire session. Accounting servers creating the accounting record may do so by processing interim accounting events or accounting events from several devices serving the same user.

Attendant

Attendant denotes an IP router that controls the access of nomadic nodes to the network. Attendants terminate the Ipsec tunnels that protect the nomadic nodes’ traffic over the wireless link, and filters out all unauthorized traffic. They also implement the AAA client function.

Authentication The act of verifying the identity of an entity (subject).

Authorization The act of determining whether a requesting entity (subject) will be allowed access to a resource (object).

Attribute-Value-Pair

The Diameter protocol consists of a header followed by one or more Attribute-Value-Pairs. An AVP includes a header and is used to encapsulate protocol-specific data (e.g. routing information) as well as authentication, authorization or accounting information.

Broker A broker is a business term commonly used in AAA infrastructures. A broker is either a relay, proxy or redirect agent, and MAY be operated by roaming consortiums. Depending on the business model, a broker may either choose to deploy relay agents or proxy agents.

Diameter Agent A Diameter Agent is a Diameter node that provides either relay, proxy, redirect or translation services.

Diameter Client A Diameter Client is a device at the edge of the network that performs access control. An example of a Diameter client is a Network Access Server (NAS) or a Foreign Agent (FA).

Diameter Node A Diameter node is a host process that implements the Diameter protocol, and acts either as a Client, Agent or Server.

Diameter Peer A Diameter Peer is a Diameter Node to which a given Diameter Node has a direct transport connection.

Diameter Security Exchange

A Diameter Security Exchange is a process through which two Diameter nodes establish end-to-end security.

Diameter Server A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. By its very nature, a Diameter Server must support Diameter applications in addition to the base protocol.

Downstream Downstream is used to identify the direction of a particular Diameter message from the home server towards the access device.

87


End-to-End Security

TLS and Ipsec provide hop-by-hop security, or security across a transport connection. When relays or proxy are involved, this hop-by-hop security does not protect the entire Diameter user session. End-to-end security is security between two Diameter nodes, possibly communicating through Diameter Agents. This security protects the entire Diameter communications path from the originating Diameter node to the terminating Diameter node.

Home Realm A Home Realm is the administrative domain with which the user maintains an account relationship.

Interim Accounting An interim accounting message provides a snapshot of usage during a user’s session. It is typically implemented in order to provide for partial accounting of a user’s session in the case of a device reboot or other network problem prevents the reception of a session summary message or session record.

Local Realm A local realm is the administrative domain providing services to a user. An administrative domain MAY act as a local realm for certain users, while being a home realm for others.

Multi-Session A multi-session represents a logical linking of several sessions. Multi-sessions are tracked by using the Acct-Multi-Session-Id. An example of a multi-session would be a Multi-link PPP bundle. Each leg of the bundle would be a session while the entire bundle would be a multi-session.

NAS Network Access Server

Network Access Identifier

The Network Access Identifier, or NAI [56], is used in the Diameter protocol to extract a user’s identity and realm. The identity is used to identify the user during authentication and/or authorization, while the realm is used for message routing purposes.

Nomadic node

Nomadic node denotes an IP host fitted with a WLAN network adapter, which attaches to different access points located in administrative domains (subsequently denoted as „visited domains”) that may be different from the administrative domain the „nomadic node” originates (subsequently denoted as „home domain”).

Opportunistic Encryption

Opportunistic Encryption allows the establishment of a secured connection without any pre-configuration needs. For this purpose FreeS/WAN obtains the public key of the receiving site using the Domain Name Service (DNS) (provided that the responsible Name

Server supports this service).

Proxy Agent or Proxy

In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices. While proxies typically do not respond to client Requests prior to receiving a Response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and may not support all Diameter applications.

Realm The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally, or whether they must be routed or redirected. In RADIUS, realm names are not necessarily piggybacked on the DNS namespace but may be independent of it.

88


Real-time Accounting

Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk.

Redirect Agent Rather than forwarding requests and responses between clients and servers, redirect agents refer clients to servers and allow them to communicate directly. Since redirect agents do not sit in the forwarding path, they do not alter any AVPs transiting between client and server. Redirect agents do not originate messages and are capable of handling any message type, although they may be configured only to redirect messages of certain types, while acting as relay or proxy agents for other types. As with proxy agents, redirect agents do not keep state with respect to sessions or NAS resources.

Relay Agent or Relay

Relays forward requests and responses based on routing-related AVPs and realm routing table entries. Since relays do not make policy decisions, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter application or message type. Since relays make decisions based on information in routing AVPs and realm forwarding tables they do not keep state on NAS resource usage or sessions in progress.

Roaming Relationships

Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming consortium, and relationships between an ISP and a roaming consortium.

Security Association

A security association is an association between two endpoints in a Diameter session which allows the endpoints to communicate with integrity and confidentially, even in the presence of relays and/or proxies.

Session A session is a related progression of events devoted to a particular activity. Each application should provide guidelines as to when a session begins and ends. All Diameter packets with the same Session-Identifier are considered to be part of the same session.

Session state A stateful agent is one that maintains session state information, by keeping track of all authorized active sessions. Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise, or by expiration.

Sub-session A sub-session represents a distinct service (e.g. QoS or data characteristics) provided to a given session. These services may happen concurrently (e.g. simultaneous voice and data transfer during the same session) or serially. These changes in sessions are tracked with the Accounting-Sub-Session-Id.

Transaction state The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, the Hop-by-Hop identifier is saved; the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state.

Translation Agent A translation agent is a stateful Diameter node that performs protocol translation between Diameter and another AAA protocol, such as RADIUS.

Transport Connection

A transport connection is a TCP or SCTP connection existing directly between two Diameter peers, otherwise known as a peer-to-peer Connection.

Upstream Upstream is used to identify the direction of a particular Diameter message from

89


the access device towards the home server.

User The entity requesting or using some resource, in support of which a Diameter client has generated a request.

90


Appendix A

A1. Data Exchange in the Simple VPN-based Access Control Procedure

The simple VPN-based access control protocol consists of the message exchanges depicted below where the following notations are used:

Code_fail / Code_succ:

Code indicating failure / success

Encr{key}(data) Cipher representing “data” encrypted with “key” HMAC: Keyed-Hashing for Message Authentication [26]: Keyed hash computed with “key” over “data”IDii: Node identity as defined in the IKE protocol Indices I, r Denote initiator and responder, respectively, as defined in the IKE protocol IP: Internet Protocol address ISAKMPi_AVP: AVP containing ISAKMP phase 1 message KA: Private key KE: Public Diffie-Hellman key as defined in the IKE protocol MAC: Media Access Control (layer 2) address NAI: Network Access Identifier [25] NN: A nonce value SA: Parameters associated to an IKE or CHILD security association, as defined in the IKE protocol SKXY: Key shared by X and Y where X and Y are one of N (nomadic node), A (attendant)or H

(AAAH) SPI: Security Parameter Index TN: A timestamp value

The message exchange takes place between peers, as depicted in Figure 7 APReq, AuthReq, AuthAns, and APAns denote the control messages exchanged by Node, Attendant and AAAH which are typically composed of a sequence of AVPs containing control information relevant to the AAA protocols. The set of existing AVPs is extended with a number of AVPs that encapsulate control information relevant to the SA and key management (a set of IKE payloads).

Node → Attendant APReq: NAI, TN, NN, IP, MAC, ISAKMPi_AVP, HMAC{SK’NH}(NAI, TN, NN, IP, MAC,

ISAKMP_AVP),

with ISAKMPi_AVP = SPIi, SAi, KEi, Ni, IDii and SK’NH = MAC(SKNH | NN)

The message contains the nomadic node’s NAI, which is used by AAAL to identify the appropriate AAAH to send the corresponding AAA authentication request.

A timestamp TN is used to protect against reply attacks and a nonce NN serves to derive the nomadic node-AAAH authentication key.

The IP address the nomadic node has acquired (typically through auto-configuration) in the visited network is stored within the message so that the attendant could learn to which address the corresponding reply must be returned without having to maintain states.

Similarly, the MAC address is also recorded in order to avoid having the attendant to maintain states or rely on neighbour discovery, as malicious nodes can easily misuse this protocol.

91


The nomadic node also includes an AVP containing an ISAKMP message and finally an authenticator that affords integrity protection to the whole message. The ISAKMP payload contains the SPI of the incoming IKE SA, the SA proposal, a public Diffie-Hellman key, a nonce and an identifier.

Attendant → AAAH AuthReq: APReq, ISAKMPr_AVP, HMAC{KA}(TA, IP, MAC, ISAKMPi_AVP, ISAKMPr_AVP),

with ISAKMPr_AVP = SPIr, SAr, KEr, Nr, IDrr

The attendant produces a response to the ISAKMP initiation message received from the nomadic node. This operation must involve minimal computational resources therefore the processing is limited to:

Checking the nomadic node’s SA proposal and compiling a response (SAr) indicating the accepted transforms, Oakley group and lifetime;

Generating a nonce;

Generating an incoming SPI for the IKE SA.

Public Diffie-Hellman keys may be reused over multiple sessions therefore they may be periodically generated off-line, as they are time consuming operations.

Additionally the attendant computes, using key known only to itself, a keyed hash over the ISAKMP messages, the IP and MAC address of the supplicant and a local timestamp. The keyed hash must be echoed by the AAAH and it enables the attendant to check that the authentication answers it receives correspond to previous authentication requests.

AAAH → Attendant AuthAns: Code_succ, TN, TH, NH, ISAKMPr_AVP, HMAC{SK”NH}(Code_succ, TN, TH, NH,

ISAKMPr_AVP), IP, MAC, ISAKMPi_AVP, HMAC{KA}(TA, IP, MAC, ISAKMPi_AVP, ISAKMPr_AVP),

with SK”NH = MAC(SKNH | NH)

The AAAH checks the authenticator provided by the nomadic node, and if the supplicant is authentic, the timestamp provided in the message is compared to the local time. If the two time values are not shifted beyond a pre-configured accepted value, then the AAAH generates a positive answer.

The AAAH provides a success code, its own timestamp, a nonce used to derive the authentication key from SKNH and authenticates the ISAKMP response message generated by the attendant.

Malicious AAA entities may attempt to fake authentication answers. However, the security scheme can only be breached when such an AAA entity conspires with malicious visitors. Otherwise an authentication answer cannot be replied nor can the public Diffie-Hellman key provided by a legitimate user be replaced. Such a collusion situation is however not typical to the proposed protocol and appropriate security measures must be taken to protect the AAA infrastructure against such attempts. In particular the AAA relay and proxy agents must be replaced with AAA redirect agents whenever this is possible, otherwise AAA servers that use their services must setup end-to-end security associations.

Attendant → Node APAns: Code_succ, TN, TH, NH, ISAKMPr_AVP, HMAC{SK”NH}(Code_succ, TN, TH, NH,

ISAKMPr_AVP)

92


The attendant checks the keyed hash computed with its private key and if the message proves to be authentic and timely the attendant creates a state, derives the shared secret from the public Diffie-Hellman exchange, forwards the relevant data to the nomadic node and waits for it to initiate the IKE quick mode exchange.

Timer Synchronisation

AAAH → Attendant AuthAns: Code_fail, TN, TH, NH, HMAC{SK”NH}(Code_fail, TN, TH, NH)

with SK”NH = MAC(SKNH | NH)

Attendant → Node APAns: Code_fail, TN, TH, NH, HMAC{SK”NH}(Code_fail, TN, TH, NH)

In this case the attendant does not create any new state and does not modify any existing state. Upon receiving such a message, the nomadic node checks the authenticator and the timestamp before proceeding with the adjustment of the local timer. This ensures that a malicious AAA entity that replies such a message or creates a faked one cannot disturb in any way the service.

93

Framework for the Support of IPv6 Wireless LANs v2 · and would serve as an IPv6 WLAN design and...

Documents

Transcript of Framework for the Support of IPv6 Wireless LANs v2 · and would serve as an IPv6 WLAN design and...