Кратко

  • RFC 9970 позволяет отдельным ответам SIP нести rsp PASSporT, подписывающий достигнутый адрес в dest; завершающая сторона без подходящего полномочия для этого адреса не должна его отправлять.
  • Такой токен является свидетельством об ответе сигнализации. Он не подтверждает происхождение медиа, неизменность собеседника, доставку ответа или действие, которое должен автоматически выполнить вызывающий абонент.

Удобный, но опасный вывод из термина connected identity состоит в том, что подпись будто бы подтверждает весь разговор. Будто бы сеть достигла нужной организации, именно она отвечает, никто не заменит её после соединения, а устройство может без дальнейшего выбора показать «безопасно». RFC 9970 формулирует значительно более узкое утверждение. В работе Chris Wendt и Jon Peterson ответ в обратном направлении SIP-диалога получает возможность нести Identity и rsp PASSporT с подписью над dest — адресом записи достигнутой стороны.

Такую информацию могут нести временные и окончательные ответы, включая 100, 180, 183 и 200. Для инициатора это важное новое наблюдение: он видит не только факт продвижения диалога, но и криптографически связанное заявление о том, какого адресата достигла сеть. Если вызов был перенаправлен с разрешением, в ответ могут быть включены и полученные ранее PASSporT div. Тогда ожидаемый адрес, фактически достигнутый адрес и цепочка перенаправления не сливаются в один неразборчивый результат.

Однако криптографическая корректность не назначает доверие. Терминирующая сторона вправе послать rsp лишь при наличии подходящей учётной основы для подписи данного dest; без неё RFC запрещает отправку. Проверяющая сторона, в свою очередь, должна доверять сертификату и иметь разумную уверенность, что этот сертификат уполномочен подписывать запросы или ответы для указанного номера. Проверка подписи связывает ключ с сообщением. Она не объясняет, кто выдал полномочие, почему оно применимо к этому номеру и следует ли данному абоненту принять такое заявление.

Разделение особенно заметно при смене адресата. Если rsp содержит dest, отличающийся от адресата в запросе, сформировавшем диалог, необходим хотя бы один div PASSporT. Но и при корректной цепочке доверие к rsp и div остаётся локальной политикой relying party. Банковский контакт может требовать заранее известного пути без непредвиденного перенаправления; другая служба может разрешить известный дежурный маршрут. Протокол даёт материал для выбора, а не изымает выбор у того, кто несёт риск.

Природа SIP-ответа не допускает и простой схемы «отклонить при ошибке». Получатель не может отвергнуть ответ так же, как запрос, и вернуть ошибку отправителю. Для временного диалога остаётся CANCEL, для установленного — BYE. Временные ответы без соответствующего механизма надёжности не гарантированы и иногда поглощаются посредниками. Поэтому отсутствие rsp не означает автоматически атаку, а действительная подпись не означает автоматически продолжение вызова. Нужны контекст доставки, ожидание поддержки функции и выбранная критичность назначения.

Главное ограничение лежит между сигнализацией и медиа. После ответа вызов может быть переведён, поставлен на удержание или передан иной стороне; вызывающий абонент может этого не заметить. RFC 9970 помогает против имитации ответов и сообщений внутри или при завершении диалога — например, ложных BYE и re-INVITE. Он не утверждает, что подписанный ответ удостоверяет последующий поток голоса, видео или данных. Медиа не наследует автоматически происхождение от подписи в ответе.

В этом состоит практическое применение Running-Code Primacy Lu Heng. Проверяемая техническая конструкция должна описывать предел своего доказательства, а не получать дополнительную власть через удобный интерфейс или название института. rsp делает заявление об адресате проверяемым. Управление сертификатами отвечает за пригодность подписанта, relying party — за принятие, а механизм медиа — за собственную защиту. Один общий индикатор безопасности скроет эти разные центры ответственности.

RFC не предписывает пользовательский интерфейс, но предполагает, что абонент способен выбрать posture авторизации для конкретного вызова или назначения, когда connected identity критична. Для финансовых, государственных и экстренных контактов это не декоративная настройка. Полезная запись должна сохранять ожидаемое назначение, подписанный dest, сертификат и основание его пригодности, принятые перенаправления, результат проверки и фактически выбранное действие.

Источники