Протоколы ESP и AH позволяют сделать реальностью важнейшие атрибуты защищенной передачи – конфиденциальность связи, аутентификацию сторон и целостность данных. Между тем очевидно, что их функции потеряют всякую ценность в отсутствии мощной поддерживающей инфраструктуры, которая обеспечивала бы распределение ключей и согласование протоколов между участниками обмена.
Роль такой инфраструктуры в IPSec выполняет протокол Internet Key Exchange (IKE, RFC 2409), введенный в обращение в 1998 г.
Данный протокол является конкретизацией в системе IPSec общих стандартов обмена и генерации ключей, имеющих название ISAKMP/Oakley. Предполагается, что в системе протоколов IPSec может использоваться любая процедура обмена и генерации ключей, а также управления параметрами виртуальных каналов, которая удовлетворяет стандартам ISAKMP/Oakley. Однако к настоящему времени единственной реализованной и стандартизированной такой процедурой является IKE.
Протокол Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), был разработан в 1997 г. в Агентстве национальной безопасности США. Он позволяет согласовать алгоритмы шифрования и аутентификации, длину ключей, процедуру обмена ключами и другие необходимые параметры обмена.
В устаревших реализациях может использоваться протокол Simple Key Management for Internet Protocol (SKIP), выполняющий аналогичные задачи.
Протокол Oakley (RFC 2412) был предложен в том же году сотрудниками Университета штата Аризона и служит для непосредственного формирования и обмена ключами шифрования с использованием алгоритма Диффи–Хеллмана (см. выше).
Основными понятиями, используемыми в инфраструктуре формирования и обмена ключами, являются:
Security Association (SA) – выделенный защищенный виртуальный канал, однозначно идентифицируемый IP-адресом отправителя и индексом SPI, указывающим на запись с описанием всех параметров канала: алгоритма аутентификации протокола AH и его ключей, алгоритма шифрования, используемого протоколом ESP, и его ключей, наличия или отсутствия криптографической синхронизации, способов аутентификации партнеров и защиты сеанса обмена, частоты смены ключей и ряда других параметров.
Security Association Database (SAD) – база данных виртуальных каналов SA, создаваемая на каждой стороне обмена. При этом отдельные записи SA создаются для каждого направления обмена и для каждого протокола. Например, для двустороннего обмена пакетами, использующего и протокол AH, и протокол ESP, потребуется четыре записи SA.
Security Policy Database (SPD) – база данных политик безопасности, реализующая механизм управления защищенной передачей данных. В соответствии с правилами, указанными администратором сети, по значениям полей IP-пакета определяется, будет ли он отвергнут, обработан механизмами IPSec (при этом указывается SA, т.е. виртуальный канал) или обработан стандартным образом. Применение политик безопасности особенно эффективно при необходимости использования различных параметров защиты для различных приложений, например, Web-трафика и обращения к корпоративной базе данных.
Domain of Interpretation (DOI) – область интерпретации, определяющая полную информацию о сервисах, терминах, алгоритмах и т.д., необходимых для построения системы защищенного обмена информацией в рамках протокола ISAKMP. Одной из областей интерпретации является IPSec-DOI, описывающая протоколы ESP, AH и IKE, т.е. конкретизирующая общие требования стандарта.
Объектом согласования при инициализации виртуального канала являются:
метод аутентификации;
алгоритм шифрования;
алгоритм хеширования;
длины и сроки использования ключей;
тип протокола защиты (ESP или AH);
информация о группах простых чисел, которые будут использоваться в алгоритме формирования общих ключей Диффи–Хеллмана;
псевдослучайная функция, с помощью которой предстоит хешировать величины, используемые при обмене ключами (эта информация необязательна, и стандартно можно использовать алгоритм HMAC).
Весь процесс делится на две фазы:
1. Взаимная идентификация сторон и установление защищенного служебного соединения, так называемого IKE SA.
2. Непосредственное согласование параметров связи по служебному виртуальному каналу или формирование AH SA или ESP SA в зависимости от протокола.
Для обеих фаз предусмотрено по два способа установления соединения, в терминологии IKE называемых режимами.
Протокол IKE предписывает производителям обязательную реализацию для первой фазы основного режима (Main Mode) обмена и опционально агрессивного режима (Aggressive Mode), являющегося менее защищенным, но более быстродействующим.
Для второй фазы предусмотрены быстрый режим (Quick Mode), согласовывающий параметры основного SA, и режим новой группы (New Group Mode), оставленный для будущих применений с целью реализации виртуальных каналов между тремя и более узлами.
В обоих случаях применяется специальный формат данных, предусмотренный протоколом ISAKMP. Сами данные между узлами передаются в пакетах UDP по порту 500.
2. Responder Cookie (32 бита) – идентификатор второй стороны канала.
3. Next Payload (1 байт) – тип первого сообщения пакета.
4. Major Version (4 бита) – общая версия протокола IASKMP (равна 1).
5. Minor Version (4 бита) – подверсия протокола IASKMP (равна 0).
6. Exchange Type (1 байт) – тип сеанса (например, основной режим).
7. Flags (1 байт) – три старших бита указывают на шифрование данных пакета, синхронизацию обмена и аутентификацию, остальные биты равны 0.
8. Message ID (32 бита) – уникальное случайное число, генерируемое инициатором фазы 2 с целью разрешения коллизий (когда оба абонента инициируют согласование параметров). В фазе 1 это поле является нулевым.
9. Length (32 бита) – длина всего пакета в байтах.
После заголовка непосредственно следуют одно или несколько сообщений протокола. Все они имеют следующий формат:
1. Заголовок сообщения, состоящий из поля Next Payload (1 байт), указывающего на тип следующего за ним сообщения в пакете, резервного поля (1 байт, равен 0), поля Payload Length (2 байта), указывающего на длину сообщения в байтах.
2. Непосредственно данные сообщения, формат которых зависит от его типа.
Сейчас предусмотрено 15 типов сообщений, назначение которых станет понятно чуть позднее: SA, предложение создать виртуальный канал, передача параметров канала, обмен ключами, выбор алгоритма аутентификации, запрос/ответ сертификата, передача значения хэш-функции, цифровой подписи, случайного числа, сообщение об ошибке, удаление канала и т.д.
Данные в любом сообщении (например, параметры виртуального канала SA) передаются также в специальном формате:
1. Бит информации – нулевое значение говорит о передаче длины параметра, а единичное – о передаче значения параметра.
2. Код параметра (15 бит).
3. Длина или значение параметра в зависимости от бита информации.
4. Значение параметра (переменной длины), если бит информации равен нулю.
Интерпретация кодов параметров происходит на основе области интерпретации DOI, которая также указывается в сообщении и должна поддерживаться производителем.
Перед началом процедуры обмена инициатор должен установить для себя следующие параметры:
1. Свой собственный идентификатор cookie – он, как правило, формируется на основе хэш-функции из IP-адресов приемника и источника, даты и времени, UDP-порта отправителя и получателя и некоторого случайного значения.
2. "Ситуацию", в которой происходит формирование виртуального канала, она зависит от DOI и включает в себя режим, метод аутентификации сторон, параметры алгоритма аутентификации и другие параметры, связанные с формированием IKE SA.
3. Предложения по параметрам устанавливаемого соединения – протокол, алгоритмы шифрования, длины и срок действия ключей и т.д.
Основной режим предусматривает передачу шести пакетов ISAKMP (за исключением повторных запросов и ошибок соединения):
1. Инициатор канала направляет другой стороне свой идентификатор (C_I), ситуацию и одно или несколько предложений по параметрам защищенного канала IKE SA.
2. Получатель направляет инициатору его идентификатор (C_I), свой идентификатор (C_R) и параметры принятого предложения по организации канала.
В соответствии с алгоритмом Диффи-Хеллмана инициатор и получатель генерируют открытый и закрытый ключи, а также случайные числа. Длина этих параметров уже является согласованной в результате описанного выше обмена пакетами.
Дальнейшая передача происходит в зависимости от согласованного алгоритма аутентификации, в качестве которого может использоваться: цифровая подпись, схема с открытым ключом, схема с предварительно согласованным ключом и др. Цель обмена в данном случае – выработать ключ шифрования и аутентификации, которые будут использоваться во второй фазе.
3. Инициатор канала направляет другой стороне открытую часть своего ключа (KO_I) и случайное число (N_I).
4. Получатель канала направляет инициатору свой открытый ключ (KO_R) и свое случайное число (N_R).
В соответствии с алгоритмом Диффи-Хеллмана инициатор и получатель из своих закрытых ключей и открытых ключей собеседников генерируют одинаковый общий ключ шифрования KEY. Кроме того, они генерируют свои идентификаторы ID_I и ID_R, которые будут аутентифицировать дальнейшие сообщения.
С помощью псевдослучайной функции prf в зависимости от согласованного алгоритма аутентификации генерируется закрытый код аутентификации сообщений (AUTH) и ключ шифрования трафика (IK). Например, для цифровой подписи используются следующие соотношения:
T_KEY = prf(N_I | N_I, KEY)
TEMP = prf(T_KEY, KEY | C_I | C_R | 0000)
AUTH = prf(T_KEY, TEMP | KEY | C_I | C_R | 0001)
IK = prf(T_KEY, AUTH | KEY | C_I | C_R | 0002)
После этого инициатор и получатель генерируют свои цифровые подписи, которые аутентифицируют сгенерированные комбинации AUTH и IK:
SIG_I = prf(TEMP1, KO_I | KO_R | C_I | C_R | IKE SA | ID_I)
SIG_R = prf(TEMP1, KO_R | KO_I | C_R | C_I | IKE SA | ID_R)
Во всех формулах знак "|" означает конкатенацию.
5. Инициатор канала направляет получателю в зашифрованном с помощью ключа IK виде значения своего идентификатора ID_I и цифровой подписи SIG_I.
6. Получатель канала направляет инициатору в зашифрованном с помощью ключа IK виде значения своего идентификатора ID_R и цифровой подписи SIG_R.
Вместе с идентификаторами и подписями на последнем этапе также могут передаваться сертификаты сторон, полученные по одному из стандартов (например. X.509 или PGP Web in Trust).
После проверки цифровых подписей фаза 1 завершается и защищенный служебный виртуальный канал IKE SA для согласования параметров основного виртуального канала считается установленным.
Идентификация канала IKE SA при этом происходит по значениям комбинаций C_I и C_R. В рамках одного такого канала могут согласовываться параметры нескольких основных виртуальных соединений, каждый такой сеанс идентифицируется значением Message ID в заголовке пакета ISAKMP.
Агрессивный режим предусматривает передачу только трех пакетов ISAKMP:
1. Инициатор канала направляет другой стороне свой идентификатор (C_I), ситуацию и одно или несколько предложений по параметрам защищенного канала IKE SA, и, кроме того значения KO_I, N_I, ID_I.
2. Получатель направляет инициатору его идентификатор (C_I), свой идентификатор (C_R) и параметры принятого предложения по организации канала, а также значения KO_R, N_R, ID_R, SIG_R и, возможно, сертификат.
3. Инициатор канала направляет получателю свою подпись SIG_I и, возможно, сертификат.
После фазы 1 выполняется фаза 2 непосредственного установления виртуальных каналов, для связи двух абонентов через VPN. При этом вся информация в пакетах ISAKMP (за исключением общего заголовка) шифруется с применением согласованного алгоритма и ключа IK, а также аутентифицируется с использованием псевдослучайной функции и ключа AUTH. В фазе 2 передается три пакета (не считая повторных передач):
1. Инициатор виртуального канала вычисляет хэш-функцию HASH1 от передаваемых данных и помещает ее в качестве первого сообщения в пакет, далее следует идентификатор DOI, описание ситуации, предложение протокола (AH или ESP), идентификатор SPI и параметры канала, все вместе называемое SA, кроме того, передается случайное число N_I, и при необходимости открытая часть ключа в алгоритме Диффи-Хеллмана KO_I, идентификаторы приемника и источника ID_I и ID_R.
2. Приемник посылает в ответ вместе с хэшем HASH2 принятые параметры канала, случайное число N_R и при необходимости свой открытый ключ KO_R, идентификаторы приемника и источника ID_I и ID_R.
3. Инициатор подписывает сообщение хэш-функцией HASH3, после чего однонаправленный виртуальный канал считается установленным и готов к применению.
При этом хэш-функции вычисляются следующим образом:
В целом процедура согласования и генерации ключей является в IPSec наиболее сложной частью. Здесь мы рассмотрели лишь общие походы в ее организации. Описание в RFC является намного более обширным и сложным, поскольку предоставляет производителям очень большие возможности по использованию самых различных алгоритмов шифрования и хеширования.
Признано, что система IPSec является достаточно стойкой к атакам отказа в обслуживании, нарушения целостности и конфиденциальности для протоколов ESP и AH. Для протокола IKE оценки не столь однозначны. Для защиты от DoS атак в нем предусмотрены лишь идентификаторы cookie, в дополнение к которым рекомендуется использовать списки авторизованных IP-адресов. Атаки, связанные со сканированием, внедрением ложного объекта-посредника и т.п., также достаточно стабильно отражаются протоколом за счет сложной системы установления связи и аутентификации. Кроме того, предусмотрена целая система тайм-аутов и откатов к начальному состоянию при любом срыве в ходе установления соединения.
Сложность протокола предопределяет высокую стоимость его аппаратной поддержки или высокую производительность вычислительных средств, программно реализующих шлюз VPN.
