Формирование управляющего контекста

В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа (опускаются детали, специфичные для алгоритма Диффи-Хелмана). Одноразовые номера (nonce) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений.

Посредством сообщений (5) и (6) происходит обмен идентификационной информацией, подписанной (с целью аутентификации) секретным ключом отправителя и зашифрованной выработанным на предыдущих шагах общим секретным ключом. Для аутентификации предполагается использование сертификатов открытых ключей. В число подписываемых данных входят одноразовые номера.

Формат заголовка ISAKMP-сообщения

Протокол формирования SA защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на доступность, применяются идентифицирующие цепочки (cookies). Эти цепочки, формируемые инициатором и его партнером с использованием текущего времени (для защиты от воспроизведения), присутствуют во всех ISAKMP-сообщениях и в совокупности идентифицируют SA (в первом сообщении фигурирует только цепочка инициатора). Если злоумышленник пытается "завалить" кого-либо запросами на создание управляющего контекста, подделывая при этом свой IP-адрес, то в сообщении (3) он не сможет предъявить идентифицирующую цепочку партнера, поэтому до выработки общего секретного ключа и, тем более, электронной подписи и полномасштабной проверки аутентичности дело попросту не дойдет.

Протокольный контекст безопасности в IPSec - это однонаправленное "соединение" (от источника к получателю), предоставляющее обслуживаемым потокам данных набор защитных сервисов в рамках какого-то одного протокола (AH или ESP). Если используются и AH, и ESP, потребуется четыре контекста.

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

-используемый в протоколе AH алгоритм аутентификации, его ключи и т.п.;

-используемый в протоколе ESP алгоритм шифрования, его ключи, начальный вектор и т.п.;

-используемый в протоколе ESP алгоритм аутентификации, его ключи и т.п.;

-время жизни контекста;

-режим работы IPSec: транспортный или туннельный;

-максимальный размер пакетов;

-группа полей (счетчик, окно, флаги) для защиты от воспроизведения пакетов;

Пользователями протокольных контекстов являются прикладные процессы - между двумя узлами сети может существовать произвольное число протокольных контекстов.

Пользователями управляющих контекстов выступают узлы сети. Управляющие контексты - двусторонние. Пара узлов может одновременно поддерживать несколько активных управляющих контекстов.

Протокольный контекст для IPSec идентифицируется целевым IP-адресом, протоколом (AH или ESP), индексом параметров безопасности (Security Parameter Index, SPI). Протокольный контекст создается на базе управляющего с использованием ключевого материала и средств аутентификации и шифрования последнего. В простейшем случае, когда протокольные ключи генерируются на основе существующих.

Формирование протокольного контекста

При выработке управляющего контекста было создано три вида ключей:

- SKEYID_d - ключевой материал, используемый для генерации протокольных ключей;

- SKEYID_a - ключевой материал для аутентификации;

- SKEYID_e - ключевой материал для шифрования.

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

Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки "совсем новых" секретных ключей или идентификаторы клиентов, от имени которых ISAKMP-серверы формируют протокольный контекст. В соответствии с протоколом IKE, за один обмен (состоящий из трех показанных сообщений) формируется два однонаправленных контекста - по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SPI), помогающий находить контекст для обработки принимаемых пакетов IPSec.

Для каждого нового пакета IPSec просматривает все записи в базе SPD и сравнивает значение селекторов этих записей с соответствующими полями IP-пакета. Если значение полей совпадает с каким- либо селектором, то над пакетом выполняются действия, определенные в поле политики безопасности данной записи: передача пакета без изменения, отбрасывание, обработка средствами IPSec. В последнем случае поле политики защиты должно содержать ссылку на запись в базе данных SAD (набор параметров безопасной ассоциации для данного пакета (на рис. для исходящего пакета определена ассоциация SA3). На основании заданных параметров безопасной ассоциации к пакету применяется соответствующий протокол (на рисунке — ESP), функции шифрования и секретные ключи.

Если к исходящему пакету нужно применить некоторую политику защиты, но указатель записи SPD показывает, что в настоящее время нет активной безопасной ассоциации с требуемой политикой, то IPSec создает новую ассоциацию с помощью протокола IKE, помещая новые записи в базы данных SAD и SPD.

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

Для каждого нового пакета, поступающего в защищенный канал, IPSec просматривает все записи в базе SPD и сравнивает значение селекторов этих записей с соответствующими полями IP-пакета. Если значение полей совпадает с каким- либо селектором, то над пакетом выполняются действия, определенные в поле политики безопасности данной записи: передача пакета без изменения, отбрасывание, обработка средствами IPSec.

В последнем случае поле политики защиты должно содержать ссылку на запись в базе данных SAD, в которую помещен набор параметров безопасной ассоциации для данного пакета (на рис. для исходящего пакета определена ассоциация SA3). На основании заданных параметров безопасной ассоциации к пакету применяется соответствующий протокол (на рисунке — ESP), функции шифрования и секретные ключи.

Если к исходящему пакету нужно применить некоторую политику защиты, но указатель записи SPD показывает, что в настоящее время нет активной безопасной ассоциации с требуемой политикой, то IPSec создает новую ассоциацию с помощью протокола IKE, помещая новые записи в базы данных SAD и SPD.

Базы данных политики безопасности создаются и администрируются либо пользователем (этот вариант больше подходит для хоста), либо системным администратором (вариант для шлюза), либо автоматически (приложением).

Как принимающий узел IPSec определяет способ обработки прибывшего пакета? (при шифровании многие ключевые параметры пакета, отраженные в селекторе, оказываются недоступными). Для решения этой проблемы в заголовках АН и ESP предусмотрено поле SPI. В это поле помещается указатель на строку базы данных SAD, в которой записаны параметры соответствующей безопасной ассоциации. Поле SPI заполняется протоколом АН или ESP во время обработки пакета в отправной точке защищенного канала. Когда пакет приходит в конечный узел защищенного канала, из его внешнего заголовка ESP или АН (на рисунке — из заголовка ESP) извлекается значение SPI, и дальнейшая обработка пакета выполняется с учетом всех параметров заданной этим указателем ассоциации.

Таким образом, для распознавания пакетов относящихся к разным безопасным ассоциацииям (SA), используются:

на узле-отправителе — селектор;

на узле-получателе — индекс параметров безопасности (SPI).

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