Московский государственный университет имени М.В.Ломоносова
Опубликован: 28.11.2014 | Доступ: свободный | Студентов: 1158 / 85 | Длительность: 23:26:00
ISBN: 978-5-9556-0163-2
Лекция 5:

Технологии тунеллирования

Протокол аутентификации Challenge-Handshake (CHAP)

Протокол СНАР используется для периодической проверки аутентификации противоположной стороны с помощью трех шагового рукопожатия. Протокол выполняется при начальном установлении канала и может повторяться в любое время после того, как канал установлен.

  • После завершения фазы установления канала та сторона, которая запрашивает аутентификацию противоположной стороны, посылает ей сообщение "challenge".
  • Противоположная сторона отвечает значением, вычисленным с помощью односторонней хэш-функции.
  • Сторона, запросившая аутентификацию, сравнивает ответ с собственным вычисленным значением. Если значения совпали, аутентификация считается выполненной, в противном случае соединение сбрасывается.
  • Через произвольные интервалы времени сторона, запросившая аутентификацию, посылает новый запрос противоположной стороне, и повторяются шаги 1 – 3.

Преимущества

СНАР обеспечивает защиту от replay-атак, если в качестве запроса по-сылается случайное значение.

Данный метод аутентификации основан на том, что оба участника знают некий секрет, который никогда не посылается по каналу.

Хотя аутентифицируется только одна сторона, СНАР-переговоры можно вести в обоих направлениях с тем же самым секретом, обеспечивая взаимную аутентификацию.

Так как данный протокол может использоваться для аутентификации многими различными системами, поле name может использоваться для нахождения нужного секрета. С помощью данного поля можно также поддерживать несколько пар name/secret для каждой системы.

Недостатки

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

Это неудобно при большом количестве участников, так как каждый секрет должен храниться на обоих концах канала.

Чтобы избежать посылки секрета по другим каналам в сети, рекомендуется, чтобы значения запроса и ответа проверялись на центральном сервере, а не каждым сервером сетевого доступа. В противном случае секрет должен будет посылаться этим серверам в зашифрованном виде. Также требуется определенная форма доверия участников друг другу.

Требования разработки

Предпочтительнее, чтобы секрет был примерно той же длины, что и значение хэша используемой хэш-функции. Например, 16 октетов для MD5. Используемая хэш-функция должна гарантировать, что вычислительно сложно определить секрет, зная запрос и ответ.

Каждый запрос является уникальным, так как повторное использование предыдущего значения запроса позволит атакующему ранее перехваченный ответ.

Формат конфигурационного параметра

Формат конфигурационного параметра протокола Аутентификации следующий:

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type	| Length 	| Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Algorithm 	|
+-+-+-+-+-+-+-++-+
Type				3
Length				5
Authentication Protocol	c223
Algorithm		

определяет используемый алгоритм. Значения алгоритмов определяются IANA. Для MD5 значением является 5.

Формат пакета

В информационное поле РРР-кадра инкапсулируется ровно один СНАР-пакет.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Code 	| Identifier 	| Length 	|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Data ...
+-+-+-+-+

Code определяет тип СНАР-пакета.

1 Запрос

2 Ответ

3 Успех

4 Неуспех

Identifier используется для определения пар соответствующих запросов и ответов.

Length определяет длину СНАР-пакета.

Data формат данного поля определяется полем Code.

Пакет Challenge используется в качестве первого пакета протокола СНАР. Аутентифицирующая сторона посылает СНАР-пакет с полем Code, установленным в 1 (Challenge). Могут посылаться дополнительные пакеты Challenge до тех пор, пока не будет получен пакет Response или не истечет счетчик повторов.

Пакет Challenge также может передаваться в любое время в течение выполнения протокола сетевого уровня, чтобы гарантировать, что не было подмены участников соединения.

Противоположная сторона ожидает пакеты Challenge в течение фаз аутентификации и протокола сетевого уровня. После получения пакета Challenge участник посылает СНАР-пакет и полем Code, установленным в 2 (Response).

После того, как пакет Response получен, аутентифицирующая сторона сравнивает значение, полученное в ответе, с собственным вычисленным значением. В зависимости от результата аутентифицирующая сторона посылает либо пакет Success, либо пакет Failure.

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

Если пакет Failure потерян, аутентифицирующая сторона завершает соединение, и пакеты Terminate-Request и Terminate-Ack протокола сетевого уровня обеспечивают альтернативный способ определения, что аутентификация была неудачной.

Поле Identifier изменяется в каждом новом пакете Challenge. Поле Identifier в пакете Response копируется из поля Identifier соответствующего пакета Challenge.

В поле Data содержатся значения Value и Name. Значение Value в пакете Challenge должно быть уникальным и не зависеть от секрета. Значение Value в пакете Response является результатом вычисления хэш-функции от следующих значений: Identifier, secret, значение Value из пакета Challenge.

В поле Name записана идентификация системы, которая послала пакет. В этом случае синтаксис может быть любой, как строка символов ASCII, так и уникальный идентификатор в ASN.1 синтаксисе.

Обсуждение безопасности

Не существует особых требований, как и когда должна выполняться повторная попытка при неудачной аутентификации. Тем не менее, в протоколе сетевого уровня может в любой момент начаться протокол аутентификации. Считается, что счетчик неудачных попыток аутентификации не должен сбрасываться до тех пор, пока не будет выполнена успешная аутентификация или не сброшено соединение.

Не существует требования, чтобы аутентификация была взаимной или что в обоих направлениях должен выполняться один и тот же протокол.

Расширения Microsoft РРР СНАР версии 1

Обзор

Microsoft разработал протокол MS-CHAP для аутентификации удаленных рабочих станций, который с одной стороны имел бы привычную для локальных пользователей функциональность, а с другой стороны использовал бы алгоритмы шифрования и хэширования.

MS-CHAP основан на протоколе СНАР. Различия между этими протоколами следующие:

  • Пакет Response в протоколе MS-CHAP имеет формат, совме-стимый с Windows NT 3.5, 3.51 и 4.0, а также Windows95. Формат MS-CHAP не требует, чтобы аутентификатор хранился в явном виде или в виде результата одностороннего преобразования.
  • MS-CHAP предоставляет механизмы запроса аутентифицирующей стороной повторной аутентификации и изменения пароля.
  • MS-CHAP определено множество значений кодов, которые возвращаются клиенту при неудачной аутентификации.

Конфигурирование LCP

Конфигурирование LCP для MS-CHAP аналогично конфигурированию стандартного СНАР, за исключением того, что поле Algorithm имеет значение 0x80, а не 0x05. Реализации РРР, который не поддерживают MS-CHAP, но корректно реализуют LCP Config-Rej, не должны иметь проблем с данным нестандартным параметром.

Пакет Challenge

Пакет Challenge в протоколе MS-CHAP аналогичен пакету Challenge в стандартном протоколе СНАР.

Аутентифицирующая сторона посылает 8-октетное значение в поле Value.

Пакет Response

Формат пакета Response аналогичен формату пакета Response в стандартном протоколе СНАР. Однако поле Value отличается:

  • В 1-ом октете может быть установлен флаг "Используется совместимость ответа с Windows NT".
  • LAN Manager или Windows NT совместимый ответ.

Совместимый с LAN Manager ответ является результатом выполнения функции LmChallengeResponse()от пароля и полученного запроса. Пароль LAN Manager не может быть длиннее 14 символов и чувствителен к регистру.

Совместимый с Window NT ответ является результатом выполнения функции NTChallengeResponse()от пароля и полученного запроса. Пароль Windows NT является строкой от 0 до 256 символов Unicode, пароль чувствителен к регистру. Обычно длина пароля в Windows NT ограничена 14 символами.

Если установлен флаг "Используется совместимость ответа с Windows NT", то используется Windows NT ответ. Ответ "LAN Manager" может ис-пользоваться, если аккаунт не имеет хэша пароля Windows NT, например, еасли пароль не был изменен после загрузки из базы данных аккаунтов LAN Manager 2.x. Если флаг установлен, то ответ Windows NT игнорирует-ся и используется ответ LAN Manager.

Поле Name содержит имя пользовательского аккаунта противоположной стороны. Имя домена Windows NT может являться префиксом имени пользователя.

Пакет Success

Формат пакета Success аналогичен формату стандартного пакета Success в СНАР.

Пакет Failure

Формат пакеты Failure аналогичен формату стандартного пакета Failure в протоколе СНАР. Однако, в отличии от стандартных правил СНАР, содержимое поля Message влияет на протокол. Формат поля Message следующий:

E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv

Где "eeeeeeeeee" есть десятичный код ошибки, который может быть одним из следующих значений:

646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED
648 ERROR_PASSWD_EXPIRED
649 ERROR_NO_DIALIN_PERMISSION
691 ERROR_AUTHENTICATION_FAILURE
709 ERROR_CHANGING_PASSWORD

Если установлен флаг "r", то возможна повторная попытка, если флаг не установлен, то повторная попытка не допускается. Если аутентифицирующая сторона устанавливает данный флаг в 1, она отключает короткие таймауты, предполагая, что противоположная сторона предложит пользователю ввести новые креденциалы и повторить ответ.

"cccccccccccccccc" является новым значением вызова (challenge). Данное поле не является обязательным. Если оно не посылается, то аутентифицирующая сторона считает, что повторный ответ будет вычислен с использованием предыдущего значения вызова, к которому прибавлено десятичное число 23.

10 цифр "vvvvvvvvvv" содержат код версии, обозначающий версию протокола MS-CHAP, поддерживаемую сервером. Это важно только при выборе пакета Change Password. Если поле отсутствует, то считается, что используется версия 1.

Пакет Change Password

Пакет Change Password не посылается в стандартном протоколе СНАР. Допускается, чтобы противоположная сторона изменила пароль аккаунта, указанного в последнем пакете Response. В версии 1 пакет Change Password должен посылаться только в том случае, если аутенти-фицирующая сторона возвратила ERROR_PASSWD_EXPIRED.

Обсуждение безопасности

Аутентифицирующая сторона должна ограничить число попыток ввода пароля, чтобы предотвратить атаки, связанные с перебором паролей. Так как пароль скрывается с помощью хэш-функции, то возможность взлома пароля зависит от криптографической стойкости используемой хэш-функции. Также необходимо достаточно часто менять пароль.

Расширения Microsoft PPP CHAP версии 2

Протокол MS-CHAP-V2 максимально соответствует как протоколу MS-CHAP-V1, так и стандартному протоколу СНАР. Различия между про-токолами MS-CHAP-V1 и MS-CHAP-V2 следующие:

  • Протокол MS-CHAP-V2 предоставляет возможность вести переговоры об алгоритме при аутентификации в протоколе LCP.
  • Протокол MS-CHAP-V2 обеспечивает возможность взаимной аутентификации участников, добавляя вызов в пакет Response, на который противоположная сторона отвечает в пакете Success.
  • Вычисление поля "Windows NT compatible challenge response" изменено в пакете Response включением вызова противоположной стороны и имени пользователя.
  • В MS-CHAP-V1 поле "LAN Manager compatible challenge re-sponse" всегда посылалось в пакете Response. В MS-CHAP-V2 данное поле заменено на поле Peer-Challenge.
  • Изменен формат поля Message в пакете Failure.
  • Пакеты Change Password версий 1 и 2 больше не поддерживаются. Они заменены единым пакетом Change-Password.

Конфигурация LCP

Конфигурация LCP аналогична той, которая используется в стандартном СНАР, за исключением того, что поле Algorithm имеет значение 0x81, а не значение 0x05 (MD5). Реализации РРР, которые не поддерживают MS-CHAP-V2, но корректно реализуют LCP Config-Rej, не имеют проблем с подобной нестандартной опцией.

Пакет Challenge

Пакет Challenge в протоколе MS-CHAP-V2 имеет тот же самый формат, что и в стандартном протоколе СНАР.

Аутентифицирующая сторона посылает 16-октетный вызов в поле Value. Противоположная сторона может использовать свой алгоритм для выбора 16-октетного значения.

Пакет Response

Формат пакета Response в протоколе MS-CHAP-V2 аналогичен формату пакета Response в стандартном протоколе СНАР. Отличается только формат поля Value.

16 октетов: вызов противоположной стороны.

8 октетов: зарезервировано, должно быть установлено в ноль.

24 октета: NT-Response.

1 октет: флаги

Поле Peer-Challenge содержит созданное противоположной стороной 16-октетное случайное число. Данное случайное число используется при вычислении поля NT-Response.

Поле NT-Response является функцией от пароля, имени пользователя, содержимого поля Peer-Challenge и содержит результат функции GenerateNTResponse(). Пароль Windows является строкой длины от 0 до 256 чувствительных к регистру символов Unicode. При вычислении значения поля NT-Response используется только имя пользователя без имени соответствующего домена, не зависимо от того, присутствует ли имя домена в поле Name или нет.

Поле Name является строкой длиной от 0 до 256 чувствительных к регистру символов ASCII, которые являются именем пользователя.

Пакет Success

Формат пакета Success аналогичен формату пакета Success в стандартном протоколе СНАР. Однако поле Message содержит строку ответа длиной 42 октета и сообщение в печатаемом формате. Формат данного поля следующий:

S=<auth_string> M=<message>

<auth_string> состоит из 20 октетов чисел, представленных в коди-ровке ASCII в виде 40 шестнадцатеричных чисел. Данное значение получено из вызова в пакете Challenge, полей Peer-Challenge и NT-Response из пакета Response, пароля противоположной стороны. Данное значение является результатом функции GenerateAuthenticatorResponse(). Аутентификатор проверяется при получении пакета Success. Если аутентификатор отсутствует или не корректный, противоположная сторона завершает сессию.

Пакет Failure

Формат пакета Failure аналогичен формату пакета Failure в стандартном протоколе СНАР. Однако текст хранится в поле Message, значение которого, в отличие от стандартного протокола СНАР, не влияет на операции протокола. Формат поля Message следующий:

E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv
M=<msg>

Где "eeeeeeeeee" представление в ASCII десятичного кода ошибки (не более 10 цифр), соотвествующего одному из перечисленных:

646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED
648 ERROR_PASSWD_EXPIRED
649 ERROR_NO_DIALIN_PERMISSION
691 ERROR_AUTHENTICATION_FAILURE
709 ERROR_CHANGING_PASSWORD

Если установлен флаг "r", то допускается повтор, в противном случае повтор не допускается. Установка флага "r" означает, что на аутентифицирующей стороне отключены все короткие таймауты и предполагается, что противоположная сторона предложит пользователю ввести новый креденциал и повторит ответ.

"cccccccccccccccccccccccccccccccc" является представлением в ASCII шестнадцатеричного значения вызова. Данное поле всегда присутствует и имеет длину 32 октета.

"vvvvvvvvvv" является представлением в ASCII кода версии, который указывает на то, что сервер поддерживает протокол изменения пароля. Для протокола MS-CHAP-V2 данное значение должно быть равно 3.

<msg> является текстом в соответствующей кодировке и языке.

Пакет Change-Password

Пакет Change-Password не поддерживается ни стандартным протоколом СНАР, ни протоколом MS-CHAP-V1. Данный пакет позволяет противоположной стороне изменить пароль, указанный в предыдущем пакете Response. Пакет Change-Password должен посылаться только если аутентифицирующая сторона присылает ERROR_PASWD_EXPIRED в поле Message пакета Failure.

Формат данного пакета следующий:

Таблица 5.3.
Длина поля Название поля Примечание
1 октет Code
1 октет Identifier Данное поле позволяет определить пары запросов и ответов.
2 октета Length
516 октетов Encrypted-Password Данное поле содержит результат выполнения функции NewPasswordEncruptedWithOldNtPasswordHash().
16 октетов Encrypted-Hash Данное поле содержит результат выполнения функции OldNtPasswordHashEncryptedWithNewNtPasswordHash().
16 октетов Peer-Challenge 16-октетное случайное число, аналогичное случайному числу в пакете Response.
8 октетов Зарезервировано.
24 октета NT-Response Аналогично соответствующему полю в пакете Response, но вычисленное для нового пароля и вызова, полученного в пакете Failure.
2 октета Флаги.
Пересылка дейтаграмм сетевого уровня

После завершения выполнения LCP-протокола должен быть сконфигурирован протокол сетевого уровня, такой как IP, IPX и т.п. Конфигурирование протокола сетевого уровня выполняется протоколом управления сетью (Network Control Protocol – NCP).

После того, как протокол NCP перейдет в открытое состояние, РРР начинает передачу пакетов соответствующего протокола сетевого уровня. В данном состоянии трафик на канальном уровне состоит из комбинации пакетов LCP, NCP и протокола сетевого уровня

Еламан Шокпаров
Еламан Шокпаров
Россия, с. Теленгит - Сортогой
Арслан Эркинов
Арслан Эркинов
Казахстан, Кызылорда, Осипенко №8, 2016