учебники, программирование, основы, введение в,

 

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

Internet Security Association and Key Management Protocol (ISAKMP)
Введение
Рассмотрим Безопасную Ассоциацию Internet и Протокол Управления Ключом (ISAKMP). ISAKMP определяет общие процедуры и форматы пакетов для ведения переговоров об установлении, изменении и удалении SA. SAs содержат всю информацию, необходимую для выполнения различных сетевых сервисов безопасности. ISAKMP определяет содержимое обменов для создания ключей и аутентификации участников. Эти форматы обеспечивают взаимосогласованную основу для передаваемого ключа и аутентификационных данных, которая не зависит от технологии создания ключа, алгоритма шифрования и механизма аутентификации.
Существует много различных протоколов обмена ключом с различными свойствами безопасности. Тем не менее, требуется общий каркас для форматов атрибутов SA, для переговоров о модификации и удалении SA. Таким общим форматом и является ISAKMP.
Атрибуты SA, необходимые для протоколов AH и ESP, как минимум, должны включать механизм аутентификации, криптографический алгоритм, режим алгоритма, длину ключа и инициализационный вектор (IV). Установление SA является частью протокола управления ключом.
ISAKMP обеспечивает полную безопасность последующих обменов (Perfect Forward Secrecy – PFS) – это означает, что при компрометации одного ключа возможен только доступ к данным, защищенным одним этим ключом. При PFS ключ, используемый для защиты передаваемых данных, не должен использоваться для получения любых дополнительных ключей, и если ключ, используемый для защиты передаваемых данных, был получен из некоторого другого ключевого материала, то этот ключевой материал не должен больше использоваться для получения других ключей.
ISAKMP обеспечивает аутентифицированный обмен ключа. ISAKMP не определяет конкретный алгоритм обмена ключа. Тем не менее, как правило, вместе с ISAKMP используется протокол IKE.
Защита от DoS-атак является одной из наиболее трудных задач. Для этой цели в ISAKMP используются «Cookie» или знак анти-препятствия (anti-clogging token – ACT), которые предназначены для защиты вычислительных ресурсов от подобной атаки без расходования собственных ресурсов на ее обнаружение. Абсолютная защита от отказа в сервисе невозможна, но такой знак анти-препятствия предоставляет технологию для того, чтобы сделать защиту более надежной.
Следует заметить, что в обменах, показанных далее, механизм анти-препятствия должен использоваться вместе с механизмом сбора мусора; атакующий может завалить сервер, используя пакеты с поддельными IP- адресами. Подобные технологии управления памятью должны быть внедрены в протоколы, использующие ISAKMP.
ISAKMP предотвращает создание соединения с атакующим, объединяя аутентификацию, обмен ключа и создание SA. Это объединение не позволяет злоумышленнику дождаться завершения аутентификации и затем осуществить имперсонизацию в одну из аутентифицированных сущностей.
Атаки man-in-the-middle включают перехват, вставку, уничтожение и модификацию сообщений, отправку сообщений назад отправителю, повтор старых сообщений и перенаправление сообщений. ISAKMP предупреждает все эти типы атак. Объединение сообщений ISAKMP защищает от возможности встроить сообщения в обмены протокола. Протокол ISAKMP позволяет хосту обнаружить уничтоженные сообщения. Требование наличия нового cookie с новой отметкой времени для каждого нового установления SA предотвращает атаки, которые включают повтор старых сообщений. Требование ISAKMP сильной аутентификации предотвращает установление SA с кем-то, кроме заданного участника. Сообщения можно перенаправить к другому получателю или модифицировать, но это будет обнаружено, и SA установлена не будет.
Основные концепции
Терминология ISAKMP
Протокол безопасности: протокол безопасности состоит из записи в конкретной точке стека сетевых протоколов, выполняющей сервис безопасности для сетевого соединения. Например, IPsec ESP и IPsec AH являются двумя различными протоколами безопасности. Протокол безопасности может выполнять более одного сервиса, например, обеспечивая целостность и конфиденциальность в одном модуле.
Набор защиты: набор защиты является списком сервисов безопасности, которые могут быть применены к различным протоколам безопасности. Например, набор защиты может состоять из DES шифрования для ESP и MD5 с ключом для AH.
Безопасная ассоциация (SA): безопасная ассоциация определяет протокол безопасности и конкретный набор параметров сервисов и механизмов, необходимых для защиты трафика. Эти параметры могут включать идентификаторы алгоритмов, режимы, криптографические ключи и т.д. SA ссылается на связанный с ней протокол безопасности (например, «ISAKMP SA», «ESP SA»).
ISAKMP SA: SA используется ISAKMP для обеспечения защиты собственного трафика.
Domain of Interpretation: Domain of Interpretation (DOI) определяет форматы содержимого, типы обменов и соглашения по именованию информации, относящейся к безопасности, такой как политики безопасности или криптографические алгоритмы и режимы. Идентификатор DOI используется для интерпретации содержимого ISAKMP. DOI определяет:

  • «Situation»: набор информации, которая будет использоваться для определения требуемых сервисов безопасности.
  • Набор политик безопасности, которые могут и должны поддерживаться.
  • Синтаксис для описания предлагаемых сервисов безопасности.
  • Схема именования относящейся к безопасности информации, включая алгоритмы шифрования, алгоритмы обмена ключа, атрибуты политики безопасности и сертификационные центры.
  • Специфицированные форматы для различного содержания.
  • Дополнительные типы обмена, если потребуется.

Situation: ситуация содержит всю относящуюся к безопасности информацию, которую система считает нужным рассматривать, принимая решение о том, какие необходимы сервисы безопасности для защиты сессии, начавшей переговоры. Ситуация может включать адреса, классификации безопасности, режимы операций (нормальный или аварийный) и т.д.
Proposal: proposal – это список, упорядоченный по уменьшению предпочтений, наборов защиты, которые система будет применять для защиты трафика в данной ситуации.
Payload: ISAKMP определяет несколько типов содержимого, которые используются при передаче информации, такой как данные SA или данные обмена ключа, в форматах, определенных DOI. Содержимое состоит из общего заголовка и строки октетов, которые ISAKMP не различает. ISAKMP использует DOI-определяемую функциональность для создания и интерпретации данного содержимого. В одном сообщении ISAKMP может быть послано несколько содержимых . Далее будут определены детали типов полезной информации.
Exchange Type: тип обмена определяет число сообщений в ISAKMP- обмене и типы содержимого в каждом из этих сообщений. Считается, что каждый тип обмена предоставляет конкретный набор сервисов безопасности, таких как анонимность участников, свойство PFS для ключевого материала, аутентификация участников и т.д., далее определяется множество типов ISAKMP-обмена по умолчанию. При необходимости могут быть добавлены другие типы для поддержки дополнительных обменов ключа.

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

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» в столбце означает, что значение в операции не применяется.


Таблица 24.1. Поля при установлении SA

Операция

I-Cookie

R-Cookie

Message ID

SPI

1. Начало ISAKMP SA переговоров

X

0

0

0

2. Ответ ISAKMP SA переговоров

X

X

0

0

3. Инициализация других SA переговоров

Х

Х

Х

Х

4. Ответ других переговоров SA

Х

Х

Х

Х

5. Другое (КЕ, ID и т.д.)

Х

Х

Х/0

NA

6. Протокол безопасности (ESP, AH)

NA

NA

NA

X

Первая строка таблицы говорит о том, что инициатор включает поле 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 зависят от реализации, но в целом должны выполняться следующие основные требования:

  • Cookie должны зависеть только от данных участников. Это не позволит злоумышленнику получить cookie, используя реальный IP-адрес и UDP-порт, и затем используя его для того, чтобы засыпать жертву запросами на вычисления по алгоритму Диффи-Хеллмана со случайных IP-адресов или портов.
  • Не должно быть такого, чтобы выходящая сущность создавала те же самые cookie, что и получающая сущность. Это подразумевает, что выходящая сущность должна использовать локальную секретную информацию при создании cookie. Возможности вычислить эту секретную информацию из конкретного 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 имеет фиксированный формат заголовка, показанный на, за которым следует переменное число определенных содержимых. Фиксированный заголовок проще разбирать, что делает ПО более легким для реализации. Фиксированный заголовок содержит информацию, необходимую протоколу для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.
Поля заголовка ISAKMP определяются следующим образом:

  • Initiator Cookie (8 октетов) – cookie участника, который инициировал установление SA, уведомление SA или уничтожение SA.
  • Responder Cookie (8 октетов) – cookie участника, который является получателем запроса установления SA, уведомления SA или уничтожения SA.
  • Next Payload (1 октет) – определяет тип первого содержимого в сообщении. Формат обработки каждого содержимого определяется далее.
  • Major Version (4 бита) – определяет старший номер версии используемого протокола ISAKMP.
  • Minor Version (4 бита) – определяет младший номер версии используемого протокола ISAKMP.
  • Exchange Type (1 октет) – определяет тип используемого обмена. Это определяет сообщение и упорядоченность полезной информации в ISAKMP-обменах.
  • Flags (1 октет) – определяет конкретные опции, которые установлены для ISAKMP-обмена. Флаги, перечисленные ниже, определяются в поле Flags, начиная с крайнего левого бита, т.е. бит Encription является нулевым битом поля Flags, бит Commit является первым битом поля Flags и бит Authentication Only является вторым битом поля Flags. Оставшиеся биты поля Flags при передаче должны быть установлены в 0.
    • E (encryption bit) – если установлен, то все содержимые, следующие после заголовка, шифруются, используя алгоритм шифрования, определенный в ISAKMP SA. ISAKMP SA Identifier является комбинацией cookie инициатора и получателя. Рекомендуется, чтобы шифрование соединения между участниками начинало выполняться как можно быстрее. Для всех ISAKMP-обменов шифрование должно начинаться после того как оба участника обменяются содержимыми Key Exchange. Если данный бит не установлен, то содержимые не шифруются.
    • C (commit bit) – данный бит используется для сигнала синхронизации обмена ключа. Он позволяет гарантировать, что зашифрованный материал не будет получен до завершения установления SA. Commit Bit может быть установлен в любое время любым из участников установления SA и может использоваться в обеих фазах установления ISAKMP SA. Тем не менее, значение должно быть сброшено после Фазы 1 переговоров. Если установлено (1), сущность, которая не установила Commit Bit, должна ждать Information Exchange, содержащий Notify payload от сущности, которая установила Commit Bit. Получение и обработка Informational Exchange говорит о том, что установление SA прошло успешно, и обе сущности могут теперь продолжать взаимодействие по зашифрованному каналу. Дополнительно к синхронизации обмена ключа Commit Bit может использоваться для защиты от падения соединения по ненадежным сетям и предохранять от необходимости многочисленных повторных восстановлений.
    • A (authentication only bit) – данный бит используется с Informational Exchange с Notify payload и позволяет передавать информацию с контролем целостности, но без шифрования (т.е. «аварийный режим»). Если бит Authentication Only установлен, ко всему содержимому Notify Informational Exchange применяются только сервисы аутентификации, и содержимое не шифруется.
  • Message ID (4 октета) – уникальный идентификатор сообщения, используется для идентификации состояния протокола в Фазе 2 переговоров. Данное значение создается случайным образом инициатором в Фазе 2 переговоров.
  • Length (4 октета) – длина всего сообщения (заголовок + содержимое) в октетах. Шифрование может увеличить размер ISAKMP-сообщения.

Таблица 24.2. Типы содержимого

Тип Next Payload

Значение

None

0

Security Association (SA)

1

Proposal (P)

2

Transform (T)

3

Key Exchange (KE)

4

Identification (ID)

5

Certificate (CERT)

6

Certificate Request (CR)

7

Hash (HASH)

8

Signature (SIG)

9

Nonce (NONCE)

10

Notification (N)

11

Delete (D)

12

Vendor ID (VID)

13

RESERED

14 – 127

Private USE

128 – 255

Таблица 24.3. Типы обменов

Тип обмена

Значение

NONE

0

Base

1

Identity Protection

2

Authentication Only

3

Aggressive

4

Informational

5

ISAKMP Future Use

6 – 31

DOI Specific Use

32 – 239

Private Use

240 – 255

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

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

  • Next Payload (1 октет) – идентификатор типа содержимого следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина текущего содержимого, включая общий заголовок.
Атрибуты данных

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

  • Attribute Type (2 октета) – уникальный идентификатор каждого типа атрибута.

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

  • Attribute Length (2 октета) – длина значения атрибута в октетах. При AF = 1 значение атрибута имеет только 2 октета, и поле длины атрибута не представлено.
  • Attribute Value (переменной длины) – значение атрибута, связанное с Attribute Type. Если бит AF = 0, то это поле имеет переменную длину, определяемую полем Attribute Length. Если бит AF = 1, то Attribute Value имеет длину 2 октета.
Содержимое SA

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

  • Next Payload (1 октет) – идентификатор типа содержимого Next payload в сообщении. Если текущее содержимое является последним в сообщении, то это поле будет 0. Данное поле не должно содержать значений для Proposal или Transform payloads, т.к. они являются частью содержимого SA. Например, это поле должно содержать значение «10» (Nonce payload) в первом сообщении Base Exchange, и значение «0» в первом сообщении Identity Protect Exchange.
  • Payload Length (2 октета) – длина в октетах всего содержимого SA, включая SA payload, все Proposal payloads и все Transform payloads, связанные с создаваемой SA.
  • Domain of Interpretation (4 октета) – определяет DOI, которым определяются данные переговоры. DOI является 32-битным беззнаковым целым. Значение 0 DOI в течение Фазы 1 обмена определяет Generic ISAKMP SA, который может использоваться любым протоколом в течение Фазы 2 обмена. Значение 1 DOI связано с IPsec DOI. Все другие значения DOI зарезервированы IANA для дальнейшего использования. IANA обычно не связывает значение DOI без некоторой открытой спецификации, такой как RFC.
  • Situation (переменной длины) – поле, определяемое DOI, которое идентифицирует ситуацию, при которой ведутся переговоры. Situation используется для того, чтобы определить политику и соответствующие атрибуты безопасности, при которых ведутся переговоры.
Содержимое Proposal

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Это поле должно содержать только значения «2» или «0». Если существуют дополнительные Proposal payload, то это поле должно быть 2. Если текущий Proposal payload является последним в SA proposal, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах всего Proposal payload, включая общий заголовок содержимого, Proposal payload и все Transform payloads, связанные с данным proposal.
  • Proposal # (1 октет) – определяет номер Proposal для текущего содержимого.
  • Protocol-Id (1 октет) – определяет идентификатор протокола для текущих переговоров. Примерами являются IPSEC ESP, IPSEC AH.
  • SPI Size (1 октет) – длина SPI в октетах как определено Protocol-Id. В случае ISAKMP пара cookie Инициатора и Получателя из заголовка ISAKMP является идентификацией ISAKMP, следовательно, SPI Size не имеет значения и может быть от нуля до 16.
  • # of Transforms (1 октет) – определяет количество преобразований для Proposal. Каждое из них содержится в Transform payload.
  • SPI (переменной длины) – SPI получающей сущности.

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

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Это поле должно содержать только значения «3» или «0». Если есть дополнительные Transform Payloads в Proposal, то данное поле должно быть равно 3. Если текущая Transform Payload является последней в proposal, то данное поле должно быть равно 0.
  • Payload Length (2 октета) – длина в октетах текущей полезной информации, включая общий заголовок, значения Transform и все атрибуты SA.
  • Transform # (1 октет) – определяет количество преобразований для текущего содержимого. Если для конкретного протокола существует более одного преобразования, то каждая Transform рayload имеет уникальный номер преобразования.
  • Transform-Id (1 октет) – определяет идентификатор преобразования для протокола в текущей Proposal. Эти преобразования зависят от протокола, для которого ведутся переговоры.
  • SA Attributes (переменной длины) – данное поле содержит атрибуты SA как они определены для данного преобразования в поле Transform-Id. Атрибуты SA должны представляться с использованием формата Data Attributes.

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним в сообщении, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Key Exchange Data (переменной длины) – данные, необходимые для создания ключа сессии.

Тип полезной информации для Key Exchange Payload есть 4.v
Содержимое Identification
Identification Payload содержит данные, используемые при обмене идентификационной информацией.
Поля Identification Payload определяются следующим образом:

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущая полезная информация является последней, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • ID Type (1 октет) – спецификация типа используемой идентификации.
  • DOI Specific ID Data (3 октета) – содержит данные идентификации. Если не используется, то данное поле должно устанавливаться в 0.
  • Identification Data (переменной длины) – содержит идентификационную информацию. Формат определяется полем ID Type.

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущая полезная информация является последней, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Certificate Encoding (1 октет) – данное поле определяет тип сертификата или информации, относящейся к сертификату, содержащейся в поле Certificate Data.
  • Certificate Data (переменной длины) – конкретное представление данных сертификата. Тип сертификата определяется полем Certificate Encoding.

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


Содержимое Certificate Request
Certificate Request Payload обеспечивает значение для запроса сертификатов с помощью ISAKMP и может появиться в любом сообщении. Certificate Request рayload должен приниматься в любой точке обмена. Получатель Certificate Request рayload должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request рayloads. На показан формат Certificate Request Payload.
Поля Certificate Payload определяются следующим образом:
  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Certificate Type (1 октет) – содержит тип запрашиваемого сертификата.
  • Certificate Authority (переменной длины) – содержит обозначение принимаемых сертификационных центров для запрашиваемых сертификатов. Например, для сертификата Х.509 оно должно содержать значение DN CA, принимаемого отправителем. Это должно помочь получателю определить, какую цепочку сертификатов необходимо послать в ответ на данный запрос. Если требуемый сертификационный центр не указан, данное поле включаться не должно.

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Hash Data (переменной длины) – данные, которые являются результатом применения хэш-функции к ISAKMP-сообщению и/или состоянию.

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Signature Data (переменной длины) – данные, которые являются результатом применения функции цифровой подписи для ISAKMP сообщения.

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Nonce Data (переменной длины) – содержит случайные данные, созданные передающей сущностью.

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

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

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Domain of Interpretation (4 октета) – идентификация DOI, с помощью которой данное уведомление имело место.
  • Protocol-Id (1 октет) – определяет идентификатор протокола для текущего уведомления. Примерами являются ISAKMP, ESP, AH.
  • SPI Size (1 октет) – длина SPI в октетах как определено в Protocol-Id. В случае ISAKMP пара cookie Инициатора и Получателя из заголовка ISAKMP есть ISAKMP SPI, следовательно, SPI Size не имеет отношения к делу и, следовательно, может быть от 0 до 16. Если SPI Size – не 0, содержимое поля SPI должно игнорироваться.
  • Notify Message Type (2 октета) – определяет тип сообщения уведомления. Дополнительный текст размещается в поле Notification Data.
  • SPI (переменной длины) – Security Parameter Index. SPI получающей сущности. Длина этого поля определяется полем SPI Size.
  • Notification Data (переменной длины) – информация или данные об ошибке, передаваемые в дополнение к Notify Message Type.

Тип содержимого для Notification Payload есть 11.
Содержимое Delete
Delete Payload содержит идентификатор SA которую отправитель удаляет из своей БД SA и которая, следовательно, более не доступна. На показан формат 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 определены следующим образом:

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Domain of Interpretation (4 октета) – идентификация DOI, с помощью которой данное уведомление было сделано.
  • Protocol-Id (1 октет) – ISAKMP может устанавливать безопасные ассоциации для различных протоколов, включая ISAKMP и IPsec.
  • SPI Size (1 октет) – длина SPI в октетах определяется Protocol-Id. В случае ISAKMP ISAKMP SPI является пара cookie Инициатора и Получателя. В этом случае SPI Size есть 16 октетов для каждого удаляемого SPI.
  • # of SPIs (2 октета) – количество SPIs, содержащихся в Delete payload. Размер каждого SPI определяется полем SPI Size.
  • Securiry Parameter Index(es) (переменной длины) – идентификаторы, определяющие удаляемые безопасные ассоциации.

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

  • Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
  • Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
  • Vendor ID (переменной длины) – хэш строки разработчика плюс версия.

Тип содержимого 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^xi и 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.
⇒ указывает на направление взаимодействия от Инициатора к Получателю (запрос).
⇐ указывает на направление взаимодействия от Получателя к Инициатору (ответ).
| обозначает конкатенацию информации.
[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 с аутентификацией с помощью подписи выполняется согласно.
Aggressive Mode с аутентификацией с помощью подписи выполняется согласно.
В обоих режимах подписанные данные, SIG_I или SIG_R, являются результатом алгоритма цифровой подписи, примененным к HASH_I или HASH_R соответственно.
В общем случае подпись выполняется поверх HASH_I и HASH_R, при этом используется prf или версия НМАС для хэш-функции (если участники не договорились о prf).
Могут быть дополнительно переданы один или более сертификатов.

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

При использовании шифрования открытым ключом для аутентификации обмена применяются зашифрованные nonces. Каждый участник имеет возможность восстановить хэш (доказывая, что другой участник дешифровал nonce), аутентифицируя обмен.
Для того чтобы выполнить шифрование открытым ключом, инициатор должен уже иметь открытый ключ получателя. В случае, когда получатель имеет несколько открытых ключей, инициатор использует хэш сертификата, передаваемой как часть третьего сообщения. При таком способе получатель может определить, какой закрытый ключ использовать для дешифрования зашифрованного содержимого и защищенной идентификации.
В дополнение к nonce идентификации участников (IDii и IDir) также зашифрованы открытым ключом другого участника. Если методом аутентификации является шифрование открытым ключом, то содержимые nonce и идентификации должны быть зашифрованы открытым ключом другого участника. Шифруется только тело содержимого, заголовки содержимого не шифруются.
При использовании для аутентификации шифрования Main Mode выполняется согласно.
Aggressive Mode выполняется согласно.
Где HASH (1) есть хэш сертификата, который инициатор использовал для шифрования nonce и идентификации.
Использование шифрования для аутентификации обеспечивает невозможность отказа от обмена.

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

 

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

Аутентификация шифрованием открытым ключом имеет важное преимущество по сравнению с аутентификацией с использованием подписей. К сожалению, ценой являются 4 операции открытого ключа – две операции шифрования открытым ключом и две операции дешифрования закрытым ключом. Данный метод аутентификации сохраняет преимущества аутентификации с использованием шифрования с открытым ключом, но делает это с использованием половины операций открытого ключа.
В данном режиме nonce все еще зашифрован с использованием открытого ключа противоположной стороны, однако идентификация противоположной стороны (и сертификат, если он послан) шифруется с использованием алгоритма симметричного шифрования, о котором договорились (из содержимого SA) с ключом, полученным из nonce. Это решение добавляет минимальную сложность, и на каждой стороне используется две операции открытого ключа. Дополнительно содержимое Key Exchange также зашифровано с использованием того же самого ключа. Это обеспечивает дополнительную защиту против криптоанализа обмена Диффи-Хеллмана.
Как и в методе аутентификации шифрованием открытым ключом содержимое HASH может быть послано для идентификации сертификата, если получатель имеет несколько сертификатов. Если содержимое HASH послано, оно должно быть первым содержимым сообщения второго обмена, и за ним должен следовать зашифрованный nonce. Если содержимое HASH не послано, первым содержимым сообщения второго обмена должен быть зашифрованный nonce. Дополнительно инициатор может послать содержимое с сертификатом для указания получателю использованного открытого ключа.
При использовании для аутентификации пересмотренного режима шифрования Main Mode определяется согласно.
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 в зависимости от направления.

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

Ключ, полученный некоторым внешним механизмом, может также использоваться для аутентификации обмена.
Когда выполняется pre-shared аутентификация, Main Mode определяется согласно.
Aggressive режим с pre-shared ключом описывается согласно.
При использовании аутентификации с 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 определяется согласно.
Где:
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 и ключах согласно.
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 обмена), это может быть не определено.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика