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

19.4. Создание статического соглашения о безопасности

Наиболее прямолинейным методом добавления соглашения о безопасности в базу является отправка сообщения

с заполненными параметрами, которые могут задаваться вручную. Последнее затрудняет смену ключей, которая необходима для предотвращения криптоаналитических атак, но зато упрощает настройку. Элис и Боб договариваются о ключах и алгоритмах без использования линий связи. Мы приводим последовательность действий по созданию и отправке сообщения .

Сообщение

обязано иметь три расширения: соглашение о безопасности, адрес и ключ. Оно может дополняться и другими расширениями: временем жизни, личными данными и параметром важности (sensitivity). Сначала мы опишем обязательные расширения.

Расширение SA описывается структурой

, представленной в листинге 19.3.

Листинг 19.3. Расширение SA

Таблица 19.4. Использование расширений

Состояние SA	Описание	Возможность использования
SADB_SASTATE_LARVAL	В процессе создания	Нет
SADB_SASTATE_MATURE	Полностью сформированное	Да
SADB_SASTATE_DYING	Превышено гибкое ограничение на время жизни	Да
SADB_SASTATE_DEAD	Превышено жесткое ограничение на время жизни	Нет

Таблица 19.5. Алгоритмы аутентификации и шифрования

Алгоритм	Описание	Ссылка
SADB_AALG_NONE	Без аутентификации
SADB_AALG_MD5HMAC	HMAC-MD5-96	RFC 2403
SADB_AALG_SHA1HMAC	HMAC-SHA-1-96	RFC 2404
SADB_EALG_NONE	Без шифрования
SADB_EALG_DESCBC	DES-CBC	RFC 2405
SADB_EALG_3DESCBC	3DES-CBC	RFC 1851
SADB_EALG_NULL	NULL	RFC 2410

Поле

содержит индекс параметров безопасности (security parameters index, SPI). Это значение вместе с адресом получателя и используемым протоколом (например, IPSec АН) уникально идентифицирует соответствующее соглашение о безопасности. При получении пакета значение SPI используется для поиска соглашения, относящегося к пакету. При отправке пакета значение помещается в него для использования получателем. Никаких иных значений SPI не имеет, поэтому назначаться индекс может последовательно, в случайном порядке или с использованием метода, рекомендуемого собеседником. Поле задает размер окна защиты от повторов. Поскольку статические соглашения о защите не дают возможности задействовать эту защиту, мы устанавливаем поле равным нулю. Значение поля меняется в зависимости от состояния динамически создаваемых соглашений о безопасности (см. табл. 19.4). Создаваемые вручную соглашения существуют исключительно в состоянии . С другими состояниями мы встретимся в разделе 19.5.

Поля

и определяют алгоритмы аутентификации и шифрования для данного соглашения. Возможные значения этих полей перечислены в табл. 19.5. Единственное значение поля определено в POSIX как константа . Этот флаг требует совершенной безопасности пересылки (perfect forward security), которая состоит в том утверждении, что значение ключа не должно зависеть от предыдущих подключений или какого-либо главного ключа. Флаг используется при запросе ключей у приложения, заведующего ими, но не при создании статических соглашений.

Следующее обязательное расширение команды

должно содержать адреса отправителя и получателя, задаваемые константами и . При необходимости может быть указан адрес прокси-сервера . Подробнее об обработке адресов прокси-серверов вы можете прочесть в RFC 2367 [73]. Адреса задаются в структуре , представленной в листинге 19.4. Поле определяет тип адреса (отправителя, получателя или прокси-сервера). Поле позволяет выбрать протокол IP или произвольный протокол (значение 0). Поле описывает значимый префикс адреса. Это позволяет использовать одно соглашение для множества адресов. За структурой следует структура соответствующего семейства (например, или ). Номер порта из структуры используется только в том случае, если поле задает протокол, поддерживающий номера портов (например, ).