In the 802.1x Authentication Overview blog we established that EAP is layer 2 protocol used within the 802.1X framework to validate users and devices. Further that EAP is very flexible in that there are many different flavors of EAP or EAP methods available. Some are proprietary such as Cisco LEAP while others are standards-based such as EAP-TLS. Some provide mutual authentication while others do not. Some require both server and client side certificates, while some require just server side certificates; others don’t require certificates at all. Some use usernames and passwords, others use tokens. Some support machine or computer authentication while others don’t. Some send credentials inside an encrypted tunnel resulting in stronger security while others do not. This blog is focused on the most common EAP method, EAP-PEAPv0 (EAP-MSCHAPv2).

EAP-PEAP
To talk about EAP-PEAPv0 (EAP-MSCHAPv2) we must first talk about EAP-Protected Extensible Authentication Protocol (EAP-PEAP), also known simply as PEAP. Like EAP, PEAP also offers flexibility as there are multiple flavors. Again this blog is focused on EAP-PEAPv0 (EAP-MSCHAPv2). Unlike EAP that has one supplicant identity and phase however, PEAP has two. The supplicant identities are often called inner and outer. The outer identity is effectively a bogus username sent in clear text outside of a TLS encrypted tunnel. The outer identity for many supplicants is often “anonymous” however this is configurable in some supplicants. The inner identity is the true identity of the supplicant sent protected inside an encrypted TLS tunnel. Thus the word “protected”. This is especially important for wireless because EAP occurs during the 802.1X authentication process, before wireless frames are encrypted. We mentioned above that PEAP also has two phases. The outer identity is sent in phase 1 in the clear and the inner identity is sent in phase 2 encrypted. Don’t confuse this encryption with the Layer 2 encryption used to encrypt wireless data over the air such as AES/TKIP. This encrypted TLS tunnel is created and only exists for a matter of milliseconds with the sole purpose of providing a secure channel to protect the user credentials. A key point is that in order to establish a TLS tunnel, it is required to install a server side certificate on the RADIUS Server. See the EAP-PEAP – Certificate Requirements blog for further information on cert requirements. PEAPv0 refers to the outer EAP method and is the mechanism used in phase 1 to create a secure TLS tunnel to protect subsequent authentication transactions in phase 2. Because the TLS channel established in phase 1 protects subsequent authentication transactions in phase 2, password-based authentication protocols that are normally susceptible to offline dictionary attacks like MS-CHAPv2 can be used for authentication. EAP-MSCHAPv2 is referred to as the inner EAP method.

EAP-PEAPv0 (EAP-MSCHAPv2)
EAP-PEAPv0 EAP-Microsoft Challenge Handshake Authentication Protocol v2 (EAP-MSCHAPv2) also known simply as PEAP-MSCHAPv2 is a mutual authentication method that supports password-based user or computer authentication. EAP-PEAPv0 (EAP-MSCHAPv2) is the most common form of PEAP in use today as it uses simple usernames and passwords instead of complex client side certificates and has extensive operating system support including Microsoft Windows, Apple OS X/iOS, Linux, Android, etc. Although we are starting to see certificate-based methods such as EAP-TLS gain popularity with Mobile Device Managements and onboarding solutions simplifying the provisioning, distribution and management of certificates. EAP-MSCHAPv2 is referred to as the inner EAP method. MSCHAPv2 defined in RFC-2759, is Microsoft’s version of CHAP (Challenge Handshake Authentication Protocol). Like CHAP, the password of the user identity is encrypted using a hash. Microsoft initially developed MS-CHAP as a proprietary version of CHAP and subsequently released MS-CHAPv2 to address security vulnerabilities in MS-CHAP. MS-CHAPv2 introduced a much stronger hashing algorithm and also added support for mutual authentication during the MS-CHAPv2 exchange. Like MS-CHAP however, MS-CHAPv2 has since been found vulnerable and should only be used inside a TLS tunnel.

802.1X/EAP-PEAPv0 (EAP-MSCHAPv2) Exchange

Machine/Computer Authentication
EAP-PEAPv0 (EAP-MSCHAPv2) machine authentication may also be referred to as computer authentication. Machine authentication allows the domain machine or computer to authenticate before the user logs in using host/machine name (host/computername.domain) as the username and the computer’s domain machine account password as the password. The domain machine account password is automatically created when the computer is registered to the domain. This allows group policies to be applied and login scripts to execute when the user logs in. This also allows a user who does not have a locally cached profile on the domain computer to login. Machine authentication emulates the full “wired” experience. Without machine authentication you will not be able to apply group policy and run login scripts to map drives, connect printers, etc. Users who have not logged on to the domain computer before will not be able to login. If you do not require group policy, login scripts, or the ability for non-cached domain users to login you may not be required to implement machine authentication.

Microsoft Windows 7 computer authentication is enabled by default

Fast Reconnect/Session Resumption
Fast Reconnect, also known as Session Resumption, allows for faster re-authentication and roaming between access points by both the client and server caching the TLS session created during PEAP Phase 1 after a successful PEAP Phase 2 authentication. Upon subsequent re-authentication, the session can be resumed by going through a simpler and shorter TLS handshake process and skipping the inner authentication method. This typically results in an overall  50% reduction in traffic exchanged with the RADIUS server however roam times typically require up to approximately 300ms to complete. Roam times may be longer if for example the RADIUS server was over a WAN circuit. Although this is a significant improvement over full authentication, Fast Reconnect/Session Resumption is still not fast enough to support real time applications such as voice over IP. Fast reconnect is an optional feature of PEAP. If you intend to use it, it must be enabled on both the client and RADIUS server.