Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

As I understood EAP-TTLS and PEAP share same level of security when implemented in wireless networks. Both only provide server side authentication via certificate.

The drawback of EAP-TTLS can be non native support in Microsoft Windows so every user has to install additional software.

The benefit of EAP-TTLS can be support for less secure authentication mechanisms (PAP, CHAP, MS-CHAP) but why would you need them in modern and properly secure wireless system?

What are you opinions? Why should I implement EAP-TTLS instead of PEAP? Let's say that I have most Windows users, medium Linux users and least iOS, OSX users.

share|improve this question

6 Answers 6

up vote 1 down vote accepted

You can support both, if your RADIUS backend supports it. However some clients "auto"-connects (Mac OS X >= 10.7 + iOS for example), and they might work less than optimal if you support more than one type, since they just try different combinations until one of them works i.e. they connect with less hassle if there's only one way to connect.

So Basically: support PEAP only, or PEAP+TTLS if you have clients that require TTLS.

share|improve this answer

PEAPv0, PEAPv1 and TTLS have the same security properties.

PEAP is a SSL wrapper around EAP carrying EAP. TTLS is a SSL wrapper around diameter TLVs carrying RADIUS authentication attributes.

EAP-TTLS-PAP can be useful over EAP-PEAP if backend authentication database store credentials in a non-reversable hash format such as bigcrypt or any form not compatible with MSCHAP (NT-OWF) In this case it is not possible to authenticate using any of the CHAP based methods.

While you could also emulate PAP using EAP-PEAPv1-GTC this is not as widely supported by clients.

PEAP has some added baggage over TTLS in the form of PEAP version negotiation headaches and historical incompatibilities in PEAPv1 (Such as client magic when deriving master key from PRF) which have made their way into early implementations.

I normally see EAP-TTLS implemented in embedded clients such as subscriber modules in wireless gear with PEAP used more by laptop computers and mobile handsets.

EAP-TTLS has historically not been supported in Windows clients without having to install third party software. EAP-TTLS is now supported starting with Windows 8.

Some additional thoughts:

EAP-TTLS was invented by a RADIUS vendor. EAP-PEAPv0 was invented by Microsoft. EAP-PEAPv1 came out of the IETF process.

There was some additional IETF work on a PEAPv2 which would have made the system more secure by way of crypto bindings to inner authentication methods. This has not gone anywhere as near as I can tell.

share|improve this answer

As disk eater wrote, the main reason people use TTLS is you can allow your radius server to see the cleartext password that way, which can be useful depending on your authentication backend.

A newer consideration that might favor PEAP is that SoH is AFAICT only presented to the RADIUS server if it asks for it, and the only way to ask for it on Microsoft systems is during a PEAP session. So if you want to get agent-like assessment out of agentless assessment (support by more AV vendors probably forthcoming) you'd want PEAP, however if you are looking to work around a 1-factor OAUTH backend by taking a naked password (because heck, the big IDPs that won't provide an inner tunnel service deserve no less and their users are clueless enough to type it in) use TTLS.

share|improve this answer

You have to consider what EAP methods the client supports natively vs. with additional software and what inner authentication methods the server supports.

PEAP and EAP-TTLS are designed to let you validate the identify of the server, but you have to make sure that clients are properly configured to validate the certificate.

PEAP and MS-CHAPv2 are well-supported by clients, but if your server doesn't support MS-CHAPv2 (because you don't store cleartext passwords), you have to come up with another solution. That's the main reason you'll see people use EAP-TTLS and PAP.

share|improve this answer

I think auto-connect would benefit from both options, the more options the less hassle... eg. if auto-connect tries TTLS-PAP first and then PEAP-MSCHAP, the auto-connect is faster with TTLS-PAP available. So basically: support both, I can't see a disadvantage.

Since MSCHAPs security is broken (google for "crack mschap") pap with cleartext password through ttls has the same level of security as PEAP-MSCHAP.

share|improve this answer

I don't know of any differences in security between EAP-TTLS and PEAP, so it basically comes down to support, where PEAP is the winner.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.