Кратко

  • RFC 9970 разрешает поле Identity в предварительных и окончательных SIP-ответах. Это отвечает на вопрос, который подпись STIR исходного запроса не закрывает: кто ответил на вызов.
  • PASSporT rsp фиксирует утверждение ответившей стороны, а div фиксирует шаг перенаправления. Они не делают новый адрес приемлемым для любого процесса и любого уровня риска.
  • Исходный адресат, полученные сигналы, цепочка перенаправления, ожидаемое поведение, критичность, исход и исключение должны быть связаны, но не слиты в одно утверждение.

Соединение с кем-то — не доказательство связи с тем, кого ожидали

Переадресация сама по себе нормальна. Приёмная переводит звонок, ночная служба принимает его вместо дневной, подрядчик отвечает за известный номер. Та же гибкость становится опасной, если маршрут изменён в пользу ресурса атакующего. Звонящий в банк или медицинскую службу может раскрыть код либо персональные сведения, потому что принял сам факт ответа за подтверждение первоначальной цели.

RFC 9970 — опубликованный в июне 2026 года IETF Proposed Standard, обновляющий connected identity для STIR. В простом вызове достигнутый address of record соответствует dest в PASSporT, с которого начался INVITE. Документ допускает подписанную Identity в предварительном или окончательном ответе; обычный тип такого ответного PASSporT — rsp. У вызывающей стороны появляется проверяемое утверждение о стороне, ответившей в данном диалоге.

Его нельзя незаметно расширить. RFC не создаёт всемирный реестр надёжных номеров, не удостоверяет человека, голос или внешнее деловое отношение и не охватывает подмену медиа после ответа. Механизм относится к сигнализации двухсторонней связи. Именно поэтому он полезен: понятное свидетельство не притворяется всеобщим доверием.

Подлинная подпись не выбирает допустимый риск

Проверка rsp устанавливает криптографические и профильные факты, но не знает цели вызова. Неожиданный, но известный представитель может быть достаточен для общей справки и совершенно недостаточен для подтверждения платежа. Одно и то же корректное сообщение способно оправдать разные решения.

RFC 9970 предполагает, что пользователь или система могут задать критичность для вызова или адресата. Когда ожидаемая connected identity отсутствует либо отличается, устройство может не завершить вызов. RFC не назначает порог, интерфейс, резервный канал или лицо, утверждающее исключение. Это верная граница: достаточность доказательства должен определять тот, кто видит назначение и отвечает за последствия.

Не стоит сводить все аномалии к «ошибке аутентификации». Отсутствие ответа с идентичностью может означать, что получатель не внедрил механизм. Корректная, но другая идентичность может обозначать известного делегата или потребовать второго канала. Повреждённый токен может быть ошибкой интеграции. Смешав эти случаи, организация теряет и способ исправления, и владельца решения.

Перенаправление должно оставлять проверяемую цепочку

RFC 8946 определяет расширение div для PASSporT, когда вызов получает новую цель по пути. Оно помогает проверяющей службе на терминальной стороне понять, почему вызов пришёл к окончательному адресу. Но цепочка, видимая терминатору, не обязательно видна вызывающей стороне. RFC 9970 отмечает, что обычный retargeting не обязан возвращать diversion PASSporT назад; SIP 3XX redirection — определённый сейчас способ безопасно показать вызывающему сведения о перенаправлении.

div — это свидетельство о шаге маршрута, а не универсальное разрешение новому адресату запрашивать секрет или распоряжение. Для чувствительного решения нужно отдельно сохранить исходную цель и причину; реально доступные initial, response и diversion PASSporT; ожидания относительно делегатов и переводов; версию применённой политики и исход; владельца исключения. Общий идентификатор вызова может их связать, но не заменить один элемент другим. Корректный rsp может привести к остановке; терминатор может знать о переводе больше, чем вызывающий; технически успешный вызов может не соответствовать местной политике.

Целостность диалога не удостоверяет человека и содержание

После установления connected identity RFC 9970 рекомендует Identity с действительным PASSporT в re-INVITE и BYE. Это затрудняет подделку изменения или завершения диалога третьей стороной. Польза конкретна для сигнализации. Она не доказывает, что говорит ожидаемый человек, что медиа не подменено или что деловое действие одобрено. Поэтому эксплуатация протокольного профиля, бизнес-решение и хранение доказательств должны иметь разных ответственных.

RFC также допускает, что каталогоподобная служба может объявлять поддержку connected identity, а устройство — предупреждать об исчезновении прежде наблюдаемой поддержки. Это возможная pre-association, а не новый мировой центр разрешений. Общему слою достаточно переносить заявленную идентичность, сообщение-носитель, результат проверки и видимое перенаправление. Пороги, конфиденциальность, срок хранения и постепенное внедрение остаются локальными и обратимыми. Обратная идентичность способна раскрыть сведения о достигнутой стороне, поэтому её применение должно быть соразмерно цели.

Sources