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

RFC 4306, Страница 35 из 62

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

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

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

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

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

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

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

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

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

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

Страница 35 из 62

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