Безопасность на сетевом уровне: IP SEC

Разбить на страницы

Показывать лекцию целиком

Цели и содержание

Эта лекция имеет несколько целей:

Определить архитектуру IPSec.

Обсудить приложение IPSec в транспортном и туннельном режимах.

Обсудить, как IPSec может использоваться, чтобы обеспечить только установление подлинности.

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

Определить службы обеспечения безопасности (SA - Security Association) и объяснить, как они реализованы для IPSec.

Определить протокол обмена ключами (IKE - Internet Key Exchange) и объяснить, как он используется в IPSec.

Безопасный IP (IPSec) - совокупность протоколов, разработанных Группой Инженерной Поддержки сети Интернет (IETF Internet Engineering Task Force), чтобы обеспечить безопасность передачи пакетов на сетевом уровне. Сетевой уровень в Интернете упоминается часто как Интернет-протокол - Internet Protocol (IP). Протокол IPSec помогает создавать заверенные и конфиденциальные пакеты для уровня IP, как это показано на рис. 8.1.

(рис 8.1) Набор протоколов TCP/IP и IPSec

IPSec может быть полезен в нескольких областях. Во-первых, он может увеличить безопасность программ "клиент-сервер", таких как электронная почта, которая использует свои собственные протоколы безопасности. Во-вторых, он может увеличить безопасность программ "клиент-сервер", которые применяют службы безопасности на транспортном уровне, - например, HTTP. Он может обеспечить безопасность программ "клиент-сервер", которые не пользуются службами безопасности транспортного уровня. Он может обеспечить безопасность для программ установления связи "от-узла-к-узлу", таких как маршрутизация.

8.1. Два режима

IPSec работает в двух различных режимах - транспортном и туннельном.

Транспортный режим

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

(рис 8.2) Транспортный режим IPSec

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

IPSec в транспортном режиме не защищает заголовок IP, а только информацию, прибывающую от транспортного уровня.

Транспортный режим обычно применяется, когда мы нуждаемся в защите данных на участке "хост-хост" ("из конца в конец"). Передающий хост использует IPSec, чтобы подтвердить подлинность и/или зашифровать полезную нагрузку, освобожденную от информации транспортного уровня. Приемный хост использует IPSec, чтобы проверить установление подлинности и/или расшифровать пакет IP и доставить его транспортному уровню. рис. 8.3 иллюстрирует эту концепцию.

(рис 8.3) Действия транспортного режима

Туннельный режим

В туннельном режиме IPSec защищает весь пакет IP. Он обрабатывает пакет IP (включая заголовок), применяя методы безопасности IPSec к полному пакету, и затем добавляет новый заголовок IP, как это показано на рис. 8.4.

(рис 8.4) Туннельный режим IPSec

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

(рис 8.5) Действия туннельного режима

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

IPSec в туннельном режиме защищает первоначальный заголовок IP.

Сравнение

В транспортном режиме уровень IPSec располагается между транспортным уровнем и сетевым уровнем. В туннельном режиме поток проходит от сетевого уровня до уровня IPSec, а затем снова возвращается назад к сетевому уровню. рис. 8.6 сравнивает эти два режима.

(рис 8.6) Сравнение транспортного и туннельного режимов

8.2. Два протокола безопасности

IPSec определяет два протокола: протокол "Заголовок аутентификации (AH - Authentication Header)" и протокол " Полезная нагрузка со встроенной защитой (ESP - Encapsulating Security Payload)". Их цель - обеспечить установление подлинности и/или шифрование для пакетов на уровне IP.

Заголовок аутентификации (AH)

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

Затем AH вставляют на соответствующее место, в зависимости от режима ( транспортный или туннельный ). рис. 8.7 показывает поля и позиции заголовка аутентификации в транспортном режиме.

(рис 8.7) Протокол "Заголовок аутентификации (AH)"

Когда дейтаграмма IP переносит заголовок аутентификации, первоначальное значение в поле протокола заголовка IP устанавливается в значение 51. Поле в заголовке аутентификации (следующее поле заголовка) содержит первоначальное значение поля протокола (тип полезной нагрузки, которую несет дейтаграмма IP). Добавление заголовка аутентификации проводится следующими шагами:

Заголовок аутентификации добавляется к полезной нагрузке с полем аутентификации данных, установленным на 0.

Заполнение добавляется, если нужно сделать полную длину сообщения для конкретного алгоритма хэширования.

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

Данные аутентификации вставляются в заголовок аутентификации.

Заголовок IP добавляется после изменения значения поля протокола на 51.

Краткое описание каждого поля дано ниже.

Следующий заголовок. Поле "следующий заголовок" имеет 8 битов и определяет тип полезной нагрузки, которую несет IP-дейтаграмма (такие как TCP, UDP, ICMP или OSPF). Поле выполняет ту же самую функцию, что и поле протокола в заголовке IP перед инкапсуляцией. Другими словами, процесс копирует значение поля протокола в дейтаграмме IP в поле "следующий заголовок". Значение поля протокола в новой дейтаграмме IP теперь установлено на 51, чтобы показать, что пакет переносит заголовок аутентификации.

Длина полезной нагрузки. Однобайтовое поле, указывающее количество байт в предыдущем поле длины полезной нагрузки AH в 32-битовых (четырехбайтных) блоках, не считая первые два блока.

Индекс параметра обеспечения безопасности. Это поле на 32 бита (SPI - Security Parameter Index) играет роль идентификатора виртуального канала и для всех пакетов, посылаемых в течение соединения и называемых Службы обеспечения безопасности трафика (Security Association). Они будут рассмотрены позже.

Порядковый номер. Порядковый номер на 32 бита обеспечивает информацию о порядке последовательности дейтаграмм. Порядковые номера предотвращают повторение. Обратите внимание, что номер не повторяется при повторной передаче пакета. Порядковый номер не циклический и не повторяет цикла после того, как он достигает 2³². Для обновления номера должно быть установлено новое соединение.

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

Протокол AH обеспечивает установление подлинности источника и целостность данных, но не конфиденциальность.

Полезная нагрузка со встроенной защитой (ESP)

Протокол AH не обеспечивает секретность, а только установление подлинности источника и целостность данных. Для IPSec был определен альтернативный протокол Полезная нагрузка со встроенной защитой (ESP-Encapsulating Security Payload) , который гарантирует установление подлинности источника, целостность и секретность. ESP добавляет заголовок и конечную метку. Обратите внимание, что данные аутентификации ESP добавляются в конце пакета - это делает их вычисление более простыми. рис. 8.8 показывает размещение заголовка ESP и конечной метки.

(рис 8.8) Протокол "Полезная нагрузка со встроенной защитой" (ESP)

Когда дейтаграмма IP переносит заголовок ESP и конечную метку, значение поля протокола в заголовке IP равно 50. Поле в конечной метке ESP (поле следующего заголовка) содержит первоначальное значение поля протокола (тип полезной нагрузки, которую несет дейтаграмма IP, такой как TCP или UDP). Процедура ESP выполняется следующими шагами:

Конечная метка ESP добавляется к полезной нагрузке.

Полезная нагрузка и конечная метка зашифровываются.

Добавляется заголовок ESP.

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

Данные аутентификации добавляются в конце конечной метки ESP.

Заголовок IP добавляется после изменения значения протокола на 50.

Поля заголовка и конечной метки следующие:

Индекс параметра обеспечения безопасности. Поле индекса параметра обеспечения безопасности на 32 бита совпадет с тем, которое определено для протокола AH.

Порядковый номер. Поле порядкового номера на 32 бита совпадет с тем, которое определено для протокола AH.

Заполнение - это поле переменной длины (от 0 до 255 байтов), состоящее из нулей и служащее заполнением.

Длина заполнения. Поле длины заполнения на 8 битов определяет число байтов заполнения между 0 и 255; максимальное значение используется редко.

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

Данные аутентификации. Наконец, поле данных аутентификации - результат применения схем аутентификации к частям дейтаграммы. Обратите внимание на отличие между данными аутентификации в AH и ESP. В AH часть заголовка IP включена в вычисление данных аутентификации, а в ESP - нет.

ESP обеспечивает установление подлинности источника, целостность данных и секретность.

IPv4 и IPv6

IPSec поддерживает и IPv4, и IPv6. В IPv6, однако, AH и ESP - часть расширения заголовка.

Сравнение AH и ESP

Протокол ESP был разработан после того, как протокол AH был уже в использовании. ESP умеет то, что AH делает только с дополнительными функциональными возможностями (секретность). Вопрос: почему же тогда мы по-прежнему нуждаемся в AH? Этот вопрос не имеет ответа. Однако реализация AH включена в несколько коммерческих продуктов, то есть AH останется частью Интернет, пока эти продукты не будут постепенно выведены из употребления.

Услуги, обеспечиваемые IPSec

Эти два протокола, AH и ESP, могут обеспечить несколько услуг безопасности для пакетов на сетевом уровне. табл. 8.1 показывает список услуг, доступных для каждого из этих протоколов.

Услуги IPSec
Услуги	AH	ESP
Управление доступом Access control	ДА	ДА
Установление подлинности сообщения (целостность сообщения) Message authentication (message integrity)	ДА	ДА
Установление подлинности объекта (установление подлинности источника данных) Entity authentication (data source authentication)	ДА	ДА
Конфиденциальность Confidentiality	НЕТ	ДА
Защита от атаки воспроизведения Replay attack protection	ДА	ДА

Управление доступом

IPSec обеспечивает управление доступом, косвенно использующее базу данных услуг обеспечения безопасности трафика (SAD - Security Association Database), как мы это увидим в следующей секции. Когда пакет достигает пункта назначения и атрибуты службы обеспечения безопасности трафика, установленные для этого пакета, отсутствуют, пакет бракуется.

Целостность сообщения

Целостность сообщения сохраняется и в AH, и в ESP. Дайджест данных создается и посылается передатчиком, который будет проверен приемником.

Установление подлинности объекта

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

Конфиденциальность

Шифрование сообщения обеспечивает конфиденциальность в ESP. AH однако, конфиденциальность не гарантирует. Если конфиденциальность необходима, нужно использовать ESP вместо AH.

Защита от атаки воспроизведения

В обоих протоколах предотвращается атака воспроизведения путем использования порядковых номеров и скользящего окна приемника. Каждый IPSec -заголовок содержит уникальный порядковый номер - когда установлены Службы обеспечения безопасности трафика. Числа начинаются от 0 и увеличиваются, пока не достигают значения 2³² - 1 (размер поля порядкового номера - 32 бита). Когда порядковый номер достигает максимума, он сбрасывается в 0, и в то же самое время удаляются старые Службы обеспечения безопасности трафика (см. следующую секцию) и устанавливаются новые. Чтобы предотвращать пакеты дубликата обработки, IPSec использует фиксированный размер окна приемника. Размер окна приемника задан по умолчанию значением 64. рис. 8.9 показывает окно ответа. Окно имеет фиксированный размер W. Затемненные пакеты показывают, что полученные пакеты были проверены и аутентифицированы.

(рис 8.9) Окно ответа

Когда пакет достигает приемника, в зависимости от значения порядкового номера может произойти одно из трех событий:

Порядковый номер пакета - меньше чем N. Тогда пакет размещается налево от окна и будет забракован. Он либо является дубликатом, либо время его прибытия истекло.

Порядковый номер пакета - между N и (N + W - 1) включительно. Тогда пакет размещается в окне. В этом случае, если пакет новый (неотмеченный) и он содержит аутентификационный тест, порядковый номер отмечается, и пакет принимается. Иначе (если пакет не новый) он бракуется.

Порядковый номер пакета больше, чем (N + W - 1). Тогда пакет размещается справа от окна. В этом случае, если пакет аутентифицирован, соответствующий порядковый номер отмечается и окно перемещается (скользит) вправо и занимает отмеченный порядковый номер. Иначе (если не аутентифицирован) пакет бракуется. Обратите внимание, что это может случиться, если пакет прибывает с порядковым номером, намного большим, чем (N + W) (очень далеким от правого края окна). В этом случае скольжение вправо может привести к попаданию немаркированных порядковых номеров налево от окна. Эти пакеты, когда они прибывают, никогда не будут приниматься; их время истекло. Например (на рис. 8.9), если пакет прибывает с порядковым номером (N + W + 3), окно перемещается и левый край начнется с (N + 3). Это означает, что порядковый номер (N + 2) теперь вне окна. Если пакет прибывает с этим порядковым номером, он будет забракован.

8.3. Услуги обеспечения безопасности трафика

Услуги обеспечения безопасности трафика - очень важный аспект IPSec. IPSec требует между двумя хостами логических отношений, называемых услуги обеспечения безопасности трафика (SA - Security Association). В этом разделе вначале рассмотрим идею, а затем покажем, как она используется в IPSec.

Идея услуг обеспечения безопасности трафика

Услуга обеспечения безопасности трафика(SA -Security Association) - соглашение между двумя сторонами для создания безопасного канала между ними. Предположим, что Алиса должна однонаправленно связаться с Бобом. Если Алиса и Боб интересуются только аспектом конфиденциальности и безопасности, они могут получить общедоступный ключ засекречивания для связи между собой. Мы можем сказать, что это есть две услуги обеспечения безопасности трафика ( SA 's) между Алисой и Бобом: одна SA - исходящая и одна SA - входящая. Каждый из них хранит значение ключа и имя алгоритма шифрования/дешифрования. Алиса использует алгоритм и ключ, чтобы зашифровать сообщение Бобу; Боб использует алгоритм и ключ, когда он должен расшифровать сообщение, полученное от Алисы. рис. 8.10 показывает эти простые услуги SA.

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

(рис 8.10) Простые услуги обеспечения безопасности (SA)

База данных услуг обеспечения безопасности

Услуги обеспечения безопасности могут быть организованы очень сложно. Это особенно справедливо, если Алиса хочет передавать сообщения многим людям, а Боб должен получать сообщения от многих людей. Кроме того, каждая сторона должна иметь и входящие, и исходящие SA 's, чтобы позволить осуществлять двунаправленную связь. Другими словами, мы нуждаемся во множестве SA 's, которые могут быть собраны в базу данных. Эта база данных называется Базой данных Услуг обеспечения безопасности (SAD - Security Association Database). Базу данных можно представлять как двумерную таблицу с каждой строкой, определяющей единственную SA. Обычно есть две SAD 's: одна - входящая и одна - исходящая. рис. 8.11 показывает концепцию исходящих и входящих SAD 's для одного объекта.

(рис 8.11) База данных услуг обеспечения безопасности

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

Индекс параметра обеспечения безопасности. Индекс параметра обеспечения безопасности (SPI) - число на 32 бита, которое определяет SA в пункте назначения. Как мы увидим позже, SPI определен в течение SA -переговоров. Тот же самый SPI включен во все IPSec -пакеты, принадлежащие одному и тому же входящему SA.

Адрес пункта назначения. Второй индекс - адрес пункта назначения хоста. Мы должны помнить, что хост в Интернете обычно имеет один индивидуальный адрес пункта назначения, но он может иметь несколько адресов групповой рассылки. IPSec требует, чтобы SA был уникален для каждого адреса пункта назначения.

Протокол. IPSec имеет два различных протокола безопасности: AH и ESP. Чтобы отделить параметры и информацию, используемую для каждого протокола, IPSec требует, чтобы пункт назначения определял различный SA для каждого протокола.

Входы для каждой строки называются параметрами SA. Типичные параметры показаны в табл. 8.2.

Типичные параметры SA

Счетчик порядкового номера Sequence Number Counter	Это значение на 32 бита, которое используется, чтобы генерировать порядковые номера для AH - или ESP -заголовка
Переполнение порядкового номера Sequence Number Overflow	Это флажок, который определяет варианты состояния в случае переполнения порядкового номера .
Окно антивоспроизведения Anti-Replay Window	Оно обнаруживает входящий воспроизведенный пакет AH или пакет ESP
Информация AH AH Information	Эта секция содержит информацию для протокола AH: Алгоритм аутентификации Ключи Время жизни ключа Другие связанные параметры
Информация ESP ESP Information	Эта секция содержит информацию для протокола ESP: Алгоритм шифрования Алгоритм аутентификации Ключи Время жизни ключа Вектор инициализации Другие связанные параметры
Время жизни SA Lifetime	Определяет время жизни для SA.
Режим IPSec IPSec Mode	Определяет режим, транспортный или туннельный
Путь MTU Path MTU	Определяет путь МАКСИМАЛЬНЫЙ ПЕРЕДАВАЕМЫЙ БЛОК (фрагментацию). This defines the path MTU (fragmentation).

8.4. Стратегия безопасности

Другой аспект импорта IPSec - Стратегия безопасности (SP - Security Policy), которая определяет тип безопасности, предоставляемой пакету, когда его нужно передать или когда его нужно принять. Перед тем как использовать SAD, рассмотренный в предыдущем разделе, хост должен определить заранее заданную стратегию обслуживания этого пакета.

База данных стратегии безопасности

Каждый хост, который использует IPSec -протокол, должен хранить Базу данных стратегии безопасности (SPD - Security Policy Database). При этом, как и раньше, необходимо иметь входящую SPD и исходящую SPD. К каждому входу в SPD можно обратиться, используя индекс из шести позиций: исходный адрес, адрес пункта назначения, название, протокола, исходный порт и порт пункта назначения, как показано на рис. 8.12.

(рис 8.12) База данных Стратегии Безопасности (SPD)

Источник и адреса пункта назначения могут быть индивидуальные, групповой рассылки или групповой символ (wildcard¹) - их имя обычно определяет в Интернете объект доменной системы имен (DNS). Протокол является или AH, или ESP. Источник и порты пункта назначения - адреса порта для процесса, функционирующего в хостах пункта назначения и источнике.

Исходящий SPD

Когда пакет нужно передать, то работают с исходящим SPD. рис. 8.13 показывает обработку пакета передатчиком.

Вход исходящего SPD состоит из шестизначного индекса; выход содержит один из трех результатов:

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

(рис 8.13) Исходящий процесс

Применить. В этом случае применяется работа с заголовком безопасности. При этом могут возникнуть две ситуации:

Если исходящую SA уже установили, возвращается тройной индекс SA, который выбирается соответствующей SA из исходящего SAD. Формируется AH или заголовок ESP ; шифрование, установление подлинности или оба этих действия применяются в соответствии с выбранной SA. Пакет передается.

Если исходящая SA еще не установлена, то вызывается протокол Интернет обмена ключами (IKE - Internet Key Exchange) (см. следующую секцию), чтобы создать исходящую и входящую SA для этого трафика. Исходящая SA добавляется источником к исходящей SAD ; входящая SA добавляется пунктом назначения к входящей SAD.

Входящий SPD

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

Вход к входящему SPD - шестикратный индекс; выход - один из трех результатов:

Сбросить. Это означает, что пакет, определенный стратегией, должен быть отброшен.

Обход. Это означает, что нет никакой стратегии для пакета с этим индексом стратегии; пакет обрабатывается, игнорируя информацию от AH или заголовок ESP. Пакет доставляют транспортному уровню.

Применить.В этом случае заголовок безопасности должен быть обработан. Здесь могут возникнуть две ситуации:

если входящая SA уже установлена, возвращается тройной индекс SA, который выбирается соответствующей SA из входящего SAD. Применяются дешифрование, установление подлинности или оба этих действия. Если пакет передает критерии безопасности, AH или заголовок ESP забракован, и пакет доставляют транспортному уровню;

если SA еще не установлена, то пакет должен быть забракован.

(рис 8.14) Входящий процесс

8.5. Протокол интернет-обмена ключами (IKE)

Протокол Интернет-обмена ключами (IKE - Internet Key Exchange) должен создавать и входящие, и исходящие услуги обеспечения безопасности. Как мы обсуждали в предыдущей секции, когда пакет IP должен быть передан между равными уровнями, тогда обращаются к базе данных стратегии безопасности (SPDB), чтобы видеть, есть ли SA для такого типа трафика. Если нет такой SA, вызывается IKE, чтобы установить ее.

Протокол Интернет-обмена ключами создает услуги обеспечения безопасности SA 's для протокола IPSec.

IKE - сложный протокол, основанный на трех других протоколах: OAKLEY, SKEME и ISAKMP, как показано на рис. 8.15.

(рис 8.15) Компоненты протокола управления ключами в Интернете

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

SKEME, разработанный Хьюго Кравчиком, является другим протоколом для смены ключей. Он использует шифрование открытым ключом для установления подлинности объекта в протоколе смены ключей. Мы коротко рассмотрим, как один из методов, используемых IKE, базируется на SKEME.

Internet-услуги обеспечения безопасности и протокол управления ключами (ISAKMP) являются протоколом, разработанным Агентством Национальной безопасности (NSA), который фактически осуществляет обмен сообщениями, определенными в IKE. Он определяет некоторые пакеты, протоколы и параметры, которые позволяют проводить обмен сообщениями IKE в стандартизированных, отформатированных сообщениях, чтобы создать SA 's. Мы обсудим ISAKMP в следующей секции как протокол, осуществляющий IKE.

В этой секции мы поговорим непосредственно об IKE как о механизме для создания услуг безопасности в SA 's в IPSec.

Улучшенный протокол управления ключами Диффи-Хеллмана

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

В лекции 5 мы обсудили метод Диффи-Хеллмана; концепция этого метода суммирована на рис. 8.16.

(рис 8.16) Обмен ключами по методу Диффи-Хеллмана

В первоначальном методе обмена ключей Диффи-Хеллмана, как показано в лекции 5 (разделе 5.3), две стороны создают симметричный ключ сеанса, чтобы обмениваться данными. При этом им не надо помнить или хранить ключ для будущего использования. Перед установлением симметричного ключа эти две стороны должны выбрать два числа: p и g. Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, - генератор в группе.

<Z*_p , x >. Алиса выбирает большое случайное число i и вычисляет KE-I = gⁱ mod p. Она передает KE-I Бобу. Боб выбирает другое большое случайное число r и вычисляет KE-R = gⁱ mod p. Он передает KE-I = gⁱ mod p Алисе. Напоминаем, что KE-I и KE-R, как полуключи метода Диффи-Хеллмана, сгенерированы для равных по уровню процессов. Они должны быть объединены вместе, чтобы создать полный ключ, K = g^ir mod p у. K - это симметричный ключ для сеанса.

Протокол Диффи-Хеллмана имеет некоторые слабости, которые должны быть устранены прежде, чем он станет приемлемым для обмена ключей в Интернет.

Засоряющая атака

Первая проблема с протоколом Диффи-Хеллмана - засоряющая атака или атака отказа в обслуживании. Злоумышленник может передать много полуключей ( g^x mod q ) сообщения Бобу, симулируя, что они из различных источников. Тогда Боб должен вычислить различные ответы ( g^y mod q ) и в то же самое время вычислить полный ключ ( g^y mod q ); это загрузит Боба настолько, что он может прекратить отвечать на любые другие сообщения. Он будет отказывать в обслуживании клиентам. Такое может случиться, потому что протокол Диффи-Хеллмана требует большого времени для вычислений.

Чтобы предотвратить атаку засорения, мы можем добавить к протоколу два дополнительных сообщения и вынудить эти две стороны передать cookies

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

(рис 8.17) Метод Диффи - Хеллмана с cookies

Инициатор передает собственное cookie; ответная сторона - свой cookie. Оба cookies повторяются в неизмененном виде в каждом последующем сообщении. Вычисления полуключей и ключа сеанса отложены до возвращения cookies. Если любой из процессов этого уровня - хакер, делающий попытку засоряющей атаки, cookies не возвращается; соответствующая сторона не тратит время и усилие на вычисление полуключа или ключа сеанса. Например, если инициатор - хакер, использующий фиктивный адрес IP, инициатор не получает второе сообщение и не может передать третье сообщение. Процесс прерывается.

, IKE использует cookies.

Атака воспроизведения

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

, IKE использует nonce.

Атака "посредника"

Третий и наиболее опасный вид атаки протокола Диффи-Хеллмана - атака "посредника", предварительно рассмотренная в лекции 5. Ева может войти в середину диалога и создать один ключ между Алисой и собой и другой ключ между Бобом и собой. Сорвать эту атаку не так просто, как первые две. Мы должны подтвердить аутентификацию каждой стороны.

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

Аутентификация обмена сообщений (целостность сообщения) и аутентификация сторон (аутентификация объекта) требует, чтобы каждая сторона доказала, что у нее есть требуемый код идентификации. Чтобы сделать это, каждый должен доказать, что он обладает секретностью.

Чтобы защититься против атаки "посредника", IKE требует, чтобы каждая сторона показала, что она обладает секретностью.

В IKE секретность может заключаться в одном из следующих сочетаний ключей:

а. предварительный открытый ключ засекречивания;

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

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

Фазы IKE

IKE создает SA 's для обмена сообщениями протокола, такого как IPSec. IKE, однако, должен обмениваться конфиденциальными и аутентифицированными сообщениями. Какие SA 's обеспечивает протокол IKE для себя? Можно догадаться, что он требует бесконечной цепочки SA 's: IKE должен создать SA 's для IPSec, протокол X должен создать SA 's для IKE, протокол Y должен создать SA 's для протокола X, и так далее. Для того чтобы решить эту дилемму и в то же время оставить IKE независимым от протокола IPSec, разработчики IKE разделили IKE на две фазы. В фазе I IKE создает SA 's для фазы II. В фазе II IKE создает SA 's для IPSec или некоторых других протоколов.

Фаза I является базовой; фаза II задана для протокола.

IKE разделен на две фазы: фаза I и фаза II. Фаза I создает SA 's для фазы II; фаза II создает SA 's для протокола обмена данными, например, такого как IPSec.

Однако остается вопрос: как защищена фаза 1? В следующей секции мы покажем, как фаза 1 использует SA, который сформирован постепенно. Более ранние сообщения заменяются в исходном тексте; более поздние сообщения заменяются созданными из ранних сообщений.

Фазы и режимы

Чтобы учесть разнообразие методов обмена, IKE определил для фаз режимы. В настоящее время есть два режима для фазы I: главный режим и энергичный режим. Единственный режим для фазы II - быстрый режим. рис. 8.18 показывает отношения между фазами и режимами.

(рис 8.18) Фазы IKE

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

(рис 8.19) Методы основного или энергичного режима

Фаза I: основной режим

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

В третьих и четвертых сообщениях инициатор и респондент обычно обмениваются своими полуключами ( gⁱ и g^r метода Диффи-Хеллмана) и их nonce (для защиты ответа). В некоторых методах обмениваются другой информацией, о которой мы поговорим позже. Обратите внимание, что полуключи и nonce не передаются с первыми двумя сообщениями, потому что две стороны должны сначала получить гарантию, что засоряющая атака невозможна.

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

SKYID = prf (предварительный совместный ключ, N-I | N-R)              (метод предварительного совместного ключа)
SKYID = prf(N-I | N-R, g^ir)                                              (метод открытого ключа)
SKYID = prf( (hash (N-I | N-R), Cookie -I | Cookie -R)                          (цифровая подпись)

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

SKYID_d = prf( (SKEYID, g^{i r}| Cookie -I | Cookie -R| 0)
SKYID_a = prf( (SKEYID, SKEYID_d | g^{i r}| Cookie -I | Cookie -R| 1)
SKYID_e = prf( (SKEYID, SKEYID_a | g^{i r}| Cookie -I | Cookie -R| 2)

SKEYID_d (derived - производный ключ) - ключ для создания других ключей. SKEYID_a - ключ аутентификации, и SKEYID_e применяется для ключа шифрования; обе эти секретности используются в течение фазы переговоров. Первый параметр ( SKEYID ) вычисляется для каждого метода обмена ключами отдельно. Второй параметр - конкатенация различных данных. Обратите внимание, ключ для prf - всегда SKEYID.

Эти две стороны также вычисляют два дайджеста хэширования, HASH-I и HASH-R, которые используются в главном режиме трех из этих четырех методов. Вычисления показаны ниже:

HASH-I = prf( (SKEYID, KE-I | KE-R | Cookie -I | Cookie -R |SA-I | ID-I)
HASH-R = prf( (SKEYID, KE-I | KE-R | Cookie -I | Cookie -R |SA-I | ID-R)

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

После вычисления ключей и хэширования каждая сторона передает хэш другой стороне, чтобы подтвердить свою подлинность. Инициатор передает HASH-I респонденту как доказательство, что она - Алиса. Только Алиса знает секретность аутентификации, и только она может вычислить HASH-I. Если HASH-I, вычисленный Бобом, соответствует HASH-I, посланному Алисой, она аутентифицирована. Тем же самым способом Боб может подтвердить свою подлинность Алисе, посылая HASH-R.

Обратите внимание, что здесь есть одна тонкость. Когда Боб вычисляет HASH I, он нуждается в ID Алисы, и наоборот. В некоторых методах ID передают с помощью предыдущих сообщений; в других - с хэшем либо с хэшем и с ID, зашифрованным SKEYID_e.

Метод предварительного совместного ключа

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

(рис 8.20) Главный режим метода с предварительным совместным ключом.

В первых двух сообщениях инициатор и респондент обмениваются cookies (в общем заголовке и параметрах SA ). В следующих двух сообщениях они обмениваются полуключами и nonces (см. лекцию 5). Теперь эти две стороны могут создать SKEYID и два ключевых хэша ( HASH-I и HASH-R ). В пятом и шестом сообщениях две стороны обмениваются созданными хэшами и их ID. Чтобы защищать ID и хэши, последние два сообщения зашифрованы с SKEYID_e.

Обратите внимание, что предварительный совместный ключ обеспечивает секретность между Алисой (инициатором) и Бобом (респондентом). Ева (злоумышленник) не имеет доступа к этому ключу. Ева не может создать SKEYID и поэтому не может создать ни HASH-I, ни HASH -R. Обратите внимание также, что обмен ID должен быть сделан в сообщениях 5 и 6, чтобы обеспечить вычисление хэша.

С этим методом есть одна проблема. Боб не может расшифровать сообщение, если он не знает предварительный совместный ключ, - то есть он должен знать, кто Алиса (знать ее ID ). Но ID Алисы зашифрован в сообщении 5. Разработчик этого метода утверждает, что ID в этом случае должен быть в адресе каждой стороны.

Это - не проблема, если Алиса находится в постоянном хосте (адрес IP установлен). Однако если Алиса двигается от одной сети к другой, это уже проблема.

Первоначальный метод открытого ключа

В первоначальном методе открытого ключа инициатор и респондент доказывают их подлинность, показывая, что они обладают секретным ключом, связанным с их объявленным открытым ключом. рис. 8.21 показывает обмен сообщениями при использовании метода первоначального открытого ключа.

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

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

(рис 8.21) Главный режим метода с первоначальным открытым ключом.

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

Пересмотренный метод открытого ключа

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

(рис 8.22) Главный режим метода с пересмотренным открытым ключом.

Обратите внимание, что два временных секретных ключа созданы из хэша nonce и cookies. Инициатор использует открытый ключ респондента, чтобы передать его nonce. Респондент дешифрирует nonce и вычисляет временный ключ инициатора, после чего могут быть расшифрованы полуключ, ID и дополнительный сертификат. Два временных ключа засекречивания, K-I и K-R, вычисляются следующим образом:

K-I = prf(N - I, Cookie-I)
K-R = prf(N - R, Cookie-R)

Метод цифровой подписи

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

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

(рис 8.23) Главный режим метода цифровой подписи

Фаза I: энергичный режим

Каждый энергичный режим - сжатая версия соответствующего главного режима. Вместо шести сообщений в обмене участвуют только три. Сообщения 1 и 3 объединены в одно - первое сообщение. Сообщения 2, 4 и 6 объединены во второе сообщение. Сообщение 5 передают как третье сообщение. Идея та же самая, что и в главном режиме.

Метод предварительного совместного ключа

Рис. 8.24 показывает метод предварительного совместного ключа в энергичном режиме. Обратите внимание, что после получения первого сообщения респондент может вычислить SKEYID и, следовательно, HASH-R. Но инициатор не может вычислить SKEYID, пока не получит второе сообщение. HASN-I в третьем сообщении может быть зашифровано.

(рис 8.24) Энергичный режим метода с предварительным совместным ключом

Метод первоначального открытого ключа

Рис. 8.25 показывает обмен сообщениями с использованием метода первоначального открытого ключа в энергичном режиме. Обратите внимание, что респондент может вычислить SKEYID и HASH-R после получения первого сообщения, но инициатор должен ждать, пока не получит второе сообщение.

(рис 8.25) Энергичный режим метода с первоначальным ключом

Пересмотренный метод открытого ключа

Рис. 8.26 показывает пересмотренный метод открытого ключа в агрессивном режиме. Идея - та же самая, что и в главном режиме, за исключением того, что некоторые сообщения объединены.

(рис 8.26) Энергичный режим метода с пересмотренным открытым ключом

Метод цифровой подписи

Рис. 8.27 показывает метод цифровой подписи в агрессивном режиме. Идея - та же самая, что и в главном режиме, за исключением того, что некоторые сообщения объединены.

(рис 8.27) Энергичный режим метода цифровой подписи

Фаза II: быстрый режим

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

Быстрый режим использует SA 's IKE, чтобы создать IPSec SA 's (или SA 's для любого другого протокола). рис. 8.28 показывает обмен сообщениями в ходе быстрого режима.

(рис 8.28) Быстрый режим

В фазе II любая сторона может быть инициатором: то есть инициатор фазы II может быть инициатором или респондентом фазы 1.

Инициатор передает первое сообщение, которое включает в себя ключевой HMAC HASH (будет рассмотрен позже), полный SA, созданный в фазе 1, новый nonce (N-I), дополнительный новый полуключ Диффи-Хеллмана ( KE-I ) и иногда ID обеих сторон. Второе сообщение похоже, но переносит ключевой HMAC HASH2, nonce респондента ( N-R ), и, если есть, то полуключ Диффи-Хеллмана, созданный респондентом. Третье сообщение содержит только HMAC HASH3 ключа.

Сообщения аутентифицированы с помощью использования трех HMAC ключа: HASH1, HASH2 и HASH3. Они вычисляются следующим образом:

HASH1 = prf (SKEYID_d, MsgID | SA | N-I)
HASH2 = prf (SKEYID_d, MsgID | SA | N-R) 
HASH3 = prf (SKEYID_d, 0 | MsgID [ SA | N-I | N-R)

Каждый HMAC включает сообщение IKE ( MsgID ), используемое в заголовке ISAKMP. Включение MsgID предотвращает одновременное создание фазы II и возможное столкновение.

Все три сообщения зашифрованы для конфиденциальности, используя SKEYID_e, созданный в течение фазы 1.

Идеальная прямая безопасность (PFS)

После установления IKE SA и вычисления SKEYID_d в фазе 1 все ключи для быстрого режима получены из SKEYID_d. Так как из единственной фазы I фаза II может быть получена много раз, безопасность фазы II является уязвимой, если злоумышленник имеет доступ к SKEYID_d. Чтобы воспрепятствовать этому, IKE применяет опцию идеальная прямая безопасность (PFS - Perfect Forward Security). В этой опции происходит обмен дополнительным полуключом Диффи-Хеллмана, и в результате совестный ключ (g^ir) используется в вычислении материала для ключей (см. следующий раздел) для IPSec. PFS эффективен, если ключ Диффи-Хеллмана после вычисления материала для ключа немедленно удален в каждом быстром режиме.

Материалы для ключей

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

K = prf  (SKEYID_d, protocol | SPI | N-I | N-R)                     (без PFS)
 K = prf (SKEYID_d, g^ir|  protocol | SPI | N-I | N-R)             (с PFS)

Если длина K слишком коротка для конкретного выбранного шифра, создается последовательность ключей, где каждый ключ получается из предыдущего, и ключи конкатенируются для того, чтобы сделать длинный ключ. Мы показываем случай без PFS; для варианта с PFS мы должны добавить g^ir.

Созданный материал для ключей - однонаправленный; каждая сторона создает свой различный материал для ключей, поэтому используемый в каждом направлении материал различен.

K₁ =prf  (SKEYID_d, protocol | SPI | N-I | N-R)              
K₂ =prf  (SKEYID_d, K₁ |  protocol | SPI | N-I | N-R)               
K₃ =prf  (SKEYID_d, K₂| protocol | SPI | N-I | N-R)    
.......           
K = K₁ | K₂ | K₃ |

Материал для ключей, созданный после фазы II, - однонаправленный; есть один ключ для каждого направления.

SA-алгоритмы

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

Группы Диффи-Хеллмана

Первые переговоры включают группу Диффи-Хеллмана, используемую для того, чтобы обмениваться полуключами. Она состоит из пяти групп, как это показано в табл. 8.3.

Группы Диффи-Хеллмана
Значение	Описание
1	Группа возведения в степень по модулю с модулем 768 битов
2	Группа возведения в степень по модулю с модулем 1024 бита
3	Группа эллиптической кривой с размером поля 155 битов
4	Группа эллиптической кривой с размером поля 185 битов
5	Группа возведения в степень по модулю с модулем 1680 битов

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

Алгоритмы хэширования
Значение	Описание
1	MD5
2	SHA
3	Tiger
4	SHA2-256
5	SHA2-384
6	SHA2-512

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

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

Алгоритмы шифрования
Значение	Описание
1	DES
2	IDEA
3	Blowfish
4	RC5
5	3DES
6	CAST
7	AES

8.6. ISAKMP

Протокол управления ключами и услуг безопасности в Интернете - ISAKMP (Internet Security Association and Key Management Protocol) - разработан для обмена сообщениями в протоколе шифрования и идентификации - ( IKE ).

Общий заголовок

Формат общего заголовка показан на рис. 8.29.

(рис 8.29) Общий заголовок ISAKMP

Cookie инициатора. Это поле на 32 бита определяет сookie объекта, который инициирует установление SA, уведомление SA или удаление SA.

Cookie респондента. Это поле на 32 бита определяет сookie ответа респондента. Значение этого поля - 0, когда инициатор передает первое сообщение.

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

Главная версия. Этот номер размером 4 бита определяет главную версию протокола. В настоящее время значение этого поля - 1.

Младший номер версии.Этот номер размером 4 бита идет после главной версии и дополняет версию протокола. В настоящее время значение этого поля - 0.

Тип обмена. Это поле на 8 битов определяет тип обмена, который осуществляется ISAKMP -пакетами. Мы обсудили различные типы обмена в предыдущем разделе.

Флажки. Это - поле на 8 битов, в котором каждый бит определяет опцию обмена. Пока определены только три самых младших бита. Бит шифрования, когда он установлен на 1, указывает, что остальная часть полезной нагрузки будет зашифрована с использованием ключа шифрования и алгоритма, определенного SA. Договорный бит, когда он установлен на 1, определяет, что перед установлением SA материал шифрования не получен. Когда бит аутентификации установлен на 1, он определяет, что остальная часть полезной нагрузки хоть и не зашифрована, но аутентифицирована для сохранения целостности.

ID Сообщения. Это поле на 32 бита - уникальный опознавательный код сообщения, которое определяет протокол. Это поле используется только в течение второй фазы переговоров и установлено на 0 в течение первой фазы.

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

Полезные нагрузки

Полезные нагрузки разработаны для того, чтобы доставлять сообщения. табл. 8.6 показывает типы полезных нагрузок.

Типы полезных нагрузок
Типы	Название	Краткое описание
0	None (Нет)	Используется, чтобы показать конец множества полезных нагрузок
1	SA	Используется для того, чтобы запустить начало процесса переговоров
2	Proposal (предложение)	Содержит информацию, используемую в течение переговоров о SA
3	Transform (преобразовать)	Определяет секретные преобразования для создания безопасного канала
4	Key Exchange (обмен ключами)	Доставляет данные, используемые для генерации ключей
5	Identification (идентификация)	Доставляет данные идентификации в соединениях равного уровня
6	Certification (Сертификация)	Доставляет сертификат открытого ключа
7	Certification Request (Запрос сертификата)	Используется, чтобы запросить сертификат другой стороны
8	Hash (хэширование)	Доставляет данные, сгенерированные хэш-функцией
9	Signature (подпись)	Доставляет данные, сгенерированные функцией подписи
10	Nonce	Доставляет беспорядочно сгенерированные данные, такие как nonce
11	Notification (уведомление)	Доставляет сообщения об ошибках или состоянии услуг безопасности (SA)
12	Delete (удалить)	Доставляет SA, который удалил передатчик
13	Vendor (производитель)	Определяет расширения спецификации производителя

Каждая полезная нагрузка имеет типовой заголовок и некоторые заданные поля. Формат общего заголовка показан на рис. 8.30.

(рис 8.30) Общий заголовок полезной нагрузки

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

Длина полезной нагрузки. Это поле на 16 битов определяет длину полной полезной нагрузки (включая типовой заголовок) в байтах.

SA полезная нагрузка

SA полезная нагрузка используется, чтобы договориться о параметрах безопасности. Однако эти параметры не включены в SA полезную нагрузку; они находятся в двух других полезных нагрузках (proposal - предложение и transform - преобразование), которые мы обсудим позже. SA полезная нагрузка сопровождается одной или несколькими полезными нагрузками proposal (предложение), и каждая полезная нагрузка предложения сопровождается одной или больше полезными нагрузками transform (преобразование). SA полезная нагрузка только определяет поле домен интерпретации и поле ситуация. рис. 8.31 показывает формат SA полезной нагрузки.

(рис 8.31) SA полезная нагрузка

Поля в общем заголовке уже обсуждались. Описание полей SA полезной нагрузки дано ниже.

Домен интерпретации (DOI - Domen Interpretation). Это - поле на 32 бита. Для фазы 1 значение 0 для этого поля определяет общий SA ; значение 1 определяет IPSec.

Ситуация. Это - поле переменной длины, определяющее ситуацию, в которой проводятся переговоры.

Полезная нагрузка "Предложение"

, начинает процесс переговоров. Хотя это само по себе не задает никаких параметров, она определяет идентификацию протокола и индекс параметра обеспечения безопасности (SPI). Параметры для переговоров посылаются в составе полезной нагрузки "Преобразование" ( transform ),.которая следует за полезной нагрузкой предложения. Каждая полезная нагрузка предложения сопровождает одну или более полезных нагрузок преобразования, которые создают альтернативные множества параметров. рис. 8.32 показывает формат полезной нагрузки предложения.

(рис 8.32) Полезная нагрузка "Предложение" (proposal)

Поля в общем заголовке уже обсуждались. Описания других полей даны ниже.

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

ID Протокола. Это поле на 8 битов определяет протокол для переговоров. Например, Фаза I IKE = 0, ESP = 1, AH = 2, и т. д.

Размер SPI. Это поле на 8 битов определяет размер индекса параметра безопасности (SPI) в байтах.

Число преобразований. Это поле на 8 битов определяет число полезных нагрузок преобразования, которые будут следовать за этой полезной нагрузкой предложения.

SPI. Это поле переменной длины фактический SPI (см.размер SPI). Обратите внимание, что если SPI не заполняет пространство на 32 бита, заполнение не добавляется.

Полезная нагрузка "Преобразование"

Полезная нагрузка " Преобразование" фактически доставляет признаки SA переговоров. рис. 8.33 показывает формат полезной нагрузки "преобразование".

Поля в общем заголовке уже обсуждались. Описания других полей даны ниже.

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

ID преобразования. Это поле на 8 битов определяет идентификацию полезной нагрузки.

Признаки. Каждая полезная нагрузка преобразования может доставить несколько признаков (атрибутов). Каждый атрибут непосредственно имеет три или два подполя (см. рис. 8.33). Подполе типа признака определяет тип признака как определенного в домене интерпретации - DOI. Подполе длины признака, если оно имеется, определяет значение длины признака. Поле значения признака - два байта в короткой форме или переменной длины в длинной форме.

(рис 8.33) Полезная нагрузка "Преобразование"

Полезная нагрузка "обмена ключами"

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

(рис 8.34) Полезная нагрузка "обмена ключами"

Поля в общем заголовке уже обсуждались. Описание поля ключа засекречивания (KE) дано ниже.

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

Полезная нагрузка "Идентификация"

Полезная нагрузка "Идентификация" позволяет объектам передать свои параметры идентификации друг другу. рис. 8.35 показывает формат полезной нагрузки "Идентификация".

(рис 8.35) Полезная нагрузка "Идентификация"

Поля в общем заголовке обсуждались. Описания других полей даны ниже.

Тип ID. Это поле на 8 битов задает домен (область) интерпретации - DOI и определяет тип используемого ID.

Данные ID. Это поле на 24 бита обычно устанавливается на 0.

Данные идентификации. Фактический идентификатор каждого объекта доставляется в этом поле переменной длины.

Полезная нагрузка "Сертификация"

В любое время в течение процесса обмена объект может передать свой сертификат (для открытого ключа шифрования/дешифрования или ключа подписи). Хотя включение полезной нагрузки "Сертификация" в процесс обмена является обычно необязательным, оно должно быть предусмотрено, если нет безопасного списка-указателя (директории), доступного для распределения сертификатов. рис. 8.36 показывает формат полезной нагрузки "сертификация".

(рис 8.36) Полезная нагрузка "сертификация"

Поля в общем заголовке уже обсуждались. Описания других полей приведены ниже.

Сертификат кодирования. Это поле на 8 битов определяет кодирование (тип) сертификата. табл. 8.7 показывает типы, определенные в настоящее время.

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

Типы сертификации
Значение	Тип
0	Нет
1	Сертификат в виде X.509
2	Сертификат по алгоритму PGP
3	Ключ подписанный DNS
4	Сертификат X.509 - Подпись
5	Сертификат X.509 - Обмен ключами
6	Маркеры Цербера (Cerberus token)
7	Список аннулирования сертификатов
8	Список административного аннулирования
9	сертификат SPKI (Simple Public Key Infrastructure)
10	X.509 сертификат - Признаки

Полезная нагрузка "Запрос сертификата"

Каждый объект может явно запросить сертификат от другого объекта, используя полезную нагрузку "запроса сертификата". Рис. 8.37 показывает формат такой полезной нагрузки.

(рис 8.37) Полезная нагрузка "Запрос сертификата"

Поля в общем заголовке уже обсуждались. Определения других полей приведено ниже.

Тип сертификата. Это 8-битовое поле определяет тип сертификата в полезной нагрузке сертификата.

Администрация сертификата. Это - поле переменной длины, которое определяет администрацию для выданного типа сертификата.

Полезная нагрузка "Хэширование"

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

(рис 8.38) Полезная нагрузка "Хэширование"

Поля в общем заголовке уже обсуждались. Описание последнего поля дано ниже.

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

Полезная нагрузка "Подпись"

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

(рис 8.39) Полезная нагрузки "Подпись"

Поля в общем заголовке уже обсуждались. Описание последнего поля дано ниже.

Подпись. Это поле переменной длины содержит дайджест, следующий из применения подписи к части сообщений или состояний ISAKMP.

Полезная нагрузка Nonce

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

(рис 8.40) Полезная нагрузка Nonce

Поля в общем заголовке уже обсуждались. Описание последнего поля дано ниже.

Nonce. Это поле переменной длины содержит значения nonce.

Полезная нагрузка "Уведомление"

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

(рис 8.41) Полезная нагрузка "Уведомление"

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

DOI. Это поле на 32 бита - то же самое, что определено для полезной нагрузки услуг обеспечения безопасности (SA).

ID протокола. Это поле на 8 битов - то же самое, что определено для полезной нагрузки "Предложение".

SPI размер. Это поле на 8 битов - то же самое, что определено для полезной нагрузки "Предложение".

Тип сообщения "Уведомление". Это поле на 16 битов определяет состояние или тип ошибки, о которой нужно передать сообщение. табл. 8.8 дает краткое описание этих типов.

SPI. Это поле переменной длины - такое же, как определено для полезной нагрузки "Предложение".

Данные уведомления. Это поле переменной длины может доставить дополнительное текстовое сообщение о состоянии или ошибках. Типы ошибок перечислены в табл. 8.8. Значения 31 до 8191 зарезервированы для будущего использования и значения от 8192 до 16383 - для частного применения.

Типы уведомления
Значение	Описание	Описание (рус.)
1	INVALID-PAYLOAD-TYPE	Недопустимый тип полезной нагрузки
2	DOI-NOT-SUPPORTED	Не поддерживается
3	SITUATION-NOT-SUPPORTED	Ситуация не поддерживается
4	INVALID-COOKIE	Недопустимое cookie
5	INVALID-MAJOR-VERSION	Недопустимая главная версия
6	INVALID-MINOR-VERSION	Недопустимый младший номер версии
7	INVALID-EXCHANGE-TYPE	Недопустимый тип обмена
8	INVALID-FLAGS	Недопустимые флажки
9	INVALID-MESSAGE-ID	Недопустимый ID сообщения
10	INVALID-PROTOCOL-ID	Недопустимый ID протокола
11	INVALID-SPI	Недопустимый SPI
12	INVALID-TRANSFORM-ID	Недопустимый ID преобразования
13	ATTRIBUTE-NOT-SUPPORTED	Атрибут не поддерживается
14	NO-PROPOSAL-CHOSEN	Предложение не выбрано
15	BAD PROPOSAL-SYNTAX	Плохой синтаксис предложения
16	PAYLOAD-MALFORMED	Неправильно сформированная полезная нагрузка
17	INVALID-KEY-INFORMATION	Недопустимая информация ключа
18	INVALID-ID-INFORMATION	Недопустимая информация ID
19	INVALID-CERT-ENCODING	Недопустимое шифрование сертификата
20	INVALID-CERTIFICATE	Недопустимый сертификат
21	CERT-TYPE-UNSUPPORTED	Неподдерживаемый тип сертификата
22	INVALID-CERT-AUTHORITY	Недопустимая администрация сертификата
23	INVALID-HASH-INFORMATION	Недопустимая информация хэширования
24	AUTHENTICATION-FAILED	Ошибочная аутентификация
25	INVALID-SIGNATURE	Недопустимая подпись
26	ADDRESS-NOTIFICATION	Уведомление адреса
27	NOTIFY-SA-LIFETIME	Уведомление о времени жизни SA
28	CERTIFICATE-UNAVAILABLE	Сертификат недоступен
29	UNSUPPORTED EXCHANGE-TYPE	Неподдерживаемый тип обмена
30	UNEQUAL-PAYLOAD-LENGTHS	Несоответствующая длина полезной нагрузки

Таблица 8.9 содержит список уведомлений состояния. Значения от 16385 до 24575 и от 40960 до 65535 зарезервированы для будущего использования, значения от 32768 до 40959 - для частного применения.

Значения уведомлений состояния
Значение	Описание
16384	Подключено
24576-32767	DOI- заданные коды интерпретации домена

Полезная нагрузка "Удаление"

Полезная нагрузка "Удаление"используется объектом, который удалил один или более SA 's и должен сообщить равным по уровню объектам, что он эти SA 's больше не поддерживает. рис. 8.42 показывает формат полезной нагрузки "удаление".

(рис 8.42) Полезная нагрузка "Удаление"

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

DOI. Это поле на 32 бита - то же самое, что определено для полезной нагрузки SA (услуг обеспечения безопасности).

Протокол ID. Это поле на 8 битов - то же самое, что определено для полезной нагрузки предложения.

SPI размер. Это поле на 8 битов - то же самое, что определено для полезной нагрузки предложения.

Номер SPI's. Это поле на 16 битов определяет номер SPI's. Каждый, кто удаляет полезную нагрузку, может известить об удалении нескольких SAs.

SPIs. Это поле переменной длины определяет SPI's, удаленные SA 's.

Полезная нагрузка "Поставщик"

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

(рис 8.43) Полезная нагрузка "Поставщик"

Поля в типовом заголовке уже обсуждались. Описание последнего поля дано ниже.

ID поставщика. Это поле переменной длины определяет константу, используемую поставщиком.

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

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

Книги

[ DH03], [ FraOl], [ KPS02], [ Res0l], [ Sta06], [ Rhe03] полностью рассматривают IPSec.

Сайты

Нижеследующие сайты дают больше информации о темах, обсужденных в этой лекции.

http://www.unixwiz.net/techtips/iguide-ipsec.html

http://www.ietf.org/rfc/rfc2401.txt

http://rfc.net/rfc240l.html

8.8. Итоги

Безопасность IP ( IPSec ) - совокупность протоколов, разработанных IETF (Группа Инженерной поддержки сети Интернет) для того, чтобы обеспечить безопасность передачи пакетов на сетевом уровне.

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

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

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

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

Смена ключей в Интернете ( IKE ) - протокол, предназначенный для создания услуг обеспечения безопасности (SA) для входящих и исходящих соединений. IKE создает SA 's для IPSec.

IKE - сложный протокол, который базируется на трех других протоколах: Oakley, SKEME и ISAKMP.

IKE работает в двух фазах: фаза I и фаза II. Фаза I создает SA 's для фазы II; фаза II создает SA 's для протокола обмена данными, такого как IPSec.

ISAKMP -протокол разработан для того, чтобы доставить сообщение для протокола IKE.

8.9. Набор для практики

Обзорные вопросы

Покажите различия между двумя режимами IPSec.

Определите протокол AH и услуги безопасности, которые он обеспечивает.

Определите протокол ESP и услуги безопасности, которые он обеспечивает.

Определите услуги обеспечения безопасности (SA) и объясните их цель.

Определите SAD и объясните его отношение к услугам обеспечения безопасности.

Определите стратегию безопасности и объясните ее цель в отношении к IPSec.

Определите IKE и объясните, почему этот протокол необходим в IPSec.

Определите фазы IKE и цели каждой фазы.

Определите ISAKMP и его отношение к IKE.

Перечислите типы полезной нагрузки ISAKMP и цель каждого типа.

Упражнения

Хост получает аутентифицированный пакет с порядковым номером 181. Окно ответа имеет промежуток от 200 до 263. Что хост сделает с пакетом? Каков будет промежуток окна после этого события?

Хост получает аутентифицированный пакет с порядковым номером 208. Окно ответа имеет промежуток от 200 до 263. Что хост сделает с пакетом? Каков будет промежуток окна после этого события?

Хост получает аутентифицированный пакет с порядковым номером 331. Окно ответа имеет промежуток от 200 до 263. Что хост сделает с пакетом? Каков будет промежуток окна после этого события?

Диаграмма для вычисления SKEYID при методе предварительного совместного ключа показана на рис. 8.44. Обратите внимание, что ключ к функции (рис 8.44) Упражнение 14

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

нарисуйте подобную диаграмму SKEYID для метода цифровой подписи.

Нарисуйте диаграмму, подобную рис. 8.44, для приводимых ниже случаев; ключ в каждом случае - SKEYID.

SKEYID_a

SKEYID_d

SKEYID_e

Нарисуйте диаграмму, подобную рис. 8.44, для приводимых ниже случаев, ключ в каждом случае - SKEYID.

HASH1

HASH-R

Нарисуйте диаграмму, подобную рис. 8.44, для следующего случая; ключ в каждом случае - SKEYID_d.

HASH1

HASH2

HASH3

Нарисуйте диаграмму, подобную рис. 8.44, для следующего случая; ключ в каждом случае - SKEYID _d.

K для случая без PFS

K для случая с PFS

Повторите упражнение для случая, в котором длина K - слишком мала.

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

Повторите упражнение 10, используя метод первоначального открытого ключа в главном режиме (см. рис. 8.21).

Повторите упражнение 10, используя пересмотренный метод открытого ключа в главном режиме (см. рис. 8.22).

Повторите упражнение 10, используя метод цифровой подписи в главном режиме (см. рис. 8.23).

Повторите упражнение 10 в энергичном режиме (см. рис. 8.24).

Повторите упражнение 11 в энергичном режиме (см. рис. 8.25).

Повторите упражнение 12 в энергичном режиме (см. рис. 8.26).

Повторить упражнение 13 в энергичном режиме (см. рис. 8.27).

Нарисуйте диаграмму и покажите фактические ISAKMP -пакеты, которыми обменялись инициатор и респондент в быстром режиме (см. рис. 8.28).

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

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

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

Сравните метод цифровой подписи в главном и агрессивном режимах. Что сделано в агрессивном режиме относительно безопасности? Каково увеличение эффективности?

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

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

Сравните методы для главного режима и покажите, какой метод позволяет обменяться защищенными ID.

Повторите упражнение для энергичных методов.

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

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

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

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

Страницы:

Цели и содержание

Эта лекция имеет несколько целей:

Определить архитектуру IPSec.

Обсудить приложение IPSec в транспортном и туннельном режимах.

Обсудить, как IPSec может использоваться, чтобы обеспечить только установление подлинности.

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

Определить службы обеспечения безопасности (SA - Security Association) и объяснить, как они реализованы для IPSec.

Определить протокол обмена ключами (IKE - Internet Key Exchange) и объяснить, как он используется в IPSec.

(рис 8.1) Набор протоколов TCP/IP и IPSec

8.1. Два режима

IPSec работает в двух различных режимах - транспортном и туннельном.

Транспортный режим

(рис 8.2) Транспортный режим IPSec

IPSec в транспортном режиме не защищает заголовок IP, а только информацию, прибывающую от транспортного уровня.

(рис 8.3) Действия транспортного режима

Туннельный режим

(рис 8.4) Туннельный режим IPSec

(рис 8.5) Действия туннельного режима

IPSec в туннельном режиме защищает первоначальный заголовок IP.

Сравнение

(рис 8.6) Сравнение транспортного и туннельного режимов

8.2. Два протокола безопасности

Заголовок аутентификации (AH)

(рис 8.7) Протокол "Заголовок аутентификации (AH)"

Заголовок аутентификации добавляется к полезной нагрузке с полем аутентификации данных, установленным на 0.

Заполнение добавляется, если нужно сделать полную длину сообщения для конкретного алгоритма хэширования.

Данные аутентификации вставляются в заголовок аутентификации.

Заголовок IP добавляется после изменения значения поля протокола на 51.

Краткое описание каждого поля дано ниже.

Полезная нагрузка со встроенной защитой (ESP)

(рис 8.8) Протокол "Полезная нагрузка со встроенной защитой" (ESP)

Конечная метка ESP добавляется к полезной нагрузке.

Полезная нагрузка и конечная метка зашифровываются.

Добавляется заголовок ESP.

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

Данные аутентификации добавляются в конце конечной метки ESP.

Заголовок IP добавляется после изменения значения протокола на 50.

Поля заголовка и конечной метки следующие:

Порядковый номер. Поле порядкового номера на 32 бита совпадет с тем, которое определено для протокола AH.

Заполнение - это поле переменной длины (от 0 до 255 байтов), состоящее из нулей и служащее заполнением.

ESP обеспечивает установление подлинности источника, целостность данных и секретность.

IPv4 и IPv6

IPSec поддерживает и IPv4, и IPv6. В IPv6, однако, AH и ESP - часть расширения заголовка.

Сравнение AH и ESP

Услуги, обеспечиваемые IPSec

Услуги IPSec
Услуги	AH	ESP
Управление доступом Access control	ДА	ДА
Установление подлинности сообщения (целостность сообщения) Message authentication (message integrity)	ДА	ДА
Установление подлинности объекта (установление подлинности источника данных) Entity authentication (data source authentication)	ДА	ДА
Конфиденциальность Confidentiality	НЕТ	ДА
Защита от атаки воспроизведения Replay attack protection	ДА	ДА

Управление доступом

Целостность сообщения

Установление подлинности объекта

Конфиденциальность

Защита от атаки воспроизведения

(рис 8.9) Окно ответа

8.3. Услуги обеспечения безопасности трафика

Идея услуг обеспечения безопасности трафика

(рис 8.10) Простые услуги обеспечения безопасности (SA)

База данных услуг обеспечения безопасности

(рис 8.11) База данных услуг обеспечения безопасности

Входы для каждой строки называются параметрами SA. Типичные параметры показаны в табл. 8.2.

Типичные параметры SA

Счетчик порядкового номера Sequence Number Counter	Это значение на 32 бита, которое используется, чтобы генерировать порядковые номера для AH - или ESP -заголовка
Переполнение порядкового номера Sequence Number Overflow	Это флажок, который определяет варианты состояния в случае переполнения порядкового номера .
Окно антивоспроизведения Anti-Replay Window	Оно обнаруживает входящий воспроизведенный пакет AH или пакет ESP
Информация AH AH Information	Эта секция содержит информацию для протокола AH: Алгоритм аутентификации Ключи Время жизни ключа Другие связанные параметры
Информация ESP ESP Information	Эта секция содержит информацию для протокола ESP: Алгоритм шифрования Алгоритм аутентификации Ключи Время жизни ключа Вектор инициализации Другие связанные параметры
Время жизни SA Lifetime	Определяет время жизни для SA.
Режим IPSec IPSec Mode	Определяет режим, транспортный или туннельный
Путь MTU Path MTU	Определяет путь МАКСИМАЛЬНЫЙ ПЕРЕДАВАЕМЫЙ БЛОК (фрагментацию). This defines the path MTU (fragmentation).

8.4. Стратегия безопасности

База данных стратегии безопасности

(рис 8.12) База данных Стратегии Безопасности (SPD)

Исходящий SPD

Когда пакет нужно передать, то работают с исходящим SPD. рис. 8.13 показывает обработку пакета передатчиком.

Вход исходящего SPD состоит из шестизначного индекса; выход содержит один из трех результатов:

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

(рис 8.13) Исходящий процесс

Входящий SPD

Вход к входящему SPD - шестикратный индекс; выход - один из трех результатов:

Сбросить. Это означает, что пакет, определенный стратегией, должен быть отброшен.

Применить.В этом случае заголовок безопасности должен быть обработан. Здесь могут возникнуть две ситуации:

если SA еще не установлена, то пакет должен быть забракован.

(рис 8.14) Входящий процесс

8.5. Протокол интернет-обмена ключами (IKE)

Протокол Интернет-обмена ключами создает услуги обеспечения безопасности SA 's для протокола IPSec.

IKE - сложный протокол, основанный на трех других протоколах: OAKLEY, SKEME и ISAKMP, как показано на рис. 8.15.

(рис 8.15) Компоненты протокола управления ключами в Интернете

В этой секции мы поговорим непосредственно об IKE как о механизме для создания услуг безопасности в SA 's в IPSec.

Улучшенный протокол управления ключами Диффи-Хеллмана

В лекции 5 мы обсудили метод Диффи-Хеллмана; концепция этого метода суммирована на рис. 8.16.

(рис 8.16) Обмен ключами по методу Диффи-Хеллмана

Засоряющая атака

(рис 8.17) Метод Диффи - Хеллмана с cookies

, IKE использует cookies.

Атака воспроизведения

, IKE использует nonce.

Атака "посредника"

В IKE секретность может заключаться в одном из следующих сочетаний ключей:

а. предварительный открытый ключ засекречивания;

Фазы IKE

Фаза I является базовой; фаза II задана для протокола.

Фазы и режимы

(рис 8.18) Фазы IKE

(рис 8.19) Методы основного или энергичного режима

Фаза I: основной режим

SKYID = prf (предварительный совместный ключ, N-I | N-R)              (метод предварительного совместного ключа)
SKYID = prf(N-I | N-R, g^ir)                                              (метод открытого ключа)
SKYID = prf( (hash (N-I | N-R), Cookie -I | Cookie -R)                          (цифровая подпись)

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

SKYID_d = prf( (SKEYID, g^{i r}| Cookie -I | Cookie -R| 0)
SKYID_a = prf( (SKEYID, SKEYID_d | g^{i r}| Cookie -I | Cookie -R| 1)
SKYID_e = prf( (SKEYID, SKEYID_a | g^{i r}| Cookie -I | Cookie -R| 2)

HASH-I = prf( (SKEYID, KE-I | KE-R | Cookie -I | Cookie -R |SA-I | ID-I)
HASH-R = prf( (SKEYID, KE-I | KE-R | Cookie -I | Cookie -R |SA-I | ID-R)

Метод предварительного совместного ключа

(рис 8.20) Главный режим метода с предварительным совместным ключом.

Первоначальный метод открытого ключа

(рис 8.21) Главный режим метода с первоначальным открытым ключом.

Пересмотренный метод открытого ключа

(рис 8.22) Главный режим метода с пересмотренным открытым ключом.

K-I = prf(N - I, Cookie-I)
K-R = prf(N - R, Cookie-R)

Метод цифровой подписи

(рис 8.23) Главный режим метода цифровой подписи

Фаза I: энергичный режим

Метод предварительного совместного ключа

(рис 8.24) Энергичный режим метода с предварительным совместным ключом

Метод первоначального открытого ключа

(рис 8.25) Энергичный режим метода с первоначальным ключом

Пересмотренный метод открытого ключа

(рис 8.26) Энергичный режим метода с пересмотренным открытым ключом

Метод цифровой подписи

(рис 8.27) Энергичный режим метода цифровой подписи

Фаза II: быстрый режим

(рис 8.28) Быстрый режим

HASH1 = prf (SKEYID_d, MsgID | SA | N-I)
HASH2 = prf (SKEYID_d, MsgID | SA | N-R) 
HASH3 = prf (SKEYID_d, 0 | MsgID [ SA | N-I | N-R)

Все три сообщения зашифрованы для конфиденциальности, используя SKEYID_e, созданный в течение фазы 1.

Идеальная прямая безопасность (PFS)

Материалы для ключей

K = prf  (SKEYID_d, protocol | SPI | N-I | N-R)                     (без PFS)
 K = prf (SKEYID_d, g^ir|  protocol | SPI | N-I | N-R)             (с PFS)

K₁ =prf  (SKEYID_d, protocol | SPI | N-I | N-R)              
K₂ =prf  (SKEYID_d, K₁ |  protocol | SPI | N-I | N-R)               
K₃ =prf  (SKEYID_d, K₂| protocol | SPI | N-I | N-R)    
.......           
K = K₁ | K₂ | K₃ |

Материал для ключей, созданный после фазы II, - однонаправленный; есть один ключ для каждого направления.

SA-алгоритмы

Группы Диффи-Хеллмана

Группы Диффи-Хеллмана
Значение	Описание
1	Группа возведения в степень по модулю с модулем 768 битов
2	Группа возведения в степень по модулю с модулем 1024 бита
3	Группа эллиптической кривой с размером поля 155 битов
4	Группа эллиптической кривой с размером поля 185 битов
5	Группа возведения в степень по модулю с модулем 1680 битов

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

Алгоритмы хэширования
Значение	Описание
1	MD5
2	SHA
3	Tiger
4	SHA2-256
5	SHA2-384
6	SHA2-512

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

Алгоритмы шифрования
Значение	Описание
1	DES
2	IDEA
3	Blowfish
4	RC5
5	3DES
6	CAST
7	AES

8.6. ISAKMP

Общий заголовок

Формат общего заголовка показан на рис. 8.29.

(рис 8.29) Общий заголовок ISAKMP

Полезные нагрузки

Типы полезных нагрузок
Типы	Название	Краткое описание
0	None (Нет)	Используется, чтобы показать конец множества полезных нагрузок
1	SA	Используется для того, чтобы запустить начало процесса переговоров
2	Proposal (предложение)	Содержит информацию, используемую в течение переговоров о SA
3	Transform (преобразовать)	Определяет секретные преобразования для создания безопасного канала
4	Key Exchange (обмен ключами)	Доставляет данные, используемые для генерации ключей
5	Identification (идентификация)	Доставляет данные идентификации в соединениях равного уровня
6	Certification (Сертификация)	Доставляет сертификат открытого ключа
7	Certification Request (Запрос сертификата)	Используется, чтобы запросить сертификат другой стороны
8	Hash (хэширование)	Доставляет данные, сгенерированные хэш-функцией
9	Signature (подпись)	Доставляет данные, сгенерированные функцией подписи
10	Nonce	Доставляет беспорядочно сгенерированные данные, такие как nonce
11	Notification (уведомление)	Доставляет сообщения об ошибках или состоянии услуг безопасности (SA)
12	Delete (удалить)	Доставляет SA, который удалил передатчик
13	Vendor (производитель)	Определяет расширения спецификации производителя

(рис 8.30) Общий заголовок полезной нагрузки

SA полезная нагрузка

(рис 8.31) SA полезная нагрузка

Поля в общем заголовке уже обсуждались. Описание полей SA полезной нагрузки дано ниже.

Ситуация. Это - поле переменной длины, определяющее ситуацию, в которой проводятся переговоры.

Полезная нагрузка "Предложение"

(рис 8.32) Полезная нагрузка "Предложение" (proposal)

Поля в общем заголовке уже обсуждались. Описания других полей даны ниже.

ID Протокола. Это поле на 8 битов определяет протокол для переговоров. Например, Фаза I IKE = 0, ESP = 1, AH = 2, и т. д.

Размер SPI. Это поле на 8 битов определяет размер индекса параметра безопасности (SPI) в байтах.

Полезная нагрузка "Преобразование"

Поля в общем заголовке уже обсуждались. Описания других полей даны ниже.

ID преобразования. Это поле на 8 битов определяет идентификацию полезной нагрузки.

(рис 8.33) Полезная нагрузка "Преобразование"

Полезная нагрузка "обмена ключами"

(рис 8.34) Полезная нагрузка "обмена ключами"

Поля в общем заголовке уже обсуждались. Описание поля ключа засекречивания (KE) дано ниже.

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

Полезная нагрузка "Идентификация"

(рис 8.35) Полезная нагрузка "Идентификация"

Поля в общем заголовке обсуждались. Описания других полей даны ниже.

Тип ID. Это поле на 8 битов задает домен (область) интерпретации - DOI и определяет тип используемого ID.

Данные ID. Это поле на 24 бита обычно устанавливается на 0.

Полезная нагрузка "Сертификация"

(рис 8.36) Полезная нагрузка "сертификация"

Поля в общем заголовке уже обсуждались. Описания других полей приведены ниже.

Типы сертификации
Значение	Тип
0	Нет
1	Сертификат в виде X.509
2	Сертификат по алгоритму PGP
3	Ключ подписанный DNS
4	Сертификат X.509 - Подпись
5	Сертификат X.509 - Обмен ключами
6	Маркеры Цербера (Cerberus token)
7	Список аннулирования сертификатов
8	Список административного аннулирования
9	сертификат SPKI (Simple Public Key Infrastructure)
10	X.509 сертификат - Признаки

Полезная нагрузка "Запрос сертификата"

(рис 8.37) Полезная нагрузка "Запрос сертификата"

Поля в общем заголовке уже обсуждались. Определения других полей приведено ниже.

Тип сертификата. Это 8-битовое поле определяет тип сертификата в полезной нагрузке сертификата.

Полезная нагрузка "Хэширование"

(рис 8.38) Полезная нагрузка "Хэширование"

Поля в общем заголовке уже обсуждались. Описание последнего поля дано ниже.

Полезная нагрузка "Подпись"

(рис 8.39) Полезная нагрузки "Подпись"

Поля в общем заголовке уже обсуждались. Описание последнего поля дано ниже.

Полезная нагрузка Nonce

(рис 8.40) Полезная нагрузка Nonce

Поля в общем заголовке уже обсуждались. Описание последнего поля дано ниже.

Nonce. Это поле переменной длины содержит значения nonce.

Полезная нагрузка "Уведомление"

(рис 8.41) Полезная нагрузка "Уведомление"

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

DOI. Это поле на 32 бита - то же самое, что определено для полезной нагрузки услуг обеспечения безопасности (SA).

ID протокола. Это поле на 8 битов - то же самое, что определено для полезной нагрузки "Предложение".

SPI размер. Это поле на 8 битов - то же самое, что определено для полезной нагрузки "Предложение".

SPI. Это поле переменной длины - такое же, как определено для полезной нагрузки "Предложение".

Типы уведомления
Значение	Описание	Описание (рус.)
1	INVALID-PAYLOAD-TYPE	Недопустимый тип полезной нагрузки
2	DOI-NOT-SUPPORTED	Не поддерживается
3	SITUATION-NOT-SUPPORTED	Ситуация не поддерживается
4	INVALID-COOKIE	Недопустимое cookie
5	INVALID-MAJOR-VERSION	Недопустимая главная версия
6	INVALID-MINOR-VERSION	Недопустимый младший номер версии
7	INVALID-EXCHANGE-TYPE	Недопустимый тип обмена
8	INVALID-FLAGS	Недопустимые флажки
9	INVALID-MESSAGE-ID	Недопустимый ID сообщения
10	INVALID-PROTOCOL-ID	Недопустимый ID протокола
11	INVALID-SPI	Недопустимый SPI
12	INVALID-TRANSFORM-ID	Недопустимый ID преобразования
13	ATTRIBUTE-NOT-SUPPORTED	Атрибут не поддерживается
14	NO-PROPOSAL-CHOSEN	Предложение не выбрано
15	BAD PROPOSAL-SYNTAX	Плохой синтаксис предложения
16	PAYLOAD-MALFORMED	Неправильно сформированная полезная нагрузка
17	INVALID-KEY-INFORMATION	Недопустимая информация ключа
18	INVALID-ID-INFORMATION	Недопустимая информация ID
19	INVALID-CERT-ENCODING	Недопустимое шифрование сертификата
20	INVALID-CERTIFICATE	Недопустимый сертификат
21	CERT-TYPE-UNSUPPORTED	Неподдерживаемый тип сертификата
22	INVALID-CERT-AUTHORITY	Недопустимая администрация сертификата
23	INVALID-HASH-INFORMATION	Недопустимая информация хэширования
24	AUTHENTICATION-FAILED	Ошибочная аутентификация
25	INVALID-SIGNATURE	Недопустимая подпись
26	ADDRESS-NOTIFICATION	Уведомление адреса
27	NOTIFY-SA-LIFETIME	Уведомление о времени жизни SA
28	CERTIFICATE-UNAVAILABLE	Сертификат недоступен
29	UNSUPPORTED EXCHANGE-TYPE	Неподдерживаемый тип обмена
30	UNEQUAL-PAYLOAD-LENGTHS	Несоответствующая длина полезной нагрузки

Значения уведомлений состояния
Значение	Описание
16384	Подключено
24576-32767	DOI- заданные коды интерпретации домена