Спецификации Internet-сообщества IPsec

Протокольные контексты и политика безопасности

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

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

Рис. 9.4. Формирование протокольного контекста.

Когда вырабатывался управляющий контекст, для него было создано три вида ключей:

• SKEYID_d - ключевой материал, используемый для генерации протокольных ключей;
• SKEYID_a - ключевой материал для аутентификации;
• SKEYID_e - ключевой материал для шифрования.

Все перечисленные виды ключей задействованы в обмене, показанном на рис. 9.4. Ключом SKEYID_e шифруются сообщения. Ключ SKEYID_a служит аргументом хэш-функций и тем самым аутентифицирует сообщения. Наконец, протокольные ключи - результат применения псевдослучайной (хэш) функции к SKEYID_d с дополнительными параметрами, в число которых входят одноразовые номера инициатора и партнера. В результате создание протокольного контекста оказывается аутентифицированным, защищенным от несанкционированного ознакомления, от воспроизведения сообщений и от перехвата соединения.

Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки "совсем новых" секретных ключей или идентификаторы клиентов, от имени которых ISAKMp-серверы формируют протокольный контекст. В соответствии с протоколом IKE, за один обмен (состоящий из трех показанных на рис. 9.4 сообщений) формируется два однонаправленных контекста - по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SpI), помогающий находить контекст для обработки принимаемых пакетов IPsec.

Строго говоря, протокольные контексты играют вспомогательную роль, будучи лишь средством проведения в жизнь политики безопасности; она должна быть задана для каждого сетевого интерфейса с задействованными средствами IPsec и для каждого направления потоков данных (входящие/исходящие). Согласно спецификациям IPsec [ 63 ] , политика рассчитывается на бесконтекстную (независимую) обработку IP-пакетов, в духе современных фильтрующих маршрутизаторов. Разумеется, должны существовать средства администрирования базы данных SpD, так же, как и средства администрирования базы правил межсетевого экрана, однако этот аспект не входит в число стандартизуемых.

С внешней точки зрения, база данных политики безопасности (SpD) представляет собой упорядоченный набор правил. Каждое правило задается как пара:

• совокупность селекторов ;
• совокупность протокольных контекстов безопасности.

Селекторы служат для отбора пакетов, контексты задают требуемую обработку. Если правило ссылается на несуществующий контекст, оно должно содержать достаточную информацию для его (контекста) динамического создания. Очевидно, в этом случае требуется поддержка автоматического управления контекстами и ключами. В принципе, функционирование системы может начинаться с задания базы SpD при пустой базе контекстов (SAD); последняя будет наполняться по мере необходимости.

Дифференцированность политики безопасности определяется селекторами, употребленными в правилах. Например, пара взаимодействующих хостов может использовать единственный набор контекстов, если в селекторах фигурируют только IP-адреса; с другой стороны, набор может быть своим для каждого приложения, если анализируются номера TCp- и UDp-портов. Аналогично, два защитных шлюза способны организовать единый туннель для всех обслуживаемых хостов или же расщепить его (путем организации разных контекстов) по парам хостов или даже приложений.

Все реализации IPsec должны поддерживать селекцию следующих элементов:

• исходный и целевой IP-адреса (адреса могут быть индивидуальными и групповыми, в правилах допускаются диапазоны адресов и метасимволы "любой");
• имя пользователя или узла в формате DNS или X.500;
• транспортный протокол;
• номера исходного и целевого портов (здесь также могут использоваться диапазоны и метасимволы).

Обработка исходящего и входящего трафика, согласно [ 63 ] , не является симметричной. Для исходящих пакетов просматривается база SpD, находится подходящее правило, извлекаются ассоциированные с ним протокольные контексты и применяются соответствующие механизмы безопасности. Во входящих пакетах для каждого защитного протокола уже проставлено значение SpI, однозначно определяющее контекст. Просмотр базы SpD в таком случае не требуется; можно считать, что политика безопасности учитывалась при формировании соответствующего контекста. (Практически это означает, что ISAKMp-пакеты нуждаются в особой трактовке, а правила с соответствующими селекторами должны быть включены в SpD.)

Отмеченная асимметрия, на наш взгляд, отражает определенную незавершенность архитектуры IPsec. В более раннем, по сравнению с [ 63 ] , документе RFC 1825 понятия базы данных политики безопасности и селекторов отсутствовали. В новой редакции сделано полшага вперед - специфицирован просмотр базы SpD как обязательный для каждого исходящего пакета, но не изменена обработка входящих пакетов. Конечно, извлечение контекста по индексу SpI эффективнее, чем просмотр набора правил, но при таком подходе, по меньшей мере, затрудняется оперативное изменение политики безопасности. Что касается эффективности просмотра правил, то ее можно повысить методами кэширования, широко используемыми при реализации IP.

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