1. 1 История tcpIP
 Скачать 340.83 Kb.
|
3.3.3 Протокол Internet Key Exchange (IKE)Протокол IPSec, как и многие другие протоколы сетевой безопасности, основан на концепции общего секрета (ключа). Два устройства, которые хотят безопасно обмениваться информацией, шифруют и расшифровывают ее с помощью секрета, известного только им. Третий, кто не владеет секретом, может перехватить информацию, но прочитать ее в большинстве случаев не сможет (возможность расшифровывания зависит от стойкости алгоритма и длины ключа). Поэтому прежде чем AH или ESP начнут работу, необходимо чтобы два взаимодействующих устройства обменялись секретом, который протоколы будут использовать. Напомним, что IPSec предполагает возможность как автоматического создания SA, так и создания SA вручную. Распределение ключей вручную является простейшим способом создания SA, определения алгоритмов и ключей, при котором администратор вручную конфигурирует каждую систему, указывая ключи и другие параметры. Такая технология применяется в маленьких, статичных окружениях и не масштабируется. Для автоматического создания и управления SA используется протокол IKE. Первая версия IKE была определена в RFC 2407, 2408, 2409. Протокол IKE версии 2 определен в ряде RFC, начиная с RFC 4306. Протокол IKEv2 обратно не совместим с протоколом IKEv1, поэтому оборудование на разных концах линии связи должно поддерживать одинаковую версию протокола. 3.3.3.1 Протокол IKEv1 В IKEv1 для описания форматов передаваемых сообщений используется протокол ISAKMP. Он определяет форматы пакетов для ведения переговоров об установлении, изменении и удалении SA. Протокол IKE обеспечивает Perfect Forward Secrecy (PFS). Термин PFS (или его синоним Forward Secrecy) описывает свойство определенных протоколов обмена ключами, которое основано на следующей концепции: компрометация одного ключа позволит получить доступ к данным, защищенным только этим одним ключом. IKE реализован поверх протокола UDP. Порт UDP с номером 500 зарезервирован для IKE в IANA. Производители могут дополнительно поддерживать IKE поверх других транспортных протоколов или поверх IP. В протоколе ISAKMP определены две фазы переговоров: Фаза I: во время первой фазы два участника ISAKMP договариваются о том, как защищать дальнейший трафик. В результате переговоров между двумя сторонами устанавливается безопасный аутентифицированный канал, называемый IKE Security Association (IKE SA). IKE SA является двунаправленной, то есть создается сразу в двух направлениях. Фаза II: IKE SA, установленная в первой фазе, используется во второй фазе для безопасного обмена информацией при создании IPSec SA для протокола АН или ESP. При этом во второй фазе может быть установлено несколько безопасных ассоциаций. Все взаимодействия IKE состоят из пары сообщений: запрос и ответ. Эта пара называется «обмен». В каждой из фаз выполняется несколько обменов сообщениями. В фазе I обмены происходят в одном из двух режимов: Main Mode или Aggressive Mode. В фазе II обмен выполняется в единственном режиме Quick Mode. Обмен фазы I Участники фазы I договариваются о следующих обязательных параметрах: алгоритме шифрования; алгоритме хэширования; методе аутентификации; информации о группе для алгоритма Диффи-Хеллмана. Кроме того, возможны дополнительные переговоры о псевдослучайной функции (PRF). Если переговоры о ней не ведутся, то используется HMAC с хэш-алгоритмом, о котором договорились (MD5, SHA). Группа Диффи-Хеллмана определяется по номеру. В главном режиме (Main Mode) переговоры об установлении IKE SA выполняются путем обмена тремя парами сообщений ISAKMP (то есть между узлами передается 6 сообщений). Сообщение ISAKMP инкапсулировано в дейтаграмму UDP с номерами порта назначения и источника, установленными в 500. Сообщение ISAKMP имеет заголовок ISAKMP и одну или более нагрузок (payload) как определено в RFC 2408. Узел, который начинает обмен, называется инициатор (initiator), узел, отвечающий на сообщение инициатора — ответчик (responder). В первой паре сообщений конечные точки договариваются об используемых алгоритмах шифрования, аутентификации, хэширования, группах Диффи-Хеллмана. Они конфигурируются администратором на устройстве. Алгоритм распределения ключей Диффи-Хеллмана используется для безопасной генерации общего секретного ключа для конечных точек, между которыми отсутствует защищенное соединение. Далее этот общий секрет используется для генерации значения, используемого для вычисления секретных ключей первой и второй фазы. Группа Диффи-Хеллмана определяется по номеру. Номер каждой группы соответствует длине ключа и типу криптографического генератора. Помимо согласования параметров, первая пара сообщений также включает обмен «cookie». Их использование может препятствовать некоторым попыткам DoS-атак, которые состоят в простом наводнении пакетами (flooding-атаки). Абсолютная защита от DoS-атак невозможна, но такие «cookie» обеспечивают возможность более быстрого ее определения. Вторая пара сообщений (3 и 4 сообщения) выполняет обмен Диффи-Хеллмана, используя параметры, согласованные в результате обмена первой парой сообщений. Инициатор и ответчик обмениваются открытыми значениями Диффи-Хеллмана и случайными значениями (nonce), необходимыми для обмена. Метод аутентификации, определенный при переговорах в первых сообщениях, влияет на содержимое сообщений второй пары. Всего определено четыре метода аутентификации: цифровая подпись, две формы аутентификации с открытым ключом, аутентификация на основе PSK. Сообщения, включающие аутентификацию на основе PSK или цифровой подписи, имеют аналогичные поля — Заголовок, KE (Key Exchange) и nonce. Сообщения, включающие аутентификацию с шифрованием открытым ключом, имеют поля Заголовок, KE (Key Exchange), зашифрованное nonce и идентификаторы обмена, защищенные общими ключами. Последние два сообщения (5 и 6) аутентифицируют обмен Диффи-Хеллмана. Другими словами, стороны обмена аутентифицируют друг друга. Как происходит эта аутентификация, зависит от ранее согласованного метода. При этом, несмотря на используемый метод аутентификации, нагрузка третьей пары сообщений шифруется с помощью информации, полученной в результате обмена второй парой сообщений. Подведем краткий итог: главный режим использует три пары сообщений. Каждая из этих пар сообщений имеет различное назначение. Первая пара сообщений согласует параметры IKE SA, вторая пара выполняет обмен ключами, третья пара взаимно аутентифицирует конечные точки соединения. Агрессивный режим (Aggressive Mode) предлагает быструю альтернативу главному режиму. Стороны договариваются об установлении IKE SA путем обмена тремя сообщениями, а не тремя парами сообщений. В первых двух сообщениях конечные точки договариваются об используемых алгоритмах, обмениваются открытыми значениями Диффи-Хеллмана, случайными значениями (nonce) и идентификациями. Второе и третье сообщения взаимно аутентифицируют инициатора и ответчика. В агрессивном режиме согласуются те же самые параметры, что и в главном режиме, определены те же методы аутентификации. Однако, несмотря на быстроту, агрессивный режим менее гибкий и безопасный. Так как обмен ключами по алгоритму Диффи-Хеллмана начинается с первого пакета, стороны не имеют возможности договориться о параметрах Диффи-Хеллмана. Обе стороны обмениваются информацией до того, как создана защищенная IKE SA. Таким образом, информация, подтверждающая идентичность в агрессивном режиме, не всегда скрыта. Если злоумышленник подключится к линии, он сможет определить стороны, выполняющие переговоры. Обмен фазы II Основная цель второй фазы — установить IPSec SA для фактического IPSec-соединения. В отличие от IKE SA, эта SA является однонаправленной. Это означает, что IPSec-соединение между двумя устройствами требует двух SA (по одной в каждом направлении). Пара SA (входящая и исходящая) создается путем обмена тремя сообщениями в быстром режиме (Quick Mode). Сам по себе быстрый режим не является законченным обменом. Он связан с фазой I, так как использует ключи, вычисленные в процессе ее выполнения. Все содержимое сообщений, которыми обмениваются в быстром режиме, за исключением заголовка ISAKMP, будет зашифровано алгоритмами и ключами, определенными в фазе I. Quick Mode выполняет переговоры об IPSec SA и обменивается случайными значениями (nonce), которые обеспечивают защиту от повторов. Nonce используются для создания нового материала ключа и предотвращения replay-атак, в результате которых могут быть созданы ложные SA. В первом сообщении инициатор обмена отправляет ключевой материал, nonce, предлагаемые параметры SA и HASH для аутентификации. По умолчанию Quick Mode вычисляет ключи из ключевого материала, созданного в фазе I. Если при настройке фазы II на устройстве была активирована функция Perfect Forward Secrecy (PFS), то для каждой SA, созданной в фазе II, будут полностью обновлены ключи путем дополнительного обмена Диффи-Хеллмана. Несмотря на то что PFS увеличивает издержки по установлению SA, она обеспечивает большую защиту, так как каждый ключ не связан с другим. Если какой-либо ключ будет скомпрометирован, атакующий не сможет получить доступ к другим IPSec SA. Во втором сообщении ответчик отправляет ключевой материал, nonce, выбранные параметры SA и HASH для аутентификации. В третьем сообщении инициатор отправляет HASH для аутентификации. Для каждой SA (одной входящей и одной исходящей) назначаются разные SPI (один SPI выбирает инициатор, другой — ответчик). Это гарантирует создание различных ключей для каждого направления. Как только ответчик подтверждает третье сообщение, SA устанавливаются, и в SAD создаются соответствующие записи. Обе IKE SA и IPSec SA обычно имеют ограниченное время жизни (lifetime). Если время жизни любой из SA подходит к концу, стороны должны создать новую SA через процесс смены ключей и использовать ее вместо предыдущей. Время жизни каждой SA можно задавать в настройках устройства. Информационный обмен В различные моменты времени стороны могут захотеть сообщить друг другу о возникших ошибках или уведомить о возникших событиях. Для выполнения этого определен информационный обмен IKE. Информационные обмены должны осуществляться только после выполнения обмена ключом, чтобы они были криптографически защищены. Это гарантирует, что неавторизованные сообщения не нарушат переговоры IPsec или преждевременно не завершат IPsec SA. С помощью информационного обмена одна конечная точка может сообщить другой, что определенная SA больше не будет использоваться. Так как сообщения информационного обмена помещаются в дейтаграммы UDP, и получатель не подтверждает их, то нет никаких гарантий, что другая конечная точка их получит. |