Кратко

  • Членство в домене T означало известное соответствие Spec(T), а доверие B к A требовало защищённого соединения и локальной конфигурации B, подтверждавшей членство A.
  • Идентичность от узла, которому получатель не доверял, не имела гарантии подлинности или целостности и не могла отображаться, передаваться дальше либо использоваться сервисом.

Общее множество правил не было общей верой

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

Опасность заключалась в слове «доверенный». Документ не объявлял всё внутри периметра одинаково достоверным. Узел входил в домен T, если было известно, что он соблюдает набор спецификаций и конфигураций Spec(T). Домен создавали люди. Один оператор мог знать свойства своего оборудования; несколько операторов могли соединить множества двусторонними соглашениями. Административное членство не создавало защищённого соединения между каждой парой.

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

Поэтому RFC считал некорректной фразу «информация получена от доверенного узла». У отдельного участника нет полного знания обо всех членах. Корректно: «получена от другого узла, которому он доверяет». Такая грамматика сохраняет точку проверки. Нужно назвать получателя, непосредственного отправителя, защищённое соединение и локальное основание членства.

Утверждение наследовало свой маршрут

Сетевая утверждённая идентичность создавалась SIP-посредником в результате аутентификации. Она могла быть SIP-, SIPS- или телефонным URI, осмысленным в соответствующем домене или диапазоне и ведущим к пользователю либо логике, работающей от его имени. Метод аутентификации, как минимум его надёжность и сила, входил в Spec(T). Пользователь мог предложить предпочтительную идентичность, но решение оставалось у политики домена.

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

От недоверенного узла контекст отсутствовал. Получатель не знал, применялся ли Spec(T), поэтому не было гарантии подлинности или целостности. RFC 3324 устанавливал не понижение рейтинга, а запрет использования: не показывать пользователю, не передавать другим узлам, не давать сервисам как входные данные. Даже отображение с предупреждением могло придать непроверенному имени влияние.

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

Совместимость не превращалась в паспорт Интернета

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

Spec(T) не обязательно являлся единым опубликованным документом. Это было согласованное знание о том, что утверждается, как это определено, какая аутентификация допустима, как сохраняется целостность и какая политика приватности действует. Видимое имя заголовка без этих сведений было синтаксисом, но не полной мерой доказательства.

Приватность дополнительно ограничивала распространение. Сообщение могло указывать, что идентичность нельзя передавать другим пользователям. Отдельное указание могло выражать собственную просьбу пользователя, поскольку политика могла различать его волю и юридическую либо эксплуатационную причину. Идентичность оставалась внутри доверенной сети, но скрывалась от внешнего пользователя. Это согласуется с относительной к наблюдателю приватностью RFC 3323, не совпадая с ней.

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

Исторический вывод прост: граница могла организовать совместимое поведение, но не могла проверять утверждения за каждого участника. Авторитет появлялся только на направленном ребре, которое получатель мог объяснить.

Источники