A Technical Comparison of TTLS and PEAP
by Matthew Gast author of 802.11 Wireless networks:the Definitive Guide
10/17/2002
Related Reading 802.11 Wireless networks:the Definitive Guide Creating and Administering Wireless Networks by Matthew Gast |
Broadly speaking, wireless LAN Security has both major issues. Authentication of the network users are not strong, so unauthorized users are able to access network resources. Traffic encryption is also weak, so attackers was able to recover transmissions. Strong authentication is a key component of wireless LAN security because it prevents unauthorized users from gaining NETW Ork access. Wireless LAN protocols is also designed in such a-to-do bolstering the access control also makes it quite easy to Shor E up the encryption of traffic, to the point where deploying products to improve authentication would also provide greater Privacy of the information traveling over the wireless LAN.
In response to the concern about weak authentication, the industry began developing a series of stronger authentication PR Otocols with wireless LANs. The key standard for wireless LAN authentication are the IEEE 802.1x standard, which are in turn based on the IETF ' s Extensi BLE authentication Protocol (EAP). EAP, and thus 802.1x, provides an authentication framework. It supports a number of authentication methods, each with its own strengths and weaknesses. Part of the challenge to deploying 802.1x on a wireless network are to decide on the type of authentication that would be us Ed. The authentication method is the key decision to make in deploying a wireless network, since it would drive all the product Choices.
tls-based Authentication Methods
802.1x was initially developed for authentication of the users on traditional wired LANs, and therefore do not require STR Ong encryption. Eavesdropping is certainly possible on wired networks, though it requires physical access to network equipment. Wireless networks is much easier to perform traffic analyst on because physical access to the network does not require P Hysical access to the network equipment. Frames on wireless networks can is easily intercepted in transit with wireless network analysis software. Wireless networks also have additional authentication requirements. Without physical access to the equipment, users need to ensure that they is connecting to legitimate access points that a Re part of the organization's network, not "rogue" access points set up as part of a man-in-the-middle attack. In addition to the requirement for user (client) authentication, wireless network users also need to authenticate the NETW Orks they connect to.
These requirements, strong encryption to prevent eavesdropping and mutual authentication to ensure that sensitive info Rmation is transmitted only over legitimate networks, must drive your wireless authentication strategy. In practice, only methods based on the IETF's well-known Transport Layer Security (TLS) standard can satisfy strict ENCRYP tion and authentication requirements. Three tls-based protocols has been developed for use with EAP and is suitable for deployments with wireless LANs:
- Eap-transport Layer Security (EAP-TLS)
- tunneled Transport Layer Security (TTLS)
- Protected EAP (PEAP)
Major differences between the protocols is summarized in this table:
Detailed Comparison of tls-based Methods
|
EAP-TLS (RFC 2716) |
TTLS (Internet Draft) |
PEAP (Internet Draft) |
Software |
Client implementations |
Cisco, Funk, Meetinghouse, Microsoft, open1x (open source) |
Funk, Meetinghouse |
Microsoft |
Supported client Platforms |
Linux, Mac OS x,windows 95/98/me, Windows nt/2000/xp |
Linux, Mac OS X, Windows 95/98/me, Windows NT/2000/XP |
Windows XP |
Authentication server implementations by |
Cisco, Funk, HP, Freeradius (open source), Meetinghouse, Microsoft |
Funk, Meetinghouse |
Cisco |
Authentication Methods |
Client certificates |
ANY[1] |
Any EAP method[2] |
Protocol Operations |
BASIC protocol Structure |
Establish TLS session and validate certificates on both client and server |
Phases: (1) Establish TLS between client and TTLS server (2) Exchange Attribute-value pairs between client and server |
Parts: (1) Establish TLS between client and PEAP server (2) Run EAP Exchange over TLS tunnel |
Fast Session Reconnect |
No |
Yes |
Yes |
WEP Integration |
Server can supply WEP key with external protocol (e.g. RADIUS extension) |
PKI and Certificate Processing |
Server Certificate |
Required |
Required |
Required |
Client Certificate |
Required |
Optional |
Optional |
Cert Verification |
Through certificate chain or OCSP TLS extension (current Internet draft) |
Effect of private key compromise |
Re-issue all server and client certificates |
Re-issue certificates for servers (and clients if using the client certificates in first TLS Exchange) |
Client and User Authentication |
Authentication direction |
Mutual:uses Digital Certificates Both ways |
Mutual:certificate for server authentication, and tunneled method for client |
Mutual:certificate for server, and protected EAP method for client |
Protection of user Identity Exchange |
No |
Yes; protected by TLS |
Yes; protected by TLS |
[1] Currently, chap, PAP, MS-CHAP, and Ms-chapv2 is implemented in addition to EAP.
[2] only the "Generic token card" method was implemented in current shipping products.
EAP-TLS
EAP-TLS uses a TLS handshake as the basis for authentication. TLS has many attractive attributes, which make attractive for security-related use. It is the well documented and have been analyzed quite extensively. Study of the Protocol have not yet revealed significant weaknesses in the protocol itself. (Several implementations has suffered from bugs, however.)
TLS authenticates peers by exchanging digital certificates. In EAP-TLS, certificates is used to provide authentication in both directions. The server presents a certificate to the client, and, after validating the server ' s certificate, the client presents a CLI ENT certificate. Naturally, the certificate is protected on the client by a passphrase, PIN, or stored on a smart card, depending on th E implementation. One flaw in EAP-TLS protocol noted by many observers are that the identity exchange proceeds in the clear before Exchange O F certificates, so a passive attack could easily observe user names.
Digital certificates is the Achilles heel of EAP-TLS. The use of certificate authentication of clients mandates a concurrent PKI roll-out. If you does not already has a PKI in place, the additional work involved in issuing and managing certificates are quite larg E. In comparison with other pki-enabled protocols, EAP-TLS may impose a greater certificate management overhead because of The need to revoke certificates as users has wireless LAN access revoked.
The bottom line:eap-tls is secure and the requirement for client certificates are too big a hurdle for most institutions To deal with.
TTLS and PEAP
Both TTLS and PEAP were developed in response to the PKI barrier in EAP-TLS. Client certificates is not ideal for the user authentication for a variety of reasons. Other older methods of user authentication is as secure as certificate-based authentication, but without the high managem ENT overhead. Both TTLS and PEAP were designed to use older authentication mechanisms while retaining the strong cryptographic foundatio N of TLS.
The structure of TTLS and PEAP are quite similar. Both is two-stage protocols that establish security on stage one and then exchange authentication in stage one. Stage one of both protocols establishes a TLS tunnel and authenticates the authentication server to the client with a cert Ificate. (TTLS and PEAP still use certificates to authenticate the wireless network to the user, but only a few certificates would b e required, so it's much more manageable.) Once. Secure channel has been established, client authentication credentials is exchanged in the second stage.
TTLS uses the TLS channel to Exchange "Attribute-value pairs" (AVPs) and much like RADIUS. (In fact, the AVP encoding format was very similar to RADIUS.) The general encoding of information allows a TTLS server to validate AVPs against any type of authentication mechanism. TTLS implementations today support all methods defined by EAP, as well as several older methods (CHAP, PAP, MS-CHAP and MS -chapv2). TTLS can easily is extended to work with new protocols by defining new attributes to support new protocols.
PEAP uses the TLS channel to protect a second EAP exchange. Authentication must be performed using a protocol, that is, defined for use with EAP. In practice, the restriction to EAP methods are not a severe drawback because any "important" authentication protocol would Be-defined for use with EAP-order so, PEAP could use it. A far greater concern are client software support. PEAP is backed by Microsoft, and clients be beginning to become available for recent professional versions of Windows (XP Now, with Windows coming shortly). Suppliers of PEAP clients for other operating systems has yet to materialize, which could restrict PEAP to being used only In pure Microsoft networks.
One major difference between TTLS and PEAP as this article was written are that TTLS are much more widely implemented. TTLS products is available from multiple vendors and has been proven interoperable by a number of the public demonstrations. TTLS software is also available for a wide range of client operating systems. In contrast, PEAP products is only beginning to come to the market. The first public interoperable PEAP demonstration I am aware of took place at the Networld+interop trade show in Atlanta l AST month. The demonstration required the use of a late pre-release copy of Ciscosecure ACS, the only authentication server that Curr Ently supports PEAP, as well as a Windows XP client. Although nothing under the PEAP specification prevents development of software for Non-windows systems, it's hard-to-see Mic Rosoft taking the initiative to develop PEAP clients for other client platforms.
Conclusion
Selection of an authentication method are the key decision in securing a wireless LAN deployment. The authentication method drives the choice of authentication server, which in turn drives the choice of the client software. Fortunately, selecting an authentication method is a reasonably straightforward endeavor. Unless you has a well-oiled PKI already deployed, bypass EAP-TLS to avoid the client certificate headaches. Though There is not a large technical difference between the TTLS and PEAP protocols, TTLS have a number of slight advantag Es. In addition to a slight degree of flexibility at the protocol level, products is available now and support a much wider V Ariety of client operating systems.
Matthew Gast is a member of the business development team at NetScreen Technologies, where he works with strategic partner S and alliances. He is also the author of O ' Reilly ' s 802.11 Wireless networks:the definitive Guide.
Http://archive.oreilly.com/pub/a/wireless/2002/10/17/peap.html
"Turn" A Technical Comparison of TTLS and PEAP