IEEE 802.11i WLAN Security Protocol – A Software Engineer’s Model
Elankayer Sithirasenan, V. Muthukkumarasamy, Danny Powell
School of Information and Communication Technology
Griffith University, Queensland, Australia
Elankayer.Sithirasenan@student.griffith.edu.au, {v.muth, Danny.Powel}@griffith.edu.au
ABSTRACT
Wireless local area networks (WLANs) based on the IEEE 802.11 standards are one of today’s
fastest growing technologies in businesses, schools, and homes, for good reasons. As WLAN
deployments increase, so does the challenge to provide these networks with security. Security
risks can originate either due to technical lapse in the security mechanisms or due to defects in
software implementations. Standard Bodies and researchers have mainly used UML state
machines to address the implementation issues. In this paper we propose the use of GSE
methodology to analyse the incompleteness and uncertainties in specifications. The IEEE
802.11i security protocol is used as an example to compare the effectiveness of the GSE and
UML models. The GSE methodology was found to be more effective in identifying ambiguities
in specifications and inconsistencies between the specification and the state machines. Resolving
all issues, we represent the robust security network (RSN) proposed in the IEEE 802.11i
standard using different GSE models.
Keywords: WLAN Security, IEEE 802.11i, RSN, Genetic Software Engineering (GSE),
Behavior Trees.
1 Introduction
The first wireless security solution for 802.11-based networks, the Wired Equivalent Privacy
(WEP), received a great deal of coverage due to various technical failures in the protocol [1].
Standards bodies and industry organizations are spending more time and money on developing
and deploying next-generation solutions that address growing wireless network security
problems. The IEEE 802.11i standard proposes a Robust Security Network (RSN) with muchimproved authentication, authorization, and encryption capabilities. The Wi-Fi Alliance, a
wireless industry organization, has created the Wi-Fi Protected Access (WPA) standard, a subset
of the 802.11i.
These new standards are more complicated than their predecessors but are more scalable and
secure than existing wireless networks. They also dramatically raise the bar for attackers and
administrators. The new standards will employ a phased adoption process because of the large
installed base of 802.11 devices. Proper migration to 802.11i and mitigating the legacy wireless
risks will be a bumpy road. However, the end result will provide users a secure base for mobile
distributed processing needs [2].
Nevertheless, the strong security mechanisms can still be in vain if not implemented properly.
Software Engineers must be able to correctly interpret and comprehend the standards. A naive
implementation of the security protocol can lead to the same security breaches caused by
technical flaws. In this regard, firstly, we have formulated a set of requirements for the RSN
from the IEEE 802.11, 802.1X, and 802.11i standards. Next, we use the GSE methodology [3] to
analyze these requirements for incompleteness, uncertainties, and inconsistencies. Thus
identified ambiguities are resolved using appropriate domain expertise to derive at a complete
and consistent set of requirements. Thereafter, we have used this new set of requirements to
AusCERT2005: Refereed R&D Stream
39
build an implementation model for the RSN. We believe that this study on the 802.11i will
provide sufficient information for software engineers enabling effective implementation of the
RSN. The GSE methodology enables systematic modelling of complex systems with good
traceability, control and accommodation of change [4].
The next section presents an overview of the various security standards and the currently known
security threats. Section 3 gives an overview of the IEEE 802.11i system as applied to RSN. The
requirements analysis and modeling details are presented in section 4. A comparison of our
models with the models given in the standards is described in sections 5. Section 6 describes the
results and section 7 concludes the paper.
2. Wireless LANs
There are two modes of operation for WLANs - ESS and IBSS. The Extended Service Set (ESS)
is typically part of a larger network with interfaces to a wired LAN with an access point (AP)
bridging the Stations (STA) to the wired LAN. The wireless stations have network interface
cards (NIC) that interface the stations to the APs by radio frequency (RF) transmissions. Another
WLAN configuration consists of a standalone RF network that is made up of only STAs. It
operates as an independent WLAN known as an ad-hoc or Independent Basic Service Set
(IBSS). This study is mainly focused on ESS.
2.1 WLAN security standards
The evolution of today’s WLAN security standards begins with 802.11 [5]. This standard helped
launch practical WLANs that were ideal for the home and most small offices, but lacking in
features required by the large enterprise. Authentication was essentially ignored by the standard.
The data privacy solution was WEP. It is an implementation of the RC4 algorithm. The RC4
encryption technique is strong enough, but a weak implementation in 802.11 meant it was only
strong enough to protect against casual eavesdropping. In addition, the proliferation of readily
available hacking tools led to WEP being generally discredited for enterprise wide distributed
processing environments [6].
IEEE 802.1X was introduced to specifically address the WLAN authentication function. In
addition, 802.1X endorsed a distributed architecture for WLANs that significantly increased
scalability [7].
The Wi-Fi Alliance introduced a security solution that counters the known weaknesses of WEP
called Wi-Fi Protected Access (WPA) [8]. It is a subset of the abilities of 802.11i, including
better encryption with Temporal Key Integrity Protocol (TKIP), easier setup using a pre-shared
key, and the ability to use RADIUS-based 802.1X authentication of users. WPA is designed to
work with existing 802.11-based products with firmware upgrade and offers forward
compatibility with 802.11i. All of the known shortcomings of WEP are addressed by WPA,
which features packet key mixing, a message integrity check, an extended initialization vector,
and a re-keying mechanism [9].
IEEE 802.11i [10] and WPA2 are future WLAN standards introduced by the IEEE and Wi-Fi
Alliance respectively. The new features in 802.11i/WPA2 are AES (Advanced Encryption
Standard), message integrity, and fast-roaming support (pre-authentication). Vendor
interoperability, as well as forward and backward compatibility, has been consistent themes for
the IEEE and Wi-Fi Alliance as WLAN standards have evolved [11].
AusCERT2005: Refereed R&D Stream
40
2.2 Common Security Threats in the Air
There are numerous tactics used by hackers to intrude enterprise wide networks via the more
vulnerable wireless LANs. Following are some of the common attacks:
Malicious or Accidental Association: A hacker can force an unsuspecting user station to
connect to an undesired/spoofed 802.11 network, or alter the configuration of the station
to operate in an ad-hoc networking mode [12].
Identity Theft (MAC Spoofing): Knowledgeable hackers can pick off authorized SSIDs
and MAC addresses and steal bandwidth, corrupt or download files, and wreak havoc on
the entire network. This is also called an Impersonation attack [12].
Man-in-the-Middle Attacks: Connections between authorized stations and access points
are intercepted by inserting a malicious station between the victim’s station and the
access point [13].
Session Hijack: A more advanced version of the above with the adversary gaining access
to session information and intruding the network [13].
Denial of Service Attacks: Directed against a specific user station to prevent that station
from communicating with the network, against a specific access point to prevent stations
from connecting with it, or as an attack against all network devices. In this last case, the
attack shuts down all wireless LAN activity [14].
Network Injection Attacks: Eexploits improperly configured wireless LANs or rogue
access points to target the entire network [15].
The above list provides some idea of the security issues and threats posed to today’s wireless
networks. It should not however be considered an exhaustive list of all the wireless threats
known to exist, and new threats continue to evolve. Let us now focus on the RSN as described in
the IEEE 802.11i standard.
3 The 802.11i
The IEEE 802.11i standard defines two classes of security framework for IEEE 802.11 WLANs:
RSN and pre-RSN as shown in Fig. 1. A station is called RSN-capable equipment if it is capable
of creating RSN associations (RSNA). Otherwise, it is called pre-RSN equipment. The network
that only allows RSNA with RSN-capable equipments is called a RSN security framework. The
major difference between RSNA and pre-RSNA is the 4-way handshake. If the 4-way handshake
is not included in the authentication/association procedures, stations are said to use pre-RSNA.
802.11i
Security
RSN Capable
Equipment
Data Privacy
Pre-RSN
Equipment
Security
Management
WEP Privacy
IEEE 802.11
Authentication
TKIP
RSN
Selection
Open System
Authentication
WRAP
IEEE 802.1X
Authentication
Shared Key
Authentication
CCMP
IEEE 802.1X
Key Management
Figure 1. The 802.11i Security Framework
AusCERT2005: Refereed R&D Stream
41
In addition to enhancing the security in pre-RSN, the RSN security defines key management
procedures for IEEE 802.11 networks. It also enhances the authentication and encryption in preRSN. The enhanced features of RSN are as follows:
Authentication Enhancement: IEEE 802.11i utilizes IEEE 802.1X for its authentication and
key management services. It incorporates two components into the IEEE 802.11 architecture
IEEE 802.1X Port and Authentication Server (AS). IEEE 802.1X port represents the association
between two peers. There is a one-to-one mapping between IEEE 802.1X Port and association.
Key Management and Establishment: Two ways to support key distribution are introduced in
IEEE 802.11i: manual key management and automatic key management. Manual key
management requires the administrator to manually configure the key. The automatic key
management is available only in RSNA. It relies on IEEE 802.1X to support key management
services. More specifically, the 4-way handshake is used to establish each transient key for
packet transmission.
Encryption Enhancement: In order to enhance confidentiality, two advanced cryptographic
algorithms are developed: Counter-Mode/CBC-MAC Protocol (CCMP) and Temporal Key
Integrity Protocol (TKIP). In RSN, CCMP is mandatory. TKIP is optional and is recommended
only to patch pre-RSN equipment.
Fig. 2 shows an example RSNA establishment between a supplicant (STA) and the authenticator
(AP) in an Extended Service Set (ESS). It assumes no use of pre-shared key. Flows 1-6 are the
IEEE 802.11 association and authentication process prior to attaching to the authenticator.
During this process, security information and capabilities could be negotiated using the RSN
Information Element (IE). The Authentication in Flows 3 and 4 refer to the IEEE 802.11 open
system authentication. After the IEEE 802.11 association is completed, the IEEE 802.1X
authentication indicated in Flow 7 is initiated. EAP messages will be exchanged between
supplicant, authenticator, and authentication server. If the supplicant and the authentication
server authenticate each other successfully, both of them independently generate a Pairwise
Master Key (PMK). The authentication server then transmits the PMK to the authenticator
through a secure channel (for example, IPsec or TLS). Fig. 3 illustrates the steps involved in the
handshake process.
802.1X
SUPPLICANT
802.1X
AUTHENTICATOR
1. 802.11 Probe Request
2. 802.11 Probe Response
802.1X
SUPPLICANT
802.1X
AUTHENTICATOR
8.1 EAPOL-Key (key_info, Anonce)
8.2 EAPOL-Key (key_info, Snonce, MIC, RSN IE)
3. Open System Authentication Request
8.3 EAPOL-Key (key_info, Anonce, MIC, RSN_IE)
4. Open System Authentication Response
8.4. EAPOL-Key (key_info, MIC)
4-way
Handshake
5. 802.11 Association Request
6. 802.11 Association Response
9.1 EAPOL-Key (key_info, Key ID, Key RSC, MIC, GTK)
7. 802.1X Authentication
9.2 EAPOL-Key (key_info, MIC)
Group Key
Handshake
8. 4-Way Handshake
9. Group Key Handshake
DATA PRIVACY
DATA PRIVACY
Figure 2. RSN Association
Figure 3. 802.1X Handshake
The 4-way handshake uses the PMK to derive and verify a Pairwise Transient Key (PTK)
guaranteeing fresh session key between the supplicant and the authenticator. Thereafter, the
group key handshake is initiated. The group key handshake is used to generate and refresh the
AusCERT2005: Refereed R&D Stream
42
group key, which is shared between a group of stations and APs. Using this key, broadcast and
multicast messages are securely exchanged in the air. In the next section the above-described
RSN is modeled. The complete modeling, from requirements analysis to the final design models
is carried out using the GSE techniques.
4 MODELING
In the process of modeling the RSN, we first model the WLAN environment using the Structure
and Composition Trees. Thereafter, the requirements translation is accomplished followed by the
development of the requirements behavior trees (RBTs).
4.1 WLAN Structure
The behavior of a system takes place on a network structure. This structure can be defined using
the analogous of behavior trees called structure trees. The structure tree is used in our analysis to
demonstrate the connection structure of two STAs in an ESS. The model shows how the
connecting STAs coordinate with other components in the system.
STA/In #
ESS
ESS #1
) BSS * (
BSS #
AP #
DS #1
) STA * (
ESS #1
STA#
AP # ^
STA/Out#
Figure 4. Connection Structure
/
[ Name#, IP# ]
/
RSN IE #
AP #
/
SSID#
/
RSN IE #a
Figure 5. ESS Composition
Fig. 4 shows the connection structure of the Extended Service Set (ESS). An STA in an ESS can
either directly connect to another STA via a single AP or it can connect via a number of APs
through the Distribution System (DS). The recursion symbol (^) used in the AP# component
notify that there can be several reversions before an STA connects to another STA.
4.2 WLAN Composition
The composition tree identifies the hierarchy of all components in the RSN, their
characterizations, classifications, multiplicity, and their compositional properties.
Fig. 5. shows the composition of an ESS. An ESS consists of one or more Basic Service Sets
(BSS). The BSS is made of one AP and several STAs. An AP advertises the SSID of the
associated ESS and its RSN capabilities using the RSN Information Element (IE). Similarly, the
STAs have their own identifiers and IP addresses. The STAs also advertise their RSN
capabilities in their RSN IE.
The next step in GSE modeling is requirements analysis. Firstly, the requirements are assembled
from the standard and translated. Thereafter, the RBTs are built. The RBTs are then integrated to
derive at the Design Behavior Tree (DBT). Finally, the DBT is used to derive at the other GSE
models for the analysis of the RSN. Detailed records of requirements translation, integration and
defect identification can be found in [3].
AusCERT2005: Refereed R&D Stream
43
4.3 RSN Modeling
Requirements translation is the first formal step in the GSE design process. Its purpose is to
translate each natural language functional requirement, one at a time, into one or more behavior
trees. This translation identifies the components (including actors and users), the states they
realize (including attribute assignments), the events and decision/constraints that they are
associated with, the data exchange, and the casual, logical and temporal dependencies associated
with component interactions. The IEEE 802.11i standard defines two classes of security
framework for IEEE 802.11 WLANs: RSN and pre-RSN security frameworks. This study is
mainly focused on the RSN security framework shown in Fig. 6. STAs in a RSN environment
can make contact with an ESS in one of two ways: initial contact or Roaming. In case of roaming
we are not concerned of whether the STAs are navigating inter-subnet or intra-subnet since the
security policy in both cases will be the same.
Clauses 8.4.1 to 8.4.10 in the IEEE 802.11i standard describe the steps involved in the RSN
security association life cycle. We have made use of these steps to develop the RBTs for the
RSN. Each individual functional requirement is translated into one or more corresponding RBTs.
Altogether, we assembled twelve functional requirements and an RBT was developed for each.
As an example we have listed the fifth requirement and shown the corresponding RBT here:
RSN Security
Framework
Initial Contact
Roaming
RSN
Selection
Open System
Authentication
Filtering of
data traffic
IEEE 802.1X
Authentication
IEEE 802.11i
Key Management
(Re-)Associate
Pre
Authenticate
IEEE 802.1X
Authentication
Remove all
Cryptographic Keys
Follow same steps
as in initial contact
Figure 6. RSN Security Framework
(5)
8.4.3
-
STA #1
[ CONNECTING ]
(5)
8.4.3
+
STA #1
[[Analyse] RSN IE #a ]
Intermediate State
Clause 8.4.1 says the
Association starts after
Open System Authentication
Check RSN IE received
from the AP with that of
the STA
(5)
8.4.3
STA #1
? NOT: Feilds [Overlap] ?
(5)
8.4.3
STA #1
? Feilds [Overlap] ?
(5)
8.4.3
STA #1
< Decline >
(5)
8.4.3
STA #1
< AsocReq + RSN IE #s / >
/
/
/
Groupwise cipher suite
(5)
8.4.3
AP #1
> AsocReq + RSN IE #s / <
(5)
8.4.3
+
AP #1
[[Analyse] AsocReq ]
(5)
8.4.3
-
AP #1
? AsocSuccess ?
(5)
8.4.3
-
AP #1
? NOT: AsocSuccess ?
(5)
8.4.3
+
STA #1
[ CONNECTING ]
(5)
8.4.3
AP #1
< Decline >
(5)
8.4.3
STA #1
> Decline <
(5)
8.4.3
-
STA #1^
[ DISCONNECTED ]
(5)
8.4.3
AP #1
> Decline <
(5)
8.4.3
-
AP #1^
[ DISCONNECTED ]
Authentication
Pairwise cipher suite
At this point the dot11
association is complete
Initiating STAs
RSN IE
Figure 7. RBT for Requirement 5
Requirement 5, Policy selection in ESS: The STA initiating an association shall insert an RSN IE
into its (Re) Association Request whenever the targeted AP indicates RSN support. The initiating
STA's RSN IE shall include one authentication and pairwise cipher suite from among those
advertised by the targeted AP in its Beacons and Probe Responses. It shall also specify a group
key cipher suite specified by the targeted AP. If at least one RSN IE field from the APs RSN IE
fails to overlap with any value the STA supports, the STA shall decline to associate with that AP.
It is invalid in an RSN to specify "None" as the pairwise cipher. If the RSN capable AP receives
a (Re) Association request including an RSN IE, and if it chooses to accept the association, the
AP shall, to secure this association use the authentication and pairwise cipher suites the RSN IE
in the (Re) Association Request specifies.
AusCERT2005: Refereed R&D Stream
44
Fig. 7 shows the RBT for the above requirement. The shaded boxes (colors used in real) in the
tree denote assumed or missing requirements. In a similar fashion RBTs are created for all of the
twelve requirements extracted from clause 8 of the standard. During the development of the
RBTs we found several incompleteness and uncertainties in requirements. We used appropriate
domain expertise to resolve these ambiguities. Table 1 below lists the ambiguities and the
relevant decisions taken by us. Next, we systematically and incrementally integrate the twelve
RBTs to construct a DBT that satisfies all its requirements. The integration issues identified
during the integration process are also listed in Table 1. These integration issues, which are
mostly due to inconsistencies in pre and post conditions, were resolved using appropriate domain
expertise. Due to space constraints we have not shown all the RBTs and the DBT in this paper. A
detailed account of the requirements translation, requirements behaviour trees and integration
can be found in [16]
IEEE Clause
Req. No. Defect
Description
8.4.1
1
Missing
Initial State of an AP assumed DISCONNECTED
1
Uncertain Post-condition if an AP does not advertise a valid SSID not clear
1
Uncertain Conditions for Declining a connection or Guessing an SSID not clear
2
Missing
2
Unc ertain Roaming sc hemes are not c learly desc ribed
2
Missing
Post-conditions of roaming assumed DISCONNECTED
3
Missing
Initial state of a STA assumed DISCONNECTED
3
Missing
Post-condition if STA not RSN capable assumed DISCONNECTED
3
Missing
Post-condition of cipher suites mismatch assumed DISCONNECTED in ESS
3
Missing
STA intermediate state assumed CONNECTING (ref. dot1x)
4
Uncertain Schemes for STAs to join an IBSS not clear
4
Uncertain STA is able to decapsulate a message but sees invalid SSID
4
Missing
Post-condition after dec apsulating a valid SSID assumed RSNA
5
Missing
Post-condition of RSN-IE mismatch assumed DISCONNECTED in ESS
5
Missing
Post-condition of dot11 association failure assumed DISCONNECTED
8.4.4
6
Missing
Post-condition of cipher suite mismatch assumed AUTHENTICATED in IBSS
8.4.5
7
Missing
Post-condition if dot1x Auth not supported assumed DISCONNECTED
8.4.6
8
Deleted
Post-condition if dot1x Auth not supported
8
Assumed
STA at ACQUIRED state when EapolReq/Identity rec eived (ref. dot1x)
8
Assumed AP at AUTHENTICATING state once EapolResp/Identity received (ref. dot1x)
8
Assumed STA at AUTHENTICATING state once EapolAcc/Challenge received (ref. dot1x)
8
Missing
Post-condition when AS rejects STA identity assumed DISCONNECTED
8
Assumed
STA at AUTHENTICATED state once EapolSuccess received (ref. dot1x)
8.4.7
9
Missing
Post-condition when STA fails to identify itself to another STA in IBSS
8.4.8
10
Missing
Pre-condition for 4-way key exchange assumed AUTHENTICATED
10
Missing
Post-condition after the GwK's are installed assumed RSNA
8.4.9
11
Missing
Post-condition when cipher suites not present in IBSS assumed DISCONNECTED
8.4.10
12
Missing
Pre-condition for Disassociation/Reassoc iation/Deauthentication assumed
12
Missing
Post-condition for Disassoc iation/Reassociation/Deauthentic ation assumed
8.4.2
8.4.3
Pre-condition for roaming assumed RSNA
Table 1. Ambiguities in Requirements
4.4 System Behavior Projection
The system behaviour projection (SBT) is accomplished by inspection of the DBT, identifying
each component and their states and projecting them separately in a tree like form analogous to
behaviour trees. The SBT is a collapsed view of the DBT presenting only the abstract states of
the components. It shows all the participating components in the system together with their
abstract states. This model is ideal for studying the interfaces between components and the
architecture of the system. The system architecture can be derived from the SBT by extracting
the components in a systematic manner into a component-based design in which each distinct
component is represented only once. We call this a Component Interaction Network (CIN).
However, in RSN since we have only two components the CIN model does not reveal any vital
results.
4.5 Component behavior projection
Next, inspecting the DBT we derive the component projection models for the supplicant and the
authenticator. We do this by simply ignoring the component-states of all components other than
the one we are currently projecting. The resulting connected behavior tree for a particular
component defines the behavior of the component that we will need to implement and
AusCERT2005: Refereed R&D Stream
45
encapsulate in the final component-based implementation. The projected component behaviour
for the Supplicant (STA) and the Authenticator (AP) are shown in Fig. 8.
In the component projection, both the STA and the AP are initially at the DISCONNECTED
state, which means the port is disconnected. From this state the STA begins the dot11 association
by sending a ProbeReq signal. This dot11 association state of the STA is indicated as dot11
ASSOCIATION in the STA projection model. At any instance if the STA is unable to establish
common security parameters with the AP, the STA is declined connection reverting it to the
DISCONNETED state. Once dot11 association is complete both the STA and the AP transfer
into the CONNECTING state enabling the port filters. When the filters are ON all non-IEEE
802.1X data traffic is blocked from the uncontrolled port of the authenticator.
Synchronize ?
8.4.1
8.4.1
STA
[ DISCONNECTED]
STA #1
8.4.2 [ dot11 ASSOCIATION ]
8.4.2
AP #1
[ DISCONNECTED]
AP #1
[ dot11 ASSOCIATION ]
dot11 Association
Complete
dot11 Association
Complete
8.4.5
STA #1
[ CONNECTING ]
8.4.1
STA #1^
[ DISCONNECTED ]
8.4.5
AP #1
[ CONNECTING ]
8.4.6
AP #1
[ AUTHENTICATING ]
8.4.8
AP #1
[ AUTHENTICATED ]
8.4.8
AP #1
[ KEY MANAGEMENT ]
8.4.8
AP #1
[ RSN ASSOCIATED ]
8.4.8
AP #1
[ AUTHENTICATING ]
8.4.1
AP #1^
[ DISCONNECTED ]
8.4.1
AP #1^
[ DISCONNECTED ]
EapolResp/Identity
Received
EapolReq/Identity
Received
8.4.6
STA #1
[ AQUIRED ]
roniz
Synch
EapolAcc/Challenge
Received
EapolSuccess
Received
1st Message of
4 Way handshake
Received
Group Key
Distribution
Complete
8.4.6
8.4.8
8.4.8
ed
STA #1
[ AUTHENTICATING ]
STA #1
[ AUTHENTICATED ]
EapolAccept
Received
1st Message of
4 Way handshake
Sent
8.4.1
STA #1^
[ DISCONNECTED ]
STA #1
[ KEY MANAGEMENT ]
Group Key
Distribution
Complete
d
ronize
Synch
8.4.8
STA #1
[ RSN ASSOCIATED ]
8.4.8
STA #1
[ DISCONNECTED ]
(b) Authenticator (AP)
8.4.1
STA #1^
[ AQUIRED ]
(a) Supplicant (STA)
Figure 8. Component Behaviour
Next the dot1x authentication begins. The dot1x authentication is initiated by the STA issuing a
EapolStart signal to the AP. In reply the AP sends the EapolReq/Identity to the STA. On
receiving this message the STA transit to the AQUIRED state. STA then issues the
EapolResp/Identity to the AP advertising its identity. AP transits to AUTHENTICATING state
on receiving the response from the STA. The AUTHENTICATING state of the AP is coupled
with the Authentication Server (RADIUS or DIAMETER). Thereafter, the STA transits into
AUTHENTICATING state no sooner it receives the EapolAcc/Challenge message from the AS.
At this stage depending on the EAP method used the number and the type of messages
interchanged between the supplicant and the authenticator may vary. However, at any instance if
the supplicant is unable to establish its identity the authenticator declines connection with the
STA, thereby reverting the STA to the DISCONNECTED state.
The dot1x authentication completes with the installation of the Pair-wise Master Keys (PMK) on
both STA and the AP. At this stage both the AP and STA reach the AUTHENTICATED state.
This state initiates the 4-way handshake. During the 4-way handshake the Pairwise Transient
Keys (PTK) are installed on both the STA and the AP. Once the PTKs are installed the Group
Key handshake begins. The group key handshake transfers the Groupwise Transient Key (GTK)
to the STA enabling it to receive broadcast/ multicast messages. Once the GTK is installed both
STA and the AP stops filtering enabling normal network traffic, at which point both AP and the
STA become RSN-ASSOCIATED. Although, the projection model does not show all of the
AusCERT2005: Refereed R&D Stream
46
details described here, these details can be found in the DBT. In contrast the state machines for
the supplicant and the authenticator given in the standard shows such details in one diagram.
5 Comparison with dot11i State Machines
In this section, we compare the projection models with the authenticator PAE (Port Access
Entity) state machine given in the IEEE 802.11i standard.
5.1 Projection Model and State Machine
Fig. 8 shows both the supplicant and the authenticator PAE projection models. The
corresponding state machines are found in [10]. The main feature on the projections model is
that it does not allow reversions into any intermediate states. This disables the possibility of
Man-In-The-Middle attacks or Session Hijacks as described in [12], [13]. Since both the AP and
STA are not synchronized from CONNECTING to AUTHENTICATED states, in our model we
intentionally revert the system to DISCONNECTED states ensuring consistent and stable states.
The diagram also shows the states where both the supplicant and the authenticator are
synchronized. At this state both the AP and STA are AUTHENTICATED and share a common
secret. Therefore, from this state onwards the integrity and privacy of all communications
between the two are guaranteed disabling any Network Injection or Authentication Spoofing
attacks as discussed in [14], [15]. Although, the projection models do not show any reversions to
the AUTHENTICATED state from later states, it is however possible to fall back to this state
maintaining strict RSN policy because of the synchronised ports.
The authenticator PAE state machine given in the standard confirms to the strict RSN policy
with no fall back to any intermediate states. The only reversion allowed on the dot11i state
machine is to the DISCONNECTED state endorsing our model although the specifications do
not specify such details. However, the state machine allows unconditional state transitions to
AUTHENTICATION & AUTHENTICATION-2 states. Reversion to the AUTHENTICATION2 state is allowed since a ReAuthentication-Request is legitimate during Pre-Authentication and
it takes place through an authenticated AP via the DS. This is analogous to reverting back to the
AUTHENTICATING state in the authenticator projection model and AQUIRED state in the
supplicant projection model. However, the AuthenticationRequest signal on the authenticator
PAE state machine is not qualified and therefore should not be allowed. The requirements too do
not indicate the circumstances under which this could take place and therefore we are unable to
derive an analogous condition in the projection models. The authenticator state machine shows
several reversions within the RSN-ASSOCIATED state that facilitates key generation and key
renewal. These states are not shown in the projection models since it is out of the scope of this
study.
5.2 System Projection and State Machines
Since the System Behaviour projection model projects all the components within the RSN
together with their states, we compare it with the RSN state machine shown in Fig. 9.
The initial state of the controlled port is said to be Unauthenticated & Unassociated, which is
analogous to the DISCONNECTED state of both the AP & STA in the system projection. The
Authenticated & Unassociated state is analogous to the AUTHENTICATED state of both the AP
& STA and the Authenticated & Associated state is analogous to the RSN-ASSOCIATED state
of both AP & STA. However, the state transitions shown on the RSN state diagram represents
AusCERT2005: Refereed R&D Stream
47
both dot1x and dot11i state transitions. In the case of RSN, the state machine has only two states
the Unauthenticated & Unassociated state and the RSN Associated state.
Class 1 & TSN
Class 2 Frames
RSN Association or
Reassociation
State 4
State 1
Deauthentication
Notification
RSN Associated
Class 1, 2 & 3
Frames except
Authentication &
Deauthentication
Class 1 & 2
Frames
Successful
Association
or ReAssociation
State 2
Authenticated
Unassociated
Disassociation
Notification
Disassociation
Successful
MAC layer
Authentication
Deauthentication
Unauthenticated
Unassociated
State 3
Authenticated
Associated
Class 1,2 & 3
Frames
Figure 9. RSN state machine
The states 2 & 3 in the RSN state machine in Fig. 9 correspond to the dot1x states which are not
allowed in an RSN environment as discussed in the earlier section. Therefore, in order to have a
strict RSN security policy all intermediate states during reversions need to be avoided unless
they are synchronized as in the projection models.
6 Discussion
Table 1 summarizes some of the issues found in clause 8 - RSN security association of the IEEE
802.11i standard. The appropriate actions taken by us to resolve such issues are also listed. Most
of the problems identified are due to incompleteness or uncertainties in specifications. Several
integration issues were also identified. The GSE methodology provides a systematic approach to
validate the correctness of system requirements while developing the RBTs and subsequently
during integration. This feature enables us to verify the completeness of the requirements in the
early stages of development without letting issues to slip into the implementation stages.
IEEE Clause Req. No. Possible Attacks
Solutions
8.4.1
1
Identity Theft
APs are not allowed to advertise their SSIDs
1
Identity Theft
STAs are not allowed to guess SSIDs
2
Malacious Association Re-association starts from DISCONNECTED state
2
Malacious Association Pre-authentication is acheived via the DS, hence STA is at AQUIRED state
3
Man-In-Middle
8.4.2
3
Malacious Association STA is deliberately reverted back to DISCONNECTED State
8.4.3
5
Malacious Association STA is DISCONNECTED if RSN requirements are not met
5
Man-In-Middle
8.4.5
7
Malacious Association STA DISCONNECTED if dot1x incapable
8.4.6
8
Man-In-Middle
EAP messages are protected by filtering (integrity ?)
8
Man-In-Middle
STA DISCONNECTED if it is unable to prove its identity to the AS
10
TKIP Recovery
Use AES
8.4.8
Authenticator port is controlled
AP goes to DISCONNECTED state if it does not choose to associate?
Table 2. Possible Attacks on the RSN
The wireless attacks listed in the Table 2 are issues arising from the various uncertainties and
inconsistencies in the specifications. The following discussions provide an insight of the defects
and their consequences.
In Clause 8.4.1 permitting an STA to guess SSIDs can lead to malicious associations with
illegitimate APs. Furthermore during the initial stages of an RSNA both the supplicant and the
authenticator operate independently. Therefore, in a situation where the supplicant or the
authenticator is allowed to make presumptions can lead to revelation of vital information to
AusCERT2005: Refereed R&D Stream
48
undisclosed entities allowing malicious associations or Identity-Theft. In case of a re-association
request by a roaming STA we first transit the STA into DISCONNECTED state before it is made
to associate with the new AP. This case makes the RSN more reliable so that session-hijack
attacks can be avoided.
If an AP is not RSN capable, STAs should not be permitted to associate with that AP. In Clause
8.4.2, we force the AP to DISCONNECT from the STA in order to avoid any malicious
associations ensuring strong RSN security policy.
During the CONNECTING stages of the AP and STA as described in Clause 8.4.3, there is no
common shared secret. Therefore there is a possibility a Man-In-The-Middle scenario can reveal
the credentials of a legitimate STA causing malicious associations. Therefore, STAs, which are
unable to meet the RSN requirements of an AP at the first instance, are DISCONNECTED
immediately without permitting them to retry or guess information relevant to dot11 association.
In Clause 8.4.6 when both STA and AP become AUTHENTICATED they share a common
secret. Until this point the integrity of the messages exchanged between the STA and the AP are
dubious. An adversary sitting in the vicinity of an RSN can construct an attack scenario if the
participating STAs are allowed to revert to intermediate states in case of an uncertainty.
Therefore, it is not recommended to revert an STA into AQUIRED state if AUTHENTICATION
fails at any stage.
The above short description shows the importance of a complete and a consistent set of
requirements together with a proven analysis technique. Issues in requirements can lead to
defects in the final system. In this case such defects can lead to significant wireless attacks that
could endanger an entire organization. However, merely conducting a rigorous analysis is not
ultimate. It is also necessary to ensure that issues resolved during the analysis are effective and
pertinent.
The Genetic Software Engineering technique is effective not only for requirements analysis and
validation, it also provides a systematic approach to integrate the system ensuring that all parts of
the system corporate and coordinate correctly with good traceability. The formal nature of the
Behaviour Tree notation used within GSE requires all ambiguities, incompleteness and
inconsistency be resolved at the time of integration. The various models of the GSE
methodology enables even complex systems to be easily understandable by non-specialists.
Furthermore, implementation issues such as partitioning and component interfacing are also
made easy and adequate.
7 Conclusion
Inconsistencies between requirements and design models are a common problem faced by
software engineers. Although the IEEE standards carry more technical details of the protocol, the
fact is that the software engineers who implement the system have little or no domain knowledge
in relevant fields. Most domain experts tend to project their mental replica on design models,
assuming to be understood by everyone. This not only leads to confusion but also makes
problem resolution impossible without proper fallback to specifications.
The systematic analysis performed in this study using the GSE methodology has identified a
number of ambiguities and defects in specifications. We have shown that issues in software
specifications can lead to serious security breaches. Feasible improvements are also
recommended to remedy those issues and a number of GSE models have been developed to
AusCERT2005: Refereed R&D Stream
49
represent the improved RSN environment. Although, we have not analysed the system to the
lowest levels, the details provided here are sufficient enough for a software developer to produce
a system with strong RSN policies.
The discrepancy in the requirements and the UML state machines shown in the standard have led
to several inconsistencies. Many of the identified incompleteness issues and ambiguities in the
standard’s requirements arise from semi-tacit and tacit knowledge not being specified. This
leads to a software engineer acquiring considerable domain expertise in order to design and
implement the RSN. Therefore, detailed and accurate specifications are essential to enable
software engineers implement standards without software flaws.
The GSE models have highlighted a number of incompleteness and inconsistency issues, which
were not identified by the UML models. The GSE models derived are simple, easy to understand
and provide systematic tracking to the original specifications.
REFERENCES
[1] Borisov, N. Goldberg, I. Wagner, D. “Intercepting Mobile Communications: The
Insecurity of 802.11”, ACM SOGMOBILE, Vol. 7, Jan. 2001, pp. 180-188.
[2] Mead, N.R. McGraw, G. “Wireless Security Future”, IEEE Security & Privacy,
July/Aug. 2003, pp. 68-72.
[3] Dromey, R.G. From Requirements to Design: formalizing the key steps, Proc. 1st
International Conference on Software Engineering and formal methods, Sep. 2003,
Brisbane, Australia, pp. 2-11.
[4] Sithirasenan, E. Muthukkumarasamy, V. “A Model for Object Based Distributed
Processing Using Behavior Trees: Proceedings of the Eighth IASTED International
Conference on Software Engineering and Applications, Nov. 2004, Cambridge MA,
USA, pp 477-482.
[5] IEEE Std. 802.11, “Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications”, 1999.
[6] Stubblefield, A. Ioannidis, J, Rubin, A.D. A key recovery Attack on the 802.11b Wired
Equivalent Privacy Protocol (WEP)", ACM Transactions on Information and System
Security, Vol. 7, No. 2, May 2004, pp. 319-332.
[7] IEEE Std. 802.1X-2001, “Local and Metropolitan Area Networks – Port-Based
Network Access Control”, June 2001.
[8] Wi-Fi Alliance. “Wi-Fi Protected Access (WPA)”, Version 2.0, April 2003.
[9] Wi-Fi Alliance. “Securing Wi-Fi Wireless Networks with today technologies”,
February, 2003
[10] IEEE Std. 802.11i/D3.0, “Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications security enhancements”, November 2002.
[11] Wi-Fi Alliance. “Wi-Fi is everywhere”, April 2003. http://www.wifi.org/OpenSection/pdf /WPA_NI_2003-Pres.pdf
[12] Arbaugh, W.A. Shankar, N. Wan, J. “Your 802.11 Wireless Network Has No Cloths”,
IEEE Wireless Communications, Dec. 2002, pp. 44-51.
[13] Mishra, A. Arbaugh, W.A. “An Initial Security Analysis of the IEEE 802.1X
Standard”, Critical Infrastructure Grant, National Institute of Standards, Feb. 2002
[14] Bellardo, J. Savage, S. “802.11 Denial-of-Service Attacks: Real Vulnerabilities and
Practical Solutions”, Proc. of the USENIX Security Symposium, August 2003.
[15] Arbaugh, W. Housley, R. “Security Problems in 802.11 based Networks”,
Communications of the ACM, Vol. 46, No. 5, May 2003, pp. 31-34.
[16] Sithirasenan, E. “A Preliminary Analysis of the IEEE 802.11i WLAN Protocol”, Masters
Thesis, Griffith University, Australia, Oct. 2004.
AusCERT2005: Refereed R&D Stream
50