RFC 5996 (часть 2)

image_print

Часть 1

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

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

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

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

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Initiator's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Responder's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Payload | MjVer | MnVer | Exchange Type |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Message ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат заголовка IKE

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

Initiator’s SPI (8 октетов)

Значение, выбранное инициатором для уникальной идентификации IKE Security Association. Нулевое значение недопустимо.

Responder’s SPI (8 октетов)

Значение, выбранное ответчиком для уникальной идентификации IKE Security Association. Это поле должно иметь значение 0 в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie).

Next Payload (1 октет)

Указывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.

Major Version (4 бита)

Указывает старшую часть номера версии используемого протокола IKE. Реализации на основе данной версии IKE, должны устанавливать Major Version=2. Реализации, основанные на предыдущих версиях IKE и ISAKMP, должны устанавливать Major Version=1. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим 2, возвращая уведомление INVALID_MAJOR_VERSION, как описано в параграфе 2.5.

Minor Version (4 бита)

Тип обмена

Значение

IKE_SA_INIT

34

IKE_AUTH

35

CREATE_CHILD_SA

36

INFORMATIONAL

37

Указывает младшую часть номера версии IKE. Реализации на основе этого документа должны устанавливать Minor Version = 0 и игнорировать младшую часть номера в принимаемых сообщениях.

Exchange Type (1 октет)

Указывает тип обмена, который будет применяться. Это значение ограничивает тип элементов данных, передаваемых в каждом сообщении обмена. Приведенные в таблице справа значения типов были определены на момент публикации RFC 4306. Другие значения могли быть добавлены с тех пор и могут добавляться после публикации этого документа. Актуальный набор значений можно найти в [IKEV2IANA].

Flags (1 октет)

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

        +-+-+-+-+-+-+-+-+
        |X|X|R|V|I|X|X|X|
        +-+-+-+-+-+-+-+-+

В приведенных ниже описаниях установленные флаги имеют значение 1, сброшенные — 0. Флаги, обозначенные символом X должны быть сброшены при передаче, а на приемной стороне должны игнорироваться.

R (Response)

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

V (Version)

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

I (Initiator)

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

Message ID (4 октета, целое число без знака)

Идентификатор сообщения, используемый для управления повтором передачи потерянных пакетов и определения соответствия между запросами и откликами. Идентификатор играет важную роль в безопасности протокола, поскольку служит для предотвращения атак с повторным использованием пакетов (см. параграфы 2.1 и 2.2).

Length (4 октета, целое число без знака)

Размер всего сообщения (заголовок и элементы данных) в октетах.

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Базовый заголовок элемента данных

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

Next Payload (1 октет)

Тип следующего элемента данных

Обозначение

Значение

Нет

0

Защищенная связь

SA

33

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

KE

34

Идентификация — инициатор

IDi

35

Идентификация — ответчик

IDr

36

Сертификат

CERT

37

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

CERTREQ

38

Аутентификация

AUTH

39

Nonce

Ni, Nr

40

Уведомление

N

41

Удаление

D

42

Идентификатор производителя

V

43

Селектор трафика — инициатор

TSi

44

Селектор трафика — ответчик

TSr

45

Зашифрованные и аутентифицированные

SK

46

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

CP

47

Расширяемая аутентификация

EAP

48

Идентификатор типа следующего элемента данных в сообщении. Если текущий элемент является последним, это поле имеет значение 0. Это поле позволяет создавать «цепочки», когда дополнительный элемент просто добавляется в конец сообщения и устанавливается значение поля Next Payload в предыдущем элементе для индикации типа нового элемента. Элемент типа Encrypted, который всегда должен быть последним в сообщении, является исключением. Он содержит структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле Next Payload устанавливается в соответствии с типом первого вложенного элемента (вместо 0), а в поле Next Payload последнего вложенного элемента устанавливается 0. Значения типов элементов данных показаны в таблице. Эти значения были определены на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Значения 1 — 32 не были распределены для того, чтобы не возникало перекрытия с кодами, определенными для IKEv1.

Critical (1 бит)

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

RESERVED (7 битов)

Должен устанавливаться в 0 при передаче и игнорироваться на приемной стороен.

Payload Length (2 октета, целое число без знака)

Размер текущего элемента данных в октетатх с учетом базового заголовка элемента данных.

Многие элементы данных содержат резервные (RESERVED) поля. Некоторые элементы данных в IKEv2 (и в IKEv1) не выравниваются по 4-октетным границам.

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

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

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

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

Структура Proposal включает Proposal Num (номер предложения) и идентификатор протокола IPsec. Каждая структура должна использовать номер предложения, увеличенный на 1 по сравнению со значением в предыдущей структуре. Первый элемент Proposal в SA инициатора должен иметь Proposal Num = 1. Одной из причин использования множества предложений является обеспечение возможности предложить использования стандартных и комбинированных шифров. Комбинированные шифры обеспечивают шифрование и защиту целостности на основе одного алгоритма и должны не предлагать алгоритма защиты целостности или предлагать алгоритм none (первый вариант является рекомендуемым). Если инициатор хочет предложить комбинированные и стандартные шифры, он должен включить два предложения — одно включает все комбинированные алгоритмы, а другое — все обычные алгоритмы в комбинации с алгоритмами защиты целостности. Например, одно такое предложение будет включать две структуры Proposal. Первая структура Proposal 1 предлагает ESP с ключами AES-128, AES-192, AES-256 в режиме CBC1 и алгоритмом защиты целостности HMAC-SHA1-96 или XCBC-96, а вторая структура Proposal 2 предлагает AES-128 или AES-256 в режиме GCM с 8-октетным значением контроля четности (ICV2). Оба предложения позволяеют, но не требуют использовать расширенные порядковые номера ESN3. Вид пердложений представлен на рисунке.

   Элемент SA 
      |
      +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
      |     |            7 преобразований,      SPI = 0x052357bb )
      |     |
      |     +-- Преобразование ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Атрибут ( Key Length = 128 )
      |     |
      |     +-- Преобразование ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Атрибут ( Key Length = 192 )
      |     |
      |     +-- Преобразование ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Атрибут ( Key Length = 256 )
      |     |
      |     +-- Преобразование INTEG ( Name = AUTH_HMAC_SHA1_96 )
      |     +-- Преобразование INTEG ( Name = AUTH_AES_XCBC_96 )
      |     +-- Преобразование ESN ( Name = ESN )
      |     +-- Преобразование ESN ( Name = не ESN )
      |
      +--- Proposal #2 ( Proto ID = ESP(3), размер SPI = 4,
            |            4 преобразования,      SPI = 0x35a1d6f2 )
            |
            +-- Преобразование ENCR ( Name = AES-GCM с 8 октетами ICV )
            |     +-- Атрибут ( Key Length = 128 )
            |
            +-- Преобразование ENCR ( Name = AES-GCM с 8 октетами ICV )
            |     +-- Атрибут ( Key Length = 256 )
            |
            +-- Преобразование ESN ( Name = ESN )
            +-- Преобразование ESN ( Name = не ESN )

За каждой структурой Proposal/Protocol следует одна или множество структур преобразований. Число разных преобразований обычно определяется элементом Protocol. Протокол AH обычно имеет два преобразования — расширенные порядковые номера (ESN4) и алгоритм контроля целостности. ESP обычно имеет три преобразования — ESN, алгоритм шифрования и алгоритм контроля целостности. IKE обычно имеет четыре преобразования — группа Diffie-Hellman, алгоритм контроля целостности, алгоритм PRF и алгоритм шифрования. Для каждого элемента Protocol набор разрешенных преобразований указывается значениями Transform ID после заголовка каждого преобразования.

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                          <Proposals>                          ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Элемент данных SA

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

Proposals (переменный размер)

Одна или множество субструктур Proposal.

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

3.3.1. Субструктура Proposal

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) или 2|   RESERVED    |         Proposal Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num  |  Protocol ID  |    SPI Size   |Num  Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    SPI (переменный размер)                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        <Transforms>                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Субструктура Proposal

0 (последнее) или 2 (не последнее) (1 октет)

Указывает, является ли данная субструктура Proposal последней в SA. Синтаксис поля унаследован от ISAKMP, но не является требуемым, поскольку последнюю субструктуру Proposal можно идентифицировать по размеру SA. Значение (2) соответствует элементу данных типа Proposal в IKEv1, а первые 4 октета субструктуры Proposal организованы так, чтобы выглядеть подобно заголовку элемента данных.

RESERVED (1 октет)

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Proposal Length (2 октета, целое число без знака)

Размер данной субструктуры Proposal с учетом всех следующих за ним преобразований и атрибутов.

Proposal Num (1 октет)

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

Протокол

Идентификатор

IKE

1

AH

2

ESP

3

Protocol ID (1 октет)

Задает идентификатор протокола IPsec для текущего согласования. Определенные на момент публикации RFC 4306 значения идентификаторов показаны в таблице. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

SPI Size (1 октет)

Для начального согласования IKE_SA это поле должно иметь нулевое значение; значение SPI получается из внешнего заголовка. При последующих согласованиях это поле показывает размер (в октетах) SPI для соответствующего протокола (8 для IKE, 4 для ESP и AH).

Num Transforms (1 октет)

Указывает число преобразований в этом предложении.

SPI (переменный размер)

Значение SPI передающей стороны. Даже при SPI Size не кратном 4 октетам заполнение для этого поля не применяется. При SPI Size = 0 это поле отсутствует в элементе данных SA.

Transforms (переменный размер)

Одна или множество субструктур Transform.

3.3.2. Субструктура Transform

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) или 3|   RESERVED    |        Transform Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type |   RESERVED    |          Transform ID         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      Transform Attributes                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Субструктура Transform

0 (последнее) или (не последнее) (1 октет)

Указывает, является ли данная субструктура Transform последней в Proposal. Синтаксис поля унаследован от ISAKMP, но не является требуемым, поскольку последнюю субструктуру Transform можно идентифицировать по размеру Proposal. Значение (3) соответствует элементу данных типа Transform в IKEv1, а первые 4 октета субструктуры Transform организованы так, чтобы выглядеть подобно заголовку элемента данных.

RESERVED

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Transform Length

Размер данной субструктуры Transform с учетом всех следующих за ним преобразований и атрибутов.

Transform Type (1 октет)

Тип преобразования, задаваемого этой субструктурой. Различные протоколы поддерживают разные значения Transform Type. Для некоторых протоколов отдельные преобразования могут быть необязательными. Если преобразование не является обязательным, а инициатор желает внести предложение без него, такое преобразование просто опускается. Если инициатор хочет передать решение вопроса использования необязательного преобразования ответчику, он включает эту субструктуру с Transform ID = 0 в качестве одной из опций.

Transform ID (2 октета)

(*) Согласование алгоритма защиты целостности является обязательным для формата Encrypted, описанного в этом документе. Например, [AEAD] задает дополнительные форматы, основанные на аутентифицированном шифровании, где отдельный алгоритм защиты целостности не согласуется.

Описание

Тип

Применение

Алгоритм шифрования (ENCR)

1

IKE и ESP

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

2

IKE

Алгоритм защиты целостности (INTEG)

3

IKE*, AH, опционально в ESP

Группа Diffie-Hellman (D-H)

4

IKE, может использоваться также в AH и ESP

Расширенные порядковые номера (ESN)

5

AH и ESP

Указывает конкретный экземпляр Transform Type, который будет предложен.

Значения Transform Type, приведенные в таблице, отражают типы, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Имя

Номер

Документ

ENCR_DES_IV64

1

Нет спецификации

ENCR_DES

2

RFC2405, [DES]

ENCR_3DES

3

RFC2451

ENCR_RC5

4

RFC2451

ENCR_IDEA

5

RFC2451, [IDEA]

ENCR_CAST

6

RFC2451

ENCR_BLOWFISH

7

Нет спецификации

ENCR_3IDEA

8

Нет спецификации

ENCR_DES_IV32

9

Нет спецификации

ENCR_NULL

11

RFC2410

ENCR_AES_CBC

12

RFC3602

ENCR_AES_CTR

13

RFC3686

Для преобразований типа 1 (Transform Type 1, алгоритм шифрования) значения идентификаторов преобразования (Transform ID) приведены в таблице слева, включающей идентификаторы, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Имя

Номер

Документ

PRF_HMAC_MD5

1

RFC2104, [MD5]

PRF_HMAC_SHA1

2

RFC2104, [SHA]

PRF_HMAC_TIGER

3

Нет спецификации

Для преобразований типа 2 (Transform Type 2, псевдослучайная функция) значения Transform ID приведены в таблице справа, включающей идентификаторы, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Имя

Номер

Документ

NONE

0

AUTH_HMAC_MD5_96

1

RFC2403

AUTH_HMAC_SHA1_96

2

RFC2404

AUTH_DES_MAC

3

Нет спецификации

AUTH_KPDK_MD5

4

Нет спецификации

AUTH_AES_XCBC_96

5

RFC3566

Для преобразований типа 3 (Transform Type 3, алгоритм защиты целостности) значения Transform ID приведены в таблице справа, включающей идентификаторы, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Для преобразований типа 4 (Transform Type 4, группа Diffie-Hellman) значения Transform ID приведены в таблице слева, включающей идентификаторы, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Имя

Номер

Документ

NONE

0

768-битовый MODP

1

Приложение B

1024-битовый MODP

2

Приложение B

1536-битовый MODP

5

[ADDGROUP]

2048-битовый MODP

14

[ADDGROUP]

3072-битовый MODP

15

[ADDGROUP]

4096-битовый MODP

16

[ADDGROUP]

6144-битовый MODP

17

[ADDGROUP]

8192-битовый MODP

18

[ADDGROUP]

Хотя протоколы ESP и AH не включают напрямую обмена Diffie-Hellman, группа DH может быть согласована для Child SA. Это позволяет партнерам использовать метод Diffie-Hellman в обмене CREATE_CHILD_SA для обеспечения совершенной защиты генерируемых ключей Child SA.

Имя

Номер

Нет ESN

0

ESN

1

Для преобразований типа 5 (Transform Type 5, расширенные порядковые номера ESN) значения Transform ID приведены в таблице справа, включающей идентификаторы, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

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

С момента публикации RFC 4306 было добавлено множество значения Transform Type, которые можно найти в реестре IANA IKEv2.

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

Протокол

Обязательные типы

Опциональные типы

IKE

ENCR, PRF, INTEG*, D-H

ESP

ENCR, ESN

INTEG, D-H

AH

INTEG, ESN

D-H

(*) Согласование алгоритма защиты целостности является обязательным для формата Encrypted, описанного в этом документе. Например, [AEAD] задает дополнительные форматы, основанные на аутентифицированном шифровании, где отдельный алгоритм защиты целостности не согласуется.

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

3.3.4. Обязательные Transform ID

Указание шифронаборов, которые должно и следует поддерживать для интероперабельности, было удалено из этого документа, поскольку стало ясно, что эти списки будут меняться чаще, нежели обновляется документ. На момент публикации этого документа такие шифронаборы были указаны в [RFC4307], но следует отметить, что этот список может быть обновлен в будущем, а другие RFC могут задавать другие наборы шифров.

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

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

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|       Attribute Type        |    AF=0  Attribute Length     |
|F|                             |    AF=1  Attribute Value      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   AF=0  Attribute Value                       |
|                   AF=1  Not Transmitted                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Атрибуты преобразования

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

Attribute Format (AF) (1 бит)

Указывает использование для данных атрибута формата TLV6 или более короткого TV7. Нулевое значение флага AF говорит о формате TLV, а 1 — о формате TV (2-байтовое значение).

Attribute Type (15 битов)

Уникальный идентификатор типа атрибута (см. ниже).

Attribute Value (переменный размер)

Значение атрибута указанного типа. Если бит AF сброшен (0), это поле имеет переменный размер, указанный полем Attribute Length. При установленном (1) флаге AF поле Attribute Value имеет размер 2 октета.

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

Тип атрибута

Значение

Формат атрибута

Key Length (в битах)

14

TV

В таблице указано значение, определенное на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Значения 0 — 13 и 15 — 17, использовалишь в похожем контексте IKEv1 и их не следует выделять без наличия совпадений.

Атрибут Key Length указывает размер ключа в битах (должен использоваться сетевой порядок байтов) для некоторых преобразований, как описано ниже.

  • Атрибут Key Length недопустимо использовать в преобразованиях с фиксированным размером ключа. Например, к таким преобразованиям относятся ENCR_DES, ENCR_IDEA, а также все преобразования Type 2 (псевдослучайная функция) и Type 3 (защита целостности), описанные в этом документе.

  • Для некоторых преобразований атрибут Key Length должен включаться всегда (пропускать атрибут не разрешается и преобразования без него должны отвергаться). Примерами могут служить преобразования ENCR_AES_CBC и ENCR_AES_CTR.

  • В некоторых преобразованиях с переменным размером ключей устанавливается используемый по умолчанию размер. Примерами таких преобразований являются ENCR_RC5 и ENCR_BLOWFISH.

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

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

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

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

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

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

3.4. Элемент Key Exchange

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Diffie-Hellman Group Num    |           RESERVED            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Key Exchange Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Формат элемента Key Exchange

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

KE создается путем копирования открытого значения Diffie-Hellman в поле Key Exchange Data. Размер открытого значения DH для модульных экспоненциальных групп (MODP9) должен совпадать с размером простого числа (prime modulus), которое возводится в степень. При необходимости поле заполняется нулями слева (prepend).

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

Идентификатор типа для элемента Key Exchange имеет значение 34.

3.5. Элемент Identification

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

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

База данных PAD10, как указано в RFC 4301 [IPSECARCH], описывает использование элемента ID в IKEv2 и обеспечивает формальную модель для привязки отождествления в политики в дополнение к службам, связанным более конкретно с исполнением политики. PAD предназначена для обеспечения связи между SPD и управления IKE Security Association (дополнительную информацию можно найти в параграфе 4.4.3 RFC 4301).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ID Type     |                 RESERVED                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Identification Data                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Формат данных Identification

Элемент Identification состоит из базового заголовка данных IKE, за которым следуют описанные ниже поля идентификации.

ID Type (1 октет)

Задает тип используемой идентификации.

RESERVED

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Identification Data (переменный размер)

Значение, определяемое полем Identification Type. Размер идентификационных данных рассчитывается из размера в заголовке элемента ID.

Идентификатор типа для элемента Identification имеет значение 35 в случае IDi и 36 в случае IDr.

В таблице приведены значения типов идентификации, выделенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

ID Type

Значение

Описание Identification Data

ID_IPV4_ADDR

1

Один четырехоктетный адрес IPv4.

ID_FQDN

2

Строка полного доменного имени (например, example.com). В строку недопустимо включать символы завершения (NULL, CR и т. п.). Все символы ID_FQDN указываются в кодировке ASCII, для доменных имен на других языках применяется синтаксис, определенный в [IDNA] (например, xn--tmonesimerkki-bfbb.example.net).

ID_RFC822_ADDR

3

Строка полного почтового адреса RFC822 (например, jsmith@example.com). В строку недопустимо включать символы завершения. С учетом [EAI] реализациям уместно трактовать эту строку, как текст UTF-8, а не ASCII.

ID_IPV6_ADDR

5

Один шестнадцатиоктетный адрес IPv6.

ID_DER_ASN1_DN

9

Двоичное представление в формате DER11 для ASN.1 X.500 Distinguished Name [PKIX].

ID_DER_ASN1_GN

10

Двоичное представление в формате DER для ASN.1 X.500 GeneralName [PKIX].

ID_KEY_ID

11

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

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

EAP [EAP] не требует использования какого-либо конкретного типа идентификаторов, но зачастую EAP применяется с идентификаторами NAI12, определенными в [NAI]. Хотя идентификаторы NAI похожи на адреса электронной почты (например, joe@example.com), их синтаксис отличается от синтаксиса почтовых адресов [MAILFORMAT]. По этой причине для NAI с компонентов realm (область) следует указывать типа ID_RFC822_ADDR. Реализациям ответчиков не нужно предпринимать попыток проверки точного соответствия идентификатора синтаксису [MAILFORMAT], принимая любые, выглядящие разумно NAI. Для идентификаторов NAI без компоненты следует указывать тип ID_KEY_ID.

3.6. Элемент Certificate

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                       Certificate Data                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. Формат элемента Certificate

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

Поля элемента Certificate описаны ниже.

Сертификат

Код

Описание

PKCS #7 wrapped X.509

1

Не задано

PGP

2

Не задано

DNS Signed Key

3

Не задано

X.509 — подпись

4

Kerberos Token

6

Не задано

CRL (список отозванных сертификатов)

7

ARL (список УЦ с прерванными полномочиями)

8

Не задано

SPKI

9

Не задано

X.509 — атрибут

10

Не задано

Raw RSA Key

11

Хэш и URL сертификата X.509

12

Хэш и URL связки (bundle) X.509

13

Certificate Encoding (1 октет)

Это поле указывает тип сертификата или связанной с сертификатом информации в поле Certificate Data. В таблице приведены значения типов сертификатов, выделенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Certificate Data (переменный размер)

Реальный размер сертификационных данных. Тип сертификата задается полем Certificate Encoding field.

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

Конкретный синтаксис для некоторых типов сертификатов в этом документе не определен. Ниже приведен список типов сертификатов, для которых синтаксис определен в этой спецификации.

  • «X.509 — подпись» содержит DER-представление сертификата X.509, открытый ключ которого служит для проверки элемента AUTH отправителя. Отметим, что при этом варианте представления в случаях, когда нужно передать цепочку сертификатов, используется множество элементов CERT и только первый из них содержит открытый ключ, используемый для проверки элемента AUTH отправителя.

  • CRL содержит DER-представление списка отозванных сертификатов X.509.

  • Raw RSA Key содержит представление PKCS #1 ключа RSA, т. е., представленную в формате DER структуру RSAPublicKey (см. [RSA] и [PKCS1]).

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

Тип «Хэш и URL связки» (Hash and URL of a bundle) использует определение ASN.1 для связки X.509 приведенное ниже.

   CertBundle
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-cert-bundle(34) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
     Certificate, CertificateList
     FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-explicit(18) } ;

   CertificateOrCRL ::= CHOICE {
     cert [0] Certificate,
     crl  [1] CertificateList }

   CertificateBundle ::= SEQUENCE OF CertificateOrCRL

   END

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

Реализации должны поддерживать метод HTTP для поиска hash-and-URL. Поведение других URL-методов в настоящее время не задается и такие методы не следует применять при отсутствии спецификаций для них.

3.7. Элемент Certificate Request

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                    Certification Authority                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Формат элемента Certificate Request

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

Поля Certificate Request описаны ниже.

Certificate Encoding (1 октет)

Указывает тип или формат запрашиваемого сертификата. Возможные значения указаны в параграфе 3.6.

Certification Authority (переменный размер)

Указывает представление приемлемого удостоверяющего центра для запрошенного типа сертификата.

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

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

Содержимое поля Certification Authority определено только для сертификатов X.509 (типы 4, 12 и 13). Использовать другие значения не следует, пока не будут опубликованы соответствующие спецификации их применения со статусом Standards-Track.

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

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

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

  • настроен на использование аутентификации по сертификатам;

  • имеет разрешение на передачу элемента CERT;

  • имеет соответствующую политику доверия к CA для текущего согласования;

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

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

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

Уведомления HTTP_CERT_LOOKUP_SUPPORTED могут включаться в любые сообщения, которые могут включать элемент CERTREQ, для указания возможности отправителя просматривать сертификаты но ссылкам HTTP (URL) и, следовательно, его вероятного предпочтения сертификатов в таком формате.

3.8. Элемент Authentication

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method   |                RESERVED                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      Authentication Data                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат элемента Authentication

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

Поля элемента Authentication описаны ниже.

Auth Method (1 октет)

Задает используемый метод аутентификации. Ниже перечислены типы подписей, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

RSA Digital Signature 1

Рассчитывается в соответствии с параграфом 2.15 с использованием секретного ключа RSA со схемой подписи RSASSA-PKCS1-v1_5, описанной в [PKCS1] (разработчикам следует принимать во внимание, что IKEv1 использует другой метод для подписей RSA). Для обеспечения взаимодействия реализациям, поддерживающим этот тип, следует поддерживать подписи, использующие SHA-1 в качестве хэш-функции, а также следует применять функцию SHA-1 по умолчанию при генерации подписей. Реализации могут использовать полученный от партнера сертификат, как рекомендацию по выбору понятной обеим сторонам хэш-функции для подписи в элементе AUTH. Однако следует отметить, что используемый в подписи элемента AUTH алгоритм хэширования не обязан совпадать с алгоритмами хэширования в сертификатах.

Shared Key Message Integrity Code 2

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

DSS Digital Signature 3

Рассчитывается в соответствии с параграфом 2.15 с использованием секретного ключа DSS (см. [DSS]) и хэширования SHA-1.

Authentication Data (переменный размер)

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                            Nonce Data                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Формат элемента Nonce

См. параграф 2.15.

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

3.9. Элемент Nonce

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

Элемент Nonce включает единственное поле.

Nonce Data (переменный размер)

Случайные данные, генерируемые передающей стороной.

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

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

3.10. Элемент Notify

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol ID  |   SPI Size    |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                Security Parameter Index (SPI)                 ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Notification Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. Формат элемента Notify

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

Поля элемента Notify описаны ниже.

Protocol ID (1 октет)

Если уведомление относится к существующей SA, значение SPI которой указано в поле SPI, это поле показывает тип данной SA. Для уведомлений, относящихся к Child SA, это поле должно содержать значение 2 для индикации протокола AH или 3 для индикации ESP. Из уведомлений, определенных в этом документе, поле SPI включается только в INVALID_SELECTORS, REKEY_SA и CHILD_SA_NOT_FOUND15. Если поле SPI пусто, в поле идентификатора протокола при передаче должно помещаться значение 0, а на приемной стороне это поле должно игнорироваться.

SPI Size (1 октет)

Размер SPI (в октетах) в соответствии с идентификатором протокола IPsec или 0, если индекс SPI не применим. Для уведомлений, касающихся IKE_SA, поле SPI Size должно иметь значение 0, а поле SPI должно быть пустым.

Notify Message Type (2 октета)

Указывает тип уведомления.

SPI (переменный размер)

Индекс параметров защиты.

Notification Data (переменный размер)

Данные о статусе или ошибке, передаваемые в дополнение к Notify Message Type. Значения этого поля определяются типом уведомления (см. ниже).

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

3.10.1. Типы сообщений Notify

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

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

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

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

Дополнительная информация по обработке ошибок приведена в параграфе 2.21.

Ниже приведены типы сообщений, определенные на момент публикации RFC 4306, а также два дополнительных типа, определенные в этом документе. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Типы ошибок для сообщений NOTIFY.

UNSUPPORTED_CRITICAL_PAYLOAD 1

См. параграф 2.5.

INVALID_IKE_SPI 4

См. параграф 2.21.

INVALID_MAJOR_VERSION 5

См. параграф 2.5.

INVALID_SYNTAX 7

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

INVALID_MESSAGE_ID 9

См. параграф 2.3.

INVALID_SPI 11

См. параграф 1.5.

NO_PROPOSAL_CHOSEN 14

Ни один из предложенных шифронаборов не может быть принят. Такое сообщение может передаваться в любой ситуации, когда предложения (включая значения элементов SA, уведомления USE_TRANSPORT_MODE и IPCOMP_SUPPORTED и др.) не могут быть приняты ответчиком. Сообщение может также указывать ошибку общего типа для Child SA, когда связь Child SA не может быть создана по той или иной причине. См. также параграф 2.7.

INVALID_KE_PAYLOAD 17

См. параграфы 1.2 и 1.3.

AUTHENTICATION_FAILED 24

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

SINGLE_PAIR_REQUIRED 34

См. параграф 2.9.

NO_ADDITIONAL_SAS 35

См. параграф 1.3.

INTERNAL_ADDRESS_FAILURE 36

См. параграф 3.15.4.

FAILED_CP_REQUIRED 37

См. параграф 2.19.

TS_UNACCEPTABLE 38

См. параграф 2.9.

INVALID_SELECTORS 39

Может передаваться в обмене IKE INFORMATIONAL, когда узел получает пакет ESP или AH с селекторами, не соответствующими SA, использованной для его доставки (это требует отбрасывания пакета). Поле Notification Data указывает начало пакета-нарушителя (как в сообщениях ICMP), а поле SPI в уведомлении устанавливается в соответствии с SPI для Child SA.

TEMPORARY_FAILURE 43

См. параграф 2.25.

CHILD_SA_NOT_FOUND 44

См. параграф 2.25.

Типы состояний для сообщений NOTIFY.

INITIAL_CONTACT 16384

См. параграф 2.4.

SET_WINDOW_SIZE 16385

См. параграф 2.3.

ADDITIONAL_TS_POSSIBLE 16386

См. параграф 2.9.

IPCOMP_SUPPORTED 16387

См. параграф 2.22.

NAT_DETECTION_SOURCE_IP 16388

См. параграф 2.23.

NAT_DETECTION_DESTINATION_IP 16389

См. параграф 2.23.

COOKIE 16390

См. параграф 2.6.

USE_TRANSPORT_MODE 16391

См. параграф 1.3.1.

HTTP_CERT_LOOKUP_SUPPORTED 16392

См. параграф 3.6.

REKEY_SA 16393

См. параграф 1.3.3.

ESP_TFC_PADDING_NOT_SUPPORTED 16394

См. параграф 1.3.1.

NON_FIRST_FRAGMENTS_ALSO 16395

См. параграф 1.3.1.

3.11. Элемент Delete

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID   |   SPI Size    |          Num of SPIs          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~               Security Parameter Index(es) (SPI)              ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 17. Формат элемента Delete

Поля элемента Delete описаны ниже.

Protocol ID (1 октет)

1 для IKE SA, 2 для AH, 3 для ESP.

SPI Size (1 октет)

Размер (в октетах) индекса SPI, определяемого идентификатором протокола. Это поле должно иметь значение 0 для IKE (SPI заголовке сообщения) или 4 для AH и ESP.

Num of SPIs (2 октета, целое число без знака)

Число индексов SPI в элементе Delete. Размер отдельных SPI определяется полем SPI Size.

Security Parameter Index(es) (переменный размер)

Указывает конкретную удаляемую связь или связи SA. Размер этого поля определяется значениями полей SPI Size и Num of SPIs.

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

3.12. Элемент Vendor ID

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

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

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Vendor ID (VID)                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 18. Формат элемента Vendor ID

Поля элемента Vendor ID описаны ниже.

Vendor ID (переменный размер)

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

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

3.13. Элемент TS

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs |                 RESERVED                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       <Traffic Selectors>                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 19. Формат элемента TS

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

Number of TSs (1 октет)

Число представляемых селекторов трафика.

RESERVED

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Traffic Selectors (переменный размер)

Один или множество индивидуальных селекторов трафика.

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

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

Элементы TSi и TSr не обязаны включать одинаковое число селекторов трафика. Пакет считается соответствующим данному Tsi/TSr, если он соответствует хотя бы одному индивидуальному селектору в TSi и хотя бы одному индивидуальному селектору в 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))

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

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TS Type     |IP Protocol ID*|       Selector Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Start Port*         |           End Port*           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Starting Address*                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Ending Address*                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 20. Селектор трафика
* (все поля, кроме TS Type и Selector Length зависят от TS Type; на рисунке приведены поля для типов 7 и 8, определенных в настоящее время)

TS Type (1 октет)

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

IP protocol ID (1 октет)

Значение, указывающее идентификатор связанного протокола IP (например, UDP, TCP, ICMP). Нулевое значение указывает, что с данным TS не связан какой-то протокол – SA может применяться для всех протоколов.

Selector Length

Указывает размер данной субструктуры Traffic Selector с учетом заголовка.

Start Port (2 октета, целое число без знака)

Наименьший номер порта, разрешенный для этого селектора. Для протоколов, где номер порта не определен (включая protocol 0) или разрешены любые номера, это поле должно иметь значение 0. Значения кода и типа ICMP и ICMPv6, а также типы заголовка (MH) Mobile IP версии 6 (MIPv6) представляются в этом поле в соответствии с параграфом 4.4.1.1 [IPSECARCH]. Значения типа и кода ICMP трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 — код. Значения MIPv6 MH Type трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 имеют значение 0.

End Port (2 октета, целое число без знака)

Наибольший номер порта, разрешенный для этого селектора. Для протоколов, где номер порта не определен (включая protocol 0) или разрешены любые номера, это поле должно иметь значение 65535. Значения кода и типа ICMP и ICMPv6, а также типы заголовка (MH) Mobile IP версии 6 (MIPv6) представляются в этом поле в соответствии с параграфом 4.4.1.1 [IPSECARCH]. Значения типа и кода ICMP трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 — код. Значения MIPv6 MH Type трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 имеют значение 0.

Starting Address

Наименьший адрес, включенный в этот селектор трафика (размер определяется полем TS Type).

Ending Address

Наибольший адрес, включенный в этот селектор трафика (размер определяется полем TS Type).

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

Селекторы трафика типов 7 и 8 могут также указывать поля типа и кода ICMP или ICMPv6, равно как тип полей MH Type в заголовках IPv6 mobility [MIPV6]. Однако следует отметить, что пакеты ICMP и MIPv6 не имеют раздельных полей для отправителя и получателя. Метод задания селекторов трафика для ICMP и MIPv6 показан в примере параграфа 4.4.1.3 [IPSECARCH].

Ниже приведены значения поля Traffic Selector Type с описаниями адресных селекторов, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

TS_IPV4_ADDR_RANGE 7

Диапазон адресов IPv4, представленный двумя 4-октетными значениями. Первое значение указывает начальный, в второе — конечный адрес IPv4 (оба значения включаются в диапазон адресов, вместе со всеми адресами внутри диапазона).

TS_IPV6_ADDR_RANGE 8

Диапазон адресов IPv6, представленный двумя 16-октетными значениями. Первое значение указывает начальный, в второе — конечный адрес IPv6 (оба значения включаются в диапазон адресов, вместе со всеми адресами внутри диапазона).

3.14. Элемент Encrypted

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

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

В этом документе описана криптографическая обработка элементов Encrypted с использованием блочного шифра в режиме CBC и алгоритма защиты целостности с контрольными суммами фиксированного размера, рассчитываемыми для сообщений переменного размера. Устройство протокола разрабатывалось после алгоритмов ESP, описанных в RFC 2104 [KBC96], 4303 [RFC4303] и 2451 [ESPCBC]. В данном документе полностью описана криптографическая обработка данных IKE, а упомянутые документы следует рассматривать в качестве обоснования устройства протокола. В будущих документах может быть задана обработка элементов Encrypted для других видов преобразований типа алгоритмов шифрования со счетчиком (counter mode encryption) и аутентифицированного шифрования (authenticated encryption). Партнерам недопустимо согласовывать преобразования, для которых нет спецификаций.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Initialization Vector                     |
|             (размер блока для алгоритма шифрования)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Encrypted IKE Payloads                     ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             Padding (0-255 октетов)           |
+-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
|                                               |  Pad Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Integrity Checksum Data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 21. Формат элемента Encrypted

При использовании алгоритма аутентифицированного шифрования для защиты IKE SA устройство элементов Encrypted отличается от описанного здесь. В документе [AEAD] представлена информация о таких алгоритмах и их использовании в ESP.

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

Next Payload

Указывает тип первого вложенного элемента данных. Отметим, что это отличается от стандартного формата заголовка, поскольку элемент Encrypted является последним в сообщении и в этом случае полю Next Payload следовало бы иметь значение 0. Однако по причине того, что содержимым этого элемента данных являются другие (вложенные) элементы и отсутствует логичное место для размещения информации о типе первого элемента, этот тип помещен сюда.

Payload Length

Размер элемента данных с учетом полей вектора инициализации (IV), Encrypted IKE Payloads, Padding, Pad Length, и Integrity Checksum Data.

Initialization Vector

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

IKE payloads

Соответствует приведенному выше описанию. Это поле шифруется с использованием согласованного алгоритма.

Padding

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

Pad Length

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

Integrity Checksum Data

Криптографическая контрольная сумма всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем Pad Length. Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля определяется согласованным алгоритмом защиты целостности.

3.15. Элемент Configuration

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C| RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CFG Type    |                    RESERVED                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Configuration Attributes                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Поля элемента Configuration описаны ниже.

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

CFG Type (1 октет)

Тип обмена, представленного полем Configuration Attributes. В таблице приведены идентификаторы типов, определенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Тип

Значение

CFG_REQUEST

1

CFG_REPLY

2

CFG_SET

3

CFG_ACK

4

RESERVED (3 октета)

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Configuration Attributes (переменный размер)

Структуры TLV17 конкртеного элемента Configuration, описанные ниже. Элемент может включать множество атрибутов или не иметь их совсем.

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

Reserved (1 бит)

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|         Attribute Type      |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 23. Формат атрибута Configuration

Attribute Type (15 битов)

Уникальный идентификатор типа конфигурационного атрибута.

Length (2 октета, целое число без знака)

Размер значения в октетах.

Value (0 или более октетов)

Значение атрибута (переменный размер). Список возможных типов атрибутов приведен ниже.

В таблице приведен список атрибутов конфигурации, определенных на момент публикации RFC 4306 (за исключением INTERNAL_ADDRESS_EXPIRY и INTERNAL_IP6_NBNS, которое отменяются этим документом). Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Тип атрибута

Значение

Многозначный

Размер

INTERNAL_IP4_ADDRESS

1

да*

0 или 4 октета

INTERNAL_IP4_NETMASK

2

нет

0 или 4 октета

INTERNAL_IP4_DNS

3

да

0 или 4 октета

INTERNAL_IP4_NBNS

4

да

0 или 4 октета

INTERNAL_IP4_DHCP

6

да

0 или 4 октета

APPLICATION_VERSION

7

нет

0 или более

INTERNAL_IP6_ADDRESS

8

да*

0 или 17 октетов

INTERNAL_IP6_DNS

10

да

0 или 16 октетов

INTERNAL_IP6_DHCP

12

да

0 или 16 октетов

INTERNAL_IP4_SUBNET

13

да

0 или 8 октетов

SUPPORTED_ATTRIBUTES

14

нет

кратно 2

INTERNAL_IP6_SUBNET

15

да

17 октетов

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

INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS

Адрес внутренней сети, иногда называемый адресом красного узла (red node address) или приватным адресом, этот адрес может быть приватным с точки зрения сети Internet. В запросе указанный адрес является запрашиваемым (или адресом нулевого размера, если конкретный адрес не запрашивается). Если запрошен конкретный адрес, это скорей всего говорит о том, что ранее существовало соединение с таким адресом и запрашивающий узел хочет снова использовать данный адрес. В IPv6 запрашивающий узел может указать младшие байты желаемого адреса. Можно запросить множество внутренних адресов, запрашивая множество атрибутов для внутреннего адреса. Ответчик может вернуть число адресов, не превышающее запрошенное количество. INTERNAL_IP6_ADDRESS может включать до двух полей, первое из которых содержит шестнадцатиоктетный адрес IPv6, а второе — однооктетный размер префикса, как определено в [ADDRIPV6]. Запрашиваемый адрес остается корректным в течение всего срока действия IKE SA (или ее наследников после смены ключей). Этот вопрос более подробно рассмотрен в параграфе 3.15.3.

INTERNAL_IP4_NETMASK

Маска внутренней сети. В запросах и откликах допускается только одна маска (например, 255.255.255.0) и она должна использоваться только с атрибутом INTERNAL_IP4_ADDRESS. Атрибут INTERNAL_IP4_NETMASK в CFG_REPLY означает то же самое, что атрибут INTERNAL_IP4_SUBNET, содержащий ту же информацию (передавать трафик для этих адресов через меня), но подразумевает границу сети. Например, клиент может использовать свой собственный адрес и маску при расчете широковещательного адреса для канала. Пустой атрибут INTERNAL_IP4_NETMASK может включаться в CFG_REQUEST для запроса информации (хотя шлюз может передать информацию даже без запроса). Непустые значения этого атрибута в CFG_REQUEST не имеют смысла и их включение недопустимо.

INTERNAL_IP4_DNS, INTERNAL_IP6_DNS

Указывает адрес сервера DNS в сети. Запрашивать можно множество серверов DNS. Ответчик может вернуть адреса множества серверов или не вернуть ни одного.

INTERNAL_IP4_NBNS

Указывает адрес сервера сервера имен NetBios (WINS) в сети. Запрашивать можно множество серверов NBNS. Ответчик может вернуть адреса множества серверов или не вернуть ни одного.

INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP

Рекомендует хосту передавать внутренние запросы DHCP по адресу, указанному в этом атрибуте. Запрашивать можно множество серверов DHCP. Ответчик может вернуть адреса множества серверов или не вернуть ни одного.

APPLICATION_VERSION

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

INTERNAL_IP4_SUBNET

Защищаемые данным краевым устройством подсети. Атрибут может содержать до двух полей, первое из которых задает адрес IP, а второе — маску. Можно запрашивать множество подсетей. Ответчик может вернуть множество подсетей или не вернуть ни одной. Дополнительное рассмотрение этого вопроса приведено в параграфе 3.15.2.

SUPPORTED_ATTRIBUTES

При использовании в запросе этот атрибут должен иметь нулевой размер и указывает ответчику запрос на возврат списка всех поддерживаемых тем атрибутов. В откликах этот атрибут содержит набор 2-октетных идентификаторов атрибутов. Размер атрибута, разделенный на 2, будет указывать число поддерживаемых атрибутов в отклике.

INTERNAL_IP6_SUBNET

Защищаемые данным краевым устройством подсети. Атрибут может содержать до двух полей, первое из которых задает 16-октетный адрес IPv6, а второе — маску. Можно запрашивать множество подсетей. Ответчик может вернуть множество подсетей или не вернуть ни одной. Дополнительное рассмотрение этого вопроса приведено в параграфе 3.15.2.

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

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

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

3.15.2. Смысл атрибутов INTERNAL_IP4_SUBNET и INTERNAL_IP6_SUBNET

Атрибуты INTERNAL_IP4/6_SUBNET млгут указывать дополнительные подсети, для которых может потребоваться одна или множество отдельных связей SA, доступных через шлюз, анонсируемый этими атрибутами. Атрибуты INTERNAL_IP4/6_SUBNET могут также выражать политику шлюза для трафика, который следует передавать через него — клиент может выбрать передачу другого трафика (входящего в TSr, но не в INTERNAL_IP4/6_SUBNET) через шлюз или напрямую адресату. Таким образом, трафик по адресам, указанным атрибутами INTERNAL_IP4/6_SUBNET, следует передавать через анонсируемые этими атрибутами шлюзы. Если нет Child SA, чьи селекторы трафика включают рассматриваемый адрес, требуется создание новых связей SA.

Например, если имеются две подсети 198.51.100.0/26 и 192.0.2.0/24, а запрос клиента включает

   CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS()
   TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

приемлемый отклик может иметь вид (TSr и INTERNAL_IP4_SUBNET содержат одинаковую информацию)

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), (0, 0-65535, 192.0.2.0-192.0.2.255))

В таких случаях INTERNAL_IP4_SUBNET реально не содержит какой-либо полезной информации.

Другой возможный отклик имеет вид

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

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

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

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

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

   CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS()
   TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

отклик шлюза может иметь вид

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Поскольку смысл атрибутов INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET в сообщениях CFG_REQUEST не ясен, их невозможно надежно применять в CFG_REQUEST.

3.15.3. Элемент Configuration для IPv6

Элементы Configuration для IPv6, основанные на соответствующих элементах для IPv4, не вполне соответствуют «обычному стилю» IPv6. В частности, не используется автонастройка IPv6 без учета состояний, сообщения с анонсами маршрутизаторов и обнаружение соседей. Отметим наличие дополнительного документа, посвященного конфигурации IPv6 в IKEv2 [IPV6CONFIG]. В настоящее время это экспериментальный документ, но есть надежда по результатам экспериментов сделать его стандартом.

Клиенту можно выделить адрес IPv6, используя атрибут INTERNAL_IP6_ADDRESS элемента Configuration. Минимальный обмен при этом может иметь вид

   CP(CFG_REQUEST) =
     INTERNAL_IP6_ADDRESS()
     INTERNAL_IP6_DNS()
   TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
   CP(CFG_REPLY) =
     INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
     INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
   TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

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

Атрибут INTERNAL_IP6_ADDRESS содержит также поле размера префикса. При использовании в CFG_REPLY это поле соответствует атрибуту INTERNAL_IP4_NETMASK для случая IPv4.

Хотя описанная модель настройки адресов IPv6 достаточно проста, ей присущи некоторые ограничения. Туннели IPsec, настроенные с использованием IKEv2 не являются полнофункциональными «интерфейсами» в понимании архитектуры адресации IPv6 [ADDRIPV6]. В частности, у него может не быть локального для канала адреса (link-local) и это может осложнять использование протоколов, предполагающих его наличие (например, [MLDV2]).

3.15.4. Отказы при выделении адресов

Если ответчик сталкивается с ошибкой при попытке выделить инициатору адрес IP в процессе обработки элемента Configuration, он отвечает уведомлением INTERNAL_ADDRESS_FAILURE. Связь IKE SA все равно создается, даже если упомянутый отказ не позволяет организовать начальную Child SA. Если ошибка возникает в обмене IKE_AUTH, связи Child SA не будут организованы. Однако имеются и более сложные ситуации.

Если ответчик совсем не поддерживает элементы Configuration, он может просто игнорировать их. Реализации такого типа никогда не передают уведомления INTERNAL_ADDRESS_FAILURE. Если инициатору требуется выделение адреса IP, он будет трактовать отклик CFG_REPLY, как ошибку.

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

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

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

3.16. Элемент EAP

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       EAP Message                             ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 24/ Формат EAP

Элемент Extensible Authentication Protocol18 (EAP) позволяет выполнять аутентификацию IKE_SA с использованием протокола, определенного в RFC 3748 [EAP] и его последующих расширений. При использовании EAP требуется выбрать подходящий метод. Определено множество таких методов, описывающих использование протокола с разными механизмами аутентификации. Типы методов EAP перечислены в [EAP-IANA]. Здесь включено краткое описание формата EAP для ясности.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Code      ! Identifier    !           Length              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Type      ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 25. Формат сообщения EAP

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

Code (1 октет)

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

Identifier (1 октет)

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

Length (2 октета, целое число без знака)

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

Type (1 октет)

Присутствует только для элементов с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а присутствие полей Type и Type_Data недопустимо. В запросах поле Type указывает запрашиваемые данные. В откликах в поле Type должно быть значение Nak или данные запрошенного типа. Поскольку протокол IKE передает индикацию отождествления инициатора в первом сообщении обмена IKE_AUTH, ответчику не следует передавать запросов EAP Identity (тип 1). Однако инициатор может отвечать на такие запросы при их получении.

Type_Data (переменный размер)

Зависит от типа запроса и связанного с ним отклика. Описание методов EAP приведено в документе [EAP].

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

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

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

  • возможность согласования SA через NAT и туннелирования полученной ESP SA с использованием UDP;

  • возможность запрашивать (и отдавать по запросу) временный адрес IP на удаленной стороне туннеля;

  • возможность поддерживать EAP-аутентификацию;

  • возможность поддерживать окна размером более 1;

  • возможность организации множества SA (ESP и/или AH) в одной IKE SA;

  • возможность замены ключей SA.

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

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

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

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

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

  • аутентификации с общим ключом, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN или ID_RFC822_ADDR;

  • аутентификации ответчика с использованием сертификатов PKIX, а инициатора — с использованием общего ключа.

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

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

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

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

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

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

Предполагается, что все показатели Diffie-Hellman удаляются из памяти после использования.

Обмены IKE_SA_INIT и IKE_AUTH происходят до того, как аутентифицируется инициатор. В результате этого от реализаций данного протокола требуется полная устойчивость к развертыванию в любой незащищенной сети. Уязвимости реализаций, особенно для DoS-атак, могут быть использованы неуполномоченными партнерами. Эта проблема вызывает особое беспокойство с учетом неограниченного числа сообщений при аутентификации EAP.

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

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

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

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

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

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

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

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

Контроль доступа имеет важное значение для безопасности протокола. Например, доверенные привязки, используемые для идентификации партнеров IKE, следует, по возможности, отделять от привязок, используемых для идентификации общедоступных web-серверов. Протокол IKE обеспечивает значительную свободу при выборе политики безопасности в части идентификации доверенных партнеров и их свидетельств (credentials), а также связей между ними и наличие политики безопасности с явными определениями в этой части весьма важно для реализации системы защиты.

5.1. Полномочия для селекторов трафика

IKEv2 основывается на данных PAD23 при определении типов Child SA, которые разрешено создавать партнеру. Этот процесс описан в параграфе 4.4.3 [IPSECARCH]. Когда партнер запрашивает создание Child SA с некими селекторами трафика, PAD должна содержать запись Child SA Authorization Data (данные о полномочиях Child SA) связывающую отождествление партнера, аутентифицированное IKEv2, и адреса, разрешенные для селекторов трафика.

Например, PAD может содержать запись, разрешающую партнеру с отождествлением sgw23.example.com создавать связи Child SA для адресов 192.0.2.0/24, которая означает, что данный защитный шлюз является приемлемым «представителем» для этих адресов. Для прямого взаимодействия между хостами IPsec требует наличия аналогичной записи. Например, fooserver4.example.com с 198.51.100.66/32 будет говорить о том, что указанное отождествление является приемлемым «владельцем» или «представителем» для данного адреса.

Как отмечено в [IPSECARCH], «Требуется вносить некоторые ограничения на создание дочерних SA, чтобы обезопасить идентифицированного партнера от обманных ID, связанных с другими легитимными партнерами.24» В приведенном выше примере корректная конфигурация PAD препятствует sgw23 в создании связей Child SA с адресом 198.51.100.66, а fooserver4 — в создании Child SA с адресами 192.0.2.0/24.

Важно отметить, сто простая передача пакетов IKEv2, использующих некий конкретный адрес, не подразумевает разрешения на создание связей Child SA с этим адресом в селекторах трафика. Например, даже если sgw23 сможет подменить свой адрес IP на 198.51.100.66, он не сможет создать связей Child SA, соответствующих селекторам трафика fooserver4.

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

Отмечено, что в некоторых средах корректная настройка конфигурации PAD может оказаться сложной. Например, если IPsec используется между парой хостов с динамическими адресами DHCP, очень сложно обеспечить указание в PAD корректного «владельца» для таких адресов IP. Это потребует защищенного механизма передачи сведений о выделении адресов от сервера DHCP и связывания этих хостов с отождествлениями, аутентифицированными с помощью IKEv2.

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

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

[IKEV2] определяет множество типов и значений полей. Агентство IANA уже внесло эти типы и значения в реестры [IKEV2IANA], поэтому они не указываются здесь.

Два элемента были удалены из таблицы IKEv2 Configuration Payload Attribute Types — INTERNAL_IP6_NBNS и INTERNAL_ADDRESS_EXPIRY.

Добавлены два элемента в реестр IKEv2 NOTIFY MESSAGES — ERROR TYPES, определенные в этом документе и отсутствовавшие в [IKEV2]:

   43   TEMPORARY_FAILURE
   44   CHILD_SA_NOT_FOUND

Агентство IANA изменило в таблицу IKEv2 Payload Types строку

   46        Encrypted                        E          [IKEV2]

на

   46        Encrypted and Authenticated      SK    [This document]

Агентство IANA заменило все ссылки на RFC 4306 ссылками на этот документ.

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

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

Ниже приведена копия раздела благодарностей из первой спецификации IKEv2.

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

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

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

[ADDGROUP] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

[ADDRIPV6] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[AEAD] Black, D. and D. McGrew, «Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol», RFC 5282, August 2008.

[AESCMACPRF128] Song, J., Poovendran, R., Lee, J., and T. Iwata, «The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 4615, August 2006.

[AESXCBCPRF128] Hoffman, P., «The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 4434, February 2006.

[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, «Extensible Authentication Protocol (EAP)», RFC 3748, June 2004.

[ECN] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[ESPCBC] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[IKEV2IANA] «Internet Key Exchange Version 2 (IKEv2) Parameters», <http://www.iana.org>.

[IPSECARCH] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[MUSTSHOULD] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[PKCS1] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, February 2003.

[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC4307] Schiller, J., «Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)», RFC 4307, December 2005.

[UDPENCAPS] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, «UDP Encapsulation of IPsec ESP Packets», RFC 3948, January 2005.

[URLS] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

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

[AH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[ARCHGUIDEPHIL] Bush, R. and D. Meyer, «Some Internet Architectural Guidelines and Philosophy», RFC 3439, December 2002.

[ARCHPRINC] Carpenter, B., «Architectural Principles of the Internet», RFC 1958, June 1996.

[Clarif] Eronen, P. and P. Hoffman, «IKEv2 Clarifications and Implementation Guidelines», RFC 4718, October 2006.

[DES] American National Standards Institute, «American National Standard for Information Systems-Data Link Encryption», ANSI X3.106, 1983.

[DH] Diffie, W. and M. Hellman, «New Directions in Cryptography», IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977.

[DIFFSERVARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[DIFFSERVFIELD] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[DIFFTUNNEL] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[DOI] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 240725, November 1998.

[DOSUDPPROT] C. Kaufman, R. Perlman, and B. Sommerfeld, «DoS protection for UDP-based protocols», ACM Conference on Computer and Communications Security, October 2003.

[DSS] National Institute of Standards and Technology, U.S. Department of Commerce, «Digital Signature Standard», Draft FIPS 186-3, June 2008.

[EAI] Abel, Y., «Internationalized Email Headers», RFC 5335, September 2008.

[EAP-IANA] «Extensible Authentication Protocol (EAP) Registry: Method Types», <http://www.iana.org>.

[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, «Man-in-the-Middle in Tunneled Authentication Protocols», November 2002, <http://eprint.iacr.org/2002/163>.

[ESP] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[EXCHANGEANALYSIS] R. Perlman and C. Kaufman, «Analysis of the IPsec key exchange Standard», WET-ICE Security Conference, MIT, 2001, <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.

[H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, «Experiences with Host-to-Host IPsec», 13th International Workshop on Security Protocols, Cambridge, UK, April 2005.

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[IDEA] X. Lai, «On the Design and Security of Block Ciphers», ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

[IDNA] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[IKEV1] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 240926, November 1998.

[IKEV2] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[IP] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, «IP Payload Compression Protocol (IPComp)», RFC 3173, September 2001.

[IPSECARCH-OLD] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240127, November 1998.

[IPV6CONFIG] Eronen, P., Laganier, J., and C. Madson, «IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)», RFC 5739, February 2010.

[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 24081, November 1998.

[MAILFORMAT] Resnick, P., Ed., «Internet Message Format», RFC 5322, October 2008.

[MD5] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[MIPV6] Johnson, D., Perkins, C., and J. Arkko, «Mobility Support in IPv6», RFC 3775, June 2004.

[MLDV2] Vida, R. and L. Costa, «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», RFC 3810, June 2004.

[MOBIKE] Eronen, P., «IKEv2 Mobility and Multihoming Protocol (MOBIKE)», RFC 4555, June 2006.

[MODES] National Institute of Standards and Technology, U.S. Department of Commerce, «Recommendation for Block Cipher Modes of Operation», SP 800-38A, 2001.

[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, «The Network Access Identifier», RFC 4282, December 2005.

[NATREQ] Aboba, B. and W. Dixon, «IPsec-Network Address Translation (NAT) Compatibility Requirements», RFC 3715, March 2004.

[OAKLEY] Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, November 1998.

[PFKEY] McDonald, D., Metz, C., and B. Phan, «PF_KEY Key Management API, Version 2», RFC 2367, July 1998.

[PHOTURIS] Karn, P. and W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, March 1999.

[RANDOMNESS] Eastlake, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[REAUTH] Nir, Y., «Repeated Authentication in Internet Key Exchange (IKEv2) Protocol», RFC 4478, April 2006.

[REUSE] Menezes, A. and B. Ustaoglu, «On Reusing Ephemeral Keys In Diffie-Hellman Key Agreement Protocols», December 2008, <http://www.cacr.math.uwaterloo.ca/techreports/2008/cacr2008-24.pdf>.

[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, «IKEv2 Extensions to Support Robust Header Compression over IPsec», RFC 5857, May 2010.

[RSA] R. Rivest, A. Shamir, and L. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», February 1978.

[SHA] National Institute of Standards and Technology, U.S. Department of Commerce, «Secure Hash Standard», FIPS 180-3, October 2008.

[SIGMA] H. Krawczyk, «SIGMA: the `SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols», Advances in Cryptography — CRYPTO 2003 Proceedings LNCS 2729, 2003, <http://www.informatik.uni-trier.de/~ley/db/conf/crypto/crypto2003.html>.

[SKEME] H. Krawczyk, «SKEME: A Versatile Secure Key Exchange Mechanism for Internet», IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security , 1996.

[TRANSPARENCY] Carpenter, B., «Internet Transparency», RFC 2775, February 2000.

Приложение A. Обзор отличий от IKEv1

Цели пересмотра IKE перечислены ниже

  1. Определение протокола IKE в едином документе, замена RFC 2407, 2408, 2409 и включение последующих изменений в части добавления работы через NAT, расширяемой аутентификации (EAP) и получения удаленных адресов.

  2. Упрощение IKE за счет замены 8 разных начальных обменов одним обменом из 4 сообщений (с изменением механизмов аутентификации, воздействующих только на один элемент AUTH вместо реструктуризации всего обмена), см. [EXCHANGEANALYSIS].

  3. Удаление полей области интерпретации (DOI), ситуации (SIT) и Labeled Domain Identifier, а также битов Commit и Authentication.

  4. Снижение задержки IKE в общем случае за счет сведения изначального обмена к 2 периодам кругового обхода (4 сообщения) и разрешения организации CHILD_SA в этом обмене.

  5. Замена криптографического синтаксиса для защиты самих сообщений IKE синтаксисом, близким к ESP, для упрощения реализации и анализа защиты.

  6. Снижение числа возможных ошибочных состояний за счет обеспечения в протоколе гарантий доставки (все сообщения подтверждаются) и упорядочивания, позволивших сократить обмены CREATE_CHILD_SA с 3 сообщений до 2.

  7. Повышение отказоустойчивости за счет предоставления ответчику возможности не выполнять существенной обработки до подтверждения инициатором возможности приема сообщений по заявленному им адресу IP.

  8. Устранение криптографических недостатков типа проблем с симметрией в хэш-значениях, используемых для аутентификации (отмечена Tero Kivinen).

  9. Задание селекторов трафика в специальных элементах данных вместо перегрузки информацией элементов ID и более гибкое указание селекторов трафика.

  10. Описание поведения при возникновении некоторых ошибок или получении непонятных данных для упрощения совместимости с будущими версиями без ухудшения совместимости с предшествующими.

  11. Упрощение и прояснение поддержки общих состояний при возникновении ошибок в сети или DoS-атаках.

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

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

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

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

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

B.1. Группа 1 — 768-битовая MODP

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

Простое число имеет значение: 2768 — 2704 — 1 + 264 * { [2638 pi] + 149686 }, а его шестнадцатеричная форма имеет вид

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

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

B.2. Группа 2 — 1024-битовая MODP

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

Простое число имеет значение 21024 — 2960 — 1 + 264 * { [2894 pi] + 129093 }, а его шестнадцатеричная форма имеет вид

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

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

Приложение C. Обмены и данные

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

Элементы данных Vendor ID (V) могут включаться почти во все сообщения. Ниже они представлены в наиболее логичных местах.

C.1. Обмен IKE_SA_INIT

   Запрос              --> [N(COOKIE)],
                           SA, KE, Ni,
                           [N(NAT_DETECTION_SOURCE_IP)+,
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [V+][N+]

   обычный отклик      <-- SA, KE, Nr,
   (без cookie)            [N(NAT_DETECTION_SOURCE_IP),
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [V+][N+]

   отклик с cookie     <-- N(COOKIE), [V+][N+]

   нужна другая группа <-- N(INVALID_KE_PAYLOAD),
   группа Diffie-Hellman   [V+][N+]

C.2. Обмен IKE_AUTH без EAP

   Запрос              --> IDi, [CERT+],
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           AUTH,
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   отклик              <-- IDr, [CERT+],
                           AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

   ошибка при         <--  IDr, [CERT+],
   создании Child SA       AUTH, N(error), [V+][N+]

C.3. Обмен IKE_AUTH с EAP

   Первый запрос       --> IDi,
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   первый отклик       <-- IDr, [CERT+], AUTH, EAP, [V+][N+]

                     / --> EAP
   повтор 1..N раз  |
                     \ <-- EAP

   послед. запрос      --> AUTH

   послед. отклик      <-- AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

C.4. Обмен CREATE_CHILD_SA для создания или смены ключей Child SA

   Запрос              --> [N(REKEY_SA)],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Ni, [KEi], TSi, TSr
                           [V+][N+]

   обычный             <-- [CP(CFG_REPLY)],
   отклик                  [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Nr, [KEr], TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)]
                           [V+][N+]

   ошибка              <-- N(error)

   нужна другая группа <-- N(INVALID_KE_PAYLOAD),
   Diffie-Hellman          [V+][N+]

C.5. Обмен CREATE_CHILD_SA для смены ключей IKE SA

   Запрос              --> SA, Ni, Kei [V+][N+]

   отклик              <-- SA, Nr, Ker [V+][N+]

C.6. Обмен INFORMATIONAL

   Запрос              --> [N+], [D+], [CP(CFG_REQUEST)]

   отклик              <-- [N+], [D+], [CP(CFG_REPLY)]

Адреса авторов

Charlie Kaufman

Microsoft

1 Microsoft Way

Redmond, WA 98052

US

Phone: 1-425-707-3335

EMail: charliek@microsoft.com

Paul Hoffman

VPN Consortium

127 Segre Place

Santa Cruz, CA 95060

US

Phone: 1-831-426-9827

EMail: paul.hoffman@vpnc.org

Yoav Nir

Check Point Software Technologies Ltd.

5 Hasolelim St.

Tel Aviv 67897

Israel

EMail: ynir@checkpoint.com

Pasi Eronen

Independent

EMail: pe@iki.fi

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Cipher Block Chaining — цепочка шифрованных блоков.

2Integrity Check Value.

3Extended Sequence Number.

4Extended Sequence Number.

5В https://www.rfc-editor.org/errata_search.php?eid=2192 была отмечена логическая ошибка в этом предложении RFC 4306, однако текст был сохранен в этой и последующей версии документа — RFC 7296. Прим. перев.

6Type/Length/Value — тип-размер-значение.

7 Type/Value — тип-значение.

8Элемент данных Key Exchange. Прим. перев.

9Modular exponentiation group.

10Peer Authorization Database — база данных для аутентификации партнеров.

11Distinguished Encoding Rules.

12Network Access Identifier — идентификатор доступа в сеть.

13В оригинале ошибочно сказано IKE_INIT_SA, см. https://www.rfc-editor.org/errata_search.php?eid=4387. Прим. перев.

14Certification Authority — агентство по сертификации, удостоверяющий центр.

15В оригинале это предложение содержит ошибку. См. http://www.rfc-editor.org/errata_search.php?eid=3036. Прим. перев.

16Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации хоста.

17Type-length-value — тип, размер, значение.

18Расширяемый протокол аутентификации.

19Public Key Infrastructure.

20См. RFC 1918. Прим. перев.

21Man-in-the-middle — атака на основе перехвата пакетов в пути с участием человека для анализа и изменения их. Прим. перев.

22Single-signon facility.

23Peer Authorization Database — база данных о полномочиях партнеров.

24Цитата приведена по опубликованному на сайте переводу. Прим. перев.

25Этот документ заменен RFC 4306, который позднее заменен данным документом, а затем RFC 7296. Прим. перев.

26Этот документ заменен RFC 4306, который позднее заменен данным документом, а затем RFC 7296. Прим. перев.

27Этот документ заменен RFC 4301. Прим. перев.

 

Please follow and like us:
error
Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий