UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Authentication and key management in heterogeneous wireless networks Al Shidhani, Ali 2010

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2010_spring_alshidhani_ali.pdf [ 2.9MB ]
Metadata
JSON: 24-1.0069416.json
JSON-LD: 24-1.0069416-ld.json
RDF/XML (Pretty): 24-1.0069416-rdf.xml
RDF/JSON: 24-1.0069416-rdf.json
Turtle: 24-1.0069416-turtle.txt
N-Triples: 24-1.0069416-rdf-ntriples.txt
Original Record: 24-1.0069416-source.json
Full Text
24-1.0069416-fulltext.txt
Citation
24-1.0069416.ris

Full Text

Authentication and Key Management in Heterogeneous Wireless Networks by  Ali Al Shidhani  B.Eng., Sultan Qaboos University, Oman, 2001 M.S., Queensland University of Technology, Australia, 2003  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  DOCTOR OF PHILOSOPHY in THE FACULTY OF GRADUATE STUDIES (ELECTRICAL AND COMPUTER ENGINEERING)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver) April 2010 © Ali Al Shidhani, 2010  Abstract Interworking wireless technologies such as the Wireless Local Area Network (WLAN), the Worldwide Interoperability for Microwave Access (WiMAX) and mobile communication systems conforming to the Third-Generation Partnership Project (3GPP) standards forms a heterogeneous wireless network. Designing secure and efficient authentication protocols to enable fast connections to the heterogeneous network is challenging. Existing standard authentication protocols mandate users to perform authentication with authentication servers located in the 3GPP Home Network (3GHN). This approach is highly inefficient. Other research work suggested performance-enhanced protocols but introduced other problems such as degrading system security. This thesis presents the designs of authentication protocols that balance security and performance by applying minor modifications to the standard authentication protocols. The proposed protocols attempt to minimize the communications between users and the 3GHN during authentication. Several protocols are proposed in this thesis to address inefficient authentications in the heterogeneous network. Firstly, in 3GPP-WLAN interworking, we propose fast authentication protocols that expedite authenticating stationary and mobile users by completing authentications locally without contacting the 3GHN. The proposed protocols outperform standard protocols and support essential security requirements such as the adoption of a secure key management scheme. Secondly, in 3GPP-WiMAX interworking, we design two handover (HO) protocols that piggyback authentication queries on HO control messages to avoid initiating a separate authentication session after performing a HO. Our proposed protocols prove to accelerate the HO procedure and conserve users’ computing resources. Important security qualities such as the provision of forward and backward secrecy are also maintained by our proposed protocols. ii  Thirdly, we design six re-authentication protocols to improve HOs between 3GPP, WiMAX and WLAN systems. The proposed protocols capitalize on the execution of an initial extensive authentication protocol to enable successive expedited HO re-authentications. Remarkable performance improvements are achieved when adopting our proposed protocols compared to standard protocols. Lastly, we propose protocols to enable efficient and secure multi-hop accesses to the heterogeneous network. A secure multi-hop authentication protocol and a secure multi-hop Mobile IP registration scheme are designed. Our scheme surpasses competitive schemes in terms of registration delay and power consumption while resisting against security attacks existing in the multi-hop network.  iii  Table of Contents Abstract ......................................................................................................................................... ii  Table of Contents ......................................................................................................................... iv  List of Tables .............................................................................................................................. viii  List of Figures .............................................................................................................................. ix  List of Acronyms ........................................................................................................................ xiii  List of Symbols ........................................................................................................................... xvi  Acknowledgements ......................................................................................................................xx  Dedication ................................................................................................................................... xxi  Chapter 1: Introduction ................................................................................................................1  1.1   Overview .......................................................................................................................... 1   1.1.1 Wireless Internet access technologies ........................................................................... 1  1.1.2 Relationship between security strength and performance in the heterogeneous wireless network ................................................................................................................................... 3  1.1.3 Interworking between mobile ad hoc networks and the Internet ................................... 5  1.2 Motivations and objectives ................................................................................................... 6  1.3 Main contributions .............................................................................................................. 10  1.4 Organization of the thesis ................................................................................................... 12  Chapter 2: Authentication in heterogeneous wireless networks .............................................14  2.1 Introduction ........................................................................................................................ 14  2.2 Network architectures ......................................................................................................... 15  2.2.1 The UMTS network architecture ................................................................................. 15  2.2.2 3GPP-WLAN interworking architecture ..................................................................... 16  2.2.3 3GPP-WiMAX interworking architecture ................................................................... 20  2.2.4 Heterogeneous wireless network architecture ............................................................. 22  2.2.5 Interworking between mobile ad hoc networks and the Internet ................................. 24  2.3 Threat model ....................................................................................................................... 25  2.4 Standard authentication protocols....................................................................................... 28  2.4.1 3GPP-AKA .................................................................................................................. 28  2.4.2 EAP-AKA .................................................................................................................... 31  2.4.2.1 EAP-AKA in 3GPP-WLAN ..................................................................................... 34  2.4.2.2 EAP-AKA in 3GPP-WiMAX ................................................................................... 37  iv  2.4.2.3 Drawbacks of EAP-AKA and 3GPP-AKA .............................................................. 38  2.5 Overview of related work ................................................................................................... 40  2.5.1 Re-authentication in 3GPP-WLAN ............................................................................. 40  2.5.2 Horizontal handover authentication in 3GPP-WLAN ................................................. 41  2.5.3 Secure and efficient horizontal handovers in 3GPP-WiMAX..................................... 43  2.5.4 Efficient vertical handover authentications in the heterogeneous wireless network ... 45  2.5.5 Securing the MANET-Internet interworking architecture ........................................... 49  2.6 Summary ............................................................................................................................. 52  Chapter 3: Fast authentication in the 3GPP-WLAN interworking architecture ..................53  3.1 Introduction ........................................................................................................................ 53  3.2 Assumptions ....................................................................................................................... 55  3.3 Modifications to EAP-AKA (mod-EAP-AKA).................................................................. 55  3.4 Proposed protocols.............................................................................................................. 60  3.4.1 WLAN local re-authentication protocol (WLLR) ....................................................... 61  3.4.2 Intra-WLAN fast pre-authentication protocol (Intra-WLAN FP) ............................... 63  3.4.3 Inter-WLAN fast pre-authentication protocol (Inter-WLAN FP) ............................... 66  3.5 Performance evaluation ...................................................................................................... 68  3.5.1 Performance evaluation of WLLR............................................................................... 68  3.5.2 Performance evaluation of the Intra/Inter-WLAN fast pre-authentication protocols .. 78  3.5.3 Selection of nWR and nHHO values ................................................................................ 89  3.6 Security analysis ................................................................................................................. 92  3.6.1 Secure key management .............................................................................................. 92  3.6.2 Mutual authentication .................................................................................................. 94  3.6.3 Protection of message integrity ................................................................................. 100  3.6.4 Protection of identities ............................................................................................... 100  3.7 Summary ........................................................................................................................... 101  Chapter 4: Performance-enhanced and secured horizontal handovers in the 3GPPWiMAX interworking architecture .........................................................................................103  4.1 Introduction ...................................................................................................................... 103  4.2 Security requirements for WiMAX horizontal handover protocols in the 3GPP-WiMAX interworking architecture ........................................................................................................ 104  4.3 Proposed handover protocols ............................................................................................ 109  4.3.1 R6 handover pre-authentication protocol (R6HP) ..................................................... 114  v  4.3.2 R3 handover pre-authentication protocol (R3HP) ..................................................... 116  4.4 Performance evaluation .................................................................................................... 119  4.4.1 Network model and handover scenarios .................................................................... 119  4.4.2 Handover signaling .................................................................................................... 121  4.4.3 Handover delay .......................................................................................................... 122  4.4.4 Handover keys ........................................................................................................... 123  4.5 Numerical results .............................................................................................................. 124  4.5.1 Selection of nR6H and nR3H values .............................................................................. 131  4.6 Security analysis ............................................................................................................... 133  4.6.1 S1-Mutual authentication .......................................................................................... 133  4.6.2 S2-Forward and backward secrecy ............................................................................ 135  4.6.3 S3-Key scope and distribution ................................................................................... 136  4.6.4 S4-Key freshness ....................................................................................................... 137  4.6.5 S5-Privacy protection ................................................................................................ 137  4.7 Summary ........................................................................................................................... 138  Chapter 5: Fast vertical handover re-authentication protocols for the heterogeneous wireless network.........................................................................................................................139  5.1 Introduction ...................................................................................................................... 139  5.2 Secure and efficient vertical handover re-authentications between WiMAX and WLAN ................................................................................................................................................ 140  5.2.1 Introduction ............................................................................................................... 140  5.2.2 Proposed vertical handover re-authentication protocols............................................ 142  5.2.2.1 WiMAX fast re-authentication (WiFR) .................................................................. 147  5.2.2.2 WiMAX proxy assisted re-authentication protocol (WiPAR)................................ 150  5.2.2.3 WiMAX local re-authentication protocol (WiLR) ................................................. 151  5.2.2.4 WLAN fast re-authentication protocol (WLFR) .................................................... 153  5.2.2.5 WLAN local re-authentication version 2 protocol (WLLRv2) .............................. 155  5.2.3 Performance analysis ................................................................................................. 156  5.2.3.1 System model and assumptions .............................................................................. 156  5.2.3.2 Authentication signaling ......................................................................................... 161  5.2.3.3 Authentication delay ............................................................................................... 162  5.2.3.4 Impact of additional keys........................................................................................ 163  5.2.4 Numerical results ....................................................................................................... 164  vi  5.2.5 Selection of nVHO, nPAR, nLR and nWRv2 values ............................................................ 171  5.2.6 Security analysis ........................................................................................................ 173  5.2.6.1 Mutual authentication ............................................................................................. 174  5.2.6.2 Forward and backward secrecy .............................................................................. 175  5.2.6.3 Protection of MS’s privacy ..................................................................................... 176  5.3 Secure and efficient vertical handover re-authentication to 3GPP ................................... 176  5.3.1 Introduction ............................................................................................................... 176  5.3.2 Modifications to 3GPP-AKA (mod-3GPP-AKA) ..................................................... 178  5.3.3 Fast 3GPP-AKA re-authentication protocol (F3AR) ................................................ 179  5.3.4 Performance evaluation ............................................................................................. 181  5.3.5 Security analysis ........................................................................................................ 189  5.4 Summary ........................................................................................................................... 191  Chapter 6: Efficient and secure multi-hop Mobile IP registration scheme for MANETInternet interworking ................................................................................................................192  6.1 Introduction ...................................................................................................................... 192  6.2 Proposed scheme .............................................................................................................. 194  6.2.1 Secure single hop MIP registration............................................................................ 195  6.2.2 Multi-hop authentication protocol ............................................................................. 198  6.2.3 Secure multi-hop MIP registration ............................................................................ 200  6.2.4 Secure multi-hop mobile IPv6 registration ................................................................ 204  6.3 Performance evaluation .................................................................................................... 206  6.3.1 MIP registration delay ............................................................................................... 207  6.3.2 Energy consumption and communication overhead .................................................. 213  6.3.3 Note on scalability ..................................................................................................... 216  6.4 Security analysis ............................................................................................................... 217  6.5 Summary ........................................................................................................................... 221  Chapter 7: Conclusions .............................................................................................................223  7.1 Summary of contributions ................................................................................................ 224  7.2 A consolidated view of the contributions ......................................................................... 229  7.3 Future work....................................................................................................................... 232  7.3.1 Improvements to the proposed protocols................................................................... 232  7.3.2 Future research direction ........................................................................................... 233  References...................................................................................................................................235  vii  List of Tables Table 3.1 Symbols used in our proposed protocols ...................................................................... 57  Table 3.2 Values of the performance metrics for each protocol in F ........................................... 70  Table 3.3 Values of the performance metrics for each protocol in P ........................................... 80  Table 3.4 Number and size of keys generated in the four scenarios ............................................ 87  Table 4.1 List of symbols used in describing our proposed protocols ....................................... 110  Table 4.2 New TLV for R6HP and R3HP .................................................................................. 113  Table 4.3 Radius messages and attributes used in R3HP ........................................................... 117  Table 4.4 Parameters used in the performance analysis ............................................................. 124  Table 4.5 Message sizes, delay and the number and sizes of keys generated in every authentication and HO protocol .................................................................................................. 125  Table 4.6 Security features of the standard and proposed HO protocols ................................... 133  Table 5.1 List of symbols used in describing our proposed protocols ....................................... 145  Table 5.2 Frequency of executing the protocols in P for every Mi when A = B = 2, nVHO = 4 and α = 1 ............................................................................................................................................... 161  Table 5.3 Numbers and sizes of keys generated in the standard and the proposed protocols .... 169  Table 5.4 Values of the performance metrics in 3GPP-AKA, fast re-authentication (Kwon et al. proposal), mod-3GPP-AKA and F3AR ...................................................................................... 184  Table 5.5 Number and size of keys generated by all nodes in Sn1, Sn2 and Sn4 ...................... 186  Table 6.1 Comparison of cryptographic-related processing delays............................................ 210   viii  List of Figures Figure 1.1 Organization of the thesis............................................................................................ 13  Figure 2.1 Simplified UMTS architecture .................................................................................... 16  Figure 2.2 Simplified 3GPP-WLAN interworking architecture ................................................... 19  Figure 2.3 Simplified 3GPP-WiMAX interworking architecture................................................. 21  Figure 2.4 Simplified heterogeneous wireless network ................................................................ 23  Figure 2.5 MANET-Internet interworking architecture (MII) ..................................................... 25  Figure 2.6 3GPP-AKA protocol ................................................................................................... 29  Figure 2.7 Standard EAP-AKA authentication ............................................................................ 33  Figure 2.8 EAP-AKA authentication protocol in the 3GPP-WLAN interworking architecture .. 35  Figure 2.9 Fast EAP-AKA re-authentication protocol in the 3GPP-WLAN interworking architecture ................................................................................................................................... 36  Figure 2.10 The initial network entry authentication in the 3GPP-WiMAX interworking architecture ................................................................................................................................... 37  Figure 2.11 EAP-AKA key hierarchy in the 3GPP-WLAN and 3GPP-WiMAX interworking architectures .................................................................................................................................. 38  Figure 3.1 Key hierarchies in (a) the standard EAP-AKA protocol and (b) proposed key extensions ..................................................................................................................................... 56  Figure 3.2 Modified EAP-AKA (mod-EAP-AKA) ...................................................................... 58  Figure 3.3 WLAN local re-authentication protocol (WLLR) ....................................................... 61  Figure 3.4 Flow chart describing MS’s operation in WLLR ........................................................ 63  Figure 3.5 Flow chart describing WAAA’s operation in WLLR ................................................. 63  Figure 3.6 Intra-WLAN fast pre-authentication ........................................................................... 64  Figure 3.7 Inter-WLAN fast pre-authentication ........................................................................... 68  Figure 3.8 Comparison between RS1, RS2 and RS3 in terms of the authentication signaling cost ...................................................................................................................................................... 72  Figure 3.9 Comparison between RS1, RS2 and RS3 in terms of authentication delay ................ 74  Figure 3.10 Authentication delay comparison between RS1, RS2 and RS3 when varying the hops between the WAAA and the HAAA ............................................................................................ 74  Figure 3.11 Comparison between RS1, RS2 and RS3 in terms of the number and size of keys generated by all nodes .................................................................................................................. 76  ix  Figure 3.12 Comparison between RS1, RS2 and RS3 in terms of the numbers and sizes of keys generated by the HSS and the HAAA .......................................................................................... 77  Figure 3.13 Comparison between RS1, RS2 and RS3 in terms of the number and size of keys generated by MS ........................................................................................................................... 77  Figure 3.14 MS movement ........................................................................................................... 78  Figure 3.15 Authentication protocols executed in Sc1, Sc2, Sc3 and Sc4 when nHHO = 5 .......... 79  Figure 3.16 Authentication signaling cost comparison between Sc1, Sc2 and Sc3 ..................... 82  Figure 3.17 Accumulative authentication signaling on every step in the 6-steps MS movement when nHHO = 5............................................................................................................................... 82  Figure 3.18 Relationship between the accumulative authentication signaling on every step when varying nHHO ................................................................................................................................. 83  Figure 3.19 Authentication delays of the four scenarios for different nHHO values...................... 84  Figure 3.20 Authentication delays of the four scenarios when varying the number of hops between WAAA and HAAA ........................................................................................................ 85  Figure 3.21 Authentication delays of Sc1, Sc3 and Sc4 when varying nHHO and the number of hops between WAAA and HAAA................................................................................................ 86  Figure 3.22 Keys generated by the authentication protocols in Sc1, Sc2, Sc3 and Sc4 when nHHO = 5 ................................................................................................................................................. 87  Figure 3.23 Numbers and sizes of keys generated by HSS and HAAA on every authentication step ................................................................................................................................................ 88  Figure 3.24 Number and size of keys generated by MS on every authentication step ................. 89  Figure 3.25 Algorithm for selecting a suitable nWR value............................................................. 90  Figure 3.26 Algorithm for selecting nHHO..................................................................................... 91  Figure 3.27 HLPSL code describing the role of WAAA server in WLLR .................................. 97  Figure 3.28 HLPSL code describing the role of the MS in Inter-WLAN FP ............................... 98  Figure. 3.29 Output message returned by SPAN after testing (a) WLLR by OFMC and (b) InterWLAN FP by CL-ATSE .............................................................................................................. 99  Figure 3.30 Output message returned by the AVISPA web interface after testing Intra-WLAN FP by SATMC ................................................................................................................................... 99  Figure 4.1 Standard default R6HO (HOB = 00) ......................................................................... 106  Figure 4.2 Standard default R3HO (HOB = 00) ......................................................................... 107  Figure 4.3 Standard optional R6HO (HOB = 10) ....................................................................... 108  Figure 4.4 Standard optional R3HO (HOB = 10) ....................................................................... 109  x  Figure 4.5 Modified INEA (mod-INEA) protocol ..................................................................... 112  Figure 4.6 R6 handover pre-authentication (HOB = 01) ............................................................ 114  Figure 4.7 A flow chart describing ASN-GW’s operation in R6HP protocol ............................ 116  Figure 4.8 R3 handover pre-authentication (HOB = 01) ............................................................ 118  Figure 4.9 A flow chart describing MS’s operation in R3HP protocol ...................................... 119  Figure 4.10 Network structure .................................................................................................... 120  Figure 4.11 HO signaling comparisons between Sn1, Sn2 and Sn3 when varying v ................. 126  Figure 4.12 HO Signaling comparisons between Sn1, Sn2 and Sn3 when varying R ............... 127  Figure 4.13 HO delay comparisons between Sn1, Sn2 and Sn3 when varying v ....................... 128  Figure 4.14 HO delay comparisons between Sn1, Sn2 and Sn3 when varying R ...................... 128  Figure 4.15 Numbers and sizes of keys generated by all the servers involved in the authentication procedure in the three scenarios when increasing the number of users in the cell ..................... 130  Figure 4.16 Numbers and sizes of keys generated by MSs performing R6HO and R3HO in Sn1, Sn2 and Sn3 ................................................................................................................................ 131  Figure 4.17 Algorithm for selecting nR6H and nR3H values.......................................................... 132  Figure 4.18 HLPSL code describing MS’s role in R6HP protocol ............................................ 134  Figure 4.19 Results of testing R6HP in (a) OFMC and (b) ATSE in SPAN.............................. 135  Figure 5.1 VHO procedures between WLAN and WiMAX as standardized by 3GPP and the WiMAX Forum for a 3GPP subscriber ...................................................................................... 141  Figure 5.2 Interconnection between WiMAX, WLAN and 3GPP authentication servers in the heterogeneous wireless network ................................................................................................. 143  Figure 5.3 Flow chart of our proposed protocols based on different HO situations .................. 144  Figure 5.4 WiMAX fast re-authentication (WiFR) .................................................................... 148  Figure 5.5 WiMAX proxy assisted re-authentication (WiPAR) ................................................ 150  Figure 5.6 WiMAX local re-authentication (WiLR) .................................................................. 152  Figure 5.7 WLAN fast re-authentication (WLFR) ..................................................................... 154  Figure 5.8 WLAN local re-authentication version 2 (WLLRv2) ............................................... 156  Figure 5.9 Algorithm used in calculating m when α = 2 ............................................................ 160  Figure 5.10 Possible combinations of proposed protocols when A = B = 2, nVHO = 4 and α = 1 161  Figure 5.11 Average (re-)authentication signaling comparison between standard and proposed protocols ..................................................................................................................................... 165  Figure 5.12 Average (re-)authentication signaling comparison between standard and proposed protocols when varying nVHO, A and B ....................................................................................... 166  xi  Figure 5.13 The effect of initially connecting to one of the networks in A or B. ...................... 167  Figure 5.14 Average (re-)authentication delay comparison between standard and proposed protocols ..................................................................................................................................... 168  Figure 5.15 Average (re-)authentication delay comparison between standard and proposed protocols when varying the number of hops between PAAA/WAAA and HAAA ................... 168  Figure 5.16 Number and size of keys generated by MS when adopting standard and proposed protocols ..................................................................................................................................... 171  Figure 5.17 Algorithm for selecting nVHO, nLR and nWRv2 values ................................................ 172  Figure 5.18 Algorithm for selecting nPAR value when α = 3 ....................................................... 173  Figure 5.19 Modified 3GPP-AKA (mod-3GPP-AKA) .............................................................. 178  Figure 5.20 Fast 3GPP-AKA Re-authentication (F3AR) ........................................................... 180  Figure 5.21 Example of MS movement when 4 VHOs are performed between 3GPP and WLAN .................................................................................................................................................... 181  Figure 5.22 VHO (re-)authentication protocols in the four scenarios when four VHOs are performed between 3GPP and WLAN ....................................................................................... 183  Figure 5.23 Comparison between Sn1, Sn2, Sn3 and Sn4 in terms of (re-)authentication signaling during VHOs between 3GPP and WLAN .................................................................................. 185  Figure 5.24 Comparison between Sn1, Sn2, Sn3 and Sn4 in terms of (re-)authentication delay during VHOs between 3GPP and WLAN .................................................................................. 185  Figure 5.25 Number and size of keys generated by the HSS during VHO re-authentications in Sn1, Sn2 and Sn3 ........................................................................................................................ 187  Figure 5.26 Number and size of keys generated by MS during VHO re-authentications in Sn1, Sn2 and Sn4 ................................................................................................................................ 188  Figure 5.27 Algorithm for selecting the value of nF3AR .............................................................. 189  Figure 6.1 Secure single hop authentication and single hop MIP registration ........................... 195  Figure 6.2 Multi-hop authentication protocol based on EAP-AKA protocol ............................. 200  Figure 6.3 Proposed secure multi-hop MIP registration scheme ................................................ 201  Figure 6.4 Single-hop MIP registration delay in the three schemes ........................................... 210  Figure 6.5 Multi-hop MIP registration delay in the three schemes when ECDSA is used ........ 212  Figure 6.6 Multi-hop MIP registration delay in the three schemes when RSA is used .............. 212  Figure 6.7 Communication overhead comparison between the three schemes when (a) ECDSA and (b) RSA is used .................................................................................................................... 215  xii  List of Acronyms 3G  3rd Generation Wireless System  3GHN  3GPP-based Home Network  3GPP  3rd Generation Partnership Project  3GPP-AKA  3rd Generation Partnership Project-Authentication and Key Agreement  AAA  Authentication Authorization and Accounting  AAP  Associated Access Point  AG  Authentication Gateway  AP  Access Point  ASN-GW  Access Server Network Gateway  AVISPA  Automated Validation of Internet Security Protocols and Applications  BS  Base Station  CA  Certificate Authority  CoA  Care of Address  DC  Digital Certificate  EAP  Extended Authentication Protocol  EAP-AKA  Extended Authentication Protocol-Authentication and Key Agreement  F3AR  Fast 3GPP-AKA Re-authentication  FA  Foreign Agent  HA  Home Agent  HAAA  Home Authentication Authorization and Accounting server  HAS  Home Authentication Server  HHO  Horizontal Handover  HO  Handover  xiii  HSS  Home Subscriber Server  IG  Internet Gateway  IMS  IP Multimedia Subsystem  IMSI  International Mobile Subscriber Identity  INEA  Initial Network Entry Access  Intra-WLAN FP  Intra-WLAN Fast Pre-authentication  Inter-WLAN FP  Inter-WLAN Fast Pre-authentication  MAC  Message Authentication Code  MANET  Mobile Ad hoc Network  MII  MANET-Internet Interworking  MIP  Mobile IPv4  MITM  Man-In-The-Middle  MSM  MS Address in the medium access control layer  Mod-3GPP-AKA  Modified 3GPP-AKA  Mod-EAP-AKA  Modified EAP-AKA  Mod-INEA  Modified INEA  MS  Mobile Station  PAAA  Proxy Authentication Authorization and Accounting server  PDG  Packet Data Gateway  PKI  Public Key Infrastructure  PKM  Privacy and Key Management  PS  Packet Switched  QoS  Quality of Service  R3HP  R3 Handover Pre-authentication  R6HP  R6 Handover Pre-authentication  SBS  Serving Base Station  xiv  SN  Serving Network  TAP  Target Access Point  TBS  Target Base Station  UICC  Universal Mobile Telecommunication System Integrated Circuit Card  UMTS  Universal Mobile Telecommunication System  USIM  Universal Mobile Telecommunication System Subscriber Identity Module  UTRAN  UMTS Radio Access Network  VHO  Vertical Handover  WAAA  WLAN Authentication Authorization and Accounting server  WiFR  WiMAX Fast Re-authentication  WiLR  WiMAX Local Re-authentication  WiMAX  Worldwide Interoperability for Microwave Access  WiPAR  WiMAX Proxy Assisted Re-authentication  WLAN  Wireless Local Area Network  WLFR  WLAN Fast Re-authentication  WLLR  WLAN Local Re-authentication  xv  List of Symbols |  Concatenation operator  ⊕  Exclusive OR operator  (* * )  Route record in MII  <A>K  A keyed message authenticated code of A calculated using key K in MII  AAK  ASN-level authentication key  AHK  ASN-level handover key  AK  Authorization key (re-authentication)  AKH  Authorization key (handover)  AN  Nonce generated by ASN-GW  CHHO  HHO counter. set by nHHO  CK  Cipher key  CLR  WiLR counter set by nLR  CPAR  WiPAR counter set by nPAR  CR3H  R3 HO counter set by nR3H  CR6H  R6 HO counter set by nR6H  CVHO  VHO counter set by nVHO  CWR  WLLR counter set by nWR  CWRv2  WLLRv2 counter set by nWRv2  DHK  Domain-level HO key  Dot16KDF  Key derivation function in IEEE 802.16e  DRK  Domain-level re-authentication key  EKAS-MS  MS and ASN-GW encryption key  EKPA-MS  MS and PAAA encryption key  EKWA-MS  MS and WAAA encryption key xvi  EMSK  Extended MSK  f  Key derivation function shared between nodes in the MII architecture  Hash  Publicly available hash function  HMAC  Publicly available HMAC function  HN  Nonce generated by the HAAA  HOK  Handover key  IDx  The identity of node x in MII  IK  Integrity key  IKAS-MS  MS and ASN-GW integrity key  IKPA-MS  MS and PAAA integrity key  IKWA-MS  MS and WAAA integrity key  IPx  The IP address of node x in MII  KAS-MS  MS and ASN-GW secret key  KDF  Key derivation function specified in EAP-AKA  KDF2  Key derivation function available in MS and SN  KFAx  A key shared between FA and MSx in MII  KHA-FA  A key shared between HA and FA in MII  KHAx  A key shared between HA and MSx in MII  Ksolx  Solicitation key shared between FA and MSx in MII  LRK  Local-level re-authentication key  LHK  Local-level HO key  MKAKA  Master key  MN  Nonce generated by the MS  MS-ID  Permanent MS ID  MSx Æ MSy  MSx sends a message to MSy in MII  MSK  Master session key xvii  nHHO  Number of horizontal HOs in 3GPP-WLAN  nLR  Permitted WiLR executions in a single ASN domain  nPAR  Permitted WiPAR executions  nR3H  Permitted number of R3 HOs  nR6H  Permitted number of R6 HOs in a single ASN domain  nVHO  Permitted number of VHOs between WiMAX and WLAN  nWR  Number of WLLR executions in a single WLAN domain  nWRv2  Permitted WLLRv2 executions in a single WLAN domain  Nx  A nonce generated by node x in MII  PAK  PAAA authentication key  PHK  PAAA handover key  PMK  Pairwise master key (re-authentication)  PMKH  Pairwise master key (handover)  PN  Nonce generated by the PAAA  R6-ID  Identity used in R6HP  R3-ID  Identity used in R3HP  t  A timestamp, an estimate of the current time used in MII  TASN-ID  Temporary identity used in WiLR  TEK  Transient EAP key  TicketPA  Tickets used to provide mutual authentication between the MS and  TicketMS  PAAA in 3GPP-WiMAX  TL-ID  Temporary local ID used in WLLR  TPA-ID  Temporary identity used in WiPAR  TWA-ID  Temporary identity used in WLLRv2  VHO-ID  VHO identity used by MS in WiFR and WLFR  WiCH  Authentication challenges in WiFR xviii  WiRP  Authentication reply in WiFR  WLCH  Authentication challenge in WLFR  WLRP  Authentication reply in WLFR  WN  Nonce generated by WAAA  xix  Acknowledgements I would like to profoundly thank my supervisor Dr. Victor Leung for his continuous support, encouragements and guidance throughout the years I spent at UBC. Without his wisdom and valuable suggestions, this work would have not materialized. I’m truly honored to be supervised by a pioneer researcher in the field of wireless communications. I would like to also thank my supervisory committee members; Dr. Vincent Wong, Dr. Son Vuong and Dr. Konstantin Beznosov, my university examiners; Dr. Alan Wagner and Dr. Jane Wang and finally my external examiner Dr. Xuemin Shen from University of Waterloo. I also would like to extend my thanks and gratitude to all the friends and colleagues I met in Vancouver. Each and every one of them supported me in one way or the other to complete this work. Our work was supported in part by the Sultan Qaboos University under Contract number 1907/2005, Bell Canada and the Natural Sciences and Engineering Research Council of Canada under grant CRDPJ 328202-05.  xx  Dedication  To my parents, words can’t describe how lucky I’m to be your son To my wife, your unconditional love and support is what keeps me going To my kids, the joy you brought to my life is second to none  xxi  Chapter 1: Introduction Individuals and business corporations rely on electronic businesses and online shopping thanks to the proliferation of fast Internet access services. Wireless Internet access technologies offer mobile users the enjoyment of accessing the Internet on the move. Securing wireless Internet access is a major concern in service provider’s perspective. Due to the open wireless access medium and the limitation in bandwidth and processing capabilities in wireless devices, it is more challenging to secure wireless communications comparing to wired communications [1]. Security received little attention in the past. Security services were not seriously considered in the design phase of legacy systems and were later added as short term solutions to security problems. Consideration for security threats must be addressed and integrated in the design of new wireless technologies to ensure their reliability. In this Chapter, we describe the wireless network architectures addressed in this thesis and identify the security-related problems occurring in these architectures. We also describe our motivations to solve these problems and summarize our technical contributions. This Chapter is organized as follows: Section 1.1 overviews existing wireless Internet access technologies and discusses the relationship between security strength and system performance. Section 1.1 also defines several interworking architectures discussed in the thesis. Section 1.2 discusses the motivations and objectives of our work. Section 1.3 outlines our contributions. Section 1.4 describes the organization of this thesis.  1.1 Overview 1.1.1 Wireless Internet access technologies The 3rd Generation (3G) mobile communication system provides global, voice-centric services and supports low data rate and relatively costly packet-switched and Internet services to subscribers. The Universal Mobile Telecommunication System (UMTS) is a widely 1  implemented flavor of 3G. UMTS is standardized by the Third Generation Partnership Project (3GPP) [2]. UMTS and succeeding 3GPP1-based technologies are simply referred to as “3GPP” in this thesis. Wireless Local Area Networks (WLANs) are a popular wireless access technology for home and small office environments. They offer higher data rates compared to 3GPP, are less costly to install, but span hundreds of meters only. IEEE 802.11 [3] is the driving technology for WLANs. The Worldwide Interoperability for Microwave Access (WiMAX) is based on IEEE 802.16 [4] wireless metropolitan area network standard. WiMAX technology presents a cheap option for extending service coverage to remote areas and supports broadband wireless Internet access. Initially, WiMAX supported fixed broadband wireless access. Lately, IEEE 802.16e [5] amendment enabled mobile access and provided security and Quality of Service (QoS) enhancements. The WiMAX Forum is a not-for-profit industry-led organization that certifies WiMAX products and publishes specifications on WiMAX products interoperability [6]. Since WiMAX, WLAN and 3GPP access networks complement each other in terms of infrastructure and service cost, service quality, network coverage and bandwidth, researchers investigated possible interworking scenarios between these technologies. A “heterogeneous wireless network” is formed by combining the three access technologies and linking them to a 3GPP-based Home Network (3GHN). Such a heterogonous network could shape the platform for future innovative services and applications. Some researchers refer to such a heterogeneous architecture as Beyond 3G (B3G) architecture or the 4th Generation network (4G) [43], [72]. In the thesis, the interworking between 3GPP access network, WLAN and WiMAX with the 3GHN is only referred to as a “heterogeneous wireless network”. Two parts of the heterogeneous wireless network are separately addressed as well in this thesis: firstly, the 3GPP-WLAN interworking architecture, and secondly, the 3GPP-WiMAX interworking architecture. 1 To avoid confusion, “3GPP” in regular type refers to the wireless technology while “3GPP” in bold type refers to the 3rd Generation Partnership Project standardization body.  2  1.1.2 Relationship between security strength and performance in the heterogeneous wireless network Several security and performance challenges exist in the heterogeneous wireless network. Security issues are addressed in terms of three essential security services: authentication, confidentiality and integrity [7]. Confidentiality is hiding highly sensitive data during information transmissions and integrity is preserving the accuracy of the transmitted information. Authentication services ensure that only legitimate users are allowed to access the network. Mutual authentication between users and the network is essential. The network must authenticate users to ensure their legibility to receive services. In addition, users must authenticate the network to confirm its legitimacy. Along with authentication comes key management. It is always desired to establish an efficient and secure key management scheme between authenticated users and different nodes in the network. In the context of wireless technologies, a security protocol encompasses all security related operations like the provision of user authentication, the protection of message integrity and the provision of message confidentiality. The latency experienced by wireless nodes and the signaling overhead introduced in the network due to executing a security protocol describe the performance of the security protocol. Typically, there is a tradeoff between security strength and performance [139]. On one hand, strong security protocols undergo complex operations and intensive processing. This negatively affects the performance of the security protocol. Negative performance is characterized by high latency in completing the security protocol and redundant security-related message signaling. On the other hand, relaxing some security features of a security protocol positively impacts performance but subjects the network to a variety of security attacks. In the heterogeneous wireless network as well as its two subsections, i.e., the 3GPPWLAN and the 3GPP-WiMAX interworking architectures, the Mobile Station (MS) holds 3  security credentials initially supplied by the 3GPP service provider. Therefore, MS authentication is always handled by the authentication servers in the 3GHN. The MS might require re-authenticating with the authentication servers in the 3GHN due to the expiration of a security key it maintains with the wireless attachment point. Furthermore, re-authentication could be instigated by a handover (HO) operation. HOs in general are classified into horizontal and vertical HOs [9]. A Horizontal HO (HHO) occurs when roaming within a network employing the same wireless technology while a Vertical HO (VHO) occurs when roaming between networks employing different wireless technologies. In the 3GPP-WLAN interworking architecture, the MS and the authentication servers in the 3GHN achieve mutual authentication by executing the Extensible Authentication ProtocolAuthentication and Key Agreement protocol (EAP-AKA) [8]. Repetitive invocation of EAPAKA by stationary and mobile users might result in high authentication delays and might introduce unnecessary signaling and processing overhead [24], [38], [39], [110]. These delays might affect the (QoS) of the applications running on the MS and might lead to user inconvenience especially during a HO. The 3GPP-WiMAX interworking architecture specified by the WiMAX Forum [10] undergo similar security and performance challenges to the 3GPP-WLAN interworking architecture. The Privacy and Key Management (PKM) protocol [5] is the security protocol adopted by the WiMAX Forum and by IEEE 802.16e specification to secure the communications between the MS and the WiMAX attachment point in the 3GPP-WiMAX interworking architecture. PKM relies on EAP-AKA protocol to mutually authenticate the MS and the 3GHN. Thus, the authentication operation in the 3GPP-WiMAX interworking architecture is prone to high authentication delays, especially when the MS performs HHOs between WiMAX networks [55]. The WiMAX Forum introduced lightweight HHO protocols to improve the performance of  4  the HO procedure [5], [15]. However, the proposed protocols introduce serious security problems. In the heterogeneous wireless network, the MS might prefer switching from one wireless technology to another, by performing a VHO, in search for an enhanced download rate or cheaper service cost. For example, the MS might be connected to a 3GPP network but prefers to perform a VHO to a WLAN to download videos from the Internet faster with a lower cost. One of the important phases in the VHO procedure is the establishment of mutual authentication between the MS and the target network. It is always desired to minimize the latency in completing the VHO procedure [140]. Several proposals have been presented in the literature to reduce the delay caused by performing VHOs [54], [67], [71], [72], [73], [77], [78], and [80]. Yet, little work has been directed towards reducing the delay caused by authentication. Since authentication delay constitutes a major part of the overall VHO delay, reducing the authentication delay greatly aids in minimizing the latency experienced during a VHO procedure.  1.1.3 Interworking between mobile ad hoc networks and the Internet MSs could be residing outside the communication range of the wireless attachment point. Therefore, the visiting MS may deploy multi-hop communication methods to reach the wireless attachment point. Intermediate MSs relaying the multi-hop communications between the visiting MS and the wireless attachment point forms a Mobile Ad Hoc Network (MANET). MANETs are created by intercommunicating wireless nodes on-the-fly to accomplish a specific ad-hoc task. Since MANETs operate in a shared wireless medium with the absence of a centralized security infrastructure, it is prone to security attacks, and messages exchanged in the MANET are assumed to be traveling in a hostile environment [11]. The disadvantage of autonomous MANETs is their lack of Internet reachability. Various techniques have been proposed to 5  provide Internet reachability to MSs in the MANET [12] by interworking them with a wireless access network. This interworking architecture is also known as a MANET-Internet interworking (MII) architecture. Mobile IP (MIP) [13] is widely used to support mobility and provide Internet reachability to MSs in wireless networks. Typically, a MS visiting a foreign IP network performs two tasks: firstly, authenticate with its home network, secondly, perform a secure MIP registration scheme. The MIP registration scheme includes a secure discovery of a local mobile agent to acquire a temporary IP address, also known as a Care of Address (CoA), and a secure CoA registration between the visiting MS and its home network. This registration permits Internet reachability to the visiting MS in the MII architecture. There is a need to secure single-hop and multi-hop MIP registration messages in the MII architecture. Messages traveling between the visiting MS and its home network must be protected against tampering and modifications. Additionally, mutual authentication between the visiting MS and various nodes involved in the MIP registration scheme must be maintained.  1.2 Motivations and objectives The provision of fast data services is essential to both the service provider and to end users. Security is no less important. Only legitimate users must be allowed to benefit from a service and must be billed according to service usage. The service provider must employ a strict authentication and key management procedure to stop impersonation attacks and attacks based on modifying and tampering transient messages. When dealing with multiple wireless access technologies, the level of security of the heterogeneous wireless network depends on the level of security of each wireless access technology. It is challenging to design security protocols that preserves strict security features and performs efficiently at the same time. Our objective is to design security protocols that balance 6  security and performance by applying minor modifications to the existing standard security protocols and architectures. Four network architectures are addressed in this thesis: firstly, the 3GPP-WLAN interworking architecture, secondly, the 3GPP-WiMAX interworking architecture, thirdly, the 3GPP-WiMAX-WLAN interworking architecture or the heterogeneous wireless network, and fourthly, the MII architecture. Next, we overview the problems existing in each network architecture and describe our motivations to solve these problems. In the 3GPP-WLAN interworking architecture, MS authentication is handled by the 3GHN. It is inefficient for stationary and mobile users to communicate with the 3GHN whenever (re-)authentication is required. Research studies show that authentication delay greatly influences link-layer HO delay when a remote authentication server is required to complete authentication [141], [142]. It was found that authentication delay constitutes 85% [141] and 64% [142] of the total HO delay in WLAN environments depending on different experimental setups. Thus, minimizing authentication delay can greatly improve HO performance. EAP-AKA proposed by the Internet Engineering Task Force (IETF) [14] and recommended by 3GPP emphasizes on security over performance. Alternative security protocols proposed in the literature enhance performance but adopt security protocols other than EAP-AKA or introduce major modifications to the interworking architecture [38], [39], [40], [43], and [53]. This problem motivates us to design protocols to protect stationary and mobile users roaming in the 3GPP-WLAN interworking architecture. Our proposed protocols are based on EAP-AKA and take an equal stand towards security strength and performance. The proposed protocols achieve mutual authentication between the MS and authentication servers in the 3GHN. In addition, the protocols establish a secure key management distribution scheme that results in generating fresh keys to secure the communications between the MS and the wireless attachment point. Mutual authentication is completed efficiently with minimum communications between the MS and the 3GHN. 7  In the 3GPP-WiMAX interworking architecture, a MS may perform HHOs between different WiMAX networks when it detects poor signal strength from the currently associated attachment point. The standard HHO procedures defined in IEEE 802.16e [5] and in the WiMAX Forum specifications [15] suffers from high HO delays. This is due to the high authentication delay resulting from frequent authentication exchange between the MS and the authentication servers in the 3GHN. IEEE 802.16e and the WiMAX Forum introduced an optional, optimized HHO procedure that aims to improve performance [5], [15]. Nonetheless, performance improvements came at the detriment of a secure key management scheme, thus, surrendering the interworking architecture to a wide variety of security attacks. This problem motivates us to design a performance-enhanced and secured HHO protocols for the 3GPPWiMAX interworking architecture. Two novel HHO protocols are designed to handle different MS movements. The proposed protocols share similar security qualities as the standard default HHO protocols; and concurrently displays similar performance features as the standard optional HHO protocols proposed by IEEE 802.16e and the WiMAX Forum [5], [15]. In the heterogeneous wireless network, a MS might prefer performing VHOs between different wireless technologies in search for a cheaper service, improved service quality or simply higher download speed. One of the important characteristics of an efficient VHO procedure is the capability to perform it promptly and securely. Most of the proposed VHO procedures in the literature favored security over performance or vice versa. Some proposed protocols with a balance attitude towards security and performance are often impractical or require additional elements to exist in the heterogeneous wireless network [67], [72], and [73]. During a VHO, authentication-related messages have to travel to the 3GHN. Other VHO messages are exchanged between the serving and the target network without communicating with the 3GHN. Therefore, the authentication activity leads to high VHO signaling and delay. This problem motivates us to design expedited VHO re-authentication procedures to be used 8  when the MS roams in the heterogeneous wireless network without degrading security. A set of protocols are designed to be executed when the MS performs VHOs between WiMAX, WLAN and 3GPP access network. The proposed re-authentication protocols shorten the authentication activity required during VHOs without subjecting the heterogeneous wireless network to authentication-related attacks. In the previously described network architectures, the visiting MS is assumed to be a single-hop away from the wireless attachment point. On the contrary, in the MII architecture, the visiting MS might not reside within the coverage area of the wireless attachment point, and, multi-hop communication methods are adopted by the visiting MS to reach the wireless attachment point. The visiting MS needs to authenticate with its home network and performs a secure and efficient MIP registration. Several proposals are recorded in the literature that tried to address securing MIP operations in MII environments [87], [88], and [94]. The downside to these proposals is their excessive dependability on asymmetric key operations like digitally signing/verifying transient messages. Generally, asymmetric key based protocols incur additional processing delay and demand higher energy consumption compared to symmetric key based protocols [138], [130]. Adopting asymmetric key based security protocols in the MII architecture might be inefficient and infeasible considering the limited processing capabilities held by MSs and the dynamic nature of MANETs. This problem motivates us to design a symmetric key based multi-hop authentication protocol and a secure and efficient multi-hop MIP registration scheme. The registration scheme includes a secure and efficient multi-hop mobile agent discovery procedure and a secure and efficient multi-hop CoA registration procedure. Our solution does not require asymmetric key operations; therefore, they are fast, feasible and capable of protecting the MII architecture.  9  1.3 Main contributions Several contributions are presented in this thesis. Each contribution targets specific problems and limitations relevant to each of the four network architectures. The main contributions are as follows: 1- Design of a fast re-authentication protocol for stationary users in the 3GPP-WLAN interworking architecture: The WLAN Local Re-authentication protocol (WLLR) is designed for stationary users that require re-authentication with the same WLAN attachment point in the 3GPP-WLAN interworking architecture. To efficiently execute WLLR, modifications to the standard EAP-AKA protocol are proposed. A security association is established between the MS and a local authentication server in the WLAN when the proposed modified EAP-AKA protocol is executed. WLLR takes advantage of this association and enables a local re-authentication protocol that does not demand interaction with the authentication servers in the 3GHN. 2- Design of fast pre-authentication protocols for mobile users roaming in the 3GPPWLAN interworking architecture: We design two pre-authentication protocols to be executed by MSs performing HHOs between WLANs in the 3GPP-WLAN interworking architecture. An execution of the modified EAP-AKA protocol must occur before these proposed protocols can be performed. The proposed protocols are the Intra-WLAN Fast Preauthentication (Intra-WLAN FP) and the Inter-WLAN Fast Pre-authentication (Inter-WLAN FP). The MS invokes Intra-WLAN FP when it performs a HHO with a target network that is controlled by the same local authentication server the MS is currently associated with. In Intra-WLAN FP, pre-authentication takes place locally between the MS and the local authentication server it is currently associated with prior to the HHO procedure. Inter-WLAN FP is invoked when the target network is controlled by a remote authentication server. In this case, the pre-authentication takes place between the MS, the currently associated local 10  authentication server, the remote authentication server and an authentication server in the 3GHN. 3- Design of performance-enhanced and secured horizontal handover protocols for the 3GPP-WiMAX interworking architecture: We design a secured and fast HHO protocols to be executed by MSs when performing WiMAX HHOs in the 3GPP-WiMAX interworking architecture. Two HHO protocols are designed, R6 Handover Pre-authentication protocol (R6HP) and R3 Handover Pre-authentication protocol (R3HP). The WiMAX Access Service Network Gateway (ASN-GW) controls several WiMAX base stations. R6HP is executed when the MS performs intra ASN-GW HHO while R3HP is executed when the MS performs inter ASN-GW HHO. The proposed protocols piggyback authentication related queries on HO control messages to avoid initiating a separate authentication session during HOs. 4- Design of fast vertical handover re-authentication protocols for the heterogeneous wireless network: We design fast re-authentication protocols to be executed when MSs perform VHOs in the heterogeneous wireless network. For application in the event of a VHO from WLAN/WiMAX to 3GPP, the Fast 3GPP-AKA Re-authentication protocol (F3AR) is proposed. To secure VHOs between WiMAX and WLAN, five re-authentication protocols have been proposed. These protocols are the WiMAX Fast Re-authentication protocol (WiFR), the WiMAX Local Re-authentication protocol (WiLR), the WiMAX Proxy Assisted Re-authentication protocol (WiPAR), the WLAN Fast Re-authentication protocol (WLFR), and the WLAN Local Re-authentication version 2 protocol (WLLRv2). The proposed protocols reuse previously derived root keys to speed the re-authentication procedure during VHOs. Moreover, they minimize the involvement of authentication servers in the 3GHN during a VHO. 5- Design of secure and efficient multi-hop MIP registration scheme for the MANETInternet interworking architecture: We design a multi-hop authentication protocol to serve 11  visiting MSs residing outside the communication range of the wireless attachment point. In addition, we design a secure and efficient multi-hop MIP registration scheme that includes a secure and efficient multi-hop mobile agent discovery procedure and a secure and efficient multi-hop CoA registration procedure. We also extend our proposed MIP registration scheme to support Mobile IPv6. 6- Security validation of the proposed authentication protocols: The security properties of the protocols proposed for the heterogeneous wireless network are validated and examined using the Automated Validation of Internet Security Protocols and Applications (AVISPA) [16] security analyzer. AVISPA is a package used to test and validate the security of largescale Internet security protocols. Each proposed protocol is coded using a programming language understandable by AVISPA. These codes can aid researchers willing to build on or enhance our proposed protocols in the future.  1.4 Organization of the thesis In this thesis, each chapter discusses the research problems and the proposed solutions pertinent to each of the four network architectures. Figure 1.1 depicts the organization of the thesis. The remainder of the thesis is organized as follows. In Chapter 2, we elaborate on the four network architectures. We also discuss the research problems and related works associated with the four network architectures. In Chapter 3, we propose solutions to the problems existing in the 3GPP-WLAN interworking architecture. In Chapter 4, we introduce our proposed performanceimproved and secured HHO protocols for the 3GPP-WiMAX interworking architecture. In Chapter 5, we present protocols to reduce re-authentication delays experienced by the MS when performing VHOs in the heterogeneous wireless network. In Chapter 6, we propose secure and efficient multi-hop MIP registration scheme for the MII architecture. Chapter 7 concludes the thesis, and suggests possible future research. 12  Figure 1.1 Organization of the thesis  13  Chapter 2: Authentication in heterogeneous wireless networks* 2.1 Introduction This chapter describes the four network architectures discussed in Chapter 1 and presents standard authentication protocols employed in the architectures. In addition, relevant related works appeared in the literature are listed. UMTS network architecture is described in Section 2.2.1 as an example of 3GPP network architecture. The 3GPP-WLAN interworking architecture, the 3GPP-WiMAX interworking architecture, the heterogeneous wireless network architecture and the MII architecture are discussed in Sections 2.2.2, 2.2.3, 2.2.4 and 2.2.5, respectively. In Section 2.3, we briefly describe the threat model we assume to exist. In Section 2.4, we overview the standard authentication protocols used to authenticate MSs attempting to access the heterogeneous wireless network. 3GPP-Authentication and Key Agreement protocol (3GPPAKA) [17] is described in Section 2.4.1. EAP-AKA protocol is described in Section 2.4.2. Section 2.5 elaborates on related work attempted to solve security and performance problems in each of the four network architectures. The related work on enhancing the authentication procedure for stationary and mobile users in 3GPP-WLAN are presented in Sections 2.5.1 and 2.5.2, respectively. Section 2.5.3 lists proposals attempting to achieve secure and efficient HHOs in 3GPP-WiMAX. Section 2.5.4 lists the related work associated with achieving fast authentication during VHOs in the heterogeneous wireless network. Section 2.5.5 lists the related work directed towards securing the multi-hop MIP registration in the MII architecture.  * Parts of this Chapter have been published in Security in Distributed and Networking Systems, Y. Xiao and Y. Pan, ed., World Scientific Publishing Co., August 2007 [95].  14  2.2 Network architectures 2.2.1 The UMTS network architecture 3G supports higher data rates and improved packet-switched services in comparison to the 2nd generation mobile communication system (2G). UMTS is a widely deployed flavor of 3G. The MS in the UMTS accesses the network through a UMTS Radio Access Network (UTRAN) subsystem which consists of Node B and Radio Network Controllers (RNC). The RNC forwards packet-switched data from the MS to the Internet through the Packet Switched Core Network (PS-CN), which consists of the Serving General Packet Radio Service (GPRS) Supporting Node (SGSN) and the Gateway GPRS Supporting Node (GGSN). Circuit Switched Core Networks (CS-CN) also exist to support voice services. Network elements responsible for providing roaming services are the SGSN and the Visitor Location Registry (VLR); they form the Serving Network (SN). Network elements responsible for storing subscriber’s security credentials are the Home Location Registry (HLR) and the Authentication Center (AuC). The UMTS Subscriber Identity Module (USIM) is a software application hosted by a tamper-resistant smart card known as the UMTS Integrated Circuit Card (UICC). The USIM/UICC is issued by the UMTS service provider and placed in the MS to store identifiers and secret keys shared with the AuC. USIM/UICC has the capability to process cryptographic algorithms for authentication and encryption purposes. A simplified UMTS architecture is shown in Figure 2.1. 3GPP specified a security extension of the Mobile Application Protocol (MAPsec) [18] to secure communications between nodes in the UMTS Home Network. MSs attempting to access the UTRAN must perform the 3GPP-Authentication and Key Agreement protocol (3GPPAKA) [17]. UMTS and other succeeding 3GPP technologies depend on authentication servers in the home network to authenticate 3GPP subscribers. Throughout the thesis, interaction between 15  users and these authentication servers are discussed. Therefore, the term “3GPP” is used to indicate UMTS and successor 3GPP-based technologies in the thesis. 3GPP encompasses an access network, like UTRAN in UMTS, and a 3GHN.  Figure 2.1 Simplified UMTS architecture  2.2.2 3GPP-WLAN interworking architecture WLANs support higher data rates, limited coverage and low implementation and service cost compared to 3GPP. Clearly both technologies complement each other, and a network which combines both technologies will benefit both end users and the service provider. End users can enjoy high speed and cost effective services. The 3GPP service provider can offer new services to utilize the increased bandwidth brought by interworking WLANs. Innovative applications that require better QoS like video conferencing and real-time applications can be offered. With such coexistence, users can seamlessly HO from 3GPP to WLAN and vice versa without serious service disruption. 3GPP-WLAN interworking is introduced in Release 6 of 3GPP specifications [19]. Researchers broadly classified 3GPP-WLAN interworking architectures to tightlycoupled and loosely-coupled approaches [20], [21]. In the tightly-coupled approach, the WLAN is treated, from 3GHN’s perspective, as another 3GPP access network directly connected to the 16  3GHN through the SGSN. The advantage is that WLAN authentication is handled by the 3GPPAKA protocol. The drawback is that WLAN and 3GPP networks must be owned by the same service provider and some 3GPP network components needs to be modified to support higher bit rate traffic delivered by WLAN [22]. In the loosely-coupled approach, WLANs are treated as a separate access network complementary to 3GPP access network while maintaining a direct connection to the Internet. In contrast to the tightly-coupled approach, data traffic in the loosely-coupled approach could access the Internet directly without passing through the 3GHN. This scheme is more desirable because 3GPP and WLANs belonging to different operators can co-exist with minimum modifications, resulting in less complex and less expensive interworking system. However, this approach is challenging because WLAN authentication is not controlled by the 3GPP network, hence WLAN authentication needs to be elevated to 3GPP authentication levels. 3GPP has specified six interworking scenarios between 3GPP and non-3GPP networks [23]: 1- Common billing and customer care. Subscribers receive a unified bill for 3GPP and non3GPP services. No interworking is required. 2- 3GPP system based access control and charging. In this scenario, Subscriber's authentication, authorization and accounting are handled by the 3GPP network. This is to provide higher security measures when accessing the Internet through a non-3GPP network. Users undergo 3GPP-based authentication challenges and key agreements to be able to directly access the Internet. Interaction between 3GPP and non-3GPP in this scenario is limited to the transportation of AAA traffic to authenticate users. 3- Access to the 3GPP Packet Switched (PS) based services. 3GPP subscriber accessing through the non-3GPP network can access the 3GPP PS based services, i.e., IP services, like Multimedia Message Services (MMS), IP Multimedia Subsystem (IMS) and the Internet.  17  Clearly this is an extension to scenario 2 because users have the capability to access PS based services provided by 3GHN in addition of being able to directly access the Internet. 4- Service continuity. This scenario guarantees the continuity of services when changing the access network from 3GPP based network to non-3GPP based network and vice versa. Change in access network may be noticeable by users and the service quality might not be maintained when moving to a new access network. 5- Seamless service continuity. This scenario improves on scenario 4 by seamlessly changing the access network without users notice and with minimum HO delay and data loss. 6- Access to 3GPP Circuit Switched (CS) service. This scenario permits users the access to 3GPP CS services over the non-3GPP access network. As scenarios move from 1 to 6, the two networks becomes more integrated and requires additional modifications to support the interworking. Scenario 1 requires no integration while scenario 6 requires very tight integration. In interworking scenario 2 and upwards, the 3GPP controls users’ authentication. Figure 2.2 pictures a simplified 3GPP-WLAN interworking architecture following a nonroaming reference model suggested by 3GPP [19]. Only the PS side of the 3GHN is shown. Three elements constitute this architecture; they are: •  The MS. It must support WLAN and 3GPP radios. It must have a USIM/UICC to be able to compute session keys and perform cryptographic operations.  •  The WLAN Access Network (WLAN-AN). The MS accesses the 3GPP-WLAN interworking system through this access network. The WLAN-AN consists of Access Points (APs), Authentication Authorization and Accounting (AAA) servers and access gateways. WLAN AAA (WAAA) handles AAA traffic and the access gateway handles the data traffic.  •  The 3GHN. It includes the Home AAA server (HAAA) and the Home Subscriber Server (HSS). The 3GPP operator issues the USIM/UICC and stores WLAN subscriber profiles in 18  the HSS. A WLAN subscriber’s profile includes the subscriber’s identity and authentication/authorization information. The HSS takes over the roles of HLR and AuC starting from 3GPP Release 6. The 3GHN also includes a Packet Data Gateway (PDG) and a Wireless Access Gateway (WAG), which handles data traffic. Roaming and trust agreements must be pre-established between 3GPP and WLAN operators.  Figure 2.2 Simplified 3GPP-WLAN interworking architecture  As shown in Figure 2.2, the network nodes used to handle authentication operations are the WAAA and the HAAA. Routing data traffic to/from the MS depends on the interworking scenario. In scenario 2, data traffic originated from the MS accesses the Internet directly. In scenario 3, the MS has the capability to access PS based services in the 3GHN, hence data traffic is routed by the access gateway in the WLAN-AN to the WAG in the 3GHN, which routes the traffic to the PDG in the PS segment of the 3GHN. In addition to routing packets to the PDG, WAG forwards subscriber’s charging information like bytes count and service duration used in billing settlements between 3GPP and WLAN operators. WAG also plays the role of a simple firewall and policy enforcement point to control traffic going to the PDG [24]. The PDG functions as a gateway to the 3GPP PS based 19  services and other Public Data Networks (PDN) in the 3GHN. It routes data traffic received from the MS to the PDN and vice versa. The MS initiates a security tunnel to the PDG to securely transmit/receive data traffic to/from the 3GPP PS based service and the PDN. As shown in Figure 2.2, reference point Wa is responsible for carrying AAA traffic in the interworking system. Reference points Wn and Wp are responsible for carrying data traffic to the 3GHN. Reference point Wx is used by the HAAA to retrieve subscriber’s authorization profile from the HSS. The Wx interface supports either AAA protocols or MAPsec protocol. Security solutions for the 3GPP-WLAN interworking architecture must encompass enough strength to resist all types of attacks against autonomous 3GPP, autonomous WLAN and the interworking architecture. 3GPP specifications suggested that the authentication mechanisms and the key distribution strategies in the 3GPP-WLAN interworking should be based on 3GPPAKA and AAA protocols like Radius and Diameter [25], [26], [27]. 3GPP suggested using EAP [28] to achieve authentication. EAP is an end-to-end protocol that can utilize various authentication mechanisms regardless of the lower layers protocols. Since the MS is equipped with a USIM/UICC, 3GPP recommends using EAP-AKA protocol designed by the IETF [8].  2.2.3 3GPP-WiMAX interworking architecture 3GPP provides excellent support for voice communications, but support for data communications and multimedia is limited and maybe more costly. WiMAX is a wireless metropolitan area network technology based on IEEE 802.16 [4] standard. WiMAX presents a cheap option for extending coverage to areas not covered by 3GPP with the benefit of broadband wireless access. The technology addresses the “last-mile” access case in remote areas. Initially, WiMAX technologies supported fixed broadband wireless accesses. Lately, IEEE 802.16e [5] amendment enables mobile accesses and provides security and QoS enhancements.  20  Interworking 3GPP and WiMAX is a fairly new concept comparing to 3GPP-WLAN interworking. 3GPP-WiMAX interworking offers a global roaming, QoS support, reliable voice services, high data rate packet services and cost effective wireless access to the Internet. The WiMAX Forum considered the six interworking scenarios between 3GPP and non-3GPP networks listed in Section 2.2.2 [10], [19]. As per the specifications published by the WiMAX Forum, 3GPP-WiMAX interworking is based on the 3GPP-WLAN interworking model specified by 3GPP [10], [19]. A simplified version of the 3GPP-WiMAX interworking architecture with emphasis on the PS side of the 3GHN is shown in Figure 2.3.  Figure 2.3 Simplified 3GPP-WiMAX interworking architecture  The MS holds 3GPP credentials and supports 3GPP and WiMAX radio interfaces. The MS initially communicates with a WiMAX Base Station (BS) located in the WiMAX Access Service Network (ASN). The BS is connected to an ASN-GW which functions as a gateway to other elements in the interworking architecture and operates as an AAA server. The ASN-GW links to the 3GHN through a WiMAX Connectivity Service Network (CSN). The CSN contains a Proxy AAA server (PAAA) and an Interworking Gateway. As in the 3GPP-WLAN interworking architecture, the 3GHN includes a WAG and a PDG, which forwards data traffic to 21  and from the MS to the Internet. In addition, the HSS and the HAAA resides in the 3GHN. These servers handle authentication procedures in addition to the PAAA which relays AAA messages between MSs and the 3GHN. Mutual authentication between MSs and the HSS/HAAA is an important step during initial network entry. IEEE 802.16e introduced the Privacy and Key Management protocol version 2 (PKMv2) [5] which handle authentication and key management procedures between MS and BS. The Initial Network Entry Authentication protocol (INEA) is first performed by MS when entering a WiMAX network as part of PKMv2 [15]. EAP-AKA is executed during INEA to achieve mutual authentication between MS and HSS/HAAA in the 3GPP-WiMAX architecture [10]. The MS may perform HHOs across different WiMAX BSs to seek stronger signals. A HO is considered intra-ASN when the serving and target BSs are controlled by the same ASN-GW. This is also known as a R6 Handover (R6HO). An inter-ASN HO is performed when serving BS and target BS are controlled by different ASN-GWs. This type of HO is also known as R3 Handover (R3HO). Intra and inter ASN HOs are shown in Figure 2.3.  2.2.4 Heterogeneous wireless network architecture Wireless technologies can be clustered with respect to their coverage areas to local area networks, metropolitan area networks and wide area networks. WLANs are an example of the local area network, WiMAX is an example of the metropolitan area network and 3GPP is an example of the wide area network. The heterogeneous wireless network composes of the WLAN, WiMAX and 3GPP access networks all linked to the 3GHN. Typically, WiMAX and WLAN domains are viewed as pockets of broadband access networks in the heterogeneous wireless network. The 3GHN is the glue that connects WiMAX and WLAN to the 3GPP network and authentication servers in the 3GHN are responsible for authenticating users accessing the heterogeneous wireless network over 3GPP or non-3GPP access networks. 22  3GPP, WiMAX and WLAN complement each other such that the downside of one technology is in fact the strength of the other. Users might prefer switching from one wireless technology to the other, i.e., perform a VHO, based on service cost, quality, speed and availability provided by one network or the other. For example, a fast moving user launches an online videoconferencing application and performs a VHO to the WiMAX network to capitalize on the guaranteed QoS support. Later, the user starts downloading a huge file from the Internet and decides to switch to a WLAN for a cheaper service. Due to limited WLAN coverage, the user might travel beyond the coverage area of the WLAN and opt to perform another VHO to the WiMAX to continue downloading the file all while engaging in a voice-based communication session over the 3GPP access network.  Figure 2.4 Simplified heterogeneous wireless network  One of the challenges impeding smooth VHO in the heterogeneous wireless network is realizing efficient mutual authentication between users and the target network. As per 3GPP and WiMAX Forum specifications, 3GPP subscribers roaming in the heterogeneous wireless network must be authenticated by the authentication servers in the 3GHN. A MS attempting to access the heterogeneous wireless network from the 3GPP access network, WLAN and WiMAX 23  is recommended to perform 3GPP-AKA, EAP-AKA and INEA, respectively. Figure 2.4 depicts a simple heterogeneous wireless network showing only the PS side of the 3GHN.  2.2.5 Interworking between mobile ad hoc networks and the Internet A MANET consists of a collection of MSs capable of intercommunicating and relaying messages to each other in the absence of a centralized infrastructure. MSs in a MANET are equipped with varying computation powers and storage capacities. MANETs are favorable for applications where quick deployment and self network organizations are required between MSs. One of the limitations of MANETs is the lack of Internet connectivity. A MS visiting a foreign IP network could sustain its Internet reachability by employing the MIP [13] protocol. Wireless attachment points like APs in IEEE 802.11 WLAN and BSs in IEEE 802.16 WiMAX have a fixed coverage area and could be congested when serving huge number of MSs. Interworking MANETs with wireless access networks permits extensions to the coverage area provided by the wireless attachment point and could aid in load balancing the traffic in the network [29]. Figure 2.5 depicts the MII architecture, where visiting MSs obtain Internet connectivity using MIP through the wireless access network. MSs residing outside the coverage area of a wireless attachment point but belong to a MANET depend on multi-hop communication methods and intermediate nodes in the MANET to relay messages to/from the wireless attachment point. In Figure 2.5, MS3, MS6 and MS7 reside outside the coverage area of the wireless attachment point. MS3 is a new visiting MS which adopts multi-hop communication methods with intermediate nodes like MS1, MS2, MS4 and MS5 to communicate with the wireless attachment point. Two gateways exist in the MII architecture, an Authentication Gateway (AG) and an Internet Gateway (IG). These gateways could be collocated in the same device. For the sake of clarity, these two gateways are treated separately in the thesis. Both gateways are reached 24  through the BS by MSs that are single-hop and multi-hops away. The WAAA in the WLAN and the ASN-GW in the WiMAX could play the role of the AG. In the MII architecture, the AG relays authentication queries between the MS and its Home Authentication Server (HAS) located in its home network. In the heterogeneous wireless network, the role of the HAS could be played by the HAAA located in the 3GHN. A new visiting MS acquires a CoA from the IG, also known as the Foreign Agent (FA) in Mobile IPv4 terminology. The MS registers this new address with the Home Agent (HA) located in its home network.  Figure 2.5 MANET-Internet interworking architecture (MII)  2.3 Threat model Authentication solutions for the heterogeneous wireless network must encompass enough strength to resist attacks against individual networks and the interworking architecture. The interworking architecture is subject to attacks originated from nodes in the core network and from adversaries in the wireless access network. Several security threats can cause damage to the heterogeneous wireless network. These security threats lead to service interruption when the availability of the service is being attacked, message interception when the confidentiality is being attacked, message modification when the integrity is being attacked and message fabrication when authentication is being attacked. 25  Authentication protocols proposed in this thesis are designed to defend against similar types of attacks that could affect 3GPP-AKA, EAP-AKA and INEA. Only attacks launched by adversaries in the wireless access network and targeting link layer authentication are considered. Attacks originated from the wired network and attacks targeting physical layer, IP layer, transport layer and application layer security are not considered. Adversaries are assumed to have access to necessary equipments to mount passive and active attacks. These attacks aim to circumvent the authentication procedure by trying to uncover security keys and attempting to intercept, modify and replay messages exchanged between users and the wireless attachment point. Examples of these attacks include impersonation attacks where an adversary tries to impersonate a legitimate user, Man-In-The-Middle (MITM) attacks where an adversary intercepts the communications between two legitimate parties believing that they are communicating in a secure channel, and rouge AP/BS attacks where an adversary sets up a bogus AP/BS to attract victim users. In addition, privacy-related attacks based on overhearing users’ identities and tracking their movements are also considered. To defend against these attacks, the protocols proposed in this thesis preserve similar security requirements as 3GPP-AKA, EAP-AKA and INEA. These security requirements are as follows: •  Mutual Authentication: A MS must engage in mutual authentication procedure with the target network or a node fully trusted by it to defend against impersonation attacks, MITM attacks and rouge AP/BS attacks.  •  Forward and backward secrecy: MS and BS/AP communicating in session n must share a unique key (Kn) that is valid only in session n. Kn must not be capable of decrypting communications between MS and target BS/AP in session n + 1 (forward secrecy) after a HO is performed. Additionally, Kn must not be capable of decrypting communications between MS and previously visited BS/AP in session n – 1 (backward secrecy). Failure to 26  preserve forward and backward secrecy may result in the domino effect [60] problem in key management schemes where a compromise of a key enables an adversary to decrypt information exchanged anywhere and anytime in the network. •  Key scope and distribution: A key’s scope must be well defined between entities using it. Keying materials used in key derivation must be unique and binding to the nodes intended to use the key. Additionally, keys and keying materials must be only distributed to parties intended to use the keys in the current session. Thus, unnecessary distribution of keys and keying materials must be prevented. This is also known as the “principle of least privilege” [60]. Failure to do so may result in the domino effect problem in which a compromise of a network entity results in revealing keys or keying material that could be used to generate keys to compromise other network entities.  •  Key freshness: Newly derived keys must be freshly generated. Keying materials used in the key derivation must contain a continuously changing parameter like a nonce or a counter to ensure the freshness of the derived key. This requirement is essential in preventing replay attacks.  •  Privacy protection: It is desirable to hide the identity of the MS to limit privacy-based attacks and to conceal users’ movement when roaming. According to 3GPP and the WiMAX Forum [10], [15], [19], [34], the 3GHN establishes  a trust agreement with WAAA and AP in the 3GPP-WLAN interworking architecture. In addition, the 3GHN establishes a trust agreement with PAAA, ASN-GW and BS in the 3GPPWiMAX interworking architecture. This trust agreement permits the transport of security keys from the 3GHN to intermediate AAA servers such as WAAA, PAAA and ASN-GW to eventually reach the BS/AP. When a successful invocation of 3GPP-AKA, EAP-AKA and INEA takes place between a user holding a MS with USIM capabilities and the 3GHN, the user and the  27  3GHN mutually believe that they are communicating with a legitimate party. Hence, the user trusts the AP/BS it is communicating with as well as all intermediate AAA servers. When designing our proposed protocols, we assume a similar trust assumptions assumed by 3GPP and the WiMAX Forum. However, we assume that the user holding a MS with USIM capabilities partially trusts AP/BS. The proposed protocols are designed to limit the propagation of security damage to APs/BSs neighboring a compromised AP/BS. Additionally, we assume that target access networks in the heterogeneous wireless network such as WLAN and WiMAX cannot trust each other because they could belong to different service providers and adhere to distinctive security policies. Therefore, the assumption that target networks could share security keys or exchange users’ security information is impractical in the context of the heterogeneous wireless networks.  2.4 Standard authentication protocols 3GPP subscribers roaming in the heterogeneous wireless network have a USIM/UICC issued by the 3GPP service provider that contains unique security credentials. 3GPP Subscribers must be authenticated by the HAAA and the HSS when roaming in the heterogeneous wireless network. Hence, authentication protocols should be based on 3GPP-AKA.  2.4.1 3GPP-AKA The objective of 3GPP-AKA is to mutually authenticate MS and HSS by proving the possession of a shared secret key (K) and a correct sequence numbers (SQN). In addition, 3GPPAKA generates and distributes fresh encryption and integrity keys to secure the link between MS and SN, i.e., SGSN and VLR. To achieve these objectives, 3GPP-AKA undertakes two phases: firstly, distribution of authentication data from HSS to SN, and secondly, authentication and key agreement between SN and MS. Figure 2.6 depicts the operation of 3GPP-AKA.  28  Figure 2.6 3GPP-AKA protocol  Phase One: Distribution of authentication data from HSS to SN. HSS forwards an Authentication Vector (AV) to SN in this phase. Initially, MS issues a registration request message to SN, which contains its identity (MS-ID), which is based on the International Mobile Subscriber Identity (IMSI). SN forwards the request to HSS, which retrieves a pre-shared 128bits master key (K) with the USIM/UICC held by MS. Subsequently, HSS generates a fresh sequence number (SQN) and an unpredictable random number (RAND). K, SQN, RAND and other credentials are generated as follows. RAND = f0K(internal state) MAC = f1K(SQNHSS | RAND | AMF) XRES = f2K(RAND) CK = f3K(RAND)  (2.1)  IK = f4K(RAND) AK = f5K(RAND) AUTN = SQNHSS ⊕ AK | AMF | MAC AV = RAND | XRES | CK | IK | AUTN  29  where, f0K is a function used to generate random variables and it is implemented in HSS only. f1K and f2K are message authentication functions. f3K, f4K, and f5K are key generation functions. AMF is an authentication and key management field. MAC is the message authentication code. XRES is the expected response from MS. Only MS holding the correct master key (K) can generate a response identical to XRES. CK and IK are 128-bits cipher and integrity keys. “ ⊕ ” denotes bitwise exclusive-OR operation and “ | ” denotes concatenation operation. SQN represents sequence numbers generated by counters maintained by HSS (SQNHSS) and MS (SQNMS). Sequence numbers are used to protect against replay attacks. AV is the authentication vector generated by HSS and sent to SN. AV includes RAND, XRES, CK, IK and an authentication token (AUTN). AUTN is used by MS to derive SQNHSS and compute XMAC. Phase Two: authentication and key agreement between SN and MS. The aim of this phase is to mutually authenticate MS and HSS. In addition, this phase distributes fresh cipher and integrity keys between MS and SN. Phase two of 3GPP-AKA protocol proceeds as follows: 1- SN sends RAND and AUTN in a user authentication request message to MS. 2- Upon receiving the request, MS has enough information and key generation functions to calculate the codes necessary to prove its possession of K and compute a fresh CK and IK. Initially, MS calculates AK as shown in (2.1) and extracts SQNHSS from AUTN. It then calculates XMAC. XMAC = f1K(SQNHSS | RAND | AMF). Next, MS compares XMAC with the MAC received in AUTN. 3- If XMAC is not identical to MAC, this implies that MS and HSS do not share the same K. MS notifies SN of the problem by sending a user authentication reject message. Otherwise, 3GPP-AKA protocol proceeds normally. 4- MS verifies that SQNHSS is in the expected range, i.e., SQNHSS > SQNMS, which proves the freshness of AV and protects against replay attacks. If SQNHSS is not in the expected range, MS notifies HSS by sending a synchronization failure message. If SQNHSS value is 30  acceptable, MS calculates RES. RES = f2K(RAND). MS sends RES to SN and calculates CK and IK as shown in (2.1). 5- SN verifies that RES is identical to XRES to prove MS’s authenticity. By the successful completion of both 3GPP-AKA phases, mutual authentication between MS and HSS is established. Furthermore, a fresh pair of cipher and integrity keys is generated and shared between MS and SN to secure the channel between them.  2.4.2 EAP-AKA EAP supports end-to-end mutual authentication between an EAP client and an EAP server. Typically, the EAP client is a node requesting authentication such as the MS while the EAP server is a node that decides whether to grant or deny permission to the EAP client such as an authentication server. EAP session establishment and the transport of authentication information are based on four EAP messages exchanged between EAP client and EAP server. They are: EAP Request, EAP Response, EAP Success and EAP Failure. EAP Request, EAP Success and EAP Failure are sent by EAP server while EAP Response is sent by EAP client. Multiple EAP request/response messages are exchanged between EAP client and EAP server during the course of an EAP session to achieve mutual authentication. When authentication procedure completes, EAP server either sends EAP Success, to indicate a successful authentication, or EAP Failure, to indicate a failed authentication. The authentication type depends on the EAP authentication method supported by EAP client and EAP server. EAP supports a wide range of authentication mechanisms like usernames/passwords, smart cards, digital certificates and others. Consequently, different EAP methods are used to reflect different authentication mechanism like EAP-Transport Layer Security (EAP-TLS) [30], EAP-Tunneled TLS [31], Protected EAP (PEAP) [32] and EAP-AKA [8].  31  EAP-AKA is based on 3GPP-AKA and holds similar objectives, namely, attaining mutual authentication between EAP client and EAP server and establishing a secure key management scheme. Figure 2.7 pictures the operation of EAP-AKA. The EAP server must be capable of performing 3GPP-AKA to execute EAP-AKA. EAP-AKA proceeds as follows: 1- Initially, EAP server requests the identity of the EAP client in an EAP Request/Identity message. EAP client includes its identity in an EAP Response/Identity message. 2- Upon receiving the client’s identity, EAP server runs 3GPP-AKA and derives RAND, AUTN, MAC, CK and IK as shown in (2.1). Additionally, EAP server derives a new master key (MKAKA) as follows: MKAKA = SHA1 (IK | CK | Identity)  (2.2)  where SHA-1 is the secure hash algorithm [33]. MKAKA is inserted into a pseudo random function to produce the Master Session Key (MSK), the Extended Master Session Key (EMSK) and the Transient EAP Key (TEK). Two keys are derived from TEK and used to preserve the confidentiality and integrity of EAP-AKA messages, they are: K-encr and Kauth. EAP server appends RAND, AUTN and MAC calculated using K-auth to the EAP Request/AKA-challenge message. 3- Upon receiving the challenge, EAP client runs 3GPP-AKA and verifies the received AUTN as explained in Section 2.4.1. If the verification is successful, EAP client derives MKAKA using (2.2) as well as MSK, EMSK and TEK. EAP client deduces K-encr and K-auth from TEK and subsequently verifies the correctness of the MAC covering the received EAP message. If all verifications are successful, EAP client believes that EAP server is legitimate and calculates a RES similar to the way it is calculated in Section 2.4.1. Finally, EAP client sends an EAP Response/AKA-challenge message which contains RES and a new MAC value covering the EAP response message.  32  4- EAP server verifies the received MAC and matches RES to XRES included in AV. If all checks are successful, EAP server sends EAP Success message to EAP client to indicate that mutual authentication was successfully achieved.  Figure 2.7 Standard EAP-AKA authentication  The authentication and key agreement procedure is terminated in case of failure to verify authentication information in any of the steps above. Re-authentication takes place sometime after a previous successful authentication. Re-authentication can be instigated due to the expiration of a timer shared between different nodes involved in authentication. Moreover, reauthentication can be triggered by an expired key or a HO operation. The designers of EAPAKA defined two types of re-authentication, they are: full EAP-AKA re-authentication and fast EAP-AKA re-authentication. Full EAP-AKA re-authentication is similar to EAP-AKA protocol depicted in Figure 2.7. Fast EAP-AKA re-authentication is an optional, lightweight version of full EAP-AKA reauthentication. Fast EAP-AKA re-authentication reuses MKAKA derived in the preceding EAPAKA to derive a new MSK, EMSK and TEK without executing the 3GPP-AKA protocol. The immediate advantage of invoking fast EAP-AKA re-authentication is the reduced processing 33  overhead experienced by both EAP client and server due to avoiding the execution of 3GPPAKA. 2.4.2.1 EAP-AKA in 3GPP-WLAN 3GPP recommends invoking EAP-AKA to authenticate users accessing the 3GPPWLAN interworking architecture [34]. MS plays the role of EAP client while the role of EAP server is played by HAAA. WAAA relays EAP traffic between MS and HAAA. In the wired network, EAP messages are encapsulated in AAA protocols like Radius or Diameter. In the wireless network, EAP messages are encapsulated in EAP over LAN (EAPoL) [35] frames. Figure 2.8 depicts the full EAP-AKA authentication operation in the 3GPP-WLAN interworking architecture. The protocol proceeds as follows: 1- Initially, MS connects and associates with WLAN AP, and receives EAP Request/Identity message. 2- MS responds with EAP Response/Identity, which includes its identifier in the Network Address Identifier (NAI) format, the identifier is derived from IMSI. 3- AP routes EAP Response/Identity message to HAAA through WAAA. HAAA communicates with HSS to retrieve a new AV. HAAA derives MKAKA using (2.2) as well as MSK, EMSK and TEK. MSK is used to secure the communications between AP and MS. EMSK is derived but its usage in EAP-AKA is not specified [8]. Depending on the policy implemented by the 3GPP service provider, HAAA have the option to generate two temporary identities, pseudonym and re-authentication identities. Pseudonym identity is generated if the policy supports subscriber’s privacy protection and re-authentication identity is generated if the policy supports fast re-authentication procedures. 4- HAAA sends EAP Request/AKA-challenge message containing RAND, AUTN and MAC to AP. The message can include the generated identities encrypted with K-encr. 34  5- AP forwards EAP Request/AKA-challenge message to MS.  Figure 2.8 EAP-AKA authentication protocol in the 3GPP-WLAN interworking architecture  6- MS runs 3GPP-AKA and verifies the correctness of the received AUTN. Next, it calculates RES, IK and CK using (2.1) and computes MKAKA, MSK, EMSK and TEK. The MS also stores the pseudonym and re-authentication identities, if included in the message, for future reauthentication procedures. Finally, the MS sends an EAP Response/AKA-challenge message which contains RES and a new MAC value covering the EAP response message. 7- AP forwards EAP Response/AKA-challenge message to HAAA. 8- HAAA verifies the received MAC and matches RES to XRES included in AV received from HSS. 9- If all checks are successful, the HAAA sends EAP Success message and MSK to AP. The first 32 Bytes of the MSK can be used as the Pairwise Master Key (PMK), which is later fed into the 4-way handshake procedure described in IEEE 802.11i to derive the Transient Session Key (TSK) [36]. TSK is used to derive keys to secure the communications between MS and AP. 10- Finally, the AP forwards the EAP Success message to MS.  35  Re-authentication takes place when MSK expires, when the timer shared between MS and AP expires or when the MS switches to another AP. As discussed earlier, EAP-AKA standard supports a fast re-authentication protocol, namely, fast EAP-AKA re-authentication. This reauthentication protocol bypasses the need to invoke 3GPP-AKA by both HSS and MS. Therefore, it reduces re-authentication delays when compared to invoking full EAP-AKA reauthentication. After a successful authentication, HAAA supporting fast re-authentication generates a temporary fast re-authentication identity as discussed earlier and forwards it to MS. The next time MS wants to launch a fast EAP-AKA re-authentication, it sends its fast reauthentication identity back to HAAA.  Figure 2.9 Fast EAP-AKA re-authentication protocol in the 3GPP-WLAN interworking architecture  In fast EAP-AKA re-authentication, new MSK and EMSK are derived from the previously derived MKAKA. MS and HAAA utilize K-auth and K-encr derived in the previous EAP-AKA authentication to protect and authenticate EAP messages. Upon successful completion of fast EAP-AKA re-authentication, HAAA forwards the new MSK to AP. MS and AP use this key to derive a new PMK and seed it into the 4-way handshake protocol to derive keys to secure the radio link between them. It was experimentally demonstrated that fast EAP36  AKA re-authentications reduce authentication delays by 46% compared to full EAP-AKA reauthentication [37]. Figure 2.9 depicts the operation of fast EAP-AKA re-authentication in the 3GPP-WLAN interworking architecture. 2.4.2.2 EAP-AKA in 3GPP-WiMAX The WiMAX Forum specified invoking INEA to authenticate MSs in the 3GPP-WiMAX interworking architecture [10], [15]. INEA invocation includes the execution of EAP-AKA protocol. Similarly to the 3GPP-WLAN interworking architecture, MS plays the role of EAP client while the role of EAP server is played by HAAA in 3GPP-WiMAX. PAAA and ASN-GW relay EAP traffic between MS and HAAA. In INEA, MS and BS negotiate the security protocols to be used by exchanging Security Basic Capability messages (SBC) as shown in Figure 2.10. BS consults with ASN-GW on security capabilities using MS_PreAttachment messages. Consequently, MS executes EAP-AKA authentication protocol with HSS/HAAA.  Figure 2.10 The initial network entry authentication in the 3GPP-WiMAX interworking architecture  EAP messages exchanged between MS and BS are encapsulated in PKMv2 messages while EAP messages exchanged between ASN-GW, PAAA and HAAA are carried by AAA protocols like Radius and Diameter. When INEA completes successfully, HAAA and MS 37  derives MSK, HAAA forwards this key to ASN-GW. MS and ASN-GW derive a Pairwise Master Key (PMK) and an Authorization Key (AK) from MSK as follows. PMK = Truncate(MSK, 160)  (2.3)  AK = Dot16KDF(PMK, BS-ID| MSM |“AK”,160)  (2.4)  where Dot16KDF is a key derivation algorithm specified in [5]. BS-ID is the identity of the BS, MSM is the MS address in the medium access control layer. AK is used to derive downlink and uplink CMAC_KEYs in addition to a Key Encryption Key (KEK). CMAC_KEYs are used to calculate Cipher-based Message Authentication Code (CMAC) to protect the integrity of messages exchanged between MS and BS. MS and BS validate the freshness of the shared AK by executing the 3-way handshake protocol (3WHS) [5], [15]. Finally the BS sends Traffic Encryption Keys (TEK) to MS in Key-Request/Reply messages. TEK is used to encrypt the traffic exchanged between MS and BS. These keys are encrypted during transmission with the KEK. Figure 2.11 depicts the key hierarchy of the EAP-AKA protocol when executed in the 3GPPWLAN and the 3GPP-WiMAX interworking architectures.  Figure 2.11 EAP-AKA key hierarchy in the 3GPP-WLAN and 3GPP-WiMAX interworking architectures  2.4.2.3 Drawbacks of EAP-AKA and 3GPP-AKA EAP-AKA suffers several drawbacks, most of which are inherited from 3GPP-AKA. A major drawback is the execution of multiple rounds of authentication challenges and replies between MS and the authentication servers in the 3GHN. The 3GHN might be far away or 38  separated by several networks from the MS. This leads to potentially high authentication delay and high cost of authentication signaling [24], [38], [39], [110]. Delay-sensitive applications running on MS might not tolerate such delays. In addition, MS and HSS require the execution of 3GPP-AKA during EAP-AKA, which accounts for much of its delay [37]. Authenticating a huge number of MSs simultaneously might overload the HSS. Fast EAP-AKA re-authentication can be used to avoid running 3GPP-AKA; however, its execution is optional and has to be activated by the 3GHN. The standard EAP-AKA protocol does not provide support for fast re-authentication or pre-authentication during a HO. In the heterogeneous wireless network, MS might perform multiple HO operations within a wireless technology or between different technologies. The full EAP-AKA authentication protocol must be executed on every HO procedure. This procedure is highly inefficient. It leads to high HO delays and increase the HO signaling required in completing the HO operation. Additionally, a MS that moves quickly between wireless networks requires frequent execution of 3GPP-AKA by the USIM/UICC. Given that the MS is a resourceconstraint node, the repetitive execution of 3GPP-AKA along with high HO delay might affect the QoS of real-time applications running on the MS during a HO. EAP-AKA is subject to privacy-related attacks due to the disclosure of MS-ID during authentication. MS-ID is based on IMSI, which includes information about MS and 3GHN. Eavesdropping MS-ID might assist attackers in tracking MS’s movements. In EAP-AKA, the 3GHN could generate two temporary identities to avoid using MS-ID on every re-authentication: the pseudonym ID and the re-authentication ID. The pseudonym ID is used in subsequent full EAP-AKA re-authentications and the re-authentication ID is used in subsequent fast EAP-AKA re-authentication executions. Use of these temporary identities is optional and subject to 3GPP service provider’s approval. Even if the option is enabled by the service provider, handling three  39  identities per MS escalates the complexity of the authentication protocol and adds extra overhead to the HAAA.  2.5 Overview of related work In this Section, an extensive list of contributions that appeared in the literature related to providing efficient authentication in 3GPP-WLAN, 3GPP-WiMAX and heterogeneous wireless network are presented. In addition, work related to securing the MII architecture is discussed.  2.5.1 Re-authentication in 3GPP-WLAN To address the problem of high (re-)authentication delays in the 3GPP-WLAN interworking architecture, Kambourakis et al. [38], Prasithsangaree et al. [39], and Chen et al. [40] proposed using EAP-TLS, EAP-TTLS and PEAP protocols, respectively, instead of EAPAKA. These solutions are capable of minimizing (re-)authentication delays because there is no need to retrieve a new AV from HSS due to the ability to complete (re-)authentication in the WLAN. Furthermore, these solutions provide reasonable identity protection mechanisms. The problem with these protocols is that they require modifications to the 3GPP-WLAN interworking architecture and they introduce asymmetric key operations and necessitate the handling of Digital Certificates (DCs). Such operations might not be appropriate for users with resourcelimited equipments like cell phones and personal digital assistants because they demand high computation capabilities and consumes more power compared to symmetric key based solutions. Salgarelli et al. [41] proposed an EAP-Shared Key Exchange (EAP-SKE) authentication and key exchange protocol to authenticate wireless users. The protocol outperforms the full EAP-AKA protocol because it only requires one round of message exchange between the visited AAA server and HAAA during re-authentication. However, it does not provide privacy protections. Solutions presented in [38] to [41] aim at minimizing (re-)authentication delays by introducing EAP-based authentication protocols other than EAP-AKA. However, since the 40  3GPP has recommended and adopted EAP-AKA as the standard authentication protocol for the 3GPP-WLAN interworking architecture, adopting non-standardized solutions might raise interoperability issues. Braun et al. [42] proposed retrieving security context information like AV from the previously visited Security Context Controller (SCC) instead of requesting them from the home network. An SCC periodically broadcasts information about the authenticated user within its perimeter to neighbor SCCs. As a result, the newly visited SCC could quickly locate the previously visited SCC and retrieve the security context directly without contacting the home network. Message broadcasting and SCC searching techniques are borrowed from peer-to-peer network searching and broadcasting mechanisms. The protocol performs well as long as the previously visited SCC holds valid security context and the home network is far away from the newly visited SCC. Practically, implementation of the protocol is questionable because a considerable amount of cooperation between the visited networks has to be established to allow the exchange of security context between them. Moreover, as a consequence of broadcasting user’s security context information, privacy-related attacks might occur.  2.5.2 Horizontal handover authentication in 3GPP-WLAN Generally, HO delay caused by roaming between and within WLANs is composed of AP scanning delays [44], authentication delays and MIP registration delays in the case of IP-layer HO. Research to reduce authentication delay during WLAN HHOs in the context of 3GPPWLAN interworking architecture is in its initial stages. EAP-AKA protocol is not designed to effeciently handle authentications instigated by HO operations. Thus, invoking EAP-AKA whenever HHOs takes place is highly inefficient. Many research studies focused on WLAN HHOs in autonomous WLAN architectures. In terms of network architecture, a major difference between authenticating a roaming MS in autonomous WLAN architectures in contrast to the 3GPP-WLAN interworking architecture is 41  that authentication servers reside in the WLAN network in the former case and they reside in the 3GHN in the latter case. Another difference is that IEEE recommends invoking EAP-TLS protocols in autonomous WLANs, while the 3GPP recommends invoking EAP-AKA authentication protocols in the 3GPP-WLAN interworking architecture. Therefore, existing HHO authentication protocols designed specifically for autonomous WLANs architecture are not directly applicable over the 3GPP-WLAN interworking architecture. Besides, several HHO authentication protocols proposed for WLANs attain reduction in authentication delay at the cost of operational problems like introducing extra signaling overhead in the WLAN network or demonstrating high dependency on MS mobility patterns. The rudimentary HO and security support in the base IEEE 802.11 protocol has been enhanced in IEEE 802.11i, IEEE 802.11f [45] and IEEE 802.11r [46]. HO protocols in IEEE 802.11i are optional and have seen limited implementation and deployment support [47]. HO protocols in IEEE 802.11f are not suitable for 3GPP-WLAN interworking environments because strong trust agreements are required between WLAN administration domains to secure interExtended Service Set (inter-ESS) HHO across these WLAN domains. On the other hand, IEEE 802.11r supports only intra-ESS HHO within specific WLAN domain but not inter-ESS HHO. Many papers in the literature proposed mechanisms to reduce intra or inter-ESS HHO delays in autonomous WLAN architectures. Some papers achieved this goal by preauthenticating the MS before HO, pre-distributing security keys, predicting MS’s next move, introducing asymmetric key cryptography or adopting hybrid techniques combining more than one method. Mishra et al. [48], Kassab et al. [49] and Hur et al. [50] proposed proactive key distribution using neighbor graphs to predict potential Target APs (TAPs). These schemes utilize EAP-TLS and may result in unnecessary distribution of keys and increase signaling overhead in the WLAN as the number of MSs increases. Pack et al. [51] and Mukherjee et al. [52] proposed mechanisms to predict MS’s mobility and hence pre-authenticating the MS with the TAP before 42  HO. The protocols share similar drawbacks as in [48], [49] and [50], and their operations are restricted to intra-ESS HHO. In the context of 3GPP-WLAN interworking architecture, the MS roams between WLANs belonging to different administration and security domains, this implies that protocols designed to work in autonomous WLAN architectures like in [48], [49], [50], [51], and [52] cannot be simply migrated to operate in the 3GPP-WLAN interworking architecture. Techniques to reduce delays in the event of WLAN HHO in the 3GPP-WLAN interworking architecture have been proposed in [43] and [53]. Lee et al. [43] suggested adding a location-aware service platform to the 3GPP-WLAN interworking architecture to predict MS’s movement and perform fast authentication during HO. This scheme aims at offloading HAAA from handling authentication whenever the MS moves, thus reducing authentication and HO delays. The drawback of this approach is that it requires major modifications to the existing 3GPP-WLAN interworking architecture. Long et al. [53] proposed a fast MS authentication protocol to be executed during inter-ESS HHO. The architecture addressed by Long et al. is similar in concept to the 3GPP-WLAN interworking architecture. The proposed mechanism requires MS authentication by its home network while roaming. Fast inter-ESS HHO is achieved by means of asymmetric key cryptography and by modifying the Secure Socket Layer authentication protocols.  2.5.3 Secure and efficient horizontal handovers in 3GPP-WiMAX IEEE 802.16e [5] and WiMAX Forum specifications [15] introduced mandatory and optional HHO types. Hard HO is a mandatory HO type that has to be supported by all nodes in the WiMAX network. Macro Diversity set HO (MDHO) and Fast Base Station Switching (FBSS) are optional HO types. In the hard HO, MS breaks communications with Serving BS (SBS) before establishing communications with Target BS (TBS). In MDHO and FBSS, MS registers and maintains a list of potential TBSs and is required to share its security context with 43  them. This results in an improved performance but compromises important HO security requirements. Moreover, MDHO and FBSS introduce additional traffic in the network and require more complex hardware [55], [56] and [57]. The standard hard HO protocol specified in [5] and [15] achieves important HO security goals but performs poorly due to the invocation of EAP-AKA after a HO. This authentication activity introduces significant delays and additional signaling cost to the network; which demonstrates inefficiency in network resource management [55], [58] and [59]. Optional, performance improved hard HO protocols are also offered in [5] and [15]. These protocols improve HO performance and reduce HO delay by omitting the execution of EAP-AKA after a HO. Omitting EAP-AKA improves performance significantly due to eliminating the need to contact the 3GHN after a HO. Nonetheless, this omission leads to two critical security flaws: firstly, the absence of a fresh round of mutual authentication after a HO, and secondly, the introduction of security key related problems due to the adoption of a weak key management scheme. Several papers in the literature proposed enhancements to reduce HO delays. In [62], the authors proposed enhancing the link-layer HO to allow receiving downlink services from the TBS during a HO. In [63], the authors proposed cutting on redundant TBS scanning delay. Yeh et al. [132] proposed a fast intra-CSN and cross-layer HO protocol especially designed for realtime services in frequent HO environments. The proposed protocol improves HOs in the IP-layer and the link-layer. Similar to Yeh’s approach, Chang et al. [65] presented a fast HO procedure that combines the link-layer HO with fast Mobile IP HO procedures. Authentication operation during HO plays a major role in shaping the performance of the HO operation [55], [59]. Solutions to improve WiMAX HO performance by enhancing the authentication operation during a HO were designed for autonomous WiMAX networks only. Hur et al. [55] proposed pre-authentication protocols based on pre-distributing PMK and AK 44  keys to TBSs prior to a HO. The proposed scheme generate additional communication and computation overhead, a consequence of computing and distributing keys to TBSs. Sun et al. [64] introduced pre-authentication protocols based on asymmetric key operations and EAP-TLS to speed authentication during HOs. Hsu and Lin [133] proposed reusing the MSK cached in the ASN-GW to speed the HO process when MS revisits the ASN-GW in the future before MSK lifetime expires. This approach can significantly improve performance. However, reusing MSK implies the absence of a fresh round of mutual authentication between MS and the target network. Additionally, MSK reuse leads to the possibility of deriving duplicate AKs by MS and ASN-GW in different HO sessions, which is insecure.  2.5.4 Efficient vertical handover authentications in the heterogeneous wireless network HHOs are typically performed based on signal strength where the MS seeks a stronger signal when the current signal weakens. Unlink HHOs; VHOs are performed based on predefined user preferences like services type and service cost as well as network availability. Intelligent decision mechanisms have been proposed in the literature to wisely select the best target network [69], [70], [71], [135]. However, VHO decision algorithms are out of the scope of our work. In this section, we present the work done on enhancing the VHO signaling procedure in general and those focusing on improving the authentication procedure during VHOs as a mean to improve the VHO signaling procedure in specific. Yahiya et al. [66] performed some studies and presented results on VHO procedures between WLAN and WiMAX networks interconnected in a loosely coupled interworking environment. Chen et al. [67] proposed the addition of a Vertical Handoff Translation Center to the interworking architecture to improve the QoS of transmitted information during VHO and to efficiently utilize available bandwidth. The authors in [68] proposed a tightly coupled  45  interworking between WiMAX and WLAN that takes advantage of the surplus WLAN capacity available in residential areas. Designing secured and efficient VHO procedures between WiMAX and WLAN networks is challenging. Work in this area is minimal. Based on 3GPP and WiMAX Forum specifications, a MS holding 3GPP credentials have to invoke the standard re-authentication protocols with the target network after a VHO [10], [19]. In the case of WiMAX to WLAN VHO, MS invokes EAP-AKA. In the case of WLAN to WiMAX VHO, MS performs INEA. Invoking EAP-AKA during VHOs between WiMAX and WLAN might introduce unnecessary traffic to and from the 3GHN and could result in increased VHO delay. Eastwood et al. [72] and Yan et al. [73] proposed utilizing Media Independent Handover (MIH) services found in IEEE 802.21 to improve HO decision and execution between different wireless technologies. The authors proposed techniques that take advantage of MIH services to acquire information about the target network and perform authentication before performing VHO to reduce delay. However, adopting MIH services introduces additional cost and complexity to the network [74]. Re-authentications instigated by a VHO procedure are generally an impediment towards achieving a fast VHO between WLANs and WiMAX networks in the heterogeneous wireless network [73]. Sun et al. [75], addressed this issue and attempted to improve re-authentications instigated by VHOs by transferring MSK from the serving network to the target network using MIH services. Thus, when a VHO is performed, the MS derives lower level keys without executing the time-consuming EAP-AKA protocol. Although this approach aids in reducing reauthentication delay and signaling during VHO, transferring MSK is a security hazard and resembles a weak key management strategy. This leads to domino effect problems [60] and might lead to false base station attacks [61]. Domino effect, in key management schemes, is the  46  situation where compromising a node in one branch of the key hierarchy results in compromising nodes in other peer branches [60]. In [75], an adversary revealing the MSK might constitute a threat to all possible recipients. The adversary might launch a false base station attack by establishing a communication link with legitimate users. Gondi et al. [76] introduced a “Roaming Intermediator” (RI) to the interworking between WiMAX and WLAN that functions as a broker between the user’s home network and target networks. The RI handles user authentication with the target network on behalf of the home network to reduce VHO delays. Choi et al. [77] proposed a VHO scheme between 3GPP and WLAN based on preauthentication and pre-registration of MS’s CoA in the MIP protocol. Pre-authentication and preregistration take place before the link-layer HO which results in reduction in HO delay and minimized packet loss. APACHE (A ProACtive Handover Enhancing protocol) introduced by Leeuwen et al. [78] achieves fast HO and low packet loss by predicting the TAP the MS is most likely going to attach to. APACHE highly depends on MS’s location coordinates; this implies that the MS must be equipped with a location determining device like the Global Positioning System (GPS). MSs equipped with GPS devices are not common in the telecommunications market today considering the high price of GPS systems. Lim et al. [54] proposed a protocol to reduce probing/scanning delays of the target AP during 3GPP-WLAN VHOs, which reduces delay. The downside to this solution is that APs must perform some of the functionalities of the 3GPP base station and share some control channels with it. Other research attempts that focused on minimizing re-authentication delays during VHO are reported in [43], [79], [80], [81] and [134]. Lee’s solution [43] depends on the location-aware service platform to predict MS’s next move and pre-authenticate before VHO. This scheme aims at offloading HSS/HAAA from handling VHO re-authentication whenever the MS moves, thus reducing re-authentication delays. As mentioned earlier, the drawback of this proposal is that it 47  requires major modifications to the heterogeneous wireless network architecture. A general wireless authentication framework was proposed by Lim et al. [79]. The objective is to avoid the communications between MS and its home network during authentication. The serving network and the target network are to trust each other and share MS’s security information to speed the re-authentication procedure during VHO. When considering VHOs in the heterogeneous wireless network, establishing trust between serving and visiting networks beforehand is challenging. Additionally, the proposed framework only works if the current serving network is WLAN because it reuses some of the keys derived from the 4-way handshake protocol to prove the authenticity of the MS. Therefore, adopting this framework to the heterogeneous wireless network might be infeasible. Another proposal to reduce authentication delays during VHO was presented by Huang et al. [80]. The authors introduced a seamless authentication protocol that minimizes authentication delays during VHOs by sharing security keys between the serving and the target networks. These keys are used to provide temporary access to the target network after a VHO. The advantage here is that the MS can gain a temporarily admission to the target network without the need to contact its home network. The target network later verifies MS’s authenticity with its home network then decides whether to continue accepting the MS in its network. The disadvantage of this approach is that extensive key generation, distribution and sharing activity takes place between MS, serving and target networks which might compromise the security of the entire network. Kwon et al. [81] modified the 3GPP-AKA authentication protocol to support a fast reauthentication scheme that mimics the fast EAP-AKA re-authentication protocol. The proposed solution generates and verifies authentication parameters without executing f1 – f5 functions in HSS and USIM. This procedure might improve performance due to bypassing the generation of a new AV on every VHO to the 3GPP; however, the MS still requires communicating with the 48  HSS to complete the re-authentication. Additionally, the MS reuses the same CK and IK keys before and after a VHO to secure its communications with the SN, which is totally insecure. Rajavelsamy and Choi [134] presented a security framework that speeds VHOs in the heterogeneous wireless networks due to exchanging user’s security context information between the serving network and the target network during a VHO. This approach requires a strong trust agreement between the service network and the target network which might not exist when access networks are interworked in a loosely-coupled fashion and operated by competing companies.  2.5.5 Securing the MANET-Internet interworking architecture Classical MANET routing protocols like Ad Hoc On-Demand Distance Vector (AODV) [82], Dynamic Source Routing (DSR) [83] and Destination-Sequenced Distance Vector (DSDV) [84] were designed without security provisions. A number of security extensions were proposed to protect these routing protocols like Ariadne [85] and the Secure Routing Protocol (SRP) [86]. Nevertheless, these protocols are designed to operate in pure MANET environments only [87], [88]. Various MII architectures have been proposed in the literature. A detailed survey on these architectures is reported in [12] and [89]. The architectures differ based on the type of MANET routing protocol, node mobility protocol and FA discovery methods. Most of the architectures employ MIP for node mobility and adopts a reactive MANET routing protocols like AODV and DSR. Sun et al. [90] proposal was one of the first approaches to integrate MANET with MIP based on AODV routing. Several other approaches based on AODV and DSR were proposed too such as [91], [92] and [93]. These contributions are based on the assumption that MSs in the MANET fully trust each other and are faithfully willing to relay messages to one another without alteration [88], [89]. Such an assumption might be unrealistic because of the adversarial nature of MANETs. 49  MANETs are vulnerable to a wide variety of security risks and attacks [11]. Several attacks can be launched by a malicious MS including impersonation attacks, message modifications and replay attacks. MANETs in the MII architecture are prone to security problems and attacks not found in a pure MANET architecture. Examples of these problems include fake MIP registration requests, fake FA discovery attempts and attacks based on modifying and replaying MIP registration messages. Vaidya et al [87], Xie et al [88] and Kandikattu et al. [94] proposed secured MIP registration schemes based on asymmetric key operations to protect the MII architecture. Vaidya’s scheme [87] is based on the assumption that a centralized Certificate Authority (CA) is trusted by all MSs, FA and HA. A newly joined MS is assumed to receive a DC from the CA before it can start a secure MIP registration. The authors also claim that MS and HA share a secret key computed by HA and delivered to MS using a secret channel. Xie’s scheme [88] relies greatly on asymmetric key operations to complete single and multi-hop MIP registration and to provide sender authentication and message integrity. In Xie’s scheme [88], a newly joined MS requires performing single or multi-hop FA discovery to obtain a DC of the FA and it requires the completion of CoA registration to obtain a DC testifying its identity and public key information. Intermediate nodes residing on the multi-hop path between the visiting MS and FA perform repetitive digital signature/verification on transient messages in addition to DC validations to complete the MIP registration scheme. The scheme assumes that FA and HA have an access to the Public Key Infrastructure (PKI) to validate each other’s certificate. Additionally, the scheme demands that each MS shares a secret key with HA prior to MIP registration. Kandikattu’s scheme [94] uses minimal asymmetric key operations to achieve secure single and multi-hop MIP registration. In the case of multi-hop connectivity, intermediate nodes on the multi-hop path between visiting MS and FA utilize keyed hashing operations to preserve the integrity of transient messages and to ensure the authenticity of the sender. Similar to Xie’s 50  scheme, FA and HA must have access to the PKI to validate each other’s certificate. The schemes proposed in [87], [88] and [94] provides adequate defense against a variety of attacks affecting the MII architecture. However, the schemes encounter three practical obstacles: firstly, the need for a feasible DC management system in the MII architecture, secondly, the need for efficient key management and distribution scheme between the MS and the HA, and thirdly, the inefficiency of the registration scheme caused by asymmetric key operations and DC validation procedures. Managing DCs is complex and could cause delays in the MII architecture. A central authority trusted by all nodes must exist to generate DCs and to maintain a Certificate Revocation List (CRL). MSs might need to validate a chain of DCs before reaching a DC issued by a trusted CA. Additionally; MSs might need to consult the CRL in the CA to ensure that the received DC is not revoked. In [87] and [94], the method by which a newly joined MS contacts the CA to validate FA’s certificate is not clear. The CA could be located in another IP network, thus contacting the CA before acquiring Internet connectivity is ambiguous. This problem is less serious in Xie’s scheme since the role of the CA is played by the FA which is reachable without the need for Internet connection. DC management limits the flexibility to join the MII architecture because interested MSs have to obtain a DC from the CA before joining. In the MII architecture, MSs are assumed to roam freely and quickly between available access networks and the need to obtain and manage DCs while visiting foreign networks could be highly inconvenient. From the CA’s perspective, issuing and revoking DCs for every MS entering and leaving a network in the MII architecture could be difficult to manage. The schemes in [87], [88] and [94] assume that the visiting MS shares a key with HA prior to the MIP registration. Methods to generate and distribute the shared key are not discussed in [88] and [94]. With such setup, MS and HA are likely to share a key for a long time since no rekeying mechanisms are specified. A shared key with a long lifetime is more susceptible to key 51  disclosure attacks than a key with a short key lifetime. In [94], the authors assume that every node shares a pair-wise key with every other node in the MANET, implementing such an assumption is complex and challenging. Finally, performing asymmetric key operations like digital signatures/verifications and DC validations by MSs incur processing delays and additional power consumptions which are scarce resources in mobile devices.  2.6 Summary Despite its tremendous features, EAP-AKA inherits security and performance problems from the 3GPP-AKA protocol. Among these problems is the exchange of several rounds of authentication queries making it prone to high re-authentication delays and its inadequacy in performing fast authentications instigated by HOs, thus, resulting in high HO latencies. Researchers proposed a wide selection of techniques to minimize authentication and HO latency for stationary and mobile users roaming in the heterogeneous wireless network. However, it seems that with every proposed solution, a new problem is born. Some of the proposed solutions incline towards security but devalue the importance of performance. Some other solutions concentrate on performance and oversight critical security requirements. Lastly, some solutions appear to treat security and performance equally but are too complex to implement or hardly practical.  52  Chapter 3: Fast authentication in the 3GPP-WLAN interworking architecture∗ 3.1 Introduction Invoking EAP-AKA at the beginning of a communication session is inevitable. Reauthentication is instigated as a result of an expired timer, expired key or as a result of a HO. Since re-authentications regularly occur during an ongoing communication session, they have stricter delay requirements. While researchers have proposed several EAP-based solutions to address the (re-)authentication delay problem in EAP-AKA [38], [39], [40] and [41], we contend that room for improvements exists in the standard EAP-AKA protocol itself. Thus, we have enhanced EAP-AKA to distinctly minimize re-authentication delays. We propose invoking a localized authentication scheme to reduce re-authentication delays. In our proposed “WLAN Local Re-authentication” or WLLR protocol, the WAAA locally re-authenticates stationary users on behalf of HAAA and HSS [96], [97]. HAAA and HSS servers delegates MS authentication in 3GPP-WLAN interworking architecture to the WAAA located in the WLAN domain. Localized re-authentication is superior, in terms of authentication delays and authentication signaling, to the standard full and fast EAP-AKA re-authentication protocols. Differently from the protocols suggested in [38], [39], [40], [41] and [42], WLLR attains fast reauthentication and maintains a high state of security. WLLR enjoys distinguishable features compared to these protocols: firstly, it does not require the usage of asymmetric key operations, secondly, it does not introduce any modifications to the existing 3GPP-WLAN interworking  ∗  Parts of this Chapter have been presented in the 6th annual Wireless Telecommunication Symposium (WTS’07) [96] and the 4th International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness (Qshine 2007) [98]. In addition, parts of this Chapter have been published in Wiley Security and Communication Networks, vol. 1, no. 4, pp. 309-323, July/August 2008 [97] and EURASIP Journal on Wireless Communications and Networking, vol 2009, Article ID 806563, PP. 116, 2009 [99].  53  architecture, and thirdly, it abides by 3GPP specifications by adopting EAP-AKA protocol but with minor modifications. In the 3GPP-WLAN interworking architecture, authentication delay largely contributes to the overall HO delay because the MS needs to communicate with HAAA and HSS residing in the 3GHN to successfully complete the authentication procedure. Invoking EAP-AKA whenever the MS performs WLAN HHOs in the 3GPP-WLAN interworking architecture is unfavorable. Instead of executing the authentication procedure after performing HO, we propose executing a pre-authentication procedure between the MS and the target network prior to a HO. Intra and Inter WLAN Fast Pre-authentication protocols (Intra/Inter-WLAN FP) achieves MS pre-authentication with the target network before a HO is performed, which results in reductions in the HO delay [98], [99]. In comparison to protocols in [43], [48], [49], [50], [51], [52] and [53], our proposed protocols enjoy unique characteristics which make them first of their kind. Firstly, they are designed to operate in the 3GPP-specified 3GPP-WLAN interworking architecture and adopt a variation of EAP-AKA according to 3GPP recommendations unlike [48], [49] and [50]. Secondly, they are independent of MS movement patterns or future movement predictions contrasting protocols in [43], [51] and [52]. Thirdly, they do not rely on asymmetric key operations like the protocols in [48], [49], [50], and [53], which might require substantial processing resources that may not be available in the MS. Fourthly, they do not require major modifications or the introduction of new servers in the 3GPP-WLAN interworking architecture as the case in [43]. Finally they avoid unnecessary generation and pre-distribution of keys to the target network and are therefore more efficient and secure. The remainder of this chapter is organized as follows. In Section 3.2, we outline the assumptions on which we based our proposed protocols. In Section 3.3, we introduce some modifications to the standard EAP-AKA protocol. Our proposed protocols are described in  54  Section 3.4. Sections 3.5 and 3.6 evaluate the performance and analyze the security of our proposed protocols, respectively. Section 3.7 summarizes the chapter.  3.2 Assumptions This section outlines general assumptions on which the proposed protocols are based. The first two assumptions are similar to those of the standard EAP-AKA protocol. •  A WAAA server exists in every WLAN. WAAA controls multiple APs forming a “WLAN domain”. The WAAA and all APs in its domain must share a Long Term Security Association (LTSA).  •  WAAAs belonging to different WLAN domains must have LTSA and roaming agreements with the HAAA.  •  WAAA and MS maintain a local re-authentication counter (CWR) and a HHO counter (CHHO). The initial counter values are pre-agreed upon between them. CWR keeps track of the number of performed local re-authentications using WLLR protocol and it is continuously incremented after performing the modified EAP-AKA and WLLR protocols. CHHO keeps track of the number of performed pre-authentications during HHOs and it is continuously incremented after performing Intra/Inter-WLAN FP. The maximum values these counters could reach are determined by nWR and nHHO parameters derived by the HAAA.  3.3 Modifications to EAP-AKA (mod-EAP-AKA) In EAP-AKA, MS and HAAA must generate MSK, EMSK and TEK keys. TEK is used to derive K-auth and K-encr keys responsible for preserving the integrity and confidentiality of EAP messages during authentication. MSK is transported to the AP to be used in generating a TSK, and EMSK is not used. We propose extending the key hierarchy by deriving additional keys from MSK and EMSK to enable fast local re-authentication and fast HHO pre-authentication. MSK and EMSK are used in the new key hierarchy to generate WLAN domain-level and local55  level keys specific to a WLAN domain. The resulting keys are later used to derive TSKs. MSK is the root key for ordinary local re-authentication operations while EMSK is the root key for HHO initiated pre-authentications. Two keys are derived from the MSK: Domain-level Reauthentication Key (DRK) and Local-level Re-authentication Key (LRK). The keys derived from EMSK are: HO root Key (HOK), Domain-level HO key (DHK) and Local-level HO key (LHK). In the extended key hierarchy, LRK is used to derive TSK in WLLR. Similarly, LHK is used to derive TSK in Intra/Inter-WLAN FP. LRK and LHK play the role of MSK in the standard EAPAKA protocol.  Figure 3.1 Key hierarchies in (a) the standard EAP-AKA protocol and (b) proposed key extensions  The advantage of separating re-authentication only keys from HO pre-authentication keys is to give the 3GPP service provider more control on different security parameters. The service provider can set filters based on the lifetimes of keys derived from MSK and EMSK. These filters aid in enforcing service policies. Figure 3.1 shows the proposed extensions to the key hierarchy in comparison to the standard EAP-AKA key hierarchy. Table 3.1 lists the symbols used in describing the operation of the proposed protocols. In describing some parameters like nonces and some identities, an attached subscript, i, indicates that the parameter is derived in the current authentication session while a subscript, i – 1, indicates that the parameter is derived in a 56  previous authentication session and used in the current session. An asterisk superscript, (*), is attached to a parameter that is recently received. The receiver usually compares the recently received parameter with an identical parameter that it holds or computes. Table 3.1 Symbols used in our proposed protocols Type  Value CK IK  Keys  n values  Nonces  Counters  Identities  MS, HSS  MS, HSS, HAAA  Size (byte) 16  MS, HSS  Derived by  Held by  Notes Cipher Key  MS, HSS, HAAA  16  Integrity Key  MKAKA  MS, HAAA  MS, HAAA  20  Master Key  MSK  MS, HAAA  MS, HAAA  64  Master Session Key  EMSK  MS, HAAA  MS, HAAA  64  Extended MSK  TEK  MS, HAAA  MS, HAAA  32  Transient EAP Key  DRK  MS, HAAA  MS, WAAA  32  Domain-level Re-auth. Key  LRK  MS, WAAA  MS, AP  64  Local-level Re-auth. Key  HOK  MS, HAAA  MS, HAAA  32  Handover Key  DHK  MS, HAAA  MS, WAAA  32  Domain-level HO Key  LHK  MS, WAAA  MS, AP  64  Local-level HO Key  EKWA-MS  MS, WAAA  MS, WAAA  16  MS and WAAA Encryption Key  IKWA-MS  MS, WAAA  MS, WAAA  16  MS and WAAA Integrity Key  nWR  HAAA  MS, WAAA  1  Number of WLLR executions  nHHO  HAAA  MS, WAAA  1  Number of horizontal HOs  HN  HAAA  MS, HAAA  16  Nonce generated by the HAAA  WN  WAAA  MS, WAAA  16  Nonce generated by the WAAA  MN  MS  MS, HAAA  16  Nonce generated by the MS  CWR  -  MS, WAAA  4  WLLR counter. Set by nWR  CHHO  -  MS, WAAA  4  HHO counter. Set by nHHO  TL-ID  MS,WAAA  16  Temporary Local ID used in WLLR  MS-ID  MS  MS, WAAA MS, HAAA, WAAA  16  Permanent MS ID  Modifications to EAP-AKA authentication protocol are necessary to derive additional keys required by WLLR and Intra/Inter-WLAN FP. We suggest replacing the standard EAPAKA with our modified EAP-AKA protocol (mod-EAP-AKA) to allow fast local reauthentication and fast Intra/Inter-WLAN HHO pre-authentication. Mod-EAP-AKA protocol is shown in Figure. 3.2 and proceeds as follows: 1- MS supplies its permanent identity (MS-ID) derived from IMSI to the 3GHN. Subsequently, HAAA derives MKAKA, MSK, EMSK and TEK as specified by the EAP-AKA standard [8]. 57  2- HAAA generates a random number, HN and indicates the permitted number of local reauthentications (nWR) and the permitted number of Intra/Inter-WLAN HHO preauthentications (nHHO). HAAA also appends parameters related to Vertical HO (VHO) activities the MS might perform in the future. These parameters include the permitted number of VHOs MS can perform (nVHO) and a VHO identity (VHO-ID). All these new parameters are appended to EAP Request/AKA-challenge message and encrypted during transmission with K-encr.  Figure 3.2 Modified EAP-AKA (mod-EAP-AKA)  3- Upon receiving EAP Request/AKA-challenge, MS derives MKAKA, MSK, EMSK and TEK as per EAP-AKA specifications [8]. In addition, MS adjust max(CWR) and max(CHHO) according to nWR and nHHO, respectively. For example, if the current CWR = 2 and nWR = 6, max(CWR) should be set to 8. On the other hand, if the current CHHO = 3 and nHHO = 5, max(CHHO) should be set to 7. MS must perform mod-EAP-AKA protocol when either CWR or CHHO exceeds max(CWR) and max(CHHO), respectively. MS also generates a fresh nonce, MN, and appends it to EAP Response/AKA-challenge message. 58  4- Upon receiving EAP Response/AKA-challenge message, HAAA derives three keys from MSK and EMSK. a. Domain-level re-authentication key, DRK, derived from MSK. A special Key Derivation Function (KDF) similar to the one used in deriving MSK is used to derive DRK. DRK = KDF(MSK, HNi | WAAA-ID | MSM | “DRK”, 256 )  (3.1)  where WAAA-ID is the identity of the WAAA. b. Handover key, HOK, derived from EMSK. HOK = KDF(EMSK, EAP-AKA session ID | HAAA-ID | MSM | “HOK” , 256)  (3.2)  where [100] EAP-AKA session ID = (EAP Type Code | RAND | AUTN)  (3.3)  c. Domain-level handover key, DHK, derived from HOK. DHK = KDF(HOK, HNi | WAAA-ID | MSM | “DHK”, 256)  (3.4)  5- HAAA securely forwards nWR, nWRv2, nHHO, DRK and DHK to WAAA in an EAP Success message encapsulated in a Radius Access-Accept message with MS-MPPE-Recv-Key attribute [8]. nWRv2 is used in future VHOs performed by MS, thus its usage is not discussed in this chapter. 6- WAAA adjusts max(CWR) and max(CHHO) according to nWR and nHHO, respectively. Additionally, WAAA derives three keys from DRK and DHK. a. The local-level re-authentication key, LRK, derived from DRK. LRK = KDF(DRK | CWR | AP-ID | MSM | “LRK”, 512)  (3.5)  where AP-ID is the identity of the AP. LRK is securely forwarded to the AP. b. Encryption Key (EKWA-MS) and Integrity Key (IKWA-MS) shared between WAAA and MS are derived to secure the traffic exchanged between them. These keys are derived from DHK and DRK as follows. EKWA-MS | IKWA-MS = KDF(DHK ⊕ DRK | WAAA-ID | MSM | “KWAMS”, 256)  (3.6) 59  7- MS derives DRK, HOK, DHK, LRK, EKWA-MS and IKWA-MS when EAP Success is received. 8- MS and WAAA derive a Temporary Local identity (TL-ID) to be used by MS in subsequent WLLR or Intra/Inter-WLAN FP invocations. WAAA creates a look-up table that includes MS-ID, the expected next local identity (TL-IDi), DRK and DHK. TL-IDi = Hash(DHK ⊕ DRK | MS-ID | CWR | CHHO)  (3.7)  where Hash is a publicly available secured hash function such as SHA-1 [33]. Finally, MS and WAAA increment CWR.  3.4 Proposed protocols Additional security keys are derived as a result of performing mod-EAP-AKA to enable the WAAA to locally authenticate MSs without reverting to the 3GHN. The strategy of localizing authentications within the WLAN domain results in reduced authentication delays and minimized dependence on critical servers in the 3GHN. To achieve fast re-authentication for stationary users, we propose replacing the existing fast EAP-AKA re-authentication with our localized re-authentication protocol, known hereafter as, WLAN Local Re-authentication protocol (WLLR). A MS roams to a neighbor AP when experiencing poor signal-strength from the currently associated AP. The Target AP (TAP) might be in the same WLAN domain or belong to a different WLAN domain. Due to the inefficiency in EAP-AKA invocation during HHOs in 3GPP-WLAN and the inadaptability of fast authentication protocols during HHOs designed for autonomous WLANs, we design Intra and Inter-WLAN Fast Pre-authentication protocols (Intra/Inter-WLAN FP). The proposed protocols are designed to efficiently operate in the 3GPP-WLAN interworking architecture. Intra/Inter-WLAN FP minimizes the dependency on HSS/HAAA, which results in improved performance without compromising security.  60  3.4.1 WLAN local re-authentication protocol (WLLR) WLLR is proposed to replace fast EAP-AKA re-authentication. It is invoked when the user is stationary and requires re-authentication with the same AP in the WLAN domain. Contrary to fast EAP-AKA re-authentication, the authentication procedure in WLLR is performed locally in the WLAN domain without the need to contact HAAA. As a result, WLLR incurs less authentication delays than fast EAP-AKA re-authentication. In WLLR, the WAAA manages MS’s authentication as long as CWR ≤ max(CWR) and DRK have not expired. WLLR is depicted in Figure 3.3 and proceeds as follows:  Figure 3.3 WLAN local re-authentication protocol (WLLR)  1- When re-authentication is necessary, MS supplies TL-IDi − 1 to WAAA. The latter initially checks if the received TL-IDi − 1* is valid and validates the key lifetime of the corresponding DRK and EKWA-MS|IKWA-MS. Subsequently, WAAA checks that CWR ≤ max(CWR). WLLR is stopped and mod-EAP-AKA is executed instead if any of the keys have expired or if CWR > max(CWR). If all checks are positive, WAAA sends an EAP Request/AKA re-authentication message to MS, which includes the current CWR value and a fresh nonce, WN, encrypted with 61  EKWA-MS. Additionally, WAAA includes a message authentication code (MAC) covering CWR and WN calculated with IKWA-MS to preserve their integrity. MAC1WLLR = HMAC(IKWA-MS, WN | CWR)  (3.8)  2- Upon receiving EAP Request/AKA re-authentication message, MS verifies CWR* against CWR stored in its database and computes MAC1WLLR using (3.8). If the calculated MAC is identical to MAC1WLLR*, MS increments WN and sends an EAP Response/AKA re-authentication message that includes CWR value found in its database and a new MAC covering CWR and WN + 1. The counter is encrypted with EKWA-MS. MAC2WLLR = HMAC(IKWA-MS, WN +1 | CWR )  (3.9)  3- WAAA receives EAP Response/AKA re-authentication message and verifies that the received CWR* is identical to CWR maintained in its database. Following that, it increments WN and validates MAC2WLLR*. If all validations are successful, WAAA derives LRK from DRK using (3.5) and the next temporary local identity (TL-IDi) using (3.7). Finally WAAA increments CWR and sends an EAP Success message to MS. In addition, LRK is securely pushed to AP and it is deleted from WAAA’s database. 4- Upon receiving EAP Success message, MS derives LRK from DRK using (3.5), derives the next temporary local identity (TL-IDi) using (3.7) and increments CWR. MS and AP seeds LRK into the 4-way handshake protocol described in 802.11i [36] to derive a fresh TSK. A flow chart describing the operation of WAAA and MS in WLLR is shown in Figure 3.4 and Figure 3.5, respectively.  62  Figure 3.4 Flow chart describing MS’s operation in WLLR  Figure 3.5 Flow chart describing WAAA’s operation in WLLR  3.4.2 Intra-WLAN fast pre-authentication protocol (Intra-WLAN FP) Intra-WLAN FP is locally executed when the currently associated AP (AAP) and the TAP reside in the same WLAN domain. MS needs to supply TAP identity (TAP-ID) and target WAAA identity (TWAAA-ID) it anticipates to HO to. Therefore, we propose adjusting the IEEE 63  802.11 Probe Response management frames transmitted by TAP to include its identity and the identity of WAAA it is associated with as Information Elements (IEs). Element IDs 7-15 and 32255 are reserved for future use and can be used for this purpose [3]. HO related decisions like HO triggers and best TAP selection are out of the scope of our work. MS examines the TWAAAID included in the modified IEEE 802.11 Probe Response management frame to determine whether an Intra-WLAN domain or Inter-WLAN domain HHO procedure is required. In IntraWLAN FP, WAAA handles MS authentication instead of HSS/HAAA. Intra-WLAN FP is depicted in Figure 3.6 and proceeds as follows:  Figure 3.6 Intra-WLAN fast pre-authentication  1- When MS recognizes the need for intra-WLAN HHO, it sends an EAPoL-start message to the currently AAP, not shown in Figure 3.6. The AAP replies with an EAP Request/identity message. 2- MS responds to the request with TL-IDi – 1. TL-IDi – 1 could be derived in a previous modEAP-AKA session, a previous WLLR session or a previous Intra/Inter-WLAN FP session. In addition, MS appends TAP-ID.  64  3- Receiving a TAP-ID indicates an Intra-WLAN FP request. WAAA validates that the TAP indicated by the received TAP-ID* exists and within its jurisdiction. If the TAP exist, WAAA verifies that CHHO ≤ max(CHHO) and prepares an EAP-Request/AKA-challenge message. The challenge includes a new fresh nonce, CHHO maintained by WAAA and a MAC calculated as follows. MAC1Intra = HMAC(IKWA-MS, WN | CHHO)  (3.10)  4- Upon receiving the challenge, MS matches the received CHHO* with CHHO it maintains in its database. If the counters match, it computes MAC1Intra using (3.10) and matches it with the received MAC1Intra*. Later, MS increments WN and prepares an EAP-Response/AKAchallenge message that includes the current CHHO it holds and MAC2Intra. MAC2Intra = HMAC(IKWA-MS, WN + 1 | CHHO)  (3.11)  5- Finally, WAAA validates the received CHHO*, increments WN and validates the received MAC2Intra*. If all validations are successful, WAAA derives a new local-level HO key, LHK, from DHK and generates a new temporary local identity (TL-IDi) using (3.7). LHK = KDF(DHK, CHHO | TAP ID | MSM | “LHK” , 512)  (3.12)  6- WAAA also increments CHHO and sends EAP Success message to MS. Consequently, MS derives LHK using (3.12), generates a new temporary local identity (TL-IDi) and increments CHHO. 7- WAAA and TAP exchange Radius Notify-Request and Notify-Accept message to confirm the HO operation [101]. Finally LHK is pushed to TAP in Radius Access-Accept message with MS-MPPE-Recv-Key attribute.  65  3.4.3 Inter-WLAN fast pre-authentication protocol (Inter-WLAN FP) Inter-WLAN FP is executed when the currently AAP and TAP reside in different WLAN domains. In Inter-WLAN FP, authentication procedure is completed without the need to retrieve a new AV from HSS as shown in Figure 3.7. The protocol proceeds as follows. 1- MS replies to the identity request message with TL-IDi – 1 previously generated in a modEAP-AKA session, a WLLR session or an Intra/Inter-WLAN FP session. Additionally, MS supplies TWAAA-ID and TAP-ID. 2- The Associated WAAA (AWAAA) matches the received TWAAA-ID* with its identity. If a mismatch is found, the AWAAA recognizes that MS is requesting an Inter-WLAN FP. AWAAA validates if CHHO ≤ max(CHHO). If HHO pre-authentication is permitted, it retrieves MS-ID and forwards it along with TAP-ID and TWAAA-ID to HAAA. 3- HAAA recognize that an Inter-WLAN FP is requested when the TWAAA-ID received matches the identity of an existing WAAA under its jurisdiction. HAAA prepares an EAP Request/AKA-challenge that includes a newly generated HNi and MAC1Inter. MAC1Inter = HMAC(K-auth, MNi – 1 | HNi )  (3.13)  where MNi – 1, is the nonce generated by MS in the last mod-EAP-AKA session. 4- Upon receiving the authentication challenge, MS verifies the correctness of the received MNi –1  *  and calculates a new MAC1Inter using (3.13) and compares it with the received MAC1Inter*.  If all verifications return positive, MS generates a new nonce and appends it along with CHHO in an EAP Response/AKA-challenge message. The response also includes a newly computed MAC2Inter. MAC2Inter = HMAC(K-auth, MNi | HNi | HNi – 1 | CHHO)  (3.14)  where HNi – 1, is the nonce generated by HAAA in the last mod-EAP-AKA session. 5- Upon receiving EAP Response/AKA-challenge message, HAAA verifies the correctness of the received HNi  – 1  *  and the received MAC2Inter*. If all verifications are successful, the 66  HAAA validates the lifetime of HOK and generates a new DRK and DHK using (3.1) and (3.4), respectively. Lastly, HAAA sends an EAP Success message to MS. 6- Upon receiving EAP Success message, MS derives a new DRK, DHK, EKTWA-MS/IKTWA-MS, LHK and TL-IDi using (3.1), (3.4), (3.6), (3.12) and (3.7), respectively. Lastly, the MS increments CHHO. 7- AAA message that includes DHK, DRK, CHHO, max(CHHO), nWR, MS-ID, and TAP-ID is sent to TWAAA by HAAA. As a result, TWAAA derives EKTWA-MS/IKTWA-MS, LHK and TL-IDi using (3.6), (3.12) and (3.7), respectively. TWAAA also increments the received CHHO and adjusts CWR according to nWR. Lastly, TWAAA confirms the HO with TAP by exchanging Radius Notify-Request and Notify-Accept messages and forwards LHK in a Radius AccessAccept message. At the conclusion of a successful Intra or Inter-WLAN FP, a fresh LHK is held by MS and TAP. LHK is used to generate TSK, which is then used to derive additional keys that are needed to secure the link between MS and TAP. EAP-AKA highly depends on IEEE 802.1X [35] protocol implemented in APs to successfully control MS’s network access. IEEE 802.1X is a port-based access control protocol. When an EAP session completes successfully between MS and AP, normal communications is permitted by the latter to pass through an authorized port. Therefore, simultaneous exchange of normal communications and EAP session is disallowed. We propose two classes of Intra/Inter-WLAN FP operation depending on the implementation of IEEE 802.1X protocol. The two classes differ on whether IEEE 802.1X protocol in APs permits single or multiport communications. Based on this, each class imposes different effect on the authentication delay. Single-port communication implies that normal communications between MS and AP is disallowed when EAP session is executed. Multi-port communications implies that AP can still handle normal communications while processing EAP messages. Multi-port communications is 67  achievable by applying simple modifications to the IEEE 802.1X protocol in the AP. In studying the performance of our proposed protocols, both single-port and multi-port communications are going to be considered.  Figure 3.7 Inter-WLAN fast pre-authentication  3.5 Performance evaluation The performances of the proposed protocols are evaluated in this section by comparing them against the standard EAP-AKA protocol. Performance metrics used in the comparisons include authentication signaling cost, authentication delay and the load on critical nodes in the 3GPP-WLAN interworking architecture.  3.5.1 Performance evaluation of WLLR Mod-EAP-AKA and WLLR are compared against full EAP-AKA (re-)authentication and fast EAP-AKA re-authentication in this section. Let F = {Full EAP-AKA (re-)authentication, Fast EAP-AKA re-authentication, mod-EAP-AKA, WLLR} denotes the set of standard and  68  proposed protocols. Let F1 indicates the first entry in F, F2 indicates the second entry in F and so forth. Three Re-authentication Scenarios (RS) are considered: •  RS1: In this scenario, MS performs full EAP-AKA authentication at the beginning of the session followed by full EAP-AKA re-authentication for every consequent re-authentication.  •  RS2: In this scenario, MS performs full EAP-AKA authentication at the beginning of the session followed by the optional fast EAP-AKA re-authentication for every consequent reauthentication.  •  RS3: In this scenario, MS performs mod-EAP-AKA at the beginning of the session followed by WLLR for every consequent re-authentication provided that CWR ≤ max(CWR). RS1 and RS2 resemble the standard authentication protocols while RS3 resembles our  proposed protocols. Although executing fast EAP-AKA re-authentication is optional and must be activated by the 3GHN, it is included in the performance analysis as the best case scenario achievable by the standard protocols. Let MR be a row matrix that indicates the total size of authentication-related messages emitted by each protocol in F. MR = [M F1 , M F 2 , M F 3 , M F 4 ]  (3.15)  The size of the authentication-related messages emitted in each protocol in F are induced and calculated from [3], [8] and [17]. 28 bytes of IEEE 802.11 frame, 6 bytes of EAPoL header and 4 bytes of EAP header are included in calculating the size of the messages exchanged in the wireless network. 18 bytes of IEEE 802.3 frame, 20 bytes of IP header, 8 bytes of UDP header, 20 bytes of Radius header, 2 bytes of Radius attribute header and 4 bytes of EAP header are included in calculating the size of the messages exchanged in the wired network. Table 3.2 lists the total size of messages emitted by the protocols in F.  69  Table 3.2 Values of the performance metrics for each protocol in F  Size of authentication-related message (MR) in bytes Average message size in each protocol in bytes Delay (TR) in milliseconds Total numbers of keys generated by all nodes Size of keys generated by all nodes in bytes Numbers of keys generated by HSS and HAAA Sizes of keys generated by HSS and HAAA in bytes Number of keys generated by MS Sizes of keys generated by MS in bytes Keys generated by MS  Full EAP-AKA (re-)auth. MF1 2914  Fast EAP-AKA re-auth. MF2 2254  100  Mod-EAP-AKA  WLLR  MF3 3155  MF4 893  90  109  69  TF1 140  TF2 131  TF3 141  TF4 100  12  6  24  2  424  296  808  128  6  3  9  0  212  148  276  0  6  3  12  1  212  148  404  64  CK, IK, MKAKA, MSK,EMSK,TEK  MSK, EMSK, XKEY’  CK, IK, MKAKA, MSK, EMSK, TEK, DRK, HOK, DHK, LRK, EKWAMS, IKWA-MS  LRK  Studying the signaling cost produced by an authentication protocol is an important metric in evaluating its performance. Authentication signaling cost is the accumulative traffic load emitted during an authentication protocol session. The size of authentication-related messages exchanged during a (re-)authentication protocol is an indicator of the signaling cost of the respective protocol. From Table 3.2, it is clear that mod-EAP-AKA emits more authentication signaling compared to full EAP-AKA. This is expected since additional keys and parameters are transferred during mod-EAP-AKA compared to full EAP-AKA. Nevertheless, WLLR emits 2.5 times less authentication signaling compared to fast EAP-AKA reauthentication and more than 3 times less signaling compared to full EAP-AKA reauthentication due to the localization in the re-authentication procedure. During WLLR session, re-authentication is achieved without contacting 3GHN, which greatly reduces the cost of the authentication signaling. 70  For an MS adopting the standard protocols, invoking full EAP-AKA is enforced when the Counter parameter in the fast EAP-AKA re-authentication protocol reaches the maximum value [8] or when the key lifetime of MKAKA expires. For an MS adopting our proposed protocols, invoking mod-EAP-AKA is enforced when CWR > max(CWR) or when DRK lifetime expires. The authentication signaling cost for RS1, RS2 and RS3, assuming that MS can perform 10 re-authentications before it is forced to invoke full EAP-AKA authentication or mod-EAPAKA is found as follows. C RS1 = LRS1 ⋅ MR C RS 2 = LRS 2 ⋅ MR  (3.16)  C RS 3 = LRS 3 ⋅ MR where LRS1 = [11, 0, 0, 0] LRS 2 = [1, 10, 0, 0]  (3.17)  ⎧ [0, 0, 4, 7] , nWR = 2 ⎪ LRS 3 = ⎨ [0, 0, 2, 9] , nWR = 6 ⎪ [0, 0,1,10] , n WR = 10 ⎩  Equations (3.16) and (3.17) also considers the situation where MS adopting our proposed protocols can only perform 2 and 6 re-authentications only, i.e., when nWR = 2 and nWR = 6, respectively. Figure 3.8 shows a comparison between standard protocols and our proposed protocols in terms of the cost of authentication signaling when 10 re-authentications are invoked. As shown in Figure 3.8, proposed protocols outperform standard protocols. RS3 cuts the authentication signaling by a factor of 2.5 compared to RS1 and by a factor of 2 compared to RS2. Our proposed protocols emit less signaling than standard protocols even when nWR < 10. Generally, as nWR increases, WLLR is executed more frequently resulting in releasing less authentication signaling in RS3 compared to RS1 and RS2. 71  Authentication Signaling (KByte)  35 RS3 RS2 RS1 25  15  5  2  6 nWR  10  Figure 3.8 Comparison between RS1, RS2 and RS3 in terms of the authentication signaling cost  Let TR be a row matrix that indicates the total authentication delay of each protocol in F. The authentication delay is calculated starting from reception of EAP Request/identity message by the AP to reception of the last message of the 4-way handshake protocol. TR = [TF1 , TF 2 , TF 3 , TF 4 ]  (3.18)  where  (  (  )) (  (  ))  TFi = M wl Dt ( wl ) + D pp ( wl ) + 2 D pc + M wd H wd Dt ( wd ) + D pp ( wd ) + 2 D pc + TEi (3.19)  where Mwl and Mwd indicate the number of messages exchanged in the wireless and wired networks, respectively. Hwd denotes the number of hops in the wired network. It is assumed that all nodes are a single hop apart except between WAAA and HAAA and between HAAA and HSS. The number of hops between WAAA and HAAA are set to 3 and the number of hops between HAAA and HSS are set to 2 when calculating the authentication delays of the protocols in F. Dt(wl) and Dt(wd) are the wireless and wired transmission delays, respectively. Dt(wl) = Avg. MFi/Wwl and Dt(wd) = Avg. MFi/Wwd. Average message size of the protocols in F are listed in Table 3.2. Wwl and Wwd are the wireless and wired data rates and they are set to 11Mbps and 100Mbps, respectively. Dpp(wl) and Dpp(wd) are the wireless and wired propagation delays, 72  respectively, and they are set to 2ms and 0.5ms, respectively. Dpc is the nodal processing delay, it is set to 1μs. TEi accounts for additional delays occurring in the protocol. The delays include encryption/decryption delays, key generation delays and AV generation delays. Equation (3.19) and the values of Dpp(wl), Dpp(wd), Dpc, Wwl and Wwd are induced and obtained from [77] and [102]. The values of TF1 to TF4 are listed in Table 3.2. The delay in executing full EAP-AKA (re-)authentication is comparable to the delay in executing mod-EAP-AKA. The delay in executing WLLR is 24% and 29% less than the delay in executing fast EAP-AKA reauthentication and full EAP-AKA (re-)authentication, respectively. This low delay is achieved because there is no need to contact the 3GHN in WLLR. Assuming that 10 re-authentications take place before invoking full EAP-AKA authentication and mod-EAP-AKA, the authentication delays in the three scenarios are found as follows: TD RS1 = LRS1 ⋅ TR TD RS 2 = LRS 2 ⋅ TR  (3.20)  TD RS 3 = LRS 3 ⋅ TR Figure 3.9 depicts a comparison between RS1, RS2 and RS3 in terms of authentication delay when 10 re-authentications are permitted. In addition, Figure 3.9 shows the comparison when 2 and 6 re-authentications are permitted in our proposed protocols. Again, RS3 experiences less authentication delay compared to RS1 and RS2. As more WLLR executions are permitted, i.e., by increasing nWR, the delay difference between RS3 and both RS1 and RS2 increases. Figure 3.10 shows the effect of increasing the number of hops between WAAA and HAAA on authentication delay. Such an increase only effects full EAP-AKA (re-)authentication, fast EAP-AKA re-authentication and mod-EAP-AKA. WLLR is not affected by such an increase because it is executed locally in the WLAN domain. Therefore, the protocols in RS3 are best suited to handle delay-sensitive wireless applications. 73  Authentication Delay (sec)  1.4  1  0.6  0.2 2  6 nWR RS3  10  RS2  RS1  Figure 3.9 Comparison between RS1, RS2 and RS3 in terms of authentication delay  RS1 RS2 RS3 (nWR = 2)  Authentication Delay (sec)  2.0  RS3 (nWR = 6) RS3 (nWR = 10)  1.6  1.2  3  4  5 6 Hops between WAAA and HAAA  7  8  Figure 3.10 Authentication delay comparison between RS1, RS2 and RS3 when varying the hops between the WAAA and the HAAA  Our proposed protocols introduce additional keys to enable future local reauthentications. A comparison between proposed protocols and standard protocols in terms of the number and size of keys generated by each protocol is studied. It is always desired to achieve a secure key management scheme with minimum number of keys. Reducing the number of keys used in a protocol infers less key generation and maintenance overhead per node. Additionally, studying the size of the keys generated per node sheds light on the key generation overhead per node. Only keys derived from CK and IK are included in the study, as shown in Figure 3.1. 74  Mod-EAP-AKA generates more keys compared to full EAP-AKA as detailed in Table 3.2. On the other hand, WLLR generates less number of keys compared to fast EAP-AKA reauthentication. Therefore our proposed protocols generate more keys compared to standard protocols when more mod-EAP-AKA and few WLLR invocations takes place. The proposed protocols show improved performance when reducing the frequency of executing mod-EAPAKA and increasing the frequency of executing WLLR. Since WLLR is locally executed, critical nodes in the 3GHN like HSS/HAAA are not involved in the re-authentication procedure, and hence, do not require to generate new keys. Figure 3.11 illustrates the number and size of keys generated by all nodes when 10 reauthentications are performed by standard protocols and for different nWR values for proposed protocol. When nWR is set to 2, mod-EAP-AKA is executed 4 times, therefore, more keys are generated in RS3 compared to RS2. Nevertheless, the number of keys generated in RS3 is always less than RS1 regardless of the value of nWR. When decreasing the frequency of executing mod-EAP-AKA, i.e., by increasing nWR, the total number and size of keys generated in RS3 becomes less than that generated in RS2. This situation is depicted in Figure 3.11 when nWR is set to 6 and 10. HSS and HAAA controls tens of thousands of users, hence it is important to minimize the numbers of keys they generate and maintain for each user. The total number and size of keys generated by HSS and HAAA in each protocol in F is listed in Table 3.2. By invoking WLLR instead of full or fast EAP-AKA re-authentication, HSS and HAAA delegates authentication and key generation to passive nodes like WAAA. WAAA controls far less number of MSs in comparison to HSS and HAAA. A better utilization of HSS and HAAA resourced is achieved by distributing the key generation and maintenance load to less busy nodes.  75  140 4.5  Size of keys (KByte)  Number of keys  100  60  3.5  2.5  1.5  20 0.5 2  6  nWR  10  2  RS3  RS2  RS1  6  10  nWR  Figure 3.11 Comparison between RS1, RS2 and RS3 in terms of the number and size of keys generated by all nodes  Figure 3.12 demonstrates the total numbers and sizes of keys generated by HSS and HAAA per MS when 10 re-authentications are permitted. The proposed protocols largely minimize the reliance on HSS and HAAA to derive keys as shown in Figure 3.12. The numbers of keys generated by HSS and HAAA per MS in RS3 is less than those generated in RS2 and RS1 by a factor of 4 and 7.3, respectively. Similarly, the size of keys generated by HSS and HAAA per MS in RS3 is less than those generated in RS2 and RS1 by a factor of 6.1 and 8.4, respectively. RS3 displays satisfying results in Figure 3.12 in spite of reducing the permissible number of re-authentications, i.e., reducing the value of nWR. Additionally, as the number of MSs requiring re-authentications increases in the WLAN domain, the numbers of keys generated by HSS and HAAA in RS1 and RS2 increases at a faster pace compared to RS3. MS has limited processing capabilities and storage space. A list of key sizes produced by MS in each protocol in F is shown in Table. 3.2. Figure 3.13 displays the total number and size of keys produced by MS when invoking 10 re-authentications in the standard protocols and for different nWR values in the proposed protocols. Due to the repetitive execution of mod-EAPAKA when nWR is set to 2, the total number and size of the keys generated by MS in RS3 76  exceeds RS2 but it is less than RS1. As nWR increases, WLLR is executed more frequently and the accumulative number and size of keys generated in RS3 becomes less than both RS2 and RS1. For 10 re-authentications, a MS adopting RS3 ends up generating keys with a total key size that is 38% and 55% less than that experienced by a MS adopting the protocols in RS2 and RS1, respectively.  70  2.5  Size of keys (KByte)  Number of keys  50  30  1.5  0.5 10  2  6  10  2  nWR  6  10  nWR RS3  RS2  RS1  Figure 3.12 Comparison between RS1, RS2 and RS3 in terms of the numbers and sizes of keys generated by the HSS and the HAAA  70  2.5  Size of keys (KByte)  Number of keys  50  30  1.5  0.5 10  2  6  10  2  nWR  6  10  nWR RS3  RS2  RS1  Figure 3.13 Comparison between RS1, RS2 and RS3 in terms of the number and size of keys generated by MS  77  3.5.2 Performance evaluation of the Intra/Inter-WLAN fast pre-authentication protocols The performance of Intra/Inter-WLAN FP protocols are compared against the standard protocols. The performance comparison is based on a fixed trajectory 6-steps MS movement shown in Figure 3.14. This movement might not reflect a realistic MS path but it is considered here for performance comparison purposes only. Initially, MS is connected to AP1 in WLAN1 and then performs two intra-WLAN domain HHOs to AP2 and AP3 in WLAN1. Later, it performs an inter-WLAN domain HHO to AP1 in WLAN2 followed by two intra-WLAN HHOs to AP2 and AP3 in WLAN2.  Figure 3.14 MS movement  Four authentication scenarios are considered in the performance study. •  Scenario 1 (Sc1): In this scenario, MS performs full EAP-AKA (re-)authentication whenever it performs a HHO.  •  Scenario 2 (Sc2): In this scenario, MS performs fast EAP-AKA re-authentication when intraWLAN HHO is performed. This is a purely hypothetical scenario because fast EAP-AKA reauthentication is not designed to handle intra-WLAN HHOs, and therefore might not be practical.  78  •  Scenario 3 (Sc3): In this scenario, MS performs mod-EAP-AKA and Intra/Inter-WLAN FP. The IEEE802.1X protocol in the APs in this scenario only supports single-port communications.  •  Scenario 4 (Sc4): This scenario is identical to Sc3 in terms of message signaling, however, IEEE 802.1X protocol in the APs supports multi-port communications. Therefore, MS and AP are capable of handling normal communications while processing EAP messages for preauthentication purposes. Sc2 is expected to outperform Sc1 because of invoking fast EAP-AKA re-authentication  when intra-WLAN HHO is performed. Hence, Sc2 is expected to produce the best theoretically achievable results using the standard authentication protocols. Our proposed pre-authentication protocols represented by Sc3 and Sc4 should perform equivalently in terms of authentication signaling cost and the number of produced keys, however, authentication delay experienced by these scenarios should distinctly differ.  Figure 3.15 Authentication protocols executed in Sc1, Sc2, Sc3 and Sc4 when nHHO = 5 79  Authentication protocols invoked in Sc3 and Sc4 depends on the number of permitted pre-authentications (nHHO). For example, setting nHHO to 1, 3 and 5 indicates that mod-EAP-AKA is going to be invoked thrice, twice and once, respectively. For a MS adopting our proposed protocols, setting nHHO to 1 resembles the worst case scenario and should display the worst performance results while setting it to 5 resembles the best case scenario and should display the best performance results. Figure 3.15 depicts the authentication protocols performed by a MS when pursuing the 6-steps MS movement depicted in Figure 3.14. Figure 3.15 shows the authentication protocols executed by MS in Sc1, Sc2 as well as Sc3 and Sc4 in the case where nHHO is set to 5. Table 3.3 Values of the performance metrics for each protocol in P  Size of authentication-related message (MR) in bytes Average message size in each protocol in bytes Delay (TR) in milliseconds Total number of keys generated by all nodes Number of keys generated by HSS and HAAA Number of keys generated by the MS Keys generated by the MS Size of keys generated by MS in bytes  Intra-WLAN FP Intra-WLAN (Sc3) FP (Sc4) MP4 = MP6 1129  Inter-WLAN FP Inter-WLAN (Sc3) FP (Sc4) MP5 = MP7 2925  71  94 TP6 48  TP4 108  TP5 146  TP7 55  2  10  0  2  1  5  LHK  DRK, DHK, LHK, EKWA-MS, IKWA-MS  64  160  Let P = {Full EAP-AKA (re-)authentication, Fast EAP-AKA re-authentication, modEAP-AKA, Intra-WLAN FP (Sc3), Inter-WLAN FP (Sc3), Intra-WLAN FP (Sc4), Inter-WLAN FP (Sc4)} denotes the set of standard and proposed authentication protocols. Let P1 indicates the first entry in P, P2 indicates the second entry in P and so forth. Let MS be a row matrix that indicates the total size of authentication-related messages emitted in every authentication  80  protocol in P. Table 3.3 lists the values of MP4, MP5, MP6 and MP7. Values of MP1, MP2 and MP3 are listed in Table 3.2 where MP1 = MF1, MP2 = MF2 and MP3 = MF3. MS = [M P1 , M P 2 , M P3 , M P 4 , M P5 , M P 6 , M P 7 ]  (3.21)  The cost of emitted authentication signaling in Sc1, Sc2, Sc3 and Sc4 based on MS movement depicted in Figure 3.14 is found as follows: C Sc1 = ASc1 ⋅ MS C Sc 2 = ASc 2 ⋅ MS  (3.22)  C Sc3 = C Sc 4 = ASc3 ⋅ MS where ASc1 = [6, 0, 0, 0, 0, 0, 0] ASc 2 = [2, 4, 0, 0, 0, 0, 0]  (3.23)  ⎧ [0, 0, 3, 2,1, 0, 0] , n HHO = 1 ⎪ ASc3 = ⎨ [0, 0, 2, 3,1, 0, 0] , n HHO = 3 ⎪ [0, 0,1, 4,1, 0, 0] , n HHO = 5 ⎩  Figure 3.16 depicts a comparison between Sc1, Sc2 and Sc3 in terms of authentication signaling cost. It is clear from the Figure that Sc3 surpasses Sc1 and Sc2 by dispatching less authentication signaling. Sc3 reduces signaling cost by 16% when compared to Sc1 and performs comparably to Sc2 when nHHO is set to 1. Improved performances results are achieved when increasing the value of nHHO. Reduction in the signaling cost experienced by Sc3 reaches up to 39% and 29% in comparison to Sc1 and Sc2, respectively, when setting nHHO to 5. Sc1 and Sc2 experience the same signaling cost in spite of the change in the value of nHHO. Increasing nHHO value means reducing the frequency of invoking mod-EAP-AKA and permitting additional pre-authentications, i.e., Intra/Inter-WLAN FP, without the need to contact 3GHN, hence achieving remarkable reduction in the signaling cost.  81  Figure 3.17 shows the accumulative authentication signaling for every authentication step in the 6-steps MS movement when nHHO is set to 5. A surge in authentication signaling is noticed in steps 1 and 4 for a MS adopting Sc3 and Sc4 compared to steps 2, 3, 5 and 6 due to the execution of mod-EAP-AKA and Inter-WLAN FP. These protocols require more authentication signaling compared to Intra WLAN FP as shown in Table 3.2 and Table 3.3. A similar trend is observed in steps 1, 4 and 5 when nHHO is set to 3 as shown in Figure 3.18.  Authentication Signaling (KByte)  18  14  10  6  2 1  3 nHHO Sc3 = Sc4  5  Sc2  Sc1  Figure 3.16 Authentication signaling cost comparison between Sc1, Sc2 and Sc3  Sc1 Sc2 Sc3 = Sc4  Authentication Signaling (KByte)  16  12  8  4  1  2  3 4 Authentication Steps  5  6  Figure 3.17 Accumulative authentication signaling on every step in the 6-steps MS movement when nHHO = 5  Authentication delay has an important impact on the overall HO delay. We assume that delays that constitute HO delay, other than authentication delay, like AP scanning delay and 82  Mobile IP registration delay have an equal effect on all authentication scenarios. Authentication delay is calculated starting from sending EAP Request/Identity message and ends by receiving the last message of the 4-way handshake protocol. Let TS be a row matrix indicating the total authentication delay of the standard and proposed protocols in P. TS = [TP1 , TP 2 , TP3 , TP 4 , TP5 , TP 6 , TP 7 ]  (3.24)  Authentication Signaling (KByte)  where TP1 = TF1, TP2 = TF2 and TP3 = TF3.  20  15  10 5  0 5 6 3  4  nHHO 1  3  2  Authentication Steps  1  Sc3 = Sc4  5  Sc1  Figure 3.18 Relationship between the accumulative authentication signaling on every step when varying nHHO  The values of TP4 to TP7 and Avg. MP4 to Avg. Mp7 used in finding TPi are listed in Table 3.3. EAP session is not included in the calculation of the authentication delay in Sc4 due to AP’s capability to support multi-port communication. This explains the reduced authentication delay experienced by the protocols in Sc4 compared to Sc3. Based on MS movement depicted in Figure 3.14, the total authentication delays of each authentication scenario is found as follows:  83  TDSc1 = ASc1 ⋅ TS TDSc 2 = ASc 2 ⋅ TS  (3.25)  TDSc3 = ASc3 ⋅ TS TDSc 4 = ASc 4 ⋅ TS where ⎧ [0, 0, 3, 0, 0, 2,1] , n HHO = 1 ⎪ ASc 4 = ⎨ [0, 0, 2, 0, 0, 3,1] , n HHO = 3 ⎪ [0, 0,1, 0, 0, 4,1] , n HHO = 5 ⎩  (3.26)  Figure 3.19 shows the authentication delay of each scenario for different nHHO values. Sc3 and Sc4 consistently outperform Sc1 and Sc2 for all nHHO values. When nHHO is set to 1, authentication delay in Sc3 is slightly less than Sc1 and Sc2 due to multiple executions of modEAP-AKA, which is a delay intensive operation. However, since Sc4 takes advantage of the multi-port communications in the AP, it experiences much less delay reduction compared to Sc1 and Sc2.  Authentication Delay (msec)  900  700  500  300  100 1  3 nHHO Sc4  Sc3  5  Sc2  Sc1  Figure 3.19 Authentication delays of the four scenarios for different nHHO values  Our proposed protocols demonstrate exceptional results as nHHO value increases. When nHHO is set to 5, our protocols capitalize on the single execution of mod-EAP-AKA to perform several pre-authentications without the need to contact HSS/HAAA, which ultimately reduces 84  authentication delay. In such settings, authentication delay reduction in Sc3 and Sc4 reaches up to 15% and 54% compared to Sc1. Similarly, the reduction reaches up to 11% and 52% compared to Sc2. Figure 3.20 depicts the authentication delay of the four scenarios when increasing the number of hops between WAAA and HAAA. For simplicity, when varying the number of hops, we assume that it takes effect on all WLANs simultaneously. When WAAA and HAAA are 8 hops apart, Sc3 outperforms Sc1 and Sc2 by a factor of 1.38 and 1.33, respectively. On the other hand, Sc4 outperforms Sc1 and Sc2 by a factor of 2.55 and 2.46, respectively.  Authentication Delay (msec)  1200 Sc1 Sc2 Sc3 Sc4  1000  800  600  400 3  4  5 6 Hops between WAAA and HAAA  7  8  Figure 3.20 Authentication delays of the four scenarios when varying the number of hops between WAAA and HAAA  Figure 3.21 shows the authentication delay in Sc1, Sc3 and Sc4 when varying nHHO and varying the number of hops between WAAA and HAAA. Increasing both nHHO and the number of hops between WAAA and HAAA results in more reductions in the authentication delay in Sc3 and Sc4 compared to Sc1 and Sc2 due to repetitive execution of Intra-WLAN FP and InterWLAN FP during HHOs. This proves the superiority and suitability of our proposed protocols to sustain the QoS of delay-sensitive applications running on the MS during HHOs. In the 3GPP-WLAN interworking architecture, critical nodes involved in the authentication procedure are HSS, HAAA and MS. HSS and HAAA are considered critical 85  because they handle the authentication of hundreds of thousands of MSs. The MS is considered critical as well because of the limitation in its processing capabilities.  400  500  600  700  800  900  1000  1100  Authentication Delay (msec)  1200  1000  800  600  400 1 3 nHHO  5  1  2  4  3  5  6  Hops between WAAA and HAAA  Sc1  Sc3  Sc4  Figure 3.21 Authentication delays of Sc1, Sc3 and Sc4 when varying nHHO and the number of hops between WAAA and HAAA  Table 3.2 and Table 3.3 list the number and size of keys generated by each protocol in P. In our proposed protocols, HSS and HAAA delegate the authentication responsibility to trusted WAAA servers. Therefore, the processing overhead on these critical nodes is reduced. Since mod-EAP-AKA introduces additional keys to permit correct Intra/Inter-WLAN FP execution, a study on the effect of the additional keys is important. In the study, the number and size of keys introduced in each authentication protocol starting from CK and IK down the hierarchy to the key used in the 4-way handshake protocol, i.e., MSK in Sc1 and Sc2 and LHK/LRK in Sc3 and Sc4, are considered. Table 3.4 indicates the number and size of keys generated by all nodes for different nHHO values based on MS movement depicted in Figure 3.14. Figure 3.22 illustrates the keys generated by each node when nHHO is set to 5. 86  Table 3.4 Number and size of keys generated in the four scenarios nHHO Number of keys generated by MS Size of keys generated by MS in Bytes Number of keys generated byWAAA1 +WAAA2 Size of keys generated by WAAA1 + WAAA2 in Bytes Numbers of keys generated by HAAA + HSS Sizes of keys generated by HAAA + HSS in Bytes Total number of keys: All nodes Total size of keys: All nodes (Bytes) Total number of keys: Critical nodes Total size of keys: Critical nodes (Bytes)  Sc1 36 1272 0  Sc2 24 1016 0  1 43 1500 14  Sc3 = Sc4 3 32 1160 12  0  0  512  480  448  36 1272 72 2544 72 2544  24 1016 48 2032 48 2032  29 988 86 2488 72 1976  20 680 64 2320 52 1840  11 372 42 1640 32 1192  5 21 820 10  Figure 3.22 Keys generated by the authentication protocols in Sc1, Sc2, Sc3 and Sc4 when nHHO = 5  As indicated in Table 3.4, the total number of keys generated by all nodes in Sc3 and Sc4 decreases as nHHO value increase. When nHHO is set to 1, Sc3 generates more number and size of keys compared to Sc1 and Sc2 due to frequent execution of mod-EAP-AKA. As nHHO value increase, the frequency of executing mod-EAP-AKA decreases and hence fewer keys are generated by all nodes when compared against Sc1 and Sc3. Critical nodes in Sc3 generate identical number of keys to Sc1 but with less key size. Critical nodes in Sc3 generate less than half the number and size of keys generated by their counterpart in Sc1 when nHHO is set to 5. 87  This is because WAAA handle some of the key generation activity. The numbers of keys generated by critical nodes in addition to WAAA1 and WAAA2 in Sc3 is 42 keys of total size of 1192 Bytes which is clearly less than the number of keys generated by all nodes in Sc1 and Sc2. From Table 3.4, the numbers and sizes of keys generated by HSS and HAAA in Sc1 is always greater than the numbers and sizes of keys generated by HSS and HAAA in Sc3. However, due to the execution of fast EAP-AKA re-authentication in Sc2, the numbers of keys generated by HSS and HAAA in that scenario is less than the numbers of keys generated by these servers in Sc3 when nHHO is set to 1. As nHHO value increases, HSS and HAAA in Sc3 produces reduced numbers of keys compared to Sc2 and Sc1 especially when nHHO ≥ 3. In terms of key sizes, Sc3 always surpasses Sc1 and Sc2 for all nHHO values. Figure 3.23 shows the accumulative numbers and sizes of keys produced by HSS and HAAA in each authentication step.  40  Size of keys (Bytes)  Number of keys  1200 30  20  800  400  10  1  2  3 4 Authentication steps Sc1  Sc2  5  6  Sc3, nHHO = 1  1  2  3 4 Authentication steps  Sc3, nHHO = 3  5  6  Sc3, nHHO = 5  Figure 3.23 Numbers and sizes of keys generated by HSS and HAAA on every authentication step  The advantage of less key generation and maintenance by HSS and HAAA is highly valued when more MSs roams in the network. For example, if 5 MSs exists in the network and follows the same movement indicated by Figure 3.14, HSS and HAAA would end up generating 180 keys (6360 Bytes) in Sc1 and 120 keys (5080 Bytes) in Sc2 while only 55 keys (1860 Bytes) 88  are necessary in Sc3 when nHHO is set to 5. This shows that our proposed protocols are capable of managing large number of MSs in the interworking architecture efficiently compared to the standard EAP-AKA protocol.  1.6  Key sizes (KByte)  Number of keys  40  30  20  1.2  0.8  0.4  10 1  2  3 4 Authentication steps Sc1  5  Sc2  6  Sc3, nHHO = 1  1  2  3 4 Authentication steps  Sc3, nHHO = 3  5  6  Sc3, nHHO = 5  Figure 3.24 Number and size of keys generated by MS on every authentication step  MS has limited processing capabilities that could affect key generation in terms of speed based on the size of the keys. The number and size of keys generated by MS in all four scenarios is listed in Table 3.4. Continuing a similar trend, MS generates less number of keys as the value of nHHO increases. Generally, a MS adopting Sc3 generates less number and size of keys compared to Sc1 when nHHO ≥ 3. Likewise, the number and size of keys generated by MS when adopting Sc3 is less than when adopting Sc2 when nHHO ≥ 5. Figure 3.24 illustrates the number and size of keys generated by MS for every authentication step in the 6-steps MS movement depicted in Figure 3.14. Since mod-EAP-AKA is invoked thrice when nHHO is set to 1 in Sc3, more key generations by MS are anticipated. 3.5.3 Selection of nWR and nHHO values The value of nWR and nHHO should be carefully chosen by the 3GHN; very high value might negatively affect security because of frequent reuse of keys while very low values might 89  negatively affect performance due to contacting 3GHN repeatedly for re-authentications and preauthentications. For stationary users, WLLR execution is instigated when LRK lifetime expires or when a timer held by MS and AP expires. The timer is set by the 3GHN [34]. The execution of mod-EAP-AKA is enforced when CWR > max(CWR) or when DRK lifetime expires. For roaming users, Intra/Inter-WLAN FP are instigated when the MS performs a HHO. nHHO selection depends on HOK lifetime, DHK lifetime, the average number of APs in the WLAN domain and the average amount of time a user stays within the coverage area of a single AP, also known as the MS resident time (Tr). The execution of mod-EAP-AKA is enforced when CHHO > max(CHHO) or when HOK lifetime expires. Two algorithms are developed to select nWR and nHHO. The algorithms are shown in Figure 3.25 and Figure 3.26, respectively.  Algorithm 3.1 Pseudocode for selecting nWR value { Variable declarations: } timer = re-authentication timer maintained by the MS and the AP [34]; LRK_lifetime = the lifetime of LRK; DRK_ lifetime = the lifetime of DRK; max_nWR = the maximum value that can be assigned to nWR; min_nWR = the minimum value that can be assigned to nWR; balanced_nWR = the suggested value of nWR for a balanced security and performance; performance_nWR = the suggested value of nWR for more performance over security; if timer ≤ LRK lifetime then max_nWR = DRK_lifetime / timer; else max_nWR = DRK_lifetime / LRK_lifetime; end if min_nWR = 1; balanced_nWR = (max_nWR + min_nWR) / 2 ; performance_nWR = (max_nWR + balanced_nWR) / 2; Figure 3.25 Algorithm for selecting a suitable nWR value  Two options for nWR and nHHO values are suggested: firstly, the balanced option, and secondly, the performance oriented option. The balanced option balances security and performance and it is recommended for visited WLAN networks that cannot be trusted by the 90  3GHN. This happens in situations where the WLAN is installed and operated by a third party. The performance oriented option favors performance over security by permitting more localized re-authentication and pre-authentications in the visited WLAN domain. This option is recommended for trusted visited WLAN networks, the ones that are installed and operated by the 3GPP operator.  Algorithm 3.2 Pseudocode for selecting nHHO value { Variable declarations: } DHK_lifetime = the lifetime of DHK; HOK_ lifetime = the lifetime of HOK; balanced_nHHO = the suggested value of nHHO for a balanced security and performance; performance_nHHO = the suggested value of nHHO for more performance over security; Tr = average MS resident time; N = average number of APs in the WLAN domain; max_ nHHO_intra = DHK_lifetime / Tr; min_ nHHO = 1; b_ nHHO_intra = (max_ nHHO_intra + min_ nHHO) / 2; p_ nHHO_intra = (max_ nHHO_intra + b_ nHHO_intra) / 2; max_ nHHO_inter = HOK_lifetime / N · Tr; b_ nHHO_inter = (max_ nHHO_inter + min_ nHHO) / 2; p_ nHHO_inter = (max_ nHHO_inter + b_ nHHO_inter) / 2; balanced_nHHO = b_ nHHO_intra + b_ nHHO_inter ; performance_nHHO = p_ nHHO_intra + p_ nHHO_inter ; Figure 3.26 Algorithm for selecting nHHO  As discussed earlier, the separation between HO keys (used in Intra/Inter-WLAN FP) and re-authentication keys (used in WLLR) is used to enforce service provider’s policies. For example, if the 3GPP service provider would like to limit the permitted number of Intra/InterWLAN FP execution without effecting WLLR execution because of the possibility that the MS could roam from a trusted WLAN network to a distrusted WLAN network, the 3GPP service provider could set a longer lifetime to DRK compared to HOK and DHK. Hence, a MS is permitted to perform more WLLR executions than Intra/Inter-WLAN executions because HOK/DHK lifetime and DRK lifetime have a direct affect on the selection of nHHO and nWR, 91  respectively, as shown in Figure 3.25 and Figure 3.26. Therefore, key separation and the capabilities to change key lifetimes gives the service provider more control to secure MS movement.  3.6 Security analysis Performance improvements to the authentication protocols should not compromise the security of the network. In this section we analyze the security of the proposed protocols in terms of supporting a secure key management scheme, mutual authentication service, integrity protection of exchanged messages and protection of transmitted identities.  3.6.1 Secure key management Keys must be held by the minimum possible number of nodes. Unnecessary distribution of keys must be avoided and keys must be unique to key holders. Additionally, keys must never be shared between nodes belonging to the same hierarchal level and keys used directly in protecting communication messages must not be reused. These measures are collectively known as the principle of least privilege, which prevents the “domino effect” problem [60] in key management protocols. HOK, DRK, DHK, LRK, LHK and EKWA-MS, IKWA-MS are analyzed to prove that they abide with the principle of least privilege. •  HOK is only generated by MS and HAAA. This is because EMSK and EAP-AKA session-ID used to generate HOK are only held by MS and HAAA. In addition, RAND and AUTN values used to generate the session-ID are only held by MS and HAAA. A new HOK is derived only in the event of mod-EAP-AKA execution.  •  DRK and DHK are only generated by MS and HAAA because no other nodes have access to MSK, HOK, and HN values used in the generation process. WAAA-ID and MSM are also used in generating these keys to aid in limiting the scope and uniqueness of the keys. These keys are only used by MS and WAAA it is communicating with and never shared between 92  different WAAA servers residing in different WLAN networks. To satisfy the principle of least privilege, DRK and DHK must be deleted from the HAAA’s database after delivering them to WAAA. •  LRK and LHK are only generated by MS and WAAA because no other nodes have access to DRK and DHK used in the generation process. Note that DRK and DHK are deleted from HAAA’s database after their delivery to WAAA. AP-ID and the MSM are also used in generating LRK and LHK; these values aid in limiting the scope and uniqueness of these keys. These keys are only used by MS and its associated AP and never shared between different APs in the WLAN domain and never re-used in future re-authentications and preauthentications. To satisfy the principle of least privilege, LRK and LHK must be deleted from WAAA’s database after delivery to AP.  •  EKWA-MS and IKWA-MS are only generated and used by MS and WAAA. This is because no other nodes holds DRK and DHK keys used in the generation process. Keys, nonces and counters are securely transmitted to protect against eavesdropping of  security-related information. No keys are transmitted in the WLAN link between MS and AP. The transport of DRK and DHK are protected by the LTSA between HAAA and WAAA. Likewise, the transport of LRK and LHK are protected by the LTSA between WAAA and AP. In addition, n parameters and nonces are encrypted during transmission with K-encr in mod-EAPAKA and Inter-WLAN FP while counters and WN are encrypted during transmission with EKWAMS  in WLLR and Intra-WLAN FP. All keys are freshly generated to defend against replay attacks. MSK, EMSK and HOK  are fresh because fresh RAND and AUTN are used to generate them. DRK and DHK are fresh because a fresh HN is used to generate them. Since DHK and DRK are fresh, EKWA-MS and IKWAMS  are believed to be fresh as well. Finally, LRK and LHK are fresh because fresh CWR and CHHO  are used to generate them, respectively. CWR and CHHO are continuously incremented on every 93  successful re-authentication and pre-authentication, respectively. In Intra-WLAN FP and InterWLAN FP, a new LHK is always derived after a HO operation. The newly derived LHK is only valid between the MS and the AP receiving the LHK. Compromising the LHK does not lead to a compromise in the communication between the MS and previously visited AP or future target AP. Therefore, Intra-WLAN FP and Inter-WLAN FP maintains forward and backward secrecy property.  3.6.2 Mutual authentication Full EAP-AKA (re-)authentication and fast EAP-AKA re-authentication achieve mutual authentication between MS and the 3GHN. WLLR and Intra/Inter-WLAN FP provides the same service to protect against MITM attacks, impersonation attacks and rogue AP attacks. In WLLR and Intra-WLAN FP, HAAA delegates the authentication operation to WAAA. The WAAA and MS mutually authenticate each other by proving the possession of correct WN, CWR, CHHO, EKWAMS  and IKWA-MS in addition to the reception of correct MAC values. MS verifies the legitimacy of WAAA by verifying the correctness of CWR, CHHO and  MAC received in the authentication challenge message. If the received counter is consistent with the counter stored in the MS's database, then EKWA-MS used to encrypt it is valid. Additionally, if the new MAC calculated by MS is identical to the received MAC, then MS is assured the legitimacy of WAAA. On the other hand, WAAA authenticates MS by receiving correct counters and MACs in the authentication response message. As explained previously, only a legitimate MS holds EKWA-MS and IKWA-MS; hence, receiving correct counters encrypted with EKWA-MS and correct MACs calculated with IKMS-WA authenticates MS. Formal verification of a security protocol is always required as a proof of its correctness and to confirm its security qualities. The security of the proposed protocols have been tested and confirmed using the “Automated Validation of Internet Security Protocols and Applications” 94  (AVISPA) package [16]. AVISPA is a state-of-the-art tool for the automatic verification and analysis of Internet security protocols. AVISPA is chosen to validate our proposed protocols for three reasons: firstly, it is widely used by researchers to validate authentication and secure HO protocols [79], [111], [112], [113], secondly, AVISPA integrates three automatic security analysis and verification back-end servers to test the protocol under examination, and thirdly, AVISPA library includes standard protocols such as EAP-AKA and 3GPP-AKA and the AVISPA team is working closely with IETF representatives to validate their protocols. AVISPA integrates back-end servers such as “On-the-Fly Model-Checker” (OFMC), “Constraint-Logicbased Attack Searcher” (Cl-AtSe) and SAT-based Model-Checker (SATMC). These servers perform different types of protocol verifications as well as protocols falsification techniques by trying to uncover possible attacks in the questioned protocol. Protocols under examination by AVISPA must be coded in the “High Level Protocol Specifications Language” (HLPSL) to be tested by the back-end servers. HLPSL is an expressive, role-based formal language used to describe the details of the protocols in question. Typically, HLPSL code includes the roles played by all the principals in the security protocol, like MS, WAAA and HAAA, as well as the role of the environment and the security goals that has to be achieved. AVISPA tool helped identifying an attack that existed in WLLR. Initially, CWR was sent in the clear, this flagged an authentication attack. With the help of the attack trace feature in AVISPA we were able to identify the origin of the attack and rectify WLLR by encrypting CWR during transmission. Figure 3.27 illustrates the role of WAAA in WLLR coded in HLPSL. The terms “request” and “witness” are used to test the support of secured mutual authentication between MS and WAAA. The statement (witness (S,P,wn1,WN’)) is used by MS to authenticate WAAA while the statement (request(S,P,wn2,WN)) is used by WAAA to authenticate MS. Figure 3.28 illustrates MS’s role in Inter-WLAN FP expressed in HLPSL. To permit testing the confidentiality of LHK, the term “secret” is used. The statement 95  (secret(LHOK’,lhok1,{P,WAAA2,AP2}) in Figure 3.28 indicates the requirement to keep LHK confidential to MS, TWAAA and TAP. Only authentication and secrecy goals are supported by AVISPA. The support of secured mutual authentication in addition to the secrecy of keys in WLLR and Intra/Inter-WLAN FP have been tested using OFMC, Cl-AtSe and four SAT solvers in SATMC. All tests show positive results and confirm the provision of mutual authentication service and no authentication attacks were found. Results also confirmed the secrecy of LRK and LHK and no vulnerabilities were discovered. AVISPA is capable of verifying the support of mutual authentication and key secrecy properties. Other security requirements presented in Section 2.3 and are non-verifiable by AVISPA such as key distribution, key freshness and forward/backward secrecy are discussed in Section 3.6.1 whereas privacy protection is discussed in Section 3.6.4. A stand-alone graphical version of the AVISPA package was used in testing our protocols named Security Protocol ANimator for AVISPA (SPAN). Figure 3.29-(a) demonstrates the messages returned by SPAN after testing WLLR by the OFMC verification tool. As shown in the figure, the proposed WLLR protocol is safe to use and no attacks were found. Figure 3.29-(b) demonstrates the messages returned by SPAN as a result of testing InterWLAN FP by Cl-AtSe. Figure 3.30 shows results of testing Intra-WLAN FP with zchaff SAT solver in SATMC. The AVISPA Web Interface was used in SATMC testing because of problems running SATMC in the stand-alone version. Output text was rearranged to fit in a single screen.  96  role server ( P,S,A : agent, %peer, server, access point F1 : hash_func, %key generation PRF HMAC : hash_func, KPS : symmetric_key, %server <-> peer KAS : symmetric_key, %server <-> access point CN : text, %Counter A_id : text, %AP_ID SND_AS,RCV_AS : channel (dy)) played_by S def= local WN : text, %W_Nonce CNE : {text}_symmetric_key, NAI : text, %WLAN UE ID MAC1 : hash(symmetric_key.text.text), MAC2 : hash(symmetric_key.text.text), LRK : hash(symmetric_key.text.text.text), State : nat const request_id, respond_id, success : text, lrk3, wn1, wn2 : protocol_id init State := 2 transition 1. State = 2 /\ RCV_AS(respond_id.NAI') =|> State' := 5 /\ WN' := new() /\ MAC1' := HMAC(KPS.WN'.CN) /\ SND_AS(WN'.MAC1'.CNE') /\ witness (S,P,wn1,WN') 2. State = 5 /\ RCV_AS(CNE'.MAC2') /\ MAC2'= HMAC(KPS.WN.CN) =|> State' := 8 /\ LRK' := F1(KPS.CN.NAI.A_id) /\ request(S,P,wn2,WN) /\ SND_AS(success.{LRK'}_KAS) /\ secret(LRK',lrk3,{P,S,A}) end role Figure 3.27 HLPSL code describing the role of WAAA server in WLLR  97  role peer ( P,WAAA1,WAAA2,AP1,AP2,HAAA : agent,%MS, WAAA servers, APs and HAAA F1,HMAC : hash_func, %MAC generation and key generation functions KPH : symmetric_key, % shared key between MS and HAAA HOK,MSK : symmetric_key, HN,MN : text, % HAAA nonce and MS nonce WAAA2_ID,AP2_ID : text, % WAAA2 AND AP2 identities SND_AP1P,RCV_AP1P : channel (dy)) played_by P def= local NMN,NHN,WCN,INTER_ID : text,% New MN, New HN, WLAN Counter, MS Identity WCNE : {text}_symmetric_key, DHK,LHK : hash(symmetric_key.text.text.text), MAC1_INTER : hash(symmetric_key.text.text) MAC2_INTER : hash(symmetric_key.text.text.text.text), State : nat const request_id,respond_id,success : text, lhk1, nhn1, nhn2 : protocol_id init State := 1 transition 1. State = 1 /\ RCV_AP1P(request_id) =|> State' := 5 /\ INTER_ID' := new() /\ SND_AP1P(respond_id.INTER_ID') 2. State = 5 /\ RCV_AP1P({NHN'}_KPH.MAC1_INTER') /\ MAC1_INTER' =HMAC(KPH.MN.NHN') =|> State' := 9 /\ NMN' := new() /\ MAC2_INTER' := HMAC(KPH.NMN'.NHN'.HN.WCN) /\ WCNE' := {WCN}_KPH /\ SND_AP1P(WCNE'.{NMN'}_KPH.MAC2_INTER') /\ request(P,HAAA,nhn1,NHN') /\ witness (P,HAAA,nhn2,NHN') 3. State = 9 /\ RCV_AP1P(success) =|> State' := 13 /\ DHK' := F1(HOK.NHN.WAAA2_ID.INTER_ID) /\ LHK' := F1(DHK.WCN.AP2_ID.INTER_ID) /\ secret(LHK',lhk1,{P,WAAA2,AP2}) % to assure %secrecy of %LHK between MS, %TWAAA and TAP end role Figure 3.28 HLPSL code describing the role of the MS in Inter-WLAN FP  98  (a)  (b)  Figure. 3.29 Output message returned by SPAN after testing (a) WLLR by OFMC and (b) Inter-WLAN FP by CL-ATSE  Figure 3.30 Output message returned by the AVISPA web interface after testing Intra-WLAN FP by SATMC  99  3.6.3 Protection of message integrity The integrity of authentication messages is protected by appending a Message Authentication Code (MAC). MAC serves two purposes: firstly, it preserves the integrity of the EAP authentication challenge/response messages, and secondly, it provides sender authentication. The MAC covers important authentication-related parameters that are not necessarily included in the EAP message. For example, MAC1Inter initially calculated by HAAA and included in EAP Request/AKA-challenge covers MNi – 1 although the nonce is not appended to the EAP message. MACs are calculated using K-auth in mod-EAP-AKA and Inter-WLAN FP. In WLLR and Intra-WLAN FP, MACs are calculated using IKWA-MS.  3.6.4 Protection of identities It is always desirable to conceal the identity of MS, TAP and TWAAA to protect against eavesdropping and tracking of MS’s movement. In our proposed protocols, the permanent ID (MS-ID) is supplied only once during the first mod-EAP-AKA invocation. A temporary local ID (TL-ID) is generated on every successful re-authentications and pre-authentications by MS and WAAA and used instead of the permanent ID. Local IDs are used as pointers to the permanent ID in the WLAN domain to protect against tracking the movement of the MS. Every local ID is a one-time identifier valid for a single authentication session. Therefore, MS and WAAA must derive a new local ID using (3.7) following a successful mod-EAP-AKA, WLLR and Intra/InterWLAN execution. WAAA maps the temporary IDs to MS’s permanent ID. In case of temporal identities desynchronization, WAAA reverts to MS’s permanent ID and instructs the MS to perform mod-EAP-AKA instead. In EAP-AKA, the HAAA must generate a special reauthentication ID to enable the invocation of future fast EAP-AKA re-authentication. Comparing to our proposed protocols, HAAA is absolved from generating and handling the temporary IDs.  100  Temporary IDs supplied by MS and received by WAAA in WLLR and Intra/InterWLAN FP are not encrypted during transmission because the identity of the MS must be known to WAAA to extract the proper decryption key. This clear text transmission does not form a threat since the transmitted temporary ID is not going to be reused in the future. TWAAA-ID and TAP-ID are encrypted with EKWA-MS when transmitted by MS to WAAA to defend against rogue AP attacks as well as to prevent tracking MS’s movement.  3.7 Summary Novel localized authentication protocols have been presented in this Chapter to speed the authentication procedure for both stationary and roaming users. To enable a proper execution of the proposed protocols, modifications to the standard EAP-AKA are introduced. The execution of the modified EAP-AKA protocol is a strict prerequisite for efficient execution of the proposed localized protocols. WLLR is designed to be locally executed in the WLAN domain to reduce reauthentication delays and the cost of authentication signaling when the user is stationary. The combination of mod-EAP-AKA along with WLLR proved to surpass the standard full EAPAKA (re-)authentication and fast EAP-AKA re-authentication protocols. They drastically reduce authentication delays, authentication signaling cost and the number and size of keys generated by all nodes involved in the authentication procedure. Intra and Inter-WLAN fast pre-authentication protocols have been introduced in this Chapter as well to minimize the total HHO delay during Intra and Inter WLAN HHOs in the 3GPP-WLAN interworking architecture. The proposed Intra and Inter-WLAN pre-authentication protocols aim to minimize authentication-related delay by pre-authenticating the MS prior to performing a HHO. The proposed protocols outperform the standard EAP-AKA protocols in terms of authentication signaling cost, authentication delay and the number and size of keys generated during the HO procedure. 101  The advantage of our proposed protocols is clearly envisioned when more WLLR and Intra-WLAN FP executions are permitted to take place, hence eliminating the need to contact the 3GHN on every authentication. The proposed protocols achieve important security goals like the support of a secured key management scheme, the support of a strict mutual authentication service, the provision of message integrity and the protection of identities generated during the authentication procedure. The securities of the proposed protocols have been verified by the AVISPA package. Examination of our protocols by AVISPA demonstrated their resistance to authentication attacks and confirmed the secrecy of the generated keys.  102  Chapter  4:  Performance-enhanced  and  secured  horizontal  handovers in the 3GPP-WiMAX interworking architecture∗ 4.1 Introduction Designing efficient WiMAX HHO procedures in the 3GPP-WiMAX interworking architecture is a challenging problem. HOs must be instantaneous and secure at the same time. INEA is first performed by the MS when connecting to a WiMAX BS as described in the IEEE 802.16e standard [5], [15]. EAP-AKA is executed during INEA to achieve mutual authentication between MS and HSS/HAAA residing in the 3GHN [10]. The standard intra and inter ASN-GW HOs involve the execution of INEA, hence are susceptible to high delays and costly signaling overhead [5], [15]. These shortcomings may degrade the QoS experienced by applications running on the MS and possibly cause user inconvenience or annoyance. Optional, performanceimproved HO techniques are also described in [5] and [15], which aid in improving intra and inter ASN-GW HOs. Such performance improvements are realized by omitting the authentication procedure during HOs, which could have an adverse effect in reducing system security. The authors in [55], [64] and [133] attempted to shorten the authentication activity during a HO to minimize the total HO delay. However, the proposal in [55] introduced additional communication and computation overhead as a consequence of extensive key generation and distribution to target BSs. In [64], the authors based their solution on the existence of a PKI and the execution of EAP-TLS. Although caching and reusing keys improves the performance as shown in [133], this approach degrades the level of security. We propose performance enhancements to the standard intra and inter ASN-GW HO protocols to curtail the mutual authentication delay between MS and HSS/HAAA without ∗  Parts of this Chapter have been accepted for publication in ACM/Springer Wireless Networks on January 2010 [103].  103  compromising the security of the interworking architecture [103]. We utilize unused keys derived in initial authentication between MS and HSS/HAAA to derive new HO-related keys. These keys are used in future HOs to provide authentication without contacting HSS/HAAA. We exploit HO control messages exchanged between MS, serving network and target network to transport authentication queries in addition to HO queries. As a consequence, mutual preauthentication is performed between MS and target BS prior to the start of direct communications between them, which yields a significant reduction in HO delay, HO signaling traffic and conserves network resources compared to the standard HO protocols in [5], [15]. Additionally, our proposed protocols meet essential HO security requirements and pass security examinations conducted using the AVISPA [16] security analyzer. To the best of our knowledge, our solution is the first proposal in the literature to address efficient and secure HHOs in the context of 3GPP-WiMAX interworking architecture. The remainder of this Chapter is organized as follows. In Section 4.2, we describe essential security requirements that must be maintained during a WiMAX HHO in the 3GPPWiMAX interworking architecture. In Section 4.3, we describe our proposed HO protocols. Sections 4.4 and 4.5, respectively, evaluate the performance of our proposed protocols against the standard protocols and present numerical results. Section 4.6 presents security analyses of our proposed protocols. Section 4.7 summarizes the Chapter.  4.2 Security requirements for WiMAX horizontal handover protocols in the 3GPP-WiMAX interworking architecture Intra ASN HO is performed when the serving and the target BSs are controlled by the same ASN-GW. This is also known as R6 Handover (R6HO) [15]. Inter ASN HO is performed when the serving and the target BSs are controlled by different ASN-GWs. This type of HO is also known as R3 Handover (R3HO) [15]. Standard R6HO and R3HO protocols involve the 104  execution of INEA. The MS invokes full EAP-AKA authentication as part of INEA when it first communicates with a WiMAX BS. EAP messages exchanged between MS and BS are encapsulated in PMKv2-REQ/RSP-EAP_Transfer messages whereas EAP messages exchanged between BS and ASN-GW are encapsulated in AuthRelay_EAP_Transfer messages. EAP messages exchanged between ASN-GW, PAAA and HAAA are carried via an AAA protocol like Radius or Diameter. At the completion of EAP-AKA, HAAA and MS derive MSK and EMSK. MSK is forwarded to ASN-GW by HAAA as shown in Figure 2.10, but EMSK is not used. MS and ASN-GW derive PMK and AK from MSK using (2.3) and (2.4), respectively. Afterwards, ASNGW forwards AK to BS. MS and BS validate the freshness of AK by executing the 3-way handshake protocol (3WHS) [5]. AK is used to secure the communications between target BS (TBS) and MS. EAP-AKA key hierarchy in the 3GPP-WiMAX interworking architecture is depicted in Figure 2.11. HHO operations in 3GPP-WiMAX must be prompt and secure. Some of the important security requirements that must be maintained during a HO are [60], [104], [105]: •  S1-Mutual Authentication  •  S2-Forward and backward secrecy  •  S3-Key scope and distribution  •  S4-Key freshness  •  S5-Privacy protection IEEE 802.16e [5] introduced mandatory and optional HO types. Hard HO is a mandatory  HO type while the Macro Diversity set HO (MDHO) and the Fast Base Station Switching (FBSS) are optional HO types. MDHO and FBSS do not satisfy security requirements S1 – S4, introduce additional traffic in the network and require more complex hardware [55], [56], [57]. Due to these problems, we are only considering hard HOs in this Chapter. The standard default 105  hard HO protocol meets security requirements S1 – S4 only but performs poorly due to the invocation of EAP-AKA during HO. A HO activity comprises of two phases, HO preparation phase and HO action phase. In the preparation phase, MS instigates a HO by sending MOB-MSHO_REQ message to Serving BS (SBS). The SBS, ASN-GW and Target BS (TBS) communicate the HO request by exchanging R6 HO_Req/HO_Rsp message. R4 HO_Req/HO_Rep is additionally exchanged between serving ASN-GW (S-ASN-GW) and target ASN-GW (T-ASN-GW) in the case of R3HO. The standard default R6HO and R3HO are shown in Figure 4.1 and Figure 4.2, respectively.  Figure 4.1 Standard default R6HO (HOB = 00)  In the action phase, MS confirms the HO by sending MOB-HO_IND message to SBS and performs ranging and negotiates security capabilities with TBS by exchanging RNG REQ/RSP messages and SBC REQ/RSP messages, respectively. Subsequently, MS executes INEA. This involves executing EAP-AKA to assure mutual authentication with HSS/HAAA. This authentication activity might introduce significant delays and inject additional signaling to the 106  network and might affect the quality of real-time applications running on MS [55], [58], [59]. Optional, performance-improved HHO protocols were also suggested in [5] and [15]. TBS could set bits number 1 and 2 in the “HO Process Optimization” field in the “Ho_Rsp” message to indicate its approval for the execution of an accelerated HO. When HO Optimization Bits (HOB) are not set, i.e., HOB = 00, R6HO and R3HO are executed normally without performance optimization as shown in Figure 4.1 and Figure 4.2. When HOB are set to 10, EAP-AKA is omitted. When HOB are set to 11, EAP-AKA and 3WHS protocols are omitted.  Figure 4.2 Standard default R3HO (HOB = 00)  Omitting EAP-AKA and 3WHS improves performance significantly. Nonetheless, it leads to two critical security flaws: firstly, the absence of a fresh round of mutual authentication procedure during a HO as required by security requirement S1, and secondly, the adoption of a weak key management scheme, which results in not fulfilling security requirements S2, S3 and S4. When HOB are set to 10, TBS requests a new AK from S-ASN-GW. Figure 4.3 depicts the standard optional R6HO with HOB = 10 and Figure 4.4 depicts the standard optional R3HO with HOB = 10. 107  As an example of the weak key management in R6HO/R3HO with HOB = 10 or 11, the only changeable parameter in deriving a new AK as shown in (2.4) in Chapter 2, is the BS-ID. However, the BS-ID can be easily eavesdropped by attackers and it is a common practice for BSs to share the same BS-ID [60]. Thus, the new AK could be identical to the old AK or easily derived by adversaries, which contravenes with security requirements S2 and S4. Additionally, PMK is not bound to a particular ASN-GW; hence PMK context and intended usage is not well defined. Compromising the PMK enables an adversary to launch “false base station” attacks on legitimate MSs during R3HO [61], thus breaching S3.  Figure 4.3 Standard optional R6HO (HOB = 10)  108  Figure 4.4 Standard optional R3HO (HOB = 10)  Unlike the solution in [64], our proposed protocols abide by WiMAX Forum recommendations [10] and are based on EAP-AKA, thus, they are backward compatible with the standard INEA protocol. Our protocols introduce less signaling overhead, reduce delay and satisfy security requirements S1 – S5 differently from the schemes in [55] and [133]. They exhibit similar security strength as R6HO/R3HO with HOB = 00 while achieving comparable performance results to the less secure R6HO/R3HO with HOB = 10 or 11.  4.3 Proposed handover protocols In the 3GPP-WiMAX interworking architecture, the performance of the standard HO protocols with HOB = 00 is unacceptable although it achieves security requirements S1 – S4. On the other hand, performing a HO with HOB = 10 or 11 improves performance but introduces serious security risks. We propose HO protocols that achieve both tight security and improved performance. In our proposed protocols, authentication challenges and replies are piggybacked on the HO control messages to slash HO delay and signaling. Two HO protocols are proposed, 109  R6 Handover Pre-authentication (R6HP) and R3 Handover Pre-authentication (R3HP). A general assumption shared between our proposed protocols and the standard HO protocols in [5] and [15] is that the 3GHN, WiMAX CSN and WiMAX ASN fully trust each other [10]. A list of symbols used in describing the proposed protocols is shown in Table 4.1. Table 4.1 List of symbols used in describing our proposed protocols Type  PAK  MS, HAAA  MS, PAAA  Size (byte) 32  PHK  MS, HAAA  MS, PAAA  32  PAAA Handover Key  AAK  MS, PAAA  MS, ASN-GW  64  ASN-level Authentication Key  AHK  MS, PAAA  MS, ASN-GW  64  ASN-level Handover Key  PMK  MS, ASN-GW  MS, ASN-GW  20  Pairwise Master Key (Auth.)  PMKH  MS, ASN-GW  MS, ASN-GW  20  Pairwise Master Key (Handover)  AK  MS, ASN-GW  MS, BS  20  Authorization Key (Auth.)  AKH  MS, ASN-GW  MS, TBS  20  Authorization Key (Handover)  KAS-MS  MS, ASN-GW  MS, ASN-GW  32  MS and ASN-GW Secret Key  Value  Keys  Auth. Challenge n values  Nonces  Counters Identities  Derived by  Held by  Notes PAAA Authentication Key  nR6H  HAAA  MS, ASN-GW  1  Tickets used to provide mutual authentication between the MS and the PAAA Permitted number of R6 HOs  nR3H  HAAA  MS, PAAA  1  Permitted number of R3 HOs  HN  HAAA  MS, PAAA  16  Nonce generated by HAAA  AN  ASN-GW  MS, ASN-GW  16  Nonce generated by ASN-GW  MN  MS  MS, PAAA  16  Nonce generated by MS  CR6H  -  MS, ASN-GW  4  R6 HO counter. Set by nR6H  CR3H  -  MS, PAAA  4  R3 HO counter. Set by nR3H  MS, ASN-GW  16  Identity used in R6HP  MS, PAAA  16  Identity used in R3HP  TicketMS  MS, PAAA  MS, PAAA  16  TicketPA  MS, PAAA  MS, PAAA  16  R6-ID  MS, ASN-GW  R3-ID  MS, PAAA  To enable the execution of R6HP and R3HP, INEA performed initially by a MS entering the interworking architecture has to be slightly modified as shown in Figure 4.5. The modified INEA (mod-INEA) protocol differs from the standard INEA protocol in the following. 1- After retrieving AV from HSS, HAAA derives three new keys. They are: PAAA Authentication Key (PAK) derived from MSK, HO root key (HOK) derived from EMSK and  110  PAAA HO Key (PHK) derived from HOK. HOK is derived using (3.2) described in Chapter 3 using the Dot16KDF key derivation function. The other keys are derived as follows. PAK = Dot16KDF(MSK, HNi | PAAA-ID | MSM | “PAK”, 256)  (4.1)  PHK = Dot16KDF(HOK, HNi | PAAA-ID | MSM | “PHK”, 256)  (4.2)  In the above equations, HNi is a nonce generated by HAAA, PAAA-ID is the identity of the PAAA and ASN-ID is the identity of ASN-GW. Since EAP-AKA specifications [8] do not specify the usage of EMSK, it is used here to derive HO-related keys. PAK is used in deriving other keys required in R6HP and R3HP. It could also be utilized to support fast reauthentications for stationary users. 2- HAAA generates and sends nR6H, nR3H, nVHO, nPAR, HNi, and HO-IDi to MS in an EAP Request/AKA-challenge message. nR6H and nR3H indicate the permitted number of R6HP and R3HP executions, respectively. nVHO, nPAR and HO-IDi are used when MS performs a VHO. Thus their usage is not discussed in this Chapter. 3- MS receives n parameters and HNi and derives HOK, PAK and PHK. MS generates a fresh nonce, MNi and includes it in the EAP Response/AKA-challenge message. 4- When EAP-AKA completes successfully, HAAA forwards HNi, MNi, PAK, PHK, MS-ID, nR6H, nR3H, nPAR, nLR and max(CVHO) to PAAA. 5- MS and PAAA adjust the maximum value the R3HP counter max(CR3H) can reach according to nR3H. The R3HP counter (CR3H) is incremented following a successful R3HP execution. The execution of mod-INEA is enforced when CR3H > max(CR3H). Thus, if CR3H = 2 and nR3H = 4, max(CR3H) should be set to 5. PAAA and MS derive ASN Authentication Key (AAK) from PAK and ASN HO Key (AHK) from PHK. Next, PAAA forwards AAK, AHK, MS-ID, nR6H, nLR and max(CVHO) to ASN-GW. AAK = Dot16KDF(PAK, CR3H | CPAR | ASN-ID | MSM |“AAK”, 512)  (4.3)  AHK = Dot16KDF(PHK, CR3H | CPAR | ASN-ID | MSM |“AHK”, 512)  (4.4) 111  6- ASN-GW and MS adjusts the maximum value the R6HP counter max(CR6H) can reach according to nR6H. The R6HP counter (CR6H) is incremented after mod-INEA and continues to be incremented after each successful R6HP and R3HP execution. Thus, if CR6H = 1 and nR6H = 3, max(CR6H) should be set to 4. MS and ASN-GW modify the derivation of PMK shown in (2.3) in Chapter 2 to be as follows. PMK = Dot16KDF(AAK, ASN-ID | MSM |“PMK”, 160)  (4.5)  AK = Dot16KDF(PMK, BS-ID | MSM |“AK”, 160)  (4.6)  7- MS and PAAA generate R3-ID to be used in future R3HP invocations. Additionally, MS and ASN-GW generate a key to secure their communications (KAS-MS) and R6-ID to be used in future R6HP invocations. R3-ID, KAS-MS and R6-ID are derived as follows. R3-ID = Hash(PHK | CR3H | PAAA-ID | MS-ID)  (4.7)  KAS-MS = Dot16KDF(AAK ⊕ AHK, ASN-ID| MSM |“K”,256)  (4.8)  R6-ID = Hash(KAS-MS| CR6H | ASN-ID | MS-ID)  (4.9)  Figure 4.5 Modified INEA (mod-INEA) protocol  112  A new R3-ID is derived by MS and PAAA after each successful mod-INEA and R3HP execution. A new R6-ID is derived by MS and ASN-GW after the successful execution of modINEA, R3HP and R6HP. Future derivation of R3-IDi is performed by substituting MS-ID with R3-IDi  – 1.  Derivation of R6-IDi is performed by substituting MS-ID with R6-IDi  – 1  in future  R6HP executions. R6-IDi derivation in the event of R3HP execution is performed as indicated in (4.9). Table 4.2 New TLV for R6HP and R3HP HO Type  Top TLV  Sub TLV  Notes  R6-IDi – 1 R6 HO and R3 HO  Prelude  R3-IDi – 1  Included in MOB_MSHO-REQ, R6 and R4 HO_Req  TicketMS  R6 HO  R6HO Preauthentication Request R6HO Preauthentication Response  ASN Nonce (AN)  Included in R6 HO_Rsp and MOB_BSHO-RSP  R6MAC1 R6MAC2  Included in MOB_HO-IND and R6 HO_Cnf  TicketPA R3 HO  R3HO Preauthentication Request  ASN Nonce (AN)  Included in R6 and R4 HO_Rsp and MOB_BSHO-RSP  R3MAC1 R3HO Preauthentication Response  R3MAC2  Included in MOB_HO-IND and R6 and R4 HO_Cnf  Mod-INEA extends EAP-AKA key hierarchy and provides total separation of authentication only keys, i.e., without HO, and HO-related keys. Authentication keys are derived from MSK and used in mod-INEA only. HO keys are derived from EMSK and used in R6HP and R3HP. Key separation offers the service provider more control to enforce service policies by setting different key lifetimes. In R6HP and R3HP, authentication challenges and replies are piggybacked on HO control messages. Since setting HOB to 01 is not used in [5] and [15], we propose setting it by TBS to signify the invocation of our proposed protocols. As per [15], HO control messages could accept additional Type, Length and Value (TLV) attributes on its trail. 113  Thus, new TLV attributes are defined to append authentication challenges and replies to HO control messages, the new TLVs are detailed in Table 4.2.  4.3.1 R6 handover pre-authentication protocol (R6HP) When TBS is controlled by the same ASN-GW as SBS, R6HO is performed. Since all TBSs fully trust ASN-GW, the latter engages in mutual authentication with MS on behalf of TBS. In R6HP, pre-authentication exchange is piggybacked on HO control messages between MS and ASN-GW. MS does not know whether TBS is controlled by the same ASN-GW, and thus, when requesting a HO, MS appends R6-IDi – 1, R3-IDi – 1 and TicketMS to the MOB_MSHOREQ message as a “Prelude” attribute and forward it to SBS. TicketMS derivation is shown below. TicketMS = Dot16KDF(PAK ⊕ PHK, HNi | CR3H | PAAA-ID | MSM |“TKTMS”,128)  (4.10)  When SBS receives this message, it appends the “Prelude” attribute to R6 HO_Req message it sends to ASN-GW. Figure 4.6 depicts the operation of R6HP.  Figure 4.6 R6 handover pre-authentication (HOB = 01)  114  ASN-GW extracts TBS-ID from R6 HO_Req message. If the TBS is within the jurisdiction of the ASN-GW, the latter relays R6 HO_Req message to the former. If TBS is controlled by another ASN-GW, R4 HO_Req message is sent to the target ASN-GW to start R3HP. TBS sets HOB to 01 to signal the start of R6HP invocation and replies to the HO request with R6 HO_Rsp message. ASN-GW validates the received R6-IDi  – 1  and checks if CR6H ≤  max(CR6H). If the verifications are positive, ASN-GW prepares a pre-authentication challenge and inserts it in the R6 HO_Rsp message as “R6HO Pre-authentication Request” attribute. The challenge includes a fresh nonce, AN, as well as a message authentication code (R6MAC1) to preserve the integrity of the message and insure the authenticity of ASN-GW. R6MAC1 is calculated with KAS-MS. R6MAC1 = HMAC(KAS-MS, R6-IDi – 1 | AN | CR6H)  (4.11)  When receiving the pre-authentication request, MS consults the CR6H value stored in its database and calculates R6MAC1 using (4.11). If the calculated R6MAC1 is identical to the received R6MAC1*, MS is assured that the ASN-GW is legitimate. Hence, it calculates R6MAC2 and includes it as “R6 HO Pre-authentication Response” attribute in the MOB_HO-IND message to ASN-GW. This attribute is appended to R6 HO_Cnf message sent by SBS to ASN-GW. Moreover, MS derives a new PMKH, derives a new AKH, generates a new R6-IDi using (4.9) by substituting MS-ID with R6-IDi – 1 and increments CR6H. R6MAC2 = HMAC(KAS-MS, AN+1 | CR6H)  (4.12)  PMKH = Dot16KDF(AHK, CR6H | ASN-ID | MSM |“PMK”, 160)  (4.13)  AKH = Dot16KDF(PMKH, CR6H | BS-ID | MSM |“AK”, 160)  (4.14)  After receiving the pre-authentication response, ASN-GW consults its copy of CR6H and calculates R6MAC2 using (4.12). If the computed R6MAC2 matches the received R6MAC2*, ASN-GW is assured that MS is legitimate. ASN-GW derives a new PMKH and AKH using (4.13) and (4.14), respectively, generates a new R6-IDi using (4.9) by substituting MS-ID with R6-IDi – 1 115  and increments CR6H. Finally, ASN-GW forwards AKH to TBS. A flow chart describing the operation of ASN-GW in R6HP is shown in Figure 4.7.  Figure 4.7 A flow chart describing ASN-GW’s operation in R6HP protocol  4.3.2 R3 handover pre-authentication protocol (R3HP) R3HO is performed when SBS and TBS are administered by different ASN-GWs. Due to the trust agreement established between TBS, T-ASN-GW and PAAA, the latter engages in mutual authentication with MS on behalf of TBS. Similar to R6HP, our proposed R3HP piggybacks authentication challenges and replies on HO control messages to improve the HO’s performance. Because MS is not aware of the ASN-GW controlling TBS, it supplies R6-IDi – 1, R3-IDi  – 1  and TicketMS to SBS as a “Prelude” attribute in MOB_MSHO-REQ message. SBS  relays this message to Serving ASN-GW (S-ASN-GW) by appending the “Prelude” attribute to R6 HO_Req message. S-ASN-GW identifies that TBS is controlled by a remote ASN-GW from TBS-ID and sends R4 HO_Req message to T-ASN-GW, the message only includes R3-IDi – 1 and TicketMS. Upon receiving R4 HO_Req message, T-ASN-GW dispatches R6 HO_Req message to TBS as shown in Figure 4.8. TBS sets HOB to 01 to signal the start of R3HP. The protocol proceeds as follows: 116  1- T-ASN-GW sends Radius Access-Request messages [26] to PAAA with “User Name” and “User Password” attributes. The attributes and their contents are shown in Table 4.3. PAAA verifies the validity of R3-IDi – 1 and verifies that CR3H ≤ max(CR3H). PAAA also calculates TicketMS using (4.10). If a match is found between the received TicketMS* and the calculated TicketMS, PAAA believes that MS is legitimate and calculates a TicketPA. In addition, it increments CR3H and derives a new AAK and AHK using (4.3) and (4.4). TicketPA = Dot16KDF(PAK ⊕ PHK, MNi | CR3H | PAAA-ID | MSM | “TKTPA”, 128) 2- PAAA generates a new R3-IDi using (4.7) but substitutes MS-ID with R3-IDi  (4.15) – 1.  Next,  PAAA dispatches a Radius Access-Accept message [26] to T-ASN-GW that includes TicketPA, AHK, AAK and nR6H in “MS-MPPE-Rec-Key” [8] attribute; this is also shown in Table 4.3. Table 4.3 Radius messages and attributes used in R3HP RADIUS Message Access-Request  Attribute (TLV)  Value  Notes  User Name [26]  R3IDi – 1  User Password [26]  TicketMS  TicketMS is used by the PAAA to authenticate the MS  TicketPA Access-Accept MS-MPPE-Recv-Key [8]  AAK AHK  TicketPA is used by the MS to authenticate the PAAA.  nR6H  3- After receiving Radius Access-Accept message, T-ASN-GW initializes CR6H, adjusts max(CR6H) according to nR6H, derives a new KAS-MS using (4.8) and prepares the “R3 HO Preauthentication Request” attribute. This attribute includes TicketPA, a fresh nonce, AN, and a message authentication code, R3MAC1. The attribute is appended to R4 HO_Rsp message and it is sent to S-ASN-GW. R3MAC1 = HMAC(KAS-MS, AN | CR6H | TicketPA)  (4.16)  117  4- The “R3 HO Pre-authentication Request” attribute is appended to R4 HO_RSP, R6 HO_RSP and MOB_BSHO-RSP to finally reach the MS as shown in Figure 4.8.  Figure 4.8 R3 handover pre-authentication (HOB = 01)  5- Upon receiving the pre-authentication request, MS calculates TicketPA and compares it with TicketPA* received in the pre-authentication request. If the Tickets are identical, it initializes CR6H and adjusts max(CR6H) according to nR6H received in the last mod-INEA. Furthermore, MS increments CR3H and derives a new AAK, AHK and KAS-MS using (4.3), (4.4) and (4.8), respectively. Furthermore, it calculates R3MAC1 using (4.16) and compares it with R3MAC1* received in the pre-authentication request. If a match is found, MS calculates R3MAC2 and generates a new R3-IDi using (4.7) but it substitutes MS-ID with R3-IDi – 1. MS also derives a new PMKH using (4.13), a new AKH using (4.14), generates a new R6-IDi using (4.9) and increments CR6H. R3MAC2 is included in the “R3 HO Pre-authentication Response” attribute as indicated in Table. 4.2. R3MAC2 = HMAC(KMS-AS, AN+1 | CR6H | TicketMS)  (4.17)  118  6- The pre-authentication reply is received by T-ASN-GW in R4 HO_Cnf message. T-ASNGW calculates R3MAC2 using (4.17) and compares it with the received R3MAC2*. If no discrepancies are found, PMKH and AKH are derived using (4.13) and (4.14). Additionally, TASN-GW generates a new R6-IDi using (4.9) and increments CR6H. Finally, AKH is forwarded to TBS. Figure 4.9 shows a flow chart describing MS’s operation in R3HP.  Figure 4.9 A flow chart describing MS’s operation in R3HP protocol  4.4 Performance evaluation In this section, the performances of our proposed HO protocols are compared against the standard HO protocols [5], [15] when HOB are set to 00 and 10. Performance is compared in terms of HO signaling, HO delay and the number and size of keys generated during a HO. The network model is first described.  4.4.1 Network model and handover scenarios The network consists of multiple hexagonal-shaped cells. A single cell represents the coverage area of a single WiMAX BS. We define an “ASN Domain” to represent a group of WiMAX BSs controlled by a single ASN-GW. Thus, the MS performs R6HO when roaming 119  within the ASN domain and R3HO is performed when the MS crosses the boundary of an ASN domain. For the sake of simplicity, we assume that all ASN-GWs are controlled by a single PAAA. Let B denotes the number of BSs in the ASN domain and R symbolizes a virtual ring in the cellular structure that outlines the border of the ASN domain as shown in Figure 4.10.  Figure 4.10 Network structure  A single BS forms the ASN domain when R = 1. When R = 2, 7 BSs exist in the ASN domain. Generally, B is calculated as follows.  B=  R  ∑ 6 ⋅ ( n − 1) + 1 = 3 ⋅ R ⋅ (R − 1) + 1  (4.18)  n =1  The area of a single cell, A(Cell), is 1.5 ⋅ 3 a 2 , where a is the length of a side of the hexagon. The perimeter of a single cell, L(Cell), is 6 · a. Therefore, the area of an ASN domain, A(ASN) is.  A( ASN ) = 1.5 ⋅ 3 ⋅ a 2 ⋅ (3 ⋅ R ⋅ (R − 1) + 1)  (4.19)  And the perimeter of an ASN domain, L(ASN) is. L( ASN ) = 6a (2 R − 1)  (4.20)  The fluid flow mobility model [106], [107], [108], [109] is used to determine HO rates. In this mobility model, the HO rate of n users residing in a cell and moving in an average velocity v in a uniformly distributed direction over [0, 2π] is found as follows.  120  HO Rate =  n⋅ v ⋅L π⋅A  (4.21)  Based on this model, R6HO rate and R3HO rate, r6H and r3H, respectively, are found as follows.  r 6H =  n⋅ v ⋅ L(Cell ) ⋅B π ⋅ A(Cell )  (4.22)  r 3H =  n⋅ B ⋅ v ⋅ L( ASN ) π ⋅ A( ASN )  (4.23)  Three HO scenarios are defined and compared in the performance analysis. •  Scenario 1 (Sn1): In this scenario, MSs perform the standard default R6HO and R3HO protocols with HOB = 00 as shown in Figure 4.1 and Figure 4.2, respectively.  •  Scenario 2 (Sn2): In this scenario, MSs perform the standard optional R6HO and R3HO protocol with HOB = 10 as shown in Figure 4.3 and Figure 4.4, respectively.  •  Scenario 3 (Sn3): In this scenario, MSs perform our proposed R6HP and R3HP protocols where HOB is set to 01 as shown in Figure 4.6 and Figure 4.8, respectively.  4.4.2 Handover signaling HO signaling refers to the total traffic load introduced in the network as a result of exchanging HO messages. In this analysis, we are focusing on the exchange of HO control messages and authentication messages during a HO. Other HO related messages like TBS scanning messages and Mobile IP registration messages are assumed to have a similar effect on all three HO scenarios, and hence have no impact on the comparison. From (4.22) and (4.23), the HO signaling exchanged in the network by MSs performing R6HOs and R3HOs when n · B users exist in the network in the three scenarios is calculated as follows.  121  00  00  10  10  SC S n1 = r 6 H ⋅ S R 6 HO + r 3H ⋅ S R 3HO SC S n 2 = r 6 H ⋅ S R 6 HO + r 3H ⋅ S R 3HO  (4.24)  SC S n3 = r 6 H ⋅ S R 6 HP + r 3H ⋅ S R 3HP where Sprotocol denotes the total size of messages exchanged in the course of a HO protocol.  4.4.3 Handover delay  Studying HO delay is important in evaluating the efficiency of a HO protocol. A major constituent of HO delay is the delay of mutual authentication during a HO. Other HO related delays like TBS scanning delay and delays caused by lost packets or retransmissions are assumed to have a similar effect on all three HO scenarios, and hence not considered in the analysis. HO delay is calculated starting from the sending of a HO request by MS and ends by exchanging Key Request/Reply messages between MS and TBS. From (4.22) and (4.23), HO delays experienced by MSs engaged in performing HOs when n · B users exist in the network in the three HO scenarios are calculated as follows. 00  00  10  10  TD S n1 = r 6 H ⋅ TR 6 HO + r 3H ⋅ TR3HO TD S n 2 = r 6 H ⋅ TR 6 HO + r 3H ⋅ TR 3HO  (4.25)  TD S n3 = r 6 H ⋅ TR 6 HP + r 3H ⋅ TR 3HP  where Tprotocol denotes the HO delay experienced by an MS when performing a HO protocol. Tprotocol is calculated as follows.  ( (  (  ))  T protocol = M wl Dt ( wl ) + D pp ( wl ) + 2 D pc + M wd H wd Dt ( wd ) + D pp ( wd ) + 2 D pc + TE protocol  (  ))  (4.26)  where the variables and some of the values of Mwl, Mwd, Hwd, Dt(wl), Dt(wd), Dpp(wl), Dpp(wd) and Dpc are explained in Section 3.5 in Chapter 3. TEprotocol accounts for additional delays occurring in the protocol.  122  TE protocol = e protocol ⋅ h  (4.27)  where h and eprotocol are row matrices. h records additional delays experienced during protocol execution. It is defined as.  [  h = D AV , D ED , DMAC , D Key , D ID  ]  (4.28)  where DAV is the delay experienced by HSS and MS when generating AV related keys, DED accounts for encryption/decryption delays, DMAC is the delay caused by calculating and verifying a message authentication code, DKey signifies the delay induced by key derivation and DID accounts for delays incurred in generating identities like R6-ID and R3-ID. The row matrix, e, for each authentication and HO protocol included in the analysis is found as follows.  e INEA = [2 , 2, 4,7,1] e R006 H = [2, 2, 4, 7,1] e R003H = [2 , 2, 4,7,1] e10 R 6 H = [0 , 0 , 0 ,1, 0] e10 R3H = [0 , 0 , 0 ,1, 0]  (4.29)  emod − INEA = [2,5, 4,14, 5] e R 6 HP = [0,0, 4,1, 2] e R3HP = [0, 0,8,6, 4]  4.4.4 Handover keys  The numbers and sizes of keys generated during a HO gives an indication of the required computation overhead on critical nodes like HSS, HAAA and MS in the interworking architecture. Keys under examination starts from CK, IK pair and keys derived from them down the hierarchy to AK. The number and sizes of keys derived before CK, IK and after AK are the same in all three scenarios and thus are not considered.  123  4.5 Numerical results Table 4.4 lists the parameters used in the performance analysis. Some of the values are calculated and induced from [77], [110]. We assume that there are three hops between PAAA and HAAA, two hops between HAAA and HSS and two hops between S-ASN-GW and T-ASNGW. All other network nodes are a single hop apart. ASprotocol is the average size of messages exchanged in a protocol. Table 4.4 Parameters used in the performance analysis Dt(wl)  Dt(wd)  BWwl  BWwd  Dpc  DAV  n  AS protocol  AS protocol  BW wl  BW wd  11 Mbps  100 Mbps  1 μs  12 μs  10 per cell  DMAC = DID  DKey  Dpp(wl)  Dpp(wd)  DED  a  12 μs (64 byte key)  2 ms  0.5 ms  5 μs (16 byte block)  1 Km  3 μs (16 byte MAC/ 16 byte ID)  Table 4.5 lists the message sizes (Sprotocol), delay (Tprotocol) and number and size of keys generated by nodes for all standard and the proposed protocols. Message sizes are calculated from [5], [15] and [17]. 21 bytes for IEEE 802.16e medium access control header, PKMv2 header and EAP header are included in calculating the size of messages exchanged in the wireless network. 50 bytes of IEEE 802.3 medium access control header, IP header, UDP header and EAP header are included in calculating the size of messages exchanged in the wired network. Additionally, 20 bytes of Radius header and 2 bytes per attribute are included in calculating the size of Radius Access-Request and Radius Access-Accept messages. TINEA and Tmod-INEA are calculated starting from the sending of the SBC REQ/RSP messages and ends by the exchange of Key Request/Reply messages.  124  Table 4.5 Message sizes, delay and the number and sizes of keys generated in every authentication and HO protocol  HOB Size of authentication or HO message in bytes (SProtocol) Average message size in each protocol in bytes Delay of authentication or HO protocols in milliseconds (Tprotocol) Total numbers of keys generated by all nodes Sizes keys generated by all nodes in bytes Numbers of keys generated by all servers Sizes of keys generated by all servers in byte Numbers of keys generated by HSS and HAAA Sizes of keys generated by HSS and HAAA in bytes Numbers of keys generated by MS Size of keys generated by MS in bytes  INEA  R6HO  R3HO  R6HO  R3HO  -  00  00  10  10  ModINEA -  3328  3951  4533  1160  2192  74  73  76  73  203  249  264  16  16  504  R6HP  R3HP  01  01  3927  1227  2675  84  87  82  107  100  125  204  98  124  16  2  2  28  4  10  504  504  40  40  1016  80  400  8  8  8  1  1  14  2  5  252  252  252  20  20  508  40  200  6  6  6  0  0  9  0  0  212  212  212  0  0  308  0  0  8  8  8  1  1  14  2  5  252  252  252  20  20  508  40  200  Our proposed HO protocols require the execution of mod-INEA. Thus every MS entering the interworking architecture must execute mod-INEA instead of standard INEA. As shown in Table 4.5, the size of authentication messages exchanged in mod-INEA is 15% more than the size of authentication messages exchanged in standard INEA. However, executing R6HP and R3HP yields HO signal reductions of 69% and 41% compared to R6HO (HOB = 00) and R3HO (HOB = 00), respectively. Thus, the additional authentication signaling introduced by executing a single mod-INEA protocol enables remarkable HO signaling reductions in future HHOs. Figure 4.11 shows the HO signaling emitted by MSs performing R6HO and R3HO in the three HO scenarios when n · B users exist in the network. Equation (4.24) and relevant 125  performance values listed in Table 4.4 and Table 4.5 are used in calculating the HO signaling of the three scenarios. Figure 4.11 displays the HO signaling for different speeds, v, when R is set to 2. Our proposed protocols, i.e., Sn3, outperform Sn1 and show comparable results to Sn2. The HO signaling emitted by MSs adopting the protocols in Sn3 is less by a factor of 2.5 compared to the signaling emitted by MSs adopting the protocols in Sn1. As v increases, more HOs occur, hence, additional HO signaling is emitted by MSs performing HOs and adopting any of the three HO scenarios. The differences in HO signaling between Sn3 and Sn1 widen as v increases. For example, when v = 0.3 m/s, MSs performing HOs and adopting Sn1 emit an additional 3 KB of HO signaling compared to MSs adopting Sn3. When v doubles, the additional HO signaling emitted by MSs in Sn1 compared to Sn3 doubles and reaches 6 KB. The performances of Sn2 and Sn3 are almost the same. However, Sn2 demonstrates a minuscule advantage compared to Sn3. This is because of the additional size of the HO control messages in Sn3 in comparison to Sn2.  HO Signaling (KB)  18  Sn1 Sn2 Sn3  14  10  6  2 0.3  0.5  0.7  0.9  v (m/s)  Figure 4.11 HO signaling comparisons between Sn1, Sn2 and Sn3 when varying v  Figure 4.12 shows the effect of varying R and setting v to 0.5 m/s in the HO signaling analysis. As R increases, more R6HOs are performed and the difference in HO signaling between Sn1 and Sn3 increases as well. When R = 2, MSs adopting Sn1 dispatches an additional 126  5 KB of HO signaling compared to MSs adopting Sn3. Hence, Sn3 reduces 59% of HO signaling dispatched by Sn1. When R is doubled, the additional HO signaling dispatched by Sn1 compared to Sn3 reaches 25 KB. Thus, when R doubles, Sn3 reduces 64% of HO signaling dispatched by Sn1. This is due to a steep increase in the frequency of performing R6HO and R3HO as a result of ASN domain extensions. As shown in Table 4.5, our proposed HO protocols dispatches much less HO signaling compared to standard HO protocols when HOB is set to 00. The advantage of our proposed protocols is demonstrated as more HOs, especially R6HOs, are invoked. Although MSs adopting Sn3 requires exchanging extra signaling when entering the interworking architecture, much less signaling are emitted compared to MSs adopting Sn1 when performing HOs as shown in Figure 4.11 and Figure 4.12.  70  HO Signaling (KB)  Sn1 Sn2 Sn3 50  30  10  1  2  3 R  4  5  Figure 4.12 HO Signaling comparisons between Sn1, Sn2 and Sn3 when varying R  Figure 4.13 shows the HO delay experienced by MSs performing R6HOs and R3HOs when n · B users exist in the network. The figure shows the delay comparison when varying MS’s speed and setting R to 2. Similarly to the HO signaling analysis, Sn3 outperforms Sn1. Sn2 and Sn3 display identical HO delay results. This is because additional delays caused by additional key derivations and MAC generation/verification in Sn3 are equivalent to the delay of generating and requesting a new AK from SASN-GW during R6HOs and R3HOs in Sn2. 127  HO Delay (s)  1  Sn1 Sn2 Sn3  0.6  0.2  0.3  0.5  0.7  0.9  v (m/s)  Figure 4.13 HO delay comparisons between Sn1, Sn2 and Sn3 when varying v  Sn1 Sn2 Sn3  HO Delay (s)  3.5  2.5  1.5  0.5 1  2  3 R  4  5  Figure 4.14 HO delay comparisons between Sn1, Sn2 and Sn3 when varying R  Figure 4.14 shows the HO delay as R increases and when v is set to 0.5 m/s. Again, our proposed protocols display outstanding results as R increases. Although Sn2 is deemed insecure compared to Sn1 and Sn3, it performs almost equivalently to Sn3. The reduction in HO delay in Sn3 demonstrates the excellence of our proposed protocols and proved its suitability for handling delay-sensitive applications. As shown in Table 4.5, authentication delay in mod-INEA is comparable to authentication delay in standard INEA. Therefore, when executing mod-INEA, 128  users should experience similar authentication delays experienced when executing standard INEA when entering the interworking architecture. Table 4.5 lists the numbers and sizes of keys generated by critical nodes in all authentication and HO protocols. During mod-INEA execution, 28 keys are generated with keys size of 1016 bytes compared to 16 keys only with a keys size of 504 bytes generated in standard INEA. MS generates 14 keys (508 bytes) in mod-INEA compared to 8 keys (252 bytes) generated in standard INEA. This double key generation is essential for the correct execution of R6HP and R3HP. The nodes involved in R6HP execution only generate 4 keys (80 bytes) per HO compared to 16 keys (504 bytes) per HO generated in R6HO with HOB = 00. Likewise, The nodes involved in R3HP execution only generate 10 keys (400 bytes) per HO compared to 16 keys (504 bytes) per HO generated in R3HO with HOB = 00. The nodes involved in R6HO and R3HO execution with HOB = 10 only generate 2 keys (40 bytes) per HO. Nevertheless, this much reduced number of keys is achieved at the expense of an insecure key management scheme. When MSs travel in 0.5 m/s and R is set to 3, all nodes involved in generating keys during a HO in Sn3 generate less keys in terms of numbers and sizes by a factor of 3 compared to Sn1. Since HSS and HAAA control hundreds of thousands of MSs, it is important to minimize the numbers and sizes of keys derived and maintained by them. Our proposed HO protocols conserve the numbers and sizes of keys produced by HSS and HAAA by virtue of local preauthentication operations, which do not require the involvement of HSS and HAAA. Therefore, regardless of the number of users and the number of performed HOs, HSS and HAAA do not derive any HO related keys in our proposed protocols. Key derivation during HOs is delegated to PAAA and ASN-GW.  129  HSS and HAAA only derive 9 keys (308 byte) per MS when mod-INEA is executed. These are the only keys derived by HSS and HAAA for each MS until the next mod-INEA execution. On the other hand, in Sn1, HSS and HAAA derive 6 keys (212 bytes) per MS per R6HO and R3HO when HOB = 00. Our proposed key management scheme shifts the burden of generating keys from HSS and HAAA to intermediate servers, and consequently, the resources in HSS and HAAA are better reserved. Figure 4.15 depicts the numbers and sizes of keys generated by all servers involved in the authentication procedure in the three scenarios as the number of users in the cell increases. Figure 4.15 emphasizes that our proposed protocols are more scalable and efficiently capable of handling increased number of users and increased number of HOs.  Number of keys - Sn1 Number of keys - Sn2 Number of keys - Sn3  7  Key size - Sn1 Key size - Sn2 Key size - Sn3  140  5  3  80  Key sizes (KB)  Number of keys  200  1  20 10  20 30 40 Number of users in a cell (n)  50  Figure 4.15 Numbers and sizes of keys generated by all the servers involved in the authentication procedure in the three scenarios when increasing the number of users in the cell  Figure 4.16 illustrates the numbers and sizes of keys generated by MSs involved in R6HO and R3HO when n · B users exist in the network in the three HO scenarios. The figure shows the numbers and sizes of keys when setting v to 1 m/s. When increasing R, more HOs are performed and Sn3 outperforms Sn1 in terms of key production. This is because invoking R6HP 130  and R3HP results in generating less numbers and sizes of keys compared to invoking R6HO and R3HO with HOB = 00. It is noted that Sn2 always produces less keys than Sn3. This is expected given that Sn2 adopts a weak and insecure key management scheme where each MS performing a HO produces a single key only.  Number of keys - Sn1 Number of keys - Sn3 Number of keys - Sn2  7  Key size - Sn1 Key size - Sn2 Key size - Sn3  150  5  90  3  30  1 0  1  2  3  4  5  Key sizes (KB)  Number of keys  210  6  Figure 4.16 Numbers and sizes of keys generated by MSs performing R6HO and R3HO in Sn1, Sn2 and Sn3  It is clear from Figure 4.16 that MSs adopting the HO protocols in Sn3 generates fewer keys with smaller key size as R increases. To illustrate, when R = 2, MSs involved in R6HO and R3HO generate and maintain 35 keys (≈ 1.1 KB) in Sn1 compared to 14 keys (≈ 400 bytes) in Sn3. In this case, MSs adopting Sn1 produce more than double the keys produced by MSs adopting the HO protocols in Sn3. When increasing R to 4, 155 keys (≈ 5 KB) are produced in Sn1 compared to 50 keys (≈ 1.3 KB) in Sn3. In this case, MSs adopting Sn1 produce more than triple the numbers and sizes of keys produced by MSs adopting the HO protocols in Sn3. 4.5.1 Selection of nR6H and nR3H values  The value of nR6H and nR3H control the frequency of executing R6HP and R3HP, respectively. MS and ASN-GW reset the counter tracking the number of performed R6HO when 131  MS enters a new ASN domain. The value of nR6H and nR3H should be chosen to permit enough R6HP and R3HP executions, respectively, which results in balancing security and performance. R6HP is executed when MS performs a HO from a BS cell to the other while R3HP is executed when MS crosses the boundaries of an ASN domain. The execution of mod-INEA is enforced when CR6H > max(CR6H), when CR3H > max(CR3H), when AHK expires or when PHK expires. Selection of nR6H and nR3H depends on AHK lifetime, PHK lifetime and MS resident time (Tr), which is the average time the MS stays within the coverage area of a BS cell. Figure 4.17 shows our suggested algorithm for selecting the values of nR6H and nR3H. Two options are suggested, the balanced option and the performance oriented option. The balanced option yields values for nR6H and nR3H that balance security with performance. The performance oriented option is more biased towards performance.  Algorithm 4.1 Pseudocode for selecting nR6H and nR3H values  { Variable declarations: } PHK_lifetime = the lifetime of PHK; AHK_ lifetime = the lifetime of AHK; balanced_nR6H = the suggested value for nR6H for a balanced security and performance; performance_nR6H = the suggested value for nR6H for more performance over security; balanced_nR3H = the suggested value for nR3H for a balanced security and performance; performance_nR3H = the suggested value for nR3H for more performance over security; Tr = average MS resident time; B = number of BSs in the ASN domain; %% Selecting nR6H %% max_ nR6H = AHK_lifetime / Tr; min_ nR6H_nR3H = 1; balanced_ nR6H = (max_ nR6H + min_ nR6H_nR3H) / 2; performance_ nR6H = (max_ nR6H + balanced_ nR6H) / 2; %% Selecting nR3H %% max_ nR3H = PHK_lifetime / B · Tr; balanced_ nR3H = ( max_nR3H + min_ nR6H_nR3H) / 2; performance_ nR3H = (max_ nR3H + balanced_ nR3H) / 2; Figure 4.17 Algorithm for selecting nR6H and nR3H values  132  4.6 Security analysis There is a trade-off between security and performance in HO protocols. The protocols should not compromise security to achieve outstanding performance or deploy a strong security scheme that is essentially inefficient. Our proposed protocols strike a balance between security and performance. On the one hand, it shares similar security features as the standard default HO protocols with HOB = 00; on the other hand, it performs comparably to the standard optional HO protocols with HOB = 10, which are less secure. Table 4.6 compares security features of our proposed HO protocols and standard HO protocols. In this section we examine the security of our proposed protocols according to the security requirements listed in Section 4.2. Table 4.6 Security features of the standard and proposed HO protocols S1  S2  S3  S4  S5  MDHO/FBSS  No  Low  Low  Low  Yes  R6HO/R3HO (HOB = 00) – Sn1  Yes  High  Medium-High  High  No  R6HO/R3HO (HOB = 10) – Sn2  No  LowMedium  Low-Medium  LowMedium  Yes  R6HP and R3HP (HOB = 01) – Sn3  Yes  High  High  Yes  High  4.6.1 S1-Mutual authentication  Mutual authentication defends against impersonation attacks, MITM attacks and rouge BS attacks. In R6HP, ASN-GW engages in mutual authentication operation with MS on behalf of TBS. MS and ASN-GW verifies the authenticity of each other by correctly computing R6MAC1 and R6MAC2 using (4.11) and (4.12), respectively. Only a legitimate MS and ASNGW holds a correct KMS-MS and CR6H used in generating R6MAC1 and R6MAC2. In R3HP, PAAA engages in mutual authentication with MS on behalf of TBS. PAAA and MS verify the 133  authenticity of each other by correctly computing TicketMS and TicketPA using (4.10) and (4.15), respectively. Only a legitimate PAAA and MS hold HN, MN, PAK, PHK and CR3H used in generating TicketMS and TicketPA. Additionally, a correctly computed R3MAC1 and R3MAC2 using (4.16) and (4.17), respectively, indicate correct KAS-MS, AAK and AHK and hence legitimate MS and TASN-GW. We tested R6HP and R3HP using AVISPA to ensure the provision of mutual authentication service. Figure 4.18 shows the HLPSL code that describes MS’s role in R6HP.  role mobile ( MS,ASN,SBS,TBS : agent, Dot16KDF, HMAC : hash_func,%key derivation functions IKMSASN, AHK : symmetric_key, CPH,ASN_ID,TBS_ID,MS_mac,NLA_ID : text, % counters and ids SND_SBS,RCV_SBS : channel (dy)) played_by MS def= local AN : text, %AN nonce MAC1R6HP : hash(symmetric_key.text.text.text), MAC2R6HP : hash(symmetric_key.text.text), PMKH,AKH : hash(symmetric_key.text.text.text), State : nat const success : text, akh1,an1,an2 : protocol_id init State := 2 transition 1. State = 2 /\ RCV_SBS(AN'.MAC1R6HP') /\ MAC1R6HP' = HMAC(IKMSASN.NLA_ID'.AN'.CPH) =|> State' := 5 /\ MAC2R6HP' := HMAC(IKMSASN.AN'.CPH) /\ SND_SBS(MAC2R6HP') /\ request(MS,ASN,an1,AN') %MS authenticates ASN-GW /\ witness(MS,ASN,an2,AN') %ASN-GW authenticates MS 2. State = 5 /\ RCV_SBS(success) =|> State' := 8 /\ PMKH' := Dot16KDF(AHK.CPH.ASN_ID.MS_mac) /\ AKH' := Dot16KDF(PMKH'.CPH.TBS_ID.MS_mac) /\ secret(AKH',akh1,{MS,ASN,TBS}) %AKH secrecy between %MS, ASN and TBS end role  Figure 4.18 HLPSL code describing MS’s role in R6HP protocol  The statement “request(MS,ASN,an1,AN')” is used to authenticate the ASN-GW while the statement “witness(MS,ASN,an2,AN')” is used to confirm the authentication of the MS by the ASN-GW. SPAN and the back-end verification tools in AVISPA, namely, 134  OFMC, CL-AtSe and SATMC, were used to test R6HP and R3HP. All test results proved the provision of mutual authentication service. No authentication attacks were discovered. Figure 4.19 shows the output result of testing R6HP by Cl-AtSe and OFMC, respectively, in SPAN.  (a)  (b)  Figure 4.19 Results of testing R6HP in (a) OFMC and (b) ATSE in SPAN  4.6.2 S2-Forward and backward secrecy  To preserve forward and backward secrecy and prevent domino effect, MS and TBS must derive new keys after HO. The new key must be ineffective in breaking the security of the communications between MS and previously serving BSs or future TBSs. In R6HP and R3HP, a new AKH is derived after R6HO and R3HO using (4.14). The derived AKH cannot be used to break the security of the communications between MS and previous SBS (backward secrecy) or future TBS (forward secrecy). This is because a new PMK and CR6H are used in AKH derivation; hence, AKH is only useful when used between MS and BS holding a correct CR6H and PMK. This 135  implies that an adversary holding a valid AKH constitutes a threat to the communication channel between MS and BS using that AKH only. The exposed AKH is ineffective in breaking the security of communications between MS and other BSs in the network. Thus, the threat of domino effect is largely marginalized.  4.6.3 S3-Key scope and distribution  Keys in R6HP and R3HP have a well defined scope. For example, MSK is the parent key for authentication keys only and EMSK is the parent key for HO keys only. Additionally, keys are bounded to the entities using them. For example, PMK is maintained by MS and ASN-GW; therefore, MSM and ASN-ID are included in their derivation procedures as shown in (4.5) and (4.13). Keys must only be effective within the jurisdictions of the nodes involved in deriving them. In the standard optional R3HO (HOB = 10), PMK derived by SASN-GW is used to produce AK, which is later used in the jurisdiction of TASN-GW. This is possible due to the lack of binding between PMK and the nodes using it, thus leading to possible false BS attacks [61]. In R6HP and R3HP, PMK is bound to the MS and the ASN-GW, and hence it is effective within the ASN domain only. Revealing PMK results in a security threat to the ASN domain in which the PMK was exposed and causes no threat to other ASN domains. This feature eliminates false BS attacks during R3HO. The “principle of least privilege” [60] is an important criterion in designing a secure HO protocol. Our proposed protocols comply with the principle of least privilege. In R6HP and R3HP, every node in the network ends up receiving keys and key materials necessary for its operation only. Keys derived by nodes other than the MS are systematically distributed from the nodes residing in higher architectural layer to nodes residing in lower architectural layers as long as both nodes trust each other. HAAA derives PHK from EMSK and forwards it to PAAA. The latter derives AHK from PHK and forwards it to ASN-GW. Finally, ASN-GW derives PMK and 136  AKH from AHK and forwards it to BS communicating with MS. Thus, no mass distribution of keys to TBSs, ASN-GWs and PAAAs takes place as the case in MDHO/FBSS and the protocols presented in [55]. Keys like PHK and PAK are derived by HAAA but held by PAAA. Thus, to enforce the principle of least privilege, HAAA must delete PHK and PAK after delivering them to PAAA. Similarly, nonces like HN and MN held by HAAA must be deleted after forwarding them to PAAA.  4.6.4 S4-Key freshness  All keys are freshly derived in R6HP and R3HP to defend against replay attacks. Key freshness is guaranteed by including a newly derived key, a fresh nonce or a continuously incremented counter in the key derivation procedure. For example, PHK is freshly derived during mod-INEA due to the inclusion of a new EMSK and HNi in its derivation procedure shown in (4.2). AHK is freshly derived during R3HP due to the inclusion of CR3H counter in its derivation procedure as shown in (4.4). Finally, PMKH and AKH are freshly derived during R6HP and R3HP due to the inclusion of CR6H in its derivation procedure as shown in (4.13) and (4.14), respectively.  4.6.5 S5-Privacy protection  The standard HOs with HOB = 00 invoke INEA which results in revealing the MS’s permanent identity. The identity can be easily eavesdropped and targeted attacks on the MS could be mounted. The proposed protocols rely on temporary identities to mask the permanent identity. Two temporary identities are proposed, R6-ID and R3-ID. R6-ID is used during R6HP while R3-ID is used during R3HP. A new R6-IDi is derived by MS and ASN-GW after performing mod-INEA, R6HP and R3HP. The freshness of the identity is guaranteed by the inclusion of CR6H and the inclusion of R6-IDi – 1 in the derivation procedure shown in (4.9). A new R3-IDi is derived by MS and PAAA after performing mod-INEA and R3HP. The freshness 137  of R3-IDi is achieved by the inclusion of CR3H and R3-IDi – 1 in the derivation procedure shown in (4.7).  4.7 Summary Performance-improved and secure HO protocols to speed the HHO operation in the 3GPP-WiMAX without downgrading security have been presented in this Chapter. R6HP and R3HP have been introduced to expedite the inefficient standard default R6HO and R3HO protocols, respectively. The proposed protocols launch a mutual authentication procedure that is executed during a HO. This is achievable by augmenting the HO control messages to include authentication-related information. We have presented thorough performance comparisons between our proposed protocols and standard HO protocols. Although MSs adopting our proposed protocols are required to execute mod-INEA, which emits additional authentication signaling and generates additional keys per MS compared to standard INEA, MSs enjoys efficient R6HO and R3HO operations. Results show that our proposed protocols achieve considerable reductions in HO signaling and delay compared to standard HO protocols. Additionally, the numbers and sizes of keys produced by critical nodes in our proposed protocols are remarkably lower than the standard HO protocols. The proposed HO protocols fulfill essential security requirements like the support of mutual authentication and the observation of forward and backward key secrecy. The mutual authentication service in our proposed protocols has been tested using a state-of-the-art formal security analysis and verification tool. Neither vulnerabilities nor authentication attacks were discovered.  138  Chapter 5: Fast vertical handover re-authentication protocols for the heterogeneous wireless network∗ 5.1 Introduction Users might prefer to switch from one wireless technology to another to endeavor faster, cheaper or better service quality. Users performing VHOs anticipate a smooth, imperceptible and secure transition between 3GPP, WiMAX and WLAN in the heterogeneous wireless network. It is important to complete the VHO procedure promptly without compromising security. A major deterrent to a quick VHO is the mutual authentication procedure between the MS and the authentication servers in the 3GHN. In this Chapter, we present and analyze five VHO re-authentication protocols executed by 3GPP subscribers performing VHOs between WiMAX and WLAN. The proposed protocols are executed according to different VHO situations. When the subscriber performs a VHO from WLAN to WiMAX, WiMAX Fast Re-authentication (WiFR) is executed when the ASN domain is visited for the first time, WiMAX Local Re-authentication (WiLR) is executed when the ASN domain is revisited while the WiMAX Proxy Assisted Re-authentication (WiPAR) is executed when the ASN domain is new and PAAA is revisited. On the other hand, when the subscriber performs a VHO from WiMAX to WLAN, WLAN Fast Re-authentication (WLFR) is executed when the WLAN domain is visited for the first time while WLAN Local Re-authentication version 2 (WLLRv2) is executed when the WLAN domain is revisited. Our proposed protocols achieve outstanding performance results compared to standard protocols in terms of re-authentication signaling traffic and re-authentication delay, while fulfilling essential VHO security requirements like the provision of mutual authentication and ∗  Parts of this Chapter have been presented in the 18th annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC’08) [114]. In addition, parts of this Chapter have been accepted for publication in IEEE Transactions on Dependable and Secure Computing on April 2010 [115].  139  forward and backward secrecy. Additionally, we propose an efficient 3GPP re-authentication protocol to minimize the re-authentication delay during VHOs from WLAN/WiMAX to 3GPP access network. The remainder of this chapter is organized as follows. In Section 5.2, we describe and evaluate the five proposed WiMAX-WLAN VHO re-authentication protocols starting with an introduction in Section 5.2.1. Section 5.2.2 details the proposed protocols. In Section 5.2.3 and Section 5.2.4 we evaluate the performance of five proposed protocols and display some numerical results. Section 5.2.6 elaborates on the security of our proposed protocols. In Section 5.3, we present the 3GPP-AKA Fast Re-authentication protocol used in improving the VHO procedure from WLAN/WiMAX to 3GPP access network. In Section 5.3.1, we present a brief introduction. The proposed VHO re-authentication protocol is presented in Sections 5.3.2 and 5.3.3. Performance evaluation of the proposed protocols is detailed in Section 5.3.4 while security of the proposed protocol is analyzed in Section 5.3.5. Finally, Section 5.4 summarizes the chapter.  5.2 Secure and efficient vertical handover re-authentications between WiMAX and WLAN 5.2.1 Introduction  The VHO re-authentication procedure influences the total dispatched traffic and delay resulting from VHO operations. Improving re-authentication is a key element in achieving an efficient VHO operation [73], [68]. As per 3GPP and WiMAX Forum specifications [10], [34], 3GPP subscribers roaming in the heterogeneous wireless network and performing a VHO between WiMAX and WLAN must achieve mutual re-authentication with HSS and HAAA. In the case of WiMAX to WLAN VHO, MS invokes EAP-AKA with HSS and HAAA if the WLAN domain is visited for the first time. Otherwise, fast EAP-AKA re-authentication is 140  executed. In the case of WLAN to WiMAX VHO, MS performs INEA when visiting an ASN domain for the first time [10], [15]. Otherwise, WiMAX Re-authentication protocol is executed [15]. Figure 5.1 depicts the standard VHO re-authentication procedures during WiMAX to WLAN VHOs and WLAN to WiMAX VHOs. As discussed before, EAP-AKA and INEA are inefficient and susceptible to high reauthentication delays. We design fast re-authentication protocols to be used in the case of WiMAX-WLAN VHOs. Since (re-)authentication depends on EAP-AKA and INEA, we utilize mod-EAP-AKA presented in Section 3.3 in Chapter 3 and mod-INEA presented in Section 4.3 in Chapter 4 to derive specific security parameters to enable the execution of our proposed protocols and eventually speed the re-authentication procedures in WiMAX-WLAN VHOs.  Figure 5.1 VHO procedures between WLAN and WiMAX as standardized by 3GPP and the WiMAX Forum for a 3GPP subscriber  To the best of our knowledge, our proposed set of protocols are the first to attempt to achieve fast and secure WiMAX-WLAN VHOs performed by a 3GPP subscriber. The proposed protocols display unique characteristics compared to closely competitive protocols. Firstly, they are designed to abbreviate the engagement of HSS and HAAA during VHO re-authentication 141  contrasting the standard protocols found in [10], [15] and [34]. Secondly, they do not require any changes to the existing interworking architecture contrasting the solutions in [67] and [76]. Thirdly, they demonstrate adequate efficiency without compromising security contrary to [75]. Lastly, they do not depend on Media Independent HO services found in IEEE 802.21 unlike the solutions in [72], [73] and [75]. The proposed protocols evade communicating with some or all authentication servers in the 3GHN as opposed to the standard VHO re-authentication protocols. Thus, our proposed protocols outperform the standard protocols in terms of re-authentication delay and signaling overhead. Moreover, our protocols are proven to be secure when tested using a formal security validation tool.  5.2.2 Proposed vertical handover re-authentication protocols  Five VHO re-authentication protocols are proposed to achieve two goals: firstly, to mutually authenticate MS and target network after performing a VHO with minimal HSS and HAAA involvement, secondly, to establish a secure key agreement between MS and target network. The proposed protocols are invoked as a result of three VHO situations: firstly, a VHO to a new ASN or WLAN domain, secondly, a VHO to a previously visited ASN or WLAN domain, and thirdly, a VHO to a new ASN domain controlled by a PAAA that holds valid security association with the MS. Figure 5.2 depicts the interconnection between the authentication servers in the ASN domains, WLAN domains and the 3GHN in the heterogeneous wireless network.  142  Figure 5.2 Interconnection between WiMAX, WLAN and 3GPP authentication servers in the heterogeneous wireless network  The Figure shows a 7-step HO path traveled by the MS. HO steps 1, 2, 4 and 7 belongs to the first HO situation because new ASN domains (ASN domains 1 and 3) and new WLAN domains (WLAN domains 2 and 3) are visited. HO steps 5 and 6 belong to the second HO situation while step 3 belongs to the third HO situation. Although a new ASN domain is visited in HO step 3 (ASN domain 2), the visited domain is controlled by PAAA holding a security association with MS established in HO step 1. The five proposed VHO re-authentication protocols are given below according to their applicability in the three VHO situations: •  VHO Situation 1: VHO to a new ASN and WLAN domains. WiFR is performed during  WLAN to WiMAX VHOs while WLFR is performed during WiMAX to WLAN VHOs. •  VHO Situation 2: VHO to a previously visited ASN and WLAN domains. WiLR is  performed during WLAN to WiMAX VHOs while WLLRv2 is performed during WiMAX 143  to WLAN VHOs. WLLRv2 is a variation of the WLLR protocol presented in Section 3.4.1 in Chapter 3. •  VHO Situation 3: VHO to a new ASN domain controlled by a previously visited PAAA.  WiPAR is the only protocol invoked under this VHO situation. The proposed protocols are only performed following the execution of either mod-INEA or mod-EAP-AKA. These executions occur when MS enters either a new ASN domain or a new WLAN domain for the first time or after the expiration of the keys shared between MS and HSS/HAAA. An execution of either mod-INEA or mod-EAP-AKA suffice to enable the execution of the proposed fast VHO re-authentication protocols. For example, executing either mod-INEA or mod-EAP-AKA enables the execution of WiFR and WLFR protocols, which doesn’t require the involvement of HSS in the VHO re-authentication. In addition, executing either mod-INEA or mod-EAP-AKA enables the execution of WiPAR, WiLR and WLLRv2, which do not contact HSS or HAAA during VHO re-authentication. A flow chart demonstrating the relation between our proposed protocols and different VHO situations is shown in Figure 5.3. A list of symbols used in describing the proposed protocols is shown in Table 5.1.  Figure 5.3 Flow chart of our proposed protocols based on different HO situations 144  Table 5.1 List of symbols used in describing our proposed protocols Type  Keys  n values  Value  Derived by  Held by  Size (byte)  Notes  EKAS-MS  MS, ASN-GW  MS, ASN-GW  16  MS and ASN-GW Encryption Key  IKAS-MS  MS, ASN-GW  MS, ASN-GW  16  MS and ASN-GW Integrity Key  EKPA-MS  MS, PAAA  MS, PAAA  16  MS and PAAA Encryption Key  IKPA-MS  MS, PAAA  MS, PAAA  16  MS and PAAA Integrity Key  nVHO  HAAA  MS, HAAA  1  Permitted number of VHOs  nPAR  HAAA HAAA, MS, ASN-GW HAAA, MS, WAAA  MS, PAAA  1  MS, ASN-GW  1  MS, WAAA  1  Permitted WiPAR executions Permitted WiLR executions in a single ASN domain Permitted WLLRv2 executions in a single WLAN domain  WiCH  MS, HAAA  MS, HAAA  16  WiRP  MS, HAAA  MS, HAAA  16  WLCH  MS, HAAA  MS, HAAA  16  WLRP  MS, HAAA  16  HN  HAAA  PN  PAAA  MS, HAAA MS, HAAA, PAAA MS, PAAA  AN  ASN-GW  MN  MS  CVHO  -  MS, ASN-GW MS, HAAA, PAAA MS, HAAA  CPAR  -  CLR  nLR nWRv2  Authentica tion Challenges  Nonces  Counters  Identities  Used to achieve mutual authentication between MS and HAAA in WiFR and WLFR  16  Nonce generated by the HAAA  16  Nonce generated by the PAAA  16  Nonce generated by the ASN-GW  16  Nonce generated by the MS  4  VHO counter set by nVHO  MS, PAAA  4  WiPAR counter set by nPAR  -  MS, ASN-GW  4  WiLR counter set by nLR  CWRv2  -  MS, WAAA  4  VHO-ID  HAAA  MS, HAAA  16  TPA-ID  MS, PAAA  MS, PAAA  16  WLLRv2 counter set by nWRv2 VHO identity used by MS in WiFR and WLFR Temporary identity used in WiPAR  TASN-ID  MS, ASN-GW  MS, ASN-GW  16  TWA-ID  MS, WAAA  MS, WAAA  16  Temporary identity used in WiLR Temporary identity used in WLLRv2  Three keys are derived by MS and HAAA as a result of executing either mod-INEA or mod-EAP-AKA. The keys are: MSK, EMSK and TEK. MSK is used to derive (re-)authentication keys, EMSK is used to derive HO-related keys and TEK is used to derive keys to protect EAP messages. Mod-INEA performed by MS when entering a new ASN domain is similar to modINEA protocol presented in Section 4.3 in Chapter 4. The usage of VHO-ID, nVHO and nPAR received in EAP Request/AKA-challenge message has not been explained in Section 4.3 in 145  Chapter 4; it is explained here. HAAA generates a VHO-IDi to be used by MS in future VHOs. Furthermore, HAAA sets the permitted number of VHOs, nVHO, a MS can perform and the permitted number of WiPAR executions, nPAR. nVHO and nPAR are used to adjust a VHO Counter, CVHO, and a WiPAR Counter, CPAR, MS also stores VHO-IDi for the next VHO operation. MS and HAAA derive the permitted number of WiLR executions in an ASN domain, nLR, from nVHO. MS set a WiLR Counter, CLR based on nLR. HAAA forwards nLR to PAAA which ultimately forwards it to ASN-GW to be used in setting CLR. CVHO is incremented on every VHO procedure while CPAR and CLR are incremented on every WiPAR and WiLR executions, respectively. The execution of mod-INEA is enforced when CVHO > max(CVHO) or CPAR > max(CPAR) or CLR > max(CLR). Thus, if the current counter value is 2 and its correspondent n value received from HAAA is 2, the maximum value of the counter should be set to 3. As explained in Section 4.3 in Chapter 4, MS and HAAA derive PAK from MSK using (4.1) and PHK from EMSK using (4.2). HAAA sets CVHO to its maximum value, max(CVHO), and forwards it along with PAK, PHK, MS-ID, nPAR and nLR to PAAA. In turn, PAAA adjusts CPAR according to nPAR and derives AAK and AHK using (4.3) and (4.4), respectively. Subsequently, it forwards AAK, AHK, nLR, MS-ID and max(CVHO) to ASN-GW. The ASN-GW adjusts CLR according to nLR and derives PMK, AK and KAS-MS using (4.5) and (4.6) and (4.8), respectively. MS derives PAK, PHK, AAK, AHK, PMK, KAS-MS and AK using (4.1), (4.2), (4.3), (4.4), (4.5), (4.6) and (4.8), respectively. Fast re-authentication protocols are based on EAP messages, and thus, to provide EAP integrity protection and message confidentiality, MS and ASN-GW divides KAS-MS to two 128 bit keys: EKAS-MS and IKAS-MS. MS and BS use AK to derive lower level keys to secure their communications. MS, ASNGW and PAAA calculate temporary identities to be used in future WiLR and WiPAR executions. Temporary PAAA ID (TPA-IDi) is calculated by MS and PAAA while Temporary ASN ID (TASN-IDi) is calculated by MS and ASN-GW. 146  TPA-IDi = Hash(PAK ⊕ PHK | MS-ID)  (5.1)  TASN-IDi = Hash(AAK ⊕ AHK | MS-ID)  (5.2)  Mod-EAP-AKA protocol performed by MS when entering a new WLAN domain is similar to mod-EAP-AKA protocol presented in Section 3.3 in Chapter 3. The usage of VHO-ID and nVHO received by MS in EAP Request/AKA-challenge message has not been explained in Section 3.3 in Chapter 3; it is explained here. MS stores VHO-ID and adjusts CVHO according to nVHO. In addition, it derives nWRv2 from nVHO and adjusts CWRv2 counter to keep track of WLLRv2 invocations. Upon completing mod-EAP-AKA, DRK and DHK are derived from MSK and EMSK, respectively, using (3.1) and (3.4) by MS and HAAA. HAAA forwards max(CVHO), DRK, DHK, nWR, nWRv2 and MS-ID to WAAA. WAAA derives LRK from DRK using (3.5), which is subsequently forwarded to AP. WAAA also adjusts CWRv2 according to nWRv2 and derives EKWA-MS and IKWA-MS using (3.6). MS derives DRK, DHK, LRK, EKWA-MS and IKWA-MS using (3.1), (3.4), (3.5) and (3.6). AP and MS use LRK to derive lower level keys to secure the communications between them. MS and WAAA compute a temporary WAAA ID, TWA-IDi, to be used in future WLLRv2 executions. TWA-IDi = Hash(DRK ⊕ DHK | MS-ID)  (5.3)  5.2.2.1 WiMAX fast re-authentication (WiFR) WiFR is invoked when MS performs a VHO to a newly visited ASN domain to permit future WiLR and WiPAR executions in that domain. In WiFR, MS and HAAA perform mutual re-authentication without the involvement of HSS. Since the re-authentication procedure takes place after a VHO, MS takes advantage of the preliminary exchanged capability negotiation messages between TBS and ASN-GW like “SBC REQ/RSP” and “MS_Preattach Req/Res” [15] messages to determine whether the ASN domain was previously visited or not. Nevertheless, MS has no means of determining whether PAAA was previously visited or not. Hence, MS supplies 147  TPA-IDi – 1, if available, in addition to VHO-IDi – 1 to PAAA. If TPA-IDi – 1 is not recognized by PAAA, VHO-IDi – 1 is forwarded to HAAA to instigate WiFR execution as shown in Figure 5.4. WiFR proceeds as follows: 1- HAAA validates VHO-IDi – 1 and verifies the lifetime of MSK and EMSK. If all verifications are positive, it prepares a re-authentication challenge that includes a fresh nonce, HNi, a new VHO-IDi, nPAR, nR6H, nR3H, a WiFR Challenge, WiCH, and a message authentication code to preserve the integrity of transmitted information, MAC1WiFR. HNi, VHO-IDi, nR6H, nR3H and nPAR are encrypted with K-encr and sent to MS. nR6H, nR3H are used when MS performs a WiMAX HHO as explained in Section 4.3 in Chapter 4. WiCH = Dot16KDF(K-auth, MNi – 1 | HA-ID | MSM | “WiCH”, 128)  (5.4)  MAC1WiFR = HMAC(K-auth, WiCH | HNi | VHO-IDi)  (5.5)  where HA-ID is the identity of the HAAA.  Figure 5.4 WiMAX fast re-authentication (WiFR)  148  2- MS receives the re-authentication challenge, adjusts CPAR according to nPAR, derives nLR from nVHO and sets CLR. It computes WiCH using (5.4) and verifies it against the received WiCH*. It also computes MAC1WiFR using (5.5) and matches it against the received MAC1WiFR*. If all verifications are positive, MS generates a fresh nonce, MNi, calculates a WiFR Reply, WiRP, and computes a MAC2WiFR. MNi and the current CVHO are encrypted with K-encr and forwarded to HAAA along with WiRP and MAC2WiFR. Additionally, MS stores VHO-IDi for the next VHO operation. WiRP = Dot16KDF(K-auth, HNi – 1 | HA-ID | MSM | “WiRP”, 128)  (5.6)  MAC2WiFR = HMAC(K-auth, WiRP | MNi | CVHO)  (5.7)  3- HAAA verifies that CVHO ≤ max(CVHO), computes WiRP and MAC2WiFR and compares them against the received WiRP* and MAC2WiFR*. If all verifications are successful, new PAK and PHK are derived using (4.1) and (4.2), respectably. HAAA sends the new PAK and PHK in addition to MS-ID, max(CVHO), nPAR, nLR, nR6H and nR3H to PAAA. 4- PAAA adjusts CPAR and derives AAK and AHK using (4.3) and (4.4), respectively. Subsequently, it forwards AAK, AHK, MS-ID, max(CVHO), nLR and nR6H to ASN-GW. 5- ASN-GW adjusts CLR and derives PMKH and AKH as follows. PMKH = Dot16KDF(AHK, CLR | ASN-ID | MSM |“PMK”, 160)  (5.8)  AKH = Dot16KDF(PMKH, CLR | BS-ID | MSM |“AK”, 160)  (5.9)  6- Upon receiving the EAP Success message, MS derives PHK, PAK, AHK, AAK, PMKH and AKH using (4.1), (4.2), (4.3), (4.4), (5.8) and (5.9). Additionally, it increments CVHO. AKH is used to derive lower level keys to secure the communications between MS and BS. 7- MS and PAAA calculate a new TPA-IDi using (5.1). MS and ASN-GW calculate a new TASN-IDi using (5.2). In the event of errors or failed security validation during WiFR, MS and HAAA invoke modINEA instead. 149  5.2.2.2 WiMAX proxy assisted re-authentication protocol (WiPAR) WiPAR is invoked when MS performs a VHO to a newly visited ASN domain that is controlled by a previously visited PAAA. In WiPAR, MS performs mutual re-authentication with PAAA instead of HSS/HAAA. Since MS has no means of determining whether PAAA was previously visited, TPA-IDi – 1 is supplied along with VHO-IDi – 1 to PAAA. WiPAR is depicted in Figure 5.5 and proceeds as follows: 1- PAAA verifies the received TPA-IDi – 1*, validates the lifetime of PAK and PHK and ensure that CPAR ≤ max(CPAR). If all verifications are positive, PAAA generates encryption and integrity keys, EKPA-MS and IKPA-MS, to protect its communications with MS. EKPA-MS | IKPA-MS = Dot16KDF(PAK ⊕ PHK, PA-ID | MSM | “EKIK”, 256)  (5.10)  2- Thereafter, PAAA generates a re-authentication challenge that includes CPAR, a fresh nonce, PNi, and a MAC1WiPAR. CPAR and PNi are encrypted during transmission with EKPA-MS. MAC1WiPAR = HMAC(IKPA-MS, PNi | CPAR)  (5.11)  Figure 5.5 WiMAX proxy assisted re-authentication (WiPAR)  150  3- Upon receiving the challenge, MS derives EKPA-MS and IKPA-MS using (5.10) and matches the received CPAR* to the WiPAR counter stored in its database, which was set in an earlier invocation of mod-INEA or WiFR. Moreover, MS validates the received MAC1WiPAR*. If all verifications are correct, it prepares a reply to the challenge that includes CVHO and MAC2WiPAR. CVHO is encrypted with EKPA-MS. MAC2WiPAR = HMAC(IKPA-MS, PNi +1 | CVHO )  (5.12)  4- PAAA verifies that CVHO ≤ max(CVHO) and validates the received MAC2WiPAR*. If all verifications are successful, PAAA increments CPAR and derives a new AAK and AHK using (4.3) and (4.4), respectively. These new keys along with MS-ID, max(CVHO), nR6H and nLR are forwarded to ASN-GW. 5- ASN-GW adjusts CLR according to nLR and derives PMKH and AKH from AHK using (5.8) and (5.9), respectively. Finally, it forwards AKH to BS. 6- When HO re-authentication completes successfully, MS increments CPAR and derives new AAK, AHK, PMKH and AKH using (4.3), (4.4), (5.8) and (5.9), respectively. Additionally, MS and ASN-GW compute a new TASN-IDi using (5.2) to be used in future WiLR invocations. Lastly, MS increments CVHO. In the event of errors or failed security validation during WiPAR, MS and PAAA invoke modINEA instead. 5.2.2.3 WiMAX local re-authentication protocol (WiLR) WiLR is invoked when MS performs a VHO to a previously visited ASN domain. In WiLR, re-authentication is executed locally in the ASN domain which results in significant performance improvements. MS recognizes that ASN-GW was previously visited from MS_Preattach Req/Res and SBC REQ/RSP messages, thus, it supplies TASN-IDi – 1 to instigate WiLR. The protocol is shown in Figure 5.6 and proceeds as follows: 151  Figure 5.6 WiMAX local re-authentication (WiLR)  1- ASN-GW validates the received TASN-IDi – 1*, ARK lifetime, AHK lifetime and verifies that CLR ≤ max(CLR). If ASN-GW does not share a key with MS, i.e., mod-INEA was not performed in this particular ASN domain; ASN-GW derives KAS-MS using (4.8) and splits the key to EKAS-MS and IKAS-MS. These keys are used to secure the integrity and confidentiality of EAP messages exchanged between MS and ASN-GW. 2- Afterwards, ASN-GW prepares a re-authentication challenge which includes CLR, a fresh nonce, ANi, and MAC1WiLR. MAC1WiLR = HMAC(IKAS-MS, ANi | CLR )  (5.13)  3- Upon receiving the challenge, MS derives EKAS-MS and IKAS-MS, if they were not derived before. Moreover, it validates the received CLR* and MAC1WiLR*. If all verifications are correct, MS issues a reply to the challenge that includes the current CLR and CVHO it maintains in addition to MAC2WiLR. Both counters are encrypted using EKAS-MS. MAC2WiLR = HMAC(IKAS-MS, ANi +1 | CVHO | CLR)  (5.14)  152  4- ASN-GW checks that CVHO ≤ max(CVHO) and validates the received MAC2WiLR*. If all checks are correct, it sends EAP success message to MS. ASN-GW and MS increment CLR, derive a new PMKH and AKH using (5.8) and (5.9), respectively, and generate a new TASN-IDi using (5.2) with the exception of substituting MS-ID with TASN-IDi – 1. Lastly, ASN-GW forwards AKH to BS and MS increments CVHO. In the event of errors or failed security validation during WiLR, MS and ASN-GW invoke modINEA instead. 5.2.2.4 WLAN fast re-authentication protocol (WLFR) WLFR is invoked when MS performs a VHO to a newly visited WLAN domain. The execution of WLFR in a WLAN domain permits the execution of WLLRv2 in future VHOs to the same domain. In WLFR, MS performs mutual re-authentication with HAAA without the need to contact HSS. MS has no means of determining whether the WLAN domain was previously visited or not. Thus, it supplies TWA-IDi  – 1,  if available, and VHO-IDi  – 1  to AP.  WLFR is depicted in Figure 5.7 and proceeds as follows: 1- If WAAA does not share a TWA-IDi – 1 with MS, it forwards the VHO-IDi – 1 to HAAA. HAAA validates the received VHO-IDi – 1 and verifies the lifetime of MSK and EMSK. If VHO-IDi – 1 is valid and keys are not expired, it prepares a re-authentication challenge that includes a fresh HNi, a new VHO-IDi, nWR, nHHO, a WLAN Challenge, WLCH, and MAC1WLFR. WLCH and MAC1WLFR are computed using (5.4) and (5.5), respectively. However, MS and HAAA use KDF presented in Section 3.3 in Chapter 3 to generate WLCH instead of Dot16KDF and replace WiCH with WLCH when calculating MAC1WLFR. 2- Upon receiving the challenge, MS validates the received WLCH* and MAC1WLFR*. Subsequently, MS derives nWRv2 from nVHO and adjusts CWRv2 accordingly. Furthermore, MS generates a fresh nonce, MNi, in addition to computing a WLFR Reply, WLRP, and 153  MAC2WLFR. WLRP and MAC2WLFR are computed using (5.6) and (5.7), respectively, with the exception of using KDF instead of Dot16KDF and replacing WiRP with WLRP in generating MAC2WLFR. MS stores VHO-IDi and uses it in the next VHO operation. CVHO and MNi are encrypted with K-encr and included in the re-authentication reply message sent to HAAA along with WLRP and MAC2WLFR.  Figure 5.7 WLAN fast re-authentication (WLFR)  3- HAAA validates that CVHO ≤ max(CVHO), and calculates WLRP and MAC2WLFR and compares them with the received WLRP* and MAC2WLFR*. Consequently, it derives DRK and DHK using (3.1) and (3.4), respectively. DRK, DHK, max(CVHO), MS-ID, nHHO, nWR and nWRv2 are forwarded by HAAA to WAAA. 4- WAAA adjusts CWRv2 based on nWRv2 and derives LHK from DHK and forwards it to AP. LHK = KDF(DHK, CWRv2 | TAP ID | MSM | “LHK” , 512)  (5.15)  5- Upon completing the re-authentication procedure, MS derives DRK, DHK and LHK using (3.1), (3.4) and (5.15), respectively. MS and the WAAA use LHK to derive lower level keys  154  to secure the communications between them. Next, MS and WAAA compute a new TWA-IDi using (5.3) to be used in future WLLRv2 invocations. Finally, MS increments CVHO. In the event of errors or failed security validation during WLFR, MS and HAAA invoke modEAP-AKA instead. 5.2.2.5 WLAN local re-authentication version 2 protocol (WLLRv2) WLLRv2 is locally executed when MS performs a VHO to a previously visited WLAN domain. This leads to significant reduction in delay and re-authentication signaling during VHOs. WLLRv2 is a variation of WLLR protocol presented in Section 3.4.1 in Chapter 3. WLLRv2 is depicted in Figure 5.8. The differences between WLLR and WLLRv2 are listed below: •  MS supplies TWA-IDi – 1 and VHO-IDi – 1 in WLLRv2 instead of TL-IDi – 1.  •  MS and WAAA use CWRv2 in calculating MAC1 and MAC2 instead of CWR.  •  MS and WAAA derive EKWA-MS and IKWA-MS using (3.6) in WLLRv2 in case these keys were not derived before, i.e., mod-EAP-AKA was not executed in this particular WLAN domain.  •  MS and WAAA derive LHK using (5.15) instead of LRK because the re-authentication procedure was instigated by a HO operation. WAAA forwards LHK to AP.  •  MS includes CVHO in EAP Response/AKA-re-auth. CVHO is also included in calculating MAC2 and it is incremented by MS when VHO re-authentication completes successfully.  •  WAAA verifies that CVHO ≤ max(CVHO) to permit the execution of WLLRv2.  •  MS and WAAA calculate a new TWA-IDi using (5.3) but replaces MS-ID with TWA-IDi – 1.  155  Figure 5.8 WLAN local re-authentication version 2 (WLLRv2)  5.2.3 Performance analysis  Performance analysis and testing tools are developed in this section to compare the performance of the proposed VHO re-authentication protocols against the performance of the standard VHO re-authentication protocols. 5.2.3.1 System model and assumptions Let A = {WLAN1, WLAN2,…, WLANi} denotes the set of WLAN domains and B = {ASN1, ASN2,…, ASNi} denotes the set of ASN domains. A indicates the number of WLAN domains in A while B indicates the number of ASN domains in B. Every WLAN domain in A contains one or more APs controlled by a single WAAA while every ASN domain in B contains one or more BSs controlled by a single ASN-GW. Similar to [10], [15] and [34] the 3GHN is assumed to establish a trust agreement with WiMAX CSN, ASN domains and WLAN domains. Re-authentication challenges and replies executed by MS when roaming between domains in A and B terminate in a single HAAA and HSS in the 3GHN. We assume that HAAA and HSS are two hops apart, WAAA and HAAA as well as PAAA and HAAA are three hops apart. In 156  addition, ASN-GW and PAAA are two hops apart and all other network entities in the system are a single hop apart. It is assumed that the MS performs a VHO between the domains in A and B only. HHOs within A are discussed in Chapter 3 while mobility within B is discussed in Chapter 4. VHOs are performed based on predefined user preferences like seeking a faster or cheaper service. Thus, when the VHO decision mechanism decides that a VHO is required, the MS performs a VHO from one wireless technology to the other. Assuming that the MS performs a VHO from WLAN to WiMAX, it is assumed that it switches to any ASN domain in B randomly. Therefore, the target domain could be visited for the first time or revisited. To accurately compute different performance metrics, all possible random VHO paths that could be taken by the MS in both directions are included in the calculation. Finally, the average performance result associated to a specific performance metric is found for both standard and proposed protocols, assuming the MS undergoes VHOs with the same frequency in both cases. The permitted number of VHOs, nVHO, is set by HAAA and received by MS in either mod-EAP-AKA or mod-INEA. A single execution of either mod-EAP-AKA or mod-INEA enables the execution of our proposed set of protocols depending on different VHO situations as shown in Figure 5.3. Re-execution of mod-EAP-AKA or mod-INEA is mandatory when CVHO > max(CVHO) or when the HOK lifetime expires. Let P = {Full EAP-AKA (re-)authentication, Fast EAP-AKA re-authentication, INEA, Fast WiMAX Re-authentication, mod-INEA, mod-EAP-AKA, WiFR, WiPAR, WiLR, WLFR, WLLRv2} denotes the set of standard and proposed (re-)authentication protocols. Let Pi identifies a protocol in P such that P1 corresponds to full EAP-AKA (re-)authentication, P2 corresponds to fast EAP-AKA re-authentication, etc. Thus, P1 to P4 represent the standard protocols whereas P5 to P11 represent our proposed set of protocols. We assume that MS initially selects to connect  157  to one of the domains in A and performs mod-EAP-AKA. It is assumed that CVHO = 1 at this instance. The probabilities of performing WiFR or WiLR in the next VHO are: Pr WiFR = 1  Pr WiLR = 1 − Pr WiFR  This implies that MS must perform a WiFR in the first VHO to any domain in B. When a VHO takes place, CVHO is incremented. At CVHO = 2, the probability of performing WLFR and WLLR in the next VHO are: Pr WLFR = 1 − A −1 ,  A>0  Pr WLLR = 1 − Pr WLFR At CVHO = 3, 5, 7,…, max(CVHO), the probability of invoking WiFR is:  (  )  Pr WiFR = 1 − nWi ⋅ B −1 ,  B > 0, nWi ≤ B  where nWi denotes the number of previous WiFR executions. At CVHO = 4, 6, 8,…, max(CVHO), the probability of invoking WLFR is:  (  )  Pr WLFR = 1 − (1 + nWL ) ⋅ A −1 ,  A > 0 , nWL ≤ A − 1 .  where nWL denotes the number of previous WLFR executions. WiPAR is invoked when two or more ASN domains in B are controlled by the same PAAA. Let α indicates the number of ASN domains controlled by the same PAAA. Therefore, α = 1 implies that every ASN domain in B is controlled by a unique PAAA server; hence, no WiPAR invocation takes place. Alternatively, setting α to 2 implies that 2 ASN domains in B are controlled by a single PAAA server. The maximum and minimum number of WiFR and WLFR invocations for a given nVHO, A, B and α are found as follows. nVHO < 2 B and nVHO ≡ 0 (mod 2) ⎧0.5 ⋅ nVHO , ⎪ nVHO < 2 B and nVHO ≡ 1(mod 2) max(WiFR) = ⎨0.5 ⋅ (nVHO + 1) , ⎪ nVHO ≥ 2 B ⎩ B, α = 1. ∀nVHO = 1,2,...,max(nVHO ), ∀B ≥ 1,  (5.16)  158  ⎧0.5 ⋅ nVHO , ⎪0.5 ⋅ (n ⎪ VHO + 1), max(WiFR) = ⎨ ⎪0.5 ⋅ B, ⎪⎩0.5 ⋅ (B + 1),  ∀nVHO = 1,2,...,max(nVHO ), min(WiFR) = 1,  nVHO < B and nVHO ≡ 1(mod 2)  nVHO ≥ B and B ≡ 0 (mod 2) nVHO ≥ B and B ≡ 1(mod 2) ∀B ≥ 1,  (5.17)  α = 2.  ∀nVHO = 1,2,...,max(nVHO ),  ⎧0.5 ⋅ nVHO , ⎪ max(WLFR ) = ⎨0.5 ⋅ (nVHO − 1), ⎪A − 1, ⎩ ∀nVHO = 1,2,...,max(nVHO ),  min(WLFR) = 0,  nVHO < B and nVHO ≡ 0 (mod 2)  ∀B and ∀α ≥ 1.  (5.18)  nVHO < 2 A and nVHO ≡ 0 (mod 2 ) nVHO < 2 A and nVHO ≡ 1(mod 2 ) n VHO ≥ 2 A ,  (5.19)  ∀A ≥ 1.  ∀nVHO = 1,2,...,max(nVHO ),  ∀A ≥ 1.  (5.20)  max(WLFR) and min(WLFR) are independent of α. max(WiPAR) when α = 2 is determined as follows: ⎧0.25 ⋅ nVHO , ⎪0.25 ⋅ (n VHO − 1), ⎪ ⎪⎪0.25 ⋅ (nVHO − 2), max(WiPAR) = ⎨ ⎪0.25 ⋅ (nVHO + 1), ⎪0.5 ⋅ B, ⎪ ⎪⎩0.5 ⋅ (B − 1),  ∀nVHO = 1,2,...,max(nVHO ), min(WiPAR) = 0,  nVHO < 2B and nVHO ≡ 0 (mod 4) nVHO < 2B and nVHO ≡ 1(mod 4)  nVHO < 2B and nVHO ≡ 2 (mod 4) nVHO < 2B and nVHO ≡ 3(mod 4)  (5.21)  nVHO ≥ 2B and B ≡ 0 (mod 2) nVHO ≥ 2B and B ≡ 1(mod 2)  ∀B ≥ 1,  α = 2.  ∀nVHO = 1,2,...,max(nVHO ),  ∀B ≥ 1,  α ≥ 1.  (5.22)  We define m as the maximum number of possible combinations of VHO re-authentication protocols a MS could execute during VHOs for a given nVHO, A, B and α. When α = 1, m is calculated from (5.16), (5.18), (5.19) and (5.20) as follows. m = ((max(WiFR) − min(WiFR) ) + 1) ⋅ ((max(WLFR ) − min(WLFR) ) + 1) ∀nVHO = 1,2,...,max(nVHO ), α = 1. ∀B and ∀A ≥ 1,  (5.23)  The algorithm used to find m when α = 2 is shown in Figure 5.9.  159  Algorithm 5.1. Pseudocode for calculating m when α = 2 if max(WiFR) = min(WiFR) then  m = ((max(WiPAR) − min(WiPAR)) + 1) · ((max(WLFR) – min(WLFR)) + 1) else if nVHO ≥ 2B then  m = (((max(WiFR) – min(WiFR)) + 1)) + ((max(WiPAR) – min(WiPAR)) + 1))) · ((max(WLFR) – min(WLFR)) + 1)) else  m = (((nVHO / 2) + 1) · ((max(WLFR) – min(WLFR)) + 1))) end if end if Figure 5.9 Algorithm used in calculating m when α = 2  For a maximum of m combinations, let Mi denote an individual combination. For each Mi, the MS could either adopt standard VHO re-authentication protocols, P1 – P4, or proposed VHO re-authentication protocols, P5 – P11. When α = 1, the frequency of performing each protocol in P (RPi) can be determined from (5.16), (5.18), (5.19), (5.20) and (5.23). An example of the frequency of performing standard protocols, RP1 – RP4, and proposed protocols, RP5 – RP11, when A = B = 2 and nVHO = 4 is shown in Table 5.2 and Figure 5.10. In Table 5.2, m = 4, WiPAR (RP8) is not invoked because α is set to 1 and mod-INEA (RP5) is not invoked since MS is assumed to initially connect to a WLAN network and perform mod-EAP-AKA. For a MS adopting proposed or standard protocols, mod-EAP-AKA or standard EAP-AKA must be initially executed for every Mi. This initial authentication is followed by four VHO reauthentication protocols because nVHO is set to 4. The relationship between RPi and nVHO can be expressed as follows. 4  ∑ RP i =  i =1  11  ∑ RP i = (nVHO + 1)  i =5  160  Table 5.2 Frequency of executing the protocols in P for every Mi when A = B = 2, nVHO = 4 and α = 1 Standard Protocols  Proposed Protocols  RP1  RP2  RP3  RP4  RP5  RP6  RP7  RP8  RP9  RP10  RP11  M1  2  1  2  0  0  1  2  0  0  1  1  M2  1  2  2  0  0  1  2  0  0  0  2  M3  2  1  1  1  0  1  1  0  1  1  1  M4  1  2  1  1  0  1  1  0  1  0  2  Figure 5.10 Possible combinations of proposed protocols when A = B = 2, nVHO = 4 and α = 1  5.2.3.2 Authentication signaling Authentication signaling is the accumulative authentication-related signaling traffic exchanged as a result of entering a new network for the first time or as a result of performing a VHO re-authentication operation. Reducing VHO re-authentication signaling leads to a 161  reduction in VHO signaling traffic travelling to and from the 3GHN. The average reauthentication signaling emitted in the standard (CS) and proposed (CP) protocols for a given nVHO, A and B are.  CS =  1 m 4 Mj ∑ ∑ R ⋅ MS P i m j =1i =1 P i  (5.24)  CP =  1 m 11 M j ∑ ∑ R ⋅ MS P i m j =1i = 5 P i  (5.25)  where MSPi is the accumulative size of the messages exchanged when performing protocol Pi. 5.2.3.3 Authentication delay Minimizing VHO re-authentication delay considerably reduces the total VHO delay. Reauthentication delay instigated by a VHO to a WLAN domain is calculated starting from reception of the first EAP message by MS and ends by reception of the last message of the 4way handshake protocol. On the other hand, re-authentication delay caused by a VHO to an ASN domain is calculated starting from the sending of “SBC-Req” message by MS and ends by the reception of “Key Reply” message. The average (re-)authentication delay for the standard (TDS) and proposed (TDP) protocols for a given nVHO, A and B is found as shown below.  TD S =  1 m 4 Mj ∑ ∑ R ⋅ TP i m j = 1i =1 P i  (5.26)  TD P =  1 m 11 M j ∑ ∑ R ⋅ TP i m j = 1i = 5 P i  (5.27)  where TPi is the total delay incurred by performing protocol Pi and calculated as follows.  ( (  (  ))  TPi = M wl D t ( wl ) + D pp ( wl ) + 2 D pc + M wd H wd D t ( wd ) + D pp ( wd ) + 2 D pc + TE Pi ,  (  ))  (5.28)  ∀i = 1,2,...,11  162  where the variables and some of the values of Mwl, Mwd, Hwd, Dt(wl), Dt(wd), Dpp(wl), Dpp(wd) and Dpc are explained in Section 3.5 in Chapter 3. TEPi records an extra delay incurred by performing Pi and calculated as follows.  [  TE P i = e Pi ⋅ D AV , D ED , DMAC , D Key , D ID  ]  (5.29)  where the variables and the values of DAV, DED, DMAC, DKey and DID are explained in Section 4.4 and Section 4.5 in Chapter 4. The row matrix ePi for each protocol in P is found as follows. e P1 = [2, 2, 4, 6,1], e P 2 = [0, 3, 4, 5,1] e P3 = [2, 2, 4, 7,1], e P 4 = [2, 2, 4, 7,1] e P5 = [2, 5, 4,14,5], e P 6 = [2, 5, 4,12,3] e P 7 = [0, 5, 8, 7,5], e P8 = [0, 2, 4, 6,2]  (5.30)  e P9 = [0, 4, 4, 2,2], e P10 = [0, 5, 8, 4,3] e P11 = [0, 4, 4, 3,2]  5.2.3.4 Impact of additional keys MS and HSS/HAAA generate additional keys when executing mod-INEA, mod-EAPAKA, WiFR and WLFR compared to executing the standard protocols. These additional keys permit the execution of the performance-improved, local re-authentication protocols like WiPAR, WiLR and WLLRv2 in future VHOs. The average numbers of keys generated by all nodes when MS adopts standard protocol (TKS) or proposed protocols (TKP) is found as follows. TK  S  1 m 4 M j = ∑ ∑ RP i ⋅ K P i m j =1i = 1 TK  P  1 m 11 M j = TAK + ∑ ∑ R P i ⋅ K P i m j =1i = 5  (5.31)  (5.32)  where KPi is the number of keys generated by all nodes when performing protocol Pi. Encryption and Integrity keys (EK, IK) derived between MS and ASN-GW in WiLR and MS and WAAA in WLLRv2, are not counted in KPi. This pair of keys is generated once per visit to the ASN domain and the WLAN domain and is not repeatedly generated on every visit. TAK in (5.32) accounts for 163  the maximum possible values of these keys generated by MS, ASN-GW and WAAA. When α = 1 and for a given A, B and nVHO, TAK is found by, TAK = AKWiLR + AKWLLR, where ⎧0.5 ⋅ nVHO , ⎪ ⎪0.5 ⋅ (nVHO − 1) , WiLR ⎪ AK = ⎨0.5 ⋅ (nVHO − 2 ) , ⎪0.5 ⋅ (n VHO + 1) , ⎪ ⎪⎩2B , ∀nVHO = 1,2,...,max (nVHO ), ∀B ≥ 1, α = 1  nVHO < 4 B and nVHO ≡ 0 (mod 4 ) nVHO < 4 B and nVHO ≡ 1 (mod 4 ) nVHO < 4 B and nVHO ≡ 2 (mod 4 ) nVHO < 4 B and nVHO ≡ 3 (mod 4 ) nVHO ≥ 4 B  nVHO < 4 A − 4 and nVHO ≡ 0 (mod 4 ) ⎧0.5 ⋅ nVHO , ⎪0.5 ⋅ (n nVHO < 4 A − 4 and nVHO ≡ 1 (mod 4 ) VHO − 1) , ⎪ WLLR ⎪ nVHO < 4 A − 4 and nVHO ≡ 2 (mod 4 ) = ⎨0.5 ⋅ (nVHO − 2 ) , AK ⎪0.5 ⋅ (n nVHO < 4 A − 4 and nVHO ≡ 3 (mod 4 ) VHO − 3) , ⎪ ⎪⎩2 ⋅ (A − 1), n VHO ≥ 4 A − 4 ∀n VHO = 1,2,...,max(n VHO ), ∀A ≥ 1, α = 1  (5.33)  (5.34)  The number and size of keys generated by MS, HSS and HAAA are also investigated.  5.2.4 Numerical results  A quantitative performance comparison between the proposed and the standard protocols is presented in this section. 38 bytes of IEEE 802.11 frame, EAPoL header and EAP header are included in calculating the size of the messages exchanged in the WLAN link. 21 bytes for IEEE 802.16e medium access control header, PKMv2 header and EAP header are included in calculating the size of messages exchanged in the WiMAX link. 50 bytes of IEEE 802.3 medium access control header, IP header, UDP header and EAP header are included in calculating the size of message exchanged in the wired network. Additionally, 20 bytes of Radius header and 2 bytes per attribute are included. The values of the parameters in (5.28) and (5.29) are listed in Table 4.4 in Chapter 4. Figure 5.11 shows the average emitted re-authentication signaling calculated using (5.24) and (5.25) when varying α and nVHO and setting A and B to 3. Generally, as nVHO increases, our proposed protocols dispatched less signaling traffic compared to the standard protocols. The 164  difference in re-authentication signaling between CS and CP widens as nVHO increases due to the execution of lightweight, fast re-authentication protocols like WiPAR, WiLR and WLLRv2. When nVHO ≥ 2(A – 1), MS starts revisiting WLAN domains in the event of WiMAX to WLAN VHO, hence it executes WLLRv2. This is depicted in Figure 5.11 when nVHO ≥ 4. Similarly, when nVHO ≥ 2B, MS starts revisiting ASN domains in the event of WLAN to WiMAX VHO,  Average Re-authentication Signaling (KB)  hence it executes WiPAR and WiLR. This situation is depicted in Figure 5.11 when nVHO ≥ 6.  40 C  S P  C (α = 1) P  C (α = 2)  30  P  C (α = 3)  20  10  2  4  6  8  10  12  nVHO  Figure 5.11 Average (re-)authentication signaling comparison between standard and proposed protocols  The advantage of adopting our proposed protocols is noticeable as MS performs additional VHOs because HSS and HAAA are no longer contacted on every VHO reauthentication. For example, when nVHO = 6, the difference between CS and CP (α = 1) is 4.5 KB, an elimination of 22% of the (re-)authentication traffic. When nVHO is doubled, the difference increases by a factor of 3.5 recording an elimination of 42% in (re-)authentication traffic. Figure 5.11 also demonstrates the emitted (re-)authentication signaling for different α values. As α increase, more ASN domains share the same PAAA and hence WiPAR is executed instead of WiFR, which results in further reduction in the signaling traffic. Figure 5.12 shows the effect of increasing nVHO, A, B and fixing α to 1 on CP and CS. In all situations, CP outperforms CS. The difference between CP and CS largely widens when either 165  nVHO ≥ 2(A – 1) or nVHO ≥ 2B. In such situations, MS adopting our proposed protocols had presumably visited all ASN and WLAN domains and therefore are more likely to execute WiLR and WLLRv2 in future VHOs.  Average Re-authentication Signaling (KB)  50K  40K  10  30K 30 20K 50 8  10K  6 4  8  12  4  16  2  A and B  nVHO C  P  C  S  Figure 5.12 Average (re-)authentication signaling comparison between standard and proposed protocols when varying nVHO, A and B  The results shown in Figure 5.11 and Figure 5.12 are based on the assumption that MS initially connects to one of the domains in A and performs mod-EAP-AKA as discussed in Section 5.2.3.1. Comparable results are observed when MS initially decides to connect to one of the domains in B and perform mod-INEA instead. Figure 5.13 shows CP for both situations for different α values when A = B = 3. It is noted that there is a slight increase in the signaling traffic emitted by MS when it is initially connected to one of the domains in B, especially when nVHO ≤ 4. In such situations, performing mod-INEA at the beginning of the communication influences the total signaling due to the execution of few VHOs. As shown in Table 4.5 and Table 3.2, more authentication-related messages are emitted when performing mod-INEA compared to modEAP-AKA. Thus, the difference in message signaling between the two protocols stands out and  166  influences the total (re-)authentication signaling considering the few number of VHOs performed. As nVHO increases, CP in both situations displays equivalent results.  Average Re-authentication Signaling (KB)  P  C - A (α = 1) P  C - A (α = 2) P  20  C - B (α = 1) P  C - B (α = 2)  10  2  4  6  8  10  12  nVHO  Figure 5.13 The effect of initially connecting to one of the networks in A or B.  Figure 5.14 shows the average (re-)authentication delays for different α values calculated using (5.31) and (5.32), respectively, with A = B = 3. Our proposed protocols outperform the standard protocols as the frequency of VHOs increases. The gap between TDP and TDS widens as nVHO increases due to revisiting ASN and WLAN domains. Following a similar pattern to the (re)authentication signaling analysis, the difference between TDP and TDS increases when either nVHO ≥ 2(A – 1) or nVHO ≥ 2B. (Re-)authentication delay in TDP (α = 1) is 13% less than TDS when nVHO = 6. The reduction reaches 21% when doubling nVHO. As α increases, the rate at which WiPAR substitutes WiFR increases as well. Since WiPAR introduces less signaling traffic and experiences less delay compared to WiFR, the performance of the proposed protocols improve as α increase. WiPAR undergoes 15% less delay and releases 43% less signaling compared to WiFR. Therefore, the effect of substituting WiFR by WiPAR is more noticeable when analyzing the emitted traffic in contrast to the (re-)authentication latency. Thus, the gap between CP with  167  different α values shown in Figure 5.11 is more significant than the gap between TDP with different α values shown in Figure 5.14.  2.2 TD  S  Average (Re-)authentication Delay (s)  P  TD (α = 1) P  TD (α = 2)  1.8  P  TD (α = 3)  1.4  1  0.6  2  4  6  8  10  12  nVHO  Figure 5.14 Average (re-)authentication delay comparison between standard and proposed protocols  0.5 TDS  Average (Re-)authentication Delay (s)  TDP (α = 1) TDP (α = 2)  2.5  1.5  0.5  3  5 7 Hops between PAAA/WAAA and HAAA  9  Figure 5.15 Average (re-)authentication delay comparison between standard and proposed protocols when varying the number of hops between PAAA/WAAA and HAAA  Figure 5.15 illustrates the effect of varying the number of hops between PAAA/WAAA and HAAA. As expected, TDP undergoes less delay than TDS thanks to executing WiPAR, WiLR and WLLRv2. These protocols are not affected by increasing the number of hops between PAAA/WAAA and HAAA. The slight increase in delay in our proposed protocols is due to 168  performing WiFR and WLFR only because they require contacting HAAA. Figure 5.15 also demonstrates the advantage of performing WiPAR instead of WiFR as the number of hops increases. Less delay is experienced when using WiPAR, i.e., α = 2, compared to when WiPAR is not used, i.e., α = 1. This is because the authentication activity is performed between MS and PAAA and is not affected by the hop increase between PAAA and HAAA. Table 5.3 details the average number of keys produced by the nodes involved in the VHO re-authentication procedure for MSs that adopts standard and proposed protocols when A = B = 3 and α = 1. As nVHO increases, key intensive protocols like WiFR and WLFR are executed less frequently while protocols producing fewer keys like WiLR and WLLRv2 are executed more frequently. Thus the total number and size of keys generated by the proposed protocols is less than those generated by the standard protocols, which implies that our proposed protocols achieve better utilization of available nodal resources. Table 5.3 Numbers and sizes of keys generated in the standard and the proposed protocols  *  nVHO  TKS (Size in byte)  TKP (Size in byte)  HSS+HAAA*  HSS+HAAA+  2  37 (1.3 KB)  40 (1.5 KB)  17 (0.6 KB)  12 (0.4 KB)  4  62 (2.2 KB)  60 (2 KB)  27 (1 KB)  14 (0.5 KB)  6  84 (3 KB)  70 (2.5 KB)  36 (1.4 KB)  15 (0.5 KB)  8  106 (3.8 KB)  84 (2.8 KB)  45 (1.7 KB)  15 (0.5 KB)  10  128 (4.6 KB)  90 (3 KB)  54 (2.1 KB)  15 (0.5 KB)  12  150 (5.4 KB)  100 (3.3 KB)  63 (2.4 KB)  15 (0.5 KB)  Standard Protocol  +  Proposed Protocols  With the increase in nVHO, the difference between the numbers and sizes of keys generated by standard protocols and proposed protocols increases as well. For example, when doubling nVHO from 6 to 12, the difference between standard and proposed protocols in terms of numbers and size of keys increases by a factor of 3. 169  HAAA and HSS control hundreds of thousands of MSs; thus the numbers of keys generated and maintained by them are important. Key generation and maintenance by HSS and HAAA are largely minimized when our proposed VHO re-authentication protocols are adopted, and that is clearly shown in Table 5.3. In our proposed protocols, HSS produces and maintains two keys only per MS regardless of the frequency of performing VHOs. These keys are generated when MS performs either mod-INEA or mod-EAP-AKA. Conversely, HSS in standard protocols consistently produces and maintains two additional keys on average on every VHO operation. Additionally, when all domains are visited, WiFR and WLFR are no longer executed; hence, HAAA does not need to generate fresh keys per VHOs. In Table 5.3, this situation is illustrated when nVHO ≥ 2(A – 1) and nVHO ≥ 2B. The number and size of keys generated by HSS and HAAA remain constant when nVHO ≥ 6 due to the execution of WiLR and WLLRv2, which does not require the generation of new keys by HSS and HAAA. Among all nodes in the heterogeneous network architecture, MS might have the least processing power and storage capacity. The number of keys generated by MS in the standard protocol, nKS, and proposed protocols, nKP, in addition to the size of the keys produced by MS in the standard protocol, SKS, and proposed protocols, SKP, are shown in Figure 5.16. When nVHO = 2, MS adopting our proposed protocols produce more keys in terms of number and size. This is expected since only mod-EAP-AKA and WiFR are performed, which produce exceeding number and size of keys compared to EAP-AKA and INEA. As nVHO increases, nKP and SKP outperform nKS and SKS by producing less number and size of keys. For example, a MS adopting our proposed protocols produce 7 keys less than a MS adopting the standard protocols when nVHO = 6. This number spikes to 25 when doubling nVHO. Likewise, when nVHO = 6, 1.23 KB of key size is generated and stored by a MS adopting our proposed protocols as opposed to 1.48 KB of key size generated by a MS adopting the standard protocol, a size reduction of 17%. When doubling 170  nVHO, the key size reduction jumps to 39%. The analysis in this section clearly demonstrates that our proposed protocols efficiently conserve the resources of MS, HSS and HAAA while performing VHOs.  nK  S  SK  S  nK  P  SK  P  2.5  2 50 1.5  30  1  Size of keys (KB)  Number of Keys  70  0.5 10 2  4  6  8  10  12  nVHO  Figure 5.16 Number and size of keys generated by MS when adopting standard and proposed protocols  5.2.5 Selection of nVHO, nPAR, nLR and nWRv2 values  nVHO records the permitted number of VHOs that MS can perform. The selection of nVHO is challenging and not straightforward because there are several factors that influences the decision to perform a VHO. These factors include user preferences and service availability. Therefore, HAAA must consider all factors influencing VHO decisions when determining a suitable nVHO value. In this section, we rule out user preferences factors and present an algorithm to help selecting a value for nVHO based on service availability. The user must perform modINEA or mod-EAP-AKA when HOK lifetime expires. The 3GHN must be aware of the average time the user spends in an ASN domain or a WLAN domain (Tc) to accurately determine the best value for nVHO. The selection of nLR and nWRv2 depends on nVHO. When nVHO >> nLR or nVHO >> nWRv2, the user could perform additional VHOs because CVHO has a long way to exceed max(CVHO), but it 171  could be forced to perform mod-INEA or mod-EAP-AKA because CLR and CWRv2 could quickly exceed max(CLR) and max(CWRv2). Algorithm 5.2 shown in Figure 5.17 details the suggested technique to select the values of nVHO, nLR and nWRv2 for both the balanced option and the performance oriented option. The values of nLR and nWRv2 also depends on whether the user starts in a WLAN domain, i.e., performs mod-EAP-AKA, or starts in an ASN domain, i.e., performs mod-INEA. Both cases are included in Algorithm 5.2. Algorithm 5.2 Pseudocode for selecting the values of nVHO, nLR and nWRv2  { Variable declarations: } HOK_ lifetime = the lifetime of HOK; max_nVHO = the maximum value that can be assigned to nVHO; min_nVHO = the minimum value that can be assigned to nVHO; b_nVHO = the suggested value of nVHO for a balanced security and performance; p_nVHO = the suggested value of nVHO for more performance over security; Tc = the average time spent by the MS on either WLAN domain or ASN domain %% selection of nVHO %% max_nVHO = HOK_lifetime / Tc; min_nVHO = 1; b_nVHO = (max_nVHO + min_nVHO) / 2 ; p_nVHO = (max_nVHO + b_nVHO) / 2; %% selection of nLR and nWRv2 assuming b_nVHO is selected %% if b_nVHO is even then if mod-EAP-AKA is executed then nLR = (b_nVHO – 2) / 2; nWRv2 = (b_nVHO) / 2; else nLR = (b_nVHO) / 2; nWRv2 = (b_nVHO – 2) / 2; end if else nLR = (b_nVHO – 1) / 2; nWRv2 = (b_nVHO – 1) / 2; end if Figure 5.17 Algorithm for selecting nVHO, nLR and nWRv2 values  nPAR records the frequency of executing WiPAR. The selection of nPAR is based on nVHO, B and α. For the sake of brevity, we suggest an algorithm to select the value of nPAR when α is set 172  to 2 and 3. When α is set to 1, nPAR = 0. When α is set to 2, nPAR takes the values of max(WiPAR) shown in (5.21). Algorithm 5.3 shown in Figure 5.18 describes nPAR selection procedure when α = 3. The values of nVHO and nPAR do not dependent on whether the user performed mod-EAPAKA or mod-INEA.  Algorithm 5.3 Pseudocode for selecting the value of nPAR when α = 3  { Variable declarations: } nVHO = the selected value for nVHO; B = the number of ASN domains if nVHO ≥ 2B – 1 then if B = 1 mod(3) then nPAR = (2B – 2) / 3; else if B = 2 mod(3) then nPAR = (2B – 1) / 3; else nPAR = 2B / 3; end if else if nVHO = 0 mod(3) then nPAR = nVHO / 3; else if nVHO = 1 mod(3) then nPAR = (nVHO – 1 ) / 3; else if nVHO is even then nPAR = (nVHO – 2 ) / 3; else nPAR = (nVHO + 1 ) / 3; end if end if Figure 5.18 Algorithm for selecting nPAR value when α = 3  5.2.6 Security analysis  Three important security requirements must be met during VHOs, firstly, the support of mutual authentication between MS and the target network, secondly, the provision of forward and backward secrecy, and lastly, the protection of MS’s privacy [60], [104], [105].  173  5.2.6.1 Mutual authentication A MS must engage in mutual re-authentication procedure with the target network or a node fully trusted by it after a VHO to defend against impersonation attaches, MITM attacks and rouge AP/BS attacks. Due to the existence of trust agreement between 3GHN, WiMAX CSN, ASN domains and WLAN domains, MS engages in mutual re-authentication with HAAA in WiFR/WLFR, PAAA in WiPAR and ASN-GW/WAAA in WiLR/WLLRv2 on behalf of the target network. In WiFR/WLFR, MS and HAAA perform mutual re-authentication by correctly computing and verifying WiCH/WLCH using (5.4) and WiRP/WLRP using (5.6). A MS computing WiCH/WLCH that is identical to the received WiCH*/WLCH* assures the authenticity of HAAA. On the other hand, computing a WiRP/WLRP by HAAA that is identical to the received WiRP*/WLRP* assures the authenticity of MS. This is because WiCH, WLCH, WiRP and WLRP are calculated with K-auth, which is secretly held by MS and HAAA only. Additionally, computing WiCH/WLCH by HAAA requires the knowledge of MNi – 1 received in a previous session encrypted with K-encr, which is only held by MS and HAAA. Furthermore, computing WiRP/WLRP by MS requires the knowledge of HNi – 1 received in a previous session encrypted with K-encr. Thus, only valid and legitimate MS and HAAA are capable of computing and verifying WiCH, WLCH, WiRP and WLRP. In WiPAR, MS ensures the authenticity of PAAA by correctly computing MAC1WiPAR and matching it against MAC1WiPAR* received from PAAA. Similarly, PAAA ensures the authenticity of MS by correctly computing MAC2WiPAR and matching it against MAC2WiPAR* received from MS. This is because MAC1WiPAR and MAC2WiPAR are calculated using IKPA-MS as shown in (5.11) and (5.12). IKPA-MS is derived using (5.10) and secretly shared by a legitimate MS and PAAA. In WiLR, MAC1WiLR and MAC2WiLR are used to ensure the authenticity of ASNGW and MS, respectively. MAC1WiLR and MAC2WiLR are calculated using IKAS-MS as shown in (5.13) and (5.14). IKAS-MS is derived using (4.8) and secretly shared by MS and ASN-GW only. 174  WLLRv2 shares similar mutual authentication qualities as WLLR presented in Section 3.4.1 in Chapter 3. Our proposed protocols have been tested to confirm the support of mutual reauthentication using the AVISPA security analyzer. Neither security vulnerabilities nor authentication attacks were found after testing WiFR, WiPAR, WiLR and WLFR by OFMC, CL-AtSe and SATMC. 5.2.6.2 Forward and backward secrecy A MS and a target BS/AP share a new fresh key after performing a VHO in our proposed protocols in provision of forward and backward secrecy. Our proposed protocols are designed to produce fresh keys after performing a VHO by including fresh nonces and continuously incremented counters in the key derivation procedures. In WiFR, fresh PAK and PHK are derived by MS and HAAA due to the inclusion of a fresh HNi in the key derivation procedure as shown in (4.1) and (4.2). This ensures that all lower level keys derived from PAK and PHK are fresh as well. In WiPAR, PAK and PHK are reused to derive fresh AAK and AHK. AAK and AHK are fresh due to the inclusion of CPAR in the derivation procedure as indicated by (4.3) and (4.4). Therefore, all keys derived from AAK and AHK for a particular ASN domain are fresh as well. In WiLR, PAK, PHK, AAK and AHK are reused to derive PMKH and AKH. The derived AKH is distinguished from the previously derived AKH in the same ASN domain because of the inclusion of CLR in the key derivation procedures shown in (5.8) and (5.9). In WLFR, fresh DRK and DHK are derived due to the inclusion of a fresh HNi in the key derivation procedure as illustrated by (3.1) and (3.4). Thus, all lower keys derived from DRK and DHK are fresh as well. In WLLRv2, DHK is reused to derive LHK. Nevertheless, the newly derived LHK is distinguished from the previously derived LHK in the same WLAN domain because of the inclusion of CWRv2 in the key derivation procedure as shown in (5.15).  175  5.2.6.3 Protection of MS’s privacy The standard EAP-AKA and INEA protocols are subject to privacy-related attacks due to the revelation of MS-ID whenever VHOs occurs between ASN and WLAN domains. In our proposed protocols, MS-ID is transmitted only once, during the execution of either mod-INEA or mod-EAP-AKA. Fresh temporary identities are employed in subsequent VHO re-authentications to hide MS’s permanent identity. The MS receives a new VHO-IDi from HAAA in mod-EAPAKA, mod-INEA, WiFR and WLFR to be used in future VHOs. A new TPA-IDi is generated using (5.1) by MS and PAAA in mod-INEA and WiFR to be used in future VHOs to a new ASN domains controlled by a PAAA previously visited by MS. A new TASN-IDi is generated by MS and ASN-GW using (5.2) in mod-INEA, WiFR, WiPAR and WiLR executions to be used when revisiting an ASN domain. TASN-IDi derived in mod-INEA, WiFR and WiPAR are always fresh because a fresh AAK and AHK are used in its derivation. In WiLR, the derived TASN-IDi is fresh because TASN-IDi  – 1  is included in its  derivation. A new TWA-IDi is generated by MS and WAAA using (5.3) in mod-EAP-AKA, WLFR and WLLRv2. TWA-IDi is used by MS in future VHOs to a previously visited WLAN domain. In mod-EAP-AKA and WLFR, a fresh TWA-IDi is generated due to the inclusion of a fresh DRK and DHK in the derivation procedure. In WLLRv2, a fresh TWA-IDi is derived due to the inclusion of TWA-IDi – 1 in its derivation procedure.  5.3 Secure and efficient vertical handover re-authentication to 3GPP 5.3.1 Introduction  3GPP subscribers might prefer to perform a VHO from a 3GPP to WLAN/WiMAX system for cheaper services or better service quality. On the other hand, users might prefer switching from WLAN/WiMAX to 3GPP for greater coverage. As performing VHOs between 3GPP and WLAN is more common than between 3GPP and WiMAX, several papers in the 176  literature suggest solutions to improve the VHO procedure between them. 3GPP-WLAN VHO procedure improvements are achieved by either predicting users movements to reduce AP/BS scanning delays [43], [54], [78], or designing improved authentication protocols [81], or authenticating users without contacting the 3GHN [79],[80]. None of the papers mentioned above provide a practical and easy-to-implement solution to reduce authentication delays during VHO without compromising security. The standard 3GPP-AKA protocol is executed by MS following a VHO from WLAN/WiMAX to 3GPP to achieve mutual authentication between MS and HSS. This procedure is highly inefficient. The specifications of 3GPP-AKA [17] included an option to generate k number of AVs (k × AV) to handle k re-authentications between MS and SN before retrieving a new batch of AVs from HSS. This option could speed the VHO procedure from WLAN/WiMAX to 3GPP because the SN is capable of handling user re-authentications without contacting HSS in request for a new AV. The downside to this approach is that a corrupted SN might be vulnerable to the “False Base Station” attack [61]. Such attacks exploit the lack of a binding between AVs and the SN authenticating the MS. Hence, an adversary capable of compromising the SN could exploit the unused AVs and launch a false base station attack in the vicinity of an uncorrupted SN. This might result in establishing false connections with MSs and decrypting the communication channel between MS and SN. Furthermore, MS always supplies its MS-ID when executing 3GPP-AKA as shown in Figure 2.6 in Chapter 2. Such identity disclosure enables adversaries to track user’s movements and might harm user’s privacy. With simple modifications to 3GPP-AKA, an effective re-authentication protocol is designed to improve the performance of VHO re-authentication from WLAN/WiMAX to 3GPP. The Fast 3GPP-AKA Re-authentication protocol (F3AR) is designed to minimize VHO delays and VHO signaling emitted in the network when users perform VHOs from WLAN/WiMAX to 3GPP. 177  5.3.2 Modifications to 3GPP-AKA (mod-3GPP-AKA)  Invoking 3GPP-AKA the first time a MS communicates with a 3GPP BS is inevitable. However, it is inefficient to execute 3GPP-AKA whenever re-authentication is required due to the delay introduced in generating AVs by HSS and MS on one hand and the link delay between SN and HSS on the other hand. Generating k × AV by HSS and delivering them to SN improves the procedure of WLAN/WiMAX to 3GPP VHO but introduces security problems. To remedy these security problems and to reduce re-authentication delays, we propose F3AR that relieves HSS from handling subsequent re-authentications after a single execution of the modified 3GPP-AKA at the beginning of communication. Mod-3GPP-AKA is shown in Figure 5.19 and proceeds as follows:  Figure 5.19 Modified 3GPP-AKA (mod-3GPP-AKA)  1- MS supplies MS-ID in a Registration Request message to SN when entering the 3GPP access network. SN forwards MS-ID to HSS. 2- HSS modifies the derivation of AV shown in (2.1) in Chapter 2 and adds an additional field as shown below. AV = RAND | XRES | CK | IK | AUTN | nF3AR  (5.35)  178  where nF3AR indicates the number of F3AR invocations permitted by HSS before falling back to mod-3GPP-AKA. 3- SN sets the maximum value of F3AR executions, CF3AR, according to nF3AR. Next, it sends a User Authentication Request message to MS that includes RAND, AUTN and nF3AR. nF3AR is encrypted with CK included in the AV. 4- MS derives CK and IK using RAND and AUTN as shown in (2.1) in Chapter 2 and sets CF3AR according to nF3AR. Subsequently, MS calculates RES and forwards it to SN in a User Authentication Response message. Finally MS calculates a temporary key (TK) to secure its communication with SN and generates a temporary F3AR identity (TF-IDi) to be used in future F3AR invocations. TK = KDF2(CK ⊕ IK, RAND | MS-ID | SN-ID |”TK”, 128 )  (5.36)  TF-IDi = KDF2(TK, CF3AR, MS-ID)  (5.37)  where KDF2 is a key derivation function available to MS and SN; and SN-ID is the identity of SN. 5- Upon receiving User Authentication Response message, SN verifies the received RES* and derives a new TK and TF-IDi using (5.36) and (5.37), respectively.  5.3.3 Fast 3GPP-AKA re-authentication protocol (F3AR)  Fast 3GPP-AKA Re-authentication protocol is proposed to reduce the re-authentication delays experienced by a MS and the re-authentication signaling exchanged between SN and the 3GHN during VHOs from WLAN/WiMAX to 3GPP networks. F3AR is depicted in Figure 5.20 and proceeds as follows: 1- When MS performs a VHO from WLAN/WiMAX to a previously visited 3GPP, it supplies TF-IDi – 1 to SN in the Registration Request message.  179  2- SN validates the received TF-IDi – 1* and verifies that CF3AR ≤ max(CF3AR). If all verifications are successful, it generates a fresh nonce, Ni, and MAC1F3AR. SN then issues a F3AR User Authentication Request message that includes Ni, the current CF3AR and MAC1F3AR. Ni and CF3AR are encrypted with TK. MAC1F3AR = HMAC(TK, Ni | CF3AR | TF-IDi – 1)  (5.38)  3- MS receives F3AR User Authentication Request message and matches the received CF3AR* with CF3AR stored in its database. Additionally, it verifies the received MAC1F3AR*. If verification returns positive, MS prepares a F3AR User Authentication Response message which includes its copy of CF3AR and MAC2F3AR. Furthermore, it derives a new CK and new IK keys to secure its future communications with SN. Lastly, MS increments CF3AR and generates a new TF-IDi using (5.37) but replaces MS-ID with TF-IDi – 1. MAC2F3AR = HMAC(TK, Ni + 1 | CF3AR)  (5.39)  newCK = KDF2(CK, Ni | CF3AR | MS-ID | SN-ID | “nCK", 128)  (5.40)  newIK = KDF2(IK, Ni | CF3AR | MS-ID | SN-ID | “nIK", 128)  (5.41)  4- When SN receives the re-authentication response, it verifies CF3AR and MAC2F3AR. If verification returns positive, it derives newCK and newIK, increments CF3AR and derives a new TF-IDi using (5.37) but replaces MS-ID with TF-IDi – 1.  Figure 5.20 Fast 3GPP-AKA Re-authentication (F3AR)  180  The advantage of F3AR is that it relieves HSS from re-authenticating the MS after performing a VHO to 3GPP. This results in a considerable reduction in VHO delay and signaling emission without subjecting the network to security attacks. When SN is compromised, the adversary cannot propagate the damage to other SNs as the case when a compromised SN holds k × AV. In the context of performing VHOs from WLAN/WiMAX to 3GPP, F3AR performs comparably to the case when 3GPP-AKA is adopted and a batch of AVs is sent to SN, but without security vulnerabilities. On the other hand, F3AR preserves similar security qualities as the case when 3GPP-AKA is performed and a single AV is sent to the SN, but with additional privacy protection and enhanced performance.  5.3.4 Performance evaluation  The performances of our proposed mod-3GPP-AKA and F3AR are evaluated in the context of a VHO between 3GPP and WLAN. We assume that the MS is initially connected to a 3GPP and authenticates with HSS by invoking 3GPP-AKA. Subsequently, MS performs repetitive VHOs between WLAN and 3GPP. Figure 5.21 depicts the situation when 4 VHOs are performed between 3GPP and WLAN.  Figure 5.21 Example of MS movement when 4 VHOs are performed between 3GPP and WLAN  The performance evaluation focuses on the (re-)authentication signaling, delay and keys generated during VHOs between 3GPP and WLAN. Four VHO re-authentication scenarios are considered: 181  •  Sn1: In this scenario, MS performs standard protocols specified by 3GPP [17], [34]. MS  performs 3GPP-AKA whenever a VHO to a 3GPP occurs and performs full EAP-AKA (re)authentication whenever a VHO to a WLAN occurs. •  Sn2: In this scenario, MS performs the optional, performance improved features in [17] and  [34]. MS invokes 3GPP-AKA when first entering the 3GPP access network and k × AV are forwarded to SN. In future VHOs to 3GPP, SN retrieves an unused AV and re-authenticates the MS without contacting HSS. In case of VHOs to WLAN, MS performs EAP-AKA the first time and it performs fast EAP-AKA re-authentications in future visits to the WLAN. •  Sn3: In this scenario, MS performs the VHO re-authentication protocols proposed by Kwon  et al. [81]. MS invokes 3GPP-AKA when first entering 3GPP and performs fast reauthentication procedure presented in [81] when revisiting the 3GPP. When MS performs a VHO to the WLAN, EAP-AKA is initially performed followed by fast EAP-AKA reauthentication in future VHOs to the WLAN. •  Sn4: In this scenario, MS performs our proposed VHO re-authentication protocols. It  performs mod-3GPP-AKA when first entering the 3GPP access network followed by F3AR in future VHOs to the 3GPP network. MS performs mod-EAP-AKA when first entering the WLAN network and performs WLLRv2 in future VHOs to the WLAN. The protocols in Sn1 and Sn2 display a tradeoff between security and performance. While the protocols in Sn1 are highly secure, their execution is inefficient due to the requirement to contact the 3GHN on every VHO. Sn2 improves the performance because of the invocation of fast EAP-AKA re-authentication during VHOs to the WLAN and the utilization of unused AVs during VHOs to 3GPP. Nonetheless, delivering k × AV to the SN subjects the interworking architecture to the false base station attacks [61]. In terms of the performance of the standard protocols, the worst case scenario is represented by the protocols in Sn1 while the best case scenario is represented by the protocols in Sn2. 182  Figure 5.22 VHO (re-)authentication protocols in the four scenarios when four VHOs are performed between 3GPP and WLAN  The fast re-authentication protocol proposed by Kwon et al. [81] eliminates the processing delay incurred by f1 – f5 functions as a result of generating a new AV in every VHO re-authentication. However, MS still communicates with HSS to achieve VHO re-authentication and MS uses the same CK and IK keys before and after VHO. Thus, the protocols in Sn3 could display some improvements compared to standard protocols but it doesn’t provide forward and backward secrecy. Figure 5.22 shows the (re-)authentication protocols executed by MS shown in Figure 5.21 for the four VHO re-authentication scenarios. Table 5.4 lists the message sizes, delays and the number of keys generated in 3GPPAKA, fast re-authentication protocol proposed by Kwon et al. [81], mod-3GPP-AKA and F3AR.  183  Similar performance parameters for full EAP-AKA (re-)authentication, fast EAP-AKA reauthentication, mod-EAP-AKA and WLLRv2 protocols are listed in Table 3.2 in Chapter 3. Table 5.4 Values of the performance metrics in 3GPP-AKA, fast re-authentication (Kwon et al. proposal), mod3GPP-AKA and F3AR 3GPP-AKA  Fast re-auth. (Kwon et al. proposal)  Mod-3GPP-AKA  F3AR  Size of message in bytes  612  532  616  260  Delay in milliseconds  48  47  49  38  Total number of keys generated by all nodes Size of the keys generated by all nodes in bytes Number of keys generated by the HSS Size of keys generated by the HSS in bytes Number of keys generated by the MS Size of keys generated by the MS in bytes  4  0  6  4  64  0  96  64  2  0  2  0  32  0  32  0  2  0  3  2  32  0  48  32  Figure 5.23 displays the signaling emitted by the protocols in the four scenarios when multiple VHOs are performed between WLAN and 3GPP. We assume that nF3AR is set to half of the number of VHOs. Thus, MS adopting the protocols in Sn4 executes mod-3GPP-AKA only once and executes F3AR in subsequent VHOs to 3GPP. Similarly, we assume that k = nF3AR; thus, MS adopting the protocols in Sn2 executes 3GPP-AKA once and executes 3GPP-AKA with unused AVs in subsequent VHOs to 3GPP. When few VHOs are performed, the protocols in the four scenarios display comparable results. As the number of VHOs between 3GPP and WLAN increases, our proposed protocols, i.e., Sn4, outperforms the competing protocols thanks to the repetitive execution of the lightweight F3AR and WLLRv2 protocols. Our proposed protocols achieve 43% and 32% performance improvement compared to the protocols in Sn1 and Sn3, respectively, when 6 VHOs are performed. The performance improvement reaches 55% and 43% compared to Sn1 and Sn2 when 12 VHOs are performed. 184  (Re-)authentication Signaling (KB)  20  Sn1 Sn2 Sn3 Sn4  15  10  5  2  4 6 8 10 Number of VHOs between 3GPP and WLAN  12  Figure 5.23 Comparison between Sn1, Sn2, Sn3 and Sn4 in terms of (re-)authentication signaling during VHOs between 3GPP and WLAN  (Re-)authentication Delay (s)  1.4  1  Sn1 Sn2 Sn3 Sn4  0.6  0.2  2  4 6 8 10 Number of VHOs between 3GPP and WLAN  12  Figure 5.24 Comparison between Sn1, Sn2, Sn3 and Sn4 in terms of (re-)authentication delay during VHOs between 3GPP and WLAN  Figure 5.24 shows the (re-)authentication delay experienced by a MS when performing multiple VHOs and adopting the four scenarios. Lower delays are experienced when adopting Sn4 compared to other scenarios. The protocols in Sn4 continue to perform outstandingly as more VHOs are performed. A MS adopting Sn4 experiences 22% and 14% reduction in the (re)authentication delay during VHOs compared to adopting Sn1 and Sn2, respectively. Table 5.4 lists the numbers and sizes of keys generated by different nodes involved in the VHO re-authentication procedure in mod-3GPP-AKA and F3AR protocols. Although additional 185  keys are generated in mod-3GPP-AKA compared to standard 3GPP-AKA, this additional key generation is important to secure the execution of F3AR. A serious security problem suffered by Kwon’s proposal [81] is the lack of forward and backward secrecy. This explains the fact that no keys are generated by MS and HSS during a VHO as shown in Table 5.4. Hence, Sn3 is not included in analyzing the number and size of keys generated during VHO re-authentication procedures. Table 5.5 lists the numbers and sizes of keys generated by all nodes when MS adopts Sn1, Sn2 and Sn4 while performing 2, 6, 10, 14 and 18 VHOs. In Table 5.5, nK indicates the number of keys and KS indicates the size of the keys generated. It is noted that Sn4 produces more keys compared to Sn1 and Sn2 when few VHOs are performed. This is understandable because mod-3GPP-AKA and mod-EAP-AKA are executed when initially visiting 3GPP and WLAN, respectively. Table 5.5 Number and size of keys generated by all nodes in Sn1, Sn2 and Sn4 Sn1 Number of VHOs  Sn2  Sn4  nK  KS (KB)  nK  KS (KB)  nK  KS (KB)  2  20  0.5  20  0.5  34  0.9  6  52  1.5  40  1.3  46  1.4  10  84  2.5  60  2  58  1.7  14  116  3.5  80  2.7  70  2.1  18  148  4.5  100  3.4  82  2.5  Mod-3GPP-AKA and mod-EAP-AKA produce more keys compared to standard 3GPPAKA and EAP-AKA as shown in Table 5.4 and Table 3.2. The protocols in Sn4 end up producing fewer keys compared to the protocols in Sn1 and Sn2 as the frequency of performing VHOs increases. When performing a VHO to 3GPP, Sn1, Sn2 and Sn4 produce comparable  186  number of keys; however, when performing a VHO to WLAN, Sn4 cuts on the number and size of keys generated thanks to the execution of WLLRv2. Figure 5.25 shows the number and size of keys produced by HSS during VHOs. It is obvious that the protocols in Sn4 conserve the resources in HSS and produce the least number of keys. In Sn4, HSS produces keys only when mod-3GPP-AKA and mod-EAP-AKA are executed. HSS does not generate keys when F3AR and WLLRv2 are executed. Therefore, HSS is not involved in re-authenticating the MS or generating new keys when VHOs are performed. In the contrary, HSS produces new keys on every VHO operation in Sn1 and Sn2.  KS - Sn1 KS - Sn2 KS - Sn4  320  14  192  Key Size (Byte)  Number of Keys  24  nK - Sn1 nK - Sn2 nK - Sn4  64 4 2  4 6 8 10 Number of VHOs between 3GPP and WLAN  12  Figure 5.25 Number and size of keys generated by the HSS during VHO re-authentications in Sn1, Sn2 and Sn3  In Sn4, the number and size of keys produced by HSS are reduced by a factor of 3.5 and 2.5 compared to Sn1 and Sn2, respectively, when 6 VHOs are performed. When doubling the number of performed VHOs, the reduction factors reach 6.5 and 4, respectively. When tripling the number of VHOs, the reduction factors reach 9.5 and 5.5, respectively. The number of keys produced by MS indicates the key maintenance overhead required during VHOs. The size of keys produced by MS indicates the key computation and storage overhead required during VHOs. Figure 5.26 displays the number and size of keys generated by 187  MS when adopting Sn1, Sn2 and Sn4. In terms of the number of keys generated, MS adopting Sn4 produces more keys compared to Sn1 when the number of performed VHOs is less than 14. MS produces more keys compared to Sn2 when less than 18 VHOs are performed. This behavior is due to the execution of mod-EAP-AKA during the first VHO to WLAN.  nK - Sn1 nK - Sn2 nK - Sn4  3.5  KS - Sn1 KS - Sn2 KS - Sn4  60  2.5  40  1.5  Key Size (KB)  Number of Keys  80  20 0.5  2  6 10 14 18 Number of VHOs between 3GPP and WLAN  22  Figure 5.26 Number and size of keys generated by MS during VHO re-authentications in Sn1, Sn2 and Sn4  12 keys are produced by MS during mod-EAP-AKA whereas half of that number is produced when standard EAP-AKA is executed as shown in Table 3.2. This escalates the number of keys generated by MS. The number of keys produced by MS in Sn1, Sn2 and Sn4 evens out when additional WLLRv2 executions occur. MS produces the same number of keys in Sn1, Sn2 and Sn4 during VHOs to the 3GPP. In terms of the size of the keys generated, MS adopting Sn4 requires 6 VHOs only to produces less key sizes compared to Sn1 and Sn2. This analysis shows that the key computation and storage overhead in Sn4 outperforms Sn1 and Sn2 provided that more than 6 VHOs are performed. Additionally, proposed protocols efficiently preserve the computation and storage resources in MS compared to standard protocols. Similar to the selection of nVHO, the selection of adequate nF3AR value is not straightforward because MS could perform a VHO to 3GPP based on user preferences and not 188  service availability. MS is enforced to execute mod-3GPP-AKA when CF3AR > max(CF3AR) or when CK/IK lifetime expires. If it is assumed that MS performs VHOs to 3GPP solely based on service availability, HSS must determine the average time spent by MS in 3GPP network and WLAN/WiMAX network, Tu. Algorithm 5.4 shown in Figure 5.27 is suggested to select an appropriate value for nF3AR. Algorithm 5.4 Pseudocode for selecting nF3AR  { Variable declarations: } CK/IK_ lifetime = the lifetime of CK/IK; max_nF3AR = the maximum value that can be assigned to nF3AR; min_nF3AR = the minimum value that can be assigned to nF3AR; b_nF3AR = the suggested value of nF3AR for a balanced security and performance; p_nF3AR = the suggested value of nF3AR for more performance over security; Tu = the average time spent by MS on a 3GPP network or a WLAN/WiMAX network %% selection of nF3AR %% max_nF3AR = CK/IK_lifetime / Tu; min_nF3AR = 1; b_nF3AR = (max_nF3AR + min_nF3AR) / 2 ; p_nF3AR = (max_nF3AR + b_nF3AR) / 2;  Figure 5.27 Algorithm for selecting the value of nF3AR  5.3.5 Security analysis  In this section we briefly analyze the security of F3AR in terms of; firstly, providing mutual authentication service, secondly, the provision of forward and backward secrecy, and thirdly, the protection of MS’s privacy during VHOs. F3AR provides mutual authentication service between MS and SN to protect against impersonation attacks and MITM attacks. HSS and SN share a mutual trust relationship allowing HSS to delegate authentication operation to SN. SN and MS mutually authenticate each other by proving the possession of correct CF3AR and TK in addition to receiving a correct MACF3AR.  189  MS authenticates SN by receiving a correct CF3AR and MAC1F3AR in F3AR User Authentication request message. A correct validation of MAC1F3AR by MS implies that SN and MS share the same TK. This fact aids in MS’s conviction that it is communicating with a legitimate SN. Likewise, SN authenticates MS and ensures its legitimacy to use the service by correctly matching the computed MAC2F3AR with MAC2F3AR* received in F3AR User Authentication response message. The provision of mutual authentication between MS and SN by F3AR has been tested using OFMC, Cl-AtSe and SATMC security analysis and verification servers available in AVISPA. All tests show positive results and no authentication attacks were found. Security keys in F3AR are distributed to the minimum number of nodes possible. TK, newCK and newIK are never shared between different SNs or between different MSs. Furthermore, newCK and newIK are never reused after performing a VHO to achieve forward and backward secrecy of keys. newCK and newIK are derived using (5.40) and (5.41), respectively. From the equations, a new nonce and a continuously incremented counter are always included in the derivation of newCK and newIK. This distinguishes the keys derived after performing VHOs to 3GPP and helps defend against domino effect problems affecting key distribution schemes. The protocols in Sn1 and Sn2 are subject to privacy-based attacks due to the disclosure of MS-ID on every VHO to 3GPP. F3AR protocol provides an adequate MS privacy protection. A new temporary identity is derived by MS and SN after every F3AR execution, derived using (5.37). This temporary identity conceals MS’s real identity and impedes attempts to track its movement. The protocols in Sn3 provides a privacy protection by mandating the usage of a specific re-authentication identity generated by HSS (in case of VHO to 3GPP) and by HAAA (in case of VHO to WLAN). Despite that, Sn3 lacks the support of forward and backward secrecy. 190  5.4 Summary In this Chapter, we have proposed a set of fast and secured VHO re-authentication protocols to reduce VHO delay and minimize re-authentication signaling during WiMAXWLAN VHOs performed by 3GPP subscribers. The proposed protocols are designed to handle different VHO scenarios between WiMAX and WLAN following the execution of either modEAP-AKA or mod-INEA. In the event of WLAN to WiMAX VHO, WiFR is executed when a new ASN domain is visited; WiPAR is executed when a new ASN domain controlled by a PAAA that shares a security association with MS is visited while WiLR is executed when an ASN domain is revisited. In the event of WiMAX to WLAN VHO, WLFR is executed when a new WLAN domain is visited and WLLRv2 is executed when the WLAN domain is revisited. F3AR has been also proposed in this Chapter to achieve efficient VHOs from WLAN/WiMAX to 3GPP. A simple modification to the standard 3GPP-AKA has been suggested to enable the execution of F3AR in subsequent VHOs to 3GPP. Our proposed protocols perform VHO re-authentication with minimum interaction with the authentication servers in the 3GHN. This results in drastic reductions in the re-authentication delay as well as the re-authentication signaling emitted due to the VHO procedure. In addition, our proposed protocols conserve the resources of essential nodes in the architecture like authentication servers in 3GHN and MS. The proposed protocols maintain a high quality of security properties and support essential security features required during a VHO operation.  191  Chapter 6: Efficient and secure multi-hop Mobile IP registration scheme for MANET-Internet interworking∗ 6.1 Introduction A MANET is a self organized, self configured network of wireless devices suited for applications that require instant on-demand communications. MSs in the MANET employ multihop relaying techniques to exchange messages. These MSs are not reachable by nodes in the Internet. MIP2 [13] is a mobility protocol widely deployed to grant Internet reachability to nodes visiting foreign wired and wireless networks. Adding MIP capabilities to MANETs permits Internet reachability. The MANET-Internet Interworking (MII) architecture is shown in Figure 2.5 in Chapter 2. As explained in Section 2.2.5 in Chapter 2, the MII architecture includes two important gateways, the Internet Gateway (IG), also known as the Foreign Agent (FA) in MIP terminology, and the Authentication Gateway (AG). A newly joined MS residing outside the communication range of the wireless BS requires performing a secure multi-hop authentication with the AG. In addition, a secure multi-hop MIP registration scheme that includes a secure multi-hop FA discovery and CoA registration procedure with the Home Agent (HA) is required. Intermediate nodes in the MANET residing within the coverage area of the BS relay the communications between the visiting MS and the BS. Several papers in the literature proposed a secure multi-hop MIP registration scheme [87], [88], [94]. The proposed schemes depend on asymmetric key operations such as utilizing digital signatures and verifications, which might entail heavy processing burden on MSs and require sophisticated Digital Certificate (DC) management. These problems lead to considerable  ∗ Parts of this Chapter will be presented in IEEE Wireless Communications and Networking Conference (IEEE WCNC 2010) [116]. In addition parts of this Chapter have been presented in the 7th Annual IEEE Consumer Communications and Networking Conference (IEEE CCNC 2010) [117]. 2 The acronym MIP refers to the Mobile IPv4 protocol. The Mobile IPv6 protocol is acronymed as MIPv6  192  increase in MIP registration delay, energy consumption and might be infeasible to implement, especially in a very dynamic and active MANET environments. We propose a secure and efficient multi-hop MIP registration scheme. Our proposed scheme is based on symmetric key operations; therefore it is faster and more feasible than the schemes proposed in [87], [88], and [94]. Since authenticating a newly joined MS is a prerequisite for gaining network and Internet access, we propose a multi-hop authentication protocol as well. Security keys derived from the authentication protocol are used to secure the MIP registration scheme. In addition, we present extensions to our proposed scheme to secure multi-hop Mobile IPv6 (MIPv6) [118] registration to accommodate MSs employing IPv6. MSs adopting our proposed scheme experience reduced MIP registration delays and requires less computation energy compared to the schemes in [87], [88] and [94], due to the absence of processing and power demanding asymmetric key operations. The scheme proposed in this chapter is applicable over the heterogeneous wireless network described in Chapter 2. Additionally, the multi-hop authentication protocol proposed in this chapter is interoperable with mod-EAP-AKA presented in Chapter 3 and mod-INEA presented in Chapter 4. Therefore, a visiting MS residing outside the communication range of the BS and trying to access the heterogonous wireless network can utilize the execution of modEAP-AKA/mod-INEA and the MIP scheme proposed in this chapter to access the heterogeneous network and the Internet over a multi-hop environment. The remainder of this Chapter is organized as follows. In Section 6.2, we present our proposed scheme. In Section 6.3, we compare the performance of our proposed scheme against competitive schemes in the literature. In Section 6.4, we analyze the security of our proposed scheme. Section 6.5 summarizes the Chapter.  193  6.2 Proposed scheme A secure and efficient MIP registration scheme is proposed. The scheme is applicable to any on-demand MANET routing like AODV [82] and DSR [83]. It supports single hop and multi-hop connectivity and it is independent of the underlying wireless technology. The AG in the MII architecture does not hold security credentials of the visiting MS. Thus, the AG relays authentication queries to HAS located in the home network of the visiting MS. We propose a multi-hop authentication protocol between the visiting MS and the HAS as well. HAS is a central entity trusted by the visiting MS, HA, and AG. HAS and HA could be collocated in the same device in practical implementations but they are treated separately here. The visiting MS could access the heterogeneous wireless network using wireless multi-hop methods. In such situations, HAS could be located in the 3GHN and thus share a long term security association with 3GPP subscribers holding an authentic USIM/UICC. We propose coupling the authentication activity with the MIP registration procedure. Therefore, some of the keys derived during authentication are used to secure the MIP registration procedure. Following a successful authentication, MIP keys are distributed by HAS to HA and FA. These keys are concurrently derived by MS. This rekeying activity takes place whenever the MS visits a new foreign IP network to renew the key it shares with HA and limit key disclosure attacks. Typically, authentication messages exchanged between MS and HAS are carried by EAP. We propose modifying the traditional EAP session between MS and HAS to include the exchange of fresh nonces. In addition, MS supplies the identity or the IP address of the HA to signal its desire to utilize MIP services. As a result, HAS computes a Top HA Key (THAK) and forwards it to both HA and FA. THAK is used by HA and FA to derive a shared secret key to protect the communications between them. By the successful completion of an EAP session, the visiting MS and HAS share MSK, EMSK and TEK as per EAP key management specifications [100]. We propose using EMSK to derive MIP related keys. In describing some parameters like 194  nonces and authentication challenges, an asterisk superscript, (*), is attached to a parameter that is recently received. The receiver usually compares the recently received parameter with an identical parameter that it holds or computes.  6.2.1 Secure single hop MIP registration  A visiting MS entering a new foreign IP network uses EMSK to derive Top MIP Key (TMK) and FA-level MIP Key (FMK). These keys are also derived by HAS as follows. TMK = f(EMSK, NHAS | N1MS1 | IDHA | IDMS1 | “TMK”, 128)  (6.1)  FMK = f(TMK, IDAG | IDMS1 | “FMK”, 128)  (6.2)  where NHAS and N1MS1 are nonces generated by HAS and MS, MS1 in Figure 6.1, and exchanged in the last modified EAP session. NHAS and N1MS1 are encrypted during transmission with TEK. IDMS1 is an identity that uniquely identifies MS1 to HAS. If HAS is the HSS, IDMS1 could be derived from IMSI. After a successful authentication, HAS forwards TMK, THAK and IDMS1 to HA and forwards FMK, THAK, IDHA and IDMS1 to AG, which relays this message to all FA’s under its jurisdiction.  Figure 6.1 Secure single hop authentication and single hop MIP registration 195  A lookup table is created by each FA containing two entries; the first entry includes IDMS1 and the corresponding FMK while the second entry includes IDHA and the corresponding THAK. MS1 could receive advertisements from FAs containing a list of CoAs. However, the advertisements must not be trusted because they could be sent by forged FAs. Hence, MS1 launches a secure FA discovery and CoA registration procedure that proceeds as follows: 1- Initially, MS1 generates N2MS1 and derives a solicitation key (Ksol1). An FA discovery request (FA_Req) message is broadcasted to all neighboring FAs. The content of the message is protected with a Message Authentication Code (MAC). MS1 Æ FA : FA_Req = { M1, FA_Address, <M1>Ksol1 } where, M1 = { IDMS1, IPMS1, N2MS1, t }, FA_Address is the All Mobility Agents multicast group address [13], set to 224.0.0.11 and Ksol1 is derived as shown below. Ksol1 = f(FMK, N2MS1 | IDMS1 | “KSOL”, 128)  (6.3)  2- Each FA receives FA_Req message and checks the timestamp, t*, and N2MS1* to ensure the freshness of the request. The FA holding FMK corresponding to IDMS1 derives Ksol1 using (6.3). Subsequently, FA validates <M1>Ksol1* to ensure the authenticity of MS1. Lastly, FA generates N1FA and replies to the request. FA Æ MS1: FA_Rep = { M2, <M2>Ksol1 } where M2 = { M1, IDFA, List of CoAs, N1FA, t } 3- MS1 selects a specific FA if multiple replies are received. It validates the freshness of the reply by inspecting t* and N1FA* against their counterpart in the latest reply messages received. Next, MS1 matches M1* in FA_Rep against M1 included in FA_Req and validates the received <M2>Ksol1* to confirm FA’s authenticity. If all validations are successful, it selects a CoA from the list, computes N3MS1, and computes a shared key with the selected FA (KFA1) and a shared key with HA (KHA1). Finally, MS1 sends a registration request (R_Req) to FA and HA. 196  KFA1 = f(FMK, N2MS1 | N1FA | IDFA | IDMS1 | “KFA”, 128)  (6.4)  KHA1 = f(TMK, N3MS1 | IDHA | IDMS1 | “KHA”, 128)  (6.5)  MS1 Æ FA: R_Req = { P1, <P1>KFA1 } where P1 = { M3, <M3>KHA1, N1FA, t } and M3 = { IDMS1, IDFA, IDHA, IPMS1, CoA, N3MS1 } 4- FA receives R_Req message and checks t*, validates that N1FA* is similar to the one sent in FA_Rep and derives KFA1 using (6.4). Subsequently, it validates <P1>KFA1*. If this is the first communication with HA or if the key it shares with it (KHA-FA) has expired, the FA extracts THAK correspondent to IDHA and derives a new KHA-FA. Finally, FA generates N2FA and relays the request to HA. KHA-FA = f(THAK, N2FA | IDHA | IDFA | “KHAFA”, 128)  (6.6)  FA Æ HA: HA-R_Req = { P2, <P2>KHA-FA } where P2 = { M3, <M3>KHA1, N2FA, t } 5- HA receives HA-R_Req message and validates t* and N2FA* to ensure the freshness of the request. It derives KHA-FA using (6.6) and validates <P2>KHA-FA* to ensure FA’s authenticity. Consequently, it extracts IDMS1* from M3 and looks up the corresponding TMK to derive KHA1 using (6.5). Then, HA validates <M3>KHA1* to verify MS1’s authenticity and registers MS1’s new CoA in the binding list. Lastly, it computes N1HA and replies to the request with the HA-R_Rep message. HA Æ FA: HA-R_Rep = { P3, <P3>KHA-FA } where P3 = { M4, <M4>KHA1, N2FA, t } and M4 = { Registration Result, N1HA, M3 } 6- FA receives HA-R_Rep message and checks t*, verifies that N2FA* is similar to the one sent in HA-R_Req and validates <P3>KHA-FA* to authenticate the HA. FA also generates N3FA and relays the reply to MS1. 197  FA Æ MS1 : R_Rep = { P4, <P4>KFA1 } where P4 = { M4, <M4>KHA1, N3FA, t } 7- MS1 receives R_Rep message, checks t* and matches N3MS1* received in M3 inside M4 to the one included in R_Req message. It also validates FA’s authenticity by computing <P4>KFA1 and comparing it against the received <P4>KFA1*. Finally, MS1 validates N1HA* in M4 and HA’s authenticity by computing <M4>KHA1 and validating it against the received <M4>KHA1*.  6.2.2 Multi-hop authentication protocol  The visiting MS must be authenticated by AG and HAS to gain access to the wireless network and the Internet. A new multi-hop authentication protocol is proposed for MSs residing outside the coverage area of the BS. In Figure 2.5, MS3 is outside BS’s coverage area. In an attempt to join the wireless network, MS3 launches an EAP session with AG and HAS through MSs residing within BS’s range like MS1, MS2, MS4 and MS5. Since EAP messages alone are not routable in the wireless link, we propose adopting the Protocol for carrying Authentication for Network Access (PANA) [119] to carry EAP messages between MS3 and BS. PANA is a client-server protocol designed to carry any EAP method between a client and an authentication server regardless of the underlying access technology. PANA is designed to carry EAP messages over IP; hence it is suitable for multi-hop authentication due to the absence of a direct link between MS3 and BS. There are three functional entities in PANA •  PANA Client (PaC): is the client side of the protocol residing in the MS attempting to access the network.  •  PANA Authentication Agent (PAA): is the entity responsible for verifying the credentials supplied by PaC and determines PaC’s eligibility to access the network. In some network  198  architectures, PAA could offload MS’s credential verification to a back-end authentication server. •  Enforcement Point (EP): is an entity in the access network that blocks data traffic originated from unauthenticated clients attempting to access the network. Limited types of traffic originated from unauthenticated clients are allowed to pass through the EP including PANA traffic and Dynamic Host Configuration Protocol (DHCP) traffic. When authentication is granted, PAA signals EP to permits the authenticated client to send/receive data traffic to/from the access network. In MII architecture depicted in Figure 2.5, MS3 represents the PaC, the role of PAA is  played by AG, the role of the back-end authentication server is played by HAS and BS represents the EP. In PANA, PaC initially starts a DHCP discovery process to obtain the IP address of PAA, IPPAA [120]. Subsequently, PANA messages carrying an EAP method are exchanged between PaC and PAA. After obtaining IPPAA, MS3 forwards PANA messages to PAA with the help of intermediate MSs residing within the coverage area of the BS like MS1 and MS2. EAP messages are carried between PAA and HAS over AAA protocols like Radius. An example of a PANA session where EAP-AKA method is used is shown in Figure 6.2. Consequent a successful PANA session, MS3 and HAS mutually authenticate each other and share a new MSK, EMSK and TEK. MS3 and HAS derive TMK and FMK from EMSK using (6.1) and (6.2). Finally, HAS forwards FMK to AG and FA.  199  Figure 6.2 Multi-hop authentication protocol based on EAP-AKA protocol  6.2.3 Secure multi-hop MIP registration  To signal its desire for Internet connectivity, MS3 sends IDHA to HAS during the PANA session as shown in Figure 6.2. Since MS3 is not within a direct communication range with BS and FA, a secure multi-hop FA discovery and CoA registration is required. MS3 broadcasts FA_Req message to intermediate MSs in search for a FA. In Xie’s scheme [88], intermediate nodes must obtain a DC from the FA, i.e., they must complete the MIP registration scheme, to participate in the multi-hop FA discovery. Kandikattu’s scheme mandates the existence of a pairwise key shared between intermediate nodes to participate in the multi-hop FA discovery and CoA registration procedures. Similarly, only intermediate nodes that have completed MIP registration and share a valid Ksol and KFA with FA could participate in our proposed multi-hop FA discovery and CoA registration procedures. Figure 6.3 depicts the messaging sequence of the proposed multi-hop FA discovery and CoA registration procedures. FA discovery is initiated by MS3 and relayed to FA by MS2 and  200  MS1, which are assumed to hold valid Ksol and KFA keys with FA. MS3 starts the multi-hop FA discovery and CoA registration procedures as follows:  Figure 6.3 Proposed secure multi-hop MIP registration scheme  1- MS3 generates N2MS3, derives Ksol3 using (6.3) and broadcasts FA_Req message to all neighboring MSs. Intermediate MSs holding a valid Ksol rebroadcast the request. We assume that MS2 and MS1 are the intermediate nodes in the path to FA. MS3 Æ MS2: FA_Req = { M1, FA_Address, <M1>Ksol3 } where M1 = { IDMS3, IPMS3, N2MS3, t } 2- MS2 receives the request and checks t* and N2MS3* to determine whether the request is fresh or a duplicate of an earlier request. Then, it appends its IP address as a route record and calculates a keyed MAC on it and rebroadcasts the request to its neighbors. Including a MAC is important for the FA to authenticate MS2. MS2 Æ MS1: RelMS2-FA_Req = { FA_Req, S1 } where S1 = { (* IPMS2 *), <IPMS2>Ksol2 } 3- The message reaches MS1 which also verifies the freshness of the request and appends its IP address as a route record and relays the request to FA. MS1 Æ FA: RelMS1-FA_Req = { RelMS2-FA_Req, S2 } 201  where S2 = { (* IPMS1 *), <IPMS1>Ksol1 } 4- FA receives the request and checks t* and N2MS3* to ensure its freshness. Subsequently, it validates <IPMS1>Ksol1*, <IPMS2>Ksol2* and <M1>Ksol3* to ensure the authenticity of MS1, MS2 and MS3, respectively. Since the request was originally broadcasted by MS3, FA could receive multiple copies of the request that traveled different paths. For example, this request could travel to FA through MS4 and MS5 when considering the MII architecture in Figure 2.5. In such a scenario, FA compares the routes and selects the best route to MS3 among the routes that passed the security validation. Best route selection is based on pre-defined parameters like the least number of hops or the minimum delay. Following a route selection, FA generates N1FA and prepares FA_Rep message. FA Æ MS1: FA_Rep = { M2, <M2>Ksol3, R, <R>Ksol2, <R>Ksol1 } where M2 = { M1, IDFA, List of CoA, N1FA, R, t } and R is the secure route record from MS3 to FA, R = (* IPMS3, IPMS2, IPMS1, IPFA *) 5- MS1 receives FA_Rep message and validates <R>Ksol1* to confirm the integrity of the route record and the authenticity of FA. Following that, MS1 stores R in its routing cache, prepares RelMS1-FA_Rep message and sends it to the next hop indicated by R, in this case its MS2. MS1 Æ MS2: RelMS1-FA_Rep = { M2, <M2>Ksol3, R, <R>Ksol2 } 6- MS2 receives RelMS1-FA_Rep message from MS1 and validates <R>Ksol2* to ensure the integrity of the route record and the legitimacy of the FA. MS2 Stores R in its routing cache and relays the message to MS3. MS2 Æ MS3: RelMS2-FA_Rep = { M2, <M2>Ksol3 } 7- MS3 receives RelMS2-FA_Rep message and validates t* and N1FA* to ensure its freshness. It also validates <M2>Ksol3* to ensure that the reply came from a legitimate FA. Subsequently, MS3 extracts R from M2 and updates its routing table and selects a CoA.  202  8- To register the CoA, MS3 sends a registration request message to FA through the intermediate nodes indicated by R. Initially, MS3 generates N3MS3 and derives both KFA3 and KHA3 using (6.4) and (6.5). MS3 Æ MS2: R_Req = { P1, <P1>KFA3 } where P1 = { M3, <M3>KHA3, N1FA } and M3 = { IDMS3, IDFA, IDHA, IPMS3, CoA, N3MS3 } 9- Every MS in the route between MS3 and FA appends a new nonce and a MAC value covering the nonce. In our example, the registration request is relayed to FA through MS2 and MS1. MS2 Æ MS1: RelMS2-R_Req = {R_Req, NMS2, <NMS2>KFA2} MS1Æ FA: RelMS1-R_Req={RelMS2-R_Req, NMS1, <NMS1>KFA1} 10- FA receives RelMS1-R_Req from MS1 and verifies that N1FA* is identical to the one included in FA_Rep messages. FA also validates <NMS1>KFA1* and <NMS2>KFA2*. Subsequently, it derives KFA3 using (6.4) and validates <P1>KFA3* to ensure that the registration request came from MS3. FA generates N2FA and derives KHA-FA using (6.6), if not previously derived. Finally, it sends HA-R_Req message to HA. FA Æ HA: HA-R_Req = { P2, <P2>KHA-FA } where P2 = { M3, <M3>KHA3, N2FA, t } 11- HA receives HA-R_Req message and follows a procedure similar to step 5 in the single hop MIP registration scheme described in Section 6.2.1. HA replies to the registration request with HA-R_Rep message. HA Æ FA: HA-R_Rep = { P3, <P3>KHA-FA } where P3 = { M4, <M4>KHA3, N2FA, t } and M4 = { Registration Result, N1HA, M3 }  203  12- FA receives HA-R_Rep message and follows a procedure similar to step 6 in the single hop MIP registration scheme described in Section 6.2.1. FA increments each nonce received from each intermediate node and includes the new nonces and their MACs in R_Rep message. FA Æ MS1: R_Rep = { P4, <P4>KFA3, NMS2 + 1, <NMS2 + 1>KFA2, NMS1 + 1, <NMS1 + 1>KFA1 } where P4 = { M4, <M4>KHA3, N3FA } 13- MS1 receives R_Rep message and validates <NMS1 + 1>KFA1* and relays R_Rep message to MS2. MS1 Æ MS2 : RelMS1-R_Rep = { P4, <P4>KFA3, NMS2 + 1, <NMS2 + 1>KFA2 } 14- MS2 receives RelMS1-R_Rep message from MS1, validates <N1MS2 + 1>KFA2* and relays the reply to MS3. MS2 Æ MS3 : RelMS2-R_Rep = { P4, <P4>KFA3 } 15- MS3 receives RelMS2-R_Rep message and verifies <P4>KFA3* and <M4>KHA3* in M4 to authenticate FA and HA, respectively.  6.2.4 Secure multi-hop mobile IPv6 registration  When a MS employs the traditional MIP procedure, a CoA is acquired from the FA. In MIPv6, the MS can self configure a CoA thanks to the increased address space and the stateless address autoconfiguration feature provided by IPv6; hence, getting a CoA from FA is no longer necessary. Several interworking techniques between MANET and MIPv6 have been proposed in the literature [121], [122], [123]. For simplicity, the interworking architecture between the Internet and MANETs deploying MIPv6 are henceforth referred to as the MIIv6 architecture. Xi and Bettstetter [121] introduced the concept of Access Routers (AR) to function as Internet access gateways. MSs connected to an AR must configure their IP address based on the prefix of the AR, thus forming an IP subnet. MSs receive periodic AR prefix advertisements and could actively initiate AR discovery processes to obtain the prefix. Internet Gateways (IGs) are 204  introduced in [122] to function as a broker between the MANET and nodes in the Internet. IGs are IPv6 nodes that offer global addressability and bidirectional Internet connectivity to MSs in the MANET. Similar to the work in [121], MSs configure their IP addresses based on the IGs prefix. Although acquiring a CoA from FA is no longer required in the MIIv6 architecture, the existence of an Internet access gateway like AR in [121] and IG in [122] is essential to link the MANET to the Internet. Such a gateway is hereafter referred to as the IG. The techniques proposed in [121], [122] and [123] assume that all nodes in the MANET are willing to faithfully participate in message forwarding. Hence, they lack adequate security protections for the multi-hop MIPv6 registration messages and are subject to a variety of security attacks. MIPv6 specifications [118] describe the use of IPv6 security headers like the Authentication Header and the Encapsulated Security Payload header to provide sender authentication and message integrity. Nevertheless, these headers provides end-to-end protection between the visiting MS and HA only. The headers cannot protect hop-by-hop MIPv6 registration messages exchanged between intermediate nodes in the MIIv6 architecture. In MIIv6, we envision that the IG plays the role played by FA in MII. We suggest simple modifications to the secure multi-hop MIP registration scheme presented in Section 6.2.3 to secure the MIIv6 architecture. A secure multi-hop IG discovery is also required in MIIv6 to acquire a correct IG prefix to be used in creating a CoA. A MS visiting a foreign IP network undergoes five steps to complete a secure multi-hop MIPv6 registration: (1) perform authentication with HAS, (2) autoconfigure a manet-local address, (3) initiate a secure multi-hop IG discovery process, (4) autoconfigure a global routable IPv6 address and set this address as a new CoA, and (5) register the CoA with its HA. To illustrate the changes required to support a secure MIPv6 registration procedure, the example of the multi-hop MIP registration scheme in Section 6.2.3 is considered. Initially, MS3 performs a multi-hop authentication protocol with HAS using PANA and EAP. Subsequently, 205  MS3 configures a manet-local address from the site-local prefix, which has the value fec0:0:0:ffff::/96 [122], [124]. Following that, MS3 performs a Duplicate Address Detection (DAD) procedure to insure the uniqueness of the configured address. Consequently, it acquires IG’s routing prefix. The prefix could be learned from IG advertisements; however, to protect against attacks based on fake IG advertisements, MS3 initiates a secure multi-hop IG discovery procedure. The procedure has many similarities to the secure multi-hop FA discovery procedure presented in Section 6.2.3. MS3 broadcasts FA_Req message but replaces FA_Address with INTERNET_GATEWAYS address. INTERNET_GATEWAYS is a multicast address of all the IGs in a MANET deploying IPv6 protocol [123]. Assuming that MS2 and MS1 serve as intermediate nodes between MS3 and IG; MS2 and MS1 append their manet-local addresses and relay the discovery request message to IG as detailed in Steps 2 and 3 in Section 6.2.3. Next, the IG holding FMK and Ksol that corresponds to IDMS3 engages in validating the authenticity of MS3, MS2 and MS1. A procedure similar to Step 4 in Section 6.2.3 is followed by the IG which ends by replacing the List of CoA field in FA_Rep with IG’s route prefix. MS1 and MS2 relay the reply to MS3 as explained in Steps 5 and 6 in Section 6.2.3. When receiving the discovery reply message, MS3 performs the procedure explained in Step 7 in Section 6.2.3 and runs the stateless address autoconfiguration procedure to configure a new CoA using IG’s routing prefix. Finally, MS3 registers the new CoA with the HA following Steps 8 to 15 in Section 6.2.3 and assigns the IG as its default route to reach nodes in the Internet.  6.3 Performance evaluation The performance of our proposed scheme is compared against schemes in the literature that provide similar security services. Equivalently to our proposed scheme, Xie’s scheme [88] 206  and Kandikattu’s scheme [94] achieves secure multi-hop MIP registration services. However, they depend on asymmetric key operations like digitally signing/verifying messages and require DC management. Our proposed scheme does not require asymmetric key operations; instead, secure multi-hop MIP registration is achieved by appending keyed MACs to transient messages.  6.3.1 MIP registration delay  The high computation overhead of running digital signature and verifications results in increased MIP registration delay. A comparison of single hop and multi-hop MIP registration delay between the three schemes is studied in this section. The registration delay is calculated starting from the sending of FA_Req message by the visiting MS and ends by receiving R_Rep message. The delay between two nodes in each of the three schemes can be calculated as follows  ( (  (  ))  TScheme = M wl H wl Dt ( wl ) + D pp ( wl ) + 2 D pc + M wd H wd Dt ( wd ) + D pp ( wd ) + 2 D pc + TE Scheme  (  ))  (6.7)  where the variables Mwl, Mwd, Hwd, Dt(wl), Dt(wd), Dpp(wl), Dpp(wd) and Dpc are explained in Section 3.5 in Chapter 3. Hwl denote the numbers of hops in the wireless network. Dt(wl) and Dt(wd) are calculated as follows, Dt(wl/wd) = S / BW(wl/wd), where S is the average messages size, set to 50 bytes and BW(wl/wd) are the wireless and the wired network data rates, set to 11 Mbps and 100 Mbps, respectively. TEScheme accounts for additional delays that occur during FA discovery and MIP registration in each scheme. These delays are caused by cryptographic related operations such as digital signature/verification delay, keyed hashing delay and DC validation delay.  TE Scheme = eScheme ⋅ h  (6.8)  where h is a single row matrix defined as follows:  h = [D S − M , D S − S , DV − M , DV − S , D H − M , D H − S , D K − M , D K − S , D C ]  (6.9)  where DS-M and DS-S, are the delays in digitally signing a message by both a MS and a server, respectively. DV-M and DV-S, are the delays in digitally verifying a signed message by both a MS 207  and a server, respectively. DH-M and DH-S, are the delays in performing a hashing operation on a message by both a MS and a server, respectively. Hashing operations are used in all three schemes to calculate a keyed MAC on some messages. DK-M and DK-S, are the delays acquired by generating a key during registration by both a MS and a server, respectively. Only keys generated and used exclusively during the current MIP registration are considered here. The delay in generating general purpose keys, like public/private keys held by MS in Xie’s and the Kandikattu’s schemes are not considered. It is assumed that a new KHA-FA is always derived between FA and HA. DC is the delay incurred in validating a DC which includes decrypting the certificate with the CA’s public key and requesting the latest copy of the Certificate Revocation List (CRL) from the CA. In practice, DC validation delay varies and can reach up to tens of milliseconds especially if the CA and the requester are located in different networks [125]. To conduct a fair comparison between our proposed scheme and both Xie’s scheme and Kandikattu’s scheme, we assumed the best case scenarios in the opponent schemes whenever detailed information vital to the comparison are missing or unclear. For example, the method used to generate keys between FA and both MS and HA is not mentioned in [94]. We assumed that it is generated by a keyed hash function, similar to our proposed scheme. eScheme for single hop MIP registration for the three schemes is found as follows. Single e Xie  = [1 , 3 , 2 , 3 , 2 , 2 , 0 , 0 , 2 ]  Single e Kandikattu Single e Proposed  = [1 , 3 , 2 , 3 , 5 , 4 ,1 , 3 , 5 ]  (6.10)  = [0 , 0 , 0 , 0 , 6 ,10 , 5 , 5 , 0 ]  Further, eScheme for multi-hop MIP registration for the three schemes is found as follows.  208  Multi − hop Single e Xie = e Xie + [2 x − 1, 0, 2 x − 1, 1, 0, 0, 0, 0, 2 x − 2] Multi − hop Single e Kandikattu = e Kandikattu + [0, 0, 0, 0, 4 x − 1, 0,1,1, 0]  (6.11)  Multi − hop Single e Propose d = e Proposed + [0 , 0 , 0, 0, 2 x, 2 x, 0, 0, 0]  where x indicates the number of intermediate nodes between the visiting MS and FA, x > 0. The OpenSSL toolkit [126] was used to estimate the cryptographic-related processing delays in MSs and servers. The processing delays experienced by MSs were estimated by running the speed tool found in OpenSSL in a notebook equipped with a single 1.6 GHz Intel Pentium M processor with a 512MB of RAM. The processing delays experienced by servers, i.e., FA/HA, were estimated by running the speed tool on a single 2.83 GHz Intel Core 2 Quad processor with 3.25 GB of RAM. Xie’s scheme employs Elliptic Curve (EC) cryptography with discrete logarithmic techniques such as the Digital Signature Algorithm (ECDSA) [127] to digitally sign/verify messages exchanged between intermediate nodes and between the visiting MS and FA/HA. However, no particular digital signing/verifying technique was specified in Kandikattu’s scheme. The most famous technique to digitally sign/verify messages today is the Rivest-ShamirAdleman (RSA) digital signature technique [128]. Both ECDSA and RSA digital signature/verification techniques are considered in the performance analysis. The size of public/private keys used in Xie’s and Kandikattu’s schemes is not specified. Since our proposed scheme uses a 128-bit key to calculate MACs and to derive keys, asymmetric key sizes with similar security strengths are used in the analysis when testing Xie’s and Kandikattu’s schemes. The National Institute of Standards and Technology (NIST) indicated that a 256-bit key for ECDSA and a 3072-bit key for RSA should provide similar security strength to a 128-bit key in a symmetric key operation [129]. Table 6.1 shows the experimental results of running the speed tool on MS and the servers. 209  Table 6.1 Comparison of cryptographic-related processing delays DS-M (ms) DV-M (ms) DS-S (ms) DV-S (ms)  RSA  ECDSA  22  0.8  RSA  ECDSA  0.7  4.2  RSA  ECDSA  7.8  0.4  RSA  ECDSA  0.2  2  DH-M = DK-M (μs)  15  DH-S = DK-S (μs)  6  DC (ms)  5 ms  A comparison of the MIP registration delay between the three schemes is displayed in Figure  6.4.  Xie’s  and  Kandikattu’s  schemes  perform  equal  numbers  of  digital  signature/verification operations during a single hop registration. Kandikattu’s scheme experiences higher delays compared to Xie’s scheme because of the delay of validating the DCs of HA and FA by the visiting MS. Our proposed scheme outperforms both Xie’s and Kandikattu’s schemes because of the absence of any asymmetric key operation.  100 Xie's scheme Kandikattu's scheme  80  Registration Delay (ms)  Proposed scheme  60  40  20  RSA  ECDSA  Figure 6.4 Single-hop MIP registration delay in the three schemes  210  Since our proposed scheme is independent of asymmetric key operations, it displays similar performance results regardless of the type of digital signature/verification technique used. When ECDSA is adopted, our proposed scheme undergoes less than half of the delay experienced in Xie’s and Kandikattu’s schemes. When RSA is adopted, delay in our proposed scheme is less than that in the opponent’s schemes by a factor of four. Figure 6.5 shows a comparison of the multi-hop MIP registration delay experienced in the three schemes when ECDSA is adopted while Figure 6.6 depicts the delay comparisons when RSA is adopted. When there are two hops or less between the visiting MS and FA, i.e., there is at most a single intermediate node between the visiting MS and FA, Kandikattu’s scheme still experiences a higher MIP registration delay compared to Xie’s scheme when ECDSA is used. As the number of hops between the visiting MS and FA increase, Xie’s scheme underperforms Kandikattu’s scheme when either ECDSA or RSA is used. This is due to the extensive digital signature/verification operations performed by every intermediate node in the path between the visiting MS and FA in Xie’s scheme. Conversely, in Kandikattu’s scheme, every intermediate node performs multiple keyed hashing operations which incur less processing delay compared to digitally signing/verifying transient messages. Our proposed scheme consistently outperforms both Xie’s and Kandikattu’s schemes in both single-hop and multi-hop MIP registration delay. In the multi-hop MIP registration, as the number of hops increase, the delay difference between Xie’s scheme and our proposed scheme widens rapidly due to the intensive digital signature and verifications operations performed in Xie’s scheme. On the other hand, the difference in delay between Kandikattu’s scheme and our proposed scheme remains relatively constant as the number of hops between the visiting MS and FA increase. This is because both schemes perform a comparable number of keyed hashing operations. Nevertheless, a careful comparison shows that our proposed scheme enjoys a minuscule advantage over Kandikattu’s scheme as the number of hops increases. 211  MIP registration delay (ms)  250 Xie's Scheme Kandikattu's Scheme Proposed Scheme  150  50  1  2 3 4 5 Number of hops between the visiting MS and the FA  6  Figure 6.5 Multi-hop MIP registration delay in the three schemes when ECDSA is used  MIP registration delay (ms)  450 Xie's Scheme Kandikattu's Scheme Proposed Scheme  350  250  150  50 1  2 3 4 5 Number of hops between the visiting MS and the FA  6  Figure 6.6 Multi-hop MIP registration delay in the three schemes when RSA is used  In Kandikattu’s scheme, the keyed hashing operations are solely performed by intermediate nodes. In our proposed scheme, the keyed hashing operations are equally distributed between FA and intermediate nodes as shown in (6.11). Since the hashing processing delay in FA (DH-S) is less than the hashing delay experienced by MSs (DH-M) as shown in Table 6.1, thus, the difference in delay between the two schemes witnesses a minor increase when increasing the number of hops between the visiting MS and FA.  212  6.3.2 Energy consumption and communication overhead  MSs have limited processing capabilities and battery power. It is always desirable to conserve their energy. Security protocols are based on intensive cryptographic based operations, and hence, might consume much of the battery power. It is challenging to design strong security protocols without hugely affecting the power of the MS executing them. Several methods are proposed to estimate the energy consumption of cryptographic operations on resourceconstrained devices. Prasithsangaree and Krishnamurthy [130] outlined existing energy consumption computation methods and used one of the methods to estimate the energy consumed by MSs as a result of executing cryptographic operations. The method used by Prasithsangaree and Krishnamurthy [130] is based on estimating the energy consumption by counting the number of computing cycles used by the Central Processing Unit (CPU) in the MS while performing cryptographic related computations. The amount of current (I) drawn for one computation cycle (C) as well as the operating voltage (V) and the CPU clock frequency (F) of the processor must be known to convert cycles to energy consumed according to the following relationship [130]. E = C ⋅V ⋅  I F  (6.12)  The authors performed extensive testing to estimate the energy consumption of cryptographic operations on an Intel Mobile Pentium III processor. They found that running asymmetric key operations on a MS results in an energy consumption in the magnitude of milijoules per operations. On the other hand, symmetric key based operations consume energy in the magnitude of microjoules per operations. Feeney and Nilsson [131] argued through experiments the existence of a linear relationship between the energy consumption during transmission and the size of the transmitted data. They concluded a set of linear equations between the transmission energy and the size of 213  the transmitted data based on extensive experiments conducted on a Lucent 802.11b PC card operating at 11 Mbps. Equations (6.13) and (6.14) shows the energy consumption during transmission experienced by the MS when sending and receiving messages, respectively, in microjoules [131]. ESend = 0.48 · b + 431  (6.13)  EReceive = 0.12 · b + 316  (6.14)  where b is the message size in bytes. We utilized the findings in [130] and [131] to roughly estimate the energy consumed by the visiting MS when performing a single-hop MIP registration in the three schemes. Based on the experiments conducted in [130], the energy consumed on performing digital signatures and signature verifications using 256 bit ECDSA key is ≈ 2 mJ and 3 mJ, respectively. When using 3072 bit RSA key, signature and verification energy consumptions are ≈ 100 mJ and 2 mJ, respectively. Hashing a 64 byte message using SHA-1 [33] yields an energy consumption of 5 μJ. Hashing a 64 byte message represent MAC and key generation in our proposed scheme. The total energy consumption by a visiting MS adopting Xie’s scheme, Kandikattu’s scheme and our proposed scheme was calculated using the findings in [130] and Equations (6.13) and (6.14). All nonces were assumed to be 16 bytes, identities are 16 bytes, MACs are 16 bytes and the size of the DC is minimized to the size of the keys, i.e., 32 bytes for ECDSA and 384 bytes for RSA. Using ECDSA for digitally signing and verifying messages, a visiting MS in the Xie’s scheme consumes 9.5 mJ while a visiting MS in the Kandikattu’s scheme consumes 9.7 mJ. Using RSA, a MS adopting Xie’s scheme consumes 105.7 mJ while a MS adopting Kandikattu’s scheme consumed 106.1 mJ. A visiting MS that adopts our proposed scheme consumed 1.7 mJ only, recording energy conservation by a factor of 5, at least, compared with the other two schemes. These preliminary results and the experiments conducted in [130] clearly show the advantage of symmetric key based operation over asymmetric key based operations in terms of 214  the energy consumed in performing these operations. Similar energy consumption results are expected to be experienced by intermediate nodes in the case of the multi-hop MIP registration. The visiting MS and intermediate MSs consume more energy in Xie’s scheme and Kandikattu’s scheme compared to our proposed scheme due to the excessive execution of asymmetric key operations. Figure 6.7 shows a comparison between the three schemes in terms of the introduced communication overhead when executing a multi-hop MIP registration scheme. In our proposed scheme, every intermediate node appends IP address and MAC when resending FA_Req and appends nonce and MAC when resending R_Req. In the competitive schemes, every intermediate node appends IP address only when resending FA_Req and do not append any additional parameters when resending R_Req. However, the competitive schemes rely on the exchange of large sizes of public keys and DCs.  15  Communication Overhead (KB)  Communication Overhead (KB)  3.5  2.5  1.5  12  9  6  3  0.5  1 2 3 4 5 Number of hops between the visiting MS and FA (a) Xie's Scheme  1 2 3 4 5 Number of hops between the visiting MS and FA (b)  Kandikattu's Scheme  Proposed Scheme  Figure 6.7 Communication overhead comparison between the three schemes when (a) ECDSA and (b) RSA is used  Figure 6.7 (a) shows the communication overhead when ECDSA is used. Our proposed scheme appears to introduce more communication overhead compared to competitive schemes. However, that is because DC sizes considered in the analysis are minimized to the public key 215  size, i.e., 32 bytes. In practical implementations, the size of a DC is expected to be much larger because the DC contains numerous data in addition to the public key, such as a serial number, an issuer name, a validity period and other information. Thus, we expect the three schemes to generate a comparable size of communication overhead in practice. When RSA is used instead, public key and DC sizes increase from 32 bytes to 384 bytes. As a result, the competitive schemes end up generating more communication overhead compared to our proposed scheme. This is illustrated in Figure 6.7 (b).  6.3.3 Note on scalability  Asymmetric key based schemes are sometimes favored over traditional symmetric key based schemes in securing mobile communications because a pair of public/private key is used to authenticate the mobile in multiple foreign networks making the scheme more scalable. This advantage is highly appreciative when compared against a traditional symmetric key based scheme that requires manual installation of keys between visiting mobiles and authentication servers in the access network. Nonetheless, our proposed symmetric key based scheme does not require manual key management. The proposed scheme takes advantage of the need for authentication before launching MIP registration to automatically distribute and derive keys. High level MIP keys are automatically distributed by HAS to HA and FA. At the same time, the visiting mobile derives the required keys to complete the proposed MIP registration scheme. The absence of a manual key installation makes our proposed scheme more scalable than traditional symmetric key based schemes. However, our proposed scheme requires an accumulatively higher number of keys to operate accurately compared to asymmetric key based schemes.  216  6.4 Security analysis The proposed scheme is designed to provide two important security services, mutual authentication and secure multi-hop FA/IG discovery and CoA registration. Mutual authentication is attained, firstly, between the visiting MS and both FA/IG and HA, and secondly, between FA/IG and HA. In the single and multi-hop FA/IG discovery, FA/IG ensures the authenticity of the visiting MS by successfully computing and validating <M1>Ksol received in FA_Req message. A successful validation implies that the request came from a legitimate MS because Ksol can only be held by a MS that knows the correct FMK, TMK and EMSK. Likewise, the visiting MS ensures the legitimacy of FA/IG by successfully computing and validating <M2>Ksol received in FA_Rep message. Only a legitimate FA/IG receives FMK and IDMS from  AG, and hence capable of deriving a unique Ksol that only corresponds to MS. In the single-hop and multi-hop CoA registration, HA confirms the legitimacy of the visiting MS by correctly computing and validating <M3>KHA included in R_Req message. Only a legitimate MS holds a valid TMK and EMSK and is capable of deriving a correct KHA. Similarly, the legitimacy of HA is assured to the visiting MS when <M4>KHA included in R_Rep message is correctly computed. As shown in Figures 6.1 and 6.2, only a legitimate HA receives TMK and IDMS from HAS, and hence capable of deriving a correct KHA. HA and FA/IG mutually  authenticate each other by the successful computation and validation of <P2>KHA-FA and <P3>KHA-FA received in R_Req and R_Rep messages, respectively. KHA-FA is only derived by HA  and FA/IG holding a valid THAK. THAK is supplied by HAS to both HA and FA. In our proposed scheme, the visiting MS and the intermediate nodes calculate a MAC keyed with Ksol during the secure multi-hop FA/IG discovery procedure. MACs help protect the integrity of transient messages and authenticate the sender in addition to establishing a secure route to FA/IG. When receiving FA_Req message, FA/IG validates each S parameter appended by every node residing in the route path between the visiting MS and FA/IG. The S parameter 217  includes the IP address of each intermediate node and a MAC value of the IP address keyed with Ksol shared between the intermediate node and FA/IG. A MAC must be included by each  intermediate node because FA/IG cannot authenticate the sender based on unique identifying identities like the medium access control address because they could be easily spoofed by adversaries. FA/IG ensures the authenticity and the integrity of FA_Req message when all S parameters included in the request are correctly validated. In FA_Rep message, FA/IG includes R parameter which contains the best route to the visiting MS. <R>Ksol for each intermediate  node is also included in FA_Rep message. Each intermediate node verifies the correctness of the received R by validating the received <R>Ksol. R is also included in M2 in FA_Rep message and its integrity is protected by <M2>KsolMS, where KsolMS is the key shared between FA/IG and the visiting MS. If the validation of <M2>KsolMS by the visiting MS is correct, it is believed that the received R represents the best secured route to the FA. Likewise, in the secure multi-hop CoA registration procedure, each intermediate node includes a fresh nonce and MAC of the nonce in R_Req message. FA/IG verifies the authenticity of the visiting MS and intermediate nodes, in addition to the integrity of R_Req message, by validating the nonces and their MACs. On the reverse path, FA/IG increments the received nonces and calculates a new MAC for each nonce. Intermediate nodes validate the MAC of its associated nonce to confirm the integrity and authenticity of the reply. An important criterion in designing a secure key distribution system is to minimize key distribution to strictly the entities that are going to use it. This is also known as the “principle of least privilege” [60]. Our proposed scheme was designed to abide by the principle of least privilege. For example, HAS forwards FMK, instead of TMK, to AG and eventually to FA/IG. This design decision was taken because sending TMK to FA/IG could enable the receiver to derive KHA using (6.5), which is a key that is supposed to be secretly shared between the visiting  218  MS and HA only. In addition, although AG knows FMK, it cannot derive Ksol and KFA because it does not know the nonces used in deriving them as shown in (6.3) and (6.4). MSs in the MII and MIIv6 architectures are prone to MIP related security problems and attacks such as, fake FA/IG discovery requests, fake registration requests, forged FA/IG attacks, registration message replay attacks and registration message modifications attacks [87], [88], [94]. Most of these problems and attacks are avoided by a strict adoption of a strong mutual authentication between the visiting MS and both FA/IG and HA as well as the adoption of a strong mutual authentication between HA and FA/IG. Fake FA/IG discovery and fake registration requests: An illicit MS might attempt to  impersonate a legitimate MS and initiate fake FA_Req or fake R_Req messages to drain FA’s/IG’s resources, or to obtain a CoA from the FA or to redirect messages from HA to a hostile recipient. This attempt is stopped in our scheme by FA/IG because the illicit MS lacks the knowledge of Ksol and KFA necessary to launch such an attack. FA/IG can easily determine fake FA_Req messages and fake R_Req messages by validating the correctness of the received <M1>Ksol in FA_Req message and <P1>KFA in R_Req message.  Xie’s scheme and Kandikattu’s scheme also provide protection against fake registration attempts but protection against fake FA/IG discovery requests is not addressed. Incapability of detecting fake FA/IG discovery requests in Xie’s and Kandikattu’s schemes could waste valuable power of the intermediate nodes and might introduce processing delays. Fake registration attacks launched on Xie’s and Kandikattu’s schemes are detected by HA. This late detection is avoided in our proposed scheme where the detection happens earlier at the FA. Forged FA/IG: A forged FA/IG could impersonate as a legitimate FA/IG and attempt to  send fake advertisements to MS, reply to MS’s request or send fake registration messages to HA. This attack is stopped in our proposed scheme due to the establishment of a mutual authentication between the visiting MS and FA/IG on one hand, and between FA/IG and HA on 219  the other hand. The visiting MS can immediately identify the existence of a forged FA/IG if <M2>Ksol received in FA_Rep message is not correct. This is because only a legitimate FA/IG  can derive a valid Ksol. Similarly, a forged FA/IG is immediately discovered by HA when <P2>KHA-FA received in R_Req message is not correct since only a legitimate FA/IG can derive  a correct KHA-FA. Replay attacks: Nonces and timestamps are used in our proposed scheme to prevent  replay attacks. The visiting MS, intermediate nodes, FA/IG and HA record the timestamp and nonces to help identifying message replay attempts. For example, M1 in FA_Req message is sent by the visiting MS and includes N2MS and t. N2MS is a fresh nonce and t is a copy of the estimated time of the request. FA/IG stores the request and compares the nonce and the timestamp with previously received nonces and timestamps to validate its freshness. An illicit eavesdropper could record the request and resend it in the future to cheat FA/IG. FA/IG can easily detect the attack since invalid timestamp and duplication in the nonce is found. The illicit MS could modify the timestamp and insert a new nonce but would fail to compute a correct <M1>Ksol because it does not have the correct Ksol. The recipient must always discard messages with failed MAC validation. Message modifications: During the multi-hop FA discovery and the multi-hop CoA  registration procedures, dishonest intermediate nodes in the path between the visiting MS and FA/IG could modify messages in transient to deny MIP services to the visiting MS. Keyed MACs are appended to each message to preserve the integrity of transient messages. For example, MS2 in Figure 6.3 could modify parts of M1 in FA_Req message to deny MS3 from receiving the requested MIP service. FA/IG detects this modification by validating <M1>Ksol. If the validation fails, FA/IG discards the request and flags this route as insecure and chooses another route to reach the visiting MS.  220  Protection of multi-hop authentication messages: EAP messages inside PANA are  integrity protected by MACs keyed with TEK. This assures the visiting MS and HAS that messages are not altered in transient by intermediate nodes. Additionally, PANA provides its own integrity protection, replay protection, and MITM attack protection mechanisms by appending a special Attribute Value Pair (AVP) named “AUTH” to PANA messages [119]. The AUTH AVP covers the entire PANA messages including the EAP message. The AUTH AVP is calculated using PANA_AUTH_KEY derived by PaC/MS and PAA/AG from the newly derived MSK. Finally, PANA provides additional replay protection by including a unique sequence  number to each PANA message. The sequence numbers are monotonically incremented in every new request. They are randomly initialized at the beginning of a session and they are verified against future expected values by the receiver.  6.5 Summary In this Chapter, we have proposed a set of procedures to securely and efficiently complete the multi-hop MIP registration operation. Firstly, a multi-hop authentication protocol based on PANA has been proposed. Secondly, we have proposed a secured and efficient singlehop and multi-hop FA discovery procedures. Thirdly, we have proposed a secured and efficient single-hop and multi-hop CoA registration procedures. In addition, the proposed MIP scheme has been extended to secure the interworking between nodes adopting IPv6 protocol and employing MIPv6. The proposed scheme achieves mutual authentication between the visiting MS, FA/IG and HA. It supports adequate protection against MANET-based attacks such as message modification attacks and replay attacks. Moreover, the proposed scheme provides protection against MIP related problems like fake FA/IG discovery requests, fake registration requests and forged FA/IG attacks. Performance analysis shows that the proposed scheme undergoes less MIP 221  registration delay and the visiting MS consumes less energy compared to competitive schemes in the literature for both single and multi-hop communications.  222  Chapter 7: Conclusions The proliferation in wireless technologies offers mobile users the enjoyment of continuous and broadband mobile Internet access. Each wireless technology has unique characteristics. 3GPP, WiMAX and WLAN technologies complement each other in terms of coverage, installation cost, operation cost, service quality and speed. Interworking these technologies brings many benefits to service provider and end users. In addition, such an interworking architecture could set a platform for future innovative services and applications. Securing the heterogeneous wireless network is a great challenge because of the increased number of vulnerabilities in autonomous networks separately and the interworking architecture as a whole. Authentication is the first line of defense in the heterogeneous wireless network. User’s security credentials are created by the 3GPP service provider; thus, users invoke authentication protocols based on 3GPP-AKA when initially connected to a 3GPP access network, WiMAX network or WLAN in the heterogonous wireless network. The standard 3GPP-AKA protocol is invoked when the user connects to a 3GPP access network. EAP-AKA is invoked when the user connects to a WLAN AP. INEA is invoked when the user connects to a WiMAX BS. When a stationary user requires re-authentication or when a mobile user performs HHOs or VHOs in the heterogeneous wireless networks, these standard protocols are executed. Since these protocols rely extensively on authentication servers in the 3GHN, invoking these protocols introduces unnecessary delays and redundant signaling. Optional performance-improved versions of these protocols are proposed in 3GPP and WiMAX Forum specifications; however, executing such protocols improves performance at the expense of security. Many proposals in the literature attempt to improve the authentication procedure instigated by a HO or instigated due to an expired key. Some proposals seem to focus on 223  performance and neglects security. Other proposals emphasize on security and negatively affect system performance. A third group of proposals balance security and performance but introduce new components to the interworking architecture or proposed infeasible or non-standardized solutions. In this thesis, we have proposed several novel authentication protocols that strike a balance between security strength and performance. Our proposed protocols are enabled by minor modifications to 3GPP-AKA, EAP-AKA and INEA. These modifications enable an extension to the key hierarchy to delegate future authentications to the target network. This ensures minimum interactions between the MS and the authentication servers in the 3GHN in subsequent authentications. In addition, security protocols have been designed to accommodate MSs that require multi-hop communications to access the heterogeneous wireless network. Next, we summarize our technical contributions, present a consolidated view of the contributions and list possible future work.  7.1 Summary of contributions Design of fast and secure authentication protocols in 3GPP-WLAN  In Chapter 3, we have proposed modifications to the standard EAP-AKA protocol (modEAP-AKA) that yields extensions to the key hierarchy and enables the execution of localized authentication for stationary and mobile users. WLLR has been designed to achieve local, fast and secure re-authentication without communicating with HSS/HAAA when users are stationary. HSS/HAAA delegates the authentication procedure to WAAA in WLLR to reduce authentication delay and authentication signaling. Intra-WLAN FP and Inter-WLAN FP have been designed to handle users’ authentication when performing intra-WLAN and inter-WLAN HHOs in 3GPP-WLAN. Intra-WLAN FP and Inter-WLAN FP perform pre-authentication with the target network before the HO operation completes. This approach allows drastic reductions in HO delay and signaling caused by HO authentication. Thorough performance comparisons 224  between the proposed protocols and the standard protocols have demonstrated the excellence of our proposed protocols in terms of authentication delay, authentication signaling and the conservation of nodal resources. Performance evaluations show that mod-EAP-AKA and WLLR cuts authentication signaling by 50% and authentication delay by 30% compared to standard protocols. Inter and Intra-WLAN FP reduces authentication signaling and authentication delays by 39% and 54%, respectively, compared to standard protocols. In conjunction with performance enhancements, security analysis shows that our proposed protocols enjoy important security features like the provision of mutual authentication between users and authentication servers, the adoptions of a secured key management scheme and the protection against message replay and modifications. The provision of mutual authentication and key secrecy in our proposed protocols has been confirmed using the AVISPA security analysis tool. The standard protocols provide a basic privacy protection technique that puts burden on HAAA. We have proposed improved identity protection mechanisms using temporary identities locally managed in the WLAN domain. The frequency of executing our proposed protocols is determined by parameters supplied by HAAA. Algorithms to aid HAAA in choosing a suitable value for these parameters have been developed in Chapter 3. These parameters play a vital role in balancing the performance of the proposed protocols and the security of the interworking architecture. Design of performance-enhanced and secured HHO protocols in 3GPP-WiMAX  In Chapter 4, we have proposed modifications to INEA to permit the design of a performance-enhanced and secured WiMAX HHO protocols applicable to 3GPP-WiMAX. Two HHO protocols have been introduced, R3HP and R6HP. R3HP is executed when MS performs an inter ASN-GW HO while R6HP is executed when MS performs an intra ASN-GW HO. Authentication queries are piggybacked on HO control messages in R6HP and R3HP. This approach results in establishing mutual authentication between MS and the target network in 225  concurrent with exchanging HO signaling. Special HO control messages have been designed to complete HO and authentication with the ASN-GW and PAAA instead of HSS/HAAA. Therefore, significant reduction in HO signaling traffic and HO delay is achieved compared to the standard default protocols. Performance evaluations based on the fluid flow mobility model have been conducted. Results show that R6HP and R3HP dispatch 60% less authentication signaling compared to the standard default HO protocols when R = 2. Additionally, the proposed protocols experience 58% less delay compared to the standard default protocols. R6HP and R3HP continue to outperform the standard protocols as more R6HOs and R3HOs are performed. Unlike the standard default protocols, HSS/HAAA in R6HP and R3HP are no longer required to generate keys for every MS performing HHOs. This illustrates the efficiency and scalability of our proposed protocols. R6HP and R3HP perform equivalently to the less secure standard optional protocols while overcoming their security pitfalls. A fresh round of mutual authentication between MS and the target network is preserved when performing R6HP and R3HP whenever HHOs are performed. No vulnerabilities or attacks on authentication were discovered when testing our protocols with the AVISPA security analysis tool. Moreover, the proposed protocols abide by forward and backward secrecy of keys during HHOs and establish a secure and cautious key distribution scheme. Temporary identities are employed to cover the permanent identity of the roaming MS to avoid privacy related attacks. Algorithms to select the permitted number of R6HP and R3HP executions have been developed as well. Design of fast VHO re-authentication protocols for the heterogeneous wireless network  3GPP-AKA, EAP-AKA and INEA lack the support of fast VHO re-authentication, thus they are deemed inefficient. We have proposed six VHO re-authentication protocols to speed the VHO activity in the heterogeneous wireless network in Chapter 5. Since HAAA is involved in 226  authenticating MS’s connected over WLAN and WiMAX, a set of protocols have been proposed to enable fast VHOs between them. A single execution of mod-EAP-AKA or mod-INEA is sufficient to enable the execution of the performance improved VHO re-authentication protocols. The proposed protocols are executed depending on different VHO situations. In the case of WiMAX to WLAN VHO, WLFR is executed when the target WLAN domain is visited for the first time while WLLRv2 is executed when the WLAN domain is revisited. In the case of WLAN to WiMAX VHO, WiFR is executed when the ASN domain is visited for the first time while WiLR is executed when the ASN domain is revisited. WiPAR is executed instead of WiFR if the MS performs a VHO between different ASN domains controlled by the same PAAA. WLFR and WiFR depend on security challenges to mutually authenticate MS and HAAA without retrieving a new AV from HSS. Executing WLFR and WiFR sets the stage to offload MS authentication responsibility to authentication servers in the ASN domain and the WLAN domain in future VHOs. F3AR has been designed to handle fast VHO re-authentication from WLAN/WiMAX to 3GPP. To correctly execute F3AR, a simple modification to the standard 3GPP-AKA has been presented. Based on these modifications, the SN could handle future VHO re-authentications instead of the HSS. The performance of the proposed protocols surpasses the standard protocols. Performance analysis illustrates that our proposed protocols perform exceptionally well when more VHOs take place and when the same target network is revisited repeatedly. Most of the delay and signaling reduction are derived from eliminating the exchange of authentication queries between the target domain and the 3GHN. Our proposed protocols eliminate up to 42% of the authentication traffic emitted by standard protocols. As more VHOs are performed and as more WiFR executions are substituted by WiPAR, further reduction in authentication signaling and delay are achieved.  227  Security has been integrated in the design of our proposed protocols. Therefore, with all outstanding performances displayed by our proposed protocols, they maintain essential security requirements while performing VHOs in the heterogeneous wireless network. These security features include the provision of mutual authentication between MS and the target network, the support of forward and backward key secrecy and the protection of users’ privacy. AVISPA security tool has been applied to ensure the capability of our proposed protocols to maintain a strict mutual authentication procedure. To ensure an equal stand between system security and VHO re-authentication efficiency, several algorithms have been developed to accurately select the permitted number of VHOs between WiMAX and WLAN and the allowed frequency of executing WiLR, WLLRv2, WiPAR and F3AR. Design of efficient and secure multi-hop Mobile IP registration scheme for MANETInternet Interworking  In Chapter 6, we have proposed a secure and efficient MIP registration scheme based on symmetric key operations. To successfully launch the proposed scheme, a secure multi-hop authentication protocol has been proposed as well. Security keys derived by the multi-hop authentication protocol are used in securing the multi-hop MIP registration scheme. Our proposed MIP registration scheme includes a secure and efficient multi-hop FA discovery procedure and a secure and efficient multi-hop CoA registration procedure. In addition, necessary modifications to support MIPv6 registration have been presented in the Chapter. Performance comparisons between the proposed MIP registration scheme and competitive schemes in the literature show the virtue of the proposed scheme. The proposed scheme capitalizes on the speed of performing symmetric key operations in contrast to performing asymmetric key operations to complete MIP registration with less latency compared to closely competitive schemes. Our proposed scheme completes multi-hop MIP registration in 48% less delay compared to the fastest scheme among the competitive schemes when a single 228  intermediate node exist between the visiting MS and the FA. As more intermediate nodes gets involved in relaying MIP messages between the visiting MS and the FA, the proposed scheme experiences further reduced registration latency compared to other competitive schemes. Due to the intensive processing power demanded by asymmetric key operations, results demonstrate that our proposed protocols conserve the energy required by the visiting MS to complete MIP registration by a factor of 5 compared to competitive schemes. In alignment with performance predominance, the proposed scheme is capable of foiling security problems and attacks affecting the MII architecture like fake FA discover requests, fake registration requests, forged FA attacks, attacks on replaying registration messages and attacks on modifying registration messages.  7.2 A consolidated view of the contributions We have suggested modifying 3GPP-AKA when the MS requires authentication in the 3GPP access network, modifying EAP-AKA when the MS requires authentication in the WLAN domain and modifying INEA when the MS requires authentication in the ASN. These modifications have been carefully designed to have a broad effect and permit the achievement of fast mutual authentication between MS and target network, whether the MS remains stationary or performs HHOs or VHOs in the heterogeneous wireless network. Therefore, the MS undergoes an extensive initial authentication that involves additional key generation to capacitate the execution of performance improved and secure future HHOs and VHOs. For example, the MS could invoke mod-EAP-AKA then perform WLLR and Intra/InterWLAN FP. Later, a VHO to an ASN domain is performed and the MS could benefit from the previously invoked mod-EAP-AKA to execute WiFR without the need to contact HSS. Subsequently, if keys lifetime have not expired, the MS could perform R6HP and R3HP protocols in the WiMAX network without contacting HSS/HAAA. Likewise, the MS can 229  perform repetitive VHOs between WLAN and WiMAX on the merits of the previously executed mod-EAP-AKA. The MS could even launch a secure multi-hop MIP registration when visiting a foreign IP network based on the initial mod-EAP-AKA execution. This example shows that for highly trusted WLAN and WiMAX networks, keys lifetime can be increased to increase the frequency of executing the proposed protocols to result in enormous performance improvements due to the avoidance of contacting HSS/HAAA for authentication. The proposed protocols capitalize on EMSK, which is unused by the standard protocols, to extend the key hierarchy and support fast HO re-authentications and pre-authentications. The execution of mod-3GPP-AKA is required when performing a VHO to 3GPP. The keys and parameters derived when executing mod-EAP-AKA or mod-INEA cannot be extended to support a fast VHO re-authentication to 3GPP. A single execution of mod-3GPP and either mod-EAP-AKA or mod-INEA can enable the MS to highly improve the authentication procedure experienced during HHOs and VHOs in the heterogeneous wireless network. Additionally, all proposed protocols perform remarkably well and demonstrate their worth in comparison to competing protocols as more HHOs and VHOs takes place. We envision that improving the performance of VHO authentication is more important than improving the performance of HHO authentication. When performing an authentication protocol such as EAP-AKA or INEA, a security association is established between the 3GHN and the local authentication server in the visited network. When the user performs a HHO within the vicinity of the local authentication server, authentication instigated by HHO might be omitted to improve performance as suggested in [5] and [15]. With some security modifications to the key derivation procedures, some security weaknesses in [5] and [15] can be resolved. In the case of VHOs, the serving and the target network might belong to different operators, and thus, all authentication signaling must travel to the 3GHN. Therefore, we anticipate that our proposed fast  230  VHO re-authentication protocols will have a higher impact on the telecommunication industry and research community compared to our proposed HHO pre-authentication protocols. The decision governing the switch from one wireless technology to the other depends on user preferences and requirements. One of the factors that can influence VHO decision making and target network selection is the security strength adopted by the target network and the capability of invoking performance improved VHOs. The VHO decision algorithm should favor previously visited target networks or networks holding unexpired keys with the MS to achieve fast VHOs. The support of our proposed performance improved protocols should be one of the factors influencing the VHO decision mechanism. We view our proposed protocols as an extension to standard authentication protocols. Therefore, our proposed protocols require minor software upgrades to MSs and authentication servers such as WAAA, PAAA and HAAA to derive additional keys and to handle extra authentication processing. APs and BSs do not require undergoing any changes. Since our proposed protocols do not introduce additional servers and utilizes the servers already existing in the heterogeneous wireless network architecture specified by 3GPP and the WiMAX Forum [10], [15], [19], [34], we believe that the proposed protocols can be easily adopted and deployed by 3GPP and the WiMAX Forum in the future. Besides authentication and authorization, AAA servers perform accounting operations. Accounting is essential to record and validate billing transactions between target networks and the home network. For example, if a 3GPP subscriber is accessing the Internet over a WLAN in the heterogeneous wireless network, the subscriber is expected to pay a unified bill for 3GPP and WLAN services to the 3GPP service provider. It is important for the WAAA to report WLAN usage time and other related information to the HAAA to charge the 3GPP service provider. All authentication procedures proposed in this thesis are handled by authentication and accounting servers such as WAAA, ASN-GW and PAAA. We believe that accounting operations will not 231  change as a result of executing our proposed protocols because we assume that the trust agreement between target networks and the home network will oblige WAAA, ASN-GW and PAAA to report accounting related information to the 3GHN. The authentication protocols proposed in this thesis have been tested using AVISPA to confirm the support of mutual authentication and key secrecy. AVISPA is a state-of-the-art formal security validation tool based on extensive attack searching and model checking back-end servers such as OFMC and Cl-AtSe. We have great confidence in AVISPA’s capability to discover possible authentication and key secrecy attacks. AVISPA does not find any feasible attack on authentication and key secrecy when used to test our protocols. Positive security validation using AVISPA ensure the security of our proposed protocols within the scope of supporting mutual authentication and key secrecy. Nevertheless, adopting our secure authentication protocols does not prevent the heterogeneous wireless network from other nonauthentication related security attacks such as denial of service attacks or mobile viruses. After all, it is well known that there is no such thing as a perfect security solution.  7.3 Future work Although the proposed protocols displayed good qualities in terms of performance and security, we believe that room for improvements still exists. The following sections describe the projected future improvements and possible future research directions.  7.3.1 Improvements to the proposed protocols  The following improvements can be investigated to perfect the operation of our proposed protocols. •  Design of error handling and error reporting mechanism. Errors can occur during the re-  authentication procedure like incorrect verification of message authentication codes. When errors occur, the execution of the protocol encountering the error stops and mod-3GPP-AKA, 232  mod-EAP-AKA or mod-INEA is executed instead depending on whether the authentication happened in the 3GPP access network, WLAN domain or ASN domain, respectively. The design of a local error rectification and error reporting mechanism is important. •  Design of Counter resynchronization mechanism. The proposed protocols are based on  counters. These counters are maintained by, for example, MS and WAAA in 3GPP-WLAN, MS and ASN-GW in 3GPP-WiMAX and MS and SN in 3GPP. Keeping synchronized counters between nodes could be challenging. A method to locally resynchronize counters between nodes could avoid the need to execute mod-3GPP-AKA, mod-EAP-AKA and modINEA and permit executing the proposed performance improved protocols. •  Retrieving a new AHK from PAAA when the current AHK expires during R6HP.  During the execution of R6HP, the ASN-GW validates the lifetime of AHK, and if AHK lifetime is still valid, R6HP proceeds normally. Otherwise, mod-INEA is executed. A messaging sequence between ASN-GW and PAAA can be designed to acquire the lifetime of PHK and to generate a new AHK from it if possible. The advantage of this procedure is to  avoid invoking mod-INEA and use this simple messaging procedure to enable R6HP execution during R6HO.  7.3.2 Future research direction  The proposed protocols presented in Chapter 3, Chapter 4 and Chapter 5 handle users authentication in interworking scenario 2 as explained in Section 2.2.2 in Chapter 2. Security in interworking scenarios 3 and above includes securing access to PS based services in the 3GHN and the IMS over WLAN and WiMAX. A secure tunnel establishment is required between MS and the PDG in interworking scenario 3. Tunnel establishment is performed using the Internet Key Exchange version 2 protocol (IKEv2) with EAP-AKA. To access the IMS, IMS-AKA protocol is executed between MS and HSS [136]. Localizing IKEv2 and IMS-AKA procedures 233  can save extra signaling and latency when the MS requests PS based services or IMS services over WLAN or WiMAX. The IETF proposed a network-based mobility management scheme named Proxy MIPv6 [137] to enable MSs to roam freely without re-registering a CoA with the HA. This approach reduces CoA registration signaling exchanged in the access network. Special mobility agents are introduced in Proxy MIPv6 to communicate with the HA on behalf of the visiting MS. Possible future research could involve an extension of our proposed secure multi-hop communications presented in Chapter 6 to secure the operation of Proxy MIPv6 when the visiting MS joins a MIIv6 architecture.  234  References 1.  H. Yang, F. Ricciato, S. Lu and L. Zhang, "Securing a wireless world", Proceedings of the IEEE, vol. 94, p. 442-454, 2006  2.  The 3rd Generation Partnership Project (3GPP), www.3gpp.org  3.  IEEE Standard for local and metropolitan area networks, “Wireless LAN Medium Access Control (MAC) and Physical Layer Specifications”, ANSI/IEEE Std 802.11, 1999 Edition (R2003)  4.  IEEE Standard for local and metropolitan area networks, “Air Interface for Fixed Broadband Wireless Access Systems”, IEEE Std 802.16-2004, October 2004  5.  IEEE Standard for local and metropolitan area networks, “Air Interface for Fixed Broadband Wireless Access Systems”, Part 16, Amendment 2 and Corrigendum 1”, IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor1-2005  6.  The WiMAX Forum, www.wimaxforum.org  7.  William Stallings, Cryptography and Network Security, Principles and Practices, 3rd Edition, Prentice Hall, 2003  8.  J. Arkko and H. Haverinen, “Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)”, IETF RFC 4187, January 2006  9.  M. Shi, X. Shen and J. Mark, “IEEE802.11 Roaming and authentication in Wireless LAN/Cellular Mobile Networks”, IEEE Wireless Communications, vol. 11, issue. 4, pp 6675, August 2004  10.  WiMAX Forum Network Architecture – Stage 2 “Architecture Tenets, Reference Model and Reference Points [3GPP – WiMAX Interworking]”, WiMAX Forum, Rel. 1, ver. 1.2, January 2008  11.  H. Yang, H. Luo, F. Ye, S. Lu and L. Zhang, “Security in Mobile Ad Hoc Networks: Challenges and Solutions”, IEEE Wireless Communications, vol. 11, issue 1, pp. 38 – 47, February 2004  12.  S. Ding, “A survey on integrating MANETs with the Internet: Challenges and designs”, Computer Communications, vol. 31, issue 14, pp. 3537 – 3551, September 2008  13.  C. Perkins, “IP mobility support”, IETF RFC 2002, October 1996  14.  The Internet Engineering Task Force (IETF), www.ietf.org 235  15.  WiMAX Forum Network Architecture – Stage 3 “Detailed Protocols and Procedures”, WiMAX Forum, Rel. 1, ver. 1.2, January 2008  16.  AVISPA - Automated Validation of Internet Security Protocols. www.avispa-project.org.  17.  3rd Generation Partnership Project, 3GPP Technical Specifications, 3G Security; Security architecture (Release 7), 3GPP TS 33.102 v7.0.0, December 2005  18.  3rd Generation Partnership Project, 3GPP Technical Specifications, 3G Security; Network Domain Security (NDS); Mobile Application Part (MAP) application layer security (Release 6), TS 33.200 v.6.1.0, April 2005  19.  3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, 3GPP system to Wireless Local Area Network (WLAN) interworking, System description (Release 7), 3GPP TS 23.234 v.7.2.0, June 2006  20.  F. Fitzek, M. Munari, V. Pastesini, S. Rossi and L. Badia, "Security and authentication concepts for UMTS/WLAN convergence", In Proc. IEEE 58th Vehicular Technology Conference, VTC 2003. vol.4, pp. 2343-2347, Florida, USA, Fall 2003  21.  M. Buddhikot, G. Chandranmenon, S. Han, Y. W. Lee, S. Miller and L. Salgarelli, "Integration of 802.11 and third-generation wireless data networks", In Proc. IEEE INFOCOM 2003, vol.1, p. 503-512, San Francisco, USA, 2003  22.  F. Olabisi and H. Chan, “AAA and Mobility Management in UMTS-WLAN interworking” In Proc. 12th International Conference on Telecommunications, ICT 2005, Cape Town, South Africa, 2005  23.  3rd Generation Partnership Project, 3GPP Technical Specification, “Group Services and System Aspects; Feasibility study on 3GPP system to Wireless Local Area Network interworking”, 3GPP TS 22.934 v.6.0.0, September 2002  24.  Chou-Chen Yang, Kuan-Hao Chu, and Ya-Wen Yang, "3G and WLAN Interworking Security: Current Status and Key Issues", International Journal on Network Security, vol.2, no.1, p.1–13, January 2006  25.  G. M. Koien and T. Haslestad, "Security aspects of 3G-WLAN interworking", IEEE Communications Magazine, vol. 41, p. 82-88, 2003  26.  C. Rigney, S. Willens, A. Rubens and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, IETF RFC 2865, June 2000  27.  P. Calhoun, J. Loughney, E Guttman, G. Zorn and J. Arkko, “Diameter Base Protocol”, IETF RFC 3588, September 2003  28.  B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, “Extensible Authentication Protocol (EAP)”, IETF RFC 3748, June 2004 236  29.  D. Cavalcanti, D. Agrawal, C. Cordeiro, B. Xie and A. Kumar, “Issues in integrating cellular networks, WLAN, and MANET: A futuristic heterogeneous wireless network”, IEEE Wireless Communications, vol. 12, issue 3, pp. 30 – 41, June 2005  30.  B. Aboba, D. Simon, “PPP EAP TLS Authentication Protocol”, IETF RFC 2716, October 1999  31.  P. Funk, S. Blake-Wilson, “EAP Tunneled TLS Authentication Protocol (EAP-TTLS)”, IETF Internet Draft, draft-ietf-pppext-eap-ttls-05.txt. July 2004  32.  A. Palekar, D. Simon, J. Salowey, G. Zorn, H. Zhou, S. Josefsson, “Protected EAP Protocol (PEAP) Version 2”, IETF Internet Draft, draft-josefsson-pppext-eap-tls-eap09.txt, October 2004  33.  NIST, Secure Hash Standard, Federal Information Processing Standard, FIPS-180-1, April 1995  34.  3rd Generation Partnership Project, 3GPP Technical Specifications, “3G Security; WLAN interworking security (Release 7)”, 3GPP TS 33.234 v7.0.0, March 2006  35.  IEEE Standard for local and metropolitan area networks, “Port-based Network Access Control”, IEEE Std 802.1x, 2001 Edition (R2004)  36.  IEEE Standard for local and metropolitan area networks, “Wireless LAN Medium Access Control (MAC) and Physical Layer Specifications, MAC Security Enhancements”. ANSI/IEEE Std 802.11i, 2004 Edition  37.  H. Kwon, K.-Y. Cheon, K.-H. Roh and A. Park, “USIM based Authentication Test-bed for UMTS-WLAN Handover”, In Proc. IEEE INFOCOM 2006, Barcelona, Spain, 2006  38.  G. Kambourakis, A. Rouskas and S. Gritzalis, “Advanced SSL/TLS-based authentication for secure WLAN-3G Interworking”, IEE Communications Proceedings, vol. 151, issue. 5, pp. 501-506, 2004  39.  P. Prasithsangaree and P. Krishnamurthy, “A new authentication mechanism for loosely coupled 3G-WLAN integrated networks”, In Proc. IEEE 59th Vehicular Technology Conference, VTC 2004, vol.5, pp. 2998-3003, Italy, Spring 2004  40.  H. Chen, M. Zivkovic and D.-J. Plas, “Transparent End-User Authentication Across Heterogeneous Wireless Networks”, In Proc. IEEE 58th Vehicular Technology Conference, VTC 2003, vol.3, pp. 2088-2092, Florida, USA, Fall 2003  41.  L. Salgarelli, M. Buddhikot, J. Garay, S. Patel and S. Miller, “Efficient authentication and key distribution in wireless IP networks”, IEEE Wireless Communications Magazine, vol.10, Issue.6, pp 52-61, 2003  237  42.  T. Braun and K. Hahnsang, “Efficient Authentication and Authorization of Mobile Users Based on Peer-to-Peer network mechanisms” In Proc. of the 38th Annual Hawaii International Conference on System Sciences, HICSS’05, pp. 306-313, Hawaii, USA, 2005  43.  M. Lee, G. Kim and S. Park, “Seamless and secure mobility management with LocationAware Service (LAS) broker for future Mobile Interworking networks”, Journal of Communications and Networks, vol. 7, no. 2, pp 207-221, June 2005  44.  A. Mishra, M. Shin, and W. Arbaugh, “An Emprical Analysis of the IEEE 802.11 MAC Layer Handoff Process”, ACM SIGCOMM Computer Communications Review. vol. 33, issue 2, pp. 93 – 102, April 2003  45.  IEEE Standard for local and metropolitan area networks “IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation”. IEEE Std 802.11f-2003  46.  IEEE Standard for local and metropolitan area networks, “Wireless LAN Medium Access Control (MAC) and Physical Layer Specifications, Fast BSS transition”. IEEE Std 802.11r (Draft 3), 2005  47.  S. Bangoale, C. Bell and E. Qi, “Performance study of fast BSS transition using IEEE802.11r”, In Proc. of the 2006 international Conference on Wireless Communications and Mobile Computing, IWCMC’06, pp 737-742, Canada, 2006  48.  A. Mishra, M. Shin, J. Nick L. Petroni, T. C. Clancy, and W. A. Arbaugh, “Proactive Key Distribution using Neighbor Graphs”, IEEE Wireless Communications, vol. 11, issue. 1, pp 26-36, February 2004  49.  M. Kassab, A. Belghith, J-M Bonnin and S. Sassi, “Fast Pre-Authentication Based on Proactive Key Distribution for 802.11 Infrastructure Networks”, In Proc. of 1st ACM Workshop on Wireless Multimedia Networking and Performance Modeling, WMuNeP’05, in conjunction with MSWiM 2005. pp 46-53, Canada, October 2005  50.  J. Hur, C. Park and H Yoon, “An Efficient Pre-authentication scheme for IEEE 802.11Based Vehicular Networks”, Advances in Information and Computer Security, Lecture Notes in Computer Science 4752, pp. 121-136, Springer 2007  51.  S. Pack and Y. Choi, “Pre-Authenticated Fast Handoff in a Public Wireless LAN based on IEEE 802.1x Model”, In Proc. of IFIP TC6 Personal Wireless Communications, vol. 234, pp 175-182, October 2002  52.  A. Mukherjee, T. Joshi and D. Agrawal, “Minimizing Re-authentication Overheads in Infrastructure IEEE 802.11 WLAN Networks”, In Proc. of IEEE Wireless Communications and Networking Conference, WCNC 2005, vol. 4, pp. 2344 – 2349, USA, March 2005  238  53.  M. Long, C-H Wu and J. Irwin, “Localised authentication for inter-network roaming across wireless LANs”, IEE Proceedings Communications, Vol. 151, No. 5, pp 496 – 500, October 2004  54.  C. Lim, D-Y. Kim, O. Song and C-H Choi, “SHARE: seamless handover architecture for 3G-WLAN roaming environment”, Journal of Wireless Networks, vol. 15, no. 3, pp. 353 – 363. Springer Netherlands, 2009  55.  J. Hur, H. Shim, P. Kim, H. Yoon and N-O Song, “Security Considerations for Handover Schemes in Mobile WiMAX Networks”, In Proc. of Wireless Communications and Networking Conference 2008, WCNC 2008, pp. 2531 – 2536, USA, March/April 2008  56.  W. Jiao, P. Jiang and Y. Ma, “Fast Handover Scheme for Real-Time Applications in Mobile WiMAX”, In Proc. of International Conference on Communications 2007, ICC 2007, pp. 6038-6042, Glasgow, Scotland, June 2007  57.  J. Sultan, M. Ismail, N. Misran and K. Jumari, “Spectral Efficiency Evaluation of Downlink Mobile Multi-HOP Relay System Employing Macro Diversity Handover Technique”, International Journal of Computer Science and Network Security, vol. 8, no. 5, May 2008  58.  F. Xu, L. Zhang and Z. Zheng, “Interworking of WiMAX and 3GPP Networks based on IMS”, IEEE Communications Magazine, vol. 45, pp. 144 – 150, March 2007  59.  R. Rajavelsamy, V. Jeedigunta and O. Song, “A Novel Method for Authentication Optimization during Handover in Heterogeneous Wireless Networks”, In Proc. of the 2nd IEEE International Conference on Communication System Software and Middleware, COMSWARE 2007, Bangalore, India, January 2007  60.  R. Housley and B. Aboba, “Guidance for Authentication, Authorization and Accounting (AAA) key management”, IETF RFC 4962, July 2007  61.  M. Zhang and Y. Fang, “Security analysis and enhancements of 3GPP AKA protocol”, IEEE Transactions on Wireless Communications, vol. 4, p 734-742, March 2005  62.  S. Choi, G-H. Hwang and T. Kwon, “Fast Handover Scheme for Real-Time Downlink Services in IEEE 802.16e BWA System”, In Proc. of IEEE Vehicular Technology Conference 2007, VTC 2007, vol. 3, pp. 2028-2032, Sweden, May 2005  63.  D. Lee, K, Kyamakya and J Umondi, “Fast Handover Algorithm for IEEE 802.16e Broadband Wireless Access System”, In Proc. of 1st International Symposium on Wireless Pervasive Computing, ISWPC 2006, Thailand, January 2006  64.  H-M. Sun, Y-H. Lin, S-M. Chen and Y-C. Shen, “Secure and Fast Handover Scheme Based on Pre-Authentication method for 802.16/WiMAX Infrastructure Networks”, In Proc. of IEEE Region 10 Conference, TENCON 2007, Taipei, October/November 2007 239  65.  C-K. Chang and C-T Huang, “Fast and Secure Mobility for IEEE 802.16e Broadband Wireless Networks”, In Proc. of the International Conference on Parallel Processing Workshops, ICPPW 2007, September 2007  66.  T. Yahiya, K. Sethom and G. Pujolle, “Seamless Continuity of Service across WLAN and WMAN Networks: Challenges and Performance Evaluation”, Proc. IEEE/IFIP Int. Workshop on Broadband Convergence Network, BcN’07, Germany, May 2007  67.  Y-C. Chen, J-H Hsia and Y-J Liao, “Advanced seamless vertical handoff architecture for WiMAX and WiFi heterogeneous networks with QoS guarantees”, Computer Communications, vol. 32, issue 2, pp. 281 – 293, February 2009  68.  F. Panken, G. Hoekstra, D. Barankanira, C. Francis, R. Schwendener, O. Grøndalen and M. Jaatun,”Extending 3G/WiMAX Networks and Service through Residential Access Capacity”, IEEE Communications Magazine, vol. 45, issue. 12, pp. 62 – 69, December 2007  69.  E. Stevens-Navarro, Y. Lin, and V. Wong, "An MDP-based Vertical Handoff Decision Algorithm for Heterogeneous Wireless Networks," IEEE Transactions on Vehicular Technology, vol. 57, no. 2, pp. 1243-1258, March 2008  70.  F. Bari and V. Leung, “Automated network selection in a heterogeneous wireless network environment”, IEEE Network, vol. 21, no. 1, pp. 34-40, January/February 2007  71.  Q. Zhang, C. Guo, Z. Guo and W. Zhu, “Efficient Mobility Management for Vertical Handoff between WWAN and WLAN”, IEEE Communications Magazine, vol. 41, issue 11, pp. 102 – 108, November 2003  72.  L. Eastwood, S. Migaldi, Q. Xie and V. Gupta, “Mobility Using IEEE 802.21 in a Heterogeneous IEEE 802.16/802.11-Based, IMT-Advanced (4G) Network”, IEEE Wireless Communications, vol. 15, issue 2, pp. 26 – 34, April 2008  73.  Z. Yan, H. Zhou, H. Zhang, H. Luo and S. Zhange, “A Dual Threshold-based Fast Vertical HO Scheme with Authentication Support”, In Proc. International Conference on Mobile Technology, Application and Systems 2008, September 2008  74.  J. Fabini, R. Pailer and P. Reichl, “Location-based assisted handover for the IP Multimedia Subsystem”, Computer Communications, vol. 31, issue 10, pp. 2367 – 2380, June 2008  75.  H-M. Sun, S-M. Chen, Y-H Chen, H-J Chung and I-H Lin, “Secure and Efficient Handover Schemes for Heterogeneous Networks”, In Proc. IEEE Asia-Pacific Services Computing Conference, pp. 205 – 210, Taiwan, December 2008  76.  V. Gondi and N. Agoulmine, “Secured Roaming Over WLAN and WiMAX Networks”, Proc. IEEE/IFIP Int. workshop on Broadband Convergence Network, BcN’07, Germany, May 2007 240  77.  H-H. Choi, O. Song and D-H. Cho, “Seamless Handoff Scheme Based on Pre-registration and Pre-authentication for UMTS-WLAN Interworking”, International Journal of Wireless Personal Communications, vol. 41, issue 3, pp. 345 – 364, 2006  78.  T. Leeuwen, I. Moerman, B. Dhoedt and P. Demeester, “Location Assisted Fast Vertical Handover for UMTS/WLAN Overlay Network”, Lecture Notes in Computer Science 3510, pp. 192 – 202, Springer Berlin Heidelberg 2005  79.  S-H. Lim, K-S Bang, O. Yi and J. Lim, “A Secure Handover Protocol Design in Wireless Networks with Formal Verification”, Lecture Notes in Computer Science 4517, pp. 67 – 78, Springer Berlin Heidelberg 2007  80.  S. Huang, H. Zhu and W. Zhang, “SAP: Seamless Authentication Protocol for Vertical handoff in Heterogeneous Wireless Networks”, The Third International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks, QShine 2006, Canada, August 2006  81.  H. Kwon, K. Ro and A. Park, “UMTS-WLAN Interworking Strategies for Reducing Handover Delays”, IEEE 64th Vehicular Technology Conference, VTC 2006, Canada, September 2006  82.  C. Perkins, E. Belding-Royer and S. Das, “Ad Hoc On-Demand Distance Vector (AODV) Routing, IETF RFC 3561, July 2003  83.  D. Johnson, Y. Hu and D. Maltz, “The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4”, IETF RFC 4728, February 2007  84.  C. Perkins and P. Bhagwat, “Highly dynamic Destination-Sequenced Distance Vector routing (DSDV) for mobile computers”, In Proc. of Conference on Communication Architectures Protocols and Applications, ACM SIGCOMM, pp. 234 – 244, UK, September 1994  85.  Y-C. Hu, A. Perrig and D. Johnson, “Ariadne: a secure on demand routing protocol for ad hoc network”, In Proc. of Annual International Conference on Mobile Computing and networking, MobiCom, USA, September 2002  86.  P. Papadimitratos, Z. Hass and P. Samar, “The secure routing protocol (SRP) for ad hoc networks”, IETF Internet Draft < Draft-papadimitratos-secure-routing-protocol-00.txt>, 2002  87.  B. Vaidya, B-L. Cho, J. Park and S. Han, “Investigating Secure Framework for Hybrid Multipath Ad Hoc Network”, In Proc. 22nd International Conference on Advanced Information Networking and Applications, AINA, pp. 1540 – 1545, Japan, March 2008  88.  B. Xie, A. Kumar and D. Agrawal, “Secure interconnection protocol for integrated Internet and ad hoc networks”, Wireless Communications and Mobile Computing, vol. 8, issue 9, pp. 1129 – 1148, November 2008 241  89.  H. Ammari, “A survey of current architectures for connecting wireless mobile ad hoc networks to the Internet”, International Journal of Communications Systems, vol. 20, issue 8, pp. 943 – 968, 2007  90.  Y. Sun, E. Belding-Royer and C. Perkins, “Internet Connectivity for Ad hoc Mobile Networks”, International Journal of Wireless Information Networks, vol. 9, no. 2, pp. 75 – 88, April 2002  91.  U. Jonsson, F. Alriksson, T. Larsson, P. Johansson and G. Maguire, “MIPMANET – Mobile IP for mobile ad hoc networks”, In Proc. of the 1st Annual Workshop on Mobile Ad Hoc Networking and Computing, MobiHoc 2000, USA, August 2000  92.  P. Ratanchandani and R. Kravets, “A hybrid approach to internet connectivity for mobile ad hoc networks”, In Proc. IEEE Wireless Communications and Networking Conference 2003, WCNC 2003, USA, March 2003  93.  J. Broch, D. Maltz and D. Johnson, “Supporting hierarchy and heterogeneous interfaces in multi-hop wireless ad hoc networks”, In Proc. of the 1999 International Symposium on Parallel Architectures, Algorithms and Network, ISPAN 1999, Australia, June 1999  94.  R. Kandikattu and L. Jacob, “Secure Internet Connectivity for Dynamic Source Routing (DSR) based Mobile Ad hoc Networks”, International Journal of Electronics, Circuits and Systems, vol. 2, number 1, pp. 40 – 45, 2008  95.  A. Al Shidhani and V.C.M. Leung, “Access Security in Heterogeneous Wireless Networks”, Security in Distributed and Networking Systems, Y. Xiao and Y. Pan, ed., World Scientific Publishing Co., August 2007  96.  A. Al Shidhani and V. Leung, “Local Fast Re-authentication protocol for 3G-WLAN interworking architecture”, In Proc. of Wireless Telecommunications Symposium, WTS 2007, USA, April 2007  97.  A. Al Shidhani and V.C.M. Leung, “Local Fast Re-authentication for 3G-WLAN Interworking”, Wiley Security and Communication Networks, vol. 1, no. 4, pp. 309-323, July/August 2008  98.  A. Al Shidhani and V. Leung, “Secured fast handover protocols for 3G-WLAN interworking architecture”, In Proc. of the 4th International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness, Qshine 2007, Canada, August 2007  99.  A. Al Shidhani and V.C.M. Leung, “Pre-authentication Schemes for UMTS-WLAN Interworking Architecture”, EURASIP Journal on Wireless Communications and Networking, vol 2009, Article ID 806563, pp. 1-16, 2009  100. B. Aboba, D. Simon and P. Eronen, “Extensible Authentication Protocol (EAP) Key Management Framework”, IETF RFC 5247, August 2008 242  101. W. Arbaugh, “Handoff Extension to RADIUS”, IETF Internet Draft (draft-irtf-aaaarchhandoff-04), October 2003 102. N. Banerjee, W. Wu, S. Das, S. Dawkins and J. Pathak, “Mobility Support in Wireless Internet”, IEEE Wireless Communications, vol. 10, issue 5, pp. 54 – 61, October 2003 103. A. Al Shidhani and V. Leung, “Enhancing the Performance of Secured Handover Protocols in UMTS-WiMAX interworking”, accepted for publication in ACM/Springer Wireless Networks on January 2010 104. T. Clancy, M. Nakhjiri, V. Narayanan and L. Dondeti, “Handover Key Management and Re-authentication Problem Statement”, IETF RFC 5169, March 2008. 105. S-H. Lee, N-S. Park and J-Y. Choi, “Secure Handover for Mobile WiMAX Networks”, IEICE Transaction on Information and Systems, vol. E91-D, no. 12, December 2008 106. S. Mohan, “Privacy and Authentication Protocols for PCS”, IEEE Personal Communications, vol. 3, issue. 5, pp. 34-38, October 1996 107. J. Lee and J. Lee, “Route Enhancement Scheme Using HMIP in Heterogeneous Wireless Data Networks”, Lecture Notes in Computer Science 3961, pp. 21-30, Springer Berlin Heidelberg, 2006 108. S. Pack and W. Lee, “Dual home agent (DHA)-based location management scheme in integrated cellular-WLAN networks” Computer Networks, vol. 52, no. 17, pp. 3273 - 3283, 2008 109. M. Kassab, J. Bonnin and A. Belghith, “Fast and secure handover in WLANs: An evaluation of the signaling overhead”, In Proc. of IEEE Computer Communications and Networking Conference, CCNC 2008, pp. 770 - 775, USA, January 2008 110. A. Hess and G. Schäfer, “Performance evaluation of AAA/Mobile IP Authentication”, In Proc. of 2nd Polish-German Teletraffic Symposium, PGTS’02, Poland, September 2002 111. R. Marin, P. Fernandez and A. Gomez, “3-Party Approach for Fast Handover in EAPBased Wireless Networks”, Lecture Notes in Computer Science 4804, pp. 1734-1751, Springer Berlin Heidelberg 2007 112. F. Allard, J-M Combes, R. Marin and A. Gomez, “Security Analysis and Security Optimization for the Context Transfer Protocol”, In Proc. 2nd International Conference on New Technologies, Mobility and Security, NTMS’08, Morocco, November 2008 113. J. Lo, J. Bishop and J. Eloff, “SMSSec: An end-to-end protocol for secure SMS”, Computers & Security, vol. 27, issue 5 – 6, pp. 154 – 167, October 2008 114. A. Al Shidhani and V.C.M. Leung, “Reducing Re-authentication Delays During UMTSWLAN Vertical Handovers”, In Proc. IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC’08, France, September 2008 243  115. A. Al Shidhani and V.C.M. Leung, “Fast and Secure Re-authentications for 3G Subscribers during WiMAX-WLAN Handovers”, accepted for publication in IEEE Transactions on Dependable and Secure Computing on April 2010. 116. A. Al Shidhani and V.C.M. Leung, “Secure and Efficient Multi-hop Mobile IP Registration Scheme for MANET-Internet Integrated Architecture”, In Proc. IEEE Wireless Communications and Networking Conference, WCNC 2010, Australia, April 2010 117. A. Al Shidhani and V.C.M. Leung, “Secure Integration between Mobile Ad Hoc Networks and Mobile IPv6”, In Proc. of IEEE Computer Communications and Networking Conference, CCNC 2010, USA, January 2010 118. D. Johnson, C. Perkins and J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004 119. D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin, “Protocol for Carrying Authentication for Network Access (PANA)”, IETF RFC 5191, May 2008 120. P. Jayaraman, R. Lopez, Y. Ohba, M. Parthasarathy and A. Yegin, “Protocol for Carrying Authentication for Network Access (PANA) Framework”, IETF RFC 5193, May 2008 121. J. Xi and C. Bettstetter, “Wireless Multihop Internet Access: gateway discovery, routing, and addressing”, In Proc. of International Conference on Third Generation Wireless and beyond (3G Wireless 2002), USA, May 2002 122. C. Perkins, J. Malinen, R. Wakikawa, A. Nilsson and A. Tuominen, “Internet connectivity for mobile ad hoc networks”, Wireless Communications and Mobile Computing. vol. 2, issue. 5, pp 465 – 482, 2002 123. R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson and A. Tuominen, “Global connectivity for IPv6 Mobile Ad Hoc Network”, IETF Internet Draft <draft-wakikawa-manet-globalv605.txt>, 2006 124. J. Jeong, J. Park, H. Kim, H. Jeong and D. Kim, “Ad Hoc IP Address Autoconfiguration”, IETF Internet Draft <draft-jeong-adhoc-ip-addr-autoconf-06.txt>, 2006 125. J-P Yoo, K. Kim, H. Choo, J-I Lee and J. Song, “Secure and Scalable Mobile IP Registration Scheme using PKI”, Lecture Notes in Computer Science 2668, pp. 220-229, Springer Berlin Heidelberg 2003 126. The OpenSSL Project, http://www.openssl.org 127. ANSI X9.62 (1999) Public key cryptography for the financial service industry: the elliptic curve digital signature algorithm (ECDSA)  244  128. R. Rivest, A. Shamir and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, vol. 21, issue 2, pp. 120 – 126, 1978 129. E. Baker, W. Burr, W. Polk and M. Smid. Recommendation for Key Management. NIST special publication 800-57, revised 2006 130. P. Prasithsangaree and P. Krishnamurthy, “On a framework for energy-efficient security protocols in wireless networks”, Computer Communications, vol. 27, issue. 17, pp. 1716 – 1729, November 2004 131. L. Feeney and M. Nilsson, “Investigating the energy consumption of a wireless network interface in an ad hoc networking environment”, In Proc. of IEEE Conference on Computer Communications, Infocom 2001, USA 2001 132. J-H. Yeh, J-C. Chen and P. Agrawal, “Fast Intra-Network and Cross-Layer Handover (FINCH) for WiMAX and Mobile Internet”, IEEE Transaction on Mobile Computing. vol. 8, No. 4, pp 558 – 574, April 2009 133. S-F. Hsu and Y-B. Lin, “A Key Caching Mechanism for Reducing WiMAX Authentication Cost in Handoff”, IEEE Transaction on Vehicular Technology. vol. 58, no. 8, pp 4507 – 4513, October 2009 134. R. Rajavelsamy and S. Choi, “Security Aspects of Inter-Access System Mobility Between 3GPP and non-3GPP Networks”, In Proc. of the 3rd International Conference on Communication System Software and Middleware, 2008, COMSWARE 2008, India, January 2008 135. Z. Dai, R. Fracchia, J. Gosteau, P. Pellati and G. Vivier, “Vertical handover criteria and algorithm in IEEE 802.11 and 802.16 hybrid networks”, In Proc. IEEE International Conference on Communications, ICC’08, pp. 2480 – 2484, China, May 2008 136. 3rd Generation Partnership Project, 3GPP Technical Specifications, 3G Security; Access Security for IP-based services (Release 9), 3GPP TS 33.203 v9.2.0, September 2009 137. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, “Proxy Mobile IPv6”, IETF RFC 5213, August 2008 138. P. Argyroudis, R. Verma, H. Tewari and D. O’Mahony, “Performance Analysis of Cryptographic Protocols on Handheld Devices”, In Proc. 3rd IEEE International Symposium on Network Computing and Applications, NCA’04, USA. August/September 2004 139. W. Liang and W. Wang, “On performance analysis of challenge/response based authentication in wireless networks”, Computer Networks, vol. 48, issue. 2, pp. 267 – 288, 2005 245  140. U. Varshney and R. Jain, “Issues in Emerging 4G Wireless Networks”, IEEE Computer Magazine, vol. 34, issue. 6, pp. 94 – 96, June 2001 141. M. Iacobucci, G. Paris, D. Simboli and G. Zitti,” Analysis and performance evaluation of wireless LAN handover”, In Proc. 2nd International Symposium on Wireless Communication Systems, ISWCS 2005, Italy, September 2005 142. Andreas Roos, Arne Keller, Andreas Schwarzbacher and Sabine Wieland, “Sequential authentication concept to improve WLAN handover performance”, Intelligent Interactive Assistant and Mobile Multimedia Computing, D. Tavangarian, T. Kirste, D. Timmermann, U. Lucke and D. Versick, Springer Berlin Heidelberg, pp. 295 – 306, 2009  246  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0069416/manifest

Comment

Related Items