• Home   /  
  • Archive by category "1"

Peap Eap Tls Comparison Essay

[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 0001020304050607080910

Internet Draft H. Andersson S. Josefsson RSA Security G. Zorn Cisco B. Aboba Microsoft October 2001 Protected Extensible Authentication Protocol (PEAP)<draft-josefsson-pppext-eap-tls-eap-01.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts may be found at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories may be found at http://www.ietf.org/shadow.html. Abstract This document specifies an Extensible Authentication Protocol (EAP) mechanism for mutual authentication and session key generation in a roaming environment. The server authentication and the negotiation of the session key is done using the PPP EAP Transport Layer Security (TLS) Authentication Protocol. The user authenticates using a PPP EAP mechanism, integrity and privacy protected by TLS. In essence, a wrapping of EAP inside TLS inside EAP is specified. An important application discussed in this document is to provide authentication of access points and stations within an IEEE 802.11 Wireless Local Area Network (WLAN), but other applications such as LAN access over Bluetooth might also be considered in the future. 1. Introduction The PPP Extensible Authentication Protocol [2] defines a general Andersson et al Expires: March 2002 [Page 1]
INTERNET-DRAFT PEAP October 2001 authentication framework. This document specifies an EAP mechanism for mutual authentication and session key generation, with support for a roaming environment. The connection is made, using EAP terminology, between a peer and an authenticator. The (public-key) authentication of the authenticator and the negotiation of the session key is done using the PPP EAP Transport Layer Security (TLS) Authentication Protocol [1]. The user performs authentication using any defined PPP EAP mechanism, see [2]. Section 2 defines the model and some terminology. A overview of this EAP mechanism is given in Section 3, and Section 4 gives a detailed description of packet formats. In Section 5, the protocol is applied to an IEEE 802.11 Wireless Local Area Network (WLAN). Finally, Section 6 discusses security issues. 2. Model and Terminology The term peer refers to a client, acting on behalf of a user, that requests access to a network. The entity contacted by the peer is denoted authenticator. The authenticator is in turn connected to an entity called back-end server. In our model, the authenticator is acting merely as a passthrough device during the authentication phase, forwarding each packet received from the peer to the back-end server, and vice versa. It should be noted that the back-end server may be a logical entity located in the same physical device as the authenticator. The realisation of the back-end server and the communication between the authenticator and backend server are outside the scope of this document. +---+ | B | | a | | c | | k | +---------------+ +--------+ | | <-----------> | Authenticator | <-----> | Peer | | e | +---------------+ EAP +--------+ | n | . | d | . | | . | S | +---------------+ . EAP | e | <-----------> | Authenticator | . | r | +---------------+ | v | | e | | r | +---+ An overview of the assumed environment is found in the figure above. Andersson et al Expires: March 2002 [Page 2]
INTERNET-DRAFT PEAP October 2001 The peer initially contacts the first authenticator (at the top of the figure). The dotted line between the peer and the second authenticator symbolizes roaming, i.e. the situation where the peer transits from one authenticator to another while still maintaining server and user authentication. It is assumed that the same logical back-end server sits behind all of the authenticators contacted by the peer. In practice, the back-end server may be distributed over several machines, for e.g. fail-over or load-balancing purposes, but in this document we regard them as one logical unit. This document frequently uses the following terms and abbreviations: authenticator The end of the link requiring the authentication. EAP Extensible Authentication Protocol. After a connection link has been established between two entities, an authentication phase may take place. The PPP EAP protocol [2] is a general authentication protocol. The authenticator sends one or more requests to the peer, and the peer sends a response in reply to each request. The authenticator ends the authentication phase with a success or failure message. peer The other end of the point-to-point link; the end which is being authenticated by the authenticator. TLS Transport Layer Security. Internet security protocol for point-to-point connections (enhancement of Secure Sockets Layer, SSL). Defined in [3]. Under this protocol, two entities are able to authenticate each other and to establish a secure link. TLS operates at the transport layer. The protocol PPP EAP TLS [1] describes how to provide for TLS mechanisms within EAP. 3. Overview of the conversation A peer wishes to set up a connection with an authenticator, for the purpose of authenticating itself to e.g. a wireless infrastructure. In our model, the authenticators are in connection with an back-end server. The following describes each EAP packet that is sent between the authenticator and peer during the EAP connection. Andersson et al Expires: March 2002 [Page 3]
INTERNET-DRAFT PEAP October 2001 3.1. Initial registration The first two steps are described in detail in Section 3.1 of [2], we include them here for illustration. Note that as per the EAP specification, this Identity exchange is not required. 1. The first EAP Request packet sent by the authenticator to the peer is of type Identity. The data field may optionally contain a displayable message. 2. The peer responds with an EAP-Response packet of type Identity. Note that the data field of the Identity packet, which contains the peer identity, cannot be assumed to be integrity or privacy protected. Accordingly, it should not be used instead of the peer identity sent inside the TLS channel later on. The entities now initiate an EAP-TLS conversation. The following is an example of a successful TLS handshake within EAP -- the packets are described in detail in Section 4 of [1]. The EAP method defined in this document does not terminate the TLS connection once the TLS handshake phase is concluded (and thus differs subtly from how TLS is used in [1]). The retry behavior and fragmentation concerns of section 3.2 and 3.3 of [1] are still applicable (but not illustrated in this example). 3. The authenticator sends an EAP-TLS packet of type Start with empty data field. The data field of following packets will encapsulate TLS Handshake Protocol messages. 4. Client hello: The peer sends a preferred TLS protocol version number, an empty Session ID field, a list of preferred cryptographic algorithms, and a random number to initialize the TLS handshake. 5. Server hello: The authenticator responds with a selected TLS protocol version number, a new Session ID, a list of selected cryptographic algorithms, and another random number. Server certificate: The authenticator then sends a chain of X.509v3 certificates, starting with its own certificate. The packet may optionally include a server key exchange. Server hello done: Finally, the authenticator indicates the end of this message stream. (Note that the authenticator must NOT send any certificate request.) 6. Client key exchange: The peer generates a premaster secret, encrypts it using the public key obtained from the server certificate, and sends the result. Change cipher spec: The Andersson et al Expires: March 2002 [Page 4]
INTERNET-DRAFT PEAP October 2001 peer selects the cipher(s) to use. Client finished: The peer also calculates a master secret from the premaster secret, and sends a hash of a message consisting of the master secret; all of the data from all previous handshake messages; the string "client finished". 7. Change cipher spec: The authenticator selects the cipher(s) to use. Server finished: Finally, the authenticator itself generates the master secret from the premaster secret and responds with a hash of a message consisting of the master secret; all of the data from all previous handshake messages; the string "server finished". 8. The peer acknowledges the end of the TLS negotiation by sending an empty EAP Response packet. This concludes the TLS handshake phase and the authentication of the authenticator. It remains to perform user authentication. Note that it is not until now that we deviate from the TLS EAP specification. The authenticator will now intiate a second EAP handshake, within TLS, to provide peer authentication in a protected channel. In this EAP handshake, any EAP mechanism may be used to provide the peer authentication. This concludes the mutual authentication, and upon success both authenticator and peer may generate any amount of new key material to be forwarded to the underlying transport. This is accomplished within the TLS Record Protocol by using the so-called PRF (Pseudo-Random Function), see Section 3.5 "Key Derivation" of [3]. It remains to be described what happens upon failures. In case the TLS negotiation has failed fatally (after the proper TLS Alert messages have been sent), an EAP-Failure messages is transmitted. Within the TLS channel, in the second EAP handshake, after any EAP- Success and EAP-Failure messages has successfully been sent, the same type of packet should be send in the outer EAP channel as well. 3.2. Roaming We now describe the case where the peer is transiting between two authenticators during a session. In order to obtain a seamless transition to a connection between the peer and the new authenticator, we use the connection re-establishment mechanism provided by the TLS Handshake Protocol. Note that the new authenticator is assumed to use the same back-end server as the old one, hence the old security parameters are still available. In the case where the back-end server is just a logical entity residing at the authenticator, the second authenticator will be required to Andersson et al Expires: March 2002 [Page 5]
INTERNET-DRAFT PEAP October 2001 (securely) transfer the security parameters from the first authenticator. The steps 1-3 above are repeated without change. The following describes a successful TLS handshake: 4. Client hello: The peer sends the TLS protocol version number, the Session ID of the old connection, the previously negotiated cryptographic algorithms, and a random number. 5. Server hello: The authenticator responds with the TLS protocol version number, the Session ID, the negotiated cryptographic algorithms, and another random number. If the old Session ID has expired, then a new Session ID is presented to the peer and full authentication takes place, as described in Subsection 3.1. Change cipher spec: the server selects the cipher(s) to use. Server finished: The authenticator responds with a hash of a message consisting of the master secret; data from all previous handshake messages; the string "server finished". 6. Change cipher spec: The peer select cipher(s) to use. Client finished: The peer sends a hash of a message consisting of the previously calculated master secret; data from all previous handshake messages; the string "client finished". Note that mutual authentication is achieved, since both peer and authenticator have to know the old master secret in order to successfully complete the protocol. An alternative to TLS resumption has been discussed, whereby a "Roaming ID" is used to identify the user moving between authenticators. At a new connection, server authentication and generation of new security parameters is mandatory. The advantage of this approach is that the authentication server does not have to store so much key material, since all data except the Roaming ID may be deleted when entities are disconnected. This can be an important issue if there are many peers to be served. On the other hand, having to generate much new key material could be very time consuming for the back-end server, and this potential danger has led us to choose TLS resumption as described above. Finally, the length of time that a Session ID is valid should be limited. The time of validity is application dependent. In some environments it may be desirable that the authenticator notify the peer that the Session ID is about to expire. No mechanism is defined in this document to handle such a scenario, but note that the Session ID validity is checked during connection re-establishment (see 5 above). 4. Packet formatsAndersson et al Expires: March 2002 [Page 6]
INTERNET-DRAFT PEAP October 2001 It is assumed that underlying transport protocols has set up the connection so that it is ready to transfer EAP packets. 4.1. TLS in EAP The syntax of EAP packets containing TLS messages are per [1], and the TLS protocol description is per [3]. Note that [1] does not use the negotiated TLS tunnel to transfer any data, while this specification does, however this does not affect the EAP protocol syntax. We include the EAP syntax in the following figure, referring to Sections 4.2 and 4.3 of [1] for the definition of the Request and Response packets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 - Request 2 - Response Identifier The identifier field is one octet and aids in matching responses with requests. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type TBA - EAP TLS EAP Data The format of the Data field is determined by the Code field. 4.2. EAP negotiation inside TLS Andersson et al Expires: March 2002 [Page 7]
INTERNET-DRAFT PEAP October 2001 We now assume that the TLS handshake has been successfully completed and that a secure TLS connection is available within the TLS Record Protocol. The following packets (protected by TLS Record Protocol and sent inside EAP packets) are used to negotiate the peer EAP authentication. The following figure describes the template packet structure that is used during this communication. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Data as per RFC 2284 ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The party acting as authenticator in this second, wrapped, EAP channel MUST be the same party that acted as authenticator in the original EAP channel. 5. Example: IEEE 802.11 WLAN IEEE 802.11 Wireless Local Area Network (WLAN) is a standard for wireless computer networks, see [5]. Any device that contains an IEEE 802.11 conformant medium access control and physical layer interface to the wireless medium is called a Station (STA). An entity that has station functionality and also provides access to the distribution services (e.g. a wired LAN) via the wireless medium for associated stations is called an Access Point (AP). The authentication services defined within IEEE 802.11 are discussed below, and the need for higher level authentication is addressed. IEEE 802.11 defines two types of authentication methods -- Open system authentication and Shared key authentication. Open system authentication is essentially a null authentication. The conversation is done in clear, no challenge procedure is performed. The purpose of Shared key authentication is to check that both parties share a pre- negotiated encryption key. The AP sends a challenge and the STA responds by encrypting this challenge. If the AP successfully decrypts that message, the authentication is finished. In other words, the AP is never required to authenticate itself. This opens up for a number of attacks, such as denial of service attacks via rogue APs. It is thus crucial to achieve mutual authentication. The IEEE 802.1X draft [4] specifies a general method for the provision of port based network access control. A port in this context is an attachment point to the LAN infrastructure, e.g. an association between a STA and an AP. The specification describes the Andersson et al Expires: March 2002 [Page 8]
INTERNET-DRAFT PEAP October 2001 architectural framework within which the authentication takes place, and establishes the requirements for a higher level authentication protocol between the station and the access point. The IEEE 802.1X draft provides a framework, Extensible Authentication Protocol Over Local area networks (EAPOL), that makes it possible to send EAP packets between IEEE 802.11 entities. In a WLAN environment, the "Authenticator" is the AP, and the "Peer" is a STA. An Authentication Server is an entity connected with the AP. The server is communicating with the STA during the authentication -- the AP is sitting in between, acting merely as a passthrough device. In a roaming environment, the STA may connect to several APs during a session. All the APs are assumed to be connected to the same authentication server. The protocol described in this paper may therefore be applied to a WLAN environment, providing authentication of the AP, strong authentication of the user of the STA, and session key negotiation. Note that the present protocol is partly based on [1], which in turn assumes PPP EAP and not EAPOL as the underlying protocol. However, this minor difference will cause no problems whatsoever, since the TLS conversation carries over word by word to the new environment. Let us finally comment on the Wired Equivalent Privacy (WEP) encryption scheme defined in the IEEE 802.11 standard. WEP uses the stream cipher RC4 with key obtained as the concatenation of a 24 bit IV and a 40 bit WEP key. Four WEP keys can be prestored, but it is also possible to use a session key negotiated during the authentication phase, i.e. follow the approach outlined in this work. WEP suffers from some serious security weaknesses, e.g. the WEP key is too short to withstand a brute force attack. Also, the IV is too short -- even if a new random IV is used for each packet, collisions will start appearing within a few seconds (according to the birthday paradox). XORing messages with the same IV results in plaintext difference that can be further analyzed. Finally, there is no real data integrity since the integrity check value used is just a linear checksum. An active attacker wishing to alter the plaintext can easily modify the checksum to be valid for the new plaintext. The IEEE 802.11 working group recognizes the need to improve security, and is currently working on a revision of the standard. 6. Security considerations The Transport Layer Security protocol is presumed to be a strong security protocol and it is widely accepted. Here we discuss some security issues. The Session ID is sent in clear, so an attacker may contact an authenticator, pretending to be the legitimate user. However, by sending correct Finished messages, the parties prove to Andersson et al Expires: March 2002 [Page 9]
INTERNET-DRAFT PEAP October 2001 each other that they know the correct premaster secret. The attacker will not be able to finish the handshake properly (unless the protocol has been completely broken). An attacker, acting as an active man-in-the-middle, might try to influence the choice of encryption algorithm by altering the corresponding handshake message. However, this will also be detected in the verification of the Finished messages, since each of these consists of a hash of all previous messages. The hash functions MD5 and SHA-1 are used in tandem wherever possible. The TLS designers claim that this approach ensures that a serious flaw in one of the functions will not lead to failure of the entire TLS protocol. Finally, the strength of the user authentication is dependent on the EAP mechanism chosen. With the approach described here, the EAP packets sent by the peer are not transmitted in clear, which improve the security of some EAP mechanisms. This is particularly important in a wireless environment where passive eavesdropping is a serious threat. 7. Acknowledgements We wish to thank Jan-Ove Larsson and Magnus Nystrom for helpful discussions and comments during the development of this draft. We would also like to thank Glen Zorn and Simon Blake-Wilson for comments on the first version of this draft. References [1] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [2] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [3] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January 1999. [4] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Draft 802.1X/D10, January 2001. [5] Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements -- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11, 1999. Andersson et al Expires: March 2002 [Page 10]
INTERNET-DRAFT PEAP October 2001 Address of the authors Hakan Andersson RSA Security Box 107 04 SE-121 29 Stockholm Sweden E-mail: handersson@rsasecurity.com Phone: +46 8 725 9758 Fax: +46 8 649 4970 Simon Josefsson RSA Security Box 107 04 SE-121 29 Stockholm Sweden E-mail: sjosefsson@rsasecurity.com Phone: +46 8 725 0914 Fax: +46 8 649 4970 Glen Zorn Cisco E-mail: gwz@cisco.com Bernard Aboba Microsoft E-mail: aboba@internaut.com Andersson et al Expires: March 2002 [Page 11]
Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/


This document answers questions about Protected Extensible Authentication Protocol.


Q. What is Protected Extensible Authentication Protocol?

A. Protected Extensible Authentication Protocol (PEAP) is an 802.1X authentication type for wireless LANs (WLANs). PEAP provides strong security, user database extensibility, and support for one-time token authentication and password change or aging. PEAP is based on an Internet Draft (I-D) submitted by Cisco Systems ®, Microsoft, and RSA Security to the IETF. Glen Zorn was the Cisco Systems ® lead engineer and coauthor of this I-D.

Q. Is PEAP supported by the Cisco Unified Wireless Network, Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access 2 (WPA2)?

A. Yes. The Cisco Unified Wireless Network supports several EAP authentication types, including PEAP. Like all EAP types, PEAP can be used with WPA and WPA2 networks.

Q. What is the Cisco Unified Wireless Network?

A. The Cisco Unified Wireless Network is the industry's only unified wired and wireless solution to cost-effectively address the WLAN security, deployment, management, and control issues facing enterprises. This powerful solution combines the best elements of wireless and wired networking to deliver scalable, manageable, and secure WLANs with a low total cost of ownership. It includes innovative RF capabilities that enable real-time access to core business applications and provides proven enterprise-class secure connectivity. The Cisco Unified Wireless Network delivers the same level of security, scalability, reliability, ease of deployment, and management for wireless LANs that organizations expect from their wired LANs.

The Cisco Unified Wireless Network supports an enterprise-ready, standards-based, wireless security solution that gives network administrators' confidence that their data will remain private and secure when they use Cisco wireless products, Cisco Aironet Series products, Cisco Compatible Extensions products or Wi-Fi Certified WLAN client devices. This enterprise-class wireless security solution supports robust wireless LAN security services that closely parallel the security available in a wired LAN. It fulfills the need for consistent, reliable, and secure mobile networking by delivering industry-leading WLAN security services. It mitigates sophisticated passive and active WLAN attacks, interoperates with a range of client devices and provides reliable, scalable, centralized security management. The Cisco Unified Wireless Network allows network administrators to deploy large-scale enterprise WLANs with scalable problem-free security administration that does not increase the burden on the IT staff.

Q. Is PEAP a standard?

A. Not yet. PEAP is based on an I-D submitted to the IETF. Cisco, Microsoft, and RSA Security are actively involved in the IETF standards body supporting a standardized PEAP implementation.

Q. Where can I find information about the PEAP draft proposed to the IETF?

A. Please visit the IETF I-D Search Engine and search for "PEAP."


Q. What are the security benefits of PEAP?

A. PEAP provides the following security benefits:

• Relies on Transport Layer Security (TLS) to allow nonencrypted authentication types such as EAP-Generic Token Card (GTC) and One Time Password (OTP) support

• Uses server-side Public-Key Infrastructure (PKI)-based digital certification authentication

• Allows authentication to an extended suite of directories, including Lightweight Directory Access Protocol (LDAP), Novell NDS, and OTP databases

• Uses TLS to encrypt all user-sensitive authentication information

• Supports password change at expiration

• Does not expose the logon user name in the EAP identity response

• Is not vulnerable to dictionary attacks

• Provides dynamic privacy protection when used in conjunction with Temporal Key Integrity Protocol (TKIP) or the Advanced Encryption Standard (AES)

Q. What are the enterprise benefits of PEAP?

A. PEAP is based on server-side EAP-TLS. With PEAP, organizations can avoid the issues associated with installing digital certificates on every client machine as required by EAP-TLS; instead, they can select the methods of client authentication, such as logon passwords or OTPs, that best suit their corporate needs.


Q. How does PEAP authentication work?

A. PEAP works in two phases:

• In Phase 1, server-side TLS authentication is performed to create an encrypted tunnel and achieve server-side authentication in a manner similar to Web server authentication using Secure Sockets Layer (SSL), a popular and trusted security method. Once Phase 1 of PEAP is established, all data is encrypted, including all user-sensitive information.

• The framework for PEAP Phase 2 authentication is extensible, and the client can be authenticated using methods such as EAP-GTC and Microsoft Challenge Authentication Protocol (MS-CHAP) Version 2 within the TLS tunnel.

Q. What Cisco wireless products support PEAP?

A. A variety of Cisco wireless products support PEAP including: Cisco Aironet autonomous and lightweight access points, Cisco wireless LAN controllers and Cisco Aironet client devices. Cisco Compatible client devices running Cisco Compatible Extensions version 4 or later also support PEAP.

Q. What client operating systems support PEAP?

A. PEAP support is available on Microsoft Windows 2000, Windows XP, and Windows CE. Visit the Cisco Aironet WLAN client software product bulletin Web page for the latest software information and guidelines to enable PEAP on a client machine.

Q. Is PEAP authentication available on wireless clients from vendors other than Cisco?

A. Yes. PEAP authentication is allowed from any PEAP-enabled supplicants that comply with the proposed PEAP IETF I-D. Cisco encourages customers to verify support and interoperability with vendors before starting installation.

Q. Can I install both PEAP client software from Cisco and PEAP client software from Microsoft on my machine?

A. PEAP client software from Cisco is complementary to PEAP client software from Microsoft. Users may choose to install either of these PEAP implementations on their client machines. When the Cisco PEAP supplicant is installed on a client machine, it completely replaces any existing MS-CHAP Version 2 PEAP supplicant on the machine.

Q. Can I use client certificate authentication with PEAP?

A. PEAP is based on server-side EAP-TLS. Client certificate authentication is not required-only the server is authenticated using certificates.

Q. Does PEAP provide single-login to Windows domains for passwords or OTP?

A. PEAP is compatible with single-login, which is a function of the client supplicant. Single-login function may be available with third-party utilities. The Windows PEAP supplicant (PEAP/MS-CHAPv2) supports single sign-on. Cisco's PEAP/GTC supplicant does not support single sign-on.

Q. How does silent session resume work during a PEAP session?

A. PEAP supports silent session resume (also known as Fast Reconnect) when only Phase 1 of PEAP is executed. In Phase 2, the previous authentication state is reused. Users are not required to reauthenticate until the PEAP session timeout expires. The PEAP session timer is independent of the RADIUS session timer, which is used to control the volatility of dynamic encryption keys with EAP.

Q. Can I use PEAP with LDAP or Novell NDS databases?

A. Yes. PEAP provides interoperability with both LDAP and Novell NDS.

Q. Where can I learn more about deploying PEAP?

A. Please read the Protected Extensible Authentication Protocol Application Note to learn more about deploying PEAP.

Q. Where can I learn more about deploying secure WLANs?

A. Please read the following documents to learn more about deploying secure WLANs:

• Wireless LAN Security White Paper

• Cisco Aironet Technical References

• Deployment Guide: Configuring the Cisco Wireless Security Suite

Q. Where can I learn more about WLAN security?

A. Please read the Cisco Wireless LAN Security brochure to learn more about WLAN security.


Q. What is the difference between the Microsoft PEAP supplicant and the Cisco PEAP supplicant?

A. Both supplicants support PEAP, but each supports different methods of client authentication through the TLS tunnel. The Microsoft PEAP supplicant supports client authentication by only MS-CHAP Version 2, which limits user databases to those that support MS-CHAP Version 2, such as Windows NT Domains and Active Directory. The Cisco PEAP supplicant supports client authentication by OTPs and logon passwords, enabling support for OTP databases from vendors (such as RSA Security and Secure Computing Corporation) and logon password databases (such as LDAP and Novell NDS) as well as Microsoft databases. In addition, the Cisco PEAP client includes the ability to hide user name identities until the TLS encrypted tunnel is established. This provides additional confidentiality that user names are not being broadcast during the authentication phase.

Q. What are the differences between PEAP, EAP-Flexible Authentication via Secure Tunneling (FAST), Cisco LEAP, and EAP-TLS?

A. Table 1 provides a summary comparison of PEAP, EAP-FAST, Cisco LEAP, and EAP-TLS.

Table 1. PEAP, EAP-FAST, Cisco LEAP and EAP-TLS Comparison Chart


PEAP with Generic Token Card (GTC)

PEAP with Microsoft Challenge Authentication Protocol (MS-CHAP) Version 2


Cisco LEAP


User Authentication Database and Server

OTP, LDAP, Novell NDS, Windows NT Domains, Active Directory

Windows NT Domains, Active Directory

Windows NT Domains, Active Directory, LDAP (limited)

Windows NT Domains, Active Directory

OTP, LDAP, Novell NDS, Windows NT Domains, Active Directory

Requires Server Certificates






Requires Client Certificates






Operating System Support

Driver: Windows XP, Windows 2000, Windows CE*

With third-party utility: Other OS**

Driver: Windows XP, Windows 2000, Windows CE

With third-party utility: Other OS**

Driver: Windows XP, Windows 2000, Windows CE***

With third-party utility: Other OS**

Driver: Windows 98, Windows 2000, Windows NT, Windows Me, Windows XP, Mac OS, Linux, Windows CE, DOS

Driver: Windows XP, Windows 2000, Windows CE

With third-party utility: Other OS

Application-Specific Device (ASD) Support






Credentials used

Client: Windows, Novell NDS, LDAP password; OTP or token

Server: Digital certificate

Windows password

Windows password, LDAP user ID/password (manual provisioning required for Pac provisioning)

Windows password****

Digital certificate

Single Sign-On Using Windows Login






Password Expiration and Change





Works with Fast Secure Roaming






Works with WPA and WPA2






* PEAP/GTC is supported on Cisco Compatible Version 2 clients and above.

** Greater operating system coverage is available with Meetinghouse and Funk supplicants.

*** Cisco Aironet 350 Series WLAN client devices and Cisco Aironet 5 GHz 54 Mbps Wireless LAN Client Adapters (CB20A) support EAP-FAST on Windows XP, Windows 2000, and Windows CE operating systems.

**** Requires strong passwords. Read more at: Cisco Response to Dictionary Attacks on Cisco LEAP.


For more information about the Cisco Unified Wireless Network, visit: http://www.cisco.com/go/unifiedwireless

For more information about Cisco Aironet products, visit: http://www.cisco.com/go/aironet

Read the Cisco Wireless LAN Security brochure at: http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps430/ps4076/prod_brochure09186a00801f7d0b.html

For more information about EAP-FAST, visit: http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00802030dc.shtml

For more information about Cisco LEAP, visit: http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps430/prod_qas0900aecd801764f1.shtml

For more information about 802.11i, WPA and WPA2, visit: http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps430/prod_qas0900aecd801e3e59.shtml

One thought on “Peap Eap Tls Comparison Essay

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *