RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.

Тезисы

В этом документе описана версия 2 протокола обмена ключами в Internet (IKE1). Протокол IKE является частью IPsec и служит для обоюдной идентификации партнеров, организации и поддержки защищенных связей (SA2).

Эта версия спецификации IKE объединяет содержимое нескольких отдельных документов прежних версий, включая ISAKMP3 (RFC 2408), IKE (RFC 2409), DOI4 (RFC 2407), спецификация работы через NAT5, унаследованную идентификацию и получение удаленного адреса.

Версия 2 протокола IKE не интероперабельна с версией 1, но имеет достаточно много общего в формате заголовков и обе версии однозначно могут работать через один и тот же порт UDP.

Оглавление

1. Введение

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

Организация этого состояния вручную не обеспечивает приемлемого масштабирования. Следовательно, требуется протокол для динамической организации этого состояния. В данном документе описан такой протокол — протокол обмена ключами Internet (IKE). Данное описание относится к версии 2 проткола IKE. Первая версия протокола IKE была определена в RFC 2407, 2408 и 2409 [Pip98, MSST98, HC98]. Данный документ заменяет три упомянутых RFC.

Определения основополагающих треминов, используемых в документе (таких, как защищенная связь или SA) можно найти в [RFC4301].

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [Bra97].

Термин Expert Review (экспертиза) интерпретируется в соответствии с определением [RFC2434].

IKE выполняет взаимную идентификацию партнеров и организует защищенную связь IKE SA, включающую разделяемый секретный ключ, который может эффективно использоваться при организации SA для протоколов ESP [RFC4303] и/или AH [RFC4302], и набор криптографических алгоритмов, которые будут использоваться SA для защиты передаваемого трафика. В этом документе термины «набор» (suite) или «криптографический набор» (cryptographic suite) обозначают все множество алгоритмов, используемых для защиты SA. Инициатор предлагает один или несколько наборов, перечисляя поддерживаемые им алгоритмы, которые могут быть объединены в наборы или использоваться «вперемешку». IKE может также согласовывать использование компрессии IP (IPComp) [IPCOMP] совместно в ESP и/или AH SA. Для IKE SA будем использовать обозначение IKE_SA. SA для ESP и/или AH, проходящие через IKE_SA, будем обозначать CHILD_SA.

Весь обмен информацией IKE организован в форме парных соощений запрос — отклик. Для пар используется тремин «обмен» (exchange). Первые сообщения при организации IKE_SA включают обмен IKE_SA_INIT и IKE_AUTH, а за ними следуют обмены CREATE_CHILD_SA или INFORMATIONAL. В общем случае для организации IKE_SA и первой связи CHILD_SA используется один обмен IKE_SA_INIT и один обмен IKE_AUTH (всего 4 сообщения). В исключительных случаях оба обмена могут использоваться неоднократно. В любом случае все обмены IKE_SA_INIT должны быть завершены до начала обмена любого другого типа, после этого должны быть завершены все обмены IKE_AUTH и далее могут выполняться в любом порядке обмены CREATE_CHILD_SA и INFORMATIONAL. В некоторых сценариях между конечными точками IPsec требуется только один обмен CHILD_SA и, следовательно, не возникает дополнительных обменов. Последующие обмены могут использоваться для организации дополнительных CHILD_SA между теми же идентифицированными парами конечных точек и для выполнения вспомогательных функций.

Поток сообщений IKE всегда состоит из запросов, за которыми следует соответствующий отклик. Ответственность за обеспечение надежности возлагается на запрашивающую сторону. Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или прервать попытку соединения).

Первый запрос/отклик в сеансе IKE (IKE_SA_INIT) согласует параметры защиты для IKE_SA, передает специальные сигналы nonce и значения Diffie-Hellman.

Вторая пара запрос/отклик (IKE_AUTH) передает идентификацию, обеспечивает информацию о секретах идентифицированных сторон и организует защищенную связь для первой (зачастую, единственной) AH или ESP CHILD_SA.

Последующие обмены относятся к типу CREATE_CHILD_SA (создание CHILD_SA) и INFORMATIONAL (удаление SA, сообщения об ошибках и другие служебные функции). Каждый запрос требует отклика. Запросы типа INFORMATIONAL, не содержащие информации (кроме пустого поля Encrypted payload, требуемого синтаксисом) обычно используются для проверки сохранности соединения. Последующие обмены не могут осуществляться, пока не будут завершены начальные обмены. Далее в описании предполагается отсутствие ошибок. Изменения потока, связанные с ошибками, рассмотрены в параграфе 2.21.

1.1. Сценарии использования

Предполагается, что IKE будет использоваться при согласовании SA SA SA для протоколов ESP и/или AH SAs во множестве различных сценариев с отличающимися требованиями.

1.1.1. Туннель между защитными шлюзами

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

1.1.2. Туннель между конечными точками

            +-+-+-+-+-+            +-+-+-+-+-+
            !Конечная ! Туннель    !Конечная !
Защищенная  !точка    !  IPsec     !точка    !  Защищенная
подсеть <-->!туннеля  !<---------->!туннеля  !<--> подсеть
            !         !            !         !
            +-+-+-+-+-+            +-+-+-+-+-+
Рисунок 1: Туннель между защитными шлюзами

В этом сценарии обе конечные точки соединения IP реализуют IPsec в соответствии с требованиями для хостов в [RFC4301]. Обычно используется транспортный режим без внутренних заголовков IP. Если внутренний заголовок используется, адрес IP в нем будет совпадать с адресом во внешнем заголовке. Для защиты с помощью данной SA согласуется одна пара адресов. Конечные точки могут реализовать средства контроля доступа на прикладных уровнях на основе Ipsec-идентификации участников соединения. Этот сценарий обеспечивает сквозную защиту, которая является одним из принципов работы Internet с момента разработки [RFC1958], [RFC2775] и метода ограничения унаследованных проблем, связанных со сложностью сетей, которые отмечены в [RFC3439]. Хотя этот сценарий не может полноценно применяться в Internet на базе IPv4, он может успешно использоваться внутри сетей intranet на базе IKEv1. Более широкому распространению этого сценария будет способствовать переход на IPv6 и адаптация IKEv2.

+-+-+-+-+-+-+                                          +-+-+-+-+-+-+
!           !        Защищенная связь (SA)             !           !
!Защищенная !в туннельном или транспортном режиме IPsec! Защищенная!
!   точка   !<---------------------------------------->!   точка   !
!           !                                          !           !
+-+-+-+-+-+-+                                          +-+-+-+-+-+-+
Рисунок 2: Туннель между конечными точкам

В таком сценарии одна или обе конечных точки могут находиться за системой трансляции сетевых адресов (NAT). В этом этом случае туннелируемые пакеты будут инкапсулироваться в UDP так, что номера портов в заголовках UDP можно будет использовать для идентификации отдельных конечных точек, расположенных за NAT (см. параграф 2.23).

1.1.3. Туннель между конечной точкой и защитным шлюзом

В этом сценарии защищенная конечная точка (обычно портативный компьютер) подключается к корпоративной сети с использованием защищенного туннеля IPsec. Туннель может использоваться только для доступа к информации, хранящейся в корпоративной сети, или служить для передачи всего трафика портативного компьютера через офисную сеть для обеспечения возможности использования корпоративного межсетевого экрана, защищающего компьютер от атак из сети Internet. В любом случае защищенной точке будет нужен IP-связанный с защитным шлюзом, чтобы адресованные этой точке пакеты попадали на защитный шлюз и передавались им через туннель на защищенную точку. Этот алрес может выделяться защитным шлюзом статически или динамически. Во втором случае IKEv2 включает механизм, с помощью которого инициатор соединения запрашивает адрес IP, принадлежащий шлюзу, для использования в течение срока действия SA.

+-+-+-+-+-+-+                          +-+-+-+-+-+
!           !         Туннель          !Конечная !     Защищенная
!Защищенная !          IPsec           !  точка  !     подсеть
!   точка   !<------------------------>! туннеля !<--- и/или
!           !                          !         !     Internet
+-+-+-+-+-+-+                          +-+-+-+-+-+
Рисунок 3: Туннель между конечной точкой и защитным шлюзом

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

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

1.1.4. Другие сценарии

Возможны и другие сценарии, представляющие собой комбинации перечисленных выше вариантов. Один примечательный вариант объединяет в сете аспекты 1.1.1 и 1.1.3. Подсеть может организовать весь доступ наружу через удаленный защитный шлюз, используя туннель IPsec и тогда внешние сети (Internet) будут маршрутизировать пакеты для подсети защитному шлюзу. Например, некая домашняя сеть может виртуально представляться в сети Internet статическими адресами IP, несмотря на то, что эта сеть подключена через ISP, который выделяет один динамический адрес пользовательскому защитному шлюзу (видимый в Internet Internet Internet Internet статический адрес IP и трансляция IPsec обеспечивается третьей стороной, расположенной в другом месте).

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.

1.3. Обмен CREATE_CHILD_SA

Этот обмен включает одну пару «запрос-отклик» и обозначается, как фаза 2 обмена в IKEv1. Обмен может инициироваться любой из сторон IKE_SA после завершения начальных обменов.

Все сообщения после первоначального обмена шифруются с использованием криптографического алгоритма и ключей, согласованных в первых двух сообщениях обмена IKE. Последующие сообщения используют синтаксис Encrypted Payload (зашифрованные данные), описанный в параграфе 3.14. Все последующие сообщения включаются в Encrypted Payload, даже если они указаны в тексте документа, как «пустые».

Любая из конечных точек может инициировать обмен CREATE_CHILD_SA, поэтому в данной секции термин «инициатор» означает конечную точку, начинающую этот обмен.

CHILD_SA создается путем передачи запроса CREATE_CHILD_SA. Этот запрос может содержкать данные KE для дополнительного обмена Diffie-Hellman, позводяющего заблаговременно гарантировать более строгую защиту (секретность) для CHILD_SA. Ключевой материал для CHILD_SA является функцией SK_d, организованного при созданиии IKE_SA, обмена сигналами nonce в процессе обмена CREATE_CHILD_SA, и значения Diffie-Hellman (если данные KE включены в обмен CREATE_CHILD_SA).

В CHILD_SA, создаваемой, как часть начального обмена, недопустимо передавать второй KE и nonce. Сигналы nonce из начального обмена используются при расчете ключей для CHILD_SA.

Запрос CREATE_CHILD_SA включает:

 Инициатор                                 Ответчик
-----------                               ----------
 HDR, SK {[N], SA, Ni, [KEi],
     [TSi, TSr]}             -->

Инициатор передает предложение (предложения) SA в данных SA, nonce в Ni, может передать значение Diffie-Hellman в KEi, а также предложенные селекторы трафика в TSi и TSr. Если этот обмен CREATE_CHILD_SA служит для замены ключей существующей SA, отличной от IKE_SA, ведущие данные N типа REKEY_SA MUST идентифицируют SA, для которой меняются ключи. Если этот обмен CREATE_CHILD_SA не является заменой ключей для существующей SA, данные N должны быть опущены. Если предложения SA включают различные группы Diffie-Hellman, данные KEi должны быть элементом группы, которую инициатор желает принять от отвечающей стороны. Если это предположение ошибочно, обмен CREATE_CHILD_SA завершится неудачей и будет повторяться с другим KEi.

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

Отклик CREATE_CHILD_SA содержит:

<--    HDR, SK {SA, Nr, [KEr],
             [TSi, TSr]}

Отвечающая сторона передает (используя то же значение Message ID) воспринятое предложение в данных SA, значение Diffie-Hellman в Ker, если в запрос были включены данные Kei, и выбранный криптографический набор, включающий данную группу. Если отвечающий выбирает криптографический набор с другой группой, он должен отвергнуть запрос. Инициатору следует повторить запрос с данными Kei из группы, выбранной отвечающим.

Селектор трафика для трафика, который будет передаваться в данной SA, указывается в данных TS, которые могут быть подмножеством предложенного инициатором CHILD_SA. Селекторы трафика опускаются, если данный запрос CREATE_CHILD_SA будет использоваться для смены ключа IKE_SA.

1.4. Обмен INFORMATIONAL

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

Управляющие сообщения, которые относятся к IKE_SA MUST, должны передаваться в данной IKE_SA. Управляющие сообщения, которые относятся к CHILD_SA должны передаваться под защитой IKE_SA, которая сгенерировала их (или ее наследник, если IKE_SA была заменена при смене ключей).

Сообщения информационного обмена содержат 0 или более элементов данных Notification, Delete и Configuration. Получатель запроса INFORMATIONAL должен передать некий отклик (иначе отправитель будет предполагать потерю сообщения в сети и повторять его). Отклик может быть сообщением без элементов данных. Запросное сообщение в информационном обмене также может не содержать элементов данных. Предполагается, что это может использоваться конечными точками для проверки того, что партнер «жив».

Защищенные связи ESP и AH всегда существуют в паре по одной SA для каждого направления. При закрытии SA должны быть закрыты оба члена пары. К тех случаях, когда SA являются вложенными, а также когда данные (и заголовки IP в туннельном режиме) сначала инкапсулируются с использованием IPComp, затем организовано ESP и, наконец, AH между одной парой конечных точек, все SA должны удаляться вместе. Каждая из конечных точек должна закрыть свои входящие SA и позволить другой точке закрыть соответствующую SA в каждой паре. Для удаления SA используется информационный обмен с передачей одного или множества элементов удаления (Delete Payload), перечисляющих SPI (которые ожидаются в заголовках входящих пакетов) удаляемых SA. Получатель должен закрыть означенные SA. Обычно отклик в информационном обмене будет содержать элементы удаления для парных SA обратного направления. Но существует одно исключение. Если обе стороны набора SA независимо решат закрыть их, каждая может передать элемент удаления и два запроса могут пересечься в сети. Если узел получает запрос удаления для SA, которые он уже указал в запросе удаления, он должен удалить исходящие SA в процессе обработки запроса и входящие SA при обработке отклика. В таких случаях в отклик недопустимо включать элементы удаления для удаленных SA, поскольку это будет приводить к дублированию удаления и может (теоретически) удалить ненужную SA.

Узлу следует рассматривать полузакрытые соединения, как аномалию, и при их сохранении делать запись в журнал аудита. Отметим, что в этой спецификации не задается никаких временных интервалов, поэтому конечные точки сами устанавливают время ожидания. Узел может отвергнуть прием входящих данных через полузакрытое соединение, но недопустимо закрывать его в одностороннем порядке и после этого снова использовать SPI. Если состояние соединения в достаточной степени беспорядочным, узел может закрыть IKE_SA; в этом случае он неявно закрывает все согласованные в нем SA. После этого узел может заново создать требуемые SA на базе новой IKE_SA.

Обмен INFORMATIONAL определяется следующим образом:

 Инициатор                        Ответчик
-----------                      ----------
 HDR, SK {[N,] [D,] [CP,] ...} -->
                             <-- HDR, SK {[N,] [D,] [CP], ...}

Обработка информационного обмена определяется включенными в него элементами данных.

1.5. Информационные сообщения вне IKE_SA

Если зашифрованный пакет IKE приходит в порт 500 или 4500 с нераспознанным SPI, причиной этого может быть неданий сбой принимающего узла и потеря информации о состоянии, тот или иной системный отказ или атака. Если принимающий узел имеет активную IKE_SA для IP-адреса, с которого пришел пакет, он может передать уведомление о странном пакете через IKE_SA, используя обмен INFORMATIONAL. Если узел не имеет такой IKE_SA, он может отправить информационное сообщение без криптографической защиты по адресу отправителя пакета. Такое сообщение не является частью информационного обмена и для принявшего это сообщение узла недопустимо отвечать на него. Такой ответ может привести к возникновению петли при обмене сообщениями.

2. Детали и вариации протокола IKE

IKE обычно слушает и передает дейтаграммы UDP через порт 500, хотя сообщения IKE принимаются также через порт UDP 4500 с использованием слегка отличающегося формата (см. параграф 2.23). Поскольку протокол UDP использует дейтаграммы (транспорт без гарантии доставки), IKE включает определение процедуры восстановления при ошибках передачи, включая потерю и повторное использование пакетов, а также прием поддельных пакетов. Протокол IKE рассчитан на работу в условиях, когда (1) по крайней мере один из серии переданных повторно пакетов достигает получателя до завершения времени ожидания и (2) канал не переполнен обманными и повторными пакетами так, что это ведет к нехватке ресурсов сети или производительности CPU на одной из конечных точек. Даже при невыполнении этих минимальных требований IKE будет прерывать работу «чисто» (как при обрыве сети.

Хотя сообщения IKEv2 должны быть короткими, они содержкат структуры данных без жестко заданной верхней границы размера (в частности, сертификаты X.509), а сам протокол IKEv2 не включает механизма фрагментирования больших сообщений. Протокол IP определяет механизм фрагментирования слишком больших дейтаграмм UDP, но максимальный поддерживаемый размер может зависеть от реализации. Более того, использование фрагментации IP открывает реализации для атак на служьы (DoS) ) [KPS03]. Кроме того, некоторые реализации NAT и/или межсетевых экранов могут блокировать фрагменты IP.

Все реализации IKEv2 должны быть способны передавать, принимать и обрабатывать сообщения IKE размером до 1280 байтов и следует также обеспечивать возможность передачи, приема и обработки сообщений размеров до 3000 байтов. Реализациям IKEv2 следует принимать во внимание максимальный размер поддерживаемых сообщений UDP и можно укорачивать сообщения, убирая из них некоторые предлагаемые сертификаты и криптографические наборы, если это позволит сохранить размер сообщения ниже максимума. Использование форматов «Hash and URL» там, где это возможно, позволит избежать большшинства проблем. В реализациях и конфигурационных параметрах следует принимать во внимание, что в тех случаях, когда поиск URL становится возможным только после организации IPsec SA, проблемы рекурсии могут воспрепятствовать примению упомянутого метода.

2.1. Использование таймеров повтора передачи

Все сообщения в IKE существуют попарно — запрос и отклик. Организация IKE_SA обычно включает две пары запрос-отклик. После организации IKE_SA любая из сторон защищенной связи может в любой момент инициировать запрос и в каждый момент времени «налету» может находиться множество запросов и откликов. Но каждое сообщение помечается, как запрос или отклик и для каждой пары запрос-отклик одна из сторон является инициатором, а другая — ответчиком.

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

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

2.2. Использование порядковых номеров для Message ID

Каждое сообщение IKE содержит идентификатор Message ID, который является частью фиксированного заголовка. Этот идентификатор используется для поиска соответствия между запросами и откликами, а также для идентификации повтора сообщений.

Message ID представляет собой 32-битовое число, которое принимает нулевое значение при передаче в IKE первого запроса в каждом направлении. Начальные сообщения при организации IKE_SA всегда будут иметь номера 0 и 1. Каждая конечная точка в IKE SA поддерживает два «текущих» значения Message ID — следующее, которое будет использоваться при инициировании запроса и следующее, которое она ожидает получить в запросе от другой стороны. Значения счетчиков инкрементируются при генерации и получении запросов, соответственно. Отклик всегда содержит значение Message ID из соответствующего запроса. Это означает, что после начального обмена каждое целое значение n может появляться в качестве идентификатора 4 разных сообщений — n-ого запроса от исходного инициатора IKE, соответствующего ему отклика, n-ого запроса от исходного ответчика IKE и соответствующего ему отклика. Если стороны делают разное число запросов, значения Message ID в разных направлениях могут существенно различаться. Однако здесь не возникает неоднозначности в сообщениях, поскольку биты инициатора (I) и ответчика (R) в заголовке сообщения показывают, которым из четырех возможных сообщений является данное.

Отметим, что значение Message ID шифруется и для него обеспечивается защита целостности для предотвращения повторного использования сообщений. В маловероятной ситуации, когда значение Message ID достигает предела 32-битового числа, требуется закрыть IKE_SA. Замена ключей IKE_SA ведет к сбросу значений идентификаторов.

2.3. Размер окна для перекрывающихся запросов

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

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

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

Для конечной точки IKE недопустимо вызодить за пределя заявленного партнером размера окна при передаче запросов IKE. Иными словами, если отвечающая сторона заявляет для своего окна размер N, инициатору для того, чтобы отправить запрос X, требуется необходимо дождаться откликов на все запросы, вплоть до X-N. Конечная точка IKE должна хранить копию (или обеспечивать точное воспроизведение) каждого переданного ею запроса, пока на этот запрос не был получен отклик. Конечная точка IKE должна хранить копию (или обеспечивать точное воспроизведение) предыдущих откликов в количестве, равном объявленному ею размеру окна, на случай потери отклика и получения от инициатора повторного запроса.

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

2.4. Синхронизация состояний и время ожидания для соединений

Конечным точкам IKE разрешается в любой момент забывать все свои состояния, связанные с IKE_SA и набором соответствующих CHILD_SA. Это сделано для обеспечения устойчивости к авариям и перезапускам конечных точек. Важно, чтобы при аварии или реинициализации состояния конечной точки другая сторона детектировала такие события и прекращала бы расход полосы сети на передачу пакетом через отброшенную SA, которые будут уходить в «черную дыру».

Поскольку протокол IKE был разработан с учетом возможности атак на отказ служб (DoS) из сети, для конечной точки недопустимо констатировать отказ другой конечной точки на основе какой-либо маршрутной информации (например, сообщений ICMP) или сообщений IKE, приходящих без криптографияеской защиты (например, сообщений Notify о неизвестных SPI). Конечная точка должна констатировать отказ другой конечной точки только в случаях повторяющихся в течение всего периода ожидания отказах (отсутствии ответов) при попытках контакта с этой точкой или при получении криптографически защищенного уведомелния INITIAL_CONTACT для другой IKE_SA с такой же идентификацией. Конесной точки на основании соответствующей маршрутной информации и инициировать запрос для проверки жизнеспособности другой точки. Для такой проверки в IKE предусмотрены пустые сообщения INFORMATIONAL, которые (подобно всем запросам IKE) требуют подтверждения (отметим, что в контексте IKE_SA «пустое» сообщение представляет собой заголовок, за которым следует поле Encrypted, не содержащее данных). Если от другой стороны недавно было получено криптографически защищенное соединение, незащищенные уведомления можно игнорировать. Реализации должны ограничивать частоту операций, выполняемых на основе незащищенных соединений.

Число попыток и продолжительность времени ожидания не задаются данной спецификацией, поскольку они не оказывают влияния на интероперабельность. Предлагается повторять передачу сообщения по крайней мере дюжину раз в течение периода по крайней мере в несколько минут прежде, чем отказаться от SA, однако в разных средах эти параметры могут различаться. Для предотвращения возможных перегрузок период повтора передачи сообщений должен возрастать экспоненциально. Если на всех SA, связанных с IKE_SA, присутствовал только исходящий трафик, важно убедиться в жизненности другой конечной точки для предотвращения «черных дыр». Если в течение некоторого времени не было получено криптографически защищенных сообщений в IKE_SA или любой из дочерних CHILD_SA, система должна проверить жизненность удаленной точки для предотвращения передачи сообщений «мертвому» партнеру. Получение свежего, криптографически защищенного сообщения в IKE_SA или любой из дочерних CHILD_SA гарантирует жизненность IKE_SA и всех дочерних CHILD_SA. Отметим, что это вносит требования к обработке отказов конечных точек IKE. Для реализации недопустимо продолжать передачу в любую SA, если тот или иной отказ не позволяет принимать сообщения на всех связанных SA. Если возможен отказ одной CHILD_SA независимо от других без возможности для IKE_SA передачи сообщения Delete, для таких SA SA SA должны согласовываться раздельные IKE_SA.

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

Отметим, что с приведенными правилами не возникает необходимости согласования срока жизни SA. Если IKE предполагает, что партнер не работает на основе повторяющегося отсутствия подтверждений для сообщения IKE, тогда IKE SA и все дочерние CHILD_SA, организованные в данной IKE_SA, удаляются.

Конечная точка IKE может в любой момент удалить неактивнst st CHILD_SA в целях освобождения ресурсов, используемых для поддержки состояния этих связей. Если конечная точка IKE принимает решение об удалении CHILD_SA, она должна передать другой стороне элемент Delete для уведомления об удалении. Это может быть похоже на тайм-аут для IKE_SA. Закрытие IKE_SA ведет к неявному закрытию всех связанных CHILD_SA. В этом случае конечной точке IKE следует передать элемент Delete, показывающий удаление IKE_SA.

2.5. Номера версий и совместимость

В этом документе описывается версия 2.0 протокола IKE — старшая часть версии имеет номер 2, а младшая — 0. Очевидно, что некоторые реализации захотят поддерживать версии 1.0 и 2.0, а в будущем и другие версии.

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

Если конечная точка получает сообщение с большим (чем у нее) значением старшей части номера версии, она должна отбросить такое сообщение; следует также передать в ответ неидентифицированное уведомление, содержащее поддерживаемое значение старшей части номера версии. Если конечная точка поддерживает версию со старшей частью n и m, она должна также поддерживать все версии между n и m. Если такая точка получает сообщение поддерживаемой версии, она должна отвечать сообщением той же версии. Для предотвращения ситуаций, когда пара узлов использует старшуу часть номера версии меньше максимально поддерживаемого обоими узлами номера, в IKE используется флаг, показывающий, что узел способен поддерживать больший номер версии.

Таким образом, старшая часть номера версии в заголовке IKE показывает номер версии для данного сообщения, а не номер версии, поддерживаемой отправителем. Если инициатор способен поддерживать версии n, n+1 и n+2, а отвечающая сторона поддерживает версии n и n+1, они согласуют использование версии n+1, а инициатор будет устанавливать флаг способности поддерживать более высокую версию. Если узлы по ошибке (или в результате активной атаки) согласуют использование версии n, тогда оба узла будут указывать поддержку более высокой версии. В этом случае они должны разорвать соединение и организовать его заново с использованием версии n+1.

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

Для обеспечения совместимости с более новыми версиями во всех резервных полях реализации версии 2.0 должны устанавливать значение 0, а при получении сообщений такие реализации должны игнорировать содержимое резервных полей (будьте консервативными при передаче и либеральными при приеме). В результате новые версии протокола смогут использовать резервные поля так, что их значения будут игнорироваться реализациями, не понимающими таких полей. Аналогично, типы данных, которые не определены, являются резервными; реализации версии 2.0 должны пропускать такие элементы данных, игнорируя их содержимое.

IKEv2 добавляет флаг «критичности» (critical) к каждому заголовку данных для более гибкой совместимости с грядущими версиями. Если флаг critical установлен, а тип данных нераспознан, сообщение должно быть отвергнуто, а отклик на запрос IKE, включающий эти данные, должен включать элемент Notify UNSUPPORTED_CRITICAL_PAYLOAD, показывающий прием нераспознанных критичных данных. Если флаг критичности не установлен, нераспознанный элемент должен игнорироваться.

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

2.6. Cookie

Термин cookies, введенный Karn и Simpson [RFC2522] в Photuris — раннем варианте системы управления ключами IPsec, продолжает использоваться до настоящего времени. Фиксированный заголовок протокола управления ключами и защищенными связями Internet (ISAKMP) [MSST98] включает два восьмиоктетных поля cookies и этот синтаксис используется в IKEv1 и IKEv2, хотя в последнем эти поля обозначаются, как IKE SPI, и имеется новое отдельное поле в элементе Notify, которое сохраняет значение cookie.

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

В отличие от ESP и AH, где только значение SPI для получателя появляется в заголовке пакета, в IKE каждое сообщение содержит также SPI отправителя. Поскольку значение SPI, выбранное исходным инициатором IKE_SA, всегда передается первым, конечная точка со множеством открытых IKE_SA, которая хочет найти подходящую IKE_SA по выбранному для нее значению SPI, должна просматривать значение флага I (инициатор) в заголовке для определения где искать — в первой или второй группе из 8 октетов.

В первом сообщении начального обмена IKE инициатор не знает значение SPI отвечающей стороны и будет, следовательно, помещать в это поле нулевое значение.

Возможной атакой на IKE является истощение ресурсов на хранение состояний и ресурсов CPU, когда объект атаки в лавинном режиме получает запросы на организацию сессий с подставных адресов IP. Воздействие таких атак можно снизить, если реализация отвечающей стороны по минимуму использует CPU и не фиксирует состояния SA до того, как узнает, что инициатор может получать пакеты по адресу, указанному в запросе. Для решения этой задачи ответчику следует при обнаружении большого числа полуоткрытых IKE_SA отвергать стартовые сообщения IKE, если они не содержат элемента Notify типа COOKIE. Взамен ответчику следует передавать в качестве отклика незащищенное сообщение IKE и включать в него COOKIE Notify с данными cookie для возврата. Инициатор, получивший такой отклик, должен повторить IKE_SA_INIT с элементом Notify типа COOKIE, содержащим предложенные ответчиком данные cookie в качестве первого элемента, сохраняя остальные элементы данных. Начальный обмен в таком случае будет иметь вид:

 Инициатор                           Ответчик
-----------                         ----------
 HDR(A,0), SAi1, KEi, Ni   -->
                           <-- HDR(A,0), N(COOKIE)
 HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
                           <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
    AUTH, SAi2, TSi, TSr}  -->
                           <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                                          SAr2, TSi, TSr}

Два первых сообщения не оказывают влияния на состояние инициатора и ответчика за исключением обмена cookie. В частности, порядковые номера в четырех первых сообщениях будут иметь нулевые значения, а в двух последних сообщениях приведенного примера номера будут иметь значение 1. «A» обозначает значение SPI, присвоенное инициатором, а «B» — значение, присвоенное ответчиком.

Реализации IKE следует поддерживать генерацию cookie ответчиком так, чтобы не требовалось сохранять какое-либо состояние для проверки корректности cookie при получении второго сообщения IKE_SA_INIT. Выбор алгоритма и используемый для cookie синтаксис не оказывают влияния на интероперабельность, поэтому не задаются данной спецификацией. Ниже приведен пример использования cookie конечной точкой для частичной защиты от DoS-атак. Хорошим способом реализации такой защиты является установка ответчиком cookie по следующему алгоритму:

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

где <secret> — случайное значение, известное только ответчику и периодически сменяемое, | указывает конкатенацию. Значение <VersionIDofSecret> следует менять всякий раз при смене <secret>. Значение cookie может быть рассчитано заново при получении IKE_SA_INIT второй раз и полученное значение сравнивается со значением cookie в принятом сообщении. Если значения совпадают, ответчик знает, что значение cookie было создано после замены <secret> и значение IPi должно совпадать с адресом отправителя, полученным в первом сообщении. Включение SPIi в расчет обеспечивает создание различных значений cookie для случаев, когда множество IKE_SA создается одновременно (предполагается, что инициаторы устанавливают уникальные значения SPIi). Включение в хэш значения Ni не позволяет атакующему, который увидел только сообщение 2, корректно подменить сообщение 3.

Если значение <secret> меняется в процессе инициализации соединения, сообщение IKE_SA_INIT может быть возвращено с отличным от текущего значением <VersionIDofSecret>. Ответчик в таком случае может отвергнуть сообщение, передавая другой отклик с новым значением cookie, или может сохранять старое значение <secret> на короткое время после его замены и принимать cookie, рассчитанные с использованием этого значения. Ответчику не следует воспринимать cookie неограниченно долго после смены <secret>, поскольку это будет нарушать часть защиты от DoS-атак. Ответчику следует менять значение <secret> достаточно часто, особенно во время атак.

2.7. Согласование криптоалгоритма

Элемент данных типа SA показывает предложения в части выбора протоколов IPsec (IKE, ESP и/или AH) для SA, а также криптографических алгоритмов, связанных с каждым протоколом.

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

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

  • Каждое предложение включает, по крайней мере, один протокол. Если предложение принимается элемент SA в отклике должен содержать те же протоколоы в том же порядке, как они были указаны в предложении. Ответчик должен принять одно из предложений или отвергнуть все предложения и возвратить сообщение об ошибке (Например, если предложение включает протоколы ESP и AH и это предложение принимается, оба протокола ESP и AH должны восприниматься. Если ESP и AH включены в разные предложения, ответчик должен принять только один из этих протоколов).
  • Каждый предлагаемый протокол IPsec содержит, по крайней мере, одно преобразование. Каждое преобразование включает тип преобазования. Принимаемые криптографические наборы должны содержать в точности одно преобразование каждого типа, включенного в предложение. Например, если предложение ESP включает преобразования ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES с размером ключа 256, AUTH_HMAC_MD5 и AUTH_HMAC_SHA, принятый набор должен включать одно преобразование ENCR_ и одно преобразование AUTH_. Таким образом, возможно шесть комбинаций.

Поскольку инициатор передает свое значение Diffie-Hellman в сообщении IKE_SA_INIT, он должен угадать группу Diffie-Hellman, которую ответчик выберет из списка поддерживаемых групп. Если выбор инициатора окажется ошибочным, ответчик будет возвращать элемент данных Notify типа INVALID_KE_PAYLOAD, показывающий выбранную группу. В таком случае инициатор должен повторить запрос IKE_SA_INIT с указанием корректной группы Diffie-Hellman. Инициатор должен снова предложить полный набор допустимых криптографических наборов, поскольку сообщение с отказом было передано без идентификации. Если этого не делать, активный атакующий сможет принудить конечные точки к выбору наиболее слабого криптографического набора из числа поддерживаемых обеими сторонами.

2.8. Смена ключей

Защищенные связи IKE, ESP и AH используют секретные ключи, которые следует применять в течение ограниченного периода времени для защиты ограниченного объема данных. Эти требования ограничивают срок существования защищенных связей. Когда время жизни защищенной связи заканчивается, дальнейшее использование такой связи недопустимо. При необходимости может быть организована новая защищенная связь. Повторная организация защищенной связи при завершении срока существования последней называется сменой ключей (rekeying).

Для того, чтобы сохранить возможность создания реализаций IPsec с минимальным набором возможностей, смена ключей SA без повторной организации IKE_SA целиком является необязательной. Реализация может отвергать все запросы CREATE_CHILD_SA в IKE_SA. Если срок жизни SA закончился или близок к завершению и попытки смены ключей с использованием описанных здесь механизмов не дали положительного результата, реализация должна закрыть IKE_SA и все дочерние CHILD_SA, а после этого может организовать новые связи. Реализациям следует поддерживать замену ключей для SA, поскольку это обеспечивает повышение производительности и снижение числа пакетов, теряемых в переходный период.

Для смены ключей CHILD_SA в существующей IKE_SA создается новая, эквивалентная SA (см. параграф 2.17 ниже) и после создания старая связь удаляется. Для смены ключей IKE_SA создается новая, эквивалентная IKE_SA (см. параграф 2.18 ниже) с партнером, который в старой IKE_SA совместно использовался в CREATE_CHILD_SA. Созданная таким путем IKE_SA наследует все CHILD_SA исходной in-place. Используется новая IKE_SA для всех управляющих сообщений, требуемых для поддержки CHILD_SA, созданных старой IKE_SA, после чего старая IKE_SA удаляется. Элемент данных Delete для удаления самой связи должен быть последним запросом, передаваемым через старую IKE_SA.

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

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

Если политика обеих сторон в части времени жизни совпадает, они могут ввести запросы на смену ключей одновременно (это приведет к созданию избыточных SA). Для снижения вероятности такого события следует использовать вариации периода смены ключей (при получении уведомления о необходимости замены ключей вносится случайная задержка).

Такая форма смены ключей может приводить к временному существованию множества похожих SA между одной парой узлов. При наличии двух SA, подходящих для получения пакетов, узел должен воспринимать входящие пакеты из обеих SA. Если при таком конфиликте создаются избыточные SA, связь, имеющую наименьшее из четырех используемых в этих двух обмена значений nonce, следует закрыть (конечной точке, которая создала эту связь).

Отметим, что существование параллельных SA с одинаковым трафиком между парой конечных точек разрешено в IKEv2 осознанно. Одной из причин этого является поддержка различий в качестве обслуживания трафика (QoS) между SA (см. [RFC2474], [RFC2475] и параграф 4.1 в [RFC2983]). Следовательно, в отличие от IKEv1, комбинация конечных точек и селекторов трафика может не быть уникальным идентификатором SA между парой точек, поэтому принятое при смене ключей в IKEv1 эвристическое удаление SA на основе совпадения селекторов трафика не следует использовать.

Узлу, который инициировал SA при досрочной земене ключей, следует удалить земененную SA после создания новой.

Существуют интервалы времени (в частности, в присутствии потерь пакетов), когда конечные точки могут по разному трактовать состояние SA. Отвечающая на CREATE_CHILD_SA сторона должна быть готова к восприятию сообщений через SA до передачи своего отклика на запрос создания связи, поэтому здесь для инициатора не возникает неоднозначности. Инициатор может начать передачу в SA сразу после обработки отклика. Иницииатор, однако, не может принимать через новую SA до получения и обработки отклика на свой запрос CREATE_CHILD_SA. Как, в таком случае, ответчик может узнать о возможности начать передачу в новую SA?

С точки зрения технической корректности и интероперабельности ответчик может начать передачу через SA, как только он отправит свой отклик на запрос CREATE_CHILD_SA. Однако в некоторых случаях это может привести к неоправданному отбрасыванию пакетов, поэтому реализация может принять решение о задержке такой передачи.

Ответчик может быть уверен в том, что инициатор готов получать сообщения через SA, если (1) он получил криптографически корректное сообщение через новую SA или (2) новая SA создана при замене ключей для существующей SA и был получен запрос IKE на закрытие земененной SA. При смене ключей SA ответчику следует продолжать передачу сообщений через старую SA, пока не будет выполнено какое-либо из приведенных выше условий. При создании новой SA ответчик может отложить передачу сообщений через нее до получения сообщения через нее или завершения времени ожидания. Если инициатор получает сообщение в SA, для которой он еще не получил отклика на свой запрос CREATE_CHILD_SA, ему следует интерпретировать это событие, как потерю пакетов, и передать запрос CREATE_CHILD_SA повторно. Инициатор может передать бутафорское (dummy) сообщение через новую SA, если у него нет сообщений в очереди, чтобы уведомить ответчика о своей готовности к приему сообщений.

2.9. Согласование селекторов трафика

Когда полученный поддерживающей RFC4301 системой IPsec пакет IP соответствует «селектору защиты» в соответствии с SPD, подсистема должна защитить пакет с использованием IPsec. Если SA еще не существует, ее создание является задачей IKE. Поддержка SPD в системе выходит за пределы IKE (см. [PFKEY] в качестве примера протокола), хотя некоторые реализации могут обновлять свои SPD в контакте с работающим IKE (см., для примера, сценарий 1.1.3).

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

В каждом из сообщений обмена, создающего пару CHILD_SA, появляется два элемента TS. Каждый из TS содержит один или множество селекторов трафика. Каждый селектор состоит из диапазона адресов (IPv4 или IPv6), диапазона портов и идентификатора протокола IP. В поддержку сценария, описанного в параграфе 1.1.3, инициатор может запросить у отвечающей стороны выделение адреса IP с его кратким описанием (что это?).

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

Первый из двух элементов TS называют TSi, а второй — TSr. TSi задает одрес отправителя трафика, пересылаемого от инициатора (или адрес получателя трафика, пересылаемого инициатору) пары CHILD_SA. TSr указывает адрес получателя трафика, пересылаемого ответчика (или адрес отправителя трафика, пересылаемого от ответчика) пары CHILD_SA. Например, если исходный инициатор запрашивает создание пары CHILD_SA и хочет туннелировать весь трафик из подсети 192.0.1.* на своей стороне в подсеть 192.0.2.* на стороне ответчика, инициатор будет включать один селектор трафика в каждый элемент TS. TSi будет задавать диапазон адресов 192.0.1.0 - 92.0.1.255, а TSr — диапазон 192.0.2.0 - 192.0.2.255. Предположим, что предложение будет принято ответчиком — тогда он будет передавать обратно идентичные элементы TS.

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

Политика отвечающей стороны может содержать множество меньших диапазонов, охватываемое предложенным инициатором селектором трафика, причем политика требует передачи трафика для этих диапазонов через разные SA. Продолжим использование приведенных выше для примера адресов. Ответчик может иметь политику, которая позволяет туннелировать эти адреса в направлении инициатора и от него, но может требовать, чтобы для каждой пары адресов независимо согласовывалась CHILD_SA. Если инициатор генерирует свой запрос в ответ на пакет с адреса 192.0.1.43, направленный по адресу 192.0.2.123, у ответчика не будет способа определить, какую пару адресов следует включить в этот туннель и он будет пытаться угадать или отбросить запрос со статусом SINGLE_PAIR_REQUIRED.

Чтобы позволить ответчику выбрать подходящий диапазон в том случае, когда инициатор запрашивает SA в результате получения пакета данных, инициатору следует включить в качестве первого селектора трафика в каждом элементе Tsi и TSr очень специфичный селектор трафика, включающий адреса в пакете, вызвывшем запрос. В нашем примере инициатор будет включать в TSi лва селектора трафика — первый будет содержать диапазон адресов 192.0.1.43 — 192.0.1.43, а также порт отправителя и протокол IP из пакета, а второй — диапазон 192.0.1.0 — 192.0.1.255 со всеми портами и протоколами. Инициатор будет также включать два селектора трафика в TSr.

Если политика отвечающей стороны не позволяет принять весь набор селекторов трафика из запроса инициатора, но позволяет принять первый селектор TSi и TSr, ответчик должен сузить селекторы трафика до подмножества, включающего первый выбор инициатора. В приведенном примере ответчик может возвратить TSi 192.0.1.43 — 192.0.1.43 с поддержкой всех портов и протоколов IP.

Если инициатор создает CHILD_SA пару не в ответ на получение пакета, а, например, при старте, может не быть предпочтений в части адресов для начального туннеля. В таких случаях первые значения TSi и TSr могут задавать диапазоны, а не конкретные адреса и ответчик выбирает подходящее подмножество указанных инициатором TSi и TSr. Если ответчика устраивает несколько подмножеств, которые нельзя объединить, ответчик должен принять некое подмножество и может включить в сообщение элемент Notify типа ADDITIONAL_TS_POSSIBLE для индикации инициатору возможности повтора. Такая ситуация возникает только в тех случаях, когда конфигурации инициатора и ответчика различаются. Если инициатор и ответчик согласовали гранулярность туннелей, инициатор никогда не будет запрашивать более широкий туннель, нежели приемлет отвечающая сторона. Такие расхождения в конфигурационных параметрах следует заносить в системный журнал ошибок.

2.10. Элементы nonce

Каждое сообщение IKE_SA_INIT содержит nonce. Эти nonce используются в качестве входной информации для криптографических функций. Запросы CREATE_CHILD_SA и отклики CREATE_CHILD_SA также включают nonce. Эти nonce используются для повышения эффективности метода, используемого при получении ключей для CHILD_SA, обеспечения достаточно высокого уровня случайности для псевдослучайных битов, получаемых из ключа Diffie-Hellman. Элементы nonce, используемые в IKEv2, должны выбираться случайным образом, должны иметь размер не менее 128 битов и не менее половины размера ключа согласованной prf. При использовании некого общего источника случайных чисел для ключей и nonce нужно быть осторожными, чтобы использование nonce не привело к компрометации ключей.

2.11. Использование адресов и портов

IKE работает по протоколу UDP через порты 500 и 4500, неявно устанавливая связи ESP и AH для тех же адресов IP. Адреса IP и номера портов во внешнем заголовке не защищаются криптографически и протокол IKE может работать даже через устройства трансляуции адресов (NAT). Реализация должна воспринимать входящие запросы даже из портов с номерами, отличными от 500 или 4500 и должна отвечать на адрес и порт, с которых был получен запрос. Реализация должна указать в отклике адрес и порт, через которые был принят запрос, в качестве адреса и порта отправителя. Функции IKE идентичны для протоколов IPv4 и IPv6.

2.12. Многократное использование экспоненциалов Diffie-Hellman

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

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

Поскольку расчет экспоненциалов Diffie-Hellman требует значительных вычислительных ресурсов, конечные точки могут получать преимущества в результате использования этих экспоненциалов для организации множества соединений. Существует несколько вариантов обоснованной стратегии многократного использования экспоненциалов. Конечная точка выбирает новый экспоненциал периодически, хотя это может приводить к снижению уровня защиты. Другим вариантом является сохранение информации об использованных для каждого соединения экспоненциалов и удалять связанную с экспоненциалом информацию только после закрытия соответствующего соединения. Это позволяет использовать экспоненциалы многократно без снижения уровня защиты, но за счет поддержки дополнительной информации о состоянии.

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

2.13. Материал для генерации ключей

В контексте IKE_SA согласуются четыре криптографических алгоритма — алгоритм шифрования, алгоритм защиты целостности, группа Diffie-Hellman и псевдослучайная функция (prf). Последняя используется при создании ключевого материала для всех криптографических алгоритмов, используемых как в IKE_SA, так и в дочерних CHILD_SA.

Мы полагаем, что каждый алгоритм шифрования и защиты целостности использует ключ фиксированного размера и случайно выбранное значение фиксированного размера может служить подходящим ключом. Для алгоритмов, которые воспринимают ключи переменного размера, должен указываться фиксированный размер ключа в процессе согласования криптографических преобразований. Для алгоритмов, в которых не все значения являются допустимыми ключами (например, DES или 3DES с четностью ключа) криптографическим преобразованием должен задаваться алгоритм создания ключей из произвольных значений. Для функций защиты целостности на основе кода HMAC фиксированным размером ключа является размер вывода нижележащей функции хэширования. Когда функций prf принимает ключ переменной длины и данные переменной длины, давая результат фиксированного размера (например, при использовании HMAC), применяются формулы из этого документа. Когда ключ для prf имеет фиксированный размер, представленные в качестве ключа данные усекаются или дополняются нулями, если приведенная ниже формула не задает специальной обработки.

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

   prf+ (K,S) = T1 | T2 | T3 | T4 | ...
где:
   T1 = prf (K, S | 0x01)
   T2 = prf (K, T1 | S | 0x02)
   T3 = prf (K, T2 | S | 0x03)
   T4 = prf (K, T3 | S | 0x04)

и т. д., пока не будет достаточно материала для расчета всех требуемых ключей. Ключи берутся из выходной строки без учета границ (например, если нужен 256-битовый ключ AES и 160-битовый ключ HMAC, а функция prf дает на выходе 160 битов, ключ AES будет взят из T1 и начальной части T2, а ключ HMAC возьмет остаток T2 и начало T3).

Константа, добавляемая в конец каждой строки на входе prf, представляет собой один октет. Использование функции prf+ в данном документе не выходит за пределы 255-кратного увеличения размера результата prf.

2.14. Генерация ключевого материала для IKE_SA

Для расчета разделяемых ключей сначала вычисляется значение SKEYSEED на основе nonce из обмена IKE_SA_INIT и разделяемого секрета Diffie-Hellman созданного при этом обмене. Значение SKEYSEED используется для расчета семи других секретов — SK_d применяется при создании новых ключей для CHILD_SA, создаваемых в данной IKE_SA; SK_ai и SK_ar применяются в качестве ключа алгоритма защиты целостности для идентификации сомпонент сообщений в последующих обменах; SK_ei и SK_er применяются для шифрования (и дешифровки) всех последующих обменов; SK_pi и SK_pr применяются при генерации элемента данных AUTH.

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

SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
          (SKEYSEED, Ni | Nr | SPIi | SPIr )

(левая часть второго уравнения показывает, что значения SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi и SK_pr берутся в указанном порядке из битов результата prf+). Параметр g^ir является разделяемым секретом из краткосрочного обмена Diffie-Hellman. Значение g^ir представляется строкой октетов в формате big endian с дополнением при необходимости нулями для выполнения требований по размеру модуля. Ni и Nr — значения элементов nonce, извлеченные из заголовков. Если согласованная функция prf принимает ключ фиксированного размера, а суммарная длина Ni и Nr превышает нужное значения, берется половина (первая) битов из Ni и половина (первая) битов из Nr.

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

2.15. Идентификация IKE_SA

Если не используется расширяемая идентификация (см. параграф 2.16), партнеры идентифицируют себя посредством подписи (или MAC с использованием разделяемого секрета в качестве ключа) для блока данных. Для ответчика подписываемые данные начинаются с первого октета первого SPI в заголовке второго сообщения и заканчиваются последним октетом последнего элемента данных во втором сообщениии. В конце к этому добавляется (с целью расчета подписи) значение nonce Ni от инициатора (просто значение, а не содержащий его элемент данных) и значение prf(SK_pr,IDr'), где IDr' — элемент ID ответчика без фиксированного заголовка. Отметим, что ни одно из значений Ni и prf(SK_pr,IDr') не передается. Подобно этому инициатор подписывает первое сообщение, начиная с первого октета первого SPI в заголовке и заканчивая последним октетом последнего элемента данных. В конце к этому добавляется (для расчета подписи) значение nonce Nr от ответчика и значение prf(SK_pi,IDi'). В приведенных выше расчетах IDi' и IDr' являются полными элементами данных ID без фиксированного заголовка. Для защиты обмена критично наличие подписи каждой стороны для nonce другой стороны.

Отметим, что подписываются все элементы данных, включая и те, которые не определены в этом документе. Если перевое сообщение в обмене передается дважды (второй раз с cookie ответчика и/или другой группой Diffie-Hellman), подписывается вторая версия сообщения.

В дополнение к спазанному сообщения 3 и 4 могут включать сертификат или цепочку сертификатов, обеспечивающие очевидность того, что использованные для расчета цифровой подписи ключ относится к имени в элементе данных ID. Сигнатрура или MAC будет рассчитываться с использованием алгоритмов, диктуемых типом ключа, используемого подписывающим, и задается полем Auth Method в элементе данных Authentication. Здесь не задается использования одного криптографического алгоритма для инициатора и ответчика. Выбор криптографического алгоритма зависит от типа ключа, который имеет каждая из сторон. В частности, инициатор может использовать разделяемый ключ, а ответчик может иметь открытый ключ подписи и сертификат. Обычной (но не обязательной) практикой при наличии разделяемого ключа является использование этого ключа для идентификации в обоих направлениях. Отметим, что общепринято, хотя и не обеспечивает достаточной защиты, использование разделяемого ключа, созданного исключитьельно на базе выбранного пользователем пароля без использования других источников случайных данных.

Такая защита недостаточна, поскольку пользовательские пароли с очевидностью не являются достаточно непредсказуемыми для устойчивости к атакам по словарю, следовательно данный метод от таких атак не защищает (приложениям, использующим идентификацию по паролю на этапе загрузки и IKE_SA, следует применять метод идентификации, описанный в параграфе 2.16, который предназначен для защиты от атак по словарю в режиме off-line). Разделяемый (pre-shared) ключ следует делать столь же непредсказуемым, как наиболее сильный из согласуемых ключей. В случае pre-shared-ключа значение AUTH вычисляется, как:

AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)

где сторока «Key Pad for IKEv2» представляет собой 17 символов ASCII без завершающего нуля. Разделяемый секрет (shared secret) ) может иметь переменный размер. Строка заполнения добавляется для того, чтобы при использовании разделяемого секрета на основе пароля реализации IKE не требовалось сохранять пароль в открытом виде, а можно было хранить его в форме prf(Shared Secret,"Key Pad for IKEv2"), которая не будет использоваться в качестве пароля для отличных от IKEv2 протоколов. Как отмечено выше, создание разделяемого ключа на основе пароля не обеспечивает должной защиты. Такая конструкция отмечена лишь потому, что многие люди ей пользуются до сих пор. Интерфейс управления, через который обеспечивается Shared Secret, должен принимать стороки символов ASCII размером, по крайней мере, 64 октета; добавление завершающего нуля перед использованием строки в качестве разделяемого секрета недопустимо. Интерфейс управления должен также воспринимать разделяемый секрет в шестнадцатеричном (HEX) представлении. Интерфейс управления может воспринимать другие варианты кодировки строки, если указан алгоритм преобразования в двоичную строку. Если согласованная функция prf принимает ключ фиксированного размера, разделяемый секрет должен иметь такой же размер.

2.16. Методы EAP

В дополнение к идентификаци на основе подписей с открытыми ключами и разделяемыми секретами IKE поддерживает идентификацию с использованием методов, определенных в RFC 3748, Расширяемый протокол идентификации [EAP]. Обычно эти методы являются асимметричными (они разработаны для идентификации пользователей на сервере) и могут не быть обоюдными. По это причине упомянутые протоколы обычно используются для идентификации инициатора на отвечающей стороне и должны применяться в комбинации с идентификацией ответчика инициатору по цифровой подписи на основе открытого ключа. Эти методы часто ассоциируются с механизмами, которые называют «унаследованной идентификацией» (Legacy Authentication).

Хотя в этом документе [EAP] упоминается, прежде всего, в плане добавления в будущем новых методов без обновления данной спецификации, некоторые простые варианты описаны здесь и в параграфе 3.16. [EAP] определяет протокол идентификации с переменным числом сообщений. Расширяемая идентификация реализуется в IKE, как дополнительные обмены IKE_AUTH, которые должны быть выполнены для инициализации IKE_SA.

Инициатор показывает свое намерение использовать расширяемую идентификацию, пропуская элемент AUTH в сообщении 3. За счет включения элемента Idi при отсутствии AUTH инициатор объявляет свою идентификацию, но доказывает ее. Если ответчик желает использовать расширяемую идентификауцию, он будет включать элемент EAP в сообщение 4 и откладывает передачу SAr2, TSi и Tsr, пока идентификаци инициатора не будет завершена в последующем обмене IKE_AUTH. В варианте минимально расширяемой идентификации организация начальной SA будет иметь вид:

 Инициатор                          Ответчик
-----------                        ----------
 HDR, SAi1, KEi, Ni         -->
                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]
 HDR, SK {IDi, [CERTREQ,] [IDr,]
          SAi2, TSi, TSr}   -->
                            <--    HDR, SK {IDr, [CERT,] AUTH, EAP}
 HDR, SK {EAP}              -->
                            <--    HDR, SK {EAP (success)}
 HDR, SK {AUTH}             -->
                            <--   HDR, SK {AUTH, SAr2, TSi, TSr}

Для методов EAP, которые создают разделяемый ключ в качестве побочного продкта идентификации, этот ключ должен использоваться инициатором и ответчиком для генерации элементов данных AUTH в сообщениях 7 и 8 с использованием синтаксиса для разделяемых секретов, описанного в параграфе 2.15. Разделяемый ключ от EAP в спецификации EAP называется полем MSK. Разделяемый ключ, созданный в процессе обмена IKE, недопустимо использовать для иных целей.

Методы EAP, не создающие разделяемого ключа, использовать не следует, поскольку они подвержены многочисленным атакам MITM [EAPMITM] при использовании в других протоколах, не применяющих идентифицированные сервером туннели. Если используются методы EAP, не генерирующие разделяемого ключа, элементы данных AUTH в сообщениях 7 и 8 должны генерироваться с использованием SK_pi и SK_pr, соответственно.

Инициатору IKE_SA с использованием EAP следует поддерживать возможность расширения начального протокольного обмена по крайней мере до десяти обменов IKE_AUTH, если ответчик передает уведомления и/или провторяет приглашение к идентификации. После успешного завершения протокольного обмена, определенного выбранным методом идентификации EAP ответчик должен передать данные EAP, содержащие сообщение Success. Если при использовании выбранного метода идентификации возник отказ, ответчик должен передать данные EAP, содержащие сообщение Failure. Ответчик может в любой момент прервать обмен IKE путем передачи данных EAP с сообщением Failure.

При таком расширенном обмене элементы данных EAP AUTH должны включаться в два сообщения, следующие за собщением, содержащим EAP Success.

2.17. Материал для генерации ключей CHILD_SA

Одна связь CHILD_SA создается обменом IKE_AUTH, а дополнительные CHILD_SA могут создаваться в обменах CREATE_CHILD_SA. Ключевой материал для них создается следующим образом:

KEYMAT = prf+(SK_d, Ni | Nr)

Здесь Ni и Nr — nonce из обмена IKE_SA_INIT, если данный запрос является первым созданием CHILD_SA, или обновленные Ni и Nr из обмена CREATE_CHILD_SA при создании дополнительных связей.

Для обменов CREATE_CHILD_SA, включающих дополнительный обмен Diffie-Hellman, ключевой материал определяется следующим образом:

KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )

где g^ir (new) — разделяемый секрет из краткосрочного обмена Diffie-Hellman данного обмена CREATE_CHILD_SA (представляется, как строка октетов в формате big endian, дополненная нулями в старших битах при необходимости выравнивания размера по модулю).

Согласование одной CHILD_SA может приводить к созданию множества защищенных связей. Связи ESP и AH существуют попарно (по одной для каждого направления) и при использовании одновременно ESP и AH в одном согласовании CHILD_SA могут создаваться четыре SA.

Ключевой материал должен браться из KEYMAT в следующем порядке:

  • все ключи для SA, передающих данные от инициатора к ответчику, берутся до SA в обратном направлении;
  • если согласуется множество протоколов IPsec, ключевой материал для каждого из них берется в порядке появления протокольных заголовков в инкапсулированном пакете;
  • если один протокол имеет ключи для шифрования и идентификации, ключ шифрования берется из первых октетов KEYMAT, а ключ идентификации — из последующих.

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

2.18. Смена ключей IKE_SA с использованием обмена CREATE_CHILD_SA

Обмен CREATE_CHILD_SA можно использовать для смены ключей существующей связи IKE_SA (см. 2.8). Новые SPI инициатора и ответчика передаются в полях SPI. Элементы данных TS опускаются при смене ключей IKE_SA. SKEYSEED для новой IKE_SA рассчитывается с использованием SK_d из существующей IKE_SA:

SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)

где g^ir (new) — разделяемый секрет из краткосрочного обмена Diffie-Hellman данного обмена CREATE_CHILD_SA (представляется, как строка октетов в формате big endian, дополненная нулями в старших битах при необходимости выравнивания размера по модулю), а Ni и Nr — два значения nonce из любых заголовков.

Новая связь IKE_SA должна сбросить свои счетчики сообщений в 0.

SK_d, SK_ai, SK_ar, SK_ei и SK_er рассчитываются из SKEYSEED, как описано в параграфе 2.14.

2.19. Запрос внутреннего адреса удаленной сети

В наиболее распространенном сценарии с подключением конечной точки к защитному шлюзу конечной точке может потребоваться адрес IP из защищенной шлюзом сети; для такого адреса может также потребоваться динамическое выделение. Запрос на такой временный адрес может быть включен в любой запрос на создание CHILD_SA (включаяя неявный запрос в сообщении 3) с помощью элемента данных CP.

Эта функция обеспечивает выделение адреса для клиента IRAC, пытающегося организовать туннель в сеть, защищенную сервером удаленного доступа IRAS. Поскольку обмен IKE_AUTH создает связи IKE_SA и CHILD_SA, IRAC должен запрашивать контролируемый IRAS адрес (и, возможно, другую информацию о защищенной сети) в обмене IKE_AUTH. IRAS может предоставлять адрес для IRAC из любого числа источников адресов типа серверов DHCP/BOOTP или из собставенного блока адресов.

 Инициатор                          Ответчик
-----------                        ----------
 HDR, SK {IDi, [CERT,] [CERTREQ,]
  [IDr,] AUTH, CP(CFG_REQUEST),
  SAi2, TSi, TSr}              -->
                               <--   HDR, SK {IDr, [CERT,] AUTH,
                                      CP(CFG_REPLY), Sar2,
                                      TSi, TSr}

Во всех случаях элемент данных CP должен помещаться перед элементом SA. В вариациях протокола с множеством обменов IKE_AUTH элементы CP должны помещаться в сообщения, содержащие элементы SA.

Элемент CP(CFG_REQUEST) должен содержать по крайней мере атрибут INTERNAL_ADDRESS attribute (IPv4 или IPv6), но может включать любое число дополнительных атрибутов, которые инициатор пожелал получить в отклике. Ниже показан пример сообщения от инициатора к ответчику.

CP(CFG_REQUEST)=
  INTERNAL_ADDRESS(0.0.0.0)
  INTERNAL_NETMASK(0.0.0.0)
  INTERNAL_DNS(0.0.0.0)
TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

Примечание. Селекторы трафика TS содержат (протокол, диапазон портов, диапазон адресов).

Сообщение инициатору от ответчика:

CP(CFG_REPLY)=
  INTERNAL_ADDRESS(192.0.2.202)
  INTERNAL_NETMASK(255.255.255.0)
  INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

Все возвращаемые значения зависят от реализации. Как можно видеть из приведенного выше примера, IRAS может также передавать другие атрибуты, которые не были включены в CP(CFG_REQUEST) и могут игнорировать необязательные атрибуты, которые они не поддерживают.

Для ответчика недопустимо передавать CFG_REPLY, если не был до этого принят запрос CP(CFG_REQUEST) от инициатора, поскольку мы не хотим, чтобы IRAS выполнял ненужные просмотры конфигурации, если IRAC не может обработать REPLY. В тех случаях, когда конфигурация IRAS требует, использования CP для данного IDi, но IRAC не удалось передать CP(CFG_REQUEST), сервер IRAS должен отвергнуть запрос и прервать обмен IKE с возвратом ошибки FAILED_CP_REQUIRED.

2.20. Запрос версии партнера

An IKE peer wishing to inquire about the other peer's IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE_SA and first CHILD_SA have been created.

An IKE implementation MAY decline to give out version information prior to authentication or even after authentication to prevent trolling in case some implementation is known to have some security weakness. In that case, it MUST either return an empty string or no CP payload if CP is not supported.

 Инициатор                           Ответчик
-----------------------------       --------------------------
 HDR, SK{CP(CFG_REQUEST)}     -->
                              <--    HDR, SK{CP(CFG_REPLY)}
CP(CFG_REQUEST)=
  APPLICATION_VERSION("")
CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
  Inc.")

2.21. Обработка ошибок

При обработке IKE может происходить множество разных ошибок. Если принятый запрос имеет некорректный формат или неприемлем по соображениям политики (например, не соответствуют криптографические алгоритмы), отклик должен содержать элемент Notify, показывающий ошибку. Если ошибка произошла за пределами контекста запроса IKE (например, узел получает сообщения ESP на несуществующий SPI), узлу следует инициировать обмен INFORMATIONAL с элементом данных Notify, описывающим проблему.

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

Если узел получает сообщение в порт UDP с номером 500 или 4500 за пределами известного ему контекста IKE_SA (и это сообщение не является запросом на создание контекста), это может говорить о недавней аварии узла. Если сообщение отмечено, как отклик, узел может занести информацию о нем в журнал аудита, но отвечать на такое сообщение недопустимо. Если сообщение помечено, как запрос, отклик на него должен быть передан в адрес IP и порт, с которых запрос поступил, при этом значения IKE SPI и Message ID в отклике должны быть копиями этих полей из запроса. Недопустимо использовать для отклика криптографическую защиту и отклик должен содержать элемент Notify, показывающий INVALID_IKE_SPI.

Узлу, получившему такой незащищенный элемент Notify, недопустимо менять состояние существующих SA. Сообщение может быть обманным или может являться легитимного корреспондента, вовлеченного в передачу обманным путем. Узлу следует трактовать такое сообщение (а также сетевые сообщения типа ICMP destination unreachable), как намек о возможности проблем с SA для данного адреса IP, а также следует выполнить проверку жизненности для всех таких IKE_SA. Реализациям следует ограничивать частоту таких проверок для предотвращения возможности их использования для организации атак на службы.

Узел, получивший подозрительное сообщение с IP-адреса, с которым он имеет IKE_SA, может передать элемент данных IKE Notify в обмене IKE INFORMATIONAL через имеющуюся SA. Получателю недопустимо менять состояние каких-либо SA в результате приема такого сообщения, но следует записать событие в журнал аудита для упрощения диагностики. Узел должен ограничивать скорость передачи откликов на незащищенные сообщения.

2.22. Компрессия IPComp

Использование компрессии IP [IPCOMP] может быть согласовано на этапе создания CHILD_SA. Хотя сомпрессия IP включает дополнительный задоловок в каждом пакете и список параметров компрессии (CPI), виртуальная «связь с компрессией» не существует за пределами содержащей ее ESP или AH SA. «Связи с компрессией» исчезают при удалении соответствующей ESP или AH SA. Эти связи не упоминаются явно в элементах данных DELETE.

Согласование компрессии IP отделено от согласования криптографических параметров, связанных с CHILD_SA. Узел, запрашивающий создание CHILD_SA, может анонсировать поддержку одного или множества алгоритмов компрессии путем передачи одного или множества элементов Notify типа IPCOMP_SUPPORTED. Отлик может показывать приемлемость одного алгоритма компрессии с помощью элемента Notify типа IPCOMP_SUPPORTED. Такие элементы недопустимо включать в сообщения, не содержащие элементов SA.

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

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

2.23. Работа через NAT

Использование шлюзов с трансляцией сетевых адресов (NAT) является спорным вопросом. В этом параграфе кратко описаны такие шлюзы и их действия по отношению к трафику IKE. Многие враждебно относятся к NAT и считают, что не следует разрабатывать протоколы для улучшения работы через системы трансляции адресов. IKEv2 задает некоторые не вполне очевидные правила обработки для улучшения работы через NAT.

Основной причиной использования NAT является нехватка адресов IPv4. Узлы IP, находящиеся за шлюзами NAT используют адреса IP, которые не являются уникальными в глобальном масштабе и могут совпадать с адресами, которые применяются за другими шлюзами NAT. В общем случае узлы, расположенные за NAT, могут взаимодейтсвовать с другими узлами за тем же шлюзом NAT и узлами с уникальными в глобальном масштабе адресами, не не с узлами, расположенными за другим шлюзом NAT. Из этого правила есть ряд исключений. Когда узлы, расположенные за NAT, соединяются с узлами в реальной сети Internet, шлюз NAT «преобразует» (транслирует) IP-адрес отправителя, меняя его на адрес, который будет маршрутизироваться обратно на этот шлюз. Полученные из Internet сообщения «транслируются» шлюзом с заменой адреса получателя на внутренний адрес соответствующего конечного узла.

Система NAT разрабатывалась с учетом обеспечения прозрачности для оконечных узлов. Ни программы находящегося за NAT узла, ни узлы Internet не требуется менять для работы через NAT. Обеспечение такой прозрачности для обних протоколов сложнее, чем для других. Протоколы, включающие IP-адреса конечных точек в данные (не только в заголовки), будут сталкиваться с проблемами, пока шлюз NAT не начнет понимать протокол и соответствующим образом изменять данные в пакетах. Такое решение является изначально ненадежным, нарушает целостность сетевого уровня и часто приводит к возникновению трудно обнаруживаемых проблем.

Организация соединений IPsec через NAT вызывает определенные проблемы. Если соединение работает в транспортном режиме, изменение адресов IP в пакетах будет приводить к изменению контрольных сумм, которые NAT не сможет скорректировать, поскольку они криптографически защищены. Даже в туннельном режиме вознкают проблемы с маршрутизацией, поскольку прозрачная трансляция адресов в пакетах AH и ESP требует реализации в NAT специальной логики, которая по своей природе эвристична и ненадежна. По этим причинам IKEv2 использует инкапсуляцию пакетов IKE и ESP в UDP. Такой вариант слегка снижает эффективность, но проще для обработки в NAT. Кроме того, межсетевые экраны могут быть настроены на передачу трафика IPsec, инкапсулированного в UDP, но при этом блокировать ESP/AH и наоборот.

NAT обычно используется для трансляции портов TCP и UDP, наряду с адресами, и использования номеров портов из входящих пакетов для принятия решения об адресе локального узла, которому адресован пакет. По этой причине, хотя пакеты IKE должны отправляться через порт UDP с номером 500, необходимо принимать пакеты, исходящие из любого порта и отклики должны направляться в порт, из которого был получен запрос. Эти требования обусловлены тем, что номера портов могут меняться при прохождении пакетов через NAT. Аналогично, адреса IP конечных точек IKE обычно не включаются в элементы данных IKE, поскольку данные криптографически защищены и не могут прозрачно изменяться устройствами NAT.

Порт 4500 зарезервирован для инкапсуляции ESP и IKE в UDP. При работе через NAT в общем случае лучше передавать пакеты IKE через порт 4500, поскольку некотрые старые реализации NAT обрабатывают трафик IKE через порт 500 некорректно, пытаясь организовать прозрачное соединение IPsec между между конечными точками, которые сами по себе не поддерживают работу через NAT. Такие реализации NAT могут конфликтовать с прямым прохождением через NAT, описанным в этом документе, поэтому конечная точка IPsec, которая обнаружит NAT между собой и своим корреспондентом, должна передавать весь последующий трафик через порт 4500, который NAT не следует обрабатывать специальным способом (как это может происходить для порта 500).

Ниже перечислены специфические требования для прохождения через NAT [RFC3715]. Поддержка работы через NAT является необязательной. Приведенные в этом параграфе требования типа «должно» относятся только к реализациям, поддерживающим работу через NAT.

  • IKE должен прослушивать порты 4500 и 500. IKE должен отвечать по адресам IP и портам, с которых были приняты пакеты.
  • Как инициатор, так и ответчик IKE должны включать в свои пакеты IKE_SA_INIT элементы данных Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти элементы могут использоваться для детектирования наличия NAT между хостами и определения, какой из хостов находится за NAT. Эти элементы располагаются в пакетах IKE_SA_INIT после элементов Ni и Nr (перед необязательным элементом CERTREQ).
  • Если ни один из полученных элементов NAT_DETECTION_SOURCE_IP не соответствует хэшу IP-адреса и порта отправителя в заголовке IP содержащего элемент пакета, это означает, что другая сторона расположена за NAT (где-то на пути доставки адрес отправителя исходного пакета заменен на адрес устройства NAT). В таких случаях данной стороне следует разрешить динамическое обновление IP-адреса другой стороны, как описано ниже.
  • Если полученный элемент данных NAT_DETECTION_DESTINATION_IP не соответствует хэшу IP-адреса и номера порта получателя из заголовка IP пакета, содержащего элемент данных, это означает, что другая сторона расположена за NAT. В этом случае локальной стороне следует начать передачу пакетов keepalive, как описано в [Hutt05].
  • Инициатор IKE должен проверить наличие этих элементов данных и при несоответствии адресам во внешнем пакете должен туннелировать все будущие пакеты IKE и ESP, связанные с данной IKE_SA через порт UDP 4500.
  • При туннелировании пакетов IKE через порт UDP 4500 заголовок IKE имеет четыре октета нулей, следующих сразу после заголовка UDP. При туннелировании пакетов ESP через порт UDP 4500 заголовок ESP следует сразу после заголовка UDP. Поскольку первые четыре байта заголовка ESP содержат значение SPI, которое не может быть нулевым, это позволяет всегда легко различать сообщения ESP и IKE.
  • Исходные IP-адреса отправителя и получателя, которые нужны в транспортном режиме для расчета контрольной суммы пакетов TCP и UDP (см. [Hutt05]), извлекаются из селекторов трафика, связанных с этим обменом. При работе через NAT селекторы трафика должны содержать в точности один адрес IP, который используется в качестве исходного адреса IP.
  • В некоторых случаях устройство NAT может удалить отображения, которые продолжают использоваться (например, интервал keepalive слишком велик или устройство NAT перезагружено). Для восстановления в таких случаях хостам, которые не расположены за NAT, следует передавать все пакеты (включая повторные) в адрес IP и порт из последнего корректно идентифицированного пакета от другой стороны (т. е., динамически обновлять адрес). Расположенному за NAT хосту не следует делать так, поскольку это будет открывать возможность организации DoS-атак. Любой идентифицированный пакет IKE или любой идентифицированный пакет ESP, инкапсулированный в UDP, можно использовать для детектирования смены IP-адреса и номера порта. Отметим, что похожие, но, возможно, не совсем идентичные, действия требуется выполнять при работе IKE через Mobile IP, но этот вопрос выходит за пределы данного документа.

2.24. Явные уведомления о перегрузке (ECN)

При развертывании туннелей IPsec в соответствии с исходной спецификацией [RFC2401], использование ECN во внешних заголовках IP было, по сути, невозможно, поскольку при екапсуляции туннеля индикаторы перегрузки ECN отбрасывались. Поддержка ECN для туннелей IPsec на базе IKEv1 требует множества режимов работы и согласований (см. [RFC3168]). IKEv2 упрощает ситуацию, вводя требование возможности использования ECN во внешних заголвках IP для всех IPsec SA в туннельном режиме, создаваемых IKEv2. В частности, точки инкапсуляции и декапсуляции туннельных SA, создаваемых IKEv2, должны поддерживать опцию полной функциональности ECN для туннелей, заданную в [RFC3168], а также должны реализовать инкапсуляцию и декапсуляцию в соответствии с [RFC4301] для предотвращения отбрасывания индикации перегрузки ECN.

3. Форматы заголовков и данных

3.1. Заголовок IKE

Сообщения IKE используют протокол UDP через порты 500 и/или 4500; передается по одному сообщению IKE в дейтаграмме UDP datagram. Информация от начала пакета до завершения заголовка UDP большей частью игнорируется; исключения составляют адреса IP и номера портов UDP в заголовках, которые сохраняются и используются для передачи ответных пакетов. При передаче через порт UDP 500 сообщение IKE начинается непосредственно после заголовка UDP. При передаче через порт UDP 4500 перед сообщением IKE помещается четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKE и не учитываются в размерах и контрольных суммах IKE. Каждое сообщение IKE начинается с заголовка IKE, обозначаемого в данном документе HDR. После заголовка следует один или множество элементов данных IKE, каждый из которых идентифицируется полем Next Payload в предыдущем элементе данных. Элементы данных обрабатываются в порядке их следования в сообщении IKE путем вызова соответствующей процедуры, согласно значению поля Next Payload в заголовке IKE, потом согласно значению Next Payload в первом элементе данных IKE и так далее, пока в поле Next Payload не будет обнаружено нулевое значение, показывающее отсутствие следующего элемента данных. При обнаружении элемента данных типа Encrypted этот элемент дешифруется и результат расшифровки разбирается, как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете и включать в зашифрованные элементы другие элементы типа Encrypted недопустимо.

Значение Recipient SPI в заголовке идентифицирует экземпляр защищенной связи IKE. Следовательно, один экземпляр IKE может мультиплексровать различные сессии с множеством партнеров.

Многооктетные поля, представляющие собой целые числа используют сетевой порядок байтов (или big endian — старший байт сначала).

Рисунок 4 показывает формат заголовка IKE.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Initiator's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Responder's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          Message ID                           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                            Length                             !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 4: Формат заголовка IKE
  • Initiator's SPI (8 октетов) — значение, выбранное инициатором для уникальной идентификации защищенной связи IKE. Нулевое значение недопустимо.
  • Responder's SPI (8 октетов) — значение, выбранное ответчиком для уникальной идентификации защищенной связи IKE. Это значение должно быть нулевым в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений нудлевое значение недопустимо.
  • Next Payload (1 октет) — показывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.
  • Major Version (4 бита) — задает старшую часть номера версии используемого протокола IKE. Реализации на основе данной версии IKE, должны устанавливать Major Version=2. Реализации, основанные на предыдущих версиях IKE и ISAKMP, должны устанавливать Major Version=1. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим 2.
  • Minor Version (4 бита) — задает младшую часть номера версии IKE. Реализации на основе этого документа должны устанавливать Minor Version = 0 и игнорировать младшую часть номера в принимаемых сообщениях.
  • Exchange Type (1 октет) — Показывает тип обмена, который будет использоваться. Тип ограничивает набор элементов данных в каждом сообщении и порядок сообщений в обмене. Типы показаны в таблице.
    Тип обмена Значение
    Резерв 0-33
    IKE_SA_INIT 34
    IKE_AUTH 35
    CREATE_CHILD_SA 36
    INFORMATIONAL 37
    Резерв IANA 38-239
    Резерв для частного использования 240-255
  • Flags (1 октет) — показывает специфические опции, установленные для сообщения. Наличие опции указывается установкой соответствующего флага. Биты флагов начинаются с младшего, т. е. Бит 0 является младшим битом октета Flags. В приведенном ниже описании термин «установлен» означает значение бита 1, а термин «сброшен» — значение 0.
    • X(резерв) (биты 0-2) — эти биты должны сбрасываться при передаче и игнорироваться на приеме.
    • I(nitiator) (бит 3 поля Flags) — этот бит должен устанавливаться в сообщениях, передаваемых исходным инициатором IKE_SA, и должен сбрасываться в сообщениях, передаваемых исходным ответчиком. Этот бит позволяет получателю определить, какие восемь октетов SPI были созданы получателем.
    • V(ersion) (бит 4 поля Flags) — этот флаг показывает, что передающий узел способен поддерживать большее значение старшей части номера версии, нежели указано в поле Major Version. Реализации IKEv2 должны сбрасывать этот бит при передаче и игнорировать его во входящих сообщениях.
    • R(esponse) (бит 5 поля Flags) — этот бит показывает, что данное сообщение является откликом на сообщение с таким же идентификатором. Этот бит должен сбрасываться во всех запросах и устанавливаться во всех откликах. Для конечной точки IKE недопустима генерация откликов на сообщения, помеченные, как отклик.
    • X(резерв) (биты 6-7) — эти биты должны сбрасываться при передаче и игнорироваться на приеме.
  • Message ID (4 октета) — идентификатор сообщения служит для управления повторной передачей потерянных пакетов и связывания запросов с откликами. Это поле важно для безопасности протокола, поскольку оно используется для предотвращения атак с повторным использованием перехваченных пакетов (replay-атаки). См. также параграфы 2.1 и 2.2.
  • Length (4 октета) — размер всего сообщения (заголовок и элементы данных) в октетах.

3.2. Базовый заголовок элемента данных

Каждый из элементов данных (payload) IKE, определенных в параграфах 3.3 — 3.16, начинается с базового заголовка (Рисунок 5). Рисунки в описании каждого элемента включают базовый заголовок, но описания полей для краткости опущены и приводятся только в этом параграфе

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 5: Формат базового заголовка данных
  • Next Payload (1 октет) — идентификатор типа следующего элемента данных в сообщении. Если текущий элемент является последним, это поле имеет значение 0. Это поле позволяет создавать «цепочки», когда дополнительный элемент просто добавляется в конец сообщения и устанавливается значение поля Next Payload в предыдущем элементе для индикации типа нового элемента. Элемент типа Encrypted, который всегда должен быть последним в сообщении, является исключением. Он содержит структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле Next Payload устанавливается в соответствии с типом первого вложенного элемента (вместо 0).

    Значения Payload Type показаны на таблице:

    Тип Next Payload Обозначение Значение
    No Next Payload 0
    Резерв 1-32
    Security Association SA 33
    Key Exchange KE 34
    Identification — Initiator IDi 35
    Identification — Responder IDr 36
    Certificate CERT 37
    Certificate Request CERTREQ 38
    Authentication AUTH 39
    Nonce Ni, Nr 40
    Notify N 41
    Delete D 42
    Vendor ID V 43
    Traffic Selector — Initiator TSi 44
    Traffic Selector — Responder TSr 45
    Encrypted E 46
    Configuration CP 47
    Extensible Authentication EAP 48
    Резерв IANA 49-127
    Для частного применения 128-255

    Значения типов 1-32 не следует использовать во избежание перекрытия со значениями, применяемыми в IKEv1. Типы 49-127 зарезервированы IANA для будущего распределения в IKEv2 (см. параграф 6). Типы 128-255 выделены для частного применения по согласованию сторон.

  • Critical (1 бит) — это поле должно иметь значение 0, если отправитель хочет, чтобы получатель пропустил этот элемент, если он не понимает код в поле Next Payload предыдущего элемента. Если получатель понимает тип элемента, он должен игноорировать этот флаг. Это поле должно устанавливаться в 0 для определенных в документе типов элементов данных. Отметим, что флаг критичности относится к текущему элементу данных, а не к следующему, чей тип указывается в первом октете. Причина сбрасывания бита критичности для определенных здесь элементов заключается в том, что все реализации должны поддерживать все типы элементов, определенные в этой спецификации, и, следовательно, должны игнорировать значение флага Critical. Предполагается, что пропускаемые элементы будут иметь корректные значения полей Next Payload и Payload Length.
  • RESERVED (7 битов) — должно иметь нулевое значение при передаче и игнорироваться на приеме.
  • Payload Length (2 октета) — размер текущего элемента данных в октетах с учетом базового заголовка.

3.3. Элементы данных SA

Данные защищенной связи, обозначаемые в этом документе SA, служат для согласования атрибутов защищенной связи. Сборка элементов данных SA требует внимания. Элемент SA может включать множество предложений. Если предложений больше одного, они должны быть упорядочены в порядке снижения предпочтительности. Каждое предложение может включать множество протоколов IPsec (протоколами являются IKE, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать множество атрибутов. При разборе SA реализация должна проверить соответствие значения Payload Length с размерами и числом отдельных компонент. Предложения (Proposal), преобразования (Transform) и атрибуты (Attribute) используют свое представление с различными размерами. Они вкладываются в элемент так, чтобы значение поля Payload Length элемента SA учитывало данные SA, Proposal, Transform и Attribute. Размер Proposal включает размер всех содержащихся в нем Transform и Attribute. Размер Transform включает размеры всех содержащихся в нем Attribute.

Синтаксис элементов SA, Proposal, Transform и Attribute основан на ISAKMP, однако семантика их слегка отличается. Причина использования иерархической структуры заключается в том, что такая структура позволяет представлять в одной SA множество возможных комбинаций алгоритмов. Иногда предоставляется выбор из множества алгоритмов, в других случаях — комбинация алгоритмов. Например, инициатор может предложить использование комбинации (AH w/MD5 И ESP w/3DES) ИЛИ (ESP w/MD5 И 3DES).

Одной из причин изменения семантики элементов SA по сравнению с ISAKMP и IKEv1 является повышение уровня компактности представления в наиболее распространенных случаях.

Структура Proposal включает Proposal # (номер предложения) и идентификатор протокола IPsec. Каждая структура должна использовать значение Proposal #, совпадающее со значением в предыдущей структуре или увеличенное на 1. Первый элемент Proposal должен иметь Proposal # = 1. Если две структуры подряд имеют одинаковый номер предложения, это значит, что предложение включает первую И вторую структуры. Так, для предложения AH И ESP будут использоваться две структуры (одна для AH, другая для ESP) с одинаковым номером Proposal #1. Для предложения AH ИЛИ ESP будут использоваться две структуры — для AH с номером Proposal #1 и для ESP с номером Proposal #2.

За каждой структурой Proposal/Protocol следует одна или множество структур преобразований. Число преобразований обычно определяется протоколом. AH обычно имеет одно преобразование — алгоритм контроля целостности. ESP обычно имеет два преобразования — алгоритм шифрования и алгоритм контроля целостности. IKE в общем случае имеет четыре преобразования — группа Diffie-Hellman, алгоритм контроля целостности, алгоритм prf и алгоритм шифрования. Если предлагаются комбинированные алгоритмы шифрования и защиты целостности, он должен предлагаться, как алгоритм шифрования, а предлагать в таком случае алгоритм защиты целостности недопустимо. Для каждого протокола набору допустимых преобразования присваиваются идентификаторы, включаемые в заголовок каждого преобразования.

Если имеется множество преобразований одного типа (одно значение Transform Type), предложение включает объединение (операция ИЛИ) этих преобразований. При наличии множества преобразований различных типов, группы объединяются операцией И. Например, чтобы предложить ESP с (3DES или IDEA) и (HMAC_MD5 или HMAC_SHA), предложение ESP будет включать два кандидата Transform Type 1 (один для 3DES, второй для IDEA) и два кандидата Transform Type 2 (для HMAC_MD5 и HMAC_SHA). Это обеспечивает эффективное предложение четырех комбинаций алгоритмов. Если инициатор хочет предложить только подмножество этого — например, (3DES и HMAC_MD5) или (IDEA и HMAC_SHA), — не существует возможности представить это в виде множества преобразований в одном предложении. Взамен инициатор будет создавать два разных предложения по паре преобразований в каждом.

Преобразование может иметь одие или множество атрибутов (Attribute). Атрибуты требуются, когда преобразование может использоваться множеством способов (например, алгоритм шифрования с переменным размером ключей — в этом случае преобразование будет задавать алгоритм, а атрибут — размер ключа). Большинство преобразований не имеет атрибутов. Для преобразования недопустимо наличие множества однотипных атрибутов. Чтобы предложить варианты значения для атрибута (например, множество размеров ключа для алгоритма шифрования AES), реализация должна включать множество преобразований с общим значением Transform Type, каждое из которых имеет один атрибут (Attribute).

Отметим, что семантика Transform и Attribute достаточно сильно отличается от IKEv1. В IKEv1 одно преобразование задает множество алгоритмов для протокола и часть их передается в Transform, а другие в Attribute.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                          <Proposals>                          ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 6: Элемент данных SA
  • Proposals (переменный размер) — одна или множество структур с предложениями. Идентификатор типа для элемента SA имеет значение 33.

3.3.1. Субструктура предложения

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 2 !   RESERVED    !         Proposal Length       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #    !  Protocol ID  !    SPI Size   !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        SPI (variable)                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                        <Transforms>                           ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 7: Субструктура Proposal
  • 0 (последнее) или 2 (не последнее) (1 октет) — показывает, является ли предложение последним в субструктуре предложений элемента SA. Синтаксис унаследован от ISAKMP, не это поле не является необходимым, поскольку последнее предложение можно идентифицировать по размеру SA. Значение 2 соответствует типу элемента Proposal в IKEv1 и первые четыре октета структуры Proposal организованы так, чтобы они выглядели, подобно заголовку Payload.
  • Резерв (1 октет) — должно устанавливаться в 0 при передаче и игнорироваться на приеме.
  • Proposal Length (2 октета) — размер данного предложения, включая все входящие в него преобразования и атрибуты.
  • Proposal # (1 октет) — номер предложения. Первое предложение в элементе SA должно иметь номер 1, а номера последующих должны совпадать с номером предшественника (И — пересечение двух предложений) или быть на 1 больше (ИЛИ — объединение двух предложений). Когда предложение принимается, все номера предложений в элементе SA должны совпадать и соответствовать номеру переданного предложения, которое было принято.
  • Protocol ID (1 октет) — Задает идентификатор протокола IPsec для текущего согласования. Определенные значения идентификаторов показаны в таблице.
    Protocol Protocol ID
    Резерв 0
    IKE 1
    AH 2
    ESP 4
    Резерв IANA 4 - 200
    Частное применение 201 - 255
  • SPI Size (1 октет) — для начального согласования IKE_SA это поле должно иметь нулевое значение; значение SPI получается из внешнего заголовка. При последующих согласованиях это поле показывает размер (в октетах) SPI для соответствующего протокола (8 для IKE, 4 для ESP и AH).
  • # of Transforms (1 октет) — показывает число преобразований в данном предложении.
  • SPI (переменный размер) — SPI передающей стороны. Даже если значение SPI Size не кратно 4, для элементов данных не используется заполнения. При нулевом значении SPI Size это поле не включается в элемент SA.
  • Transforms (переменный размер) — одна или множество субструктур преобразований.

3.3.2. Субструктура преобразования

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 3 !   RESERVED    !        Transform Length       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!Transform Type !   RESERVED    !          Transform ID         !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                      Transform Attributes                     ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 8: Субструктура Transform
  • 0 (последнее) или 3 (не последнее) (1 октет) — показывает, является ли это преобразование последним в предложении. Синтаксис унаследован от ISAKMP, не это поле не является необходимым, поскольку последнее предложение можно идентифицировать по размеру Proposal. Значение 2 соответствует типу элемента Transform в IKEv1 и первые четыре октета структуры организованы так, чтобы они выглядели, подобно заголовку Payload.
  • Резерв (1 октет) — должно устанавливаться в 0 при передаче и игнорироваться на приеме.
  • Transform Length — размер субструктуры Transform (в октетах) с учетом заголовка и атрибутов.
  • Transform Type (1 октет) — показывает тип преобразования, задаваемого этим элементом. Различные протоколы поддерживают разные типы преобразований. Для некоторых протоколов часть преобразований может быть опциональной. Если преобразование является необязательным и инициатор предлагает его пропустить, преобразования этого типа не включаются в предложение. Если инициатор желает отдать решение вопроса об использовании необязательного преобразования ответчику, он включает субструктуру этого преобразования с нулевым идентификатором (Transform ID = 0) в качестве одной из опций.
  • Transform ID (2 октета) — указывает конкретный экземпляр предлагаемого преобразования.

Типы преобразований перечислены ниже в таблице.

Тип преобразования Используется
Резерв 0
Encryption Algorithm (ENCR) — алгоритм шифрования 1 IKE и ESP
Pseudo-random Function (PRF) — псевдослучайная функция 2 IKE
Integrity Algorithm (INTEG) — алгоритм защиты целостности 3 IKE, AH, опционально в ESP
Diffie-Hellman Group (D-H) — группа Diffie-Hellman 4 IKE, опционально в AH и ESP
Extended Sequence Numbers (ESN) — расширенные порядковые номера 5 AH и ESP
Резерв IANA 6 — 240
Частное применение 241-255

Для преобразований типа 1 (Transform Type 1 — алгоритм шифрования) определены следующие идентификаторы (Transform ID):

Имя Значение Определение
Резерв 0
ENCR_DES_IV64 1 RFC1827
ENCR_DES 2 RFC2405, [DES]
ENCR_3DES 3 RFC2451
ENCR_RC5 4 RFC2451
ENCR_IDEA 5 RFC2451, [IDEA]
ENCR_CAST 6 RFC2451
ENCR_BLOWFISH 7 RFC2451
ENCR_3IDEA 8 RFC2451
ENCR_DES_IV32 9
Резерв 10
ENCR_NULL 11 RFC2410
ENCR_AES_CBC 12 RFC3602
ENCR_AES_CTR 13 RFC3664
Резерв IANA 14 - 1023
Резерв для частного использования по соглашению сторон 1024-65535

Для преобразований типа 2 (псевдо-случайная функция) определены идентификаторы:

Имя Значение Определение
Резерв 0
PRF_HMAC_MD5 1 RFC2104, [MD5]
PRF_HMAC_SHA1 2 RFC2104, [SHA]
PRF_HMAC_TIGER 3 RFC2104
PRF_AES128_XCBC 4 RFC3664
Резерв IANA 5 - 1023
Резерв для частного использования по соглашению сторон 1024-65535

Для преобразований типа 3 (алгоритм защиты целостности) определены идентификаторы:

Имя Значение Определение
NONE 0
AUTH_HMAC_MD5_96 1 RFC2403
AUTH_HMAC_SHA1_96 2 RFC2404
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 RFC1826
AUTH_AES_XCBC_96 5 RFC3566
Резерв IANA 5 - 1023
Резерв для частного использования по соглашению сторон 1024-65535

Для преобразований типа 4 (группа Diffie-Hellman) определены идентификаторы:

Имя Значение
NONE 0
Определены в Приложении B 1 - 2
Резерв 3 - 4
Определены в [ADDGROUP] 5
Резерв IANA 6 - 13
Определены в [ADDGROUP] 14 - 18
Резерв IANA 19 - 1023
Частное применение 1024-65535

Для преобразований типа 5 (расширенные порядковые номера) определены идентификаторы:

Имя Значение
No Extended Sequence Numbers — нет расширенных номеров 0
Extended Sequence Numbers — расширенные номера 1
Резерв 2 - 65535

3.3.3. Корректные типы преобразований по протоколам

Число и тип преобразований в элементах SA зависит от типа протокола в самой SA. Элемент данных SA, предлагающий организацию SA имеет обязательные и опциональные типы преобразований. Совместимая с требованиями реализация должна понимать все обязательные и опциональные типы для каждого поддерживаемого ею протокола (хотя принимать предложения с неподходящими наборами не требуется). Предложение может опускать необязательные типы, если единственным воспринимаемым значением этого типа является NONE.

Протокол Обязательные типы Опциональные типы
IKE ENCR, PRF, INTEG, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H

3.3.4. Обязательные идентификаторы преобразований

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

Важным результатом использования IKEv1 является понимание того, что системам не следует реализовать только обязательные алгоритмы и ждать, что они явятся лучшим выбором для всех пользователей. Например, во время подготовки этого документа многие разработчики IKEv1 начали переход на AES в режиме CBC для приложений VPN. Многие системы IPsec на базе IKEv2 будут поддерживать AES, дополнительные группы Diffie-Hellman и дополнительные алгоритмы хэширования, а некоторым пользователям IPsec уже требуются эти алгоритмы в дополнение к перечисленным выше.

Очевидно, что IANA будет добавлять преобразования и некоторые пользователи могут ждать этого, применяя приватные наборы, особенно для IKE, где разработчикам следует обеспечивать поддержку различных параметров, вплоть до некоторых ограничений размера. В поддержку этой идеи всем реализациям IKEv2 следует включать средства управления, которые позволяют (пользователю или системному администратору) задавать параметры Diffie-Hellman (DH) (генератор, модули, размер и значения экспоненты) для новых групп DH. Разработчикам следует обеспечивать интерфейс управления, через который эти параметры и связанные с ними идентификаторы преобразований могут задаваться (пользователем или системным администратором) для обеспечения возможности согласования таких групп.

Все реализации IKEv2 должны включать средства управления, которые позволят пользователю или администратору системы задавать наборы, подходящие для использования с IKE. При получении элемента данных с набором идентификаторов преобразований, реализация должна сравнить переданные идентификаторы преобразований с выбранными локально для проверки согласованности предложенного набора с локальной политикой. Реализация должна отвергать предложения SA, которые не разрешены этими средствами управления наборами IKE. Отметим, что криптографические наборы, которые должны быть реализованы, необходимо включить с локальную политику.

3.3.5. Атрибуты преобразования

Каждое преобразование элемента данных SA может включать атрибуты, меняющие или дополняющие спецификацию преобразования. Эти атрибуты представляют собой пары «тип-значение» и определены ниже. Например, если алгоритм шифрования имеет ключи переменного размера, этот размер может задаваться в качестве атрибута. Атрибуты могут иметь значение фиксированного (2 октета) или переменного размера. В последнем случае для представления атрибута используется формат «тип-размер-значение».

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A!       Attribute Type        !    AF=0  Attribute Length     !
!F!                             !    AF=1  Attribute Value      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                   AF=0  Attribute Value                       !
!                   AF=1  Not Transmitted                       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 9: Атрибуты преобразования
  • Attribute Type (2 октета) — уникальный идентификатор для каждого типа атрибутов (см. ниже). Старший бит этого поля является флагом формата атрибута (AF), показывающим использование полного (TLV) или сокращенного (TV) формата. При AF = 0, для атрибута используется формат TLV, при AF = 1 - TV.
  • Attribute Length (2 октета) — размер поля Attribute Value в октетах. При AF = 1, размер Attribute Value всегда составляет 2 октета и поле Attribute Length отсутствует.
  • Attribute Value (переменный размер) — значение атрибута, связанное с Attribute Type. Если AF = 0, размер этого поля указывается в поле Attribute Length. При AF = 1 размер поля Attribute Value всегда равен 2 октетам.

Отметим, что в настоящее время определен только один тип атрибута — размер ключа (Key Length) и для него используется фиксированный размер. Спецификации атрибутов переменной длины включены только для будущих расширений. Из определенных в этом документе алгоритмов атрибуты принимают только основанные на AES функции шифрования, защиты целостности и генерации случайных чисел — им нужен один атрибут, задающий размер ключа.

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

Тип Значение Формат
Резерв 0-13
Key Length (в битах) 14 TV
Резерв 15-17
Резерв IANA 18-16383
Для частного применения 16384-32767

Значения 0-13 и 15-17 использовались в аналогичном контексте IKEv1 и их не следует выбелять во избежание конфликтов. Значения 18-16383 зарезервированы для IANA. Диапазон 16384-32767 выделен для частного применения по согласованию сторон.

  • Key Length — размер ключа
  • При использовании алгоритма шифрования с ключами переменного размера этот атрибут показывает размер ключа в битах (должен использоваться сетевой порядок байтов). Это атрибут недопустимо использовать с алгоритмами шифрования, имеющими фиксированный размер ключа.

3.3.6. Согласование атрибутов

При согласовании защищенной связи инициатор вносит свои предложения ответчикам. Ответчики должны выбирать из предложений один полный набор параметров или отвергать все предложения, если они не подходят. Если имеется множество предложений, ответчик должен выбрать номер одного из них и вернуть инициатору все субструктуры Proposal с этим номером предложения. Если имеется множество однотипных преобразований, ответчик должен выбрать одно из них. Все атрибуты выбранного преобразования должны возвращаться в неизменном виде. Инициатор обмена должен убедиться в том, что принятое предложение согласуется со сделанными им предложениями. При наличии расхождений отклик должен быть отвергнут.

Согласование групп Diffie-Hellman имеет некоторые особенности. Предложение SA включает предлагаемые атрибуты и открытый номер Diffie-Hellman (KE) в одно сообщение. Если в начальном обмене инициатор предлагает использовать одну из нескольких групп Diffie-Hellman, ему следует выбрать ту, которую ответчик с высокой вероятностью примет, и включить соответствующее этой группе значение KE. Если предсказание окажется неверным, ответчик укажет в отклике корректную группу и инициатору следует найти для своего KE элемент в этой группе при повторе сообщения. Однако ему следует по-прежнему предлагать полный набор поддерживаемых групп, чтобы предотвратить возможность организации атак, направленных на снижение уровня защиты.

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

Поддержка такой возможности позволяет реализации выражать концепции защиты не ниже определенного уровня — «ключ размером не менее X битов для шифра Y».

3.4. Обмен ключами

Элемент данных Key Exchange (KE) служит для обмена открытыми номерами Diffie-Hellman при обмене ключами Diffie-Hellman. Элемент KE включает базовый заголовок IKE, за которым следует открытое значение Diffie-Hellman.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!          DH Group #           !           RESERVED            !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Key Exchange Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 10: Формат обмена ключами

Элемент данных обмена ключами создается путем копирования открытого значения Diffie-Hellman в поле Key Exchange Data. Размер открытого значения Diffie-Hellman должен быть равен размеру первичного модуля, для которого выполняется возведение в степень, дополненного при необходимости нулями в начале.

Поле DH Group # идентифицирует группу Diffie-Hellman в которой было рассчитано значение Key Exchange Data (см. параграф 3.3.2). Если выбранное предложение использует другую группу Diffie-Hellman, сообщение должно быть отвергнуто с возвратом элемента Notify типа INVALID_KE_PAYLOAD.

Тип элемента для обмена ключами KE имеет значение 34.

3.5. Формат идентификации

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   ID Type     !                 RESERVED                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Identification Data                         ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 11: Формат идентификации

Элемент данных Identification (ID), обозначаемый в этом документе IDi и IDr, позволяет партнерам предъявлять свою идентификацию другой стороне. Эта идентификация может использоваться при просмотре политики, но не обязана соответствовать информации в элементе CERT — оба эти поля могут использоваться реализацией для контроля доступа.

Примечание. В IKEv1 использовались два идентификатора элементов (для разных направлений), чтобы передать информацию TS для данных, передаваемых через SA. В IKEv2 эта информация передается в элементах TS (см. параграф 3.13).

  • ID Type (1 октет) — задает тип используемой идентификации.
  • Резерв — должно обнуляться при передаче и игнорироваться на приеме.
  • Identification Data (переменный размер) — значение, указанное полем Identification Type. Размер данных идентификации рассчитывается по размеру в заголовке элемента ID.

Тип элемента для Identification может принимать значение 35 (Idi) и 36 (IDr).

В таблице приведен список выделенных значений поля Identification Type с описанием соответствующего поля Identification Data.

ID Type Значение Описание Identification Data
Резерв 0
ID_IPV4_ADDR 1 Один четырехоктетный адрес IPv4.
ID_FQDN 2 Строка полного доменного имени (например, example.com). В строку недопустимо включать символы завершения (NULL, CR и т.п.).
ID_RFC822_ADDR 3 Строка полного почтового адреса RFC822 (например, [email protected] ). В строку недопустимо включать символы завершения.
Резерв IANA 4
ID_IPV6_ADDR 5 Один шестнадцатиоктетный адрес IPv6.
Резерв IANA 6-8
ID_DER_ASN1_DN 9 Двоичное представление правил DER для ASN.1 X.500 Distinguished Name [X.501].
ID_DER_ASN1_GN 10 Двоичное представление правил DER для ASN.1 X.500 GeneralName [X.509].
ID_KEY_ID 11 Неструктурированный поток октетов, который может использоваться для передачи связанной с производителем информации, требуемой для некоторых фирменных вариантов идентификации.
Резерв IANA 12-200
Резерв для частного использования 201-255

Две реализации будут интероперабельны только в том случае, когда каждая может генерировать тип ID, приемлемый для другой стороны. Для обеспечения максимальной интероперабельности реализация должна быть настраиваемой на передачу по крайней мере одного из типов ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_KEY_ID и восприятие всех этих типов. Реализациям следует обеспечивать возможность генерации и восприятия всех этих типов. Поддерживающие IPv6 реализации должны дополнительно иметь возможность настройки восприятия ID_IPV6_ADDR. Реализации, поддерживающие только IPv6, можно настраивать на передачу только ID_IPV6_ADDR.

3.6. Сертификат

Элемент данных Certificate (CERT) обеспечивает способ передачи сертификатов или другой, связанной с идентификацией информации через IKE. Элементы Certificate следует включать в обмен, если сертификаты доступны отправителю до того, как партнер указал возможность получения идентификационной информации иным путем с использованием элемента Notify типа HTTP_CERT_LOOKUP_SUPPORTED. Отметим, что термин «Certificate Payload» может вводить в заблуждение, поскольку не все механизмы идентификации используют сертификаты и в этом элементе могут передаваться иные данные.

Элемент данных Certificate имеет следующие поля:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                       Certificate Data                        ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 12: Формат сертификата
  • Certificate Encoding (1 октет) — это поле показывает тип представления сертификата или иной информации, содержащейся в поле Certificate Data (см. таблицу).
    Кодирование сертификата Значение
    Резерв 0
    Сертификат X.509 с PKCS #7 1
    Сертификат PGP 2
    Подписанный ключ DNS 3
    Сертификат X.509 — подпись 4
    Маркер Kerberos 6
    CRL 7
    ARL 8
    Сертификат SPKI 9
    Сертификат X.509 — атрибут 10
    Неразобранный ключ RSA 11
    Хэш и URL сертификата X.509 12
    Хэш и URL связки (bundle) X.509 13
    Резерв IANA 14 — 200
    Для частного применения 201 — 255
  • Certificate Data (переменный размер) — представление данных сертификата. Тип сертификата указывается в поле Certificate Encoding.

Идентификатор типа элемента данных Certificate имеет значение 37.

Конкретный синтаксис ряда перечисленных типов сертификатов в этом документе не определяется. К числу сертификатов, синтаксис которых определен здесь относятся:

  • Сертификат X.509 — подпись (4) содержит сертификат X.509 (в представлении DER), открытый ключ которого используется для проверки элемента данных AUTH отправителя.

    Список отозванных сертификатов (7) содержит представление DER для списка отозванных сертификатов X.509.

    Неразобранный ключ RSA (11) содержит ключ RSA в представлении PKCS #1 (см. [RSA] и [PKCS1]).

    Хэш и URL (12-13) позволяют включать в сообщения IKE замену больших структур данных с 20-октетным хэшем SHA-1 (см.[SHA]) значением URL переменной длины, которое преобразуется в структуру данных (в представлении DER). Это повышает эффективность в тех случаях, когда конечные точки имеют хэшированные сертификаты и снижает эффект воздействия на IKE атак на отказ служб, которые становились бы проще в реализации при использовании достаточно больших сообщений IKE, требующих фрагментации на уровне IP [KPS03].

    Ниже приведено представление сборки X.509 в формате ASN.1.

     CertBundle
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-cert-bundle(34) }
 DEFINITIONS EXPLICIT TAGS ::=
 BEGIN
 IMPORTS
   Certificate, CertificateList
   FROM PKIX1Explicit88
      { iso(1) identified-organization(3) dod(6)
        internet(1) security(5) mechanisms(5) pkix(7)
        id-mod(0) id-pkix1-explicit(18) } ;
CertificateOrCRL ::= CHOICE {
  cert [0] Certificate,
  crl  [1] CertificateList }
CertificateBundle ::= SEQUENCE OF CertificateOrCRL
END

Реализации должны обеспечивать возможность настройки передачи и восприятия до четырех сертификатов X.509 в поддержку идентификации, а также должны обеспечивать возможность настройки передачи и восприятия двух первых форматов «Hash and URL» (с HTTP URL). Реализациям следует обеспечивать возможность настройки передачи и восприятия ключей Raw RSA. При передаче множества сертификатов первый из них должен содержать открытый ключ, используемый для подписывания элемента AUTH. Остальные сертификаты можно передавать в любом порядке.

3.7. Запрос сертификата

Элемент Certificate Request (CERTREQ) обеспечивает возможность запросить предпочитаемые сертификаты через IKE и может появляться в откликах IKE_INIT_SA и запросах IKE_AUTH. Элементы Certificate Request могут включаться в обмен, когда отправителю нужен сертификат получателя. При наличии множества доверенных CA, если поле C Cert Encoding не разрешает список, следует передавать множество элементов Certificate Request.

Элемент Certificate Request содержит следующие поля:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                    Certification Authority                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 13: Формат запроса сертификата
  • Certificate Encoding (1 октет) — задает тип представления запрашиваемого сертификата. Возможные значения перечислены в параграфе 3.6.
  • Certification Authority (переменный размер) — указывает подходящий удостоверяющий центр для запрашиваемого типа сертификата.

Идентификатор типа для элемента данных Certificate Request имеет значение 38.

Поле Certificate Encoding имеет такие же значения, как описано в параграфе 3.6. Поле Certification Authority содержит индикатор удостоверяющего центра для данного типа сертификата. Значение Certification Authority представляет собой конкатенацию хэш-значений SHA-1 для открытых ключей удостоверяющих центров (CA). Каждое значение представляет собой хэш SHA-1 для элемента Subject Public Key Info (см. параграф 4.1.2.7 работы [RFC3280]) из каждого сертификата Trust Anchor. Двадцатиоктетные хэш-значения объединяются (конкатенация) и помещаются в поле без дополнительного форматирования.

Отметим, что термин «Certificate Request» (запрос сертификата) может ввожить в заблуждение, поскольку запрашиваться с помощью этого элемента могут не только сертификаты, но и другие данные, как было указано в описании элемента «Certificate». Синтаксис элемента Certificate Request для таких случаев не определяется в этом документе.

Элемент Certificate Request обрабатывается путем проверки поля Cert Encoding для определения наличия у обрабатывающего сертификатов этого типа. Если такие сертификаты имеются, проверяется поле Certification Authority для проверки наличия у обрабатывающего сертификатов, которые могут быть проверены в одном из указанных удостоверяющих центров. Это может быть цепочка сертификатов.

Если существует сертификат конечного объекта, который удовлетворяет критериям, заданным в CERTREQ, этот сертификат или цепочку сертификатов следует передать назад запрашивающему сертификат узлу, при условии, что получатель CERTREQ:

  • настроен на использование идентификации по сертификатам;
  • имеет разрешение на передачу элемента CERT;
  • имеет соответствующую политику доверия к CA для текущего согласования;
  • имеет по крайней мере один действующий (time-wise) и подходящий сертификат конечного объекта, связанный с CA из CERTREQ.

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

Не ставится задачи блокирования связи на основе строгого соответствия выбора сертификата предложенному в CERTREQ — отправитель может выбирать другие сертификаты, которые получатель может проверить и которым он сможет доверять за счет использования кросс-сертификации. Таким образом, обработке CERTREQ следует выглядеть, как предложению на выбор сертификата (не обязательно одного). Если сертификата нет, элемент CERTREQ игнорируется. С точки зрения протокола это не является ошибкой. Могут быть случаи наличия предпочтительного CA, переданного в CERTREQ, когда подходящим может оказаться другой удостоверяющий центр (возможно, в результате выбора оператора).

3.8. Идентификация

Элемент данных Authentication (AUTH) содержит данные, которые используются для идентификации. Синтаксис Authentication Data меняется в соответствии с выбором Auth Method, как описано ниже.

Элемент Authentication имеет следующие поля:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth Method   !                RESERVED                       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                      Authentication Data                      ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 14: Формат идентификации
  • Auth Method (1 октет) — задает используемый метод мдентификации и может принимать значения:
    • RSA Digital Signature (1) — рассчитывается, как указано в параграфе 2.15, с использованием приватного ключа RSA и хэш-значения PKCS#1 с заполнением (см. [RSA] и [PKCS1]).
    • Shared Key Message Integrity Code (2) — рассчитывается, как указано в параграфе 2.15, с использованием разделяемого ключа, связанного с объектом из элемента ID, и согласованной функции prf.
    • DSS Digital Signature (3) — рассчитывается, как указано в параграфе 2.15, с использованием приватного ключа DSS (см. [DSS]) и хэш-значения SHA-1.
    • Значение 0 и 4-200 зарезервированы IANA. Значения 201-255 выделены для частных приложений.
  • Authentication Data (переменный размер) — см. параграф 2.15.

Идентификатор типа элемента Authentication имеет значение 39.

3.9. Элемент Nonce

Элементы Nonce, обозначаемые в этом документе Ni и Nr (для инициатора и ответчика, соответственно), содержат случайные значения, служащие для проверки жизненности в процессе обмена и защиты от атак с повторным использованием пакетов.

Элемент Nonce имеет одно поле:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                            Nonce Data                         ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 15: Формат Nonce
  • Nonce Data (переменный размер) — случайное значение, созданное передающей стороной.

Идентификатор типа элемента Nonce имеет значение 40.

Размер Nonce должен находиться в диапазоне от 16 до 256 октетов, включительно. Недопустимо повтороное использование значений Nonce.

3.10. Уведомление

Элемент Notify (N) используется для передачи служебной информации (ошибки, смена состояния) партнеру IKE. Элемент Notify может появляться в откликах на отвергнутые запросы (обычно с указанием причины отказа), обмене INFORMATIONAL (для сообщений об ошибках, не относящихся к запросу IKE) и в других сообщениях для индикации возможностей отправителя или изменения трактовки запроса.

Элемент Notify имеет следующие поля:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Protocol ID  !   SPI Size    !      Notify Message Type      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                Security Parameter Index (SPI)                 ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Notification Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 16: Формат уведомления
  • Protocol ID (1 октет) — если уведомление относится к существующей SA, это поле показывает тип данной SA. Для уведомлений IKE_SA это поле должно иметь значение 1. Для уведомлений, касающихся IPsec SA, это поле должно содержать значение 2 для протокола AH или 3 для ESP. Для уведомлений, не относящихся к существующим SA, это поле должно сбрасываться в 0 при передаче и игнорироваться на приеме. Все остальные значения зарезервированы IANA для использования в будущем.
  • SPI Size (1 октет) — размер SPI (в октетах) в соответствии с идентификатором протокола IPsec или 0, если SPI не применим. Для уведомлений, касающихся IKE_SA, поле SPI Size должно иметь значение 0.
  • Notify Message Type (2 октета) — задает тип уведомления.
  • SPI (переменный размер) — список параметров защиты.
  • Notification Data (переменный размер) — информация или данные об ошибке, передаваемые в дополнение к Notify Message Type. Значения этого поля зависят от типа и описаны нижеэ

Идентификатор типа элемента Notify имеет значение 41.

3.10.1. Типы уведомлений

Уведомления могут сообщать о причинах ошибок, не позволивших организоовать SA. Они могут также содержать данные о состоянии, которые процесс, управляющий базой данных SA, желает передать процессу партнера. Приведенная ниже таблица содержит список сообщений Notification и их идентификаторов. Число различных ошибочных состояний существенно снижено по сравнению с IKEv1 в целях упрощения и сокращения объема информации для зондирования.

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

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

Сообщение Notify — ошибки Значение Описание
Резерв 0
UNSUPPORTED_CRITICAL_PAYLOAD 1 Передается в тех случаях, когда не распознан элемент с флагом Critical. Поле Notification Data содержит октет типа элемента.
INVALID_IKE_SPI 4 Показывает, сообщение IKE, полученное с нераспознанным SPI адресата. Это обычно говорит о перезагрузке партнера с утратой существующей IKE_SA.
INVALID_MAJOR_VERSION 5 Показывает, что получатель не может обрабатывать версию IKE, указанную в заголовке. В заголовке отклика указывается ближайший номер версии, поддерживаемой получателем.
INVALID_SYNTAX 7 Показывает сообщения IKE, полученные некорректно по причине вызода за допустимые пределы типа, размера или значения, а также отвергнутые на основе политики. Для предотвращения атак на службы с использованием обманных сообщений это сообщение можно возвращать только для шифрованных сообщений (в шифрованных сообщениях), если идентификатор сообщения и криптографическая контрольная сумма корректны. Во избежание утечки информации к зондирующему это сообщение должно передаваться в ответ на любую ошибку, для которой не выделено кода. Для отладки следует выводить более детальную информацию об ошибке на консоль или в системный журнал.
INVALID_MESSAGE_ID 9 Передается при получении сообщения IKE, идентификатор которого не попадает в поддерживаемое окно. Такое уведомление недопустимо передавать в отклике, поскольку подтверждение некорректного запроса недопустимо. Вместо этого другую сторону можно проинформировать с помощью обмена INFORMATIONAL с поле Notification, содержащим четыре октета некорректного идентификатора сообщения. Передача этого уведомления является опциональной и должна быть ограничена по частоте.
INVALID_SPI 11 Может передаваться в обмене INFORMATIONAL, когда узел получает пакет ESP или AH с некорректным SPI. Поле Notification Data содержит SPI из полученного пакета. Обычно такое сообщение говорит о перезагрузке узла с потерей SA. Если такое сообщение передается вне контекста IKE_SA, его следует использовать только в качестве «совета», поскольку подделать такое сообщение достаточно просто.
NO_PROPOSAL_CHOSEN 14 Неприемлем ни один из предложенных криптографических наборов.
INVALID_KE_PAYLOAD 17 Поле D-H Group # элемента KE не совпадает с номером группы, выбранным ответчиком для этого обмена. С таким уведомлением связаны два октета (в сетевом порядке) данных, указывающие номер приемлемой группы D-H.
AUTHENTICATION_FAILED 24 Передается в ответ на сообщение IKE_AUTH, когда идентификация не прошла. Связанных данных нет.
SINGLE_PAIR_REQUIRED 34 Это сообщение показывает, что запрос CREATE_CHILD_SA не принят потому, что отправитель согласен принимать только селекторы трафика, задающие одну пару адресов. Предполагается, что запрашивающая сторона ответит запросом SA только для конкретного трафика.
NO_ADDITIONAL_SAS 35 Это сообщение показывает, что запрос CREATE_CHILD_SA не принят потому, что ответчик не хочет создавать дополнительные CHILD_SA для данной IKE_SA. Некоторые минимальные реализации могут принимать организацию только одной CHILD_SA в контексте начального обмена IKE и отвергают все последующие попытки организации связей.
INTERNAL_ADDRESS_FAILURE 36 Показывает ошибку при выделении внутреннего адреса (INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS) в процессе обработки ответчиком элемента Configuration. Если это сообщение создано в контексте обмена IKE_AUTH, связи CHILD_SA не будут организованы.
FAILED_CP_REQUIRED 37 Передается ответчиком в тех случаях, когда CP(CFG_REQUEST) предполагалось, но не было получено в результате конфликта с локальной политикой. Связанных данных нет.
TS_UNACCEPTABLE 38 Показывает неприемлемость всех адресов/протоколов/портов в селекторе трафика.
INVALID_SELECTORS 39 Может передаваться в обмене INFORMATIONAL, когда узел получает пакет ESP или AH, в котором селекторы не соответствуют использованной SA (это приводит к отбрасыванию пакета). Поле Notification Data содержит начало ошибочного пакета (как в сообщениях ICMP), а в поле SPI помещается значение SPI для IPsec SA.
Резерв IANA — типы ошибок 40 - 8191
Для частного применения — типы ошибок 8192 - 16383
Сообщения NOTIFY — состояния Значение Описание
INITIAL_CONTACT 16384 Данное уведомление заявляет, что данная IKE_SA является единственной активной IKE_SA между идентифицированными сторонами. Уведомление может передаваться при создании IKE_SA после аварии и получатель может использовать эту информацию для удаления всех прочих IKE_SA с тем же идентифицированным партнером без ожидания. Недопустима передача таких уведомлений со стороны реплицируемых объектов (например, представление мобильного пользователя, которому разрешено подключаться к корпоративному шлюзу с двух удаленных систем одновременно).
SET_WINDOW_SIZE 16385 Это уведомление заявляет, что передающая сторона способна сохранять состояние для множества незавершенных обменов, что позволяет получателю отправлять множество запросов без ожидания ответа на первый запрос. Данные, связанные с SET_WINDOW_SIZE, должны иметь размер 4 октета (сетевой порядок байтов) и содержать представление числа сообщений, которые могут сохраняться. До завершения начального обмена размер окна всегда равен 1.
ADDITIONAL_TS_POSSIBLE 16386 Это уведомление заявляет, что передающая сторона сужает предложенный набор селекторов трафика, и говорит о возможности использования других селекторов через отдельные SA (см. параграф 2.9). С этим типом уведомлений не связано данных. Уведомление может передаваться только в качестве дополнительного элемента сообщения, включающего подходящие TS.
IPCOMP_SUPPORTED 16387 Это уведомление можно включать только в сообщения, содержащие элемент SA для согласования CHILD_SA, где указано желание использовать IPComp в данной SA. Связанные с уведомлением данные включают двухоктетное значение IPComp CPI, за которым следует однооктетный идентификатор преобразования (возможно, с атрибутами, размер и формат которых определяются идентификатором преобразования). Сообщение, предлагающее SA, может включать множество уведомлений IPCOMP_SUPPORTED для индикации поддержки разных алгоритмов. Сообщение, принимающее SA, может содержать не более одного такого уведомления.

Идентификаторы преобразований показаны ниже.

Имя Номер Определение
Резерв 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2 FC 2394
IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051

Значения 5-240 зарезервированы IANA, значения 241-255 предназначены для частно применения по согласования сторон.
NAT_DETECTION_SOURCE_IP 16388 Это уведомление используется получателем для проверки нахождения его отправителя за устройством NAT. Данные, связанные с этим уведомлением, представляют собой подпись SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда пакет был послан. Возможно наличие множества уведомлений этого типа в сообщении, если отправитель не знает, какое из соединений с сетью будет использоваться для передачи пакета. Получатель уведомления может сравнить полученное значение с хэшем SPI, адреса IP и порта получателя — при несовпадении следует включить режим работы через NAT (см. параграф 2.23). Если работа через NAT не поддерживается, попытка соединения может быть отвергнута.
NAT_DETECTION_DESTINATION_IP 16389 Это уведомление используется его получателем для проверки своего нахождения за устройством NAT. Данные, связанные с этим уведомлением, представляют собой подпись SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда пакет был послан. Получатель уведомления может сравнить полученное значение с хэшем SPI, адреса IP и порта получателя — при несовпадении следует включить режим работы через NAT (см. параграф 2.23). Несоответствие говорит о том, что данная сторона расположена за устройством NAT и ей следует начать передачу пакетов keepalive, как определено в [Hutt05]. Если работа через NAT не поддерживается, попытка соединения может быть отвергнута.
USE_TRANSPORT_MODE 16391 Это уведомление может быть включено в запрос, содержащий также элемент SA для создания CHILD_SA. Уведомление запрашивает для CHILD_SA использование транспортного режима, вместо туннельного. Если запрос принимается, отклик на него должен включать уведомление USE_TRANSPORT_MODE. Если ответчик отвергает запрос, CHILD_SA будет создаваться для туннельного режима. Если это неприемлено для инициатора, он должен удалить SA.

Примечание: Для всех SA с туннельным режимом, создаваемых IKEv2, должна выполняться декапсуляция, измененная в соответствии с [RFC4301].
HTTP_CERT_LOOKUP_SUPPORTED 16392 Это уведомление может включаться в любое сообщение, которое содержит элемент CERTREQ, и показывает, что отправитель может находить сертификаты по URL на основе HTTP (и, следовательно, будет предпочитать получение сертификатов в таком формате).
REKEY_SA 16393 Это уведомление должно включаться в обмен CREATE_CHILD_SA, если задачей обмена является замена существующей SA (ESP или AH). Поле SPI идентифицирует SA, для которой будут меняться ключи. Уведомление не включает данных.
ESP_TFC_PADDING_NOT_SUPPORTED 16394 Это уведомление заявляет, что передающая точка не будет принимать пакеты с заполнением TFC
NON_FIRST_FRAGMENTS_ALSO 16395 Служит для контроля фрагментации (см. [RFC4301]).
Резерв IANA — типы состояний 16396 - 40959
Для частного применения — типы состояний 40960 - 65535

3.11. Удаление

Элемент удаления (D) содержит определяемый протоколом идентификатор защищенной связи, которую отправитель удаляет из базы данных (следовательно, связь перестает быть корректной). Рисунок 17 Показывает формат элемента Delete. В этом элементе данных можно передавать множество SPI, однако все SPI должны относиться к одному протоколу. Смешивание идентификаторов протоколов в элементе Delete недопустимо. Однако в одном обмене INFORMATIONAL допускается использование множества уведомлений Delete с SPI для разных протоколов.

Удаление IKE_SA указывается значением идентификатора протокола 1 (IKE), а не значениями SPI. Удаление CHILD_SA (таких, как ESP или AH) будет включать идентификатор протокола IPsec (2 для AH, 3 для ESP) и значение SPI, которое передающая точка ожидает во входящих пакетах ESP ил AH.

Элемент Delete включает поля:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID   !   SPI Size    !           # of SPIs           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~               Security Parameter Index(es) (SPI)              ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 17: Формат удаления
  • Protocol ID (1 октет) — 1 для IKE_SA, 2 для AH, 3 для ESP.
  • SPI Size (1 октет) — размер (в октетах) SPI, определенного идентификатором протокола. Это поле должно иметь нулевое значение для IKE (SPI в заголовке сообщения) и значение 4 для AH и ESP.
  • # of SPIs (2 октета) — число SPI в данном элементе Delete. Размер каждого значения SPI определяется полем SPI Size.
  • Security Parameter Index(es) (переменный размер) — идентифицирует удалюяемую защищенную связь (связи). Размер этого поля определяется значением поля SPI Size и числом полей SPI.

Идентификатор типа для элемента Delete имеет значение 42.

3.12. Vendor ID

Элемент данных Vendor ID (V) содержит определенные производителем констант, которые служат для идентификации и распознавания удаленных реализаций данного производителя. Этот механизм позволяет производителям экспериментировать с новыми возможностями, обеспечивая совместимость со старыми версиями.

Элемент Vendor ID может анонсировать возможность отправителя работать с некими расширениями протокола или может просто идентифицировать реализацию (например, в целях отладки). Для элементов Vendor ID недопустимо изменять интерпретацию каких-либо данных, определенных в этой спецификации (например, бит критичности должен иметь значение 0). Возможна передача множества элементов Vendor ID. Реализации не обязана передавать элементы Vendor ID и может не использовать их совсем.

Элемент Vendor ID может передаваться в любом сообщении. Получение понятного элемента Vendor ID дает реализации возможность использовать значения, выделенные в этом документе для частного применения — частные элементы данных, типы обмена, уведомления и т.п. Непонятные элементы Vendor ID должны игнорироваться. Разработчики проектов протоколов (Internet-Draft), желающие расширить данный протокол, должны определить элемент Vendor ID для анонсирования возможности реализовать расширение из Internet-Draft. Предполагается, что получившие признание документы Internet-Draft, будут стандартизоваться с выделением значений из резервных блоков IANA и использование данного Vendor ID будет прекращаться.

Элемент Vendor ID имеет одно поле:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                        Vendor ID (VID)                        ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 18: Формат элемента Vendor ID
  • Vendor ID (переменный размер) — несмотря на отсутствие реестра идентификаторов на выбравшего значение Vendor ID ложится ответственность за уникальность этого идентификатора. Хорошим тоном является включение в идентификатор названия компании, имени разработчика и т.п. Можно также использовать географическую широту и долготу в комбинации со временем выбора значения или придумать иной уникальный идентификатор. Использование цифровой сигнатуры взамен длинных строк является предпочтительной практикой.

Идентификатор типа элемента данных Vendor ID имеет значение 43.

3.13. Элемент данных TS

Элемент данных Traffic Selector Payload (TS) позволяет партнерам идентифицировать потоки пакетов для обработки службами IPsec.

Элемент TS состоит из базового заголовка IKE, за которым следуют отдельные селекторы трафика:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of TSs !                 RESERVED                      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       <Traffic Selectors>                     ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 19: Формат элемента данных Traffic Selector
  • Number of TSs (1 октет) — число распространяемых селекторов трафика.
  • Резерв — это поле должно иметь нулевое значение при передаче и игнорироваться на приеме.
  • Traffic Selectors (переменный размер) — один или множество индивидуальных селекторов трафика.

Размер элемента TS учитывает заголовок TS и все селекторы трафика.

Идентификатор типа элемента TS имеет значение 44 для адресов на стороне инициатора и 45 для адресов на стороне ответчика.

3.13.1. Субструктура селектора трафика

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   TS Type     !IP Protocol ID*|       Selector Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Start Port*         |           End Port*           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                         Starting Address*                     ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                         Ending Address*                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 20: Селектор трафика

Примечение. Все поля, за исключением TS Type и Selector Length зависят от значения TS Type. Ниже поля показаны для TS Type 7 и 8 (единственные значения, определенные в настоящий момент).

  • TS Type (1 октет) — задает тип селектора трафика.
  • IP protocol ID (1 октет) — значение, показывающее идентификатор связанного протокола IP ID (например, UDP/TCP/ICMP). Нулевое значение говорит о неприменимости идентифкатора протокола к данному селектору трафика (SA может передавать все протоколы).
  • Selector Length — задает размер данной субструктуры Traffic Selector с учетом заголовка.
  • Start Port (2 октета) — задает минимальный номер порта, допустимый для данного селектора. Для протоколов, где порт не определен или разрешается использовать любые порты, это поле должно иметь значение 0. Для протокола ICMP два однооктетных поля Type и Code трактуются, как 16-битовое целое число (Type занимает старшие 8 битов, а Code — младшие), задающее номер порта для целей фильтрации по данному полю.
  • End Port (2 октета) — задает максимальный номер порта, допустимый для данного селектора. Для протоколов, где порт не определен или разрешается использовать любые порты, это поле должно иметь значение 65535. Для протокола ICMP два однооктетных поля Type и Code трактуются, как 16-битовое целое число (Type занимает старшие 8 битов, а Code — младшие), задающее номер порта для целей фильтрации по данному полю.
  • Starting Address — Наименьший адрес, включенный в данный селектор (размер определяется полем TS type).
  • Ending Address — Наибольший адрес, включенный в данный селектор (размер определяется полем TS type).

Системы, соответствующие [RFC4301] и желающие показать все порты (ANY), должны устанавливать для начального порта значение 0, а для конечного — 65535 (отметим, что, согласно [RFC4301], ANY включает OPAQUE). Системы, работающие с [RFC4301], и желающие показать порты OPAQUE, но не ANY, должны установить для начального порта значение 65535, а для конечного — 0.

В таблице показаны определенные к настоящему моменту значения поля Traffic Selector Type и соответствующие им адресные данные.

TS Type Значение
Резерв 0 - 6
TS_IPV4_ADDR_RANGE 7 Диапазон адресов IPv4, представленный двумя четырехоктетными значениями. Первое значение указывает начальный адрес диапазона, второе — конечный. Обе границы и все адреса между ними включаются в диапазон.
TS_IPV6_ADDR_RANGE 8 Диапазон адресов IPv4, представленный двумя шестнадцатиоктетными значениями. Первое значение указывает начальный адрес диапазона, второе — конечный. Обе границы и все адреса между ними включаются в диапазон.
Резерв IANA 9 - 240
Частное применение 241 - 255

3.14. Элемент Encrypted

Элемент Encrypted, обозначаемый в этом документе SK{...} или E, содержит другие элементы в зашифрованном виде. При наличии в сообщении элемента Encrypted этот элемент должен быть последним в сообщении. Часто этот элемент является единственным элементом данных в сообщении.

Алгоритмы шифрования и защиты целостности согласуются при организации IKE_SA, а ключи расчитываются в соответствии с параграфими 2.14 и 2.18.

Алгоритмы шифрования и защиты целостности применяются после алгоритмов ESP, описанных в RFC 2104 [KBC96], 4303 [RFC4303] и 2451 [ESPCBC]. В данном документе полностью описана криптографическая обработка данных IKE, а упомянутые документы следует рассматривать обоснование дизайна. Мы требуем блочного шифрования с фиксированным размером блока и алгоритма защиты целостности с фиксированным размером контрольной суммы независимо от размера сообщения.

Идентификатор типа для элемента Encrypted имеет значение 46. Элемент Encrypted включает базовый заголовок IKE и перечисленные ниже поля.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                     Initialization Vector                     !
!         (length is block size for encryption algorithm)       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Encrypted IKE Payloads                     ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!               !             Padding (0-255 octets)            !
+-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
!                                               !  Pad Length   !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Integrity Checksum Data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 21: Формат зашифрованных данных
  • Next Payload — тип первого вложенного элемента данных. Отметим, что это отличается от стандартного формата заголовка IKE — элемент Encrypted является в сообщении последним и, следовательно, значение поля Next Payload в обычных условиях было бы равно 0. Но, поскольку этот элемент содержит в себе другие элементы и нет другого логичного места для указания типа первого элемента, было выбрано это поле.
  • Payload Length — размер элемента с учетом заголовка IV, Encrypted IKE Payloads, Padding, Pad Length и Integrity Checksum Data.
  • Initialization Vector — случайное значение, размер которого совпадает с размером блока используемого алгоритма шифрования. Получатели должны воспринимать любые значения. Отправителям следует следует генерировать псевдо-случайное значение независимо для каждого сообщения или использовать для выбора значений шифрованный блок предыдущего сообщения. Для отправителя недопустимо использовать одно значение для всех сообщений, последовательности с малым расстоянием Хэмминга (например, порядковые номера) или шифрованные данные из предыдущего принятого сообщения.
  • IKE Payloads в соответствии с приведенным выше описанием. Это поле шифруется с использованием согласованного алгоритма.
  • Поле Padding может содержать любое значение, выбранное отправителем и должно иметь размер, делающий суммарный размер шифрованных элементов, поля Padding и поля Pad Length кратным размеру блока шифрования. Это поле шифруется с использованием согласованного алгоритма.
  • Pad Length — размер поля Padding. Этправителю следует устанавливать в поле Pad Length минимальное значение, которое делает размер полей шифрованных элементов, Padding и Pad Length кратным размеру блока шифрования, но получатель должен принимать любые значения, обеспечивающие требуемое выравнивание. Это поле шифруется с использованием согласованного алгоритма.
  • Integrity Checksum Data — криптографическая контрольная сумма всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем Pad Length. Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля определяется согласованным алгоритмом защиты целостности.

3.15. Конфигурация

Элемент данных Configuration (CP) используется для обмена конфигурационными параметрами между партнерами IKE. Такой обмен включает запрос клиентом IRAC внутреннего адреса IP у сервера IRAS, а также обмен другими данными в процессе получения адреса по протоколу DHCP, если клиент IRAC подключен непосредственно к ЛВС.

Элемент Configuration может принимать тип CFG_REQUEST/CFG_REPLY или CFG_SET/CFG_ACK (см. описание поля CFG Type ниже). Элементы CFG_REQUEST и CFG_SET могут добавляться к любому запросу IKE. отклик IKE должен включать соответствующий элемент CFG_REPLY, CFG_ACK или уведомление (элемент Notify) с кодом ошибки, показывающим причину невозможности выполненияя запроса. Исключением являются минимальные реализации, которые могут игнорировать все элементы CFG_REQUEST и CFG_SET, поэтому отклик без соответствующего элемента CFG_REPLY или CFG_ACK должен приниматься и трактоваться, как индикация того, что запрос не поддерживается.

CFG_REQUEST/CFG_REPLY позволяет конечной точке IKE запросить информацию у партнера. Если значение атрибута в элементе Configuration типа CFG_REQUEST отлично от 0, такой запрос воспринимается, как предложение для данного атрибута. Элемент Configuration типа CFG_REPLY может возвратить это значение или предложить другое. Он может также добавить новые атрибуты и не включать некоторые из запрошенных. Запрашивающая сторона должна игнорировать атрибуты, которые она не способна распознать.

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

Если тип данных, запрошенных в CFG_REQUEST, не распознан или не поддерживается, ответчику недопустимо возвращать ошибку — вместо этого он должен передать элемент CFG_REPLY, который может быть пустым, или вернуть отклик без CFG_REPLY. Возврат ошибки зарезервирован для случаев, когда запрос распознан, но не может быть выполнен должным образом, или запрос имеет некорректный формат.

CFG_SET/CFG_ACK позволяет конечной точке IKE «вытолкнуть» конфигурационные данные своему партнеру. В этом случае элемент Configuration типа CFG_SET содержит атрибуты, которые инициатор хочет изменить у своего партнера. Ответчик должен вернуть элемент Configuration, если он принимает какие-нибудь конфигурационные данные. Этот отклик должен содержкать воспринятые ответчиком атрибуты без данных (данные нулевой длины). Непринятые атрибуты недопустимо включать в CFG_ACK Configuration. Если не был принят ни один из атрибутов, ответчик должен вернуть пустой элемент типа CFG_ACK или отклик без элемента CFG_ACK. В настоящее время использование обмена CFG_SET/CFG_ACK не определено, хотя такой обмен может применяться в соединениях с расширениями на базе Vendor ID. Минимальные реализации данной спецификации могут игнорировать элементы CFG_SET.

Расширения через элемент CP не следует использовать для управления общего типа. Основным назначением такого расширения является обеспечение механизма загрузки с обменом информацией IPsec между IRAS и IRAC. Хотя такой подход может применяться в качестве метода обмена информацией между защитными шлюзами (SGW) или небольшими сетями, для управления крупными сетями и повторяющихся информационных обменов предпочтительно использовать существующие протоколы управления типа DHCP [DHCP], RADIUS [RADIUS], SNMP или LDAP [LDAP].

Рисунок 22 иллюстрирует формат элемента данных Configuration.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C! RESERVED    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   CFG Type    !                    RESERVED                   !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Configuration Attributes                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 22: Формат конфигурационных данных

Идентификатор типа элемента Configuration имеет значение 47.

  • CFG Type (1 октет) — тип обмена, представленного атрибутами элемента Configuration. Определенные значения типов показаны в таблице. Значения 5-127 зарезервированы IANA, значения 128-255 выделены для частного применения по согласованию сторон.
    CFG Type Значение
    Резерв 0
    CFG_REQUEST 1
    CFG_REPLY 2
    CFG_SET 3
    CFG_ACK 4
  • Резерв (3 октета) — должно устанавливаться в 0 при передаче и игнорироваться на приеме.
  • Configuration Attributes (переменные размер) — атрибуты конфигурации в формате «тип-размер-значение», описанные ниже. В элементе Configuration может содержаться множество (в том числе, пустое) атрибутов.

3.15.1. Атрибуты конфигурации

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R|         Attribute Type      !            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 23: Формат атрибута конфигурации
  • Резерв (1 бит) — должен устанавливаться в 0 при передаче и игнорироваться на приеме.
  • Attribute Type (15 битов) — уникальный идентификатор для каждого типа атрибутов конфигурации.
  • Length (2 октета) — размер поля Value в октетах.
  • Value (0 или более октетов) — поле переменного размера, содержащее значение атрибута конфигурации.

Определенные в данное время типы атрибутов показаны в таблице. Значения типов 16 - 16383 зарезервированы IANA, диапазон значений 16384-32767 выделен для частного применения по согласованию сторон.

Тип атрибута Значение Многозначный Размер
Резерв 0
INTERNAL_IP4_ADDRESS 1 Да* 0 или 4 октета
INTERNAL_IP4_NETMASK 2 Нет 0 или 4 октета
INTERNAL_IP4_DNS 3 Да 0 или 4 октета
INTERNAL_IP4_NBNS 4 Да 0 или 4 октета
INTERNAL_ADDRESS_EXPIRY 5 Нет 0 или 4 октета
INTERNAL_IP4_DHCP 6 Да 0 или 4 октета
APPLICATION_VERSION 7 Нет 0 или более октетов
INTERNAL_IP6_ADDRESS 8 Да* 0 или 17 октетов
Резерв 9
INTERNAL_IP6_DNS 10 Да 0 или 16 октетов
INTERNAL_IP6_NBNS 11 Да 0 или 16 октетов
INTERNAL_IP6_DHCP 12 Да 0 или 16 октетов
INTERNAL_IP4_SUBNET 13 Да 0 или 8 октетов
SUPPORTED_ATTRIBUTES 14 Нет кратно 2
INTERNAL_IP6_SUBNET 15 Да 17 октетов

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

  • INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS — адрес внутренней сети, иногда называемый адресом красного узла (red node address) или приватным адресом, который может быть приватным адресом в сети Internet. Указанный в запросе адрес является запрашиваемым; если в запросе указан 0, это говорит о том, что адрес не запрашивается. Если запрошен конкретный адрес, это скорей всего говорит о том, что ранее существовало соединение с таким адресом и запрашивающий узел хочет снова использовать данный адрес. В IPv6 запрашивающий узел может укаазать младшие байты желаемого адреса. Можно запросить множество внутренних адресов, запрашивая множество атрибутов для внутреннего адреса. Ответчик может вернуть число адресов, не превышающее запрошенное количество. INTERNAL_IP6_ADDRESS может включать до двух полей, первое из которых содержит шестнадцатиоктетный адрес IPv6, а второе — однооктетный размер префикса, как определено в [ADDRIPV6]. Запрашиваемый адрес остается корректным до окончания срока его действия, заданного атрибутом INTERNAL_ADDRESS EXPIRY, или до завершения всех IKE_SA между партнерами.

  • INTERNAL_IP4_NETMASK — внутренняя маска сети. В запросах и откликах может содержаться только одна маска (например, 255.255.255.0) и она должна использоваться только с атрибутом INTERNAL_IP4_ADDRESS.

  • INTERNAL_IP4_DNS, INTERNAL_IP6_DNS — задает адрес сервера DNS внутри сети. Можно запрашивать адреса множества серверов DNS. Ответчик может возвращать 0 или более атрибутов серверов DNS.

  • INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS — задает адрес сервера имен NetBios (WINS) внутри сети. Можно запрашивать адреса множества серверов NBNS. Ответчик может возвращать 0 или более атрибутов серверов NBNS.

  • INTERNAL_ADDRESS_EXPIRY — задает время (в секундах), в течение которого хост может использовать внутренний адрес IP. Хост должен обновить IP-адрес до завершения срока его аренды. В отклике может присутствовать только один такой атрибут.

  • INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP — говорит хосту о необходимости отправки всех внутренних запросов DHCP по адресу, содержащемуся в этом атрибуте. Можно запрашивать адреса множества серверов DHCP. Ответчик может возвращать 0 или более атрибутов серверов DHCP.

  • APPLICATION_VERSION — версия или прикладные данные хоста IPsec, заданная в форме строки печатаемых символов ASCII без null-символа завершения.

  • INTERNAL_IP4_SUBNET — защищенная данным краевым устройством подсеть. Этот атрибут может содержать до двух полей, первое из которых задает адрес IP, а второе — маску. Можно запрашивать множество подсетей. Ответчик может возвращать 0 или более атрибутов подсетей.

  • SUPPORTED_ATTRIBUTES — при использовании в запросе этот атрибут должен иметь нулевой размер и задает запрос ответчику на получение всех поддерживаемых им атрибутов. Отклик содержит атрибут, который включает набор идентификаторов атрибутов (по 2 октета в каждом). Размер данного атрибута, поделенный на 2 (октета) будет показывать число включенных в отклик поддерживаемых атрибутов.

  • INTERNAL_IP6_SUBNET — защищенная данным краевым устройством подсеть. Этот атрибут может содержать до двух полей, первое из которых задает шестнадцатиоктетный адрес IPv6, а второй однооктетный размер префикса, как определено в [ADDRIPV6]. Можно запрашивать множество подсетей. Ответчик может возвращать 0 или более атрибутов подсетей.

Отметим, что в этом документе не дается рекомендаций по выбору информации, которую реализация будет возвращать в откликах. В частности, мы не даем каких-либо рекомендаций в части определения сервером IRAS сервера DNS, адрес которого следует возвращать по запросам IRAC.

3.16. Элемент EAP

Элемент Extensible Authentication Protocol (EAP) позволяет выполнять идентификацию IKE_SA с использованием протокола, определенного в RFC 3748 [EAP] и его последующих расширений. that protocol. Полный набор приемлемых значений выходит за пределы этой спецификации, однако краткий перечень значений из RFC 3748 включен в документ для использования в наиболее общих случаях.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       EAP Message                             ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 24: Формат EAP

Идентификатор типа для элемента данных EAP Payload имеет значение 48.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Code      ! Identifier    !           Length              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Type      ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Рисунок 25: Формат сообщения EAP

  • Code (1 октет) показывает, является это сообщение запросом (Request — 1), откликом (Response — 2), успешным завершением (Success — 3) или отказом (Failure — 4).

  • Identifier (1 октет) используется в PPP, чтобы отличить повторное использование сообщений от повторной передачи. Поскольку в IKE протокол EAP работает на базе протокола с гарантированной доставкой, использование идентификатора смысла не имеет. В откликах этот октет должен устанавливаться равным значению идентификатора в соответствующем запросе. В остальных сообщениях это поле может принимать любое значение.

  • Length (2 октета) показывает размер сообщения EAP и должно быть в 4 раза меньше значения поля Payload Length инкапсулирующего элемента.

  • Type (1 октет) присутствует только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а поля Type и Type_Data должны отсутствовать. В запросах (1) поле Type показывает запрашиваемые данные, а в откликах (2) поле Type должно быть пустым или соответствовать типу запрошенных данных В RFC 3748 определены следующие типы:

    1. Identity — тождественность
    2. Notification — уведомление
    3. Nak (только отклики)
    4. MD5-Challenge
    5. One-Time Password (OTP) — однократный пароль
    6. Generic Token Card — маркерная карта базового типа

  • Type_Data (переменный размер) зависит от типа запроса и связанного с ним отклика. Дополнительная информация по методам EAP приведена в работе methods, see [EAP].

Поскольку IKE передает идентификацию инициатора в протокольном сообщении с номером 3, ответчику не следует передавать запросы EAP Identity. Инициатору следует, однако, отвечать на такие запросы при их получении.

4. Требования по совместимости

Для обеспечения интероперабельности всех реализаций IKEv2 вводятся специальные требования «необходимо поддерживать» (MUST support) в дополнение к другим требованиям. IKEv2 является протоколом защиты и одной из его основных функций является предоставление возможности организации SA только уполномоченным сторонам. Поэтому конкретная реализаця может быть настроена с любыми ограничениями по части алгоритмов и удостоверяющих центров, что вступает в противоречие с всеобщей интероперабельностью.

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

  • возможность согласования SA через NAT и туннель, приводящая к организации ESP SA с использованием UDP;
  • возможность запрашивать (и отдавать по запросу) временный адрес IP на удаленной стороне туннеля;
  • возможность поддерживать различные типы унаследованной идентификации;
  • возможность поддерживать окна размером более 1;
  • возможность организации множества SA (ESP и/или AH) в одной IKE_SA;
  • возможность замены ключей SA.

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

Каждая реализация должна быть способна выполнять обмен 4 сообщениями IKE_SA_INIT и IKE_AUTH, обеспечивающий организацию двух SA (одна для IKE, одна для ESP и/или AH). Реализации могут работать в режиме «только инициатор» или «только ответчик», если это подходит для используемой платформы. Каждая реализация должна быть способна отвечать на обмен INFORMATIONAL, но минимальные реализации могут отвечать на любое сообщение INFORMATIONAL пустым откликом INFORMATIONAL (отметим, что в контексте IKE_SA «пустое» сообщение состоит из заголовка IKE, за которым следует элемент Encrypted без вложенных в него элементов). Минимальная реализация может поддерживать обмен CREATE_CHILD_SA лишь для случаев, когда запрос распознан и отвергнут с уведомлением типа NO_ADDITIONAL_SAS. От минимальных реализаций не требуется возможность инициирования обменов CREATE_CHILD_SA или INFORMATIONAL. Когда срок жизни SA истекает (по локальному значению времени жизни или числу переданных октетов), реализация может попытаться обновить связь с помощью обмена CREATE_CHILD_SA или может удалить (закрыть) SA и создать новую. Если ответчик отвергает запрос CREATE_CHILD_SA с передачей уведомления NO_ADDITIONAL_SAS, реализация должна быть способна взамен закрыть старую SA и создать новую.

Реализации не обязаны поддерживать возможность запроса временных адресов IP и отклики на такие запросы. Если реализация поддерживает создание таких запросов, она должна включать в сообщение 3 элемент данных CP, содержащий по крайней мере поле типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Все остальные поля являются необязательными. Если реализация поддерживает отклики на такие запросы, она должна разбирать элемент CP типа CFG_REQUEST в сообщении 3 и распознавать поля типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Если реализация поддерживает выдачу временных адресов запрошенного типа, она должна возвратить элемент CP типа CFG_REPLY, содержащий адрес запрошенного типа. Ответчику следует включать все остальные связанные с адресом атрибуты, если они имеются.

Минимальная реализация ответчика IPv4 будет игнорировать все содержимое элемента CP, кроме атрибута INTERNAL_IP4_ADDRESS, и будет отвечать на сообщение с включением адреса и других атрибутов, независимо от того, что запрашивал инициатор.

Минимальная реализация инициатора IPv4 будет генерировать элементы CP, содержащие только атрибут INTERNAL_IP4_ADDRESS и разбирать полученный отклик, игнорируя атрибуты, которые она не может использовать. Единственным атрибутом, который должна обрабатывать такая реализация, является атрибут INTERNAL_ADDRESS_EXPIRY, ограничивающий время жизни SA, если она не будет обновлена до завершения срока жизни. От минимальной реализации инициатора не требуется поддержка запросов на обновление аренды адреса, а минимальные реализации ответчиков не поддерживают откликов на такие запросы.

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

  • сертификатов PKIX, содержащих ключи RSA размером 1024 или 2048 и подписанных с использованием таких ключей, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR или ID_DER_ASN1_DN;
  • идентификации с разделяемым ключом, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN или ID_RFC822_ADDR;
  • идентификации в случаях идентифицирования ответчика с использованием сертификатов PKIX, а инициатора с использованием разделяемого ключа.

5. Вопросы безопасности

Хотя протокол разработан так, чтобы минимизировать раскрытие конфигурационной информации неуполномоченным партнерам, некоторое раскрытие все-таки неизбежно. Один из партнеров в любом случае должен сначала идентифицировать себя и подтвердить эту идентификацию. Для того, чтобы предотвратить зондирование к инициаторам обмена предъявляется требование идентифицировать первым и первым предъявить свои полномочия. Однако инициатор может узнать, что ответчик поддерживает IKE и определить поддерживаемые им криптографические протоколы. Ответчик (или кто-нибудь, прикидывающийся таковым) может не только проверить идентификацию инициатора, но и с помощью элементов CERTREQ определить, какие сертификаты желает использовать инициатор.

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

Повторяющаяся замена ключей с использованием CREATE_CHILD_SA без дополнительных обменов Diffie-Hellman делает все SA уязвимыми для криптоанализа одного ключа или перегрузки (overrun) другой точки. Разработчикам следует отметить этот факт и установить предел для числа обменов CREATE_CHILD_SA между сторонами. В этом документе данный предел не задается.

Стойкость ключей, созданных в результате обмена Diffie-Hellman с использованием любой из определенных здесь групп, зависит от стойкости самой группы, размера используемой экспоненты и энтропии при генерации случайных значений. По причине большого числа влияющих на стойкость факторов сложно определить стойкость ключа для любой из определенных групп. Группа Diffie-Hellman номер 2 при использовании с качественным генератором случайных чисел и экспонентой не менее 200 битов является общепринятой для 3DES. Группа 5 обеспечивает лучшую защиту по сравнению с группой 2. Группа 1 сохранена в качестве достояния истории и не обеспечивает достаточной защиты за исключением случаев использования с алгоритмом DES, который тоже стал уже достоянием истории. Разработчикам следует принимать во внимание эти оценки при выборе политики и согласовании параметров защиты.

Отметим, что отмеченные выше ограничения относятся к самим группам Diffie-Hellman. В IKE нет запретов на использование более сильных групп и ничто не снижает уровень стойкости, обеспечиваемый наиболее сильными группами (уровень стойкости ограничивается только выбранными при согласовании алгоритмами, включая функцию prf). Фактически, расширяемая схема IKE поощряет определение новых групп; использование групп эллиптических кривых позволяет существенно повысить уровень стойкости при использовании значительно меньших чисел.

Предполагается, что все экспоненты Diffie-Hellman удаляются из памяти после использования. В частности, такие экспоненты недопустимо создавать на базе долгоживущих секретов типа «затравок» (seed) генератора случайных чисел, которые не уничтожаются после использования.

Тойкость всех ключей ограничивается размером результата согласованной функции prf. По этой причине функции prf, выходное значение которых имеет размер менее 128 битов (например, 3DES-CBC) недопустимо использовать с протоколом IKEIKEIKE.

Безопасность данного протокола критически зависит от уровня случайности параметров, использующих случайные значения. Случайные числа должны генерироваться качественным генератором случайных чисел или источником псевдо-случайных чисел с подходящей «затравкой» (см. [RFC4086]). Разработчикам следует обеспечить гарантии того, что использование случайных чисел для создания ключей и nonce не может приводить к снижению уровеня защиты ключей.

Для информации о причинах выбора многих криптографических параметров протокола рекомендуется обратиться к работам [SIGMA] и [SKEME]. Хотя защита согласованных CHILD_SA не зависит от стойкости алгоритмов шифрования и защиты целостности, выбранных для IKE_SA, реализациям недопустимо согласовывать использование NONE в качестве алгоритма защиты целостности IKE или ENCR_NULL в качестве алгоритма шифрования IKE.

При использовании разделяемый (pre-shared) ключей критически важным становится вопрос уровня случайности этих секретов. Жесткая практика требует обеспечения для этих ключей уровня случайности не меньше, чем у самого строго из согласуемых ключей. Создание разделяемых ключей из паролей, имен или других источников с малой энтропией не обеспечивает нужной защиты. Такие источники не обеспечивают устойчивости к атакам по словарю и использованию методов социальной психологии, а также к другим атакам.

Уведомления NAT_DETECTION_*_IP содержат хэш адресов и портов для сокрытия внутренней структуры сети IP, расположенной за устройством NAT. Поскольку пространство адресов IPv4 включает лишь 32 бита и обычно очень разбросано, атакующий может найти внутренние адреса, скрытые NAT простым перебором всех возможных адресов IP и сравнением хэш-значений. Номера портов обычно содержат фиксированное значение 500, а значения SPI можно выделить из пакетов. Это снижает число попыток расчета хэш-значений жо 2^32. Когда можно обоснованно предположить использование адресов из приватных блоков, объем расчетов дополнительно сокращается во много раз. Разработчикам, в результате, не следует полагаться на то, что использование IKE гарантирует отсутствие утечки адресной информации.

При использовании методов идентификации EAP без генерации разделяемых ключей для защиты последующих элементов данных AUTH становятся возможными некоторые MITM-атаки и атаки с подставными серверами [EAPMITM]. Такие уязвимости возникают при использовании EAP с протоколами, которые не защищены безопасным туннелем.

Поскольку EAP является протоколом идентификации общего назначения, который часто используется в системах с единым входом, развернутое решение IPsec, которое опирается на идентификацию EAP без генерации разделяемого ключа (этот метод также называют EAP без генерации ключей), может быть скомпрометировано в результате развертывания совершенно не связанных с ним приложений, использующих тот же метод EAP без генерации ключей, но не обеспечивающих должной защиты. Отметим, что эта уязвимость не связана только с EAP, но может возникать и в других сценариях с повторным использованием инфораструктуры идентификации. Например, если механизм EAP, используемый IKEv2, основан на маркерных идентификаторах, организатор MITM-атаки может использовать подставной web-сервер, перехватить идентификационный обмен с использованием маркера и применить результат для организации соединения IKEv2. По этой причине следует избегать по возможности использования методов EAP без генерации ключей. При использовании таких методов крайне следует применять такие методы EAP только в защищенных туннелях, когда инициатор проверяет сертификат ответчика до начала обмена EAP. Разработчикам следует описывать уязвимость использования методов EAP без генерации ключей в своих реализациях так, чтобы администраторы при развертывании решений IPsec осознавали возможные риски.

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

Если сообщения IKEv2 слишком велики и требуется фрагментация на уровне IP, атакующие могут заблокировать завершение обмена путем опустошения ресурсов (заполнения буферов) для сборки фрагментов. Вероятность такого исхода можно минимизировать за счет использования кодирования «Hash and URL» вместо передачи сертификатов (см. параграф 3.6). Дополнительные меры по снижению рисков обсуждаются в работе [KPS03].

6. Согласование с IANA

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

Агенство IANA создало перечисленные ниже реестры:

  • IKEv2 Exchange Types (параграф 3.1)
  • IKEv2 Payload Types (параграф 3.2)
  • IKEv2 Transform Types (параграф 3.3.2)
  • IKEv2 Transform Attribute Types (параграф 3.3.2)
  • IKEv2 Encryption Transform IDs (параграф 3.3.2)
  • IKEv2 Pseudo-random Function Transform IDs (параграф 3.3.2)
  • IKEv2 Integrity Algorithm Transform IDs (параграф 3.3.2)
  • IKEv2 Diffie-Hellman Transform IDs (параграф 3.3.2)
  • IKEv2 Identification Payload ID Types (параграф 3.5)
  • IKEv2 Certificate Encodings (параграф 3.6)
  • IKEv2 Authentication Method (параграф 3.8)
  • IKEv2 Notify Message Types (параграф 3.10.1)
  • IKEv2 Notification IPCOMP Transform IDs (параграф 3.10.1)
  • IKEv2 Security Protocol Identifiers (параграф 3.3.1)
  • IKEv2 Traffic Selector Types (параграф 3.13.1)
  • IKEv2 Configuration Payload CFG Types (параграф 3.15)
  • IKEv2 Configuration Payload Attribute Types (параграф 3.15.1)

Изменения и дополнения перечисленных реестров осуществляются после экспертизы (процедура expert review).

7. Благодарности

Этот документ является результатом совместных усилий рабочей группы IPsec. Если бы не было ограничений на количество авторов RFC, следовало бы указать всех перечисленных ниже в алфавитном порядке людей — Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingold и Michael Richardson. Множество других людей также внесло свой вклад. Это работы по развитию IKEv1, ISAKMP и IPsec DOI, каждая из которых имеет свой авторский колектив. Hugh Daniel предложил включить нахождение инициатора (в сообщении 3), задал имя для ответчика и дал имя функции «You Tarzan, Me Jane». David Faucher и Valery Smyzlov помогли усовершенствовать процесс согласования селекторов трафика.

8. Литература

8.1. Нормативные документы

[ADDGROUP] Kivinen, T. и M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, Май 2003.
[ADDRIPV6] Hinden, R. и S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 3513, Апрель 2003.
[Bra97] Bradner, S., «Key Words for use in RFCs to indicate Requirement Levels», BCP 14, RFC 2119, Март 1997.
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, «Расширяемый протокол идентификации (EAP)», RFC 3748, Июнь 2004.
[ESPCBC] Pereira, R. и R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, Ноябрь 1998.
[Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, «UDP Encapsulation of IPsec ESP Packets», RFC 3948, Январь 2005.
[RFC2434] Narten, T. и H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «Добавление явных уведомлений о перегрузке (ECN) в IP», RFC 3168, Сентябрь 2001
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, Апрель 2002.
[RFC4301] Kent, S. и K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, Декабрь 2005.

8.2. Дополнительная литература

[DES] ANSI X3.106, «American National Standard for Information Systems-Data Link Encryption», American National Standards Institute, 1983.
[DH] Diffie, W., and Hellman M., «New Directions in Cryptography», IEEE Transactions on Information Theory, V. IT-22, n. 6, Июнь 1977.
[DHCP] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, Март 1997.
[DSS] NIST, «Digital Signature Standard», FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994.
[EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., «Man-in-the-Middle in Tunneled Authentication Protocols», Ноябрь 2002
[HC98] Harkins, D. и D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, Ноябрь 1998.
[IDEA] Lai, X., «On the Design and Security of Block Ciphers», ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, «Протокол компрессии данных IP (IPComp)», RFC 3173, Сентябрь 2001.
[KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., «DoS protection for UDP-based protocols», ACM Conference on Computer and Communications Security, Октябрь 2003.
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, Февраль 1997.
[LDAP] Wahl, M., Howes, T., and S Kille, «Lightweight Directory Access Protocol (v3)», RFC 2251, Декабрь 1997.
[MD5] Rivest, R., «Алгоритм цифровых подписей MD5», RFC 1321, Апрель 1992.
[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, Ноябрь 1998.
[Orm96] Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, Ноябрь 1998.
[PFKEY] McDonald, D., Metz, C., and B. Phan, «PF_KEY Key Management API, Version 2», RFC 2367, Июль 1998.
[PKCS1] Jonsson, J. и B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, Февраль 2003.
[PK01] Perlman, R., and Kaufman, C., «Analysis of the IPsec key exchange Standard», WET-ICE Security Conference, MIT,2001
[Pip98] Piper, D., «The Internet IP Security Domain Of Interpretation for ISAKMP», RFC 2407, Ноябрь 1998.
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Протокол RADIUS», RFC 2865, Июнь 2000.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, Июнь 2005.
[RFC1958] Carpenter, B., «Architectural Principles of the Internet», RFC 1958, Июнь 1996.
[RFC2401] Kent, S. и R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, Ноябрь 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, Декабрь 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «Архитектура дифференцированного обслуживания (Diffserv)», RFC 2475, Декабрь 1998
[RFC2522] Karn, P. и W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, Март 1999.
[RFC2775] Carpenter, B., «Internet Transparency», RFC 2775, Февраль 2000.
[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, Октябрь 2000.
[RFC3439] Bush, R. и D. Meyer, «Some Internet Architectural Guidelines and Philosophy», RFC 3439, Декабрь 2002.
[RFC3715] Aboba, B. и W. Dixon, «Требования по совместимости NAT и протколов IPsec-архитектуры», RFC 3715, Март 2004.
[RFC4302] Kent, S., «Идентификационный заголовок IP», RFC 4302, Декабрь 2005
[RFC4303] Kent, S., «Инкапсуляция защищенных данных IP (ESP)», RFC 4303, Декабрь 2005.
[RSA] Rivest, R., Shamir, A., and Adleman, L., «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», Communications of the ACM, v. 21, n. 2, Февраль 1978.
[SHA] NIST, «Secure Hash Standard», FIPS 180-1, National Institute of Standards and Technology, U.S. Department of Commerce, Май 1994.
[SIGMA] Krawczyk, H., «SIGMA: the «SIGn-and-MAc» Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols», in Advances in Cryptography — CRYPTO 2003 Proceedings, LNCS 2729, Springer, 2003
[SKEME] Krawczyk, H., «SKEME: A Versatile Secure Key Exchange Mechanism for Internet», from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security.
[X.501] ITU-T Recommendation X.501: Information Technology — Open Systems Interconnection — The Directory: Models, 1993.
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology — Open Systems Interconnection — The Directory: Authentication Framework, Июнь 1997.

Приложение A: Список отличий от IKEv1

Задачами этого пересмотра IKE явились:

  1. определение протокола IKE в едином документе взамен RFC 2407, 2408, a2409 и последующих изменений в части добавления работы через NAT, расширяемой идентификации (EAP) P) и получения удаленных адресов;
  2. упрощение IKE за счет замены 8 разных начальных обменов одним обменом из 4 сообщений (с изменением механизмов идентификации, воздействующих только на один элемент AUTH вместо реструктуризации всего обмена), см. [PK01];
  3. удаление полей области интерпретации (DOI), ситуации (SIT) и помеченных идентификаторов доменов, а также битов Commit и Authentication;
  4. снижение задержки IKE в общем случае за счет сведения изначального обмена к 2 периодам кругового обхода (4 сообщения) и разрешения организации CHILD_SA в этом обмене;
  5. To replace the cryptographic syntax for protecting the IKE messages themselves with one based closely on ESP to simplify implementation and security analysis;
  6. снижение числа возможных ошибочных состояний за счет обеспечения гарантий доставки (все сообщения подтверждаются) и упорядочивания, позволивших сократить обмены CREATE_CHILD_SA с 3 сообщений до 2;
  7. повышение отказоустойчивости за счет предоставления ответчику возможности не выполнять существенной обработки до подтверждения инициатором возможности приема сообщений по заявленному им адресу IP и не менять состояния обмена, пока инициатор не будет криптографически идентифицирован;
  8. устранение криптографических недостатков типа проблем с симметрией в хэш-значениях, используемых для идентификации, документированной Tero Kivinen;
  9. задание селекторов трафика в специальных элементах данных вместо перегрузки информацией элементов ID и более гибкое указание селекторов трафика;
  10. задание поведения при возникновении некоторых ошибок или при получении непонятных данных для упрощения совместимости с будущими версиями;
  11. упрощение и прояснение поддержки разделяемых состояний при возникновении ошибок в сети или DoS-атаках;
  12. поддержка существующего синтаксиса и «магических» значений для упрощения поддержки в реализациях IKEv1 расширения для работы с IKEv2 при минимальных затратах.

Приложение B: Группы Diffie-Hellman

Имеется две группы Diffie-Hellman, определенных здесь для использования в протоколе IKE. Эти группы создал Richard Schroeppel из Университета штата Аризона. Свойства этих примитивов описаны в работе [Orm96].

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

Дополнительные группы Diffie-Hellman определены в работе [ADDGROUP].

B.1. Группа 1 — 768 Bit MODP

Этой группе присвоен идентификатор 1 (один).

Примитив имеет значение: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }, а его шестнадцатеричная форма:

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A63A3620 FFFFFFFF FFFFFFFF

Генератор имеет значение 2.

B.2. Группа 2 — 1024 Bit MODP

Этой группе присвоен идентификатор 2 (два).

Примитив имеет значение 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }, а его шестнадцатеричная форма:

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE65381 FFFFFFFF FFFFFFFF

Генератор имеет значение 2.

Адрес автора

Charlie Kaufman
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
Phone: 1-425-707-3335
EMail: moc.tfosorcim@keilrahc

2007 - 2022 © Русские переводы RFC, IETF, ISOC.