Архитектура безопасности для IP (часть 2)

Фазы переговоров

ISAKMP предполагает две фазы переговоров. Во время первой фазы две сущности ( ISAKMP -серверы) договариваются о том, как защищать дальнейший трафик переговоров, устанавливая ISAKMP SA. Эта ISAKMP SA затем используется для защиты переговоров о требуемой SA.

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

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

Во-первых, ISAKMP серверы могут уменьшить время установления первой фазы до нескольких секунд. Это позволяет устанавливать несколько SAs между двумя участниками за одно и то же время с начала соединения.

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

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

Идентификация Безопасных Ассоциаций

Хотя при установлении безопасных каналов между системами ISAKMP не может предполагать существования сервисов безопасности, должна обеспечиваться некоторая степень защиты. Следовательно, SA ISAKMP отличается от остальных типов SA, и ее идентификация отличается от идентификации других типов SA. ISAKMP использует два поля cookie в заголовке ISAKMP для идентификации ISAKMP SAs. Message ID в ISAKMP Header и поле SPI в Proposal payload используются при установлении SA для идентификации SA других протоколов безопасности.

В приведенной ниже таблице показано наличие или отсутствие определенных полей при установлении SA. Следующие поля необходимы для различных операций, связанных с установлением SA: cookies в заголовке ISAKMP, поле Message ID в заголовке ISAKMP, поле SPI в Proposal payload. "X" в столбце означает, что значение должно присутствовать. "NA" в столбце означает, что значение в операции не применяется.

Первая строка таблицы говорит о том, что инициатор включает поле Initiator Cookie в ISAKMP Header.

Вторая строка таблицы говорит о том, что отвечающий включает поля Initiator и Responder Cookie в ISAKMP Header. Взаимодействующие стороны ISAKMP могут обмениваться дополнительными сообщениями в зависимости от типа обмена ISAKMP, используемого в первой фазе переговоров. После завершения первой фазы обмена Initiator и Responder cookies включаются в ISAKMP Header всех обменов между участниками ISAKMP.

В течение первой фазы переговоров cookies инициатора и получателя определяют ISAKMP SA. Следовательно, поле SPI в Proposal payload избыточно и может быть установлено в 0 или может содержать cookie передаваемых сущностей.

Третья строчка таблицы говорит о том, что инициатор связывает Message ID с Protocols, содержащимися в SA Proposal. Это Message ID и SPI (s) инициатора связываются с каждым протоколом в Proposal и посылаются получателю. SPI (s) будут использоваться в протоколах безопасности сразу после завершения второй фазы переговоров.

В четвертой строке таблицы получатель включает тот же самый Message ID, и SPI (s) получателя связываются с каждым протоколом в принимаемом Proposal. Эта информация возвращается инициатору.

Пятая строка таблицы говорит о том, что инициатор и получатель используют поле Message ID в ISAKMP Header для отслеживания выполнения протокола переговоров. Это применяется на второй фазе обмена, и значение должно быть 0 для первой фазы обмена, потому что комбинированные cookies определяют ISAKMP SA. Поле SPI в Proposal payload не применяется, потому что Proposal payload используется только на протяжении обмена сообщениями переговоров SA (шаги 3 и 4).

В шестой строке таблицы фаза 2 переговоров завершается.

При установлении SA должно создаваться SPI. ISAKMP предполагает применение SPIs различных размеров. Это достигается путем использования поля SPI Size в Proposal payload при установлении SA.

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

Дополнительные определения и понятия

Создание Token анти-препятствия ("Cookie")

Детали создания cookie зависят от реализации, но в целом должны выполняться следующие основные требования:

Кэрн (Karn) предложил метод создания cookie, основанный на выполнении быстрого хэша (например, MD5) над IP-адресами источника и получателя, портов UDP источника и получателя и локально созданного секретного случайного значения. ISAKMP требует, чтобы cookie были уникальными для каждой устанавливаемой SA для того, чтобы предотвратить replay-атаки и, следовательно, в хэшируемую информацию должны добавляться значения даты и времени. Созданные cookie помещаются в заголовок ISAKMP инициатора и получателя. Эти поля имеют длину 8 октетов, таким образом, создаваемые cookie должны быть длиной 8 октетов.

Содержимые ISAKMP

Содержимые ISAKMP обеспечивают возможность конструировать ISAKMP сообщения из модульно построенных блоков. Наличие и последовательность содержимых в ISAKMP определяется полем Exchange Type, размещаемым в заголовке ISAKMP. Типы содержимых ISAKMP обсуждаются далее. Описания сообщений и обменов показаны, используя сетевой порядок представления октетов.

Формат заголовка ISAKMP

Сообщение ISAKMP имеет фиксированный формат заголовка, показанный на рис. 24.1, за которым следует переменное число определенных содержимых. Фиксированный заголовок проще разбирать, что делает ПО более легким для реализации. Фиксированный заголовок содержит информацию, необходимую протоколу для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.

Поля заголовка ISAKMP определяются следующим образом:

Общий заголовок содержимого

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

Поля общего заголовка содержимого определяются следующим образом:

Атрибуты данных

Существует несколько случаев в ISAKMP, когда должны быть представлены атрибуты данных. Примером могут служить атрибуты SA, содержащиеся в Transform payload. Эти атрибуты данных не являются самостоятельным содержимым ISAKMP, а представляют собой часть некоторого содержимого. Формат атрибутов данных обеспечивает гибкость представления различных типов информации. В содержимом может существовать много атрибутов данных. Длина атрибутов данных или равна 4 октетам, или определяется полем Attribute Length. Это определяется битом формата атрибута, описанным ниже.

Поля атрибутов данных определяются следующим образом:

Бит Attribute Format ( AF ) указывает, будут ли атрибуты данных определяться форматом Type/Length/Value ( TLV ) или короткой формой формата Type/Value ( TV ). Если бит AF = 0, то атрибуты данных имеют форму TLV. Если бит AF = 1, то атрибуты данных имеют форму TV.

Содержимое SA

Содержимое SA используется при переговорах об атрибутах безопасности и для определения Situation, при котором переговоры имеют место. Рис. 24.4 показывает формат полезной информации SA.

Содержимое Proposal

Proposal Payload содержит информацию, используемую в течение переговоров SA. Proposal состоит из механизмов безопасности, или преобразований, используемых для обеспечения безопасности информационного канала. На рис. 24.5 показан формат Proposal Payload.

Поля Proposal Payload определяются следующим образом:

Тип содержимого для Proposal Payload равен 2.

Содержимое Transform

Transform Payload содержит информацию, используемую SA при переговорах. Transform Payload состоит из конкретных механизмов безопасности, или преобразований, которые используются для обеспечения безопасности информационного канала. Transform Payload также содержит атрибуты SA, связанные с конкретным преобразованием. Эти атрибуты SA определяются DOI. На рис. 24.6 показан формат Transform Payload.

Поля Transform Payload определяются следующим образом:

Тип полезной информации для Transform Payload есть 3.

Содержимое Key Exchange

Key Exchange Payload поддерживает различные технологии обмена ключа. Примерами обменов ключа являются Oakley, Diffie-Hellman, расширенный обмен ключа Diffie-Hellman, описанный в Х9.42, и обмен ключа на основе RSA, используемый в PGP. На рис. 24.7 показан формат Key Exchange рayload.

Поля Key Exchange Payload определяются следующим образом:

Тип полезной информации для Key Exchange Payload есть 4.v

Содержимое Identification

Identification Payload содержит данные, используемые при обмене идентификационной информацией.

Поля Identification Payload определяются следующим образом:

Тип полезной информации для Identification Payload есть 5.

Содержимое Certificate

Certificate Payload обеспечивает способ передачи сертификатов или другой информации, относящейся к сертификатам, с помощью ISAKMP и может появляться в любом сообщении ISAKMP. На рис. 24.9 показан формат Certificate Payload.

Поля Certificate Payload определяются следующим образом:

Тип содержимого для Certificate Payload есть 6.

Содержимое Certificate Request

Certificate Request Payload обеспечивает значение для запроса сертификатов с помощью ISAKMP и может появиться в любом сообщении. Certificate Request рayload должен приниматься в любой точке обмена. Получатель Certificate Request рayload должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request рayloads. На рис. 24.10 показан формат Certificate Request Payload.

Поля Certificate Payload определяются следующим образом:

Тип содержимого для Certificate Request Payload есть 7.

Содержимое HASH

Hash Payload содержит данные, создаваемые хэш-функцией (определенной во время обмена при установлении SA), для некоторой части сообщения и/или состояния ISAKMP. Данное содержимое может использоваться для проверки целостности данных в ISAKMP -сообщении или для аутентификации сущностей, ведущих переговоры. На рис. 24.11 показан формат Hash Payload.

Поля Hash Payload определяются следующим образом:

Содержимое Signature

Signature Payload содержит данные, созданные функцией цифровой подписи (выбранной при обмене во время установления SA) для определенной части сообщения и/или ISAKMP -состояния. Данное содержимое используется для проверки целостности данных в ISAKMP - сообщении, и может быть использовано для сервисов невозможности отказа. На рис. 24.12 показан формат Signature Payload.

Поля Signature Payload определяются следующим образом:

Тип содержимого для Signature Payload есть 9.

Содержимое Nonce

Nonce Payload содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. На рис. 24.13 показан формат Nonce Payload. Если nonces используются в конкретном обмене ключа, то применение Nonce рayload определяется обменом ключа. Nonces могут передаваться как часть данных обмена ключа или как отдельное содержимое. Это, однако, определяется обменом ключа, а не ISAKMP.

Поля Nonce Payload определяются следующим образом:

Тип содержимого для Nonce Payload есть 10.

Содержимое Notification

Notification Payload может содержать как определяемые ISAKMP, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification Payload в одном сообщении ISAKMP. На рис. 24.14 показан формат Notification Payload.

Notification, которые возникают на Фазе 1 переговоров, идентифицируются парой cookie Инициатора и Получателя в заголовке ISAKMP. Идентификатором протокола в данном случае является ISAKMP, и значение SPI есть 0, потому что пара cookie в заголовке ISAKMP идентифицирует ISAKMP SA. Если notification имеет место перед завершением обмена ключевой информацией, то она не будет защищена.

Notification, которые возникают во время Фазы 2 переговоров, определяются парой cookie Инициатора и Получателя в заголовке ISAKMP, и Message ID и SPI связаны с текущими переговорами.

Поля Notification Data определяются следующим образом:

Тип содержимого для Notification Payload есть 11.

Содержимое Delete

Delete Payload содержит идентификатор SA которую отправитель удаляет из своей БД SA и которая, следовательно, более не доступна. На рис. 24.15 показан формат Delete Payload. Возможна посылка нескольких SPIs в Delete Payload, однако каждый SPI должен быть предназначен для того же самого протокола.

Удаление, которое относится к ISAKMP SA, содержит Protocol-Id для ISAKMP, и SPIs есть cookies отправителя и получателя из заголовка ISAKMP. Удаление, которое имеет дело с Protocol SA, такими как ESP или АН, будет содержать Protocol-Id протокола (т.е. ESP, AH), и SPI есть SPI(s) посылающей сущности.

Поля Delete Payload определены следующим образом:

Тип содержимого для Delete Payload есть 12.

Содержимое Vendor ID

Vendor ID Payload содержит константу, определяющую разработчика. Данная константа используется разработчиком для собственной идентификации и удаленной сущностью для распознавания разработчика. Данный механизм позволяет разработчику экспериментировать с новыми возможностями, сохраняя обратную совместимость. На рис. 24.16 показан формат Vendor ID Payload.

Поля Vendor ID Payload определяются следующим образом:

Тип содержимого Vendor ID есть 13.

Internet Key Exchange (IKE)

Используемая нотация

Используются следующие нотации.

HDR – это заголовок ISAKMP, который определяет тип обмена. Запись HDR* означает, что содержимое зашифровано.

SA – это содержимое переговоров SA с одним или более Proposals. Инициатор может предоставить несколько Proposals для переговоров; получатель должен выбрать только одну.

<P>_b – это тело содержимого <P>. Например, SA_b есть все тело содержимого SA (минус общий заголовок ISAKMP ), т.е. DOI, Situation, все Proposals и все Transforms, представленные Инициатором.

CKY-I и CKY-R есть cookie Инициатора и cookie Получателя, соответственно, из ISAKMP -заголовка.

g^x i и g^xr – это открытые значения Диффи-Хеллмана Инициатора и Получателя соответственно.

КЕ – это содержимое обмена ключа, т.е. открытая информация, которой обмениваются в алгоритме Диффи-Хеллмана. Специального шифрования, используемого для содержимого КЕ, не существует.

Nx – это содержимое nonce; x может быть i или r для ISAKMP Инициатора и Получателя соответственно.

IDx – есть содержимое идентификации для "х". Х может быть "ii" или "ir" для ISAKMP Инициатора и Получателя соответственно во время Фазы 1 переговоров ; или "ui" или "ur" для Инициатора и Получателя соответственно во время Фазы 2.

SIG – это содержимое подписи. Подписываемые данные зависят от обмена.

СERT – это содержимое сертификата.

HASH – это содержимое хэша, которое определяется методом аутентификации.

prf (key, msg) – это псевдослучайная функция, часто хэш-функция, основанная на ключе, используемая для создания детерминированного выхода, который можно рассматривать как псевдослучайный. Prf используется как для получения ключа, так и для аутентификации (т.е. как МАС с ключом).

SKEYID есть строка, полученная из секрета и известная только участникам обмена.

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

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

SKEYID_d есть материал ключа, используемый для получения ключей для не- ISAKMP безопасных ассоциаций.

<x>y определяет, что х зашифровано ключом y.

$$\Rightarrow$$ указывает на направление взаимодействия от Инициатора к Получателю (запрос).

$$\Leftarrow$$ указывает на направление взаимодействия от Получателя к Инициатору (ответ).

| обозначает конкатенацию информации.

[x] обозначает, что х не является обязательным.

Шифрование сообщения (когда указана * после ISAKMP заголовка) должно начинаться сразу после ISAKMP -заголовка. При защищенном взаимодействии все содержимые после ISAKMP заголовка должны шифроваться. Ключи шифрования создаются из SKEYID_e тем способом, который определен для каждого алгоритма.

Введение

IKE представляет различные обмены как режимы, которые выполняются в одной из двух фаз.

В течение Фазы 1 участники устанавливают безопасный аутентифицированный канал, по которому они будут взаимодействовать. Это называется ISAKMP SA. Для фазы 1 определено два режима: Main Mode и Aggressive Mode.

Фаза 2 определяется тогда, когда уже установлены ISAKMP SA. "Quick Mode" определен для второй фазы обмена.

"New Group Mode" реально ни с Фазой 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"). Если prf в переговорах не участвует, то версия HMAC хэш-алгоритма, о котором договорились, используется в качестве псевдослучайной функции.

Группа Диффи-Хеллмана задается по номеру или путем определения всех атрибутов группы. Атрибуты группы не должны зависеть от значений группы, определенной в предыдущем случае.

Обмены

Существует два основных режима, используемых для установления аутентифицированного обмена ключа: 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 подписаны и верифицированы; при аутентификации либо шифрованием открытым ключом, либо pre-shared ключами HASH_I и HASH_R непосредственно аутентифицируют обмен. Все содержимое ID (включая тип ID, порт и протокол, но исключая общий заголовок) хэшировано как в HASH_I, так и в HASH_R.

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

IKE Фаза 1 с аутентификацией с помощью подписей

При использовании подписей вспомогательной информацией, которой обмениваются при второй круговой передаче, являются nonces; обмен аутентифицируется путем подписывания хэша. Main Mode с аутентификацией с помощью подписи выполняется согласно рис.24.17.

Aggressive Mode с аутентификацией с помощью подписи выполняется согласно рис.24.18.

В обоих режимах подписанные данные, SIG_I или SIG_R, являются результатом алгоритма цифровой подписи, примененным к HASH_I или HASH_R соответственно.

В общем случае подпись выполняется поверх HASH_I и HASH_R, при этом используется prf или версия НМАС для хэш-функции (если участники не договорились о prf).

Могут быть дополнительно переданы один или более сертификатов.

Фаза 1 аутентификации шифрованием открытым ключом

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

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

В дополнение к nonce идентификации участников ( IDii и IDir ) также зашифрованы открытым ключом другого участника. Если методом аутентификации является шифрование открытым ключом, то содержимые nonce и идентификации должны быть зашифрованы открытым ключом другого участника. Шифруется только тело содержимого, заголовки содержимого не шифруются.

При использовании для аутентификации шифрования Main Mode выполняется согласно рис.24.19.

Aggressive Mode выполняется согласно рис.24.20.

Где HASH (1) есть хэш сертификата, который инициатор использовал для шифрования nonce и идентификации.

Использование шифрования для аутентификации обеспечивает невозможность отказа от обмена.

Заметим, что в отличие от других методов аутентификации, аутентификация шифрованием открытым ключом допускает защиту идентификации в Aggressive Mode.

Фаза 1 аутентификации с Revised Mode шифрования открытым ключом

Аутентификация шифрованием открытым ключом имеет важное преимущество по сравнению с аутентификацией с использованием подписей. К сожалению, ценой являются 4 операции открытого ключа – две операции шифрования открытым ключом и две операции дешифрования закрытым ключом. Данный метод аутентификации сохраняет преимущества аутентификации с использованием шифрования с открытым ключом, но делает это с использованием половины операций открытого ключа.

В данном режиме nonce все еще зашифрован с использованием открытого ключа противоположной стороны, однако идентификация противоположной стороны (и сертификат, если он послан) шифруется с использованием алгоритма симметричного шифрования, о котором договорились (из содержимого SA) с ключом, полученным из nonce. Это решение добавляет минимальную сложность, и на каждой стороне используется две операции открытого ключа. Дополнительно содержимое Key Exchange также зашифровано с использованием того же самого ключа. Это обеспечивает дополнительную защиту против криптоанализа обмена Диффи-Хеллмана.

Как и в методе аутентификации шифрованием открытым ключом содержимое HASH может быть послано для идентификации сертификата, если получатель имеет несколько сертификатов. Если содержимое HASH послано, оно должно быть первым содержимым сообщения второго обмена, и за ним должен следовать зашифрованный nonce. Если содержимое HASH не послано, первым содержимым сообщения второго обмена должен быть зашифрованный nonce. Дополнительно инициатор может послать содержимое с сертификатом для указания получателю использованного открытого ключа.

При использовании для аутентификации пересмотренного режима шифрования Main Mode определяется согласно рис.24.21.

Aggressive Mode, аутентифицируемый с помощью пересмотренного метода шифрования, определяется согласно рис.24.22.

Где 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 в зависимости от направления.

Фаза 1 аутентификации с Pre-Shared ключом

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

Когда выполняется pre-shared аутентификация, Main Mode определяется согласно рис.24.23.

Aggressive режим с pre-shared ключом описывается согласно рис.24.24.

При использовании аутентификации с pre-shared ключом с Main Mode ключ может только идентифицироваться по IP-адресу противоположной стороны, так как HASH_I должен быть вычислен до того, как инициатор обработает IDir. Aggressive Mode охватывает более широкий диапазон идентификаторов используемого pre-shared секрета. Дополнительно Aggressive Mode позволяет двум участникам поддерживать несколько различных pre-shared ключей и идентификаций для отдельного обмена.

Фаза 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 определяется согласно рис.24.25.

Где:

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 и ключах согласно рис.24.26.

New Group Mode

New Group Mode не должен использоваться до установления ISAKMP SA. Описание новой группы должно следовать только за фазой 1 переговоров. (Однако это не фаза 2 обмена).

Где HASH (1) является выходом prf с использованием SKEYID_a в качестве ключа, и message-ID из заголовка ISAKMP, присоединенного ко всему SA proposal, как телу, так и заголовку; HASH (2) есть выход prf с использованием SKEYID_a в качестве ключа, и message-ID из заголовка ISAKMP, присоединенного к ответу. Другими словами, хэшами для обменов являются:

HASH (1) = prf (SKEYID_a, M-id | SA )

HASH (2) = prf (SKEYID_a, M-id | SA)

Proposal определяется характеристиками группы. Описания группы для частных групп должны быть больше или равны 215. Если группа не принимается, получатель должен ответить сообщением с содержимым Notify, и тип сообщения установить в ATTRIBUTE-NOT-SUPPORTED (13).

Реализации ISAKMP могут требовать частных групп для устанавливаемых SA.

О группах можно непосредственно договариваться в SA Proposal в Main Mode. Чтобы это сделать, компоненты – MODP группы, тип, простое и генератор; тип для EC2N группы, несократимый полином, генератор группы One, генератор группы Two, группа эллиптической кривой А, группа эллиптической кривой В и порядок группы – передаются в качестве атрибутов SA.

Информационные обмены ISAKMP

Данный протокол, когда это возможно, защищает информационные обмены ISAKMP. После того как безопасная ассоциация ISAKMP установлена (и SKEYID_e и SKEYID_a созданы) информационные обмены ISAKMP при использовании данного протокола представляют собой следующее:

Где N/D есть либо ISAKMP Notify Payload, либо ISAKMP Delete Payload и HASH (1) есть выход prf с использованием SKEYID_a в качестве ключа, и M-ID, уникальный для данного обмена, присоединяется в качестве данных ко всему информационному содержимому (либо Notify, либо Delete). Другими словами, хэшем для предыдущего обмена является:

HASH (1) = prf (SKEYID_a, M-ID | N/D)

Как уже было замечено, ID сообщения в заголовке ISAKMP – и используемые в prf вычисления – являются уникальными для данного обмена и не должны повторять ID сообщения для другой фазы 2 обмена, во время которой был создан данный информационный обмен.

Если безопасная ассоциация ISAKMP ко времени информационного обмена еще не установлена, обмен выполняется в явном виде без сопутствующего HASH содержимого.

Обсуждение проблем безопасности

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

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

В ситуациях, когда определенные группы не обеспечивают необходимую силу, можно использовать New Group Mode для обмена группой Диффи-Хеллмана, которая обеспечит ее.

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

Хотя сообщения последней круговой передачи в Main Mode (и не обязательно последнее сообщение Aggressive Mode ) являются зашифрованными, они строго говоря не являются аутентифицированными. Активная атака замены для зашифрованного текста может привести к разрушению содержимого. Если такая атака имела место для обязательных содержимых, это будет определено и приведет к падении аутентификации, но если это произошло для дополнительных содержимых (например, для содержимых уведомления, измененных в последнем сообщении Main Mode обмена), это может быть не определено.