RFC 4306 Часть 2

Please enter banners and links.

Часть 1

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

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

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

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

Сообщения 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 — старший байт сначала).

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

• Initiator’s SPI (8 октетов) – значение, выбранное инициатором для уникальной аутентификации защищенной связи IKE. Нулевое значение недопустимо.

• Responder’s SPI (8 октетов) – значение, выбранное ответчиком для уникальной аутентификации защищенной связи IKE. Это значение должно быть нулевым в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений нулевое значение недопустимо.

• Next Payload (1 октет) – показывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.

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

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

• Тип обмена	Значение
  Резерв	0-33
  IKE_SA_INIT	34
  IKE_AUTH	35
  CREATE_CHILD_SA	36
  INFORMATIONAL	37
  Резерв IANA	38-239
  Резерв для частного использования	240-255

  Exchange Type (1 октет) – показывает тип обмена, который будет использоваться. Тип ограничивает набор элементов данных в каждом сообщении и порядок сообщений в обмене. Типы показаны в таблице справа.

• Flags (1 октет) – показывает специфические опции, установленные для сообщения. Наличие опции указывается установкой соответствующего флага. Биты флагов начинаются с младшего, т. е. Бит 0 является младшим битом октета Flags. В приведенном ниже описании термин «установлен» означает значение бита 1, а термин «сброшен» – значение 0.

• X(резерв) (биты 0-2) – эти биты должны сбрасываться при передаче и игнорироваться на приеме.

• I(nitiator) (бит 3 поля Flags) – этот бит должен устанавливаться в сообщениях, передаваемых исходным инициатором IKE_SA, и должен сбрасываться в сообщениях, передаваемых исходным ответчиком. Этот бит позволяет получателю определить, какие восемь октетов SPI были созданы получателем.

• V(ersion) (бит 4 поля Flags) – этот флаг показывает, что передающий узел способен поддерживать большее значение старшей части номера версии, нежели указано в поле Major Version. Реализации IKEv2 должны сбрасывать этот бит при передаче и игнорировать его во входящих сообщениях³⁷.

• R(esponse) (бит 5 поля Flags) – этот бит показывает, что данное сообщение является откликом на сообщение с таким же идентификатором. Этот бит должен сбрасываться во всех запросах и устанавливаться во всех откликах. Для конечной точки IKE недопустима генерация откликов на сообщения, помеченные, как отклик.

• X(резерв) (биты 6-7) – эти биты должны сбрасываться при передаче и игнорироваться на приеме.

• Message ID (4 октета) – идентификатор сообщения служит для управления повторной передачей потерянных пакетов и связывания запросов с откликами. Это поле важно для безопасности протокола, поскольку оно используется для предотвращения атак с повторным использованием перехваченных пакетов (replay-атаки). См. также параграфы 2.1 и 2.2.

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Формат базового заголовка данных

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

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

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

  Значения Payload Type показаны в таблице справа.

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

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

• RESERVED (7 битов) – должно иметь нулевое значение при передаче и игнорироваться на приеме.

• Payload Length (2 октета) – размер текущего элемента данных в октетах с учетом базового заголовка.

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

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

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

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

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

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

Если имеется множество преобразований одного типа (одно значение Transform Type), они должны комбинироваться в одно предложение с помощью операции ИЛИ⁴¹. При наличии множества преобразований различных типов, группы объединяются операцией И. Например, чтобы предложить 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!   Резерв    !         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) or 2 !    Резерв     !         Proposal Length       !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ! Proposal #    !  Protocol ID  !    SPI Size   !# of Transforms!
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                        SPI (переменный)                       ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !                                                               !
  ~                        <Transforms>                           ~
  !                                                               !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

• Резерв (1 октет) – должно устанавливаться в 0 при передаче и игнорироваться на приеме.

• Proposal Length (2 октета) – размер данного предложения, включая все входящие в него преобразования и атрибуты.

• Proposal # (1 октет) – номер предложения. Первое предложение в элементе SA должно иметь номер 1, а номера последующих должны совпадать с номером предшественника (И – пересечение двух предложений) или быть на 1 больше (ИЛИ – объединение двух предложений). Когда предложение принимается, все номера предложений в элементе SA должны совпадать и соответствовать номеру переданного предложения, которое было принято.

• Протокол	Protocol ID
  Резерв	0
  IKE	1
  AH	2
  ESP	4
  Резерв IANA	4 – 200
  Частное применение	201 – 255

  Protocol ID (1 октет) – задает идентификатор протокола IPsec для текущего согласования. Определенные значения идентификаторов показаны в таблице справа.

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

• # of Transforms (1 октет) – показывает число преобразований в данном предложении.

• SPI (переменный размер) – SPI передающей стороны. Даже если значение SPI Size не кратно 4, для элементов данных не используется заполнения. При нулевом значении SPI Size это поле не включается в элемент 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) or 3 !    Резерв     !        Transform Length       !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !Transform Type !    Резерв     !          Transform ID         !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !                                                               !
  ~                      Transform Attributes                     ~
  !                                                               !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

  0 (последнее) или 3 (не последнее) (1 октет) – показывает, является ли это преобразование последним в предложении. Синтаксис унаследован от ISAKMP, не это поле не является необходимым, поскольку последнее предложение можно идентифицировать по размеру Proposal⁴³. Значение 2 соответствует типу элемента Transform в IKEv1 и первые четыре октета структуры организованы так, чтобы они выглядели, подобно заголовку Payload.

• Резерв (1 октет) – должно устанавливаться в 0 при передаче и игнорироваться на приеме.

• Transform Length – размер субструктуры Transform (в октетах) с учетом заголовка и атрибутов.

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

• Transform ID (2 октета) – указывает конкретный экземпляр предлагаемого преобразования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очевидно, что 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 Type (2 октета) – уникальный идентификатор для каждого типа атрибутов (см. ниже).

  Старший бит этого поля является флагом формата атрибута (AF⁴⁷), показывающим использование полного (TLV⁴⁸) или сокращенного (TV⁴⁹) формата. При AF = 0, для атрибута используется формат TLV, при AF = 1 – TV.

• Attribute Length (2 октета) – размер поля Attribute Value в октетах. При AF = 1, размер Attribute Value всегда составляет 2 октета и поле Attribute Length отсутствует.

• Attribute Value (переменный размер) – значение атрибута, связанное с Attribute Type. Если AF = 0, размер этого поля указывается в поле Attribute Length. При AF = 1 размер поля Attribute Value всегда равен 2 октетам.

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

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

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

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

Key Length – размер ключа

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

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

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

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!          DH Group #           !            Резерв             !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Key Exchange Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

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

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   ID Type     !                  Резерв                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Identification Data                         ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Формат идентификации

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

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

• ID Type (1 октет) – задает тип используемой идентификации.

• Резерв – должно обнуляться при передаче и игнорироваться на приеме.

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

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

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

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

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                       Certificate Data                        ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12: Формат сертификата

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

Кодирование сертификата	Значение
Резерв	0
Сертификат X.509 с PKCS #7	1
Сертификат PGP	2
Подписанный ключ DNS	3
Сертификат X.509 – подпись	4
Маркер Kerberos	6
CRL	7
ARL	8
Сертификат SPKI	9
СертификатX.509 – атрибут	10
Неразобранный ключ RSA	11
Хэш и URL сертификата X.509	12
Хэш и URL связки (bundle) X.509	13
Резерв IANA	14 – 200
Для частного применения	201 – 255

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

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

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

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

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

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

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

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

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

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

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

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

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

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

CertificateBundle ::= SEQUENCE OF CertificateOrCRL

END

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                    Certification Authority                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Формат запроса сертификата

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

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

• Certificate Encoding (1 октет) – задает тип представления запрашиваемого сертификата. Возможные значения перечислены в параграфе 3.6.

• Certification Authority (переменный размер) – указывает подходящий удостоверяющий центр для запрашиваемого типа сертификата.

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

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

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

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

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

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

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

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

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

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth Method   !                 Резерв                        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                      Authentication Data                      ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат аутентификации

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

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

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

• Auth Method (1 октет) – задает используемый метод аутентификации и может принимать значения:

RSA Digital Signature (1) – рассчитывается, как указано в параграфе 2.15, с использованием приватного ключа RSA и хэш-значения PKCS#1 с заполнением (см. [RSA] и [PKCS1]).

Shared Key Message Integrity Code (2) – рассчитывается, как указано в параграфе 2.15, с использованием разделяемого ключа, связанного с объектом из элемента ID, и согласованной функции prf.

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

Значение 0 и 4-200 зарезервированы IANA. Значения 201-255 выделены для частных приложений.

• Authentication Data (переменный размер) – см. параграф 2.15.

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

3.9. Элемент Nonce

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                            Nonce Data                         ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

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

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

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Protocol ID  !   SPI Size    !      Notify Message Type      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                Security Parameter Index (SPI)                 ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Notification Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. Формат уведомления

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

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

• Protocol ID (1 октет) – если уведомление относится к существующей SA, это поле указывает тип данной SA. Для уведомлений IKE_SA это поле должно иметь значение 1. Для уведомлений, касающихся IPsec SA, это поле должно содержать значение 2 для протокола AH или 3 для ESP. Для уведомлений, не относящихся к существующим SA, это поле должно сбрасываться в 0 при передаче и игнорироваться на приеме. Все остальные значения зарезервированы IANA для использования в будущем.

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

• Notify Message Type (2 октета) – задает тип уведомления.

• SPI (переменный размер) – список параметров защиты.

• Notification Data (переменный размер) — информация или данные об ошибке, передаваемые в дополнение к Notify Message Type. Значения этого поля зависят от типа и описаны нижеэ

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

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

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

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

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

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

Сообщения NOTIFY – состояния	Значение	Описание
INITIAL_CONTACT	16384	Данное уведомление заявляет, что данная IKE_SA является единственной активной IKE_SA между аутентифицированными сторонами. Уведомление может передаваться при создании IKE_SA после аварии и получатель может использовать эту информацию для удаления всех прочих IKE_SA с тем же аутентифицированным партнером без ожидания. Недопустима передача таких уведомлений со стороны реплицируемых объектов (например, представление мобильного пользователя, которому разрешено подключаться к корпоративному шлюзу с двух удаленных систем одновременно).
SET_WINDOW_SIZE	16385	Это уведомление заявляет, что передающая сторона способна сохранять состояние для множества незавершенных обменов, что позволяет получателю отправлять множество запросов без ожидания ответа на первый запрос. Данные, связанные с SET_WINDOW_SIZE, должны иметь размер 4 октета (сетевой порядок байтов) и содержать представление числа сообщений, которые могут сохраняться. До завершения начального обмена размер окна всегда равен 1.
ADDITIONAL_TS_POSSIBLE	16386	Это уведомление заявляет, что передающая сторона сужает предложенный набор селекторов трафика, и говорит о возможности использования других селекторов через отдельные SA (см. параграф 2.9). С этим типом уведомлений не связано данных. Уведомление может передаваться только в качестве дополнительного элемента сообщения, включающего подходящие TS.
IPCOMP_SUPPORTED	16387	Это уведомление можно включать только в сообщения, содержащие элемент SA для согласования CHILD_SA, где указано желание использовать IPComp в данной SA. Связанные с уведомлением данные включают двухоктетное значение IPComp CPI, за которым следует однооктетный идентификатор преобразования (возможно, с атрибутами, размер и формат которых определяются идентификатором преобразования). Сообщение, предлагающее SA, может включать множество уведомлений IPCOMP_SUPPORTED для индикации поддержки разных алгоритмов. Сообщение, принимающее SA, может содержать не более одного такого уведомления. Идентификаторы преобразований показаны ниже. Имя Номер Определение Резерв 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051 Значения 5-240 зарезервированы IANA, значения 241-255 предназначены для часто применения по согласования сторон.
NAT_DETECTION_SOURCE_IP	16388	Это уведомление используется получателем для проверки нахождения его отправителя за устройством NAT. Данные, связанные с этим уведомлением, представляют собой подпись SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда пакет был послан. Возможно наличие множества уведомлений этого типа в сообщении, если отправитель не знает, какое из соединений с сетью будет использоваться для передачи пакета. Получатель уведомления может сравнить полученное значение с хэшем SPI, адреса IP и порта получателя – при несовпадении следует включить режим работы через NAT (см. параграф 2.23). Если работа через NAT не поддерживается, попытка соединения может быть отвергнута.

Сообщения NOTIFY – состояния	Значение	Описание
NAT_DETECTION_DESTINATION_IP	16389	Это уведомление используется его получателем для проверки своего нахождения за устройством NAT. Данные, связанные с этим уведомлением, представляют собой подпись SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда пакет был послан. Получатель уведомления может сравнить полученное значение с хэшем SPI, адреса IP и порта получателя – при несовпадении следует включить режим работы через NAT (см. параграф 2.23). Несоответствие говорит о том, что данная сторона расположена за устройством NAT и ей следует начать передачу пакетов keepalive, как определено в [Hutt05]. Если работа через NAT не поддерживается, попытка соединения может быть отвергнута.
USE_TRANSPORT_MODE	16391	Это уведомление может быть включено в запрос, содержащий также элемент SA для создания CHILD_SA. Уведомление запрашивает для CHILD_SA использование транспортного режима, вместо туннельного55. Если запрос принимается, отклик на него должен включать уведомление USE_TRANSPORT_MODE. Если ответчик отвергает запрос, CHILD_SA будет создаваться для туннельного режима. Если это неприемлемо для инициатора, он должен удалить SA. Примечание. Для всех SA с туннельным режимом, создаваемых IKEv2, должна выполняться декапсуляция, измененная в соответствии с [RFC4301].
HTTP_CERT_LOOKUP_SUPPORTED	16392	Это уведомление может включаться в любое сообщение, которое содержит элемент CERTREQ, и показывает, что отправитель может находить сертификаты по URL на основе HTTP (и, следовательно, будет предпочитать получение сертификатов в таком формате).
REKEY_SA	16393	Это уведомление должно включаться в обмен CREATE_CHILD_SA, если задачей обмена является замена существующей SA (ESP или AH). Поле SPI аутентифицирует SA, для которой будут меняться ключи. Уведомление не включает данных/
ESP_TFC_PADDING_NOT_SUPPORTED	16394	Это уведомление заявляет, что передающая точка не будет принимать пакеты с заполнением TFC56.
NON_FIRST_FRAGMENTS_ALSO	16395	Служит для контроля фрагментации (см. [RFC4301]).
Резерв IANA – типы состояний	16396 – 40959
Для частного применения – типы состояний	40960 – 65535

3.11. Удаление

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID   !   SPI Size    !           # of SPIs           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~               Security Parameter Index(es) (SPI)              ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

• Protocol ID (1 октет) – 1 для IKE_SA, 2 для AH, 3 для ESP.

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

• # of SPIs (2 октета) – число SPI в данном элементе Delete. Размер каждого значения SPI определяется полем SPI Size.

• Security Parameter Index(es) (переменный размер) – идентифицирует удаляемую защищенную связь (связи). Размер этого поля определяется значением поля SPI Size и числом полей SPI.

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

3.12. Vendor ID

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

Элемент Vendor ID может анонсировать возможность отправителя работать с некими расширениями протокола⁵⁷. Возможна передача множества элементов Vendor ID. Реализации не обязана передавать элементы 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!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                        Vendor ID (VID)                        ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Элемент Vendor ID может передаваться в любом сообщении. Получение понятного элемента Vendor ID дает реализации возможность использовать значения, выделенные в этом документе для частного применения – частные элементы данных, типы обмена, уведомления и т. п. Непонятные элементы Vendor ID должны игнорироваться. Разработчики проектов протоколов (Internet-Draft), желающие расширить данный протокол, должны определить элемент Vendor ID для анонсирования возможности реализовать расширение из Internet-Draft. Предполагается, что получившие признание документы Internet-Draft, будут стандартизоваться с выделением значений из резервных блоков IANA и использование данного 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!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of TSs !                   Резерв                      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       <Traffic Selectors>                     ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 19: Формат элемента данных Traffic Selector

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

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

• Number of TSs (1 октет) – число представляемых селекторов трафика.

• Резерв – это поле должно иметь нулевое значение при передаче и игнорироваться на приеме.

• Traffic Selectors (переменный размер) — один или множество индивидуальных селекторов трафика.

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

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

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

• TS Type (1 октет) – задает тип селектора трафика.

• IP protocol ID (1 октет) – значение, показывающее идентификатор связанного протокола IP ID (например, UDP/TCP/ICMP). Нулевое значение говорит о неприменимости идентификатора протокола к данному селектору трафика (SA может передавать все протоколы).

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

• Start Port (2 октета) – задает минимальный номер порта, допустимый для данного селектора. Для протоколов, где порт не определен или разрешается использовать любые порты, это поле должно иметь значение 0. Для протокола ICMP два однооктетных поля Type и Code трактуются, как 16-битовое целое число (Type занимает старшие 8 битов, а Code — младшие), задающее номер порта для целей фильтрации по данному полю.

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

  Рисунок 20: Селектор трафика

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

  End Port (2 октета) – – задает максимальный номер порта, допустимый для данного селектора. Для протоколов, где порт не определен или разрешается использовать любые порты, это поле должно иметь значение 65535. Для протокола ICMP два однооктетных поля Type и Code трактуются, как 16-битовое целое число (Type занимает старшие 8 битов, а Code — младшие), задающее номер порта для целей фильтрации по данному полю.

• Starting Address – Наименьший адрес, включенный в данный селектор (размер определяется полем TS type).

• Ending Address – Наибольший адрес, включенный в данный селектор (размер определяется полем TS type).

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

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

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

3.14. Элемент Encrypted

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

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

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

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

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

  Рисунок 21: Формат зашифрованных данных

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

• Payload Length – размер элемента с учетом заголовка IV, Encrypted IKE Payloads, Padding, Pad Length и Integrity Checksum Data.

• Initialization Vector – случайное значение, размер которого совпадает с размером блока используемого алгоритма шифрования. Получатели должны воспринимать любые значения. Отправителям следует следует генерировать псевдослучайное значение независимо для каждого сообщения или использовать для выбора значений шифрованный блок предыдущего сообщения. Для отправителя недопустимо использовать одно значение для всех сообщений, последовательности с малым расстоянием Хэмминга⁵⁸ (например, порядковые номера) или шифрованные данные из предыдущего принятого сообщения.

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

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

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

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

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

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

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

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

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

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

                     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        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   CFG Type    !                     Резерв                    !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Configuration Attributes                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 22. Формат конфигурационных данных

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

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

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

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

• CFG Type	Значение
  Резерв	0
  CFG_REQUEST	1
  CFG_REPLY	2
  CFG_SET	3
  CFG_ACK	4

  CFG Type (1 октет) – тип обмена, представленного атрибутами элемента Configuration.

  Определенные значения типов показаны в таблице справа. Значения 5-127 зарезервированы IANA, значения 128-255 выделены для частного применения по согласованию сторон.

• Резерв (3 октета) – должно устанавливаться в 0 при передаче и игнорироваться на приеме.

• Configuration Attributes (переменные размер) – атрибуты конфигурации в формате «тип-размер-значение», описанные ниже. В элементе Configuration может содержаться множество (в том числе, пустое) атрибутов.

3.15.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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !R|         Attribute Type      !            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                             Value                             ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Рисунок 23. Формат атрибута конфигурации

  Резерв (1 бит) – должен устанавливаться в 0 при передаче и игнорироваться на приеме.

• Attribute Type (15 битов) – уникальный идентификатор для каждого типа атрибутов конфигурации.

• Length (2 октета) – размер поля Value в октетах.

• Value (0 или более октетов) – поле переменного размера, содержащее значение атрибута конфигурации.

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

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

  Запрашиваемый адрес остается корректным до окончания срока его действия, заданного атрибутом INTERNAL_ADDRESS EXPIRY, или до завершения всех IKE_SA между партнерами.

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

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

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

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

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

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

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

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

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

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

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

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

3.16. Элемент EAP

                     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 Protocol⁶² (EAP) позволяет выполнять аутентификацию IKE_SA с использованием протокола, определенного в RFC 3748 [EAP] и его последующих расширений. Полный набор приемлемых значений выходит за пределы этой спецификации, однако краткий перечень значений из RFC 3748 включен в документ для использования в наиболее общих случаях.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     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 должны отсутствовать. В запросах (1) поле Type показывает запрашиваемые данные, а в откликах (2) поле Type должно быть пустым или соответствовать типу запрошенных данных В RFC 3748 определены следующие типы:

1 Identity – тождественность.

2 Notification – уведомление.

3 Nak (только отклики)

4 MD5-Challenge

5 One-Time Password (OTP) – однократный пароль.

6 Generic Token Card – маркерная карта базового типа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IKEv2 Exchange Types (параграф 3.1)

IKEv2 Payload Types (параграф 3.2)

IKEv2 Transform Types⁶⁶ (параграф 3.3.2)

IKEv2 Transform Attribute Types (параграф 3.3.2)

IKEv2 Encryption Transform IDs (параграф 3.3.2)

IKEv2 Pseudo-random Function Transform IDs (параграф 3.3.2)

IKEv2 Integrity Algorithm Transform IDs (параграф 3.3.2)

IKEv2 Diffie-Hellman Transform IDs (параграф 3.3.2)

IKEv2 Identification Payload ID Types (параграф 3.5)

IKEv2 Certificate Encodings (параграф 3.6)

IKEv2 Authentication Method (параграф 3.8)

IKEv2 Notify Message Types (параграф 3.10.1)

IKEv2 Notification IPCOMP Transform IDs (параграф 3.10.1)

IKEv2 Security Protocol Identifiers (параграф 3.3.1)

IKEv2 Traffic Selector Types (параграф 3.13.1)

IKEv2 Configuration Payload CFG Types (параграф 3.15)

IKEv2 Configuration Payload Attribute Types (параграф 3.15.1)

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

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

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

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

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

[ADDGROUP] Kivinen, T. 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, “Internet Protocol Version 6 (IPv6) Addressing Architecture”, RFC 3513⁶⁷, April 2003.

[Bra97] Bradner, S., “Key Words for use in RFCs to indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

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

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

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

[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

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

[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 3280, April 2002.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, December 2005.

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

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

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

[DHCP] Droms, R., “Dynamic Host Configuration Protocol”, RFC 2131, March 1997.

[DSS] NIST, “Digital Signature Standard”, FIPS 186⁶⁹, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994.

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

[HC98] Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE)”, RFC 2409⁷⁰, November 1998.

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

[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, “IP Payload Compression Protocol (IPComp)”, RFC 3173, September 2001.

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

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

[LDAP] Wahl, M., Howes, T., and S Kille, “Lightweight Directory Access Protocol (v3)”, RFC 2251, December 1997.

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

[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, “Internet Security Association and Key Management Protocol (ISAKMP)”, RFC 2408⁷¹, November 1998.

[Orm96] 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.

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

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

[Pip98] Piper, D., “The Internet IP Security Domain Of Interpretation for ISAKMP”, RFC 2407⁷², November 1998.

[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, June 2000.

[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, June 2005.

[RFC1958] Carpenter, B., “Architectural Principles of the Internet”, RFC 1958, June 1996.

[RFC2401] Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401⁷³, November 1998.

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

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Service”, RFC 2475, December 1998.

[RFC2522] Karn, P. and W. Simpson, “Photuris: Session-Key Management Protocol”, RFC 2522, March 1999.

[RFC2775] Carpenter, B., “Internet Transparency”, RFC 2775, February 2000.

[RFC2983] Black, D., “Differentiated Services and Tunnels”, RFC 2983, October 2000.

[RFC3439] Bush, R. and D. Meyer, “Some Internet Architectural Guidelines and Philosophy”, RFC 3439, December 2002.

[RFC3715] Aboba, B. and W. Dixon, “IPsec-Network Address Translation (NAT) Compatibility Requirements”, RFC 3715, March 2004.

[RFC4302] Kent, S., “IP Authentication Header”, RFC 4302, December 2005.

[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, December 2005.

[RSA] Rivest, R., Shamir, A., and Adleman, L., “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems”, Communications of the ACM⁷⁴, v. 21, n. 2, February 1978.

[SHA] NIST, “Secure Hash Standard”, FIPS 180-1⁷⁵, National Institute of Standards and Technology, U.S. Department of Commerce, May 1994.

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

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

[X.501] ITU-T Recommendation X.501: Information Technology — Open Systems Interconnection – The Directory: Models, 1993.

[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology – Open Systems Interconnection – The Directory: Authentication Framework, June 1997.

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

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

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

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

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 из Университета штата Аризона. Свойства этих простых чисел описаны в работе [Orm96].

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

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

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

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

Простое число имеет значение 2⁷⁶⁸ – 2⁷⁰⁴ – 1 + 2⁶⁴ * { [2⁶³⁸ 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.

Простое число имеет значение 2¹⁰²⁴ – 2⁹⁶⁰ – 1 + 2⁶⁴ * { [2⁸⁹⁴ pi] + 129093 }, а его шестнадцатеричная форма имеет вид

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

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

Адрес автора

Charlie Kaufman

Microsoft Corporation

1 Microsoft Way

Redmond, WA 98052

Phone: 1-425-707-3335

EMail: [email protected]

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

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

[email protected]

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [email protected].

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.