Windows Wi-Fi с 802.1X + EAP-TTLS + EAP-MSCHAPv2 и клиентскими сертификатами

Question

Ооочень ... У нас есть обязательное требование, чтобы клиенты, желающие присоединиться к нашей беспроводной локальной сети, представили действительный сертификат компьютера, выданный нашим внутренним корневым центром сертификации. Это сделано для того, чтобы злоумышленники, имеющие правильную комбинацию имени пользователя и пароля, не могли подключиться к беспроводной локальной сети. В конце концов, проще получить рабочее имя пользователя и пароль, чем действительный сертификат.

До Windows 8.x мы использовали EAP-TLS в качестве внешнего протокола аутентификации, чтобы удовлетворить это требование, и использовали внутренний протокол аутентификации для проверки имени пользователя и пароля в нашей AD.

В Windows 8.1 кажется, что EAP-TLS больше не поддерживается (по крайней мере, его нельзя настроить в графическом интерфейсе. Если я ошибаюсь, укажите ссылку, как это делается). Поэтому я начал экспериментировать с EAP-TTLS в качестве внешнего протокола аутентификации и EAP-MSCHAPv2 в качестве внутреннего протокола аутентификации. Хотя это работает, я не могу включить сертификат клиента на этапе установления связи TLS. Я не могу, черт возьми, найти способ заставить Windows сделать это.

Правильно ли я предполагаю, что НЕТ СПОСОБА для настройки собственного соискателя Windows 8.1 802.1X для предоставления сертификата клиента, когда EAP-TTLS используется в качестве внешнего протокола аутентификации?

RFC 5281 прямо заявляет, что проверка сертификата клиента поддерживается во время фазы 1, поэтому я не могу понять, почему Microsoft не использовала опцию в GUI для настройки этого.

Answer 1

Windows GUI традиционно называет аутентификацию EAP-TLS «Смарт-карта или другой сертификат». Так что, возможно, это то, что вы ищете.

Однако эта часть вашего вопроса не имеет для меня никакого смысла:

До Windows 8.x мы использовали EAP-TLS в качестве внешнего протокола аутентификации, чтобы удовлетворить это требование, и использовали внутренний протокол аутентификации для проверки имени пользователя и пароля в нашей AD.

... потому что, насколько я знаю, EAP-TLS не предусматривает "внутренний" протокол аутентификации. Поэтому мне интересно, возможно, вы использовали EAP-TLS в качестве единственного типа EAP 802.1X, и тогда аутентификация имени пользователя / пароля, которую вы помните, не была частью 802.1X, но, возможно, была частью аутентификации в вашем домене AD после того, как вы были уже полностью 802.1X-аутентифицированы и имели сетевое подключение.

Насколько я знаю, только PEAP и TTLS устанавливают "внешний" безопасный туннель с помощью фиктивной аутентификации, а затем используют этот туннель для безопасной передачи "внутренней" транзакции аутентификации. И даже PEAP и TTLS для внешней аутентификации выполняют только TLS, но, насколько я помню, я использую его только для проверки подлинности (сервер AP или AAA) и настройки зашифрованного туннеля. Я не помню, чтобы когда-либо был способ указать сертификат клиента для аутентификации TLS снаружи PEAP или TTLS.

И PEAP, и TTLS технически допускают использование EAP-TLS в качестве внутреннего механизма аутентификации, хотя многие ранние реализации TTLS не допускали EAP; они допускали только методы аутентификации PPP до EAP: PAP, CHAP, MS-CHAP, MS-CHAP-V2. Вполне возможно, что родной соискатель Windows 8.1 802.1X является одним из них. Аналогично, некоторые реализации PEAP поддерживают EAP-MS-CHAP-V2 и EAP-GTC в качестве внутренних типов аутентификации и могут не поддерживать другие типы аутентификации, такие как EAP-TLS, в качестве внутреннего типа аутентификации. Однако нативный соискатель Windows 802.1X от Microsoft всегда поддерживал EAP-TLS в качестве внутреннего типа аутентификации для PEAP, он просто помечал его как «смарт-карту или другой сертификат».

Меня никогда не удивляет, когда разработчик пропускает необязательные части спецификации протокола при реализации этого протокола. Почти у каждого RFC, который я когда-либо читал, были части, которые я никогда не видел, чтобы кто-то реализовал. Поэтому неудивительно, если искатель Windows 802.1X от Microsoft не предоставляет способ предложить клиентский сертификат TLS при внешней аутентификации TTLS. Если вы прочитаете спецификацию TTLS, то увидите, что когда это происходит, TTLS в конечном итоге пропускает внутреннюю аутентификацию, так что в этот момент это просто EAP-TLS. Microsoft, вероятно, полагала, что, поскольку они уже поддерживают EAP-TLS, зачем беспокоиться о реализации режима EAP-TTLS, который заканчивается примерно так же, как EAP-TLS?