1.2. Начальные обмены
Коммуникации с использованием IKE всегда начинаются с обменов IKE_SA_INIT и IKE_AUTH (в IKEv1 — Фаза 1). Эти начальные обмены включают четыре сообщения, хотя в некоторых сценариях это число может расти. Все коммуникации с использованием IKE состоят из пар «запрос-отклик». Сначала будет описываться базовый обмен, а затем — возможные варианты. Первая пара сообщений (IKE_SA_INIT) согласует криптографические алгоритмы, осуществляет обмен сигналами nonce и обмен Diffie-Hellman [DH].
Вторая пара сообщений (IKE_AUTH) идентифицирует предыдущие сообщения, обеспечивает обмен идентификационной информацией и сертификатами, а также создает первую CHILD_SA. Компоненты этих сообщений шифруются и целостность их защищается с использованием ключей, организованных при обмене IKE_SA_INIT, поэтому идентификационные данные недоступны для подслушивания, а все поля сообщений идентифицируются.
На врезке приведен список обозначений и краткое описание данных, содержащихся в сообщениях.
| Обозначение | Данные |
| AUTH | идентификация |
| CERT | сертификат |
| CERTREQ | запрос сертификата |
| CP | конфигурация |
| D | удаление |
| E | зашифровано |
| EAP | расширенная идентификация |
| HDR | заголовок IKE |
| IDi | идентификация — инициатор |
| IDr | идентификация — отвечающая сторона |
| KE | обмен ключами |
| Ni, Nr | Nonce |
| N | уведомление |
| SA | защищенная связь |
| TSi | селектор трафика — инициатор |
| TSr | селектор трафика — отвечающая сторона |
| V | идентификатор производителя |
Содержимое данных в сообщениях подробно рассматривается в разделе 3. Данные, которые являются необязательными, указываюся в квадратных скобках — [CERTREQ] показывает возможность включения запроса сертификата.
Начальные обмены имеют вид:
Инициатор Ответчик ----------- ---------- HDR, SAi1, KEi, Ni -->
HDR содержит списки параметров защиты (SPI), номера версий и различные флаги. SAi1 указывает поддерживаемые инициатором криптографические алгоритмы для IKE_SA. В KE передаются значения Diffie-Hellman от инициатора. Ni задает nonce от инициатора.
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
Отвечающая сторона выбирает криптографический набор из числа предложенных инициатором и указавает свой выбор в SAr1, завершает обмен Diffie-Hellman в KEr ипередает свой сигнал nonce в Nr.
На этом этапе согоасования каждая из сторон может генерировать «затравку» SKEYSEED, на основе которой будут создаваться все ключи для данной IKE_SA. Все, кроме заголовков, во всех последующих сообщениях будет шифроваться с дополнительной защитой целостности. Ключи, используемые для шифрования и защиты целостности, создаются на основе SKEYSEED и обозначаются SK_e (encryption — шифрование) и SK_a (authentication — идентификация для защиты целостности). Для каждого направления создаются ттдельные ключи SK_e и SK_a. В дополнение к ключам SK_e и SK_a, создаваемым из значения DH для защиты IKE_SA, создается другая величина SK_d is, которая используется для создания последующего материаля для зазищенных связей CHILD_SA. Обозначения SK { ... } показывают, что эти данные зашифрованы с защитой целостности на основе ключей SK_e и SK_a для соответствующего направления.
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
целостность содержимого первого сообщения, используя AUTH (см. параграф 2.15). Он может также передать свой сертификат (сертификаты) в CERT и список своих доверенных привязок в CERTREQ. При включении CERT первый представляемый сертификат должен содержать открытый ключ, используемый для проверки поля AUTH. Необязательные данные IDr позволяют инициатору указать, какую идентификацию он хочет получить от отвечающей стороны. Это полезно в тех случаях, когда на машине, где работает отвечающая сторона, поддерживается множество вариантов идентификации для одного адреса IP. Инициатор начинает согласовывать CHILD_SA с использованием SAi2. Завершающие поля (начиная с SAi2) описаны при рассмотрении обмена CREATE_CHILD_SA.
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
Отвечающая сторона представляет свою идентификацию в IDr, и может передавать один или множество сертификатов (как и у инициатора, сертификат, содержащий публичный ключ для проверки AUTH, должен указываться первым), подтверждает свою идентификацию, защищает целостность второго сообщения с помощью AUTH и завершает согласование CHILD_SA в дополнительных полях, описанных ниже для обмена CREATE_CHILD_SA.
Получателя сообщений 3 и 4 должны проверить корректность расчета всех сигнатур и MAC, а также соответствие имен в ID ключам, используемым для генерации AUTH.