Р 1323565.1.048-2023. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе обмена ключами в сети Интернет версии 2 (IKEv2)

(утв. и введены в действие Приказом Росстандарта от 13.12.2023 № 1576-ст)

Утверждены и введены в действие Приказом Федерального агентства по техническому регулированию и метрологии от 13 декабря 2023 г. № 1576-ст

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

ИСПОЛЬЗОВАНИЕ РОССИЙСКИХ КРИПТОГРАФИЧЕСКИХ АЛГОРИТМОВ В ПРОТОКОЛЕ ОБМЕНА КЛЮЧАМИ В СЕТИ ИНТЕРНЕТ ВЕРСИИ 2 (IKEv2)

Information technology. Cryptographic data security. Using Russian cryptographic algorithms in the Internet Key Exchange protocol version 2 (IKEv2)

Р 1323565.1.048-2023

ОКС 35.040

Дата введения 1 января 2024 года

Предисловие

1 РАЗРАБОТАНЫ Акционерным обществом «ЭЛВИС-ПЛЮС» (АО «ЭЛВИС-ПЛЮС») при участии специалистов Общества с ограниченной ответственностью «Фактор-ТС» (ООО «Фактор-ТС»)

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 26 «Криптографическая защита информации»

3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 13 декабря 2023 г. № 1576-ст

4 ВВЕДЕНЫ ВПЕРВЫЕ

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

Настоящие рекомендации содержат описание протокола обмена ключами в сети Интернет версии 2 (IKEv2) при использовании в нем российских криптографических алгоритмов, регламентируемых ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015, Р 50.1.113-2016, Р 1323565.1.023-2022, Р 1323565.1.024-2019 и Р 1323565.1.026-2019.

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

1 Область применения

Протокол IKEv2 (Internet Key Exchange version 2), описанный в данных рекомендациях, предназначен для выработки ключей с целью защиты трафика в сетях TCP/IP посредством протоколов семейства IPsec при использовании в нем криптографических алгоритмов, определяемых документами Национальной системы стандартизации Российской Федерации. Протокол реализует аутентифицированный обмен ключами, в результате которого вырабатываются сеансовые ключи, используемые при создании защищенных соединений, и обеспечивает при этом взаимную аутентификацию участников взаимодействия, а также конфиденциальность и целостность передаваемой информации (включая идентификаторы участников), в том числе при наличии активного противника. Протокол может быть применен при защите информации, не содержащей сведений, составляющих государственную тайну.

Настоящие рекомендации базируются на материалах публикаций [1], [2], [3] и [4] и расширяют их в плане применения стандартизованных российских криптографических алгоритмов.

2 Нормативные ссылки

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

ГОСТ Р 34.10 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ Р 34.11 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ Р 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры

Р 50.1.113-2016 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов электронной цифровой подписи и функции хэширования

Р 1323565.1.023-2022 Информационная технология. Криптографическая защита информации. Использование алгоритмов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 в сертификате, списке аннулированных сертификатов (CRL) и запросе на сертификат PKCS #10 инфраструктуры открытых ключей X.509

Р 1323565.1.024-2019 Информационная технология. Криптографическая защита информации. Параметры эллиптических кривых для криптографических алгоритмов и протоколов

Р 1323565.1.026-2019 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров, реализующие аутентифицированное шифрование

Р 1323565.1.035-2021 Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе защиты информации ESP

Примечание - При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных документов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный документ, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины, определения, обозначения и сокращения

3.1 Термины и определения

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

3.1.1 инициатор (initiator): Активная сторона взаимодействия.

3.1.2 ответчик (responder): Пассивная сторона взаимодействия.

3.1.3 секция (payload): Блок данных, содержащий информацию определенного типа; состоит из заголовка и тела.

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

3.1.4 подсекция (substructure): Блок данных, содержащий информацию определенного типа внутри секции; состоит из заголовка и тела.

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

3.1.5 сообщение (message): Блок данных, который передается в протоколе IKEv2 между инициатором и ответчиком; состоит из заголовка и одной или более секций.

3.1.6 обмен (exchange): Элементарная единица информационного взаимодействия инициатора и ответчика в протоколе IKEv2, состоящая из отправки инициатором ответчику сообщения, содержащего запрос, и получения ответного сообщения.

Примечание - Характеризуется типом, который в настоящих рекомендациях изображается следующим образом: ОБМЕН.

3.1.7 уведомление (notification): Информационный блок.

Примечание - Характеризуется типом, который в настоящих рекомендациях изображается следующим образом: УВЕДОМЛЕНИЕ.

3.1.8 трансформ (transform): Набор правил, в соответствии с которыми происходит обработка сообщения в IKEv2.

Примечание — Характеризуется типом, определяющим вид обработки (например, трансформ типа ENCR определяет алгоритм шифрования, режим его использования, способ формирования вектора инициализации и т.д.) и уникальным идентификатором, используемым в протоколе IKEv2 при согласовании трансформов в процессе создания защищенного соединения (3.1.11).

3.1.9 нонс <1> (nonce): Вектор, содержащий случайные или псевдослучайные данные; используется для внесения энтропии в процесс выработки ключей.

<1> В настоящих рекомендациях термин «нонс» используется для обозначения случайных или псевдослучайных данных, что отличается от его общеупотребительного использования. Термин является устоявшимся в контексте протокола IKEv2.

3.1.10 селектор трафика (traffic selector): Совокупность сетевых характеристик, позволяющих выделить некоторое подмножество IP-пакетов.

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

3.1.11 защищенное соединение (Security Association; SA): Логическое объединение используемых трансформов, а также сеансовых ключей, позволяющее осуществлять защиту трафика.

3.1.12 политика безопасности: Совокупность настроек и/или особенностей реализации протокола на конкретном устройстве, определяющая поведение данного устройства как участника сетевого взаимодействия по этому протоколу в отношении требований обеспечения безопасности.

3.2 Обозначения

В настоящих рекомендациях применены следующие обозначения:

B* — множество всех байтовых строк произвольной конечной длины;

Bs — множество байтовых строк длины s, s >= 0. Строка b = (b1, ..., bs) принадлежит множеству Bs, если {}_{b_{1},...,b_{s} \in}{_{0,...,255}} . При s = 0 множество Bs состоит из единственной пустой строки длины 0;

| — конкатенация двух байтовых строк; для двух строк a = (a_{1},...,a_{s1}) \in B_{s1} , b = (b_{1},...,b_{s2}) \in B_{s2} , их конкатенацией a|b называется строка c = (a_{1},...,a_{s1},b_{1},...,b_{s2}) \in B_{s1 + s2} ;

& — операция побитовой конъюнкции (побитовое «И») для операндов одинаковой длины;

STRs(r) — строка STR_{s}(r) = (b_{1},...,b_{s}) \in B_{s} , соответствующая числу r = 256s-1·b1 + ... + 256·bs-1 + bs <= 256s — 1 (представление числа r в виде байтовой строки в формате big-endian);

strs(r) — строка str_{s}(r) = (b_{1},...,b_{s}) \in B_{s} , соответствующая числу r = 256s-1·bs + ... + 256·b2 + b1 <= 256s — 1 (представление числа r в виде байтовой строки в формате little-endian);

|b| — длина байтовой строки b \in B^{*} в байтах (если b — пустая строка, то |b| = 0);

b[i...j] — строка b[i...j] = (b_{i},b_{i + 1},...,b_{j}) \in B_{j - i + 1} , где: 1 <= i <= j <= s и b = (b_{1},...,b_{s}) \in B_{s} ;

ENCR — тип трансформа, основанного на алгоритме шифрования или AEAD алгоритме (см. 3.3); как правило, трансформ типа ENCR обеспечивает свойство конфиденциальности, однако если он основывается на AEAD алгоритме, то в протоколе IKEv2 он обеспечивает и конфиденциальность, и имитозащиту;

INTEG — тип трансформа, основанного на алгоритме имитозащиты, обеспечивает свойство имитозащиты; в случае, если трансформ типа ENCR базируется на AEAD алгоритме, то трансформ типа INTEG не должен использоваться;

PRF — тип трансформа, реализующего псевдослучайную функцию;

KE — тип трансформа, реализующего алгоритм выработки общего ключа;

ESN — тип трансформа, указывающего на использование расширенных номеров пакетов в протоколе ESP;

ByteToBit — функция перевода байтовой строки в битовую; определена в Р 1323565.1.026-2019;

prf(K, S) — псевдослучайная функция; принимая на вход произвольные аргументы K и S, детерминированно и эффективно вычисляет выходное значение, не отличимое от случайной величины;

[X] — в диаграммах обменов IKEv2 означает, что секция X в данном сообщении является необязательной;

X+ — в диаграммах обменов IKEv2 означает, что секция X в данном сообщении может встречаться несколько раз;

[X+] — в диаграммах обменов IKEv2 означает, что секция X в данном сообщении является необязательной, но при ее наличии может присутствовать несколько раз;

X(Y) — в диаграммах обменов IKEv2 обозначает, что секция X имеет содержимое Y; при этом Y не обязательно полностью определяет содержимое X, но позволяет описывать в диаграммах случаи, когда содержимое секции имеет значение для протокола;

SK{...} — в диаграммах обменов IKEv2 означает, что секции, заключенные в фигурные скобки, шифруются, а само сообщение целиком имитозащищается на ключах данного IKE SA.

3.3 Сокращения

В настоящих рекомендациях применены следующие сокращения:

IPsec — IP Security (семейство протоколов защиты информации на уровне IP пакетов);

IKE, IKEv2 — Internet Key Exchange (протокол обмена ключами в Интернете). В настоящих рекомендациях описывается только версия 2 протокола (IKEv2), поэтому обозначения IKE и IKEv2 считаются синонимами;

SA — Security Association (защищенное соединение);

ESP — Encapsulating Security Payload (протокол защиты информации в IPsec);

AH — Authentication Header (протокол защиты информации в IPsec, не обеспечивающий конфиденциальности информации);

IPcomp — IP Compression (протокол сжатия данных);

ICV — Integrity Check Value (имитовставка);

IV — Initialization Vector (вектор инициализации, синхропосылка);

SPI — Security Parameter Index (идентификатор защищенного соединения);

PFS — Perfect Forward Secrecy (совершенная прямая секретность/защита от «чтения назад»);

PSK — Preshared Key (предварительно распределенный ключ);

MSGID — Message ID (идентификатор сообщения);

PRF — PseudoRandom Function (псевдослучайная функция);

HMAC — Hash-based Message Authentication Code (код аутентификации сообщения на основе хэш-функции);

nSHA — функция сжимающего отображения, определена в приложении А;

TFC — Traffic Flow Confidentiality (конфиденциальность потока данных);

AEAD — Authenticated Encryption with Associated Data (шифрование с имитозащитой и ассоциированными данными);

AAD — Additional Authenticated Data (дополнительные имитозащищаемые данные);

NAT — Network Address Translation (трансляция сетевых адресов).

Примечания

1 Числовые константы, определяемые в данных рекомендациях, приведены в виде байтовой строки в шестнадцатеричном виде.

2 В настоящих рекомендациях предполагается, что все приведенные строковые константы представлены в кодировке ASCII.

3 Байтовое представление данных, соответствующих группе полей, задается конкатенацией байтовых представлений значений полей группы. Байтовое представление значения поля, являющегося вектором элементов некоторого типа, задается конкатенацией байтовых представлений элементов данного вектора в порядке их нумерации (слева направо).

4 Описание протокола IKEv2

4.1 Общие сведения о протоколах IPsec

Семейство протоколов IPsec предназначено для обеспечения безопасной передачи IP-пакетов между узлами IP-сети. Оно включает в себя два основных протокола:

• протокол ESP, обеспечивающий непосредственную защиту IP-пакетов;
• протокол IKEv2, обеспечивающий обмен ключами, взаимную аутентификацию сторон и создание/удаление защищенных соединений ESP; создание защищенного соединения ESP включает в себя согласование его параметров (включая используемые трансформы), выбор SPI и вычисление сеансовых ключей.

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

Протокол IKEv2 устанавливает защищенное соединение IKE (IKE SA <1>), включающее в себя общий ключ, который используется для создания защищенных соединений протоколов ESP и/или AH (IPsec SA), и набор криптографических алгоритмов, которые могут быть использованы в этих защищенных соединениях.

<1> В настоящих рекомендациях термины «защищенное соединение IKE» и «IKE SA» считаются равнозначными и используются оба.

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

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

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

4.2 Транспорт IKEv2

IKEv2 использует протокол UDP в качестве основного транспортного протокола. Кроме того, опционально в качестве транспортного протокола для IKE и ESP может быть использован протокол TCP. Более подробно использование TCP описано в 4.13.

При использовании UDP задействованы два порта — 500 и 4500. Порт 500 используется для начального обмена (IKE_SA_INIT) и для последующих обменов, если между абонентами нет NAT; порт 4500 используется для последующих обменов, если между абонентами присутствует NAT. Полезные данные UDP для всех пакетов с IKE-сообщениями, посылаемыми на порт 4500, должны начинаться с префикса, состоящего из четырех байт нулей (Non-ESP Marker), однако этот префикс не является частью сообщения IKE (например, его не учитывают при указании длины сообщения в поле Length заголовка IKE). Как правило, порт источника в IKE устанавливают равным порту назначения (то есть 500 или 4500), но реализация должна принимать входящие запросы, даже если порт источника у них не равен 500 или 4500 и должна при этом отвечать на тот адрес и порт, с которого был получен запрос. В качестве IP протокола может быть использован как IPv4, так и IPv6. Протокол разработан таким образом, чтобы функционировать при выполнении следующих минимальных условий:

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

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

Для начальных обменов (IKE_SA_INIT и IKE_AUTH) инициатор всегда является также и инициатором обмена; после установления IKE SA любая из сторон может инициировать последующие обмены (CREATE_CHILD_SA и INFORMATIONAL).

Два первых поля заголовка IKE размером 8 байт каждое, называемые IKE SPI, используются для идентификации защищенного соединения в сообщениях IKE. Каждая из сторон выбирает один из двух IKE SPI (инициатор выбирает SPIi, а ответчик — SPIr) таким образом, чтобы он служил уникальным идентификатором защищенного соединения IKE для данной стороны, при этом значения IKE SPI должны выбираться непредсказуемо для внешнего наблюдателя. Входящие пакеты IKE соотносятся с соответствующим IKE SA только посредством IKE SPI из пакета, не используя, например, IP-адрес источника пакета. Нулевое значение IKE SPI является специальным: оно показывает, что значение IKE SPI ответчика еще неизвестно посылающей стороне (первое сообщение от инициатора). Таким образом, SPIi не может быть нулевым, а SPIr может быть нулевым только в первом сообщении от инициатора или в ответе на него, если обмен не привел к созданию IKE SA вследствие ошибок INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN или COOKIE. Однако если в этом случае SPIr будет ненулевым, инициатору не следует отвергать ответ только по этой причине.

Сообщение IKE состоит из заголовка HDR и одной или более секций, которые в описаниях обменов по тексту настоящих рекомендаций обозначают следующим образом:

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

4.3 Обмены IKEv2

4.3.1 Общие сведения об обменах IKEv2

Обмены в IKE состоят из пары сообщений: запрос и ответ (см. приложение Б). Обеспечение надежности доставки сообщений лежит на инициаторе обмена. Если ответ не получен в течение определенного интервала времени, запрашивающая сторона должна заново послать запрос (или прекратить попытки соединения). Ответчик не должен перепосылать ответ, если только он не получил повторный запрос. Инициатор должен перепосылать запрос до тех пор, пока он не получит соответствующий ответ, либо не сочтет IKE SA неработоспособным. В последнем случае инициатор удаляет все данные, ассоциированные с данным IKE SA, и все IPsec SA, созданные посредством данного IKE SA.

Каждое сообщение IKE содержит 32-битный идентификатор сообщения (поле MSGID) как часть фиксированного заголовка. Этот идентификатор используется для сопоставления ответов с запросами и для выявления повторных сообщений. Ответные сообщения содержат тот же идентификатор сообщения, что и соответствующие им запросы. При перепосылках одного и того же сообщения идентификатор сообщения не изменяется. Сообщения начального обмена (IKE_SA_INIT) всегда имеют идентификатор сообщения, равный 0, в дальнейшем каждый последующий инициированный обмен использует увеличенное на единицу значение идентификатора сообщения. Для обменов, инициированных в разных направлениях, идентификаторы являются независимыми, т.е., каждый из абонентов ведет свой счетчик для определения идентификатора сообщения для очередного обмена, который он инициирует. Это означает, что после начального обмена каждое целое число n может появиться в поле MSGID в четырех различных сообщениях: n-й запрос от изначального инициатора IKE SA, соответствующий ему ответ, n-й запрос от изначального ответчика и соответствующий ему ответ. Это не приводит к неопределенности, поскольку флаги Initiator (Инициатор) и Response (Ответ) в заголовке сообщения позволяют определить, к какому из этих четырех случаев относится данное сообщение.

Идентификатор сообщения криптографически защищен и обеспечивает защиту от приема повторных сообщений. При достижении идентификатором сообщения максимального значения для 32-битного числа IKE SA должно быть удалено или обновлено.

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

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

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

При посылке запросов реализация IKE не должна посылать их в большем количестве, чем размер окна, указанный противоположной стороной. Иными словами, если ответчик анонсировал размер своего окна как S, то, когда инициатор собирается послать запрос X, он должен ждать до тех пор, пока он не получит ответы на все свои запросы вплоть до запроса X — S. Реализация IKE, которая поддерживает размер окна больше, чем 1, должна быть способна обрабатывать входящие запросы вне зависимости от их порядка.

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

Уведомление INVALID_MESSAGE_ID посылается в том случае, если идентификатор полученного сообщения находится вне текущих границ окна. Это уведомление не должно посылаться как ответ: ошибочные запросы не должны подтверждаться. Вместо этого другую сторону информируют путем инициирования обмена INFORMATIONAL, при этом в область данных уведомления записывается 4 байта с неверным идентификатором сообщения. Отсылка этого уведомления является опциональной, ее частота должна быть ограничена.

Первые два обмена, устанавливающие защищенное соединение IKE, называются IKE_SA_INIT и IKE_AUTH; последующие обмены называются CREATE_CHILD_SA и INFORMATIONAL. В простейшем случае для установления IKE SA и первого IPsec SA требуется один обмен IKE_SA_INIT и один обмен IKE_AUTH. В некоторых случаях может потребоваться проведение более одного обмена обоих типов. В любом случае, все IKE_SA_INIT обмены должны завершиться до начала любого другого обмена, затем все IKE_AUTH обмены должны завершиться, и после этого любое количество CREATE_CHILD_SA и INFORMATIONAL обменов могут быть инициированы любой стороной в любом порядке, и могут быть использованы для создания дополнительных IPsec SA и для выполнения задач управления.

4.3.2 Начальные обмены

Использование IKE всегда начинается с обменов IKE_SA_INIT и IKE_AUTH. Обычно эти начальные обмены содержат в сумме 4 сообщения, хотя в некоторых сценариях это число может увеличиваться. Первая пара сообщений (IKE_SA_INIT) согласует криптографические алгоритмы, обменивается нонсами и эфемерными открытыми ключами по протоколу Диффи-Хеллмана для вычисления общего ключа. Вторая пара сообщений (IKE_AUTH) аутентифицирует предыдущие сообщения, выполняет обмен идентификаторами и сертификатами абонентов и создает первое IPsec SA.

В обменах IKE_AUTH, CREATE_CHILD_SA и INFORMATIONAL сообщение после заголовка является зашифрованным, а целостность всего сообщения, включая заголовок, контролируется посредством криптографических алгоритмов с использованием ключей, выработанных для данного защищенного соединения IKE в процессе обмена IKE_SA_INIT.

Создание IKE SA начинается с обмена IKE_SA_INIT.

HDR содержит идентификаторы защищенного соединения (IKE SPI), номер версии протокола и различные флаги. Секция SAi1 содержит трансформы, которые инициатор считает возможным использовать в данном IKE SA. Секция KEi содержит значение эфемерного открытого ключа протокола Диффи-Хеллмана инициатора. Секция Ni содержит нонс инициатора:

Ответчик выбирает приемлемый для себя набор трансформов из предложенных инициатором и возвращает его в секции SAr1, посылает свое значение эфемерного открытого ключа протокола Диффи-Хеллмана в секции KEr и свой нонс в секции Nr, а также опционально список доверенных сертификатов CERTREQ.

По завершении обмена IKE_SA_INIT каждая из сторон вырабатывает ключ SKEYSEED, из которого в дальнейшем получаются все ключи для данного защищенного соединения IKE, в том числе ключи шифрования, и ключи аутентификации и контроля целостности. Для разных направлений трафика вырабатывают разные ключи, обозначаемые как SKei, SKer (ключи шифрования) и SKai, SKar (ключи аутентификации и контроля целостности сообщений). Детали выработки ключей описаны в 4.14. Последующие сообщения полностью зашифрованы, за исключением заголовков сообщений, а их целостность контролируется, включая заголовки.

Примечание - В случае применения AEAD алгоритмов для защиты IKE SA ключи SKai и SKar не используют и, соответственно, не вырабатывают.

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

После завершения обмена IKE_SA_INIT инициатор начинает обмен IKE_AUTH:

Инициатор представляет свой идентификатор в секции IDi, подтверждает знание закрытого ключа, соответствующего этому идентификатору и обеспечивает аутентификацию посланных им сообщений, используя секцию AUTH (см. 4.15), а также предложения по параметрам IPsec SA в секциях SAi2, TSi, TSr. Он может также опционально послать свой сертификат (или сертификаты) в секции (секциях) CERT и список доверяемых сертификатов в секции (секциях) CERTREQ. Опциональная секция IDr позволяет инициатору указать, с каким из идентификаторов ответчика он желает создать защищенное соединение.

Ответчик представляет свой идентификатор в секции IDr, опционально посылает один или несколько сертификатов, аутентифицирует свой идентификатор и обеспечивает аутентификацию посланных им сообщений посредством секции AUTH и завершает создание IPsec SA посредством секций SAr2, TSi, TSr, описанных при детализации обмена CREATE_CHILD_SA. Инициатор завершает создание IPsec SA, используя полученные секции SAr2, TSi, TSr.

4.3.3 Обмен CREATE_CHILD_SA

4.3.3.1 Общие сведения об обмене CREATE_CHILD_SA

Обмен CREATE_CHILD_SA используется для создания нового IPsec SA и для обновления ключей как для IPsec SA, так и для IKE SA. Он может быть инициирован любой стороной защищенного соединения IKE после того, как завершатся обмены IKE_SA_INIT и IKE_AUTH.

Обновление ключей защищенного соединения происходит путем создания нового защищенного соединения с последующим удалением старого. Данный раздел описывает первую часть этого процесса — создание нового защищенного соединения.

Сообщения обмена CREATE_CHILD_SA могут опционально содержать секцию Key Exchange для проведения дополнительного обмена ключами с целью обеспечения невозможности «чтения назад» для IPsec SA. Ключевой материал для IPsec SA вырабатывается с использованием ключа SKd, вычисляемого в процессе установления IKE SA, нонсов, которыми стороны обмениваются в обмене CREATE_CHILD_SA и общего ключа (если секции Key Exchange были включены в обмен CREATE_CHILD_SA).

4.3.3.2 Создание IPsec SA посредством обмена CREATE_CHILD_SA

IPsec SA может быть создано путем посылки сообщения с запросом обмена CREATE_CHILD_SA. Запрос обмена CREATE_CHILD_SA для создания IPsec SA выглядит следующим образом:

Инициатор обмена посылает свои предложения параметров защищенного соединения в секции SAi, нонс в секции Ni, опционально эфемерный открытый ключ протокола Диффи-Хеллмана в секции KEi и предлагает селектор трафика для создаваемого IPsec SA в секциях TSi и TSr. В секции SAi инициатор указывает предлагаемые параметры и SPI ESP SA, который он формирует в соответствии с Р 1323565.1.035-2021 (пункт 4.1.1).

Ответное сообщение обмена CREATE_CHILD_SA при создании IPsec SA выглядит следующим образом:

Ответчик обмена посылает обратно инициатору выбранный им набор параметров IPsec SA в секции SAr, нонс в секции Nr и свое значение эфемерного открытого ключа протокола Диффи-Хеллмана в секции KEr в том случае, если секция KEi присутствовала в запросе и выбранный ответчиком набор включает группу из KEi. В секции SAr ответчик указывает выбранные параметры и SPI ESP SA, который он формирует в соответствии с Р 1323565.1.035-2021 (пункт 4.1.1).

В зависимости от заданной политики безопасности IPsec SA может создаваться как с вычислением нового общего ключа по протоколу Диффи-Хеллмана, так и без него (при этом в сообщениях отсутствуют секции KEi и KEr). В первом случае новое защищенное соединение IPsec будет обладать свойством PFS, во втором — нет.

Секции TSi и TSr в ответе содержат селектор трафика, который будет защищаться данным защищенным соединением, и могут представлять подмножество того, что предложил инициатор создания IPsec SA.

Неудачная попытка создания IPsec SA не должна приводить к удалению IKE SA. В этом случае результатом начальных обменов является только IKE SA, а IPsec SA могут быть созданы позднее посредством проведения обменов CREATE_CHILD_SA.

4.3.3.3 Обновление ключей IKE SA посредством обмена CREATE_CHILD_SA

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

Инициатор обмена посылает свои предложения параметров защищенного соединения в секции SAi, нонс в секции Ni и свой эфемерный открытый ключ протокола Диффи-Хеллмана в секции KEi. Секция KEi должна присутствовать в сообщении. Новый идентификатор защищенного соединения IKE инициатора передается в поле SPI секции SA.

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

Ответчик обмена посылает назад выбранный им набор параметров IKE SA в секции SAr, нонс в секции Nr и свое значение эфемерного открытого ключа протокола Диффи-Хеллмана в секции KEr, если выбранный ответчиком набор включает группу из KEi. Новый идентификатор защищенного соединения IKE ответчика передается в поле SPI секции SA.

Новое защищенное соединение IKE должно иметь счетчики сообщений сброшенными в 0, вне зависимости от того, какими они были в старом соединении, т.е. первые запросы, сделанные по новому защищенному соединению IKE, с любой стороны должны иметь идентификаторы сообщений равными 0. Старое соединение продолжает использовать свои значения счетчиков, так что любые последующие запросы (например, на удаление IKE SA) будут иметь последовательную нумерацию. Инициатор обновления ключей становится инициатором нового защищенного соединения IKE.

В 4.14.4 также рассмотрены детали обновления ключей IKE SA.

4.3.3.4 Обновление ключей IPsec SA посредством обмена CREATE_CHILD_SA

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

Инициатор обмена посылает свои предложения параметров защищенного соединения в секции SAi, нонс в секции Ni, опционально свой эфемерный открытый ключ протокола Диффи-Хеллмана в секции KEi и предлагает селектор трафика для создаваемого IPsec SA в секциях TSi и TSr. В секции SAi инициатор указывает предлагаемые параметры и SPI ESP SA, который он формирует в соответствии с Р 1323565.1.035-2021 (пункт 4.1.1).

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

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

Ответчик посылает назад выбранный им набор параметров IPsec SA в секции SAr, нонс в секции Nr и свое значение эфемерного открытого ключа протокола Диффи-Хеллмана в секции KEr, если секция KEi присутствовала в запросе и выбранный ответчиком набор включает группу из KEi. В секции SAr ответчик указывает выбранные параметры и SPI ESP SA, который он формирует в соответствии с Р 1323565.1.035-2021 (пункт 4.1.1).

В зависимости от заданной политики безопасности обновление ключей IPsec SA может быть произведено как с вычислением нового общего ключа по протоколу Диффи-Хеллмана, так и без него. В первом случае новое защищенное соединение IPsec будет обладать свойством PFS, во втором — нет.

Секции TSi и TSr в ответе содержат селектор трафика, который будет защищаться данным защищенным соединением, и могут представлять подмножество того, что предложил инициатор создания IPsec SA.

4.3.4 Обмен INFORMATIONAL

4.3.4.1 Общие сведения об обмене INFORMATIONAL

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

Сообщения в INFORMATIONAL обмене могут быть пустыми (то есть не содержать ничего, кроме пустой секции Encrypted) или содержать одну или более секций Notify, Delete или Configuration. Получатель сообщения с запросом в INFORMATIONAL обмене должен послать какой-либо ответ; в противном случае противоположная сторона будет считать, что сообщение не дошло и перепошлет его.

Примечание — Несмотря на то, что пустая секция Encrypted не содержит полезных данных, ее содержимое (см. рисунок 20) зашифровывают, а само сообщение аутентифицируют как и любое сообщение IKEv2, переданное после установления IKE SA.

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

Обработка обмена INFORMATIONAL зависит от его содержимого.

4.3.4.2 Удаление защищенных соединений посредством обмена INFORMATIONAL

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

Обычно ответное сообщение в INFORMATIONAL обмене будет содержать секцию Delete для парных защищенных соединений противоположного направления (на диаграмме ниже обозначенных как SPI1 и SPI2):

IKE SA также удаляют посредством INFORMATIONAL обмена. Удаление защищенного соединения IKE неявно удаляет все оставшиеся IPsec SA, которые были созданы в его контексте. Ответом на запрос на удаление IKE SA является сообщение INFORMATIONAL обмена, не содержащее никаких секций, кроме пустой секции Encrypted:

4.3.4.3 Проверка жизнеспособности IKE SA

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

4.3.5 Информационные сообщения вне защищенного соединения IKE

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

• если полученный ESP пакет содержит неизвестный получателю SPI. Это может быть следствием того, что получатель перезагрузился и потерял все защищенные соединения, из-за ошибок в системе или результатом проведения атаки;
• если на порт 500 или 4500 получено зашифрованное сообщение IKE, содержащее неизвестный получателю идентификатор защищенного соединения (IKE SPI). Это может быть следствием того, что получатель перезагрузился и потерял все IKE SA из-за ошибок в системе, или результатом проведения атаки;
• если получено сообщение IKE с большим номером версии IKE, чем поддерживает данная реализация.

В первом случае, если получатель имеет активное защищенное соединение (IKE SA) с IP-адресом, с которого был получен пакет, то он может послать уведомление INVALID_SPI в INFORMATIONAL обмене по этому соединению. Данные уведомления содержат SPI из полученного пакета. Если подходящего защищенного соединения IKE не существует, сторона может послать информационное сообщение без криптографической защиты на адрес, с которого был получен пакет, используя порт источника пакета в качестве порта назначения, если пакет был инкапсулирован в UDP (UDP-инкапсулированные ESP). Поскольку такое сообщение может легко быть подделано, то получатель должен воспринимать его только как признак того, что возможно у противоположной стороны отсутствует данное защищенное соединение. Это сообщение не является частью INFORMATIONAL обмена, и его получатель не должен отвечать на него. Сообщение формируется следующим образом: поскольку реальные идентификаторы защищенного соединения IKE в этом случае отсутствуют, то приемлемо использовать в их качестве нулевые или случайные значения; это является исключением из правила, описанного в 4.2, запрещающего нулевой идентификатор защищенного соединения IKE для инициатора. Флаг Initiator устанавливается в 1, флаг Response сбрасывается в 0, значение версии протокола формируется обычным образом; все эти флаги рассмотрены в 5.1.

Во втором и третьем случаях сообщение всегда посылается без криптографической защиты (вне контекста IKE SA) и включает уведомление INVALID_IKE_SPI либо уведомление INVALID_MAJOR_VERSION. Сообщение является ответом и поэтому его посылают на IP-адрес и порт, с которого был получен запрос, с теми же идентификаторами IKE SA, идентификатором сообщения и типом обмена, которые были в запросе. Флаг Response устанавливается в 1, а версия протокола формируется обычным образом.

4.3.6 Иерархия обменов в IKEv2

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

Таблица 1

Обмены IKEv2

4.4 Согласование криптографических алгоритмов

4.4.1 Общие сведения о согласовании криптографических алгоритмов

Секция SA содержит предложения по набору IPsec-протоколов (IKE, ESP) для защищенного соединения и криптографические алгоритмы, ассоциированные с каждым протоколом.

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

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

• каждое предложение содержит один протокол. Если ответчик принимает предложение, то ответная секция SA должна содержать тот же протокол. Ответчик должен принять единственное предложение либо отвергнуть их все и вернуть ошибку в уведомлении типа NO_PROPOSAL_CHOSEN;
• каждое предложение протокола IPsec содержит один или более трансформов. Принятый криптографический набор должен содержать по одному-единственному трансформу каждого типа, включенному в предложение.

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

4.4.2 Согласование алгоритма обмена ключами

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

Инициатор вырабатывает открытый ключ протокола Диффи-Хеллмана для наиболее приемлемого (с его точки зрения) алгоритма обмена ключами из предложенных инициатором ответчику в секции SA и посылает этот ключ в секции KE. В том случае, если ответчика этот алгоритм устраивает, обмен продолжается как обычно и ответчик возвращает его как выбранный алгоритм обмена ключами. Если же ответчик выбирает другой алгоритм обмена ключами, то в ответном сообщении он возвращает уведомление об ошибке INVALID_KE_PAYLOAD, содержащее выбранный им алгоритм обмена ключами из предложенных инициатором в секции SA. Получив такое уведомление, инициатор должен послать новый запрос, включив в него без изменения все секции исходного запроса за исключением того, что для секции KE должен быть выработан новый открытый ключ, соответствующий алгоритму, выбранному ответчиком. Новый запрос в случае обмена CREATE_CHILD_SA посылают как новый обмен, с новым значением MSGID, в случае обмена IKE_SA_INIT новый запрос не меняет значение MSGID, которое остается равным 0.

В обмене IKE_SA_INIT это выглядит следующим образом:

В обмене CREATE_CHILD_SA это выглядит следующим образом:

Обозначение KEi' на диаграммах выше призвано подчеркнуть, что открытый ключ протокола Диффи-Хеллмана вырабатывают заново.

Возможна ситуация, когда в обмене CREATE_CHILD_SA инициатор в качестве одного из алгоритмов обмена ключами предложил NONE (в тех случаях, когда это допустимо, то есть при создании или обновлении IPsec SA), при этом включив в сообщение секцию KEi с открытым ключом для другого предложенного алгоритма. Если в этом случае ответчик выбирает NONE, то он не посылает уведомление INVALID_KE_PAYLOAD, а продолжает обмен как обычно без секции KEr.

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

Секции Traffic Selector определяют критерии выбора IP-пакетов, которые будут защищаться вновь создаваемым IPsec SA. Две секции TSi и TSr появляются в каждом из сообщений в обмене, который создает пару IPsec SA. Каждая из секций TSi и TSr содержит одну или более подсекций Selector. Каждая подсекция Selector содержит диапазон адресов (IPv4 или IPv6), диапазон портов и идентификатор IP-протокола.

Первая из двух секций TS обозначена TSi (Traffic Selector-Initiator). Вторая обозначена как TSr (Traffic Selector-Responder). TSi определяет адрес источника для IP-пакетов, идущих от инициатора создания пары IPsec SA (или адрес назначения для IP-пакетов, идущих в его сторону). TSr определяет адрес назначения для IP-пакетов, идущих в сторону ответчика при создании пары IPsec SA (или адрес источника для IP-пакетов, идущих от него). Например, если инициатор запрашивает создание пары IPsec SA и желает туннелировать весь трафик из подсети 192.168.100.0/24 на стороне инициатора на подсеть 192.168.2.0/24 на стороне ответчика, то инициатор включит по одной подсекции Selector в каждую секцию TS. TSi будет определять диапазон адресов (192.168.100.0 — 198.168.100.255), a TSr будет определять диапазон адресов (192.168.2.0 — 192.168.2.255). Если такое предложение устраивает ответчика, он пошлет в ответе идентичные секции TS.

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

Когда ответчик выбирает подмножество из множества адресов и портов из селектора трафика, предложенного инициатором, он таким образом «сужает» предложенный инициатором селектор. Если тип какой-то из подсекций Selector в предложенном инициатором селекторе трафика неизвестен, то ответчик ее игнорирует, так что подсекция Selector с неизвестным типом не включается в суженное подмножество.

Для того чтобы ответчик мог корректно сузить селектор трафика, инициатору следует включить в секции TSi и TSr в качестве самой первой подсекции Selector селектор с конкретными адресами из IP-пакета, запустившего процесс создания IPsec SA, если SA создается как реакция на исходящий IP-пакет. Например, инициатор включает в секцию TSi две подсекции Selector: первая содержит диапазон из одного адреса (198.168.100.43 — 198.168.100.43) вместе с портом источника и IP-протоколом из IP-пакета, а вторая содержит весь допустимый диапазон адресов (198.168.100.0 — 198.168.100.255) вместе со всеми допустимыми портами и IP-протоколами. Подобным же образом инициатор включает две подсекции Selector в TSr. Если инициатор создает пару IPsec SA не в ответ на исходящий IP-пакет, а например при старте системы, то в этом случае может не быть адресов, наличие которых в селекторе защищенного соединения инициатор считал бы обязательным. В этом случае первая подсекция Selector в TSi и TSr может представлять диапазон, а не специфические значения.

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

• если политика безопасности ответчика не разрешает трафик ни по одному из селекторов, определенных в подсекциях Selector, предложенных инициатором, то он отвечает сообщением с уведомлением TS_UNACCEPTABLE;
• если политика безопасности ответчика разрешает трафик по всему множеству селекторов, определенных в подсекциях Selector, включенных в TSi и TSr, то в сужении нет необходимости и ответчик может вернуть те же самые TSi и TSr;
• если политика безопасности ответчика разрешает трафик по первым подсекциям Selector из TSi и TSr, то ответчик должен сузить селектор трафика, сделав его подмножеством предложенного инициатором, при этом включающим в себя первые селекторы. В примере выше ответчик мог бы ответить с TSi равным (198.168.100.43 — 198.168.100.43) со всеми портами и IP-протоколами;
• если политика безопасности ответчика не разрешает трафик первым подсекциям Selector из TSi и TSr, то ответчик сужает TSi и TSr до приемлемого для себя уровня.

Результатом выполнения сужения может оказаться наличие нескольких подмножеств, каждое из которых допустимо, а их объединение — нет. В этом случае ответчик произвольно выбирает одно из них и может включить в ответ уведомление ADDITIONAL_TS_POSSIBLE. Уведомление ADDITIONAL_TS_POSSIBLE означает, что ответчик сузил предложенный селектор трафика, при этом какие-то части из того, что было выкинуто, также допустимы, но только в отдельном защищенном соединении. Никаких данных с этим типом уведомления не ассоциируется. Эта ситуация может возникнуть, только если конфигурации инициатора и ответчика не совпадают. Если политики безопасности инициатора и ответчика согласованы, то инициатор никогда не предложит более широкий селектор трафика, чем ответчик может принять.

Возможно, что политика безопасности ответчика составлена таким образом, что содержит множество небольших диапазонов, которые покрываются селектором трафика, предложенным инициатором, но при этом она требует, чтобы трафик по каждому из диапазонов защищался своим IPsec SA. Продолжая пример, приведенный выше, ответчик может иметь политику безопасности, допускающую туннелирование предложенных инициатором адресов, но требующую, чтобы каждая пара адресов защищалась отдельным IPsec SA. Если инициатор делает свой запрос не на основе реального IP-пакета, а, например в момент старта системы, то в этом случае специфичные первые подсекции Selector, которые помогли бы ответчику выбрать правильный диапазон, будут отсутствовать. У ответчика не будет возможности определить, какая пара адресов должна присутствовать в создаваемом туннеле, и ему придется угадывать либо отвергнуть запрос с сообщением, содержащим уведомление SINGLE_PAIR_REQUIRED. Это уведомление говорит о том, что данный запрос на создание IPsec SA является неприемлемым, поскольку ответчик готов принять только селекторы трафика, определяющие одну пару адресов. Ожидается, что инициатор повторит свой запрос, включив в него только ту пару адресов, для которой он создает защищенное соединение.

4.6 Обновление ключей

4.6.1 Общие сведения об обновлении ключей

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

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

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

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

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

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

IKEv2 явно разрешает одновременное существование нескольких IPsec SA с одинаковыми селекторами трафика между двумя абонентами.

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

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

4.6.2 Одновременное обновление ключей IPsec SA

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

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

Ниже следует объяснение того, как это влияет на реализацию протокола. Предположим, что абоненты A и B имеют существующую пару IPsec SA с SPI (SPIa1, SPIb1) и оба начинают обновление ключей в одно и то же время:

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

Теперь B тоже знает, что происходит одновременное обновление ключей. Он отвечает как обычно:

В этот момент существуют три пары IPsec SA между A и B (старая и две новых). A и B теперь могут сравнить нонсы. Предположим, что наименьшим был нонс Nr1 в сообщении ответ2; в этом случае B (отправитель сообщения запрос2) удаляет лишнее новое защищенное соединение, а A (сторона, инициировавшая оставшееся новое защищенное соединение) удаляет старое:

Обновление ключей теперь завершено.

Однако существует вторая возможная последовательность событий, которая может иметь место, если сообщения теряются в сети, приводя к перепосылкам. Обновление ключей начинается как обычно, но первое сообщение от A (запрос1) теряется:

С точки зрения B обновление ключей уже завершено, а поскольку он не получил сообщение запрос1 от A, то он не знает, что имело место одновременное обновление ключей. Однако A, не получив ответа на сообщение запрос1, будет продолжать перепосылать его и когда-нибудь он достигнет B:

Для B это выглядит так, что A пытается обновить ключи защищенного соединения, которого уже не существует; таким образом, B отвечает на запрос уведомлением о нефатальной ошибке CHILD_SA_NOT_FOUND.

Когда A получает это уведомление, он уже знает, что имело место одновременное обновление, так что он может игнорировать сообщение об ошибке.

4.6.3 Одновременное обновление ключей IKE SA

Самый сложный случай возникает, если оба абонента пытаются одновременно обновить ключи IKE SA. В этом случае также применимы общие положения, описанные в 4.6, однако важно быть уверенным в том, что IPsec SA наследуются правильным IKE SA.

Случай, когда обе стороны обнаружили одновременное обновление, обрабатывается аналогично ситуации с IPsec SA. После обменов CREATE_CHILD_SA между A и B существуют три IKE SA: старое IKE SA и два новых IKE SA. Новое IKE SA с наименьшим нонсом следует удалить той стороне, которая его создала, а оставшееся новое IKE SA должно унаследовать все IPsec SA.

В дополнение к обычным случаям одновременного обновления ключей существует особый случай, когда один из участников завершает свое обновление до того, как он обнаруживает, что вторая сторона тоже обновляет ключи. Если только один абонент обнаруживает одновременное обновление, то лишние IKE SA не создаются. Если абонент, не заметивший одновременного обновления, получает запрос на обновление ключей защищенного соединения, которое он уже успешно обновил, то ему следует отослать уведомление TEMPORARY_FAILURE: это то самое защищенное соединение, которое он в данный момент пытается удалить после его обновления. Это следует сделать независимо от того, послал ли абонент уже сообщение о его удалении или еще нет. Если абонент, который заметил одновременное обновление, получает от другой стороны запрос на удаление старого IKE SA, то он знает, что противоположная сторона не обнаружила одновременного обновления и может забыть о своей попытке обновить IKE SA:

В этот момент абонент B видит запрос на удаление IKE SA. Ему ничего не остается, как ответить обычным образом. Однако, при этом абонент B должен прекратить перепосылки запрос2, поскольку, как только абонент A получит ответ3, он немедленно удалит все данные, ассоциированные со старым IKE SA, и не будет способен ответить на запрос:

4.6.4 Обновление ключей и повторная аутентификация

Обновление ключей IKE SA и повторная аутентификация являются различными сущностями в IKEv2. Обновление ключей задает новые ключи для IKE SA, но не вызывает повторную аутентификацию абонентов (в сообщениях отсутствуют секция Authentication).

В IKEv2 нет специального механизма для повторной аутентификации. Она может быть выполнена путем создания нового защищенного соединения IKE «с нуля» (используя обмены IKE_SA_INIT/IKE_AUTH), создания новых IPsec SA в контексте нового соединения и затем удаления старого соединения (которое также удалит старые IPsec SA).

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

4.7 Коллизии обменов

4.7.1 Общие сведения о коллизиях обменов

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

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

Уведомление TEMPORARY_FAILURE следует посылать при получении запроса, который в текущий момент не может быть выполнен, например вследствие операции обновления ключей. Если инициатор получает в ответ уведомление TEMPORARY_FAILURE, то он не должен повторять запрос немедленно; необходимо выждать время, чтобы дать возможность противоположной стороне завершить операцию, вызвавшую временную неспособность выполнить запрос. Инициатор может повторить запрос один или несколько раз в течение нескольких минут. Если он продолжает получать уведомления TEMPORARY_FAILURE в течение нескольких минут, то ему следует удалить данное IKE SA.

Уведомление CHILD_SA_NOT_FOUND следует посылать, если реализация IKE получает запрос на обновление ключей несуществующего IPsec SA. IPsec SA, которое инициатор пытается обновить, указывается в поле SPI секции Notify, куда копируется содержимое поля SPI из уведомления REKEY_SA. Абоненту, который получает уведомление CHILD_SA_NOT_FOUND, следует удалить это IPsec SA без информирования другой стороны (если это защищенное соединение еще существует) и послать запрос на создание нового IPsec SA «с нуля» (если его еще нет).

4.7.2 Коллизии при обновлении ключей или удалении IPsec SA

Если абонент получает запрос на обновление ключей IPsec SA, которое он в этот момент пытается удалить, то ему следует ответить уведомлением TEMPORARY_FAILURE. Если абонент получает запрос на обновление ключей IPsec SA, которое он в этот момент сам обновляет, то ему следует ответить как обычно и следует быть готовым к тому, чтобы впоследствии удалить лишние защищенные соединения на основании сравнения нонсов (см. 4.6.2). Если абонент получает запрос на обновление ключей IPsec SA, которого не существует, то ему следует ответить уведомлением CHILD_SA_NOT_FOUND.

Если абонент получает запрос на удаление IPsec SA, которое он в этот момент пытается удалить, то ему следует ответить без секции Delete (см. 4.3.4.2). Если абонент получает запрос на удаление IPsec SA, которое он в этот момент пытается обновить, то ему следует ответить как обычно, с секцией Delete. Если абонент получает запрос на удаление IPsec SA, которого не существует, то ему следует ответить без секции Delete.

Если абонент получает запрос на обновление ключей IKE SA в тот момент, когда он создает, обновляет или удаляет IPsec SA по данному IKE SA, ему следует ответить уведомлением TEMPORARY_FAILURE.

4.7.3 Коллизии при обновлении ключей или удалении IKE SA

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

Если абонент получает запрос на удаление IKE SA, которое он в этот момент обновляет, то ему следует ответить как обычно и забыть про свой запрос на обновление. Если абонент получает запрос на удаление IKE SA, которое он в этот момент пытается удалить, то ему следует ответить как обычно и забыть про свой запрос на удаление.

Если абонент получает запрос на создание или обновление IPsec SA в тот момент, когда он обновляет IKE SA, ему следует ответить уведомлением TEMPORARY_FAILURE. Если абонент получает запрос на удаление IPsec SA в тот момент, когда он обновляет IKE SA, ему следует ответить как обычно, с секцией Delete.

4.8 Обработка ошибок

4.8.1 Общие сведения об обработке ошибок

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

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

Только ошибки аутентификации (AUTHENTICATION_FAILED) и неправильно сформированное сообщение (INVALID_SYNTAX) приводят к неявному удалению IKE SA (без проведения обмена INFORMATIONAL, содержащего секцию Delete).

4.8.2 Обработка ошибок в IKE_SA_INIT

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

В обмене IKE_SA_INIT любое уведомление об ошибке приводит к тому, что он завершается как неудавшийся обмен. Однако некоторые уведомления об ошибках, такие как COOKIE, INVALID_KE_PAYLOAD или INVALID_MAJOR_VERSION, могут вызывать последующий успешный обмен. Поскольку уведомления об ошибках в обмене IKE_SA_INIT никак не аутентифицированы, то инициатор должен продолжать посылать запросы некоторое время, прежде чем отказаться от создания данного IKE SA. То есть, при получении уведомления об ошибке в обмене IKE_SA_INIT, инициатор должен немедленно реагировать только в тех случаях, когда соответствующая реакция прописана в настоящих рекомендациях (то есть для уведомлений COOKIE, INVALID_KE_PAYLOAD и INVALID_MAJOR_VERSION).

4.8.3 Обработка ошибок в IKE_AUTH

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

Примечание - Несмотря на то, что сообщения IKE_AUTH зашифрованы и их целостность защищена, инициатор в этом случае еще не аутентифицировал ответчика и не может быть уверенным, что сообщение послано именно тем абонентом, с которым он рассчитывает установить IKE SA.

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

Запросы, содержащие неподдерживаемые секции, помеченные как критические, или если само сообщение некорректно сформировано (а не просто содержит некорректные данные в какой-либо секции), должны отбрасываться целиком и должны вызывать только отсылку в ответе уведомлений UNSUPPORTED_CRITICAL_PAYLOAD или INVALID_SYNTAX. Получатель не должен в этом случае обрабатывать секции, относящие к аутентификации.

Если аутентификация была успешной в обмене IKE_AUTH, то IKE SA создается; однако, создание IPsec SA или запрос конфигурационной информации при этом могут окончиться неудачей. Эта неудача не приводит к автоматическому удалению IKE SA. В частности, ответчик может включить в ответ все секции, связанные с аутентификацией (IDr, Certificate и Authentication), но при этом послать уведомление об ошибке создания IPsec SA (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN и т.п.), в этом случае инициатор не должен считать аутентификацию неудачной. Инициатор может удалить такое IKE SA впоследствии, если это предписано его политикой безопасности.

В обмене IKE_AUTH (или в немедленно следующем после него обмене INFORMATIONAL, если ошибка случилась при обработке ответа на IKE_AUTH) только наличие уведомлений UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX и AUTHENTICATION_FAILED приводит к тому, что IKE SA удаляется или не создается без отсылки секции Delete.

4.8.4 Обработка ошибок после аутентификации противоположной стороны

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

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

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

Ошибки проверки имитовставки должны приводить к отбрасыванию сообщения без отсылки каких-либо уведомлений (если иное не предписано политикой безопасности).

4.8.5 Обработка ошибок вне защищенного соединения IKE

Реализация протокола должна ограничивать частоту отсылки сообщений в ответ на незащищенные сообщения.

Если абонент получает сообщение на UDP порт 500 или 4500 вне известных контекстов IKE SA (и это не запрос на создание новой IKE SA), то это может быть следствием недавнего аварийного завершения работы данного абонента. Если сообщение помечено как ответ, то абонент не должен на него отвечать. Если сообщение помечено как запрос, то абонент может на него ответить. В этом случае ответ должен отсылаться на тот IP-адрес и порт, с которого пришел запрос, с теми же IKE SPI и MSGID, скопированными из него. Сообщение не должно быть криптографически защищено и должно содержать уведомление INVALID_IKE_SPI.

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

4.9 Токен проверки актуальности запроса (cookie)

Если ответчик обнаруживает у себя большое количество незавершенных IKE SA, ему следует в ответ на запросы обмена IKE_SA_INIT посылать уведомление COOKIE. Данные этого уведомления должны иметь размер от 1 до 64 байт, а их выработка описана ниже. Если ответ IKE_SA_INIT содержит уведомление COOKIE, инициатор должен повторить свой запрос, включив в него в качестве самой первой секции в сообщении уведомление COOKIE с содержимым, побитно скопированным из полученного уведомления, при этом все остальные секции должны остаться неизменными по отношению к изначальному запросу. Начальный обмен при этом выглядит следующим образом:

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

Первые два сообщения (запрос1 и ответ1) не меняют состояние IKE у инициатора и ответчика (помимо самого факта отсылки токена). В частности, идентификатор сообщения MSGID в первых четырех сообщениях, относящихся к обмену IKE_SA_INIT (запрос1, ответ1, запрос2 и ответ2), будет равен 0, а в последних двух сообщениях, относящихся к обмену IKE_AUTH (запрос3 и ответ3), будет равен 1.

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

cookie = VersionIdOfSecret|hash(Ni|IPi|SPIi|secret), (1)

где hash() — криптографически стойкая хэш-функция;

Ni — значение секции Ni из сообщения запрос1;

IPi — IP-адрес, с которого пришло сообщение запрос1;

SPIi — SPIi из сообщения запрос1;

secret — случайная величина, известная только ответчику и периодически заменяемая;

VersionIdOfSecret — версия переменной secret; эту величину следует менять при каждом изменении величины secret.

При таком методе выработки токена он может быть вычислен повторно при получении второго сообщения IKE_SA_INIT (запрос2) и сравнен с токеном из этого сообщения. Если они совпали, то ответчик удостоверяется, что токен в сообщении был выработан после последнего изменения secret и что IPi не изменился по сравнению с IP-адресом источника в первом сообщении (запрос1). Включение в вычисление SPIi гарантирует, что если одновременно создается несколько IKE SA с одним IP-адресом, то все токены будут разными (при условии уникальности SPIi). Включение в вычисление Ni гарантирует, что нарушитель, который видел только сообщение ответ1, не сможет подделать сообщение запрос2.

Если новое значение величины secret вырабатывается в то время, когда существуют защищенные соединения, находящиеся в процессе создания, то токен в ответе IKE_SA_INIT может быть вычислен с другой версией ключа VersionIdOfSecret, чем текущая. В этом случае ответчик может отвергнуть сообщение и послать новый ответ с заново сформированным токеном или может хранить старые значения secret в течение некоторого времени и принимать токены, сделанные с использованием предыдущих версий secret. Ответчику следует достаточно часто менять значение secret, особенно при наличии большого числа соединений с неподтвержденными IP-адресами инициаторов.

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

4.10 Вектора со случайными данными (нонсы)

Сообщения обменов IKE_SA_INIT содержат случайные (или псевдослучайные) данные (нонсы), которые используются в качестве исходных данных для криптографических операций. Запрос и ответ обмена CREATE_CHILD_SA также содержат нонсы. Эти нонсы используются для добавления энтропии при выработке ключей для IKE SA и IPsec SA и для гарантии получения стойкого псевдослучайного числа из общего ключа, вычисляемого в соответствии с трансформом KE. Нонсы должны быть случайными или псевдослучайными и должны вырабатываться заново при каждом их использовании в IKEv2.

4.11 Работа при наличии трансляции сетевых адресов (NAT)

4.11.1 Общие сведения о работе при наличии трансляции сетевых адресов (NAT)

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

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

Примечание - Как правило, на каждую сессию TCP (или псевдо-сессию UDP) NAT создает внутреннюю структуру данных, сопоставляющую IP-адреса и порты до и после их трансляции. Далее по тексту такое сопоставление называется отображением сетевых адресов.

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

Инициатор может использовать порт 4500 для IKE и ESP с самого начала установления IKE SA (с обмена IKE_SA_INIT) независимо от того, есть ли между абонентами NAT. Если любая из сторон использует порт 4500, то отсылка ESP с UDP инкапсуляцией не является обязательной, но распознавание полученного UDP-инкапсулированного ESP пакета является обязательным. Инкапсуляция ESP в UDP не должна применяться с использованием порта 500. Оба абонента должны быть способны получать и обрабатывать в любой момент времени как UDP-инкапсулированные ESP пакеты, так и пакеты без UDP инкапсуляции. Каждая из сторон принимает решение, использовать или нет UDP инкапсуляцию для ESP, независимо от решения другой стороны. Однако, если обнаружено присутствие NAT, то обе стороны должны использовать инкапсуляцию ESP в UDP.

Ниже перечислены конкретные требования по поддержке прохождения через NAT:

а) Инициатор и ответчик IKE должны включить в сообщения IKE_SA_INIT секции Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти секции могут использоваться для обнаружения факта присутствия NAT между абонентами и определения того, какой из абонентов находится за NAT.

б) Данные, ассоциированные с уведомлением NAT_DETECTION_SOURCE_IP, представляют собой результат применения функции сжимающего отображения nSHA для IKE SPI инициатора и ответчика (в том порядке, в каком они присутствуют в заголовке) IP-адреса и порта, откуда это сообщение было отправлено. В сообщении может присутствовать несколько уведомлений NAT_DETECTION_SOURCE_IP, если отправитель не знает, какое из нескольких сетевых подключений будет использовано для отправки сообщений IKE. Формулы (2) и (3) описывают вычисление данных, ассоциированных с уведомлением NAT_DETECTION_SOURCE_IP, для запроса и ответа обмена IKE_SA_INIT соответственно:

NAT_DET_SRC_{i}^{j} = nSHA(SPI_{i}|0_{8}|IP_{i}^{j}|P_{i}), (2)

NAT_DET_SRC_{r}^{j} = nSHA(SPI_{i}|SPI_{r}|IP_{r}^{j}|P_{r}), (3)

где j — номер сетевого интерфейса, с которого может уйти отсылаемый пакет;

IP_{i}^{j} — IP-адрес сетевого интерфейса j (возможный адрес источника сообщения, отсылаемого инициатором);

IP_{r}^{j} — IP-адрес сетевого интерфейса j (возможный адрес источника сообщения, отсылаемого ответчиком);

Pi — порт источника сообщения, отсылаемого инициатором;

Pr — порт источника сообщения, отсылаемого ответчиком;

SPIi, SPIr — значения SPI из заголовка IKE;

08 — восемь байт нулей.

в) Данные, ассоциированные с уведомлением NAT_DETECTION_DESTINATION_IP, представляют собой результат применения функции сжимающего отображения nSHA для IKE SPI инициатора и ответчика (в том порядке, в каком они присутствуют в заголовке), IP-адреса и порта, куда было отправлено сообщение. Формулы (4) и (5) описывают вычисление данных, ассоциированных с уведомлением NAT_DETECTION_DESTINATION_IP, для запроса и ответа обмена IKE_SA_INIT соответственно:

NAT_DET_DSTi = nSHA(SPIi|08|IPr|Pr), (4)

NAT_DET_DSTr = nSHA(SPIi|SPIr|IPi|Pi), (5)

где IPi — IP-адрес назначения сообщения, отсылаемого ответчиком;

IPr — IP-адрес назначения сообщения, отсылаемого инициатором;

Pi — порт назначения сообщения, отсылаемого ответчиком;

Pr — порт назначения сообщения, отсылаемого инициатором;

SPIi, SPIr — значения SPI из заголовка IKE;

08 — восемь байт нулей.

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

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

е) Инициатор IKE должен проверить значения уведомлений NAT_DETECTION_SOURCE_IP или NAT_DETECTION_DESTINATION_IP, если они присутствуют, и если они не соответствуют адресам сообщения, то инициатор должен отправлять весь будущий IKE и ESP трафик, ассоциированный с этим IKE SA, по UDP порту 4500.

ж) При отправке сообщений IKE по UDP порту 4500 отсылающая сторона добавляет четыре нулевых байта между UDP заголовком и заголовком IKE. При туннелировании ESP пакетов по UDP порту 4500 ESP заголовок следует немедленно за UDP заголовком. Поскольку первые четыре байта ESP заголовка содержат SPI, а валидный SPI не может быть нулевым, то всегда возможно различить ESP и IKE сообщения.

и) Реализация протокола должна корректно обрабатывать получаемые UDP-инкапсулированные ESP пакеты, даже если NAT между абонентами не обнаружен.

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

4.11.2 Поддержание отображения сетевых адресов в активном состоянии

Как правило, NAT устройства при создании нового отображения адресов для протокола UDP устанавливают достаточно короткое время жизни для этого отображения — часто менее минуты, после чего при отсутствии трафика, использующего это отображение, оно удаляется. Если такое случится, то ответчик не сможет ничего послать инициатору до тех пор, пока инициатор не пошлет какое-либо IKE сообщение или ESP пакет, и NAT не создаст новое отображение для него, что может произойти через неопределенное время.

Поскольку трафик ESP и IKEv2 не является постоянным, то в ситуации, когда стороны обнаружили наличие NAT между ними, та сторона, которая находится за NAT, должна периодически посылать специальные пакеты с целью поддержания текущего отображения адресов. Такие пакеты, называемые NAT keepalives, представляют собой UDP датаграммы, содержащие 1 байт данных, равный 0xff. Рекомендуемая периодичность передачи таких пакетов — раз в 20 секунд при условии отсутствия исходящего IKE или ESP трафика с данным абонентом в течение предыдущих 20 секунд. Пакеты NAT keepalives не защищаются, поскольку не несут никакой полезной информации и служат только для поддержания текущего отображения сетевых адресов NAT устройствами. При получении пакетов NAT keepalives они должны отбрасываться.

4.12 Фрагментация сообщений

Протокол IKEv2 использует UDP в качестве транспорта для обмена своими сообщениями. Как правило, размер сообщений не превышает одного килобайта, но в некоторых случаях, например при включении в сообщения сертификатов, их размер может превысить максимальный допустимый размер пакета, определенный для данного сетевого интерфейса, и такие сообщения будут разделены на фрагменты на уровне протокола IP. Фрагментация на уровне IP может приводить к проблемам при наличии по пути следования пакета сетевых устройств, реализующих трансляцию адресов (NAT) или межсетевых экранов. Для корректной трансляции адреса у фрагментированных IP-пакетов реализация NAT в большинстве случаев вынуждена хранить временные данные на каждый обрабатываемый пакет, что требует ресурсов. Аналогичные проблемы с фрагментированными IP-пакетами возникают и у межсетевых экранов. По этой причине многие реализации NAT и межсетевые экраны в этой ситуации просто не пропускают фрагментированные IP-пакеты. Такое поведение в случае с большими сообщениями IKEv2 приводит к невозможности создать IKE SA и, как следствие, к неработоспособности протокола.

Для предотвращения отправки фрагментированных IP-пакетов в IKEv2 есть механизм, позволяющий разделять большие сообщения на несколько сообщений меньшего размера на уровне IKE, при этом каждое из таких сообщений не приводит к фрагментации на уровне IP. Использование данного механизма в IKEv2 является опциональным, однако реализациям протокола рекомендуется его поддерживать.

Абоненты договариваются о поддержке IKE фрагментации путем включения уведомления IKEV2_FRAGMENTATION_SUPPORTED в сообщения обмена IKE_SA_INIT. Если оба абонента включили это уведомление, то в дальнейших обменах IKE фрагментация может быть использована, в противном случае — нет. IKE фрагментация не может быть использована в самом обмене IKE_SA_INIT. Как правило, сообщения обмена IKE_SA_INIT имеют размер, не приводящий к необходимости их фрагментации на уровне IP.

Если абоненты согласовали возможность использования IKE фрагментации в данном защищенном соединении, то сообщения могут разделяться на фрагменты в любом из последующих обменов, начиная с IKE_AUTH. Использование IKE фрагментации не является обязательным; решение, использовать ли ее в каждом конкретном обмене, обычно принимает инициатор этого обмена. Возможна ситуация, когда сначала инициатор посылает нефрагментированное сообщение, а после нескольких безответных повторов разделяет его на фрагменты и далее продолжает посылать уже их. Возможно также, что инициатор с самого начала обмена фрагментирует сообщение. В некоторых случаях использовать IKE фрагментацию нецелесообразно, например, если сообщения в обмене имеют заведомо малый размер. В общем случае при принятии решения об использовании IKE фрагментации следует руководствоваться следующими соображениями:

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

б) если IKE фрагментация уже была использована в предыдущих обменах, то следует продолжать ее использовать;

в) не следует использовать IKE фрагментацию, если сообщение, скорее всего, не будет фрагментировано на уровне IP (например, размер сообщения мал).

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

Сообщение IKE может быть фрагментировано, только если оно содержит секцию Encrypted. Все сообщения IKE, передаваемые после окончания обмена IKE_SA_INIT, удовлетворяют этому требованию. Фрагментация сообщения происходит следующим образом. Содержимое секции Encrypted (содержащее другие секции) до его зашифрования разбивается на блоки подходящего размера, каждый из которых становится исходным содержимым секции Encrypted Fragment. Формат секции Encrypted Fragment описан в 5.16. Разбивка содержимого секции Encrypted на блоки осуществляется без учета границ секций, содержащихся внутри данной секции, т.е. содержимое интерпретируется как бинарный массив. Каждая из полученных секций Encrypted Fragment зашифровывается так же, как секция Encrypted, и помещается в отдельное сообщение IKE со своим заголовком, который должен быть идентичен заголовку исходного сообщения, за исключением двух полей — Length и Next Payload (в частности, в поле Next Payload значение Encrypted заменяется на Encrypted Fragment). При этом MSGID у всех этих сообщений будет одинаковым. Все полученные таким образом сообщения отсылаются вместе:

Размер фрагмента выбирают таким образом, чтобы полученное сообщение не подвергалось дальнейшему фрагментированию на уровне IP. Рекомендуется для протокола IPv4 использовать размер 576 байт, а для IPv6 — 1280 байт.

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

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

4.13 Использование транспортного протокола TCP

4.13.1 Общие сведения об использовании TCP

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

В IKEv2 не предусмотрена возможность согласовывать использование транспортного протокола в момент создания защищенного соединения. Транспортный протокол должен быть указан в политике безопасности инициатора для каждого из абонентов, с которым создается IKE SA. Возможен также вариант, когда инициатор сначала пытается создать IKE SA на UDP, а при отсутствии ответа от противоположной стороны в течение некоторого времени переходит на TCP.

В качестве порта назначения в случае TCP используется порт 4500; порт источника, как правило, выбирается системой при создании TCP соединения. Если для IKE SA используется TCP, то ESP пакеты всех IPsec SA, созданных в контексте данного IKE SA, также должны инкапсулироваться в TCP и передаваться по тому же TCP соединению.

4.13.2 Формат инкапсуляции IKE сообщений в TCP

Формат инкапсуляции IKEv2 сообщений в TCP (см. рисунок 1) схож с форматом инкапсуляции в UDP при использовании порта 4500, т.е. любому сообщению IKE предшествуют 4 байта нулей (Non-ESP Marker), которые не являются частью сообщения IKE и требуются для того, чтобы можно было отличить IKE сообщения от ESP пакетов (подробнее см. 4.2). В дополнение к этому для разделения отдельных записей в потоке TCP перед каждым пакетом добавляют поле LEN размером в 2 байта, которое содержит в сетевом порядке байт длину следующего за ним ESP пакета или сообщения IKE (включая Non-ESP Marker в случае IKE) плюс размер самого поля (2 байта).

Рисунок 1 — Формат инкапсуляции IKEv2 в TCP

4.13.3 Префикс TCP инкапсуляции

При создании TCP соединения для целей инкапсуляции IKE сообщений сторона, которая его инициировала, должна немедленно после его создания послать строку «IKETCP» (6 байт: 0x49, 0x4b, 0x45, 0x54, 0x43 и 0x50). Эта последовательность, называемая префиксом TCP инкапсуляции, позволяет приемной стороне определить назначение создаваемого TCP соединения (например, в случае совместного использования TCP портов для разных сервисов). Она должна быть послана до отсылки по данному TCP соединению любых сообщений IKE или ESP пакетов; кроме того, ответчик не должен воспринимать получаемые данные как сообщения IKE или ESP пакеты до получения данной строки сразу после создания TCP соединения. Строка посылается однократно и только инициатором создания TCP соединения.

4.13.4 Создание и закрытие TCP соединений

При начальном установлении IKE SA инициатор, в случае если он использует TCP инкапсуляцию, сначала устанавливает TCP соединение с ответчиком. В дальнейшем это TCP соединение используется для передачи сообщений данного IKE SA, и тех защищенных IKE SA, которые могут создаться в результате обновления ключей данного защищенного соединения IKE, а также ESP пакетов всех IPsec SA, которые были созданы в контексте упомянутых IKE SA. После штатного удаления IKE SA (с отсылкой секции Delete) сторона, инициировавшая создание TCP соединения, должна его удалить, если оно не используется другими IKE SA. Сторона, которая была ответчиком при создании TCP соединения, может его удалить, если оно более не используется ни одним IKE SA.

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

Инициатор должен создавать новое TCP соединение для каждого нового защищенного соединения IKE, если только оно не является результатом обновления ключей существующего IKE SA. При этом, как правило, каждому IKE SA соответствует одно TCP соединение (оно же используется для передачи ESP пакетов тех IPsec SA, которые были созданы под защитой данного IKE SA). При обновлении ключей IKE SA в течение короткого времени одно TCP соединение используется для двух IKE SA одновременно — старого и нового, старое вскоре удаляется.

4.13.5 Поведение протокола в случае использования TCP

При начальном создании IKE SA с использованием протокола UDP стороны определяют наличие NAT между ними путем обмена уведомлениями NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP и, в случае если NAT присутствует, переходят с порта 500 на порт 4500 (см. 4.11). При использовании TCP независимо от присутствия NAT никаких действий по изменению портов предпринимать не нужно. Однако информация о наличии NAT может быть использована, например, для активации механизма корректировки контрольной суммы протоколов UDP и TCP в случае применения ESP в транспортном режиме.

При использовании TCP для IKEv2 фрагментация IKE сообщений (см. 4.12) не требуется. Соответственно, стороны могут не согласовывать ее или не использовать.

В общем случае при наличии NAT между абонентами использование протокола TCP не требует периодической посылки пакетов NAT keepalives (см. 4.11.2), и поэтому посылать их не рекомендуется. Однако абоненты могут отсылать их даже в случае использования TCP. В этом случае пакетам NAT keepalives (как и сообщениям IKE и ESP пакетам) должны предшествовать два байта LEN, содержащих в сетевом порядке байт значение 3 (общая длина данной записи), т.е. в потоке TCP такие пакеты выглядят как последовательность 0x00, 0x03, 0xff.

4.14 Выработка ключевого материала

4.14.1 Общие сведения о выработке ключевого материала

В контексте защищенного соединения IKE согласовывают четыре трансформа: ENCR (обеспечивает конфиденциальность), INTEG (обеспечивает имитозащиту), KE (обеспечивает выработку общего ключа) и PRF (реализует псевдослучайную функцию). Псевдослучайная функция используется для выработки ключевого материала для всех криптоалгоритмов, используемых как в IKE SA, так и в IPsec SA.

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

Примечание - В случае, если для трансформа ENCR согласован AEAD криптоалгоритм, то трансформ INTEG не используется.

Считается, что псевдослучайные функции могут принимать на вход ключи любого размера, но в то же время имеют предпочтительный размер ключа. Предпочтительный размер ключа должен использоваться в качестве длины SKd, SKpi и SKpr (см. 4.14.2). Для псевдослучайных функций на основе конструкции HMAC предпочтительный размер ключа равен размеру выходного значения используемой хэш-функции.

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

prf+(K, S) = T1|T2|T3|T4|..., (6)

где K — ключ;

S — произвольная байтовая строка,

(7)

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

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

4.14.2 Выработка ключевого материала для защищенного соединения IKE

Ключи IKE SA вычисляют следующим образом. Первоначально из нонсов Ni и Nr, которыми стороны обмениваются в процессе обмена IKE_SA_INIT, и общего ключа Kir, вычисляемого в том же обмене по протоколу Диффи-Хеллмана, получается величина, называемая SKEYSEED:

SKEYSEED = prf(Ni|Nr, Kir). (8)

Представление Kir определяется трансформом KE. Если для данного трансформа KE не определено иное, то Kir представляется в виде строки байт в сетевом порядке, дополненной, при необходимости, нулевыми байтами в старших разрядах до величины порядка использованной группы. Ni и Nr — значения нонсов (не включая заголовки соответствующих секций).

Примечание — При использовании стандартизованных российских криптографических алгоритмов представление Kir определено в 6.3.2.

SKEYSEED используется для вычисления семи остальных ключей защищенного соединения IKE

SKd|SKai|SKar|SKei|SKer|SKpi|SKpr = = prf+(SKEYSEED, Ni|Nr|SPIi|SPIr), (9)

т.е. величины SKd, SKai, SKar, SKei, SKer, SKpi и SKpr берут в указанном порядке из выходного потока prf+.

Ключ SKd используют для выработки новых ключей для защищенных соединений IPsec, создаваемых в контексте данного защищенного соединения IKE. Ключи SKai и SKar используют в алгоритме контроля целостности для аутентификации сообщений последующих обменов. Ключи SKei и SKer используют для шифрования сообщений всех последующих обменов. Ключи SKpi и SKpr используют для вычисления содержимого секции Authentication. Длины SKd, SKpi и SKpr должны быть равны предпочтительной длине ключа согласованной псевдослучайной функции.

Для двух направлений трафика используют разные ключи: SKai и SKei используют для защиты сообщений, идущих от инициатора создания IKE SA, а SKar и SKer используют для защиты сообщений, идущих от ответчика.

Примечание — В случае, если для трансформа ENCR согласован AEAD криптоалгоритм, то трансформ INTEG не используется; соответственно, при вычислении ключей согласно формуле (9) длина SKai и SKar полагается равной 0.

4.14.3 Выработка ключевого материала для IPsec SA

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

KEYMAT = prf+(SKd, Ni|Nr), (10)

где Ni и Nr — нонсы из обмена IKE_SA_INIT, если речь идет о первом защищенном соединении, или из обмена CREATE_CHILD_SA, если создаются другие IPsec SA.

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

KEYMAT = prf+(SKd, Kir|Ni|Nr), (11)

где Kir — общий ключ, полученный на выходе протокола Диффи-Хеллмана в обмене CREATE_CHILD_SA. Представление Kir определяется трансформом KE. Если для данного трансформа KE не определено иное, то Kir представляется в виде строки байт в сетевом порядке, дополненной, при необходимости, нулевыми байтами в старших разрядах до величины порядка использованной группы.

Примечание — При использовании стандартизованных российских криптографических алгоритмов представление Kir определено в 6.3.2.

Проведение единичного обмена CREATE_CHILD_SA может приводить к созданию нескольких защищенных соединений. Защищенные соединения ESP существуют в парах (по одному в каждом направлении), так что один обмен приводит к созданию двух IPsec SA. Более того, обмен может включать какие-то будущие IPsec протокол(ы) в дополнение к (или вместо) ESP. В любом случае ключевой материал для каждого IPsec SA следует брать из KEYMAT последовательно слева направо по следующим правилам:

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

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

4.14.4 Обновление ключей IKE SA с использованием обмена CREATE_CHILD_SA

Обмен CREATE_CHILD_SA может быть использован для обновления ключей существующего IKE SA (см. 4.3.3.3). Новые идентификаторы защищенного соединения IKE для инициатора и ответчика передают в поле SPI подсекций Proposal внутри секции SA (не в полях SPI заголовка IKE). При обновлении ключей IKE SA секции TS в сообщениях не присутствуют. SKEYSEED для нового защищенного соединения вычисляют с использованием ключа SKd существующего соединения следующим образом

SKEYSEED = prf(SKd, Kir|Ni|Nr), (12)

где Kir — общий ключ, полученный на выходе протокола Диффи-Хеллмана в обмене CREATE_CHILD_SA. Представление Kir определяется трансформом KE. Если для данного трансформа KE не определено иное, то Kir представляется в виде строки байт в сетевом порядке, дополненной, при необходимости, нулевыми байтами до величины порядка использованной группы;

Ni и Nr — значения нонсов (не включая заголовки соответствующих секций).

Примечание — При использовании стандартизованных российских криптографических алгоритмов представление Kir определено в 6.3.2.

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

Новое защищенное соединение должно сбросить идентификаторы сообщений MSGID в 0.

SKd, SKai, SKar, SKei и SKer вычисляют из SKEYSEED согласно формуле (9), используя SPIi, SPIr, Ni и Nr из нового обмена и псевдослучайную функцию, согласованную для нового защищенного соединения. Ключи SKpi и SKpr в этом случае не вычисляют, так как при обновлении ключей IKE SA повторная аутентификация партнеров не проводится.

4.15 Аутентификация защищенного соединения IKE

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

Для инициатора

BLOBi = MSGi|Nr|prf(SKpi, IDi), (13)

для ответчика

BLOBr = MSGr|Ni|prf(SKpr, IDr), (14)

где MSGi — бинарное представление сообщения, посланного инициатором в обмене IKE_SA_INIT, начиная с первого байта заголовка сообщения (см. 5.1); опциональные поля, которые могут предшествовать сообщению IKE (см. 4.11 и 4.13), не учитываются; если инициатор в обмене IKE_SA_INIT отправил несколько различных сообщений (например, повторив запрос с токеном проверки его актуальности или изменив тип и значение открытого ключа в протоколе Диффи-Хеллмана по запросу ответчика), то в качестве MSGi используется последнее посланное сообщение;

MSGr — бинарное представление сообщения, посланного ответчиком в обмене IKE_SA_INIT, начиная с первого байта заголовка сообщения (см. 5.1); опциональные поля, которые могут предшествовать сообщению IKE (см. 4.11 и 4.13), не учитываются; если ответчик в обмене IKE_SA_INIT отправил несколько различных сообщений (например, запросив вернуть токен проверки актуальности запроса или запросив изменить тип и значение открытого ключа протокола Диффи-Хеллмана), то в качестве MSGr используется последнее посланное сообщение;

Ni, Nr — значения нонсов (векторов со случайными данными), которыми партнеры обменялись в обмене IKE_SA_INIT в секциях Ni и Nr соответственно (используется содержимое поля Nonce Data, см. 5.9);

SKpi, SKpr — ключи, выработанные в обмене IKE_SA_INIT согласно формуле (9);

IDi — идентификационная информация инициатора, посланная им ответчику в обмене IKE_AUTH в секции IDi (используется бинарное представление секции без ее заголовка, т.е. содержимое полей, описанных в 5.5);

IDr — идентификационная информация ответчика, посланная им инициатору в обмене IKE_AUTH в секции IDr (используется бинарное представление секции без ее заголовка, т.е. содержимое полей, описанных в 5.5);

prf — согласованная партнерами псевдослучайная функция.

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

При аутентификации цифровой подписью формирование содержимого секции Authentication осуществляют следующим образом.

Для инициатора

AUTH_{i} = SIGN_{K_{i}}(BLOB_{i}), (15)

для ответчика

AUTH_{r} = SIGN_{K_{r}}(BLOB_{r}), (16)

где Ki — закрытый ключ цифровой подписи инициатора;

Kr — закрытый ключ цифровой подписи ответчика.

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

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

Аутентификационные данные вычисляют с использованием алгоритма, ассоциированного с типом ключа, используемого подписывающей стороной, и указанного в поле Auth Method секции Authentication (см. 5.8). Требование того, чтобы инициатор и ответчик использовали для аутентификации один и тот же алгоритм, не накладывается. Каждая из сторон выбирает криптоалгоритм для своей аутентификации в соответствии с типом ключа аутентификации, который у нее есть.

Если для аутентификации используется метод Digital Signature (см. 5.8), то стороны должны перед этим обменяться уведомлениями SIGNATURE_HASH_ALGORITHMS в обмене IKE_SA_INIT. Уведомления SIGNATURE_HASH_ALGORITHMS должны содержать идентификаторы хэш-алгоритмов, которые отправитель данного уведомления может использовать при формировании и проверке цифровой подписи.

При использовании стандартизованных российских криптографических алгоритмов возможные значения идентификаторов хэш-алгоритмов приведены в 6.4.

В случае предварительно распределяемого ключа (PSK) содержимое секции Authentication вычисляют следующим образом:

Для инициатора:

AUTHi = prf(prf(PSK, «Key Pad f or IKEv2»), BLOBi), (17)

для ответчика:

AUTHr = prf(prf(PSK, «Key Pad f or IKEv2»), BLOBr), (18)

где PSK — предварительно распределяемый симметричный ключ длиной от 256 до 512 бит;

• строка «Key Pad f or IKE2» представлена в виде 17 символов ASCII, без завершающего нулевого байта.

В случае предварительно распределяемого ключа связывание идентификатора абонента из секций IDi/IDr с ключом этого абонента осуществляется через политику безопасности.

Обобщенное криптографическое описание протокола IKEv2 приведено в справочном приложении В. Использование ключей в протоколе IKEv2 обобщено в справочном приложении Г.

5 Форматы данных

5.1 Заголовок сообщения IKE

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

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

Все многобайтовые поля представляют величины в сетевом порядке байт.

Формат заголовка сообщения IKE показан на рисунке 2.

Рисунок 2 — Заголовок сообщения IKE

• Initiator's SPI (восемь байт) — величина, выбранная инициатором для идентификации уникального защищенного соединения IKE. Эта величина не должна быть равной 0;
• Responder's SPI (восемь байт) — величина, выбранная ответчиком для идентификации уникального защищенного соединения IKE. Это поле должно быть равно 0 в первом сообщении начального обмена и не должно быть нулевым в остальных случаях;
• Next Payload (один байт) — указывает тип секции, следующей непосредственно за заголовком. Формат и значение типа каждой из секций приведены ниже;
• MjVer (четыре бита) — указывает старшую версию используемого протокола IKE. Реализации, базирующиеся на настоящих рекомендациях, должны устанавливать это поле равным 2;
• MnVer (четыре бита) — указывает младшую версию используемого протокола IKE. Реализации, базирующиеся на настоящих рекомендациях, должны устанавливать это поле равным 0 и игнорировать младшую версию в получаемых сообщениях;
• Exchange Type (один байт) — указывает тип используемого обмена. Тип обмена обуславливает типы посылаемых секций в каждом сообщении обмена:

• Flags (один байт) — указывает специфические опции, установленные для сообщения. Наличие опции определяется тем, что соответствующий бит в поле флагов установлен, т.е. его значение равно 1. Соответственно, отсутствие опции определяется тем, что соответствующий бит сброшен, т.е. его значение равно 0. Определены следующие биты:

• X — биты должны быть сброшены при отправке и должны игнорироваться при приеме;
• R (Response) — бит указывает, что сообщение является ответом на сообщение с тем же идентификатором. Этот бит должен быть сброшен во всех запросах и должен быть установлен во всех ответах;
• V (Version) — бит означает, что противоположная сторона способна использовать более старшую версию протокола, чем указанная в поле MjVer. Реализации IKEv2 должны сбрасывать этот бит при отправке и должны игнорировать его при приеме;
• I (Initiator) — бит должен быть установлен в сообщениях, посылаемых изначальным инициатором создания данного IKE SA (т.е., либо инициатором обмена IKE_SA_INIT, либо инициатором обмена CREATE_CHILD_SA, созданного с целью обновления ключей IKE SA, результатом которого стало создание данного IKE SA), и должен быть сброшен в сообщениях, посылаемых изначальным ответчиком. Он используется при приеме для определения того, какие из 8 байт SPI были выбраны приемной стороной;
• MSGID (четыре байта, беззнаковое целое число) — идентификатор сообщения, используемый для управления перепосылками при потере пакетов и для определения соответствия запросов и ответов;
• Length (четыре байта, беззнаковое целое число) — полная длина сообщения (заголовка и входящих в данное сообщение секций) в байтах.

5.2 Общий заголовок секции

Каждая секция, определенная в 5.3 - 5.16, начинается с общего заголовка, показанного на рисунке 3. Рисунки для каждой секции, описанные ниже, будут включать общий заголовок, но для краткости описание его полей будет опущено.

Рисунок 3 — Общий заголовок секции

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

• Next Payload (один байт) — идентификатор типа следующей секции в сообщении. Если текущая секция является последней в сообщении, это поле должно быть равным 0. Это поле обеспечивает возможность «связывания» секций, когда новые секции могут добавляться к сообщению путем дописывания их в конец сообщения и спецификации типа последующей секции в поле Next Payload предшествующей секции. Секция Encrypted, которая всегда должна быть последней в сообщении, является исключением. Она содержит другие секции в зашифрованном виде. В заголовке секции Encrypted поле Next Payload задается равным типу первой из секций, содержащихся в ней (вместо нуля), а поле Next Payload последней из содержащихся секций устанавливается равным 0. Ниже указаны значения типов секций:

• C (Critical, один бит) — должен быть сброшен в 0 для всех секций, определенных в настоящих рекомендациях; должен игнорироваться при приеме;
• RESERVED (семь бит) — должны быть посланы как нули; должны игнорироваться при приеме;
• Payload Length (два байта, беззнаковое целое число) — длина текущей секции в байтах, включая общий заголовок.

5.3 Секция Security Association

5.3.1 Формат секции Security Association

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

Рисунок 4 — Секция Security Association

Подсекция Proposal содержит номер предложения и идентификатор IPsec протокола. Каждое предложение должно иметь номер на единицу больше предыдущего. Самая первая подсекция Proposal в секции Security Association инициатора должна иметь номер предложения, равный единице. Трансформы ENCR на основе AEAD алгоритмов обеспечивают аутентифицированное шифрование, поэтому их следует предлагать без трансформов INTEG. Если инициатор желает предложить варианты как с классическим шифрованием, так и основанные на AEAD алгоритмах, то он должен включить два предложения: в одном будут собраны все трансформы ENCR на основе AEAD алгоритмов, а в другом — все трансформы ENCR на основе классического шифрования вместе с трансформами INTEG.

Каждая подсекция Proposal включает в себя одну или несколько подсекций Transform. Число различных трансформов обычно зависит от протокола в подсекции Proposal. ESP обычно включает три трансформа: ENCR, INTEG и ESN. IKE обычно имеет четыре: ENCR, INTEG, PRF и KE. Для каждого протокола допустимые трансформы имеют свои номера Transform ID, которые присутствуют в заголовке подсекции Transform.

Если в предложении указано несколько трансформов с одним и тем же типом (Transform Type), то ответчик должен выбрать один из них. Если указано несколько трансформов с разными типами, то ответчик должен выбрать по одному трансформу каждого типа.

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

• Proposals (переменная длина) — одна или более подсекций Proposal.

Секция Security Association имеет тип тридцать три (33).

5.3.2 Подсекция Proposal

Подсекция Proposal (Предложение) имеет следующий формат, представленный на рисунке 5:

• Last Substruc (один байт) — указывает, является или нет данная подсекция последней в секции SA. Это поле имеет значение 0, если это последняя подсекция Proposal, и значение 2, если за ней следуют другие подсекции Proposal;
• RESERVED (один байт) — должно быть нулевым при отсылке; должно игнорироваться при приеме;
• Proposal Length (два байта, беззнаковое целое число) — длина данной подсекции Proposal, включая все входящие в нее подсекции Transform и элементы Attribute;
• Proposal Num (один байт) — когда предложение создают, то в первой подсекции Proposal в секции SA данное поле должно быть равно 1, в каждой последующей подсекции оно должно быть на единицу больше, чем в предыдущей. Когда предложение выбрано другой стороной, это поле должно равняться номеру того предложения в секции SA, которое было принято;
• Protocol ID (1 байт) — указывает идентификатор IPsec-протокола для данного предложения:

• SPI Size (один байт) — при начальном создании IKE SA это поле должно быть нулевым; SPI при этом берут из внешнего заголовка. В последующих обменах это поле указывает размер поля SPI в байтах (8 для IKE, 4 для ESP);
• Num Transforms (один байт) — указывает число подсекций Transform в данном предложении;
• SPI (переменная длина) — значение SPI, соответствующее данному предложению;
• Transforms (переменная длина) — одна или более подсекций Transform.

Рисунок 5 — Подсекция Proposal

При формировании секции Proposal во всех случаях, кроме начального обмена IKE_SA_INIT, поле SPI не должно быть пустым (соответственно, SPI Size не должно быть равно 0). Содержимое поля SPI зависит от протокола, указанного в поле Protocol ID. Для протокола IKE инициатор обмена включает в поле SPI значение SPIi для создаваемого защищенного соединения, а ответчик — значение SPIr. Для протокола ESP поле SPI содержит значение SPI для того защищенного соединения, в котором сторона, посылающая данное сообщение, будет получателем пакетов. В случае если сообщение инициатора содержит несколько секций Proposal, относящихся к одному протоколу, значения SPI в них могут быть одинаковыми или различными, при этом в созданном SA будет использовано значение SPI из секции, содержащей параметры, которые в результате будут выбраны ответчиком.

Значения SPI следует вырабатывать непредсказуемо для внешнего наблюдателя и следует выбирать таким образом, чтобы обеспечивать однозначный поиск SA по SPI при получении сообщений протокола IKE или пакетов ESP.

5.3.3 Подсекция Transform

Подсекция Transform (Трансформ) имеет следующий формат, представленный на рисунке 6:

• Last Substruc (один байт) — указывает, является или нет данная подсекция последней в подсекции Proposal. Это поле имеет значение 0, если это последняя подсекция Transform, и значение 3, если за ней следуют другие подсекции Transform;
• RESERVED (один байт) — должно быть равно 0 при отсылке; должно игнорироваться при приеме;
• Transform Length (два байта, беззнаковое целое число) — длина данной подсекции Transform, включая ее заголовок и все входящие в нее элементы Attribute;
• Transform Type (один байт) — тип трансформа, указанного в данной подсекции. Различные протоколы поддерживают различные типы трансформов. Для некоторых протоколов некоторые типы трансформов могут быть опциональными. Если трансформ опционален и инициатор хочет предложить не использовать его, то он не включает ни одну подсекцию Transform с данным типом в свое предложение;
• Transform ID (два байта) — указывает конкретный трансформ того типа, который предлагается.

Рисунок 6 — Подсекция Transform

Значения типов трансформов:

Примечание - При использовании в IKE алгоритмов ENCR, основанных на аутентифицированном шифровании (AEAD), алгоритм INTEG не должен согласовываться, в противном случае он является обязательным.

При использовании стандартизованных российских криптографических алгоритмов возможные значения идентификаторов для трансформов типов 1 — 4 приведены в 6.4.

Ниже перечислены возможные значения идентификаторов для трансформов типа 5 (Extended Sequence Numbers):

Инициатор, который поддерживает расширенные номера пакетов, обычно будет включать в свое предложение два трансформа ESN, со значениями 0 и 1. Предложение, содержащее единственный трансформ ESN со значением 1, означает, что использование обычных (нерасширенных) номеров пакетов неприемлемо.

5.3.4 Допустимые типы трансформов для разных протоколов

Количество и тип трансформов, присутствующих в секции SA, зависят от протокола, для которого создается защищенное соединение. Реализация IKE должна понимать все обязательные и опциональные типы трансформов для всех протоколов, которые она поддерживает (однако она не обязана принимать предложения с неприемлемыми наборами трансформов). Опциональные трансформы могут отсутствовать в предложении, если единственным предлагаемым значением было бы NONE:

Примечание - При использовании в IKE алгоритмов ENCR, основанных на аутентифицированном шифровании (AEAD), алгоритм INTEG не должен согласовываться, в противном случае он является обязательным.

5.3.5 Атрибуты трансформов

Каждый трансформ в секции Security Association может включать дополнительные элементы Attribute (Атрибуты), которые изменяют или дополняют спецификацию этого трансформа (см. рисунок 7). Набор допустимых атрибутов зависит от типа трансформа. В настоящий момент определен единственный атрибут: атрибут Key Length (Длина Ключа).

Рисунок 7 — Формат элемента Attribute

Атрибуты представляют собой пары тип/значение с форматом, описанным ниже. Значение атрибутов может иметь фиксированный размер в два байта или переменный размер. Во втором случае атрибут задается как тип/длина/значение.

• AF (Attribute Format, один бит) — указывает, представлен ли данный атрибут в формате Тип/Длина/Значение (TLV) или в укороченном формате Тип/Значение (TV). Если бит AF сброшен (равен 0), то атрибут использует формат TLV; если бит AF установлен (равен 1), то используется формат TV (с длиной данных — два байта);
• Attribute Type (15 бит) — уникальный идентификатор для каждого из типов атрибутов; в настоящий момент определены следующие типы атрибутов:

в атрибуте Key Length передается длина ключа в битах в сетевом порядке байт;

• Attribute Length (два байта, беззнаковое целое число) — если бит AF сброшен (равен 0), то поле указывает длину следующего за ним поля Attribute Value в байтах; если бит AF установлен (равен 1), то данное поле отсутствует;
• Attribute Value (переменная длина) — значение атрибута данного типа. Если бит AF сброшен (равен 0), то это поле имеет переменную длину, указанную в поле Attribute Length. Если бит AF установлен (равен 1), то поле Attribute Value имеет длину два байта.

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

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

5.3.6 Согласование параметров SA

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

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

Согласование алгоритма обмена ключами имеет некоторые особенности. Предложение по созданию защищенного соединения содержит предлагаемые атрибуты и открытый ключ этого алгоритма (в секции Key Exchange) в одном сообщении. Если в начальном обмене инициатор предлагает использовать один из нескольких трансформов KE, то ему следует выбрать тот трансформ, который с наибольшей вероятностью устроит ответчика, и включить в секцию Key Exchange открытый ключ, соответствующий этому трансформу. Если ответчик выбирает предложение с другим трансформом KE (кроме NONE), то он указывает в ответе выбранный трансформ, и инициатору следует выработать ключевую пару, соответствующую этому трансформу, и включить ее открытый ключ в секцию Key Exchange при повторной отсылке первого сообщения. Ему следует, однако, продолжать включать в свое предложение весь набор поддерживаемых трансформов KE для предотвращения атаки «человек посередине» (в противном случае нарушитель может вынудить партнеров использовать менее стойкий трансформ обмена ключами). Если среди предложенных трансформов KE есть NONE и ответчик выбирает этот вариант, то он должен проигнорировать секцию Key Exchange инициатора и не включать секцию Key Exchange в ответное сообщение.

5.4 Секция Key Exchange

Секция Key Exchange (Ключевой Обмен), обозначаемая KE, используется для обмена эфемерными открытыми ключами протокола Диффи-Хеллмана для вычисления общего ключа. Секция Key Exchange состоит из заголовка, за которым следует сам открытый ключ (см. рисунок 8).

Рисунок 8 — Формат секции Key Exchange

• Key Exchange Transform (два байта) — идентифицирует трансформ обмена ключами KE, для которого передается открытый ключ;
• RESERVED (два байта) — должно быть равно 0 при отсылке; должно игнорироваться при приеме;
• Key Exchange Data (переменная длина) — значение открытого ключа протокола Диффи-Хеллмана.

Поле Key Exchange Transform должно соответствовать трансформу KE, указанному в каком-либо из предложений в секции SA, посланной в том же сообщении; рекомендуется, чтобы оно соответствовало первому трансформу KE в первом предложении, если таковой в нем присутствует. Если ни одно из предложений в указанной секции SA не включает трансформа KE, то секция Key Exchange не должна присутствовать в сообщении. Если выбранное ответчиком предложение включает иное значение трансформа KE (кроме NONE), то сообщение должно быть отвергнуто с посылкой уведомления типа INVALID_KE_PAYLOAD. См. также 4.4.2 и 5.3.6.

Секция Key Exchange формируется путем записи значения эфемерного открытого ключа протокола Диффи-Хеллмана в поле Key Exchange Data.

Секция Key Exchange имеет тип тридцать четыре (34).

5.5 Секция Identification

Секция Identification (Идентификация), обозначаемая как IDi и IDr, позволяет сторонам передавать друг другу свои идентификаторы. Содержимое IDi/IDr используется исключительно для выбора политики безопасности, определяющей параметры работы с противоположной стороной, а также аутентификационной информации противоположной стороны.

Секция Identification состоит из заголовка, за которым следуют поля, описывающие идентификационную информацию (см. рисунок 9):

• ID Type (один байт) — указывает тип используемой идентификационной информации;
• RESERVED (три байта) — должно быть равно 0 при отсылке; должно игнорироваться при приеме;
• Identification Data (переменная длина) — значение указанного типа идентификационной информации. Длину поля вычисляют на основе значения в поле Payload Length.

Рисунок 9 — Формат секции Identification

Секция Identification имеет тип тридцать пять (35) для IDi и тридцать шесть (36) для IDr.

Ниже перечислены возможные значения поля ID Type и соответствующая им семантика.

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

5.6 Секция Certificate

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

Формат секции Certificate определен следующим образом (см. рисунок 10):

• Certificate Encoding (один байт) — указывает тип сертификата или информации, относящейся к сертификату, который содержится в поле Certificate Data;

• Certificate Data (переменная длина) — бинарное представление сертификата. Тип сертификата указывают в поле Certificate Encoding.

Рисунок 10 — Формат секции Certificate

Секция Certificate имеет тип тридцать семь (37).

Настоящие рекомендации определяют синтаксис для следующих типов:

• X.509 Certificate — Signature: содержит X.509 сертификат в формате DER, открытый ключ которого используют для проверки полученной секции Authentication. Заметим, что если необходимо послать цепочку сертификатов с данным типом представления, то используют несколько секций Certificate, только первая из которых содержит открытый ключ, используемый для проверки отсылаемой секции Authentication;
• Certificate Revocation List (CRL): содержит список отозванных сертификатов в формате DER.

Название секции Certificate (Сертификат) не вполне корректно в том плане, что в ней могут быть переданы иные сущности (например, CRL).

5.7 Секция Certificate Request

Секция Certificate Request (Запрос Сертификата), обозначаемая как CERTREQ, обеспечивает возможность запросить через IKE предпочтительные сертификаты и может появляться в ответе IKE_SA_INIT и/или в запросе IKE_AUTH. Одна или несколько секций Certificate Request могут быть включены в обмен, если получающей их стороне нужно получить сертификаты противоположной стороны.

Формат секции Certificate Request определен следующим образом (см. рисунок 11):

• Certificate Encoding (один байт) — содержит информацию о типе или формате запрошенного сертификата. Значения перечислены в 5.6;
• Certification Authority (переменная длина) — содержит информацию о доверенных центрах сертификации для указанного типа запрошенного сертификата.

Рисунок 11 — Формат секции Certificate Request

Секция Certificate Request имеет тип тридцать восемь (38).

Возможные значения для поля Certificate Encoding те же, что и в 5.6. Поле Certification Authority содержит указание на доверенные центры для данного типа сертификатов. Это поле представляет собой конкатенацию представлений открытых ключей доверенных удостоверяющих центров сертификации (УЦ), каждое из которых получено посредством функции сжимающего отображения nSHA. Каждый центр сертификации представлен как результат применения nSHA для элемента SubjectPublicKeyInfo в доверенном корневом сертификате центра. Конкатенацию полученных 20-байтовых значений включают в это поле без дополнительного форматирования.

Содержимое поля Certification Authority определено только для X.509 сертификатов.

Название секции Certificate Request (Запрос Сертификата) не вполне корректно в том плане, что в секции Certificate помимо самих сертификатов могут присутствовать иные сущности (например, CRL), и они могут быть запрошены в секции Certificate Request.

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

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

• сконфигурирован использовать аутентификацию посредством сертификатов;
• сконфигурирован посылать секцию Certificate;
• имеет соответствующее доверие к указанным УЦ согласно политике безопасности для данного защищенного соединения;
• имеет, по крайней мере, один подходящий по условиям использования сертификат, срок действия которого не истек, и который может быть проверен одним из доверенных УЦ, указанным в присланной секции Certificate Request.

Проверка того, что сертификат не отозван, должна быть выполнена в процессе построения цепочки при выборе сертификата. Если два абонента сконфигурированы так, что используют различные УЦ, то в процессе выбора сертификата следует учитывать возможность кросс-сертификации.

5.8 Секция Authentication

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

Формат секции Authentication определен следующим образом (см. рисунок 12):

• Auth Method (один байт) — специфицирует используемый метод аутентификации. Возможны следующие методы аутентификации:

Данные аутентификации вычисляют как описано в 4.15, формулы (17) и (18), с использованием предварительно распределенного ключа, ассоциированного с данными из секции Identification, и выбранной псевдослучайной функцией prf.

Данные аутентификации вычисляют как описано в 4.15, формулы (15) и (16), с использованием цифровой подписи;

• RESERVED (три байта) — должно быть равно 0 при отсылке; должно игнорироваться при приеме.
• Authentication Data (переменная длина) — см. 4.15.

Рисунок 12 — Формат секции Authentication

Секция Authentication имеет тип тридцать девять (39).

При использовании метода аутентификации Digital Signature поле Authentication Data имеет следующий формат (см. рисунок 13):

• ASN.1 Length (один байт) — содержит длину поля AlgorithmIdentifier;
• AlgorithmIdentifier (переменная длина) — содержит ASN.1 объект AlgorithmIdentifier, специфицирующий алгоритм подписи;
• Signature Value (переменная длина) — содержит значение цифровой подписи.

Рисунок 13 — Формат поля Authentication Data для метода Digital Signature

5.9 Секция Nonce

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

Формат секции Nonce определен следующим образом (см. рисунок 14):

• Nonce Data (переменной длины) — содержит случайные или псевдослучайные данные, выработанные передающей стороной.

Рисунок 14 — Формат секции Nonce

Секция Nonce имеет тип сорок (40).

Значения нонсов не должны использоваться повторно.

5.10 Секция Notify

5.10.1 Формат секции Notify

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

Формат секции Notify определен следующим образом (см. рисунок 15):

• Protocol ID (один байт) — если данное уведомление касается существующего защищенного соединения, чей SPI указан в поле SPI, то данное поле указывает его тип. Для уведомлений, касающихся IPsec SA, это поле должно содержать значение 3 для указания ESP. Из уведомлений, определенных в настоящих рекомендациях, SPI указывают только с INVALID_SELECTORS, REKEY_SA и CHILD_SA_NOT_FOUND. Если поле SPI является пустым, то данное поле следует посылать равным 0 и его игнорируют при приеме;
• SPI Size (один байт) — длина SPI в байтах для протокола, указанного в Protocol ID, или 0, если SPI не указывается. Для уведомлений, относящихся к IKE SA, поле SPI Size должно быть равным 0, соответственно поле SPI должно отсутствовать;
• Notify Message Type (два байта) — указывает тип уведомления;
• SPI (переменная длина) — идентификатор защищенного соединения;
• Notification Data (переменная длина) — данные об ошибке или состоянии, передаваемые в дополнение к Notify Message Type. Значения специфичны для каждого типа уведомления (см. 5.10.2).

Рисунок 15 — Формат секции Notify

Секция Notify имеет тип сорок один (41).

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

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

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

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

Ниже перечислены уведомления, определенные в настоящих рекомендациях. Если не указано иначе, то дополнительные данные в поле Notification Data отсутствуют:

5.11 Секция Delete

Секция Delete (Удаление), обозначаемая как D, содержит идентификатор защищенного соединения для конкретного протокола, которое посылающая сторона удалила у себя. Можно послать несколько SPI в одной секции Delete, однако все они должны относиться к одному протоколу. Допускается отсылка нескольких секций Delete в одном INFORMATIONAL обмене, где каждая из секций перечисляет SPI для своего протокола.

Удаление IKE SA обозначают путем задания поля Protocol ID равным 1 (IKE) при отсутствии SPI. При удалении ESP SA поле Protocol ID будет содержать идентификатор этого протокола (3), а поле SPI будет содержать SPI, который посылающая сторона ожидает во входящих ESP пакетах.

Формат секции Delete определен следующим образом (см. рисунок 16):

• Protocol ID (один байт) — должно быть указано 1 для IKE SA и 3 для ESP;
• SPI Size (один байт) — длина в байтах SPI, в соответствии с идентификатором протокола. Должна быть 0 для IKE (SPI присутствует в заголовке сообщения) или четыре для ESP;
• Num of SPIs (два байта, беззнаковое целое число) — число SPI, содержащихся в секции Delete. Поле SPI Size определяет размер каждого SPI;
• Security Parameter Index(es) (переменная длина) — указывает конкретные защищенные соединения, подлежащие удалению. Каждый из абонентов при отсылке сообщения сданной секцией указывает те SPI, которые при создании удаляемых защищенных соединений выбирал именно он. Поля SPI Size и Num of SPIs определяют длину этого поля.

Рисунок 16 — Формат секции Delete

Секция Delete имеет тип сорок два (42).

5.12 Секция Vendor ID

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

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

Формат секции Vendor ID определен следующим образом (см. рисунок 17):

• Vendor ID (переменная длина) — уникальный идентификатор вендора. Хорошей практикой обеспечения уникальности при отсутствии централизованного реестра является включение имени компании, персонального имени или другой подобной информации. Использование хэша от уникальной строки предпочтительнее, чем использование самой строки.

Рисунок 17 — Формат секции Vendor ID

Секция Vendor ID имеет тип сорок три (43).

5.13 Секция Traffic Selector

5.13.1 Формат секции Traffic Selector

Секция Traffic Selector (Селектор Трафика), обозначаемая как TS, позволяет абонентам идентифицировать поток данных для обработки протоколами IPsec. Секция Traffic Selector состоит из заголовка, за которым следуют подсекции Selector (см. рисунок 18):

• Number of TSs (один байт) — количество подсекций Selector в данной секции;
• RESERVED (три байта) — это поле должно быть равно 0 при отсылке и должно игнорироваться при приеме;
• Selectors (переменная длина) — одна или более подсекций Selector.

Рисунок 18 — Формат секции Traffic Selector

Длина секции Traffic Selector включает ее заголовок и все входящие в нее подсекции Selector.

Секция Traffic Selector имеет тип сорок четыре (44) для адресов со стороны инициатора создания IPsec SA и сорок пять (45) для адресов со стороны ответчика.

Требование, чтобы TSi и TSr содержали одинаковое количество подсекций Selector, не накладывается. Таким образом, их интерпретируют следующим образом: IP-пакет попадает под данную пару TSi/TSr, если он попадает по крайней мере в одну подсекцию Selector из TSi и по крайней мере в одну подсекцию Selector из TSr.

Например, следующие селекторы трафика:

TSi = ((17, 100, 198.51.100.66-198.51.100.66), (17, 200, 198.51.100.66-198.51.100.66))

TSr = ((17, 300, 0.0.0.0-255.255.255.255), (17, 400, 0.0.0.0-255.255.255.255))

включают IP-пакеты с протоколом UDP с адреса 198.51.100.66 на любой адрес с любой из следующих комбинаций портов источника назначения: (100, 300), (100, 400), (200, 300) и (200, 400).

Таким образом, в зависимости от политики безопасности, может потребоваться создание нескольких пар IPsec SA. Например, политика безопасности, требующая обработки только комбинации портов источника назначения (100, 300) и (200, 400), но не двух оставшихся, не может быть реализована в рамках одной пары IPsec SA.

5.13.2 Подсекция Selector

Формат подсекции Selector (Селектор Трафика) показан на рисунке 19:

Рисунок 19 — Подсекция Selector

Примечание - Все поля, помеченные символом «*», зависят от типа селектора (TS Type).

Показаны поля для типов 7 и 8 — единственных, определенных в настоящее время.

• TS Type (один байт) — определяет тип селектора;
• IP protocol ID (один байт) — значение, указывающее идентификатор IP-протокола (например, UDP, TCP и ICMP). Значение 0 означает, что идентификатор протокола не имеет значения для данного селектора и IPsec SA может принимать любой протокол;
• Selector Length (два байта, беззнаковое целое число) — указывает длину данной подсекции Selector, включая ее заголовок;
• Start Port (два байта, беззнаковое целое число) — значение, указывающее наименьший номер порта, разрешенный данным селектором. Для тех протоколов, для которых порт не определен (включая протокол 0), или для случаев, когда разрешены все порты, это поле должно иметь значение 0. Значения ICMP Type и ICMP Code представляют как один 16-битный номер порта, при этом Type занимает старшие восемь бит, а Code — младшие восемь бит. Значение типа заголовка Mobile IPv6 Mobility Header (MIPv6 MH) должно указываться как один 16-битный номер порта, при этом тип заголовка занимает старшие восемь бит, а младшие восемь бит содержат нули;
• End Port (два байта, беззнаковое целое число) — значение, указывающее наибольший номер порта, разрешенный данным селектором. Для тех протоколов, для которых порт не определен (включая протокол 0), или для случаев, когда разрешены все порты, это поле должно быть 65535. Значения ICMP Type и Code представляют как один 16-битный номер порта, при этом Type занимает старшие восемь бит, а Code — младшие восемь бит. Значение типа заголовка MIPv6 MH представляют как один 16-битный номер порта, при этом тип заголовка занимает старшие восемь бит, а младшие восемь бит содержат нули;
• Starting Address — наименьший адрес, включаемый в данный селектор (длина зависит от типа селектора);
• Ending Address — наибольший адрес, включаемый в данный селектор (длина зависит от типа селектора).

Системы, желающие указать «любой» порт, должны задать начальный порт равным 0, а конечный порт — 65535.

Ниже перечислены возможные значения поля TS Type и соответствующие им данные адресов селектора:

5.14 Секция Encrypted

Секция Encrypted (Защищенная), обозначаемая как SK{...}, содержит другие секции в зашифрованном виде. Секция Encrypted, если она присутствует в сообщении, должна быть последней секцией в сообщении. Часто она единственная секция в сообщении.

Алгоритмы для шифрования и имитозащиты согласовывают в момент создания IKE SA, а ключи вычисляют, как описано в 4.14.2 и 4.14.4.

Секция Encrypted имеет тип сорок шесть (46) и состоит из заголовка, за которым следуют индивидуальные поля (см. рисунок 20):

• Next Payload — тип первой вложенной секции. Такая интерпретация поля Next Payload является исключением из общего формата заголовка секций: так как секция Encrypted является последней в сообщении, то поле Next Payload должно было быть равным 0. Но поскольку эта секция содержит другие секции, то тип первой из них помещается в это поле;
• Payload Length — включает длину заголовка секции, синхропосылки (Initialization Vector) зашифрованных секций IKE (Encrypted IKE Payloads), дополнения (Padding), длины дополнения (Pad Length) и кода аутентификации сообщения (Integrity Check Value);
• Initialization Vector — синхропосылка;
• Encrypted IKE Payloads — защищенные секции сообщения; это поле зашифровано согласованным алгоритмом шифрования;
• Padding — может содержать любые значения, выбранные посылающей стороной, и должно иметь размер, который обеспечивает суммарную длину полей Encrypted IKE Payloads, Padding и Pad Length кратной величине, определяемой используемым трансформом ENCR; это поле зашифровано согласованным алгоритмом шифрования;
• Pad Length — содержит длину поля Padding; посылающей стороне следует выбирать длину дополнения минимальной, чтобы комбинация длин секций, Padding и Pad Length была кратной величине, определяемой используемым трансформом ENCR, но получатель должен принимать любое значение длины, которое обеспечивает надлежащее выравнивание; это поле зашифровано согласованным алгоритмом шифрования;
• Integrity Check Value — имитовставка, посчитанная начиная от заголовка IKE и заканчивая полем Pad Length (включая это поле). Длина этого поля зависит от согласованного трансформа INTEG (или ENCR для AEAD алгоритмов).

Рисунок 20 — Формат секции Encrypted

5.15 Секция Configuration

5.15.1 Формат секции Configuration

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

Формат секции Configuration определен следующим образом (см. рисунок 21):

Секция Configuration имеет тип сорок семь (47).

Рисунок 21 — Формат секции Configuration

• CFG Type (один байт) — тип обмена:

• RESERVED (три байта) — должно быть равно 0 при отсылке и должно игнорироваться при приеме;
• Configuration Attributes (переменная длина) — элементы Configuration Attribute (Конфигурационный Атрибут) в формате Тип/Длина/Значение (TLV), специфичные для секции Configuration и определенные в 5.15.2. Может быть включено ноль или более элементов Configuration Attribute.

5.15.2 Конфигурационные атрибуты

Формат элемента Configuration Attribute показан на рисунке 22.

Рисунок 22 — Формат элемента Configuration Attribute

• R (один бит) — этот бит должен быть сброшен в 0 и должен игнорироваться приемной стороной;
• Attribute Type (15 бит) — уникальный идентификатор для каждого из типов элементов Configuration Attribute;
• Length (два байта, беззнаковое целое число) — длина поля Value в байтах;
• Value (ноль или более байт) — передаваемое значение. Ниже перечислены типы атрибутов:

Примечание - Символом «*» отмечены атрибуты, которых в ответе может присутствовать более одного, при условии, если более одного значения было запрошено.

• INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS — адрес во внутренней сети, иногда называемый адресом красного интерфейса или приватным адресом, и он может быть приватным адресом в сети Интернет;
• INTERNAL_IP4_NETMASK — маска внутренней сети;
• INTERNAL_IP4_DNS, INTERNAL_IP6_DNS — указывают адрес DNS сервера внутри сети;
• INTERNAL_IP4_NBNS — указывает адрес сервера имен NetBios (WINS) внутри сети;
• INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP — указывает абоненту посылать любой внутренний запрос DHCP на адрес, содержащийся в атрибуте;
• APPLICATION_VERSION — версия или информация о приложении. Является строкой печатных ASCII символов, которая не завершается нулевым символом;
• INTERNAL_IP4_SUBNET — подсети, которые защищает данный шлюз безопасности. Этот атрибут состоит из двух частей: первой является IP-адрес, а второй — маска подсети;
• SUPPORTED_ATTRIBUTES — при использовании в запросе этот элемент должен иметь нулевую длину, он означает предложение ответчику вернуть список всех Конфигурационных Атрибутов, которые тот поддерживает. В ответе данный элемент содержит набор идентификаторов типов элементов Configuration Attribute, по 2 байта каждый. Длина элемента, поделенная на 2 (байта), дает число поддерживаемых типов элементов Configuration Attribute, содержащихся в ответе;
• INTERNAL_IP6_SUBNET — подсети, которые защищает данный шлюз безопасности. Этот элемент состоит из двух частей: первая представляет собой 16-байтный IPv6-адрес, а вторая — однобайтную длину префикса.

Данные рекомендации не регламентируют, откуда ответчику следует получать информацию, посылаемую в ответе.

Пара CFG_REQUEST и CFG_REPLY позволяет оконечному устройству IKE запросить информацию у противоположной стороны. Если какой-либо атрибут в секции Configuration типа CFG_REQUEST не пустой, то его значение воспринимается как предложение по данному атрибуту. Секция Configuration типа CFG_REPLY может вернуть это значение или новое. Она может также содержать новые атрибуты или не включать запрошенные. Нераспознанные или неподдерживаемые атрибуты должны игнорироваться как в запросе, так и в ответе.

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

5.16 Секция Encrypted Fragment

Секция Encrypted Fragment (Защищенный Фрагмент), обозначаемая как SKF{...}, содержит другие секции в зашифрованном виде. Секция Encrypted Fragment, если она присутствует в сообщении, должна быть последней секцией в сообщении. Фрагментация IKE сообщений описана в 4.12.

Секция Encrypted Fragment имеет тип пятьдесят три (53) и состоит из заголовка, за которым следуют индивидуальные поля (см. рисунок 23):

• Next Payload — в первом фрагменте (Fragment Number равен 1) должно содержать тип первой вложенной секции (аналогично секции Encrypted). В остальных фрагментах должно быть равным 0;
• Payload Length — включает длину заголовка секции, полей Fragment Number и Total Fragments, синхропосылки (Initialization Vector), зашифрованных секций IKE (Encrypted IKE Payloads), дополнения (Padding), длины дополнения (Pad Length) и кода аутентификации сообщения (Integrity Check Value);
• Fragment Number (два байта, беззнаковое целое число) — номер текущего фрагментированного сообщения, начиная с 1. Значение этого поля не должно содержать 0 и должно быть меньше или равно значению поля Total Fragments;
• Total Fragments (два байта, беззнаковое целое число) — количество фрагментов, на которые было разбито исходное сообщение. Это поле не должно содержать 0.

Рисунок 23 — Формат секции Encrypted Fragment

Прочие поля идентичны полям секции Encrypted (см. рисунок 20).

6 Использование российских криптографических алгоритмов

6.1 Версия протокола IKE и согласование параметров IKE SA

Данные рекомендации определяют использование стандартизованных российских криптографических алгоритмов только для версии 2 протокола IKE (IKEv2, см. 5.1). Версия 1 протокола IKE не должна применяться.

При следовании данным рекомендациям в процессе согласования параметров IKE SA для следующих типов трансформов — ENCR, INTEG, PRF, KE, а также для метода аутентификации, должны использоваться только параметры, представленные в 6.4. При следовании данным рекомендациям в уведомление SIGNATURE_HASH_ALGORITHMS должен быть включен хотя бы один из идентификаторов хэш-алгоритмов, приведенных в 6.4. Данные рекомендации не накладывают ограничений на согласование прочих параметров IKE SA.

6.2 Размер векторов со случайными данными (нонсов)

При использовании стандартизованных российских криптоалгоритмов суммарный размер нонсов Ni и Nr (см. 5.9), которыми стороны обмениваются в обменах IKE_SA_INIT (см. 4.3.2) и CREATE_CHILD_SA (см. 4.3.3), должен быть не меньше 512 бит, при этом рекомендуется, чтобы нонс каждой из сторон имел размер не меньше 256 бит.

6.3 Используемые алгоритмы

6.3.1 Алгоритмы подписи

Для аутентификации с помощью цифровой подписи в настоящих рекомендациях используется алгоритм ГОСТ Р 34.10 совместно с хэш-функцией ГОСТ Р 34.11. При аутентификации с помощью цифровой подписи реализации должны использовать метод аутентификации Digital Signature, при этом поле AlgorithmIdentifier должно содержать значения id-tc26-signwithdigest-gost3410-12-256 или id-tc26-signwithdigest-gost3410-12-512, определенные в Р 1323565.1.023.

Значение поля Signature Value (см. рисунок 13) формируют в соответствии с Р 1323565.1.023-2022 как конкатенацию чисел s и r, полученных в результате выполнения алгоритма подписи, в формате big-endian

SIGNVALUE = STRssz(s)|STRssz(r), (19)

где SIGNVALUE — значение поля Signature Value;

ssz — принимает значение 32 в случае использования для формирования подписи эллиптической кривой над 256-битным полем (при этом AlgorithmIdentifier формируют с id-tc26-signwithdigest-gost3410-12-256 в качестве идентификатора алгоритма) и 64 в случае использования для формирования подписи эллиптической кривой над 512-битным полем (при этом AlgorithmIdentifier формируют с id-tc26-signwithdigest-gost3410-12-512 в качестве идентификатора алгоритма).

6.3.2 Выработка общего ключа

Для выработки общего ключа в данных рекомендациях определены два трансформа типа KE (см. таблицу 2).

Таблица 2

Трансформы выработки общего ключа

Эти трансформы используют эллиптические кривые в форме Эдвардса, параметры которых определены в Р 1323565.1.024-2019. В дополнение к ним таблица 2 определяет параметр gsz, используемый при представлении точек эллиптической кривой в виде байтовых строк.

Далее по тексту будут использованы следующие обозначения:

E — используемая эллиптическая кривая;

m — порядок группы точек эллиптической кривой E;

q — порядок циклической подгруппы группы точек эллиптической кривой E;

P — точка эллиптической кривой E порядка q (порождающий элемент подгруппы);

Q — точка эллиптической кривой порядка q (открытый ключ);

xQ — координата x точки эллиптической кривой Q;

yQ — координата y точки эллиптической кривой Q;

(di, Qi) — эфемерная ключевая пара инициатора: закрытый и открытый ключи, соответствующие кривой E;

(dr, Qr) — эфемерная ключевая пара ответчика: закрытый и открытый ключи, соответствующие кривой E;

0 — нулевая точка эллиптической кривой E.

Примечание — Величины m, q и P являются параметрами эллиптической кривой и для кривых, указанных в таблице 2, определены в Р 1323565.1.024.

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

S = strgsz(xQ)|strgsz(yQ), (20)

где gsz берут из таблицы 2 для соответствующего трансформа KE. Полученную байтовую строку S помещают в тело секции Key Exchange. Иными словами, тело секции Key Exchange содержит координаты x и y точки Q, представленные в виде чисел размером gsz байт в формате little-endian.

Для вычисления общего ключа применяют следующий алгоритм с использованием операций над точками эллиптических кривых в соответствии с ГОСТ Р 34.10.

Инициатор и ответчик вырабатывают эфемерные ключевые пары (di, Qi) и (dr, Qr) на кривой E, соответствующей согласованному трансформу KE, таким образом, что натуральные числа di и dir выбирают случайно из множества {1, ..., q — 1}, а точки эллиптической кривой вычисляют по формулам Qi = di·P (соответственно Qr = dr·P). Стороны обмениваются открытыми ключами Qi и Qr по протоколу Диффи-Хеллмана на эллиптических кривых. Каждая из сторон должна убедиться, что открытый ключ, присланный противоположной стороной, является точкой на кривой E. Если это условие не выполняется, то обмен должен быть прекращен, при этом рекомендуется послать противоположной стороне уведомление INVALID_SYNTAX.

Каждый из абонентов вычисляет значение точки Qir

Q_{ir} = (\frac{m}{q} \cdot d_{i}) \cdot Q_{r} = (\frac{m}{q} \cdot d_{r}) \cdot Q_{i}. (21)

Затем каждой из сторон необходимо проверить, что выполняется условие: Q_{ir} \neq 0 . Если оно не выполняется, то обмен должен быть прекращен, при этом рекомендуется послать противоположной стороне уведомление INVALID_SYNTAX.

Общий ключ Kir вычисляют следующим образом

K_{ir} = str_{gsz}(x^{Q_{ir}}), (22)

где gsz берут из таблицы 2 для соответствующего трансформа KE. Иными словами, в качестве общего ключа Kir используют координату x точки Qir, представленную в виде числа размером gsz байт в формате little-endian.

6.3.3 Псевдослучайная функция

Настоящие рекомендации определяют трансформ PRF_HMAC_STREEBOG_512, который задают как псевдослучайную функцию prf(K,S) на основе алгоритма HMAC_GOSTR3411_2012_512. Этот алгоритм определен в Р 50.1.113-2016 на основе хэш-функции H, в качестве которой используется хэш-функция «Стрибог» с размером выходного значения 512 бит. Далее этот алгоритм будет обозначен как HMAC_GOST(K,S).

Р 50.1.113-2016 накладывает ограничение на длину аргумента K в алгоритме HMAC_GOSTR3411_2012_512, который должен иметь длину от 256 до 512 бит. Это условие может не выполняться в протоколе IKEv2, поэтому функцию prf(K,S) определяют следующим образом

(23)

где K — ключ;

S — произвольная байтовая строка;

H — хэш-функция «Стрибог» с размером выходного значения 512 бит.

То есть, если длина аргумента K превышает 512 бит, то он предварительно хэшируется с использованием хэш-функции «Стрибог» с размером выходного значения 512 бит.

Примечание - Условие, что длина аргумента K должна быть больше или равна 256 битам, всегда выполняется при следовании настоящим рекомендациям.

6.3.4 Защита сообщений

6.3.5 Трансформы защиты сообщений

Настоящие рекомендации определяют два трансформа типа ENCR: ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE. Эти трансформы представляют собой AEAD алгоритмы с диверсификацией ключей и обеспечивают конфиденциальность и имитозащиту передаваемых данных. Трансформы базируются соответственно на алгоритмах ГОСТ Р 34.12 «Кузнечик» и «Магма» в режиме MGM, описанном в Р 1323565.1.026-2019.

При согласовании параметров защищенного соединения трансформ ENCR_KUZNYECHIK_MGM_KTREE представляется AEAD алгоритмом с длиной ключа 352 бита, из которых первые 256 бит используют как корневой ключ защищенного соединения (K), а последующие 96 бит — в качестве соли (salt). В свою очередь, трансформ ENCR_MAGMA_MGM_KTREE представляется AEAD алгоритмом с длиной ключа 288 бит, из которых первые 256 бит используют как корневой ключ защищенного соединения (K), а последующие 32 бита — в качестве соли (salt). Для обоих трансформов длины ключей являются фиксированными, поэтому при их согласовании атрибут Key Length не должен присутствовать.

Данные трансформы не накладывают требований на выравнивание длины защищаемых данных (см. 5.14).

6.3.5.1 Блочный шифр

Определенные в настоящих рекомендациях трансформы ENCR в качестве блочного шифра используют шифры «Магма» и «Кузнечик», определенные в ГОСТ Р 34.12 (см. таблицу 3). Длина блока составляет 128 бит для шифра «Кузнечик» и 64 бита для шифра «Магма», длина ключа K в обоих случаях составляет 256 бит.

Таблица 3

Алгоритмы блочного шифрования

6.3.5.2 AEAD алгоритм

Определенные в настоящих рекомендациях трансформы ENCR в качестве AEAD алгоритма используют MGM — режим работы блочного шифра, описанный в Р 1323565.1.026-2019. Для трансформа ENCR_KUZNYECHIK_MGM_KTREE длину имитовставки S полагают равной 96 битам, для трансформа ENCR_MAGMA_MGM_KTREE используют полную имитовставку, т.е. S = 64.

Функцию зашифрования AEAD-Encrypt задают в соответствии со следующей формулой

AEAD-Encrypt (Kmsg, nonce, AAD, Plaintext) = = Ciphertext|ICV, (24)

где

(MGMnonce, AAD, Ciphertext, ICV) = = MGM-Encrypt (Kmsg, MGMnonce, AAD, Plaintext), MGMnonce = nonce [1 ... 1]&0x7f|nonce[2 ... |nonce|]. (25)

Функцию расшифрования AEAD-Decrypt задают в соответствии со следующей формулой

AEAD-Decrypt (Kmsg, nonce, AAD, Ciphertext, ICV) = res, (26)

где

res' = MGM-Decrypt (Kmsg, MGMnonce, AAD, Ciphertext, ICV), MGMnonce = nonce [1 ... 1]]&0x7f|nonce[2 ...|nonce|],

(27)

В формулах (24), (25), (26) и (27) Kmsg обозначает ключ защиты сообщения (см. 6.3.5.6).

6.3.5.3 Формат ключа трансформа ENCR

В качестве ключа трансформа ENCR в IKEv2 используют ключи SKei и SKer, вычисляемые согласно формуле (9). Далее ключ трансформа ENCR будет обобщенно обозначен как SKe.

Примечание — Поскольку используемые в настоящих рекомендациях трансформы ENCR представляют собой AEAD алгоритмы, то трансформ INTEG не используется, длины ключей SKai и SKar в формуле (9) принимают равными 0.

Длина ключа SKe составляет 352 бита (klen = 44) для трансформа ENCR_KUZNYECHIK_MGM_KTREE и 288 бит (klen = 36) для трансформа ENCR_MAGMA_MGM_KTREE.

Настоящие рекомендации предполагают, что из ключа трансформа SKe формируется корневой ключ K \in B_{32} и строка salt \in B_{klen - 32} :

K|salt = SKe. (28)

6.3.5.4 Алгоритм диверсификации ключа

Ключ защиты сообщения вычисляют на основании корневого ключа K и величин i1, i2 и i3, передаваемых в векторе инициализации, следующим образом:

IKETREE(K, i1, i2, i3) = Divers(Divers(Divers(K, l1, 0x00|i1), l2, STR2(i2)), l3, STR2(i3)), (29)

где i_{1} \in B_{1} , i2, i_{3} \in B_{2} — параметры диверсификации ключа;

l1, l2, l3 — константные ASCII строки длиной 6 байт (без нулевого байта в конце строки):

l1 = «level1», l2 = «level2», l3 = «level3»;

Divers (K, L, D) — алгоритм диверсификации ключа K \in B_{32} по данным диверсификации D \in B_{2} и метке L \in B_{6} , который определен с использованием алгоритма KDF_GOSTR3411_2012_256, описанного в пункте 4.4 Р 50.1.113-2016, таким образом, что Divers(K,L,D) \equiv KDF_{256}(K,L,D) .

6.3.5.5 Формат вектора инициализации сообщения

Каждое защищенное сообщение содержит вектор инициализации. Вектор инициализации представляет собой конкатенацию четырех величин:

(30)

где i_{1} \in B_{1} , i2, i_{3} \in B_{2} — параметры диверсификации ключа;

pnum \in B_{3} — порядковый номер сообщения, зашифрованного на данном ключе.

l2, l3 и PNUM являются представлением в сетевом порядке байт величин i2, i3 и pnum соответственно (см. рисунок 24). Суммарная длина вектора инициализации — 8 байт.

Рисунок 24 — Формат вектора инициализации

Значение вектора инициализации должно быть уникальным для каждого зашифрованного сообщения в контексте данного защищенного соединения. То есть, для данного ключа K должно быть обеспечено различие векторов инициализации IV = i1|l2|l3|PNUM для всех передаваемых пакетов.

6.3.5.6 Ключ защиты сообщения

Ключ шифрования и имитозащиты сообщения вычисляют следующим образом

Kmsg = IKETREE(K, i1, i2, i3), (31)

где K — корневой ключ трансформа ENCR;

i_{1} \in B_{1} , i2, i_{3} \in B_{2} — параметры диверсификации ключа, передаваемые в векторе инициализации (см. 6.3.5.5).

6.3.5.7 Одноразовый вектор

Для защиты сообщения используют одноразовый вектор nonce. Формат одноразового вектора зависит от используемого трансформа.

Для трансформа ENCR_KUZNYECHIK_MGM_KTREE одноразовый вектор nonce имеет размер 128 бит, его формируют, как показано на рисунке 25.

Рисунок 25 — Формат одноразового вектора для трансформа ENCR_KUZNYECHIK_MGM_KTREE

где zero — 8 нулевых бит ( zero \in B_{1} , zero \equiv 0 );

PNUM — порядковый номер сообщения (24 бита) из вектора инициализации (см. рисунок 24);

salt — соль (96 бит), берут из ключа трансформа SKe (см. формулу (28)).

Для трансформа ENCR_MAGMA_MGM_KTREE одноразовый вектор имеет размер 64 бита, его формируют, как показано на рисунке 26.

Рисунок 26 — Формат одноразового вектора для трансформа ENCR_MAGMA_MGM_KTREE

где zero — 8 нулевых бит ( zero \in B_{1} , zero = 0);

PNUM — порядковый номер сообщения (24 бита) из вектора инициализации (см. рисунок 24);

salt — соль (32 бит), берут из ключа трансформа SKe (см. формулу (28)).

Иными словами, одноразовый вектор nonce вычисляют на основании строки salt \in B_{klen - 32} и порядкового номера пакета pnum \in B_{3} следующим образом

nonce = zero|PNUM|salt. (32)

Для трансформа ENCR_KUZNYECHIK_MGM_KTREE одноразовый вектор nonce имеет размер 128 бит, для трансформа ENCR_MAGMA_MGM_KTREE одноразовый вектор nonce имеет размер 64 бита.

6.3.5.8 Формат защищенного сообщения IKE

Формат защищенного сообщения IKE показан на рисунке 27.

Рисунок 27 — Формат защищенного сообщения IKE

Дополнительные имитозащищенные данные (AAD) включают в себя заголовок сообщения IKE (см. рисунок 2), все незашифрованные секции, предшествующие секции Encrypted или секции Encrypted Fragment, если таковые присутствуют в сообщении <1>, и заголовок секции Encrypted (см. рисунок 20) или секции Encrypted Fragment (см. рисунок 23).

<1> В настоящих рекомендациях ни один обмен не содержит таких секций.

AAD = IKE-hdr|[unencrypted-pld|]pld-hdr, (33)

где IKE-hdr — заголовок сообщения IKE (см. 5.1);

unencrypted-pld — незашифрованные секции в сообщении (опционально, в случае их наличия);

pld-hdr — заголовок секции Encrypted (см. 5.14) или Encrypted Fragment (см. 5.16) в зависимости от того, применяется ли к сообщению IKE-фрагментация.

При использовании трансформа ENCR_KUZNYECHIK_MGM_KTREE имитовставку после вычисления усекают до размера 96 бит путем отбрасывания бит справа, при использовании трансформа ENCR_MAGMA_MGM_KTREE используют полную имитовставку (64 бита). Полученную величину записывают в поле Integrity Check Value.

6.3.5.9 Выбор параметров диверсификации ключа

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

6.3.5.10 Нагрузка на криптографические ключи

Предполагается, что передающая сторона ведет учет объема данных, защищенных на одном ключе Kmsg (ключ сообщения, который вырабатывают по параметрам i1, i2, i3 согласно формуле (31)). Если при обработке очередного сообщения объем трафика будет превышен, либо произойдет переполнение счетчика pnum, то до обработки данного пакета передающая сторона вырабатывает новый ключ Kmsg путем увеличения параметра i3 на единицу, pnum при этом обнуляется. При возможном превышении нагрузки на ключ второго уровня или при переполнении i3 передающая сторона производит увеличение параметра i2 на единицу, а при возможном превышении нагрузки на ключ первого уровня или при переполнении i2 передающая сторона производит увеличение параметра i1 на единицу. При превышении нагрузки на ключ K или при переполнении i1 передающая сторона удаляет данное защищенное соединение и взамен него создает новое с новым корневым ключом K, при этом значения i1, i2, i3 и pnum сбрасывают в 0.

Формула (34) описывает логику выработки нового ключа защиты сообщения, если нагрузка на текущий ключ Kmsg достигла предельно допустимого значения, или при увеличении pnum произойдет его переполнение:

(34)

иначе необходимо пересчитать Kmsg согласно (31),

где i_{1}^{max} , i_{2}^{max} и i_{3}^{max} должны быть заданы политикой безопасности, но в любом случае ограничены величинами: i_{1}^{max} \leq 255 , i_{2}^{max} \leq 65535 и i_{3}^{max} \leq 65535 .

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

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

Предполагается, что на приемной стороне также ведется учет объема данных (см. приложение Д), защищенных на одном ключе Kmsg (ключ сообщения, который приемная сторона вырабатывает по параметрам i1, i2, i3 из полученного сообщения согласно формуле (31)). Если при получении очередного сообщения объем входящего трафика, защищенного на данном ключе Kmsg, достигнет максимально допустимого для приемной стороны значения нагрузки на ключ или произойдет превышение нагрузки на промежуточные ключи дерева, то обработка пакета продолжается как обычно, но при этом приемная сторона инициирует создание нового защищенного соединения с новым ключом K, которое должно быть использовано взамен текущего.

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

Если на приемной стороне фиксируют получение значительного числа искаженных сообщений за короткий промежуток времени в контексте какого-то защищенного соединения, то это может служить признаком проведения атаки, особенно если при этом наблюдается частое изменение значений i1, i2, i3 и pnum в получаемых пакетах. В этом случае приемная сторона может удалить данное защищенное соединение и создать идентичное ему, но с новыми идентификаторами IKE SPI и с новым ключом Kencr.

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

Максимально допустимый объем трафика, обрабатываемого на одном ключе, указан в справочном приложении Д.

6.4 Идентификаторы алгоритмов

Ниже приведены идентификаторы трансформов, используемых в настоящих рекомендациях. Эти идентификаторы также приведены в [5].

Идентификаторы для трансформа типа 1 (алгоритм шифрования):

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

Идентификаторы для трансформа типа 3 (алгоритм имитозащиты):

Идентификаторы для трансформа типа 4 (алгоритм Обмена Ключами):

Идентификаторы для метода аутентификации:

Идентификаторы для хэш-алгоритмов, включаемые в уведомление SIGNATURE_HASH_ALGORITHMS:

В соответствии с Р 1323565.1.023 значения ASN.1 объектов AlgorithmIdentifier, которые указывают в поле AlgorithmIdentifier секции Authentication при аутентификации с помощью цифровой подписи, должны быть заданы следующим образом:

• для алгоритма ГОСТ Р 34.10 с длиной ключа 256 бит:

OID: id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::=

{ iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-12-256(2)}

Параметры отсутствуют.

Длина ASN.1 объекта AlgorithmIdentifier — 12 байт.

Представление в шестнадцатеричном виде:

30 0a 06 08 2a 85 03 07 01 01 03 02

• для алгоритма ГОСТ Р 34.10 с длиной ключа 512 бит:

OID: id-tc26-signwithdigest-gost3410-12-512 OBJECT IDENTIFIER ::=

{ iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-12-512(3)}

Параметры отсутствуют.

Длина ASN.1 объекта AlgorithmIdentifier — 12 байт.

Представление в шестнадцатеричном виде:

30 0a 06 08 2a 85 03 07 01 01 03 03

7 Фиксированные алгоритмы

В протоколе IKEv2 в некоторых случаях применяется функция сжимающего отображения nSHA. В частности:

• при вычислении содержимого Уведомлений NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP (см. 4.11);
• при вычислении содержимого секции Certificate Request (см. 5.7).

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

Описание функции nSHA приведено в приложении А.

Приложение А (обязательное)

ОПИСАНИЕ ФУНКЦИИ СЖИМАЮЩЕГО ОТОБРАЖЕНИЯ nSHA

В данном приложении использована своя система обозначений (x и y — двоичные вектора одинаковой длины):

x \wedge y — побитовая операция «И» между операндами x и y;

x \vee y — побитовая операция «ИЛИ» между операндами x и y;

xy — побитовая операция «ИСКЛЮЧАЮЩЕЕ ИЛИ» между операндами x и y;

x — побитовая инверсия операнда x;

x + y — сложение операндов x и y по модулю 232;

x << n — побитовый сдвиг x влево на n бит с поглощением бит слева и дописыванием нулевых бит справа;

x >> n — побитовый сдвиг x вправо на n бит с поглощением бит справа и дописыванием нулевых бит слева;

x mod y — остаток от деления x на y;

ROTLn(x) — циклический сдвиг 32-битного операнда x влево на n бит (n < 31):

ROTL^{n}(x) = (x \ll n) \vee (x \gg 32 - n) .

Все константы, используемые в данном приложении, представляют собой 32-битные числа в формате big-endian.

В nSHA использованы функции ft (x, y, z) и константы Kt, которые определяют следующим образом в зависимости от 0 <= t <= 79:

(А.1)

(А.2)

Для вычисления значения nSHA от сообщения M первоначально проводят дополнение сообщения следующим образом. Пусть длина сообщения M составляет I бит. К сообщению приписывают справа один бит равный 1, после которого приписывают k нулевых бит, где k вычисляют как минимальное значение, удовлетворяющее тождеству:

(I + 1 + k)mod512 \equiv 448. (А.3)

После этого к сообщению приписывают справа значение l, представленное как 64-битное число в формате big-endian. Получившееся в результате сообщение M' должно иметь размер, кратный 512 битам. После этого сообщение разбивают на № 512-битных блоков, обозначаемых как M(1), M(2), ..., M(N). В свою очередь, каждый такой блок записывают в виде шестнадцати 32-битных слов, обозначаемых для блока i как M_{1}^{(i)} , M_{2}^{(i)} , ..., M_{1(5)}^{i} .

Для вычисления выходного значения используют пять рабочих переменных a, b, c, d, e, а также пять переменных H_{0}^{(i)} , H_{1}^{(i)} , H_{2}^{(i)} , H_{3}^{(i)} , H_{4}^{(i)} , содержащих промежуточные значения на итерации i, и временную переменную T. Все переменные имеют размер 32 бита.

Перед началом вычисления H_{0}^{(i)} , H_{1}^{(i)} , H_{2}^{(i)} , H_{3}^{(i)} , H_{4}^{(i)} инициализируют следующим образом:

(А.4)

Далее, для i = 1 ... № выполняют следующие вычисления:

• подготавливают вектор переменных {Wt}, t = 0 ... 79:

(А.5)

• инициализируют рабочие переменные a, b, c, d, e:

(А.6)

• для t = 0 ... 79 вычисляют:

(А.7)

• вычисляют новые промежуточные значения H_{0}^{(i)} , H_{1}^{(i)} , H_{2}^{(i)} , H_{3}^{(i)} , H_{4}^{(i)} :

(А.8)

Результирующее значение размером 160 бит вычисляют как конкатенацию H_{0}^{(i)} , H_{1}^{(i)} , H_{2}^{(i)} , H_{3}^{(i)} , H_{4}^{(i)} после выполнения № итераций

nSHA(M) = H_{0}^{(N)}|H_{1}^{(N)}|H_{2}^{(N)}|H_{3}^{(N)}|H_{4}^{(N)}. (А.9)

Приложение Б (справочное)

ДИАГРАММЫ ОБМЕНОВ IKEv2

Б.1 Общая информация о данном приложении

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

Б.2 Обмен IKE_SA_INIT

Б.3 Обмен IKE_AUTH

Б.4 Обмен CREATE_CHILD_SA для создания или обновления ключей IPsec SA

Б.5 Обмен CREATE_CHILD_SA для обновления ключей IKE SA

Б.6 Обмен INFORMATIONAL

Приложение В (справочное)

ОБОБЩЕННОЕ ОПИСАНИЕ ПРОТОКОЛА IKEv2

В.1 Общая информация о данном приложении

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

В.2 Первоначальное создание защищенных соединений IKE и ESP

Осуществляется посредством обменов IKE_SA_INIT и IKE_AUTH.

Таблица В.1

Первоначальное создание защищенных соединений IKE и ESP

В.3 Обновление ключей защищенного соединения IKE

Осуществляют путем создания нового защищенного соединения IKE на основе существующего посредством обмена CREATE_CHILD_SA.

Таблица В.2

Обновление ключей защищенного соединения IKE

В.4 Создание нового защищенного соединения ESP со свойством PFS

Осуществляют посредством обмена CREATE_CHILD_SA.

Таблица В.3

Создание нового защищенного соединения ESP со свойством PFS

В.5 Создание нового защищенного соединения ESP без свойства PFS

Осуществляют посредством обмена CREATE_CHILD_SA.

Таблица В.4

Создание нового защищенного соединения ESP без свойства PFS

Приложение Г (справочное)

ИСПОЛЬЗОВАНИЕ КЛЮЧЕЙ В ПРОТОКОЛЕ IKEv2

Таблица Г.1 содержит обобщенную информацию об используемых в протоколе IKEv2 ключах.

Таблица Г.1

Ключи в IKEv2

Приложение Д (справочное)

ОГРАНИЧЕНИЯ НА ОБЪЕМ ТРАФИКА

Таблица Д.1 содержит рекомендуемые величины максимально допустимого суммарного объема трафика, который может обрабатываться на одном ключе Kmsg. При достижении максимального объема должен быть выработан новый ключ Kmsg из дерева ключей по процедуре, описанной в 6.3.5.10.

Таблица Д.1

Максимально допустимый объем трафика, обрабатываемого на одном ключе Kmsg

При использовании трансформа, базирующегося на шифре «Магма» (ENCR_MAGMA_MGM_KTREE), рекомендуется ограничивать количество допустимых ключей Kmsg для каждого корневого ключа K величиной меньшей, чем размер дерева ключей при полном переборе i1, i2, i3 (например, путем введения ограничений на максимальные значения этих счетчиков).

БИБЛИОГРАФИЯ