Автоматические SA и Управление Ключом

Широкое использование IPsec требует стандартного для Internet, масштабируемого, автоматического протокола управления SA. Такая поддержка необходима для использования anti-replay возможностей AH и ESP и для возможности создания SAs.

Протоколом автоматического управления ключом по умолчанию является IKE, но могут быть реализованы и другие протоколы автоматического управления ключом.

База данных Безопасной Ассоциации (SAD)

В IPsec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPsec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для поддержки SA в реализации IPsec.

Для входящей обработки следующие поля пакета используются для поиска SA в SAD:

IP адрес назначения внешнего заголовка: IPv4 или IPv6 адрес назначения.Протокол IPsec: AH или ESP, используемый в качестве индекса SA в данной БД. Определяет протокол IPsec, применяемый к трафику для данной SA.SPI: 32-битное значение, применяемое для идентификации различных SA, заканчивающихся одним и тем же адресом назначения и использующих один и тот же IPsec протокол.

Следующие поля SAD используются для IPsec-обработки:

Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в AH или ESP заголовках (используется только для исходящего трафика).Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызывать событие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).Anti-Replay Window: 32-битный счетчик или битовая карта (или некий эквивалент), используемые для проверки, является ли входящий AH или ESP пакет повтором. (Используется только для входящего трафика. Замечание: если anti-reply сервис не используется получателем, например, в случае ручных ключей SA, когда anti-reply window не используется.)Алгоритм аутентификации для AH, ключи и т.д.Алгоритм шифрования для ESP, ключи, режим, IV и т.д.Алгоритм аутентификации для ESP, ключи и т.д. Если сервис аутентификации не выбран, данное поле будет нулевым.

Время жизни данной SA: интервал времени, после которого SA должна быть заменена новой SA (и новым SPI) или завершение SA, а также определения того, какое из этих действий должно выполняться. Это может быть выражено в виде времени или количества байтов, или и того, и другого одновременно. Реализации должны поддерживать оба типа времени жизни и одновременное применение обоих типов. Если используется время и если IKE задействует сертификаты Х.509 для установления SA, то время жизни SA должно входить в допустимый интервал для сертификатов. В этом смысле как инициатор, так и получатель ответственны за установление корректного времени жизни SA.

Должно быть два типа времени жизни: soft – время жизни, по истечении которого выдается предупреждение начать действия по замене SA, и hard – время жизни, когда текущая SA завершается.

Режим IPsec протокола: туннель или транспорт. Определяет применяемый режим AH или ESP к трафику для данной SA.

Базы данных безопасной ассоциации

Многие детали, связанные с обработкой IP-трафика в реализации IPsec не являются предметом стандартизации. Тем не менее, некоторые внешние аспекты обработки должны быть стандартизованы для обеспечения интероперабельности IPsec. Рассмотрим общую модель обработки IP трафика, относящуюся к безопасным ассоциациям. Внешнее поведение каждой реализации должно соответствовать характеристикам данной модели.

Существуют две БД: БД Политики Безопасности (SPD) и БД Безопасной Ассоциации (SAD). Первая описывает политики, которые определяют характер обработки всего IP трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Определим также понятие Селектора как множества значений полей IP протокола и протокола более высокого уровня, которые используются БД Политики Безопасности для отображения трафика на SA.

Каждый сетевой интерфейс, для которого необходима обработка IPsec, требует определения баз данных для входящего и исходящего трафика.

БД политики безопасности (SPD)

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

SPD должна рассматриваться при обработке всего трафика (входящего и исходящего), включая не-IPsec трафик. Для того чтобы это поддерживать, SPD требует различных записей для входящего и выходящего трафика. Можно считать, что это отдельные SPDs (входящая и выходящая). Кроме того, отдельная SPD должна существовать для каждого IPsec-интерфейса.

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

Каждая реализация IPsec должна иметь программный интерфейс, который позволяет системному администратору управлять SPD. SPD должна определять, какие действия должны быть выполнены в том или ином случае. Таким образом, программный интерфейс должен позволять специфицировать обработку, применяемую к любому пакету, входящему или выходящему из системы. Интерфейс управления для SPD должен допускать создание последовательности записей, и должна поддерживаться упорядоченность этих записей.

Возможно использование символа "*" в различных полях.

Определим стандартный набор элементов SPD, который должны поддерживать все реализации IPsec.

SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SAs. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPsec. Если применяется обработка IPsec, запись содержит описание SA (или узла SA), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС /SHA-1.

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

Так как политика безопасности может требовать, чтобы более одной SA применялось к трафику в определенной последовательности, запись политики в SPD должна эту последовательность определять.

SA (или узел SA) может быть хорошо структурирована или грубоструктурирована в зависимости от селекторов, используемых для определения трафика, обрабатываемого SA. Например, весь трафик между двумя хостами может быть направлен через единственную SA, и может быть определен лишь один набор сервисов безопасности. В другом случае трафик между парой хостов может направляться через несколько SAs, в зависимости от используемых приложений, с различными сервисами безопасности, предоставляемыми различными SAs. Аналогично, весь трафик между парой шлюзов безопасности может быть направлен через единственную SA, или для каждой взаимодействующей пары хостов может быть определена своя SA.

Безопасные Ассоциации

Понятие "Безопасные Ассоциации" (Security Association – SA) является фундаментальным в IPsec.

SA есть симплексное (однонаправленное) логическое соединение, создаваемое для обеспечения безопасности. Весь трафик, передаваемый по SA, некоторым образом обрабатывается в целях обеспечения безопасности. И AH, и ESP используют в своей работе SAs. Одной из основных функций IKE является установление SA. Опишем различные аспекты управления SA, определим требуемые характеристики управления политикой SA, обработку трафика и технологии управления SA.

Цели разработки

IPsec предназначен для безопасного взаимодействия на основе криптографии для IPv4 и IPv6. Набор сервисов безопасности включает управление доступом, целостность соединения, аутентификацию исходных данных, защиту от replay-атак (целостность последовательности), конфиденциальность (шифрование) и конфиденциальный поток трафика. Эти сервисы предоставляются на уровне IP, обеспечивая защиту для IP и/или протоколов более высокого уровня.

IPsec поддерживает две формы целостности: целостность соединения и частичную целостность последовательности. Целостность соединения является сервисом безопасности, который определяет модификацию конкретной IP датаграммы, безотносительно последовательности датаграмм в потоке трафика. Частичная целостность последовательности является anti-reply сервисом, с помощью которого определяется получение дубликатов IP датаграм.

Эти сервисы реализуются с использованием двух протоколов обеспечения безопасного трафика, Authentication Header (AH) и Encapsulating Security Payload (ESP), и с помощью процедур и протоколов управления криптографическим ключом. Множество применяемых IPsec протоколов и метод их использования определяются требованиями безопасности.

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

Определен стандартный набор алгоритмов по умолчанию для обеспечения интероперабельности. Использование этих алгоритмов совместно с защитой трафика на основе IPsec и протоколами управления ключа позволяет обеспечить высокую степень криптографической безопасности.

Безопасность, обеспечиваемая IPsec, зависит от многих факторов операционного окружения, в котором IPsec выполняется. Например, от безопасности ОС, источника случайных чисел, плохих протоколов управления системой и т.д.

Функциональности SA

Набор реализуемых SA сервисов безопасности зависит от выбранного протокола безопасности, режима SA, конечных точек SA и выбора дополнительных сервисов в протоколе. Например, AH обеспечивает аутентификацию исходных данных и целостность соединения для IP датаграм (в дальнейшем будем называть это "аутентификацией"). "Точность" сервиса аутентификации является функцией от степени детализованности SA, для которой используется AH.

AH также предоставляет анти-replay сервис (целостность отдельной последовательности) для получателя, помогая предотвратить атаки отказа в сервисе. AH применяется, когда не требуется конфиденциальность. AH также обеспечивает аутентификацию отдельных частей IP заголовка, за исключением изменяющихся частей IP заголовка.

ESP обеспечивает конфиденциальность трафика. Сила сервиса конфиденциальности зависит от используемого алгоритма шифрования. ESP также может дополнительно обеспечивать аутентификацию. Область аутентификации, обеспечиваемая ESP, является более узкой по сравнению с AH, т.е. IP-заголовок (заголовки), "внешние" по отношению к ESP заголовку, не защищены. Если аутентификация нужна только протоколам более высокого уровня, то аутентификация ESP является подходящей альтернативой, причем более эффективной, чем использование AH, инкапсулирующего ESP. Если для ESP SA используется аутентификация, получатель также может выбрать усиление использованием анти-replay сервиса с теми же самыми возможностями, что и AH анти-replay сервис. Хотя и конфиденциальность, и аутентификация являются необязательными, оба сервиса не могут быть опущены. По крайней мере, один из них должен присутствовать.

Использование туннелирующего режима позволяет зашифровывать внутренние IP заголовки, скрывая отправителя и получателя. Следует заметить, что сильно детализированные SAs обычно являются более уязвимыми для анализа трафика, чем слабо детализированные.

Где может размещаться IPsec

Существует несколько способов реализации IPsec на хосте или в соединении с роутером или firewall (для создания безопасного шлюза). Приведем несколько общих примеров:

Интеграция IPsec в конкретную реализацию IP. Это требует доступа к исходному коду IP и применимо как к хостам, так и к шлюзам безопасности.Bump-in-the-stack (BITS) реализации, где IPsec реализован "внизу" существующей реализации стека протоколов IP, между обычным IP и локальными сетевыми драйверами. Доступа к исходному коду стека IP в данном контексте не требуется, что делает такой подход пригодным для встраивания в существующие системы. Данный подход обычно реализуется на хостах.Использование внешнего криптопроцессора (обычно в военных и в некоторых коммерческих системах). Как правило, это является Bump-in-the-stack (BITS) реализацией. Такие реализации могут использоваться как на хостах, так и на шлюзах. Обычно BITS-устройства являются IP-адресуемыми.

Как работает IPsec

IPsec использует два протокола для обеспечения безопасности трафика – Authentication Header (AH) и Encapsulating Security Payload (ESP).

Authentication Header (AH) обеспечивает целостность соединения, аутентификацию исходных данных и дополнительно может обеспечивать anti-replay сервис.Encapsulating Security Payload (ESP) протокол может обеспечивать конфиденциальность (шифрование) трафика. ESP также может обеспечивать целостность соединения, аутентификацию исходных данных и дополнительно anti-replay сервис. Целостность обеспечивается только для протоколов более высокого уровня. Хотя бы один из этих сервисов должен быть задействован при использовании ESP.

Эти протоколы могут применяться как по отдельности так и в комбинации с друг другом для обеспечения необходимого набора сервисов безопасности в IPv4 и IPv6. Каждый протокол поддерживает два режима использования: режим транспорта и режим туннелирования. В транспортном режиме протоколы обеспечивают защиту главным образом для протоколов более высокого уровня; в режиме туннелирования протоколы применяются для скрытия IP-заголовков исходных пакетов. Разница между двумя режимами рассматривается дальше.

IPsec позволяет системному администратору управлять детализацией, с которой предоставляется сервис безопасности. Например, можно создать единственный зашифрованный туннель между двумя безопасными шлюзами, или для каждого ТСР соединения может быть создан зашифрованный туннель между парой хостов. IPsec позволяет указывать следующие параметры:

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

Комбинации SA

Иногда политика безопасности может требовать комбинации сервисов для конкретного потока трафика. В таких случаях необходимо установить несколько SAs для реализации принятой политики безопасности. Термин "узел безопасных ассоциаций" или "узел SA" применяется к последовательности SA, через которые должен проходить трафик для обеспечения требуемой политики безопасности. Заметим, что SAs, которые образуют узел, могут заканчиваться в различных точках.

Безопасные aссоциации могут комбинироваться в узлы двумя способами: транспортное соседство и повторное туннелирование.

Транспортное соседство означает применение более одного протокола для одной и той же IP датаграммы без использования туннелирования. Данный подход при комбинировании AH и ESP допускает только один уровень комбинации; дальнейшие вложенные поля не добавляют преимущества (в случае использования одинаково сильных алгоритмов для каждого протокола).

Рис. 23.1. Транспортное средство SAs

Повторное туннелирование означает применение нескольких протоколов, выполняющих туннелирование.

Существует три основных варианта повторного туннелирования:

Оба конца SAs являются одинаковыми – внутренний и внешний туннели могут быть каждый AH или ESP, хотя маловероятно, что протоколы будут одинаковые, например, AH внутри AH или ESP внутри ESP.

Рис. 23.2. Повторное туннелирование SAs – оба конца одинаковы

Один конец нескольких SAs является одним и тем же – внутренний и внешний туннели могут оба быть AH или ESP.

Рис. 23.3. Повторное туннелирование SAs – один конец общий

Ни один из концов нескольких SAs не является одним и тем же – каждый внутренний и внешний туннели могут быть AH или ESP.

Рис. 23.4. Повторное туннелирование SAs – оба конца разные

Эти два подхода также могут комбинироваться, например, узел SA может быть сконструирован из одного SA туннелироющего режима и одного или двух SAs транспортного режима, применяемых последовательно.

Обзор системы

Опишем функционирование IPsec, компоненты системы и то, как они взаимодействуют друг с другом для обеспечения сервисов безопасности.

IPsec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP- трафика. Термин "шлюз безопасности" используется для обозначения промежуточной системы, которая реализует IPsec-протоколы. Защита основана на требованиях, определенных в Базе Данных Политики Безопасности (Security Policy Database- SPD), определяемой и поддерживаемой системным администратором. Пакеты обрабатываются одним из трех способов на основании соответствия информации заголовка IP или транспортного уровня записям в SPD. Каждый пакет либо отбрасывается сервисом безопасности IPsec, либо пропускается без изменения, либо обрабатывается сервисом IPsec на основе применения определенной политики.

IPsec обеспечивает сервисы безопасности на IP-уровне, выбирая нужные протоколы безопасности, определяя алгоритмы, используемые сервисами, и предоставляя все криптографические ключи требуемым сервисам. IPsec может использоваться для защиты одного или нескольких "путей" между парой хостов, между парой шлюзов безопасности или между шлюзом безопасности и хостом.

Определения

SA есть совокупность параметров соединения, которые дают возможность сервисам обеспечивать безопасный трафик. SA определяет использование AH или ESP. Если к потоку трафика применяются оба протокола, AH и ESP, то создаются две SAs. При двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется два SA (по одному на каждое направление).

SA однозначно определяется тройкой, состоящей из Security Parameter Index (SPI), IP Destination Address (адресом назначения) и идентификатора протокола безопасности (AH или ESP). В принципе адрес назначения может быть единственным адресом, широковещательным (broadcast) адресом или групповым (multicast) адресом. Однако механизм управления SA в настоящее время определяется только для единственной SA. Следовательно, SAs будут описаны в контексте point-to-point соединения, даже если концепция также применяется в случае point-to-multipoint.

Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка.

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

B туннелирующем режиме SA существует "внешний" IP заголовок, который определяет пункт назначения IPsec, и "внутренний" IP заголовок, который определяет конечный пункт назначения для пакета. Заголовок протокола безопасности расположен после внешнего IP заголовка и перед внутренним IP заголовком. Если AH используется в туннелирующем режиме, части внешнего IP заголовка являются защищенными, как и весь туннелируемый IP пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, зашита обеспечивается только для туннелируемого пакета, а не для внешнего IP-заголовка.

Кратко подытожим:

Хост может поддерживать оба режима, как транспортный, так и туннелирующий.Шлюз безопасности может использовать только туннелирующий режим. Если он поддерживает транспортный режим, то этот режим должен использоваться только тогда, когда безопасный шлюз является хостом, например, для управления сетью.

Примеры комбинаций SA

Приведем четыре примера комбинаций SA, которые должны поддерживаться IPsec-хостами и шлюзами безопасности. Дополнительные комбинации AH и/или ESP в туннелирующем и/или транспортном режимах могут поддерживаться по усмотрению разработчиков. Реализации должны иметь возможность создавать и обрабатывать эти четыре комбинации. Введем следующие обозначения:

=	-	одна или более SA (AH или ESP, транспорт или туннель);
–	-	соединение (или административная граница);
Нх	-	хост х;
SGx	-	шлюз безопасности х;
Х*	-	Х поддерживает IPsec.

Замечание: рассматриваемые ниже безопасные ассоциации могут быть как AH, так и ESP. Режим (туннель или транспорт) определяется характером конечных точек. Для host-to-host SAs режим может быть как транспортным, так и туннелирующим.

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

Вариант 1. Обеспечение end-to-end безопасности между двумя хостами через Internet (или intranet)

Таблица 23.1. Последовательность заголовков при соединении Host-Host

Transport	Tunnel
1. [IP1] [AH] [upper]	1. [IP2] [AH] [IP1] [upper]
2. [IP1] [ESP] [upper]	2. [IP2] [ESP] [IP1] [upper]
3. [IP1] [AH] [ESP] [upper]

Во втором варианте требуется только туннелирующий режим. При этом заголовки в пакете между SG1 и SG2 должны выглядеть как в таб. 23.2.

Вариант 2. Создание простых виртуальных частных сетей

Таблица 23.2. Последовательность заголовков при соединении SG-SG

Tunnel

1. [IP2] [AH] [IP1] [upper]

2. [IP2] [ESP] [IP1] [upper]

Вариант 3. Комбинация вариантов 1 и 2 путем добавления end-to-end безопасности между хостами отправителя и получателя. Для хостов или шлюзов безопасности не вводится новых требований, кроме требования, чтобы шлюз безопасности был сконфигурирован для прохождения IPsec-трафика (включая ISAKMP трафик) для хостов позади него.

Вариант 4. Рассматривается случай, когда удаленный хост (Н1) использует Internet для достижения firewall'a организации ( SG2) и затем получает доступ к некоторому серверу или другой машине (Н2). Удаленный хост может быть мобильным хостом (Н1), подсоединяющимся по dial up к локальному РРР серверу (на диаграмме это не показано) по Internet и затем проходящему по Internet к firewall организации (SG2) и т.д.

Между Н1 и SG2 возможен только туннелирующий режим. Вариант для SA между Н1 и SG2 может быть быть один из тех, что представлены в варианте 2. Альтернатива для SA между Н1 и Н2 должна быть одной из тех, что представлены в варианте 1.

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

Поддержка дополнительных комбинаций AH и ESP не является обязательной. Дополнительные комбинации могут неблагоприятно сказываться на интероперабельности.

Проблемы выполнения

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

Использование IPsec также увеличивает стоимость компонентов, осуществляющих пересылку и роутинг в инфраструктуре Internet, но не реализующих IPsec. Это происходит из-за возрастания размера пакета в результате добавления заголовков AH и/или ESP, AH и ESP туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве примеров это возрастание не будет сильно влиять на инфраструктуру Internet.

Ручные технологии

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

SA и Управление Ключом

IPsec поддерживает как ручные, так и автоматически созданные SA и соответствующее управление криптографическими ключами. Протоколы AH и ESP практически не зависят от используемых технологий управления ключом, хотя эти технологии могут некоторым образом влиять на сервисы безопасности, предоставляемые протоколами. Например, дополнительные anti-replay сервисы требуют автоматического управления SA. Более того, детализированность используемого распределения ключа определяет детализированность предоставляемой аутентификации.

Рассмотрим архитектуру семейства протоколов IPsec.

Рассмотрим архитектуру семейства протоколов IPsec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP в окружении как IPv4, так и IPv6. Кроме того, будут представлены сервисы безопасности, предоставляемые протоколами IPsec, и применение этих сервисов в IP окружении. Затем мы обсудим следующие компоненты архитектуры безопасности IPsec:
Протоколы безопасности – Authentication Header (AH) и Encapsulating Security Payload (ESP).Безопасные Ассоциации – что это такое, как они работают и как ими управлять.Управление ключом – ручное и автоматическое (Internet Key Exchange – IKE).Алгоритмы, используемые для аутентификации и шифрования.

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

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

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

Рис. 24.3. Атрибуты данных

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 октета.

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

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

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

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

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

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

Рис. 24.24. Определение Aggressive Mode при выполнении pre-shared аутентификации

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

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

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

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

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

Рис. 24.21. Аутентификация пересмотренного режима шифрования Main Mode

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

Рис. 24.22. Аутентификация пересмотренного режима шифрования 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 аутентификации шифрованием открытым ключом

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

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

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

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

Рис. 24.19. Аутентификация шифрования Main Mode

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

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

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

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

Рис. 24.20. Аутентификация шифрования Aggressive Mode

Фаза 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.

Рис. 24.25. Определение 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 и ключах согласно рис.24.26.

Рис. 24.26. Определение SAs и ключей при использовании Quick Mode

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

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

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

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

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

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

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

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

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

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

Рис. 24.1. Формат заголовка 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 не может предполагать существования сервисов безопасности, должна обеспечиваться некоторая степень защиты. Следовательно, 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-CookieR-CookieMessage IDSPI

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 по своей природе являются двунаправленными.

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

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

Рис. 24.17. Main Mode с аутентификацией с помощью подписи

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

Рис. 24.18. Aggressive Mode с аутентификацией с помощью подписи

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

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

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

Информационные обмены 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 содержимого.

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

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

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 тем способом, который определен для каждого алгоритма.

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.

Обмены

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

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

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

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

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

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

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

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

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

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

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

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

Содержимое Certificate

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

Рис. 24.9. Формат 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. На рис. 24.10 показан формат Certificate Request Payload.

Рис. 24.10. Формат Сertificate Request Payload

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

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

Содержимое Delete

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

Рис. 24.15. Формат Delete Payload

Удаление, которое относится к 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.

Содержимое HASH

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

Рис. 24.11. Формат HASH Payload

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

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

Содержимое Identification

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

Рис. 24.8. Формат 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.

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

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

Рис. 24.7. Формат Key Exchange Payload

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

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

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

Содержимое Nonce

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

Рис. 24.13. Формат Nonce Payload

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

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

Содержимое Notification

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

Рис. 24.14. Формат Notification Data

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.

Содержимое Proposal

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

Рис. 24.5. Формат 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.

Содержимое SA

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

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

Содержимое Signature

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

Рис. 24.12. Формат Signature Payload

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

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

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

Содержимое Transform

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

Рис. 24.6. Формат 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.

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

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

Рис. 24.16. Формат Vendor ID Payload

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

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

Содержимые ISAKMP

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

Создание 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

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

и форматы пакетов для ведения

Рассмотрим Безопасную Ассоциацию 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 установлена не будет.

Абсолютная защита от отказа в сервисе невозможна, но такой знак анти-препятствия предоставляет технологию для того, чтобы сделать защиту более надежной.
Следует заметить, что в обменах, показанных далее, механизм анти-препятствия должен использоваться вместе с механизмом сбора мусора; атакующий может завалить сервер, используя пакеты с поддельными IP- адресами. Подобные технологии управления памятью должны быть внедрены в протоколы, использующие ISAKMP.
ISAKMP предотвращает создание соединения с атакующим, объединяя аутентификацию, обмен ключа и создание SA. Это объединение не позволяет злоумышленнику дождаться завершения аутентификации и затем осуществить имперсонизацию в одну из аутентифицированных сущностей.
Атаки man-in-the-middle включают перехват, вставку, уничтожение и модификацию сообщений, отправку сообщений назад отправителю, повтор старых сообщений и перенаправление сообщений. ISAKMP предупреждает все эти типы атак. Объединение сообщений ISAKMP защищает от возможности встроить сообщения в обмены протокола. Протокол ISAKMP позволяет хосту обнаружить уничтоженные сообщения. Требование наличия нового cookie с новой отметкой времени для каждого нового установления SA предотвращает атаки, которые включают повтор старых сообщений. Требование ISAKMP сильной аутентификации предотвращает установление SA с кем-то, кроме заданного участника. Сообщения можно перенаправить к другому получателю или модифицировать, но это будет обнаружено, и SA установлена не будет.