Why would you use EAP-TTLS instead of PEAP?

Solution 1:

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.

Solution 2:

Client restrictions

• iOS clients won’t support EAP-TTLS with PAP (only MsCHAPv2) unless you manually (via a computer) install a profile.

• Windows clients won’t support EAP-TTLS out-of-box (you’ll need to install a software like secure2w), unless they have Intel wireless cards.

• Android support almost all combinations of EAP and PEAP.

Password database restrictions

Thus, the real problem is how your passwords are stored.

If they are in:

• Active Directory, then you can use EAP-PEAP-MsCHAPv2 (Windows boxes) and EAP-TTLS-MsCHAPv2 (with iOS clients).

• If you store passwords on LDAP, you can use EAP-TTLS-PAP (Windows boxes) but you will be lost about iOS.

Important Security Concerns

• Both EAP-TTLS and PEAP use TLS (Transport Layer Security) over EAP(Extensible Authentication Protocol).

As you may know, TLS is a newer version of SSL and works based on certificates signed by a trusted central authority (Certification Authority - CA).

To establish a TLS tunnel, the client must confirm it is talking to the correct server (In this case, the radius server used to authenticate users). It does that by checking if the server presented a valid certificate, issued by a trusted CA.

Problem is: normally, you won’t have a certificate issued by a trusted CA, but one issued by an ad-hoc CA you made just for this purpose. Operational system will complain to users that it doesn't know that CA and users (as oriented by you) will happily accept that.

But this poses a major security risk:

Someone can setup a rogue AP inside your business (in a bag or even on a laptop), configure it to talk to his own radius server (running on his laptop or at the own rogue AP).

If your clientes find this AP to have a stronger signal then your access points, they will try connecting to it. Will see an unknown CA (users accept), will establish a TLS tunnel, will send authentication information on this tunnel and the rogue radius will log it.

Now the important part: if you are using a plain text authentication scheme (PAP for example), the rogue radius server will have access to your users passwords.

You can solve that by using a valid certificate issued by a Certification Authority both iOS, Windows (and Android) trust. Or, you can distribute the CA root certificate to your users and inform them to refuse connecting when they see certificate problems (good luck with that).

Solution 3:

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 (rather than EAP-PEAP or EAP-TTLS) if the 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.