Идентификация и аутентификация. Протокол Kerberos

Протокол IPSec

Протокол IPSec или, если точнее, набор протоколов, разработан IETF как базовый протокол обеспечения безопасности на уровне IP-соединения. IPSec является дополнением к использующемуся сейчас протоколу IP ver.4 и составной частью IP ver.6. Возможности, предоставляемые IPSec:

• контроль доступа;
• контроль целостности данных;
• аутентификация данных;
• защита от повторений;
• обеспечение конфиденциальности.

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

Протокол работает на сетевом уровне модели OSI и, соответственно, он "прозрачен" для приложений. Иными словами, на работу приложений (таких как web-сервер, браузер, СУБД и т.д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет.

Операционные системы семейства Windows 2000 и выше имеют встроенную поддержку протокола IPSec. С точки зрения многоуровневой модели защиты, этот протокол является средством защиты уровня сети.

Рис. 5.9. Туннель безопасности

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

Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого туннеля описывает информационная структура, называемая контекст защиты или ассоциация безопасности (от англ. Security Association, сокр. SA). Как уже отмечалось выше, IPSec является набором протоколов, и состав SA может различаться, в зависимости от конкретного протокола. SA включает в себя:

• IP-адрес получателя;
• указание на протоколы безопасности, используемые при передаче данных;
• ключи, необходимые для шифрования и формирования имитовставки (если это требуется);
• указание на метод форматирования, определяющий, каким образом создаются заголовки;
• индекс параметров защиты (от англ. Security Parameter Index, сокр. SPI) - идентификатор, позволяющий найти нужный SA.

Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA. Каждый хост имеет свою базу SA, из которой выбирается нужный элемент либо на основании SPI, либо по IP-адресу получателя.

Два протокола, входящие в состав IPSec это:

1. протокол аутентифицирующего заголовка - AH (от англ. Authentication Header), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола описана в RFC 4302 (предыдущие - RFC 1826, 2402);
2. протокол инкапсулирующей защиты данных - ESP (от англ. Encapsulating Security Payload) - обеспечивает конфиденциальность и, дополнительно, может обеспечивать проверку целостности и аутентификацию, описан в RFC 4303 (предыдущие - RFC 1827, 2406).

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

Транспортный режим ориентирован на соединение хост-хост. При использовании ESP в транспортном режиме защищаются только данные IP-пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.

Протокол AH

В IP ver.4 аутентифицирующий заголовок располагается после IP-заголовка. Представим исходный IP-пакет как совокупность IP-заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP, на рис. 5.10 он обозначен как ULP - от англ. Upper-Level Protocol) и данных.

Рис. 5.10. а) исходный IP-пакет; b) IP-пакет при использовании AH в транспортном режиме; c) IP-пакет при использовании AH в туннельном режиме

На рис. 5.10 представлен исходный пакет и варианты его изменения при использовании протокола AH в разных режимах. В транспортном режиме заголовок исходного IP-пакета остается на своем месте, но в нем модифицируются некоторые поля. Например, меняется поле Next Header, указывающее на то, заголовок какого протокола следует за IP-заголовком. В туннельном режиме создается новый IP-заголовок, после которого идет заголовок AH, а за ним - полностью исходный IP-пакет.

Аутентификация производится путем создания имитовставки (MAC) для чего используется хэш-функция и секретный ключ. Во всех реализациях AH обязательно должно поддерживаться использование хэш-функций с ключом HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96, представляющих собой варианты хэш-функций MD5 и SHA-1, соответственно. Но могут использоваться и другие, "факультативные" алгоритмы хэширования. Полученное значение, называемое в описании протокола ICV (от англ. Integrity Check Value - значение контроля целостности) помещается в поле Authentication Data ( рис. 5.11). Это поле переменной длины, т.к. разные алгоритмы хеширования формируют разные по длине дайджесты.

Рис. 5.11. Структура заголовка протокола AH

При использовании AH в транспортном режиме, ICV рассчитывается для ULP, данных и неизменяемых полей IP-заголовка. Изменяемые поля, такие как поле TTL, указывающее на время жизни пакета и изменяемое при прохождении маршрутизаторов, при расчете значения хэш-функции принимаются равными 0. В туннельном режиме аутентифицируется весь исходный IP-пакет и неизменяемые поля нового заголовка.

Рассмотрим формат заголовка AH ( рис. 5.11). Первые 8 бит заголовка (поле Next Header ) содержат номер, соответствующий протоколу следующего уровня. Номер для каждого протокола назначает организация IANA (Internet Assigned Numbers Authority). Например, номер TCP - 6, ESP - 50, AH - 51 и т.д.

Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.

Поле SPI содержит значение индекса параметров защиты, по которому получатель сможет найти нужный SA. Нулевое значение SPI показывает, что для данного пакета SPI не существует.

Поле Sequence Number было введено в RFC 2402. Значение счетчика, содержащееся в этом поле, может использоваться для защиты от атак путем повторных посылок перехваченных пакетов. Если функция защиты от повторов активирована (а это указывается в SA), отправитель последовательно наращивает значение поля для каждого пакета, передаваемого в рамках данной ассоциации (соединения, использующего единый SA).

Поле Authentication Data, как уже указывалось ранее, хранит значение ICV.

Протокол ESP

Если AH обеспечивает защиту от угроз целостности передаваемых данных, то ESP также может обеспечивать и конфиденциальность.

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

• для формирования имитовставки HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96;
• для шифрования - DES (в режиме CBC, используется по умолчанию) и NULL (отсутствие шифрования).

Кроме того, зарегистрированы и могут быть реализованы еще ряд алгоритмов шифрования - Triple DES, CAST-128, RC5, IDEA, Blowfish, ARCFour (общедоступная версия RC4) [21].

Рассмотрим формат заголовка ESP ( рис. 5.13). Он начинается с двух 32-разрядных значений - SPI и SN. Роль их такая же, как в протоколе AH - SPI идентифицирует SA, использующийся для создания данного туннеля; SN - позволяет защититься от повторов пакетов. SN и SPI не шифруются.

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

Рис. 5.12. а) исходный IP-пакет; b) ESP в транспортном режиме; c) ESP в туннельном режиме

Рис. 5.13. Структура заголовка ESP

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

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

При совместном использовании протоколов AH и ESP, после IP заголовка идет AH, после него - ESP. В этом случае, ESP решает задачи обеспечения конфиденциальности, AH - обеспечения целостности и аутентификации источника соединения.

Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec. Начнем с того, откуда берется информация о параметрах соединения - SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов - SKIP, ISAKMP (Internet Security Association and Key Management Protocol) и IKE (Internet Key Exchange).

IPSec и NAT

При подключении сетей организаций к Интернет, часто используется механизм трансляции сетевых адресов - NAT (Network Address Translation). Это позволяет уменьшить число зарегистрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные адреса (как правило, из диапазонов, специально выделенных для этой цели, например, адреса вида 192.168.x.x для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу которого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо частных адресов зарегистрированный адрес. То, как производится подстановка, фиксируется в специальной таблице. При получении ответа, в соответствии с таблицей делается обратная замена и пакет переправляется во внутреннюю сеть.

Рассмотрим пример использования NAT рис. 5.14. В данном случае, во внутренней сети используются частные адреса 192.168.0.x. С компьютера, с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).

увеличить изображение
Рис. 5.14. Пример использования NAT

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

Получив представление о механизме работы NAT, разберемся, какие сложности могут возникнуть, в случае использования IPSec. Предположим, с хоста с адресом 192.168.0.2 пытаются установить защищенное соединение с внешним хостом 195.242.2.2, используя протокол аутентифицирующего заголовка (AH). При прохождении маршрутизатора, ip-адрес отправителя меняется, как было описано выше. Протокол AH определяет, что значение имитовставки рассчитывается, включая неизменяемые поля IP-заголовка, в частности - адрес отправителя. Сторона-получатель, обнаружит неверное (из-за трансляции адресов) значение имитовставки и отбросит пакет.

Таким образом, NAT и AH несовместимы. В то же время, протокол ESP, который не контролирует целостность ip-заголовка, может использоваться совместно с NAT.

Кроме того, RFC 2709 определяет расширение NAT - IPC-NAT (IPSec policy Controlled NAT - NAT управляемый правилами IPSec), которое позволяет решить указанную проблему путем создания IP-IP туннеля, одной из конечных точек которого является узел NAT. В этом случае, вместо модификации IP-адреса отправителя в заголовке исходного пакета, NAT-устройство помещает без изменений весь исходный пакет (который аутентифицирован AH), в новый IP-пакет, в заголовке которого в качестве адреса отправителя ставится адрес NAT-устройства. На стороне получателя из полученного пакета изымают исходный пакет и далее обрабатывают его как обычно.

Отдельно необходимо решать вопрос с распределением ключей. Если для этой цели используется протокол IKE (а он использует UDP, порт 500), потребуется специально организовать пересылку соответствующих данных во внутреннюю сеть. В том, случае, если задействовать UDP-порт 500 не представляется возможным, можно использовать описываемый в RFC 3947, 3948 механизм NAT-T (от англ. NAT traversal), определяющий инкапсуляцию IKE и IPSec трафика в пакеты UDP. При этом задействуется порт 4500.

Вопросы, связанные настройкой и использованием реализации IPSec в ОС семейства Windows, рассматриваются в лабораторной работе №12. В ней, в частности, подробно рассматривается создание "политики" IPSec, определяющей для каких узлов и с какими параметрами будет создаваться туннель.