UNIX: разработка сетевых приложений

ПРИМЕЧАНИЕ

Как отмечалось в разделе 4.2, на большинстве систем константа AF_KEY совпадает с PF_KEY. Однако в RFC 2367 совершенно четко утверждается, что с сокетами управления ключами должна использоваться константа PF_KEY.

Для открытия символьного сокета управления ключами требуются определенные привилегии. В системах с сегментированными привилегиями для этого действия должна иметься специальная привилегия. В обычных Unix-системах открывать такие сокеты может только привилегированный пользователь.

IPSec предоставляет криптографический сервис на базе соглашений о безопасности( security association, SA). Соглашение о безопасности представляет собой сочетание адресов отправителя и получателя (а при необходимости, транспортного протокола и портов), механизма (например, аутентификации) и ключей. К одному потоку трафика может относиться несколько соглашений (например, соглашения об аутентификации и о шифровании). Набор хранящихся в системе соглашений называется базой данных соглашений о безопасности( security association database, SADB).

База SADB может использоваться не только для работы с IPSec. В ней могут иметься записи для OSPFv2, RIPv2, RSVP и Mobile-IP. По этой причине нельзя считать, что сокеты PF_KEY предназначены только для работы с IPSec.

Для работы IPSec необходима также база политик безопасности( security policy database, SPDB). Политики описывают требования к трафику, например: «трафик между узлами А и В должен аутентифицироваться при помощи заголовков аутентификацииIPSec ( authentication header, АН); не удовлетворяющий требованию трафик должен сбрасываться». База соглашений описывает порядок выполнения требуемых для обеспечения безопасности действий, например, если трафик между узлами А и В использует заголовки аутентификации, то в SADB содержится соответствующий алгоритм и ключи. К сожалению, стандартного механизма управления SPDB не существует. Сокеты PF_KEY работают только с базой SADB, но не с SPDB. Реализация IPSec группы KAME использует для управления SPDB расширенияPF_KEY, однако никаким стандартом эти расширения не описываются.

Сокеты управления ключами поддерживают три типа операций:

1. Процесс может отправить сообщение ядру и всем остальным процессам с открытыми сокетами, записав это сообщение в свой сокет. Таким способом добавляются и удаляются записи в базе соглашений о безопасности. Таким же способом процессы, обеспечивающие собственную безопасность самостоятельно (типа OSPFv2), могут запрашивать ключи у демона-ключника (демона, управляющего ключами).

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

3. Процесс может отправить ядру запрос дампа, и ядро в ответ передаст ему дамп текущей базы SADB. Это отладочная функция, которая может быть доступна не во всех системах.

19.2. Чтение и запись

Все сообщения в сокете управления ключами должны иметь одинаковые заголовки, соответствующие листингу 19.1 [1] . Сообщение может сопровождаться различными расширениями в зависимости от наличия дополнительной информации или необходимости ее предоставления. Все нужные структуры определяются в заголовочном файле <net/pfkeyv2.h>. Все сообщения и расширения подвергаются 64-разрядному выравниванию и дополняются до длин, кратных 64 разрядам. Все поля длины оперируют 64-разрядными единицами, то есть значение длины 1 означает реальную длину 8 байт. Расширение, не содержащее достаточного количества данных, дополняется произвольным образом до длины, кратной 64 разрядам.

1

Все исходные коды программ, опубликованные в этой книге, вы можете найти по адресу http://www.piter.com.

Значение sadb_msg_type задает одну из десяти команд управления ключами. Типы сообщений перечислены в табл. 19.1. За заголовком sadb_msg может следовать произвольное количество расширений. Большинство сообщений имеют обязательные и необязательные расширения, которые будут описаны в соответствующих разделах. Шестнадцать типов расширений с названиями структур, их определяющих, перечислены в табл. 19.3.

Листинг 19.1. Заголовок сообщения управления ключами

 struct sadb_msg {
  u_int8_t sadb_msg_version; /* PF_KEY_V2 */
  u_int8_t sadb_msg_type; /* см. табл. 19.1 */
  u_int8_t sadb_msg_errno; /* код ошибки */
  u_int8_t sadb_msg_satype; /* см. табл. 19.2 */
  u_int16_t sadb_msg_len; /* длина заголовка и расширений / 8 */
  u_int16_t sadb_msg_reserved; /* нуль при передаче, игнорируется
  при получении */
  u_int32_t sadb_msg_seq; /* порядковый номер */
  u_int32_t sadb_msg_pid; /* идентификатор процесса отправителя
  или получателя */
 };

Таблица 19.1. Типы сообщений

Тип сообщения	К ядру	От ядра	Описание
SADB_ACQUIRE	•	•	Запрос на создание записи в SADB
SADB_ADD	•	•	Добавление записи в полную базу безопасности
SADB_DELETE	•	•	Удаление записи
SADB_DUMP	•	•	Дамп SADB (используется для отладки)
SADB_EXPIRE		•	Уведомление об истечении срока действия записи
SADB_FLUSH	•	•	Очистка всей базы безопасности
SADB_GET	•	•	Получение записи
SADB_GETSPI	•	•	Выделение SPI для создания записи SADB
SADB_REGISTER		•	Регистрация для ответа на SADB_ACQUIRE
SADB_UPDATE	•	•	Обновление записи в частичной SADB

Таблица 19.2. Типы соглашений о безопасности

Тип соглашения	Описание
SADB_SATYPE_AH	Аутентифицирующий заголовок IPSec
SADB_SATYPE_ESP	ESP IPSec
SADB_SATYPE_MIP	Идентификация мобильных пользователей (Mobile IP)
SADB_SATYPE_OSPFV2	Аутентификация OSPFv2
SADB_SATYPE_RIPV2	Аутентификация RIPv2
SADB_SATYPE_RSVP	Аутентификация RSVP
SADB_SATYPE_UNSPECIFIED	He определен