IEEE i WLAN Security Protocol A Software Engineer s Model

Transcription

1 IEEE i 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 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 i 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 i standard using different GSE models. Keywords: WLAN Security, IEEE i, RSN, Genetic Software Engineering (GSE), Behavior Trees. 1 Introduction The first wireless security solution for 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 i 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 i. 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 devices. Proper migration to i 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.1X, and i 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

2 build an implementation model for the RSN. We believe that this study on the i 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 i 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 [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. 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 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 i, 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 based products with firmware upgrade and offers forward compatibility with i. 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 i [10] and WPA2 are future WLAN standards introduced by the IEEE and Wi-Fi Alliance respectively. The new features in i/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

3 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 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 i standard. 3 The i The IEEE i standard defines two classes of security framework for IEEE 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 i Security RSN Capable Equipment Pre-RSN Equipment Data Privacy Security Management WEP Privacy IEEE TKIP WRAP CCMP RSN Selection IEEE 802.1X IEEE 802.1X Key Management Open System Shared Key Figure 1. The i Security Framework AusCERT2005: Refereed R&D Stream 41

4 In addition to enhancing the security in pre-rsn, the RSN security defines key management procedures for IEEE networks. It also enhances the authentication and encryption in pre- RSN. The enhanced features of RSN are as follows: Enhancement: IEEE i utilizes IEEE 802.1X for its authentication and key management services. It incorporates two components into the IEEE architecture IEEE 802.1X Port and 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 i: 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 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 in Flows 3 and 4 refer to the IEEE open system authentication. After the IEEE 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 X SUPPLICANT 802.1X AUTHENTICATOR 802.1X SUPPLICANT 802.1X AUTHENTICATOR Probe Request Probe Response 3. Open System Request 4. Open System Response Association Request Association Response X 8. 4-Way Handshake 9. Group Key Handshake DATA PRIVACY 8.1 EAPOL-Key (key_info, Anonce) 8.2 EAPOL-Key (key_info, Snonce, MIC, RSN IE) 8.3 EAPOL-Key (key_info, Anonce, MIC, RSN_IE) 8.4. EAPOL-Key (key_info, MIC) 9.1 EAPOL-Key (key_info, Key ID, Key RSC, MIC, GTK) 9.2 EAPOL-Key (key_info, MIC) DATA PRIVACY 4-way Handshake Group Key Handshake Figure 2. RSN Association Figure X 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

5 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 * ( AP # BSS # DS #1 ESS #1 ) STA * ( AP # / SSID# AP # ^ STA/Out# STA# / [ Name#, IP# ] / RSN IE #a / RSN IE # Figure 4. Connection Structure 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

6 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 i standard defines two classes of security framework for IEEE 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 to in the IEEE i 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? NOT: Feilds [Overlap]? - + [ CONNECTING ] [[Analyse] RSN IE #a ]? Feilds [Overlap]? Intermediate State Clause says the Association starts after Open System Check RSN IE received from the AP with that of the STA Initial Contact RSN Selection Open System Filtering of data traffic IEEE 802.1X IEEE i Key Management (Re-)Associate Roaming IEEE 802.1X Remove all Cryptographic Keys Follow same steps as in initial contact Pre Authenticate - < Decline > > Decline < ^ + - < AsocReq + RSN IE #s / > / / Pairwise cipher suite / Groupwise cipher suite + > AsocReq + RSN IE #s / < [[Analyse] AsocReq ]? AsocSuccess? [ CONNECTING ] - Initiating STAs RSN IE? NOT: AsocSuccess? < Decline > Figure 6. RSN Security Framework At this point the dot11 association is complete > Decline < - ^ 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

7 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 4.4 System Behavior Projection Missing Initial State of an AP assumed DISCONNECTED Table 1. Ambiguities in Requirements 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 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 Pre-condition for roaming assumed RSNA 2 Uncertain Roaming schemes are not clearly described 2 Missing Post-conditions of roaming assumed DISCONNECTED 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 decapsulating 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 Missing Post-condition of cipher suite mismatch assumed AUTHENTICATED in IBSS Missing Post-condition if dot1x Auth not supported assumed DISCONNECTED Deleted Post-condition if dot1x Auth not supported 8 Assumed STA at ACQUIRED state when EapolReq/Identity received (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) Missing Post-condition when STA fails to identify itself to another STA in IBSS Missing Pre-condition for 4-way key exchange assumed AUTHENTICATED 10 Missing Post-condition after the GwK's are installed assumed RSNA Missing Post-condition when cipher suites not present in IBSS assumed DISCONNECTED Missing Pre-condition for Disassociation/Reassociation/Deauthentication assumed 12 Missing Post-condition for Disassociation/Reassociation/Deauthentication assumed 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

8 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? STA [ DISCONNECTED] [ DISCONNECTED] [ dot11 ASSOCIATION ] [ dot11 ASSOCIATION ] dot11 Association Complete dot11 Association Complete [ CONNECTING ] ^ [ CONNECTING ] ^ EapolResp/Identity Received EapolReq/Identity Received EapolAcc/Challenge Received EapolSuccess Received 1st Message of 4 Way handshake Received [ AQUIRED ] [ AUTHENTICATING ] [ AUTHENTICATED ] [ KEY MANAGEMENT ] Synchronized ^ EapolAccept Received 1st Message of 4 Way handshake Sent Group Key Distribution Complete [ AUTHENTICATING ] [ AUTHENTICATED ] [ KEY MANAGEMENT ] [ RSN ASSOCIATED ] ^ Group Key Distribution Complete [ RSN ASSOCIATED ] Synchronized [ AUTHENTICATING ] (b) Authenticator (AP) ^ [ 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 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

9 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 i 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 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 AUTHENTICATION- 2 state is allowed since a Re-Request is legitimate during Pre- 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 Request 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

10 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 State 1 Unauthenticated Unassociated RSN Association or Reassociation Disassociation State 4 RSN Associated Deauthentication Successful MAC layer Class 1, 2 & 3 Frames except & Deauthentication Deauthentication Notification State 2 Authenticated Unassociated Disassociation Notification Successful Association or ReAssociation Class 1 & 2 Frames 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 i 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 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 Authenticator port is controlled Malacious Association STA is deliberately reverted back to DISCONNECTED State 5 Malacious Association STA is DISCONNECTED if RSN requirements are not met 5 Man-In-Middle AP goes to DISCONNECTED state if it does not choose to associate? Malacious Association STA DISCONNECTED if dot1x incapable 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 TKIP Recovery Use AES 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 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

11 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, 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 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

12 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 , ACM SOGMOBILE, Vol. 7, Jan. 2001, pp [2] Mead, N.R. McGraw, G. Wireless Security Future, IEEE Security & Privacy, July/Aug. 2003, pp [3] Dromey, R.G. From Requirements to Design: formalizing the key steps, Proc. 1 st International Conference on Software Engineering and formal methods, Sep. 2003, Brisbane, Australia, pp [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 [5] IEEE Std , Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, [6] Stubblefield, A. Ioannidis, J, Rubin, A.D. A key recovery Attack on the b Wired Equivalent Privacy Protocol (WEP)", ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004, pp [7] IEEE Std X-2001, Local and Metropolitan Area Networks Port-Based Network Access Control, June [8] Wi-Fi Alliance. Wi-Fi Protected Access (WPA), Version 2.0, April [9] Wi-Fi Alliance. Securing Wi-Fi Wireless Networks with today technologies, February, 2003 [10] IEEE Std i/D3.0, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications security enhancements, November [11] Wi-Fi Alliance. Wi-Fi is everywhere, April /WPA_NI_2003-Pres.pdf [12] Arbaugh, W.A. Shankar, N. Wan, J. Your Wireless Network Has No Cloths, IEEE Wireless Communications, Dec. 2002, pp [13] Mishra, A. Arbaugh, W.A. An Initial Security Analysis of the IEEE 802.1X Standard, Critical Infrastructure Grant, National Institute of Standards, Feb [14] Bellardo, J. Savage, S Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions, Proc. of the USENIX Security Symposium, August [15] Arbaugh, W. Housley, R. Security Problems in based Networks, Communications of the ACM, Vol. 46, No. 5, May 2003, pp [16] Sithirasenan, E. A Preliminary Analysis of the IEEE i WLAN Protocol, Masters Thesis, Griffith University, Australia, Oct AusCERT2005: Refereed R&D Stream 50