Extensible Network Access Authentication - CiteSeerX

Extensible NetworkAccess Authentication

Thomas Otto

July 4, 2006

Administrator

IMPORTANT NOTICE This thesis was written during an employment at SIEMENS AG. For questions concerning reproduction of the content or parts of it, I recommend to contact my supervisor Hannes Tschofenig, [email protected]. Thomas Otto

Administrator

IMPORTANT NOTICE This thesis was written during an employment at SIEMENS AG. For questions around reproduction of the content or parts of it, I recommend to contact my supervisor Hannes Tschofenig, [email protected].

Preface

This diploma thesis is a continuation of my pre-master thesis [126], which I wrote in early2004 about authentication mechanisms in 802.11 wireless networks. It was mainly con-cerned with the analysis of WEP, IEEE 802.1X, EAP and some selected EAP methods. Inthe past two years, a lot of research has been made, which led to significant progresses.

In June 2004, IEEE released the standard for revised security mechanisms in 802.11Wireless LAN, called 802.11i. In the same month, the IETF EAP Working Group pub-lished its revised EAP specification in RFC 3748. Many new EAP methods have beenproposed, for instance EAP-PSK, EAP-PAX and EAP-SAKE. IEEE enhanced the authenti-cation capabilities for the mobility extension of IEEE 802.16 by EAP-based authentication.In June 2005, this amendment (802.16e) was finally adopted as IEEE Standard. Further-more, the 3GPP specified extensions for WLAN-based subscriber access, which makes useof EAP-SIM and EAP-AKA.

In early 2006, the EAP Working Group announced that it will conclude soon. Atthe same time, a new IETF Working Group entitled ”EAP Method Update” (EMU) wasfounded, which is occupied with the development and standardization of a shared secret-based EAP method, a password-based EAP method as well as the revision of the certificate-based EAP-TLS mechanism.

The goal of this diploma thesis is to survey research results from IETF, IEEE and 3GPPand to provide a comprehensive but nonetheless comprehensible analysis of EAP. The thesisconsists of three main parts,

• a survey of EAP,

• an in-depth analysis of the most important EAP methods, which are EAP-TLS, EAP-TTLS, EAP-FAST, EAP-PSK, EAP-PAX, EAP-IKEv2 and EAP-AKA,

• as well as an illustration of the three most important deployment scenarios for EAP,namely 802.11 WLAN, 802.16e WiMAX and 3G/WLAN Interworking.

This diploma thesis was written at Siemens AG, Corporate Technology (CT IC3) in Mu-nich. I would like to thank my advisor Hannes Tschofenig for his enduring support andfor enabling me to be involved in current projects, like contributing to EAP-IKEv2 [146],authoring EAP-TLS-PSK [128] and preparing input for the upcoming shared secret mecha-nism EAP-GPSK [40].

I am especially grateful to my first supervisor, Prof. Dr. Stefan Fischer, University ofLübeck. Without his support and confidence in me, this thesis would not exist.

Furthermore, I would like to thank Prof. Dr. Dieter Gollmann, Technical UniversityHamburg-Harburg, for serving as second supervisor for this thesis.

Stade, 06.07.2006 Thomas Otto

Contents

1 Introduction 11.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Network Access Authentication . . . . . . . . . . . . . . . . . . . . . . . 21.3 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 The Extensible Authentication Protocol 72.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 History of EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 EAP network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Characteristics of EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 EAP frames and messages . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 EAP authentication message flow . . . . . . . . . . . . . . . . . . . . . . . 172.7 EAP keying hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8 EAP encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8.1 EAP encapsulation in 802.11 . . . . . . . . . . . . . . . . . . . . . 212.8.2 EAP encapsulation in RADIUS . . . . . . . . . . . . . . . . . . . 222.8.3 EAP message flow in the IEEE 802.11i application . . . . . . . . . 28

2.9 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.9.1 EAP threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.9.2 EAP method security claims . . . . . . . . . . . . . . . . . . . . . 322.9.3 Determining the key strength . . . . . . . . . . . . . . . . . . . . . 342.9.4 EAP method requirements for IEEE 802.11 . . . . . . . . . . . . . 36

3 Analysis of EAP methods 393.1 EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.1.2 Transport Layer Security (TLS) . . . . . . . . . . . . . . . . . . . 40

3.1.2.1 Protocol overview . . . . . . . . . . . . . . . . . . . . . 403.1.2.2 Session resuming . . . . . . . . . . . . . . . . . . . . . 423.1.2.3 Authentication and key exchange within TLS . . . . . . 43

i

3.1.2.4 Key derivation within TLS . . . . . . . . . . . . . . . . 483.1.3 EAP-TLS Protocol overview . . . . . . . . . . . . . . . . . . . . . 503.1.4 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 503.1.5 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2 EAP-TTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.2 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2.3 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 553.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.3 EAP-FAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.2 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3.3 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.3.3.1 The Protected Access Credential . . . . . . . . . . . . . 593.3.3.2 Key derivation . . . . . . . . . . . . . . . . . . . . . . . 59

3.3.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4 EAP-PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.4.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.4.2 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . 623.4.3 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.4.3.1 The Implicit Key Exchange Protocol . . . . . . . . . . . 633.4.3.2 CMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.4.3.3 EAX mode of operation . . . . . . . . . . . . . . . . . . 643.4.3.4 Key derivation . . . . . . . . . . . . . . . . . . . . . . . 66

3.4.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.5 EAP-PAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.5.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.5.2 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . 693.5.3 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.5.3.1 Comparision of the four different modes . . . . . . . . . 703.5.3.2 Key derivation . . . . . . . . . . . . . . . . . . . . . . . 72

3.5.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.6 EAP-IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.6.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.6.2 Internet Key Exchange Protocol v2 (IKEv2) . . . . . . . . . . . . . 74

3.6.2.1 IKEv2 message flow . . . . . . . . . . . . . . . . . . . . 753.6.2.2 Key derivation within IKEv2 phase 1 . . . . . . . . . . . 763.6.2.3 Key derivation within IKEv2 phase 2 . . . . . . . . . . . 783.6.2.4 Authentication types within IKEv2 . . . . . . . . . . . . 78

ii

3.6.3 EAP-IKEv2 Protocol overview . . . . . . . . . . . . . . . . . . . . 813.6.4 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 823.6.5 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.7 EAP-AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.7.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.7.2 The UMTS AKA protocol . . . . . . . . . . . . . . . . . . . . . . 853.7.3 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . 863.7.4 Cryptographic design . . . . . . . . . . . . . . . . . . . . . . . . . 873.7.5 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.8 Further EAP methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.8.1 EAP-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.8.2 EAP-Cisco Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 913.8.3 PEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923.8.4 EAP-SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923.8.5 EAP-Double-TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 933.8.6 EAP-SAKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933.8.7 EAP-POTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4 EAP for Network Access Authentication 954.1 EAP in IEEE 802.11 Wireless LAN . . . . . . . . . . . . . . . . . . . . . 96

4.1.1 History of the 802.11 Standard . . . . . . . . . . . . . . . . . . . . 964.1.2 Legacy 802.11 authentication mechanisms . . . . . . . . . . . . . 98

4.1.2.1 Shared Key Authentication . . . . . . . . . . . . . . . . 984.1.2.2 Universal Access Method . . . . . . . . . . . . . . . . . 100

4.1.3 802.11i Authentication mechanisms . . . . . . . . . . . . . . . . . 1034.1.3.1 WPA2 Personal . . . . . . . . . . . . . . . . . . . . . . 1044.1.3.2 WPA2 Enterprise . . . . . . . . . . . . . . . . . . . . . 1054.1.3.3 802.11 key derivation function . . . . . . . . . . . . . . 1114.1.3.4 PMK caching and Pre-authentication . . . . . . . . . . . 1114.1.3.5 Improvements by 802.11 Task Group r . . . . . . . . . . 112

4.2 EAP in IEEE 802.16 Wireless MAN . . . . . . . . . . . . . . . . . . . . . 1134.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134.2.2 802.16 Network model . . . . . . . . . . . . . . . . . . . . . . . . 1134.2.3 The Privacy and Key Management (PKM) Protocol . . . . . . . . . 114

4.2.3.1 PKM RSA Authentication . . . . . . . . . . . . . . . . . 1154.2.3.2 PKM EAP Authentication . . . . . . . . . . . . . . . . . 1174.2.3.3 Authenticated EAP-after-RSA mode . . . . . . . . . . . 1194.2.3.4 Authenticated EAP-after-EAP mode . . . . . . . . . . . 119

4.2.4 802.16 Key derivation function . . . . . . . . . . . . . . . . . . . . 119

iii

4.3 EAP in 3GPP networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214.3.2 3GPP-WLAN interworking scenarios . . . . . . . . . . . . . . . . 1224.3.3 EAP in 3GPP WLAN interworking . . . . . . . . . . . . . . . . . 123

4.3.3.1 Interworking Scenario 2 . . . . . . . . . . . . . . . . . . 1244.3.3.2 Interworking Scenario 3 . . . . . . . . . . . . . . . . . . 125

5 Future Work 1295.1 Standardized EAP methods . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.2 Open issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.2.1 EAP method performance analysis . . . . . . . . . . . . . . . . . . 1325.2.2 Revision of EAP method requirements . . . . . . . . . . . . . . . . 1345.2.3 Outstanding environmental analysis . . . . . . . . . . . . . . . . . 136

6 Outlook 137

iv

List of Figures

1.1 ISO/OSI network layer model . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Example of today’s network attachment (from [13]) . . . . . . . . . . . . . 31.3 EAP layering model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 CHAP packet formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Abstract EAP model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 EAP network model with pass-through Authenticator . . . . . . . . . . . . 152.4 EAP packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 EAP packet formats in detail . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 Message flow of a successful EAP conversation . . . . . . . . . . . . . . . 182.7 EAP in a roaming scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8 EAP method internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.9 Transport of EAP in 802.11i network authentication . . . . . . . . . . . . . 212.10 EAPOL frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.11 EAP encapsulation in 802.1X / 802.11 . . . . . . . . . . . . . . . . . . . . 232.12 EAP encapsulation in RADIUS . . . . . . . . . . . . . . . . . . . . . . . . 242.13 RADIUS Access-Request and Access-Challenge encapsulating EAP . . . . 262.14 EAP in the 802.11i network attachment procedure . . . . . . . . . . . . . . 28

3.1 Full TLS handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2 Abbreviated TLS handshake . . . . . . . . . . . . . . . . . . . . . . . . . 433.3 Key sizes for equivalent security levels (in bit) [113, 120] . . . . . . . . . 473.4 TLS key hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.5 EAP-TLS message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.6 EAP-TTLS with tunneled CHAP . . . . . . . . . . . . . . . . . . . . . . . 54

3.7 EAP-FAST message flow . . . . . . . . . . . . . . . . . . . . . . . . . . 583.8 EAP-FAST key derivation function . . . . . . . . . . . . . . . . . . . . . 603.9 EAP-PSK message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.10 Implicit key exchange protocol AKEP2 . . . . . . . . . . . . . . . . . . . 633.11 EAP-PSK’s adoption of AKEP2 . . . . . . . . . . . . . . . . . . . . . . . 64

v

3.12 EAX encryption operation . . . . . . . . . . . . . . . . . . . . . . . . . . 653.13 Milenage modified counter mode . . . . . . . . . . . . . . . . . . . . . . 673.14 EAP-PSK key derivation function . . . . . . . . . . . . . . . . . . . . . . 673.15 EAP-PSK key derivation in detail . . . . . . . . . . . . . . . . . . . . . . 683.16 EAP-PAX_STD mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.17 EAP-PAX_SEC mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.18 Cryptographic core of EAP-PAX . . . . . . . . . . . . . . . . . . . . . . 713.19 Cryptographic agility offered by EAP-PAX . . . . . . . . . . . . . . . . . 72

3.20 EAP-PAX packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.21 EAP-PAX key derivation function . . . . . . . . . . . . . . . . . . . . . . 733.22 IKEv2 phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.23 IKEv2 phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.24 IKEv2 key derivation function . . . . . . . . . . . . . . . . . . . . . . . . 773.25 Key derivation within IKEv2 phase 1 . . . . . . . . . . . . . . . . . . . . 773.26 IKEv2 phase 1 authentication using EAP . . . . . . . . . . . . . . . . . . 803.27 EAP in IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.28 EAP-IKEv2 message flow . . . . . . . . . . . . . . . . . . . . . . . . . . 813.29 EAP-IKEv2 fast reconnect . . . . . . . . . . . . . . . . . . . . . . . . . . 823.30 EAP-IKEv2 key derivation in detail . . . . . . . . . . . . . . . . . . . . . 833.31 UMTS AKA authentication procedure . . . . . . . . . . . . . . . . . . . . 853.32 EAP-AKA message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.33 EAP-AKA key derivation function . . . . . . . . . . . . . . . . . . . . . . 883.34 Key derivation for EAP-AKA full authentication . . . . . . . . . . . . . . 893.35 EAP-MD5 message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.36 LEAP message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.1 Network families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.2 WEP encryption process and WEP-encrypted frame . . . . . . . . . . . . . 994.3 802.11 Open System and Shared Key Authentication . . . . . . . . . . . . 1004.4 Universal Access Method . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.5 802.11 network modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.6 IEEE 802.1X Port-based Network Access Control . . . . . . . . . . . . . . 1074.7 WPA2 Enterprise Network Model . . . . . . . . . . . . . . . . . . . . . . 1084.8 RSN Information Element . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.9 RSNA establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.10 802.11i key derivation function . . . . . . . . . . . . . . . . . . . . . . . . 1114.11 802.16 roaming reference model . . . . . . . . . . . . . . . . . . . . . . . 1144.12 PKMv2 RSA authentication . . . . . . . . . . . . . . . . . . . . . . . . . 1174.13 PKMv2 EAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . 118

vi

4.14 802.16e Double-EAP mode . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.15 Scenario for Double-EAP Mode . . . . . . . . . . . . . . . . . . . . . . . 1204.16 802.16 Key derivation function (CMAC-based Dot16KDF for PKMv2) . . 1214.17 802.16 Key derivation function (SHA-1-based Dot16KDF for PKMv2) . . . 1214.18 Reference model for 3GPP-WLAN interworking [1] . . . . . . . . . . . . 1254.19 3GPP-WLAN Interworking Scenario 2 . . . . . . . . . . . . . . . . . . . 1254.20 3GPP-WLAN Interworking Scenario 3 . . . . . . . . . . . . . . . . . . . 1264.21 Tunnel establishment between WLAN UE and PDG . . . . . . . . . . . . . 127

5.1 EAP-GPSK message flow . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.1 The SIGMA-I protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.2 EAP-SIGMA message flow (signature mode) . . . . . . . . . . . . . . . . 139

vii

List of Tables

2.1 EAP methods per 1995 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 EAP methods per 1998 (RFC 2284) . . . . . . . . . . . . . . . . . . . . . 112.3 Recommendations for key sizes with equivalent strength (I) . . . . . . . . . 352.4 Recommendations for key sizes with equivalent strength (II) . . . . . . . . 352.5 IETF’s recommendations for key sizes with equivalent strength . . . . . . . 36

3.1 Key exchange algorithms in TLS v1.0 . . . . . . . . . . . . . . . . . . . . 443.2 Performance of RSA and DSA operations . . . . . . . . . . . . . . . . . . 45

5.1 Goals and Milestones EMU Working Group [49] . . . . . . . . . . . . . . 1305.2 Performance of EAP-TTLS with 2048-bit certificates . . . . . . . . . . . . 133

ix

Notation

Throughout the thesis, the following notation is used.EA(M) Encryption of message M with the public key of entity A.MK Encryption of message M with a shared key K.MACK(M) Message Authentication Code computed over M, keyed with key K.SIGA(M) Digital signature of message M generated by entity A.

A, B Distinguished identifier of entities A resp. B.rA, rB Nonce generated by entities A resp. B.A→ B : M Message M, sent from A to B.⊕ exclusive OR (XOR)‖ concatenation[, ...] optional argument”identifier” stringdata [0..15] byte 0 to 15 of data

xi

Chapter 1

Introduction

This thesis is entitled "Extensible Network Access Authentication". Given as such, the titledoes not reveal very much about the goal or content of the thesis. But this title is the bestparaphrase of the Extensible Authentication Protocol (EAP), which this thesis focuses on.EAP provides a framework for extensible network access authentication.

Chapter 2 provides an overview of EAP, its origin and history, message flows and packetformats. Furthermore, the keying hierarchy and the security requirements for an EAPmethod are surveyed. Chapter 3 analyzes the most important of the currently proposed EAPmethods. Chapter 4 focuses on applications for EAP, namely IEEE 802.11, IEEE 802.16and 3G/UMTS. In Chapter 5, current work on EAP and EAP methods is surveyed and someselected open issues are identified. Chapter 6 concludes with an outlook on possible furtherdevelopments in the context of EAP.

This introduction is given by separating the thesis’ title in its single components whichare each individually dealt with. Hence, this chapter will look closer on the terms ”authen-tication”, ”network access authentication” and ”extensibility”.

1.1 Authentication

Authentication is a very important, probably the most important security service in com-puter security. However, it lacks a precise definition of this term. The literature distin-guishes between two kinds of authentication, message authentication, also known as dataorigin authentication, and entity authentication.

The goal of data origin authentication is to provide a proof of the authenticity of thedata, which can be verified by the receiver. Data origin authentication is typically realizedby computing a Message Authentication Code or a digital signature over the message.

However, the kind of authentication behind EAP is entity authentication. Unfortunately,there exists no precise definition of the term. [105] and [32] intensively deal with thisquestion. Instead of surveying all definitions, we silently agree on the following. Entityauthentication is the process of determining if an entity is who it claims to be.

Entity authentication occurs between two distinguished parties, commonly referred to as

1

2 Introduction

claimant and verifier. The claimant pretends an identity which belongs to an entity, typicallya user or device, and offers an adequate proof to the verifier.

Authentication can be accomplished by means of

• knowledge (e.g. a password),

• possession (e.g. a pre-shared key, a public key pair, a hardware token)

• biometric property (e.g. fingerprint, face recognition),

• occurence (to be at a particular place at a particular time), or also by a

• trusted third party (like the Authentication Server in the Kerberos authenticationframework).

Furthermore, one can distinguish between one-way and mutual authentication. Mutual au-thentication takes place if both entities authenticate each other in the same protocol. Itdoes not suffice to perform an unilateral authentication in each direction. Additionally,both runs must be interlocked adequately, for instance by incorporating the identities of theparticipants and some immediate values which bind the current protocol instance into thecomputation.

1.2 Network Access Authentication

Network access is a typical application that can be performed on layer 2 in the ISO/OSIreference model (Figure 1.1). Oftentimes, the term ”(data) link layer” is used instead of”layer 2”.

7 application layer

6 presentation layer

5 session layer

4 transport layer

3 network layer

2 data link layer

1 physical layer

Figure 1.1: ISO/OSI network layer model

The most important service that layer 2 offers layer 3 is to send data from a given sourceto a given destination over a dedicated link. Layer 2 is capable to deal with transmission

1.2 Network Access Authentication 3

errors. The physical layer transmits raw bit streams between the two parties, while it han-dles and hides media-specific questions. The link layer can detect and correct transmissionerrors. In addition, it can implement a retransmission mechanism or flow control, to get fastsenders and slow receivers coordinated.

There are good reasons to perform network access authentication at layer 2 and not athigher layers. As the name already implies, the main goal is to obtain network access. Thedecision to grant network access depends on the result of an authentication procedure, but itcan be decided at the edge of the network. That is, there is no need to obtain an IP addressprior that the peer has successfully authenticated.

The authentication procedure is carried out between the peer and a node on the edgeof the network, oftentimes called Network Access Server (NAS), to which a point-to-pointconnection is established. Either the NAS has enough knowledge to perform the authen-tication self or it relays the authentication procedure to another node inside the network,oftentimes referred to as Authentication Server (AS).

networkaccess

Beacon

and Association802.11 Authentication

802.11 Attachment

802.11i 4−Way Handshake

IPv6 Router Discovery

MLD

IPv6 DAD

NEMO / MIPv6 Reg

home nodeclient

MIPv6 RO Reg

802.1X and EAP

Figure 1.2: Example of today’s network attachment (from [13])

4 Introduction

Since layer 2 traffic is not routeable, it would have to be encapsulated in a routeablehigher layer protocol. A very common choice to transmit EAP packets between NAS andAS is to encapsulate EAP packets in RADIUS or Diameter. Another problem of a layer 2protocol is that it is not scalable, thus one must take care during the protocol design thatit does not utilize properties of a specific link layer. For instance, not all link layer relyon the concept of unique hardware addresses. While Ethernet utilizes unique 6-byte MACaddresses, PPP has no device addresses at all. A layer 3 protocol like IPsec seems to havean advantage here, because it is independent from the underlying link layer. However, itrelies on IP, and there might be situations where availability of IP is simply not given.

Usually, several steps must be performed before a device has gained sufficient end-to-end connectivity for its applications. This initial procedure performed by a device con-necting to a network is referred to as network attachment procedure. In current attachmentprocedures, typical steps are parameter agreement on link layer, access control, authentica-tion and network layer configuration.

The IEEE 802.11i network attachment procedure, for instance, which is partially re-peated in Section 4.1.3, consists of network detection, authentication and association at linklayer, IP address assignment, router discovery and mobility tasks. Figure 1.2 depicts the802.11 network attachment procedure in the IPv6 setting (cf. [18, 13]). There are at least27 messages, assumed that the EAP method consists of two roundtrips1 only.

Obviously, network attachment procedures are susceptible for high latency, caused bythe large number of exchanged messages on link layer and network layer. Therefore, everystep must be designed as efficient as possible, while preserving the overall security. Theconsequence for the remainder of the thesis is the insight, that network access authenticationis only one step next to many others in a network attachment procedure.

1.3 Extensibility

When designing a protocol, a tradeoff must be made between flexibility and complexity.The more flexibility is introduced, for instance by allowing for extensions or for variationin cryptographic algorithms, the more complexity is added to the protocol’s state machine.In general, however, flexiblity is considered as a very appreciable feature, because it makesthe protocol resistant to changes in the future.

Most current security protocols offer some kind of flexibility. TLS allows to add authen-tication and key exchange mechanisms by means of specifying new ciphersuites. IKEv2performs initial negotiation of the encryption algorithm, the hash function, the pseudoran-dom function as well as the Diffie-Hellman group. In that IKEv2 allows additionally toperform EAP-based authentication, it also offers a high degree of flexibility.

An example where no flexibility was taken into account, is the Kerberos authentica-tion framework, which relies on the Needham-Schroder three-party authentication protocol.Kerberos is susceptible for brute-force dictionary attacks, which cannot be solved within the

1The first roundtrip is assumed to be an Identity exchange; then, EAP-AKA is the only EAP method whichwould fit in the message flow of Figure 1.2.

1.3 Extensibility 5

scope of Kerberos, at least not without making significant changes to the core protocol - onewould have to tunnel Kerberos through an IPsec or TLS tunnel to mitigate this threat. Fromthe point on when this weakness was found, the interest in Kerberos rapidly decreased.

EAP provides extensibility regarding its authentication mechanisms without that theprotocol’s complexity increases. This is the most notable property that distinguishes EAPfrom many other proposals - it separates the transport protocol from the authentication pro-tocol and makes them both modular. Extensibility in the context of EAP means to allowfor additional authentication protocols, referred to as EAP methods, without the necessity toadapt the transport protocol. These different layers are called EAP method layer and EAPlayer, as shown in Figure 1.3. The EAP server located in the access network can decide foreach authentication run the EAP method, represented by a unique 1-byte identifier, the socalled EAP type number. It is sent as part of the EAP packet header.

EAP−PSKEAP−TLS EAP−FAST

802.1X802.11/ IP/UDP/

IKEv2PKMv2

EAP−AKA

802.3Ethernet

EAP method layer

EAP layer

Lower layer802.16e/

EAP

Figure 1.3: EAP layering model

If an authentication mechanism turns out to be insecure (e.g. EAP-MD5) or encum-bered by IPR claims (e.g. EAP-SRP), then the implementation will not support these typesanymore. However, there is no need to abandon the whole (EAP) protocol in case that onemechanism would have to be discarded.

More than 40 EAP methods are specified at present. They vary, for instance, in the wayhow client and server authenticate each other, or in terms of computational costs. In thissense, EAP offers flexible and extensible authentication. One might now ask whether not asingle mechanism could be sufficient - but indeed, there exist no single mechanism whichaddresses all needs. IKEv2 offers cryptographic flexibility, TLS some kind of extensibility(by adding new ciphersuites) - however, the basic message flow remains the same. Thisis different in the case of EAP, where the message flow totally depends on the selectedEAP method. There are only the following requirements on the message flow. It must beinitiated by the server, not by the peer, and it must consist of message pairs except for thelast message, which carries the authentication result and which is either an EAP-Success oran EAP-Failure message.

6 Introduction

Chapter 2

The Extensible AuthenticationProtocol

2.1 Motivation

The Extensible Authentication Protocol (EAP) was designed to enable extensible authenti-cation for network access in situations where the Internet Protocol is not available. Actuallydeveloped for use with PPP [139], it has been applied subsequently to IEEE 802 wired net-works [74], wireless networks such as IEEE 802.11i [81] and IEEE 802.16e [75] as well asIKEv2 [91].

EAP allows for various authentication mechanisms, in the following called EAP meth-ods. As stated in Chapter 1, EAP was developed for network access authentication purposeson data link layer (layer 2 in the ISO/OSI reference model). The only requirement EAPposes to its lower layer is that packets have to arrive in order. In contrast, retransmissionand duplicate elimination are addressed by EAP. Regarding the packet size, EAP guaranteesa so-called minimum EAP MTU (maximum transfer unit) of 1020 byte. EAP methods thatexceed this packet size must support a mechanism for fragmentation.

In that EAP runs on layer 2, EAP distinguishes itself from other authentication mech-anisms developed in the IETF, most notably SASL (Simple Authentication and SecurityLayer), GSS-API (Generic Security Services API), TLS (Transport Layer Security) andIKEv2 (Internet Key Exchange v2), which run all on higher layers. But as figured out in theprevious chapter, layer 2 is particularly suited for network access authentication purposes.

The most significant advantage of EAP is its flexibility which is introduced by the rig-orous separation of transport protocol and authentication protocol. EAP specifies the mes-sage exchange and packet formats (the ”container”), while the authentication protocol (the”logic”) is encapsulated in EAP methods. The EAP specification offers four very basic EAPmethods where one of them, EAP-MD5, is the mandatory-to-implement mechanism.

Instead of having pre-negotiated a specific EAP method, the choice of a suitable EAPmethod is within the scope of the EAP server. Except for the requirement that implementa-tions must support EAP-MD5, which encapsulates the MD5-based CHAP handshake, thereis not a single further cryptographic algorithm fixed. Decisions about cryptographic param-

7

8 The Extensible Authentication Protocol

eters are within the responsibility of the EAP method.The remainder of Chapter 2 is organized as follows. The circumstance that EAP has its

origin in PPP is helpful to understand its design, for instance, that EAP does not have built-inprotection mechanisms. Therefore, some historic remarks are presented. The remainder ofthe chapter, however, will point out that EAP in its current specification is much more thana PPP enhancement. EAP’s three-party model is introduced and the participating entitiesare described. EAP is characterized by four fundamental properties, called EAP invari-ants, which are discussed next, before technical details on the packet format and messagetypes are provided. This is prerequisite to describe and understand the EAP authenticationprocedure.

An EAP method must fulfil several requirements regarding authentication, key deriva-tion and security properties. Particularly if an authentication has finished successfully, anEAP method must derive certain keying material on both sides, which is exported and laterused to protect subsequent communication. All these issues are broadly studied. Since EAPdoes not have a header which makes the packets routable, EAP must be appropriately encap-sulated. The thesis restricts itself to the most popular application, namely its encapsulationwithin 802.1X and RADIUS. Knowledge about the encapsulation is helpful for Chapter 4.

2.2 History of EAP

The acknowledgment section of RFC 3748 states that EAP derives ”much of its inspirationfrom Dave Carrel’s AHA document, as well as the PPP CHAP protocol [RFC1994]” ([5],p.57). That is, EAP’s history dates back until the year 1994. In the meeting minutes of thePPPEXT WG1 of March 19942, a paragraph mentions a discussion about three protocolsdescribing enhanced authentication procedures for PPP.

These protocols are ”The Arbitrary Handshake Authentication (AHA) protocol” (draft-ietf-pppext-aha-auth-00.txt), ”The Generic Authentication Protocol (GAP)” (draft-ietf-pppext-gap-auth-00.txt), and the ”PPP Kerberos Authentication Protocol (KAP)” (draft-ietf-pppext-kap-auth-00.txt). Although all of these protocols have been disappeared in the meantime,and indeed no electronic version can still be found in the Internet, the clue might be to lookcloser at Point-to-Point (PPP) protocol.

The name ”Extensible Authentication Protocol” was introduced in 1995 and entitlesan enhancement specification for the PPP protocol [139]. PPP was ratified only one yearago, in July 1994. For a better understanding of the motivation behind EAP, the PPP au-thentication procedure will be focused on. The establishment of a PPP connection requiresfour phases, called Link Establishment Phase, User Authentication Phase (optional), Call-back Phase, and Configuration Phase. During the Link Establishment Phase, both sidesexchange LCP (Link Control Protocol) packets to configure the data link. The endpointsof the link are referred to as peer and authenticator. After the link has been established,PPP provides for an optional Authentication Phase. The authenticator indicates to enter the

1Point-to-Point Protocol Extensions Working Group2http://mirror.switch.ch/ftp/doc/ietf/pppext/pppext-minutes-94mar.txt

2.2 History of EAP 9

Authentication Phase by sending an Authentication-Protocol Configuration Option duringthe Link Establishment Phase.

Originally, PPP authentication was addressed by two authentication protocols, namely

• PAP (Password Authentication Protocol [102]) and

• CHAP (Challenge Handshake Authentication Protocol [140]).

PAP and CHAP rely on a shared secret, mostly a password, known only to the peer and theauthenticator. While PAP transmits username and password in plaintext, CHAP improvesthis shortcoming in that the password is not sent directly over the link, but rather goes asinput in an one-way hash function. According to the CHAP specification, the passwordmust have a length of at least 1 byte, although it recommends a length comparable to theoutput of the hash function. In case of MD5, this would mean 16 byte.

The CHAP packet format is depicted in Figure 2.1.

LengthCode Identifier

1 Challenge2 Response

NameValueValue−Size


"4"3 Success4 Failure

Figure 2.1: CHAP packet formats

The fields have the following meaning.

Code CHAP defines four message types, indicated by the 1-byte Code field.

1 Challenge2 Response3 Success4 Failure

Identifier This field aids to bring a CHAP Challenge and the CHAP Response sent inreply together. Therefore, the Challenge Identifier field must be different for eachchallenge. The Response Identifier is then copied from the Identifier field of theChallenge which caused the Response.

Length The Length field contains the length of the whole CHAP packet in byte.


Value-Size This field contains the size of the Value field in byte.

Value For a CHAP Challenge, the Value field encapsulates the CHAP Challenge message.For a CHAP Response, this field contains the MD5 hash over various parameters ofthe session.

Name There are no limitations on this field’s content. Its length, however, is determinedby the Length field.

A CHAP authentication consists of three messages.

1. In the first message, the authenticator sends a ”challenge” message, which is uniqueand unpredictible for the peer.

2. The peer then computes a MD5 hash over the identifier (from the CHAP Challengepacket), the password and the challenge. The second message transmits this hashvalue and the peer’s username.

3. The authenticator checks the response against its own calculation of the expectedMD5 hash value. If both values match, the authentication is successful. The thirdmessage is sent from the authenticator to the peer and contains the authenticationresult.

Due to the unique challenge chosen by the authenticator and the incorporation of the iden-tifier and the challenge into the MD5 hash, CHAP provides replay attack protection. How-ever, an eavesdropper who has captured a successful CHAP authentication can initiate abrute-force dictionary attack to reveal the password. As a consequence, there was still needfor a PPP extension which does not suffer from these shortcomings but provides at thesame time sufficient flexibility to add further authentication mechanisms. This motivatedthe development of a more general protocol for PPP authentication.

In March 1995, the ”PPP Extensible Authentication Protocol (EAP)” [27] was pub-lished.

EAP provides the required flexibility in that it does not negotiate a specific authentica-tion mechanism during Link Control Phase, but rather postpones this choice until the Au-thentication Phase. This modification allows the authenticator to request more informationbefore determining the specific authentication mechanism.

The flexiblity also permits to use a backend authentication server which implementsthe different authentication mechanisms while the PPP authenticator merely acts as pass-through of the messages. In other words, the authenticator does not need to have knowl-edge of the specific authentication mechanism that peer and backend server have previouslyagreed upon. The authenticator only needs to look for a Success or Failure packet to termi-nate the PPP Authentication Phase.

Of course, not much of this very early stage of EAP is still existent in the current EAPspecification, because its application was restricted to PPP. However, three of the 1995’EAP authentication types have survived until today, namely numbers 1-3. The 1995’ list

2.2 History of EAP 11

contains another interesting fact. While there are currently motions to develop an EAP-Kerberos method, a similar mechanism already existed in the past (EAP Type 10 and 11).

1 Identity2 Notification3 Nak (Response only)4 Password5 MD5-Challenge6 MD4-S/Key7 MD5-S/Key8 Echoed user input9 Non-echoed user input10 Kerberos V411 Kerboros V5240-255 Vendor Specific (reserved)

Table 2.1: EAP methods per 1995

The PPP-EAP specification [27] was updated twice in the ensuing time. At the IETFmeeting in March 1998, the PPPEXT WG adopted EAP as Proposed Standard. It waspublished in RFC 2284 [28], which comprises 16 pages only.

EAP inherits many characteristics and features of CHAP, also the four message typesand the packet formats. Only ”Challenge” was renamed to ”Request”. In comparison to the1995’ version, RFC 2284 mandates an EAP implementation to mandatorily support EAPtypes 1-4, listed in Figure 2.2. This claim was maintained by RFC 3748 ([5], Section 5) forbackward compatibility.

1 Identity2 Notification3 Nak (Response only)4 MD5-Challenge5 One-Time Password (OTP) (RFC 1938)6 Generic Token Card (GTC)254 Expanded Types255 Experimental use

Table 2.2: EAP methods per 1998 (RFC 2284)

At the mentioned IETF meeting of March 1998, several EAP methods have been dis-cussed, namely EAP-TLS, the public-key mechanisms EAP-RSA, EAP-DSS and EAP-KEA as well as EAP-ISAKMP. The latter mechanism describes how to combine ISAKMPwith Oakley key exchange and how the result is encapsulated in EAP. Today, EAP-TLS isthe only EAP method of these early days which has survived - all other EAP methods have


disappeared in the meantime, although many of them have allocated an EAP type number byIANA. Appendix A in the back of this thesis lists all currently assigned EAP type numbers.

At the IETF meeting 43 in December 1998, a first attempt was made to establish anEAP Working Group. However, the charter of the Working Group had a completely otherintention, herein after mentioned three items,

• to unify existing authentication frameworks like SASL, GSS-API and EAP,

• to consider an establishment of a moratorium addressing the introduction of new au-thentication frameworks, like XAUTH

• and to develop an EAP Type for GSS-API.

The corresponding Meeting Report [10] gives insight for this direction. ”The focus of EAPis to provided extended authentication in situations where IP is not available. SASL cannotsubstitute for EAP since it does not provide transport services, as EAP does. It was notedthat while EAP methods can provide extended security services, including public key au-thentication, integrity and replay protection, these services are not provided by EAP itself.[...] Within the overall architecture, it is best to think of both SASL and EAP as protocolsfor encapsulation of authentication methods provided by GSS_API. Thus rather than addingnew methods to SASL, it is best for new authentication methods to be added to GSS_API,where they can become available within EAP as well as SASL. This will provide the mostefficient use of resources.”

This meeting did not lead to the foundation of an EAP Working Group, so that EAPremained an item of the PPPEXT Working Group. After many months of high activityand enthusiasm, it became more and more silent. In subsequent PPPEXT Working Groupmeetings, the interest went from EAP to completely other issues. At two IETF conferencesin 2000, the PPPEXT Working Group did not meet at all.

In 2001, EAP regained popularity when IEEE 802.11 Task Group i (TGi) signalizedtheir interest in the EAP framework. 802.11 TGi was chartered with the development ofa revised security architecture for the 802.11 Wireless LAN architecture. They were stilllooking for a key management and authentication mechanism which covers all needs, ad-dresses all requirements but provides at the same time enough flexibility for extensions.

The most prevalent issue was to choose an authentication mechanism supporting ubiqui-tous authentication credentials. Credentials which had to be taken into account were digitalcertificates, token cards, passwords and re-use of cellular network credentials. To addressthese diverse authentication needs, IEEE 802.11i decided to adopt IEEE 802.1X, the Stan-dard for Port-based Network Access Control, for improved access control, authenticationand key management. 802.1X in turn strongly relies on EAP. Due to this transitive relation,EAP gained more and more attention.

In 2001, numerous new EAP methods were proposed, for instance EAP-SRP-SHA1 inJuly 2001 and EAP-TTLS (Tunneled TLS) in August 2001. Facing this new applicationfield for EAP and the high interest in it, the community held an EAP BoF meeting at the53th IETF conference in March 2002. One of the main goals was to avoid rewriting EAP

2.3 EAP network model 13

from the scratch (”this is not EAP NG”3) and to maintain backward compatiblity with AAAinterfaces to RADIUS and Diameter. At the EAP BOF, several EAP methods have been dis-cussed, namely EAP-TTLS, PEAP, EAP-SIM, EAP-AKA, EAP-SKE, EAP-MSCHAPv2,and EAP-SPEKE.

Among the goals and milestones of the working group, the work on an EAP state ma-chine, an EAP keying framework and a revision of RFC 2284 is found. In contrast, theworking group was not chartered with any development, review or standardization of EAPmethods.

EAP had to be thoroughly revised in light of the new applications. In mid 2004, therevised EAP specification was finally adopted as Proposed Standard in RFC 3748 - abouttwo years later than expected - and also the state machine specification was published. Atthe 65th IETF meeting in March 2006, the EAP WG announced that almost all of its workitems are closed, except for the EAP Key Management Framework and Network Selectiondocuments. Both have completed the Working Group’s last call. The meeting report gives ahint that this might have been the last meeting of the EAP WG, depending on how fast theopen issues can be solved.

2.3 EAP network model

Figure 2.2 depicts the abstract network model of EAP. It consists of three entities, the EAPpeer, the Authenticator and the EAP server. Authentication in EAP takes place betweenEAP peer and EAP server as endpoints of the link. However, EAP allows that EAP peerand EAP server are not directly connected, but that all communication is relayed by someintermediate node, the so called Authenticator. Consequently two EAP network modelsexist, namely

• that EAP peer and EAP server are directly connected, which means that Authenticatorand EAP server reside on the same node,

• or that an Authenticator exists acting as pass-through device.

Note that the nodes which relay the traffic are not known and do not have to authenticatethemselves to the peer.

The following terminology will be used throughout this thesis.

Authenticator The Authenticator denotes the end of the link which initiates the EAP au-thentication. The term ”Authenticator” is used in IEEE 802.1X, and Authenticatorhas the same meaning in the scope of EAP. In AAA terminology (e.g. [8]), the terms”Network Access Server” (NAS) as device providing access to the network and ”RA-DIUS client” are used synonymously for ”Authenticator”.

(EAP) peer The end of the link that responds to the Authenticator.

3http://www3.ietf.org/proceedings/02nov/136.htm


EAP peer Authenticator EAP server

EAP EAP

Figure 2.2: Abstract EAP model

Backend Authentication server A backend Authentication server is an entity that pro-vides an authentication service to an Authenticator. This terminology is also usedin IEEE 802.1X.

EAP server The entity that terminates the EAP authentication method with the peer. Incase that no backend Authentication server is used, the EAP server is part of theAuthenticator. In case that the Authenticator operates in pass-through mode, theEAP server is located on the backend Authentication server. In this thesis, the termsEAP server, backend Authentication server and (backend) AAA server are used in-terchangeably.

Master Session Key (MSK) The MSK is keying material derived between peer and EAPserver, having at least 64 byte in length. It is exported by the EAP method. The EAPserver typically transmits the MSK to the Authenticator - in this context, the MSK isalso called ’AAA-Key’.

Extended Master Session Key (EMSK) The EMSK is additional keying material derivedbetween the peer and server that is exported by the EAP method. The EMSK is atleast 64 byte in length, and is never shared with a third party.

2.4 Characteristics of EAP

The Keying Framwork document [7] elaborates four basic characteristics of EAP, also re-ferred to as ’EAP invariants’. These invariants are basically assurances which hold for EAPimplementations on all media.

Mode Independence EAP supports two modes. Either an Authenticator is deployed stand-alone, so that the EAP conversation takes place between peer and Authenticator, orthe Authenticator is utilized in pass-through mode. In the former case, the Authenti-cator must have locally implemented those EAP methods which he supports. In thelatter case, new EAP methods may be introduced without requiring to update the Au-thenticator.

2.4 Characteristics of EAP 15

(1)

(2)

(3)

EAP server

initiates EAP conversation

EAP peer

EAP method execution

Authenticator

Result indication (e.g. EAP−Success)Result indication (e.g. EAP−Success)

Transmission of MSK

Figure 2.3: EAP network model with pass-through Authenticator

This becomes possible because the Authenticator relays only EAP traffic without in-terpreting it. Of course, both modes are allowed to run concurrently - some users areauthenticated locally, some with aid of a backend Authentication server. The ”modeindependence” property claims that an EAP method operates identically in all aspectsregardless of whether the authenticator is operating in pass-through mode or not.

Media Independence EAP allows EAP methods to work on any lower layer. At present,EAP runs over PPP, IEEE 802 wired networks (802.3, 802.5), IEEE wireless networks(802.11, 802.16e), as well as on top of UDP/IKEv2 and TCP/TLS. On the downside,EAP methods may not use elements of a specific lower layer, like a MAC address ora BSSID, even if they are designed for that particular application only.

Method Independence EAP requires the Authenticator to support any EAP method. Thisis obtained when the Authenticator runs in pass-through mode. Consequently, the Au-thenticator is not required to implement EAP methods but rather restricts on relayingthe EAP conversation between EAP peer and EAP server.

Ciphersuite Independence EAP methods must generate keying material (MSK, EMSK)in adequate length and sufficient entropy4 to be applicable for any ciphersuite, thatis, the keying material must be ciphersuite-independent. While an EAP method hascontrol over the ciphersuite used in protection of the EAP conversation, the cipher-suite used for the protection of data exchanges subsequent to the EAP authenticationconversation is outside the scope of EAP.

4Entropy is a measure for unpredictability. It is defined as negative logarithm of the process’s most likelyoutput [58]. For instance, consider a N-bit binary string with uniformly distributed 0/1s. Each possible N-bitstring thus has the same probability (2−N ) of being produced. The entropy a uniformly distributed N-bit stringis then -log(2−N )=N.


2.5 EAP frames and messages

The general EAP packet format is shown in Figure 2.4. The fields are transmitted from leftto right.

Identifier DataLengthCode

variable length1 byte 2 byte1 byte

Figure 2.4: EAP packet format

Code EAP defines four message types, indicated by the Code field.

1 Request2 Response3 Success4 Failure

Code EAP-Request messages are transmitted only in the direction from Authenticator toEAP peer. Vice versa, EAP-Response messages occur only in direction from EAPpeer to Authenticator. The peer must send a Response packet in reply to a valid Re-quest packet. In the following, these two messages are also referred to as ”messageexchange” or ’roundtrip”.

After completion of an EAP authentication method of Type 4 or greater, the Authen-ticator sends an EAP-Success or EAP-Failure (Code 3 or 4), where an EAP-Successis sent after successful completion and an EAP-Failure after unsuccessful completionof the EAP method.

Identifier The Identifier field is one byte and aids in matching Responses with Requests.If a packet is retransmitted, then the identifier must be the same.

Length The Length field is two byte and contains the length over the whole EAP frame,i.e. Code, Identifier, Length and Data fields.

Data The Data field has variable length, which depends on the Code field. Request and Re-sponse messages carry in their payload a specific EAP method. In this case, the Datafield consists of a 1-byte Type field which gives a hint on the EAP method encapsu-lated in the Payload field. Its content thus fully depends on the respectively chosenEAP method.

2.6 EAP authentication message flow 17

EAP-Success and EAP-Failure messages do not have Type and Data fields. Con-sequently, the length of those EAP messages is constantly 4 byte. For illustrativepurposes, Figure 2.5 shows the two different EAP packet formats.

LengthCode Identifier Payload

...

Type

1 Identity

13 EAP−TLS

1 EAP−Request

2 EAP−Response


3 EAP−Success4 EAP−Failure

"4"

Figure 2.5: EAP packet formats in detail

For further details on EAP packets and their characteristics, RFC 3748 Section 4 shouldbe referenced. Some facts not yet mentioned are:

• If an EAP method will likely have packet sizes that exceed 1024 byte, it must includesupport for fragmentation and reassembly.

• An EAP method must protect its payload itself against forgery, replay and modifica-tion. The EAP frame format has no field reserved for this purpose. As a consequence,messages which indictate the result of the authentication procedure, EAP-Success andEAP-Failure, can easily be spoofed.

2.6 EAP authentication message flow

Figure 2.6 depicts the message flow of an EAP authentication conversation. It consistsof exchanges of EAP-Request and EAP-Response message pairs concluding by an EAP-Success or EAP-Failure message. The peer relates his EAP-Response to the received EAP-Request by copying the Requests’ identifier into his EAP-Response packet. Each validEAP-Request must be replied by the peer with an EAP-Response. Furthermore, a newEAP-Request cannot be sent unless a valid Response has been received.

Usually, the initial EAP exchange is an Identity exchange (Type 1). Since this exchangeis optional, it can be omitted entirely. Consequently an EAP method must use a method-specific identity exchange, preferably through an established protected channel. However,in roaming situations, the identifier may help to locate the appropriate backend Authentica-tion server before the actual authentication takes place. This is realized by interpreting therealm portion of the Network Access Identifier (NAI).


EAP peer Authenticator

(1)

(2)

(3)

(4)

(5)

EAP−Response / Identity

EAP−Request / Identity

EAP−Request / EAP−Type=X (...)

EAP−Response / EAP−Type=X (...)

EAP method authentication

EAP−Success / EAP−Failure

takes place in subsequent messageexchanges

Figure 2.6: Message flow of a successful EAP conversation

The NAI is formally specified in RFC 4282 [9] and provides a standardized methodfor identifying users. Valid NAI constructions are username, @realm or [email protected] roaming situations, the user’s home Authentication server must be determined. This isobtained by interpreting the NAI’s realm part.

In the example illustrated in Figure 2.7, the roaming client (being a client of t-mobile.de)is connected to the foreign network telefonica.es, whose AAA server interprets therealm portion t-mobile.de and thus is capable to route the EAP conversation to the user’shome network. [9] allows that the client can also omit the peer-name portion of the NAI inroaming scenarios, so that the EAP-Response/Identity could alternatively encapsulate theidentifier ”@t-mobile.de” only.

2.7 EAP keying hierarchy

Generation of keying material is within the responsability of an EAP method. Parts of thiskeying material may be used by the EAP method internally and parts of this material maybe exported. As depicted in Figure 2.8, the EAP method key derivation has at the root thelong term-credential, which is typically a long-term secret. For a pre-shared key based EAPmethod, this long-term credential is the pre-shared key. For a certificate-based EAP method,this long-term credential is the private key associated with the certificate.

During an EAP conversation, two kinds of keys are derived:

2.7 EAP keying hierarchy 19

NAS

AAA−H

NAS

EAP−Request/Identity

t−mobile.de

telefonica.es

Network

HomeNetwork

RoamingClient

EAP−Response/Identity(00491214@t−mobile.de)

EAP conversation

Foreign

AAA−V

NAS

NAS

��

��

��

��

Figure 2.7: EAP in a roaming scenario

• Keys which are used only locally by the EAP method but which are not exported.These are mainly session keys which are computed as intermediate result or as by-product.

• Keys which are exported by the EAP method, namely a Master Session Key (MSK),an Extended Master Session Key (EMSK) and an Initialization Vector (IV). All threekeys must have at least 64 byte length. An EAP method must derive MSK and EMSK,while the derivation of IV is optional. Specific usage of these keys is not within thescope of EAP.

The EMSK is reserved solely for the purpose of deriving master keys for one or morepurposes identified as usage definitions. Such an application is specified in [137].

There are still other parameters which an EAP method has to specify, namely method-specific peer and server identifiers (Peer-Id and Server-Id), a method-specific EAP con-versation identifier (Session-Id), and the lifetime of the exported keys (Key-Lifetime). Aspreviously mentioned, the identity transmitted in the EAP-Identity exchange may be differ-ent from the peer identity authenticated by the EAP method. If an EAP method defines amethod-specific peer identity, that identity is exported by the method as the Peer-Id. Thesame holds for the server identity and Server-Id.

The contents of Client-Id and Server-Id have no specific format. The Server-Id couldprovide the client with a hint of what secret to use. It might possibly be provisioned withthe shared secret. Open questions, however, are whether the Server-Id can be associatedwith a service, or whether the client should be enabled to specify a Server-Id that it shares asecret with. These questions are currently subject to discussions.


Key−Lifetime

MSK, EMSK

IV (64 Bytes)MSK (64+ Bytes)EMSK (64+ Bytes)

ChannelBinding&Result

DerivationDerivation DerivationIV

Long−term credential

TEK

EAP methodkey derivation

EAP method

exported by Server−IdSession−Id

Peer−Id

EAP method

Figure 2.8: EAP method internals

The Session-Id uniquely identifies an EAP session between a peer and an EAP server,and can be used, for instance, to identify a set of keys. It can be obtained by concatenatingPeer-Id and Server-Id. The core EAP protocol has no mechanism for lifetime negotiationfor exported keys. However, it is possible for an EAP method to adjust the lifetime, bymeans of the Key-Lifetime parameter.

Finally, an EAP method may export Channel Bindings. The goal of Channel Bindingsis to specify parameters that can be verified for consistency between peer and EAP server.Channel Bindings are created by both peer and EAP server and then transmitted to thecommunication partner, who verifies them. Typically, the peer’s capabilities are limited totheir verification on equality. The result of the verification is accessible by an EAP method.

2.8 EAP encapsulation

As outlined in Section 2.5, EAP has a very simple packet format comprising only a fewbyte. Since an EAP packet lacks of a sender and receiver address field, it is not routeable.EAP depends on a transport protocol which provides these capabilities. This protocol canbe a Layer 2 protocol, but can also be a higher layer protocol like TLS, RADIUS or IKEv2.

This subsection will look closer at a very popular application for EAP, namely its adop-

2.8 EAP encapsulation 21

tion in the context of IEEE 802.11 network access authentication. 802.11’s revised securityarchitecture IEEE 802.11i [81] adopts the IEEE 802.1X [74] framework for authenticationand key management, which in turn strongly relies on EAP. While Section 4.1.3 focuses onthis application, this section wants to look closer at the encapsulation mechanisms.

client station

EAP over

access point

Supplicant

EAP over

backend AAA server

AuthenticationAuthenticator/NAS Server

802.1X RADIUS ��

��

Figure 2.9: Transport of EAP in 802.11i network authentication

Figure 2.9 points out that between Supplicant and Authenticator, which are most likelynotebook and access point, EAP is encapsulated in IEEE 802.1X frames and that betweenAuthenticator and Authentication server, EAP is encapsulated in an AAA protocol likeRADIUS.

2.8.1 EAP encapsulation in 802.11

As previously mentioned, 802.11 chooses the 802.1X framework to perform network accessauthentication and key distribution. EAP is carried within EAPOL frames (EAP over LAN).Figure 2.10 depicts the EAPOL MPDU format for 802.3/Ethernet, which is adopted by802.11.

TypeProtocolVersion

PacketType

PAE EthernetBody LengthPacket Packet

Body

1 byte 1 byte 2 byte variable2 byte

Figure 2.10: EAPOL frame format

PAE Ethernet Type This field is constantly 0x888E, the identifier for the Port Access En-tity Ethernet Type.

Protocol Version If the EAPOL packet is conform to 802.1X-2004 [74], this field’s valueis ”2”, otherwise ”1”.


Packet Type The Standard defines five packet types.

0 EAP-Packet1 EAPOL-Start2 EAPOL-Logoff3 EAPOL-Key4 EAPOL-Encapsulated-ASF-Alert

An EAPOL-Start is sent by the Supplicant to the Authenticator to initiate an 802.1Xconversation. The Supplicant sends an EAPOL-Logoff frame to the Authentica-tor to indicate the termination of an established 802.1X-authenticated session. TheEAPOL-Key packet type is used to transmit key information between Supplicant andAuthenticator.

EAPOL-Encapsulated-ASF-Alert packets can carry alerts (e.g. SNMP traps). Thesepackets are routed over the Uncontrolled Port and must therefore be treated with cau-tion. Indeed, most 802.1X implementations do not support this packet type, becausethere is no reason for an unauthenticated, unauthorized Supplicant to send any errormessages to the network. Of particular interest for our analysis is the packet type 0encapsulating an EAP packet.

Packet Body Length This field contains the length of the Packet Body field in byte. If theEAPOL frame does not have a Packet Body, this field is assigned the value ”0”.

Packet Body The Packet Body field is present if the Packet Type is one of EAP-Packet,EAPOL-Key or EAPOL-Encapsulated-ASF Alert. Consequently, EAPOL-Start andEAPOL-Logoff frames do not have a Packet Body.

If the Packet Type indicates an EAP-Packet, then the Packet Body will encapsulate exactlyone EAP packet. Figure 2.11 shows the big picture on EAP encapsulation in 802.11 Wire-less LAN.

2.8.2 EAP encapsulation in RADIUS

The Remote Authentication Dial In User Service (RADIUS) is an authentication, authoriza-tion and accounting protocol used to control network access. RADIUS authentication andauthorization is specified in RFC 2865 [131] and RADIUS accounting is specified in RFC2866 [132]. RADIUS extensions for support of EAP are described in RFC 3579 [8], whichwas published in September 2003 and which obsoletes RFC 2869 [133].

RADIUS packets are transported in UDP datagrams, where one UDP datagram en-capsulates exactly one RADIUS packet. Authentication-related information are exchangedover port 1812, accounting-related information over port 1813.

RADIUS client (running on the NAS) and RADIUS server have established a trust rela-tionship based on a shared secret. This shared secret may not be empty. [131] recommends


TypeProtocolVersion

PacketType

PAE EthernetBody LengthPacket Packet

Body

Duration/ID

FrameControl

Address 1 Address 2 Address 3 SequenceControl

Address 4 FrameBody

FCS

Code LengthIdentifier

2 byte1 byte1 byte

Data

L byte

6 byte2 byte2 byte 6 byte 6 byte 2 byte 6 byte 4 byte

1 byte2 byte 4+L byte2 byte1 byte

Figure 2.11: EAP encapsulation in 802.1X / 802.11

that it should be at least 16 byte long and be a well-chosen password in order to providesufficient protection against exhaustive search attacks.

As can be seen in Figure 2.8.2, the RADIUS packet has a very simple construction,which is by the way very similar to the packet format of EAP.

Code The Code field is one byte and identifies the type of the RADIUS packet. In thescope of EAP encapsulation, the following packet types are found.

Code Type Message direction

1 Access-Request Authenticator→ RADIUS server2 Access-Accept RADIUS server→ Authenticator3 Access-Reject RADIUS server→ Authenticator11 Access-Challenge RADIUS server→ Authenticator

Identifier The Identifier field is one byte and aids in matching Requests and Challenges.Furthermore, it can be used for duplicate detection, namely if the RADIUS serverreceives an Access-Request which has the same client source IP address, source UDPport and Identifier within a short span of time.

Length The Length field is two byte and contains the total size of the RADIUS packet inunit byte.


Code LengthIdentifier

2 byte1 byte1 byte 16 byte

AttributesAuthenticator

Type ValueLength

1 byte 1 byte 0..253 byte

79: EAP−Packet80: Authenticator

Figure 2.12: EAP encapsulation in RADIUS

Authenticator The Authenticator field is 16 byte in length and is used to authenticate theRADIUS packet. In Access-Request packets, the Authenticator value is a 16-byterandom number, called the ”Request Authenticator”, which should be unpredictableand unique over the lifetime of the secret shared between the NAS and the RADIUSserver. This attribute must be used with much caution, otherwise RADIUS becomessusceptible for various attacks (see e.g. [131], Section 3).

In Access-Challenge, Access-Accept and Access-Reject packets, the Authenticatorvalue is called the ”Response Authenticator”, and contains a MD5 hash calculatedover the RADIUS packet, i.e. Code, Identifier, Length, the Request Authenticatorfield from the Access-Request packet, and the attributes followed by the shared se-cret. It is computed as follows

Response-Authenticator = MD5 ( Code || Identifier || Length ||Request Authenticator || attributes || shared secret)

Attributes The Attribute field encapsulates RADIUS attributes, which are 3-tupel Type-Length-Value fields. The size of an RADIUS attribute is limited to 255 byte. Thenumber of Attributes is not restricted.

RFC 3579 specifies two RADIUS attributes in order to support EAP, namely EAP-Message(attribute type 79) and Message-Authenticator (attribute type 80).


EAP-Message (Attribute-Type 79)

This attribute encapsulates EAP packets. If an Authenticator has received an EAP messagefrom a peer, he encapsulates this message within one or more EAP message attributes andforwards them in an Access-Request message to the RADIUS server.

In all four RADIUS message types, EAP-Message attributes may occur. However,Access-Requests are sent in direction from the Authenticator to the RADIUS server, i.e.therein placed EAP-Message attributes will encapsulate only EAP-Response messages. Incontrast, RADIUS packets of type Access-Challenge, Access-Accept and Access-Rejectare sent only in direction from the RADIUS server to the Authenticator, so that they willencapsulate EAP-Request, EAP-Success and EAP-Failure messages.

RADIUS packets may contain multiple EAP-Message attributes. Where more than oneEAP-message attribute is included, the implemention will silently assume that the concate-nation of the attribute’s value fields form a single EAP message. However, only one EAPmessage may be encapsulated per one RADIUS packet, not multiple.

Message-Authenticator (Attribute-Type 80)

RADIUS provides per-packet authentication and integrity protection to prevent attackersfrom modifying EAP-Message attributes. The Message-Authenticator attribute is specifiedfor this purpose. That is, every Access-Request, Access-Challenge, Access-Accept, andAccess-Reject packet which contains one (or more) EAP-Message attribute(s) must alsoinclude a Message-Authenticator attribute. If this attribute is not present, the packet will bediscarded.

A RADIUS server which receives an Access-Request with a Message-Authenticatorattribute present (or a NAS which receives an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator attribute present) must first verify the value priorto any further processing. If the calculated value does not match the value sent, the packetwill be discarded.

The Message-Authenticator attribute has the Attribute-Type ”80”, the constant length”18” and carries as value an HMAC-MD5 over the entire RADIUS packet, i.e. Type, ID,Length, Authenticator and all present attributes, keyed with the shared secret. In Access-Request packets, the Value field contains (next to other attributes)

Message-Authenticator = HMAC-MD5 (shared secret; Code || Identifier || Length ||Request Authenticator || attributes)

In Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticatorattribute is calculated using the Request-Authenticator from the Access-Request the packetis in reply to. For these packets, the Message-Authenticator is calculated and inserted in thepacket before the Response Authenticator is calculated.

Figure 2.13 shows a sample Access-Request with an Access-Challenge in reply. Whilethe peer’s EAP-Response fits in a single EAP-Message attribute, the server’s EAP-Requestmust be distributed over two such attributes.


Type ValueLength Type ValueLength

Type ValueLength Type ValueLength Type ValueLength

RADIUS Serversent from NAS to

Attributes

"79"

Code Identifier Length Type Payload

1 (Access−Request)

¨80" "16" HMAC−MD5 (Code || Identifier || Length || Request−Authenticator || Attributes)

e.g. "17"(EAP−TLS)Payload < 253 Byte

Code LengthIdentifier (Request−)Authenticator

16−byte randomnumber

"2" (EAP−Response)

Attributes

"79"

Code Identifier Length Type Payload

11 (Access−Challenge)

returned from RADIUS Serverto NAS (=RADIUS Client)

"79"

e.g. "17"(EAP−TLS)"1" (EAP−Request) payload > 253 byte, less than 506 byte

"80"

HMAC−MD5 (Code || Identifier || Length || Request−Authenticator ||Attributes )

Code LengthIdentifier (Response−)Authenticator

MD5 hash overpacket, Request Authenticatorand shared secret

Figure 2.13: RADIUS Access-Request and Access-Challenge encapsulating EAP

Some remarks on the security

Next to the general shortcomings of the RADIUS protocol (summarized for instance in[53] Section 1), numerous new attacks are introduced through the encapsulation of EAP inRADIUS. The security considerations of [8] outline the threat model and then identify anddiscuss the known attacks.


The security of RADIUS depends on the secrecy of the shared secret. If the sharedsecret is exposed to an attacker, he obtains full control over the RADIUS conversation.

From a cryptographic point of view, there are other shortcomings too. For instance,RADIUS provides no mechanism for negotiation of authenticator algorithms. Even if such amechanism would exist, the fixed 16-byte length of the authenticator field limits the numberof alternatives. Per definition, the Response-Authenticator field contains a MD5 hash overthe RADIUS packet and the random number of the Access-Request. Unfortunately, thesecurity of the MD5 hash function is thoroughly broken [155, 156, 157].

Also the Message-Authenticator attribute makes use of MD5 - fortunately used in theHMAC construction. Unless not more sophisticated attacks are found, the HMAC construc-tion remains secure even if the underlying hash function suffers from found collisions. Forsome background, [47] is a recommended reading. [11] points out that eliminating MD5from the Authenticator field would require a major protocol change (like a version number)or manual configuration, which becomes impractible in larger networks.

Due to the lack of of per-packet confidentiality, RFC 3579 suggests the usage of RA-DIUS over IPSec ([8], Section 4.2). With aid of IPsec ESP [92] with a non-null encryptiontransform and authentication support, RADIUS would provide per-packet confidentiality,authentication, integrity and replay protection. RADIUS over IPsec addresses known RA-DIUS security vulnerabilities ([8], Section 4.3), for example, it protects against both MD5collisions and dictionary attacks on MD5 and HMAC-MD5. For key mangement purposes,the Internet Key Exchange protocol [70, 71, 72] is recommended. At present, a proprietarymechanism called RadSec5 specifies how to carry RADIUS over TLS.

5Open Systems. RadSec - a secure, reliable RADIUS Protocol. http://www.open.com.au/radiator/radsec-whitepaper.pdf


2.8.3 EAP message flow in the IEEE 802.11i application

Now that all contributing components are surveyed, the message flow of an EAP authen-tication conversation during the 802.11i network attachment procedure can be presented.Figure 2.14 depicts this message flow.

Authenticator EAP peer

EAP−Response/Identity

EAP−Request/Identity

EAP−Response / EAP−X (...)

EAP−Success

explicit termination of session

EAP server

in case of successfulauthentication

(PMK)

(5)

(4)

(1)

(2)

(3)

(6)

(7) (8)

(9)

(10)

(11)

EAP−Request / EAP−X (...)

RADIUS Access−Request / Identity

RADIUS Access−Challenge (EAP−X (...))

RADIUS Access−Request (EAP−X (...))

RADIUS Access−Accept

802.1X port unblocked

EAPOL−Logoff

EAPOL−Start

Figure 2.14: EAP in the 802.11i network attachment procedure

1. By broadcasting an EAPOL-Start frame6, the peer indicates to perform an EAP-basedauthentication.

2. If the Authenticator accepts this request, he sends an EAP-Request message, whichcan be of EAP-Type 1 (Identity) or already be the first message of the selected EAPmethod, of EAP-Type 4 or higher. Here, we assume that an EAP-Identity exchangetakes place.

3. The peer replies in (3) with an EAP-Response with the same EAP-Type of (2). Inthe general scenario, the Authenticator decides whether it wants to perform a local

6This frame is sent to a broadcast address reserved for Authenticators, called ”PAE group address”. Itis 01:80:C2:00:00:03. As a consequence, all available and willing Authenticators within the RF range willrespond.

2.9 Security considerations 29

authentication or whether it wants to act as pass-through device. In this scenario, theAuthenticator acts as pass-through, which means, that all EAP messages are simplyforwarded between peer and EAP server. The EAP-Response/Identity is encapsu-lated in an EAP-Message attribute, which is transmitted as payload of an RADIUSAccess-Request packet.

The content of the EAP-Response/Identity data field is copied into an User-Nameattribute. In all subsequent Access-Request packets, this User-Name attribute mustbe taken along. [131] Section 5.6 suggests that Access-Requests use the value of theCalling-Station-Id as the value of the User-Name attribute.

4. The Authentication server selects an appropriate EAP method, builds the correspond-ing EAP-Request message and encapsulates it in one or more EAP-Message at-tributes. These attributes are enclosed in an Access-Challenge packet.

5. Having received the Access-Challenge packet, the Authenticator verifies first the hashin ’Authenticator’ attribute. If this was successful, the EAP-Message attribute(s) aredecapsulated and reassembled to a single EAP packet. This EAP packet is then en-capsulated in 802.1X EAPOL packet of type 0 and transmitted to the peer.

6. The peer generates an EAP-Response packet according to the negotiated EAP-Type,and sends the packet to the Authenticator, which encapsulates the EAP packet inRADIUS attributes. The attributes are enclosed in an Access-Request message andsent to the Authentication Server. If the peer does not acknowledge the proposed EAPtype, he can alternatively send an EAP-Nak.

7. This conversation continues until either a RADIUS Access-Reject or Access-Acceptpacket is received from the RADIUS server. In case of an Access-Reject packet, theAuthenticator denies access to the authenticating peer. In case of an Access-Acceptpacket, the peer has authenticated successfully.

8. The authentication concludes with the delivery of the AAA-Key to the Authenticator,which is securely transmitted within EAPOL-Key frames.

2.9 Security considerations

Section 7 of RFC 3748 focuses on the security of both EAP and EAP methods. It specifiesa generic threat model and corresponding security claims to facilitate the definition of EAPmethod requirements for specific environments or applications. At present, only a singleof such a requirement catalogue exists, namely RFC 4017, in which IEEE has compiledrequirements for EAP methods intended for use in 802.11 Wireless LANs.


2.9.1 EAP threat model

A threat model can be considered as foundation for designing an authentication protocol.The threat model of EAP assumes an attacker which has access to the link over which EAPpackets are transmitted ([5], Section 7.1). In other words, the adversary is put in controlof all communications. In this sense, EAP’s threat model ressembles the Dolev-Yao model[44]. This model makes two independent assumptions. First, the adversary can interceptand modify all messages exchanged in a protocol run, and can itself start protocol runs.Second, it is assumed that cryptographic algorithms have no special properties, which couldbe exploited as back-door. For instance, decryption can only be accomplished by applyingthe correct key. These assumptions correspond to those made by EAP.

In the 1998’ EAP specification, RFC 2284, threat model and security considerationswere missing. At that time, EAP was applied only as enhanced PPP authentication mecha-nism, and PPP was assumed to run over wired networks or over leased lines. Today, EAP istransmitted over links which are not difficult to access by an attacker, so that the assumptionof an attacker having full control over the communication channel seems to be reasonable.

Most of currently known attacks on networks, network protocols and cryptographic pro-tocols can also be applied to EAP, its authentication mechanisms and the communicationchannel over which the packets are transmitted. As stated above, the adversary model as-sumes an attacker who has the possibility for interception, fabrication, modification andinterruption of EAP packets7. Consequently, numerous passive or active attacks result.

Passive attacks comprise eavesdropping and analysis of all exchanged data traffic. Thethreat model points out that eavesdropping can be used to reveal the user’s identity or toreveal authentication credentials. Particularly if the EAP method relies on a pre-sharedkey which has not full entropy (e.g. a password or a value derived from a password),dictionary attacks or brute-force attacks exhausting the search space seems to be promisingto an attacker.

Active attacks have numerous intentions. EAP itself is susceptible for miscellaneousactive attacks, for instance Denial-of-Service (DoS) attacks, replay attacks or Man-in-the-Middle attacks.

EAP packets that indicate the result of the conversation, i.e. EAP-Success and EAP-Failure, are not cryptographically protected. So, an attacker could easily spoof these pack-ets. If they are received within an EAP authentication procedure, i.e. premature, the EAPstate machine mandates to terminate the EAP conversation.

Further DoS attacks are flooding the EAP peer with EAP-Request/Identity messages, orrefusing the EAP method proposed by the EAP server by sending EAP-Nak responses in thehope that the server selects a weaker EAP method. If EAP is used in 802.11 Wireless LAN,further DoS attacks are possible. For instance, flooding the access point with EAPOL-Startpackets targeting the availability of the network access, or issuing forged EAPOL-Logoffpackets to prevent wireless clients to complete an EAP authentication procedure.

7In this sense, this adversary model is rather conservative because it does not address an attacker who hasthe capability to compromise the peer’s machine or the EAP server. In this case, all stored credentials forauthentication would be accessible by the attacker.


A possible Man-in-the-Middle attack can be guessed that the attacker acts as Authen-ticator and let EAP peers connect to him. Then, he relays all traffic between peer andlegitimate Authenticator with the intention to analyze the forwarded EAP traffic and to ap-ply techniques to reveal the user credentials. Tunneled EAP methods, for instance, havebeen a long time vulnerable to this type of attack (see [19]).

The next category of active attacks attempts to exploit shortcomings or weaknesses ofspecific EAP methods, for example weak key derivation techniques used within an EAPmethod, or more general downgrading attacks for those EAP methods that perform somekind of ciphersuite negotiation. Replay attacks are also very popular, where the replay cancomprise a whole EAP conversation or single packets of such a conversation. Replay attackscan be successfully averted by adding freshness to the EAP method, for instance through anonce exchange, or through use of sequence counters or timestamps.

An EAP method which wants to be compliant to RFC 3748 must describe its securityproperties. These properties comprise the following terms: Mutual authentication, integrityprotection, replay protection, confidentiality, key derivation, dictionary attack resistance,fast reconnect, and cryptographic binding.

However, this list is not exhaustive. If the method has other properties like active useridentity confidentiality or denial-of-service resistance, these claims can be mentioned aswell. Even if the claims does not need to be supported mandatorily, it is at least highlyrecommended that they are taken into account while designing the protocol. For instance, anewly proposed EAP method that does not perform mutual authentication or that is highlyvulnerable to dictionary attacks, will with high certainty not attract much attention.

To summarize, an EAP method must

1. explain which security claims are made, but must also expose those security claimswhich are not addressed, so that potential vulnerabilities can be pointed out,

2. estimate its key strength and

3. describe its key hierarchy.

The next two subsections will survey the security claims and some background informationon estimating the key strength of an EAP method. Describing the key hierarchy is quitestraightforward, in that the path from the long-term credential through all internal sessionkeys to the exported keying material is outlined - this is not further considered here.

If an EAP method complies with the requirements of RFC 3748, the author(s) can askthe EAP Working Group (or its successor, the EMU Working Group) for an expert review,whose intention is to obtain an EAP type code. A designated expert will be elected, whowill thoroughly analyze the EAP method and verify its compliance. A catalogue8 may helpwith this. If all issues are solved, IANA may allocate an EAP type code for that method.By this procedure, one assures that the very limited EAP type space of 1 byte is not floodedwith new proposals, but only with well-analyzed methods.

8http://www.drizzle.com/~aboba/EAP/template.txt


2.9.2 EAP method security claims

(C1) Mutual authentication An EAP method should perform mutual authentication be-tween EAP peer and EAP server. Mutual authentication cannot be realized by twoindependent unilateral authentications9, but only through an interlocked authentica-tion exchange. The reason ist that two unilateral authentications remain simply uni-lateral authentications, because they do not defeat Man-in-the-Middle attacks. Thiscan only be avoided by relating the second authentication to the first one with aid ofcryptographic techniques.This claim is a lesson-learned not only from legacy EAP methods like EAP-MD5or early-stage EAP-TTLS and PEAP, but also from the GSM cellular network au-thentication protocol, where the mobile device does not authenticate the network it istalking to. This lack of network-to-user authentication enables for successful Man-in-the-Middle attacks. The client is convinced talking to the legitimate base stationwhen it has proven knowledge of the GSM triplet. Unfortunately, it is not too difficultfor a third party to intercept GSM triplets and to impersonate a legitimate base station(”IMSI catcher”).

(C2) Integrity protection If integrity protection is a concern, the EAP method must spec-ify its own mechanisms to provide per-packet data origin authentication and integrityprotection. Even if this protection does not prevent modification of EAP packets, itallows at least to identify modified packets. One possiblity to protect EAP packetsagainst modification, and also against spoofing or replay, is to append a MessageIntegrity Check (MIC) at the end of the packet. The MIC could best be realizedas Message Authentication Code (MAC) over the whole EAP packet including itsheader. The receiver then verifies the ICV before it processes the packet’s payload.At present, EAP-AKA, EAP-SAKE and EAP-PAX provides such an explicit integrityprotection.An alternative to per-packet ICVs is to compute a MAC over the whole EAP conver-sation and to exchange this MAC during the last exchange. The TLS protocol adoptsthis strategy, and therefore also EAP-TLS and all of its derivatives, namely EAP-TTLS, PEAP, EAP-FAST and EAP-Double-TLS. At the end of the TLS handshake,client and server compute a MAC over all previously exchanged handshake messages.This MAC is encapsulated and exchanged within the TLS Finished messages. If theMIC validation fails, the EAP conversation should be terminated.

(C3) Replay protection An EAP method should take care of adequate countermeasuresagainst replay of a whole session or of single packets. Replay attacks can be mit-igated by adding some kind of freshness to each session. This can be obtained byincorporating nonces, timestamps or sequence counters. Except for EAP-AKA (dueto its relationship to the UMTS AKA protocol), all other current EAP methods per-

9This naive perception is found e.g. in CHAP, RFC 1994 how to obtain mutual authentication: “Althoughthe authentication is only one-way, by negotiating CHAP in both directions the same secret set may easily beused for mutual authentication.”


form a nonce exchange.

(C4) Confidentiality This claim is addressed by an EAP method when it encrypts all EAPpackets including EAP-Success and EAP-Failure.

(C5) Key derivation The ability to derive keying material and to export a MSK and anEMSK (see also Section 2.7). The MSK must be at least 64 byte long. It is used forfurther key derivation and may not be used within the EAP method e.g. for protectingthe EAP conversation or subsequent data exchanges. The specific use of the EMSK,which must also be at least 64 byte, is reserved. An EAP method that performs keyderivation must also provide mutual authentication (C1).

(C6) Dictionary attack resistance An EAP method can make this claim, if its authentica-tion relies on a password but is still resistant to dictionary attacks. The EAP specifica-tion explains “A method may be said to provide protection against dictionary attacksif, when it uses a password as shared secret, the method does not allow an offlineattack that has a work factor based in the number of passwords in an attacker’s dic-tionary” ([5], p.45).

For example, password-based EAP methods vulnerable to this attack are LEAP andEAP-MD5. Other very prominent representants for password-based authenticationprotocols are Kerberos and both MS-CHAP versions. These protocols could be tun-neled through a protected channel to mitigate dictionary attacks, but this would leadto significantly higher complexity and computational overhead.

Password-based authentication protocols that are not susceptible for dictionary at-tacks, are called “strong password protocols”. This resistance is obtained by sophis-ticated mathematical techniques. Examples for strong password protocols are SRP[165], EKE [24] and SPEKE [87, 88].

(C7) Fast reconnect Fast reconnect is the ability of an EAP method to re-use a previouslyestablished security association to create a new or refreshed security association moreefficiently or in a smaller number of roundtrips. This ability is especially helpful forprotocols which make use of expensive public key techniques, e.g. RSA private keyoperations (decryption, signature) or a Diffie-Hellman key exchange well-known forits modular exponentiations.

(C8) Cryptographic binding This claim can only be made by tunneled EAP method. Cryp-tographic binding is “a demonstration of the peer to the EAP server that a single entityhas acted as the EAP peer” for all authentication methods executed within a tunneledEAP method.

(C9) Session Independence An EAP method provides session independence, if neitherpassive attacks nor active attacks enable an attacker to compromise subsequent orprior MSKs or EMSKs.


(C10) Fragmentation If an EAP method generates EAP packets which exceed the mini-mum EAP MTU (maximum transfer unit) of 1020 byte, it must provide support forfragmentation and reassembly. Experience has shown that EAP methods which relyon symmetric key techniques do not reach this limit. In contrast, certificate-basedEAP methods are more likely concerned with fragmentation issues.

(C11) Channel binding An EAP method utilizes channel bindings, if it adopts integrity-protected channel properties into its protocol (see Section 2.7 for some informationon channel bindings).

2.9.3 Determining the key strength

The security of an EAP method is determined by the choice of its algorithms and the cho-sen key length. Furthermore, its security is limited to that of the underlying long-term-credential. RFC 3748 requires an EAP method deriving key material to estimate its effec-tive key strength, which is defined as follows: ”If the effective key strength is N bits, thebest currently known methods to recover the key (with non-negligible probability) require,on average, an effort comparable to 2N−1 operations of a typical block cipher” ([5], 7.2c).

The protocol specification must dwell on its effective key strength. This explanationshould also contain the parameters required to achieve N bits of entropy based on currentknowledge of the algorithms. The reason to ask for the ”effective” key strength is to deter-mine the effective entropy of the derived MSK and EMSK, which is by the way independentof their physical length. For example, if a 128-bit key is derived from a password, then itseffective entropy is much less than 128 bit, although its physical length is 128 bit.

Determining the effective key strength for an EAP method which makes use of symmet-ric key techniques only, is not difficult. In absense of short cut attacks, an N-bit symmetricscheme provides a key strength of N bit, because an attacker would have to exhaust the keyspace of 2N to find the correct key. Even if he finds the correct key after 2N

2 = 2N−1 (whichequals the definition of the beginning) runs on average, the complexity is though O(2N).Consequently, if an EAP method relies on a strong N-bit pre-shared key, and all algorithmsor computations maintain the N-bit entropy, then the overall (=effective) key strength is Nbit.

Determining the effective key strength for an EAP method which makes use of bothsymmetric and asymmetric techniques, is much more difficult. Imagine an EAP methodwhich relies on a N-bit pre-shared key, but wants to achieve additional protection for thederived session key by adding a Diffie-Hellman key exchange. If the Diffie-Hellman sharedsecret is used correctly, it adds perfect forward secrecy to the method. This means, thatdisclosure of the long-term pre-shared key does not lead to disclosure of the session keys- they remain secure. The question now arises which field size must be chosen to obtain acomparable key strength to the given N-bit symmetric key strength.

There is no exact answer to this, because different models have been proposed withdifferent resulting equivalent key sizes. The problem ist that the key strength of a publickey scheme is much more difficult to determine than that one of a symmetric key scheme.The basic assumption is to correlate the strength of a public key to the problem to solve the


integer factoring problem or the discrete logarithm problem. Over the last decades, manyeffective and efficient attacks have been discovered, all much better than brute force.

The difficulty of solving the discrete logarithm (DLOG) problem in prime order fieldsof size 2N is asymptotically equivalent to the difficulty of breaking N-bit RSA. Since bothkey sizes are equal, the key is commonly called ”RSA/DLOG”, where the value stands forthe length N=pq of the RSA modulus respective the size N of the field 2N.

In the following, the approach of the EU ECRYPT project [46]10 is briefly presented.The idea is to find a single pair of symmetric and asymmetric key sizes having equivalentstrength. In the next step, an extrapolation formula is determined to derive further equivalentkey sizes. ECRYPT develops an extrapolation formula which relies on the run-time formulaof the most efficient General Number Field Sieve (GNFS) algorithm. The run-time forfactorization of a number N is asymptotically given by

L(N) = A · e(C+O(1)) (lnN)1/3 (ln lnN)2/3

for a constant A, and C = (64/9)1/3. The O(1) term is set to zero. Based on heuristics, thestrength of a 512-bit RSA scheme is brought in correlation to a 4-6 bit decreased DES-56strength, which is finally set to the fixed value 50. That is, L(512)=50. The report concludeswith the extrapolation formula to determine the effective key-size of a n-bit RSA modulusN:

s(n) =(64

9

)1/3log2(e) (nln2)1/3 (ln(nln2))2/3 −14

Table 2.3 shows some results of this formula. Table 2.4 shows results of the extrapola-tion formula to find symmetric key counterparts to established asymmetric key length, nextto recommendations of NIST [119] and NESSIE [120].

RSA / DLOG key size 512 768 1024 1536 2048 3072 4096 8192symmetric key size (ECRYPT) 50 63 73 89 103 125 143 195

Table 2.3: Recommendations for key sizes with equivalent strength (I)

symmetric key size 56 64 80 112 128 160 192 256RSA/DLOG key size (NIST) - - 1024 2048 3072 - 7680 15360RSA/DLOG key size (NESSIE) 512 768 1536 4096 6000 10000 - -RSA/DLOG key size (ECRYPT) 640 816 1248 2432 3248 5312 7936 15424

Table 2.4: Recommendations for key sizes with equivalent strength (II)

10ECRYPT - European Network of Excellence for Cryptology is a 4-year network of excellence fundedwithin the Information Societies Technology (IST) Programme of the European Commission’s Sixth Frame-work Programme (FP6) under contract number IST-2002-507932. The official website is http://www.ecrypt.eu.org/.


However, the IETF has published its own recommendations in a separate document,RFC 3766 [124], published in April 2004. Since another cost model is used, slightly differ-ent values result, as can be seen in Figure 2.5.

Therefore, we claim that asymmetric and symmetric keys have ”equivalent strength”when the difficulty of factoring the modulus roughly equals the difficulty of a brute-forceattack on the symmetric key. Certainly, it is allowed to use key sizes different from therequirements, having in mind, that use of a larger key size than required has only impacton the performance without adding additional security, and vice versa, use of a smaller keysize will not provide enough security.11

symmetric key size 70 80 90 100 150 200 250RSA/DH modulus size 947 1228 1553 1926 4575 8719 14596

Table 2.5: IETF’s recommendations for key sizes with equivalent strength

Two examples will now map this theoretical work to the context of EAP methods.

• Given an EAP method which relies on a 128-bit pre-shared key, and which aims toperform a Diffie-Hellman key exchange. Accordingly, the method must choose aDiffie-Hellman group with about 3200-bit size to preserve the effective key strengthof 128-bit. It would be benefical to adopt the 3072-bit Diffie-Hellman group specifiedin [93]12. Note that the size of the Diffie-Hellman exponent must be chosen carefully.Its size is recommended to be double the entropy of the overall strength. This impliesfor this setting a 256-bit exponent.

• Given an EAP method which relies on a 128-bit pre-shared key and a 2048-bit RSAcertificate, then this EAP method does not provide 128-bit symmetric key strength,but (in absense of other degradations) an effective key strength of about 112 bit.

2.9.4 EAP method requirements for IEEE 802.11

RFC 4017, which was adopted in March 2005 as Informational RFC, specifies requirementsand recommendations for EAP methods used in IEEE 802.11 Wireless LANs. Rather thanselecting a specific EAP method for this purpose, IEEE restricts on specifying a few re-quirements. They are separated into mandatory, recommended and optional requirements.The references which are made to the security claims of RFC 3748 are omitted here.

Mandatory requirements: The EAP method must perform mutual authentication (C1)and generate keying material with an effective key strength of 128 bit, and it must

11Due to different cost models, the recommendations vary slightly. Only the NESSIE recommendation seemsto grow too fast, which is the consequence of an inaccurate extrapolation formula ([46], p.21).

12Suitable groups for 512, 760 and 1024 bit are found in IKEv2 [91], suitable groups for 1536, 2048, 3072,4096, 6144 and 8192 bit modulus length are found in [93].


export a MSK and an EMSK of at least 64 byte (C5). Regarding possible attacks, theEAP method must be resistant to dictionary attacks and Man-in-the-Middle attacks.If the EAP method negotiates a ciphersuite, this must be done securely.

Recommended requirements: If the EAP method is aware of payloads larger than theminimum EAP MTU (i.e. 1020 byte), it should include support for fragmentationand reassembly (C10). Also, it should provide end-user identity hiding (C1).

Optional requirements: This category comprises two properties, namely support for Chan-nel Binding (C11) and for Fast Reconnect (C7).

A method that does not support the mandatory requirements is thus not compliant withRFC 4017 and may consequently not be used in IEEE 802.11 Wireless LAN applications.As can be seen, IEEE does not take care about Denial-of-Service resistance and Active UserIdentity Protection.

Chapter 3

Analysis of EAP methods

The Extensible Authentication Protocol (EAP) is a network access authentication frame-work which is adopted by a variety of protocols and applications. EAP specifies only thepacket format, message exchange, and general requirements for compliant authenticationmechanisms. The actual authentication is accomplished by so called EAP methods. Morethan 40 EAP methods have been proposed so far, some have reached the state of an RFC,some are progressing as Internet-Draft, and others have been abandoned or are deprecatedfor security reasons. Another difference is that some methods have allocated an EAP typenumber, which is a prerequisite for being available in implementations, and others not.

Therefore, a reasonable subset must be found. The thesis has selected EAP-TLS, EAP-TTLS, EAP-FAST, EAP-PSK, EAP-PAX, EAP-IKEv2 and EAP-AKA. This set containsthe most promising candidates among the currently proposed EAP methods. They givea broad picture of the flexibility and diversity of EAP methods and cover a wide range ofclient authentication credentials, namely passwords, pre-shared keys, digital certificates andhardware token.

The roadmap for each analysis is as follows. The respective section begins with somehistoric remarks and with the presentation of the main design goals. It follows a surveyof the cryptographic components underlying the EAP method in a comprehensible butnonetheless precise manner. If it implements an existing security protocol, this protocolis described at first. This holds for TLS, IKEv2, and UMTS AKA. The goal is to pro-vide the reader with a strong background knowledge for a better understanding of the EAPmethod.

The key hierarchy and key derivation procedure will be particularly focused on. If theauthentication procedure was successful, an EAP method exports keying material accordingto Section 2.7 - it is worth to see the single steps of its derivation from the long-term creden-tial and session-specific parameters. Since more keying material is required than available(e.g. 16-byte fresh session key versus 128-byte export keys), a key derivation function mustbe employed to generate the required amount of random data.

Not only cryptographic algorithms can decrease the effective key strength of the method(as defined in Section 2.9.3), but also the internals of the key derivation function. This isthe rationale to break the KDF down into its details.

39

40 Analysis of EAP methods

The analysis of an EAP method concludes with some personal comments.In other words, the main focus will be on the cryptography used by the EAP method.

The analysis will not address all security claims of the catalogue and verify if they arefulfilled or not. The reason is as simple as convincing: All methods presented below complywith the core requirements of RFC 3748, regardless, whether the specification reflects thisor must be revised for this purpose (e.g. due to some minor deviations, like in case ofEAP-TLS and EAP-IKEv2). What can be stated is that each of the proposals has no seriousweaknesses or protocol flaws that prevent the compliance with EAP’s security requirements.

Section 3.8 finally surveys some of the not-analyzed EAP methods, namely EAP-MD5,LEAP, PEAP, EAP-SIM, EAP-Double-TLS, EAP-SAKE and EAP-POTP.

3.1 EAP-TLS

3.1.1 History

EAP-TLS is a development by Microsoft. It was first time published in October 1997 withthe intention to enhance PPP’s authentication capabilitites by digital certificates. In October1999, EAP-TLS was adopted as an Experimental RFC [6]. EAP-TLS is a mature, stableand widely deployed protocol. Currently, the EMU Working Group is occupied with therevision of the specification [138].

EAP-TLS relies on the Transport Layer Security Protocol (TLS v1.0 [42]), which it-self relies on the Secure Socket Layer protocol (SSL v3.0 [111]), originally proposed byNetscape Communications in 1993. Although the changes are not dramatic, they are signif-icant enough that both protocols do not interoperate. In April 2006, TLS v1.1 was published[43]. It is only a slightly revised TLS v1.0 protocol with some small security improvements,clarifications, and editorial improvements ([43], Section 1.1).

Since EAP-TLS is a straightforward adoption of the TLS Handshake protocol, the mainfocus is firstly on describing the TLS protocol. This facilitates the subsequent presentationof EAP-TLS considerably.

3.1.2 Transport Layer Security (TLS)

3.1.2.1 Protocol overview

The primary goal of TLS is to provide privacy and data integrity between two communi-cating parties. TLS specifies four protocols, referred to as Record protocol, Handshakeprotocol, ChangeCipherSpec protocol and Alert protocol.

The Record protocol encapsulates higher level protocols and takes care about the reli-ability, confidentiality, and compression of the messages exchanged over a previously es-tablished connection. This connection prevents eavesdropping, tampering of messages andforgery. The Handshake protocol allows to negotiate a set of cryptographic algorithms thatcan be combined arbitrarily to perform one-way or mutual authentication and to establish ashared session key. Such a set of algorithms is called a ”ciphersuite”.

3.1 EAP-TLS 41

A TLS ciphersuite consists of three algorithms, namely an algorithm for key exchangeand authentication, a symmetric algorithm for bulk encryption on TLS Record layer, and ahash function. Each ciphersuite is identified by a 2-byte hexadecimal code. For instance,the ciphersuite 0x000A stands for TLS_RSA_WITH_RC4_128_SHA, which means, that keyexchange and authentication are accomplished by RSA, bulk data encryption by the streamcipher RC4 operating on 128-bit blocks, and hashing by SHA-1.

TLS’ key exchange capabilities comprise RSA, DSA, ECC, Diffie-Hellman or pre-shared key based techniques. Encryption at Record layer is accomplished by stream ci-phers like RC4 or IDEA, or block ciphers like DES, 3DES-EDE or AES [36]. As hashfunctions, MD5 and SHA-1 are the most common ones. Due to recent research results indi-cating a reduced collision-resistance of MD5 and SHA-1 ([155, 156, 157]), newly proposedciphersuites tend to use other hash functions. SHA-256 is a very popular choice, also be-cause it is NIST’s recommendation. Another example is the powerful Counter-Mode, whichcombines elegantly encryption and authentication and which is therefore chosen by somerecently proposed ciphersuites [108].

Figure 3.1 depicts the full TLS handshake. Expressions enclosed in brackets stand foran optional message, and an expression followed by a star denotes a situation-dependentmessage, that is a message which occurs only in certain situations. With establishment of theshared session key, the ”master secret”, the Handshake protocol finishes. The Record layerderives from the master secret symmetric keying material for encryption and authentication,which allows peer and server to communicate securely. In the following, we suppose aciphersuite with RSA-based key exchange.

Client Server

(1) ClientHello -ServerHello

(2) Certificate*ServerKeyExchange*CertificateRequest*

¾ ServerHelloDone(3) Certificate*

ClientKeyExchangeCertificateVerify*[ChangeCipherSpec]Finished -

[ChangeCipherSpec](4) ¾ Finished

(5) Application Data -¾ Application Data

Figure 3.1: Full TLS handshake


1. The client sends a random number, the TLS version number, a set of supported ci-phersuites, and optionally a session identifier to the server (ClientHello).

2. The server chooses one of the offered ciphersuites and sends his choice together withanother random number, his TLS version number, and a session identifier to the client(ServerHello). The server first tries to find the client’s session identifier in his sessioncache. If an entry matches, this indicates that the client wants to resume the corre-sponding session. Otherwise, the server chooses a new session identifier, which isassumed here. The Certificate message encapsulates the server’s certificate. If it con-tains a DSS or RSA signature public key rather than a RSA or Diffie-Hellman keyexchange public key, the ServerKeyExchange message is required. The server in-cludes the CertificateRequest message, if he wants the client to authenticate himself,too.

3. The client verifies the certificate, that is, he verifies the signature on the server’s RSApublic key and generates 48-byte random data, the so-called ”pre-master secret”. Thepre-master secret is then encrypted under the server’s public key and returned to theserver (ClientKeyExchange). If the server has issued a CertificateRequest, the clientmust include Certificate and CertificateVerify messages. The latter message containsa signed authentication response.

4. The server decrypts the pre-master secret with his RSA private key and verifies theclient’s certificate and signature. Thereafter, client and server use the pre-master se-cret to derive the master secret. Together with the random numbers, the master secretgoes into the derivation of cipher keys, initialization vectors and MAC keys for bulkencryption and authentication on the TLS Record layer. With aid of ChangeCipher-Spec, both sides indicate that subsequent messages are protected by the keys derivedright before.

5. The Finished message is the first one protected by the session keys. It contains a MACover all handshake messages and guarantees for the integrity of the handshake. Afterthe Finished message exchange, client and server can exchange arbitrary informationthrough the established channel.

3.1.2.2 Session resuming

Next to the full TLS handshake, TLS allows for an abbreviated handshake to resume a pre-viously negotiated session. This mode is also referred to as ”fast session resumption” modeor ”fast reconnect” mode. Resuming means, that the pre-master secret of a previous TLSsession is re-used. Consequently, all parts of the handshake which belong to the deriva-tion of the pre-master secret can be omitted. The fast session resumption mode is veryefficient, because it avoids expensive public-key operations. In comparison to the full TLShandshake, also fewer and shorter messages are exchanged.

The session resumption works as follows. In the ClientHello message, the client in-cludes an identifier of a previous session. The server then looks in its session cache for a

3.1 EAP-TLS 43

Client Server

(1) ClientHello -ServerHello

(2) [ChangeCipherSpec]¾ Finished

(3) [ChangeCipherSpec]Finished -

(4) Application Data -¾ Application Data

Figure 3.2: Abbreviated TLS handshake

corresponding session. Assume that the server has found a corresponding entry1 and wantsto resume the session, then he includes this session identifier in the ServerHello message.Figure 3.2 illustrates the abbreviated TLS handshake.

After the Hello message exchange, the server sends immediately the ChangeCipherSpecand Finished messages. Client and server mutually authenticate by verifying the receivedFinished messages, which means after decrypting it and verifying the MAC.

3.1.2.3 Authentication and key exchange within TLS

As mentioned above, a TLS session is protected by algorithms of an initially negotiatedciphersuite. A ciphersuite consists of three algorithms, namely a key exchange algorithm,an encryption algorithm and a hash function. The TLS v1.0 specification introduces numer-ous ciphersuites, which are summarized on page 163. Table 3.1 depicts the key exchangealgorithms offered by TLS v1.0.

From a cryptographic point of view, these variants distinguish in the way the pre-mastersecret is generated. The initial exchange of random numbers and the generation of the mas-ter secret and key block remains the same. During the last years, interest in TLS has contin-uously increased, so that numerous ciphersuites with some new key exchange mechanismshave been added. They adopt, for instance, the Kerberos cryptosystem [104], pre-sharedkey based mechanisms [52] and Elliptic Curve Cryptography [26]. The most common case,however, is a ciphersuite which relies on RSA for both authentication and key exchange.

It might be of interest that TLS v1.0 defines a mandatory-to-implement ciphersuite,namely TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ([42], Section 9). The revised TLS v1.1specification has changed this to the much more common ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA. NIST argues in [112] to use RSA or DSA for authentication together with

1Typically, sessions are deleted from the session cache after expiration of a certain time. Many implemen-tations use 12 hours as default value.


Key exchange Authentication

DHE_DSS ephemeral DH DSS signaturesDHE_RSA ephemeral DH RSA signaturesDH_anon anonymous DH no signaturesDH_DSS Diffie-Hellman DSS signaturesDH_RSA Diffie-Hellman RSA signaturesRSA RSA key exchange RSA signatures

Table 3.1: Key exchange algorithms in TLS v1.0

an ephemeral Diffie-Hellman key agreement to obtain forward secrecy, and recommendsthe ciphersuites TLS_DHE_RSA_WITH_AES128_CBC_SHA and TLS_DHE_DSS_WITH_AES256_CBC_SHA.

RSA Key ExchangeIn case of RSA as key exchange algorithm, the client receives the server’s certificate,

extracts the server’s public key and verifies the validity of the signature. Then, he generatesa 48-byte pre-master secret, encrypts it with the server’s public key and sends the result backto the server, who in turn decrypts the payload to retrieve the pre-master secret. Thereafter,client and server can derive the master secret and the key block independently from eachother.

At this point, a closer look at the performance of the RSA and DSA public key opera-tions seems to be helpful to understand the upcoming alternatives to the RSA key exchangemechanism within TLS. Table 3.2 presents some performance results for public key op-erations, obtained with the OpenSSL benchmark ”openssl speed”. It determines both theelapsed time for a single operation and the total number of operations per second. Thetestbed consists of two machines, a slow and a fast machine. The slow machine is equippedwith a Mini-ITX board with a 600 MHz Via Samuel processor (Via Epia ME-6000). Thefast machine is a notebook equipped with an Intel Pentium M processor running at 1.7 GHz(Fujitsu-Siemens Amilo M-1425).

Table 3.2 points out that the RSA public key operation (encryption, signature verifica-tion) is comparatively cheap, while the RSA private key operation (decryption, signature)is highly expensive. Regardless whether slow or fast machine, the signature with 2048-bit keys consumes more than 97%, in case of 4096-bit even more than 98.5% of the totalrunning time for both signature and verification operation. Other public key systems likeEl-Gamal, DSA or ECC have far less asymmetry between these two operations. As Table3.2 reveals, the costs for DSA signature and verification are roughly the same.

The asymmetry of RSA operations results from the significant difference in the sizes ofthe chosen public and private RSA keys ([105], Section 8.2.3 and 11.3.3). The exponent ischosen accordingly so that encryption resp. signature verification can be done efficiently.The efficiency depends on the number of modular exponentiations. Preferred exponents

3.1 EAP-TLS 45

one operation operations / secslow machine sign verify sign verify

RSA 512 bit 0.009670 0.000901 103.4 1110.4RSA 1024 bit 0.056534 0.003012 17.7 332.1RSA 2048 bit 0.371111 0.010865 2.7 92.0RSA 4096 bit 2.610000 0.040040 0.4 25.0

DSA 512 bit 0.008654 0.010365 115.6 96.5DSA 1024 bit 0.029179 0.033857 34.3 29.5DSA 2048 bit 0.105684 0.126835 9.5 7.9

fast machine sign verify sign verify

RSA 512 bit 0.000795 0.000062 1258.6 16093.4RSA 1024 bit 0.003634 0.000169 275.2 5915.1RSA 2048 bit 0.020080 0.000525 49.8 1906.1RSA 4096 bit 0.124375 0.001776 8.0 563.0slow machineDSA 512 bit 0.000590 0.000698 1693.7 1432.0DSA 1024 bit 0.001623 0.001956 616.1 511.2DSA 2048 bit 0.005069 0.006260 197.3 159.7

Table 3.2: Performance of RSA and DSA operations

are the primes 3, 17 and 216 + 1. In its binary representation, 216 + 1 has only two 1s andrequires only 16 modular squarings and 1 modular exponentiation ([105], Section 11.23,Example (iv)).

Mapping these experimental results to the TLS handshake with an RSA-based key ex-change (e.g. TLS_RSA_WITH_AES_256_SHA) offers to some helpful insights. Recall thatTLS and EAP-TLS allow next to mutual authentication also unilateral authentication, inthat the server authenticates himself to the client only. In this mode, the performance bot-tleneck is not - as one might guess - on client-side, but on server-side. The client performstwo RSA public key operations, namely for signature verification of the server’s certificateand for encryption of the pre-master secret. The server performs one expensive RSA privatekey operation, namely for decrypting the pre-master secret.

In case of mutual authentication, the client performs two RSA public key operations,the same as with unilateral authentication, but additionally performs a RSA private keyoperation, needed for the signature in the CertificateVerify message, which is computedover the whole handshake up to that point,

CertificateVerify = Client.Sign ( MD5 (handshake messages) ||SHA-1 (handshake messages))

In addition to the RSA private key operation needed to decrypt the pre-master secret,


the server performs two RSA public key operations, namely to verify the client’s certificateand to verify the client’s signature in the CertificateVerify message. As a consequence, theRSA-based TLS handshake with mutual authentication (like in typical EAP-TLS applica-tion scenarios) leads to approximately the same computational costs on both sides, whilean RSA-based TLS handshake with unilateral authentication retains all expensive compu-tations from the client.

Pre-shared key based key exchangeIn December 2005, RFC 4279 was published [52]. It specifies pre-shared key based

TLS ciphersuites. The main goal is to avoid the need for expensive public key operations.Consequently, the ciphersuites seem to be attractive for constrainted devices, but also forthose environments, where the configuration of pre-shared keys is more convenient than theinstallation of digital certificates. If an infrastructure for provisioning already exists, it canbe borrowed to distribute the pre-shared key. Regarding the performance, [100] provides acomparative analysis of pre-shared key and certificate-based ciphersuites.

The RFC specifies three sets of ciphersuites, abbreviated with PSK, DHE_PSK andRSA_PSK. PSK ciphersuites perform mutual authentication based on a pre-shared key us-ing symmetric cryptography only. DHE_PSK ciphersuites use the pre-shared key to au-thenticate a Diffie-Hellman key exchange. And finally, RSA_PSK ciphersuites authenticatethe server by means of public key techniques and the client by means of symmetric keytechniques.

They distinguish in the way the pre-master secret is computed. Here, len(x) denotes afunction returning the length of x formatted as uint16 type.

PSK: pre-master secret = len(PSK) || (0x00) len(PSK) || len(PSK) || PSK

DHE_PSK: pre-master secret = len(gxy) || gxy || len(PSK) || PSK

RSA_PSK: pre-master secret = uint16(48) || 48 byte random data || len(PSK) || PSK

For DHE_PSK ciphersuites, the Diffie-Hellman parameters (generator g, modulus n,public keys gx mod n and gy mod n) are exchanged in the TLS ClientKeyExchange andServerKeyExchange handshake messages, respectively.

For RSA_PSK ciphersuites, the client generates 48 byte random data after he has re-ceived an verified the server’s certificate. This data is then sent encrypted with the server’spublic key to the server. Obviously, this corresponds to the derivation procedure of the pre-master secret during an RSA-based key exchange. However, the actual pre-master secret iscomputed as described before.

TLS has not been designed for pre-shared key extensions, and in fact, these extensionshave some limitations and bear some risks, as outlined in [52], Section 7. While PSK andRSA_PSK ciphersuites do not offer Perfect Forward Secrecy, DHE_PSK ciphersuites do so.However, this holds only if each handshake generates fresh Diffie-Hellman private keys anddoes not re-use previous ones. Another restriction is that the PSK identity is sent in plaintextand therefore is susceptible for eavesdropping. To prevent a brute-force or dictionary attack,the pre-shared key must have full entropy.

3.1 EAP-TLS 47

Password-based key exchangeSeveral suggestions have been made to extend TLS by strong password authentication

protocols. [142] proposes, for instance, a DH-EKE-based ciphersuite. DH-EKE (Diffie-Hellman Encrypted Key Exchange) relies on EKE, specified by Bellovin and Merritt in1992 [24]. The exchanged Diffie-Hellman parameters are encrypted with a weak secret P,like a password. Regardless the security strength of P, the Diffie-Hellman shared secretgxy is strong as long as both exchanged Diffie-Hellman parameters are strong. [142] alsodiscusses SRP- and SPEKE-based TLS extensions.

Another password-based technique for user authentication in TLS is described in [4].The SOKE (Simple Open Key Exchange) ciphersuites exchange unauthenticated Diffie-Hellman parameters, where the client’s Diffie-Hellman parameter is encrypted using a sim-ple mask generating function. The mask is a constant value raised to the power of a pass-word (more precisely, the hash of that password). The authors of [4] recognize three advan-tages of their proposal over other strong-password based TLS ciphersuites. First, a securityproof under the random oracle model exists. Second, SOKE is shown to be computation-ally efficient. Third, and for use in the context of EAP probably most important, the usersends his identity after the server has sent his identity and has authenticated himself to theclient. Active user identity confidentiality is a very desireable feature for EAP methods, andcurrently only addressed by EAP-IKEv2 [146].

Elliptic Curve Key exchangeAs stated above, the asymmetry of RSA operations has particularly impact on the

server’s performance. Even if client authentication is omitted, the server must decrypt thepre-master secret, which is very costly. One real world application, which suffers specif-ically from the delay caused by these computations, are web server, when TLS-securedHTTP connection is established with aid of a RSA-based ciphersuite. A very serious al-ternative to RSA is Elliptic Curve Cryptography (ECC). The theoretical background wasdeveloped in 1985 independently by Victor Miller and Neal Koblitz. ECC provides a simi-lar level of security compared to RSA but with significantly smaller key sizes. The differentkey sizes are contrasted in Figure 3.3.

symmetric 80 112 128 196 256ECC 163 233 283 409 571RSA/DSS/DH 1024 2048 3072 7680 15360

Figure 3.3: Key sizes for equivalent security levels (in bit) [113, 120]

Recently, ECC-based TLS ciphersuites have been published [26]. They specify the useof Elliptic Curve Diffie-Hellman (ECDH) key agreement in the TLS handshake and the useof Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mecha-nism. These ciphersuites are already available in the OpenSSL implementation. Regardingthe performance improvement of ECDSA over RSA, [61] provides a thorough analysis, il-lustrated with experimental results for a 450 MHz UltraSparc-II and a PDA equipped with


a 200 MHz StrongARM processor. While the verify operation takes for ECDSA slightlymore time than for RSA, the sign operation is much more efficient for ECDSA.

Mutual authentication

Having surveyed the most prominent key exchange mechanisms for TLS, we briefly investi-gate how authentication is accomplished. TLS provides three authentication modes, namelyauthentication of both parties, server authentication with an unauthenticated client, and totalanonymity. With regard to EAP-TLS and its most common configuration to perform mutualauthentication, the thesis focuses on this mode only.

The client authenticates to the server by means of the CertificateVerify message, whichcontains a signature over all handshake messages. The server authenticates to the client byverifying the Certificate Authorities’ signature on the server’s certificate. In the Finishedmessage exchange, client and server mutually prove possession of the session key.

The server sends to the client

Finished = PRF (master secret, ”server finished”,MD5(handshake messages) || SHA-1 (handshake messages)) [0..11]

The client sends to the server

Finished = PRF (master secret, ”client finished”,MD5(handshake messages) || SHA-1 (handshake messages)) [0..11]

In cryptographic terms, this exchange provides explicit key confirmation. In contrastto implicit key confirmation, both sides prove explicitely that they have knowledge of thesession key. This is actually a very desireable feature, even if it is not required by the EAPspecification. As can be seen in Section 2.9.4, the requirements for EAP methods intendedfor WLAN environments do not comprise this feature. That is, the EAP server typicallysends an EAP-Success message to the EAP peer without having an assurance that bothsides have derived the same MSK - this is addressed in some of the subsequent steps first.For instance, in the 802.11i authentication procedure, this confirmation occurs within the4-Way handshake.

3.1.2.4 Key derivation within TLS

If RSA is used for key exchange, the 48-byte pre-master secret is generated solely by theclient, where the first two byte are the TLS version number and the remaining 46 byte arerandom data. The pre-master secret is used along with the previously exchanged randomnumbers to generate the master secret. Authentication and encryption keys for the TLSRecord protocol are derived from the master secret and the random numbers of the Helloexchange. TLS specifies its own key derivation function, which is based on a pseudorandomfunction.

The pseudorandom function runs iteratively until the required amount of data is gener-ated. Its basic building block is P_hash, where ’hash’ is to replace with MD5 and SHA-1,respectively.

3.1 EAP-TLS 49

P_hash (secret, seed) = HMAC-hash (secret, A(1) || seed) ||HMAC-hash (secret, A(2) || seed) ||HMAC-hash (secret, A(3) || seed) || ...

whereA(0) = seedA(i) = HMAC-hash (secret, A(i-1)).

TLS splits the secret into two halves, denoted with S1 and S2, where the one half goesinto P_MD5 and the other half goes into P_SHA-1. The returned value of both functions isthen XORed.

PRF (secret, label, seed) = P_MD5 (S1, label || seed) XORP_SHA-1 (S2, label || seed)

Due to different output length of both sides, the boundaries are not aligned. There-fore both sides should be computed independently, and at the end, the two pseudorandomstreams are XORed and correctly truncated.

Figure 3.4 depicts the TLS keying hierarchy.

key block

mastersecret

client / serverMAC secret

client / servercipher key

client / serverIV

randomclient server

random

TLS−PRF

TLS−PRF

pre−master secret

Figure 3.4: TLS key hierarchy

Regardless of the particular key exchange mechanism, the algorithm for generating themaster secret and the key block remains the same. The master secret has always the length


of 48 byte, while the length of the pre-master secret depends on the chosen ciphersuite. ForRSA, the pre-master secret is 48 byte long.

master secret = PRF (pre-master secret, “master secret”,client random || server random) [0..47]

key block = PRF (master secret, "key expansion",server random || client random)

The key block is then used to derive six keys, namely client and server MAC secret inlength of the negotiated hash function, client and server encryption key, and an initializationvector for a block cipher.

3.1.3 EAP-TLS Protocol overview

The EAP-TLS specification comprises 24 pages only and is mainly concerned with tech-nical questions, for instance, how TLS is properly encapsulated into EAP packets, howfragmentation and reassembly are accomplished, or how EAP keying material is derived.Seven pages are dedicated for the example message flows only.

Regardless of TLS’ powerful capabilities, which were surveyed in the previous sec-tion, EAP-TLS supports only certificate-based authentication. To allow for TLS pre-sharedkey ciphersuites, a complementary EAP method called EAP-TLS-PSK is currently in work[128].

Like in case of TLS, authentication can be mutual or only one-way (server to client).The decision is within the scope of the EAP server. If message (5) contains a Certifi-cateRequest, the peer has received the signal for mutual authentication, so that he sendsCertificate and CertificateVerify messages in (6).

3.1.4 Cryptographic design

EAP-TLS relies on the cryptography of the TLS v1.0 protocol. Therefore, it suffices toshow how EAP-TLS derives the export keying material. MSK, EMSK and IV are derivedaccording to

MSK = PRF (master secret, "client EAP encryption",client random || server random) [0..63]

EMSK = PRF (master secret, "client EAP encryption",client random || server random) [64..127]

IV = PRF ("", "client EAP encryption",client random || server random) [0..63]

Note that the ordering of the random values is different from the original ordering inTLS.

3.1 EAP-TLS 51

(1) A← B : EAP-Request / Identity(2) A→ B : EAP-Response / Identity (id)

(3) A← B : EAP-Request / EAP-TLS (TLS Start)(4) A→ B : EAP-Response / EAP-TLS (TLS client_hello)

(5) A← B : EAP-Request / EAP-TLS(TLS server_hello,TLS certificate,[TLS server_key_exchange,][TLS certificate_request,]TLS server_hello_done)

(6) A→ B : EAP-Response / EAP-TLS(TLS certificate,TLS client_key_exchange,[TLS certificate_verify,]TLS change_cipher_spec,TLS finished)

(7) A← B : EAP-Request / EAP-TLS(TLS change_cipher_spec, TLS finished)

(8) A→ B : EAP-Response / EAP-TLS()

(9) A← B : EAP-Success

Figure 3.5: EAP-TLS message flow

3.1.5 Comments

For a long time, EAP-MD5 and EAP-TLS have been the only available EAP methods.While EAP-MD5 is deprecated for security reasons, EAP-TLS is widely deployed and pro-vides a well-understood and reliable mechanism to perform mutual authentication betweenEAP peer and EAP server. Due to the fact that it is proposed for more than five years,almost all 802.1X and RADIUS server implementations provide support for EAP-TLS. Inaddition, the Wi-Fi Alliance has added EAP-TLS to the set of ”Wi-Fi certified products”2, which provides some guarantee for interworking among Wi-Fi certified implementationsand hardware. The recently founded EMU Working Group is chartered with a revision ofthe current EAP-TLS specification - this indicates an enduring interest in EAP-TLS.

2Further Wi-Fi certified methods are EAP-TTLS w/MSCHAPv2, PEAPv0 w/EAP-MSCHAPv2, PEAPv1w/EAP-GTC as well as EAP-SIM. (source: http://certifications.wi-fi.org/wbcs_certified_products.php)


However, a recent IETF presentation3 estimates that only about 10% of all EAP de-ployments use EAP-TLS. The main reason for this is certainly the administrative burden ofprovisioning clients with certificates. Establishment and maintainance of a public key in-frastructure (PKI) is a fairly complex task and bears numerous risks. [48] surveys the mostprevalent issues regarding PKIs.

Due to the fact that EAP-TLS authenticates by means of digital certificates, it auto-matically inherits all certificate-related problems. Some selected problems in this contextare

Unencrypted certificate: Certificates are sent unencrypted. Since a digital certificate con-tains numerous information about the user (name, country, company, and so on)the EAP-TLS conversation is susceptible for eavesdropping and certificate analysis.Therefore, if privacy is a concern, another EAP method should be chosen instead.

Postponed verification: A typical application of EAP-TLS is to obtain network access.If the server presents the client a certificate signed by an unknown CA, the clientcannot verify the signature or follow the certificate chain. And even if the CA isknown, the peer cannot verify whether the EAP server’s certificate has been revokedin the meantime. The EAP-TLS authors are aware of this problem and recommendthat if the client is not capable of verifying the certificate, the verification should bepostponed ([6], Section 6.1).

Average User: The average user is typically not familar with the concept of digital certifi-cates. The authors of EAP-TTLS have described it as ”Users are ’notoriously bad’about following security guidelines. When presented with a dialogue saying ’thename in the certificate is different from the name you requested’, most users willsimply continue with the transaction.” ([55], Section 12). Another brilliant character-ization of this shortcoming is given in [31]:

"[...] Another notable use of cryptography is SSL, the Secure Socket Layer. While intheory quite general, in practice SSL is used almost exclusively for communicationbetween Web browsers and servers. Furthermore, in almost all cases authenticationis at best one-way - servers have certificates; clients rarely do - and in practice isunauthenticated, since most users of the technology neither know nor care what acertificate is, nor who has signed it. For that matter, the popular browsers give verylittle guidance on whether or not certificates should be accepted, what the meaningof the signing certificate is, etc. We thus have the dual of the situation with secureemail: the certificate authorities exist, and are used, but to little practical effect. [...]With SSL and secure email, the trust question is made more complex because the an-swer must relate to the real world. If I request a secure connection to www.wsj.com,my Web browser warns me that the certificate was issued to interactive.wsj.com.Should these two be considered identical? The company name is Dow Jones; is that

3http://www3.ietf.org/proceedings/05nov/slides/emu-0/emu-0.ppt

3.2 EAP-TTLS 53

right? How should I know that, a priori? And domain names are often confusing;nasa.com bears no relation to nasa.gov. Will a user notice the distinction?"

Storage of Certificate: The private key must be always accessible, but shall be kept secret.In contrast to a password, the private key is too long to be kept in memory, thus it mustbe stored persistently on the hard disk drive, a smartcard, an USB stick, or anothersuitable device. There are situations where this is difficult to accomplish.

Note that this list is not exhaustive. To summarize, if the related risks and problems arerecognized and understood, and the complexity of a PKI and the increased computationalcosts are not a concern, then EAP-TLS is well-suited for most applications and consequentlya highly recommended mechanism.

3.2 EAP-TTLS

3.2.1 History

EAP-TTLS stands for ”EAP Tunneled TLS” and is a proposal by Funk Software (now partof Juniper Networks) and Certicom Corporation. The first version appeared in August 2001,version 04 was published in April 2004. This version has obtained the EAP type code 21.In mid 2004, EAP-TTLS was divided into EAP-TTLSv0 and EAP-TTLSv1. EAP-TTLSv0expired in August 2005, while EAP-TTLSv1 was updated in March 2006.

In other words, EAP-TTLSv0 is the original EAP-TTLS, while EAP-TTLSv1 shouldbe treated as new protocol. It relies on a TLS extension called ”TLS Inner Application”(TLS/IA), which is specified in [56]. This presentation focuses on the original EAP-TTLS,which is available in most implementations and also very frequently used.

The main goal of EAP-TTLS is to extend EAP-TLS in that it does not stop after theTLS Handshake protocol but uses the TLS Record protocol to allow for secure exchangeof further information. In EAP-TLS, the client identity is sent in cleartext and thereforesusceptible for eavesdroppers. This shortcoming is addressed by EAP-TTLS in that it allowsfor postponed client authentication, which is protected by the key material derived duringthe TLS Handshake protocol.

EAP-TTLS requires the EAP server to authenticate himself by means of his certificate,while it offers three different modes for client authentication. First, the client can authenti-cate during the TLS handshake with aid of his certificate, which is very similar to EAP-TLS.Second, the client could authenticate twice, in the TLS handshake and inside the TLS tun-nel. Third, and this might be the most popular setting, the TLS handshake performs onlyserver authentication, while client authentication occurs first inside the tunnel. As inner au-thentication methods, EAP-TTLS allows next to EAP also legacy password authenticationprotocols like PAP, CHAP, MS-CHAP or MS-CHAPv2. Support of the latter protocols haseasy deployment against existing authentication databases and their authentication infras-tructure in mind.


3.2.2 Protocol overview

EAP-TTLS consists of two phases, the TLS handshake phase and the TLS tunnel phase.During the TLS handshake phase, the server authenticates himself to the client and, op-

tionally, the client authenticates himself to the server. At the end of this phase, client andserver have agreed on a secret key and have established a protected communication channel,that is, they are able to send data over the TLS Record layer which offers privacy, confiden-tiality and integrity protection. Alike EAP-TLS, the security depends on the negotiatedciphersuite - in case client and server have negotiated the null ciphersuite, subsequentlyexchanged communication is not protected.

During the TLS tunnel phase, client and server use the previously established chan-nel to exchange arbitrary information. Such an exchange chould be client authentication,negotiation or re-negotiation of security parameters, exchange of accounting-related infor-mations and key distribution for subsequent data connections. All data is encapsulated intoAttribute-Value-Pairs (AVPs). The AVP exchange continues until the EAP server decidesto send an EAP-Success or EAP-Failure.


(3) A← B : EAP-Request / EAP-TTLS (Start)(4) A→ B : EAP-Response / EAP-TTLS (ClientHello)

(5) A← B : EAP-Request / EAP-TTLS(ServerHello,Certificate,ServerKeyExchange,ServerHelloDone)

(6) A→ B : EAP-Response / EAP-TTLS(ClientKeyExchange, ChangeCipherSpec, Finished)

(7) A← B : EAP-Request / EAP-TTLS(ChangeCipherSpec, Finished)

(8) A→ B : EAP-Response / EAP-TTLS({User-Name}, {CHAP-Challenge}, {CHAP-Password})


Figure 3.6: EAP-TTLS with tunneled CHAP

EAP-TTLS also offers a fast session resumption mode, which is based on the TLS

3.2 EAP-TTLS 55

session resumption mode. If the EAP peer wants to resume a session, he sends as part of theClientHello message the session identifier of the session to be resumed. If the EAP serveraccepts the request, he sends the same session identifier as part of the ServerHello message.


EAP-TTLS relies on the cryptography of EAP-TLS, so that this section can be kept short.Client and server generate the required keying material via the TLS PRF as

keying material = PRF (master secret, "ttls keying material",client random || server random)

It may be assumed (although the EAP-TTLS specification [55] is not very precise inthis point) that the first 64 byte correspond to the MSK. Alike EAP-TLS, the ordering of therandom values is reversed and therefore deviates from the original TLS specification.4 EAP-TTLSv1 [55] is more precise in that it provides an explicit formula for the MSK derivation.

MSK = PRF (inner secret, "ttls v1 keying material",client random || server random) [0..63]

However, the specification does not tell how the EMSK is derived. Again, it must beassumed that the PRF is iterated twice as long and that the EMSK corresponds to the second64 byte.

If CHAP, MS-CHAP or MS-CHAPv2 are used inside the tunnel, it must be ensured thatthe client cannot control or predict the challenge. Therefore, client and EAP server generatethe challenge using the PRF, which is used iteratively to produce the required amount ofdata.

challenge = PRF (master secret, "ttls challenge",client random || server random) [0..X]

In case of CHAP as inner authentication method, the PRF has to generate 17 byte(X=16), where the first 16 byte are the CHAP-Challenge, and the last byte is the CHAP-Identifier. As shown in Figure 3.6, the client sends Username, CHAP-Challenge and CHAP-Password to the EAP server. The CHAP-Password attribute consists of the CHAP-Identifierand the CHAP-Response, which is computed according to the CHAP mechanism ([140]Section 4.2). Denote ’secret’ the user’s password, then the CHAP-Password attribute iscomputed as follows:

CHAP-Password = CHAP-Identifier || CHAP-Response= CHAP-Identifier || MD5 (CHAP-Identifier || secret || CHAP-Challenge)

In case of MS-CHAP and MS-CHAPv2 as inner authentication method, the PRF mustreturn 9 byte and 17 byte, respectively. For further information, please refer to [55], Section10.2.

4Although the rationale is not plausible: ”Altering the order of randoms avoids namespace collisions be-tween constant strings defined for EAP-TTLS and those defined for the TLS protocol."


3.2.4 Comments

EAP-TTLS takes advantage of the highly asymmetric computational costs of RSA publickey operations. If an RSA-based ciphersuite is negotiated, and the TLS Handshake phaseperforms only server-to-client authentication, then there are no computationally expensiveoperations on client-side. This makes EAP-TTLS well-suited for resource-constraintedclient devices. In addition, EAP-TTLS allows for a session resumption mode, which re-duces the latency even more.

Regarding the deployment status, EAP-TTLS is a very popular and widely deployedEAP method. Its main advantage is that it supports legacy password authentication proto-cols and therefore requires only minimal configuration efforts on client side. The companyof one of the authors, Funk Software (now part of Juniper Networks), offers software forclient and server side, called ”Odyssey Client” and ”Odyssey Server”. For Internet ServiceProviders or large companies, the product portfolio comprises a high-performance RADIUSimplementation called Steel-Belted Radius. Most of 802.1X supplicant and RADIUS serverimplementations support EAP-TTLS. All in all, EAP-TTLS can be seen as simple, easy-to-deploy and easy-to-understand network access authentication method with an attractivetradeoff between security and efficiency.

In the charter of the newly proposed EMU Working Group, which is concerned with thestandardization of EAP methods, the need for a password-based mechanism is outlined asfollows ”A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use ofexisting password databases such as AAA databases. The implementation should strive tobe usable in resource constrained environments.” ([49]). In July 2006, a design team forthis task will be founded. Without anticipating the WG’s decision, EAP-TTLS seems to bea good starting point for further exploration.

3.3 EAP-FAST

3.3.1 History

EAP-FAST is a proposal of Cisco Systems. In February 2004, the first version appeared, inOctober 2005, the current version 03 was published. IANA has allocated EAP type number45 for this mechanism. EAP-FAST was primarily developed as alternative authenticationmechanism to Cisco-EAP, also known as LEAP, which is based on passwords and whichwas pointed out to be vulnerable to dictionary attacks if the password is chosen poorly[164].

FAST stands for ”Flexible Authentication via Secure Tunneling”. Alike EAP-TTLS andPEAP, EAP-FAST adopts the TLS Handshake protocol to establish a mutually authenticatedprotected tunnel. In contrast to them, however, the tunnel can be established with eitherpublic key techniques similar to EAP-TLS, or with symmetric key techniques. Within thetunnel, one or more EAP methods can be executed, or an arbitrary exchange of informationcan take place.

As primary design goals of EAP-FAST, the specification mentions mutual authentica-tion, resistance to brute-force dictionary attacks, immunity to Man-in-the-middle attacks,

3.3 EAP-FAST 57

and large support for user databases (like Microsoft Active Directory, LDAP or OTP). Fur-thermore, by allowing for pre-shared key based authentication, EAP-FAST has particularlywireless networks and their mostly constrainted devices in mind.

EAP-FAST offers three possibilities how client and server can mutually authenticate.Firstly, EAP-FAST is able to perform certificate-based mutual authentication which is closelyrelated to EAP-TLS. Secondly, EAP-FAST allows that the server authenticates himselfcertificate-based, while the client authenticates himself within the established protected TLStunnel. Thirdly, the TLS handshake can fully established with symmetric key techniques.During this handshake, the server authenticates to the client based on a shared secret whilethe client authenticates through the secure tunnel. Consequently, EAP-FAST combines thefeatures of EAP-TLS and EAP-TTLS, and adopts the idea to use EAP-TLS with pre-sharedkey ciphersuites.

As secondary design criterias, EAP-FAST aims to provide flexibility for extensionsinside the tunnel, and to offer user-friendly authentication and easy deployment, which isachieved by a password-based authentication procedure to obtain a cryptographically strongpre-shared key (PAC), as well as pre-shared key-based authentication.


The pre-shared secret in EAP-FAST is referred to as PAC, which is short for ”ProtectedAccess Credential”’. The PAC can be provisioned automatically, with aid of in-band mech-anisms or manually with aid of out-of-band mechanisms. The IOS Software running inCisco wireless access points supports manual generation and distribution of the PAC. ThePAC would then be provisioned via the Trivial File Transfer Protocol (TFTP).

The PAC consists of two or three elements, namely the PAC-Key, the PAC-Opaque, andoptionally PAC-Info. Every pair of wireless client and EAP server requires an own PAC.The fields have the following meaning. The PAC-Key is the actual pre-shared key. ThePAC-Opaque field contains information which only the EAP server understands, thus takesthe role of a ticket. It is sent to the server to obtain network access. Finally, the PAC-Infofield is intended to carry information like the EAP server’s name.

Originally, EAP-FAST comprised three phases, namely phase 0 for provisioning of thePAC, and phase 1 and 2 for the actual TLS-based authentication. This has changed inthe meantime. In-band provisioning mechanisms are discussed in a separate Internet-Draft[35]. For simplicity, we assume henceforth that the client is in possession of a PAC thatcorresponds to the EAP server he is currently talking to.

Figure 3.7 depicts the EAP-FAST message flow.EAP-FAST phase 1 establishes with aid of the PAC a TLS tunnel between client and

server. The server sends his identity, referred to as Authority-ID. The client is thus able topick the correct PAC of all stored PACs, and returns the PAC-Opaque (not the PAC-Key) tothe server, which helps the server to validate the client’s identity and authenticity.

If the client has no corresponding PAC, then the server falls back to a full TLS hand-shake. In subsequence to this handshake, the client can issue a request to obtain a valid PAC.The server decrypts the PAC-Opaque and verifies its validity. If the PAC is not expired, the



(3) A← B : EAP-Request / EAP-FAST, V=1 (EAP-FAST Start, S bit set, A-ID)

(4) A→ B : EAP-Response / EAP-FAST, V=1(ClientHello [PAC-Opaque extension])

(5) A← B : EAP-Request / EAP-FAST, V=1(ServerHello, ChangeCipherSpec, Finished)

(6) A→ B : EAP-Response / EAP-FAST, V=1 (ChangeCipherSpec, Finished)

(7) A← B : EAP-Request / EAP-FAST, V=1(EAP Payload TLV (EAP-GTC Challenge))

(8) A→ B : EAP-Response / EAP-FAST, V=1(EAP Payload TLV (EAP-GTC Response (username,password)))

(9) A← B : EAP-Request / EAP-FAST, V=1(Intermediate-Result TLV (Success) Crypto-Binding TLV (Request))

(10) A→ B : EAP-Response / EAP-FAST, V=1(Intermediate-Result TLV (Success) Crypto-Binding TLV (Response))

(11) A← B : EAP-Request / EAP-FAST, V=1(Result TLV (Success) (Optional PAC TLV))

(12) A→ B : EAP-Response / EAP-FAST, V=1(Result TLV (Success) (PAC TLV Acknowledgement))


Figure 3.7: EAP-FAST message flow

server allows for an abbreviated TLS handshake, which relies on the TLS session resump-tion case (see Section 3.1.2.2). As a result, server and client have agreed on a particularPAC, whose PAC-Key is subsequently used to establish the TLS tunnel. EAP-FAST phase2 deals with exchanging information through this tunnel.

Having established the tunnel appropriately, user authentication credentials can be passedsecurely to the EAP server, for instance by EAP-GTC (as in Figure 3.7) or EAP-MSCHAPv2.In case of a successful client authentication, the EAP server sends a concluding EAP-

3.3 EAP-FAST 59

Success message. It is allowed to execute more than one EAP method within phase 2.In this case, the methods are executed serially. The specification gives the example to runEAP-TLS twice as inner method, initially with machine credentials followed by user cre-dentials.


3.3.3.1 The Protected Access Credential

The PAC is the central authentication credential of EAP-FAST and therefore plays a crucialrole within EAP-FAST. The specification calls it sometimes a ticket, and indeed it remindson the Kerberos ticket. In the world of Kerberos, a central server delivers a ticket to theclient, which has to present it whensoever it wants to gain network access. The Kerberosticket is also opaque to the client (in the sense, that the session key is encrypted).

Due to the importance of the PAC, its concept and construction will be revisited. ThePAC consists of a 32-byte PAC-Key, a PAC-Opaque and a PAC-Info, both in variable length.It is important to note that the server does not store PACs, but rather reveals all relevantinformation by interpretation of the PAC-Opaque field only.

The PAC-Key is randomly generated by the server, in order to ensure full entropy. InEAP-FAST phase 1, the TLS master secret must be derived.

The PAC-Opaque part can only be interpreted by the EAP server. It helps the serverto reveal and to verify the peer’s identity. Although the specifiation does not stipulate itscontent, it is suggested to incorporate the PAC-Key and the PAC’s peer identity. The specificcomposition is left to the PAC issuing server. In contrast to PAC-Opaque, which may bepublic, the PAC-Key must be kept secret.

3.3.3.2 Key derivation

The key derivation within EAP-FAST phase 1 is closely related to the TLS key derivationprocedure. If phase 1 is executed without the PAC, the master secret is generated as withinTLS (see Section 3.1.2.4) unless a PAC is used to establish the TLS tunnel. Then, it iscomputed as

master secret = T-PRF (PAC-Key, "PAC to master secret label hash",server random || client random) [0..47]

As mentioned before, the EAP server has determined the PAC-Key of the PAC-Opaque.The master secret and the initially exchanged random numbers are then used to derive fur-ther keying material. EAP-FAST requires the generation of additional 40 byte, the so called”session key seed”.

key block = TLS-PRF ( master secret, "key expansion”,server random || client random) [0..111]


Note that the ordering of the random values corresponds to the TLS ordering, that is,EAP-FAST does not reverse the order like EAP-TLS and EAP-TTLS do so. The size of”key block” is variable, because it depends on the previously negotiated ciphersuite. As-suming for illustrative purposes that the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA hasbeen negotiated, then T-PRF must generate 112 byte. Client and Server MAC secret haveeach 20 byte (due to SHA-1), client and server cipher key have each 16 byte (due to theblock size of 128 bit), plus 40 byte for session key seed, which is reserved for EAP-FASTphase 2. The EAP-FAST specification does not address derivation of initialization vectors.

T-PRF (key, label, seed, outputlength){

S = label + 0x00 + seed;n = doutputlength/20e;T0 = ””;for i=1 to n

Ti = HMAC−SHA1(key,Ti−1 ‖ S ‖ outputlength ‖ ”i”);

return T1 ‖ T2 ‖ · · · ‖ Tn;}

Figure 3.8: EAP-FAST key derivation function

The key derivation function of EAP-FAST, called T-PRF, is shown in Figure 3.8. Eachiteration yields 20 byte of keying material, thus the application must truncate the outputaccordingly. The 40 byte session key seed are required to combine keying material of bothEAP-FAST phases. The specification describes the derivation procedure very flexible (forn inner EAP methods).

The general key derivation looks as follows.

S− IMCK0 = session key seed;

for j=1 to n{

IMCKj = T-PRF (S− IMCKj−1,"Inner Methods Compound Keys", MSKj, 60);

S− IMCKj = IMCKj [0..39];CMKj = IMCKj [40..59];

}

As shown above, an IMCK combines the MSKs from inner EAP methods with keyingmaterial from EAP-FAST phase 1. Each successful inner EAP method derives an IMCK.The CMK helps to protect against man-in-the-middle attacks through cryptographically

3.3 EAP-FAST 61

binding keying material of phase 1 and 2. After each successful inner EAP authentica-tion, EAP MSKs are cryptographically combined with keying material from EAP-FASTphase 1 to generate a compound session key (CMK).

EAP-FAST generates MSK and EMSK as follows:MSK = T-PRF (S− IMCKj, "Session Key Generating Function", 64)EMSK = T-PRF (S− IMCKj, "Extended Session Key Generating Function", 64)

where j is the number of the last successfully executed inner EAP method. This mech-anism guarantees that phase 1 and each inner EAP method contributes to the derivation ofthe MSK and EMSK.

Until now, we assumed that within EAP-FAST phase 2, one or more EAP methods areexecuted. As mentioned above, it is also possible that phase 1 performs a full handshakewhich mutually authenticates client and server. Without inner EAP methods, EAP-FASTderives the MSK and EMSK as follows:

MSK = T-PRF (session key seed, "Session Key Generating Function", 64)EMSK = T-PRF (session key seed, "Session Key Generating Function", 64)

3.3.4 Comments

EAP-FAST can be seen as a very flexible EAP method which is particularly intended fornetworks with constrainted devices due to the possibility to mutually authenticate based ona pre-shared key. In comparison to EAP-TTLS and PEAP, EAP-FAST does not require thatthe EAP server authenticates by means of a digital certificate.

EAP-FAST has been one of the first EAP methods which were designed especiallyhaving RFC 3748 (the ”new” EAP specification) and RFC 4017 in mind. EAP-FAST offersreasonable countermeasures against all currently known attacks on network protocols ingeneral and on EAP in particular.


3.4 EAP-PSK

3.4.1 History

EAP-PSK is a joint work of France Telecom R&D and Siemens AG. The first version waspublished in January 2004. The latest version 10 appeared in February 2006. EAP-PSK hasgot an EAP expert review in June 2005, and a second expert review in January 2006, and iscurrently pending in the RFC editor queue.

EAP-PSK performs mutual authentication based on a 16-byte pre-shared key. The au-thors have designed EAP-PSK particularly for environments with restricted computationalressources, for instance for network access authentication purposes in wireless networks.EAP-PSK consists of two roundtrips only, of small sized messages and of lightweightcryptographic computations, which can be efficiently implemented. EAP-PSK avoids public-key operations. Alike most other EAP methods, EAP-PSK offers a protected channel whichcan be used to exchange arbitrary informations.

EAP-PSK relies on one cryptographic primitive only, namely the AES block cipher.All other cryptographic components are chosen in accordance to this. Therefore, EAP-PSK distinguishes from other EAP methods in its very elegantly design, which will beinvestigated in the next section.


EAP-PSK specifies two variants, EAP-PSK standard authentication and EAP-PSK extendedauthentication. They distinguish in the way the protected channel is used which is estab-lished during the authentication procedure. In EAP-PSK standard authentication, the chan-nel is only used for transmission of a protected result indication. If an exchange of arbitraryinformation in variable length is desired, the EAP-PSK extended authentication proceduretakes place. However, the general design is the same, and therefore the thesis restricts onthe analysis of the EAP-PSK standard authentication procedure, as shown in Figure 3.9.


(3) A← B : EAP-Request / EAP-PSK msg 1 (Flags, RANDS, IDS)(4) A→ B : EAP-Response / EAP-PSK msg 2 (Flags, RANDS,RANDP,MACP, IDP)

(5) A← B : EAP-Request / EAP-PSK msg 3 (Flags, RANDS,MACS,PCHANNELS0)(6) A→ B : EAP-Response / EAP-PSK msg 4 (Flags, RANDS,PCHANNELP1)


Figure 3.9: EAP-PSK message flow

3.4 EAP-PSK 63

EAP peer and EAP server mutually authenticate in 1.5 roundtrips only, namely in mes-sages (3)-(5). The underlying authentication protocol is based on the AKEP2 protocol pro-posed in [21]. It is a typical nonce-based challenge/response protocol. Both sides exchangenonces, their identities and a proof of knowledge of the pre-shared key. This is achievedby computing a MAC keyed with the pre-shared key over the previously exchanged nonces(RANDS and RANDP) and identities (IDS and IDP), to bind them to the current sessionparameters.


EAP-PSK attempts to rely on a single cryptographic primitive, namely a block cipher with128 bit block size. The specification chooses AES-128 for this purpose, but does not stip-ulate this setting. All other cryptographic components are chosen having this setting inmind. These mechanisms are the authentication and key agreement protocol (AKEP2 [21]),the MAC function (CMAC [84]), the block cipher mode of operation (EAX [22]) and thekey derivation function PRF, which is based on [59]. They will be described briefly in thefollowing sections.

3.4.3.1 The Implicit Key Exchange Protocol

Mutual authentication and session key derivation is based on AKEP2 (Authenticated KeyExchange protocol 2), specified in [21]. This paper introduces four authentication protocols,namely MAP1, MAP2, AKEP1 and AKEP2. Among them, the implicity key exchange pro-tocol AKEP2 (Figure 3.10) provides a particularly efficient key exchange. [21] explicitelyallows to remove redundant parts from the protocol without an impact on the security. Forinstance, the values B,A, rA in message 2 can be omitted without loss on security.

(1) A→ B : rA(2) A← B : B,A, rA, rB,MACa1(B,A, rA, rB)(3) A→ B : A, rB,MACa1(A, rB)

Session key : k = g(f′a2(rB))

Figure 3.10: Implicit key exchange protocol AKEP2

Initially, the parties A and B must have agreed on two keys, a1 and a2, where a1 is usedexclusively for authentication purposes, and a2 is used exclusively in the scope of sessionkey derivation.[21] suggests f′=DES and g to be a pseudorandom function. The authorsalso allow to derive a1 and a2 from a single key (a), for instance a1 = ga(1) and a2 = ga(2).Finally, the session key is derived independently on both sides as a function of B’s nonceand the key derivation key a2.


EAP-PSK adopts AKEP2 as follows. The pre-shared key is transformed into two 16-byte keys, the Authentication Key (AK) and the Key Derivation Key (KDK). AK corre-sponds to a1, while KDK corresponds to a2. Initially, peer and server share a 16-byte pre-shared key, PSK, which is transformed with aid of KDK and the client’s nonce rA into thesession key TEK (see Section 3.4.3.4). Note that this transformation is performed onlyonce, and that the pre-shared key can be deleted when this has happened.

(1) A← B : B, rB(2) A→ B : A, rA, rB,CMACAK(A,B, rB, rA)(3) A→ B : rA,CMACAK(B, rA)

TEK = PRF(KDK;rA)

Figure 3.11: EAP-PSK’s adoption of AKEP2

To comply with the EAP message flow, where the EAP server sends the first message,the roles of AKEP2 are reversed, so that the EAP server sends the first message. The peerreturns his random number together with a MAC computed over both identities and bothrandom numbers. The MAC is keyed with the Authentication Key (AK). The server thencomputes a similar MAC. The rationale of the MACs is obvious, namely to proof possessionof AK. The nonces guarantee freshness of the exchange and thus prevent replay of a session.

3.4.3.2 CMAC

As message authentication code, EAP-PSK has chosen the One-Key CBC-MAC [84], ab-breviated with OMAC. There are actually two variants of OMAC, namely OMAC1 andOMAC2. OMAC1 is equivalent to CMAC, which is NIST’s recommendation for block ci-pher modes of operation [117]. CMAC is very conservative in its design and requires onlythe existence of a block cipher like AES, Camellia or 3DES, and a hash function. Furtherinformations on the design of CMAC can be found on the author’s website [85].

CMAC is a provably secure variant of the CBC-MAC and improves it in that it allows formessages of both arbitrary length and variable length (in the sense that it does not need to bepadded up). Furthermore, it requires only one key. Other CBC-MAC variants are RMAC,EMAC, XCBC and TMAC, while [86] points out that CMAC offers the best performanceamong them without loss of security strength. Furthermore, the design of CMAC allowsfor highly efficient implementations. OMAC is required by the EAX mode of encryption,which is discussed in the next section. See [107].

3.4.3.3 EAX mode of operation

A mode of operation allows a block cipher to work properly on data larger than its blocksize, which usually coincides with its key size. EAP-PSK chooses the EAX mode of en-

3.4 EAP-PSK 65

cryption as mode of operation, mainly because it strongly relies on OMAC. EAX has beenpublished in 2003, and can be alternatively used to the CCM (Counter Mode with CBC-MAC) mode of operation [118]. In a nutshell, EAX is a combined mode of operation, whichoffers simultaneously encryption and data origin authentication. These schemes are muchmore efficient than to serially apply an encryption and an integrity protection algorithm (forinstance, like TLS does so. On TLS Record layer, the payload is first authenticated, thenencrypted under the ciphersuite’s algorithms).

Another very appreciable property of both CMAC and EAX is, that no Intellectual Prop-erty Right (IPR) claims are filed, which means that CMAC and EAX are both entirely inthe public domain.

From a technical point of view, EAX belongs to the family of two-pass AEAD schemes(authenticated-encryption with associated-data). An AE scheme is a symmetric-key mech-anism which provides both privacy and authenticity of a message. Oftentimes, not all of thedata needs to be privacy-protected, i.e. encrypted, but needs only to be integrity-protected.This portion is referred to as the ”header” or ”associated data”, the scheme is then called an”AEAD scheme”. Finally, a two-pass AEAD scheme has one pass to encrypt the data usinga symmetric encryption algorithm, which yields privacy, and another pass to authenticatethe message using a MAC algorithm, which yields authenticity.

N M

C

H

T

K

K

CTR (.)

0

2

K1 OMAC (.)

KOMAC (.)

OMAC (.)

Figure 3.12: EAX encryption operation

EAX is parametrized by a block cipher E, having the block size n (in bit), and a taglength τ ∈ {0, . . . ,n} (in bit). The tag length determines the strength of the integrity pro-


tection. Given a nonce N, a message M and a header H, EAX protects the privacy of Mand the authenticity of both M and H. Its output is the ciphertext C and the tag T. Figure3.12 illustrates the internals of the EAX encryption procedure. In this figure, OMACt

K(M)stands for OMACK([t]n‖M), where [t]n denotes the encoding of t into an n-bit binary string(t ∈ [0, . . . ,2n−1]).

EAP-PSK has chosen the EAX mode of encryption to allow client and server to securelyexchange information within the protected channel. The payload of the PCHANNEL at-tributes (in messages 5 and 6 of Figure 3.9) are encrypted under EAX. The instantiation isas follows. EAX is keyed with TEK, the header H is the EAP header and parts of the EAPmessage, and the message M is the EAP payload. The nonce N is realized through a counter.Its initial value is 0 and is incremented by 1 for each message containing a PCHANNELattribute.


Key derivation is realized through an one-block-to-many mode of operation for block ci-phers, a typical construction scheme for pseudorandom functions. [59] describes how tocombine a one-block-to-many-block function FK with a mode of operation for block ciphers(e.g. the CTR-mode) while the output stream remains pseudorandom. This construction isalso used in the UMTS authentication and key agreement sample algorithm Milenage andis referred to as ”Milenage modified counter mode”, abbreviated by FMIL.

This function has the following construction. Under the control of a key K, FMILexpands one input block x into a longer t-block output (z1, . . . ,zt), t ≥ 2, that is FMIL :{0,1}n→ {0,1}t·n, where the output block zk is computed to as zk = f(rot(f(x), rk))⊕ ck).This construction is illustrated in Figure 3.13.

EAP-PSK implements FMIL as follows. As counter values ci, the monoton-increasingsequence "i" is chosen. With this setting, the rotation may be omitted, because all ci con-stants are pairwise distinct ([59], Section 4). Furthermore, f is instantiated with AES withn=128 bit block size.

The key derivation function FMIL is used twice within EAP-PSK. The first time, it isused to transform the 16-byte pre-shared key PSK into two 16-byte keys, the AuthenticationKey (AK) and the Key Derivation Key (KDK). The second time, it is used to derive thesession key TEK and the MSK and EMSK. This derivation follows the recommendation of[BR93], that is, it is keyed with another key than the key used for authentication, and it hasas seed the client’s nonce.

To generate the required amount of data, the PRF has to iterate 9 times, which returnsexactly the required 144 byte. The TEK is the first output block, the MSK corresponds toblocks 2-5, and the EMSK corresponds to blocks 6-9.

3.4.4 Comments

EAP-PSK is a sophisticated EAP method with a particular elegant design. The crypto-graphic components are well-deliberated. They are lightweight and keep the latency foran authentication procedure small. By the choice to restrict on symmetric cryptography,

3.4 EAP-PSK 67

c1

f

...............

rotation by r1

rotationby r2 by rt

rotation

...............

f f

c2 ct

f

y

x

z1 z2 zt

Figure 3.13: Milenage modified counter mode

PRF (key, label, seed, outputlength){

n = doutputlength/16e;temp = AES-128 (key, seed);

for i=1 to nTi = temp XOR "i";

return T1 ‖ T2 ‖ · · · ‖ Tn;}

Figure 3.14: EAP-PSK key derivation function

however, numerous enhanced features cannot be realized, for instance identity protection,perfect foward secrecy and support for weak pre-shared keys (e.g. those derived from apassword). Nevertheless, according to the specification, the main intention of EAP-PSK isto be a lightweight pre-shared key based EAP method and to be comparable to EAP-MD5in terms of simplicity and efficiency.

Obviously, EAP-PSK has already attracted attention, namely in the scope of IEEE


TEK MSK EMSK

(64 byte)(64 byte)(16 byte)

.............

............. .............

.............c1="1" c2="2" c9="9"

z1 z2 z5 z6 z9AK KDK

"0"

AES−128(PSK, .) (PSK, .)

AES−128

AES−128(PSK, .)

AES−128

AES−128(KDK, .)

AES−128(KDK, .)

AES−128(KDK, .)

c1="1" c2="2"

(KDK, .)

(16 byte)(16 byte)

(16 byte) (16 byte)

(16 byte) (16 byte)

(16 byte) (16 byte) (16 byte)

rA

Figure 3.15: EAP-PSK key derivation in detail

802.16e (WiMAX). The WiMAX Forum suggests EAP-PSK to perform device authenti-cation between the subscriber’s device and the base station of the access network ([161],7.3.6.2.3). Also the IEEE 802.16e Standard mentions EAP-PSK to be suitable for bothfirst and second EAP method of PKMv2 Double-EAP mode ([75], p.224; see also Section4.2.3.4). Consequently, there is serious need for an EAP method like EAP-PSK.

3.5 EAP-PAX

3.5.1 History

EAP-PAX (EAP type number 46) is a proposal of the University of Maryland. The firstversion was published in July 2004, the most recent version 06 was released in January2006.

EAP-PAX performs mutual authentication based on a 16-byte pre-shared key. It at-tempts to be minimal in terms of computation, packet count and infrastructure requirementshaving particularly handheld devices in wireless environments in mind. EAP-PAX allows tobootstrap key derivation using a weak pre-shared key, for instance a 6-digit PIN. As optionalfeature, EAP-PAX offers user identity protection with aid of public-key cryptography.

3.5 EAP-PAX 69


EAP-PAX comprises two distinct subprotocols, called PAX_STD and PAX_SEC. Each ofthem is available in two operational modes, from now on called ”mode 1” and ”mode 2”.These two modes vary in the quality of random data, which is exchanged at the begin-ning of an EAP-PAX authentication procedure. While mode 1 exchanges nonces, mode 2exchanges Diffie-Hellman or ECC public keys and thus offers forward secrecy.

(1) A← B : EAP-Request/Identity(2) A→ B : EAP-Response/Identity (id)

(3) A← B : EAP-Request / PAX_STD-1 (A)(4) A→ B : EAP-Response / PAX_STD-2 (B, CID, MACCK(A, B, CID) [, ADE])

(5) A← B : EAP-Request / PAX_STD-3 (MACCK(B, CID) [, ADE])(6) A→ B : EAP-Response / PAX-ACK ([ADE])


Figure 3.16: EAP-PAX_STD mode


(3) A← B : EAP-Request / PAX_SEC-1 (M, PK or CertPK)(4) A→ B : EAP-Response / PAX_SEC-2 (ENCPK(M, N, CID))

(5) A← B : EAP-Request / PAX_SEC-3 (A, MACN(A, CID))(6) A→ B : EAP-Response / PAX-SEC-4 (B, MACCK(A, B, CID) [, ADE])

(7) A← B : EAP-Request / PAX-SEC-5 (MACCK(B, CID) [, ADE])(8) A→ B : EAP-Response / PAX-ACK ([ADE])


Figure 3.17: EAP-PAX_SEC mode

The PAX_STD and PAX_SEC message flows are shown in Figure 3.16 and Figure 3.17,respectively. PAX_STD is the basic version and suitable for most applications. It is usedduring a typical authentication. PAX_SEC offers more features in that it supports provi-sioning and identity protection. Therefore, public key operations are required. PAX_SEC


can run in several configurations with or without certificates. Even raw public keys aresupported.

The cryptography will be discussed in the next section. However, the following detailsmay be helpful to understand the PAX_STD protocol. In mode 1, the attributes A and Bcontain 256-bit nonces, in mode 2 they contain Diffie-Hellman or ECC public keys. CIDmeans Client Identifier, and is typically a client NAI. The confirmation key CK is derivedfrom the pre-shared key and the exchanged nonces. Peer and EAP server then compute aMAC over the nonces and the peer’s identity and exchange them subsequently.

If each side is able to verify the received MAC, both parties were able to authenticatethemselves. ADE stands for ”Authenticated Data Exchange” and allows for exchange ofarbitrary communication. The concept behind an ADE exchange is similar to the protectedchannel, which is offered by most other EAP methods. In contrast to them, however, EAP-PAX authenticates only the data, but does not encrypt it.

The PAX_SEC protocol contains an additional roundtrip (messages 3 and 4 in Figure3.17). In message 3, the server sends his certificate CertPK or his public key PK - whichdepends on the configuration - together with a 128-bit nonce M. The peer generates a 128-bit nonce N and uses the server’s public key to encrypt his identity and both nonces M andN. The parameters A and B have the same definition as in PAX_STD.

Since EAP-PAX contains four different protocols having each a different motivation, itis important to elaborate their differences. This is the intention of Section 3.5.3.1, whileSection 3.5.3.2 investigates the key derivation within EAP-PAX.


3.5.3.1 Comparision of the four different modes

Figure 3.18 contrasts the four different protocols offered by EAP-PAX. Since mode 2 per-forms a public key exchange to obtain forward secrecy, this mode is particularly suited forprovisioning of a weak pre-shared key.

Regarding the notation, rA and rB are 256-bit random numbers, r′A and r′B are 128-bitrandom numbers.

EAP-PAX offers flexibility regarding the choice of cryptographic algorithms in that itallows the EAP server to select a MAC algorithm, a Diffie-Hellman Group and a public-keyalgorithm. Figure 3.20 depicts the packet format of an EAP-PAX message. Obviously, eachEAP-PAX packet contains a MAC ID, a DH-Group ID and a Public Key ID. Figure 3.19summarizes the possible choices.

The MAC output is truncated to 128 bit. In case of PAX_STD, a Public Key ID isnot required. If no key update takes place, then the Diffie-Hellman Group ID ”none” mustbe chosen. For simplicity, EAP-PAX specifies two ciphersuites which are mandatory toimplement. They vary in the offered security strength. Ciphersuite 1 offers roughly 112 bitof security and consists of HMAC-SHA-1, the 2048-bit modp group (IANA DH Group 14)and RSA-PKCS1-V1.5, used with a 2048-bit public key. Ciphersuite 2 offers roughly 128bit of security and is the recommended suite of the EAP-PAX specification. It comprises

3.5 EAP-PAX 71

EAP-PAX_STD mode 1

(3) A← B : rB

(4) A→ B : rA,A,MACCK(rB, rA,A)(5) A← B : MACCK(rA,A)

EAP-PAX_STD mode 2

(3) A← B : gx

(4) A→ B : gy,A,MACCK(gx,gy,A)(5) A← B : MACCK(gy,A)

EAP-PAX_SEC mode 1

(3) A← B : r′B,pkB

(4) A→ B : ENCpkB(r′B, r′A,A)

(5) A← B : rB,MACr′A(rB,A)

(6) A→ B : rA,MACCK(rB, rA,A)(7) A← B : MACCK(rA,A)

EAP-PAX_SEC mode 2

(3) A← B : r′B,pkB

(4) A→ B : ENCpkB(r′B, r′A,A)

(5) A← B : rB,MACr′A(gx,A)

(6) A→ B : gy,MACCK(gx,gy,A)(7) A← B : MACCK(gy,A)

Figure 3.18: Cryptographic core of EAP-PAX

HMAC-SHA-256, the 3072-bit modp group (IANA DH Group 15) and RSAES-OAEP, usedwith a 3072-bit public key.

Each EAP-PAX packet contains an Integrity Check Value (ICV), which is computedover the entire EAP packet, including the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC is keyed with ICK using the MAC type specified by the MAC IDin the EAP-PAX header. Note that the ICK is not yet available for the messages PAX_STD-1, PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3. Therefore, the MAC in these messages iskeyed using a zero-byte NULL key. Note that at present, only EAP-PAX, EAP-AKA andEAP-SAKE compute a MAC over the entire EAP packet.


MAC ID 0x01 HMAC_SHA1_128 [FIPS198] [FIPS180]0x02 AES_CBC_MAC_128 [FIPS113] [FIPS197]0x03 HMAC_SHA256_128 [FIPS180]

DH Group ID 0x00 NONE0x01 2048-bit MODP Group (IANA DH Group 14) [RFC3526]0x02 3072-bit MODP Group (IANA DH Group 15) [RFC3526]0x03 NIST ECC Group P-256 [FIPS186]

Public Key ID 0x00 NONE0x01 RSAES-OAEP [RFC3447]0x02 RSA-PKCS1-V1_5 [RFC3447]0x03 El-Gamal Over NIST ECC Group P-256 [FIPS186]

Figure 3.19: Cryptographic agility offered by EAP-PAX

0 31

Code Identifier

Type OP−Code Flags MAC ID

Public Key IDDH Group ID

ICV

Payload

Length

Figure 3.20: EAP-PAX packet format


The PAX-KDF is depicted in Figure 3.21. It is very similar to the EAP-FAST key derivationfunction T-PRF in the sense that it results a concatenation of HMAC-SHA-1 outputs. Thedifference to T-PRF is that the blocks are not cryptographically interlocked, but independentof each other.

3.5 EAP-PAX 73

The PAX-KDF is applied to generate session keys as well as to export keying material.The long-life pre-shared key has a length of 16 byte and is denoted with AK. If EAP-PAXperforms a key update, the 16-byte AK is replaced with AK’. From AK, a master key MK isderived. This key is subsequently used together with the entropy E to derive further keyingmaterial. In mode 1, the entropy E is rB‖rA, in mode 2, it is gxy.

PAX-KDF(key, label, seed, outputlength){

n = doutputlength/16e;for i=1 to n

Ti = MAC (key, label || seed || ”i”) ;

return T1 ‖ T2 ‖ · · · ‖ Tn;}

Figure 3.21: EAP-PAX key derivation function

The key derivation within EAP-PAX can be summarized to as

AK’ = PAX-KDF (AK, "Authentication Key", E, 16)MK = PAX-KDF (AK, "Master Key", E, 16)CK = PAX-KDF (MK, "Confirmation Key", E, 16)ICK = PAX-KDF (MK, "Integrity Check Key", E, 16)MID = PAX-KDF (MK, "Method ID", E, 16)MSK = PAX-KDF (MK, "Master Session Key", E, 64)EMSK = PAX-KDF (MK, "Extended Master Session Key", E, 64)IV = PAX-KDF ((0x00)16, "Initialization Vector", E, 64)

3.5.4 Comments

EAP-PAX belongs like EAP-PSK or EAP-AKA to the pre-shared key based EAP methods.The four subprotocols allow for a broad range of deployment scenarios. The basic EAP-PAX authentication mode, PAX_STD, is very efficient and likely the most common choice.This mode relies on the exchange of nonces and MACs. It makes use of symmetric cryp-tography only. The exchange of nonces can be replaced by a Diffie-Hellman or ECC publickey exchange. This mode offers forward secrecy and is particularly suited for key update.

Finally, EAP-PAX optionally supports identity protection. This is achieved by means ofan initial message exchange, where the server sends his public key, and the client encryptshis identity under this public key and sends the result back. In case of a raw public key,which cannot be verified by the client, passive identity protection is achieved. In case of acertificate, the client can first verify the server’s public key. Only if the client is convinced


of the authenticity, he sends his identity. Hence, the client’s identity is protected againstactive attackers.

EAP-PAX seems therefore to be an interesting alternative to EAP-PSK and EAP-FAST.Especially the cryptographic agility and the supported optional features distinguish EAP-PAX from other EAP methods.

3.6 EAP-IKEv2

3.6.1 History

EAP-IKEv2 is a proposal of Siemens AG, France Telecom R&D and Toshiba. The firstversion of EAP-IKEv2 was published in March 2003. The most recent version 10 appearedin February 2006.

The basic idea is to provide a flexible, secure EAP method by adopting mechanisms andpayloads of IKEv2. EAP-IKEv2 aims to benefit from IKEv2’s well-analyzed cryptography,which in turn may benefit from more than ten years work on IKE version 1. EAP-IKEv2allows for a variety of authentication combinations. Server and peer can authenticate bymeans of public key techniques (certificate or raw RSA public key), symmetric key tech-niques (shared secret), or a combination of both.

Since EAP-IKEv2 chooses the EAP server as Initiator and the peer as Responder, itfollows that the EAP server authenticates prior to the peer. If the server now authenticatespublic-key based, the peer can authenticate by means of a weak pre-shared key, e.g. apassword. Therefore, EAP-IKEv2 seems to be applicable as well as suitable for a variety ofdeployment scenarios.

Before EAP-IKEv2 is described, the corresponding parts of IKEv2 are briefly presented.The Internet Key Exchange protocol is a very complex protocol. Therefore, the intentionwon’t be to discuss all aspects of IKEv2, but rather to restrict on elaborating the necessaryparts to understand the EAP-IKEv2 protocol properly.

3.6.2 Internet Key Exchange Protocol v2 (IKEv2)

In December 2005, IKEv2 was adopted as Standards Track and published in RFC 4306[91]. It obsoletes IKEv1, specified in RFC 2407-2409 [70, 71, 72]. IKEv2 is a componentof IPsec [69] and performs mutual authentication between two parties and establishes anIKE security association (IKE_SA) which can be used susequently to establish SAs forESP and AH (CHILD_SAs). The two parties are referred to as Initiator and Responder.

A security association can be considered as a connection that affords security servicesto the traffic carried by it. A security association comprises keys, algorithms, operationalmodes, and protocols, and is uniquely identified by its security parameter index (SPI). Notethat a security association is unidirectional, hence a bidirectional connection requires twoSAs.

3.6 EAP-IKEv2 75

3.6.2.1 IKEv2 message flow

IKEv2 consists of two phases. IKEv2 phase 1 establishes an IKE_SA and optionally the firstCHILD_SA. IKEv2 phase 2 is optional and allows for establishing of further CHILD_SAs(with aid of so called CREATE_CHILD_SA exchanges). EAP-IKEv2 is actually only in-terested in re-use of the IKE_SA. Therefore, the thesis will focus on IKEv2 phase 1. Thisphase consists of four messages, namely the IKE_SA_INIT and IKE_AUTH exchange.Figure 3.23 depicts the IKEv2 phase 1 message flow.

Initiator Responder

(1) HDR, SAi1, KEi, Ni -

(2) ¾ HDR, SAr1, KEr, Nr[,CERTREQ]

(3) HDR, SK {IDi, [CERT,] -[CERTREQ,] [IDr,] AUTH,SAi2, TSi, TSr}

(4) ¾ HDR, SK {IDr, [CERT,]AUTH, SAr2, TSi, TSr}

Figure 3.22: IKEv2 phase 1

In the IKE_SA_INIT exchange, security parameters for the IKE_SA are negotiated, andDiffie-Hellman public keys and nonces are exchanged. The cryptographic algorithms com-prise an encryption algorithm, a pseudorandom function, an integrity protection algorithmand a Diffie-Hellman group. Appendix C (page 165) summarizes the supported algorithms.

After the IKE_SA_INIT exchange, encryption and integrity protection keys are derived,which are used to protect subsequent communication. It follows the IKE_AUTH exchange,in which the previous messages are authenticated and in which identities and certificatesare exchanged. At the end of IKEv2 phase 1, an IKE_SA and the first CHILD_SA areestablished.

Messages 1 and 2 are not difficult to explain. HDR contains the Security ParameterIndices (SPIs), version numbers and various flags. The Initiator sends within SAi1 a set ofsupported cryptographic algorithms. The Responder chooses a suitable set and informs theInitiator about his choice through the SAr1 payload. The KEi and KEr payloads containDiffie-Hellman public keys, the Ni and Nr payloads contain nonces.

Messages 3 and 4 can vary, because their specific content depends on the key which isassociated with each sides’ identifier IDi and IDr. If the authentication is based on public-key, then certificates can be exchanged within CERT payloads. With CERTREQ, the senderrequests the receiver to send his certificate.


Initiator Responder



(3) HDR, SK {IDi, [CERT,] -[CERTREQ,] [IDr,] AUTH,SAi2, TSi, TSr}

(4) ¾ HDR, SK {IDr, [CERT,]AUTH, SAr2, TSi, TSr}

Figure 3.23: IKEv2 phase 1

The AUTH payloads of message 3 and 4 authenticate the ”unauthenticated” messages1 and 2, respectively. This is accomplished by a signature or a MAC. Cruicial for thecorrectness and subsequent security of the IKEv2 protocol is that the nonce of the otherparty is signed, and that the identity of the other party is not signed. The IKEv2 signaturemode relies on the SIGMA key exchange protocol [95]. Payloads within the brackets of SK{ } are encrypted and integrity protected by means of SK_e and SK_a of the sending party.These two keys result from the initially exchanged Diffie-Hellman public keys and nonces.With aid of the IDr payload, the Initiator can explicitely specify with which Responder hewants to communicate.

EAP-IKEv2 omits the last three payloads of both IKE_AUTH messages, because theybelong to the negotiation of the first CHILD_SA, which is not used by EAP-IKEv2.

3.6.2.2 Key derivation within IKEv2 phase 1

The initially negotiated pseudorandom function is used for the construction of keying ma-terial for all cryptographic algorithms in both IKE_SA and CHILD_SAs. Its constructionis depicted in Figure 3.24. It can be based on HMAC-MD5, HMAC-SHA-1, HMAC-Tigeror AES-128-CBC (see [91], Section 3.3.2). Consequently, one iteration of the IKEv2 PRFreturns 16 or 20 byte output. The PRF is used iteratively, indicated by prf+, to generate therequired amount of data. A very similar construction underlies T-PRF of EAP-FAST (seeFigure 3.8 on page 60). T-PRF, however, hashes in addition the given outputlength.

Figure 3.25 describes the keying hierarchy of IKEv2 phase 1. The goal of the IKE_SA_INITexchange is to add freshness to the IKE session. The Diffie-Hellman key exchange offersperfect forward secrecy. IKEv2 itself introduces prime order groups with 768 bit and 1024bit, and allows for additional groups with larger moduli, specified in [93], where six primeorder groups with size up to 8192 bit are proposed. Nonces must be chosen randomly, must

3.6 EAP-IKEv2 77

prf+(key, seed){

S = label‖”0”‖seed;n = doutputlength/20e;T0 = ””;

for i=1 to nTi = prf(key,Ti−1 ‖ S ‖ ”i”);

return T1 ‖ T2 ‖ · · · ‖ Tn;}

Figure 3.24: IKEv2 key derivation function

be at least 16 byte and must be at least half of the output size of the negotiated pseudoran-dom function.

SK_d SK_ai SK_ar SK_ei SK_er SK_pi SK_pr

irg

Nrprf

prf+SPIi SPIr

Ni

SKEYSEED

Figure 3.25: Key derivation within IKEv2 phase 1

After the IKE_SA_INIT exchange, both sides compute with aid of the nonces and theDiffie-Hellman shared secret SKEYSEED = prf (Ni || Nr, gir), which is subsequently used


to derive keying material for derivation of CHILD_SAs (SK_d), data origin authentication(SK_ai and SK_ar), encryption (SK_ei and SK_er) as well as to generate the AUTH payload(SK_pi and SK_pr). These keys are computed by prf+ (SKEYSEED, Ni || Nr || SPIi || SPIr).

3.6.2.3 Key derivation within IKEv2 phase 2

Although the core EAP-IKEv2 message exchange adopts parts of IKEv2 phase 1 only,the EAP-IKEv2 session resuming case and the EAP-IKEv2 key derivation procedure re-use parts of IKEv2 phase 2. The IKE_SA exchange finishes with the establishment of anIKE_SA, but also piggybacks the establishment of the first CHILD_SA. Further CHILD_SAscan be established with aid of CREATE_CHILD_SA exchanges in IKEv2 phase 2. Keyingmaterial for the CHILD_SAs is generated by

KEYMAT = prf+(SK_d,[gir(new)‖] Ni || Nr).

The nonces stem from the IKE_SA_INIT exchange, SK_d stems from the key derivationafter that exchange. Optionally, a Diffie-Hellman key exchange may take place. EAP-IKEv2 uses this mechanism without the additional Diffie-Hellman key exchange to generatekeying material for the MSK, EMSK and IV.

The second mechanism re-used by EAP-IKEv2 is the ability of CHILD_SAs to rekeyIKE_SAs. EAP-IKEv2 applies this mechanism for its fast reconnect case. The SKEYSEEDfor the new IKE_SA is generated with aid of SK_d of the existing IKE_SA as

SKEYSEED = prf (SK_d (old),[gir(new)‖] Ni || Nr),

where SKEYSEED is splitted in the same way as described above.

3.6.2.4 Authentication types within IKEv2

IKE already offers a variety of different authentication types. Mutual authentication can bedone by means of digital certificates, shared secrets or a combination of both. In addition,IKEv2 allows authentication by means of EAP. The basic concept is that an AUTH payloadauthenticates the previously exchanged ”unauthenticated” data, for instance, the nonces andDiffie-Hellman public keys. The Initiator’s AUTH value in message 3 shall authenticate thevalues of message 1, while the Responder’s AUTH value shall authenticate the values ofmessage 2.

IKEv2 offers numerous certificate encodings, e.g. X509 certificates with a signature, aPGP certificate or raw public keys. The IKEv2 specification [91] provides in Section 3.6a complete list of supported encoding styles. But regardless which specific certificate typeis used, IKEv2 distinguishes only between three different values in the AUTH payloads([91] Section 3.8), namely to address public key-based authentication, shared secret-basedauthentication, and EAP-based authentication.

Denote IDi’ and IDr’ the entire ID payloads excluding the fixed header, Ni and Nr theplain nonces (without the header). In case of public-key based authentication, the AUTH

3.6 EAP-IKEv2 79

payload contains either a RSA Digital Signature (RSA private key over a PKCS#1 paddedhash) or a DSS Digital Signature (DSS private key over a SHA-1 hash).

I→ R: AUTH = SIG (message 1 || Nr || prf (SK_pi, IDi’))

I← R: AUTH = SIG (message 2 || Ni || prf (SK_pr, IDr’))In case of shared secret-based authentication, the AUTH payload contains a MAC,

which is referred to as ”Shared Secret Message Integrity Code”. The IKEv2 specificationsuggests to store prf (Shared Secret, ”Key Pad for IKEv2”) rather than the shared secret selfin the configuration file.5

I→ R: AUTH = prf (prf (Shared Secret, "Key Pad for IKEv2"),message 1 || Nr || prf (SK_pi, IDi’) )

I← R: AUTH = prf (prf (Shared Secret, "Key Pad for IKEv2"),message 2 || Ni || prf (SK_pr, IDr’) )

In addition, IKEv2 offers the possibility for EAP-based mutual authentication. Thespecification assumes the Initiator to be the EAP peer, and the Responder either to be theEAP server or an intermediate node (e.g. gateway) which has a connection to the EAPserver.

The Initiator signalizes to use EAP by omitting the AUTH payload in message 3. Ifthe Responder agrees on EAP-based authentication, he sends in message 4 his signature tothe peer. The Initiator can thus assure to talk to the legitimate Responder. It follows oneor more EAP message exchanges. The EAP authentication is finished when the Responder(i.e. EAP server) sends an EAP-Success or EAP-Failure. As a consequence, both sides havederived the MSK and EMSK. The AUTH payload proves knowledge of the MSK and alsoauthenticates the unauthenticated values from the IKE_SA_INIT exchange.

The computation is as follows

I→ R: AUTH = prf (prf (MSK, "Key Pad for IKEv2"), message 1 || Nr || prf (SK_pi, IDi’) )

I← R: AUTH = prf (prf (MSK, "Key Pad for IKEv2"), message 2 || Ni || prf (SK_pr, IDr’) )

It should be discussed briefly why the Responder has to send a signature in message 3,the more so as mutual authentication is already covered by the EAP method. The reasonis that within the EAP method, the Initiator in its role as EAP peer mutually authenticateswith the EAP server in the background and not with the Responder. The authors of [51]claim that due to the trust-relationship between Responder and EAP server, transmissionof the Responder’s signature to the Initiator may be omitted and that mutual authenticationwithin the EAP method would be sufficient. This issue has already been broadly discussedin the IPSec mailing list in December 20036. In how far this modification affects IKEv2’ssecurity, should be investitated further. Anyway, proposals which tend to modify a sound,well-analyzed security protocol should be done only with much caution.

5Since the prf is negotiated during the IKE_SA_INIT exchange, it is not clear which prf to apply. See arelated thread [127] in the IPsec mailing list for further details. Short, the IKEv2 specification has a mistakehere.

6http://www.vpnc.org/ietf-ipsec/03.ipsec/msg02534.html


Initiator Responder



(3) HDR, SK {IDi, [CERT,] -[CERTREQ,] [IDr,]SAi2, TSi, TSr}

(4) ¾ HDR, SK {IDr, [CERT,]AUTH, EAP }

(5) HDR, SK {EAP} -...

(6) ¾ HDR, SK {EAP-Success}

(7) HDR, SK {AUTH} -(8) ¾ HDR, SK {AUTH, SAr2, TSi, TSr}

Figure 3.26: IKEv2 phase 1 authentication using EAP

Initiator Responder EAP server

IKEv2Corporate Network

Backend AuthenticationServer

Security GatewayRoad Warrior

EAP method in IKEv2

Figure 3.27: EAP in IKEv2

As mentioned above, EAP-IKEv2 assigns the EAP peer to the Responder, and the EAPserver to the Initiator, that is, the roles are reversed to the original IKEv2 proposal. Conse-quently EAP-IKEv2 cannot make use of IKEv2’s EAP extension.

3.6 EAP-IKEv2 81

3.6.3 EAP-IKEv2 Protocol overview

EAP-IKEv2 chooses the EAP server to be the Initiator, the peer to be the Responder. There-fore, the EAP server initiates the EAP-IKEv2 conversation. Figure 3.28 shows the EAP-IKEv2 message flow. As can be seen, it is a straightforward encapsulation of the originalIKEv2 protocol in EAP-Request/Response pairs. Messages 3 and 4 negotiate cryptographicalgorithms, exchange nonces, and perform a Diffie-Hellman key exchange. Optionally,message 4 can transport the peer’s identity. These two messages correspond approximatelyto the IKE_SA_INIT exchange of IKEv2. Messages 5 and 6 authenticate the values ofthe previous message exchange. Both sides exchange their identities, and depending onthe chosen authentication type, certificates and signatures or message authentication codes.These two messages are similar to the IKE_AUTH exchange of IKEv2.


(3) A← B : EAP-Request / EAP-IKEv2 (HDR(A,0), SAi1, KEi, Ni)

(4) A→ B : EAP-Response / EAP-IKEv2(HDR(A,B), SAr1, KEr, Nr [,CERTREQ] [,SK{IDr}])

(5) A← B : EAP-Request / EAP-IKEv2(HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH})

(6) A→ B : EAP-Response / EAP-IKEv2(HDR(A,B), SK {IDr, [CERT,] AUTH})


Figure 3.28: EAP-IKEv2 message flow

If both sides autenticate by means of a pre-shared key, however, the server needs to knowthe peer’s identity in order to lookup for the correct pre-shared key. The AUTH payload isgenerated with aid of the pre-shared key. Unfortunately, the client sends its password in thefollowing message first. This problem already arised in the scope of IKE, but in contrastto EAP, the Initiator can assume the Responder’s identity with aid of the IP address. Tosolve this problem, the peer sends his identity in message 4 by means of SK{IDr}. It is sentencrypted, therefore it is protected against eavesdropping.

EAP-IKEv2 also offers a fast reconnect case. It is based on the mechanism of IKEv2 torekey and IKE_SA using a CREATE_CHILD_SA exchange (see Section 3.6.2.3). The pro-cedure is very similar to the TLS session resumption case. The SK_d from the establishedIKE_SA (corresponds roughly to the TLS pre-master secret) is re-used, and is refreshed byan exchange of nonces and optionally Diffie-Hellman values.

Note that the fast reconnect case does not work in its current form. The EAP server



(3) A← B : EAP-Request / EAP-IKEv2 (HDR, SK {SA, Ni [,KEi]})(4) A→ B : EAP-Response / EAP-IKEv2 (HDR, SK {SA, Nr [,KEr]})


Figure 3.29: EAP-IKEv2 fast reconnect

does not know in message (3) which session to resume. The identity of message (2) maynot be used for a hint on the client’s identity. Either, a suitable client identifier must betransmitted in (2), for instance following the approach of the SIGMA-P protocol [96], orthe roles of Initiator and Responder must be reversed. The latter case would cause an addi-tional roundtrip as well as make the password-based authentication of the peer unapplicable(because the EAP peer authenticates prior to the EAP server).


To generate keying material for the MSK, EMSK and IV, EAP-IKEv2 adopts IKEv2’sderivation procedure for keying material for CHILD_SAs,

KEYMAT = prf+ (SK_d, Ni || Nr),

where Ni and Nr originate from the EAP-IKE_SA_INIT exchange. The pseudorandomfunction prf+ is iterated as long as the required amount of data is generated, namely 192byte. If prf yields 20 byte per iteration, then the loop must iterate 10 times. The last 8 byteare then skipped. If the prf yields 16 byte per iteration, then the loop iterates exactly 12times. The MSK is the first 64 byte, the EMSK the second 64 byte, and the IV the third 64byte.

This section aims to conclude with Figure 3.30, which provides a big picture of the keyderivation process in EAP-IKEv2.

3.6 EAP-IKEv2 83

IDi prf

SIG NrSAi1,KEi,Ni

(for the initiator)

AUTH

irg

prf

prf+

SKEYSEED

gr, i gi, r (for the responder)(for the initiator)

SK_d SK_ai SK_ar SK_ei SK_er SK_pi SK_pr

SPIr

Nr

SPIi

Ni

(certificate−based)

prf

SIG

AUTH

IDr

SAr1,

NrKEr, Ni

(for the responder)

Ni Nrprf+

IVEMSKMSK

KEYMAT

key generation for CHILD_SA

adopted from IKEv2

Figure 3.30: EAP-IKEv2 key derivation in detail

3.6.5 Comments

Due to the variety of supported user authentication credentials, EAP-IKEv2 seems to com-bine the capabilities of certificate-based methods like EAP-TLS, pre-shared key based meth-ods like EAP-PSK, and password-based methods like EAP-TTLS. Indeed, the offered flexi-bility is similar to that of EAP-FAST (see Section 3.3). The distribution of the roles enablesfor password-based authentication of the peer and - in case of public-key based server au-thentication - for active identity protection, but let valuable mechanisms of IKEv2 unused,for instance the EAP-based authentication or the Cookie-based denial-of-service protectionmechanism. As mentioned above, the fast reconnect mode does not work in its current form.

However, it must be explicitely stated that EAP-IKEv2 is a completely new protocoleven if it re-uses parts of IKEv2. Therefore EAP-IKEv2 does not inherit the security proper-ties of IKEv2. The main reason is that the environment in which EAP-IKEv2 is performedis totally different from the intended one for IKEv2. By adding the Responder’s identitySK{IDr} to message 4, compliance with the original IKEv2 protocol is given up. There-fore, a thorough cryptographic analysis of EAP-IKEv2’s security seems to be reasonable itis released.


3.7 EAP-AKA

3.7.1 History

The EAP-AKA protocol (EAP type number 23) was developed in the 3GPP by Ericsson andNokia.7 EAP-AKA is an EAP method which re-uses the Authentication and Key Agreement(AKA) mechanism originally specified for the 3G networks UMTS and cdma2000. AKAruns in an UMTS Subscriber Identity Module (USIM) and - for cdma2000 - in a (Remov-able) User Identity Module ((R)UIM). The first version of EAP-AKA was published in May2001, the final draft version 15 appeared in December 2004. In January 2006, EAP-AKAwas finally adopted as RFC [17].

The primary intention of EAP-AKA is to make the UMTS authentication mechanismavailable in EAP. By this extension, any application or protocol which can perform EAPauthentication is now able to perform UMTS AKA. Especially cellular network providersrecognize an opportunity to extend their product portfolio by offering 802.11 WLAN-basednetwork access to their subscribers.

UMTS AKA performs authentication based on a 128-bit pre-shared key, which is sharedbetween the user’s mobile station (MS) and the user’s home network. Furthermore, UMTSAKA addresses the shortcomings of GSM AKA and improves it by adding network to userauthentication to prevent false base station attacks, by adding an integrity protection key(next to a cipher key) and by increasing the key strength from 64 to 128 bit.

According to [166], the main design goals of UMTS can be summarized to be mutualauthentication between the user and the network, establishment of a cipher key and anintegrity key upon successful authentication, as well as freshness assurance to the user ofthe established cipher key and integrity key.

Furthermore, the UMTS security goals as outlined in [1] comprise user identity con-fidentiality (that the user’s IMSI cannot be eavesdropped), user location privacy (user’spresence or arrival cannot be determined by eavesdroppers), and user untraceability (thatby eavesdropping an intruder cannot deduce whether different services are delivered to thesame user).

In the following, a brief description of UMTS AKA is given, which is helpful to under-stand EAP-AKA. For basic information on UMTS AKA and its role in the UMTS securityarchitecture, [121, 122, 29] are recommended. In September 2005, the very comprehensiveanalysis [94] appeared. Security aspects and improvements are discussed in [166].

7The 3GPP (3rd Generation Partnership Project) is a collaboration agreement that was established in De-cember 1998 and that brings brings together a number of telecommunications standards bodies. Currently,these are ARIB, CCSA, ETSI, ATIS, TTA, and TTC. 3GPP’s original scope is to develop globally applicablespecifications for a 3rd Generation Mobile System based on evolved GSM core networks and the radio ac-cess technologies that they support, In addition, 3GPP is occupied with maintenance and development of theGlobal System for Mobile communication (GSM) Technical Specifications and Technical Reports includingevolved radio access technologies (e.g. General Packet Radio Service (GPRS) and Enhanced Data rates forGSM Evolution (EDGE)).

3.7 EAP-AKA 85

3.7.2 The UMTS AKA protocol

The involved parties in AKA are the Mobile Station (MS), the Visitor Location Regis-ter (VLR) and the Home Environment (HE) hosting the Home Location Register (HLR).Mobile Station and Home Location Register share a 128-bit secret key, K, which is subse-quently used for mutual authentication between Mobile Station and Home Location Regis-ter, and for derivation of an encryption key CK and an integrity protection key IK. The keyK is never transmitted directly over the air interface.

Next to the secret key, Mobile Station and Home Location Register have agreed on aset of cryptographic functions, for instance f1, a message authentication function used tocompute the MAC. In addition, the Home Location Register maintains a sequence counterfor each subscriber, and each subscriber maintains a sequence counter for his home network.

MS HLR

User authentication requestRAND(i), AUTN(i)

verify AUTN(i)compute RES(i) user authentication response

RES(i)

VLR/SGSN

Authentication data request

Authentication data responseAuthentication vectors AV(1..n)

Select AV(i)Store authentication vectors

Verify RES(i)==XRES(i) ?select CK(i) and IK(i)compute CK(i) and IK(i)

Figure 3.31: UMTS AKA authentication procedure

The AKA protocol is initiated by the Visitor Location Register, which sends an au-thentication data request to the Home Location Register. Upon receipt of this request, theHome Location Register generates n Authentication Vectors (AVs) and returns them to theVisitor Location Register. An Authentication Vector is a quintet and contains a randomvalue RAND, an expected user response XRES, a 128-bit cipher key CK, a 128-bit integritykey IK and a network authentication token AUTN. The Authentication Vector is the UMTSequivalent to the GSM triplet (RAND, XRES, CK). As can be seen, the AuthenticationVector contains two new elements, IK and AUTN.

With aid of the AUTN token, the network authenticates to the user. The AUTN value is


computed asAUTN = SQN⊕AK‖AMF‖MAC,

where SQN is the sequence counter, AK an anonymity key, and MAC a message authen-tication code over the random value and the sequence counter. AMF stands for ”Authentica-tion Management Field”, and serves to define operator-specific options in the authenticationprocess, like the use of multiple authentication algorithms or a limitation of the key lifetime.The MAC value is calculated as

MAC = f1(K;AMF‖SQN‖RAND).To run the AKA protocol with the subscriber’s USIM, the Visitor Location Register

sends the RAND and AUTN values to the user. The USIM verifies the AUTN component,computes the cipher and integrity keys CK and IK and generates the response RES, whichis delivered to the VLR. This response is compared to XRES, and if they are equal, the sub-scriber’s home network has successfully authenticated the subscriber. Finally, the MobileStation sends the previously derived CK and IK to the Visitor Location Register to protectsubsequent communication.


Figure 3.32 depicts the basic EAP-AKA message flow. It is assumed that the peer hasaccess to the subscriber’s USIM, where the shared secret key K is stored and where theactual AKA protocol is performed. It is assumed next that the EAP server has access to themobile network (more precisely, the Authentication Centre, which has as part of the cellularnetwork access to K).

(1) A← B : EAP-Request / Identity(2) A→ B : EAP-Response / Identity (user’s NAI)

(3) A← B : EAP-Request / AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)(4) A→ B : EAP-Response / AKA-Challenge (AT_RES, AT_MAC)


Figure 3.32: EAP-AKA message flow

Initially, an EAP-Identity exchange takes place. The identifier here is either the user’spermanent identity (i.e. the International Mobile Subscriber Identity (IMSI)), a pseudonymidentity, or a fast re-authentication identity. Since this exchange is optional, the EAP servercan alternatively request the subscriber’s identity in Message (3), indicated by a requestattribute. In this case, Message (4) would contain an AT_IDENTITY attribute.

Having received the subscriber’s identity, the EAP server requests from the Authenti-cation Centre one or more Authentication Vectors (RAND, AUTN, RES, CK, IK) for this

3.7 EAP-AKA 87

subscriber. According to the UMTS specification, the EAP server is allowed to receive mul-tiple AVs, to store them for subsequent AKA runs. One AV is valid for exactly one AKAauthentication8.

Indeed, EAP-AKA offers a very efficient mechanism for fast re-authentication whichdoes not make use of the AKA algorithms and does not request Authentication Vectorsfrom the Authentication Centre, but relies on the keys derived in the last full AKA authen-tication. The fast-reauthentication case is fairly complex, because it must deal with variousproblems that arise through the sequence counter-based approach. Therefore, it is not fur-ther discussed here.

The EAP server selects an Authentication Vector, extracts the random number RANDand the network authentication token AUTN, and sends them together with a message au-thentication code covering the whole EAP packet to the peer. The AUTN token containsnext to other elements a MAC keyed with K and computed over several values, includingRAND. The peer first verifies the authenticity of AUTN by computing the MAC itself andcomparing it to the received one. If the MAC can be verified, the peer is assured to talk tothe legitimate EAP server.

The peer, which has not yet revealed his identity, computes a response RES provingpossession of K and sends this value together with a MAC covering the EAP packet tothe EAP server. The EAP server then verifies the correctness of RES and the MAC. Asuccessful verification is signalized by issuing an EAP-Success packet.


At the end of the EAP-AKA protocol, the Master Key (MK) is computed according to

MK = SHA-1(id‖ IK‖CK),where id is the identity sent within the EAP-Response/Identity and CK and IK are the

cipher key and integrity key resulting from the AKA protocol. The MK serves to derivetransient EAP session keys (TEKs), MSK and EMSK.

Key derivation is based on the random number generation functions of NIST’s DigitalSignature Algorithm (DSA) [113, 114] which is depicted in Figure 3.33. The function Gused in the algorithm is constructed via the Secure Hash Standard [115]. G is very similar toSHA-1, in that it deviates only in message padding rules. However, for further informationon G’s design and the meaning of the parameters, the original specifications should bereferenced.

For EAP-AKA full authentication, the initial secret seed-key XKEY is assigned theMaster Key MK. Each iteration of the pseudorandom function yields 40 byte. Since EAP-AKA requires 160 byte keying material for one full authentication, the function DSS-prf+is invoked as DSS-prf+(MK, 160). The resulting 160 byte are divided into two 16-byteTEKs (Kencr and Kaut) to protect the EAP-AKA packets, and two 64-byte keys, the MSKand EMSK.

8Note the difference to EAP-SIM, where three GSM triplets are requested and required for one authentica-tion procedure, to obtain an adequate key strength.


DSS-prf+ (seed, outputlength){

m = doutputlength/40e;b = 160;XKEY = seed;t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0;

H0‖H1‖H2‖H3‖H4 = t; (initial value for SHS)

for j=1 to m{

w0 = G(t,XKEY mod 2b);XKEY = (1+XKEY+w0) mod 2b;w1 = G(t,XKEY mod 2b);XKEY = (1+XKEY+w1) mod 2b;xj = w0‖w1;

}return x1 ‖x2 ‖ · · · ‖xm

}

Figure 3.33: EAP-AKA key derivation function

Figure 3.34 summarizes the key derivation for EAP-AKA full authentication.

3.7.5 Comments

Certainly, the most remarkable property of EAP-AKA is that authentication is accomplishedwithin a single roundtrip only. In this regard, EAP-AKA distinguishes from all other EAPmethods, which thoroughly require two or more roundtrips (due to 3 messages or more).Consequently, this property makes EAP-AKA very attractive. Admittedly, EAP-AKA hasinherited this feature from the UMTS AKA protocol. And, this feature comes at the ex-pense of a sequence number-based replay-protection mechanism. Sequence number-basedauthentication is in general accomplished within fewer messages than nonce-based authen-tication. Informally, this becomes possible because the freshness value does not need to beexchanged during the authentication session, but is known already known on both sides -namely by means of the maintained sequence number.

In January 2006, EAP-AKA and EAP-SIM have been adopted as RFC. At present, theseboth methods are next to EAP-TLS the only ones specified in an RFC. To summarize, EAP-AKA seems to be particularly helpful for cellular network operators which wants to re-useexisiting authentication token (USIM) of their customers to allow them for WLAN-basednetwork access. The subscriber can access Internet services as well as internal services ofthe operator’s network, e.g. SMS or MMS. Section 4.3 will precise how 3GPP network

3.8 Further EAP methods 89

user identity

MK

DSS prf+

SHA−1

KautencrK MSK EMSK

16 byte16 byte 64 byte64 byte

IK CK

Figure 3.34: Key derivation for EAP-AKA full authentication

operators benefit from EAP in general and EAP-AKA in particular.

3.8 Further EAP methods

Clearly, not all EAP methods could be discussed in the scope of this thesis. Therefore, asubset had to be chosen in a reasonable manner. The remainder of this section will brieflyand informally discuss some of the remaining EAP methods, namely EAP-MD5, LEAP,PEAP, EAP-SIM, and finally the more recent proposals EAP-Double-TLS, EAP-SAKE andEAP-POTP.

EAP-MD5 is a very simple EAP method, which is the mandatory-to-implement mecha-nism of RFC 2284. When EAP was published in 1998, customers could basicallydecide between two EAP methods, EAP-MD5 and EAP-TLS. Although there wereother proposals at this time, these two EAP methods were broadly supported by im-plementations. EAP-MD5 is inherently insecure and all the more, it does not complywith RFC 3748.

LEAP (Lightweight EAP) or officially ”EAP-Cisco Wireless” is an early-stage EAP methodinvented by Cisco Systems. It worked fine for many years, until reverse-engineeringrevealed LEAP’s poor design which allows for a brute-force dictionary attack. As aconsequence, Cisco proposed EAP-FAST as a replacement for LEAP. LEAP does notcomply with RFC 3748 for various reasons, e.g. lack of key strength and WEP keygeneration instead of WPA/WPA2 key generation.


PEAP is very similar to EAP-TTLS. However, EAP-TTLS seems to be more widespreadin implementations, and enhances PEAP in that it allows for PAP and CHAP authen-tication within the TLS tunnel. Even if PEAP was long time favorized by customersdue to its native support in the Microsoft Windows operating system, the protocolseems not to be further developed.

EAP-SIM Like EAP-AKA which re-uses the UMTS network credentials, EAP-SIM makesuse of the GSM network authentication token, the SIM card located in the subscriber’sGSM device (e.g. cell phone). In contrast to UMTS AKA, the GSM authenticationprotocol is not strong enough to fulfil the requirements for an EAP method. AlthoughEAP-SIM has been modified accordingly to meet a key strength comparable to 128-bit symmetric strength, UMTS AKA appears to have better a prospective due to itsmore sophisticated design.

EAP-SAKE is a proposal by Flarion. According to the authors, it was already inventedin 2002, but became publicly available first in 2005. It is very similar to EAP-PSK,EAP-PAX and adopts many ideas of EAP-AKA. Since all these three mechanismsare described in this thesis, EAP-SAKE is omitted in the analysis.

EAP-Double-TLS is a variant of EAP-TLS and very similar to it, therefore left out in theanalysis.

EAP-POTP is a ”proprietary” EAP method of RSA Security Inc. Although its specifica-tion is public available, it primarily addresses the RSA SecurID R© token. EAP-POTPis mentioned here for the sake of completeness, namely to present an EAP methodwhich relies on a One-Time-Pad token.

3.8.1 EAP-MD5

EAP-MD5 is the mandatory-to-implement EAP method of RFC 2284, which is was main-tained by RFC 3748. Actually, it should have been called ”EAP-CHAP”, because it en-capsulates the Challenge Handshake Protocol (CHAP). While EAP-MD5 worked fine overwired LANs, it is thoroughly insecure when it is used in Wireless LAN or across the Inter-net. It performs only client to server authentication, it is vulnerable to brute-force dictionaryattacks and to replay attacks, and finally, it does not derive keying material.

The only benefit one might admit is that EAP-MD5 is very lightweight, in that it requiresonly two hash operations - one on client side, to compute a hash over the challenge and thepassword, and one on server-side to verify the client’s challenge response. Figure 3.35depicts the EAP-MD5 message flow.



(3) A← B : EAP-Request / MD5 Challenge(4) A→ B : EAP-Response / MD5 Challenge


Figure 3.35: EAP-MD5 message flow

3.8.2 EAP-Cisco Wireless

This EAP method is also referred to as ”LEAP”. LEAP is an invention of Cisco Systemsand was primarily implemented in Cisco wireless LAN products, for instance the Aironetseries. In the sequel, it was also implemented in third party products, e.g. Funk Software’sOdyssey Server. LEAP is a shared key EAP method and improves EAP-MD5 in that isoffers mutual authentication rather than user-to-network authentication only.


(3) A← B : EAP-Request / LEAP (8 byte challenge)(4) A→ B : EAP-Response / LEAP (24 byte response)


(6) A→ B : EAP-Response / LEAP (8 byte challenge)(7) A← B : EAP-Request / LEAP (24 byte response)

Figure 3.36: LEAP message flow

Although LEAP makes use of EAP frames to convey messages, it is not compliant withthe EAP specification, since LEAP does not conclude with an EAP-Success or EAP-Failure,but with a Request/Response exchange in which the network authenticates itself to the user.Also, the access point seems to modify packets in transit, instead of simply passing themto an Authentication server9. As stated in Section 2.4, an Authenticator compliant to EAPmay not modify packets.

LEAP uses a modified MS-CHAPv2 challenge response to mutually authenticate clientand server. Carried over insecure media such as Wireless LAN, the authentication message

9http://asleap.sourceforge.net/README


flow can be easily intercepted and introduces a brute-force dictionary attack on it ([164]).Briefly, if an attacker can record a successful authentication and the attacker’s dictionarytext file contains the user’s password, the password can be revealed. A proof-of-conceptimplementation to reveal weak LEAP passwords has been released by J. Wright, called”asleap” [163].

3.8.3 PEAP

PEAP is a joint proposal by Cisco Systems, Microsoft and RSA Security. The first versionappeared in August 2001 and was proposed by RSA Security with the title ”ProtectingEAP with TLS (EAP-TLS-EAP)”. In version 01 of October 2001, Microsoft and Ciscowere added as authors. From version 02 on, the protocol has been called ”Protected EAPProtocol (PEAP)”. In October 2003, version 07 was published, entitled with PEAPv2. InOctober 2004, the last draft update (version 10) appeared. Since it was not refreshed, thePEAP draft has been expired.

PEAP is very similar to EAP-TTLS in that it requires only a server-side certificate toestablish a TLS tunnel. Through this tunnel, client authentication can be securely take place.However, PEAP does not support legacy password-based authentication protocols, but onlyEAP methods inside the tunnel.

Basically, there are two versions of PEAP. Microsoft released PEAPv0 with EAP-MSCHAPv2 inside the tunnel, Cisco released PEAPv1 with EAP-GTC inside the tunnel.PEAPv0 is next to EAP-TLS natively supported in Microsoft Windows OS, and is veryfrequently used. PEAPv0 and PEAPv1 are widely available in implementations. PEAPv2seems to be abandoned by its authors. There are good reasons for this. Cisco focuses onEAP-FAST, Microsoft on EAP-TLS and PEAPv0, RSA Security possibly on EAP-POTP.And, if there is need for an EAP method like PEAP, the very similar EAP-TTLS can beused instead.

3.8.4 EAP-SIM

EAP-SIM is a proposal by Nokia and Cisco Systems. It re-uses the GSM Subscriber IdentityModule. The first version was proposed in February 2001. The most recent version 16 waspublished in December 2004. In January 2006, EAP-SIM has been published as RFC [67].The GSM AKA protocol is similar to the UMTS AKA protocol presented in Section 3.7.2.The difference is that GSM authentication yields only 64 bit security and performs onlyuser-to-network authentication, but no network-to-user authentication.

These deficiencies are pointed out in [129] and addressed by EAP-SIM as follows. Bysending two or three GSM triplets (Kc, RAND, XRES)10 rather than only one, EAP-SIMobtains stronger keying material. To achieve mutual authentication, the client sends a noncelike a challenge to the EAP server. The server computes a MAC over the client’s nonce

10These triplets are issued by the subscriber’s home network. They contain a 64-bit cipher key Kc, a 128-bit challenge RAND and the expected response XRES. When the subscriber receives RAND, he computesA3(RAND,Ki) - where Ki is the 128-bit subscriber’s secret key stored on the SIM - and sends the result back.


and the RAND and Kc values of the GSM triplets. By returning this MAC, the serverauthentiates himself to the client. That is, the security of EAP-SIM fully relies on theknowledge of the GSM triplets.

EAP-SIM also offers optional support for protecting the privacy of the subscriber’s iden-tity in a similar manner as GSM, namely by pseudonyms and/or temporary identifiers. Italso specifies an optional fast re-authentication procedure.

3.8.5 EAP-Double-TLS

EAP-Double-TLS is a proposal by ENST Paris. The first version was published in May2004, the current version is 04 and appeared in October 2005 [20]. The main goal ofEAP-Double-TLS is to extend EAP-TLS by pre-shared key based authentication. EAP-Double-TLS consists of two phases. The first relies on the TLS abbreviated handshake andperforms pre-shared key based mutual authentication. This is accomplished by setting themaster secret equal to the pre-shared key. The second phase is optional. It can be a full TLShandshake, an anonymous Diffie-Hellman key exchange or an exchange of Attribute-Value-Pairs. The second phase can be used for various purposes, like re-negotiation of securityparameters or update of the pre-shared key. The author of EAP-Double-TLS has merged hisproposal with other proposals into the PSK-based TLS ciphersuites RFC (RFC 4279 [52]).

3.8.6 EAP-SAKE

EAP-SAKE is an EAP method developed by Flarion Technologies in 2002 and first timepublished in the IETF in August 2005 under the name EAP-MAKE. Due to name spacecollisions with Sagem’s EAP-MAKE (EAP type number 14), the draft was renamed toEAP-MAKE2, finally to EAP-SAKE, where SAKE stands for ”Shared-secret Authentica-tion and Key Establishment”. EAP-SAKE relies on a 32-byte pre-shared key and performsmutual authentication in two roundtrips with a protocol similar to AKEP2 [21]. The authorsdesigned EAP-SAKE having subscription-based public access networks, e.g. cellular net-works, in mind. At present, EAP-SAKE has passed the EAP expert review process and iswaiting in the RFC editor queue.

3.8.7 EAP-POTP

EAP-POTP is a proposal by RSA Security. The first version was published in February2005, the current version 05 appeared in December 2005. EAP-POTP is an EAP methodsuitable for use with One-Time Password (OTP) tokens. Although its design is kept inde-pendent of particular OTP devices and algorithms, RSA primarily intends to offer supportfor the RSA SecurID R© token. The token continuously generates and displays a 6-8 digitcode every few seconds. Whenever a user wants to log in, he has to enter his long-term PIN(typically 4-digit long) followed by the currently displayed number by the SecurID R© token.

The basic variant of EAP-POTP provides client authentication only. A more advancedvariant provides mutual authentication, integrity protection of the exchange, protection


against eavesdroppers, and establishment of authenticated keying material. Both variantsallow for fast session resumption.

Chapter 4

EAP for Network AccessAuthentication

Originally, EAP has been developed to enhance authentication capabilities within PPP. Until2000, the interest in EAP was rather limited. In 2000, the situation changed dramatically.WEP was thoroughly shown to be insecure. The IEEE looked for a successor of WEP, andchose the 802.1X framework, which itself strongly relies on EAP.

At this point, EAP had been mainly used for wired networks and it became obvious thatEAP had to be revised thoroughly to be applicable in shared media networks like 802.11Wireless LAN. Step by step, the requirement catalogue grew and was finally adopted inJune 2004 as RFC 4017. In the meantime, however, various other protocols have decidedto use EAP. It is also deployed in applications beyond network access authentication.

MAN

WAN

LAN

PAN

IEEE 802.20

ETSI

ETSIIEEE 802.15Bluetooth HiperPAN

HiperLAN

ETSIHiperMAN

IEEE 802.11Wireless LAN

Wireless MANIEEE 802.16

3GPP EDGEGSM

3GPPUMTS

cdma2000

Figure 4.1: Network families

95

96 EAP for Network Access Authentication

The main purpose of this section is, however, to elaborate how EAP is used in thescope of network access authentication. Therefore, the thesis will look a three popularapplications, which are highlighted in Figure 4.1.

Initially, it is shown how IEEE 802.11 Wireless LAN adopts EAP. Next, the usage ofEAP in IEEE 802.16 Wireless MAN (better known as WiMAX) will be discussed. EAP isaccrued from the mobility amendment 802.16e. Finally, the usage of EAP in 3G networkswill be described. 3G networks can be efficiently combined with WLAN, as both technolo-gies complement one another. In this context, the interworking of UMTS and IEEE 802.11is mainly considered, because its 802.1X-based authentication is the reason that EAP canbe found in some functions of the 3G network.

4.1 EAP in IEEE 802.11 Wireless LAN

Wireless LANs based on the IEEE 802.11 Standard are widely deployed nowadays. Whilethe original specification of 1999 offers only very weak security mechanisms, which havebeen broken thorougly within two years, a revised specification was released in mid 2004,called IEEE 802.11i [81]. The newly introduced mechanisms allow to block unauthenti-cated and thus unauthorized devices already at the edge of the network, namely in WLANaccess points, and prevents them to get access to offered services. This is accomplished byIEEE 802.1X, which in turn makes use of EAP.

The original 802.11 security architecture suffers from many weaknesses and flaws. Es-pecially the mechanisms for network access authentication turned out to be impractible. Allinformation that an attacker needs to authenticate himself to the network, are transmittedover the air interface and are consequently easy to obtain. In light of the huge gap betweenthe weakness of the original mechanisms of IEEE 802.11 and the improved security mecha-nisms introduced by IEEE 802.11i, the thesis will focus on both. Finally, the improvementsof the 802.1X-based approach over WEP are pointed out. To achieve better readability, anabbreviated notation is used, e.g. 802.11 instead IEEE 802.11 Wireless LAN.

4.1.1 History of the 802.11 Standard

The first version of the IEEE 802.11 Standard has been published in 1999 and offers datarates of up to 2 MBit/sec [78]. It is commonly denoted with 802.11-1999. In the same year,802.11b has been proposed with data transfer rates of 11 MBit/sec. The 802.11g amend-ment released in 2003 specifies changes to the physical layer that allow up to 54 MBit/sec.However, the security mechanisms have remained the same. In 2000 and 2001, researchersidentified numerous shortcomings and flaws. In particular, the immature design of WEP(Wired Equivalent Protocol) introduced many attacks. As a consequence, IEEE charged802.11 Task Group e (TGe1) with the development of improved security mechanisms. Forsome time, this improvement was called WEP2.

1Originally, 802.11 TGe was responsible for both Quality-and-Service and Security. In 2001, a new TaskGroup “i” has been founded to exclusively deal with security.

4.1 EAP in IEEE 802.11 Wireless LAN 97

Originally, there were two proposals that met 802.11 TGe requirements on a successorof WEP. The one was jointly proposed by Intel and Symbol and relies on the Generic Secu-rity Services Applications Programming Interface (GSS-API), and Kerberos as mandatory-to-implement GSS-API mechanism. The motivation was to create a simple proposal withoutre-inventing the wheel. For this reason, the widely deployed and well-understood Kerberossecurity service was chosen.

The other proposal was jointly developed by Microsoft and Cisco and relies on 802.1X,which in turn makes use of EAP. In fact, the usage of 802.1X was already suggested in early2000 [150], while the adoption of EAP was stated afterwards [62]. The flexibility, modu-larity and extensibility are mentioned as main advantages of this proposal. And indeed, theframework can be easily extended by additional authentication mechanisms without needto make changes on the infrastructure. In November 2000, 802.11 TGe declared to useKerberos v5 for authentication and fast handoff, and 802.1X and EAP for authenticationpurposes [63]. This framework was designed to work with a Kerberos Key DistributionCenter as well as with a RADIUS Authentication server. In May 2001, however, this con-cept was withdrawn and all Kerberos-related parts were removed.

In 2001, the Wi-Fi Alliance2 released a subset of 802.11i, called WPA (Wi-Fi ProtectedAccess). WPA is only an intermediate solution and should mitigate the known weaknessesof WEP, while being fully compatible with fielded hardware. WPA comprises the TemporalKey Integrity Protocol (TKIP) with a Message Integrity Code called ”Michael”, and 802.1Xfor improved access control.

In June 2004, IEEE has ratified the security amendment 802.11i as IEEE Standard.The new security architecture is called Robust Security Network (RSN). It allows only thecreation of robust security network associations (RSNAs). However, Robust Security isonly achieved if all devices in the network use RSNAs. RSN algorithms comprise TKIP,CCMP, 802.1X-based authentication, and improved key management procedures. To facil-itate smooth migration to RSN mechanisms, 802.11i still allows use of 802.11’s deprecatedsecurity mechanisms, called pre-RSNA algorithms. They comprise 802.11 Open Authenti-cation, Shared Key Authentication and the WEP algorithm.

CCMP stands for ”Counter Mode with Cipher Block Chaining Message AuthenticationCode Protocol”. It relies on AES, while it combines the counter mode for confidentialityand the CBC-MAC for data origin authentication. CCMP uses AES with a 128-bit keyand 128-bit block size. Note that CCMP uses the same key for encryption and data originauthentication. Furthermore, WEP’s 24-bit initialization vector has been replaced by a 48-bit sequence number (the packet number; PN).

Regarding authentication, the 802.11i amendment specifies two authentication methods.They are denoted with WPA PSK authentication and IEEE 802.1X EAP authentication,while the Wi-Fi Alliance prefers the terms ”WPA2 Personal” and ”WPA2 Enterprise”.3 In

2WiFi Alliance was founded in 2000 to certify interoperability of Wi-Fi (IEEE 802.11, and recently 802.11i)products and to promote the Wi-Fi technology as global standard across all market segments. Wi-Fi is a trade-mark of Wi-Fi alliance and refers to all certified networking products. UAM, WPA, WPA2 are trademarks ofWi-Fi alliance (and not of IEEE, as sometimes supposed).

3There exist also the terms WPA Personal and WPA Enterprise. They denote the authentication modes of


Wi-Fi Alliance’ terminology, WPA2 stands for the final, strong security mechanisms of the802.11i Standard. To avoid confusion, the notation WPA2 Personal and WPA2 Enterpriseis used to distinguish between the two authentication methods.

4.1.2 Legacy 802.11 authentication mechanisms

4.1.2.1 Shared Key Authentication

WEP intends to offer Wired Equivalent Privacy, that is to offer security level equivalent towired networks. Next to the original goal of providing confidentiality, WEP is also used fornetwork access authentication purposes. More precisely, 802.11 defines two authenticationmethods, 802.11 Open System Authentication and 802.11 Shared Key Authentication.

In case of 802.11 Open System Authentication, the access point permits any willingclient station to join the network. Shared Key Authentication, in contrast, lets the clientproof possession of a pre-shared key. Although it relies on the WEP engine, its usage doesnot require the use of the WEP privacy mechanism. To better understand how Shared KeyAuthentication works and what are its weaknesses, the WEP encryption and decryption willbe briefly faced.

The fist step in the WEP encryption process is that a CRC32 checksum is computed overthe plaintext. This checksum is called ”Integrity Check Value” (ICV). Plaintext and ICV arethen concatenated and encrypted with a key stream produced by a RC4 key pseudorandomstream generator. This function has as input the 40- or 104 bit WEP key k and a 24-bitInitialization Vector, which is implemented as sequence counter. Encryption is implementedas Exclusive OR (XOR). Then, IV and ciphertext are transmitted. The encryption processis shown in Figure 4.2.

The receiver uses the received IV to generate the key stream RC4(k,IV), which isXORed with the ciphertext. This process returns the plaintext and the 32-bit ICV. Thereceiver then computes the CRC32 checksum over the plaintext and compares it to the ICV.If they are equal, the decryption of the payload was successful and the authenticity of thesender is assumed.

In case of 802.11 Shared Key Authentication, the access point generates a 128-bytechallenge RAND and sends it to the client station, which in turn chooses a 24-bit initializa-tion vector IV and WEP-encrypts the challenge under the secret WEP key k. The 802.11Standard suggests to generate also the challenge with aid of the RC4 keystream generator.The encrypted challenge is returned to the authenticator, which decrypts it and verifies thechecksum. If the checksum is correct and the original challenge results, the client stationhas successfully authenticated to the access point.

Shared key Authentication bears some problems. On the one hand, eavesdropping of asuccessful shared key authentication yields a 128-byte plaintext with its corresponding ci-phertext computed under a certain Initialization Vector. This can itself be exploited. On theother hand, XORing the plaintext and the ciphertext returns a valid key stream RC4(k,IV).

WPA. These two modes use only TKIP. Although WPA Enterprise makes use of IEEE 802.1X and EAP, theauthentication procedure yields only WEP keying material, which is different from RSN keying material.


InitializationVector

RC4PRNGWEP Key k

XOR

||

CRC||

Plaintext

pad

initializationvector

keyidentifier

Cipher−text

ICV

IV Data>= 1 byte

ICV4 byte4 byte

Key ID2 bit

Pad6 bit

Initialization Vector24 bit

encrypted

Figure 4.2: WEP encryption process and WEP-encrypted frame

Since the user and not the Authenticator chooses the Initialization Vector, the attacker sim-ply re-uses this Initialization Vector by applying the gathered key stream to the receivedchallenge.

A correct checksum (ICV) is computed according to the attack presented in [30]. As aconsequence, the authenticator will recognize the result as valid. As said before, Shared KeyAuthentication can be used without WEP. The access point allows the attacker to join thenetwork and to access its services or to use its resources. Otherwise, WEP-related attacks[143, 54] can be applied to reveal the secret WEP key.

Obviously, the original IEEE 802.11 Standard does not offer strong authentication mech-anisms. In case of Open Authentication, basically no authentication occurs, in case ofShared Key Authentication, a very weak WEP-based challenge-response protocol is used.A vast amount of literature about 802.11 security exists, which should be referenced formore detailed information. For an overview of security issues in IEEE 802.11, the sur-vey papers [33] and [16] are particularly recommended. The original research papers[14, 15, 30, 54, 143] are also worth reading.


User

(Auth, "Shared Key", SeqNr=1)Management Frame

User

Management Frame (Auth, "Shared Key",SeqNr=2, Challenge=RAND)

Management Frame (Auth, "Shared Key",SeqNr=4, Authentication Result)

(Auth, "Open System", SeqNr=2)Management Frame,

(Auth, "Open System", SeqNr=1)Management Frame

Authen− ticator

Management Frame (Auth, "Shared Key",SeqNr3, Response = RAND XOR RC4(k,IV)

Authen− ticator

Figure 4.3: 802.11 Open System and Shared Key Authentication

4.1.2.2 Universal Access Method

UAM, short for Universal Access Method, is a browser-based network access authenticationmethod developed by Wi-Fi Alliance [159]. The central component in the UAM architectureis a proxy which filters IP traffic of unauthenticated users, identified by the MAC address ofthe network adapter. The Wi-Fi Alliance has specified UAM as recommended authentiationmethod for public access networks, e.g. those maintained by Wireless Internet ServiceProviders or hotspot operators. Indeed, most current hotspot deployments rely on UAM foruser authentication.

The main goal of UAM is to facilitate compatibility with legacy Wi-Fi products. UAMposes only minimal requirements on user and system capabilities. A web browser and aTCP/IP capable network adapter are sufficient. The user gains network access by enteringhis username and password into a login website. In case of successful authentication, theproxy unlocks the corresponding MAC address and allows the device for passing arbitraryIP traffic.

Despite these favorable features, UAM is vulnerable to a variety of attacks, and canbe summarized to be inherently insecure. Of course, this has been widely recognized, andthe Wi-Fi Alliance recommends to replace UAM by 802.11i-based security mechanisms,described in Section 4.1.3, which provide end-to-end security instead. It is impressive to seehow these mechanisms significantly improve UAM’s weak mechanisms. As next, UAM’slogin procedure is surveyed, then UAM’s shortcomings are exposed.

Protocol overview

Figure 4.4 illustrates the message flow of an UAM login process. For simplicity, the loginis assumed to be successful.

The user selects the correct network by means of its SSID and associates to this networkthrough 802.11 Open Authentication. As a consequence, the user’s device is assigned anIP address via DHCP. The user has then to open a web browser and to enter an URL. The


GET http://www.example.com

REDIRECT http://www.example.com

User AP / AAA

usage of subscribed services

user associates andauthenticates to thenetwork, then receivesan IP address via DHCP

HTTP−Request

HTTP−ResponseREDIRECT https://proxy/login.html

HTTP−Request POST (username, password)

HTTP−Response

proxy sends its certificate, TLS−securedHTTP connection established

authenticated?Is MAC address

RADIUS Access−Challenge (CHAP−Challenge)

RADIUS Access−Request(CHAP−Password)

RADIUS Access−Accept ()

RADIUS Access−Request (username)

Proxy Server

802.11 Open Authentiation

802.11 Association

DHCP

Figure 4.4: Universal Access Method

proxy checks if the user has already authenticated. If this has not yet happened, the originalHTTP GET request of the browser is redirected to the login website.

This HTTP session is TLS-protected. Typically, a portal website is presented with apossibility to enter and submit an username and a password. Next to the login form, theportal website usually also offers subscription-free services and a possibility for new usersto sign up. The proxy then verifies the entered credentials by sending the username to thebackend AAA server, which returns a CHAP-Challenge attribute. As the proxy knows thepassword, it computes the CHAP-Password (response) and sends it back to the AAA server.

On successful authentication, the MAC address and the corresponding IP address areunlocked and the user is allowed to access his subscribed services. For convenience, theaccess point will finish the authentication by redirecting the user’s browser to the originallyrequested URL. Termination of the session could be implemented by means of the idle time,


together with a browser window, which allows for manual termination of the session.

Shortcomings and Weaknesses

UAM offers very poor security mechanisms. Due to the numerous vulnerabilities, UAM’spromises of authentication and access control turn out to be meaningless. Even the factthat the user has to start his web browser and to enter an arbitrary URL in order to performnetwork authentication, requires that the user must have some knowledge of UAM. This canbe seen as a disadvantage.

Recall how UAM accomplishes user authentication. The user establishes a secure HTTPconnection with the proxy. Through this protected tunnel, the user transmits his usernameand password to the proxy. If the authentication was successful, the MAC address of theuser’s network adapter is unblocked. And indeed, UAM performs only user authenticationand device authorization, but no key derivation. That is, all traffic is sent unencrypted andunauthenticated.

If privacy is a concern, the user can establish a VPN tunnel through the proxy to thehome network (based on PPTP [65] or IPsec) and sends all traffic through this tunnel. Avery common choice is PPTP or PPTPv2 for tunnel setup and MS-CHAPv2 for transmissionof username and password. Another problem arises in the context of roaming. When a userconnects to an access point of a roaming partner, the user’s credentials are exposed to theforeign network, which forwards them to the home network. It is possible that the usercredentials could be tampered with by a malicious hotspot operator.

The attacks on UAM tend to hijack the user’s session, to reveal the user’s credentialsand to gain access the user’s device.

Session-related attacks: These attacks have hijacking of an authenticated user session inmind. The attacker observes the traffic for an authenticated session and determinesthe corresponding MAC address. If the user logs off, the attacker assigns the capturedMAC address to his own adapter and thus can continue the session. It is also possiblethat the attacker concurrently uses the authenticated session. Therefore, he assignshis own adapter the user’s MAC address and restricts the use of higher ports to accessservices. The goal is that both user and attacker operate in their own port range toavoid collisions. Regardless of the details, the compromised user may not becomeaware of the concurrent access.

User credential-related attacks: These attacks target to get knowledge of the user’s cre-dentials, that is, his username and password. The security of UAM depends on theuser’s ability to verify the server’s certificate, which is presented to him during theestablishment of the TLS-secured HTTP session. At this point, the user has typicallynot yet access to the internet. In case that the user receives a certificate with a signa-ture of an unknown CA, he has two possible choices. Either he accepts the certificateas-is and hopes that the subscribed services are available after the network logon hasfinished, or he cancels the procedure. Experience has shown that users try the firstmore likely. Short, an attacker could exploit this threat in that he installs rogue access


points and let subscribers connect to them instead to the legitimate access point.

This attack is not difficult to put into practice. It suffices to broadcast the same SSID,to present an identical login website, and to offer equivalent services. As mentionedabove, the offered service typically limits to providing internet access. Or, the rogueaccess point acts as man-in-the-middle and relays all traffic to the original accesspoint. The attacker then basically has two possibilities how to deal with the capturedtraffic. Either he restricts to relaying and filtering without modification, with the goalto reveal user credentials, or he modifies the traffic.

Device-related attacks: The problem with rogue access points is addressed by sendingall traffic through an VPN tunnel. The service provider typically provides guidanceregarding setup and configuration of such a VPN4. The authentication does not ter-minate at the access point, but in the home network. This makes exposure of usercredentials difficult, so that it might be simpler for an attacker to attack the user’smachine directly with the goal to obtain access to it. Typically, the attacker installs abackdoor entry on the machine.

Certainly, this catalogue of attacks is not comprehensive. However, due to this variety ofattacks on UAM, the Wi-Fi Alliance intends to replace UAM authentication by the moresecure WPA-based authentication. The bottom line of Section 4.1.2 is, that both WEP andUAM provide only inadequate protection and that there is tremendous need for a replace-ment.

4.1.3 802.11i Authentication mechanisms

As mentioned before, 802.11i specifies two authentiation methods, WPA2 Personal andWPA2 Enterprise.

WPA2 Personal does not rely on an Authentication server and allows for a very simpleshared secret based authentication. In contrast to this, WPA2 Enterprise requires a back-end Authentication server. The underlying AAA protocol is not mandated. It can be, forinstance, Diameter or RADIUS. Since RADIUS is more widespread, the thesis assumesRADIUS as AAA protocol. The AAA server has stored all user authentication credentialsor has at least a possibility to get access to them, and performs mutual authentication withthe user.

Consequently, two different network models result, which will first be presented. There-after, WPA2 Personal and WPA2 Enterprise will be discussed with main focus on WPA2Enterprise. Since this mode makes use of IEEE 802.1X, which in turn makes use of EAP,it seems helpful to outline the basic ideas behind IEEE 802.1X first. Having given a solidbackground, the thesis proceeds with the description of the 802.1X-based RSNA establish-ment procedure.

4Unfortunately, the vast majority of providers supports only Microsoft Windows operating system.


4.1.3.1 WPA2 Personal

WPA2 Personal performs mutual authentication between client station and access pointbased on a pre-shared key.5 IEEE has specified this mode in addition to WPA2 Enterpriseto allow RSNA establishment in scenarios without AAA infrastructure. This mode hasparticularly small offices and home deployments in mind.

The pre-shared key PSK is 32 byte long, and is exactly the Pairwise Master Key (PMK;see Figure 4.9). In practise, this key is usually derived6 from a passphrase 8 to 63 characterslong, by means of

PSK = PBKDF2 (passphrase, ssid || ssidLength, 4096, 256)

where PBKDF2 is part of the Password-based Cryptography Standard (PKCS#5 version2), specified in RFC 2898 [90]. In this formula, ssid denotes the Service Set Identifier(SSID) of the network where the passphrase is in use, and ssidLength denotes the lengthof the ssid in byte. Their concatenation is used in PBKDF2 as seed. The values 4096and 256 indicate that the pseudorandom function is applied 4096 times on each processedblock, which are finally concatenated. The last parameter of PBKDF2 stands for the outputlength (in bit). Without going too much into details, the result of PBKDF2 is basicallya concatenation of HMAC-SHA1 values keyed with the passphrase, where each 20-byteblock is iteratively XORed by the number of given iterations.

The conversion formula is not very sophisticated and in fact, it bears the risk of a suc-cessful offline dictionary attack if the passphrase is chosen poorly. Therefore, implemen-tations have to take care of the quality of the entered passphrase and, if needed, to ask theuser to enter a stronger one. If an attacker has found the passphrase and thus is aware ofthe corresponding pre-shared key, the whole 802.11i keying hierarchy and consequently allassociations of the network which are established under that pre-shared key are under hiscontrol.

First it can be observed that the PMK is the same for all clients and for all networkauthentications. Freshness is introduced during the subsequent 4-Way Handshake by meansof an exchange of nonces. In this handshake, the Pairwise Transient Key (PTK) is derivedfrom the PMK and other values. Unfortunately, all other parameters can be obtained bysimple eavesdropping ([81], Section 8.5.1.2). Due to the limited entropy of the ASCII-based passphrase, the security strength of the passphrase is estimated to as 2.5n+12, wheren denotes the number of characters ([81], Section H.4.1).

To achieve 128-bit symmetric key strength, one would thus require a passphrase 47characters long. [110] suggests a length of at least 20 characters. Further informations onthe weakness of WPA passphrase mode can be found in [110] and [103]. In addition, two

5Actually, the IEEE Standard allows for a different pre-shared key per each client station. However, mostvendors have restricted the configuration capabilities for only one pre-shared key per ESS. In this regard, WPA2Personal is no improvement over WEP, since the PSK is the same for all users and its detection leads to com-promise of the whole network.

6The 802.11i amendment invokes PBKDF2 incorrectly, namely with five arguments: Section H4.1 says PSK= PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256).


open-source projects exist that exploit the WPA passphrase weakness, namely coWPAtty[162] and WPA Cracker [144].

4.1.3.2 WPA2 Enterprise

The 802.1X-based RNSA establishment consists of two main parts, namely 802.1X authen-tication and execution of subsequent key management protocols. The 802.1X authenticationplays an important role, because it discards non-authenticated user traffic already at the edgeof the network, i.e. at the access point. In the following, the thesis briefly describes how the802.1X network access control mechanism works, and how 802.11 makes use of 802.1X.Thereafter, the whole 802.1X-based RSNA establishment procedure is presented, with thegoal to see how EAP is embedded in this procedure.

802.11 Network Modes revisited

The 802.11i Standard specifies four different RSNA establishment procedures ([81], Section8.1.3), namely WPA2 Personal and WPA2 Enterprise in an ESS and IBSS network. Recallthe difference between ESS and IBSS. The basic building block of an 802.11 LAN is theso called ”Basic Service Set” (BSS). It contains either two client stations or a client stationand an access point.

STAAPLAN

Client StationAccess PointLocal Area Network

BSSIBSS

DS

Basic Service SetIndependent BSSExtended Service SetESSDistribution System

ESSIBSS

STA

BSS

BSS

LAN

DS

BSS

BSS

AP

Figure 4.5: 802.11 network modes

The left picture of Figure 4.5 depicts two Basic Service Sets. Together, they form anIndependent BSS (IBSS). The right picture of Figure 4.5 shows an Extended Service Set


(ESS). ESS and IBSS distinguish themselves in that their BSSs do not consist of two clientstations, but of one client station and an access point. The access point is located in theDistribution System (DS).

802.1X-based RSNA establishment in an IBSS is performed in that each station uses802.1X to authenticate with the Authentication Server associated with the other client sta-tion’s Authenticator. Hence two 802.1X/EAP authentications are performed concurrently.Nevertheless, even if the 802.11i would allow for WPA2 Enterprise in both IBSS and ESS,only an ESS seems to have the suitable network architecture for a 802.1X/EAP-based au-thentication. Therefore, the thesis will assume an ESS as underlying network type.

Overview about IEEE 802.1X

IEEE 802.1X is an IEEE Standard for Port-based Network Access Control. It belongs to the802.1 family, which is entitled ”LAN/MAN Bridging & Management”. Its first version hasbeen published in 2001. In order to work properly in shared media LANs, like the Internetor Wireless LAN, IEEE revised it thoroughly and published the second version in November2004, also known as 802.1X-2004 [74]. Although 802.1X is designed to be applicable tothe whole IEEE 802 network protocol family, it gained certainly most popularity throughits adoption in IEEE 802.11i.

IEEE 802.1X defines three parties, known as Supplicant, Authenticator and Authenti-cation Server.

Supplicant The Supplicant is the client station that wants to be authenticated. In orderto participate in the network, the Supplicant initiates an 802.1X authentication withthe Authenticator. This is achieved by sending an EAPOL-Start frame to a broadcastaddress reserved for Authenticators.

Authenticator The Authenticator is an 802.1X-capable network node, which is located atthe edge of the network and controls access to it. Depending on the authorizationstatus, a Supplicant is allowed to use the offered services. If a client has not yetbeen authenticated, all traffic except authentication requests is discarded. Hence, theAuthenticator acts as intermediate proxy, in that it simply relays all authentication-related traffic between Supplicant and Authentication Server. The advantage is thatthe Authenticator does not need to implement any authentication methods - this is leftto the Supplicant and Authentiation Server.

Authentication Server The Authentication Server is a backend AAA server which pro-vides an authentication service to the Authenticator. The protocol is not stipulated,but RADIUS and Diameter seems to be the most suitable ones. During an 802.1Xauthentication, Supplicant and Authentication Server mutually authenticates. There-fore, the Authentication Server must have stored the user’s credentials or must haveat least access to them.

A central component in the 802.1X framework is the Network Access Port. This is a pointof attachment to the network, which can be a physical connection or an association to a


wireless network. For each Supplicant, the Authenticator maintains a PAE (Port AccessEntity), which is implemented as a process that handles authentication requests associatedwith a port. An Authenticator PAE consists of two logical ports, the Controlled Port and theUncontrolled Port.

Controlled Port

Authenticator PAE

Uncontrolled Port

LAN

Controlled Port

Authenticator PAE

Uncontrolled Port

LAN

PortUnauthorized

PortAuthorized

Figure 4.6: IEEE 802.1X Port-based Network Access Control

The Uncontrolled Port is used for exchange of authentication-related traffic, which isalways allowed to pass. This traffic is then relayed to the Authentication Server. The Con-trolled Port can enter two states, authorized and unauthorized. Its default state is unautho-rized, i.e. blocked from passing general data traffic between Supplicant and Authenticator.The port’s state changes to authorized, when an 802.1X authentication has been carried outover the Uncontrolled Port and finished successfully.

Once the client has been successfully authenticated, the Controlled Port becomes au-thorized, i.e. unblocked and will allow general traffic to pass. This traffic will be protectedunder the initially negotiated RSNA ciphersuite (CCMP or TKIP), whose keys are derivedfrom the EAP method’s MSK. The Authentication Server transmits the AAA-Key, whichis the first 32 byte of the MSK, in EAPOL-Key frames to the Authenticator. From thismoment, the Authenticator is responsible for securing the data traffic exchange.

The 802.1X three-party network model matches perfectly the EAP three-party networkmodel. So the mapping is straightforward. The EAP peer corresponds to the Supplicant,the Authenticator remains the same, and the EAP Server corresponds to the AuthenticationServer. In 802.11 networks, the client station is the Supplicant, the Authenticator the accesspoint, and the Authentication Server the backend AAA server.

Next to the Controlled/Uncontrolled Port model, 802.1X specifies its own encryptionmechanisms for delivering keying information. This becomes necessary because 802.1X isdesigned also for purposes beyond 802.11, and therefore it must be independent of specificalgorithms such as WEP, TKIP or CCMP. 802.1X defines EAPOL-Key frames for securelytransport of keying material and EAPOL-EAP frames for encapsulation of EAP frames (see


client station

EAP over

802.1x

access point

Supplicant Authenticator

EAP over

RADIUS /Diameter

backend AAA server

ServerAuthentication

Figure 4.7: WPA2 Enterprise Network Model

also Section 2.8.1).To summarize, WPA2 Enterprise performs

• user-based authentication between wireless client and EAP server

while the access point simply relays authentication-related traffic. This is different to WPA2Personal, which performs

• device-based authentication between wireless client and access point

In both cases, authentication is mutual, not unilateral. IEEE 802.16e (WiMAX), for in-stance, supports initial device authorization followed by user authentication. The differenceto 802.11 is that each hardware device is equipped with a certificate which allows for itssecure identification.

WPA2 Enterprise RSNA Establishment

A client station discovers the Authenticator’s security policy by interpreting an RSNA in-formation element (RSN IE), which occurs in Beacon, Probe Response, Association andReassociation Request frames as well as in the second and third message of the 4-WayHandshake. The client station usually gathers an RSNIE through passively monitoring aBeacon frame, or through active probing.

VersionLengthGroupCipherSuite

PairwiseCipherSuite

PairwiseCiphersuiteList

AKMSuite Count

1 byte1 byte 2 byte 2 byte 2 byte 2 byte

AKM Suite List

Element ID

RSNCountPMKID PMKID

List

2 byte4 byte 4m byte 4n byte 16s byte

Capabilities

Figure 4.8: RSN Information Element


An RSN Information Element is composed as shown in Figure 4.8. The RSNIE containsauthentication and pairwise cipher suite selectors, a single group cipher suite selector, anRSN Capabilities field, the PMK identifier (PMKID) count, and a PMKID list. Due tothe three list fields, the RSNIE’s size is variable, but may not exceed 255 byte. The exactmeaning of each field can be found in [81], Section 7.3.2.25. In this scope, only the fieldAKM Suite List is of relevance.

Each AKM suite selector specifies an Authentication and Key Management Protocol(AKMP). Three byte prefix 00 0F AC are followed by one byte, which determines thesuite type. Currently, two suite types are specified, namely 01 for 802.1X-based authen-tication, which is also RSNA default setting, and 02 for WPA-PSK-based authentication.For illustrative purposes, a sample RSNIE is presented. Its capabilities are 802.1X authen-tication, CCMP as pairwise cipher suite and CCMP as group cipher suite, while WEP-40,WEP-104 and TKIP are not allowed. In addition, the RSNIE gives a hint that 802.1X pre-authentication is supported (see Section 4.1.3.4).

30 information element id (constant), 48 expressed as Hex value14 length in octets, 20 expressed as Hex value01 00 RSN version 1 (constant)00 0F AC 04 CCMP as group cipher suite01 00 pairwise cipher suite count00 0F AC 04 CCMP as pairwise cipher suite01 00 authentication count00 0F AC 01 802.1X authentication01 00 pre-authentication capabilities

If 802.1X authentication is negotiated, the EAP authentication process is triggered offby either the Supplicant (i.e. wireless client) which sends an EAPOL-Start message or bythe Authenticator (i.e. access point) which sends an EAP-Request message. This mightbe either an EAP-Request/Identity message or the first EAP-Request of the chosen EAPmethod.

As shown in Figure 4.9, which follows [68], EAP-based authentication occurs afternetwork association (with Open System Authentication) and before the 4-Way Handshakeand Group Key Handshake. The handshake messages are encapsulated in EAPOL-Keyframes and are therefore cryptographically protected.

The highest order key in the IEEE 802.11i key hierarchy is the PMK. It is derived eitherfrom an EAP method’s MSK or directly from a pre-shared key, which is the case for WPA2Personal. The goal of the 4-Way Handshake is to confirm possession of the Pairwise MasterKey (PMK), to generate the Pairwise Transient Key (PTK) as a fresh session key for datatransmission and to assure that PTK is fresh and derived from the PMK7. In case of TKIP,the PTK is 512 bit long, as TKIP requires two keys, one for Michael, one for RC4. In caseof CCMP, the PTK is 384 bit long, which is divided into a 128-bit EAPOL encryption key, a

7The term ’pairwise’ means that the keys are shared only between the two entities in a pairwise association.In case of an ESS, these entities are the access point and the station. In case of an IBSS, the entities are twostations.


and AssociationAuthentication802.11 Stage 2:

Stage 1:Network andSecurity CapabilityDiscovery

Stage 3:EAP−basedauthentication

resp. RADIUS)

(11) RADIUS Access Request

(12) RADIUS Access Challenge

(15) RADIUS Access Request

(16) RADIUS Access Accept

(6) 802.11 Association Request, SPA RSN IE

(5) 802.11 Authentication Response

(4) 802.11 Authentication Request

(3) Probe Response + AA RSN IE

(2) Probe Request

(1) Beacon + AA RSN IE

(7) 802.11 Association Response

(8) EAPOL−Start

(9) EAP−Request / Identity

(10) EAP−Response / Identity

(13) EAP−Request / EAP−X

(14) EAP−Response / EAP−X

(17) EAP−Success

(18) {AA, ANonce, sn, msg1}

Stage 4:4−WayHandshake

UnassociatedUnauthenticated

MSK derivation

Stage 5:Group Key

msg2, MIC)(19) {SPA, SNonce, SPA RSN IE, sn,

(20) {AA, ANonce, AA RSN IE, GTK,

(21) {SPA, sn+1, msg4, MIC}

Generate RAND GTK

Generation of GTKPTK derivation

(22) EAPOL−Key{Group,sn+2, GTK; Key ID, MIC}

sn+1, msg3, MIC}

(23) EAPOL−Key {Group, sn+2, MIC}Handshake(OPTIONAL)

new GTK obtained

GTK derivation

PTK derivation

PMK derivation PMK derivation

MSK derivation and deliveryto the authenticator

AuthenticatedAssociated

Supplicant Authen− ticator

Authenti−cationServer

802.1X blocked

802.1X blocked

(over 802.1X

802.1X unblocked802.1X unblocked

Stage 6:

Communication (25) EAPOL−LogoffSecure Data

(24) Protected data packets

802.1X blocked 802.1X blocked

Figure 4.9: RSNA establishment


128-bit EAPOL integrity protection key, and a 128-bit key for encryption and key exchangepurposes.

Upon successful completion of the 4-Way Handshake, Supplicant and Authenticatorhave mutually authenticated, and the 802.1X Controlled Ports are unblocked to permit ar-bitrary data traffic.

4.1.3.3 802.11 key derivation function

In accordance to the analysis of EAP methods in Chapter 3, we want to cite the 802.11ibuilt-in key derivation function, which is, for instance, adopted by EAP-SAKE [148]. T-PRF of EAP-FAST is also very similar. Figure 4.10 shows the 802.11i KDF - in its correctedversion.8

Dot11PRF (key, label, seed, outputlength){

S = label + ”0” + seed;n = doutputlength/20e;

for i=1 to nTi = HMAC−SHA1(key,S ‖ outputlength ‖ i);

return truncate(T1 ‖ T2 ‖ · · · ‖ Tn, outputlength)}

Figure 4.10: 802.11i key derivation function

4.1.3.4 PMK caching and Pre-authentication

When a wireless client roams from one access point to another, he must actually performa full 802.1X/EAP authentication with each access point. Certain applications like Voice-over-IP require very low latency - the literature typically specifies 30ms are upper bound,so that a full-fledged 802.1X/EAP authentication should be avoided. To address this issue,WPA2 has introduced two mechanisms, PMK caching and 802.1X pre-authentication. Bothmechanisms yield to improve performance in roaming situations9.

Whenever the station is associated with an access point, it caches the correspondingPMK. As defined above, the PMK is the first 32 byte of the MSK. The goal is to re-usethe PMK when re-associating to this access point. How long these PMK cache entriesare maintained or when such an entry expires, depends on the configuration on both sides.

8Unfortunately, the 802.11i standard has a mistake in the PRF in that it does not determine the number ofiterations correctly. The loop is intended to run from i=0 to (len+159)/160, which yields normally one blockless than required. Instead, the loop must run from i=0 to int ((outputlength-1)/160). The thesis however usesanother notation to obtain compliance with the previously described PRFs.

9In fact, these two mechanisms have led to the long delay of 802.11i’s adoption as Standard, because con-sensus was difficult to achieve in detail questions.


To re-use the PMK, the client includes the corresponding PMK identifier (PMKID) in theAssociation Request Frame and thus signalizes to re-use it. The access point then looks forthe PMK in its PMK cache and determines whether it is still valid. In this case, the 802.1X-based authentication is omitted, and client and access point immediately initiate the 4-WayHandshake.

The second mechanism, 802.1X pre-authentication, has a similar goal. If a mobiledevice is associated with an access point, but is in range of another access point (or more),it can optionally perform an 802.1X authentication with this access point, while remainingassociated with the current access point. An access point that supports pre-authenticationgives a hint to this capability in Beacon and Probe Response frames. If the client connectsto an access point with which it has pre-authenticated, the 802.1X/EAP authentication isomitted, and client and access point immediately initiate the 4-Way Handshake.

4.1.3.5 Improvements by 802.11 Task Group r

As mentioned in [153], it is still an open issue of 802.11i that keying and authenticationare too slow to support real-time applications such as voice: ”Voice sounds fine until theuser starts walking around, causing them to disconnect from one access point and connectto another. The 802.11r task group has been created to solve this problem. Intel has beenworking on a solution in that group with Cisco and Texas Instruments.”

802.11’s Task Group r is concerned with the development of fast BSS transition mecha-nisms [82]. They address the short loss of connectivity when a transition between two BSSsin an ESS takes place. Each time the wireless station looses its connection with one accesspoint and establishes a new connection with another, there is a brief loss of connectivitywhich may result in packet loss. Hence, the fast BSS transition mechanisms target to min-imize the transition gap. This is achieved, for instance, by minimizing PTK computationand latencies by enabling the station to perform key computations prior to re-association.Or, by introducing an authenticated re-association message exchange.

4.2 EAP in IEEE 802.16 Wireless MAN 113

4.2 EAP in IEEE 802.16 Wireless MAN

IEEE 802.16 is a suite of air interface standards for combined fixed, portable and mo-bile Broadband Wireless Access. The mobility amendment 802.16e, which was adoptedin December 2005 as IEEE Standard, has introduced EAP into the 802.16 protocol suiteto perform user authentication and optionally device authorization. Most readers are cer-tainly more familiar with the term WiMAX10, which is used in the literature equivalently to802.16e.

This section proceeds as follows. First, the history of 802.16 and the general networkarchitecture of the roaming case are surveyed. Then, the Privacy and Key Managementprotocol is introduced and the 802.16 authentication procedure is described. It defines fourmodes, while three of them make use of EAP and thus are of particular interest.

4.2.1 Introduction

IEEE 802.16 is a wireless broadband technology, whose development began in 1998. It hadbeen originally designed for cost effective last mile broadband access having areas in mindwhich are not covered by wired technologies like DSL or cable. Since 802.16 also offersQuality-of-Service features, it is well suited for realtime applications like Voice-over-IP.This makes 802.16 attractive for underserved as well as unserved areas or countries to buildup phone and broadband networks.

The first release of 802.16 is called 802.16-2001 and was approved in December 2001[76]. It was extended by two amendments, namely by 802.16c-2002, which operates in the10-66 GHz frequency band and requires fixed line-of-sight connections, and by 802.16a-2003 (approved in January 2003), which operates in low frequency bands between 2 GHzand 11 GHz allowing for non-line-of-sight connections. The bandwidth depends on distanceand chosen cell radius and can be up to 70 MBit/s.

The 802.16-2004 standard [77] supersedes all previous versions as the base standard.But again, it is limited to fixed network access. In December 2005, the extension forportable and mobile network access was adopted as IEEE Standard. This amendmentis called 802.16e [75]. In a fixed deployment with basic functionality, 802.16-2004 and802.16e offer similar performance. However, 802.16-2004 is optimized for fixed access,and 802.16e is optimized for mobile access.

4.2.2 802.16 Network model

The main components of an 802.16 network are the subscriber station and the base station.A subscriber station (SS) is defined as a general equipment set providing connectivity be-

10WiMAX stands for ”Wordwide Interoperability for Microwave Access” and is trademark of the WiMAXForum. The WiMAX Forum is working to facilitate the deployment of broadband wireless networks basedon the IEEE 802.16 standard by helping to ensure the compatibility and inter-operability of broadband wire-less access equipment. The organization is a nonprofit association formed in June of 2001 by equipment andcomponent suppliers to promote the adoption of IEEE 802.16 compliant equipment by operators of broadbandwireless access systems. (Source: www.wimaxforum.org)


tween subscriber equipment and base station. A base station (BS) is defined as a generalizedequipment set providing connectivity, management and control of the subscriber station. In802.16e, the SS is called ”mobile subscriber station” (MSS) to emphasize that the clientdevice supports communication even if it is in motion. Since there is no difference in thescope of authentication, both terms are used synonymously.

Figure 4.11 shows the 802.16 roaming reference model, which is adopted by 802.16e.Basically, an 802.16e authentication procedure consists of two authentication exchanges.Both exchanges can be realized with EAP. The one takes place between SS and BS, theother takes place between SS and backend AAA server in the subscriber’s home network.

AAA Server

CSNin visited NSP

CSNin Home NSP

ASN

AAA Proxy(s)NAS

EAP over

DiameterRADIUS /

EAP over

DiameterRADIUS /

BSSS / MS

EAP/

802.16(PKM2)

MS Mobile Station ASN Access Service Network NSP Network Service ProviderBS Base Station CSN Connectivity Service Network NAS Network Access Server

Figure 4.11: 802.16 roaming reference model

4.2.3 The Privacy and Key Management (PKM) Protocol

The 802.16 security architecture consists of two main components. One the one hand,the 802.16 frames are encrypted and authenticated. Therefore, cryptographic suites arespecified, which comprise a data encryption algorithm, an authentication algorithm, andrules how to apply these algorithms to packet payloads. These rules are called cryptographictransforms. On the other hand, there is the Privacy and Key Management (PKM) protocol.

The PKM protocol has already been introduced in 802.16-2004, but without support forEAP. 802.16e finally incorporated EAP into PKM. Basically there exists two PKM variants,PKMv1 and PKMv2. This thesis will focus on PKMv2, because it has mandatory supportfor EAP authentication and will sometime replace PKMv1.

In a nutshell, the PKM protocol offers authentication and authorization of subscriberstations, provisioning of keying material from base stations to subscriber stations, periodicre-authentication and re-keying. PKM specifies two authentication schemes, one based onRSA and one based on EAP. These two schemes are also referred to as

• PKM RSA authentication and

• PKM EAP authentication.


Authentication is done either mutually or one-way, but the latter only from SS to BS, notvice versa.

Subsequently to the authentication procedure, SS and BS establish a shared secret, theAuthorization Key (AK). The derivation procedure is comparable to the 4-Way Handshakeof 802.11i - both have the same intention. AK is an intermediate shared key which is usedfor further key derivation, therefore comparable to the 802.11i PMK. More precisely, theAK assists to secure further PKM exchanges of Traffic Encryption Keys (TEKs).

Informally spoken, access to a specific service requires a specific TEK. The motivationbehind this two-tiered mechanism is very similar to the motivation behind the two phases ofIKEv2. During an intitial phase, which is rather computationally expensive, a shared secretis established. The benefit of this effort is that subsequent key exchanges can be done veryefficiently.

IEEE 802.16 distinguishes between

• device authentication (also referred to as device authorization) and

• user authentication.

Furthermore, IEEE 802.16 distinguishes between initial authentication and re-authentication(e.g. for rekeying). In case of initial authentication, two subsequent authentication ex-changes take place. The first exchange performs device authorization, the second exchangeuser authentication. For the initial authentication case, two variants exist, namely

• RSA followed by EAP, also known as ”Authenticated EAP-after-RSA mode”, and

• EAP followed by EAP, also known as ”Authenticated EAP-after-EAP mode”.

If both authentication procedures terminate in the same provider network, [161] recom-mends to optimize the authentication process in that both device and user authentication arecolocated in a single EAP method. A single EAP method is also used when either user-onlyor device-only authentication is desired. Regardless of the specific choice, at the end of theauthentication procedure, the Authentication Key (AK) must be established.

The initial authentication is intended to achieve network access authentication and istherefore particularly focused on. First, the basic building blocks PKM RSA authenticationand PKM EAP authentication are outlined. Then, the aforementioned EAP-after-RSA andEAP-after-EAP variants are presented. For each type, the derivation of the AK will beshown.

4.2.3.1 PKM RSA Authentication

This variant is mainly used for device authorization. Each SS carries a unique X.509 certifi-cate issued by the SS manufacturer itself or an external authority. All SS must have eitherfactory-installed RSA public/private key pairs or provide an internal algorithm to generatedynamically such key pairs. In the latter case, the SS must also support a mechanism forinstalling manufacturer-issued X.509 certificates, which takes place immediately after an


RSA key pair generation. The certificate contains the SS’s public key, the SS’s identity andits MAC address. The key exchange between SS and BS is secured by PKCS#1 RSA publickey encryption algorithm.

Before describing the message exchange of the PKM RSA Authentication mode, thecorresponding PKM messages are themselves surveyed ([75], Section 6.3.2.3.9).

PKMv2 RSA-Request: This message is sent by the SS to initiate an RSA-based authen-tication. It contains four attributes, MS_Random, MS_Certificate, SAID and SigSS.The former is an 8-byte random number generated by the SS. It follows the MS’sX.509 certificate, issued by the SS’ manufacturer. SAID identifies the Security Asso-ciation. SigSS is a RSA signature over all other attributes of the message, keyed withSS’s private key.

PKMv2 RSA-Reply: This message is sent by the BS as response to a PKMv2 RSA-Request message. It contains seven attributes, MS_Random, BS_Random, Encryptedpre-PAK, Key Lifetime, Key Sequence Number, BS_Certificate and SigBS. MS_Randomis the random number of the preceded PKMv2 RSA-Request message, while BS_Randomis a randomly generated 8-byte number by the BS. The Encrypted pre-PAK attributecontains the pre-PAK and SS MAC address, encrypted with SS’s public key. Further-more, the BS X.509 certificate and a RSA signature over all the other attributes of themessage are transmitted. The signature is keyed with the BS’s private key.

PKMv2 RSA-Reject: If the BS rejects SS’s authorization request, it responds with thismessage. This message is listed here for the sake of completeness - in a successfulauthorization procedure as described below, it does not occur.

PKMv2 RSA-Acknowledgement: This message is sent by the SS in response to PKMv2RSA-Reply message. It contains five attributes, BS_Random, Auth Result Code,Error-Code, Display-String (optional), and SigSS. BS_Random denotes an 8-byterandom number generated by the BS. Auth Result Code indicates the result of theauthentication. SigSS is a RSA signature over the other attributes, keyed with SS’sprivate key.

The goal of the PKM RSA Authentication is to mutually authenticate SS and BS and totransport the Preliminary Primary Authorization Key (pre-PAK) securely to the SS. This isrealized in that the BS encrypts the pre-PAK with the public key of the SS certificate, havingsuccessfully validated the SS certificate before.

The message flow for the successful case results directly from the PKM message flowdescribed above and is depicted in Figure 4.12.

The pre-PAK is mainly used to generate the Primary Authorization Key (PAK), and toderive the EAP Integrity Key (EIK). Both keys have a length of 20 byte. They are derivedas


Subscriber Station (SS) Base Station (BS)

(1) PKMv2 RSA-Request →(MS_Random, MS_Certificate, SAID,SIGSS (msg attributes) )

verify SS signature; generate pre-PAK

(2) ← PKMv2 RSA-Reply(MS_Random, BS_Random,ENCpkSS

(pre-PAK || MS MAC Address)Key Lifetime, Key Sequence Number,

decrypt pre-PAK with private key BS_Certificate, SIGBS (msg attributes))of SS certificate

(3) PKMv2 RSA-Acknowledgement →(BS_Random, Auth Result Code,Error-Code, Display Message,SIGSS (msg attributes))

compute EIK and PAK compute EIK and PAK

Figure 4.12: PKMv2 RSA authentication

EIK = Dot16KDF (pre-PAK, SS MAC Address || BSID || "EIK+PAK", 320) [0..159]PAK = Dot16KDF (pre-PAK, SS MAC Address || BSID || "EIK+PAK", 320) [160..319]

AK = Dot16KDF (PAK, SS MAC Address || BS_ID || PAK || ”AK”, 160)

The PAK is used to generate the Authorization Key (AK), the EIK is used to integrityprotect a subsequent EAP exchange. Note that AK is derived like this only in the PKMRSA mode. In EAP-after-EAP mode or EAP-after-RSA mode, the AK is derived by othermeans.

4.2.3.2 PKM EAP Authentication

Next to RSA-based authentication, PKM offers an EAP-based authentication, which is moreflexible. While PKM RSA authentication has SS and BS as endpoints, PKM EAP authenti-ation is executed between the SS and the AAA server in the SS’s home network. Operatorscan choose an EAP method which fits best to the specific scenario. In absense of a betterproposal, IEEE adopted the requirement catalogue for EAP methods used in 802.11 Wire-less LANs, RFC 4017, for EAP methods used in 802.16e.


EAP is encapsulated in PKM messages, more precisely, PKMv2 EAP Start, PKMv2EAP-Transfer, PKMv2 EAP Complete, PKMv2 Authenticated EAP Start and PKMv2 Au-thenticated EAP-Transfer (see also [75], Section 6.3.2.3.9).

PKMv2 EAP Start: This message contains two attributes, an AK sequence number anda HMAC/CMAC Digest calculated using AK. During initial authentication, both at-tributes are omitted.

PKMv2 EAP-Transfer: This message contains three attributes, namely the EAP payload,which is not interpreted in the MAC, an AK sequence number and an HMAC/CMACDigest calculated using AK.

PKMv2 EAP Complete: This message appears only in Double-EAP mode. The BS usesthis message to inform the SS of a successful completion of the first EAP method. Itconsists of three attributes, the EAP payload, and only in case of re-authentication,an AK sequence counter and an HMAC/CMAC Digest calculated using AK.

PKMv2 Authenticated EAP-Transfer*: When SS and BS have established an EIK, EAPpayloads are encapsulated in this PKM message type. The EAP payload is crypto-graphically bound to previous EAP methods. This PKM message has three attributes,the PAC Sequence Number (optional; only present in Authenticated EAP after RSAmode), the EAP payload, and an HMAC/CMAC Digest calculated using EIK.

PKMv2 Authenticated EAP Start: This message occurs only in Double-EAP mode. Itis sent by the SS to the BS in order to indicate the beginning of the second EAPmethod. It is signed with the EIK, which is derived after the first EAP method. Itcomprises two attributes, MS_Random, a random number generated by MS, and aHMAC/CMAC Digest calculated using EIK.

*) Note that the 802.16e Standard uses an inconsistent notation. Only EAP-Transfer and Authenticated EAP-Transfer have aslash in their names. The other messages not.

The message exchange of PKMv2 EAP authentication is depicted in Figure 4.13.


(1) PKMv2 EAP Start() →(2) ← PKMv2 EAP-Transfer

(EAP-Request(EAP-Type=X; ...))(3) PKMv2 EAP-Transfer →

(EAP-Response(EAP-Type=X; ...))(4) ← PKMv2 EAP Complete

compute EIK and PMK compute EIK and PMK

Figure 4.13: PKMv2 EAP authentication

Keys are derived as follows


EIK = MSK [0..159]PMK = MSK [160..319]AK = Dot16KDF (PMK, SS MAC Address || BSID || ”AK”, 160)

Note that AK is derived like this only in PKM EAP mode. In EAP-after-EAP mode orEAP-after-RSA mode, the AK is derived by other means.

4.2.3.3 Authenticated EAP-after-RSA mode

The message flow of this variant is approximately the subsequent execution of the flows de-picted in Figures 4.12 and 4.13. EIK and PAK are derived like in PKM RSA Authentication(Section 4.2.3.1), while the PMK is derived like in PKM EAP authentication, i.e. PMK =MSK [169..319]. AK is determined to

AK = Dot16KDF (PAK ⊕ PMK, SS MAC Address || BSID || PAK || ”AK”, 160)

As can be seen, the PRF is keyed with the exclusive-ORed PAK and PMK, hence it isderived from the results of both RSA authentication and EAP authentication.

4.2.3.4 Authenticated EAP-after-EAP mode

This mode is probably better known as ”Double-EAP mode”. It is usually chosen if deviceauthentication and user authentication do not terminate in the same network. If deviceauthentication is based on X.509 certificates, the authentication will terminate in the servingnetwork (ASN), while user authentication will terminate in the subscriber’s home network(CSN). This local authentication has the advantage of reducing roundtrip delay. As EAPmethod, a WiMAX specification suggests EAP-TLS ([161], Section 7.3.6.2.2). The genericmessage flow of the Double-EAP mode is shown in Figure 4.15.

After the first EAP method, both sides derive the EAP Integrity Key (EIK) and PairwiseMaster Key as follows

EIK = MSK [0..159]PMK = MSK [160..319], and after the second EAP method,PMK2 = MSK2 [0..159]

AK = Dot16KDF (PMK ⊕ PMK2, SS MAC Address || BSID || "AK", 160)

4.2.4 802.16 Key derivation function

802.16e specifies its own key derivation function, Dot16KDF, which is used as pseudoran-dom function. All PKMv2 key derivations are based on Dot16KDF. Since 802.16 supportsmessage authentication codes based on AES and SHA-1, i.e. CMAC (see Section 3.4.3.2)and HMAC, Dot16KDF is available in two variants.

The construction is based on concatenation of 128-bit CMAC and 160-bit SHA-1 blocks,respectively. The design of the HMAC variant is not quite clear, because it uses a simplekeyed SHA-1 instead of the more secure HMAC-SHA1 construction.



- 1st EAP method -

(1) PKMv2 EAP Start() →(2) ← PKMv2 EAP-Transfer

(EAP-Request(EAP-Type=X; ...))(3) PKMv2 EAP-Transfer →

(EAP-Response(EAP-Type=X; ...))(4) ← PKMv2 EAP Complete

compute EIK and PMK compute EIK and PMK

- 2nd EAP method -verify with aid of EIK thedigest in PKMv2 EAP Complete

(5) PKMv2 Authenticated EAP Start →verify MAC to assure that SS knows EIK

(6) ← PKMv2 Authenticated EAP-Transfer(EAP-Request(EAP-Type=Y; ...))

(7) PKMv2 Authenticated EAP-Transfer →(EAP-Response(EAP-Type=Y; ...))

(8) ← PKMv2 EAP Complete

Figure 4.14: 802.16e Double-EAP mode

SS ASNCSN

ServingCSNHome

negotiation

device authenticationPKMv2/EAP for

PKMv2/EAP foruser authentication RADIUS/EAP RADIUS/EAP

Double−EAP Mode

Figure 4.15: Scenario for Double-EAP Mode

4.3 EAP in 3GPP networks 121

Dot16KDF (key, label, outputlength){

result = null;kin = truncate (key, 128);for (i=0; i <= int ((outputlength-1)/128); i++)

result = result || CMAC (kin, i || seed || outputlength);

return truncate (result, outputlength)}

Figure 4.16: 802.16 Key derivation function (CMAC-based Dot16KDF for PKMv2)

Dot16KDF (key, label, outputlength){

result = null;kin = truncate (key, 160);for (i=0; i <= int ((outputlength-1)/160); i++)

result = result || SHA-1 (i || astring || outputlength || kin);

return truncate (result, outputlength)}

Figure 4.17: 802.16 Key derivation function (SHA-1-based Dot16KDF for PKMv2)

4.3 EAP in 3GPP networks

4.3.1 Introduction

3G cellular systems provide wide coverage, support roaming and an attractive combina-tion of bandwidth and quality-of-service, which makes the technique suitable for real-timebroadband applications. Another advantage is the infrastructure for authentication, autho-rization and accounting. Once deployed, it can be re-used for various other purposes. Con-trasting 3G cellular networks to Wireless Local Area Networks, it becomes obvious thattheir capabilities complement each other. Wireless LANs also have very appreciable prop-erties. They are comparatively inexpensive, widely deployed (i.e. all newer laptops areequipped with a built-in WLAN adapter) and they offer data transfer rates of 54 MBit persecond and above. However, the drawbacks of Wireless LAN are, that they do not supportroaming and mobility, and that they offered for a long time very poor security mechanisms- clearly, the security amendment 802.11i introduces improved security mechanisms.

Cellular network carriers and mobile operators have recognized the resulting benefitsof combining WLAN and 3G. There is increased interest in heterogenous mobile data net-works which allow for ubiquitous data services and high data rate IP connectivity in strategiclocations, so called hotspots. 3GPP is working intensively on related solutions. Many tech-


nical issues have to be solved, for instance, common authentication, centralized accountingand billing, security and quality-of-service guarantees.

All related efforts are referred to as ”3GPP-WLAN interworking”. It deals with issueshow to integrate the WLAN family of standards into 3G networks. While various WLANtechnologies exist, 3GPP initially focuses on integrating IEEE 802.11 Wireless LAN. Nev-ertheless, the goal is to keep the interworking specification as flexible as possible and totake care that other WLAN technologies are not excluded.

The 3GPP has defined several formal requirements for the authentication protocol,which is performed between WLAN User Equipment (UE) and 3GPP network ([1], Sec-tion 4.2). The solution has to be a challenge response protocol, has to provide mutualauthentication, has to re-use the credentials of the UICC/SIM and has to support sessionkey derivation. Furthermore, the protocol has to be resistant to man-in-the-middle attacksand has to provide protected success or failure indications. Of particular importance is theprotection of the subscriber’s identity. In general, the authentication for subscriber accessvia Wireless LAN has to be at least of the same security as for the cellular access. The 3GPPhas chosen EAP, since it best addresses the requirements mentioned before. To perform mu-tual authentication between WLAN UE and 3G network, EAP-AKA is used. Consequently,all WLAN UE is required to support EAP-AKA.

4.3.2 3GPP-WLAN interworking scenarios

An interworking between 3GPP and WLAN is desired in a variety of scenarios, whichcan be separated into public, corporate and residential environments (cf. [3]). These threecategories vary in their security capabilities and policies. These factors determine the rangeof services offered, e.g. access to the public internet, access to services of the local operatoror access to corporate services.

[2] investigates the feasibility of interworking between 3GPP systems and WLANs. Itdescribes six 3GPP-WLAN interworking scenarios, ranging from common billing to so-phisticated provisioning of services. They are

• Scenario 1: Common Billing and Customer Care

• Scenario 2: 3G-based Access Control and Charging

• Scenario 3: Access to 3GPP Packet Switched services

• Scenario 4: Access to 3GPP Packet Switched services with service continuity

• Scenario 5: Access to 3GPP Packet Switched services with seamless service continu-ity

• Scenario 6: Access to 3GPP Packet Switched and Circuit Switched services withseamless service continuity


Scenario 1 is the simplest use case. The subscriber can use both 3GPP and WLAN servicesand receives one common bill for both services from the mobile operator. In this scenario,3G and WLAN security mechanisms are used independently of each other.

Scenario 2 extends Scenario 1 in that the 3GPP system’s access control is reused to ob-tain authentication, authorization and accounting for WLAN services. The WLAN systemmust provide the same security strength as the 3GPP system. The main goal of Scenario 2is to provide IP connectivity to 3G subscribers. Apart from the IP connectivity, however, nofurther services are specified.

Scenario 3 offers both IP connectivity and 3GPP system PS-based services11 to theWLAN. These services are, for instance, multimedia applications (Voice-over-IP, Audio orVideo Streaming, Video Conferencing, Web browsing), location or presence based services,instant messaging, SMS, MMS and so on. Consequently, if an operator maintains a WirelessApplication Gateway (WAP), he will certainly make the WAP and MMS services accessiblethrough the WLAN.

While Scenario 3 makes PS-based services available in both networks, it does not offerservice continuity across them. Scenario 4 addresses this issue. Scenario 5 has particularlyseamless service continuity in mind. This means, PS-based services shall be accessible inboth systems in a seamless manner, i.e. without significant handover delays or additionaluser interaction. Finally, Scenario 6 exceeds all predecessors in that it gives access to 3GPPcircuit-switched services with seamless mobility, for instance normal voice calls.

The main intention of the subsequent section is to give an impression how EAP is usedin the context of 3GPP-WLAN interworking. In the scope of EAP, Scenarios 2 and 3 are ofparticular interest, because they deal with the basic interworking between 3GPP systems andWLAN, and cover aspects like network access authentication and authorization. Scenarios2 and 3 are currently considered to feature the highest market interest [135]. They enable3G subscribers to benefit from high throughput IP connectivity and let them access 3GPS-based services via WLAN.

4.3.3 EAP in 3GPP WLAN interworking

3GPP’s specification [1] discusses security issues of WLAN interworking and specifiesthree reference network models for 3GPP WLAN interworking. The first is a non-roamingreference model. The other two are roaming reference models. The one of them assumes asubscriber who wants to access PS based services provided via the 3GPP Home Network.The other assumes a user, who wants to access PS based services provided by the 3GPPVisitor Network. To describe the general concept, it suffices to consider the non-roamingscenario as depicted in Figure 4.18.

The nodes in Figure 4.18 are mostly fixed elements of the 3GPP network. The relevantnodes in the scope of 3GPP-WLAN interworking are the WLAN User Equipment (WLAN

11PS stands for packet-switching and refers to protocols in which messages are divided into packets beforethey are sent. Each packet is then transmitted individually to the destination address. Once they are all arrived,the packets are reassembled to the original message. Oftentimes, the term PS occurs together with CS (circuit-switched). In a circuit-switched network, the communication path (”circuit”) for the connection is set up anddedicated to the participants in that connection.


UE), the Packet Data Gateway (PDG) and the 3GPP AAA Server. The WLAN UE is aterminal equipped with a USIM or having access to it, for example a laptop with an attachedmobile phone.

The 3GPP AAA Server is a new introduced node for the purpose of interworking withWLANs. It takes over the role of the EAP server. Hence, mutual authentication of EAP-AKA takes place between WLAN UE and 3GPP AAA Server. In accordance with theoriginal AKA protocol (see Section 3.7.2), the 3GPP AAA Server must be connected to theHome Subscriber Server (HSS) to get access to subscriber-specific informations.

The other nodes HLR (Home Location Register), CGw/CCF (Charging Gateway / Charg-ing Collection Function), and OCS (Online Charging System) are of minor relevance here.Next, some of the interfaces (also known as ”reference points”) will be briefly explained.

Ww connects the WLAN User Equipment to the WLAN Access Network. This mightbe IEEE 802.11 Wireless LAN. The goal of the Wa interface is to connect the WLANAccess Network to the 3GPP AAA Server located in the 3G network. The protocol must beable to transport authentication and key information. The specification suggests RADIUSor Diameter. While RADIUS offers itself appropriate security mechanisms12, Diametershould be protected by an IPsec tunnel.

In order to retrieve authentication informations (in case of UMTS: Authentication Vec-tors) and WLAN access-related information, the Wx interface connects the AAA Serverto the Home Subscriber Server (HSS), which offers in 3G networks similar services likethe Home Location Register (HLR) in the GSM network. The protocol is either MobileApplication Part (MAP) or Diameter.

The Home Location Register is connected to the 3GPP AAA Server via the D’/Gr’ inter-face, which employs a MAP-based protocol. If the WLAN UE has access to the 3G network,it might want to use services. Therefore, on the Wu interface, WLAN UE and Packet DataGateway (PDG) run the IKEv2 protocol to establish an IPsec tunnel and protect user datapackets.

4.3.3.1 Interworking Scenario 2

As mentioned above, the main goal of Scenario 2 is to re-use parts of the 3GPP AAAinfrastructure to facilitate access to services via the WLAN interface. Figure 4.19 illustratesthis scenario. It is possible that the WLAN Access Network is not directly attached tothe subscriber’s home network, but to some visitor’s network. In this case, the 3GPP AAAServer of the visited networks act as proxies and are assigned to forward the AAA messagestransparently.

In subsequence to the EAP conversation, the WLAN UE typically uses DHCP to obtainan IP address, which might be either a private IP address or a public IP address.

12In case of RADIUS based Wa reference point, protection is achieved by means of RADIUS standardprocedures. In particular, the attribute MS-MPPE-Recv-Key as described in RFC 2548 provides protection ofthe keying material derived in the 3GPP AAA server and sent to the WLAN Access network. (cf. [1], Section5.1.3).


Figure 4.18: Reference model for 3GPP-WLAN interworking [1]

WLANUE

WLANAccess Node

0 ... *

3GPP AAA 3GPP AAAProxy Server

WaWw Wd

over DiameterEAP−AKAEAP−AKA

over DiameterEAP−AKA

over 802.1X

Figure 4.19: 3GPP-WLAN Interworking Scenario 2

4.3.3.2 Interworking Scenario 3

Interworking scenario 3, also called ”WLAN 3GPP IP Access”, extends Scenario 2 in thatit offers next to plain IP connectivity also access to packet-switched services of the 3Gnetwork via WLAN. This traffic is protected by IPsec ESP. The new units in this contextare the Wireless Access-Point Name (W-APN) and the Packet Data Gateway (PDG). Whileauthentication-related messages terminate at the 3GPP AAA Server, like in Scenario 2,user data traffic is exchanged with the PDG. The WLAN UE specifies the desired servicesby means of the W-APN. The PDG uses this W-APN for service authorization and policyenforcement, and to route user data traffic between WLAN UE and the external Packet DataNetwork (PDN).

A W-APN is encoded as Internet Domain Name. Hence, the W-APN gives the PDN ahint which service the user wants to use. This includes also the selection of the respective


EAP−AKA over IKEv2

ServicesEAP−AKAover Diameter

Packet Data

3GPP AAAServer

WLANUE Gateway

Wu

Wm

Figure 4.20: 3GPP-WLAN Interworking Scenario 3

IP network. A W-APN might be, for instance, internet.vodafone.com to access inter-net through the 3GPP operator’s network, or intranet.vodafone.com to access serviceswithin the home network. After the IP network has been selected with aid of the W-APN,IPsec tunnels are established to route the user data traffic to the selected IP network.

The establishment of the IKEv2 tunnel is depicted in Figure 4.21. Once the user hasdecided to use a service, the WLAN UE initiates an IKEv2 conversation with the PDG.WLAN UE and 3GPP AAA Server mutually authenticate through EAP-AKA which is per-formed within IKEv2. The corresponding message flow is shown in Figure 3.27 on page 80,where the WLAN UE acts as IKEv2 Initiator and the PDG as IKEv2 Responder. The PDGis connected with the 3GPP AAA Server via the Wm interface.

In message 3, the WLAN UE sends either the USIM’s IMSI or the pseudonym. Fur-thermore, a Configuration Payload is transmitted to obtain a remote IP address13. The PDGforwards this request to the 3GPP AAA Server. The parameter W-APN gives a hint to thedesired service and thus helps the 3GPP AAA Server to distinguish between authenticationexchanges for WLAN access and authentication exchanges for tunnel setup. If the AAAserver has not already stored Authentication Vectors for the specific user, a request is sentto the HSS/HLR.

In message 4, the PDG authenticates to the WLAN UE by sending its certificate and asignature14. In messages 5 and 6, it follows the EAP-AKA authentication within IKEv2.The way how EAP is encapsulated in IKEv2, is shown more detailed in Section 3.6.2.4.

13The Configuration Payload addresses the IPsec Remote Access Client (IRAC) problem, which must beassigned a private IP address (in order to specify TSi) before creating CHILD_SAs. The Configuration Pay-load allows an IRAC to acquire bootstrapping configuration within IKEv2_AUTH exchange. The responseCFG_REPLY to the IRAC contains a minimal IP address configuration so that a CHILD_SA can be estab-lished, i.e. IPv4 address, netmask, dns, nbns.

14[1], 6.6A remarks that the WLAN UE is possibly not capable to verify the PDG certificate, because ithas not yet access to the OCSP server. Consequently, the verification has to be postponed to after tunnelestablishment. If the certificate is not valid, the UE terminates the tunnel that was established just before.


WLAN UE Packet Data Gateway 3GPP AAA Server(IKEv2 Initiator) (IKEv2 Responder)

(1) HDR, SAi1, KEi, Ni →(2) ← HDR, SAr1, KEr, Nr

IDi← user IDIDr←W-APN

(3) HDR, SK {IDi, IDr, CFG_

REQUEST, SAi2, TSi, TSr} →EAP-Response/Identity(user ID, W-APN) → Retrieve user

profile and AVsfrom HSS/HLR.

EAP-Request/AKA-Challenge

← (RAND, AUTN, MAC)IDr← PDG ID

(4) HDR, SK {IDr, CERT, AUTH,EAP-Request/AKA-Challenge

← (RAND, AUTN, MAC) }

(5) HDR, SK {EAP-Response/AKA-Challenge(RES, MAC)} →

EAP-Response/AKA-Challenge(RES, MAC)} →

← EAP-Success(6) ← HDR, SK {EAP-Success}

compute AUTH payload as described on page 79

(7) HDR, SK {AUTH} →(8) HDR, SK {AUTH, CFG_

← REPLY, SAr2, TSi, TSr}

Figure 4.21: Tunnel establishment between WLAN UE and PDG

The AUTH payloads exchanged in messages 7 and 8 contain a MAC keyed with the MSKresulting from the EAP-AKA authentication exchange. They give both sides the assuranceto talk to the desired peer. In message 8, the PDG sends a remote IP address through theConfiguration Payload (CFG_REPLY) to the WLAN UE.


Section 6.5 of [1] provides details on the cryptographic properties of the IPsec tun-nel. Basically, two cryptographic suites are defined. They are based on recommendationsfor protecting Virtual Private Networks. The first suite comprises 3DES in CBC modefor confidentiality, HMAC-SHA1 as pseudorandom function, HMAC-SHA1-96 as integrityprotection algorithm and as Diffie-Hellman group the 1024-bit DH Group 2, defined in[72], Section 6.2. The second suite uses AES-128 in CBC mode for confidentiality, AES-XCBC-PRF-128 as pseudorandom function, AES-XCBC-MAC-96 as integrity protectionalgorithm and, like suite 1, the 1024-bit Diffie-Hellman group 2.

Chapter 5

Future Work

This chapter aims to give an overview of further IETF work on EAP and EAP methods andto identify some selected open issues.

5.1 Standardized EAP methods

In the more than four years after its foundation in March 2002, the EAP Working Group hasalmost finished all work items and therefore declared to be near to conclusion. A corres-ponding hint is found in the meeting minutes of the 65th IETF meeting in March 2006.1

At 64th IETF meeting in November 2005, an informal meeting (a so called ”Bird ofa feather” or short BoF meeting) took place to determine the possible need for a revisionof EAP methods. Due to enormous feedback, the IESG approved the foundation of a newWorking Group, called ”EAP Method Update”. The main goal of this Working Group is thedevelopment and standardization of EAP methods suited for current and upcoming networkaccess technologies.

During this meeting, a voting took place, which elected three priority tasks out of alarger set of possible working items, summarized in Appendix D in the back of the thesis.The elected priority tasks are

• to work on an update of EAP-TLS (RFC 2716) in order to meet the requirements ofRFC 3748, RFC 4017 and the EAP keying framework. Since the revised EAP-TLShas to be backward compatible to the original specification (RFC 2716), the changeswill focus on clarifications to the existing protocol.

• the development of a strong shared secret mechanism compliant to RFC 3748 andRFC 4017. This mechanism has to be simple in its design and compact for imple-mentation in resource-constrained environments.

1 ”The EAP WG has completed all of its work items other than the EAP Key Management Frameworkand Network Selection documents, both of which have completed WG last call. This will be the last meetingof the EAP WG; the goal of this meeting is to close the remaining issues on these documents.” (source:http://www3.ietf.org/proceedings/06mar/minutes/eap.txt)

129

130 Future Work

• the development of a mechanism that makes use of existing password databases. Itmust meet the requirements of RFC 3748 and RFC 4017, and should also be useablein constrained environments.

To obtain an initial protocol specification for the shared secret-based and password-basedmechanisms, design teams are formed. They should take existing methods into account inorder to facilitate the development and to obtain a wide consensus.

Feb 2006 Form design team to work on strong shared secret mechanismMar 2006 Submit 2716bis I-DJun 2006 Submit first draft of enhanced EAP-TLS I-DJul 2006 Form password based mechanism design teamJul 2006 Submit first draft of shared secret mechanism I-DAug 2006 Submit 2716bis draft to IESG for Proposed StandardNov 2006 Submit 2716bis draft to IESG for draft standardDec 2006 Submit first draft password based method I-DJan 2007 Submit Strong Shared Secret Mechanism to IESGJan 2007 Submit enhanced EAP-TLS to IESGAug 2007 Submit password Based Mechanism to IESG

Table 5.1: Goals and Milestones EMU Working Group [49]

Table 5.1 depicts the goals and milestones of the EMU Working Group. According tothis charter, in February 2006 a design team was formed to work on the specification of theshared secret-based EAP method, called EAP-GPSK (Generalized PSK). In the subsequentweeks, the design team worked on the features and design of the upcoming method. Theefforts yielded in a first version of EAP-GPSK, which was published in May 2006 in [40].

From its design, EAP-GPSK should

• be based on a strong shared secret, preferably 16-byte or 32-byte,

• be a lightweight protocol,

• abstain from asymmetric cryptography,

• provide cryptographic agility,

• offer negotiation of a set of algorithms (”ciphersuite”), in contrast to per-algorithmnegotiation

• provide support for channel bindings,

• generate nonces on both sides to derive the session key (”joint key control” [105])

• keep its message sizes small to avoid fragmentation

5.1 Standardized EAP methods 131

• not provide a bootstrapping or provisioning mode

• avoid multiple modes of operation

In the following, EAP-GPSK will be briefly outlined. Though the protocol specificationis still very preliminary and thus subject to change, the general idea might yet becomeapparent.

EAP-GPSK performs mutual authentication and session key derivation compliant toRFC 3748 within two roundtrips. It relies on a pre-shared key K, whose length depends onthe chosen ciphersuite. The two currently proposed ciphersuites require a 16- and 32-bytekey, respectively.

Figure 5.1 depicts the message flow of EAP-GPSK. Peer and EAP server mutually au-thenticate by exchanging nonces and by computing a Message Authentication Code overthe nonces and their identities in order to proof possession of the pre-shared key. This takesplace in messages (3)-(5). EAP-GPSK is thisregarding very similar to existing proposalslike EAP-PSK, EAP-PAX or EAP-SAKE.

Messages (5) and (6) allow for the exchange of further information, e.g. channel bindingdata, protected under previously derived session keys. The protection comprises integrityprotection (SEC) and - depending on the chosen ciphersuite - encryption (ENC).


(3) A← B : EAP-Request / GPSK-1(ID_Server || RAND_Server || CSuite_List)

(4) A→ B : EAP-Response / GPSK-2(SEC_SK (ID_Client || ID_Server || RAND_Client || RAND_Server ||CSuite_List || CSuite_Sel [ || ENC_PK(PD_Payload_1), ... ] ))

(5) A← B : EAP-Request / GPSK-3(SEC_SK (RAND_Client || RAND_Server ||CSuite_Sel [ || ENC_PK(PD_Payload_2) ] ))

(6) A→ B : EAP-Response / GPSK-4([ SEC_SK(ENC_PK(PD_Payload_3)) ])


Figure 5.1: EAP-GPSK message flow

One of the protocol’s design goals is to offer cryptographic flexibility. This is realizedin that the EAP server sends in message (3) a set of supported ciphersuites to the peer.

132 Future Work

The peer selects a ciphersuite and sends his choice encoded in Csuite_Sel back to the EAPserver.

In its current version, EAP-GPSK specifies two ciphersuites, a block cipher-based anda hash function-based one. Ciphersuite 1 is based on the AES block cipher, the EAX modeof encryption [22] and the CMAC algorithm [84]. It requires a 16-byte shared secret andprovides an effective key strength comparable to 128-bit symmetric security. Ciphersuite 2relies on the SHA-256 hash function [116], and requires a 32-byte shared secret.

Ciphersuite Key length Encryption Integrity Key Derivation1 16 AES-EAX-128 AES-CMAC-128 GKDF-1282 32 NULL HMAC-SHA256 GKDF-256

Keying material is derived by an own key derivation function, GKDF, which generateskeying material in arbitrary length by concatenating outputs of the negotiated MAC algo-rithm.

Another design goal of EAP-GPSK is to provide extensibility, which means, that itallows to exchange information between peer and EAP server using a protected channel,found in messages (5) and (6). This channel could be used to exchange channel bindinginformation or to realize identity confidentiality.

5.2 Open issues

Taking the publication of RFC 2284 as beginning, the EAP Working Group has developedwithin the past 8 years a mature, extensible and flexible authentication framework. How-ever, there are still a lot of open issues in the context of EAP and EAP methods. Some ofthem are discussed next.

5.2.1 EAP method performance analysis

It still lacks of a performance and energy consumption analysis of EAP methods. In gen-eral, the more security features a cryptographic protocol offers, the worse its performancebecomes. Therefore, the design process is comparable to make a tradeoff between securityand efficiency. The energy consumption of a cryptographic protocol is closely related to itscomputational costs, because a high execution time (”latency”) is typically caused by heavycomputations, which lead to higher processor load and hence to higher energy consumption.

Regarding the latency of an EAP authentication run, it can be break up into three com-ponents, namely operating system time, computational time and transmission time. It isassumed that the computational time is the dominant factor among them. As performancemetrics, client and server processing time, amount of transmitted data, and the overall la-tency seems to be the most common ones.

In the following, some experimental results are presented, which shall motivate fora more in-depth performance analysis. The testbed consists of a notebook (Pentium-M1.7GHz, 1024 MB RAM), and two EAP servers, a slow one and a fast one. The fast machineis a Pentium 4 with 2.24GHz, the slow machine is a Via Epia ME-6000 running at 600 MHz.

5.2 Open issues 133

Table 5.2 contains detailed data for EAP-TTLS with 2048-bit certificates for server andCA. The EAP peer authenticates password-based through MS-CHAPv2. The software usedon peer-side is wpa_supplicant2, on server-side freeRADIUS3. The data were captured onthe peer-side with the network protocol analyzer ethereal4, that is, the given data denote thearrival time of a packet and the departure time of a packet on the client machine. Details ofthe EAP-TTLS message flow can be found in Figure 3.6 on page 54.

data / byte time / secVia Epia Pentium IV

msg 802.11 EAP run 1 run 2 run 3 run 1 run 2 run 3

(1) 185 5 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000(2) 194 14 0.002838 0.002864 0.002843 0.002243 0.002863 0.002839

(3) 186 6 0.009381 0.008487 0.009816 0.008458 0.006997 0.006376(4) 286 106 0.011793 0.010911 0.012296 0.010867 0.009417 0.008760

(5) 1214 1034 0.024427 0.026095 0.025145 0.021496 0.020080 0.017903(5’) 186 6 0.025396 0.027063 0.026141 0.022466 0.021050 0.018886(5”) 1122 942 0.033803 0.035935 0.036543 0.026855 0.025436 0.023493

(6) 512 332 0.040036 0.042179 0.042960 0.033189 0.031740 0.029845

(7) 249 69 0.429729 0.431814 0.431932 0.087678 0.088308 0.074477(8) 292 112 0.431772 0.433748 0.433989 0.089605 0.090218 0.076536

(9) 184 4 0.453233 0.451288 0.454960 0.096906 0.095534 0.080665

Table 5.2: Performance of EAP-TTLS with 2048-bit certificates

The following conclusions can be drawn.

• On the slow server machine, the latency is about 450 ms, on the fast server machine, itis only about 90 ms. As pointed out in Section 3.1.2.3, the performance bottleneck inthe TLS handshake is - when only server-to-client authentication is performed - not onclient-side, but on server-side. Therefore, the notable improvement when upgradingthe EAP server with a faster processor, is no surprise. This expensive computationtakes place after the server has received message (6). On the slow machine, generationof message (7) takes more than 85% of the total execution time, and even on the fastmachine more than 55%.

2http://hostap.epitest.fi/wpa_supplicant/3http://www.freeradius.org/4http://www.ethereal.com/

134 Future Work

• The second and third column of Table 5.2 contain the size of the EAP message andthe size of the transmitted data when used in 802.11i network authentication. As canbe seen, 802.11/802.1X adds an overhead of constantly 180 byte to the EAP frame.While the core EAP-TTLS would require peer and EAP server to send 570 and 2060byte, respectively, it requires in the 802.11 setting 1470 and 3140 byte, respectively.This corresponds to a communicational overhead of 158% for the peer and 42% forthe EAP server.

• The deviation of the third experiment on the fast machine (80 ms) indicates that thereis need for further investigation. Although the EAP server took much less time togenerate message (7), it could also be that the process in which the third experimentwas executed, was handled with another priority by the operating system. In general,it seems useful to determine next to mean value of the latency also its variance orstandard deviation, and to determine additionally the impact of random values on therespective message and on the overall execution time.

Further fields of investigation could be a comparison between shared secret-based mech-anisms (like EAP-PSK and EAP-PAX) and public key-based mechanisms like EAP-TLS.Anyway, EAP-TLS-PSK [128] which makes use of the shared secret-based TLS cipher-suites [52] will likely result a similar performance to the shared secret-based EAP methods.

EAP-TLS and EAP-TTLS could be as such further investigated, with main focus oncomparing the latency of different ciphersuites running on different machines. The goalcould be to determine and weight all parameters (like number of roundtrips, transmitteddata, number of hops in AAA infrastructure, and number and kind of cryptographic opera-tions) and to compile a closed formula for the expected latency.

5.2.2 Revision of EAP method requirements

The currently favorized application for EAP is in the context of network access authentica-tion in 802.11 Wireless LAN, which adopts the 802.1X framework for port-based networkaccess control. However, EAP is designed to be independent from its applications and there-fore EAP methods should not be designed having only this particular application in mind.That is, they could also address features beyond RFC 4017.

As mentioned earlier in the thesis, EAP is not only used in the scope of network accessauthentication, but also in higher layer protocols as enhanced authentication mechanism,like in TLS or IKEv2. If the underlying protocol that encapsulates EAP messages takescare for proper routing, like in case of IP, then EAP could also be used in HTTP, FTP, POP,and further protocols on application layer.

Consequently, also possible further applications beyond 802.11 Wireless LAN shouldbe taken into account. However, towards defining another requirement catalogue, RFC 4017seems to be good starting point for further investigation, because most of its requirementsare generally believed to be useful.

Requirements not mentioned in RFC 4017 are, for instance, explicit key confirma-tion, perfect forward secrecy, denial-of-service resistance, key confirmation (May an EAP

5.2 Open issues 135

method finish without that both sides have assured having derived the same session key?),negotiation of cryptographic parameters, active identity protection of the peer, and denia-bility.

Four of them are focused next.

Active Identity Protection: Passive identity protection is typically achieved by sendingthe identity encrypted over the network, so that an eavesdropper is not able to dis-cover it. Active identity protection means, that a party reveals its identity only if ithas the assurance to talk to the desired other party and not to an impostor. This featureis particularly helpful for the EAP peer. It is achieved when the EAP server authenti-cates himself prior to the peer, and when the peer’s identity is transmitted encryptedover the link. Currently, only EAP-IKEv2 offers this feature.

User identity confidentiality becomes more meaningful in the presence of wirelesshotspots and also when location information are transmitted. While passive user iden-tity confidentiality can also be obtained with symmetric cryptography, the other vari-ant can only accomplished with public key cryptography. The theoretic backgroundis given in [64].

Perfect Forward Secrecy (PFS): PFS stands for the confidence, that compromise of along-term secret key does not compromise keys of earlier sessions. Actually it isa very desireable feature, except that it requires a computationally expensive Diffie-Hellman key exchange.

Deniability: This protocol feature is certainly a very advanced one. Actually, deniabilitycontradicts the service of authentication because a deniable authentication protocolshould offer the possibility to authenticate the other party, but not allow to prove thata communication with this party has taken place. That is, a recorded session cannothanded to a judge as proof-of-communication.

Negotiation of cryptographic algorithms: In face of recent advances in the area of colli-sion-resistant hash functions, e.g. MD5 and SHA-1, it makes sense to re-think whethercryptographic protocols should not be made more flexible by incorporating negotia-tion or at least agility of cryptographic parameters.

Two recent voices might be of interest. In [99], H. Krawczyk and S. Halevi pointout the importance of the following two fundamental cryptographic design principles:”(i) Design protocols and applications such that the underlying cryptographic pieces(e.g., hash functions) are easy to replace when need arises (in particular, avoid hard-wiring of any specific construction into the application), and (ii) design as generalas possible mechanisms with as little as possible requirements from the basic cryp-tographic building blocks.” R. Housley recommends that the IETF should ”developalgorithm independent security protocols that include features to aid in the transitionfrom one mandatory-to-implement cipher suite to another one”5 rather than working

5www3.ietf.org/proceedings/05nov/slides/saag-1/saag-1.ppt

136 Future Work

on a new hash function as replacement.

5.2.3 Outstanding environmental analysis

Although RFC 3748 does not stipulate a certain effective key strength, all recent proposalsattempt to offer an effective key strength of 128 bit. As shown in Section 2.9.3, the compara-ble asymmetric key strength is approximately 3000-bit for RSA/DH. Unfortunately, publickey operations in this key size order are very expensive and lead to a significantly increasedlatency. The question arises whether all applications require an effective key strength of128-bit, or if not less might be sufficient, too.

There are alternative public key cryptosystems, like Elliptic Curve Cryptography, whichoperates with much smaller key sizes and promises better performance. However, there isno unique happiness when dealing with ECC, because it is widely believed that all goodelliptic curve algorithms are encumbered with IPR claims6. The use of algorithms withpatents pending is highly discouraged in the IETF. By the way, a similar problem occurs inthe context of strong password methods, which are thoroughly filed with patents, e.g. EKE,SPEKE and SRP. The question could arise whether there exists a non-IPR encumberedstrong password method at all - at present, however, none is known.

6”The rule of thumb for ECC is something like "ECC curves are divided into three groups, weak curves,inefficient curves, and curves patented by Certicom". (Peter Gutmann. August 2001. http://www.imc.org/ietf-openpgp/mail-archive/msg03514.html)

Chapter 6

Outlook

The thesis will conclude with an outlook on possible further developments in the context ofEAP.

EAP and IKEv3

In December 2005, the specification of IKEv2.1 has been published ([73]). It is basicallya combination of the core IKEv2 specification [91] and the clarifications of it [50]. Thereare motions in the IETF community to re-open IKEv2 (see [83] and follow-ups). Such adecision would require the foundation of a new IETF Working Group. It is concerned thatthis Working Group would take several years to produce an RFC, as every protocol detailwill have to be verified and discussed again.

However, possible working items could comprise negotiation of hash and signature al-gorithm (in particular for certificate handling), re-authentication, support of multiple EAPauthentications, revision of EAP authentication within IKEv2 and IKE over TCP and overSCTP. Since EAP methods compliant to RFC 3748 perform mutual authentication and keyderivation, the signature-based authentication of the EAP server would be re-analyzed (seealso Section 3.6.2.4). Possibly, an own method requirement catalogue will be defined.

Comparison of authentication frameworks

As mentioned at the beginning of Chapter 2, EAP is not the only authentication frameworkdeveloped in the IETF. There are some others, most notably TLS, IKEv2, SASL, and GSS-API. So the question arises which of these authentication frameworks is best suited forwhich application, or whether they could not converge. In fact, the EAP, GSS-API andSASL frameworks are very similar, since all focus on authentication and establishment ofa secure context. In those discussions, Kerberos as most popular GSS-API authenticationmechanism is oftentimes found.

Similar discussions took already place at the EAP BOF meeting in 1998, which is docu-mented in the meeting minutes ([10], see also page 11). Possibly, there is enough feedbackwhich would justify the foundation of a new IETF Working Group.

137

138 Outlook

Further EAP methods

It is expected that as consequence to the increased use of EAP, further EAP methods will beproposed. Instead of deploying a new cryptographic protocol, they could possibly also relyon a well-established and analyzed protocol like Oakley [125], JFK [12], or SIGMA [95].Also, new EAP methods which reflect current cryptographic research efforts are highlyforeseeable. For instance, the design of a particularly lightweight EAP method for resource-limited devices. These methods could make use of advanced cryptographic techniques ortake benefit from cryptographic research results.

In contrast, when designing new methods, cryptographic knowledge is required. Onedoes not need to develop a password-based authentication mechanism resistant to offlinepassword-guessing attacks that fully relies on symmetric cryptography - such a mechanismcannot exist. [64] points out that it would require the use of public key cryptography.

For illustrative purposes, we consider the SIGMA protocol [95] next. SIGMA is shortfor ”Sign-and-MAC-your-own-identity” and stands for a family of authenticated Diffie-Hellman key exchange protocols, which serve as cryptographic basis for both IKE andIKEv2. The SIGMA protocol has very desireable features, which have not been focusedyet by other EAP methods, but seems to be of high importance. These features comprise(a) perfect forward secrecy, (b) passive and active identity protection and (c) deniability(in contrast to non-repudation). In addition, the SIGMA protocol is minimal in terms ofcryptographic operations and messages, that is highly optimized.

[95] describes first a basic SIGMA protocol, which is subsequently enhanced by activeidentity protection. Depending on which identity (Initiator, Responder) is considered asmore sensitive and shall be protected against active attacks, two different SIGMA variantsresult, namely SIGMA-I and SIGMA-R. Regarding the EAP message flow, SIGMA-I (Fig-ure 6.1) seems to be more suitable.

(1) A→ B : gx

(2) A← B : gy,{B,SIGB(gx,gy),MACKm(B)}Ke

(3) A→ B : {A,SIGA(gy,gx),MACKm(A)}Ke

Figure 6.1: The SIGMA-I protocol

Perfect forward secrecy is obtained by the Diffie-Hellman key exchange. The Diffie-Hellman shared key is used to derive two subkeys, an encryption key Ke and an authenti-cation key Km, to as Km = prf(gxy) and Ke = prf(gxy). It is important that Ke and Kmare computationally independent, that is, knowledge of the one key does not lead to partialknowledge of the other one.

A signature can be used for non-repudation purposes, if it is computed over both partic-ipants identities and some value which binds the identities to the specific session. SIGMAdoes exactly the opposite in that only the sender’s identity is signed, but not the receiver’sone. In this sense, it provides deniability of the conversation in that the signature cannot

139

be used as proof-of-communication. Active identity protection means, that the identity issent encrypted and that the sender has gained assurance of the peer’s authenticity beforeauthenticating himself. As can be seen in Figure 6.1, A sends his identity first in message(3).

SIGMA-I consists of three messages, but since EAP requires message pairs, one mes-sage must carry other information. This is addressed by the first message of the server (3),which contains similar to EAP-TLS a ”Start” indication. The peer then initiates the SIGMAprotocol in the role as Initiator, consequently the EAP peer’s identity is protected againstactive attacks. It sends his identity first in message (6), when the EAP server has already au-thenticated himself to the peer. According to [95], the signature is extended over the MAC,and the Diffie-Hellman parameters are MACed before signing. Messages (5) and (6) reflectthese changes.


(3) A← B : EAP-Request / SIGMA-1 (Start)(4) A→ B : EAP-Response / SIGMA-2 (gx)

(5) A← B : EAP-Request / SIGMA-3 ( gy,{B, SIGB(MACKm(B,gx,gy))}Ke )(6) A→ B : EAP-Response / SIGMA-4 ( {A, SIGA(MACKm(A,gy,gx))}Ke )


Figure 6.2: EAP-SIGMA message flow (signature mode)

This protocol provides only signature-based authentication. If the signature in message(6) is omitted, a ”mixed mode” would result, which allows the peer to authenticate himselfby a shared secret, which could also be a password. The EAP server still authenticatesby means of a signature. By incorporating ideas from the SIGMA-P protocol [96], theEAP method could be completed by a shared-secret authentication mode. However, thesechanges must be done very carefully in order to maintain SIGMA’s security properties.

Further EAP deployments

Until the end of 2007, the EMU Working Group will hopefully have finished their work.This would result in three very mature EAP methods, namely the revised EAP-TLS, theshared secret-based method EAP-GPSK and a password-based method, which will be highlikely rely on the TLS handshake having a design very similar to EAP-TTLS. Together withEAP-SIM and EAP-AKA, the most common authentication token are then covered.

Given this set of standardized EAP methods, it is expected that EAP will be re-consideredby many existing protocols to enhance their authentication capabilities. Although EAP has

140 Outlook

been designed for network access authentication at link layer, there are no serious reasonsthat it could not be used within Upper Layer Protocols. For instance, EAP could enhanceauthentication within POP3, SMTP, HTTP, FTP or DNS.

In recent discussions, the usage of EAP in IEEE 802.1af bridge-to-bridge authentica-tion, or in the upcoming research field of wireless mesh networking were investigated. Butalso router and middleboxes, that is intermediary devices other than IP routers on the data-gram path between source and destination host - like Firewalls, NATs and Application LevelGateways, can benefit from EAP-based authentication. In summary, a lot of further appli-cations are expected.

Glossary

3GPP Third Generation Partnership Project

AAA Authentication, Authorization, Accounting

AES Advanced Encryption Standard

AKA Authentication and Key Agreement

AuC Authentication Center

BS Base Station

CA Certificate Authority

CBC Cipher Block Chaining

CCMP Counter mode with CBC-MAC Protocol

DES Data Encryption Standard

EAP Extensible Autentication Protocol

EAPOL EAP over LAN

EAPOW EAP over Wireless

ECC Elliptic Curve Cryptography

EMSK Extended Master Session Key

HLR Home Location Register

HMAC Hash-based Message Authentication Code

HTTP HyperText Transfer Protocol

GSM Global System for Mobile Communications

GTK Group Transient Key

IEEE Institute of Electrical and Electronical Engineers

141

142 Glossary

IETF Internet Engineering Task Force

IMSI International Mobile Subscriber Identity

IPR Intellectual Property Right

ISO International Standardization Organization

LAN Local Area Network

MAC (1) Message Authentication Code(2) Medium Access Control

MAP Mobile Application Part

MAN Metropolitan Local Area Network

MD5 Message Digest No. 5

MIC Message Integrity Check (used in IEEE as synonym for MAC)

MSK Master Session Key

MSS Mobile Subscriber Station

NAI Network Access Identifier

NASREQ Network Access Server Requirements (title of an IETF Working Group)

PAE Port Access Entity

PEAP Protected EAP

PKI Public Key Infrastructure

PKCS Public Key Cryptography Standards (of RSA Security Inc.)

PMK Pairwise Master Key

PPP Point-to-Point Protocol

PPPEXT Point-to-Point Protocol Extensions (title of an IETF Working Group)

PTK Pairwise Transient Key

RFC Request For Comments

RSN Robust Secure Network

RSNA RSN Architecture

RSNIE RSN Information Element

143

SIM Subscriber Identity Module

SRES Signed Response to Authentication Challenge

SRP Secure Remote Password

SS Subsciber Station

SSL Secure Sockets Layer

TKIP Temporal Key Integrity Protocol

TLS Transport Layer Security

TTLS Tunneled TLS

UMTS Universal Mobile Telecommunication System

USIM Universal Subscriber Identity Module

VLR Visitor Location Register

WEP Wired Equivalent Privacy

WAN Wide Area Network

WiFi Wireless Fidelity (trademark of Wi-Fi Alliance)

WiMAX Worldwide Interoperability for Microwave Access (trademark of WiMAX Fo-rum)

WLAN Wireless LAN

144 Glossary

Bibliography

[1] 3GPP TS 33.234. 3G Security. Wireless Local Area Network Interworking Security (Release6). http://www.3gpp.org/ftp/Specs/html-info/33234.htm

[2] 3GPP TR 22.934. Feasibility study on 3GPP system to Wireless Local Area Network(WLAN) interworking (Release 6); http://www.arib.or.jp/IMT-2000/V460Nov05/5_Appendix/Rel6/22/22934-620.pdf

[3] 3GPP TR 22.934. Feasibility study on 3GPP system to Wireles Local Area Network (WLAN)interworking. http://www.3gpp.org/ftp/Specs/html-info/22934.htm

[4] Michel Abdalla, Emmanuel Bresson, Olivier Chevassut, Bodo Möller, David Pointcheval.Provably Secure Password-Based Authentication in TLS. http://www.di.ens.fr/~pointche/Documents/Papers/2006_asiaccs.pdf; Extended abstract appeared atAsiaCCS’06, March 2006. http://dsd.lbl.gov/Projects/OPKeyX/Publications/ASIACCS06/asiaccs06.pdf

[5] Bernard Aboba, Larry Blunk, John Vollbrecht, J Carlson, Henrik Levkowetz. Extensible Au-thentication Protocol (EAP). RFC 3748, obsoletes RFC 2284. Category: Standards Track.June 2004.

[6] Bernard Aboba, Dan Simon. PPP EAP TLS Authentication Protocol. RFC 2716. CategoryExperimental. October 1999.

[7] Bernard Aboba, Dan Simon, Jari Arkko, Pasi Eronen, Henrik Levkowetz. Extensible Authen-tication Protocol (EAP) Key Management Framework. Internet-Draft. <draft-ietf-eap-keying-13.txt>. Mai 2006.

[8] Bernard Aboba, Pat R. Calhoun. RADIUS (Remote Authentication Dial In User Service)Support For Extensible Authentication Protocol (EAP). RFC 3579. Category: Informational.Updates RFC 2869. September 2003.

[9] Bernard Aboba, Mark A. Beadles, Jari Arkko, Pasi Eronen. The Network Access Identifier.RFC 4282. Category: Standards Track. Obsoletes RFC 2486. December 2005.

[10] Bernard Aboba. Minutes of Extensible Authentication Protocol BOF 43rd IETF, Friday, 11Dec 98. http://www3.ietf.org/proceedings/98dec/43rd-ietf-98dec-118.html

[11] Bernard Aboba. RADIUS Security Issues. NIST RADIUS Security Review. June 2005. http://www.drizzle.com/~aboba/RADEXT/NIST-RADIUS.ppt

[12] William Aiello. Steven M. Bellovin. Matt Blaze. Ran Canetti. John Ioannidis. Angelos D.Keromytis. Omer Reingold. Just Fast Keying: Key Agreement In A Hostile Internet. ACMTransactions on Information and System Security, Vol. 7, No. 2, May 2004, Pages 1-30.www.wisdom.weizmann.ac.il/~reingold/publications/jfk-tissec.pdf

[13] – Ambient Networks. D-7-2 Ambient Network Security Architecture. http://www.ambient-networks.org/publications/D7_2_Ambient_Network_Security_Architecture_PU.pdf

145

146 BIBLIOGRAPHY

[14] William A. Arbaugh. Your 802.11 Wireless Network has No Clothes. March 2001. http://www.cs.umd.edu/~waa/wireless.pdf

[15] William A. Arbaugh, Arunesh Mishra. An Initial Security Analysis of the IEEE 802.1X Pro-tocol. February 2002. http://www.cs.umd.edu/~waa/1x.pdf

[16] William A. Arbaugh. The Dangers of Mitigating Security Design Flaws: A Wireless CaseStudy. IEEE Security&Privacy, January / February 2003. http://www.cs.umd.edu/~waa/pubs/security-privacy-inductive.pdf

[17] Jari Arkko, Henry Haverinen. Extensible Authentication Protocol Method for 3rd GenerationAuthentication and Key Agreement (EAP-AKA). RFC 4187. January 2006.

[18] Jari Arkko, Pasi Eronen, Seppo Heikkinen, Hannes Tschofenig, Anand Prasad. Quick NAP -Secure and Efficient Network Access Protocol. Document IST-2002-507134-AN/WP7/D02.EU Project ”Ambient Networks”. December 2005. http://www.ambient-networks.org/publications/D%207_2_ANNEX_4_PU.pdf

[19] Nadarajah Asokan, Valtteri Niemi, Kaisa Nyberg. Man-in-the-Middle in Tunnelled Authen-tication Protocols. Cryptology ePrint Archive: Report 2002/163. November 2002. http://eprint.iacr.org/2002/163.pdf

[20] Mohamad Badra, Pascal Urien. EAP-Double-TLS Authentication Protocol. Internet-Draft.<draft-badra-eap-double-tls-04.txt>. October 2005.

[21] Mihir Bellare, Phillip Rogaway. Entity Authentication and Key Distribution. August 1993.

[22] Mihir Bellare, Philip Rogaway, David Wagner. The EAX Mode of Operation (A Two-PassAuthenticated Encryption Scheme Optimized for Simplicity and Efficiency). January 2004.http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf

[23] Steven M. Bellovin, Eric K. Rescorla. Deploying a New Hash Algorithm. September 2005.www.cs.columbia.edu/~smb/papers/new-hash.pdf

[24] Steven M. Bellovin, Michael Merritt. Encrypted Key Exchange: Password-Based ProtocolsSecure Against Dictionary Attacks, in Proc. IEEE Computer Society Symposium on Researchin Security and Privacy, May 1992. http://www.cs.columbia.edu/~smb/papers/neke.ps

[25] Florent Bersani, Hannes Tschofenig. The EAP-PSK protocol. Internet-Draft. <draft-bersani-eap-psk-10.txt>. February 2006.

[26] Simon Blake-Wilson, Nelson Bolyard, Vipul Gupta, Chris Hawk, Bodo Möller. ECC CipherSuites for TLS. Internet-Draft. <draft-ietf-tls-ecc-12.txt>. October 2005.

[27] Larry Blunk, John Vollbrecht. PPP Extensible Authentication Protocol (EAP). Internet-Draft. <draft-ietf-pppext-eap-auth-00.txt>. March 1995. http://bgp.potaroo.net/ietf/all-ids/draft-ietf-pppext-eap-auth-00.txt

[28] Larry Blunk, John Vollbrecht. PPP Extensible Authentication Protocol (EAP). RFC 2284.Standards Track. March 1998.

[29] Karl Boman, Günther Horn, Peter Howard, Valtteri Niemi. UMTS Security. Appeared in IEEElectronics & Communication Engineering Journal, Oct. 2002; http://net.informatik.uni-tuebingen.de/teaching/umts/pdf_ss05/UMTS%20Security%20IEE.pdf

[30] Nikita Borisov, Ian Goldberg, David Wagner. Intercepting Mobile Communications: The In-security of 802.11. Published in the proceedings of the Seventh Annual International Confer-ence on Mobile Computing And Networking, July 2001. http://www.cs.berkeley.edu/~daw/papers/wep-mob01.pdf

BIBLIOGRAPHY 147

[31] Colin Boyd. Towards Extensional Goals in Authentication Protocols; DIMACS Workshopon Design and Formal Verification of Security Protocols; September 1997. http://dimacs.rutgers.edu/Workshops/Security/program2/boyd.ps

[32] Colin Boyd, Anish Mathuria. Protocols for Authentication and Key Establishment. SpringerVerlag, 2003.

[33] Nancy Cam-Winget, Russ Housley, David Wagner, Jesse Walker. Security Flaws in 802.11Data Link Protocols. Communications of the ACM. May 2003. http://www.cs.berkeley.edu/~daw/papers/wireless-cacm.pdf

[34] Nancy Cam-Winget, David Mc Grew, Joseph Salowey, Hao Zhou. The Flexible Authentica-tion via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST). Internet-Draft. <draft-cam-winget-eap-fast-03.txt>. October 2005.

[35] Nancy Cam-Winget, David Mc Grew, Joseph Salowey, Hao Zhou. Dynamic Provisioning us-ing EAP-FAST. Internet-Draft. <draft-cam-winget-eap-fast-provisioning-01.txt>. July 2005.

[36] P. Chown. Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security(TLS). RFC 3268. June 2002.

[37] Cisco Systems. EAP-FAST Deployment Guide. July 2004. http://www.cisco.com/application/pdf/en/us/guest/products/ps4076/c1067/ccmigration_09186a00802623a2.pdf

[38] Jyh-Cheng Chen, Ming-Chia Jiang, Yi-Wen Liu: Wireless LAN Security and IEEE 802.11i.Appeared in IEEE Wireless Communications. February 2005. http://icat2.snu.ac.kr:8080/IP_origin/paper/upload/2005-08-204306c9ae53_icat4.pdf

[39] T. Charles Clancy. William Arbaugh. EAP Password Authenticated Exchange. <draft-clancy-eap-pax-06.txt>. Internet-Draft. January 2006.

[40] T. Charles Clancy (ed.), Hannes Tschofenig (ed.). EAP Generalized Pre-Shared Key (EAP-GPSK) <draft-clancy-emu-eap-shared-secret-00.txt>. Internet-Draft. May 2006.

[41] Anupam Datta, Changhua He, John C. Mitchell, Arnab Roy, Mukund Sundararajan. 802.16eNotes - Mitchell Group. Electrical Engineering and Computer Science Departments StanfordUniversity. June 2005.http://www.iab.org/liaisons/ieee/EAP/802.16eNotes.pdf

[42] Tim Dierks, Christopher Allen. The TLS Protocol Version 1.0. RFC 2246. Category: Stan-dards Track. October 1999.

[43] Tim Dierks. Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1. RFC4346. Obsoletes RFC 2246. Category: Standards Track. April 2006.

[44] Danny Dolev. Andrew C. Yao. On Security of Public Key Protocols. IEEE Transactions onInformation Theory, IT-30 (1983) 198-208.

[45] Minutes of the EAP BOF IETF 53 Minneapolis, MN Wednesday, March 20, 2002. http://www.drizzle.com/~aboba/EAP/eapbof.txt

[46] ECRYPT. Network of Excellence in Cryptology. Yearly Report on Algorithms and KeyLengths (2005), updated in January 2006. http://www.ecrypt.eu.org/documents/D.SPA.16-1.0.pdf

[47] ECRYPT. Network of Excellence in Cryptology. Recent Collision Attacks on Hash Func-tions: ECRYPT Position Paper. February 2005. http://www.ecrypt.eu.org/documents/STVL-ERICS-2-HASH_STMT-1.1.pdf

[48] Carl Ellison, Bruce Schneier. Ten Risks of PKI: What You’re Not Being Told About Pub-lic Key Infrastructure. Computer Security Journal, v16, no. 1, 2000, pp. 1-7. http://www.schneier.com/paper-pki.pdf

148 BIBLIOGRAPHY

[49] EAP Method Update Working Group. Official website. http://www1.ietf.org/html.charters/emu-charter.html

[50] Pasi Eronen, Paul Hoffman. IKEv2 Clarifications and Implementation Guidelines. Internet-Draft. <draft-eronen-ipsec-ikev2-clarifications-09.txt>. May 2006.

[51] Pasi Eronen, Hannes Tschofenig. Extension for EAP Authentication in IKEv2. Internet-Draft.<draft-eronen-ipsec-ikev2-eap-auth-04.txt>. October 2005.

[52] Pasi Eronen (ed.), Hannes Tschofenig (ed.). Pre-Shared Key Ciphersuites for Transport LayerSecurity (TLS). RFC 4279. December 2005.

[53] Pasi Eronen (ed.), Tom Hiller, Glen Zorn. Diameter Extensible Authentication Protocol (EAP)Application. RFC 4072. Category: Standards Track. August 2005.

[54] Scott Fluhrer, Itsik Mantin, Adi Shamir. Weaknesses in the Key Scheduling Algorithm ofRC4. http://www.cs.umd.edu/~waa/class-pubs/rc4_ksaproc.ps

[55] Paul Funk, Simon Blake-Wilson. EAP Tunneled TLS Authentication Protocol (EAP-TTLS).Internet-Draft. <draft-ietf-pppext-eap-ttls-05.txt>. July 2004.

[56] Paul Funk, Simon Blake-Wilson, Ned Smith, Hannes Tschofenig, Thomas Hardjono.TLS Inner Application Extension (TLS/IA). Internet-Draft. <draft-funk-tls-inner-application-extension-01.txt>. February 2005.

[57] Paul Funk, Simon Blake-Wilson. EAP Tunneled TLS Authentication Protocol Version 1(EAP-TTLSv1). <draft-funk-eap-ttls-v1-01.txt>. March 2006.

[58] Rosario Gennaro. Randomness in Cryptography. Security & Privacy Magazine, IEEE Volume4, Issue 2, March-April 2006, Pages 64-67.

[59] Henri Gilbert. The Security of ”One-Block-to-Many” Modes of Operation.LNCS 2887/2003. http://perso.rd.francetelecom.fr/bersani/EAP_PSK/SecurityOneBlockToMany-GILBERT.pdf

[60] Vipul Gupta, Douglas Stebila, Stephen Fung, Sheueling Chang, Nils Gura, Hans Eberle.Speeding up Secure Web Transactions using Elliptic Curve Cryptography (ECC), appearedin Network and Distributed System Security (NDSS) Symposium Conference Proceedings:2004. http://www.douglas.stebila.ca/research/papers/GSFCGE04.pdf

[61] Vipul Gupta, Sumit Gupta, Sheueling Chang. Performance Analysis of Elliptic CurveCryptography for SSL. September 2002. http://research.sun.com/projects/crypto/performance.pdf

[62] IEEE 802.1X for IEEE 802.11 ( D. Halasz, S. Norman, G. Zorn, B. Aboba, T. Moore, CiscoSystems) IEEE 802.11 Document 00/275. http://grouper.ieee.org/groups/802/11/Documents/DocumentHolder/0-275.zip

[63] Dave Halasz. TGe Security Baseline. Cisco Systems. IEEE 802.11 Document 00(419. http://grouper.ieee.org/groups/802/11/Documents/DocumentHolder/0-419.zip

[64] Shai Halevi, Hugo Krawczyk. Public-key cryptography and password protocols. February1999. http://www.research.ibm.com/security/pub-passw.ps

[65] Kory Hamzeh, Gurdeep Singh Pall, William Verthein, Jeff Taarud, W. Andrew Little, GlenZorn. Point-to-Point Tunneling Protocol (PPTP). RFC 2637. Category: Informational. July1999

[66] Dan Harkins (ed.), Dave Carrel (ed.). The Internet Key Exchange (IKE). RFC 2409. Category:Standards Track. November 1998.

BIBLIOGRAPHY 149

[67] Henry Haverinen (ed.), Joe Salowey (ed.). Extensible Authentication Protocol Method forGlobal System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM).RFC 4186. January 2006.

[68] Changhua He, John C. Mitchell. Security Analysis and Improvements for IEEE802.11i. http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/NDSS05-1107.pdf

[69] Stephen Kent, Ran Atkinson. Security Architecture for the Internet Protocol. November 1998.RFC 2401.

[70] Don Piper. The Internet IP Security Domain of Interpretation for ISAKMP. RFC 2407.November 1998.

[71] D. Maughan,M. Schertler, M. Schneider, J. Turner. Internet Security Association and KeyManagement Protocol (ISAKMP). RFC 2408. November 1998.

[72] Dan Harkins, Dan Carrell. The Internet Key Exchange (IKE). RFC 2409. November 1998.

[73] Paul Hoffman. Internet Key Exchange Protocol: IKEv2.1. Internet-Draft. <draft-hoffman-ikev2-1-00.txt>. December 2005.

[74] IEEE 802.1X-2004. IEEE Standards for Local and metropolitan area network. Port-Based Network Access Control. http://standards.ieee.org/getieee802/download/802.1X-2004.pdf

[75] IEEE P802.16e/D12, October 2005. Draft IEEE Standard for Local and metropolitan areanetworks.Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems.Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mo-bile Operation in Licensed Bands.

[76] IEEE Std 802.16-2001. IEEE Standard for Local and metropolitan area networks.Part 16: Air Interface for Fixed Broadband Wireless Access Systems. http://standards.ieee.org/getieee802/download/802.16-2001.pdf

[77] IEEE Std 802.16-2004. Draft IEEE Standard for Local and metropolitan area networks.Part 16: Air Interface for Fixed Broadband Wireless Access Systems. http://standards.ieee.org/getieee802/download/802.16-2004.pdf

[78] IEEE 802.11, 1999 Edition. IEEE Standards for Information Technology.Telecommunications and Information Exchange between Systems. Local and MetropolitanArea Network.Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifi-cationshttp://standards.ieee.org/getieee802/download/802.11-1999.pdf

[79] Supplement to 802.11-1999,Wireless LAN MAC and PHY specifications: Higher speedPhysical Layer (PHY) extension in the 2.4 GHz band; http://standards.ieee.org/getieee802/download/802.11b-1999.pdf

[80] IEEE 802.11g-2003. IEEE Standard for Information Technology.Telecommunications and information exchange between systems. Local and MetropolitanArea Networks.Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifica-tionsAmendment 4: Further Higher-Speed Physical Layer Extension in the 2.4 GHz Bandhttp://standards.ieee.org/getieee802/download/802.11g-2003.pdf

150 BIBLIOGRAPHY

[81] Amendment to IEEE Std 802.11, 1999 Edition (Reaff 2003). IEEE Standard for Informa-tion technology–Telecommunications and information exchange between system–Local andmetropolitan area networks?Specific requirements–Part 11: Wireless LAN Medium AccessControl (MAC) and Physical Layer (PHY) specifications–Amendment 6: Medium AccessControl (MAC) Security Enhancementshttp://standards.ieee.org/getieee802/download/802.11i-2004.pdf

[82] Draft Amendment to STANDARD FOR Information Technology - Telecommunications andInformation Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wire-less Medium Access Control (MAC) and physical layer (PHY) specifications: Amendment 2:Fast BSS Transition; <P802.11r-D1.1.pdf>; January 2006.

[83] — IPsec Mailing List. http://www1.ietf.org/mail-archive/web/ipsec/current/msg01925.html

[84] Tetsu Iwata, Kaoru Kurosawa. OMAC: One-Key CBC MAC. Fast Software Encryption, FSE2003, LNCS 2887, pp. 129–153. Springer-Verlag (2003/02/24–26, Lund, Sweden). Updatedversion is posted on IACR ePrint (2003/03/10). http://crypt.cis.ibaraki.ac.jp/omac/docs/omac.pdf

[85] The OMAC website. http://crypt.cis.ibaraki.ac.jp/omac/omac.html

[86] Tetsu Iwata. Comparison of CBC MAC Variants and Comments on NIST’s Consultation Pa-per. May 2003. crypt.cis.ibaraki.ac.jp/omac/docs/omac-cm2.pdf

[87] David Jablon. Strong Password-Only Authenticated Key Exchange. October 1996. http://www.jablon.org/jab96.pdf

[88] David Jablon. Extended Password Key Exchange Protocols Immune to Dictionary Attacks.June 1997. http://www.jablon.org/jab97.pdf

[89] David Johnston, Jesse Walker. Overview of IEEE 802.16 Security. IEEE Security&Privacy.May/June 2004.www.kjhole.com/Seminar/Spring2005/PDF/802.16sec.pdfhttp://people.cs.vt.edu/~kafura/cs6204/Readings/Wireless/Overview802.16Protocol.pdf

[90] Burt Kaliski. PKCS #5: Password-Based Cryptography Specification Version 2.0. RFC 2898.September 2000.

[91] Charlie Kaufman (ed.). Internet Key Exchange (IKEv2) Protocol. RFC 4306. (Obsoletes RFC2407, 2408, 2409). December 2006.

[92] Steven Kent. Ran Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406. Category:Standards Track. Obsoletes RFC 1827. November 1998.

[93] Tero Kivinen. M. Koio. More Modular Exponential (MODP) Diffie-Hellman groups for In-ternet Key Exchange (IKE). RFC 3526. Category: Standards Track. May 2003.

[94] Geir M. Køien. Privacy Enhanced Cellular Access Security. ACM WiSe 2005, This paperwon the "Best Paper Award", Köln, Germany, September 2005.

[95] Hugo Krawczyk. The SIGMA Family of Key-Exchange Protocols. Crypto’03 (LNCS Series,Vol. 2729), http://www.ee.technion.ac.il/~hugo/sigma.ps

[96] Hugo Krawczyk. The IKE-SIGMA Protocol, November 2001. http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt

[97] Hugo Krawczyk. On JFK design and a comparison with SIGMA, http://www.ee.technion.ac.il/~hugo/compare-jfk-sigma.txt

BIBLIOGRAPHY 151

[98] Hugo Krawczyk, Mihir Bellare, Ran Canetti. HMAC: Keyed-Hashing for Message Authenti-cation. RFC 2104. Category: Informational. February 1997.

[99] Hugo Krawczyk, Shai Halevi. Strengthening Digital Signatures via Randomized Hashing.Internet-Draft. <draft-irtf-cfrg-rhash-00.txt>. May 2005.

[100] Fang-Chun Kuo, Hannes Tschofenig, Fabian Meyer, and Xiaoming Fu. Comparison Stud-ies between Pre-Shared Key and Public Key Exchange Mechanisms for Transport LayerSecurity (TLS). Technical Report No. IFI-TB-2006-01, Institute for Informatics, Univer-sity of Göttingen, January 2006. http://user.informatik.uni-goettingen.de/~fkuo/publications/ptls-ifi-tb-2006-01.pdf

[101] Kirstin Lauter. The Advantages of Elliptic Curve Cryptography for Wireless Security.IEEE Wireless Communications. February 2004. research.microsoft.com/~klauter/IEEEfinal.pdf

[102] B. Lloyd. William Simpson. PPP Authentication Protocols. RFC 1334. October 1992.

[103] John L. MacMichael. Auditing wi-fi protected access (WPA) pre-shared key mode. LinuxJournal. September 2005. http://www.linuxjournal.com/article/8312

[104] Ari Medvinsky, Matthew Hur. Addition of Kerberos Cipher Suites to Transport Layer Security(TLS). RFC 2712. Category: Standards Track. October 1999.

[105] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone. Handbook of Applied Cryptog-raphy. CRC Press. Revised Reprint with Updates, 1997.

[106] Arunesh Mishra, Nick L. Petroni Jr., William Arbaugh, Timothy Fraser, "Security Issuesin IEEE 802.11 Wireless Local Area Networks: A Survey" in Wiley Interscience WirelessCommunications and Mobile Computing Journal (Wiley Wireless), Vol 4 No 8, December,2004.

[107] Chris Mitchell. On the Security of XCBC, TMAC and OMAC. August 2003. http://www.ma.rhul.ac.uk/techreports/2003/RHUL-MA-2003-4.ps

[108] Nagendra Modadugu, Eric Rescorla. AES Counter Mode Cipher Suites for TLS and DTLS.Internet-Draft. <draft-ietf-tls-ctr-00.txt>. February 2006.

[109] Shiho Moriai, Akihiro Kato, Masayuki Kanda. Addition of Camellia Cipher Suites to Trans-port Layer Security (TLS). RFC 4132. Category: Standards Track.

[110] Robert Moskowitz. Weakness in Passphrase Choice in WPA Interface. November 2003.http://wifinetnews.com/archives/002452.html

[111] Netscape Communications. SSL 3.0 Specification. 1996. http://wp.netscape.com/eng/ssl3/

[112] National Institute of Standards and Technology (NIST). Guidelines for the Selection and Useof Transport Layer Security (TLS) Implementations. NIST Special Publication 800-52. June2005.

[113] National Institute of Standards and Technology (NIST). Digital Signature Standard. FIPSPUB 186-2. January 2000.

[114] National Institute of Standards and Technology (NIST). A change notice for FIPS 186-2,Digital Signature Standard (DSS). October 2001.

[115] National Institute of Standards and Technology (NIST). Secure Hash Standard. FIPS PUB180-1. April 1995.

[116] National Institute of Standards and Technology (NIST). Secure Hash Signature Standard(SHS). FIPS PUB 180-2. August 2002.

152 BIBLIOGRAPHY

[117] National Institute of Standards and Technology (NIST). Recommendation for Block CipherModes of Operation: The CMAC Mode for Authentication. SP 800-38B. May 2005.

[118] National Institute of Standards and Technology (NIST). Recommendation for Block CipherModes of Operation: the CCM Mode for Authentication and Confidentiality. SP 800-38C.May 2004.

[119] National Institute of Standards and Technology (NIST). Key Management Guide-line Workshop Document, November 2001. http://csrc.nist.gov/encryption/kms/key-management-guideline-(workshop).pdf

[120] NESSIE consortium. NESSIE security report. Deliverable 20, Version 2.0. February 2003.https://www.cosic.esat.kuleuven.ac.be/nessie/deliverables/D20-v2.pdf

[121] Valtteri Niemi. Kaisa Nyberg. UMTS Security. Hardcover, 286 pages. November 2003.Sample chapter at http://media.wiley.com/product_data/excerpt/48/04708479/0470847948.pdf

[122] Kaisa Nyberg. CRYPTOGRAPHIC ALGORITHMS FOR UMTS. July 2004. www.tcs.hut.fi/Studies/T-79.159/articles/nyberg.pdf

[123] Magnus Nystrom. The Protected One-Time Password Protocol (EAP-POTP). Internet-Draft.<draft-nystrom-eap-potp-04.txt>. December 2005.

[124] Hilarie Orman, Paul Hoffman. Determining Strengths For Public Keys Used For ExchangingSymmetric Keys. RFC 3766. Category: Best Current Practice. April 2004.

[125] Hilarie Orman. The OAKLEY Key Determination Protocol. RFC 2412. Category: Informa-tional. November 1998.

[126] Thomas Otto. Netzwerkauthentifizierung im WLAN. Pre-master thesis. April 2004. http://www.ibr.cs.tu-bs.de/theses/schmidt/otto_eap/otto_eap.pdf

[127] Thomas Otto. ”Bug in IKEv2 shared secret authentication?”. http://www1.ietf.org/mail-archive/web/ipsec/current/msg01980.html. February 2006.

[128] Thomas Otto, Hannes Tschofenig. The EAP-TLS-PSK Authentication Protocol. Internet-Draft. <draft-otto-emu-eap-tls-psk-00.txt>. April 2006.

[129] Sarvar Patel. Analysis of EAP-SIM Session Key Agreement. http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf

[130] Lawrence C. Paulson. Inductive Analysis of the Internet Protocol TLS. University of Cam-bridge. www.cl.cam.ac.uk/users/lcp/papers/Auth/tls.pdf

[131] Carl Rigney, Allan C. Rubens, William Allen Simpson, Steve Willens. Remote AuthenticationDial In User Service (RADIUS). RFC 2865. Category: Standards Track. Obsoletes RFC 2138.June 2000.

[132] Carl Rigney. RADIUS Accounting. RFC 2866. Category: Informational. Obsoletes RFC2139. June 2000.

[133] Carl Rigney, Ward Willats, Pat Calhoun. RADIUS Extensions. RFC 2869. Category: Infor-mational. June 2000.

[134] Ron Rivest. The MD5 Message-Digest Algorithm. RFC 1321. April 1992.

[135] Apostolis K. Salkintzis. Interworking Techniques and Architectures for WLAN/3G Inte-gration Towards 4G Mobile Data Networks. http://evolute.intranet.gr/WLAN-3G_Interworking_towards_4G.pdf; revised version appeared in IEEE Wireless Communica-tions, June 2004. ieeexplore.ieee.org/iel5/7742/29047/01308950.pdf?arnumber=1308950

BIBLIOGRAPHY 153

[136] Joseph Salowey. H Zhou, Pasi Eronen, Hannes Tschofenig. Transport Layer Security Ses-sion Resumption without Server-Side State. Internet-Draft. <draft-salowey-tls-ticket-06.txt>December 2005.

[137] Joseph Salowey. Specification for the Derivation of Usage Specific Root Keys (USRK)from an Extended Master Session Key (EMSK). <draft-salowey-eap-emsk-deriv-00.txt>. Mai2006.

[138] Dan Simon, Bernard Aboba. The EAP TLS Authentication Protocol. <draft-simon-emu-rfc2716bis-01.txt>. Internet-Draft. Category: Proposed Standard. February 2006. http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-01.txt

[139] William Simpson (ed.). The Point-to-Point Protocol (PPP). RFC 1661. Standards Track. July1994.

[140] William Simpson. PPP Challenge Handshake Authentication Protocol (CHAP). RFC 1994(obsoletes RFC 1334).

[141] Dorothey Stanley, Jesse Walker, Bernard Aboba. Extensible Authentication Protocol (EAP)Method Requirements for Wireless LANs. RFC 4017. Category: Informational. March 2005.

[142] Michael Steiner. Peter Buhler, Thomas Eirich, Michael Waidner. Secure Password-Based Ci-pher Suite for TLS. first published in Symposium on Network and Distributed Systems Se-curity (NDSS ’00), San Diego, CA, February 2000; Internet Society. http://www.semper.org/sirene/publ/BESW_00EKETLS.ps.gz; updated and extended in: ACM Transactionson Information and System Security, 4(2), 2001. http://www.semper.org/sirene/publ/SBEW_01EKETLS.pdf

[143] Adam Stubblefield, John Ioannidis, Aviel D. Rubin. Using the Fluhrer, Mantin, and ShamirAttack to Break WEP. http://ftp.die.net/mirror/papers/802.11/wep_attack.pdf

[144] Takehiro Takahashi. WPA Cracker. http://www.michiganwireless.org/tools/WPA-Cracker/ http://www.tinypeap.com/html/wpa_cracker.html

[145] David Taylor, Tom Wu, Nikos Mavrogiannopoulos, Trevor Perrin. Using SRP for TLS Au-thentication. Internet-Draft. <draft-ietf-tls-srp-10.txt>. October 2005.

[146] Hannes Tschofenig, Dirk Kroeselberg, Yoshihiro Ohba, Florent Bersani. EAP IKEv2 Method(EAP-IKEv2). Internet-Draft. <draft-tschofenig-eap-ikev2-10.txt>. February 2006.

[147] Mayank Upadhyay, Merlin. Minutes of the EAP BOF IETF 53 Minneapolis, MN Wednesday,March 20, 2002. http://www.drizzle.com/~aboba/EAP/eapbof.txt

[148] Michaela Vanderveen, Hesham Soliman. Extensible Authentication Protocol Method forShared-secret Authentication and Key Establishment (EAP-SAKE). Internet-Draft. <draft-vanderveen-eap-sake-02.txt>. May 2006.

[149] John Vollbrecht, Pasi Eronen, Nick Petroni, Yoshihiro Ohba. State Machines for ExtensibleAuthentication Protocol (EAP) Peer and Authenticator. RFC 4137. August 2005.

[150] Jesse Walker. Discussion of the 802.1X and 802.11 Security Models. IEEE 802.11 Document00/035. http://grouper.ieee.org/groups/802/11/Documents/DocumentHolder/0-035.zip

[151] Jesse Walker. Bob Beach. An Overview of the GSS-API and Kerberos. IEEE802.11 Document 00/292. http://grouper.ieee.org/groups/802/11/Documents/DocumentHolder/0-292.zip

[152] Jesse Walker. Bob Beach. The GSS-API as an 802.11 Security Service. Proposal by Inteland Symbol. IEEE 802.11 Document 00/293. http://grouper.ieee.org/groups/802/11/Documents/DocumentHolder/0-293.zip

154 BIBLIOGRAPHY

[153] Jesse Walker. IEEE 802.11i Standard Improves Wireless LAN Security. Technology@IntelMagazine. May 2005. http://www.intel.com/technology/magazine/standards/80211i-0505.pdf

[154] Jesse Walker. Unsafe at any key size; An analysis of the WEP encapsulation. IEEE 802.11Document 00/365. October 2000. http://www.dis.org/wl/pdf/unsafe.pdf

[155] X. Wang, X. Lai, D. Feng, H. Chen and X. Yu, Cryptanalysis of the Hash Func- tions MD4and RIPEMD, Advances in Cryptology-EUROCRYPT 2005, R. Cramer (Ed.), LNCS 3494,Springer-Verlag, pp. 1-18, 2005. 42.

[156] X. Wang and H. Yu, How to Break MD5 and Other Hash Functions, Advances in Cryptology-EUROCRYPT 2005, R. Cramer (Ed.), LNCS 3494, Springer-Verlag, pp. 19-35, 2005. 43.

[157] X. Wang, Y. L. Yin and H. Yu, Finding Collisions in Full SHA-1, Advances in Cryptology-CRYPTO 2005, V. Shoup (Ed.), LNCS 3621, Springer-Verlag, pp. 17- 36, 2005.

[158] Wi-Fi Alliance. WPA Deployment Guidelines for Public Access Wi-Fi Networks October2004. http://www.weca.net/opensection/pdf/WPA_for_Public_Access_Final.pdf

[159] Wi-Fi Alliance. Best Current Practises for Wireless Internet Service Provider (WISP) Roam-ing. February 2003. http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf

[160] WiMax report: WiMax: The critical standard. 33 pages, Caroline Gabriel. Arcchart. October2003 XXX www.arcchart.com/pr/blueprint/pdf/BluePrint_WiFi_REPORT_I.pdf

[161] WiMAX Forum. WiMAX End-to-End Network Systems Architecture. Stage 2: Ar-chitecture Tenets, Reference Model and Reference Points. November 29th 2005.051129_NWG_Stage2.doc

[162] Joshua Wright. CoWPAtty. coWPAtty is designed to audit the security of pre-shared keysselected in WiFi Protected Access (WPA) networks. http://sourceforge.net/projects/cowpatty

[163] Joshua Wright. Asleap. Open source tool which recovers weak LEAP password. July 2004.http://asleap.sourceforge.net

[164] Joshua Wright. Weaknesses in LEAP Challenge/Response. Defcon 2003. http://home.jwu.edu/jwright/presentations/asleap-defcon.pdf

[165] Thomas Wu. The Secure Remote Password Protocol. Stanford University. http://www.isoc.org/isoc/conferences/ndss/98/wu.pdf

[166] Muxiang Zhang, Yuguang Fang. Security Analysis and Enhancements of 3GPP Authenti-cation and Key Agreement Protocol, September 2003. http://www.fang.ece.ufl.edu/mypaper/tw05zhang.pdf

Appendix

155

Appendix A. EAP type numbers

0 RESERVED

1 Identity∗

2 Notification∗

3 Legacy Nak∗

4 MD5-Challenge∗

5 One-Time Password (OTP)∗

6 Generic Token Card (GTC)∗

7 Allocated∗

8 Allocated∗

9 RSA Public Key Authentication

10 DSS Unilateral

11 KEA

12 KEA-VALIDATE

13 EAP-TLS

14 Defender Token (AXENT)

15 RSA Security SecurID EAP

16 Arcot Systems EAP

17 EAP-Cisco Wireless

18 GSM Subscriber Identity Modules (EAP-SIM)

19 SRP-SHA1

20 available

21 EAP-TTLS

22 Remote Access Service

23 EAP-AKA Authentication

24 EAP-3Com Wireless

25 PEAP

26 MS-EAP-Authentication

27 Mutual Authentication w/Key Exchange (MAKE)

28 CRYPTOCard

29 EAP-MSCHAP-V2

30 DynamID

31 Rob EAP

32 SecurID EAP

33 MS-Authentication-TLV

34 SentriNET

35 EAP-Actiontec Wireless

36 Cogent Systems Biometrics Authentication EAP

37 AirFortress EAP

38 EAP-HTTP Digest

39 SecureSuite EAP

40 DeviceConnect EAP

41 EAP-SPEKE

42 EAP-MOBAC

43 EAP-FAST

44 ZoneLabs EAP (ZLXEAP)

45 EAP-Link

46 EAP-PAX

47-191 AVAILABLE via review by Designated Expert∗

192-253 RESERVED for allocation via Standards Action∗

254 RESERVED for the Expanded Type∗

255 EXPERIMENTAL∗

∗ as defined in RFC 3748Source: http://www.iana.org/assignments/eap-numbers

Appendix B. TLS Ciphersuites

TLS 1.0 ciphersuites

Code CipherSuite Key Exchange Cipher Hash

0x00 TLS_NULL_WITH_NULL_NULL NULL NULL ULL

0x01 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5

0x02 TLS_RSA_WITH_NULL_SHA RSA NULL SHA

0x04 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5

0x05 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA

0x07 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA

0x09 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA

0x0A TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA

0x0C TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA

0x0D TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA

0x0F TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA

0x10 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA

0x12 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA

0x13 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA

0x15 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA

0x16 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA

0x18 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5

0x1A TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA

0x1B TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA

DHE_DSS = Ephemeral DH with DSS signaturesDHE_RSA = Ephemeral DH with RSA signaturesDH_anon = Anonymous DH, no signaturesDH_DSS = DH with DSS-based certificatesDH_RSA = DH with RSA-based certificatesNULL = No Key ExchangeRSA = RSA key exchange

RFC 3268 - AES Ciphersuites


0x2F TLS_RSA_WITH_AES_128_CBC_SHA RSA AES-128 SHA

0x30 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES-128 SHA

0x31 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES-128 SHA

0x32 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES-128 SHA

0x33 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES-128 SHA

0x34 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES-128 SHA

0x35 TLS_RSA_WITH_AES_256_CBC_SHA RSA AES-256 SHA

0x36 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES-256 SHA

0x37 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES-256 SHA

0x38 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES-256 SHA

0x39 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES-256 SHA

0x3A TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES-256 SHA

RFC 4279 ciphersuites


0x8A TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA

0x8B TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA

0x8C TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA

0x8D TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA

0x8E TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA

0x8F TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA

0x90 TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA

0x91 TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA

0x92 TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA

0x93 TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA

0x94 TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA

0x95 TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA

Appendix C. IKEv2 transform types

Values above the specified algorithms up to 1023 are reserved to IANA, and the values1024-65535 are for private use among mutually consenting parties.

Transform Type 1 - Encryption Algorithm (ENCR)

0 RESERVED1 ENCR_DES_IV64 (RFC1827)2 ENCR_DES (RFC2405), [DES]3 ENCR_3DES (RFC2451)4 ENCR_RC5 (RFC2451)5 ENCR_IDEA (RFC2451), [IDEA]6 ENCR_CAST (RFC2451)7 ENCR_BLOWFISH (RFC2451)8 ENCR_3IDEA (RFC2451)9 ENCR_DES_IV3210 RESERVED11 ENCR_NULL (RFC2410)12 ENCR_AES_CBC (RFC3602)13 ENCR_AES_CTR (RFC3664)

Transform Type 2 - Pseudo-random Function (PRF)

0 RESERVED1 PRF_HMAC_MD5 (RFC2104), [MD5]2 PRF_HMAC_SHA1 (RFC2104), [SHA]3 PRF_HMAC_TIGER (RFC2104)4 PRF_AES128_XCBC (RFC3664)

Transform Type 3 - Integrity Algorithm (INTEG)

0 NONE1 AUTH_HMAC_MD5_96 (RFC2403)2 AUTH_HMAC_SHA1_96 (RFC2404)3 AUTH_DES_MAC4 AUTH_KPDK_MD5 (RFC1826)5 AUTH_AES_XCBC_96 (RFC3566)

Transform Type 4 - Diffie-Hellman Group (D-H)

0 NONE1-2 Defined in Appendix B3-4 RESERVED5 Defined in [ADDGROUP]6-13 RESERVED TO IANA14-18 Defined in [ADDGROUP]19-1023 RESERVED TO IANA1024-65535 PRIVATE USE

DH Group 1 is a 768-bit group with the prime 2768−2704−1+264 · (2638π+149686).DH Group 2 is a 1024-bit group. The prime is 21024−2960−1+264 · (2894π+129093).The generator is as usual g=2.[ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-

Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.The document defines new Modular Exponential (MODP) Groups for the Internet Key

Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, andalso defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numberedstarting at 14. The selection of the primes for theses groups follows the criteria establishedby Richard Schroeppel.

• 1536 bit: p = 21536−21472−1+264 · (21406π+741804)

• 2048 bit: p = 22048−21984−1+264 · (21918π+124476)

• 3072 bit: p = 23072−23008−1+264 · (22942π+1690314)

Appendix D. EMU WG - proposed working items

In the following, all proposed potential work items which were negotiated at the EMU BOFat 64th IETF Meeting are presented.

1. Revision of EAP-TLS, to be placed on the standards track. The primary goal of thiswould be to bring the specification up to date, clarify unclear issues, etc. A standardstrack specification would also enable the consideration of EAP-TLS as a mandatoryrequirement in other Proposed Standard specifications.Note that there are limitations in current implementations which may need to be con-sidered during this update. Similarly, the existing EAP-TLS specification may notaccommodate all types of extensions in a backwards compatible manner. For in-stance, there may be issues in adding channel binding support or the use of new TLSmechanisms such as TLS PSK when run against RFC 2716 compliant devices. Theseissues shall be investigated and clarified; the revised EAP-TLS must be backwardscompatible with existing deployment.

2. Shared Secret - a pre-shared secret method. This is likely to be widely deployed ifavailable, and another likely candidate to be referred to by other Proposed Standardspecifications. Desired by IEEE 802.11.

3. Password based - essentially a shared secret mechanism that provides resistance todictionary attacks. It should support various backend databases of password that usedifferent storage techniques and perhaps support for one time tokens as well. Coulduse something related to EKE or a tunneling approach. Desired by IEEE 802.11, andwould likely be widely deployed if available.

4. One time passwords - a secure one-time password -based mechanism that can providekeying material.

5. Tunneling - a tunneling method is useful to protect weaker authentication mecha-nisms. Tunneling methods are also used to exchange other types of authenticationdata.

6. Channel binding support - it has been suggested that new methods should have anability to authenticate identifiers claimed by NASes. But it has also been suggestedthat backwards compatible extensions to do this in a few commonly used currentmethods should be developed for security reasons. Similarly, for the ability to re-tain EAP method and media indepedence, it may be necessary to have coordinatedapproach or even binding data formats between different methods.

7. Enrollment mechanisms - methods to automatically enroll clients in wireless environ-ments. However, this list should not be taken as a proposal but rather as a templatethat can be used to determine community consensus on which of the items are worth-while. It is certainly impossible to take on ALL of the above tasks, so a set of 3-4

priority tasks needs to be determined. There may also be IPR, complexity, or existingdeployment concerns that make it undesirable to take on work for a specific item.

Source: http://www3.ietf.org/proceedings/05nov/emu.html

Extensible Network Access Authentication - CiteSeerX

Documents

Transcript of Extensible Network Access Authentication - CiteSeerX