USING IDENTITY-BASED PRIVACY-PROTECTED ACCESS CONTROL FILTER (IPACF) TO AGAINST DENIAL OF SERVICE ATTACKS AND PROTECT USER PRIVACY Except where reference is made to the work of others, the work described in this thesis is my own or was done in collaboration with my advisory committee. This thesis does not include proprietary or classified information. _____________________________________________ Chun-Ching Andy Huang Certificate of Approval: _________________________________ J. David Irwin Professor Electrical and Computer Engineering _________________________________ Chwan-Hwa Wu, Chair Professor Electrical and Computer Engineering _________________________________ Fa Foster Dai Associate Professor Electrical and Computer Engineering _________________________________ Stephen L. McFarland Acting Dean Graduate School USING IDENTITY-BASED PRIVACY-PROTECTED ACCESS CONTROL FILTER (IPACF) TO AGAINST DENIAL OF SERVICE ATTACKS AND PROTECT USER PRIVACY Chun-Ching Andy Huang A Thesis Submitted to the Graduate Faculty of Auburn University in Partial Fulfillment of the Requirements for the Degree of Master of Science Auburn, Alabama August 7, 2006 iii USING IDENTITY-BASED PRIVACY-PROTECTED ACCESS CONTROL FILTER (IPACF) TO AGAINST DENIAL OF SERVICE ATTACKS AND PROTECT USER PRIVACY Chun-Ching Andy Huang Permission is granted to Auburn University to make copies of this thesis at its discretion, upon request of individuals or institutions and at their expense. The author reserves all publication rights. _______________________________ Signature of Author _______________________________ Date of Graduation iv VITA Chun-Ching Andy was born in December 1978, in Taipei, Taiwan. He graduated with Bachelor of Science degree in Computer Science from University Of British Columbia, Vancouver, Canada in 2003. Chun-Ching Andy Huang then entered Graduate School, Auburn University, in January 2004. v THESIS ABSTRACT USING IDENTITY-BASED PRIVACY-PROTECTED ACCESS CONTROL FILTER (IPACF) TO AGAINST DENIAL OF SERVICE ATTACKS AND PROTECT USER PRIVACY Chun-Ching Andy Huang Master of Science, August 7, 2006 (B.S., University Of British Columbia, Canada, 2003) 75 Typed Pages Directed by Chwan-Hwa Wu Denial of service (DoS)/Distributed DoS (DDoS) attack is an eminent threat to an authentication server, which is used to guard access to firewalls, virtual private networks and wired/wireless networks. The major problem is that an authentication server needs to verify whether a request is from a legitimate user and if intensive computation and/or memory resources are needed for verifying a request, then DoS/DDoS attack is feasible. In this thesis, a new protocol called Identity-Based Privacy-Protected Access Control Filter (IPACF) is proposed to counter DoS/DDoS attack. This protocol is an improvement of IDF (Identity-Based Dynamic Access Control Filter). The proposed protocol is stateless because it does not create a state for an authentication request unless vi the request is from a legitimate user. Moreover, the IPACF is stateless for both user and authentication server since a user and responder authenticate each other. A filter value, which is generated by pre-shared secrets, is sent in a frame and checked to see if the request is legitimate. Note that the process of checking filter value is not intensive computation. The filter value is tabulated in a table with user identity so that a filter value represents a user?s identity and only the legitimate user and authentication server can figure out the identity. When a filter value is from a legitimate source, a new filter value will be generated for the next frame. Consequently, the filter value is changed for every frame. Thus the privacy of both user and server are protected. The IPACF is implemented for both user and authentication server. The performance of the implementation is reported in this thesis. In order to counter more DoS/DDoS attacks that issue fake requests, parallel processing technique is used to implement the authentication server, which is divided into server 1 and server 2. Server 1 only checks the validity of the request filter value against the filter value table. If the request is legitimate, the request will be passed to server 2 for generating a new filter value; otherwise, the fake request is rejected by server 1. The performance comparison of dual server and single server is also reported. vii ACKNOWLEDGMENTS This thesis could not be done without the following individuals. First, I would like to thank my major advisor Dr. Chwan-Hwa Wu. Dr. Wu gives me great learning experiences. I could not finish this thesis with his guidance during my research. He also turns me into a more mature person. Second, I would like to thank Dr. J. David Irwin for giving me the great opportunity to be here and full support of my Master study. He always encourages me on my researches. I would also like to thank Dr. Fa Dai. He always concerns about my research every time we meet and gives me some feedbacks. For the past two years of study in Auburn University, it?s really a pleasure to be part of the research lab. Finally, I would like to dedicate this thesis to my parents Shun- Ming Huang and Chin-Hui Kao, my brother Chun-Ju Huang, and my fianc?e Szu-Hua Chen for their continuously support and endless love. viii Style manual or journal used: Bibliography conforms to the Institute of Electrical and Electronics Engineers Computer software used: Microsoft Word 2003, Microsoft Visio 2003 ix TABLE OF CONTENTS TABLE OF CONTENTS???????????????????????..?. ix LIST OF FIGURES??????????????????????????... xi LIST OF TABLES?????????????????????????....... xii CHAPTER ONE??????????????????..?????????? 1 INTRODUCTION?????????????????????????...?? 1 1.1 Current Problem??????.???????????????...?..?... 1 1.2 Motivation of the Proposed IPACF protocol????????????..?.... 2 1.3 Organization Of the Thesis?????????????????????. 3 CHAPTER TWO?????????????????????..??.????.. 5 RELATED WORKS??????????????????????????.... 5 2.1 Denial of Service (DoS)???.???????????????...?..?... .5 2.2 Current research???????????????????????..?.... 6 CHAPTER THREE????????????????????.?.??...??.. 10 PROTOCOL DESIGN?????????????????????????... 10 3.1 The Basic Concept of the Filter.??????????????????... 10 3.2 Design principle???????????????????????..?.. 12 CHAPTER FOUR?.???????????????????.?.??.............. 15 THE IDENTITY-BASED PRIVACY-PROTECTED?????????.?.....?? 15 ACCESS CONTROL FILTER (IPACF) PROTOCOL????????????.? 15 4.1 Notation for Identity-Based Privacy-Protected Access Control Filter...?..?? 15 4.2 Initial Configuration Stage?...??????????????????.... 17 4.2.1 Master keys and pre-shared secrets generation..???.?...???....... 17 4.2.2 Initial Filter Setup in a Responder as a Filter Table.?...????.?.... 19 4.2.3 User Login and Master Key Renew...????????????..? 23 4.3 Session Mutual Authentication Stage (SMAS)????????......??..? 26 x 4.4 Dynamic Data Communication Stage (DDCS)??...??????????. 32 4.5 The Summary of the Dynamic Data Communication Stage?...??????. 38 4.6 Privacy Protected Filter Exchange????...??...??????????. 43 CHAPTER FIVE?.??????????????.?????.?.??............... 47 IMPLEMENTATION AND PERFORMANCE EVALUATION????????? 47 5.1 Implementation????????????????????......?..??. 47 5.2 Performance?????..?...??????????????????..... 49 5.2.1 Performance in authentication??????...???.?...???....... 49 5.2.2 Performance in DoS attacks?????????.?...????.??. 52 5.2.3 Performance in dual server over single server?...????????... 54 5.3 Interoperability of IPv4 (user application) and IPv6 (responder)?..................... 55 CHAPTER SIX?.??????????????.?????.?.??.................. 57 CONCLUSIONS AND FUTURE WORKS?????????????????.. 57 BIBLIOGRAPHY???????????????????????????. 60 xi LIST OF FIGURES Figure 1: The Concept of Identity-Based Privacy-Protected Access Control Filter??. 11 Figure 2: Identity-Based Privacy-Protected Access Filter (IPACF) Overview????. 13 Figure 3: The Responder?s Truncated Function???????????????? 21 Figure 4: The User?s Truncated Function?????????????????..? 28 Figure 5: Session Mutual Authentication Stage Overview???????????? 29 Figure 6: The Dynamic Data Communication Stage?????????????.? 34 Figure 7: The Overview of Dynamic Data Communication Stage????????? 39 Figure 8: Filter Value Table Update Flowchart????????????????. 46 Figure 9: Diagram with dual servers design?????????????????.. 49 Figure 10: The SMAS for the responder??????????????????....51 Figure 11: The SMAS for the user?????????????????????. 52 Figure 12: User performs SMAS to the responder while attackers perform DoS attack 53 Figure 13: Comparison chart of IPACF and IDF in averaged rejection time????? 54 Figure 14: Comparison chart of dual server vs single server in average round trip time.. 54 Figure 15: UDP socket?????????????????????????... 56 Figure 16: UDP6 socket?????????????????????????. 56 xii LIST OF TABLES Table 1: Responder?s Dynamic Access Filter Table?????????????.? 21 Table 2: User?s Dynamic Access Filter Table??????????????...?? 28 1 CHAPTER ONE INTRODUCTION Authentication server is widely used to guard wireless access points, virtual private networks, firewalls and so on. Denial of service (DoS) or distributed DoS (DDoS) attacks floods the authentication server with fake packets and causes the server to exhaust its resources for processing fake packets. When the resources of the authentication server is exhausted, legitimate user?s authentication requests can not be responded. In this thesis, we propose a stateless authentication protocol, which allows the authentication server to check if the request is from a legitimate user and to commit computational resources only if the request is legitimate. This protocol protects the resources of an authentication server so that the resource consumption of DoS/DDoS attacks is minimized. 1.1 Current Problem The advancement in wireless network technology provides wireless access networks to the Internet. Authentication servers are used to defend the wireless access networks. Attackers can easily launch DoS/DDoS attacks to authentication servers and can disable the wireless access networks. The current 802.1x [1] and 802.11i [2] standards both still lack the ability to prevent the DoS/DDoS attacks to authentication servers and wireless 2 access points. Firewalls and virtual private networks suffer the same drawback that DoS/DDoS can easily halt the authentication functions [3]. The major problem of DoS/DDoS attack is that the authentication server (or responder) needs to validate that the request is from a legitimate user (or initiator). However, the authentication server only has a limited CPU computation power and restricted amount of memory. When attackers initiate sufficient requests, the authentication server cannot respond to legitimate requests. It is necessary to minimize the resource committed to a request before verifying the request is from a legitimate source. Ingress and egress filters based on IP address have been suggested to counter DoS/DDoS attacks. But a legitimate source IP address can be spoofed to launch DoS/DDoS attacks by sniffing the communication frames between the legitimate user and authentication server. 1.2 Motivation of the Proposed IPACF protocol To address the current problems, a protocol called Identity-Based Privacy-Protected Access Control filter (IPACF) is proposed. An identity based filtering is used instead of an IP address-based filtering. The IPACF is based on pre-shared secrets that are known by a user (initiator) and an authentication server (responder). Both user and responder generate a unique (one-time) filter value for each communication frame using pre-shared secrets. Only the user and responder have the necessary secrets to calculate the filter values. The filter value can be checked to make sure that the value is from a legitimate source. If the filter value is correct, then a new filter value is generated for the next frame; otherwise, the received frame is rejected. 3 Follow the concept of a stateless protocol ?Do not create any state or do expensive computation before you can ensure that the received frame is legitimate.? the concept of stateless server and stateless connection was proposed to defend against DoS. If the server authenticates the user and verifies the user?s filter value without keeping states, the authentication scheme will be stateless. Moreover, the protocol is stateless since a frame with an incorrect filter value is only checked and no other computation resource is committed. Only when the frame has a legitimate filter value, then resource will be committed for calculating next filter value. The privacy of the identity relies on the one-time filter value and the pseudo ID which are an indication of the user identity. Furthermore, the IPACF can prevent session hijacking, dictionary attacks and man-in-the-middle attacks using the secure master key exchange. 1.3 Organization of the Thesis This thesis is divided into six chapters. The first chapter provides the background information that is necessary to understand the rest of the work. The remaining chapters are organized as follows. In Chapter 2, we present the related work and current research to show the importance of proposed IPACF protocol. In Chapter 3, we propose a concept and the design goals for the new IPACF protocol. We also point out a couple of disadvantage and drawbacks about Wang?s IDF protocol [4]. In Chapter 4, we explain the details of how the proposed IPACF protocol creates a truly stateless protocol environment and defends against DoS/DDoS attacks. In Chapter 5, we implemented and simulated 4 Wang?s IDF protocol in the real-world implementation. We also describe the implementation and performance of the IPACF protocol and compare it with Wang?s IDF protocol; the compatibility of the IPACF protocol in IPv6 network is also described. Chapter 6 contains the conclusions and suggestions for future work. 5 CHAPTER TWO RELEATED WORKS 2.1 Denial of Service (DoS) The objective of DoS attack is to degrade services by flooding a network with faulty beacons, preventing legitimate traffic and causing systems not to respond. Denial of service relies on methods that exploit the weaknesses of the network and attempts to reduce the ability of a responder to service users [5]. DoS can be achieved by either overloading the ability of the target network, that causing a responder to neglect incoming traffic, or by sending network packets that causing target networks to behave unpredictably and crash. For example, one common form of DoS is Ping of Death, which generates and sends certain kinds of network messages that are technically unsupported but known to cause problems for systems that receive them. Other DoS attacks may simply "flood" a network with useless data traffic, rendering systems incapable by pretending as legitimate users. The main problem is: when a responder receives a request that requires verifying the request using system resources, the computation and memory storage gives an adversary a chance to launch a DoS attack. 6 2.2 Current research DoS attacks continue to be a critical threat. They can intervene critical services, prevent data transfer between devices, and decrease overall productivity. Because DoS attacks can be extraordinarily costly and harmful to internetworking environment, networks must proactively counteract these attacks. Authentication is a significant issue in establishing secure communication between the users and responders by identifying each other prior to accepting each other?s frames. Several works [8-14] have been proposed to prevent DoS attacks and to improve the security or the computational performance based on public-key signatures authentication scheme. Two password- based integrated schemes for user authentication and access control was proposed by Jan and Tseng [13], defined as the JT-1 and the JT-2 schemes, to administer the security administration functions with respect to both the computational cost and the communicational overhead efficiency. But both the JT-1 and the JT-2 schemes are not secure against an impersonation attack, an adversary can successfully fool the system to act as any other legitimate user, and take over all access rights granted to that user without being detected [14]. W. Aiello et al [8] provides a capability for perfect forward secrecy in order to efficiently defend against DoS attacks. Although the public-key signatures scheme can provide a certain level of security to resist a DoS attack, it is still vulnerable to DoS attacks on the first and third message flows [8][10]. Since the first flow is sent in clear text, the adversary can sniff the legitimate user?s identity and then spoof it to become a legitimate user and pass the identity check from the server. This process could lead to a DDoS attack. If the server need not check the identity of the user like J. Leiwo?s scheme [10], the adversary can randomly generate a request nonce to the 7 server for launching a DoS attack. This will cause the responder very busy in processing the spoofed requests sent from an adversary and has limited ability for legitimate users. In the third flow, the public-key signatures authentication scheme must verify the authenticity of the returned data that is sent from the legitimate uses. This step is vulnerable to a DoS attack, because an adversary can send out a plethora of faked signatures to the server for verification that will require system resources and cause buffer overflow. Zhiguo et al [12] proposed a PKC (Public Key Cryptosystem) based protocol which was combined with [8]?s key exchange protocol JFKi. The user identity protection has been added but this protocol is susceptible to DoS attacks on the first message flow that the nonce generated by the client and sent in clear text to the server. This message is not authenticated and could be sent by attackers to perform DoS attacks. DoS detection techniques has been brought up to reduce the threats [15][16]. These techniques and testing results provides insight into our ability to successfully identify DoS flooding attacks. But none completely solve the detection problem. The client puzzle is another technique that users are required to do a considerable amount of computation before consuming resources. The first client puzzle was used to defend against connection depletion attacks proposed by Juels and Brainard [6]. A user must solve the puzzle correctly in order to get service from a responder. Client puzzles were also proposed to similarly protect authentication protocols [7], which combined the stateless authentication protocols [19][20] with a client puzzle to address a DoS attack. In general, cryptographic puzzles have been employed for key agreement [21] and address the problem of junk e-mail [22]. The only implementation of a client puzzle in the context of transport layer security (TLS) was proposed by Dean [23]. Wang and 8 Reiter [24] proposed a puzzle auction that allows the client to determine the difficulty (bid) of the puzzle using their implementation within transmission control protocol (TCP). While the deployment of client puzzles in attack scenarios seems promising, but most proposed systems of this type have one basic shortcomings found by Waters [25]. The client puzzle mechanism itself can become the target of a denial-of-service attack. In most systems either the puzzle creation or verification operations (or both) require the server to perform a cryptographic hash computation [7][26][27]. This opens the possibility that the puzzle verification mechanism itself will be the target of a denial of service attack, in which an attacker floods the server with bogus puzzle solutions that the server has to process. Secure key exchange is also a critical issue in authentication scheme. Internet Key Exchange (IKE) is an Internet Protocol Security (IPSec) standard protocol used for establishing and maintaining security associations, and to ensure security for virtual private network (VPN) using secure key exchange [28]. Several works [8], [29], [30], [31], and [32] have reported that IKE is vulnerable to DoS attacks. The user identity can not be protected in IKE [8] and IKE is very vulnerable to untraceable DoS attacks against both computational and memory resources [32]. IKEv2 [33] was then proposed to replace the original IKE. Some work has been done towards addressing, or at least examining, the DoS problems found in IKE [9][34]. Other protocol design that defend against DoS attacks include stateless cookies[36], forcing clients to store server state, rearranging the order of computations in a protocol [37], and the use of a formal method framework for analyzing the properties of protocols with respect to DoS attacks [38]. 9 Any protocol for a server commits expensive computations or to store the protocol state prior to the client authentication is vulnerable to DoS attacks [7][19]. The advantages of being stateless, at least in the beginning of a protocol run, were recognized in the security protocol context in [19] and [20]. 10 CHAPTER THREE PROTOCOLS DESIGN A new protocol, called the identity-based, privacy-protected access control filter (IPACF), has been proposed to defend DoS/DDoS attacks. The design of the proposed protocol is described as follows. 3.1 The Basic Concept of the Filter The IP address-based filter will not prevent DDoS attacks from coming into a network with a valid source IP address. The IP address-based filter contains a fixed set of IP addresses and cannot change dynamically to protect the IP address from being sniffed and spoofed by an adversary. An adversary can spoof source IP addresses from legitimate users or a subnet?s valid address range in order to pass through the IP address- based filter and launch a DoS attack. Using an identity-based filter, all users have their unique filter values and pseudo ID generated from their master pre-shared secret keys. The master key is protected by two-factor feature keys. The user?s ID and password are memorized by the user, and nonce and timestamp are generated by the user?s system [4]. Only legitimate users or responders have exact secrets to generate their filter values so that subsequent frames can pass through the access control filter. Otherwise, the prohibited frames will be rejected by the filter. To avoid sniffing and spoofing, the filter 11 values cannot be reused, and thus the IPACF filter value should be changed dynamically. For the IPACF protocol, only the received frames that match the users? or responders? filter values will be allowed to use system resources as shown in Figure 1. The system performs computations only after the frames have passed the privacy protected access control filter, F(t, P id(t) ), which is a time-dependent function that changes every frame (P id(t) is the pseudo ID). If received frames do not match the users? or responders? filter value, they will be rejected by the privacy protected access control filter. At this point, the computer commits only the resources necessary to compare filter values. Similar access control techniques are being used in packet filters, routers and firewalls and are well-known for their processing speed [4]. Figure 1: The Concept of Identity-Based Privacy-Protected Access Control Filter: if F(t, P id(t) ) matches the filter value, then E[Data] (encrypted data) is allowed to use system resources for decryption. 12 3.2 Design principle With the current designed protocol, it is clear that Wang?s IDF [4] has several weaknesses that are related to the server system resources. The following design principles were improved in the thesis. ? Efficient two frames used in the session mutual authentication stage (SMAS) ? Stateless protocol for both the user and the responder in SMAS ? User privacy is protected ? Capable of being implemented on a firewall, router, access point and authentication server ? Prevention of resource (memory and CPU) exhausting DoS and DDoS attacks, session hijacking, dictionary attacks, and men-in-the-middle attacks on both sides The hash based message authentication codes (HMAC) is used here because the computational cost for a keyed hash function is less than that for Public Key Infrastructure (PKI) based or signature-based schemes, both of which are more vulnerable to DoS attacks [7]. Confidentiality for packet transmissions can be provided using techniques that utilize symmetric key cryptography. Encrypting the message with the secret keys shared among the users and the responders. The Advanced Encryption Standard (AES) with HMAC [39] is used to guarantee the confidentiality and integrity of data during communication. 13 PC MC IA56K INSERT THIS END P Uid(0) , F R(0) , E[ N U ,T NU ] User Responder 1.Check filter F R(0) 2.Generate user's filter value F U(0) 3.Update filter value F R(0) to F R(1) Access filters 1.Check filter F U(0) 2.Generate responder's filter value F R(1) 3.Update filter value F U(0) to F U(1) Access filters 1.Generate F R(0) 2.Generate N U, T UN 3.Generate user's filter value F U(0) 1.Check filter F R(1) 2.Generate user's filter value F U(1) 3.Update filter value F R(1) to F R(2) 1.Check filter F U(1) 2.Generate responder's filter value F R(2) 3.Update filter value F U(1) to F U(2) P Rid(0) , F U(0) , E[ Data, P Uid(1) ] P Uid(1) , F R(1) , E[ Data, P Rid(1) ] P Rid(1) , F U(1) , E[ Data, P Uid(2) ] Figure 2: Identity-Based Privacy-Protected Access Filter (IPACF) Overview The Identity-Based Privacy-Protected Access Filter is derived from a user?s and responder?s pre-shared secrets. Each user has a unique filter associated with a particular responder. It is a time-dependent filter that changes with every frame. Only legitimate users and responders can update their filters and confirm corresponding filter values, as illustrated in Figure 2. The ID and password for user and responder are protected by human memory, never stored on a device, or sent in traffic. These precautions theoretically guarantee IDs and passwords will not be lost. When a responder receives the first frame from a user, the IPACF can determine the user ID by comparing the received filter value to the responder?s filter table using the pseudo ID. Then the 14 Identity-Based Privacy-Protected Access Control Filter is triggered for a particular user. This time-dependent scheme involves both the user?s secret and a timestamp sent from the user. The anonymity of the user?s ID protects the user?s privacy in wired/wireless networks. 15 CHAPTER FOUR THE IDENTITY-BASED PRIVACY-PROTECTED ACCESS CONTROL FILTER (IPACF) PROTOCOL The Identity-Based Privacy-Protected Access Control Filter (IPACF) protocol consists of three stages. The first stage is the initial configuration stage (ICS). During this stage, the master secret keys of a user and responder are generated and exchanged via a secure channel as pre-shared secrets. Using the pre-shared secrets, the initial access control filter values for all legitimate users will be generated and stored on a responder filter table for authenticating legitimate users. The second stage is the session mutual authentication stage (SMAS) used by users and responders to identify each other. The third stage is the dynamic data communication stage (DDCS). The computational for all stages should be designed with the stateless requirement in order to prevent DoS/DDoS attacks. To keep the notations simple and easy to understand, the discussions of the IPACF protocol are based on one user with a responder. 4.1 Notations for Identity-Based Privacy-Protected Access Control Filter P R T R N Ri A responder?s secret key memorized by an administrator A timestamp generated by responder?s system when an administrator assigns the P R An initial nonce generated by responder?s system when P R is assigned 16 K R U id U id P Uid P Rid P u T u N ui K U N i T KU N R T NR f R(t) f U(t) F R(t) F U(t) MAC R(t) MAC U(t) S Ri S Ui S R(t) Master secret key of a responder generated by a keyed hash function during the ICS User?s identifier Responder?s identifier Pesudo identifier for user Pesudo identifier for responder User password, typed in for each login session and not stored in the device A timestamp generated by a user?s system when a user is assigned a password An initial nonce generated by a user?s system when P u is assigned Master secret key of a user generated by a keyed hash function during the initial stage A random number is chosen by a user. This number remains the same during the user?s login session. It will be updated automatically after a new K U is generated and used for the next login session. Timestamp when K U is generated A nonce is generated by a responder. It is encrypted using the AES when sent to challenge a user during session mutual authentication stage. Timestamp when a responder?s nonce N R is generated A 128-bit seed from a responder?s truncated function used to update filter F R(t) A 128-bit seed from a user?s truncated function used to update filter F U(t) Access filter stored in a responder?s filter table to filter the frames from users Access filter stored in a user?s filter table to filter the frames from a responder The output of HMAC-SHA-512, which is used to generate the filter for a responder The output of HMAC-SHA-512, which is used to generate the filter for a user A responder?s initial seed during the initial configuration stage A user?s initial seed during the initial configuration stage A responder?s seed used to update the frame key K RF(t) 17 S U(t) N U T NU K RF(t) K? RF(t) K UF(t) K? UF(t) MAC RF(t) MAC UF(t) T RF(t) T UF(t) N INI T INI K R(j) K U(j) h A user?s seed used to update the frame key K US(t) A nonce is generated by a user. It is encrypted using the AES when sent to challenge a server during the mutual authentication stage. Timestamp when a user?s nonce N U is generated A responder?s frame key for AES encryption A responder?s HMAC key for integrity check A user?s frame key for AES encryption A user?s HMAC key for integrity check A 256-bit MAC that contains K RF(t) and K? RF(t) that are used for responder as AES encryption key and HMAC key, respectively A 256-bit MAC that contains K UF(t) and K? UF(t) that are used for user as AES encryption key and HMAC key, respectively A timestamp generated by a responder when updating its filter value A timestamp generated by a user when updating its filter value A nonce is generated by a responder. It is exchanged in initial configuration stage via secured channel for generating the first hash value of mutual authentication stage. A timestamp generated by a responder when nonce N INI is generated Updated master secret key of a user for session j generated by a hash function for the next session Updated master secret key of a responder for session j generated by a hash function for the next session HMAC operation. 18 4.2 Initial Configuration Stage 4.2.1 Master keys and pre-shared secrets generation K U , K R , and N i , are the pre-shared secrets of a user and a responder and are stored on both systems. The pre-shared secrets K U , K R , and N i could be delivered between a user and responder via a secure channel or could be used by a trusted third party to secure the delivery. The actual techniques are beyond the scope of this paper. K U and K R are the master secret keys of a user (initiator) and responder, respectively. K U = h () ui N [ U id || P u || T u || N ui ] ( )1 K R = h () Ri N [ R id || P R || T R || N Ri ] ( )2 U id and P u are the user?s ID and password, respectively, required for each login session, and should not be stored on any system. N ui and T u are generated automatically by the user?s system when a user types in the U id and P u during the system ICS. The user system generates a different nonce N ui and timestamp T u to ensure a user?s master key K U is refreshed. N ui is only known by the user?s system and will be the input key for the HMAC function in equation (1). K U is a user?s master key generated by the HMAC function and must be stored in both the user?s and responder?s system. The R id and P R are the responder?s ID and password, respectively, and assigned by a system administrator during the ICS. A responder?s initial nonce N Ri and timestamp T R are known only by the responder?s system. They are generated automatically by a system when the system administrator assigns the P R and R id for a responder. N Ri is an input key for the HMAC function and used to generate the responder?s master key K R as shown in equation (2). Both the user?s password P u and the responder?s password P R are dictionary attack resistant because they are protected by the nonce and timestamp that are known only by 19 the systems. The user or responder knows half (U id , P u and R id , P R ) of the master secret and their systems know the other half (N ui , T u and N Ri , T R ). This mechanism is called a two-factor feature and widely used to protect the real user?s password and ID from dictionary attacks [4]. N i is a random number that must be chosen by a user during the ICS and stored in both the user?s and responder?s systems; this number remains constant during the same session for the user. After the ICS, N i can be updated locally by equation (3) while the old N i will be used in a HMAC function to generate a new N i for a new login session [4]. N i ?h () iu NK ? [ U id || K U || T KU || N i ] ( )3 The nonce N INI and the time stamp T INI will be generated by the responder while a user and responder are exchanging the pre-shared secrets K R , K U , and N i via a secured channel. N INI and T INI are used in ICS for a user and responder to generate the initial access control filter value F R(0) . The pseudo identifier P Uid and P Rid are assigned by the user and responder respectively to hide their real identities. P Uid and P Rid will be changed for each frame to ensure the privacy protection in IPACF protocol. During the ICS, [R id , N i , K U , K R , N INI , T INII , P Uid , P Rid ] is stored on the user?s system and [U id , N i , K U , K R , N INI , T INII , P Uid , P Rid ] is stored in the responder?s system as pre-shared secrets, which are used to generate the filter value and frame key. 20 4.2.2 Initial Filter Setup in a Responder as a Filter Table After a user and responder have saved the pre-shared secrets in their systems, the responder must generate a filter table for all of its legitimate users. The user will also be able to create the initial access control filter value using the equations (3), (4), and (5). To create the initial filter table, the random nonce N INI and timestamp T INI will be used. To create the responder?s access control filter, two calculation steps are required as outlined in equations (4) and (5). h () Ri KN ? [ N i || N INI || T INI ] ? S Ri ( )4 K R is the master key of the responder and is a group key known by all of its legitimate users in IDF protocol proposed by Wang [4]; however, K R is a pairwise key shard by a user and a responder in this thesis. Then the input key for the HMAC function is formed by K R XOR with N i, which is chosen by a particular user. Different users have different N i and thus different S Ri . S Ri is a 512-bit output of the HMAC function as shown in equation (4). It is a responder?s initial seed and used only at the ICS. This seed S Ri is used as an input key for the HMAC function in equation (5). The purpose of the formula in equation (4) is to generate different seeds for a particular user, given the user?s N i , and use N i , N INI , and T INI to avoid reusing the seed. Because the input keys for the HMAC function are never reused, the output of the HMAC function in equation (5) is made very secure by avoiding dictionary attacks [18][35]. h () [] INIi Ri NN S ? [ U id || K U || N i || N INI || T INI ] ? MAC R(0) ()5 21 [N i ? N INI ] is the number of rounds used to conduct the hash function. In consideration of performance, the number of rounds is recommended to be truncated to 10 bit, which means that the number of rounds is limited to between 0 and 1023. MAC R(t) is a 512-bit keyed hash value and is truncated in three parts, including the 128 most significant bits f R(t) and the 128 least significant bits S R(t) , as shown in Figure 3. t is the index of a time-dependent function, and t=0 is the responder?s first seed used to generate the first access control filter and frame key [4]. Figure 3: The Responder?s Truncated Function f R(0) is a seed used to generate a 160-bit responder?s access control filter F R(0) using equation (6) . The length of the HMAC function used to generate the access control filter is recommended to be a 160-bit HMAC-SHA-1, but different applications may vary. F R(0) is the initial access control filter value stored in a responder?s device. The first frame sent from the user must match this value so that subsequent parts of this frame can be admitted into the responder?s system. S R(0) , which is the 128 least significant bits of MAC R(0) , is a seed used to update the frame key and then generate the new access filter for the next frame. 22 h () Ri S [ K U || N i || MAC R(0) || T INI || f R(0) ] ? F R(0) ( )6 The responder can then create a table and store the identity-based filters and all the necessary key information as shown in Table 1. P Uid Flag U id P Rid Access Filter Hash Value Frame Key Packet counter Idle Time F R(0) MAC R(0) Table 1: Responder?s Dynamic Access Filter Table Each row specifies the information for a particular user. The packet counter will accumulate all the received frames that pass the access control filter for a user?s login session. The packet counter will repeat the process for each new login session. This feature aids the responder in monitoring any abnormal traffic from the user and thus helps prevent a DDoS attack. The idle time is represented by the time that the packet counter does not increase while the user remains connected. The responder should ask the user to re-authenticate if the idle time is too long. On the other hand, the users can generate the initial access control filter value F R(0) using equations (4), (5), and (6) that introduce a complete stateless configuration. In Wang?s IDF protocol [4], the user side was not completely stateless in the mutual authentication stage. The user?s access control filter will be created after the user receives the beacon from the responder and can derive the responder?s nonce N R , and timestamp T NR , by using the responder?s pre-shared master key K R . The IDF protocol requires one more frame in comparison to IPACF in the mutual authentication stage for the responder to broadcast the beacon to the legitimate users who can decrypt the beacon 23 encrypted with AES encryption. Nonce N R and timestamp T NR will be the contents of the beacon. N R and T NR will be the secrets for the user to generate filter value F R(0) . The responder will pre-generate the filter value ahead of time in Wang?s IDF protocol [4]. N R and T NR are broadcast in the beacon by the responder; a user receives and generates the same filter value as the responder. But there is one problem: what happens if the users do not log in during this period of time? The responder will have to regenerate F R(0) for every user if N R and T NR are changed, and this is a computationally expensive process. It is desirable that a protocol does not require every user to calculate F R(0) periodically. Using equations (4), (5), and (6) will make the IPACF protocol for both the user and the responder stateless after ICS. In addition, IPACF protocol has one less frame to complete in SMAS in comparison to IDF since there is no need of the beacon frame. Because of the complete stateless configuration in IPACF, the user protocol becomes stateless in the SMAS, the user will not have to depend on the beacon broadcasted by the responder. At this point, the ICS is completed. The pre-shared secrets and initial filter value F R(0) are stored in both user and responder, as well as the information for all of its legitimate users, in a filter table. 4.2.3 User Login and Master Key Renew Session Login K U , K R and N i , are the pre-shared secrets stored on a user?s system. When a user wants to log in, the user must type in the user ID and password. The user?s system has stored N ui and T u from the initial setup; therefore, the user?s system can generate a K U 24 based upon the password and ID that the user entered using equation (1). If this K U matches the pre-stored K U , then the system identifies that the user as a legitimate one. If this K U does not match the pre-stored K U , after a reasonable number of trials, the user?s system should be locked. In this case, no filter values will be generated for the particular user to prevent an on-line password guessing attack. Master Key Renewal The K U and N i should be refreshed for every login session. The N i will be updated using equation (3). During each login session, the pre-stored K U is matched to ensure that he is a legitimate user, and the system will generate a new nonce and timestamp. Given the new nonce and timestamp, the system performs a calculation using equation (7) to obtain the new K U(j) for session j. The new K U(j) and N i for the next login session will be encrypted using the AES and then sent to the responder during communication. Wang?s IDF [4] on a fixed master key K R means that the responder must uses the same key to encrypt the packet. All users must use the same master key K R to decrypt packets. Since all users have the same K R , they not only have the ability to encrypt packets, but also have the capability to pretend to be a responder, and perform malicious actions. Therefore, K R does not provide the essential security. Furthermore, the master key K R will not be updated unless ICS is performed: this problematic feature is the most serious drawback in Wang?s IDF protocol. If ICS is necessary to perform updating master key K R , all legitimate users will have to perform ICS at the same time, which means all legitimate users need to be synchronized to change K R while ICS is performed. A legitimate user will not be able to update the master key K R unless the user creates a 25 secured channel and updates the master key K R with the responder individually; otherwise, the legitimate user will not be able to decrypt any beacon sent by the responder in the mutual authentication stage. An entire group of users should not be responsible for updating master key K R(j) . Legitimate users should have the flexibility of performing ICS, whenever necessary. On the other hand, having a pairwise master key K R(j) for each legitimate user will avoid malicious actions from other legitimate users. IPACF protocol will be able to set up pairwise master keys with every legitimate user, and the master secret keys will be exchanged between the user and the responder in every session. K U(j+1) = h () ui N [ U id || P u || N u || T NU || K U(j) ] j = 1, 2, 3? ()7 K R(j+1) = h () Ri N [ R id || P R || N R || T NR || K R(j) ] j = 1, 2, 3? ()8 In equations (7) and (8), K U , K R , and N i are the pre-shared secrets of a user and a responder and are stored on both systems and j is the index of session number. U id and P u are the user?s ID and password, respectively, required for each login session and should not be stored on any system. N u , T NU , N R , and T NR are nonce and time stamp generated for each session master key update and stored in both the user?s and the responder?s systems. K R(j) and K U(j) are set for each session during which a user logs in and logs out. For each login session, the system generates a different nonce N u , N R and timestamp T NU , T NR automatically to ensure that both a user?s master key K U and a responder?s master key K R are not reused before. K R and K U are used as input key for the HMAC function in 26 equation (7) and (8). The purpose of master key renewal is to provide authenticated keying material in a protected manner. Each user will have a pairwise master key K R to avoid malicious actions from other legitimate users and the master key K R(j) will be exchanged between the user, and the responder in every session. We introduced the secured master secret key exchange (SMSKE) in ICS. The idea of SMSKE is to negotiate and provide authenticated keying material for security associations in a protected manner. SMSKE will be performed in the last frame of the SMAS and the first frame of the DDCS. After the secured authentication has been initiated, the user and the responder have identified each other; a secured channel is created after SMAS using Advanced Encryption Standard (AES) encryption and HMAC message authentication code for integrity check. The SMSKE will not only decrease the communication cost using a secured channel, but also improved the security of Wang?s IDF protocol [4] by using dynamic master key K R(j) and K U(j) for each session while IDF must used a fixed master secret key K R . The IPACF protocol is based on the legitimate user?s pre-shared secret and not their IP address in order to avoid an IP spoofing attack. The IPACF filter is not a fixed value filter. The filter values vary with every frame by both the user and the responder to prevent sniffing and replay attacks. Perform SMSKE will make the result of secure master key update on both user and responder after every single success SMAS. All the legitimate users will have a unique responder master key K R(j) that will increase the randomness of both master keys for the future SMAS. 27 4.3 Session Mutual Authentication Stage (SMAS) Following the initial configuration stage, two processes will be accomplished by a user before the user initiates the SMAS. First, both the responder and the user will be able to generate the same F R(0) using equations (4), (5), and (6). F R(0) is a 160-bit responder?s filter value and will be sent to the responder to check its access filter after the second step. Second, before a user initiates SMAS, a user will generate a user?s nonce N U and a timestamp T NU for that nonce to authenticate the responder and also create the user?s initial dynamic access filter. To create this filter, two rounds of calculation are required as outlined in equations (9) and (10). h () iU NK ? [ N i || N INI || N U || T NU ] ? S Ui ( )9 h () [] Ui Ui NN S ? [ U id || K U || N i || N INI || N U || T NU ] ? MAC U(0) ()10 The message authentication code will be generated with HMAC-SHA1. SHA1 is considered cryptographically stronger than MD5 even it takes more CPU cycles to compute. HMAC-SHA1 is also recommended in IPSec where the slightly superior security of SHA1 over MD5 is important [17]. S Ui is a 512-bit output of the HMAC function in equation (9) and will be used as an input key for the HMAC function in equation (10). It is a user?s initial seed and is only used in the initial configuration stage. This seed will be changed for every login session by the user because of varying properties of K U , N i , N U , and T NU . The primary aim of the formula in equation (9) is to generate different seeds for every login session to avoid reuse of the filter values. 28 [N i ? N U ] is the number of rounds employed in conducting the hash function, and from a performance perspective, should be truncated to 10 bits. Therefore, the number of rounds is limited to between 0 and 1023. MAC U(t) is a 512-bit keyed hash value truncated in three parts, including the 128 most significant bits f U(t) and the 128 least significant bits S U(t), as shown in Figure 5. t is an index for a time-dependent function, and t=0 is the user?s first seed that is used to generate the first access control filter and frame key [4]. Figure 4: The User?s Truncated Function f U(0) is a seed used to generate a 160-bit user?s access control filter F U(0) , as illustrated in equation (11). F U(0) is a user?s first access control filter value stored on the user?s system and is used for checking the frames sent from a responder. If the frame does not match the filter, it will be blocked by the user?s system. S U(0) is a user?s first seed used to update the frame key and generates the new access filter for the next frame. Once the user generates F U(0) , an access filter table will be created as shown in Table 2, to store the filter value and other information. h () Ui S [ K U || N U || MAC U(0) || T NU || T INI || f U(0) ] ? F U(0) ()11 29 P Rid Flag R id P Uid Access Filter Hash Value Frame Key Packet counter Idle Time F U(0) MAC U(0) Table 2: User?s Dynamic Access Filter Table PC MC IA 56K IN SER T THIS EN D User Responder 1.Check filter F R(0) 2.Figure out F U(0) 3.Update the filter to F R(1) Access filters Check filter Access filters 1.Figure out F R(0) , and generate N U , T NU 2.Generate the User's filter F U(0) Session Mutual Authentication Stage Frame 1 Frame 2 P Uid(0) , F R(0) , EAES(K U )[N U , T NU ] P Rid(0) , F U(0) , EAES(K RF(0) )[Data, T RF(1) , K R(j) , P Uid(1) ] Figure 5: Session Mutual Authentication Stage Overview Frame 1 U ? R : P Uid(0) , F R(0) , EAES(K U )[N U , T NU ] A legitimate user will be able to perform SMAS as the user desires. After the responder receives Frame 1, the responder will perform three steps: First, the responder will check F R(0) to see if F R(0) matches one of the filter values in the filter value table. If there is a match, the responder will know the user?s ID and K U in accordance with the received filter value. The responder will also identify the user as legitimate and then pass the encrypted data to the system for decryption to obtain N U and T NU . If Frame 1 matches the value in the responder?s filter table, the responder has completed half of the SMAS for identifying a legitimate user. If the received filter value F R(0) does not match 30 the responder?s filter values, the responder should block this frame and stop the session. Second, equations (9), (10), and (11) are used to derive S Ui , MAC U(0) , f U(0) , S U(0) , and F U(0) . Third, generate a timestamp T RF(1) , and update the responder?s access filter table for the next frame using the previous secret MAC R(0) to generate a new MAC R(1) from equation (12). f R(1) and S R(1) will be truncated from MAC R(1) . f R(1) is a new seed that is used to update the responder?s access control filter from F R(0) to F R(1) using equation (14). S R(1) is a new seed that is used to update the responder?s frame key generation function K RF(t) for the next frame [4]. h () )0(RF MAC [ K R || K U || N i || N INI || MAC R(0) || T RF(1) ] ? MAC R(1) ()12 MAC RF(t) is the generation function for the responder?s frame key. When t=0, as shown in equation (13), MAC RF(0) is the secret used by the responder to generate MAC R(1) to update the access filter from F R(0) to F R(1) for the next frame using equations (12) and (14). K RF(0) and K? RF(0) will be truncated from MAC RF(0) with 128 most significant bits and 128 least significant bits, respectively. K RF(0) is a frame key used by the AES to encrypt the data. K? RF(0) is a new key used in HMAC for data integrity. The encrypted data, with filter value F U(0) , will be sent to the user after the responder updates the filter table. h () )( jR K [ S Ri || S R(0) || T INI || N INI || K U || K R ] ? MAC RF(0) ()13 F R(1) is a new access control filter value, which is stored in the responder system and used for checking the next frame that is sent from the user. 31 h () )0(RF MAC [ K U || N i || MAC R(1) || T RF(1) || f R(1) ] ? F R(1) ()14 Frame 2 R ? U : P Rid(0) , F U(0) , EAES(K RF(0) ) [Data, T RF(1) , K R(j) , P Uid(1) ] After the responder has authenticated the user in Frame 1, the master secret key for the next session, K R(j) will be sent to the user in this frame. When the user receives Frame 2, three steps are performed: First, check F U(0) to see if it matches the filter value. If there is a match, most likely this frame was sent from the responder, and then the encrypted data, T RF(1) and K R(j) can be decrypted using the key K RF(0) . Since the user knows the same secrets S Ri , S R(0) , T INI , K U , and K R as the responder, the user can perform the same calculation to derive secret MAC RF(0) by using equation (13). K RF(0) (128-bit AES key) and K? RF(0) (128-bit HMAC key) can be truncated from MAC RF(0) and the user is able to decrypt the data using frame key K RF(0) to obtain the timestamp T RF(1) and K R(j) . Second, use this secret MAC RF(0) and the timestamp T RF(1) to derive MAC R(1) , f R(1) , S R(1) and F R(1) by using equations (12) and (14). F R(1) is a filter value that will be sent to the responder for checking. S R(1) is a seed used to update the responder?s secret from MAC RF(0) to MAC RF(1). The user must also store this seed to update and synchronize the responder?s secret in the future. In addition, the user must update the K R ; original K R(j-1) will be replaced by K R(j) . Third, the user will update the access filter from F U(0) to F U(1) to check the next frame. Two rounds are required to update the access filter: First Round: Generate the user?s frame key as follows: h () )( jU K [ S Ui || S U(0) || N i || N INI || T NU ] ? MAC UF(0) ()15 32 MAC UF(t) is the generation function for the user?s frame key. When t = 0, as shown in equation (15), MAC UF(0) is the secret employed by the user to generate MAC U(1) to update the access filter from F U(0) to F U(1) for the next frame using equations (16) and (17). K UF(0) and K? UF(0) will be truncated from MAC UF(0) with 128 most significant bits and 128 least significant bits, respectively. K UF(0) is a frame key used by the AES to encrypt the data. K? UF(0) is a key used in HMAC for data integrity. The encrypted data, with filter value F R(1) , will be sent to the responder after the user updates the filter table. Second Round: Calculate the new MAC value and update the access filter as follows: h () )0(UF MAC [ K U || N i || N INI || MAC U(0) || T UF(1) ] ? MAC U(1) ()16 f U(1) and S U(1) will be truncated from the MAC U(1) in the same manner. f U(1) is a seed used to generate a 160-bit user?s access control filter F U(1) using equation (17). F U(1) is a new user?s access filter and is stored in the user?s access filter table for checking the next frame. S U(1) is a new seed that is used to update the user?s secret MAC UF(t) , from MAC UF(0) to MAC UF(1). h () )0(UF MAC [ K U || MAC U(0) || T UF(1) || f U(1) ] ? F U(1) ()17 After the user identifies the responder, the SMAS for the IPACF protocol is completed. The user will start Dynamic Data Communication Stage (DDCS). 33 4.4 Dynamic Data Communication Stage (DDCS) In the DDCS, the filter value is changed with every frame. Because the responder must process a high volume of traffic, the cost of computation at this stage should be less than other stages. This stage is called the dynamic data communication stage because at this stage, the user and the responder need not generate the nonce to identify each other. The amount of system computation is also less than that required in the SMAS because fewer rounds of the hash function are performed for every frame. To enhance security, however, a time-dependent scheme is used at this point to refresh the frame key and update the filter for both the user and the responder. The master key will be also updated in the first frame of DDCS. In the DDCS, both the access control filter values of the responder and the user are changed dynamically in every frame. The advantage of this approach is that an adversary is unable to predict the dynamic access filter value for the next frame. Only the legitimate user and responder that can match access filter values are allowed to use system resources. During the DDCS, the user and responder identify each other continuously to match the access filter. This mechanism prevents both the middleman attack and session-hijack because an adversary is unable to guess the filter values and frame keys. If a frame is lost in this stage, a re-transmission by UDP will maintain the connectivity. If a connectionless link is being used, then the SMAS must be carried out again to maintain high security for the re-established link. 34 PC MC IA56K INSERT THIS END P Uid(1) , F R(1) , EAES(K UF(0) )[Data, T UF(1) , K U(j) , P Rid(1) ] P Rid(1) , F U(1) , EAES(K RF(1) ) [Data, T RF(2) , P Uid(2) ] P Uid(2) , F R(2) , EAES(K UF(1) )[Data, T UF(2) , P Rid(2) ] Figure 6: The Dynamic Data Communication Stage In the DDCS, three steps are required on both sides for responders and users. First, check the access filter when a frame is received. Second, determine the filter values on the other side. Third, update the access control filter for the next frame. For example, the following Frame 3 and 4, are the first and second frames for the DDCS as shown in Figure 6. Frame 3 U ? R : P Uid(1) , F R(1) , EAES(K UF(0) )[ Data, T UF(1) , K U(j) , P Rid(1) ] In the first frame of DDCS (Frame 3), the responder will perform three steps: First verify the F R(1) from the user based on the pseudo ID P Uid(1) . If there is a match, the 35 responder will then decrypt data, T UF(1) , and K U(j) . Since the responder knows the same secrets S Ui , S U(0) , T NU , N i , and N INI as the user, the responder can perform the same calculation with the equation (15), which to derive secret MAC UF(0) . Then, the responder is able to get the frame key K UF(0) and decrypts the data to obtain the timestamp T UF(1) and K U(j) . Second, using this secret MAC UF(0) and the timestamp T UF(1) to derive MAC U(1) , f U(1) , S U(1) , and F U(1) . The responder must also update the K U(j) , original K U(j-1) will be replaced by K U(j) to become the new K U . Third, the responder will generate a timestamp T RF(2) and update the responder?s access control filter from F R(1) to F R(2) and pseudo ID from P Uid(1) to P Uid(2) , check the next frame sent from the user using equations (18), (19) and (20). Two rounds are required to update the access control filter: First Round: the new responder?s frame key generation h () )( jR K [ S R(0) || S R(1) || K R || K U || T RF(1) ] ? MAC RF(1) ()18 MAC RF(1) is a new responder?s secret which replaces MAC RF(0) . MAC RF(1) is used by the responder to generate MAC R(2) to update the access control filter F R(1) to F R(2) . This secret will be truncated into 128-bit K RF(1) and 128-bit K? RF(1) . K RF(1) is used as a new frame key for AES to encrypt the data when the frame is sent to the user; K? RF(1) is a new key used in HMAC for data integrity. Second Round: Calculate the new MAC value and update the access filter h () )1(RF MAC [ K R || K U || N i || N R || MAC R(1) || T RF(2) ] ? MAC R(2) ()19 36 f R(2) and S R(2) will be truncated from MAC R(2) using the method as shown in Figure 3. f R(2) is a new seed used to update the responder?s access control filter from F R(1) to F R(2) , as illustrated in equation (20). h () )1(RF MAC [ K U || N i || MAC R(2) || T RF(2) || f R(2) ] ? F R(2) ()20 F R(2) is a new responder?s access filter and is stored in the responder?s access filter table for filtering the next frame. S R(2) is a new seed that is used to update the responder?s secret MAC RF(1) to MAC RF(2) . When the responder receives further frames from the user, the responder will repeat the same three steps outlined for Frame 3. Frame 4 R ? U : P Rid(1) , F U(1) , EAES(K RF(1) ) [Data, T RF(2) , P Uid(2) ] After the user receives Frame 4 from the responder, the user then performs these three steps: First, checks F U(1) to see if it matches the access control filter value based on pseudo ID P Rid(1) . If there is a match, the user can verify that this frame was sent from the responder, and then pass the encrypted frame to the system for decryption using the frame key K RF(1) . Since the user knows the same secrets S R(0) , S R(1) , K U , K R , and T RF(1) as the responder, the user can perform the same calculation with the equation (18) as the responder to derive MAC RF(1) . Then, the user is able to get the frame key K RF(1) to decrypt the encryption data and the timestamp T RF(2). Second, use this secret MAC RF(1) and timestamp T RF(2) to perform the same calculation with equations (19) and (20) as the responder to derive MAC R(2) , f R(2) , S R(2) , and F R(2) . F R(2) is a filter value that will be sent to the responder for checking. S R(2) is a seed used to update the responder?s secret from MAC RF(1) to MAC RF(2). Third, the user will generate a timestamp T UF(2) and update the 37 user?s access control filter from F U(1) to F U(2) and pseudo ID from P Rid(1) to P Rid(2) to check the next frame sent from the responder using equations (21), (22) and (23). Two rounds are required to update the access control filter: First Round: the new responder?s frame key generation h () )( jU K [ S U(0) || S U(1) || K R || K U || T UF(1) ] ? MAC UF(1) ()21 MAC UF(1) is a new responder?s secret which replaces MAC UF(0) . MAC UF(1) is used by the responder to generate MAC U(2) to update the access control filter F U(1) to F U(2) . MAC UF(1) will be truncated into K UF(1) and K? UF(1) . K UF(1) used as a new frame key for AES to encrypt the data when the frame is sent to the user; K? UF(1) is a key used in HMAC for data integrity. Second Round: Calculate the new MAC value and update the access filter h () )1(UF MAC [ K R || K U || N i || N R || MAC U(1) || T UF(2) ] ? MAC U(2) ()22 f U(2) and S U(2) will be truncated from MAC U(2) using the method shown in Figure 3. f U(2) is a new seed used to update the responder?s access control filter from F U(1) to F U(2) , as illustrated in equation (23). h () )1(UF MAC [ K U || N i || MAC U(2) || T UF(2) || f U(2) ] ? F U(2) ()23 F U(2) is a new responder?s access filter value and is stored in the responder?s access filter table for filtering the next frame. S U(2) is a new seed that is used to update the 38 responder?s secret from MAC UF(1) to MAC UF(2) . When the user receives further frames from the responder, the user will repeat the same three steps outlined for Frame 4. 4.5 The Summary of the Dynamic Data Communication Stage During the DDCS, the frames sent from the user to the responder should appear as follows: U ? R : P Uid(t) , F R(t) , E () )1( ?tUF K [Data, T UF(t) , P Rid(t) ] t = 2, 3? Also, the frames sent from the responder to the user should appear as follows: R ? U : P Rid(t) , F U(t) , E () )1( ?tRF K [Data, T RF(t) , P Uid(t+1) ] t = 1, 2, 3? Generally, during the DDCS, as shown in Figure 7, there are three steps needed for both the user and the responder. The user and the responder check the filter values when they receive the frames. If the filter value matches, then the new filter value is calculated to address the other side?s filter. Next, they update their access control filters for filtering the next frame. If an administrator determines that an adversary is unable to capture and replay the filter value at the frame speed, then the filter values may be changed for multiple frames instead of every frame. However, in a high security environment, the filter values should be changed for every single frame. 39 PC MC IA56K INSERT THIS END )1(R F )1(U F P Uid(1) , F R(1) , EAES(K UF(0) )[Data, T UF(1) , K U(j) , P Rid(1) ] P Rid(1) , F U(1) , EAES(K RF(1) ) [Data, T RF(2) , P Uid(2) ] P Uid(2) , F R(2) , EAES(K UF(1) )[Data, T UF(2) , P Rid(2) ] P Rid(2) , F U(2) , EAES(K RF(2) ) [Data, T RF(3) , P Uid(3) ] P Uid(3) , F R(3) , EAES(K UF(2) )[Data, T UF(3) , P Rid(3) ] Figure 7: The Overview of Dynamic Data Communication Stage Three steps for a user: First step: When a legitimate user receives the frame from a responder, the user compares it with the access control filter F U(t) to see if there is a match using pseudo ID P Rid(t) . If the filter value matches the access filter value, the user will pass the encrypted data to the system for decryption, and then the system can derive the data and timestamp T RF(t+1) . Second step: Calculate the responder?s access control filter using equations (27), (28) and (29). f R(t+1) and S R(t+1) will be truncated from MAC R(t+1) using the same 40 technique shown in Figure 3. f R(t+1) is a new seed used for the user to calculate the responder?s access control filter F R(t+1) using equation (29). F R(t+1) is a filter value sent with the user?s encrypted data frame to the responder for checking so the encrypted data will be allowed in the responder?s system. S R(t+1) is a seed that must be stored in the user side for calculating the responder?s secret MAC RF(t+1) . The same method employed for the responder with equation (27) needs to be used. This secret must also be stored on the user side for decrypting the next encrypted frame sent from the responder. K RF(t+1) and K? RF(t+1) will be truncated from MAC RF(t+1) . K RF(t+1) is the frame key used by the user to decrypt the data and K? RF(t+1) is the key for the data integrity. Third step: Generate a timestamp T UF(t+1) , and update the user?s access filter from F U(t) to F U(t+1) and pseudo ID P Rid(t) to P Rid(t+1) for checking the next frame. Two rounds are required to update the access filter: First Round: Frame key Generation Function h () )( jU K [ S U(t-1) || S U(t) || N i || N INI || T UF(t) ] ? MAC UF(t) , t = 1, 2, 3? ()24 MAC UF(t) is the generation function for the user?s frame key. It is an input key used by the HMAC to generate the new MAC value MAC U(t+1) in equation (25) and to update the dynamic access control filter in equation (26). K UF(t) and K? UF(t) will be truncated from MAC UF(t) . K UF(t) is the frame key used by the user to encrypt the data and K? UF(t) is the key for the data integrity. Every frame has a unique frame key. 41 Second Round: Calculate the New MAC value and Update the User?s Filter h () )(tUF MAC [ K U || N i || N INI || MAC U(t) || T UF(t+1) ] ? MAC U(t+1) , t = 1, 2, 3? ()25 f U(t+1) and S U(t+1) will be truncated from MAC U(t+1) using the same technique as shown in Figure 4. f U(t+1) is a new seed used to update the user?s access control filter from F U(t) to F U(t+1) as illustrated in equation (26). S U(t+1) is a seed used for the frame key generation function to update the secret from MAC UF(t) to MAC UF(t+1) . h () )(tUF MAC [ K U || MAC U(t+1) || T UF(t+1) || f U(t+1) ] ? F U(t+1) , t = 1, 2, 3? ()26 F U(t+1) is used to replace the previous filter value F U(t) and is stored in the user?s filter table for checking the next frame sent from the responder. Three steps for a responder: First step: When a responder receives the frames from a user, the responder checks the access control filter F R(t) to see if there is a match using pseudo ID P Uid(t) . If the received frame matches the access control filter value, the responder will pass the encrypted data to the system for decryption, and then the system can derive the data and timestamp T UF(t+1) . Second step: Calculate the user?s access filter using equations (24), (25) and (26). f U(t+1) and S U(t+1) will be truncated from MAC U(t+1) using the same technique shown in Figure 4. f U(t+1) is a new seed used by the responder to calculate the user?s access control filter F U(t+1) using equation (26). F U(t+1) is a filter value sent with the responder?s encrypted data frame to the user for checking. S U(t+1) is a seed that must be stored in the responder side for calculating the user?s secret MAC UF(t) via the same 42 method employed for the user, i.e. equation (24). This secret must also be stored in the responder side for decrypting the next encrypted frame sent from user. K UF(t) and K? UF(t) will be truncated from MAC UF(t) . K UF(t) is the frame key used by the responder to decrypt the data and K? UF(t) is the key for the data integrity. Third step: Generate a timestamp T RF(t+1) , and update the responder?s access control filter from F R(t) to F R(t+1) and pseudo ID P Uid(t) to P Uid(t+1) for checking the next frame. Two rounds are needed to update the access control filter: First Round: Frame key Generation Function h () )( jR K [ S R(t-1) || S R(t) || K R || K U || T RF(t) ] ? MAC RF(t) , t = 1, 2, 3? ()27 MAC RF(t) is the generation function for the responder?s frame key. K RF(t) and K? RF(t) will be truncated from MAC RF(t) . K RF(t) is the frame key used by the responder to encrypt the data and K? RF(t) is the key for the data integrity. Every frame has a unique frame key. MAC RF(t) is an input key for the HMAC to generate the new MAC value MAC R(t+1) in equation (28) and to update the dynamic access filter in equation (29). Second Round: Calculate the New MAC value and Update the Responder?s Filter h () )(tRF MAC [ K R ||K U || N i || N INI || MAC R(t) || T RF(t+1) ] ? MAC R(t) , t = 1, 2, 3? ()28 f R(t+1) and S R(t+1) will be truncated from MAC R(t+1) using the same method illustrated in Figure 3. f R(t+1) is a new seed used to update the responder?s access control filter from F R(t) to F R(t+1) using equation (29). S R(t+1) is a seed used by the frame key generation function in updating the secret from MAC RF(t) to MAC RF(t+1) . 43 h () )(tRF K [ K U || N i || MAC R(t+1) || T RF(t+1) || f R(t+1) ] ? F R(t+1) , t = 1, 2, 3? ()29 F R(t+1) is used to replace the previous filter value F R(t) and is stored in the responder?s filter table for filtering the next frame sent from the user. 4.6 Privacy Protected Filter Exchange After the ICS, the responder will be able to generate F R(0), and the F R(0) for each user (initiator) will be stored in the responder?s system. When the user wants to initiate the SMAS, the user will send over the corresponding F R(0) . The responder will have to find out which user is trying to perform SMAS. The responder will compare the F R(0) (as a function of P Uid ) with the filter table to see if there is a match. If there is a match, the responder will be able to know the user?s identity and correspond with K U, N i , N INI , and T INI . What was described above introduces the privacy-protected feature of the IPACF protocol. With the user identity hidden in the filter value and pseudo ID, which sent in plaintext for the stateless entry in SMAS, no one will be able to know which user initiated SMAS except the responder. After the user finishes SMAS, the responder will need to update the F R(t) (t=1, 2, 3?etc.) for the DDCS and the F R(0) for the next session. The user will need to update the F U(t) (t=1, 2, 3?etc.) for the DDCS and generate F R(0) for the next session. The pseudo code algorithm to store and update for both the pseudo ID and filter value table on the responder side in ICS, SMAS, and DDCS is as follows: 44 m; // maximum number of users n; // number of users P Uid [m]; // pseudo ID table F R [m]; // filter value table // initialization for( i = 0; i < m; i++){ P Uid [i] = i; } j = m // j is for available positions // When a user registers and Do Loop will run for each user For(k = 0; k < n-1; k++) { random # = rand() ; // generate random # New P id = random # mod j; // new pseudo ID index j = j ? 1; // decrease the user size // shift the Pseudo ID table for( i = New P id ; i < j-1 ; i++){ P Uid [i] = P Uid [i+1]; } F R [New P id ] = initial filter value; // store initial filter value } 45 Do while(a user sends in a message) // When a user sends in a message IndexP Uid ; // the pseudo ID for the current user random # = rand(); // generate random # New P id = random # mod j ; // new pseudo ID index // shift the Pseudo ID table for( i = New P id ; i < j-1 ; i++){ P Uid [i] = P Uid [i+1]; } F R [New P id ] = updated filter value; // store updated filter value P Uid [j-1] = IndexP Uid ; // add the used pseudo ID back to table Two tables are created for pseudo IDs and the filter values using arrays. The filter value table uses the pseudo ID as an index to store each filter value for a specific user. The pseudo ID table will be initialized as the index of the array with m maximum number of users. When n new user registers, the responder generates a random number and uses the remainder of the random number divided by j (mod j) as the new pseudo ID for each new user. The pseudo ID that is used is removed from the table by the responder and the j available positions for the next new user are updated by shifting up the pseudo ID table. When a legitimate user sends in a message, the responder updates the registered user?s pseudo ID and filter value for the next frame in SMAS and DDCS as follows. The responder generates the new pseudo ID for the user by using the same technique in ICS, removes the new pseudo ID from the available pseudo ID array by shifting up the pseudo 46 ID table, updates the filter value table for the new pseudo ID, and attaches the previous pseudo ID to the end of the pseudo ID array to ensure that the previous pseudo ID is available for other users. The same algorithm can be used on a user side. Figure 8 shows the flowchart of updating filter value by both responder and user where F(t, P id(t) ) is either F R (t, P Uid(t) ) or F U (t, P Rid(t) ) . After the responder receives the filter value F(t, P id(t) ) from a user, the responder will compare the filter value by comparing the filter value table by using the pseudo ID. If the filter value F(t, P id(t) ) is found, the responder will find the new pseudo ID for the filter value F(t+1, P id(t+1) ) and insert the filter value F(t+1, P id(t+1) ), and then the filter value F(t, P id(t) ) will be deleted from the filter value table. The user conducts similar operations as the responder. Figure 8: Filter Value Table Update Flowchart 47 CHAPTER FIVE IMPLEMENTATION AND PERFORMANCE EVALUATION 5.1 Implementation IPACF protocol has been implemented in Linux systems. The software is implemented, compiled, and run in an IBM ThinkPad T42 with a Pentium M processor running at 1.7 GHz, with a L2 cache of 2MB, 512 MB of main memory and connecting with CAT 5e cable to 100BASET Ethernet switch. IPACF protocol can also be split into a dual servers design as shown in Figure 9. With a dual server design, the server 1 can filter out the packets for legitimate users and route the legitimate requests to Server 2. Server 1 listens for connections from the user on specific port number, which allows only the legitimate packets to go through to Server 2 by comparing the received filter value based on pseudo ID. Server 1 rejects the packet right away if the filter value does not match; otherwise, it routes the packets to Server 2. The Server 2 provides the service that generates the new filter value, then updates the filter value and sends it back to legitimate users through Server 1. When Server 1 receives a packet, Server 1 compares the filter value with the filter value table alone with the pseudo ID. If there is a match, Server 1 can obtain the hidden user ID from the filter table and routes the packet with the user ID to Server 2; otherwise, the packet is dropped. If the received packet is legitimate, Server 1 sends the packet to 48 Server 2 that performs the SMAS stage. Server 2 updates the filter value for the specific user and updates the pseudo ID to ensures that the user real identity is hidden with four steps: first, generate the new pseudo ID, and the filter value is updated from the filter value table; the computation costs O(1) to update. Second, Server 2 removes the original filter value from the filter value table; the computation costs O(1) to remove. After Server 2 completes filter value update, it sends the updated filter value with the new pseudo ID to Server 1. Server 1 then updates the filter value table in order to maintain its current status. In a DoS/DDoS attack, the attacker attempts to make network services unavailable by flooding the authentication server in the network with numerous requests. The CPU usage eventually reaches its maximum and the server service becomes unavailable. A dual server design can improve request response time using Server 2 to calculate filter values and frame key so that Server 1 only performs the comparison of filter values. In this paper, we will demonstrate the IPACF protocol with both single server and dual server and conduct the comparison for the performance evaluation. 49 subnet #1 192.168.1.0 subnet #2 131.204.128.0 Server 1 Server 2 User Attacker AttackerAttacker IPACF Dual Server Design 192.168.1.100 192.168.1.101 192.168.1.102 192.168.1.103 NIC #2: 131.204.128.1 131.204.128.2 NIC #1: 192.168.1.1 Figure 9: Diagram with dual servers design IPACF protocol is implemented in RedHat Linux 9.0, using gcc and g++ compiler with Crypto++ Library. Crypto++ Library is a free C++ class library of cryptographic schemes. Integrity uses hash function HMAC with SHA1 keyed-hash and confidentiality uses AES are tested. In this experiment, we use 128 bits for both key size and block size in AES. 5.2 Performance 5.2.1 Performance in authentication The server accepts the packet from a user and verifies the filter value. If the corresponding filter value of the user matches, the server will perform the SMAS. During the SMAS stage, after the server verifies the filter value, the server has authenticated the user. The server will decrypt the secrets, which are the time stamp and nonce, sent by the user to perform the same calculation for the user to authenticate the 50 server. The server will send the filter value, time stamp, and the master secret key K R(j) back to the user, and allow the user to verify the filter value and update the server secret master key from K R(j) to K R(j+1) . After the user authenticates the server by comparing the filter value sent by the server, the SMAS is completed, and the filter value F R(0) will be updated for the DDCS and for next session login. Figure 10 and Figure 11 show the session mutual authentication for the responder and the user, respectively. The averaged wired authentication time for the responder in SMAS is 4.2003 millisecond (ms) while IDF needs 181.55 ms, IPACF needs only 2.31% authentication time of IDF in wired links; the averaged wireless (using 802.11b instead of Ethernet) authentication time for the responder in SMAS is 9.12124 ms while IDF needs 189.37 ms, IPACF needs only 4.86% authentication time of IDF in wireless links. 51 Figure 10: The SMAS for the responder 52 Figure 11: The SMAS for the user 5.2.2 Performance in DoS attacks When a hacker performs an attack to the server, we can see the screen capture in which packets get rejected by the server after the verification of the filter value is failed as shown in Figure 12. When a legitimate user tries to get authenticated by the server while attackers are trying to perform the attacks to the server, we can see the rejected messages from the server. When the attack is performed, the server shows the ?Login Failed? message after comparing the filter value that does not match. When the SMAS is performed successfully for the legitimate user, we can see ?Filter Value Matches? in Figure 12. 53 Figure 12: User performs SMAS to the responder while attackers perform DoS attack As shown in Figure 13, the averaged rejection time as a function of the number of attacking PCs is defined as the time between an attacker sends out Frame 1 and receives the rejection from the server. Both IPACF and IDF have an averaged reject time 5.90 ns (nanoseconds) by the responder. 54 IPACF/IDF Averaged Rejection Time 0.00 2.00 4.00 6.00 8.00 10.00 12345 # Of Attacking PCs A v e r ag ed R ej ect i o n T i m e ( n a no s e c o nd s ) IPACF/IDF Averaged Rejection Time Figure 13: Comparison chart of IPACF and IDF in averaged rejection time 5.2.2 Performance in dual server over single server In our experiments, the dual server needs only 5.4% authentication time of single server while a number of attackers are performing attacks as shown in Figure 14. Dual Server vs Single Server 1.000E-03 1.000E-02 1.000E-01 1.000E+00 1PC 2PCs 3PCs 4PCs # Of Attacking PCs A u t h en t i cat i o n T i me ( s ec) single server dual server Figure 14: Comparison chart of dual server vs single server in average round trip time 55 5.3 Interoperability of IPv4 (user application) and IPv6 (responder) The IPACF implementation is designed to be compatible with IPv6 networks, a server code is bound to the IPv6 address and the server will be able to accept connections from IPv4 and IPv6 clients. When an IPv4 client is connecting to the IPv6 server, the dual stack kernel converts the client IPv4 address to the IPv4-mapped IPv6 address since the IPv6 server can only deal with IPv6 connections. When porting to IPv6, most of changes will be made in the transport module, which is User Datagram Protocol that is in charge of establishing communications to remote nodes. If the IPACF implementation is changed to IPv6, only the transport module should be modified. Figure 15 and Figure 16 show the difference between UDP and UDP6 socket. The inet6 family is an IPv6 version of inet4 family. While inet4 implements Internet Protocol version 4, inet6 implements Internet Protocol version 6. inet6 is a collection of protocols layered atop the Internet Protocol version 6 (IPv6) transport layer, and utilizing the IPv6 address format. UDP/UDP6 is used to support the SOCK_DGRAM abstraction (UDP) in inet6 family that provides access to the IPv6 protocol. Each protocol-specific data structure is designed to carry the addresses for each protocol, so it can be cast into a protocol-independent data structure - the "sockaddr" structure. The sockaddr_in structure is the protocol-specific address data structure for IPv4; the sockaddr_in6 structure is the protocol-specific address data structure for IPv6. They both pass addresses between applications and the system in the socket programming functions. A new address family name, AF_INET6, distinguishes between the original AF_INET sockaddr_in address data structure and the new sockaddr_in6 data structure. The sin6_port field contains the 16-bit UDP port number. This field is used in the same 56 way as the sin_port field of the sockaddr_in structure and the port number is stored in the network byte order. Applications use in6addr_any similarly to the way that they use INADDR_ANY in IPv4. In Figure 15, the server creates a sockaddr_in structure with AF_INET family, which contains its source IPv4 address to bind the socket to port number 32000. In Figure 16, the server creates a sockaddr_in6 structure with AF_INET6 family, which contains its source IPv6 address to bind the socket to port number 32000. Figure 15: UDP socket Figure 16: UDP6 socket 57 CHAPTER SIX CONCLUSIONS AND FUTURE WORKS In this thesis, we introduced an identity-based privacy-protected access control filter (IPACF) to solve DoS/DDoS problems. The IPACF protocol provides the following unique properties. ? The IPACF filter is based on the legitimate users? identities, which is hidden in the filter values that are generated by the pre-shared secrets, nonce, timestamp, user ID and password. ? The IPACF filter value varies with every frame for both responder and user to prevent sniffing attacks. ? A filter value table is initialized for both users and responder during ICS. The identities of both users and responder are tabulated with pseudo ID in the filter value table. ? The privacy of both user and responder is guarded by the one-time filter value, which is the temporary equivalent identity that is accessible in the communication. Only the legitimate user and responder can figure out the identity from the filter value table. ? The IPACF protocol is stateless because the input filter value is checked against the filter table without creating a state unless the filter value is legitimate. When a 58 legitimate filter value is received, a new state is created by calculating the new filter value for the next frame. When a legitimate filter value comes in, a sorted filter value table is maintained by deleting the old filter value, searching the new index for the new filter value and inserting it into the filter table. ? The stateless property provides the capability to resist DoS/DDoS attacks. The IPACF protocol ensures a secure update for both user and responder session master key K R(j) and K U(j) . A pairwise key K R exists for each user so that a user cannot pretend to be a responder. Future research direction is proposed as follows. In PKI ((Public Key Infrastructure) authentication protocols, a server must use the system resources to compute and store a hash, it makes the DoS/DDoS attack feasible [12]. When a web server integrates with the IPACF protocol, the web server immediately turns into an application server to offer safe, secure information exchange to registered/legitimate clients. The implementation of PKI that combined with IPACF to defend against DoS/DDoS attacks is via web server and client certificates. There are three steps during the initial configuration stage in a secured channel such as a SSL (Secure Socket Layer) channel. First, a client and the web server exchange their certificates via a SSL channel. Second, a client generates the master secret key K U using equation (30) without a user ID and a password, using its private key K PU instead, encrypts K U and N i with the web server?s public key, and then sends the encrypted information to the web server. Third, after the web server receives the encrypted information, it will decrypt the received information using its private key K PR . The web 59 server will generate the master secret key K R using equation (31) without a responder ID and a password, using its private key K PR instead, encrypts K R , T INI and N INI with the client?s public key, and then sends the encrypted information back to the client. Since most of users do not have a certificate, as an alternative, a user can use a user ID and a password instead of a private key as shown in equation (1). K U = h () ui N [ K PU || T u || N ui ] ( )30 K R = h () Ri N [ K PR || T R || N Ri ] ( )31 After the initial configuration stage, the client will be able to perform authentication with the web server. The authentication scheme will be stateless for both client and web server to against DoS/DDoS attacks. The initial configuration stage will not need to be performed unless it is necessary for a new client to register. The session key will be generated for any further authentication. The web server uses the authentication and encryption/decryption services of IPACF and can securely communicate with clients, which will be able to use the server-side resources. The IPACF protocol provides compatibility with the PKI schemes to prevent a DoS/DDoS attack. 60 BIBLIOGRAPHY [1] IEEE Standard for Local and metropolitan area networks: Port-Based Network Access Control, IEEE Std 802.1X-2003. [2] IEEE Std 802.11i/D4.1, ?Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Security Enhancements,? July 2003. [3] A. Saxena and B. Soh, ?Distributed Denial of Service Attacks and Anonymous Group Authentication on the Internet,? Third International Conference on Information Technology and Applications, vol. 2, ICITA 2005, pp.460-464. [4] C. Wang, C. Wu and J. D. Irwin, ?Using an Identity-Based Dynamic Access Control Filter (IDF) to Defend Against DoS Attacks,? In IEEE Wireless Communications and Networking Conference, vol. 1, March 2004, pp. 639-645. [5] P. Owezarski, ?On the impact of DoS attacks on Internet traffic characteristics and QoS,? In Proc. 14 th International Conference on Computer Communications and Networks, ICCCN 2005, pp. 268-274. [6] A. Juels and J. Brainard, ?Client puzzles: A cryptographic countermeasure against connection depletion attacks,? In Proc. of the Network and Distributed Systems Security Symposium (NDSS ?99), February 1999, pp. 151?165. [7] T. Aura, P. Nikander, and J. Leiwo, ? DOS-resistant authentication with client puzzles,? In Proc. of the 8th International Workshop on Security Protocols, April 2000, pp.170-177. [8] W. Aiello, S. M. Bellovin, M. Blaze, R. Canetti, J. Ioannidis, A. Keromytis, and O. Reingold, ?Efficient, DoS-Resistant, Secure Key Exchange for Internet Protocols,? In Proceedings of the 9th ACM conference on Computer and communications security, Washington D.C., 2002, pp. 48-58. [9] K. Matsuura and H. Imai, ?Modified aggressive mode of Internet key exchange resistant against denial-of-service attacks,? In IEICE Transactions on Information and Systems, May 2000, pp. 972?979. 61 [10] J. Leiwo, P. Nikander, and T. Aura, ?Towards network denial of service resistant protocols,? In Proc. of the 15 th International Information Security Conference (IFIP/SEC), August 2000, pp. 301-310. [11] C. Meadows, ?A formal framework and evaluation method for network denial of service,? In Proc. of the 12th IEEE Computer Security Foundations Workshop, June 1999, pp. 4?13. [12] W. Zhiguo, Zhu Bo, R.H. Deng, Bao Feng, and A.L. Ananda, ?DoS-resistant access control protocol with identity confidentiality for wireless networks,? IEEE Wireless Communications and Networking Conference, vol. 3, March 2005, pp. 1521-1526. [13] JAN, J.K., and TSENG, Y.M., ?Two integrated schemes of user authentication and access control in a distributed computer network?, IEE Proc. Comput. Digit. Tech., 1998, 145, (6), pp. 419-424. [14] W.H He, and T.C. Wu, ?Security of the Jan-Tseng integrated schemes for user authentication and access control? IEE Proc. Comput. Digit. Tech., 147, (5), 2002, pp. 365-368. [15] G. Carl, G.Kesidis, R.R.Brooks, Rai Suresh, ?Denial-of-service attack-detection techniques,? IEEE Internet Computing, vol. 10, January 2006, pp.82-89. [16] J. Mirkovic, J. Martin, and P. Reiher, ?A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms,? ACM Sigcomm Computer Comm. Rev., vol. 34, no. 2, 2004, pp. 39?53. [17] A. Ferrante, V. Piuri, and J. Owen, ?IPSec hardware resource requirements evaluation,? Next Generation Internet Networks, April 2005, pp. 240-246. [18] M. Bellare, and R. Canetti, ?HMAC: keyed-hashing for message authentication,? Request for Comments 2104, Internet Engineering Task Force, February 1997. [19] T. Aura and P. Nikander, ?Stateless connections,? In Proc. Of International Conferenec on Information and Communications Security (ICICS ?97), Lecture Notes in Computer Science, vol. 1334, Springer, November 1997, pp. 87?97. [20] P. Janson, G. Tsudik, and M. Yung, ?Scalability and flexibility in authentication services: The KryptoKnight approach,? In IEEE INFOCOM?97, Tokyo, April 1997, pp. 725-736. [21] R. C.Merkle, ?Secure communications over insecure channels,? Communications of the ACM, vol. 21, April 1978, pp. 294? 299. 62 [22] C. Dwork and M. Naor, ?Pricing via processing or combating junk mail,? In E. Brickell, editor, Proceedings of Advances in Cryptology - Proc. CRYPTO ?92, vol. 1323, Santa Barbara, CA USA , August 1992, Springer-Verlag, pp. 139?147. [23] D. Dean and A. Stubblefield, ?Using Client Puzzles to Protect TLS,? In Proceedings of the 10th USENIX Security Symposium, Washington D.C., August 2001, pp. 1-8. [24] X.F. Wang and M.K. Reiter, ?Defending Against Denial-of-Service Attacks with Puzzle Auctions,? In IEEE Symposium on Security and Privacy, May 2003, pp. 78- 92. [25] Brent Waters, Ari Juels, J. Alex Halderman, and Edward W. Felten, ?New client puzzle outsourcing techniques for DoS resistance,? The 11th ACM Conference on Computer and Communications Security (CCS 2004) ACM Press, 2004, pp. 246? 256. [26] D. Dean and A. Stubblefield, ?Using client puzzles to protect TLS,? In 10th USENIX Security Symposium, 2001, pp. 1?8. [27] A. Juels and J. Brainard, ?Client puzzles: A cryptographic countermeasure against connection depletion attacks,? In Proc. of the Network and Distributed Systems Security Symposium (NDSS ?99), February 1999, pp. 151?165. [28] D. Harkins and D. Carrel, ?The Internet Key Exchange (IKE),? Request for Comments 2409, Internet Engineering Task Force, November 1998. [29] N. Ferguson and B. Schneier, ?A Cryptographic Evaluation of IPSec,? In http://www.counterpane.com/ipsec.pdf, January 2000. [30] C. Kaufman and R. Perlman, ?Analysis of IKE,? In IEEE Transactions on Network Computing, vol. 4, November 2000, pp. 50-56. [31] Matsuura and H. Imai, ?Resolution of ISAKMP/Oakley key-agreement protocol resistant against denial-of-service attack,? In Proc. of Internet Workshop (IWS ?99), February 1999, pp. 17?24. [32] W. A. Simpson, ?IKE/ISAKMP Considered Harmful,? USENIX ;login:, December 1999, pp. 48-58. [33] D. Harkins, C. Kaufman, S. Kent, T. Kivinen, and R. Perlman, ?Proposal for the IKEv2 Protocol,? In draft-ietf-ipsec-ikev2-01.txt, Internet Engineering Task Force, April 2002. Work in progress. 63 [34] K. Matsuura and H. Imai, ?Resolution of ISAKMP/Oakley key-agreement protocol resistant against denial-of-service attack,? In Proc. of Internet Workshop (IWS '99), February 1999, pp. 17-24. [35] M. Bellare, R. Canetti, and H. Krawczyk, ?Keying Hash Functions for Message Authentication,? Abridged version appears in CRYPTO '96, vol. 1109 of Lecture Notes in Computer Scienc, Springer-Verlag, 1996 e, pp. 1-15. [36] M. Jakobsson and A. Juels, ?Proofs of work and bread pudding protocols,? In Proc. of the IFIP TC6 and TC11 Joint Working Conference on Communications and Multimedia Security, September 1999, pp. 258-272. [37] R. Oppliger, ?Protecting key exchange and management protocols against resource clogging attacks,? In Proc. of the IFIP TC6 and TC11 Joint Working Conference on Communications and Multimedia Security (CMS ?99), September 1999, pp. 163? 175. [38] S. Hirose and K. Matsuura, ?Enhancing the resistance of a provably secure key agreement protocol to a denial-of-service attack?, In Proceedings of the 2 nd International Conference on Information and Communication Security (ICICS ?99), Lecture Notes in Computer Science vol. 1726, Sydney, Australia, November 1999, Springer, pp. 169?182. [39] M.T. Goodrich, ?Leap-frog packet linking and diverse key distributions for improved integrity in network broadcasts,? In IEEE Symposium on Security and Privacy, May 2005, pp. 196-207.