Я не знаю каких-либо различий в безопасности между EAP-TTLS и PEAP, поэтому в основном все сводится к поддержке, где PEAP является победителем.

PEAPv0, PEAPv1 and TTLS have the same security properties.

PEAP is a SSL wrapper around EAP carrying EAP.

Обычно я вижу, что EAP-TTLS реализован во встроенных клиентах, таких как абонентские модули в беспроводном оборудовании, с PEAP, используемым больше портативными компьютерами и мобильными телефонами.

EAP-TTLS исторически не поддерживался в клиентах Windows без необходимости установки третьего партийное программное обеспечение. EAP-TTLS теперь поддерживается, начиная с Windows 8.

Некоторые дополнительные мысли:

EAP-TTLS был изобретен поставщиком RADIUS. 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.

Вы должны учитывать, какие методы EAP клиент поддерживает изначально, а какие с дополнительным программным обеспечением, и какие методы внутренней аутентификации поддерживает сервер.

PEAP и EAP-TTLS разработаны, чтобы позволить вам проверить идентификацию сервера, но вы должны убедиться, что клиенты правильно настроены для проверки сертификата.

PEAP и MS-CHAPv2 хорошо поддерживаются клиентами, но если ваш сервер не поддерживает MS-CHAPv2 (потому что вы не храните пароли в открытом виде), вам нужно придумать другое решение. Это основная причина, по которой вы увидите, что люди используют EAP-TTLS и PAP.

Как писал пожиратель дисков, основная причина, по которой люди используют TTLS, заключается в том, что вы можете разрешить своему серверу RADIUS видеть пароль в открытом виде таким образом, что может быть полезно в зависимости от вашего бэкенда аутентификации.

A новое соображение, которое может отдать предпочтение PEAP, состоит в том, что SoH AFAICT предоставляется серверу RADIUS только в том случае, если он его запрашивает, и единственный способ запросить его в системах Microsoft - это во время сеанса PEAP. Поэтому, если вы хотите получить агентную оценку из безагентной оценки (поддержка со стороны других поставщиков AV, вероятно, будет в будущем), вам понадобится PEAP, однако, если вы хотите обойти однофакторный бэкэнд OAUTH, взяв открытый пароль (потому что черт возьми, крупные IDP, которые не будут предоставлять службу внутреннего туннеля, заслуживают не меньшего, а их пользователи достаточно невежественны, чтобы ввести его) используют TTLS.

Я думаю, что автоподключение выиграет от обоих вариантов, чем больше вариантов, тем меньше хлопот ... 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.

Клиентские ограничения

• iOS-клиенты не будут поддерживать EAP-TTLS с помощью PAP (только MsCHAPv2), если вы вручную (через компьютер) не установите профиль.

• Клиенты Windows не будут поддерживать EAP-TTLS (вам нужно будет установить программное обеспечение типа secure2w), если только у них нет беспроводных карт Intel.

• Android поддерживает практически все комбинации EAP и PEAP.

Ограничения базы данных паролей

Таким образом, настоящая проблема заключается в том, как хранятся ваши пароли.

Если они есть:

• Active Directory, то можно использовать EAP-PEAP-MsCHAPv2 (коробки Windows) и EAP-TTLS-MsCHAPv2 (с клиентами iOS).

• Если вы храните пароли на LDAP, то можно использовать EAP-TTLS-PAP (коробки Windows), но при этом вы будете утеряны из-за iOS.

Важные вопросы безопасности

• Как EAP-TTLS, так и PEAP используют TLS (безопасность на транспортном уровне) поверх EAP(протокол расширяемой аутентификации).

Как вы, возможно, знаете, TLS является более новой версией SSL и работает на основе сертификатов, подписанных доверенным центральным центром (Certification Authority - CA).

Чтобы создать TLS туннель, клиент должен подтвердить, что он разговаривает с правильным сервером (в этом случае радиус-сервер, используемый для аутентификации пользователей). Он делает это, проверяя, представил ли сервер действительный сертификат, выданный доверенным центром сертификации.

Проблема в том, что обычно у вас не будет сертификата, выданного доверенным центром сертификации, а сертификата, выданного ad-hoc центром сертификации, который вы сделали специально для этой цели. Операционная система будет жаловаться пользователям на то, что она не знает, что CA и пользователи (ориентированные на вас) с радостью это примут.

Но это создает большой риск безопасности:

Кто-то может установить неавторизованную точку доступа внутри вашего бизнеса (в сумке или даже на ноутбуке), настроить ее на разговор со своим радиус-сервером (работающим на ноутбуке или на собственной неавторизованной точке доступа).

Если ваши клиенты обнаружат, что эта точка доступа имеет более сильный сигнал, чем ваши точки доступа, они попробуют подключиться к ней. Увидит неизвестный CA (пользователи принимают), создаст TLS туннель, отправит аутентификационную информацию по этому туннелю, а неавторизованный радиус зарегистрирует его.

Теперь важная часть: если вы используете схему аутентификации открытым текстом (PAP, например), неавторизованный радиус-сервер будет иметь доступ к паролям ваших пользователей.

Вы можете решить эту проблему, используя действительный сертификат, выданный сертификационным центром, которому доверяют и iOS, и Windows (и Android). Или же вы можете раздать корневой сертификат ЦС своим пользователям и сообщить им об отказе в соединении, когда они увидят проблемы с сертификатом (удачи вам в этом)