Кратко

  • RFC 5197 сравнивает режимы MIKEY по масштабируемости, зависимости от PKI, PFS, участию сторон в создании ключа и пригодности для групп; ни одна общая метка не переносит эти свойства между режимами.
  • Для конференции нужно доказать, кто распространяет групповой материал, какие участники входят в область TGK и TEK, как меняется членство и что происходит при fork, а затем отдельно подтвердить готовность каждого media-потока.

Топология — часть ключевого решения

MIKEY создавался прежде всего для установления контекста SRTP, но его структура допускает расширения и другие защищаемые протоколы. Один Crypto Session Bundle может включать несколько Crypto Sessions, которые делят TGK и параметры, но получают разные TEK. Уже это показывает, что «ключ установлен» без указания области слишком грубое утверждение.

В разговоре один на один область кажется очевидной. В конференции появляются сервер смешивания, распределитель ключей, десятки клиентов, смена состава и несколько media-потоков. RFC 5197 не объявляет каждый режим одинаково пригодным для такой среды.

PSK может применяться в централизованной конференции, если mixer отправляет инициирующее сообщение и уже имеет нужные доверительные отношения. RSA также допускает центральную раздачу группового ключа, защищённого открытыми ключами клиентов. DH-SIGN даёт PFS и вклад обоих участников в точке-точке, но сам по себе не поддерживает multiparty conference. Полученный DH-secret можно использовать как основу для дальнейшего группового механизма, однако это уже следующий слой. DH-HMAC эффективен при центральном доверенном сервере с PSK многих клиентов, но RFC 5197 прямо отмечает отсутствие поддержки group keying как недостаток режима.

Поэтому вопрос закупки должен звучать не «есть ли MIKEY», а «какой режим, какая групповая архитектура, кто контролирует членство и какой ключ получает каждый поток».

Свойства нельзя суммировать из разных строк таблицы

PSK прост, быстр и не требует PKI, но не даёт PFS и оставляет генерацию материала инициатору. RSA масштабируется через сертификаты, когда сертификат responder известен заранее; PFS также нет, а проверка отзыва может быть не в реальном времени.

DH-SIGN обеспечивает совместный вклад и PFS, но для масштабирования требует доверенной PKI и преимущественно остаётся point-to-point. DH-HMAC даёт те же два свойства без PKI, ценой заранее распределённого секрета. RSA-R позволяет получить сертификат responder внутри обмена при неизвестном конечном адресате, но не превращает опциональный RAND инициатора в истинную PFS. NULL целиком зависит от TLS или IPsec и может раскрыть master key промежуточному proxy, где заканчивается нижний защищённый канал.

Ошибка начинается, когда система берёт PFS из строки DH-SIGN, групповую раздачу из строки RSA и простоту PSK, а затем приписывает сумму слову MIKEY. Свойства принадлежат выполненному режиму и конкретной топологии.

Fork меняет число владельцев ключа

В SIP fork одно приглашение и его MIKEY payload уходят нескольким получателям. Forward-режим может передать связанный материал разным ответчикам. Если две ветви используют одну TEK и выбирают одинаковый 32-битный SSRC, SRTP способен вывести одинаковые session keys и векторы инициализации. RFC 5197 связывает это с риском two-time pad.

В групповой системе недостаточно считать участников в каталоге. Нужно фиксировать фактические ветви, ответы, область TEK, SSRC и результат collision handling. При выходе участника должна быть видна смена области ключа; при входе — отдельное решение о том, какие прежние данные ему доступны.

Состояние времени и момент готовности

MIKEY использует timestamps и message cache для replay handling. Допустимый clock skew и ёмкость cache участвуют в гарантии. Перезапуск узла может изменить её без смены режима.

Разные режимы различаются и по задержке. PSK и RSA могут передать материал одним сообщением, что удобно для early media. DH-режимы и RSA-R требуют ответа. Media может прийти быстрее SDP-ответа, и у инициатора ещё не будет итогового ключа. В конференции умножение ответов способно увеличить число проверок подписей и DH-вычислений, отодвигая готовность дальше.

Так что групповая готовность состоит минимум из трёх независимых фактов: членство и область ключа определены; replay-состояние действительно; каждый endpoint установил нужную TEK до обработки потока.

Что должно остаться в квитанции

Запишите режим и роль каждого узла, фактический список участников, mixer или распределитель, источник членства и версию политики. Для сертификатов сохраните binding личности, время проверки и свежесть отзыва; для PSK — идентификатор и жизненный цикл; для NULL — реальные концы нижнего защищённого канала.

Свяжите transcript hash с CSB, TGK и всеми Crypto Sessions. Укажите TEK scope, ветви fork, SSRC, collision resolution и события rekey при изменении состава. Добавьте источник времени, skew, cache epoch, ответ, установку ключа, первый защищённый пакет и первый успешный decrypt для каждого получателя.

Это не новая команда протокола, а способ сохранить различия, которые RFC 5197 уже описал. Реализовано, выбрано, подходит для группы, доставлено всем участникам и работает на media — разные слои. Галочка совместимости может начать проверку, но не завершить её.

Источники

  1. RFC 5197 в HTML
  2. Текст RFC 5197
  3. Информационная страница RFC 5197
  4. IETF Datatracker: RFC 5197
  5. История RFC 5197
  6. Ссылки RFC 5197
  7. Errata RFC 5197
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — DH-HMAC
  11. RFC 4738 — RSA-R
  12. RFC 4567 — key management для SDP и RTSP
  13. RFC 4568 — security descriptions
  14. RFC 5027 — security preconditions
  15. RFC 4086 — требования к случайности
  16. RFC 4082 — TESLA
  17. RFC 4442 — bootstrapping TESLA
  18. Heng Lu — слои реальности и символическая власть
  19. Heng Lu — минимальная начальная спецификация
  20. Heng Lu — приоритет работающего кода