Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
24.4.6 Сценарий 3
Сценарий 3 показан на рис. 24.4. Цель состоит в том, чтобы сделать невидимым для внешнего мира весь трафик, который компания XYZ посылает через недоверенную сеть. Для этого используется инкапсуляция в режиме туннеля, т.е. датаграммы шифруются и инкапсулируются внутри других датаграмм.
Рис. 24.4. Трафик в туннеле между двумя сетями
Когда датаграмма с точкой назначения в сети 193.40.3 достигает граничного маршрутизатора для сети 130.15, он зашифровывает всю эту датаграмму, включая заголовки. Он подставляет временный (открытым текстом) IP-заголовок и пересылает датаграмму через сеть провайдера на граничный маршрутизатор сети 193.40.3. Можно подставить и другие заголовки (например, отдельный заголовок аутентификации для взаимодействия маршрутизатор-маршрутизатор). В маршрутизаторе-приемнике временный заголовок удаляется, датаграмма дешифрируется и отправляется в истинную точку назначения. В данном случае ассоциации безопасности устанавливаются между двумя граничными маршрутизаторами.
24.4.7 Обобщение
Мы рассмотрели некоторые конкретные примеры, чтобы познакомится с основной структурой безопасности. В целом можно использовать обычный набор механизмов для защиты пересылаемого трафика:
■ Между хостами
■ Между маршрутизаторами
■ Между хостом и маршрутизатором
■ Между маршрутизатором и хостом
Если хост назначения имеет более одного IP-адреса, следует установить отдельные параметры ассоциации безопасности для каждого адреса. Не существует никаких ограничений на реализацию аутентификации, целостности данных и конфиденциальности.
В сценарии 2 безопасность определена для уровней пользователя и роли. При необходимости можно еще глубже структурировать безопасность. Более того, параметры безопасности могут конфигурироваться на основе важности информации (например, "не секретно" или "совершенно секретно"). Обслуживание множества различных параметров следует переложить на хорошее приложение.
24.5 Элементы протокола безопасности
Рассмотрим реализацию безопасности более детально.
24.5.1 Ассоциации безопасности
Безопасность одновременно управляет только одним направлением обмена. Для обеспечения безопасности коммуникации источника и получателя каждый из них должен хранить набор параметров, например:
■ Адрес источника
■ Используемый алгоритм аутентификации и целостности данных
■ Используемый алгоритм конфиденциальности
■ Секретные ключи и другую необходимую для алгоритмов информацию
■ Ограничения по времени на ключи
■ Ограничение по времени на ассоциации безопасности
■ Гриф секретности (например, "не секретно" или "совершенно секретно")
Ассоциация безопасности формально определяется как набор защищенных параметров, которые поддерживают безопасность однонаправленного взаимодействия между источником и приемником. Из приведенных выше сценариев видно, что:
■ Хост источника может применять один набор параметров для пересылки данных в точки назначения.
■ Хост может использовать несколько ассоциаций безопасности для различных хостов точек назначения. Ассоциации выбираются на основе идентификатора пользователя, роли или важности информации.
Каждому набору параметров безопасности в каждой из точек назначения присваивается цифровой идентификатор, называемый индексом параметров безопасности (Securuty Parameter Index — SPI). Некоторым наборам стандартных параметров значение SPI присваивает IANA.
Одинаковые SPI могут использоваться для различных точек назначения. Наборы параметров (Назначение=A, SPI=300) и (Назначение=В, SPI=300), скорее всего, будут различными. Другими словами, набор параметров идентифицируется как SPI, так и точкой назначения.
Для реализации безопасности в IP версий 4 и 6 применяются заголовки Authentication Header и Encapsulating Security Payload Header.
24.5.2 Authentication Header
Если для аутентификации используется резюме сообщения, заголовок Authentication Header (заголовок аутентификации) выполняет две задачи:
■ Проверяет отправителя, поскольку настоящий отправитель должен знать секретный ключ для вычисления резюме сообщения.
■ Проверяет, не были ли данные изменены при пересылке.
Формат Authentication Header показан на рис. 24.5. Получатель использует SPI для выбора требуемого протокола и ключа аутентификации. Ключ служит для вычисления приемником резюме по алгоритму MD5.
Рис. 24.5. Формат заголовка Authentication Header
Вычисление аутентификации по MD5 выполняется над всеми полями датаграммы IP, которые не изменяются при пересылке (изменяемые поля, например счетчик попаданий или указатель пути в версии 6, при вычислении трактуются как нулевые). Результат у получателя сравнивается со значением из поля данных аутентификации. При расхождении датаграмма отбрасывается.
24.5.3 Режимы транспорта и туннеля
Рассмотрим способы реализации конфиденциальности. Формат датаграммы IP версии 6 с шифрованной полезной нагрузкой более высокого уровня показан на рис. 24.6. Такой формат определяет режим транспорта (Transport-mode).
Рис. 24.6. Шифрование для режима транспорта
На рис. 24.7 показан формат для режима туннеля (Tunnel-mode). Шифруется вся датаграмма, включая все ее заголовки. Для пересылки подставляется новый заголовок. Режим туннеля между хостами может не сработать, если по пути следования попадутся фильтрующие маршрутизаторы со средствами защиты. Такие системы будут проверять информацию, подобную IP-адресам источника и назначения либо порты, а эти сведения будут скрыты внутри зашифрованного сообщения.
Рис. 24.7. Шифрование для режима туннеля
24.5.4 Инкапсуляция защищенной полезной нагрузки
Заголовок инкапсуляции защищенной полезной нагрузки протокола IP (IP Encapsulating Security Payload) применяется как для режима транспорта, так и для режима туннеля.
Формат этого заголовка показан на рис. 24.8. Получатель использует индекс SPI для выбора алгоритма и ключа (ключей). Оставшиеся данные зависят от выбранного алгоритма.
Рис. 24.8. Заголовок Encapsulating Security Payload
При использовании CBC-DES формат заголовка Encapsulating Security Payload и оставшаяся часть сообщения будут выглядеть как на рис. 24.9.
Рис. 24.9. Заголовок и полезная нагрузка при использовании алгоритма CBC-DES
Вектор инициализации (Initialization Vector) — это блок данных, необходимых для начала работы алгоритма CBC-DES. Затененная область на рисунке представляет зашифрованные данные. Тип 4 означает инкапсулирование в полезной нагрузке всей датаграммы (режим туннеля).
Хотя первоначально планируется использование CBC-DES, в будущем могут появиться другие протоколы для инкапсуляции полезной нагрузки, комбинирующие аутентификацию и целостность данных с шифрованием.
24.5.5 Аутентификация в режиме туннеля
При обмене между граничными маршрутизаторами в режиме туннеля в сообщение могут включаться два независимых заголовка аутентификации. Один будет размещен внутри исходного заголовка датаграммы и будет зашифрован и скрыт от остального мира. Этот заголовок обеспечит аутентификацию между конечными точками. Другой заголовок станет частью нешифрованного заголовка IP, используемого для обмена между граничными маршрутизаторами. Он обеспечит аутентификацию между границами сетей.
24.5.6 Обслуживание ключей
Широкое использование безопасности в IP требует распространения множества секретных ключей среди большого количества сетевых узлов. Ключи должны периодически обновляться, и их нужно синхронизовать между собой.
Существует много литературы по управлению ключами. Но ни один из методов управления ключами не специфицирован, поэтому имеются возможности для экспериментирования.
Использование асимметричных общедоступных/личных пар ключей вместо симметричного метода CBC-DES может значительно уменьшить количество администрируемых ключей.
24.6 Дополнительная литература
Следующий список RFC являлся актуальным на момент выхода книги. Последние изменения можно найти в индексе RFC.
RFC 1825 Security Architecture for the Internet Protocol (Архитектура безопасности для протокола Интернета). Справочный раздел этого документа содержит список множества других публикаций по теме безопасности.
