The most upvoted 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-reversible 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
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
The accepted answer was:
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
Source: Why would you use EAP-TTLS instead of PEAP?