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

ПРОТОКОЛ ОБМЕНА КЛЮЧАМИ - IKE 8.1 Общие сведения Поскольку основным механизмом обеспечения безопасности данных протокола являются криптографические методы, участники защищенного соединения должны наладить обмен соответствующими криптографическими ключами. Обеспечить настройку процесса такого обмена можно вручную и автоматически. Первый способ допустим для небольшого количества достаточно статичных систем, а в общем случае это производится автоматически. Для автоматического обмена ключами по умолчанию используется Протокол управления ключами в Интернете (Internet Key Management Protocol - IKMP), иначе называемый Обмен ключами в Интернете (Internet Key Exchange - IKE). Дополнительно или альтернативно могут быть применены другие протоколы, такие как Kerberos или SKIP. IKE совмещает в себе три основных направления (отдельных протокола): - ISAKMP (Internet Security Association and Key Management Protocol) - протокол ассоциаций безопасности и управления ключами в интернете; это общее описание (framework) для обеспечения аутентификации и обмена ключей без указания конкретных прикладных алгоритмов; - Oakley (Oakley key determination protocol) - протокол определения ключей Окли; он описывает последовательности обмена ключами - моды (mode) и описывает предоставляемые ими функции; - SKEMI (Secure Key Exchange Mechanism for Internet) - механизм безопасного обмена ключами в Интернете; он описывает многофункциональные технологии, предоставляющие анонимность, неотрекаемость (аппелируемость) и быстрое обновление ключей; IKE содержит две фазы согласования ключей. В первой фазе происходит создание защищенного канала, во второй - согласование и обмен ключами, установление SA. Первая фаза использует один из двух режимов: основной (англ. Main Mode) или агрессивный (англ. Aggressive Mode). Различие между ними в уровне защищенности и скорости работы. Основной режим, более медленный, защищает всю информацию, передаваемую между узлами. Агрессивный режим для ускорения работы оставляет ряд параметров открытыми и уязвимыми для прослушивания, его рекомендуется использовать только в случае, когда критическим вопросом является скорость работы. Во второй фазе используется быстрый режим (англ. Quick Mode), названный так потому, что не производит аутентификации узлов, считая, что это было сделано в первой фазе. Эта фаза обеспечивает обмен ключами, с помощью которых происходит шифрование данных. Определим следующие нотации для дальнейшего использования: HDR - это заголовок ISAKMP, который определяет тип обмена. Запись HDR* означает, что содержимое зашифровано. SA - это содержимое переговоров SA с одним или более Proposals. Инициатор может предоставить несколько Proposals для переговоров; получатель должен выбрать только одну.

_b - это тело содержимого

. Например, SA_b есть все тело содержимого SA (минус общий заголовок ISAKMP), т.е. DOI, Situation, все Proposals и все Transforms, представленные Инициатором. CKY-I и CKY-R есть cookie Инициатора и cookie Получателя, соответственно, из ISAKMP-заголовка. g^xi и g^xr - это открытые значения Диффи-Хеллмана Инициатора и Получателя соответственно. КЕ - это содержимое обмена ключа, т.е. открытая информация, которой обмениваются в алгоритме Диффи-Хеллмана. Специального шифрования, используемого для содержимого КЕ, не существует. Nx - это содержимое nonce; x может быть i или r для ISAKMP Инициатора и Получателя соответственно. IDx - есть содержимое идентификации для <х>. Х может быть или для ISAKMP Инициатора и Получателя соответственно во время Фазы 1 переговоров; или или для Инициатора и Получателя соответственно во время Фазы 2. SIG - это содержимое подписи. Подписываемые данные зависят от обмена. СERT - это содержимое сертификата. HASH - это содержимое хэша, которое определяется методом аутентификации. prf (key, msg) - это псевдослучайная функция, часто хэш-функция, основанная на ключе, используемая для создания детерминированного выхода, который можно рассматривать как псевдослучайный. Prf используется как для получения ключа, так и для аутентификации (т.е. как МАС с ключом). SKEYID есть строка, полученная из секрета и известная только участникам обмена. SKEYID_e есть материал ключа, используемый ISAKMP для обеспечения конфиденциальности сообщений. SKEYID_а есть материал ключа, используемый ISAKMP для аутентификации своих сообщений. SKEYID_d есть материал ключа, используемый для получения ключей для не-ISAKMP безопасных ассоциаций. y определяет, что х зашифровано ключом y. => указывает на направление взаимодействия от Инициатора к Получателю (запрос). ? указывает на направление взаимодействия от Получателя к Инициатору (ответ). | обозначает конкатенацию информации. [x] обозначает, что х не является обязательным. Шифрование сообщения (когда указана * после ISAKMP заголовка) должно начинаться сразу после ISAKMP-заголовка. При защищенном взаимодействии все содержимые после ISAKMP заголовка должны шифроваться. Ключи шифрования создаются из SKEYID_e тем способом, который определен для каждого алгоритма. 8.2 Введение IKE представляет различные обмены как режимы, которые выполняются в одной из двух фаз. В течение Фазы 1 участники устанавливают безопасный аутентифицированный канал, по которому они будут взаимодействовать. Это называется ISAKMP SA. Для фазы 1 определено два режима: Main Mode и Aggressive Mode. Фаза 2 определяется тогда, когда уже установлены ISAKMP SA. определен для второй фазы обмена. реально ни с Фазой 1, ни с Фазой 2 не связан. Он следует за Фазой 1, но служит для установления новой группы, которая может использоваться при будущих переговорах. ISAKMP SA является двунаправленной. Это означает, что установив однажды, каждый участник может инициировать Quick Mode, Informational и New Group Mode-обмены. ISAKMP SA идентифицируется cookie Инициатора, которые следуют за cookie Получателя - роли каждого участника в Фазе 1 обмена определяют, какие cookie являются cookie Инициатора. Последовательность cookie, установленная в Фазе 1 обмена, продолжает идентификацию ISAKMP SA, независимо от направления обменов Quick Mode, Informational или New Group. Другими словами, cookie при изменении направления ISAKMP SA не должны меняться местами. В результате использования фаз ISAKMP может выполнять обмен ключа достаточно быстро. Кроме того, может требоваться единственная фаза 2 переговоров для создания нескольких SAs. Main Mode для Фазы 1 обеспечивает защиту идентификации. Когда нет необходимости в защите идентификации, может использоваться Aggressive Mode для уменьшения числа взаимных передач. Также следует заметить, что при аутентификации шифрованием с открытым ключом в Aggressive Mode также обеспечивается защита идентификации. Следующие атрибуты используются в IKE и о них договариваются участники ISAKMP SA. (Эти атрибуты принадлежат только ISAKMP SA, а не каким-то другим Безопасным Ассоциациям, для которых ISAKMP может вести переговоры от имени других сервисов.) - алгоритм шифрования; - хэш-алгоритм; - метод аутентификации; - информация о группе для алгоритма Диффи-Хеллмана; Все эти атрибуты обязательны, и о них должны вестись переговоры. Кроме того, возможны дополнительные переговоры о псевдослучайной функции (). Если prf в переговорах не участвует, то версия HMAC хэш-алгоритма, о котором договорились, используется в качестве псевдослучайной функции. Группа Диффи-Хеллмана задается по номеру или путем определения всех атрибутов группы. Атрибуты группы не должны зависеть от значений группы, определенной в предыдущем случае. 8.3 Обмены Существует два основных режима, используемых для установления аутентифицированного обмена ключа: Main Mode и Aggressive Mode. Каждый из них создает аутентифицированный ключевой материал из обмена Диффи-Хеллмана. Обязательно должен быть реализован Main Mode. Кроме того, Quick Mode должен быть реализован в качестве механизма для создания нового материала ключа и переговоров неISAKMP SA (т.е. AH SA и ESP SA). В дополнение к этому New Group Mode может быть реализован в качестве механизма определения частных групп для обменов ДиффиХеллмана. Содержимое SA должно предшествовать всем другим содержимым в Фазе 1 обмена. Кроме этого не существует никаких других требований ни к содержимым ISAKMP в любом сообщении, ни к их упорядоченности. Открытое значение Диффи-Хеллмана передается в содержимом КЕ в Фазе 1, оно может передаваться в Фазе 2 обмена, если требуется PFS. Длина открытого значения ДиффиХеллмана определяется во время переговоров. Длина содержимого nonce колеблется между 8 и 256 байтами. Main Mode является реализацией обмена с защищенной идентификацией: в первых двух сообщениях договариваются о политике; в следующих двух сообщениях обмениваются открытыми значениями Диффи-Хеллмана и вспомогательными данными (т.е. nonces), необходимыми для обмена; последние два сообщения аутентифицируют обмен ДиффиХеллмана. Метод аутентификации является частью переговоров начального ISAKMPобмена, влияющий на композицию содержимых, но не на их цель. В первых двух сообщениях Aggressive Mode договариваются о политике, обмениваются открытыми значениями Диффи-Хеллмана и вспомогательными данными, необходимыми для обмена, а также идентификациями. Второе сообщение аутентифицирует получателя. Третье сообщение аутентифицирует инициатора. Заключительное сообщение может не посылаться по ISAKMP SA, позволяя каждому участнику откладывать в случае необходимости вычисление экспоненты до завершения переговоров. Во время переговоров инициатор представляет получателю предложения о потенциальных безопасных ассоциациях. Получатель не должен модифицировать атрибуты любого предложения. Если инициатор обмена замечает, что значения атрибутов были изменены или атрибуты были добавлены или уничтожены из предложенного метода, ответ должен быть отброшен. Допускаются четыре различных метода аутентификации как для Main Mode, так и для Aggressive Mode - цифровая подпись, две формы аутентификации шифрованием открытым ключом и предварительно распределенным секретом. Значение SKEYID вычисляется отдельно для каждого метода аутентификации. Для подписей: SKEYID = prf (Ni_b | Nr_b, g^xy) Для шифрования открытым ключом: SKEYID = prf ( HASH (Ni_b | Nr_b), CKY-I | CKY-R) Для предварительно распределенного секрета: SKEYID = prf (pre-shared-key, Ni_b | Nr_b) Результатом как Main Mode, так и Aggressive Mode являются три группы аутентифицированного материала ключа: SKEYID_d = prf (SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf (SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf (SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) и согласованная политика по защите дальнейших коммуникаций. Значения 0, 1 и 2 представлены в одном октете. Ключ, используемый для шифрования, получается из SKEYID_e с помощью специфицированного алгоритма. Для аутентификации обмена инициатора протокола создается HASH_I и для получателя создается HASH_R, где HASH_I = prf (SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b) HASH_R = prf (SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b) При аутентификации с помощью цифровых подписей HASH_I и HASH_R подписаны и верифицированы; при аутентификации либо шифрованием открытым ключом, либо preshared ключами HASH_I и HASH_R непосредственно аутентифицируют обмен. Все содержимое ID (включая тип ID, порт и протокол, но исключая общий заголовок) хэшировано как в HASH_I, так и в HASH_R. Метод аутентификации, о котором договорились, влияет на содержимое и использование сообщений для Фазы 1 режимов, но не на их цели. При использовании для аутентификации открытых ключей обмен Фазы 1 может быть завершен либо использованием подписей, либо использованием шифрования открытым ключом (если алгоритм поддерживает это). Далее следуют обмены Фазы 1 с различными опциями аутентификации. 8.4 IKE Фаза 1 с аутентификацией с помощью подписей При использовании подписей вспомогательной информацией, которой обмениваются при второй круговой передаче, являются nonces; обмен аутентифицируется путем подписывания хэша. Main Mode с аутентификацией с помощью подписи выполняется в соответствии с рисунком 8.1. Рисунок 8.1 - Main Mode с аутентификацией с помощью подписи Aggressive Mode с аутентификацией с помощью подписи выполняется в соответствии с рисунком 8.2. Рисунок 8.2 - Aggressive Mode с аутентификацией с помощью подписи В обоих режимах подписанные данные, SIG_I или SIG_R, являются результатом алгоритма цифровой подписи, примененным к HASH_I или HASH_R соответственно. В общем случае подпись выполняется поверх HASH_I и HASH_R, при этом используется prf или версия НМАС для хэш-функции (если участники не договорились о prf). Могут быть дополнительно переданы один или более сертификатов. 8.5 Фаза 1 аутентификации шифрованием открытым ключом При использовании шифрования открытым ключом для аутентификации обмена применяются зашифрованные nonces. Каждый участник имеет возможность восстановить хэш (доказывая, что другой участник дешифровал nonce), аутентифицируя обмен. Для того чтобы выполнить шифрование открытым ключом, инициатор должен уже иметь открытый ключ получателя. В случае, когда получатель имеет несколько открытых ключей, инициатор использует хэш сертификата, передаваемой как часть третьего сообщения. При таком способе получатель может определить, какой закрытый ключ использовать для дешифрования зашифрованного содержимого и защищенной идентификации. В дополнение к nonce идентификации участников (IDii и IDir) также зашифрованы открытым ключом другого участника. Если методом аутентификации является шифрование открытым ключом, то содержимые nonce и идентификации должны быть зашифрованы открытым ключом другого участника. Шифруется только тело содержимого, заголовки содержимого не шифруются. При использовании для аутентификации шифрования Main Mode выполняется в соответствии с рисунком 8.3. Рисунок 8.3 - Аутентификация шифрования Main Mode Aggressive Mode выполняется в соответствии с рисунком 8.4. Где HASH (1) есть хэш сертификата, который инициатор использовал для шифрования nonce и идентификации. Использование шифрования для аутентификации обеспечивает невозможность отказа от обмена. В отличие от других методов аутентификации, аутентификация шифрованием открытым ключом допускает защиту идентификации в Aggressive Mode. Рисунок 8.4 - Аутентификация шифрования Aggressive Mode 8.6 Фаза 1 аутентификации с Revised Mode шифрования открытым ключом Аутентификация шифрованием открытым ключом имеет важное преимущество по сравнению с аутентификацией с использованием подписей. Ценой являются 4 операции открытого ключа - две операции шифрования открытым ключом и две операции дешифрования закрытым ключом. Данный метод аутентификации сохраняет преимущества аутентификации с использованием шифрования с открытым ключом, но делает это с использованием половины операций открытого ключа. В данном режиме nonce все еще зашифрован с использованием открытого ключа противоположной стороны, однако идентификация противоположной стороны (и сертификат, если он послан) шифруется с использованием алгоритма симметричного шифрования, о котором договорились (из содержимого SA) с ключом, полученным из nonce. Это решение добавляет минимальную сложность, и на каждой стороне используется две операции открытого ключа. Дополнительно содержимое Key Exchange также зашифровано с использованием того же самого ключа. Это обеспечивает дополнительную защиту против криптоанализа обмена Диффи-Хеллмана. Как и в методе аутентификации шифрованием открытым ключом содержимое HASH может быть послано для идентификации сертификата, если получатель имеет несколько сертификатов. Если содержимое HASH послано, оно должно быть первым содержимым сообщения второго обмена, и за ним должен следовать зашифрованный nonce. Если содержимое HASH не послано, первым содержимым сообщения второго обмена должен быть зашифрованный nonce. Дополнительно инициатор может послать содержимое с сертификатом для указания получателю использованного открытого ключа. При использовании для аутентификации пересмотренного режима шифрования Main Mode определяется в соответствии с рисунком 8.5. Рисунок 8.5 - Аутентификация пересмотренного режима шифрования Main Mode Aggressive Mode, аутентифицируемый с помощью пересмотренного метода шифрования, определяется в соответствии с рисунком 8.6. Рисунок 8.6 - Аутентификация пересмотренного режима шифрования Aggressive Mode Где HASH (1) была определена выше. Ke_i и Ke_r являются ключами для алгоритма симметричного шифрования, о котором участники договорились при обмене содержимом SA. Шифруется только тело содержимых (как в операциях с открытым ключом, так и симметричного шифрования), общие заголовки содержимого не шифруются. Симметричные ключи шифрования получаются из дешифрованных nonces следующим образом. Прежде всего вычисляются значения Ne_i и Ne_r: Ne_i = prf (Ni_b, CKY-I) Ne_r = prf (Nr_b, CKY-R) Если длина выхода prf, о которой договорились, больше или равна длине ключа, необходимой для шифрования, Ke_i и Ke_r получаются из старших битов Ne_i и Ne_r, соответственно. Если требуемая длина Ke_i и Ke_r превышает длину выхода prf, необходимое количество битов получается после повторным применением prf и конкатенацией результата необходимое число раз. Например, если алгоритм шифрования требует 320 битов ключа и выход prf дает только 128 бит, в качестве Ke_i берутся старшие биты K, где K = K1 | K2 | K3 K1 = prf (Ne_i, 0) K2 = prf (Ne_i, K1) K3 = prf (Ne_i, K2) Для краткости показано получение только Ke_i; Ke_r получается аналогично. Значение 0 при вычислении K1 является одним октетом. Заметим, что Ne_i, Ne_r, Ke_i и Ke_r после использования должны быть сброшены. Существуют требования только на размещение дополнительного содержимого HASH и обязательного содержимого nonce, более никаких содержимых не требуется. Все содержимые - в любом порядке - следующие за зашифрованным nonce, должны быть зашифрованы с ключом Ke_i или Ke_r в зависимости от направления. 8.7 Фаза 1 аутентификации с Pre-Shared ключом Ключ, полученный некоторым внешним механизмом, может также использоваться для аутентификации обмена. Когда выполняется pre-shared аутентификация, Main Mode определяется в соответствии с рисунком 8.7. Рисунок 8.7 - Определение Main Mode при выполнении pre-shared аутентификации Aggressive режим с pre-shared ключом описывается в соответствии с рисунком 8.8. При использовании аутентификации с pre-shared ключом с Main Mode ключ может только идентифицироваться по IP-адресу противоположной стороны, так как HASH_I должен быть вычислен до того, как инициатор обработает IDir. Aggressive Mode охватывает более широкий диапазон идентификаторов используемого pre-shared секрета. Дополнительно Aggressive Mode позволяет двум участникам поддерживать несколько различных preshared ключей и идентификаций для отдельного обмена. Рисунок 8.8 - Определение Aggressive Mode при выполнении pre-shared аутентификации 8.8 Фаза 2 - Quick Mode Quick Mode сам по себе законченным обменом не является (это означает, что он связан с фазой 1 обмена), он используется как часть процесса переговоров SA (фаза 2) для получения материала ключа и обсуждений разделяемой политики для не-ISAKMP SAs. Информация, которой обмениваются в Quick Mode, должна быть защищена ISAKMP SA, т.е. все содержимые за исключением заголовка ISAKMP должны быть зашифрованы. В Quick Mode содержимое HASH должно непосредственно следовать за заголовком ISAKMP и содержимое SA должно непосредственно следовать за HASH. Данный HASH аутентифицирует сообщение и обеспечивает доказательство существования. Quick Mode проводит переговоры об SA и обменивается nonces, которые обеспечивают защиту от повторов. Nonces используются для создания нового материала ключа и предотвращения replay-атак, создающих ложные SA. Можно произвести обмен дополнительным содержимым KE, чтобы допустить дополнительный обмен экспонентами Диффи-Хеллмана при Quick Mode. Базовый Quick Mode (без содержимого KE) обновляет материал ключа, полученный из экспоненты в Фазе 1. Это не обеспечивает PFS. При использовании дополнительного содержимого KE вычисляется дополнительная экспонента и тем самым обеспечивается PFS для материала ключа. Все предложения, сделанные в течение Quick Mode, являются логически взаимосвязанными и должны быть согласованы. Например, если послано содержимое KE, атрибут, описывающий группу Диффи-Хеллмана, должен быть включен в каждый Transform каждой Proposal каждой SA, о которой ведутся переговоры. Аналогично, если используются идентификации клиента, они должны применяться к каждой SA, о которой ведутся переговоры. Quick Mode определяется в соответствии с рисунком 8.9. Рисунок 8.9 - Определение Quick Mode Где: HASH (1) есть prf поверх сообщения id (M-ID) из ISAKMP заголовка, присоединенного ко всему сообщению; HASH (2) идентичен HASH (1) за исключением nonce инициатора - Ni, минус заголовок содержимого, который добавляется после M-ID, но перед завершенным сообщением. Добавление nonce в HASH (2) сделано для доказательства существования; HASH (3) - для доказательства существования - является prf поверх нулевого значения, представленного одним октетом, за которым следует конкатенация id сообщения и два nonces - инициатора и получателя - минус заголовок содержимого. Другими словами, хэши предыдущего обмена есть: HASH (1) = prf (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ]) HASH (2) = prf (SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ]) HASH (3) = prf (SKEYID_a, 0 | M-ID | Ni_b | Nr_b) За исключением содержимых HASH, SA и необязательных ID, не существует содержимых, для которых определены ограничения упорядоченности в Quick Mode. HASH (1) и HASH (2) могут отличаться от приведенных выше, если порядок содержимых в сообщении отличается от приведенного выше или если в сообщение включены дополнительные содержимые. Если PFS не является необходимой и обмен содержимым KE не выполняется, то новый материал ключа определяется как KEYMAT = prf (SKEYID_d, protocol | SPI | Ni_b | Nr_b) Если PFS требуется и участники обмениваются содержимым KE, то новый материал ключа определяется как KEYMAT = prf (SKEYID_d, g (qm) ^xy | protocol | SPI | Ni_b | Nr_b) Где g (qm) ^xy является разделяемым секретом из одноразового обмена Диффи-Хеллмана для данного Quick Mode. В любом случае protocol и SPI берутся из ISAKMP Proposal Payload, содержащим Transform, о котором договариваются. Единственным результатом переговоров SA являются две безопасные ассоциации - одна входящая и одна выходящая. Различные SPIs для каждой SA (один выбирается инициатором, другой получателем) гарантируют различные ключи для каждого направления. SPI, выбираемые получателем, используются для получения KEYMAT для данной SA. В ситуации, когда количество требуемого материала ключа больше, чем предлагается prf, KEYMAT расширяется конкатенацией результатов до тех пор, пока не будет получено необходимое количество материала ключа. Другими словами KEYMAT = K1 | K2 | K3 | _ Где K1 = prf (SKEYID_d, [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b) K2 = prf (SKEYID_d, K1 | [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b) K3 = prf (SKEYID_d, K2 | [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b) Данный материал ключа (с PFS или без, полученный непосредственно или с помощью конкатенации) должен использоваться в SA, о которой ведутся переговоры. Это определяет ключи, которые получаются из материала ключа. Используя Quick Mode, за один обмен можно договориться о нескольких SAs и ключах в соответствии с рисунком 8.10. Рисунок 8.10 - Определение SAs и ключей при использовании Quick Mode 8.11 Проблемы безопасности Internet Key Exchange (IKE) Сила ключа, полученная из обмена Диффи-Хеллмана, использующего определенную группу, зависит от силы самой группы, используемой длины экспоненты и энтропии, обеспечиваемой используемым генератором случайных чисел. Группа Диффи-Хеллмана по умолчанию (номер один) при использовании сильного генератора случайных чисел и экспоненты не менее 160 бит является достаточной при использовании для DES. Группы со второй по четвертую обеспечивают большую безопасность. Реализации должны помнить об этой общей оценке при определении политики и обсуждаемых параметрах безопасности. Это не является ограничением на сами группы Диффи-Хеллмана. Ничто не препятствует IKE использовать более сильные группы и ничто не ослабляет силу этих групп. Расширяемый каркас IKE поддерживает определение многих групп; использование групп эллиптических кривых увеличивает силу при использовании меньших чисел. В ситуациях, когда определенные группы не обеспечивают необходимую силу, можно использовать New Group Mode для обмена группой Диффи-Хеллмана, которая обеспечит ее. Предполагается, что экспоненты Диффи-Хеллмана для данного обмена после использования удаляются из памяти. В частности, эти экспоненты не должны получаться из долго живущих секретов, подобных seed для псевдослучайного генератора. Хотя сообщения последней круговой передачи в Main Mode (и не обязательно последнее сообщение Aggressive Mode) являются зашифрованными, они не являются аутентифицированными. Активная атака замены для зашифрованного текста может привести к разрушению содержимого. Если такая атака имела место для обязательных содержимых, это будет определено и приведет к падении аутентификации, но если это произошло для дополнительных содержимых (например, для содержимых уведомления, измененных в последнем сообщении Main Mode обмена), это может быть не определено. Материал по желанию. 9. РАСШИРЕННЫЙ ОБЗОР БЕЗОПАСНЫХ АССОЦИАЦИЙ (КОНТЕКСТОВ) 9.1 Основные определения Понятие "безопасные ассоциации" (Security Association - SA) является фундаментальным в IPSec. SA есть симплексное (однонаправленное) логическое соединение, создаваемое для обеспечения безопасности. Весь трафик, передаваемый по SA, некоторым образом обрабатывается в целях обеспечения безопасности. И AH, и ESP используют в своей работе SAs. Одной из основных функций IKE является установление SA. Далее приводятся различные аспекты управления SA, определим требуемые характеристики управления политикой SA, обработку трафика и технологии управления SA. SA есть совокупность параметров соединения, которые дают возможность сервисам обеспечивать безопасный трафик. SA определяет использование AH или ESP. Если к потоку трафика применяются оба протокола, AH и ESP, то создаются две SAs. При двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется два SA (по одному на каждое направление). SA однозначно определяется тройкой, состоящей из Security Parameter Index (SPI), IP Destination Address (адресом назначения) и идентификатора протокола безопасности (AH или ESP). В принципе адрес назначения может быть единственным адресом, широковещательным (broadcast) адресом или групповым (multicast) адресом. Однако механизм управления SA в настоящее время определяется только для единственной SA. Следовательно, SAs будут описаны в контексте point-to-point соединения, даже если концепция также применяется в случае point-to-multipoint. Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка. Другим режимом SA является режим туннелирования. Если хотя бы одним из концов соединения является шлюз безопасности, то SA обязательно должна выполняться в туннелирующем режиме. SA между двумя шлюзами безопасности всегда находится в туннелирующем режиме, так же, как и SA между хостом и шлюзом безопасности. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае SNMP-команд, шлюз безопасности рассматривается как хост, и допустим транспортный режим. Два хоста могут при желании так же устанавливать туннелирующий режим. B туннелирующем режиме SA существует "внешний" IP-заголовок, который определяет пункт назначения IPSec, и "внутренний" IP-заголовок, который определяет конечный пункт назначения для пакета. Заголовок протокола безопасности расположен после внешнего IP-заголовка и перед внутренним IP-заголовком. Если AH используется в туннелирующем режиме, части внешнего IP заголовка являются защищенными, как и весь туннелируемый IP-пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, зашита обеспечивается только для туннелируемого пакета, а не для внешнего IP-заголовка. 9.2 Функциональность Набор реализуемых SA сервисов безопасности зависит от выбранного протокола безопасности, режима SA, конечных точек SA и выбора дополнительных сервисов в протоколе. Например, AH обеспечивает аутентификацию исходных данных и целостность соединения для IP датаграм (в дальнейшем будем называть это "аутентификацией"). "Точность" сервиса аутентификации является функцией от степени детализованности SA, для которой используется AH. AH также предоставляет анти-replay сервис (целостность отдельной последовательности) для получателя, помогая предотвратить атаки отказа в сервисе. AH применяется, когда не требуется конфиденциальность. AH также обеспечивает аутентификацию отдельных частей IP-заголовка, за исключением изменяющихся частей IP-заголовка. ESP обеспечивает конфиденциальность трафика. Сила сервиса конфиденциальности зависит от используемого алгоритма шифрования. ESP также может дополнительно обеспечивать аутентификацию. Область аутентификации, обеспечиваемая ESP, является более узкой по сравнению с AH, т.е. IP-заголовок (заголовки), <внешние> по отношению к ESP заголовку, не защищены. Если аутентификация нужна только протоколам более высокого уровня, то аутентификация ESP является подходящей альтернативой, причем более эффективной, чем использование AH, инкапсулирующего ESP. Если для ESP SA используется аутентификация, получатель также может выбрать усиление использованием анти-replay сервиса с теми же самыми возможностями, что и AH антиreplay сервис. Хотя и конфиденциальность, и аутентификация являются необязательными, оба сервиса не могут быть опущены. По крайней мере, один из них должен присутствовать. Использование туннелирующего режима позволяет зашифровывать внутренние IPзаголовки, скрывая отправителя и получателя. Следует заметить, что сильно детализированные SAs обычно являются более уязвимыми для анализа трафика, чем слабо детализированные. 9.3 Комбинации SA Иногда политика безопасности может требовать комбинации сервисов для конкретного потока трафика. В таких случаях необходимо установить несколько SAs для реализации принятой политики безопасности. Термин "узел безопасных ассоциаций" или "узел SA" применяется к последовательности SA, через которые должен проходить трафик для обеспечения требуемой политики безопасности. Заметим, что SAs, которые образуют узел, могут заканчиваться в различных точках. Безопасные aссоциации могут комбинироваться в узлы двумя способами: транспортное соседство, в соответствии с рисунком 9.1, и повторное туннелирование: а) транспортное соседство означает применение более одного протокола для одной и той же IP-датаграммы без использования туннелирования; данный подход при комбинировании AH и ESP допускает только один уровень комбинации; дальнейшие вложенные поля не добавляют преимущества (в случае использования одинаково сильных алгоритмов для каждого протокола); Рисунок 9.1 - Транспортное соседство SAs б) повторное туннелирование означает применение нескольких протоколов, выполняющих туннелирование; Существует три основных варианта повторного туннелирования: а) оба конца SAs являются одинаковыми, в соответствии с рисунком 9.2 - внутренний и внешний туннели могут быть каждый AH или ESP, хотя маловероятно, что протоколы будут одинаковые, например, AH внутри AH или ESP внутри ESP; Рисунок 9.2 - Повторное туннелирование SAs - оба конца одинаковы б) один конец нескольких SAs является одним и тем же, в соответствии с рисунком 9.3 внутренний и внешний туннели могут оба быть AH или ESP; Рисунок 9.3 - Повторное туннелирование SAs - один конец общий в) ни один из концов нескольких SAs не является одним и тем же, в соответствии с рисунком 9.4 - каждый внутренний и внешний туннели могут быть AH или ESP; Рисунок 9.4 - Повторное туннелирование SAs - оба конца разные Эти два подхода также могут комбинироваться, например, узел SA может быть сконструирован из одного SA туннелирующего режима и одного или двух SAs транспортного режима, применяемых последовательно. 9.4 Базы данных безопасной ассоциации Многие детали, связанные с обработкой IP-трафика в реализации IPSec не являются предметом стандартизации. Некоторые внешние аспекты обработки должны быть стандартизованы для обеспечения интероперабельности IPSec. Существуют две БД: БД Политики Безопасности (SPD) и БД Безопасной Ассоциации (SAD). Первая описывает политики, которые определяют характер обработки всего IP трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Определим также понятие Селектора как множества значений полей IP протокола и протокола более высокого уровня, которые используются БД Политики Безопасности для отображения трафика на SA. Каждый сетевой интерфейс, для которого необходима обработка IPSec, требует определения баз данных для входящего и исходящего трафика. 9.4.1 База данных политики безопасности (SPD) В конечном счете, SA используется для осуществления политики безопасности в окружении IPSec. Таким образом, существенным элементом выполнения SA является лежащая в основе База Данных Политики Безопасности (SPD), которая определяет, какие сервисы обрабатывают IP датаграммы и каким образом. Форма БД и ее интерфейс находятся вне области стандартизации. Тем не менее определим основные возможности управления, которые должны быть представлены, чтобы системный администратор мог управлять применением IPSec к трафику, передаваемому или получаемому хостом или проходящему через шлюз безопасности. SPD должна рассматриваться при обработке всего трафика (входящего и исходящего), включая не - IPSec-трафик. Для того чтобы это поддерживать, SPD требует различных записей для входящего и выходящего трафика. Можно считать, что это отдельные SPDs (входящая и выходящая). Кроме того, отдельная SPD должна существовать для каждого IPSec-интерфейса. SPD должна распознавать трафик, который разрешен защитой IPSec, и трафик, которому разрешено проходить IPSec без обработки. Для любой выходящей или входящей датаграммы существует три возможных способа обработки: отбросить датаграмму, обойти IPSec или применить IPSec. Первый вариант означает, что трафик не разрешен для хоста, не может пересекать шлюз безопасности или не может быть доставлен на уровень приложения. Второй вариант означает, что трафику разрешено проходить без дополнительной IPSec-защиты. Третий вариант означает, что к трафику применяется IPSec защита и для такого трафика SPD должна специфицировать применяемые сервисы безопасности, применяемые протоколы, используемые алгоритмы и т.д. Каждая реализация IPSec должна иметь программный интерфейс, который позволяет системному администратору управлять SPD. SPD должна определять, какие действия должны быть выполнены в том или ином случае. Таким образом, программный интерфейс должен позволять специфицировать обработку, применяемую к любому пакету, входящему или выходящему из системы. Интерфейс управления для SPD должен допускать создание последовательности записей, и должна поддерживаться упорядоченность этих записей. Возможно использование символа <*> в различных полях. Определим стандартный набор элементов SPD, который должны поддерживать все реализации IPSec. SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SAs. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPSec. Если применяется обработка IPSec, запись содержит описание SA (или узла SA), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС/SHA-1. Записи SPD должны быть упорядочены, и SPD должна всегда просматриваться в одном и том же порядке. Это требование является необходимым, чтобы воздействие на обрабатываемый трафик записей SPD было детерминированным. Так как политика безопасности может требовать, чтобы более одной SA применялось к трафику в определенной последовательности, запись политики в SPD должна эту последовательность определять. SA (или узел SA) может быть хорошо структурирована или грубоструктурирована в зависимости от селекторов, используемых для определения трафика, обрабатываемого SA. Например, весь трафик между двумя хостами может быть направлен через единственную SA, и может быть определен лишь один набор сервисов безопасности. В другом случае трафик между парой хостов может направляться через несколько SAs, в зависимости от используемых приложений, с различными сервисами безопасности, предоставляемыми различными SAs. Аналогично, весь трафик между парой шлюзов безопасности может быть направлен через единственную SA, или для каждой взаимодействующей пары хостов может быть определена своя SA. 9.4.2 База данных Безопасной Ассоциации (SAD) В IPSec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPSec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для поддержки SA в реализации IPSec. Для входящей обработки следующие поля пакета используются для поиска SA в SAD: а) IP адрес назначения внешнего заголовка: IPv4- или IPv6-адрес назначения. б) Протокол IPSec: AH или ESP, используемый в качестве индекса SA в данной БД. Определяет протокол IPSec, применяемый к трафику для данной SA. в) SPI: 32-битное значение, применяемое для идентификации различных SA, заканчивающихся одним и тем же адресом назначения и использующих один и тот же IPSec-протокол. Следующие поля SAD используются для IPSec-обработки: а) Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в AH или ESP заголовках (используется только для исходящего трафика). б) Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызывать событие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика). в) Anti-Replay Window: 32-битный счетчик или битовая карта (или некий эквивалент), используемые для проверки, является ли входящий AH- или ESP-пакет повтором. (Используется только для входящего трафика. Замечание: если anti-reply сервис не используется получателем, например, в случае ручных ключей SA, когда anti-reply window не используется.). д) Алгоритм аутентификации для AH, ключи и т.д. е) Алгоритм шифрования для ESP, ключи, режим, IV и т.д. ж) Алгоритм аутентификации для ESP, ключи и т.д. Если сервис аутентификации не выбран, данное поле будет нулевым. и) Время жизни данной SA: интервал времени, после которого SA должна быть заменена новой SA (и новым SPI) или завершение SA, а также определения того, какое из этих действий должно выполняться. Это может быть выражено в виде времени или количества байтов, или и того, и другого одновременно. Реализации должны поддерживать оба типа времени жизни и одновременное применение обоих типов. Если используется время и если IKE задействует сертификаты Х.509 для установления SA, то время жизни SA должно входить в допустимый интервал для сертификатов. В этом смысле как инициатор, так и получатель ответственны за установление корректного времени жизни SA. Должно быть два типа времени жизни: soft - время жизни, по истечении которого выдается предупреждение начать действия по замене SA, и hard - время жизни, по истечении которого текущая SA завершается. Режим IPSec-протокола: туннель или транспорт. Определяет применяемый режим AH или ESP к трафику для данной SA. 9.5 Примеры комбинаций SA Приведем четыре примера комбинаций SA, которые должны поддерживаться IPSecхостами и шлюзами безопасности. Дополнительные комбинации AH и/или ESP в туннелирующем и/или транспортном режимах могут поддерживаться по усмотрению разработчиков. Реализации должны иметь возможность создавать и обрабатывать эти четыре комбинации. Введем следующие обозначения в соответствии с рисунком 9.5. = одна или более SA (AH или ESP, транспорт или туннель); соединение (или административная граница); Нх хост х; SGx шлюз безопасности х; Х* Х поддерживает IPsec. Рисунок 9.5 - Условные обозначения Замечание: рассматриваемые ниже безопасные ассоциации могут быть как AH, так и ESP. Режим (туннель или транспорт) определяется характером конечных точек. Для host-to-host SAs-режим может быть как транспортным, так и туннелирующим. В данном случае как транспортный, так и туннелирующей режим могут быть хостами в соответствии с рисунками 9.6 и 9.7. Заголовки в пакете между Н1 и Н2 должны выглядеть в соответствии с таблицей 1. Рисунок 9.6 - Вариант 1. Обеспечение end-to-end безопасности между двумя хостами через Internet (или intranet) Таблица 1. Последовательность заголовков при соединении Host-Host Transport Tunnel 1. [IP1] [AH] [upper] 1. [IP2] [AH] [IP1] [upper] 2. [IP1] [ESP] [upper] 2. [IP2] [ESP] [IP1] [upper] 3. [IP1] [AH] [ESP] [upper] Рисунок 9.7 - Вариант 1. Обеспечение end-to-end безопасности между двумя хостами через Internet (или Intranet) Во втором варианте требуется только туннелирующий режим в соответствии с рисунком 9.8. При этом заголовки в пакете между SG1 и SG2 должны выглядеть в соответствии с таблицей 2. Рисунок 9.8 - Вариант 2. Создание простых виртуальных частных сетей Таблица 2. Последовательность заголовков при соединении SG-SG Tunnel 1. [IP2] [AH] [IP1] [upper] 2. [IP2] [ESP] [IP1] [upper] Рисунок 1.11 - Варианты 3 и 4 Вариант 3. Комбинация вариантов 1 и 2 путем добавления end-to-end безопасности между хостами отправителя и получателя. Для хостов или шлюзов безопасности не вводится новых требований, кроме требования, чтобы шлюз безопасности был сконфигурирован для прохождения IPSec-трафика (включая ISAKMP трафик) для хостов позади него. Вариант 4. Рассматривается случай, когда удаленный хост (Н1) использует Internet для достижения firewall'a организации ( SG2) и затем получает доступ к некоторому серверу или другой машине (Н2). Удаленный хост может быть мобильным хостом (Н1), подсоединяющимся по dial up к локальному РРР-серверу (на диаграмме это не показано) по Internet и затем проходящему по Internet к firewall организации (SG2) и т.д. Между Н1 и SG2 возможен только туннелирующий режим. Вариант для SA между Н1 и SG2 может быть быть один из тех, что представлены в варианте 2. Альтернатива для SA между Н1 и Н2 должна быть одной из тех, что представлены в варианте 1. В данном варианте отправитель должен применять транспортный заголовок перед туннелирующим заголовком. Следовательно, интерфейс управления в реализациях IPSec должен поддерживать конфигурацию SPD и SAD, гарантирующую данную упорядоченность заголовка IPSec. Поддержка дополнительных комбинаций AH и ESP не является обязательной. Дополнительные комбинации могут неблагоприятно сказываться на интероперабельности. 9.6 SA и Управление Ключом IPSec поддерживает как ручные, так и автоматически созданные SA и соответствующее управление криптографическими ключами. Протоколы AH и ESP практически не зависят от используемых технологий управления ключом, хотя эти технологии могут некоторым образом влиять на сервисы безопасности, предоставляемые протоколами. Например, дополнительные anti-replay сервисы требуют автоматического управления SA. Более того, детализированность используемого распределения ключа определяет детализированность предоставляемой аутентификации. Простейшей формой управления является ручное управление, при котором администратор вручную конфигурирует каждую систему материалом ключа и данными управления безопасной ассоциацией. Ручные технологии применяются в маленьких, статичных окружениях, и они не масштабируются. Например, компания может создать VPN, используя IPSec на хостах. Если количество хостов мало, и если все хосты расположены в пределах одного административного домена, то возможно применение ручных технологий управления. В данном случае хост должен выборочно защищать трафик и от других хостов в организации, используя вручную сконфигурированные ключи, допуская незащищенный трафик для других получателей. Данные технологии можно задействовать и в том случае, когда только выборочные коммуникации должны быть безопасны. Аналогичный аргумент может быть применен для использования IPSec в организации с небольшим числом хостов и/или шлюзов. Широкое использование IPSec требует стандартного для Internet, масштабируемого, автоматического протокола управления SA. Такая поддержка необходима для использования anti-replay возможностей AH и ESP и для возможности создания SAs. Протоколом автоматического управления ключом по умолчанию является IKE, но могут быть реализованы и другие протоколы автоматического управления ключом. Использование IPSec навязывает высокую вычислительную стоимость на хостах и шлюзах безопасности, которые реализуют эти протоколы. Эта цена связана с памятью, необходимой для структур данных IPSec, вычисление значений проверки целостности, шифрование и дешифрование, а также дополнительное управление пакетом. Использование протоколов управления SA/ ключом, особенно тех, которые реализуют криптографию с открытым ключом, также добавляет соответствующую вычислительную стоимость в использование IPSec. Использование IPSec также увеличивает стоимость компонентов, осуществляющих пересылку и роутинг в инфраструктуре Internet, но не реализующих IPSec. Это происходит из-за возрастания размера пакета в результате добавления заголовков AH и/или ESP, AH- и ESP-туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве примеров это возрастание не будет сильно влиять на инфраструктуру Internet.