Кратко

  • P-Preferred-Identity позволял пользователю подсказать, какую из его допустимых идентичностей выбрать, но не служил доказательством и должен был исчезнуть до пересылки сообщения.
  • P-Asserted-Identity от недоверенного источника следовало заменить значением, созданным после аутентификации, либо удалить: правильное название заголовка не давало отправителю полномочий.

Представление, предпочтение и утверждение

В SIP уже существовал From. Пользователь мог показать в нем имя или псевдоним, подходящий для разговора. Телефонным сетям, однако, требовалась иная величина для передачи номера вызывающего абонента, применения услуг или расследования происхождения запроса. При этом абонент мог не желать, чтобы операционная идентичность стала известна получателю. RFC 3325 не превратил From в более сильное удостоверение. Он развел три действия и назначил им разных авторов.

From оставался представлением пользователя. P-Preferred-Identity тоже поступал от пользовательского агента, но предназначался непосредственно доверенному прокси. Если после аутентификации у абонента было несколько допустимых номеров или SIP-идентичностей, поле указывало, какой вариант он предпочитает. P-Asserted-Identity уже был утверждением сети, возникшим после проверки либо полученным от доверенного соседа. Похожие названия скрывали принципиально разную ответственность.

Получив предпочтение от недоверенного элемента, прокси мог использовать его только как подсказку. Сначала он аутентифицировал инициатора, затем сравнивал значение с набором идентичностей, допустимых для этого субъекта. Если совпадения не было, прокси мог построить другое корректное утверждение или отклонить запрос. Простое копирование желания в привилегированное поле не превращало его в результат проверки.

После выбора прокси обязан был удалить предоставленный пользователем P-Preferred-Identity из каждого пересылаемого сообщения. Это было не косметическое очищение синтаксиса, а сохранение происхождения доказательства. Если бы предпочтение шло дальше рядом с утверждением, журнал или приложение мог бы позднее счесть их двумя независимыми подтверждениями, хотя одно было лишь сырьем, повлиявшим на создание другого.

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

Поддельный авторитет требовалось разрушить

Еще жестче правило работало, когда недоверенный пользователь сам присылал P-Asserted-Identity. Умение правильно написать имя заголовка не делало терминал представителем доверенного домена. Если прокси намеревался добавить утверждение, он должен был аутентифицировать инициатора и использовать идентичность, полученную в результате этой процедуры.

Если недоверенный вход уже содержал заявленную SIP- или SIPS-идентичность, прокси должен был заменить ее одной SIP- или SIPS-идентичностью собственной конструкции либо удалить заголовок. Для телефонной идентичности действовало то же правило. Нельзя было оставить старое значение и просто прикрепить к нему отметку о доверии: подделка тогда въехала бы в домен по защищенному каналу. Прежний авторитет следовало уничтожить или полностью пересобрать из фактов, контролируемых прокси.

P-Asserted-Identity от доверенного узла, напротив, можно было использовать так, будто прокси самостоятельно аутентифицировал пользователя. Но это сокращение наследовало все предпосылки Trust Domain из RFC 3324: защищенное получение, настроенное членство и Spec(T), описывающую аутентификацию, защиту канала, участников, правила конфиденциальности и соблюдение требований. Сам заголовок не становился криптографическим сертификатом.

Раздел о применимости прямо отмечал ограничение. Утвержденные идентичности не были криптографически заверены и не показывали, какой именно элемент сделал заявление. Предполагалось, что за него отвечает домен целиком. За пределами архитектуры, удовлетворяющей этим требованиям, значения оставались уязвимы для подделки, повторного воспроизведения и искажения. RFC 3325 не предлагал универсальное удостоверение для открытого Интернета.

Конфиденциальность требовала второго удаления

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

Новый маркер id обязывал удалить все значения P-Asserted-Identity до передачи запроса недоверенному элементу. Противоположное значение none требовало не удалять утвержденные идентичности по соображениям конфиденциальности. При отсутствии Privacy решение принимала политика домена, записанная в Spec(T). RFC рекомендовал сохранять идентичность, когда политика это допускает, поскольку удаление могло нарушить услуги. Одновременно он предупреждал: пересылка способна раскрыть сведения, публикации которых пользователь не просил и которую не может предотвратить, если подходящий сервис приватности недоступен.

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

Для принимающего пользовательского агента существовала симметричная граница. Если предыдущий элемент не был доверенным, P-Asserted-Identity запрещалось использовать каким-либо образом. Внутри подходящего Trust Domain политика реализации или сервиса могла решить, как показать значение; спецификация не навязывала способ согласования разных типов.

RFC 5876 позднее обновил отдельные детали RFC 3325. RFC 4474, RFC 8224 и RFC 8225 развивали иные конструкции аутентифицированной идентичности и PASSporT, а RFC 4916 рассматривал связанную идентичность в ходе диалога. Эти механизмы не отменяют исторический вывод. Полномочия заключались не в официально звучащем названии, а в контролируемой цепочке: аутентифицировать, ограничить допустимое множество, выбрать, пересоздать, удалить предпочтение, классифицировать следующий переход и стереть утверждение, если этого требует приватность.

RFC 3325 оставил важный урок об обращении с доказательствами. Пользовательский ввод может быть законным основанием для выбора, не являясь доказательством результата. Прокси создавал собственную квитанцию только тогда, когда не позволял исходному желанию пережить решение и выглядеть вторым свидетелем его истинности.

Источники