A Technical Comparison of TTLS and PEAP
by Matthew Gast author of 802.11 Wireless Networks: The Definitive Guide10/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.
|
Related Reading 802.11 Wireless Networks: The Definitive Guide |
Return to the Wireless DevCenter
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 28 of 28.
-
Mac OS X does LEAP/PEAP to ACS, PEAP to ACS with SecurID token auth
2004-07-06 14:48:42 chrisshenton [Reply | View]
We have gotton Mac OS X 10.3 to auth over PEAP and LEAP to a Cisco ACS server with locally-stored passwords. We've also gotton it to auth over PEAP to the ACS when the ACS authenticates "unknown users" to a backend SecurID server (over RADIUS to its RADIUS front-end, or over SecurID's proprietary protocol). Works great.
The Windows guys are having a tough time with W2K, WXP, Cisco ACU, MS's supplicant. No joy with SecurID so far.
-
TTLS versus PEAP
2003-12-11 19:04:11 anonymous2 [Reply | View]
I really am entertained about those that endorse PEAP over TTLS because it is pushed by Microsoft...
Sounds like a GREAT idea to me.. especially when Microsoft cannot keep viruses under control with all their vulnerabilites they have on a day by day basis.. Remember Nimda, Sobig, Welchia. For those of you endorsing PEAP because Microsoft developed it, take time to pat Microsoft on the back... I am sure those of us IT professionals who work hard cleaning up the mess caused by the viruses will appreciate it.
One last point.... Take a Wireless Sniffer like Wild Packets AiroPeek and watch the EAP authentication for PEAP before the protected tunnell is setup.... What the unencrypted username go by... Don't worry it will get encrypted but not before the tunnell is setup. You can see this with AiroPeek. Now go back and do the same thing with TTLS and use the Odyssey client to send anonymous to foil the WLAN hacker with a sniffer. Guess what you will see in AiroPeek... anonymous. Now you tell me which one is more secure: TTLS or PEAP...
Remember we are talking about Wireless....
Do you want your company to be another WLAN hack statistic because of Microsoft's lack of concern for security.
Oh, and do remember there are 2 versions of PEAP. Cisco and Microsoft went divided in their efforts and each did their own implementation.
JMK, CISSP -
TTLS versus PEAP
2003-12-22 07:26:39 anonymous2 [Reply | View]
I would like to add something else against the Microsoft PEAPv0 implementation that is part of the Windows XP sp1 and Windows 2003 IAS: It seems that the IAS RADIUS server in sending in the clear to the access point the FULL MSCHAP V2 exchange(Challenge, Peer Challenge, NTResponse...) in RADIUS attribute in one of the last success RADIUS frame. The power of the PEAP implementation was that this exchange (in the Phase 2) was encrypted by the TLS established in the phase1. So why is IAS sending in the clear this exchange at the end of the authentication.
It seems that it is a huge security issue, or maybe i am mistaking...
-
Clarifications
2003-04-18 09:44:23 anonymous2 [Reply | View]
The article was a good start. There are some inaccuracies; and probably things have changed since the article was written.
I didn't see the advantages in TTLS claimed in the article.
This is what I found out which is different than mentioned in the article.
PEAP is authored by Cisco, MS, RSA.
PEAP seems to be available from more vendors than TTLS.
PEAP RADIUS servers are available from Microsoft, Funk, Meetinghouse (Windows and Linux), Cisco, Radiator.
PEAP clients are available on many systems including Win95/98/ME, NT, 2000/XP, Pocket PC 2002.
TTLS supports 3 choices for password authentication(PAP, CHAP, MSCHAPv2) and PEAP supports one (MSCHAPv2). I probably don't need three.
Cisco PEAP supports One-time-passwords. Microsoft PEAP supports passwords; and allows other vendors to provide EAP methods that work inside PEAP. TTLS supports passwords and one-time-passwords.
Microsoft PEAP supports authentication of machines or users. Machine verification seems useful in certain situations.
-
regarding TTLS : AVP's format
2004-03-16 22:49:04 useme1 [Reply | View]
Can you people please guide me on how to encapsulate PAP,CHAP,MS-CHAP messages in AVP formats.
I am a new bee to this EAP-TLS and TTLS.
Any useful documents or open source for the same would be of great help
Much Thanks -
Clarifications
2003-05-16 14:39:46 anonymous2 [Reply | View]
Hmmm... MSCHAPv2 which requires a database that supports MSCHAPv2 or passwords stored in plain-text. Therefore no authenticating PEAP to LDAP or SQL(unless sql database supports MSCHAPv2). That alone gives the edge to TTLS. There's a free TTLS client for W2k/XP from http://www.alfa-ariss.com -
Clarifications
2003-06-13 12:48:08 anonymous2 [Reply | View]
The information seems technically incorrect.
MSCHAP does not require passwords stored in plain-text; and this is considered one of the many advantages of MSCHAP compared to CHAP. CHAP requires the password to be stored in plain-text.
MSCHAP protocol can be used with SQL. A number of RADIUS servers support PPP-MSCHAP with SQL.
If there is indeed a real demand for SQL with MSCHAPv2, then it maybe just a question of time before RADIUS vendors support it. -
MS-Chap is designed for MS Databases
2003-07-07 08:51:37 anonymous2 [Reply | View]
Here is the issue: When using the MS-CHAP or MS-CHAPv2 protocols, the Challange exchange between the RADIUS server and the supplicant are based on the NT-Hash of the users password. This means that the Database that the RADIUS server looks at needs to have access to the NT-Hash of the users password, not the clear text version of the password. This is fine if your database happens to be Active Directory, because this is how passwords are stored in AD, but if it is LDAP, or SQL, you would have to go through some process to get the NT-hash of all your users passwords into this other database. This is why EAP-MSChapv2 (and thus Micosoft's PEAP supplicant) is really only good if your database is Microsoft.
-
MS-Chap is designed for MS Databases
2003-07-08 21:59:41 anonymous2 [Reply | View]
Sorry, the information above seems technically incorrect.
It is trivial to create the hash from the clear text password, and this can be done by the RADIUS server during authentication. SQL databases typically store the password in clear text. -
MS-Chap is designed for MS Databases
2003-07-28 16:11:26 anonymous2 [Reply | View]
Actually it is correct, but probably deserves a more detailed explanation.
>> It is trivial to create the hash from the clear text password, and this can
>> be done by the RADIUS server during authentication.
This is correct, but unfortunately in a PEAP(MS-CHAP-V2) exchange, the RADIUS server never receives the clear text password from the user.
Remember, CHAP, MS-CHAP and MS-CHAP-V2 are all challenge based exchanges, where the server generates a random challenge, and sends it to the supplicant. The supplicant then uses that challenge to hash the user’s password, returning the result in a challenge response to the server. The server then uses the same challenge that was sent to the supplicant to hash it's stored version of the password, and it compares it's result with the result returned in the challenge response. If they match, then the user must have supplied the same password that the server retrieved from the database.
The tricky part is that with MS-CHAP, when the supplicant receives the challenge from the server, it hashes the NT-Hash of the password with the challenge, and returns the NT-HASH-HASH of the password in the challenge response. This means that the server also has to use the NT-Hash of the password as input in order for the results to match.
Hopefully it makes a bit more sense this time :)
The bottom line:
PEAP(MS-CHAP-V2) will only work when the database that the RADIUS server is pointing to stores the user’s NT-HASH of their password.
-
Funk Software RADIUS support MS-CHAP-V2 in Solaris
2003-07-07 17:53:52 anonymous2 [Reply | View]
For your Information, Funk has recently released its latest RADIUS server running on the both Windows and Solaris platform.
I have tested the solaris version and it supports Microsoft PEAP (which requires MS-CHAP-V2 for inner-authentication). It worked fine with Microsoft XP Service Pack 1 PEAP and Funk's client software 'Odyssey Client'.
I don't think nobody can say which protocol is which. It is only the decision of the network administrators or wlan security policy admin to use PEAP or TTLS.
But if I am, I will use TTLS with Funk. Easier but expensive. -
Funk Software RADIUS support MS-CHAP-V2 in Solaris
2003-10-04 09:40:16 pppeterd [Reply | View]
TTLS and PEAP are functionally similiar. TTLS encodes data in RADIUS AVPs while PEAP is just another EAP session instead of a TLS(SSL) tunnel.
There are some opportunities for PEAP to be more secure than TTLS. The latest drafts establish a cryptographic binding between the TLS channel and the authentication protocol itself (For example MSCHAPv2) making some man-in-the-middle attacks harder to pull off.
Anyway lots of RADIUS servers are starting to support PEAP and or TTLS. SBR, Interlink, RadiusNT/X, Radiator..etc. PEAPs big advantage in the market can be summed up with one word.. "Microsoft". There are client options for TTLS, and some of them may be free.. But it boils down to some 90 something percent of clients running a MS operating system who already have the required software installed.
-
Two Different PEAPs
2003-02-11 12:04:22 anonymous2 [Reply | View]
Is anyone aware that Microsoft's PEAP and Cisco's PEAP are not compatible? -
Two Different PEAPs
2003-04-05 02:32:26 anonymous2 [Reply | View]
Yup.. sure am. I found that out when I was chosing which vendor to use for a 50 AP rollout...
It REALLY gave me the craps.
The reason is that PEAP is EAP within EAP and both Cisco and MS use different forms for the 2nd level EAP exchange. (MS uses MS-CHAP v2 and Cisco uses... ? not 100% sure)
You really have 2 choices at the moment (but there is a resolution in the wind that I'll get to in a second)
[1] Use the ACU on the clients and a CiscoSecure ACS server
[2] Use only windows 2000/XP clients and you can use MS IAS server
The resolution in the wind in the new version of the Cisco ACU which will support PEAP for MS IAS.
Cheers,
Graham Robinson
grahamr@simplywireless.com.au
-
Two Different PEAPs
2003-07-07 08:54:01 anonymous2 [Reply | View]
Another option would be to use Funk's Odyssey Server, which supports both versions of PEAP -
Two Different PEAPs
2003-10-04 10:13:15 pppeterd [Reply | View]
Its funny, there are really Three different versions of PEAP. Hopefully everyone will leave the v2 drafts mature and out of the equation at least until my head stops spinning :)
I think you'll find most RADIUS servers that support PEAP support both (0 and 1) versions. Including Ciscos ACS server.
-
EAP-TTLS
2003-01-15 06:36:27 anonymous2 [Reply | View]
I'm serching for a radius server FREE that support EAP-TTLS.
Thanks all for your time
Daniele Brevi
MAIL danibreviNOSPAM@libero.it
-
RE: PEAP Clarifications
2002-12-13 08:06:29 anonymous2 [Reply | View]
Microsoft announced support for 802.1x w/ PEAP in early November of this year. Since then, however, they've pulled their clients and modified their announcement so that support is only offered on Win 2000 & XP. I do not know why they have done this, although I can speculate ... One of my peers still has the Microsoft NT4.0 PEAP client. Given this recent change, much of your response makes sense.
A heavily entrenched Microsoft & Cisco infrastructure does in fact matter in buying decisions, and is not irrelevent to a TTLS vs. PEAP decision, albeit perhaps not soley on technical merit. I agree with you that TTLS & PEAP are very similar technically, but I do not hold the same philosophy of implementing immediately without considering the future ramifications. Because TTLS & PEAP are so similar, it makes sense that only one will become the dominant industry leader/standard. I would not want to invest a substantial amount of energy into implementing TTLS, only to see it never really take off, and receive minimal support and updates over the long run. Clearly, you can gather from my response that I think PEAP will become the dominant of the two solutions.
Additionally, you have to ask which direction embedded wireless handheld devices will go. Are the major players in that industry licensing PEAP or TTLS for positioning?
If someone needs instant security, but has a significant user base of pre-Win2000 laptops, another solution would be to implement 802.1X w/ LEAP and enforcing a strong password policy. By using ACS and Aironet client cards, the move to PEAP would be easier.
-
No Two Factor Authentication in TTLS
2002-11-29 10:45:29 pauldodd [Reply | View]
It's refreshing to see a technically accurate description of WLAN Security instead of the usual hype and misinformation.
However, one topic didn't seem to get much attention in the article. The article mentions the need for "strong authentication" on a WLAN, but it doesn't discuss the relative merits of different authenticators. While it's still a topic of debate in the security community, I think it's generally accepted that static passwords are insufficient where you don't have adequate compensating controls (such as physical security). They are particularily inadequate where you have any type of remote access, which includes Internet-based VPN's, dial-up, and WLAN.
For such situations, a strong case can be made to require two factor authentication. Of the three authentication methods discussed, only EAP-TLS and PEAP currently support two factor authentication. So for sites that have a policy that requires two factor authentication for remote access, there is one less choice.
The PKI requirements of EAP-TLS make PEAP a compelling choice, and we are lucky that more PEAP supplicants are being released. Cisco is shipping their code, and other WLAN vendors are sure to follow. Hopefully, two factor authentication will be added to TTLS to enable more choices for buyers and implementers.
Paul Dodd, CISSP -
No Two Factor Authentication in TTLS
2003-07-07 09:05:01 anonymous2 [Reply | View]
>> Hopefully, two factor authentication will be >> added to TTLS to enable more choices for
>> buyers and implementers.
TTLS was the first to market with two factor solution (EAP-TTLS(PAP/Token Card)nearly a year and a half ago Peap is only now beginning to catch up.
Keep in mind that TTLS also supports EAP methods as the secondary authentcation, so you can do TTLS(EAP-Generic Token Card) as well
-
Two Factor Authentication in TTLS with RSA SecurID
2002-12-10 16:34:13 Matthew Gast [Reply | View]
> Of the three authentication methods discussed,
> only EAP-TLS and PEAP currently support two
> factor authentication. So for sites that have a
> policy that requires two factor authentication
> for remote access, there is one less choice.
TTLS supports tunneling using token cards such as SecurID or Secure Computing's SafeWord. You can pass a username and a token code to the two-factor authentication server.
As an example, RSA has certified the use of Funk's Odyssey TTLS client with the ACE Server and SecurID. (See RSA's page for details, as well as the Implementation Guide with the details.)
-
PEAP Clarifications
2002-11-26 09:27:34 anonymous2 [Reply | View]
There are several points on PEAP in this article that are either incorrect, could use some clarification, or have been changed since its writing.
1. I think it's worth mentioning that PEAP Internet Draft is being driven by Cisco, Microsoft, & RSA.
2. Microsoft does not have the only PEAP client implementation. Cisco has PEAP built into its client as well, and other open source linux groups are working on integrating PEAP support on both the client & server.
3. Since the writing of the article, Microsoft has released 802.1X w/ PEAP support in most of its desktop OS's: WinNT4.0, 95/98/ME, Win2K, & XP.
4. Both Microsoft & Cisco have PEAP authentication servers. OSC Radiator for Linux will authenticate PEAP clients. I am confident that other PEAP-capable RADIUS servers exist.
Taking these points into consideration, I wonder if the article's conclusion was a bit too skewed to imply that PEAP would not have enough industry support or distribution.
In reality, it will be corporations that deploy a RADIUS based security solution for securing 802.11 WLAN's, and not your typical SOHO. I would be willing to bet that these corporations have significant investments into Microsoft & Cisco assets. The logical conclusion is not that difficult to guess:
A) Corporations typically use MS OS and it is probable that a Cisco infrastructure exists as well.
B) PEAP Internet draft is being led by Microsoft, Cisco, & RSA.
C) Corporations will be positioned to use PEAP over TTLS.
-
PEAP Clarifications
2002-12-10 16:18:11 Matthew Gast [Reply | View]
> 2. Microsoft does not have the only PEAP client
> implementation. Cisco has PEAP built into its
> client as well, and other open source linux
> groups are working on integrating PEAP support
> on both the client & server.
At the time the article was written, PEAP were not widely available. The Cisco PEAP client was not shipping during N+I Atlanta 2002, though it was planned for release shortly afterward. The only PEAP client we could obtain at the time was the Microsoft client for Windows XP.
> ... Microsoft has released 802.1X w/ PEAP
> support in most of its desktop OS's: WinNT4.0,
> 95/98/ME, Win2K, & XP.
PEAP was added to XP in a service pack on September 7. PEAP was added to Windows 2000 with a download on December 3 (http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/8021xclient.asp).
However, I can't find the code for the earlier Windows operating systems. Microsoft announced support for PEAP in desktop OSes on February 13, 2002 (http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/secwireless.asp), but that announcement was written saying that Microsoft would support PEAP in the future.
A series of searches for "PEAP" on the Microsoft's Web site failed to turn up the desktop PEAP implementations for Windows 95/98/ME and Windows NT 4.0. The only result from running a search on "PEAP" in the Windows area is a page about the new features in .NET Server 2003.
A general search throughout Microsoft yields a large number of technical documents, such as the definition of PEAP in TechNet (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsnetserver/proddocs/datacenter/sag_ias_protocols_peap.asp). The definition is still listed as "preliminary and subject to change."
> Taking these points into consideration, I
> wonder if the article's conclusion was a bit
> too skewed to imply that PEAP would not have
> enough industry support or distribution.
I never meant to imply that PEAP would not have wide support. There is a great deal that Microsoft and Cisco can do to create support. All I meant to illustrate is that QA-tested and released TTLS-based products were generally available at the time I wrote the article, while PEAP was still coming together as a solution. If a buyer were looking for a solution that could be purchased and deployed immediately, TTLS is the only choice. (Unless anybody can point out the client support for Win95/98/ME, it may still be the only choice today.)
Buyers who are willing to wait for a PEAP-based solution are welcome to do so.
> A) Corporations typically use MS OS and it is
> probable that a Cisco infrastructure exists as
> well.
This point is irrelevant to a choice between PEAP and TTLS. There is an extensive installed base of Microsoft operating systems in corporations supported by TTLS today. (Unless I missed the Win95/98/ME and NT4 downloads a minute ago, it may still be the only choice today!)
> C) Corporations will be positioned to use PEAP
> over TTLS.
Unless they need a solution right now, in which case they can adopt TTLS today. There is no technical advantage to waiting for PEAP, since the protocol is similar. Running code counts for a lot in my book.
-
Lucent Radius..not that great.
2002-10-28 08:39:17 anonymous2 [Reply | View]
It does not support TTLS though. And how long will you wait till it supports PEAP?
-
Lucent Radius & MacOSX TTLS
2002-10-19 01:40:05 fmiserey [Reply | View]
I noticed that www.lucentradius.com isn't mentioned here although it is a great product. We've been using it since its first inception (1999) and the product has always evolved like we dreamed of. </ads ;)>
MacOSX is listed as supporting TLS and TTLS. May someone explain how ? -
MacOS X support for TTLS
2002-12-10 15:37:47 Matthew Gast [Reply | View]
> MacOSX is listed as supporting TLS and TTLS.
> May someone explain how ?
As an example, The Meetinghouse Data Communications (http://www.mtghouse.com) Aegis client was released in July, and supports OS X.
Interestingly, TTLS still seems to be the most widely supported on the client end... at least when you consider non-MS OS's.
Additionally, PEAP suffers some security issues if you want to use u:p authentication -- you have to store the passwords in plaintext or at least reversible encryption. This is inherently insecure and a big "no-no". Yes, you can hack the PEAP-GTC EAP method to do it, but it is just that -- a hack. TTLS, on the other hand will let you use PAP within the tunnel to authenticate, meaning you can store passwords that have been crypt()'d or otherwise secured... PEAP uses CHAP, which uses a challenge-handshake, and can only prove that it knows the right password -- but the server has to have the plaintext password available, too.
All in all, TTLS appears to be the most robust, cheapest and all round best way of doing things, especially if you have to support non-MS OS's.
Oh, and someone had commented about using LEAP -- This is a Bad Idea. Major security flaws have been discovered in LEAP, and you had might as well stick with WEP, too, while you're at it!
-kb
--
Kris Benson, CCP, I.S.P.