To improve the security of Authentication phase in wireless client connections 802.1X & EAP (Extensible Authentication Protocol) has been introduced into wireless standards. There are 3 key roles in this process. Client, Authentication server & Authenticator (WLC in Unified deployment or AAP in Autonomous deployment)
Usually 802.1x communication happens between Client & Authenticator where as Authenticator to Authentication server it would be RADIUS protocol. EAP defines headers for the typical packets used in an authentication exchange between Client & Authentication Server.
As shown in the above, there are 4 different type of EAP packets exchange between client & server.
1. EAP Request : Used by Authenticator to ask supplicant’s identity
2. EAP Response: Used by Supplicant to send requested information
3. EAP Success : Used by Authenticator to indicate authentication succeeded.
4. EAP Failure : Used by Authenticator to indicate authentication failed.
There are 3 common EAP types available & depend on Clients & Authentication server’s capability it will choose a EAP type to associate with a wireless network.
1. EAP-FAST (EAP- Flexible Authentication via Secure Tunnel)
2. PEAT (Protected Extensible Authentication Protocol)
3. EAP-TLS (EAP- Transport Layer Security)
With all EAP methods, Open System authentication first takes place with an Authentication Request, Authentication Response, Association Request & Association Response. Once Open System Authentication phase completes, EAP starts.
During authentication, the client & RADIUS server derive a PMK (Pairwise Master Key) for data encryption. This key is unique to each session of a given client. For broadcast & multicast traffic it will use a GTK (Group Transient Key) which is common to all clients.
Out of the 3 EAP methods, EAP-TLS would be the most secured method. Both Client & Authentication Server use certifcates through a PKI (Public Key Infrastructure). Though it is most secure, client certificate management would be a burden. Below show the EAP-TLS packet flow.
In PEAP, supplicant does not have a certificate which reduce the administrative burden of implementing EAP-TLS. PEAP exist in two flavors
1. PEAPv0 -MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2)
2. PEAPv1 -GTc (Generic Token Card)
Below shows the PEAP packet flow.
Out of the 3 method EAP-FAST is Cisco’s version of implementation. It uses PAC (Protected Access Credential) file instead of certificate. The PAC contain server Authority ID (A-ID), a client encryption/decryption key & a PAC opaque section with encrypted client key. Only EAP-FAST server generate PAC can decrypt PAC Opaque section. There are 3 phases (called 0,1 & 2) of EAP-FAST show in the below (Phase 0 in the first diagram & Phase 1-2 in second diagram).
Pingback: WPA notes |
Great thank you very much !
Thanks a lot, this was really helpful.
Will you help me in understanding how msk will get generated ?
Nikhila Vemuri said:
Do you have any lectures created over this concept? If yes, could you please share the link.
There is no recorded video from my end.
Pingback: Wireless – JD's Notepad
Anton K. said:
Can you explain, who will be responsable for EAP method to choose? For example if server accepts EAP-PEAP and EAP-TLS (Cisco ISE with default access protocols in authentication policy for example) then how will be chosen exectly EAP-TLS for particular client?
If RADIUS server allows multiple EAP-Method, then it will allow what client ask for. If client ask to do PEAP, then RADIUS server go with it.
Same goes with cipher suite to be used. Client will provide list of cipher suites that it support and then RADIUS server pick one that need to be used
Ambarish Almelkar said:
I am looing for any source of information on testing EAP-AKA and EAP-AKA Prime authentication methods.
To verify this on a real-time scenario, a test SIM would be required in order to program Milenage algorithm keys.
Any vendor who I can reach for the test SIMS?