Контексты безопасности и управление ключамиФормирование контекстов безопасности в IPsec разделено на две фазы. Сначала создается управляющий контекст, назначение которого — предоставить надежный путь (в терминологии "Оранжевой книги", см. [25]), то есть аутентифицированный, защищенный канал для выработки (в рамках второй фазы) протокольных контекстов, и, в частности, для формирования криптографических ключей, используемых протоколами AH и ESP. В принципе, для функционирования механизмов IPsec необходимы только протокольные контексты; управляющий контекст играет вспомогательную роль. Более того, явное выделение двух фаз утяжеляет и усложняет формирование ключей, если рассматривать последнее как однократное действие. Тем не менее, из архитектурных соображений управляющие контексты не только могут, но и должны существовать, поскольку они обслуживают все протокольные уровни стека TCP/IP, концентрируя в одном месте необходимую функциональность. Первая фаза начинается в ситуации, когда взаимодействующие стороны, вообще говоря, не имеют общих секретов (общих ключей) и не уверены в аутентичности друг друга. Если с самого начала не создать надежный путь, то для выполнения каждого управляющего действия с ключами (их модификация, выдача диагностических сообщений и т.п.) в каждом протоколе (AH, ESP, SSL и т.д.) этот путь придется формировать заново. Управляющий контекст и управление ключамиОбщие вопросы формирования контекстов безопасности и управления ключами освещаются в спецификации [28] — "Контексты безопасности и управление ключами в Интернет" (Internet Security Association and Key Management Protocol, ISAKMP). Здесь вводятся две фазы выработки протокольных ключей, определяются виды управляющих информационных обменов и используемые форматы заголовков и данных. Иными словами, в [28] строится протокольно-независимый каркас. Существует несколько способов формирования управляющего контекста. Они различаются по двум показателям:
В простейшем случае секретные ключи задаются заранее (по сути это ручной метод распределения ключей). Для небольших сетей такой подход вполне работоспособен, но он не является масштабируемым. Последнее свойство может быть обеспечено при использовании протоколов, основанных на алгоритме Диффи-Хелмана. Таковым является Протокол для обмена ключами в Интернет (The Internet Key Exchange, IKE, [29]). При формировании управляющего контекста идентификаторы общающихся сторон (такие, например, как IP-адреса) могут передаваться в открытом виде или шифроваться. Поскольку ISAKMP предусматривает функционирование в режиме клиент/сервер (то есть ISAKMP-сервер может формировать контекст для клиента), сокрытие идентификаторов в определенной степени повышает защищенность от пассивного прослушивания сети. Последовательность передаваемых сообщений, позволяющих сформировать управляющий контекст и обеспечивающих защиту идентификаторов, выглядит следующим образом (см. Рис. 22). В первом сообщении (1) инициатор направляет предложения по набору защитных алгоритмов и конкретных механизмов их реализации. Предложения упорядочиваются по степени предпочтительности (для инициатора). В ответном сообщении (2) партнер информирует о сделанном выборе — какие алгоритмы и механизмы его устраивают. Для каждого класса защитных средств (генерация ключей, аутентификация, шифрование) выбирается ровно один элемент. В сообщениях (3) и (4) инициатор и партнер отправляют свои части ключевого материала, необходимые для выработки общего секретного ключа. В случае алгоритма Диффи-Хелмана эти части имеют вид gXi и gXr, где g - генератор согласованной группы Диффи-Хелмана, а Xi и Xr - значения, выбранные, соответственно, инициатором и партнером. (Общий секрет при этом имеет вид g^xixr.) Одноразовые номера (nonce) представляют собой псевдослучайные величины, служащие для защиты от воспроизведения сообщений. Посредством сообщений (5) и (6) происходит обмен идентификационной информацией, подписанной (с целью аутентификации) секретным ключом отправителя и зашифрованной выработанным на предыдущих шагах общим секретным ключом. Вообще говоря, для аутентификации предполагается использование аппарата сертификатов, но способы его воплощения пока остаются открытыми прежде всего из-за отсутствия устраивающей всех реализации службы каталогов. Отметим, что в число подписываемых данных входят одноразовые номера. В представленном виде протокол формирования управляющего контекста защищает от атак, производимых нелегальным посредником, а также от нелегального перехвата соединений. Для защиты от атак на доступность, связанных прежде всего с навязыванием интенсивных вычислений, присущих криптографии с открытым ключом, используются так называемые идентифицирующие цепочки (cookies). Эти цепочки, формируемые инициатором и его партнером с использованием текущего времени (для защиты от воспроизведения), на самом деле присутствуют во всех ISAKMP-сообщениях и в совокупности идентифицируют управляющий контекст (в первом сообщении, по понятным причинам, фигурирует только цепочка инициатора). Согласно спецификациям [28], заголовок ISAKMP-сообщения имеет вид, изображенный на Рис. 23. Если злоумышленник пытается "завалить" кого-либо запросами на создание управляющего контекста, подделывая при этом свой IP-адрес, то в сообщении (3) (см. Рис. 22) он не сможет предъявить идентифицирующую цепочку партнера, так что до выполнения алгоритма Диффи-Хелмана и, тем более, до выработки электронной подписи и полномасштабной проверки аутентичности дело попросту не дойдет. Управляющие контексты являются двунаправленными в том смысле, что любая из общающихся сторон может инициировать с их помощью выработку новых протокольных контекстов или иные действия. Для передачи ISAKMP-сообщений в принципе может использоваться любой протокол, однако стандартным является UDP с номером порта 500. Протокольные контексты и политика безопасностиСистемы, реализующие IPsec, должны поддерживать две базы данных:
Все IP-пакеты (входящие и исходящие) сопоставляются с упорядоченным набором правил политики безопасности. При сопоставлении используется фигурирующий в каждом правиле селектор — совокупность анализируемых полей сетевого и более высоких протокольных уровней. Первое подходящее правило определяет дальнейшую судьбу пакета:
Таким образом, системы, реализующие IPsec, функционируют в духе межсетевых экранов, фильтруя и преобразуя потоки данных на основе предварительно заданной политики безопасности. Далее мы детально рассмотрим контексты и политику безопасности, а также порядок обработки сетевых пакетов. Протокольный контекст безопасности в IPsec — это однонаправленное "соединение" (от источника к получателю), предоставляющее обслуживаемым потокам данных набор защитных сервисов в рамках какого-то одного протокола (AH или ESP). В случае симметричного взаимодействия партнерам придется организовать как минимум два контекста (по одному в каждом направлении). Если используются и AH, и ESP, потребуется четыре контекста (см. Рис. 24). Элементы базы данных протокольных контекстов содержат следующие поля (в каждом конкретном случае часть значений полей будут пустыми):
Пользователями протокольных контекстов, как правило, являются прикладные процессы. Вообще говоря, между двумя узлами сети может существовать произвольное число протокольных контекстов, так как произвольным является число приложений в узлах. Отметим, что в качестве пользователей управляющих контекстов обычно выступают узлы сети (поскольку в этих контекстах желательно сосредоточить общую функциональность, необходимую сервисам безопасности всех уровней модели ISO/OSI для управления криптографическими ключами). Управляющие контексты являются двусторонними, то есть любой из партнеров может инициировать новый ключевой обмен. В принципе, пара узлов может одновременно поддерживать несколько активных управляющих контекстов, если имеются приложения с существенно разными криптографическими требованиями. Например, допустима выработка части ключей на основе предварительно распределенного материала, в то время как другая часть порождается по алгоритму Диффи-Хелмана. На Рис. 25 изображена типичная комбинация управляющего и протокольных контекстов. Протокольный контекст для IPsec идентифицируется целевым IP-адресом, протоколом (AH или ESP), а также дополнительной величиной — индексом параметров безопасности (Security Parameter Index, SPI). Последняя величина необходима, так как может существовать несколько контекстов с одинаковыми IP-адресами и протоколами (см. Рис. 25). Далее мы увидим, как используются индексы SPI при обработке входящих пакетов. IPsec обязывает поддерживать ручное и автоматическое управление контекстами безопасности и криптографическими ключами. В первом случае все системы заранее снабжаются ключевым материалом и иными данными, необходимыми для защищенного взаимодействия с другими системами. Во втором случае материал и данные вырабатываются динамически, на основе определенного протокола, такого как IKE [29], поддержка которого является обязательной. Протокольный контекст создается на основе управляющего, с использованием ключевого материала и средств аутентификации и шифрования последнего. В простейшем случае, когда протокольные ключи генерируются на основе существующих, последовательность передаваемых сообщений выгладит так, как показано на Рис. 26. Когда вырабатывался управляющий контекст, для него было создано три вида ключей:
Все перечисленные виды ключей задействованы в обмене, показанном на Рис. 26.Ключом SKEYID_e шифруются сообщения. Ключ SKEYID_a служит аргументом хэш-функций и тем самым аутентифицирует сообщения. Наконец, протокольные ключи являются результатом применения псевдослучайной (хэш) функции к SKEYID_d с дополнительными параметрами, в число которых входят одноразовые номера инициатора и партнера. В результате создание протокольного контекста оказывается аутентифицированным, защищенным от несанкционированного ознакомления, от воспроизведения сообщений и от перехвата соединения. Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки "совсем новых" ключей по алгоритму Диффи-Хелмана или идентификаторы клиентов, от имени которых ISAKMP-серверы формируют протокольный контекст. В соответствии с протоколом IKE, за один обмен (состоящий из трех показанных на Рис. 26 сообщений) формируется два однонаправленных контекста — по одному в каждом направлении. Получатель контекста задает для него индекс параметров безопасности (SPI), с помощью которого он (получатель) будет находить контекст для обработки принимаемых пакетов IPsec. Строго говоря, протокольные контексты играют вспомогательную роль, являясь лишь средством проведения в жизнь политики безопасности. Политика безопасности должна быть задана для каждого сетевого интерфейса с задействованными средствами IPsec и для каждого направления потоков данных (входящие/исходящие). Согласно спецификациям IPsec [26], политика должна быть рассчитана на бесконтекстную (независимую) обработку IP-пакетов, в духе современных фильтрующих маршрутизаторов. Разумеется, должны существовать средства администрирования базы данных SPD, аналогично средствам администрирования базы правил межсетевого экрана, однако этот аспект не входит в число стандартизуемых. С внешней точки зрения база данных политики безопасности (SPD) представляет собой упорядоченный набор правил. Каждое правило задается как пара:
Селекторы служат для отбора пакетов, контексты задают требуемую обработку. Если правило ссылается на несуществующий контекст, оно должно содержать достаточную информацию для его (контекста) динамического создания. Очевидно, в этом случае должно поддерживаться автоматическое управление контекстами и ключами. В принципе, функционирование системы может начинаться с задания базы SPD при пустой базе контекстов (SAD); последняя будет наполняться по мере необходимости. Дифференцированность политики безопасности определяется селекторами, употребленными в правилах. Например, пара взаимодействующих хостов может использовать единственный набор контекстов, если в селекторах фигурируют только IP-адреса; с другой стороны, этот набор может быть своим для каждого приложения, если анализируются номера TCP- и UDP-портов. Аналогично, два защитных шлюза могут организовать единый туннель для всех обслуживаемых хостов или же расщепить его (путем организации разных контекстов) по парам хостов или даже приложений. Все реализации IPsec должны поддерживать селекцию следующих элементов:
Обработка исходящего и входящего трафика, согласно [26], не является симметричной. Для исходящих пакетов просматривается база SPD, находится подходящее правило, извлекаются ассоциированные с ним протокольные контексты и применяются соответствующие механизмы безопасности. Во входящих пакетах для каждого защитного протокола уже проставлено значение SPI, однозначно определяющее контекст. Таким образом, просмотр базы SPD в этом случае не требуется; можно считать, что политика безопасности учитывалась при формировании соответствующего контекста. (Практически это означает, что ISAKMP-пакеты нуждаются в особой трактовке, а правила с соответствующими селекторами должны быть включены в SPD.) Отмеченная асимметрия, на наш взгляд, отражает определенную незавершенность архитектуры IPsec. В более раннем, по сравнению с проектом [26], документе RFC 1825 (см. [30]), понятия базы данных политики безопасности и селекторов отсутствовали. Новый проект сделал в этом смысле полшага вперед, специфицировав просмотр базы SPD как обязательный для каждого исходящего пакета, но по сути не изменив обработку пакетов входящих. Конечно, извлечение контекста по индексу SPI эффективнее, чем просмотр набора правил, но при таком подходе по меньшей мере затрудняется оперативное изменение политики безопасности. Что же касается эффективности просмотра правил, то ее можно повысить методами кэширования, широко используемыми при реализации IP. Возможно, еще более серьезным недостатком является невозможность обобщения предложенных процедур формирования контекстов (управляющих и протокольных) на многоадресный случай. В текущих спецификациях IPsec смешиваются две разные вещи — область действия контекста (сейчас это может быть односторонний или двусторонний поток данных) и способ его идентификации (по индексу SPI или паре идентифицирующих цепочек). Получается, что способ идентификации (именования) навязывает трактовку области действия, что представляется неверным. На наш взгляд, вопросы именования могут решаться локально, при этом область действия контекста потенциально должна распространяться на произвольное число партнеров.
|
