A Technical Comparison of TTLS and PEAP
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 |
Broadly speaking, wireless LAN security has two major issues. Authentication of network users is not strong, so unauthorized users may be able to access network resources. Traffic encryption is also weak, so attackers are able to recover transmissions. Strong authentication is a key component of wireless LAN security because it prevents unauthorized users from gaining network access. Wireless LAN protocols are also designed in such a way that bolstering the access control also makes it quite easy to shore up the encryption of traffic, to the point where deploying products to improve authentication will 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 protocols for use with wireless LANs. The key standard for wireless LAN authentication is the IEEE 802.1x standard, which is in turn based on the IETF's Extensible 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 is to decide on the type of authentication that will be used. The authentication method is the key decision to make in deploying a wireless network, since it will drive all the product choices you make.
TLS-based Authentication Methods
802.1x was initially developed for authentication of users on traditional wired LANs, and therefore did not require strong encryption. Eavesdropping is certainly possible on wired networks, though it requires physical access to network equipment. Wireless networks are much easier to perform traffic analysis on because physical access to the network does not require physical access to the network equipment. Frames on wireless networks can be 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 are connecting to legitimate access points that are 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 networks they connect to.
These two requirements, strong encryption to prevent eavesdropping and mutual authentication to ensure that sensitive information 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 encryption and authentication requirements. Three TLS-based protocols have been developed for use with EAP and are 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 are 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 | Two phases: (1) Establish TLS between client and TTLS server (2) Exchange attribute-value pairs between client and server | Two 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 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 are implemented in addition to EAP.
[2] Only the "generic token card" method is implemented in current shipping products.
EAP-TLS
EAP-TLS uses a TLS handshake as the basis for authentication. TLS has many attractive attributes that make attractive for security-related use. It is well documented and has been analyzed quite extensively. Study of the protocol has not yet revealed significant weaknesses in the protocol itself. (Several implementations have suffered from bugs, however.)
TLS authenticates peers by exchanging digital certificates. In EAP-TLS, certificates are 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 client certificate. Naturally, the certificate may be protected on the client by a passphrase, PIN, or stored on a smart card, depending on the implementation. One flaw in EAP-TLS protocol noted by many observers is that the identity exchange proceeds in the clear before exchange of certificates, so a passive attack could easily observe user names.
Digital certificates are the Achilles heel of EAP-TLS. The use of certificate authentication of clients mandates a concurrent PKI roll-out. If you do not already have a PKI in place, the additional work involved in issuing and managing certificates is quite large. 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 have wireless LAN access revoked.
The bottom line: EAP-TLS is secure, but the requirement for client certificates is 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 are not ideal for user authentication for a variety of reasons. Other older methods of user authentication are as secure as certificate-based authentication, but without the high management overhead. Both TTLS and PEAP were designed to use older authentication mechanisms while retaining the strong cryptographic foundation of TLS.
The structure of TTLS and PEAP are quite similar. Both are two-stage protocols that establish security in stage one and then exchange authentication in stage two. Stage one of both protocols establishes a TLS tunnel and authenticates the authentication server to the client with a certificate. (TTLS and PEAP still use certificates to authenticate the wireless network to the user, but only a few certificates will be required, so it is much more manageable.) Once that secure channel has been established, client authentication credentials are exchanged in the second stage.
TTLS uses the TLS channel to exchange "attribute-value pairs" (AVPs), much like RADIUS. (In fact, the AVP encoding format is 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 be 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 is not a severe drawback because any "important" authentication protocol would be defined for use with EAP in short order so that PEAP could use it. A far greater concern is client software support. PEAP is backed by Microsoft, and clients are beginning to become available for recent professional versions of Windows (XP now, with Windows 2000 support coming shortly). Suppliers of PEAP clients for other operating systems have yet to materialize, which may restrict PEAP to being used only in pure Microsoft networks.
One major difference between TTLS and PEAP as this article was written is that TTLS is much more widely implemented. TTLS products are available from multiple vendors and have been proven interoperable by a number of public demonstrations. TTLS software is also available for a wide range of client operating systems. In contrast, PEAP products are only beginning to come to market. The first public interoperable PEAP demonstration I am aware of took place at the Networld+Interop trade show in Atlanta last month. The demonstration required the use of a late pre-release copy of CiscoSecure ACS, the only authentication server that currently supports PEAP, as well as a Windows XP client. Although nothing in the PEAP specification prevents development of software for non-Windows systems, it is hard to see Microsoft taking the initiative to develop PEAP clients for other client platforms.
Conclusion
Selection of an authentication method is 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 client software. Fortunately, selecting an authentication method is a reasonably straightforward endeavor. Unless you have 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 has a number of slight advantages. In addition to a slight degree of flexibility at the protocol level, products are available now and support a much wider variety of client operating systems.
Matthew Gast is a member of the business development team at NetScreen Technologies, where he works with strategic partners 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