Multi-Factor Authentication Systems with higher level of authentication needs multiple credentials to be presented for user validation. Such process of authentication is referred to as multi-factor authentication. Each one of the supplied credential can fall in one of the three categories:
Something you know (e.g passwords, pin)
Something you are (e.g Bio-metrics such as finger prints, picture, retina)
Something you have (e.g. Security token, Mobile number for OTP, Debit Card)
When only two credentials (each from different category) are provided then it is referred to as two-factor authentication. Different Supplicants
One which comes integrated with OS - Works with most hardware
Windows XP Wireless Zero Configuration (WZC)
Windows 7 Supplicant
Apple's Airport Client
Chipset Vendor Supplicant
Intel's PROSet Client
WLAN vendor Supplicant: Works only with vendor radios.
Ones which are provided by Netgear, DLink etc
Third Party Supplicant - works with different chipsets & OS
Juniper Networks's OAC
Different Authentication Servers
Cisco ACS [RADIUS based]
Juniper Steel Belted RADIUS [RADIUS based]
Microsoft IAS (Windows Server 2003) [RADIUS based]
Microsoft NAP (Windows Server 2008) [RADIUS based]
Microsoft Active Directory 2003 and higher [Kerberos and LDAP]
FreeRADIUS (open source) [RADIUS based]
Configuring RADIUS and Access Points
Authenticator needs to know RADIUS server's IP address & UDP port along with a shared secret (required to validate & encrypt the communication link between authenticator and authentication server)
Normally, authenticator is provided with a prioritized list of authentication servers. Usually, up to three RADIUS servers are configured for redundancy purpose.
Authentication server needs to know the authenticator's IP address and shared secret in order to communicate with the authenticator.
RADIUS uses UDP port 1812 for authentication and 1813 for accounting. Prior to this official assignment by IANA 1645 & 1646 respectively were used by most vendors.
RADIUS assigned VLAN Helps to assign VLAN to different users hence, no need to have separate SSIDs for segregation of different users. RADIUS based MAC ACL Here both username and password can be filled with MAC address Realm & NAS Identifier Username & password can be accompanied by a domain name or realm that might tell the RADIUS server which master database to use. Options while using Digital Certificates
Public Key Infrastructure [PKI]
You maintain your private PKI
Self Signed Certificates
Server certificate needs to be deployed to each client
Recommended, if distributing server certificate is not a problem then self signed certificates is the best option.
Note: List of "trusted root authorities" s sometimes referred to as a "Certified Trust List". Verisign is one of the trusted root authority.
User Database: Windows Active Directory & LDAP Server
Needs certificate on both Server and Client side. Due to client side certificate requirement it is costly to implement.
Needs public key infrastructure(PKI).
Normally, it does not create tunnel to pass the client certificate to the server as tunnel is not required for passing the client certificate. However in privacy mode, a tunnel is created.
Tunneled Methods: In these methods, a TLS tunnel is established between authentication server and supplicant using server certificate. The purpose of establishing a tunnel is to protect the information provided by the supplicants.
EAP-TTLS (defined in RFC 5281)
EAP-PEAPv0(outer authentication) / EAP-MSCHAPv2(inner authentication): Microsoft
EAP- PEAPv0 (outer authentication) / EAP-TLS (inner authentication): Microsoft
Instead of using standards based X.509 digital certificates, it uses Protected Access Credentials (PACs).
PACs can be automatically provisioned on the clients by the server or can be manually configured by the administrator.
PACs contain symmetric keys. Hence, EAP-FAST has advantage of performance when compared to methods using asymmetric keys.
In May 2009, Wi-Fi added EAP-FAST to the WPA2 interoperability certification.
These methods supports mutual authentication. i.e. both authentication server and supplicant are validated.
In tunneled methods, supplicant has two identities (outer and inner). The outer identity is effectively a bogus user name and inner one is the true identity. The outer identity is seen is clear text as it is prior to setting encrypted tunnel however, inner identity is sent within the tunnel.
EAP-PEAPv0 / EAP-MSCHAPv2 is most popular among tunneled methods as Microsoft was the dominant player in both server and client operating system.
EAP-PEAP cam after EAP-TTLS but size of Microsoft & Cisco enables it to surpass TTLS.
PEAP is often referred as "EAP inside EAP"
Microsoft OS does not provide support for EAP-PEAPv1.
EAP-TTLS supports just about anything for inner authentication whereas EAP-PEAP is very selective. Methods such as legacy methods PAP, CHAP, MS-CHAP and MS-CHAPv2 and also the EAP-Protocols e.g. EAP-MSCHAPv2 are supported are supported in EAP-TTLS. But support of EAP-TTLS is much smaller than EAP-PEAP.
Designed for 2G (GSM) networks.
It does not offer mutual authentication.
Designed for 3G (UMTS & CDMA2000) networks.
Supports mutual authentication.
EAP-TLS vs TLS
TLS (SSL3.0) secure communication at the transport layer of the OSI model however, EAP-TLS works at L2 layer.
There are two old (but standard) methods of roaming as described in 802.11i. These are:
PMK Caching (done only when security is 802.1x /WPA2-Enterprise)
This method is also called PMKID Caching or PMKSA Caching or Sticky Key Caching
In this method, PMKSA is cached by the AP and by the client. One should note that PMKSA is specific to a combination of AP and client. Hence, each AP will have separate PMKSA cached for each client (same is true for client). This demands for high memory at AP and client and hence a bottleneck for scalable roaming.
When a client needs to move to new AP, it first checks its cache for PMKSA for that AP. In case, the cache has PMKSA for that AP it will send re-association request to that AP with PMKID included in RSN information element. However, if there is no matching entry in the cache it will go for either full authentication or pre-authentication if it is enabled.
The other issue is that client needs to get authenticated with all access points before it has PMKSA cached for them.
Note: Client provides PMKID only when moving in same ESS i.e. from one BSSID to another inside same ESS. When moving to different ESS (different SSID) it does not include PMKID.
This method sits on top of PMK caching. i.e. PMKSA caching is enabled.
When a client decided to move to new AP and does not have PMKSA cached then its starts pre-authentication with new access point with out breaking association with current access point. In case both AP and client supports OKC then client should calculate PMKID for the new AP (even if was not authenticated with this AP) and send it using RSN IE.
Pre-authentication starts with EAPOL-Start frame to current AP. However, pre-authentication frames have ether type (88-C7) as opposed on standard EAPOL frames (ether type is 88-8E).
Pre-authentication frame fields look like:
DA: BSSID of target AP
BSSID: BSSID of current AP
SA: Client source address.
Pre-authentication frames are destined to target AP but sent through current AP.
Using pre-authentication, client authenticates with target AP. Traget AP then caches PMKSA for this client.
After pre-authentication stage is complete, the client directly send association request (authentication frames are skipped) with PMKID just established. This way the costly authentication process with new AP is complete with breaking existing data connection with current AP.
Pre-authentication is indicated by access point by RSN Capabilities in RSN IE.
FT or 802.11r is first WiFi standard which offers standardized & scalable WFi roaming solution. Prior to this Pre-authentication & PMKSA caching (recommended in 802.11i) were based on PMKSA caching rather PMK due to which these methods were not scalable. Another roaming method OKC is scalable as it is basedon PMK caching however, OKC is not a standard roaming method. Refer to this post for some basics on roaming. Key Hierarchy: Even though, FT can be used for Controller-less deployments but it was designed by keeping controller and thin APs architecture in mind. In this architecture, instead of access points, controller act as authenticator and is responsible for keys derivation and distribution to access points. In this architecture:
Controller is identified by PMKR0KH-ID acts as PMKR0-Key Holder.
Access Point is identified by PMKR1KH-ID acts as PMKR1-Key Holder.
PMKR0 is identified by its name PMKR0Name. (same as PMKR0ID)
PMKR1 is identified by its name PMKR1Name. (same as PMKR1ID)
PMKR0 is derived by controller from MSK/PMK using PMKR0KH-ID as input. Hence, PMKR0 is dependent on controller identifier.
PMKR1 is derived by controller from PMKR0 using PMKR1KH-ID as input and is responsible for distributing these keys to access points. Hence, PMKR1 can be different for each access point if all access points are configured with different identifier. It is possible to configure each AP with same identifier.
Information Elements [IEs] Changes
Holds PMKRxName (PMKRxID to be more precise)
AKM suite is updated to include FT.
MDIE (new): Mainly holds Mobility Domain identifier & whether Over-the-DS mode is supported. As it holds mobility domain identifier, it is present in all frames related to 802.11r. However, its presence inside Beacons, Probe Response (from AP) & Association request (from stations) indicates 802.11r support on AP & station respectively.
FTIE (new): This IE holds PMKR0KH-ID, PMKR1KH-ID (always) & additionally PTK Key derivation material such as ANounce, SNounce, MIC & GTK) (in re-association request & response frames).
Over-the-air mode is mandatory but over-the-ds mode is optional. If access point supports both modes then client will attempt over-the-ds mode.
When FT is enabled, some non FT stations (which cannot decode updated RSNIE) might not be able to connect.
FT is even faster than PSK roaming because 4-Way handshake is eliminated.
4-Way handshake is modified as now key data includes FTIE, RSNIE & MDIE.
Initial Mobility Domain Association:
In controller less environment or when PSK is used then its the responsibility of the initial AP to derives PMKR1-key for other key holders (access points in same mobility domain) and pass message to them so that other APs can build their PMKR1Key cache.
Over the Air Transition:
Over the DS Transition:
UPDATE: Why over-the-ds mode can be better when both access points are on different channels? (source) Over the DS vs Over the Air: Negotiation with the next AP can happen over the air, or over the DS. With "over the air", the client gets to the edge of the first cell, scans, finds another AP, and negotiates directly with this next AP the next key (and possibly QoS parameters). The advantage of this method is that communication is direct (no delay by going through the DS, not need for AP to AP wired communication protocol). The downside is that the client needs to leave its active channel to negotiate on another channel. Most BYODs send a frame to their current AP, telling them that they "go to sleep" (Null frame with Power Management set to 1, while in fact they go negotiate on another channel), then return to the active channel to "empty their and the AP buffer" (Null frame with Power management set to 0) before jumping out to the next AP. The over the air process is direct, but may be disrupting in a location where the device is already at the edge of the cell (low data rate, lots of retries). To avoid that the negotiation also forces the device to go off channel for a while, the Over the DS method can be enabled. In this case, the device stays on the current channel (no need to pretend to sleep and leave the channel), and asks the current AP to negotiate with the next AP (your client still has to discover the next AP first, i.e. scan). This process saves time and increases efficiency, provided that both APs have a way to communicate. In a controller-based network, no problem. The unknown is in the efficiency (what is faster: direct negotiation, or going through the current AP, the WLC, then the next AP, with all the switches or routers that may be on the way?). The only answer is to test (or know your network, if APs are on the same switch and the WLC is close, DS is great. Add routers and switches, and the needle switches toward Over the air).
Its wonderful to have voice calls over WiFi Network as it saves a lot of cost (especially for long distance calls). However, there are two big requirements for having good quality voice calls on WiFi network and these are covered under following WiFi alliance certifications:
Voice Personal: Relates with QoS requirements for voice on single access point so as voice can have low latency and low jitter.
Voice Enterprise: Relates to voice performance on multiple access points especially station movement from one access point to another.
BSS Transition: Movement of client from one BSS to another under the same ESS. Each BSS can be under same or different sub-net.
Mobility Domain: Group of access points across which a station can quickly roam. These access points can be under same or different sub-net.
Layer 2 Roaming: When a client moves from one BSS to another (with in the same sub-net).
Layer 3 [IP] Roaming: When a client moves from one BSS to another (each in different sub-net). Moving from one sub-net to another normally involves IP change. Hence, layer 3 roaming is trickier than layer 2 roaming. Vendors either implement proprietary tunneling methods or Mobile IP to preserve the IP.
Inter AP handover: Roaming often involves data exchange from one access point to another. However, communication between different access points is not defined in 802.11 standard. Vendors are free to implement their own mechanisms.
For layer 2 roaming, this can be simple broadcast message or a layer 2 uni-cast packet.
For layer 3 roaming, it has to a uni-cast message from one access point to another.
Mobility Domain is the group of access points which knows the IP (or MAC or both) of other access points in that group.
Inter access point communication should be secure.
When a VoIP phone moves from one access point during a call there is layer 2 connectivity transfer which leads to frame loss depending on time it takes for connectivity transfer. Large time can lead to call drop. In order to avoid call drop, connectivity transfer (roaming) time should be less than 50 msecs. However, when WPA2-enterprise level security is used then it generally takes 700 msecs for the station to authenticate and connect (that too when authentication server is on LAN). To overcome this large roaming time while using robust security mechanisms becomes the objective of roaming techniques.
Clients can authenticate themselves based on different type of credentials, such as:
Username & password
Pre-shared keys (PSK)
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.