Please enter banners and links.
Network Working Group C. Kaufman, Ed. Request for Comments: 4306 Microsoft Obsoletes: 2407, 2408, 2409 December 2005 Category: Standards Track
Протокол обмена ключами в Internet (IKEv2)
Internet Key Exchange (IKEv2) Protocol
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2005).
Тезисы
В этом документе описана версия 2 протокола обмена ключами в Internet (IKE1). Протокол IKE является частью IPsec и служит для обоюдной аутентификации партнеров, организации и поддержки защищенных связей (SA2).
Эта версия спецификации IKE объединяет содержимое нескольких отдельных документов прежних версий, включая ISAKMP3 (RFC 2408), IKE (RFC 2409), DOI4 (RFC 2407), спецификация работы через NAT5, унаследованную аутентификацию и получение удаленного адреса.
Версия 2 протокола IKE не совместима с версией 1, но имеет достаточно много общего в формате заголовков и обе версии однозначно могут работать через один и тот же порт UDP.
Оглавление
Исключено в версии HTML.
1. Введение
Протоколы защиты IP (IPsec6) обеспечивает конфиденциальность, целостность данных, контроль доступа, а также аутентификацию источника данных для дейтаграмм 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 для протоколов ESP7 [RFC4303] и/или AH8 [RFC4302], и набор криптографических алгоритмов, которые будут использоваться SA для защиты передаваемого трафика. В этом документе термины «набор» (suite) или «шифронабор» (cryptographic suite) обозначают все множество алгоритмов, используемых для защиты SA. Инициатор предлагает один или несколько наборов, перечисляя поддерживаемые им алгоритмы, которые могут быть объединены в наборы или использоваться «вперемешку». IKE может также согласовывать использование компрессии IP (IPComp9) [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 для протоколов ESP и/или AH SAs во множестве различных сценариев с отличающимися требованиями.
1.1.1. Туннель между защитными шлюзами
+-+-+-+-+-+ +-+-+-+-+-+
!Конечная ! Туннель !Конечная !
Защищенная !точка ! IPsec !точка ! Защищенная
подсеть <-->!туннеля !<---------->!туннеля !<--> подсеть
! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+
Рисунок 1. Туннель между защитными шлюзами
В этом сценарии ни одна из конечных точек соединений IP не поддерживает IPsec, но расположенные между конечными точками узлы сетей обеспечивают защиту трафика на пути передачи. Защита прозрачна для конечных точек и пакеты через обычную систему маршрутизации передаются в конечную точку туннеля для обработки. Каждая из конечных точек туннеля будет анонсировать множество расположенных за ней адресов и пакеты для этих адресов будут передаваться в туннель с адресом конечного получателя во внутреннем заголовке IP.
1.1.2. Туннель между конечными точками
+-+-+-+-+-+-+ +-+-+-+-+-+-+ ! ! Защищенная связь (SA) ! ! !Защищенная !в туннельном или транспортном режиме IPsec!Защищенная ! ! точка !<---------------------------------------->! точка ! ! ! ! ! +-+-+-+-+-+-+ +-+-+-+-+-+-+
Рисунок 2. Туннель между конечными точкам
В этом сценарии обе конечные точки соединения IP реализуют IPsec в соответствии с требованиями для хостов в [RFC4301]. Обычно используется транспортный режим без внутренних заголовков IP. Если внутренний заголовок используется, адрес IP в нем будет совпадать с адресом во внешнем заголовке. Для защиты с помощью данной SA согласуется одна пара адресов. Конечные точки могут реализовать средства контроля доступа на прикладных уровнях на основе IPsec-аутентификации участников соединения. Этот сценарий обеспечивает сквозную защиту, которая является одним из принципов работы Internet с момента разработки [RFC1958], [RFC2775] и метода ограничения унаследованных проблем, связанных со сложностью сетей, которые отмечены в [RFC3439]. Хотя этот сценарий не может полноценно применяться в Internet на базе IPv4, он может успешно использоваться внутри сетей intranet на базе IKEv1. Более широкому распространению этого сценария будет способствовать переход на IPv6 и адаптация IKEv2.
В таком сценарии одна или обе конечных точки могут находиться за системой трансляции сетевых адресов (NAT). В этом этом случае туннелируемые пакеты будут инкапсулироваться в UDP так, что номера портов в заголовках UDP можно будет использовать для аутентификации отдельных конечных точек, расположенных за NAT (см. параграф 2.23).
1.1.3. Туннель между конечной точкой и защитным шлюзом
+-+-+-+-+-+-+ +-+-+-+-+-+ ! ! Туннель !Конечная ! Защищенная !Защищенная ! IPsec !точка ! подсеть !точка !<------------------------>!туннеля !<--- и/или ! ! ! ! Internet +-+-+-+-+-+-+ +-+-+-+-+-+
Рисунок 3. Туннель между конечной точкой и защитным шлюзом
В этом сценарии защищенная конечная точка (обычно портативный компьютер) подключается к корпоративной сети с использованием защищенного туннеля IPsec. Туннель может использоваться только для доступа к информации, хранящейся в корпоративной сети, или служить для передачи всего трафика портативного компьютера через офисную сеть для обеспечения возможности использования корпоративного межсетевого экрана, защищающего компьютер от атак из сети Internet. В любом случае защищенной точке будет нужен IP-связанный с защитным шлюзом, чтобы адресованные этой точке пакеты попадали на защитный шлюз и передавались им через туннель на защищенную точку. Этот адрес может выделяться защитным шлюзом статически или динамически. Во втором случае IKEv2 включает механизм, с помощью которого инициатор соединения запрашивает адрес IP, принадлежащий шлюзу, для использования в течение срока действия SA.
В этом сценарии пакеты будут использовать туннельный режим. В каждом пакете от защищенной конечной точки внешний заголовок IP будет содержать адрес отправителя, связанный с текущим местоположением (адрес, по которому трафик будет маршрутизироваться непосредственно к конечной точке), а внутренний заголовок IP будет содержать адрес отправителя, выделенный защитным шлюзом (т. е., адрес, по которому трафик будет маршрутизироваться защитному шлюзу для пересылке конечной точке). Внешний адрес получателя будет указывать защитный шлюз, а внутренний адрес получателя — конечного адресата пакета.
В этом сценарии защищенная конечная точка может находиться за системой трансляции адресов (NAT). При этом адрес, который будет видеть защитный шлюз, отличается от IP-адреса защищенной конечной точки и пакеты будут инкапсулироваться в дейтаграммы UDP для обеспечения корректной маршрутизации.
1.1.4. Другие сценарии
Обозначение Данные
AUTH аутентификация
CERT сертификат
CERTREQ запрос сертификата
CP конфигурация
D удаление
E зашифровано
EAP расширенная аутентификация
HDR заголовок IKE
IDi идентификация – инициатор
IDr идентификация – отвечающая сторона
KE обмен ключами
Ni, Nr Nonce
N уведомление
SA защищенная связь
TSi селектор трафика – инициатор
TSr селектор трафика – отвечающая сторона
V идентификатор производителя
Возможны и другие сценарии, представляющие собой комбинации перечисленных выше вариантов. Один примечательный вариант объединяет в сете аспекты 1.1.1 и 1.1.3. Подсеть может организовать весь доступ наружу через удаленный защитный шлюз, используя туннель IPsec и тогда внешние сети (Internet) будут маршрутизировать пакеты для подсети защитному шлюзу. Например, некая домашняя сеть может виртуально представляться в сети Internet статическими адресами IP, несмотря на то, что эта сеть подключена через ISP, который выделяет один динамический адрес пользовательскому защитному шлюзу (видимый в 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, поэтому аутентификационные данные недоступны для подслушивания, а все поля сообщений аутентифицируются.
На врезке справа приведен список обозначений и краткое описание данных, содержащихся в сообщениях.
Содержимое данных в сообщениях подробно рассматривается в разделе 3. Данные, которые являются необязательными, указываются в квадратных скобках – [CERTREQ] показывает возможность включения запроса сертификата.
Начальные обмены имеют вид:
Инициатор Ответчик
----------- ----------
HDR, SAi1, KEi, Ni -->
HDR содержит списки параметров защиты (SPI10), номера версий и различные флаги. 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} -->
Инициатор предъявляет свою идентификацию в IDi, доказывает свое знание ключа, соответствующего IDi и защищает целостность содержимого первого сообщения, используя AUTH (см. параграф 2.15). Он может также передать свой сертификат (сертификаты) в CERT и список своих доверенных привязок11 в 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) канал не переполнен обманными и повторными пакетами так, что это ведет к нехватке ресурсов сети или производительности CPU12 на одной из конечных точек. Даже при невыполнении этих минимальных требований IKE будет прерывать работу «чисто» (как при обрыве сети).
Хотя сообщения IKEv2 должны быть короткими, они содержат структуры данных без жестко заданной верхней границы размера (в частности, сертификаты X.509), а сам протокол IKEv2 не включает механизма фрагментирования больших сообщений. Протокол IP определяет механизм фрагментирования слишком больших дейтаграмм UDP, но максимальный поддерживаемый размер может зависеть от реализации. Более того, использование фрагментации IP открывает реализации для атак на службы (DoS13) [KPS03]. Кроме того, некоторые реализации NAT и/или межсетевых экранов могут блокировать фрагменты IP.
Все реализации IKEv2 должны быть способны передавать, принимать и обрабатывать сообщения IKE размером до 1280 байтов и следует также обеспечивать возможность передачи, приема и обработки сообщений размеров до 3000 байтов. Реализациям IKEv2 следует принимать во внимание максимальный размер поддерживаемых сообщений UDP и можно укорачивать сообщения, убирая из них некоторые предлагаемые сертификаты и криптографические наборы, если это позволит сохранить размер сообщения ниже максимума. Использование форматов «Hash and URL14» там, где это возможно, позволит избежать большинства проблем. В реализациях и конфигурационных параметрах следует принимать во внимание, что в тех случаях, когда поиск 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 должны согласовываться раздельные IKE_SA.
Существуют DoS-атаки на инициатора IKE_SA, которых можно избежать в случае применения инициатором соответствующих мер. Поскольку два первых сообщения при организации SA не защищаются криптографически, атакующий может ответить на сообщения инициатора раньше, чем вызываемая сторона, и сорвать организацию соединения. Для предотвращения этого инициатор может выбрать восприятие множества откликов на свое первое сообщение, трактуя их, как потенциально легитимные, а потом отбросить все некорректные полуоткрытые соединения, когда будет получен корректный, криптографически защищенный отклик на любой из его запросов. После получения криптографически корректного отклика все последующие отклики15 следует игнорировать, независимо от их криптографической корректности.
Отметим, что с приведенными правилами не возникает необходимости согласования срока жизни SA. Если IKE предполагает, что партнер не работает на основе повторяющегося отсутствия подтверждений для сообщения IKE, тогда IKE SA и все дочерние CHILD_SA, организованные в данной IKE_SA, удаляются.
Конечная точка IKE может в любой момент удалить неактивную 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, а при получении сообщений такие реализации должны игнорировать содержимое резервных полей (будьте консервативными при передаче и либеральными при приеме). В результате новые версии протокола смогут использовать резервные поля так, что их значения будут игнорироваться реализациями, не понимающими таких полей. Аналогично, типы данных, которые не определены, являются резервными16.
IKEv2 добавляет флаг «критичности» (critical) к каждому заголовку данных для более гибкой совместимости с грядущими версиями. Если флаг critical установлен, а тип данных нераспознан, сообщение должно быть отвергнуто, а отклик на запрос IKE, включающий эти данные, должен включать элемент Notify UNSUPPORTED_CRITICAL_PAYLOAD, показывающий прием нераспознанных критичных данных. Если флаг критичности не установлен, нераспознанный элемент должен игнорироваться.
Хотя в будущем могут добавляться новые элементы данных, которые будут появляться вперемешку с определенными в этой спецификации полями, реализации должны передавать определенные в этой спецификации элементы в том порядке, который показан на рисунках раздела 2 и реализациям следует отвергать некорректные сообщения с другим порядком элементов данных.
2.6. Cookie
Термин cookie, введенный 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 включены в разные предложения, ответчик должен принять только один из этих протоколов17).
Каждый предлагаемый протокол 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 осознанно. Одной из причин этого является поддержка различий в качестве обслуживания трафика (QoS18) между 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 соответствует «селектору защиты» в соответствии с SPD19, подсистема должна защитить пакет с использованием IPsec. Если SA еще не существует, ее создание является задачей IKE. Поддержка SPD в системе выходит за пределы IKE (см. [PFKEY] в качестве примера протокола), хотя некоторые реализации могут обновлять свои SPD в контакте с работающим IKE (см., для примера, сценарий 1.1.3).
Элементы данных TS20 позволяют конечным точкам обмениваться некой информацией из SPD со своими партнерами. Элементы TS задают критерии выбора пакетов, которые будут передаваться через вновь созданную SA. Это может служить проверкой согласованности в некоторых сценариях для контроля непротиворечивости SPD. В других случаях это ведет к динамическому обновлению SPD.
В каждом из сообщений обмена, создающего пару CHILD_SA, появляется два элемента TS. Каждый из TS содержит один или множество селекторов трафика. Каждый селектор состоит из диапазона адресов (IPv4 или IPv6), диапазона портов и идентификатора протокола IP. В поддержку сценария, описанного в параграфе 1.1.3, инициатор может запросить у отвечающей стороны выделение адреса IP с его кратким описанием (что это?).
IKEv2 позволяет ответчику выбрать подмножество селекторов трафика, предложенных инициатором. Это может происходить в тех случаях, когда конфигурация двух конечных точек была изменена, но только одна сторона получила новую информацию. Поскольку обе конечных точки могут настраиваться разными людьми, может возникать период несовместимости даже при отсутствии ошибок. Это также разрешает заведомо разные конфигурации, когда одна сторона настроена на туннелирование всех адресов и обновление списка зависит от другой стороны.
Первый из двух элементов TS называют TSi21, а второй – TSr22. TSi задает адрес отправителя трафика, пересылаемого от инициатора (или адрес получателя трафика, пересылаемого инициатору) пары CHILD_SA. TSr указывает адрес получателя трафика, пересылаемого ответчика (или адрес отправителя трафика, пересылаемого от ответчика) пары CHILD_SA. Например, если исходный инициатор запрашивает создание пары CHILD_SA и хочет туннелировать весь трафик из подсети 192.0.1.* на своей стороне в подсеть 192.0.2.*23 на стороне ответчика, инициатор будет включать один селектор трафика в каждый элемент TS. TSi будет задавать диапазон адресов 192.0.1.0 — 192.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 битов и не менее половины размера ключа согласованной prf24. При использовании некого общего источника случайных чисел для ключей и nonce нужно быть осторожными, чтобы использование nonce не привело к компрометации ключей.
2.11. Использование адресов и портов
IKE работает по протоколу UDP через порты 500 и 4500, неявно устанавливая связи ESP и AH для тех же адресов IP. Адреса IP и номера портов во внешнем заголовке не защищаются криптографически и протокол IKE может работать даже через устройства трансляции адресов (NAT). Реализация должна воспринимать входящие запросы даже из портов с номерами, отличными от 500 или 4500 и должна отвечать на адрес и порт, с которых был получен запрос. Реализация должна указать в отклике адрес и порт, через которые был принят запрос, в качестве адреса и порта отправителя. Функции IKE идентичны для протоколов IPv4 и IPv6.
2.12. Многократное использование экспоненциалов Diffie-Hellman
Для обеспечения высокого уровня защиты25 IKE генерирует короткоживущие ключи с использованием обмена Diffie-Hellman. Это означает, что после закрытия соединения соответствующие ключи забываются. Если кто-либо смог записать всю переданную через соединение информацию и получил доступ к долгосрочным ключам обеих сторон соединения, он не сможет восстановить ключи, которые использовались для соединения без перебора26 всего пространства сеансовых ключей.
В соответствии с требованиями по обеспечению высокого уровня защиты каждая конечная точка при закрытии соединения должна забыть не только использованные в соединении ключи, но и любую информацию, которая применялась для расчета этих ключей. В частности необходимо забыть секреты, использованные в расчетах Diffie-Hellman и любые состояния, которые могли бы сохраниться в состоянии генератора псевдослучайных чисел, используемого для пересчета секретов Diffie-Hellman.
Поскольку расчет экспоненциалов Diffie-Hellman требует значительных вычислительных ресурсов, конечные точки могут получать преимущества в результате использования этих экспоненциалов для организации множества соединений. Существует несколько вариантов обоснованной стратегии многократного использования экспоненциалов. Конечная точка выбирает новый экспоненциал периодически, хотя это может приводить к снижению уровня защиты. Другим вариантом является сохранение информации об использованных для каждого соединения экспоненциалов и удалять связанную с экспоненциалом информацию только после закрытия соответствующего соединения. Это позволяет использовать экспоненциалы многократно без снижения уровня защиты, но за счет поддержки дополнительной информации о состоянии.
Решение вопроса о многократном использовании экспоненциалов Diffie-Hellman и способе такого использования является частным и не влияет на интероперабельность. Реализация, использующая экспоненциалы многократно, может принять решение о сохранении экспоненциалов, использованных другой точкой в предшествующих обменах, избегая второй половины расчетов при использовании этих экспоненциалов.
2.13. Материал для генерации ключей
В контексте IKE_SA согласуются четыре криптографических алгоритма — алгоритм шифрования, алгоритм защиты целостности, группа Diffie-Hellman и псевдослучайная функция (prf). Последняя используется при создании ключевого материала для всех криптографических алгоритмов, используемых как в IKE_SA, так и в дочерних CHILD_SA.
Мы полагаем, что каждый алгоритм шифрования и защиты целостности использует ключ фиксированного размера и случайно выбранное значение фиксированного размера может служить подходящим ключом. Для алгоритмов, которые воспринимают ключи переменного размера, должен указываться фиксированный размер ключа в процессе согласования криптографических преобразований. Для алгоритмов, в которых не все значения являются допустимыми ключами (например, DES или 3DES с четностью ключа) криптографическим преобразованием должен задаваться алгоритм создания ключей из произвольных значений. Для функций защиты целостности на основе кода HMAC27 фиксированным размером ключа является размер вывода нижележащей функции хэширования. Когда функций 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-битовый ключ AES28 и 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 является разделяемым секретом из краткосрочного29 обмена Diffie-Hellman. Значение g^ir представляется строкой октетов в формате big endian30 с дополнением при необходимости нулями для выполнения требований по размеру модуля. Ni и Nr — значения элементов nonce, извлеченные из любых заголовков. Если согласованная функция prf принимает ключ фиксированного размера, а суммарная длина Ni и Nr превышает нужное значения, берется половина (первая) битов из Ni и половина (первая) битов из Nr.
Для двух направления потока трафика используются разные ключи. Ключи, служащие для защиты сообщений от исходного инициатора, обозначаются SK_ai и SK_ei. Ключи, служащие для защиты сообщений в другом направлении, обозначаются SK_ar и SK_er. Каждый алгоритм принимает фиксированное число битов ключевого материала, заданное как часть алгоритма. Для алгоритмов защиты целостности на основе хэш-функций размер ключа всегда равен размеры результата нижележащей хэш-функции.
2.15. Аутентификация IKE_SA
Если не используется расширяемая аутентификация (см. параграф 2.16), партнеры аутентифицируют себя посредством подписи (или MAC31 с использованием разделяемого секрета в качестве ключа) для блока данных. Для ответчика подписываемые данные начинаются с первого октета первого 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 инициатор объявляет свою идентификацию, но не подтверждает ее. Если ответчик желает использовать расширяемую аутентификацию, он будет включать элемент EAP32 в сообщение 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, не создающие разделяемого ключа, использовать не следует, поскольку они подвержены многочисленным атакам MITM33 [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.
Эта функция обеспечивает выделение адреса для клиента IRAC34, пытающегося организовать туннель в сеть, защищенную сервером удаленного доступа IRAS35. Поскольку обмен 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. Запрос версии партнера
Узел IKE, желающий узнать номер версии программ своего партнера IKE, может воспользоваться описанным ниже методом. Это пример конфигурационного запроса в рамках обмена INFORMATIONAL после создания IKE_SA и первой дочерней CHILD_SA.
Реализация IKE может отвергать запросы на выдачу своего номера версии до завершения аутентификации партнера и даже после аутентификации в целях предотвращения возможности использования известных недостатков в части защиты. В таких случаях реализация должна возвращать пустую строку или пакет без данных CP, если CP не поддерживается.
Инициатор Ответчик
----------- ----------
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 включает дополнительный задоловок в каждом пакете и список параметров компрессии (CPI36), виртуальная «связь с компрессией» не существует за пределами содержащей ее 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.
Уведомление: RFC 5226 Guidelines for Writing an IANA Considerations Section in RFCs | Энциклопедия сетевых протоколов