Extensible Authentication Protocol

Last updated

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC   3748, which made RFC   2284 obsolete, and is updated by RFC   5247. EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages.

Contents

EAP is in wide use. For example, in IEEE 802.11 (Wi-Fi) the WPA and WPA2 standards have adopted IEEE 802.1X (with various EAP types) as the canonical authentication mechanism.

Methods

EAP is an authentication framework, not a specific authentication mechanism. [1] It provides some common functions and negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined. Methods defined in IETF RFCs include EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA, and EAP-AKA'. Additionally, a number of vendor-specific methods and new proposals exist. Commonly used modern methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, LEAP and EAP-TTLS. Requirements for EAP methods used in wireless LAN authentication are described in RFC   4017. The list of type and packets codes used in EAP is available from the IANA EAP Registry. [2]

The standard also describes the conditions under which the AAA key management requirements described in RFC   4962 can be satisfied.

Lightweight Extensible Authentication Protocol (LEAP)

The Lightweight Extensible Authentication Protocol (LEAP) method was developed by Cisco Systems prior to the IEEE ratification of the 802.11i security standard. [3] Cisco distributed the protocol through the CCX (Cisco Certified Extensions) as part of getting 802.1X and dynamic WEP adoption into the industry in the absence of a standard. There is no native support for LEAP in any Windows operating system, but it is widely supported by third-party client software most commonly included with WLAN (wireless LAN) devices. LEAP support for Microsoft Windows 7 and Microsoft Windows Vista can be added by downloading a client add in from Cisco that provides support for both LEAP and EAP-FAST. Due to the wide adoption of LEAP in the networking industry many other WLAN vendors[ who? ] claim support for LEAP.

LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected and easily compromised; an exploit tool called ASLEAP was released in early 2004 by Joshua Wright. [4] Cisco recommends that customers who absolutely must use LEAP do so only with sufficiently complex passwords, though complex passwords are difficult to administer and enforce. Cisco's current recommendation is to use newer and stronger EAP protocols such as EAP-FAST, PEAP, or EAP-TLS.

EAP Transport Layer Security (EAP-TLS)

EAP Transport Layer Security (EAP-TLS), defined in RFC   5216, is an IETF open standard that uses the Transport Layer Security (TLS) protocol, and is well-supported among wireless vendors. EAP-TLS is the original, standard wireless LAN EAP authentication protocol.

EAP-TLS is still considered one of the most secure EAP standards available, although TLS provides strong security only as long as the user understands potential warnings about false credentials, and is universally supported by all manufacturers of wireless LAN hardware and software. Until April 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo. [5] There are client and server implementations of EAP-TLS in 3Com, Apple, Avaya, Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft, and open source operating systems. EAP-TLS is natively supported in Mac OS X 10.3 and above, wpa_supplicant, Windows 2000 SP4, Windows XP and above, Windows Mobile 2003 and above, Windows CE 4.2, and Apple's iOS mobile operating system.

Unlike most TLS implementations of HTTPS, such as on the World Wide Web, the majority of implementations of EAP-TLS require mutual authentication using client-side X.509 certificates without giving the option to disable the requirement, even though the standard does not mandate their use. [6] [7] Some have identified this as having the potential to dramatically reduce adoption of EAP-TLS and prevent "open" but encrypted access points. [6] [7] On 22 August 2012 hostapd (and wpa_supplicant) added support in its Git repository for an UNAUTH-TLS vendor-specific EAP type (using the hostapd/wpa_supplicant project RFC   5612 Private Enterprise Number), [8] and on 25 February 2014 added support for the WFA-UNAUTH-TLS vendor-specific EAP type (using the Wi-Fi Alliance Private Enterprise Number), [9] [10] which only do server authentication. This would allow for situations much like HTTPS, where a wireless hotspot allows free access and does not authenticate station clients but station clients wish to use encryption (IEEE 802.11i-2004 i.e. WPA2) and potentially authenticate the wireless hotspot. There have also been proposals to use IEEE 802.11u for access points to signal that they allow EAP-TLS using only server-side authentication, using the standard EAP-TLS IETF type instead of a vendor-specific EAP type. [11]

The requirement for a client-side certificate, however unpopular it may be, is what gives EAP-TLS its authentication strength and illustrates the classic convenience vs. security trade-off. With a client-side certificate, a compromised password is not enough to break into EAP-TLS enabled systems because the intruder still needs to have the client-side certificate; indeed, a password is not even needed, as it is only used to encrypt the client-side certificate for storage. The highest security available is when the "private keys" of client-side certificate are housed in smart cards. [12] This is because there is no way to steal a client-side certificate's corresponding private key from a smart card without stealing the card itself. It is more likely that the physical theft of a smart card would be noticed (and the smart card immediately revoked) than a (typical) password theft would be noticed. In addition, the private key on a smart card is typically encrypted using a PIN that only the owner of the smart card knows, minimizing its utility for a thief even before the card has been reported stolen and revoked.

EAP-MD5

EAP-MD5 was the only IETF Standards Track based EAP method when it was first defined in the original RFC for EAP, RFC   2284. It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise. EAP-MD5 differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication. By not providing EAP server authentication, this EAP method is vulnerable to man-in-the-middle attacks. [13] EAP-MD5 support was first included in Windows 2000 and deprecated in Windows Vista. [14]

EAP Protected One-Time Password (EAP-POTP)

EAP Protected One-Time Password (EAP-POTP), which is described in RFC   4793, is an EAP method developed by RSA Laboratories that uses one-time password (OTP) tokens, such as a handheld hardware device or a hardware or software module running on a personal computer, to generate authentication keys. EAP-POTP can be used to provide unilateral or mutual authentication and key material in protocols that use EAP.

The EAP-POTP method provides two-factor user authentication, meaning that a user needs both physical access to a token and knowledge of a personal identification number (PIN) to perform authentication. [15]

EAP Pre-Shared Key (EAP-PSK)

[1] EAP Pre-shared key (EAP-PSK), defined in RFC   4764, is an EAP method for mutual authentication and session key derivation using a pre-shared key (PSK). It provides a protected communication channel, when mutual authentication is successful, for both parties to communicate and is designed for authentication over insecure networks such as IEEE 802.11.

EAP-PSK is documented in an experimental RFC that provides a lightweight and extensible EAP method that does not require any public-key cryptography. The EAP method protocol exchange is done in a minimum of four messages.

EAP Password (EAP-PWD)

EAP Password (EAP-PWD), defined in RFC   5931, is an EAP method which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack.

EAP-PWD is in the base of Android 4.0 (ICS). It is in FreeRADIUS [16] and Radiator [17] RADIUS servers, and it is in hostapd and wpa_supplicant. [18]

EAP Tunneled Transport Layer Security (EAP-TTLS)

EAP Tunneled Transport Layer Security (EAP-TTLS) is an EAP protocol that extends TLS. It was co-developed by Funk Software and Certicom and is widely supported across platforms. Microsoft did not incorporate native support for the EAP-TTLS protocol in Windows XP, Vista, or 7. Supporting TTLS on these platforms requires third-party Encryption Control Protocol (ECP) certified software. Microsoft Windows started EAP-TTLS support with Windows 8, [19] support for EAP-TTLS [20] appeared in Windows Phone version 8.1. [21]

The client can, but does not have to be authenticated via a CA-signed PKI certificate to the server. This greatly simplifies the setup procedure since a certificate is not needed on every client.

After the server is securely authenticated to the client via its CA certificate and optionally the client to the server, the server can then use the established secure connection ("tunnel") to authenticate the client. It can use an existing and widely deployed authentication protocol and infrastructure, incorporating legacy password mechanisms and authentication databases, while the secure tunnel provides protection from eavesdropping and man-in-the-middle attack. Note that the user's name is never transmitted in unencrypted clear text, improving privacy.

Two distinct versions of EAP-TTLS exist: original EAP-TTLS (a.k.a. EAP-TTLSv0) and EAP-TTLSv1. EAP-TTLSv0 is described in RFC   5281, EAP-TTLSv1 is available as an Internet draft. [22]

EAP Internet Key Exchange v. 2 (EAP-IKEv2)

EAP Internet Key Exchange v. 2 (EAP-IKEv2) is an EAP method based on the Internet Key Exchange protocol version 2 (IKEv2). It provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:

Asymmetric key pairs
Public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party.
Passwords
Low-entropy bit strings that are known to both the server and the peer.
Symmetric keys
High-entropy bit strings that are known to both the server and the peer.

It is possible to use a different authentication credential (and thereby technique) in each direction. For example, the EAP server authenticates itself using public/private key pair and the EAP peer using symmetric key. However, not all of the nine theoretical combinations are expected in practice. Specifically, the standard RFC   5106 lists four use cases: The server authenticating with an asymmetric key pair while the client uses any of the three methods; and that both sides use a symmetric key.

EAP-IKEv2 is described in RFC   5106, and a prototype implementation exists.

EAP Flexible Authentication via Secure Tunneling (EAP-FAST)

Flexible Authentication via Secure Tunneling (EAP-FAST; RFC   4851) is a protocol proposal by Cisco Systems as a replacement for LEAP. [23] The protocol was designed to address the weaknesses of LEAP while preserving the "lightweight" implementation. Use of server certificates is optional in EAP-FAST. EAP-FAST uses a Protected Access Credential (PAC) to establish a TLS tunnel in which client credentials are verified.

EAP-FAST has three phases: [24]

PhaseFunctionDescriptionPurpose
0In-band provisioning—provide the peer with a shared secret to be used in secure phase 1 conversationUses Authenticated Diffie-Hellman Protocol (ADHP). This phase is independent of other phases; hence, any other scheme (in-band or out-of-band) can be used in the future.Eliminate the requirement in the client to establish a master secret every time a client requires network access
1Tunnel establishmentAuthenticates using the PAC and establishes a tunnel keyKey establishment to provide confidentiality and integrity during the authentication process in phase 2
2AuthenticationAuthenticates the peerMultiple tunneled, secure authentication mechanisms (credentials exchanged)

When automatic PAC provisioning is enabled, EAP-FAST has a vulnerability where an attacker can intercept the PAC and use that to compromise user credentials. This vulnerability is mitigated by manual PAC provisioning or by using server certificates for the PAC provisioning phase.

It is worth noting that the PAC file is issued on a per-user basis. This is a requirement in RFC   4851 sec 7.4.4 so if a new user logs on the network from a device, a new PAC file must be provisioned first. This is one reason why it is difficult not to run EAP-FAST in insecure anonymous provisioning mode. The alternative is to use device passwords instead, but then the device is validated on the network not the user.

EAP-FAST can be used without PAC files, falling back to normal TLS.

EAP-FAST is natively supported in Apple OS X 10.4.8 and newer. Cisco supplies an EAP-FAST module [25] for Windows Vista [26] and later operating systems which have an extensible EAPHost architecture for new authentication methods and supplicants. [27]

Tunnel Extensible Authentication Protocol (TEAP)

Tunnel Extensible Authentication Protocol (TEAP; RFC   7170) is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV (Type-Length-Value) objects are used to convey authentication-related data between the EAP peer and the EAP server.

In addition to peer authentication, TEAP allows the peer to ask the server for a certificate by sending a request in PKCS#10 format. After receiving the certificate request and authenticating the peer, the server can provision a certificate to the peer in PKCS#7 format ( RFC   2325). The server can also distribute trusted root certificates to the peer in PKCS#7 format ( RFC   2325). Both operations are enclosed into the corresponding TLVs and happen securely within the already established TLS tunnel.

EAP Subscriber Identity Module (EAP-SIM)

EAP Subscriber Identity Module (EAP-SIM) is used for authentication and session key distribution using the subscriber identity module (SIM) from the Global System for Mobile Communications (GSM).

GSM cellular networks use a subscriber identity module card to carry out user authentication. EAP-SIM use a SIM authentication algorithm between the client and an Authentication, Authorization and Accounting (AAA) server providing mutual authentication between the client and the network.

In EAP-SIM the communication between the SIM card and the Authentication Centre (AuC) replaces the need for a pre-established password between the client and the AAA server.

The A3/A8 algorithms are being run a few times, with different 128 bit challenges, so there will be more 64 bit Kc-s which will be combined/mixed to create stronger keys (Kc-s won't be used directly). The lack of mutual authentication in GSM has also been overcome.

EAP-SIM is described in RFC   4186.

EAP Authentication and Key Agreement (EAP-AKA)

Extensible Authentication Protocol Method for Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (EAP-AKA), is an EAP mechanism for authentication and session key distribution using the UMTS Subscriber Identity Module (USIM). EAP-AKA is defined in RFC   4187.

EAP Authentication and Key Agreement prime (EAP-AKA')

The EAP-AKA' variant of EAP-AKA, defined in RFC   5448, and is used for non-3GPP access to a 3GPP core network. For example, via EVDO, WiFi, or WiMax.

EAP Generic Token Card (EAP-GTC)

EAP Generic Token Card, or EAP-GTC, is an EAP method created by Cisco as an alternative to PEAPv0/EAP-MSCHAPv2 and defined in RFC   2284 and RFC   3748. EAP-GTC carries a text challenge from the authentication server, and a reply generated by a security token. The PEAP-GTC authentication mechanism allows generic authentication to a number of databases such as Novell Directory Service (NDS) and Lightweight Directory Access Protocol (LDAP), as well as the use of a one-time password.

EAP Encrypted Key Exchange (EAP-EKE)

EAP with the encrypted key exchange, or EAP-EKE, is one of the few EAP methods that provide secure mutual authentication using short passwords and no need for public key certificates. It is a three-round exchange, based on the Diffie-Hellman variant of the well-known EKE protocol.

EAP-EKE is specified in RFC   6124.

Nimble out-of-band authentication for EAP (EAP-NOOB)

Nimble out-of-band authentication for EAP [28] (EAP-NOOB) is a generic bootstrapping solution for devices which have no pre-configured authentication credentials and which are not yet registered on any server. It is especially useful for Internet-of-Things (IoT) gadgets and toys that come with no information about any owner, network or server. Authentication for this EAP method is based on a user-assisted out-of-band (OOB) channel between the server and peer. EAP-NOOB supports many types of OOB channels such as QR codes, NFC tags, audio etc. and unlike other EAP methods, the protocol security has been verified by formal modeling of the specification with ProVerif and MCRL2 tools. [29]

EAP-NOOB performs an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) over the in-band EAP channel. The user then confirms this exchange by transferring the OOB message. Users can transfer the OOB message from the peer to the server, when for example, the device is a smart TV that can show a QR code. Alternatively, users can transfer the OOB message from the server to the peer, when for example, the device being bootstrapped is a camera that can only read a QR code.

Encapsulation

EAP is not a wire protocol; instead it only defines message formats. Each protocol that uses EAP defines a way to encapsulate EAP messages within that protocol's messages. [30] [31]

IEEE 802.1X

The encapsulation of EAP over IEEE 802 is defined in IEEE 802.1X and known as "EAP over LANs" or EAPOL. [32] [33] [34] EAPOL was originally designed for IEEE 802.3 Ethernet in 802.1X-2001, but was clarified to suit other IEEE 802 LAN technologies such as IEEE 802.11 wireless and Fiber Distributed Data Interface (ANSI X3T9.5/X3T12, adopted as ISO 9314) in 802.1X-2004. [35] The EAPOL protocol was also modified for use with IEEE 802.1AE (MACsec) and IEEE 802.1AR (Initial Device Identity, IDevID) in 802.1X-2010. [36]

When EAP is invoked by an 802.1X enabled Network Access Server (NAS) device such as an IEEE 802.11i-2004 Wireless Access Point (WAP), modern EAP methods can provide a secure authentication mechanism and negotiate a secure private key (Pair-wise Master Key, PMK) between the client and NAS which can then be used for a wireless encryption session utilizing TKIP or CCMP (based on AES) encryption.

PEAP

The Protected Extensible Authentication Protocol, also known as Protected EAP or simply PEAP, is a protocol that encapsulates EAP within a potentially encrypted and authenticated Transport Layer Security (TLS) tunnel. [37] [38] [39] The purpose was to correct deficiencies in EAP; EAP assumed a protected communication channel, such as that provided by physical security, so facilities for protection of the EAP conversation were not provided. [40]

PEAP was jointly developed by Cisco Systems, Microsoft, and RSA Security. PEAPv0 was the version included with Microsoft Windows XP and was nominally defined in draft-kamath-pppext-peapv0-00. PEAPv1 and PEAPv2 were defined in different versions of draft-josefsson-pppext-eap-tls-eap. PEAPv1 was defined in draft-josefsson-pppext-eap-tls-eap-00 through draft-josefsson-pppext-eap-tls-eap-05, [41] and PEAPv2 was defined in versions beginning with draft-josefsson-pppext-eap-tls-eap-06. [42]

The protocol only specifies chaining multiple EAP mechanisms and not any specific method. [38] [43] Use of the EAP-MSCHAPv2 and EAP-GTC methods are the most commonly supported.[ citation needed ]

RADIUS and Diameter

Both the RADIUS and Diameter AAA protocols can encapsulate EAP messages. They are often used by Network Access Server (NAS) devices to forward EAP packets between IEEE 802.1X endpoints and AAA servers to facilitate IEEE 802.1X.

PANA

The Protocol for Carrying Authentication for Network Access (PANA) is an IP-based protocol that allows a device to authenticate itself with a network to be granted access. PANA will not define any new authentication protocol, key distribution, key agreement or key derivation protocols; for these purposes, EAP will be used, and PANA will carry the EAP payload. PANA allows dynamic service provider selection, supports various authentication methods, is suitable for roaming users, and is independent from the link layer mechanisms.

PPP

EAP was originally an authentication extension for the Point-to-Point Protocol (PPP). PPP has supported EAP since EAP was created as an alternative to the Challenge-Handshake Authentication Protocol (CHAP) and the Password Authentication Protocol (PAP), which were eventually incorporated into EAP. The EAP extension to PPP was first defined in RFC   2284, now obsoleted by RFC   3748.

See also

Related Research Articles

In computing, the Challenge-Handshake Authentication Protocol (CHAP) is an authentication protocol originally used by Point-to-Point Protocol (PPP) to validate users. CHAP is also carried in other authentication protocols such as RADIUS and Diameter.

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

IEEE 802.1X is an IEEE Standard for port-based network access control (PNAC). It is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.

Wi-Fi Protected Access (WPA), Wi-Fi Protected Access 2 (WPA2), and Wi-Fi Protected Access 3 (WPA3) are the three security certification programs developed after 2000 by the Wi-Fi Alliance to secure wireless computer networks. The Alliance defined these in response to serious weaknesses researchers had found in the previous system, Wired Equivalent Privacy (WEP).

An authentication protocol is a type of computer communications protocol or cryptographic protocol specifically designed for transfer of authentication data between two entities. It allows the receiving entity to authenticate the connecting entity as well as authenticate itself to the connecting entity by declaring the type of information needed for authentication as well as syntax. It is the most important layer of protection needed for secure communication within computer networks.

IEEE 802.11i-2004, or 802.11i for short, is an amendment to the original IEEE 802.11, implemented as Wi-Fi Protected Access II (WPA2). The draft standard was ratified on 24 June 2004. This standard specifies security mechanisms for wireless networks, replacing the short Authentication and privacy clause of the original standard with a detailed Security clause. In the process, the amendment deprecated broken Wired Equivalent Privacy (WEP), while it was later incorporated into the published IEEE 802.11-2007 standard.

Lightweight Extensible Authentication Protocol (LEAP) is a proprietary wireless LAN authentication method developed by Cisco Systems. Important features of LEAP are dynamic WEP keys and mutual authentication. LEAP allows for clients to re-authenticate frequently; upon each successful authentication, the clients acquire a new WEP key. LEAP may be configured to use TKIP instead of dynamic WEP.

IEEE 802.11r-2008 or fast BSS transition (FT), is an amendment to the IEEE 802.11 standard to permit continuous connectivity aboard wireless devices in motion, with fast and secure client transitions from one Basic Service Set to another performed in a nearly seamless manner. It was published on July 15, 2008. IEEE 802.11r-2008 was rolled up into 802.11-2012. The terms handoff and roaming are often used, although 802.11 transition is not a true handoff/roaming process in the cellular sense, where the process is coordinated by the base station and is generally uninterrupted.

The Protected Extensible Authentication Protocol, also known as Protected EAP or simply PEAP, is a protocol that encapsulates the Extensible Authentication Protocol (EAP) within an encrypted and authenticated Transport Layer Security (TLS) tunnel. The purpose was to correct deficiencies in EAP; EAP assumed a protected communication channel, such as that provided by physical security, so facilities for protection of the EAP conversation were not provided.

In cryptography, a password-authenticated key agreement (PAK) method is an interactive method for two or more parties to establish cryptographic keys based on one or more party's knowledge of a password.

MS-CHAP is the Microsoft version of the Challenge-Handshake Authentication Protocol, (CHAP).

Xsupplicant is a supplicant that allows a workstation to authenticate with a RADIUS server using 802.1X and the Extensible Authentication Protocol (EAP). It can be used for computers with wired or wireless LAN connections to complete a strong authentication before joining the network and supports the dynamic assignment of WEP keys.

strongSwan is a multiplatform IPsec implementation. The focus of the project is on authentication mechanisms using X.509 public key certificates and optional storage of private keys and certificates on smartcards through a PKCS#11 interface and on TPM 2.0.

<span class="mw-page-title-main">Wireless security</span> Aspect of wireless networks

Wireless security is the prevention of unauthorized access or damage to computers or data using wireless networks, which include Wi-Fi networks. The term may also refer to the protection of the wireless network itself from adversaries seeking to damage the confidentiality, integrity, or availability of the network. The most common type is Wi-Fi security, which includes Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA). WEP is an old IEEE 802.11 standard from 1997. It is a notoriously weak security standard: the password it uses can often be cracked in a few minutes with a basic laptop computer and widely available software tools. WEP was superseded in 2003 by WPA, a quick alternative at the time to improve security over WEP. The current standard is WPA2; some hardware cannot support WPA2 without firmware upgrade or replacement. WPA2 uses an encryption device that encrypts the network with a 256-bit key; the longer key length improves security over WEP. Enterprises often enforce security using a certificate-based system to authenticate the connecting device, following the standard 802.11X.

IEEE 802.11u-2011 is an amendment to the IEEE 802.11-2007 standard to add features that improve interworking with external networks.

Internet Authentication Service (IAS) is a component of Windows Server operating systems that provides centralized user authentication, authorization and accounting.

wpa_supplicant Open-source implementation of IEEE 802.11i

wpa_supplicant is a free software implementation of an IEEE 802.11i supplicant for Linux, FreeBSD, NetBSD, QNX, AROS, Microsoft Windows, Solaris, OS/2 and Haiku. In addition to being a WPA3 and WPA2 supplicant, it also implements WPA and older wireless LAN security protocols.

<span class="mw-page-title-main">Supplicant (computer)</span> Part of IEEE 802.1X standard

In computer networking, a supplicant is an entity at one end of a point-to-point LAN segment that seeks to be authenticated by an authenticator attached to the other end of that link. The IEEE 802.1X standard uses the term "supplicant" to refer to either hardware or software. In practice, a supplicant is a software application installed on an end-user's computer. The user invokes the supplicant and submits credentials to connect the computer to a secure network. If the authentication succeeds, the authenticator typically allows the computer to connect to the network.

Cisco Centralized Key Management (CCKM) is a form of Fast Roaming and a subset of the Cisco Compatible EXtensions (CCX) specification.

In cryptography, Simultaneous Authentication of Equals (SAE) is a password-based authentication and password-authenticated key agreement method.

References

  1. 1 2 "Introduction". Extensible Authentication Protocol (EAP). sec. 1. doi: 10.17487/RFC3748 . RFC 3748.
  2. ↑ "Extensible Authentication Protocol (EAP) Registry". www.iana.org. Retrieved 2021-06-01.
  3. ↑ George Ou (January 11, 2007). "Ultimate wireless security guide: An introduction to LEAP authentication". TechRepublic . Retrieved 2008-02-17.
  4. ↑ Dan Jones (October 1, 2003). "Look Before You LEAP". Unstrung. Archived from the original on February 9, 2008. Retrieved 2008-02-17.
  5. ↑ "Understanding the updated WPA and WPA2 standards". techrepublic.com. Retrieved 2008-02-17.
  6. 1 2 Byrd, Christopher (5 May 2010). "Open Secure Wireless" (PDF). Archived from the original (PDF) on 12 December 2013. Retrieved 2013-08-14.
  7. 1 2 The EAP-TLS Authentication Protocol. March 2008. doi: 10.17487/RFC5216 . RFC 5216. The certificate_request message is included when the server desires the peer to authenticate itself via public key. While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means.
  8. ↑ "Add UNAUTH-TLS vendor specific EAP type". hostapd . Archived from the original on 2013-02-13. Retrieved 2013-08-14.
  9. ↑ "HS 2.0R2: Add WFA server-only EAP-TLS peer method". hostapd . Archived from the original on 2014-09-30. Retrieved 2014-05-06.
  10. ↑ "HS 2.0R2: Add WFA server-only EAP-TLS server method". hostapd . Archived from the original on 2014-09-30. Retrieved 2014-05-06.
  11. ↑ Byrd, Christopher (1 November 2011). "Open Secure Wireless 2.0". Archived from the original on 26 November 2013. Retrieved 2013-08-14.
  12. ↑ Rand Morimoto; Kenton Gardinier; Michael Noel; Joe Coca (2003). Microsoft Exchange Server 2003 Unleashed. Sams. p. 244. ISBN   978-0-672-32581-6.
  13. ↑ "Alternative Encryption Schemes: Targeting the weaknesses in static WEP". Ars Technica. Retrieved 2008-02-17.
  14. ↑ "922574", Knowledge Base, Microsoft
  15. ↑ "EAP-POTP Authentication Protocol". Juniper.net. Retrieved 2014-04-17.
  16. ↑ FreeRADIUS EAP module rlm_eap_pwd
  17. ↑ McCauley, Mike. "Added support for EAP-PWD per RFC 5931". radiator-announce (Mailing list).
  18. ↑ Secure-authentication with only a password
  19. ↑ Extensible Authentication Protocol (EAP) Settings for Network Access
  20. ↑ "802.1x / EAP TTLS support? – Windows Phone Central Forums". Forums.wpcentral.com. Retrieved 2014-04-17.
  21. ↑ "Enterprise Wi-Fi authentication (EAP)". Microsoft.com. Retrieved 2014-04-23.
  22. ↑ EAP Tunneled TLS Authentication Protocol Version 1 (EAP-TTLSv1). I-D draft-funk-eap-ttls-v1-01.
  23. ↑ "Ultimate wireless security guide: A primer on Cisco EAP-FAST authentication". techrepublic.com. Archived from the original on 2008-03-24. Retrieved 2008-02-17.
  24. ↑ "EAP-FAST > EAP Authentication Protocols for WLANs". Ciscopress.com. Retrieved 2014-04-17.
  25. ↑ "EAP-FAST for Windows Vista Administrator Guide". Archived from the original on February 10, 2009.
  26. ↑ How do I install CISCO EAP-FAST on my computer?
  27. ↑ EAPHost in Windows
  28. ↑ Aura, Tuomas; Sethi, Mohit; Peltonen, A. (December 2021). Nimble out-of-band authentication for EAP (EAP-NOOB). doi: 10.17487/RFC9140 . RFC 9140.
  29. ↑ EAP-NOOB Model on GitHub
  30. ↑ Pedersen, Torben (2005). "HTTPS, Secure HTTPS". Encyclopedia of Cryptography and Security. pp. 268–269. doi:10.1007/0-387-23483-7_189. ISBN   978-0-387-23473-1.
  31. ↑ Plumb, Michelle, CAPPS : HTTPS Networking, OCLC   944514826
  32. ↑ "EAP Usage Within IEEE 802". Extensible Authentication Protocol (EAP). sec. 3.3. doi: 10.17487/RFC3748 . RFC 3748.
  33. ↑ "Link Layer". Extensible Authentication Protocol (EAP). sec. 7.12. doi: 10.17487/RFC3748 . RFC 3748.
  34. ↑ IEEE 802.1X-2001, § 7
  35. ↑ IEEE 802.1X-2004, § 3.2.2
  36. ↑ IEEE 802.1X-2010, § 5
  37. ↑ "EAP encapsulation". Microsoft's PEAP version 0 (Implementation in Windows XP SP1). sec. 1.1. I-D draft-kamath-pppext-peapv0-00.
  38. 1 2 Protected EAP Protocol (PEAP) Version 2. Abstract. I-D draft-josefsson-pppext-eap-tls-eap-10.
  39. ↑ "Introduction". Protected EAP Protocol (PEAP) Version 2. sec. 1. I-D draft-josefsson-pppext-eap-tls-eap-10.
  40. ↑ "Introduction". Protected EAP Protocol (PEAP) Version 2. sec. 1. I-D draft-josefsson-pppext-eap-tls-eap-07.
  41. ↑ Protected EAP Protocol (PEAP). sec. 2.3. I-D draft-josefsson-pppext-eap-tls-eap-05.
  42. ↑ "Version negotiation". Protected EAP Protocol (PEAP). sec. 2.3. I-D draft-josefsson-pppext-eap-tls-eap-06.
  43. ↑ "Protocol Overview". Protected EAP Protocol (PEAP) Version 2. p. 11. I-D draft-josefsson-pppext-eap-tls-eap-10.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.