Таблица N 6

2.8. формат элемента данных Запрос сертификата приведен на рисунке 9.

Рисунок 9

Примечание:

поле "Тип сертификата" (1 октет) должно содержать информацию о способе кодирования сертификата;

поле "Удостоверяющий центр" должно иметь переменный размер.

2.9. элемент данных Идентификация должен содержать данные, используемые для идентификации.

Формат элемента данных Идентификация приведен на рисунке 10.

Рисунок 10

Примечание:

поле "Метод идентификации" (1 октет) должно содержать информацию о используемом методе идентификации и принимать значения:

RSA цифровая подпись (1) (должно рассчитываться с использованием приватного ключа RSA и хэш-значения PKCS N 1 с заполнением);

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

DSS (Digital Signature Standard) цифровая подпись (3) (должно рассчитываться с использованием закрытого ключа DSS и хэш-значения алгоритма криптографического хеширования SHA-1 (Secure Hash Algorithm);

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

поле "Идентификационные данные" должно иметь переменный размер;

2.10. элемент данных Случайное число должно иметь одно поле переменного размера, содержащее созданное передающей стороной случайное значение, размер элемента должен находиться в диапазоне (16 - 256) октетов включительно, повторное использование значения Случайного числа не допускается;

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

Формат элемента данных Уведомление приведен на рисунке 11.

Рисунок 11

Примечание:

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

поле "Размер SPI" (Security Parameter Index) (1 октет) должно указывать размер SPI в октетах;

поле "Тип уведомления" (2 октета) должен задавать тип уведомления;

поле "SPI" должно иметь переменный размер и содержать идентификатор параметров защиты;

поле "Данные уведомления" должно иметь переменный размер и содержать дополнительную информацию к типу уведомления;

3.1. формат элемента данных Удаление приведен на рисунке 12.

Элемент данных Удаление должен содержать определяемый протоколом идентификатор защищенной связи.

Рисунок 12

Примечание:

поле "Идентификатор протокола" (1 октет) должно быть равно "1" для IKE_SA, з "2" - для AH, "3" - для ESP;

поле "Размер SPI" (1 октет) должно содержать размер SPI указанного протокола (в октетах);

поле "Количество SPI" (2 октета) должно содержать количество SPI в элементе данных Удаление;

поле "Индекс параметров безопасности" (SPI) должно иметь переменный размер и идентифицировать удаляемое защищенное соединение;

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

3.3. элементы данных Селектор трафика - Инициатор, Селектор трафика - Ответчик.

Формат элемента Селектор трафика приведен на рисунке 13.

Рисунок 13

Примечание:

поле "Количество селекторов трафика" должно иметь размер 1 октет;

поле "Резерв" (3 октета) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Селектор трафика" должно иметь переменный размер и содержать один или несколько отдельных указателей типа трафика;

3.4. элемент данных Кодирование (Encrypted - далее E), должен содержать другие элементы в зашифрованном виде. При наличии в сообщении элемента Кодирование он должен быть последним в сообщении.

Формат элемента данных Кодирование приведен на рисунке 14.

Рисунок 14

Примечание:

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

поле "Данные IKE" должно быть переменной длины, содержать шифрованные элементы IKE и шифроваться с использованием согласованного алгоритма;

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

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

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

3.5. элемент данных Конфигурация (CP) должен использоваться для обмена конфигурационными параметрами между партнерами IKE.

Требования к формату элемента данных Конфигурация приведены на рисунке 15.

Рисунок 15

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

поле "Тип обмена" (1 октет) должно содержать информацию о типе обмена данными Конфигурации (REQUEST-1, REPLY-2, SET-3, ACK-4);

поле "Резерв" (3 октета) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Атрибуты конфигурации" должно иметь переменный размер и содержать атрибуты конфигурации в формате "тип-размер-значение".

Элемент данных Конфигурация может содержать несколько атрибутов или не содержит атрибуты;

3.6. элемент данных Расширяемая идентификация (EAP) должен позволять выполнять идентификацию IKE_SA с использованием протокола EAP. Формат элемента данных EAP приведен на рисунке 16.

Рисунок 16

Примечание:

поле "Код" (1 октет) должно показывать тип сообщение и должно быть равно "1" при запросе (Request), "2" при отклике (Response), "3" при успешном завершении (Success) или "4" при отказе (Failure);

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

поле "Длина" (2 октета) должно содержать информацию о размере сообщения EAP и быть в 4 раза меньше значения поля "Размер текущего элемента (Payload Lenqth) базового заголовка";

поле "Тип" (1 октет) должно быть только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должно составлять четыре октета, а поля "Тип" и "Данные" должны отсутствовать. В запросах (1) поле "Тип" должно указывать запрашиваемые данные, а в откликах (2) поле "Тип" должно быть пустым или соответствовать типу запрошенных данных.

Значения поля "Тип":

1 - тождественность;

2 - уведомление;

3 - только отклики;

4 - MD5 - вызов;

5 - однократный пароль;

6 - маркерная карта базового типа.

Поле "Данные" должно быть переменного размера и зависеть от типа запроса и связанного с ним отклика.