Clients can authenticate themselves based on different type of credentials, such as:
- Username & password
- Digital Certificate
- Pre-shared keys (PSK)
- Smart Card
- RFID tags
- Dynamic security token devices
- Protected Access Credential (PACs)
Each different credential demands different "Authentication Protocol" (we will defer information about which credential needs which protocol to another post). Hence, to accommodate different authentication protocols an authentication framework was required which can accomodate all present and future authentication protocols. EAP was answer to that question for PPP links. EAP was later extended to authentication in WiFi.
- EAP was designed for PPP protocol (where PPP provides information aboutdestination and source). Hence, EAP inherently does not have any such information.
- EAPOL adds source and destination MAC information to EAP frame.
- Packet Type: A new field added by EAPOL. Possible values:
- EAPOL Packet: Contains an encapsulated EAP frame (the original frame shown above).
- EAPOL Start: Instead of waiting for a challenge from the authenticator, the supplicant can issue an EAPOL-Start frame. In response, the authenticator sends an EAP-Request/Identity frame.
- EAPOL Logoff : When a system is done using the network, it can issue an EAPOL-Logoff frame to return the port to an unauthorized state.
- EAPOL Key: EAPOL can be used to exchange cryptographic keying information. All EAPOL frames exchanged during 4 Way key handshake are EAPOL-Key frame which has the following structure.
- EAPOL is limited to L2 network (only MAC addresses) by design as supplicant does not have any IP address before authentication.To talk to authentication server, authenticator needs to have L3 protocol. This protocol can be RADIUS or Diameter.
- RADIUS is based on UDP and the communication between RADIUS server and client is secured. Frames exchanged between RADIUS server and client along with their direction are:
- Generic EAP exchange looks like:
- RADIUS server checks IP address of RADIUS client and validates shared secret before answering. i.e Data sent by client is encrypted using shared secret. For this to work, server should have mapping between ip address of client and shared secret.
- Realm: Its define the user account location. Check here.
- RADIUS message contains a set of RADIUS defined attributes (IETF defined and proprietary). Hence, message sent by supplicant needs to fill these attributes.
- Supplicant has an identity and some credentials (password, certificate etc) to prove that is is who it claims to be.
- In the IETF world, authenticator is referred to as Network Access Server (NAS) or RADIUS Client.