CHAP (Challenge Handshake Authentication Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 15:52, 22 июня 2016.

CHAP (англ. Challenge Handshake Authentication Protocol) - широко поддерживаемый метод аунтентификации, в котором используется передача косвенных сведений о пароле, вместо передачи его самого.

Цикл работы

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

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

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

CHAP обеспечивает защиту от атак воспроизведения с помощью возрастающего значения идентификатора и переменного значения "запроса". Использование повторяющейся процедуры "запроса" предназначено для ограничения время воздействия какой-либо одиночной атаки. Аутентификатор контролирует частоту и время запроса. Этот метод проверки подлинности зависит от "секрета", известного только аутентификатору и узлу. Секрет не передается по каналу связи.

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

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

Недостатки

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

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

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

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

Алгоритм CHAP требует, чтобы длина секрета была не менее 1 октета. Секрет должен быть по крайней мере столь же большим и неопределяемым как хорошо выбранный пароль. Предпочтительно, чтобы секрет был по крайней мере длины хэш-значения при хешировании выбранным алгоритмом (16 октетов для MD5). Это необходимо, чтобы обеспечить достаточно большой диапазон для секрета, что позволяет защититься от атак перебора.

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

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

Каждое значение запроса должно также быть непредсказуемым, чтобы злоумышленник не смог обмануть узел предугаданным будущим запросом и затем отправить ответ аутентификатору.

Хотя протоколы такие как CHAP не способны защитить от активных атак прослушки в реальном времени, создание уникальных непредсказуемых запросов может защитить от широкого спектра активных атак.


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

Краткая информация о формате аутентификации - Protocol Configuration Option, использующимся в протоколе проверки подлинности Запрос-Ответ показано ниже. Поля передаются слева направо.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Authentication-Protocol   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm   |
+-+-+-+-+-+-+-+-+

Type

3

Length

5

Authentication-Protocol

c223 (hex) для протокола Challenge-Handshake Authentication Protocol.

Algorithm

Поле Algorithm длинной один октет показывает, какой метод будет использоваться.

5       CHAP with MD5


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

Ровно один пакет протокола аутентификации Запрос-Ответ искапсулируется в информационном поле кадра PPP Layer Data Link, где в поле протокола указывается тип hex c223 (Challenge-Handshake Authentication Protocol). Краткая информация о формате CHAP пакета показана ниже. Поля передаются слева направо.

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

Code

Поле Code длинной один октет определяет тип CHAP пакета. Коды CHAP соотносятся со следующими значениями:

  1. Вызов
  2. Ответ
  3. Success
  4. Failure

Identifier

Поле Identifier длинной один октет участвует в согласовании запроса, ответы и подтверждения.


Length

Поле Length состоит из двух октетов и показывает длину CHAP пакета включая поля кода, идентификатора, длинны и данных. Октеты за пределами поля Length должны рассматриваться как Data Link Layer padding и должны быть проигнорированы при приеме.

Data

Длина поля Data равна нулю или более октетов. Формат данных поле определяется полем Code.


Запрос и ответ

Пакет запрос используется для запуска протокола. Аутентификатор должен передавать CHAP пакет с полем кода установленным на 1 (запрос). Дополнительные запросы должны отправляться, пока не будет получен валидный ответ.

Узел ожидает пакет запроса. Всякий раз, когда вызов пакет получен, узел должен передать CHAP пакет с кодом поля установленным на 2 (Ответ).

Всякий раз, когда пакет ответа будет получен, аутентификатор сравнивает значение. На основе этого сравнения, аутентификатор должен послать пакет Success или Failure.


Краткое описание формата запроса и ответного пакета показано ниже. Поля передаются слева направо.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Value-Size   |  Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

 1 для Запроса
 2 для Ответа

Identifier

Длина поля - один октет. Идентификатор ответа копируется из поля идентификатора запроса.


Value-Size

Длина поля - один октет.

Value

Длина поля - один или более октетов. Наиболее значащие октеты передаются в первую очередь.

Name

Поле Name длинной один или более октетов представляет собой идентификацию системы, передающей пакет.

Success и Failure

Если принятое значение совпадает с вычисленным, аутентификатор отправляет CHAP пакет с выставленным значением 3 (Success) в поле Code, иначе - 4 (Failure).

Краткое описание формата пакета Success и Failure показано ниже. Поля передаются слева направо

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Code

 3 в случае Success
 4 в случае Failure

Identifier

Поле Identifier длинной один октет заимствует значение аналогичного поля из Запроса и Ответа.

Message

Поле Message длинной 0 или более октетов предназначено для удобной читаемости человеком и НЕ влияет на процесс работы. Рекомендуется использовать ASCII символы (код 32-126). Длина сообщения определяется полем Length.

Ссылки