1. 1 История tcpIP
 Скачать 340.83 Kb.
|
2.5.2 Протокол Challenge Handshake Authentication Protocol (CHAP)Протокол СНАР используется для периодической проверки аутентификации противоположной стороны с помощью трехстороннего рукопожатия (3-way handshake). Протокол выполняется после установления канала и может быть повторно использован в любое время после того, как канал установлен. Первоначально CHAP был описан в RFC 1334, а позднее дополнен в RFC 1994.
Процесс аутентификации СНАР показан на рисунке 2.18. Аутентификация состоит из следующих шагов: После завершения фазы установления канала, аутентификатор посылает узлу сообщение Challenge. Оно содержит идентификатор (Identifier) этого сообщения и вызов (Challenge Value) — произвольную строку символов переменной длины. Узел-получатель выполняет одностороннюю хэш-функцию (обычно Message Digest 5 (MD5)) над информацией, полученной из сообщения Challenge (идентификатором и вызовом) и паролем. Вычисленное значение он отправляет аутентификатору в сообщении Response. Идентификатор сообщения Response аналогичен идентификатору сообщения Challenge. Аутентификатор сравнивает полученное значение с собственным вычисленным значением хэш-функции. Хэш-функция на стороне аутентификатора выполняется над идентификатором и вызовом оригинального сообщения Challenge и паролем. Поэтому у аутентификатора и узла должны быть одинаковые пароли. Если вычисленное и полученное значения хэш-функции совпали, аутентификация считается успешной и аутентификатор отправляет сообщение Success. В противном случае соединение сбрасывается и отправляется сообщение Failure. Через произвольные интервалы времени аутентификатор отправляет новый Challenge и шаги 1–3 повторяются. СНАР обеспечивает защиту от replay-атак благодаря использованию при каждой отправке сообщения Challenge уникального значения идентификатора и случайного набора символов переменной длины. Таким образом, нет возможности воспользоваться перехваченной информацией для получения неавторизованного доступа к сети. Повторная отправка сообщений Challenge в течение сессии CHAP предназначена для ограничения времени на проведения любых единичных атак. Аутентификатор управляет частотой и временем отправки сообщений Challenge. Метод аутентификации CHAP основан на том, что оба участника знают некий секрет (пароль), который никогда не отправляется по каналу. Хотя аутентификация односторонняя, стороны могут договориться о применении CHAP в обоих направлениях и использовать одинаковый пароль для обеспечения взаимной аутентификации. Т. к. CHAP может использоваться для аутентификации множества различных устройств, поле Имя (Name) в сообщениях Challenge и Response может служить индексом для поиска правильного пароля в больших таблицах, хранящих их. Также это позволяет создавать для каждого устройства более одной пары имя/пароль и изменять используемый пароль в любое время в течение сессии. Аутентификация CHAP имеет свои недостатки, в частности требует, чтобы пароль хранился в открытом виде. При этом она устраняет одну из уязвимостей PAP — пароль не передается по сети в открытом виде, а используется вызов и хэширование ответа, что позволяет избежать replay-атак. Также, в отличие от PAP, аутентификация CHAP может выполняться несколько раз за сессию. В 1996 году IETF обновила стандарт, описывающий аутентификацию PPP, и оставила в нем только CHAP. Новый стандарт получил название RFC 1994 «PPP Challenge Handshake Authentication Protocol (CHAP)». RFC 1334 в настоящее время является устаревшим. 2.5.3 Протокол Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) был создан компанией Microsoft для аутентификации удаленных рабочих станций Windows. Существует две версии этого протокола: MS-CHAP v1 и MS-CHAP v2. Первая версия протокола MS-CHAP описана в RFC 2433. Там, где это возможно, она согласуется со стандартом CHAP. Различия между MS-CHAP v1 и стандартным CHAP следующие: Согласование MS-CHAP в процессе переговоров LCP аналогично согласованию стандартного СНАР, за исключением того, что поле Algorithm опции Authentication Protocol имеет значение 0x80. Пакет MS-CHAP Response представлен в формате, обеспечивающем совместимость с Microsoft Windows NT 3.5, 3.51 и 4.0 и Windows 95. Формат MS-CHAP не требует хранение аутентификатором пароля в открытом или в обратимо зашифрованном виде. MS-CHAP обеспечивает механизмы запроса аутентифицирующей стороной повторной аутентификации и изменения пароля. MS-CHAP определяет набор значений кодов, сообщающих о причине отказа, которые возвращаются узлу в сообщении Failure при неудачной аутентификации. Аутентификация MS-CHAP v1 состоит из трех шагов: Аутентификатор отправляет сообщение MS-CHAP Challenge, содержащее 8-байтную произвольную строку символов (вызов). Узел отправляет сообщение MS-CHAP Response. По сравнению с CHAP его поле Value отформатировано по-другому: 24 октета: ответ на запрос совместимый с LAN Manager; 24 октета: ответ на запрос совместимый с Windows NT; 1 октет: флаг совместимости с Windows NT. Ответ на запрос совместимый с LAN Manager является результатом функции шифрования LmChallengeResponse(), выполненной над хэшем пароля в формате LAN Manager и полученной 8-байтной строки символов. Узел использует хэш пароля в формате LAN Manager, чтобы получить 3 ключа алгоритма DES. Каждый из этих ключей применяется для шифрования полученного вызова. Получается три зашифрованных блока, которые объединяются в 24-байтный ответ. Ответ на запрос совместимый с Windows NT является результатом функции шифрования NTChallengeResponse(), выполненной над хэшем пароля в формате Windows NT и полученной 8-байтной строки символов. Узел создает второй 24-байтный ответ, используя хэш пароля в формате Windows NT и аналогичную процедуру. Если флаг совместимости с Windows NT равен 1, это указывает на то, что поддерживается ответ в формате Windows NT и он предпочтительнее ответа, совместимого с LAN Manager. Аутентификатор расшифровывает полученный ответ, используя известный ему хэш пароля совместимый с LAN Manager или с Windows NT в зависимости от установленного в ответе флага. Если расшифрованные блоки совпадают с отправленным вызовом, аутентификация считается успешной и аутентификатор отправляет сообщение Success. В противном случае отправляется сообщение Failure. По сравнению с CHAP, в MS-CHAP v1 появилось новое сообщение Change Password, которое позволяет узлу изменить пароль, указанный в последнем отправленном пакете Response. Основным недостатком MS-CHAP v1 является отправка клиентом ответа, содержащего две величины: в формате совместимости с LAN Manager и в формате совместимости с Windows NT. Несмотря на то что по сравнению с CHAP в MS-CHAP v1 появилось шифрование ответа, он не является безопасным протоколом аутентификации. Для формирования ответа вызов шифруется с помощью ключей DES, основанных на хэше пароля. Возможность взлома пароля зависит от криптографической стойкости используемой хэш-фунции. Хэш в формате LAN Manager значительно слабее хэша формате Windows NT. Всякий раз, когда пользователь подключается с одним и тем же паролем, создаются одни и те же ключи шифрования. Поэтому в средах с большой вероятностью прослушивания необходимо достаточно часто менять пароль. Протокол MS-CHAP версии 2 (описан в RFC 2759) соответствует как протоколу MS-CHAP v1, так и стандартному протоколу СНАР. Отличия между MS-CHAP v1 и MS-CHAP v2 следующие: Согласование MS-CHAP v2 в процессе переговоров LCP аналогично согласованию стандартного СНАР, за исключением того, что поле Algorithm опции Authentication Protocol имеет значение 0x81. Протокол MS-CHAP v2 обеспечивает взаимную аутентификацию участников, добавляя в сообщении Response вызов узла (Peer-Challenge'>Peer-Challenge), на который аутентификатор отвечает в сообщении Success. В MS-CHAP v2 больше не поддерживается формат LAN Manager. Ответ в этом формате заменен в сообщении Response на Peer-Challenge. Изменен формат поля Message в пакете Failure. Пакеты Change Password версий 1 и 2 больше не поддерживаются. Они заменены единым пакетом Change-Password. Аутентификация MS-CHAP v2 состоит из следующих шагов: Аутентификатор отправляет узлу сообщение MS-CHAP v2 Challenge, которое содержит идентификатор и 16-байтную произвольную строку символов (вызов). Узел посылает ответ MS-CHAP v2 Response. По сравнению с CHAP его поле Value отформатировано по-другому: 16 октетов: произвольная строка символов, сгенерированных узлом (Peer-Challenge); 8 октетов: зарезервировано; 24 октета: ответ на запрос NT-Response_;_1_октет:_флаги._Ответ_на_запрос_NT-Response'>NT-Response; 1 октет: флаги. Ответ на запрос NT-Response является результатом функции шифрования GenerateNTResponse(), входными данными для которой являются пароль, имя пользователя, строка Peer-Challenge и полученная из сообщения Challenge 16-байтная строка символов. Шифрование выполняется с помощью алгоритма DES. Аутентификатор отправляет узлу 16-байтный вызов, но в отличие от MS-CHAP v1, узел его напрямую не использует. Он получает из него следующим образом 8-байтный вызов: Узел генерирует произвольную строку символов, называемую Peer-Challenge. Строка Peer-Challenge объединяется с 16-байтным вызовом, полученным от аутентификатора, и именем пользователя. Полученный результат хэшируется с помощью SHA-1. Первые 8 байтов полученного хэша становятся 8-байтным вызовом. Далее узел создает 24-байтный ответ, используя хэш-функцию Windows NT и полученный 8-байтный вызов. Процедура получения ответа аналогична MS-CHAP v1. Аутентификатор расшифровывает полученный NT-Response, используя известный ему хэш пароля узла. Если расшифрованные блоки совпадают с отправленным вызовом, аутентификация считается успешной и аутентификатор отправляет сообщение Success. В противном случае отправляется сообщение Failure. Сообщение Success в поле Message содержит ответ аутентификатора длиной 20 байт, представленный в кодировке ASCII в виде 40 шестнадцатеричных чисел и текстовую строку. Ответ аутентификатора получается следующим образом: Аутентификатор хранит хэшированный с помощью MD4 пароль узла. Он хэширует этот хэш пароля с использованием MD4, чтобы получить хэш хэша пароля. Аутентификатор объединяет хэш хэша пароля, 24-байтный ответ NT-Response и константу «Magic1», затем хэширует полученный результат с помощью SHA. К полученному хэшу присоединяется 8-байтный вызов из ответа на запрос и константа «Magic2». Результат хэшируется с помощью SHA. Полученный ответ используется для взаимной аутентификации узла и аутентификатора. Узел проверяет ответ аутентификатора, проводя аналогичные вычисления и сравнивая полученный ответ с вычисленным. Если они не совпали, узел прерывает соединение. |