ПРИМЕЧАНИЕ
Как отмечалось в разделе 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 разрядам.
Значение
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 |
