Кратко

  • При third-party REGISTER принятый binding остаётся pending: регистратор должен запросить согласие владельца final recipient URI, а уже затем разрешать forwarding. HTTP 202 не переносит полномочия регистранта на получателя.
  • Permission document связывает sender, target URI, final recipient и grant/deny capabilities. Аутентификация решения, установка состояния и runtime match — самостоятельные квитанции.
  • Ограничение в один contact на транзакцию, 470 Consent Needed, refresh и Trigger-Consent сдерживают усиление и устаревшие права. Они не доказывают правильный fan-out, доставку, внимание человека или завершённый отзыв.

Binding и разрешение отвечают на разные вопросы

Обычный REGISTER часто предполагает, что регистрирующая сторона и endpoint, который будет принимать запросы, совпадают. В таком случае аутентификация регистрации может служить частью разумной модели доверия.

Third-party registration меняет картину. Злоумышленник способен связать свой Address of Record с contact жертвы и направить к ней нежелательные звонки или сообщения.

RFC 5360 позволяет серверу ответить 202, принять операцию в обработку и оставить contact pending. Затем регистратор запрашивает согласие, а пакет событий Pending Additions сообщает регистранту дальнейший статус.

Это не требование добавлять церемонию согласия к каждому REGISTER. Документ отдельно рассматривает user agent, который регистрируется и принимает по тому же соединению, и регистратор, допускающий регистрацию третьей стороны.

Доказательство должно назвать конкретный случай: AoR, contact, аутентифицированного регистранта, связь с connection, признак third-party, pending state, permission tuple и фактическое решение о forwarding.

Фраза «REGISTER успешно выполнен» слишком широка. Сервер мог лишь согласиться продолжить обработку и всё ещё не иметь права направлять вызовы на contact.

202 — квитанция очереди, а не согласие

Тот же принцип действует при изменении списков. A предлагает добавить B, relay отвечает HTTP 202 и помещает B в pending.

Ответ показывает, что операция принята. Он ничего не доказывает о доставке permission request, решении B, аутентификации, установке состояния, совпадении будущего запроса или доставке человеку.

Pending Additions различает pending, waiting, error, denied и granted именно потому, что исход появится позже. Если B недоступен и нет store-and-forward, может не дойти даже MESSAGE с запросом разрешения.

Сохраняйте manipulation ID, target, recipient, ответ, версию pending и последовательность NOTIFY. Переход к granted должен ссылаться на определённые document и authentication receipt.

Один зелёный статус «accepted» стирает границы между полномочием предложить изменение и полномочием получателя его разрешить.

Permission должна находиться у translation logic

Relay получает запрос к target URI и преобразует его в одну или несколько recipient URI. Он может быть proxy, B2BUA или гибридом. Mapping поступает из регистрации, списка или локальных правил.

Именно в этой точке permission становится исполнимой. Комментарий в административном интерфейсе не управляет будущими исходящими запросами.

Пока получатель не согласился, relay игнорирует его при переводе. После grant каждый runtime match должен использовать конкретную версию permission и проверять её scope.

Снимок настройки доказывает попытку администратора. Аутентифицированная grant capability доказывает ограниченное решение. Ни то ни другое не показывает, какую версию mapping relay применил к последующему INVITE или MESSAGE.

Исполнительная квитанция соединяет sender, target, final recipient, версию permission и идентификатор исходящего запроса. Для B2BUA важно также отметить место завершения и повторного создания сообщения.

Администратор не может согласиться за адресата

Клиенту нужны аутентификация и авторизация на изменение списка. Это необходимый контроль, но его право заканчивается до чужого recipient URI.

RFC сохраняет два решения. Политика позволяет администратору предложить участника. Получатель решает, вправе ли relay переводить трафик на его адрес в обозначенном контексте.

Аудит должен хранить обоих субъектов: кто предложил добавление, какая policy разрешила его, кого спросили, что показали и каким способом подтвердили grant или deny.

Запись «добавлено авторизованным пользователем» скрывает именно ту защиту, ради которой существует framework.

Владелец имени группы, оператор relay и владелец каждого endpoint имеют разные полномочия. Коллективный адрес не присваивает себе волю участников.

Permission — это кортеж, а не общее «да»

Permission document содержит sender, original recipient или target URI, final recipient URI и capabilities для grant и deny.

Sender может иметь широкий scope, target допускает wildcard в модели документа, но final recipient не может быть wildcard. Эта асимметрия не даёт превратить согласие в разрешение на произвольные будущие адреса.

Корректный синтаксис не гарантирует понимания. Показывал ли интерфейс wildcard? Совпадал ли human-readable текст с машинным? Не переназначили ли target alias? Не расширила ли новая identity policy множество sender?

Храните точные bytes, hash, версию формата, идентичность relay, sender, target, recipient, hashes grant/deny и hash представления для человека. Будущий запрос сравнивается с этим замороженным scope.

Поле consented=true не позволяет восстановить, кто и что разрешил, в отношении какого перевода и на какой срок.

Capability должна принадлежать нужному principal

Получатель отправляет пустой SIP PUBLISH или HTTP GET на grant либо deny URI. Пустое тело не лишает запрос контекста: capability связана с одной permission.

Relay должен удостовериться, что originator владеет final recipient URI. RFC рассматривает SIP Identity, P-Asserted-Identity в доверенном административном домене, SIP Digest при shared secret и return routability.

У методов разные цепочки ответственности. Утверждение домена зависит от его границы, Digest — от секрета и challenge state, подписанная identity — от применимого механизма. Return routability доказывает более узкое владение секретной capability.

Не ограничивайтесь authenticated=true. Нужны method, asserted principal, проверенный recipient, trust domain или credential context, capability hash, policy version и решение.

Правильные credentials другого principal не становятся согласием владельца конечного URI.

Return routability доказывает получение секрета

Relay создаёт непредсказуемую URI и доставляет её вместе с запросом согласия. Возврат запроса на эту URI может считаться аутентифицированным при выполнении условий framework.

MESSAGE направляется на SIPS URI, grant и deny capabilities должны быть SIPS или HTTPS, а случайная часть содержит не менее 32 бит криптографической случайности.

Даже тогда вывод ограничен. Доказано владение секретом, доставленным на достижимый endpoint. Не доказаны гражданская идентичность, длительный контроль адреса, информированное понимание или отсутствие forwarded copy.

Сохраняйте качество генерации, заявление об entropy, hash вместо повторно используемого секрета, защищённый путь доставки, время redemption и обработку replay.

Переход к более сильной identity меняет acceptance policy. Старые решения нельзя задним числом объявить равными новым.

Один recipient на транзакцию — защита от усиления

Relay сам способен усилить атаку. Небольшая конфигурационная операция могла бы добавить много адресов и вызвать отправку MESSAGE каждому из них.

Поэтому XCAP-клиент добавляет не более одного recipient за HTTP transaction, а REGISTER в этом framework — не более одного contact за транзакцию. Инициатор тратит сопоставимое число запросов.

Это не глобальный rate limit и не доказательство добрых намерений. Атакующий может создать множество транзакций, распределить учётные записи или растянуть их во времени.

Логируйте principal, target, предложенный recipient, входные и ожидаемые исходящие bytes, rate и решение. Отказ 409 или 403 подтверждает только ограничение конкретной операции.

Дополнительно нужны бюджеты по аккаунтам, target и destination, а также учёт retries и store-and-forward.

470 запрещает скрытый частичный fan-out

Request-contained URI list выбирает получателей в момент коммуникации. Relay сверяет её с более широким набором уже имеющихся permissions.

Если хотя бы одной URI не хватает разрешения, перевод не выполняется и возвращается 470 Consent Needed. Permission-Missing указывает отсутствующие элементы.

Это правило all-or-nothing. Отправить разрешённым и молча отбросить остальных — другая policy, которая создаёт трафик без полного основания и может раскрыть состав группы.

Сохраняйте hash входного списка, версию permission set, результат каждого match, 470 и раскрытый missing set. Сам missing set может быть чувствительным.

В сохранённом снимке errata есть технический отчёт со статусом Reported о скобках вокруг URI при неоднозначной пунктуации Permission-Missing. Это датированное предложение, не молча применённая редакция стандарта.

Отзыв завершается изменением состояния

Получатель использует deny capability. Если она потеряна, последующий переведённый запрос может содержать Trigger-Consent и target URI. Получатель запрашивает новый документ, а затем отказывает.

Recovery path не означает немедленного удаления старого права. Ответ 200 принимает запрос восстановления; MESSAGE доставляет новый документ. Только аутентифицированный deny и удаление permission меняют активную translation logic.

Ledger должен связать намерение, trigger, новый документ, deny, версию состояния, cutover и последний исходящий запрос при прежнем grant. Для конкурентных запросов нужна определённая граница.

Контекст тоже может закончиться: удаление recipient удаляет permission, истечение registration убирает право contact, неудачный refresh запускает удаление по policy.

«Не был отозван» не означает «вечен».

Защищённый транспорт не доказывает понимания

Permission documents и pending status раскрывают отношения между sender, target и recipient. Подмена может заставить человека разрешить не то, что ему показали.

RFC рекомендует сильную целостность и конфиденциальность, включая end-to-end S/MIME и hop-by-hop TLS/SIPS при отсутствии более сильного средства. Store-and-forward также требует защищённой custody.

Эти меры защищают канал и bytes в рамках своих предпосылок. Они не доказывают совпадение human-readable и machine-readable, показ wildcard, правильного principal или установку той же tuple.

Связывайте display с document hash и храните доказательства транспорта отдельно от семантики. Проверяйте mutation, replay, leakage, stale pending и смену policy.

Шифрование необходимо, но не должно заимствовать полномочия над фактами, которые оно не наблюдает.

Позднее уточнение синтаксиса не доказывает внедрения

RFC 8217 обновляет RFC 5360 и другие документы SIP, уточняя, когда URI использует production name-addr. Это меняет нормативную среду разбора затронутых полей.

Отсюда не следует, что конкретный relay уже обновил parser. Для исполнения нужны software version, configuration и governing document set.

Статус Proposed Standard тоже относится к документу. Он не доказывает adoption, interoperability или работу в конкретном сервисе.