Разделяй и властвуй: гарантированный взлом MS-CHAPv2
На двадцатой конференции Defcon мы с Дэвидом Халтоном представили презентацию о взломе MS-CHAPv2. В данном посте дан примерный обзор того, что мы охватили в своем выступлении.
Автор: Moxie Marlinspike
На двадцатой конференции Defcon мы с Дэвидом Халтоном представили презентацию о взломе MS-CHAPv2. В данном посте дан примерный обзор того, что мы охватили в своем выступлении.
Почему MS-CHAPv2?
Первый очевидный вопрос – почему мы занялись MS-CHAPv2, учитывая давнее ощущение, что Интернет не стоит полагаться на этот протокол. К сожалению, даже будучи устаревшим протоколом и объектом распространенной критики, он продолжает использоваться повсеместно. Наиболее примечательно использование MS-CHAPv2 в PPTP VPN. Он также довольно интенсивно используется в конфигурациях WPA2 Enterprise, особенно в тех случаях, когда полагаются на его свойства взаимной аутентификации. Для своего выступления мы составили список из сотен VPN-провайдеров, которые зависят от PPTP. Он включает такие значимые примеры, как iPredator, VPN-сервис The Pirate Bay, который предположительно разработан для защиты информационного обмена от наблюдения со стороны государства.
Мы полагаем, что MS-CHAPv2 остается таким распространенным, поскольку предыдущие исследователи потенциальных слабостей протокола главным образом фокусировались на атаках по словарю. Если сложить эту ограниченность исследований с крайне широким количеством клиентов, поддерживающих протокол, и его совместимостью с ОС, станет понятно, почему это решение, требующее наименьшего количества телодвижений от пользователя, столь заманчиво. В своем анализе данного протокола (1999 год), например, Брюс Шнайер и Мадж заключили следующее: «Microsoft улучшил PPTP, исправив основные изъяны безопасности, описанные в [SM98]. Однако, фундаментальная слабость аутентификации и шифрования протокола в том, что он безопасен настолько, насколько безопасен выбранный пользователем пароль. » [курсив добавлен]. Эта и другие работы привели к тому, что провайдеры и пользователи решили, что они могут использовать MS-CHAPv2 в PPTP VPN и взаимно аутентифицироваться с серверами WPA2 Enterprise, если будут выбирать хорошие пароли. Например, на основе данного в работе Шнайера анализа Riseup.net, сконцентрированный на безопасности провайдер VPN, решил пойти на генерацию для своих пользователей равномерно случайных 21-символьных паролей, не давая им возможности выбирать свои собственные пароли, чтобы гарантировать безопасность развертывания PPTP VPN-сервиса.
Протокол
Давайте взглянем на сам протокол, чтобы увидеть, с чем мы имеем дело:
На первый взгляд может показаться, что протокол излишне сложен. Он похож на цифровой эквивалент пустого размахивания руками – как будто добавление лишнего хэша, случайного числа или необычное строение дайджеста как-то повлияют на предполагаемых противников. Строковые константы «Pad to make it do more than one iteration» и «Magic server to client signing constant» выглядят особенно занятно. При аккуратном рассмотрении, однако, оказывается, что во всем протоколе действительно неизвестным является лишь MD4-хэш пароля пользователя, который используется для построения трех отдельных ключей DES. Все прочие элементы протокола либо сами посылаются явным образом, либо могут быть получены из того, что посылается явно: 
Так как все остальное известно, мы можем попробовать игнорировать все, кроме неизвестного ядра, и посмотреть, какие возможности это нам дает: 
У нас есть неизвестный пароль, неизвестный MD4-хэш этого пароля, известный открытый текст и известный шифртекст. Присмотревшись, можно видеть, что MD4-хэш пользовательского пароля служит эквивалентом пароля, то есть, MD4-хэша пароля пользователя достаточно для аутентификации от имени этого пользователя, равно как и расшифровки любого его трафика. Итак, нашей целью является восстановление MD4-хэша пользовательского пароля. Обычно, располагая перехваченным трафиком, атакующий попытается провести атаку по словарю. Используя инструмент вроде asleap, возможно быстро перебрать ряд паролей в оффлайн-режиме. Для каждого пароля из словаря, password_guess, атакующий может просто вычислить MD4(password_guess), разделить полученный хэш на три DES-ключа, зашифровать известный открытый текст три раза и посмотреть, совпадает ли сконкатенированный результат DES-шифрований с известным шифртекстом. Проблема с данным подходом в том, что он не даст атакующему 100% гарантию успеха, а также зависит от склонности пользователя выбирать предсказуемые пароли. В случае PPTP VPN-сервиса riseup.net, например, атакующему пришлось бы перебирать все 96 вариантов символа для каждого из 21 символов сгенерированного пароля. Общая сложность такого перебора равна 96 21 , что немногим больше 2 138 , то есть сравнима со сложностью подбора 138-битного ключа. В ситуации с неограниченной длиной пароля, составленного из широкого набора символов, имеет смысл напрямую подбирать результат MD4-хэширования. Тем не менее, длина MD4-хэша равна 128 бит. Это делает размер пространства ключей, подлежащих перебору, равным 2 128 , что вряд ли когда-либо станет вычислительно достижимым.
Разделяй и властвуй
Преследуемый нами хэш, однако, используется как ключевой материал для трех DES-операций. DES-ключи имеют длину 7 байт, так что каждая DES-операция использует 7-байтовый фрагмент MD4-хэша. Это дает нам возможность для классической атаки «разделяй и властвуй». Поскольку имеют место три DES-операции, и каждая DES-операция полностью независима от остальных, это дает нам аддитивную сложность всего пространства ключей, равную 2 56 + 2 56 + 2 56 = 2 57.59 . Это безусловно лучше, чем 2 138 или 2 128 , но все еще довольно большое число. Однако, наши вычисления не совсем верны. Нам нужно три DES-ключа, каждый 7 байтов длиной, а всего 21 байт: 
Данные ключи извлекаются из значения MD4(password), которое имеет длину лишь 16 байт. 
Нам недостает пяти байтов ключевого материала для третьего DES-ключа. Решение Microsoft состоит в дополнении пяти последних байт нулями, что делает эффективную длину третьего DES-ключа равной двум байтам. 
Поскольку третий DES-ключ имеет эффективную длину всего два байта, т. е. принадлежит пространству ключей размером всего 2 16 , мы можем немедленно увидеть эффективность подхода «разделяй и властвуй», подобрав третий ключ за секунды. Это даст нам два последних байта MD4-хэша. Нам осталось найти 14 оставшихся байтов хэша, но мы можем разделить их на два 7-байтовых фрагмента, что дает общую сложность 2 57 . Опять же большое число, но значительно лучше. По существу, нам осталось решить такую ключевую задачу: 
Следующий интересный факт об оставшихся неизвестных частях – то, что обе оставшихся DES-операции производятся над одним и тем же открытым текстом, но с разными ключами. Наивный подход ко взлому данных DES-операций будет выглядеть так: 
Здесь мы пробегаем каждый ключ в пространстве ключей, используем его для шифрования нашего известного открытого текста и сравниваем результат с нашим первым известным шифртекстом. Когда будет найдено соответствие, мы начнем сначала и пробежим каждый ключ, шифруя известный открытый текст и сравнивая результат с нашим вторым известным шифртекстом. Наиболее затратной частью данных циклов являются DES-операции. Но, поскольку в каждом цикле используется один и тот же открытый текст, мы можем соединить все в единственный цикл по ключевому пространству с одним шифрованием для каждого из ключей и двумя сравнениями. 
Таким образом, мы уменьшим общую сложность до 2 56 ! Это означает, что безопасность MS-CHAPv2 может быть сведена к стойкости одного DES-шифрования.
Взлом DES
Теперь остается открытым лишь вопрос вычислительной достижимости. В 1998 году EFF использовала ASIC чтобы построить Deep Crack, который стоил $250,000 и взламывал ключ в среднем за 4.5 дня. Компания Дэвида Халтона, Pico Computing, специализируется на построении FPGA оборудования для криптографических приложений. Они смогли построить FPGA-устройство, DES cracking box, которое реализовывало DES как конвейер с одной DES-операцией на каждый тактовый цикл. Обладая 40 ядрами по 450 МГц оно позволяет перебирать 18 миллиардов ключей в секунду. Используя 48 FPGA, DES cracking box в худшем случае взламывает ключ DES за 23 часа, а в среднем за полдня. Теперь, вооружившись данным оборудованием Pico Computing, мы можем взломать любое рукопожатие по протоколу MS-CHAPv2 меньше, чем за день. Если бы взломать рукопожатия MS-CHAPv2 могли только я или Дэвид, это было бы не так весело. Поэтому, мы интегрировали DES cracking box с CloudCracker, чтобы сделать доступными для каждого талант, навыки и ресурсы Дэвида и его команды. Мы опубликовали утилиту, названную chapcrack, которая разбирает перехваченный сетевой трафик в поисках рукопожатий MS-CHAPv2. Для каждого рукопожатия она выводит имя пользователя, известный открытый текст, два известных шифртекста и взламывает третий DES-ключ. Она также выводит «токен» CloudCracker, в котором закодированы три параметра, обходимые для нашей атаки «разделяй и властвуй». Когда токен отправляется в CloudCracker, закодированная в нем задача передается DES cracking box, и вы получаете результаты менее чем через день.
Что вы выигрываете?
Теперь вы можете поместить взломанный CloudCracker MD4-хэш обратно в chapcrack, и она расшифрует весь захваченный сетевой трафик (и все последующие перехваты трафика данного пользователя). Вы также можете использовать данный хэш для входа в VPN-сервис пользователя или на RADIUS-сервер WPA2 Enterprise. Мы надеемся, что, сделав данный сервис доступным, мы сможем эффективно прекратить использование MS-CHAPv2 в Интернет раз и навсегда. И, как обычно, передача задач по взлому MS-CHAPv2 на CloudCracker доступна через стандартный веб-интерфейс и через API.
Что теперь?
1) Все пользователи и провайдеры PPTP VPN-решений должны немедленно начать миграцию на другой VPN-протокол. PPTP-трафик следует считать незашифрованным. 2) Компании, которые зависят от свойств взаимной аутентификации MS-CHAPv2 для соединения со своими WPA2 RADIUS-серверами, должны немедленно начать миграцию на альтернативное решение. Во многих случаях большие компании выбрали использование IPSEC-PSK поверх PPTP. В то время как PPTP теперь очевидно взломан, IPSEC-PSK, вероятно, еще более уязвим к вектору атаки по словарю, чем когда-либо был PPTP. PPTP по крайней мере требует от атакующего перехвата активного сетевого трафика, чтобы начать оффлайновую атаку по словарю, тогда как IPSEC-PSK VPN в агрессивном режиме, по существу, выдает хэши любому подключившемуся атакующему. Учитывая доступные сегодня решения, безопасное развертывание чего-либо нуждается в некоторой проверке сертификатов. Это касается либо конфигурации OpenVPN, либо использования IPSEC в режиме сертификатов вместо PSK.
Протоколы MS-CHAP и MS-CHAP v2
Протокол MS-CHAP (Microsoft Challenge Handshake Protocol) представляет собой реализацию протокола CHAP, предложенную компанией Microsoft. В отличие от CHAP, для хэширования паролей применяется алгоритм MD4. Существует две версии протокола MS-CHAP. Вторая версия протокола MS-CHAP (MS-CHAP v2) предлагает более эффективный механизм аутентификации (табл. 14.1). В частности, реализован механизм взаимной аутентификации. Сервер удаленного доступа по окончании процедуры аутентификации клиента удаленного доступа предоставляет ему информацию о собственных полномочиях. Соединение не считается установленным до тех пор, пока клиент не удостоверится в подлинности сервера удаленного доступа.
Таблица 14.1. Сравнение протоколов MS-CHAP версий 1 и 2
| Проблемы MS-CHAP версии 1 | Решение в MS-CHAP версии 2 |
| Кодирование ответа по схеме LAN Manager, которое используется для обратной совместимости со старыми клиентами Microsoft удаленного доступа, использует слабое шисррование | MS-CHAP v2 более не поддерживает ответы, закодированные по схеме LAN Manager |
| Кодирование пароля по схеме LAN Manager использует слабое шифрование | MS-CHAP v2 более не поддерживает передачу изменений паролей, закодированных по схеме LAN Manager |
| Возможна только однонаправленная проверка подлинности. Клиент удаленного доступа не может проверить, соединился он с подлинным или с ложным (подставным) сервером удаленного доступа | MS-CHAP v2 поддерживает двустороннюю проверку подлинности, также называемую взаимной проверкой подлинности. Клиент удаленного доступа проверяет, к тому ли серверу удаленного доступа он подключился |
| При 40-разрядном шифровании ключ шифрования основывается на пароле пользователя. Каждый раз, когда пользователь подключается с тем же самым паролем, будет сгенерирован тот же самый ключ | При использовании MS-CHAP v2 ключ шифрования основывается на пароле пользователя и произвольной строке запроса. Каждый раз, когда пользователь подключается с тем же самым паролем, используется другой ключ |
| Используется единый ключ шифрования для данных, передаваемых в обоих направлениях соединения | Используются отдельные ключи шифрования, которые генерируются для передаваемых и получаемых данных |
Выполнение аутентификации PEAP-MS-CHAP v2 для Microsoft PPTP VPN
Протокол MSCHAP (Microsoft Challenge-Handshake Authentication Protocol) версии 2.0 — это протокол проверки подлинности, работающий на основе паролей. Он широко применяется как метод проверки подлинности для VPN на базе протоколов PPTP (Point-to-Point Tunneling Protocol). Корпорация Майкрософт предупреждает, что любое использование MS-CHAP v2 без формирования пакета данных совместно с тоннелями PPTP для соединения VPN потенциально является небезопасным.
ВВЕДЕНИЕ
Корпорация Майкрософт рекомендует организациям, использующим MS-CHAP v2/PPTP, выполнять в своих сетях протокол PEAP (Protected Extensible Authentication Protocol) Таким образом можно смягчить подобную технику путем формирования трафика проверки подлинности MS-CHAP v2 в TLS.
Конфигурирование PPTP для использования PEAP-MS-CHAP v2 для проверки подлинности
PEAP-MS-CHAP v2
PEAP и MS-CHAP v2 в качестве способа проверки подлинности клиента — это один из способов обеспечения проверки подлинности VPN. Для того чтобы сделать выполнение PEAP на клиентских платформах обязательным серверы RRAS (Windows Routing and Remote Access Server) должны быть сконфигурированы так, чтобы разрешать только одно подключение, использующее проверку подлинности PEAP, и должны отказывать в подключении клиентам, использующим MS-CHAP v2 или EAP-MS-CHAP v2. Администраторы должны проверять настройки соответствующего способа проверки подлинности на сервере RRAS и сервере NPS (Network Policy Server).
Администраторы также должны подтвердить следующее:
- Подтверждение сертификата сервера включено. (По умолчанию включено).
- Подтверждение имени сервера включено. (По умолчанию включено). Должно быть указано правильное имя сервера.
- Корневой сертификат, который выдал сертификат сервера, установлен правильно на системе клиента и включен. (Всегда включен).
- В Windows 7, Windows Vista и Windows XP должен быть поставлен флажок Не запрашивать пользователя авторизовать новые серверы или доверенные центры сертификации. По умолчанию, отключено.
Конфигурирование сервера RRAS для способа проверки подлинности PEAP-MS-CHAP v2
Процесс конфигурации способа проверки подлинности PEAP-MS-CHAP v2 для сервера RRAS и отключения менее надежных методов — MS-CHAP v2 и EAP-MS-CHAP v2 — кратко описан далее.
Конфигурация способа проверки подлинности для RRAS
Для этого выполните следующие действия.
- В окне управления сервером RRAS откройте окно Свойства и выберите вкладку Безопасность.
- Выберите Способы проверки подлинности.
- Убедитесь, что флажок EAP поставлен, а MS-CHAP v2 отключен.
Конфигурация соединений для NPS
Сконфигурируйте сервер политики сети так, чтобы он разрешал только подключения от клиентов, использующих способ проверки подлинности PEAP-MS-CHAP v2. Для конфигурации NPS выполните следующие действия:
- Откройте интерфейс пользователя NPS, щелкните политик и выберите политики сети.
- Щелкните правой кнопкой мыши Подключения к серверу маршрутизации и удаленного доступа и выберите Свойства.
- В пользовательском интерфейса Свойства выберите вкладку Ограничения.
- В левой части выберите способы проверки подлинности, а затем уберите флажки способов MS-CHAP и MS-CHAP-v2.
- Удалите EAP-MS-CHAP v2 из списка типов EAP.
- Нажмите Добавить, выберите способ проверки подлинности PEAP и нажмите OK.
Конфигурирование клиента RRAS для способа проверки подлинности PEAP-MS-CHAP v2
Клиенты Windows VPN должны быть сконфигурированы для использования способа проверки подлинности PEAP-MS-CHAP v2. Для этого нужно выбрать соответствующий способ из свойств соединения VPN и установить подходящий корневой сертификат на систему клиента.
Защищенный расширяемый протокол аутентификации
Protected Extensible Authentication Protocol, Protected EAP или, проще говоря, PEAP , — это метод безопасной передачи информации аутентификации, изначально созданный для беспроводных сетей. Этот протокол был разработан совместно Microsoft , RSA Security и Cisco Systems . Это открытый стандарт IETF .
PEAP — это не метод шифрования, это процедура аутентификации клиента в сети.
Резюме
- 1 Введение
- 2 PEAPv0 / EAP-MSCHAPv2
- 2.1 Формат кадра
- 2.2 Сценарий
- 3.1 Формат кадра
- 3.2 Сценарий
- 4.1 Формат кадра
- 4.2 Сценарий
- 4.2.1 A. Обмен незашифрованными идентификационными данными
- 4.2.2 B. Сценарий без обмена открытым текстом
Вступление
PEAP очень похож на другой метод EAP: EAP-TTLS. Защищенный EAP был создан , чтобы счетчик EAP-TTLS, который ранее был единственным ЕАР способом использовать только инфраструктуры открытого ключа (PKI) , как на стороне сервера, чтобы защитить аутентификации путем создания туннеля TLS . В этих двух стандартах использование открытого ключа на стороне клиента не является обязательным. PEAP требует внутренней аутентификации с помощью другого метода EAP, тогда как TTLS позволяет использовать любой метод внутренней идентификации CHAP, PAP, MS-CHAP , MS-CHAPv2 или метод EAP.
Существует две версии PEAP, сертифицированные WPA (обновленные) и WPA2 :
- PEAPv0 / EAP-MSCHAPv2 (только метод внутренней идентификации), также называемый PEAP версией Microsoft
- PEAPv1 / EAP-GTC или EAP-TLS, или EAP-MS-CHAP-V2, также называемая версией PEAP Cisco
PEAP проходит в два этапа:
- Фаза 1 или «внешняя идентификация» позволяет аутентифицировать сервер с использованием инфраструктуры открытого ключа. После аутентификации сервера создается безопасный туннель, который позволит зашифровать второй этап.
- Фаза 2 или «внутренняя идентификация» позволяет аутентифицировать клиента через зашифрованный туннель.
PEAPv0 / EAP-MSCHAPv2
PEAPv0 / EAP-MSCHAPv2 — наиболее используемая версия PEAP. Именно на эту версию мы ссылаемся, когда говорим о PEAP без дальнейших подробностей. После EAP-TLS PEAP является наиболее широко используемым EAP . В этой версии используется версия протокола аутентификации Challenge Handshake Authentication Protocol ( CHAP ) от Microsoft . Он основан на вызове. Если корреспонденту удается расшифровать отправленный запрос (зашифрованный открытым ключом), это потому, что у него есть секретный ключ. Что доказывает его личность.
Есть реализации этого протокола во многих торговых точках. Существуют реализации этого протокола для Windows, Linux, MacOs, . Следующие системы поддерживают его изначально: MAC OS 10.3 и выше, Windows 2000 SP4, Windows XP, Windows Mobile. 2003 и выше и Windows CE 4.2. Серверная часть изначально присутствует в Windows 2003 Server.
MSCHAPv2 подвержен атакам по словарю. Но с протоколом PEAP это не проблема, потому что информация циркулирует по защищенному каналу.
У PEAPv0 есть еще одна слабость. Он пересылает вход за пределы туннеля TLS. С помощью сниффера можно восстановить действительное имя пользователя. Обладая этой информацией, злоумышленник может запустить DOS , заблокировав допустимых пользователей. Эта проблема решена в PEAPv2.
Эта версия PEAP определена в Интернет-проектах IETF draft-kamath-pppext-eap-mschapv2-01.txt и draft-kamath-pppext-peapv0-00.txt.
Формат кадра
+---------------+---------------+---------------+---------------+ | Code | Identifier | Length | +---------------+---------------+---------------+---------------+ | Type | OpCode | MS-CHAPv2-ID | MS-Length. +---------------+---------------+---------------+---------------+ | MS-Length | Data. +---------------+---------------
Закодировано:
Поле кода занимает 1 байт, оно используется для определения типа кадра:
1 — Запрос
2 — ОтветИдентифицировать:
Поле идентификатора занимает один байт, оно используется для сопоставления ответов с запросами.
Поле длины составляет 2 байта, оно указывает размер пакета EAP с заголовком.
Поле Тип определяет в одном байте тип используемого протокола EAP
26 — EAP MS-CHAP-V2Код операции:
Поле OpCode занимает один байт, оно определяет тип пакетов EAP MS-CHAP-v2:
1 Запрос
2 Ответ
3 Успех
4 Ошибка
7 Изменить парольПоле идентификатора MS-CHAPv2 составляет 1 байт, оно используется для сопоставления запросов и ответов MS-CHAPv2.
поле длины MS составляет 2 байта и должно быть идентично полю длины минус 5.
Формат этого поля определяется полем OpCode.
Сценарий
Клиент Аутентификатор ← EAP-запрос / идентификация EAP-Response / Identity (MyID) → ← EAP-Request / EAP-Type = PEAP, V = 0 (начало PEAP, установлен бит S) EAP-Response / EAP-Type = PEAP, V = 0 (TLS client_hello) → ← EAP-Request / EAP-Type = PEAP, V = 0 (TLS server_hello, сертификат TLS, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response / EAP-Type = PEAP, V = 0 ([сертификат TLS,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS завершен) → ← EAP-Request / EAP-Type = PEAP, V = 0 (TLS change_cipher_spec, TLS завершен) EAP-Response / EAP-Type = PEAP → Создан туннель TLS: оттуда сообщения отправляются в туннель TLS, здесь также начинается протокол MS-CHAPv2 для обмена идентификаторами клиента. ← EAP-запрос / идентификация EAP-Response / Identity (MyID) → ← EAP-Request / EAP-Type = EAP MS-CHAP-V2 (Запрос) EAP-Response / EAP-Type = EAP-MS-CHAP-V2 (Ответ) → ← EAP-Request / EAP-Type = EAP-MS-CHAP-V2 (Успешно) EAP-Response / EAP-Type = EAP-MS-CHAP-V2 (Успех) → Конец туннеля TLS (следующие сообщения отправляются в открытом виде) ← EAP-Успех PEAPv1 / EAP-GTC
PEAPv1 / EAP-GTC был создан Cisco как альтернатива PEAPv0 / EAP-MSCHAPv2. Хотя PEAP был совместно разработан Microsoft, Cisco и RSA, Microsoft никогда не интегрировала эту версию PEAP в свою ОС. Поэтому EAP-GTC изначально не присутствует в системах Microsoft. Cisco предпочитает поддерживать свои другие протоколы LEAP или EAP-FAST, а не PEAP. Эта версия PEAP используется очень мало.
Эта версия PEAP определена в draft-josefsson-pppext-eap-tls-eap-05.txt.
Формат кадра
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags |Ver| Data. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Закодировано:
Определить: это однобайтовое поле используется для сопоставления запросов и ответов.
Длина: это поле составляет 2 байта, оно указывает размер пакета EAP.
Тип: 25 — PEAP
0 1 2 3 4 5 +-+-+-+-+-+-+ |L M S R R R| +-+-+-+-+-+-+ L = Length included M = More fragments S = PEAP start R = Réservé, doit être à zéro
Бит L используется для обозначения наличия следующих полей. Бит M равен 1. Бит S равен 1 для сообщений запуска PEAP.
0 1 +-+-+ |R 1| +-+-+ R = Réservé, doit être à zéro
Данные : это поле определяется форматом поля кода.
Сценарий
Клиент Аутентификатор ← EAP-запрос / идентификация EAP-Response / Identity (MyID) → ← EAP-Request / EAP-Type = PEAP (начало PEAP, установлен бит S) EAP-Response / EAP-Type = PEAP (TLS client_hello) → ← EAP-Request / EAP-Type = PEAP (TLS server_hello, сертификат TLS, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response / EAP-Type = PEAP ([сертификат TLS,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS завершен) → ← EAP-Request / EAP-Type = PEAP (TLS change_cipher_spec, TLS завершен) Туннель TLS установлен. Оттуда сообщения отправляются через туннель TLS. EAP-Response / EAP-Type = PEAP → ← EAP-запрос / идентификация EAP-Response / Identity (MyID) → ← Запрос EAP / Тип EAP = X EAP-Response / EAP-Type = X или NAK → ← Запрос EAP / Тип EAP = X EAP-Response / EAP-Type = X → ← EAP-Успех Конец туннеля TLS. Оттуда сообщения отправляются в открытом виде. PEAPv2
PEAPv2 является преемником PEAPv0. В этой версии исправлено несколько слабых мест (включая передачу имени пользователя за пределы туннеля TLS). Он был разработан Microsoft, Cisco Systems и Extundo. Исправлены слабые места версии 0.
На данный момент реализации этой версии не так много. В настоящее время он мало используется.
Эта версия PEAP определена в Интернет-проекте документа IETF draft-josefsson-pppext-eap-tls-eap-10.txt.
PEAPV2 требует, чтобы служба RADIUS установила главный ключ, который будет использоваться для генерации других ключей, необходимых для шифров. Реализация PEAPv2 требует небольших усилий для развертывания и считается безопасной в отрасли.
Формат кадра
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Ver | Fragment Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Message Length | TLS Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS Message Length | TLS Data. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer TLVs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Закодировано:
Идентификатор: поле идентификатора имеет длину один байт и позволяет сопоставлять запросы и ответы.
Длина: поле длины составляет 2 байта; дает длину пакета EAP
Тип: 25 — PEAP
0 1 2 3 4 +-+-+-+-+-+ |L M S T R| +-+-+-+-+-+ L = Length included M = More fragments S = PEAP start T = TLS Length included R = Reserved (must be zero)
Бит L используется для обозначения наличия следующих полей. Бит M равен 1. Бит S равен 1 для сообщений запуска PEAP. Бит T используется для указания наличия поля длины сообщения TLS.
0 1 2 +-+-+-+ |R|1|0| +-+-+-+ R = Réservé, doit être à zéro
Длина фрагментированного сообщения: это поле составляет 4 байта, оно присутствует только в том случае, если бит L равен 1. Он дает размер сообщения после поля флага.
Длина сообщения TLS: это поле составляет 4 байта, оно присутствует, только если бит T равен 1. Он определяет общий размер данных TLS.
Данные TLS: это поле содержит инкапсулированные пакеты TLS.
Внешние TLV: это поле является необязательным, оно помогает установить туннель TLS.
Сценарий
A. Незашифрованный обмен идентификационной информацией
В этой версии часть идентичности дана в открытом виде, но этой «полуидентичности» недостаточно для того, чтобы хакер использовал идентичность, чтобы вызвать отказ в обслуживании (DOS), заблокировав пользователей, которых он имел. восстановить «половинную идентичность».
Клиент Аутентификатор ← EAP-запрос / идентификация EAP-Response / Identity (MyID1) → Часть удостоверения отправляется в открытом виде. ← EAP-Request / EAP-Type = PEAP, V = 2 (начало PEAP, установлен бит S) EAP-Response / EAP-Type = PEAP, V = 2 (TLS client_hello) → ← EAP-Request / EAP-Type = PEAP, V = 2 (TLS server_hello, сертификат TLS, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response / EAP-Type = PEAP, V = 2 ([сертификат TLS,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS завершен) → ← EAP-Request / EAP-Type = PEAP, V = 2 (TLS change_cipher_spec, TLS завершен, EAP-Request / EAP-Type = EAP-TLV [EAP-Payload-TLV EAP-Request / Identity ) // Туннель TLS создан. Личность защищена TLS. Пакеты EAP-TLV не имеют заголовка EAP. EAP-TLV [EAP-Payload-TLV EAP-Response / Identity (MyID2) → ← EAP-TLV [EAP-Payload-TLV EAP-Request / EAP-Type = X EAP-TLV [EAP-Payload-TLV EAP-Response / EAP-Type = X → Конец защиты. ← EAP-TLV [TLV результата (успех), TLV крипто-привязки (версия = 2, полученная-версия = 2, Nonce, B1_MAC), TLV промежуточного результата (успех)] EAP-TLV [TLV результата (успех), TLV промежуточного результата (успех), TLV шифрования (версия = 2, полученная версия = 2, Nonce, B2_MAC)] → Конец туннеля TLS (сообщения теперь отправляются в виде открытого текста). ← EAP-Успех Б. Сценарий без обмена открытым текстом
В этой версии нет четкого обмена идентичностями.
Клиент Аутентификатор ← EAP-Request / EAP-Type = PEAP, V = 2 (начало PEAP, установлен бит S) EAP-Response / EAP-Type = PEAP, V = 2 (TLS client_hello) → ← EAP-Request / EAP-Type = PEAP, V = 2 (TLS server_hello, сертификат TLS, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response / EAP-Type = PEAP, V = 2 ([сертификат TLS,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS завершен) → ← EAP-Request / EAP-Type = PEAP, V = 2 (TLS change_cipher_spec, TLS завершен, EAP-TLV [EAP-Payload-TLV (EAP-Request / Identity)]) Создан туннель TLS (сообщения отправляются через туннель TLS) EAP-TLV [EAP-Payload-TLV EAP-Response / Identity (MyID) → ← EAP-TLV [EAP-Payload-TLV EAP-Type = EAP-Request / EAP-Type = X EAP-TLV [EAP-Payload-TLV [EAP-Response / EAP-Type = X или NAK] → ← EAP-TLV [EAP-Payload-TLV EAP-Request / EAP-Type = X EAP-TLV [EAP-Payload-TLV EAP-Response / EAP-Type = X → ← EAP-TLV [TLV криптографической привязки = (версия = 2, полученная-версия = 2, одноразовый номер, B1_MAC), TLV промежуточного результата (успех), TLV результата (успех)] EAP-TLV [TLV крипто-привязки = (версия = 2, полученная-версия = 2, одноразовый номер, B2_MAC), TLV промежуточного результата (успех), TLV результата (успех)] → Конец туннеля TLS (сообщения отправляются в открытом виде) ← EAP-Успех Внешние ссылки
- (in) Сравнить PEAP TTLS
- (ru) Статья о различных EAP
- (ru) PEAPv2: draft-josefsson-pppext-eap-tls-eap-10.txt