|
2. ОСНОВНЫЕ СОСТАВЛЯЮЩИЕ АРХИТЕКТУРЫ И ИХ ОСОБЕННОСТИ
3. РАЗМЕЩЕНИЕ И ФУНКЦИОНИРОВАНИЕ IPSEC
4. КОНТЕКСТЫ (АССОЦИАЦИИ) БЕЗОПАСНОСТИ И УПРАВЛЕНИЕ КЛЮЧАМИ
5. ПРОТОКОЛЬНЫЕ КОНТЕКСТЫ (АССОЦИАЦИИ) И ПОЛИТИКА БЕЗОПАСНОСТИ
6. АУТЕНТИФИКАЦИОННЫЙ ЗАГОЛОВОК (AH)
7. БЕЗОПАСНОЕ СОКРЫТИЕ СУЩЕСТВЕННЫХ ДАННЫХ
8. ПРОТОКОЛ ОБМЕНА КЛЮЧАМИ - IKE
9. РАСШИРЕННЫЙ ОБЗОР БЕЗОПАСНЫХ АССОЦИАЦИЙ (КОНТЕКСТОВ)
10. INTERNET SECURITY ASSOCIATION AND KEY MANAGEMENT PROTOCOL (ISAKMP)
IPSec (сокращение от IP Security) - определенный IETF стандарт достоверной/конфиденциальной передачи данных по сетям IP. Чаще всего IPSec используется для создания VPN (Virtual Private Network).
IPSec является неотъемлемой частью IPv6 - Интернет-протокола следующего поколения, и расширением существующие версии Интернет-протокола IPv4. IPSec определён в RFC с 2401 по 2412.
Практически все механизмы сетевой безопасности могут быть реализованы на третьем уровне эталонной модели ISO/OSI в соответствии с рисунком 1.1. Кроме того, IP-уровень можно считать оптимальным для размещения защитных средств, поскольку при этом достигается удачный компромисс между защищенностью, эффективностью функционирования и прозрачностью для приложений.
Рисунок 1.1 - Модель OSI/ISO
Стандартизованными механизмами IP-безопасности могут (и должны) пользоваться протоколы более высоких уровней и, в частности, управляющие протоколы, протоколы конфигурирования и маршрутизации.
Средства безопасности для IP описываются семейством спецификаций IPSec, разработанных рабочей группой IP Security.
Протоколы IPSec обеспечивают управление доступом, целостность вне соединения, аутентификацию источника данных, защиту от воспроизведения, конфиденциальность и частичную защиту от анализа трафика.
Основополагающими понятиями IPSec являются:
- аутентификационный заголовок (АН);
- безопасное сокрытие данных (ESP);
- режимы работы: туннельный и транспортный;
- контексты (ассоциации) безопасности (SA);
- управление ключами (IKE);
2. ОСНОВНЫЕ СОСТАВЛЯЮЩИЕ АРХИТЕКТУРЫ И ИХ ОСОБЕННОСТИ
Архитектура средств безопасности для IP-уровня специфицирована в документе Security Architecture for the Internet Protocol. Ее основные составляющие представлены в соответствии с рисунком 2.1. Это, прежде всего протоколы обеспечения аутентичности (протокол аутентифицирующего заголовка - Authentication Header, AH) и конфиденциальности (протокол инкапсулирующей защиты содержимого - Encapsulating Security payload, ESP), а также механизмы управления криптографическими ключами. На более низком архитектурном уровне располагаются конкретные алгоритмы шифрования, контроля целостности и аутентичности. Наконец, роль фундамента выполняет так называемый домен интерпретации (Domain of Interpretation, DOI), являющийся, по сути, базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах.
Рисунок 2.1 - Основные элементы архитектуры средств безопасности IP-уровня
Деление на уровни важно для всех аспектов информационных технологий. Там же, где участвует еще и криптография, важность возрастает вдвойне, поскольку приходится считаться не только с чисто техническими факторами, но и с особенностями законодательства различных стран, с ограничениями на экспорт и/или импорт криптосредств.
IPSec поддерживает две формы целостности: целостность соединения и частичную целостность последовательности. Целостность соединения является сервисом безопасности, который определяет модификацию конкретной IP датаграммы, безотносительно последовательности датаграмм в потоке трафика. Частичная целостность последовательности является anti-reply сервисом, с помощью которого определяется получение дубликатов IP датаграм.
Эти сервисы как раз и реализуются с использованием двух протоколов обеспечения безопасного трафика, Authentication Header (AH) и Encapsulating Security Payload (ESP), и с помощью процедур и протоколов управления криптографическим ключом. Множество применяемых IPSec протоколов и метод их использования определяются требованиями безопасности.
Когда данные механизмы установлены корректно, они не мешают пользователям, хостам и другим компонентам Internet, которые не применяют данные механизмы безопасности для защиты своего трафика. Протоколы обеспечения аутентичности и конфиденциальности в IPSec не зависят от конкретных криптографических алгоритмов. (Более того, само деление на аутентичность и конфиденциальность предоставляет и разработчикам, и пользователям дополнительную степень свободы в ситуации, когда к криптографическим относят только шифровальные средства.) В каждой стране могут применяться свои алгоритмы, соответствующие национальным стандартам, но для этого, как минимум, нужно позаботиться об их регистрации в домене интерпретации. Это означает возможность выбора различного набора алгоритмов без воздействия на другие части реализации. Например, различные группы пользователей могут выбрать при необходимости различные наборы алгоритмов.
Определен стандартный набор алгоритмов по умолчанию для обеспечения интероперабельности. Использование этих алгоритмов совместно с защитой трафика на основе IPSec и протоколами управления ключа позволяет обеспечить высокую степень криптографической безопасности.
Алгоритмическая независимость протоколов имеет и оборотную сторону, состоящую в необходимости предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых общающимися сторонами. Иными словами, стороны должны выработать общий контекст безопасности (Security Association, SA) и затем использовать такие его элементы, как алгоритмы и их ключи. SA подробно рассматривается далее. За формирование контекстов безопасности в IPSec отвечает особое семейство протоколов ISAKMP, которое рассматривается также в отдельном разделе.
Безопасность, обеспечиваемая IPSec, зависит от многих факторов операционного окружения, в котором IPSec выполняется. Например, от безопасности ОС, источника случайных чисел, плохих протоколов управления системой.
3. РАЗМЕЩЕНИЕ И ФУНКЦИОНИРОВАНИЕ IPSEC
IPSec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP- трафика. Термин <шлюз безопасности> используется для обозначения промежуточной системы, которая реализует IPSec-протоколы. Защита основана на требованиях, определенных в Базе Данных Политики Безопасности (Security Policy Database- SPD), определяемой и поддерживаемой системным администратором. Пакеты обрабатываются одним из трех способов на основании соответствия информации заголовка IP или транспортного уровня записям в SPD. Каждый пакет либо отбрасывается сервисом безопасности IPSec, либо пропускается без изменения, либо обрабатывается сервисом IPSec на основе применения определенной политики.
IPSec обеспечивает сервисы безопасности на IP-уровне, выбирая нужные протоколы безопасности, определяя алгоритмы, используемые сервисами, и предоставляя все криптографические ключи требуемым сервисам. IPSec может использоваться для защиты одного или нескольких <путей> между парой хостов, между парой шлюзов безопасности или между шлюзом безопасности и хостом.
IPSec использует два протокола для обеспечения безопасности трафика - Authentication Header (AH) и Encapsulating Security Payload (ESP). Хотя бы один из этих сервисов должен быть задействован при использовании ESP.
Эти протоколы могут применяться как по отдельности так и в комбинации с друг другом для обеспечения необходимого набора сервисов безопасности в IPv4 и IPv6. Каждый протокол поддерживает два режима использования: режим транспорта и режим туннелирования. В транспортном режиме протоколы обеспечивают защиту главным образом для протоколов более высокого уровня; в режиме туннелирования протоколы применяются для скрытия IP-заголовков исходных пакетов. Разница между двумя режимами рассматривается дальше.
IPSec позволяет системному администратору управлять детализацией, с которой предоставляется сервис безопасности. Например, можно создать единственный зашифрованный туннель между двумя безопасными шлюзами, или для каждого ТСР соединения может быть создан зашифрованный туннель между парой хостов. IPSec позволяет указывать следующие параметры:
а) какие сервисы используются, и в какой комбинации;
б) необходимый уровень детализации применяемой защиты;
в) алгоритмы, используемые для обеспечения безопасности на основе криптографии;
Существует несколько способов реализации IPSec на хосте или в соединении с роутером или firewall (для создания безопасного шлюза). Несколько общих примеров:
а) интеграция IPSec в конкретную реализацию IP, что требует доступа к исходному коду IP и применимо как к хостам, так и к шлюзам безопасности;
б) bump-in-the-stack (BITS) реализации, где IPSec действует <внизу> существующей реализации стека протоколов IP, между обычным IP и локальными сетевыми драйверами; доступа к исходному коду стека IP в данном контексте не требуется, что делает такой подход пригодным для встраивания в существующие системы, и реализации на хостах;
в) использование внешнего криптопроцессора (обычно в военных и в некоторых коммерческих системах), как правило, это является Bump-in-the-stack (BITS) реализацией, используется как на хостах, так и на шлюзах, обычно BITS-устройства являются IP-адресуемыми;
В этом варианте механизмы безопасности применяются только для протоколов, начиная с транспортного (TCP) уровня и выше, оставляя данные самого сетевого уровня (заголовок IP) без дополнительной защиты. Места размещения дополнительной информации, вставляемой протоколами в пакет, представлены в соответствии с рисунком 3.1.
Рисунок 3.1 - Транспортный режим
Туннельный режим работы.
Этот режим интересен тем, что обеспечивает защиту также и данных сетевого уровня путем добавления нового IP-заголовка. После определения ассоциаций безопасности (например, между двумя шлюзами) истинные адреса хостов отправления и назначения (и другие служебные поля) полностью защищаются от модификаций для АН или вообще скрываются для ESP, а в новый заголовок выставляются адреса и другие данные для шлюзов (отправления/получения). В соответствии с рисунком 3.2 видны преимущества и недостатки обоих протоколов. ESP обеспечивает сокрытие данных, но не полную аутентификацию всего пакета. АН полностью аутентифицирует, но не скрывает данные. В этом причина того, что для обеспечения высокого уровня безопасности, применение протоколов совмещается.
Рисунок 3.2 - Туннельный режим
4. КОНТЕКСТЫ (АССОЦИАЦИИ) БЕЗОПАСНОСТИ И УПРАВЛЕНИЕ КЛЮЧАМИ
Формирование контекстов безопасности в IPSec разделено на две фазы. Сначала создается управляющий контекст, назначение которого - предоставить доверенный канал, т. е. аутентифицированный, защищенный канал для выработки (в рамках второй фазы) протокольных контекстов и, в частности, для формирования криптографических ключей, используемых протоколами AH и ESP.
В принципе, для функционирования механизмов IPSec необходимы только протокольные контексты; управляющий играет вспомогательную роль. Более того, явное выделение двух фаз утяжеляет и усложняет формирование ключей, если рассматривать последнее как однократное действие. Тем не менее, из архитектурных соображений управляющие контексты не только могут, но и должны существовать, поскольку обслуживают все протокольные уровни стека TCP/IP, концентрируя в одном месте необходимую функциональность. Первая фаза начинается в ситуации, когда взаимодействующие стороны не имеют общих секретов (общих ключей) и не уверены в аутентичности друг друга. Если с самого начала не создать доверенный канал, то для выполнения каждого управляющего действия с ключами (их модификация, выдача диагностических сообщений и т.п.) в каждом протоколе (AH, ESP, TLS и т.д.) этот канал придется формировать заново.
Общие вопросы формирования контекстов безопасности и управления ключами освещаются в спецификации "Контексты безопасности и управление ключами в Internet" (Internet Security Association and Key Management Protocol, ISAKMP). Здесь вводятся две фазы выработки протокольных ключей, определяются виды управляющих информационных обменов и используемые форматы заголовков и данных. Иными словами строится протокольно-независимый каркас.
Существует несколько способов формирования управляющего контекста. Они различаются двумя показателями:
- используемым механизмом выработки общего секретного ключа;
- степенью защиты идентификаторов общающихся сторон;
В простейшем случае секретные ключи задаются заранее (ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, но он не является масштабируемым. Последнее свойство может быть обеспечено при автоматической выработке и распределении секретных ключей в рамках протоколов, основанных на алгоритме Диффи-Хелмана. Пример тому - "Протокол для обмена ключами в Internet " (The Internet Key Exchange, IKE).
При формировании управляющего контекста идентификаторы общающихся сторон (например, IP-адреса) могут передаваться в открытом виде или шифроваться. Поскольку ISAKMP предусматривает функционирование в режиме клиент/сервер (т. е. ISAKMP-сервер может формировать контекст для клиента), сокрытие идентификаторов в определенной степени повышает защищенность от пассивного прослушивания сети.
Последовательность передаваемых сообщений, позволяющих сформировать управляющий контекст и обеспечивающих защиту идентификаторов, выглядит в соответствии с рисунком 4.1.
Рисунок 4.1 - Формирование управляющего контекста
В первом сообщении (1) инициатор направляет предложения по набору защитных алгоритмов и конкретных механизмов их реализации. Предложения упорядочиваются по степени предпочтительности (для инициатора). В ответном сообщении (2) партнер информирует о сделанном выборе - какие алгоритмы и механизмы его устраивают. Для каждого класса защитных средств (генерация ключей, аутентификация, шифрование) выбирается только один элемент.
В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа (опускаются детали, специфичные для алгоритма Диффи-Хелмана). Одноразовые номера (nonce) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений.
Посредством сообщений (5) и (6) происходит обмен идентификационной информацией, подписанной (с целью аутентификации) секретным ключом отправителя и зашифрованной выработанным на предыдущих шагах общим секретным ключом. Для аутентификации предполагается использование сертификатов открытых ключей. В число подписываемых данных входят одноразовые номера.
В представленном виде протокол формирования управляющего контекста защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на доступность, для которых характерно прежде всего навязывание интенсивных вычислений, присущих криптографии с открытым ключом, применяются так называемые идентифицирующие цепочки (cookies). Эти цепочки, формируемые инициатором и его партнером с использованием текущего времени (для защиты от воспроизведения), на самом деле присутствуют во всех ISAKMP-сообщениях и в совокупности идентифицируют управляющий контекст (в первом сообщении, по понятным причинам, фигурирует только цепочка инициатора). Согласно спецификациям, заголовок ISAKMP-сообщения имеет вид в соответствии с рисунком 4.2. Если злоумышленник пытается "завалить" кого-либо запросами на создание управляющего контекста, подделывая при этом свой IP-адрес, то в сообщении (3) он не сможет предъявить идентифицирующую цепочку партнера, поэтому до выработки общего секретного ключа и, тем более, электронной подписи и полномасштабной проверки аутентичности дело попросту не дойдет.
Рисунок 4.2 - Формат заголовка ISAKMP-сообщения
Управляющие контексты являются двунаправленными в том смысле, что любая из общающихся сторон может инициировать с их помощью выработку новых протокольных контекстов или иные действия. Для передачи ISAKMP-сообщений используется любой протокол, однако в качестве стандартного принят UDP с номером порта 500.
5. ПРОТОКОЛЬНЫЕ КОНТЕКСТЫ (АССОЦИАЦИИ) И ПОЛИТИКА БЕЗОПАСНОСТИ
Системы, реализующие IPSec, должны поддерживать две базы данных:
- базу данных политики безопасности (Security Policy Database, SPD);
- базу данных протокольных контекстов безопасности (Security Association Database, SAD);
Все IP-пакеты (входящие и исходящие) сопоставляются с упорядоченным набором правил политики безопасности. При сопоставлении используется фигурирующий в каждом правиле селектор - совокупность анализируемых полей сетевого уровня и более высоких протокольных уровней. Первое подходящее правило определяет дальнейшую судьбу пакета:
- пакет может быть ликвидирован;
- пакет может быть обработан без участия средств IPSec;
- пакет должен быть обработан средствами IPSec с учетом набора протокольных контекстов, ассоциированных с правилом;
Таким образом, системы, реализующие IPSec, функционируют как межсетевые экраны, фильтруя и преобразуя потоки данных на основе предварительно заданной политики безопасности.
Далее рассматриваются контексты и политика безопасности, а также порядок обработки сетевых пакетов.
Протокольный контекст безопасности в IPSec - это однонаправленное "соединение" (от источника к получателю), предоставляющее обслуживаемым потокам данных набор защитных сервисов в рамках какого-то одного протокола (AH или ESP). В случае симметричного взаимодействия партнерам придется организовать два контекста (по одному в каждом направлении). Если используются и AH, и ESP, потребуется четыре контекста.
Элементы базы данных протокольных контекстов содержат следующие поля (в каждом конкретном случае некоторые значения полей будут пустыми):
- используемый в протоколе AH алгоритм аутентификации, его ключи и т.п.;
- используемый в протоколе ESP алгоритм шифрования, его ключи, начальный вектор и т.п.;
- используемый в протоколе ESP алгоритм аутентификации, его ключи и т.п.;
- время жизни контекста;
- режим работы IPSec: транспортный или туннельный;
- максимальный размер пакетов;
- группа полей (счетчик, окно, флаги) для защиты от воспроизведения пакетов;
Пользователями протокольных контекстов, как правило, являются прикладные процессы. Вообще говоря, между двумя узлами сети может существовать произвольное число протокольных контекстов, так как число приложений в узлах произвольно. В качестве пользователей управляющих контекстов обычно выступают узлы сети (поскольку в этих контекстах желательно сосредоточить общую функциональность, необходимую сервисам безопасности всех протокольных уровней эталонной модели для управления криптографическими ключами).
Управляющие контексты - двусторонние, т. е. любой из партнеров может инициировать новый ключевой обмен. Пара узлов может одновременно поддерживать несколько активных управляющих контекстов, если имеются приложения с существенно разными криптографическими требованиями. Например, допустима выработка части ключей на основе предварительно распределенного материала, в то время как другая часть порождается по алгоритму Диффи-Хелмана.
Протокольный контекст для IPSec идентифицируется целевым IP-адресом, протоколом (AH или ESP), а также дополнительной величиной - индексом параметров безопасности (Security Parameter Index, SPI). Последняя величина необходима, поскольку могут существовать несколько контекстов с одинаковыми IP-адресами и протоколами. Далее показано, как используются индексы SPI при обработке входящих пакетов.
IPSec обязывает поддерживать ручное и автоматическое управление контекстами безопасности и криптографическими ключами. В первом случае все системы заранее снабжаются ключевым материалом и иными данными, необходимыми для защищенного взаимодействия с другими системами. Во втором - материал и данные вырабатываются динамически, на основе определенного протокола - IKE, поддержка которого обязательна.
Протокольный контекст создается на базе управляющего с использованием ключевого материала и средств аутентификации и шифрования последнего. В простейшем случае, когда протокольные ключи генерируются на основе существующих, последовательность передаваемых сообщений выглядит в соответствии с рисунком 5.1.
Рисунок 5.1 - Формирование протокольного контекста
Когда вырабатывался управляющий контекст, для него было создано три вида ключей:
- SKEYID_d - ключевой материал, используемый для генерации протокольных ключей;
- SKEYID_a - ключевой материал для аутентификации;
- SKEYID_e - ключевой материал для шифрования;
Все перечисленные виды ключей задействованы в обмене. Ключом SKEYID_e шифруются сообщения. Ключ SKEYID_a служит аргументом хэш-функций и тем самым аутентифицирует сообщения. Наконец, протокольные ключи - результат применения псевдослучайной (хэш) функции к SKEYID_d с дополнительными параметрами, в число которых входят одноразовые номера инициатора и партнера. В результате создание протокольного контекста оказывается аутентифицированным, защищенным от несанкционированного ознакомления, от воспроизведения сообщений и от перехвата соединения.
Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки "совсем новых" секретных ключей или идентификаторы клиентов, от имени которых ISAKMP-серверы формируют протокольный контекст. В соответствии с протоколом IKE, за один обмен (состоящий из трех показанных сообщений) формируется два однонаправленных контекста - по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SPI), помогающий находить контекст для обработки принимаемых пакетов IPSec.
Протокольные контексты играют вспомогательную роль, будучи лишь средством проведения в жизнь политики безопасности; она должна быть задана для каждого сетевого интерфейса с задействованными средствами IPSec и для каждого направления потоков данных (входящие/исходящие). Согласно спецификациям IPSec, политика рассчитывается на бесконтекстную (независимую) обработку IP-пакетов, в духе современных фильтрующих маршрутизаторов. Разумеется, должны существовать средства администрирования базы данных SPD, так же, как и средства администрирования базы правил межсетевого экрана, однако этот аспект не входит в число стандартизуемых.
С внешней точки зрения, база данных политики безопасности (SPD) представляет собой упорядоченный набор правил. Каждое правило задается как пара:
- совокупность селекторов;
- совокупность протокольных контекстов безопасности;
Селекторы служат для отбора пакетов, контексты задают требуемую обработку. Если правило ссылается на несуществующий контекст, оно должно содержать достаточную информацию для его (контекста) динамического создания. В этом случае требуется поддержка автоматического управления контекстами и ключами. В принципе, функционирование системы может начинаться с задания базы SPD при пустой базе контекстов (SAD); последняя будет наполняться по мере необходимости.
Дифференцированность политики безопасности определяется селекторами, употребленными в правилах. Например, пара взаимодействующих хостов может использовать единственный набор контекстов, если в селекторах фигурируют только IP-адреса; с другой стороны, набор может быть своим для каждого приложения, если анализируются номера TCP- и UDP-портов. Аналогично, два защитных шлюза способны организовать единый туннель для всех обслуживаемых хостов или же расщепить его (путем организации разных контекстов) по парам хостов или даже приложений.
Все реализации IPSec должны поддерживать селекцию следующих элементов:
- исходный и целевой IP-адреса (адреса могут быть индивидуальными и групповыми, в правилах допускаются диапазоны адресов и метасимволы "любой";
- имя пользователя или узла в формате DNS или X.500;
- транспортный протокол;
- номера исходного и целевого портов (здесь также могут использоваться диапазоны и метасимволы);
Обработка исходящего и входящего трафика, не является симметричной. Для исходящих пакетов просматривается база SPD, находится подходящее правило, извлекаются ассоциированные с ним протокольные контексты и применяются соответствующие механизмы безопасности. Во входящих пакетах для каждого защитного протокола уже проставлено значение SPI, однозначно определяющее контекст. Просмотр базы SPD в таком случае не требуется; можно считать, что политика безопасности учитывалась при формировании соответствующего контекста. (Практически это означает, что ISAKMP-пакеты нуждаются в особой трактовке, а правила с соответствующими селекторами должны быть включены в SPD.)
Отмеченная асимметрия отражает определенную незавершенность архитектуры IPSec. В более раннем документе RFC 1825 понятия базы данных политики безопасности и селекторов отсутствовали. В новой редакции сделано полшага вперед - специфицирован просмотр базы SPD как обязательный для каждого исходящего пакета, но не изменена обработка входящих пакетов. Извлечение контекста по индексу SPI эффективнее, чем просмотр набора правил, но при таком подходе, затрудняется оперативное изменение политики безопасности. Что касается эффективности просмотра правил, то ее можно повысить методами кэширования, широко используемыми при реализации IP.
Содержание6. АУТЕНТИФИКАЦИОННЫЙ ЗАГОЛОВОК (AH)
Аутентификационный заголовок (англ. authentication header) AH предназначен для обеспечения аутентификации отправителя, контроля целостности данных и опционально для предотвращения повторной посылки (англ. replay) пакета - при условии, что принимающая сторона настроена производить проверку последовательного номера пакета. Поля IP-пакета, которые изменяются в пути следования, не подлежат контролю целостности. AH защищает данные протоколов более высоких уровней и те поля IP-заголовков, которые не меняются на маршруте доставки или меняются предсказуемым образом (число "непредсказуемых" полей невелико - это prio. (Traffic Class), Flow Label и Hop Limit. Предсказуемо меняется целевой адрес при наличии дополнительного заголовка исходящей маршрутизации.).
Формат заголовка AH показан в соответствии с рисунком 6.1.
Рисунок 6.1 - Формат заголовка AH
- поле "Следующий заголовок" (Next header) идентифицирует тип следующих значимых данных за аутентификационным заголовком; значения поля берутся из предопределенного множества установленных IANA (Internet Assigned Numbers Authority) номеров;
- поле "Длина значимих данных" (Payload length) определяет длину самого АН в 32-битовых словах минус 2 слова, поскольку для заголовков, расширяемых для IPv6, установлено требование сокращения длины заголовка на 64 бита;
- зарезервированное поле должно быть нулевым;
- поле "Индекс параметров безопасности" (Security Parameters Index - SPI) - это значение, которое в совокупности с адресом назначения и самим протоколом (в данном случае АН) однозначно определяет ассоциацию безопасности (Security Association - SA) для данной датаграммы в виде 32-битного номера; номера с 1 по 255 зарезервированы IANA; SPI, равный нулю, означает, что SA не установлена; ассоциация безопасности - это набор параметров (версия алгоритмов шифрования и аутентификации, схема обмена ключами и т. п.), определяющих, каким образом будет обеспечиваться защита данных;
- поле "Последовательный номер" (Sequence number) - зто монотонно возрастающий от 0 (при установлении SA) номер пакета. Он используется для возможности контроля получателем ситуации повторной пересылки пакетов;
- поле "Данные аутентификации" (Authentication data) содержат значение контроля целостности (Integrity check value - ICV), рассчитанное по всем данным, которые не изменяются в пути следования пакета или предсказуемы на момент достижения им получателя. Значение ICV рассчитывается в зависимости от алгоритма, определенного в SA, например код аутентификации сообщения (Message Authentication Code - МАС) с ключом симметричного или асимметричного алгоритма или хэшфункции;
7. БЕЗОПАСНОЕ СОКРЫТИЕ СУЩЕСТВЕННЫХ ДАННЫХ
Протокол инкапсулирующей защиты содержимого (Encapsulating Security payload, ESP) предоставляет три вида сервисов безопасности:
- обеспечение конфиденциальности (шифрование содержимого IP-пакетов, а также частичная защита от анализа трафика путем применения туннельного режима);
- обеспечение целостности IP-пакетов и аутентификации источника данных;
- обеспечение защиты от воспроизведения IP-пакетов;
Функциональность ESP шире, чем у AH (добавляется шифрование); ESP не обязательно предоставляет все сервисы, но либо конфиденциальность, либо аутентификация должны быть задействованы. Формат заголовка ESP выглядит в соответствии с рисунком 7.1. Это не столько заголовок, сколько обертка (инкапсулирующая оболочка) для зашифрованного содержимого. Например, ссылку на следующий заголовок нельзя выносить в начало, в незашифрованную часть, так как она лишится конфиденциальности.
Рисунок 7.1 - Формат заголовка ESP
Поля "Индекс параметров безопасности (SPI)", "Порядковый номер" и "Аутентификационные данные" (последнее присутствует только при включенной аутентификации) имеют тот же смысл, что и для AH. ESP аутентифицирует лишь зашифрованную часть пакета (плюс два первых поля заголовка).
Применение протокола ESP к исходящим пакетам можно представлять себе следующим образом. Пусть остаток пакета та его часть, которая помещается после предполагаемого места вставки заголовка ESP. При этом не важно, какой режим используется - транспортный или туннельный. Шаги протокола таковы:
- остаток пакета копируется в буфер;
- к остатку приписываются дополняющие байты, их число и номер (тип) первого заголовка остатка, с тем чтобы номер был прижат к границе 32-битного слова, а размер буфера удовлетворял требованиям алгоритма шифрования;
- текущее содержимое буфера шифруется;
- в начало буфера приписываются поля "Индекс параметров безопасности (SPI)" и "Порядковый номер" с соответствующими значениями;
- пополненное содержимое буфера аутентифицируется, в его конец помещается поле "Аутентификационные данные";
- в новый пакет переписываются начальные заголовки старого пакета и конечное содержимое буфера;
Если в ESP включены и шифрование, и аутентификация, то аутентифицируется зашифрованный пакет. Для входящих пакетов действия выполняются в обратном порядке, т. е. сначала производится аутентификация. Это позволяет не тратить ресурсы на расшифровку поддельных пакетов, что в какой-то степени защищает от атак на доступность.
8. ПРОТОКОЛ ОБМЕНА КЛЮЧАМИ - IKE
8.1 Общие сведения
Поскольку основным механизмом обеспечения безопасности данных протокола являются криптографические методы, участники защищенного соединения должны наладить обмен соответствующими криптографическими ключами. Обеспечить настройку процесса такого обмена можно вручную и автоматически. Первый способ допустим для небольшого количества достаточно статичных систем, а в общем случае это производится автоматически.
Для автоматического обмена ключами по умолчанию используется Протокол управления ключами в Интернете (Internet Key Management Protocol - IKMP), иначе называемый Обмен ключами в Интернете (Internet Key Exchange - IKE). Дополнительно или альтернативно могут быть применены другие протоколы, такие как Kerberos или SKIP.
IKE совмещает в себе три основных направления (отдельных протокола):
- ISAKMP (Internet Security Association and Key Management Protocol) - протокол ассоциаций безопасности и управления ключами в интернете; это общее описание (framework) для обеспечения аутентификации и обмена ключей без указания конкретных прикладных алгоритмов;
- Oakley (Oakley key determination protocol) - протокол определения ключей Окли; он описывает последовательности обмена ключами - моды (mode) и описывает предоставляемые ими функции;
- SKEMI (Secure Key Exchange Mechanism for Internet) - механизм безопасного обмена ключами в Интернете; он описывает многофункциональные технологии, предоставляющие анонимность, неотрекаемость (аппелируемость) и быстрое обновление ключей;
IKE содержит две фазы согласования ключей. В первой фазе происходит создание защищенного канала, во второй - согласование и обмен ключами, установление SA. Первая фаза использует один из двух режимов: основной (англ. Main Mode) или агрессивный (англ. Aggressive Mode). Различие между ними в уровне защищенности и скорости работы. Основной режим, более медленный, защищает всю информацию, передаваемую между узлами. Агрессивный режим для ускорения работы оставляет ряд параметров открытыми и уязвимыми для прослушивания, его рекомендуется использовать только в случае, когда критическим вопросом является скорость работы. Во второй фазе используется быстрый режим (англ. Quick Mode), названный так потому, что не производит аутентификации узлов, считая, что это было сделано в первой фазе. Эта фаза обеспечивает обмен ключами, с помощью которых происходит шифрование данных.
Определим следующие нотации для дальнейшего использования:
HDR - это заголовок ISAKMP, который определяет тип обмена. Запись HDR* означает, что содержимое зашифровано.
SA - это содержимое переговоров SA с одним или более Proposals. Инициатор может предоставить несколько Proposals для переговоров; получатель должен выбрать только одну.
<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 - есть содержимое идентификации для <х>. Х может быть
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 тем способом, который определен для каждого алгоритма.
8.2 Введение
IKE представляет различные обмены как режимы, которые выполняются в одной из двух фаз.
В течение Фазы 1 участники устанавливают безопасный аутентифицированный канал, по которому они будут взаимодействовать. Это называется ISAKMP SA. Для фазы 1 определено два режима: Main Mode и Aggressive Mode.
Фаза 2 определяется тогда, когда уже установлены ISAKMP SA.
ISAKMP SA является двунаправленной. Это означает, что установив однажды, каждый участник может инициировать Quick Mode, Informational и New Group Mode-обмены. ISAKMP SA идентифицируется cookie Инициатора, которые следуют за cookie Получателя - роли каждого участника в Фазе 1 обмена определяют, какие cookie являются cookie Инициатора. Последовательность cookie, установленная в Фазе 1 обмена, продолжает идентификацию ISAKMP SA, независимо от направления обменов Quick Mode, Informational или New Group. Другими словами, cookie при изменении направления ISAKMP SA не должны меняться местами.
В результате использования фаз ISAKMP может выполнять обмен ключа достаточно быстро. Кроме того, может требоваться единственная фаза 2 переговоров для создания нескольких SAs. Main Mode для Фазы 1 обеспечивает защиту идентификации. Когда нет необходимости в защите идентификации, может использоваться Aggressive Mode для уменьшения числа взаимных передач. Также следует заметить, что при аутентификации шифрованием с открытым ключом в Aggressive Mode также обеспечивается защита идентификации.
Следующие атрибуты используются в IKE и о них договариваются участники ISAKMP SA. (Эти атрибуты принадлежат только ISAKMP SA, а не каким-то другим Безопасным Ассоциациям, для которых ISAKMP может вести переговоры от имени других сервисов.)
- алгоритм шифрования;
- хэш-алгоритм;
- метод аутентификации;
- информация о группе для алгоритма Диффи-Хеллмана;
Все эти атрибуты обязательны, и о них должны вестись переговоры. Кроме того,
возможны дополнительные переговоры о псевдослучайной функции (
Группа Диффи-Хеллмана задается по номеру или путем определения всех атрибутов группы. Атрибуты группы не должны зависеть от значений группы, определенной в предыдущем случае.
Существует два основных режима, используемых для установления аутентифицированного обмена ключа: 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 с различными опциями аутентификации.
8.4 IKE Фаза 1 с аутентификацией с помощью подписей
При использовании подписей вспомогательной информацией, которой обмениваются при второй круговой передаче, являются nonces; обмен аутентифицируется путем подписывания хэша. Main Mode с аутентификацией с помощью подписи выполняется в соответствии с рисунком 8.1.
Рисунок 8.1 - Main Mode с аутентификацией с помощью подписи
Aggressive Mode с аутентификацией с помощью подписи выполняется в соответствии с рисунком 8.2.
Рисунок 8.2 - Aggressive Mode с аутентификацией с помощью подписи
В обоих режимах подписанные данные, SIG_I или SIG_R, являются результатом алгоритма цифровой подписи, примененным к HASH_I или HASH_R соответственно.
В общем случае подпись выполняется поверх HASH_I и HASH_R, при этом используется prf или версия НМАС для хэш-функции (если участники не договорились о prf).
Могут быть дополнительно переданы один или более сертификатов.
8.5 Фаза 1 аутентификации шифрованием открытым ключом
При использовании шифрования открытым ключом для аутентификации обмена применяются зашифрованные nonces. Каждый участник имеет возможность восстановить хэш (доказывая, что другой участник дешифровал nonce), аутентифицируя обмен.
Для того чтобы выполнить шифрование открытым ключом, инициатор должен уже иметь открытый ключ получателя. В случае, когда получатель имеет несколько открытых ключей, инициатор использует хэш сертификата, передаваемой как часть третьего сообщения. При таком способе получатель может определить, какой закрытый ключ использовать для дешифрования зашифрованного содержимого и защищенной идентификации.
В дополнение к nonce идентификации участников (IDii и IDir) также зашифрованы открытым ключом другого участника. Если методом аутентификации является шифрование открытым ключом, то содержимые nonce и идентификации должны быть зашифрованы открытым ключом другого участника. Шифруется только тело содержимого, заголовки содержимого не шифруются.
При использовании для аутентификации шифрования Main Mode выполняется в соответствии с рисунком 8.3.
Рисунок 8.3 - Аутентификация шифрования Main Mode
Aggressive Mode выполняется в соответствии с рисунком 8.4.
Где HASH (1) есть хэш сертификата, который инициатор использовал для шифрования nonce и идентификации.
Использование шифрования для аутентификации обеспечивает невозможность отказа от обмена.
В отличие от других методов аутентификации, аутентификация шифрованием открытым ключом допускает защиту идентификации в Aggressive Mode.
Рисунок 8.4 - Аутентификация шифрования Aggressive Mode
8.6 Фаза 1 аутентификации с Revised Mode шифрования открытым ключом
Аутентификация шифрованием открытым ключом имеет важное преимущество по сравнению с аутентификацией с использованием подписей. Ценой являются 4 операции открытого ключа - две операции шифрования открытым ключом и две операции дешифрования закрытым ключом. Данный метод аутентификации сохраняет преимущества аутентификации с использованием шифрования с открытым ключом, но делает это с использованием половины операций открытого ключа.
В данном режиме nonce все еще зашифрован с использованием открытого ключа противоположной стороны, однако идентификация противоположной стороны (и сертификат, если он послан) шифруется с использованием алгоритма симметричного шифрования, о котором договорились (из содержимого SA) с ключом, полученным из nonce. Это решение добавляет минимальную сложность, и на каждой стороне используется две операции открытого ключа. Дополнительно содержимое Key Exchange также зашифровано с использованием того же самого ключа. Это обеспечивает дополнительную защиту против криптоанализа обмена Диффи-Хеллмана.
Как и в методе аутентификации шифрованием открытым ключом содержимое HASH может быть послано для идентификации сертификата, если получатель имеет несколько сертификатов. Если содержимое HASH послано, оно должно быть первым содержимым сообщения второго обмена, и за ним должен следовать зашифрованный nonce. Если содержимое HASH не послано, первым содержимым сообщения второго обмена должен быть зашифрованный nonce. Дополнительно инициатор может послать содержимое с сертификатом для указания получателю использованного открытого ключа.
При использовании для аутентификации пересмотренного режима шифрования Main Mode определяется в соответствии с рисунком 8.5.
Рисунок 8.5 - Аутентификация пересмотренного режима шифрования Main Mode
Aggressive Mode, аутентифицируемый с помощью пересмотренного метода шифрования, определяется в соответствии с рисунком 8.6.
Рисунок 8.6 - Аутентификация пересмотренного режима шифрования Aggressive Mode
Где HASH (1) была определена выше. Ke_i и Ke_r являются ключами для алгоритма симметричного шифрования, о котором участники договорились при обмене содержимом SA. Шифруется только тело содержимых (как в операциях с открытым ключом, так и симметричного шифрования), общие заголовки содержимого не шифруются.
Симметричные ключи шифрования получаются из дешифрованных nonces следующим образом. Прежде всего вычисляются значения Ne_i и Ne_r:
Ne_i = prf (Ni_b, CKY-I)
Ne_r = prf (Nr_b, CKY-R)
Если длина выхода prf, о которой договорились, больше или равна длине ключа, необходимой для шифрования, Ke_i и Ke_r получаются из старших битов Ne_i и Ne_r, соответственно. Если требуемая длина Ke_i и Ke_r превышает длину выхода prf, необходимое количество битов получается после повторным применением prf и конкатенацией результата необходимое число раз. Например, если алгоритм шифрования требует 320 битов ключа и выход prf дает только 128 бит, в качестве Ke_i берутся старшие биты K, где
K = K1 | K2 | K3
K1 = prf (Ne_i, 0)
K2 = prf (Ne_i, K1)
K3 = prf (Ne_i, K2)
Для краткости показано получение только Ke_i; Ke_r получается аналогично. Значение 0 при вычислении K1 является одним октетом. Заметим, что Ne_i, Ne_r, Ke_i и Ke_r после использования должны быть сброшены.
Существуют требования только на размещение дополнительного содержимого HASH и обязательного содержимого nonce, более никаких содержимых не требуется. Все содержимые - в любом порядке - следующие за зашифрованным nonce, должны быть зашифрованы с ключом Ke_i или Ke_r в зависимости от направления.
8.7 Фаза 1 аутентификации с Pre-Shared ключом
Ключ, полученный некоторым внешним механизмом, может также использоваться для аутентификации обмена.
Когда выполняется pre-shared аутентификация, Main Mode определяется в соответствии с рисунком 8.7.
Рисунок 8.7 - Определение Main Mode при выполнении pre-shared аутентификации
Aggressive режим с pre-shared ключом описывается в соответствии с рисунком 8.8.
При использовании аутентификации с pre-shared ключом с Main Mode ключ может только идентифицироваться по IP-адресу противоположной стороны, так как HASH_I должен быть вычислен до того, как инициатор обработает IDir. Aggressive Mode охватывает более широкий диапазон идентификаторов используемого pre-shared секрета. Дополнительно Aggressive Mode позволяет двум участникам поддерживать несколько различных pre-shared ключей и идентификаций для отдельного обмена.
Рисунок 8.8 - Определение Aggressive Mode при выполнении pre-shared аутентификации
8.8 Фаза 2 - Quick Mode
Quick Mode сам по себе законченным обменом не является (это означает, что он связан с фазой 1 обмена), он используется как часть процесса переговоров SA (фаза 2) для получения материала ключа и обсуждений разделяемой политики для не-ISAKMP SAs. Информация, которой обмениваются в Quick Mode, должна быть защищена ISAKMP SA, т.е. все содержимые за исключением заголовка ISAKMP должны быть зашифрованы. В Quick Mode содержимое HASH должно непосредственно следовать за заголовком ISAKMP и содержимое SA должно непосредственно следовать за HASH. Данный HASH аутентифицирует сообщение и обеспечивает доказательство существования.
Quick Mode проводит переговоры об SA и обменивается nonces, которые обеспечивают защиту от повторов. Nonces используются для создания нового материала ключа и предотвращения replay-атак, создающих ложные SA. Можно произвести обмен дополнительным содержимым KE, чтобы допустить дополнительный обмен экспонентами Диффи-Хеллмана при Quick Mode.
Базовый Quick Mode (без содержимого KE) обновляет материал ключа, полученный из экспоненты в Фазе 1. Это не обеспечивает PFS. При использовании дополнительного содержимого KE вычисляется дополнительная экспонента и тем самым обеспечивается PFS для материала ключа.
Все предложения, сделанные в течение Quick Mode, являются логически взаимосвязанными и должны быть согласованы. Например, если послано содержимое KE, атрибут, описывающий группу Диффи-Хеллмана, должен быть включен в каждый Transform каждой Proposal каждой SA, о которой ведутся переговоры. Аналогично, если используются идентификации клиента, они должны применяться к каждой SA, о которой ведутся переговоры.
Quick Mode определяется в соответствии с рисунком 8.9.
Рисунок 8.9 - Определение Quick Mode
Где:
HASH (1) есть prf поверх сообщения id (M-ID) из ISAKMP заголовка, присоединенного ко всему сообщению;
HASH (2) идентичен HASH (1) за исключением nonce инициатора - Ni, минус заголовок содержимого, который добавляется после M-ID, но перед завершенным сообщением. Добавление nonce в HASH (2) сделано для доказательства существования;
HASH (3) - для доказательства существования - является prf поверх нулевого значения, представленного одним октетом, за которым следует конкатенация id сообщения и два nonces - инициатора и получателя - минус заголовок содержимого. Другими словами, хэши предыдущего обмена есть:
HASH (1) = prf (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ])
HASH (2) = prf (SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ])
HASH (3) = prf (SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
За исключением содержимых HASH, SA и необязательных ID, не существует содержимых, для которых определены ограничения упорядоченности в Quick Mode. HASH (1) и HASH (2) могут отличаться от приведенных выше, если порядок содержимых в сообщении отличается от приведенного выше или если в сообщение включены дополнительные содержимые.
Если PFS не является необходимой и обмен содержимым KE не выполняется, то новый материал ключа определяется как
KEYMAT = prf (SKEYID_d, protocol | SPI | Ni_b | Nr_b)
Если PFS требуется и участники обмениваются содержимым KE, то новый материал ключа определяется как
KEYMAT = prf (SKEYID_d, g (qm) ^xy | protocol | SPI | Ni_b | Nr_b)
Где g (qm) ^xy является разделяемым секретом из одноразового обмена Диффи-Хеллмана для данного Quick Mode.
В любом случае protocol и SPI берутся из ISAKMP Proposal Payload, содержащим Transform, о котором договариваются.
Единственным результатом переговоров SA являются две безопасные ассоциации - одна входящая и одна выходящая. Различные SPIs для каждой SA (один выбирается инициатором, другой получателем) гарантируют различные ключи для каждого направления. SPI, выбираемые получателем, используются для получения KEYMAT для данной SA.
В ситуации, когда количество требуемого материала ключа больше, чем предлагается prf, KEYMAT расширяется конкатенацией результатов до тех пор, пока не будет получено необходимое количество материала ключа. Другими словами
KEYMAT = K1 | K2 | K3 | _
Где
K1 = prf (SKEYID_d, [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b)
K2 = prf (SKEYID_d, K1 | [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b)
K3 = prf (SKEYID_d, K2 | [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b)
Данный материал ключа (с PFS или без, полученный непосредственно или с помощью конкатенации) должен использоваться в SA, о которой ведутся переговоры. Это определяет ключи, которые получаются из материала ключа.
Используя Quick Mode, за один обмен можно договориться о нескольких SAs и ключах в соответствии с рисунком 8.10.
Рисунок 8.10 - Определение SAs и ключей при использовании Quick Mode
8.9 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.
8.10 Информационные обмены 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 содержимого в соответствии с рисунком 8.11.
Рисунок 8.11 - Информационные обмены ISAKMP
8.11 Проблемы безопасности Internet Key Exchange (IKE)
Сила ключа, полученная из обмена Диффи-Хеллмана, использующего определенную группу, зависит от силы самой группы, используемой длины экспоненты и энтропии, обеспечиваемой используемым генератором случайных чисел. Группа Диффи-Хеллмана по умолчанию (номер один) при использовании сильного генератора случайных чисел и экспоненты не менее 160 бит является достаточной при использовании для DES. Группы со второй по четвертую обеспечивают большую безопасность. Реализации должны помнить об этой общей оценке при определении политики и обсуждаемых параметрах безопасности.
Это не является ограничением на сами группы Диффи-Хеллмана. Ничто не препятствует IKE использовать более сильные группы и ничто не ослабляет силу этих групп. Расширяемый каркас IKE поддерживает определение многих групп; использование групп эллиптических кривых увеличивает силу при использовании меньших чисел.
В ситуациях, когда определенные группы не обеспечивают необходимую силу, можно использовать New Group Mode для обмена группой Диффи-Хеллмана, которая обеспечит ее.
Предполагается, что экспоненты Диффи-Хеллмана для данного обмена после использования удаляются из памяти. В частности, эти экспоненты не должны получаться из долго живущих секретов, подобных seed для псевдослучайного генератора.
Хотя сообщения последней круговой передачи в Main Mode (и не обязательно последнее сообщение Aggressive Mode) являются зашифрованными, они не являются аутентифицированными. Активная атака замены для зашифрованного текста может привести к разрушению содержимого. Если такая атака имела место для обязательных содержимых, это будет определено и приведет к падении аутентификации, но если это произошло для дополнительных содержимых (например, для содержимых уведомления, измененных в последнем сообщении Main Mode обмена), это может быть не определено.
9. РАСШИРЕННЫЙ ОБЗОР БЕЗОПАСНЫХ АССОЦИАЦИЙ (КОНТЕКСТОВ)
9.1 Основные определения
Понятие "безопасные ассоциации" (Security Association - SA) является фундаментальным в IPSec.
SA есть симплексное (однонаправленное) логическое соединение, создаваемое для обеспечения безопасности. Весь трафик, передаваемый по SA, некоторым образом обрабатывается в целях обеспечения безопасности. И AH, и ESP используют в своей работе SAs. Одной из основных функций IKE является установление SA. Далее приводятся различные аспекты управления SA, определим требуемые характеристики управления политикой SA, обработку трафика и технологии управления SA.
SA есть совокупность параметров соединения, которые дают возможность сервисам обеспечивать безопасный трафик. SA определяет использование AH или ESP. Если к потоку трафика применяются оба протокола, AH и ESP, то создаются две SAs. При двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется два SA (по одному на каждое направление).
SA однозначно определяется тройкой, состоящей из Security Parameter Index (SPI), IP Destination Address (адресом назначения) и идентификатора протокола безопасности (AH или ESP). В принципе адрес назначения может быть единственным адресом, широковещательным (broadcast) адресом или групповым (multicast) адресом. Однако механизм управления SA в настоящее время определяется только для единственной SA. Следовательно, SAs будут описаны в контексте point-to-point соединения, даже если концепция также применяется в случае point-to-multipoint.
Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка.
Другим режимом SA является режим туннелирования. Если хотя бы одним из концов соединения является шлюз безопасности, то SA обязательно должна выполняться в туннелирующем режиме. SA между двумя шлюзами безопасности всегда находится в туннелирующем режиме, так же, как и SA между хостом и шлюзом безопасности. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае SNMP-команд, шлюз безопасности рассматривается как хост, и допустим транспортный режим. Два хоста могут при желании так же устанавливать туннелирующий режим.
B туннелирующем режиме SA существует "внешний" IP-заголовок, который определяет пункт назначения IPSec, и "внутренний" IP-заголовок, который определяет конечный пункт назначения для пакета. Заголовок протокола безопасности расположен после внешнего IP-заголовка и перед внутренним IP-заголовком. Если AH используется в туннелирующем режиме, части внешнего IP заголовка являются защищенными, как и весь туннелируемый IP-пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, зашита обеспечивается только для туннелируемого пакета, а не для внешнего IP-заголовка.
9.2 Функциональность
Набор реализуемых SA сервисов безопасности зависит от выбранного протокола безопасности, режима SA, конечных точек SA и выбора дополнительных сервисов в протоколе. Например, AH обеспечивает аутентификацию исходных данных и целостность соединения для IP датаграм (в дальнейшем будем называть это "аутентификацией"). "Точность" сервиса аутентификации является функцией от степени детализованности SA, для которой используется AH.
AH также предоставляет анти-replay сервис (целостность отдельной последовательности) для получателя, помогая предотвратить атаки отказа в сервисе. AH применяется, когда не требуется конфиденциальность. AH также обеспечивает аутентификацию отдельных частей IP-заголовка, за исключением изменяющихся частей IP-заголовка.
ESP обеспечивает конфиденциальность трафика. Сила сервиса конфиденциальности зависит от используемого алгоритма шифрования. ESP также может дополнительно обеспечивать аутентификацию. Область аутентификации, обеспечиваемая ESP, является более узкой по сравнению с AH, т.е. IP-заголовок (заголовки), <внешние> по отношению к ESP заголовку, не защищены. Если аутентификация нужна только протоколам более высокого уровня, то аутентификация ESP является подходящей альтернативой, причем более эффективной, чем использование AH, инкапсулирующего ESP. Если для ESP SA используется аутентификация, получатель также может выбрать усиление использованием анти-replay сервиса с теми же самыми возможностями, что и AH анти-replay сервис. Хотя и конфиденциальность, и аутентификация являются необязательными, оба сервиса не могут быть опущены. По крайней мере, один из них должен присутствовать.
Использование туннелирующего режима позволяет зашифровывать внутренние IP-заголовки, скрывая отправителя и получателя. Следует заметить, что сильно детализированные SAs обычно являются более уязвимыми для анализа трафика, чем слабо детализированные.
9.3 Комбинации SA
Иногда политика безопасности может требовать комбинации сервисов для конкретного потока трафика. В таких случаях необходимо установить несколько SAs для реализации принятой политики безопасности. Термин "узел безопасных ассоциаций" или "узел SA" применяется к последовательности SA, через которые должен проходить трафик для обеспечения требуемой политики безопасности. Заметим, что SAs, которые образуют узел, могут заканчиваться в различных точках.
Безопасные aссоциации могут комбинироваться в узлы двумя способами: транспортное соседство, в соответствии с рисунком 9.1, и повторное туннелирование:
а) транспортное соседство означает применение более одного протокола для одной и той же IP-датаграммы без использования туннелирования; данный подход при комбинировании AH и ESP допускает только один уровень комбинации; дальнейшие вложенные поля не добавляют преимущества (в случае использования одинаково сильных алгоритмов для каждого протокола);
Рисунок 9.1 - Транспортное соседство SAs
б) повторное туннелирование означает применение нескольких протоколов, выполняющих туннелирование;
Существует три основных варианта повторного туннелирования:
а) оба конца SAs являются одинаковыми, в соответствии с рисунком 9.2 - внутренний и внешний туннели могут быть каждый AH или ESP, хотя маловероятно, что протоколы будут одинаковые, например, AH внутри AH или ESP внутри ESP;
Рисунок 9.2 - Повторное туннелирование SAs - оба конца одинаковы
б) один конец нескольких SAs является одним и тем же, в соответствии с рисунком 9.3 - внутренний и внешний туннели могут оба быть AH или ESP;
Рисунок 9.3 - Повторное туннелирование SAs - один конец общий
в) ни один из концов нескольких SAs не является одним и тем же, в соответствии с рисунком 9.4 - каждый внутренний и внешний туннели могут быть AH или ESP;
Рисунок 9.4 - Повторное туннелирование SAs - оба конца разные
Эти два подхода также могут комбинироваться, например, узел SA может быть сконструирован из одного SA туннелирующего режима и одного или двух SAs транспортного режима, применяемых последовательно.
9.4 Базы данных безопасной ассоциации
Многие детали, связанные с обработкой IP-трафика в реализации IPSec не являются предметом стандартизации. Некоторые внешние аспекты обработки должны быть стандартизованы для обеспечения интероперабельности IPSec.
Существуют две БД: БД Политики Безопасности (SPD) и БД Безопасной Ассоциации (SAD). Первая описывает политики, которые определяют характер обработки всего IP трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Определим также понятие Селектора как множества значений полей IP протокола и протокола более высокого уровня, которые используются БД Политики Безопасности для отображения трафика на SA.
Каждый сетевой интерфейс, для которого необходима обработка IPSec, требует определения баз данных для входящего и исходящего трафика.
9.4.1 База данных политики безопасности (SPD)
В конечном счете, SA используется для осуществления политики безопасности в окружении IPSec. Таким образом, существенным элементом выполнения SA является лежащая в основе База Данных Политики Безопасности (SPD), которая определяет, какие сервисы обрабатывают IP датаграммы и каким образом. Форма БД и ее интерфейс находятся вне области стандартизации. Тем не менее определим основные возможности управления, которые должны быть представлены, чтобы системный администратор мог управлять применением IPSec к трафику, передаваемому или получаемому хостом или проходящему через шлюз безопасности.
SPD должна рассматриваться при обработке всего трафика (входящего и исходящего), включая не - IPSec-трафик. Для того чтобы это поддерживать, SPD требует различных записей для входящего и выходящего трафика. Можно считать, что это отдельные SPDs (входящая и выходящая). Кроме того, отдельная SPD должна существовать для каждого IPSec-интерфейса.
SPD должна распознавать трафик, который разрешен защитой IPSec, и трафик, которому разрешено проходить IPSec без обработки. Для любой выходящей или входящей датаграммы существует три возможных способа обработки: отбросить датаграмму, обойти IPSec или применить IPSec. Первый вариант означает, что трафик не разрешен для хоста, не может пересекать шлюз безопасности или не может быть доставлен на уровень приложения. Второй вариант означает, что трафику разрешено проходить без дополнительной IPSec-защиты. Третий вариант означает, что к трафику применяется IPSec защита и для такого трафика SPD должна специфицировать применяемые сервисы безопасности, применяемые протоколы, используемые алгоритмы и т.д.
Каждая реализация IPSec должна иметь программный интерфейс, который позволяет системному администратору управлять SPD. SPD должна определять, какие действия должны быть выполнены в том или ином случае. Таким образом, программный интерфейс должен позволять специфицировать обработку, применяемую к любому пакету, входящему или выходящему из системы. Интерфейс управления для SPD должен допускать создание последовательности записей, и должна поддерживаться упорядоченность этих записей. Возможно использование символа <*> в различных полях.
Определим стандартный набор элементов SPD, который должны поддерживать все реализации IPSec.
SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SAs. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPSec. Если применяется обработка IPSec, запись содержит описание SA (или узла SA), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС/SHA-1.
Записи SPD должны быть упорядочены, и SPD должна всегда просматриваться в одном и том же порядке. Это требование является необходимым, чтобы воздействие на обрабатываемый трафик записей SPD было детерминированным.
Так как политика безопасности может требовать, чтобы более одной SA применялось к трафику в определенной последовательности, запись политики в SPD должна эту последовательность определять.
SA (или узел SA) может быть хорошо структурирована или грубоструктурирована в зависимости от селекторов, используемых для определения трафика, обрабатываемого SA. Например, весь трафик между двумя хостами может быть направлен через единственную SA, и может быть определен лишь один набор сервисов безопасности. В другом случае трафик между парой хостов может направляться через несколько SAs, в зависимости от используемых приложений, с различными сервисами безопасности, предоставляемыми различными SAs. Аналогично, весь трафик между парой шлюзов безопасности может быть направлен через единственную SA, или для каждой взаимодействующей пары хостов может быть определена своя SA.
9.4.2 База данных Безопасной Ассоциации (SAD)
В IPSec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPSec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для поддержки SA в реализации IPSec.
Для входящей обработки следующие поля пакета используются для поиска SA в SAD:
а) IP адрес назначения внешнего заголовка: IPv4- или IPv6-адрес назначения.
б) Протокол IPSec: AH или ESP, используемый в качестве индекса SA в данной БД. Определяет протокол IPSec, применяемый к трафику для данной SA.
в) SPI: 32-битное значение, применяемое для идентификации различных SA, заканчивающихся одним и тем же адресом назначения и использующих один и тот же IPSec-протокол.
Следующие поля SAD используются для IPSec-обработки:
а) Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в AH или ESP заголовках (используется только для исходящего трафика).
б) Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызывать событие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).
в) Anti-Replay Window: 32-битный счетчик или битовая карта (или некий эквивалент), используемые для проверки, является ли входящий AH- или ESP-пакет повтором. (Используется только для входящего трафика. Замечание: если anti-reply сервис не используется получателем, например, в случае ручных ключей SA, когда anti-reply window не используется.).
д) Алгоритм аутентификации для AH, ключи и т.д.
е) Алгоритм шифрования для ESP, ключи, режим, IV и т.д.
ж) Алгоритм аутентификации для ESP, ключи и т.д. Если сервис аутентификации не выбран, данное поле будет нулевым.
и) Время жизни данной SA: интервал времени, после которого SA должна быть заменена новой SA (и новым SPI) или завершение SA, а также определения того, какое из этих действий должно выполняться. Это может быть выражено в виде времени или количества байтов, или и того, и другого одновременно. Реализации должны поддерживать оба типа времени жизни и одновременное применение обоих типов. Если используется время и если IKE задействует сертификаты Х.509 для установления SA, то время жизни SA должно входить в допустимый интервал для сертификатов. В этом смысле как инициатор, так и получатель ответственны за установление корректного времени жизни SA.
Должно быть два типа времени жизни: soft - время жизни, по истечении которого выдается предупреждение начать действия по замене SA, и hard - время жизни, по истечении которого текущая SA завершается.
Режим IPSec-протокола: туннель или транспорт. Определяет применяемый режим AH или ESP к трафику для данной SA.
9.5 Примеры комбинаций SA
Приведем четыре примера комбинаций SA, которые должны поддерживаться IPSec-хостами и шлюзами безопасности. Дополнительные комбинации AH и/или ESP в туннелирующем и/или транспортном режимах могут поддерживаться по усмотрению разработчиков. Реализации должны иметь возможность создавать и обрабатывать эти четыре комбинации. Введем следующие обозначения в соответствии с рисунком 9.5.
=
-
одна или более SA (AH или ESP, транспорт или туннель);
-
-
соединение (или административная граница);
Нх
-
хост х;
SGx
-
шлюз безопасности х;
Х*
-
Х поддерживает IPsec.
Рисунок 9.5 - Условные обозначения
Замечание: рассматриваемые ниже безопасные ассоциации могут быть как AH, так и ESP. Режим (туннель или транспорт) определяется характером конечных точек. Для host-to-host SAs-режим может быть как транспортным, так и туннелирующим.
В данном случае как транспортный, так и туннелирующей режим могут быть хостами в соответствии с рисунками 9.6 и 9.7. Заголовки в пакете между Н1 и Н2 должны выглядеть в соответствии с таблицей 1.
Рисунок 9.6 - Вариант 1. Обеспечение end-to-end безопасности между двумя хостами
через Internet (или intranet)
Таблица 1. Последовательность заголовков при соединении Host-Host
Transport
Tunnel
1. [IP1] [AH] [upper]
1. [IP2] [AH] [IP1] [upper]
2. [IP1] [ESP] [upper]
2. [IP2] [ESP] [IP1] [upper]
3. [IP1] [AH] [ESP] [upper]
Рисунок 9.7 - Вариант 1. Обеспечение end-to-end безопасности между двумя хостами
через Internet (или Intranet)
Во втором варианте требуется только туннелирующий режим в соответствии с рисунком 9.8. При этом заголовки в пакете между SG1 и SG2 должны выглядеть в соответствии с таблицей 2.
Рисунок 9.8 - Вариант 2. Создание простых виртуальных частных сетей
Таблица 2. Последовательность заголовков при соединении SG-SG
Tunnel
1. [IP2] [AH] [IP1] [upper]
2. [IP2] [ESP] [IP1] [upper]
Рисунок 1.11 - Варианты 3 и 4
Вариант 3. Комбинация вариантов 1 и 2 путем добавления end-to-end безопасности между хостами отправителя и получателя. Для хостов или шлюзов безопасности не вводится новых требований, кроме требования, чтобы шлюз безопасности был сконфигурирован для прохождения IPSec-трафика (включая ISAKMP трафик) для хостов позади него.
Вариант 4. Рассматривается случай, когда удаленный хост (Н1) использует Internet для достижения firewall'a организации ( SG2) и затем получает доступ к некоторому серверу или другой машине (Н2). Удаленный хост может быть мобильным хостом (Н1), подсоединяющимся по dial up к локальному РРР-серверу (на диаграмме это не показано) по Internet и затем проходящему по Internet к firewall организации (SG2) и т.д.
Между Н1 и SG2 возможен только туннелирующий режим. Вариант для SA между Н1 и SG2 может быть быть один из тех, что представлены в варианте 2. Альтернатива для SA между Н1 и Н2 должна быть одной из тех, что представлены в варианте 1.
В данном варианте отправитель должен применять транспортный заголовок перед туннелирующим заголовком. Следовательно, интерфейс управления в реализациях IPSec должен поддерживать конфигурацию SPD и SAD, гарантирующую данную упорядоченность заголовка IPSec.
Поддержка дополнительных комбинаций AH и ESP не является обязательной. Дополнительные комбинации могут неблагоприятно сказываться на интероперабельности.
9.6 SA и Управление Ключом
IPSec поддерживает как ручные, так и автоматически созданные SA и соответствующее управление криптографическими ключами. Протоколы AH и ESP практически не зависят от используемых технологий управления ключом, хотя эти технологии могут некоторым образом влиять на сервисы безопасности, предоставляемые протоколами. Например, дополнительные anti-replay сервисы требуют автоматического управления SA. Более того, детализированность используемого распределения ключа определяет детализированность предоставляемой аутентификации.
Простейшей формой управления является ручное управление, при котором администратор вручную конфигурирует каждую систему материалом ключа и данными управления безопасной ассоциацией. Ручные технологии применяются в маленьких, статичных окружениях, и они не масштабируются. Например, компания может создать VPN, используя IPSec на хостах. Если количество хостов мало, и если все хосты расположены в пределах одного административного домена, то возможно применение ручных технологий управления. В данном случае хост должен выборочно защищать трафик и от других хостов в организации, используя вручную сконфигурированные ключи, допуская незащищенный трафик для других получателей. Данные технологии можно задействовать и в том случае, когда только выборочные коммуникации должны быть безопасны. Аналогичный аргумент может быть применен для использования IPSec в организации с небольшим числом хостов и/или шлюзов.
Широкое использование IPSec требует стандартного для Internet, масштабируемого, автоматического протокола управления SA. Такая поддержка необходима для использования anti-replay возможностей AH и ESP и для возможности создания SAs.
Протоколом автоматического управления ключом по умолчанию является IKE, но могут быть реализованы и другие протоколы автоматического управления ключом.
Использование IPSec навязывает высокую вычислительную стоимость на хостах и шлюзах безопасности, которые реализуют эти протоколы. Эта цена связана с памятью, необходимой для структур данных IPSec, вычисление значений проверки целостности, шифрование и дешифрование, а также дополнительное управление пакетом. Использование протоколов управления SA/ ключом, особенно тех, которые реализуют криптографию с открытым ключом, также добавляет соответствующую вычислительную стоимость в использование IPSec.
Использование IPSec также увеличивает стоимость компонентов, осуществляющих пересылку и роутинг в инфраструктуре Internet, но не реализующих IPSec. Это происходит из-за возрастания размера пакета в результате добавления заголовков AH и/или ESP, AH- и ESP-туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве примеров это возрастание не будет сильно влиять на инфраструктуру Internet.
10. INTERNET SECURITY ASSOCIATION AND KEY MANAGEMENT PROTOCOL (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 установлена не будет.
10.1 Основные концепции и терминология
Протокол безопасности: протокол безопасности состоит из записи в конкретной точке стека сетевых протоколов, выполняющей сервис безопасности для сетевого соединения. Например, IPSec ESP и IPSec AH являются двумя различными протоколами безопасности. Протокол безопасности может выполнять более одного сервиса, например, обеспечивая целостность и конфиденциальность в одном модуле.
Набор защиты: набор защиты является списком сервисов безопасности, которые могут быть применены к различным протоколам безопасности. Например, набор защиты может состоять из DES шифрования для ESP и MD5 с ключом для AH.
Безопасная ассоциация (SA): безопасная ассоциация определяет протокол безопасности
и конкретный набор параметров сервисов и механизмов, необходимых для защиты
трафика. Эти параметры могут включать идентификаторы алгоритмов, режимы, криптографические
ключи и т.д. SA ссылается на связанный с ней протокол безопасности (например,
ISAKMP SA: SA используется ISAKMP для обеспечения защиты собственного трафика.
Domain of Interpretation (DOI) определяет форматы содержимого, типы обменов и соглашения по именованию информации, относящейся к безопасности, такой как политики безопасности или криптографические алгоритмы и режимы. Идентификатор DOI используется для интерпретации содержимого ISAKMP. DOI определяет:
а)
б) Набор политик безопасности, которые могут и должны поддерживаться;
в) Синтаксис для описания предлагаемых сервисов безопасности;
д) Схема именования относящейся к безопасности информации, включая алгоритмы шифрования, алгоритмы обмена ключа, атрибуты политики безопасности и сертификационные центры;
е) Специфицированные форматы для различного содержания;
ж) Дополнительные типы обмена, если потребуется;
Situation: ситуация содержит всю относящуюся к безопасности информацию, которую система считает нужным рассматривать, принимая решение о том, какие необходимы сервисы безопасности для защиты сессии, начавшей переговоры. Ситуация может включать адреса, классификации безопасности, режимы операций (нормальный или аварийный) и т.д.
Proposal: proposal - это список, упорядоченный по уменьшению предпочтений, наборов защиты, которые система будет применять для защиты трафика в данной ситуации.
Payload: ISAKMP определяет несколько типов содержимого, которые используются при передаче информации, такой как данные SA или данные обмена ключа, в форматах, определенных DOI. Содержимое состоит из общего заголовка и строки октетов, которые ISAKMP не различает. ISAKMP использует DOI-определяемую функциональность для создания и интерпретации данного содержимого. В одном сообщении ISAKMP может быть послано несколько содержимых . Далее будут определены детали типов полезной информации.
Exchange Type: тип обмена определяет число сообщений в ISAKMP- обмене и типы содержимого в каждом из этих сообщений. Считается, что каждый тип обмена предоставляет конкретный набор сервисов безопасности, таких как анонимность участников, свойство PFS для ключевого материала, аутентификация участников и т.д., далее определяется множество типов ISAKMP-обмена по умолчанию. При необходимости могут быть добавлены другие типы для поддержки дополнительных обменов ключа.
10.2 Фазы переговоров
ISAKMP предполагает две фазы переговоров. Во время первой фазы две сущности (ISAKMP-серверы) договариваются о том, как защищать дальнейший трафик переговоров, устанавливая ISAKMP SA. Эта ISAKMP SA затем используется для защиты переговоров о требуемой SA.
Вторая фаза переговоров используется для установления SA для других протоколов безопасности. Эта вторая фаза может применяться для установления нескольких безопасных ассоциаций.
Хотя подход, основанный на двух фазах, является достаточно дорогостоящим для большинства простых сценариев, существует несколько причин, чтобы он оказывался в большинстве случаев предпочтительным.
Во-первых, ISAKMP серверы могут уменьшить время установления первой фазы до нескольких секунд. Это позволяет устанавливать несколько SAs между двумя участниками за одно и то же время с начала соединения.
Во-вторых, сервисы безопасности, которые ведут переговоры во время первой фазы, предоставляют свойства безопасности для второй фазы. Например, после первой фазы переговоров шифрование, предоставляемое ISAKMP SA, может обеспечивать защиту идентификации, потенциально допуская возможность применения более простых обменов во второй фазе. С другой стороны, если канал, устанавливаемый в течение первой фазы, адекватно не защищает идентификации, вторая фаза должна вести переговоры, учитывая это.
Для каждой фазы переговоров могут применяться различные сервисы безопасности. Например, разные участники осуществляют аутентификацию в течение каждой фазы переговоров. На первой фазе участниками, осуществляющими аутентификацию, могут быть ISAKMP серверы или хосты, в то время как на второй фазе аутентификация осуществляется на уровне пользователей или прикладных программ.
10.3 Идентификация безопасных соединений
Хотя при установлении безопасных каналов между системами ISAKMP не может предполагать существования сервисов безопасности, должна обеспечиваться некоторая степень защиты. Следовательно, SA ISAKMP отличается от остальных типов SA, и ее идентификация отличается от идентификации других типов SA. ISAKMP использует два поля cookie в заголовке ISAKMP для идентификации ISAKMP SAs. Message ID в ISAKMP Header и поле SPI в Proposal payload используются при установлении SA для идентификации SA других протоколов безопасности.
В приведенной ниже таблице 3 показано наличие или отсутствие определенных полей
при установлении SA. Следующие поля необходимы для различных операций, связанных
с установлением SA: cookies в заголовке ISAKMP, поле Message ID в заголовке
ISAKMP, поле SPI в Proposal payload.
| Таблица 3. Поля при установлении SA | ||||
| Операция |
I-Cookie | R-Cookie | Message ID | SPI |
|
1. Начало ISAKMP SA переговоров
|
X
|
0
|
0
|
0
|
| 2. Ответ ISAKMP SA переговоров |
X | X | 0 | 0 |
| 3. Инициализация других SA переговоров |
X | X | X | X |
| 4. Ответ других переговоров SA |
X | X | X | X |
| 5. Другое (КЕ, ID и т.д.) |
X | X | X/0 | NA |
| 6. Протокол безопасности (ESP, AH) |
NA | NA | NA | X |
Первая строка таблицы свидетельствует о том, что инициатор включает поле Initiator Cookie в ISAKMP Header.
Вторая строка таблицы свидетельствует о том, что отвечающий включает поля Initiator и Responder Cookie в ISAKMP Header. Взаимодействующие стороны ISAKMP могут обмениваться дополнительными сообщениями в зависимости от типа обмена ISAKMP, используемого в первой фазе переговоров. После завершения первой фазы обмена Initiator и Responder cookies включаются в ISAKMP Header всех обменов между участниками ISAKMP.
В течение первой фазы переговоров cookies инициатора и получателя определяют ISAKMP SA. Следовательно, поле SPI в Proposal payload избыточно и может быть установлено в 0 или может содержать cookie передаваемых сущностей.
Третья строчка таблицы свидетельствует о том, что инициатор связывает Message ID с Protocols, содержащимися в SA Proposal. Это Message ID и SPI(s) инициатора связываются с каждым протоколом в Proposal и посылаются получателю. SPI(s) будут использоваться в протоколах безопасности сразу после завершения второй фазы переговоров.
В четвертой строке таблицы получатель включает тот же самый Message ID, и SPI(s) получателя связываются с каждым протоколом в принимаемом Proposal. Эта информация возвращается инициатору.
Пятая строка таблицы свидетельствует о том, что инициатор и получатель используют поле Message ID в ISAKMP Header для отслеживания выполнения протокола переговоров. Это применяется на второй фазе обмена, и значение должно быть 0 для первой фазы обмена, потому что комбинированные cookies определяют ISAKMP SA. Поле SPI в Proposal payload не применяется, потому что Proposal payload используется только на протяжении обмена сообщениями переговоров SA (шаги 3 и 4).
В шестой строке таблицы фаза 2 переговоров завершается.
При установлении SA должно создаваться SPI. ISAKMP предполагает применение SPIs различных размеров. Это достигается путем использования поля SPI Size в Proposal payload при установлении SA.
При начальном установлении SA одна из сторон выступает в роли инициатора, а другая - в роли получателя. После того как SA установлена, как инициатор, так и получатель могут начать вторую фазу переговоров с противоположной сущностью. Таким образом, ISAKMP SAs по своей природе являются двунаправленными.
Далее описывается понятие: Создание Token анти-препятствия (cookie).
Детали создания cookie зависят от реализации, но в целом должны выполняться следующие основные требования:
а) Cookie должны зависеть только от данных участников; это не позволит злоумышленнику получить cookie, используя реальный IP-адрес и UDP-порт, и затем используя его для того, чтобы засыпать жертву запросами на вычисления по алгоритму Диффи-Хеллмана со случайных IP-адресов или портов;
б) Не должно быть такого, чтобы выходящая сущность создавала те же самые cookie, что и получающая сущность. Это подразумевает, что выходящая сущность должна использовать локальную секретную информацию при создании cookie. Возможности вычислить эту секретную информацию из конкретного cookie существовать не должно;
в) Функция создания cookie должна быть быстрой, чтобы предотвратить атаки, направленные на использование ресурсов ЦП;
Кэрн (Karn) предложил метод создания cookie, основанный на выполнении быстрого хэша (например, MD5) над IP-адресами источника и получателя, портов UDP-источника и получателя и локально созданного секретного случайного значения. ISAKMP требует, чтобы cookie были уникальными для каждой устанавливаемой SA для того, чтобы предотвратить replay-атаки и, следовательно, в хэшируемую информацию должны добавляться значения даты и времени. Созданные cookie помещаются в заголовок ISAKMP инициатора и получателя. Эти поля имеют длину 8 октетов, таким образом, создаваемые cookie должны быть длиной 8 октетов.
10.5 Содержимые ISAKMP
Содержимые ISAKMP обеспечивают возможность конструировать ISAKMP-сообщения из модульно построенных блоков. Наличие и последовательность содержимых в ISAKMP определяется полем Exchange Type, размещаемым в заголовке ISAKMP. Типы содержимых ISAKMP приводятся далее. Описания сообщений и обменов показаны, используя сетевой порядок представления октетов.
10.5.1 Формат заголовка ISAKMP
Сообщение ISAKMP имеет фиксированный формат заголовка, показанный в соответствии с рисунком 10.1, за которым следует переменное число определенных содержимых. Фиксированный заголовок проще разбирать, что делает ПО более легким для реализации. Фиксированный заголовок содержит информацию, необходимую протоколу для поддержки состояния, обработки содержимого и, возможно, предотвращения DoS-атак и replay-атак.
Поля заголовка ISAKMP определяются следующим образом:
Рисунок 10.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-сообщения;
Таблица 4 - Типы содержимого
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
10.5.2 Общий заголовок содержимого
Каждое содержимое ISAKMP, определяемое далее, начинается с общего заголовка, показанного в соответствии с рисунком 10.2, который обеспечивает возможность <связывания> содержимых и позволяет явно определять границы содержимого.
Поля общего заголовка содержимого определяются следующим образом:
Рисунок 10.2 - Общий заголовок содержимого
а) Next Payload (1 октет) - идентификатор типа содержимого следующего содержимого в сообщении; если текущее содержимое является последним, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина текущего содержимого, включая общий заголовок;
10.5.3 Атрибуты данных
Существует несколько случаев в ISAKMP, когда должны быть представлены атрибуты данных. Примером могут служить атрибуты SA, содержащиеся в Transform payload. Эти атрибуты данных не являются самостоятельным содержимым ISAKMP, а представляют собой часть некоторого содержимого. Формат атрибутов данных обеспечивает гибкость представления различных типов информации. В содержимом может существовать много атрибутов данных. Длина атрибутов данных или равна 4 октетам, или определяется полем Attribute Length. Это определяется битом формата атрибута, описанным ниже.
Поля атрибутов данных определяются следующим образом в соответствии с рисунком 10.3:
Рисунок 10.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 октета;
10.5.4 Содержимое SA
Содержимое SA используется при переговорах об атрибутах безопасности и для определения Situation, при котором переговоры имеют место. Формат полезной информации SA в соответствии с рисунком 10.4:
Рисунок 10.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 используется для того, чтобы определить политику и соответствующие атрибуты безопасности, при которых ведутся переговоры;
10.5.5 Содержимое Proposal
Proposal Payload содержит информацию, используемую в течение переговоров SA. Proposal состоит из механизмов безопасности, или преобразований, используемых для обеспечения безопасности информационного канала. Формат Proposal Payload в соответствии с рисунком 10.5.
Рисунок 10.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.
10.5.6 Содержимое Transform
Transform Payload содержит информацию, используемую SA при переговорах. Transform Payload состоит из конкретных механизмов безопасности, или преобразований, которые используются для обеспечения безопасности информационного канала. Transform Payload также содержит атрибуты SA, связанные с конкретным преобразованием. Эти атрибуты SA определяются DOI. Формат Transform Payload в соответствии с рисунком 10.6.
Рисунок 10.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.
10.5.7 Содержимое Key Exchange
Key Exchange Payload поддерживает различные технологии обмена ключами. Примерами обмена ключами являются Oakley, Diffie-Hellman, расширенный обмен ключами Diffie-Hellman, описанный в Х9.42, и обмен ключами на основе RSA, используемый в PGP. Формат Key Exchange рayload в соответствии с рисунком 10.7.
Рисунок 10.7 - Формат Key Exchange Payload
Поля Key Exchange Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущее содержимое является последним в сообщении, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Key Exchange Data (переменной длины) - данные, необходимые для создания ключа сессии;
Тип полезной информации для Key Exchange Payload есть 4.v
10.5.8 Содержимое Identification
Identification Payload содержит данные, используемые при обмене идентификационной информацией.
Рисунок 10.8 - Формат Identification Payload
Поля Identification Payload определяются следующим образом в соответствии с рисунком 10.8:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущая полезная информация является последней, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) ID Type (1 октет) - спецификация типа используемой идентификации;
д) DOI Specific ID Data (3 октета) - содержит данные идентификации; если не используется, то данное поле должно устанавливаться в 0;
е) Identification Data (переменной длины) - содержит идентификационную информацию; формат определяется полем ID Type;
Тип полезной информации для Identification Payload есть 5.
10.5.9 Содержимое Certificate
Certificate Payload обеспечивает способ передачи сертификатов или другой информации, относящейся к сертификатам, с помощью ISAKMP и может появляться в любом сообщении ISAKMP. Формат Certificate Payload в соответствии с рисунком 10.9.
Рисунок 10.9 - Формат Certificate Payload
Поля Certificate Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущая полезная информация является последней, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Certificate Encoding (1 октет) - данное поле определяет тип сертификата или информации, относящейся к сертификату, содержащейся в поле Certificate Data;
д) Certificate Data (переменной длины) - конкретное представление данных сертификата; тип сертификата определяется полем Certificate Encoding;
Тип содержимого для Certificate Payload есть 6.
10.5.10 Содержимое Certificate Request
Certificate Request Payload обеспечивает значение для запроса сертификатов с помощью ISAKMP и может появиться в любом сообщении. Certificate Request рayload должен приниматься в любой точке обмена. Получатель Certificate Request рayload должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request рayloads. Формат Certificate Request Payload в соответствии с рисунком 10.10.
Рисунок 10.10 - Формат Сertificate Request Payload
Поля Certificate Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущее содержимое является последним, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Certificate Type (1 октет) - содержит тип запрашиваемого сертификата;
д) Certificate Authority (переменной длины) - содержит обозначение принимаемых сертификационных центров для запрашиваемых сертификатов; например, для сертификата Х.509 оно должно содержать значение DN CA, принимаемого отправителем; это должно помочь получателю определить, какую цепочку сертификатов необходимо послать в ответ на данный запрос; если требуемый сертификационный центр не указан, данное поле включаться не должно;
Тип содержимого для Certificate Request Payload есть 7.
10.5.11 Содержимое HASH
Hash Payload содержит данные, создаваемые хэш-функцией (определенной во время обмена при установлении SA), для некоторой части сообщения и/или состояния ISAKMP. Данное содержимое может использоваться для проверки целостности данных в ISAKMP-сообщении или для аутентификации сущностей, ведущих переговоры. Формат Hash Payload в соответствии с рисунком 10.11.
Рисунок 10.11 - Формат HASH Payload
Поля Hash Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущее содержимое является последним, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Hash Data (переменной длины) - данные, которые являются результатом применения хэш-функции к ISAKMP-сообщению и/или состоянию;
10.5.12 Содержимое Signature
Signature Payload содержит данные, созданные функцией цифровой подписи (выбранной при обмене во время установления SA) для определенной части сообщения и/или ISAKMP-состояния. Данное содержимое используется для проверки целостности данных в ISAKMP-сообщении, и может быть использовано для сервисов невозможности отказа. Формат Signature Payload в соответствии с рисунком 10.12.
Рисунок 10.12 - Формат Signature Payload
Поля Signature Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущее содержимое является последним, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Signature Data (переменной длины) - данные, которые являются результатом применения функции цифровой подписи для ISAKMP сообщения;
Тип содержимого для Signature Payload есть 9.
10.5.13 Содержимое Nonce
Nonce Payload содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. Формат Nonce Payload в соответствии с рисунком 10.13. Если nonces используются в конкретном обмене ключа, то применение Nonce рayload определяется обменом ключа. Nonces могут передаваться как часть данных обмена ключа или как отдельное содержимое. Это, однако, определяется обменом ключа, а не ISAKMP.
Рисунок 10.13 - Формат Nonce Payload
Поля Nonce Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущее содержимое является последним, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Nonce Data (переменной длины) - содержит случайные данные, созданные передающей сущностью;
Тип содержимого для Nonce Payload есть 10.
10.5.14 Содержимое Notification
Notification Payload может содержать как определяемые ISAKMP, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification Payload в одном сообщении ISAKMP. Формат Notification Payload в соответствии с рисунком 10.14.
Рисунок 10.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.
10.5.15 Содержимое Delete
Delete Payload содержит идентификатор SA которую отправитель удаляет из своей БД SA и которая, следовательно, более не доступна. Формат Delete Payload в соответствии с рисунком 10.15. Возможна посылка нескольких SPIs в Delete Payload, однако каждый SPI должен быть предназначен для того же самого протокола.
Рисунок 10.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.
10.5.16 Содержимое Vendor ID
Vendor ID Payload содержит константу, определяющую разработчика. Данная константа используется разработчиком для собственной идентификации и удаленной сущностью для распознавания разработчика. Данный механизм позволяет разработчику экспериментировать с новыми возможностями, сохраняя обратную совместимость.Формат Vendor ID Payload в соответствии с рисунком 10.16.
Рисунок 10.16 - Формат Vendor ID Payload
Поля Vendor ID Payload определяются следующим образом:
а) Next Payload (1 октет) - идентификатор типа следующего содержимого в сообщении; если текущее содержимое является последним, то данное поле должно быть 0;
б) Payload Length (2 октета) - длина в октетах текущего содержимого, включая общий заголовок;
в) Vendor ID (переменной длины) - хэш строки разработчика плюс версия;
Тип содержимого Vendor ID есть 13.
"Методы и средства защиты информации". ПетрГУ, 2006.