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

• Cookie должны зависеть только от данных участников. Это не позволит злоумышленнику получить cookie, используя реальный IP-адрес и UDP-порт, и затем используя его для того, чтобы засыпать жертву запросами на вычисления по алгоритму Диффи-Хеллмана со случайных IP-адресов или портов.
• Не должно быть такого, чтобы выходящая сущность создавала те же самые cookie, что и получающая сущность. Это подразумевает, что выходящая сущность должна использовать локальную секретную информацию при создании cookie. Возможности вычислить эту секретную информацию из конкретного cookie существовать не должно.
• Функция создания cookie должна быть быстрой, чтобы предотвратить атаки, направленные на использование ресурсов ЦП.

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