Кратко

  • Элемент AUTH_SESSION из RFC 3520 переносит ограниченное разрешение из сигнализации сеанса в запрос ресурса. Сохранность байтов и верная подпись помогают принять решение, но не создают локальных полномочий, не резервируют путь и не доказывают результат приложения.
  • Надёжная цепочка хранит отдельно издателя и границы его власти, точный токен, свежесть, сопоставление полей, локальное решение PDP, исполнение PEP, состояние RSVP, предусловия SIP, наблюдаемый транспорт и аутентифицированный итог приложения.

У непрозрачного контейнера есть полезное свойство: его можно передать через узел, которому не доверяют толкование содержания. Но эта же непрозрачность подталкивает оператора принять успешно доставленный объект за успешно доставленную услугу. Переход между плоскостями управления — лишь начало проверки.

RFC 3520 опубликована в апреле 2003 года в Standards Track и сейчас числится Proposed Standard. Она определяет Session Authorization Policy Element: хост получает его через протокол сигнализации и без изменений помещает в RSVP-объект POLICY_DATA.

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

Разные модели сохраняют контекст в разных местах

В coupled model один policy server участвует и в решении сервиса, и в решении о ресурсе. Обязателен только SESSION_ID: он отсылает к сохранённому состоянию. Формат остаётся делом реализации, но это состояние должно переживать репликацию, перезапуск и переключение.

В associated model элемент несёт также идентичность авторизующей стороны. Пограничный узел по ней находит сервер, хранящий решение о медиа. Если он не знает независимо, что указанная сторона — легитимный policy server домена, требуются данные аутентификации, иначе запрос можно перенаправить к ложному авторизатору.

В варианте с двумя серверами один знает сервис, другой распоряжается ресурсом. Сам запрос между ними, ответ и локальное условие доверия становятся доказательствами. В non-associated model общей истории может не быть, поэтому токен приносит больше данных для автономного решения.

Одна надпись «token valid» не показывает, где жило состояние, какая связь доверия сработала и что потерялось при отказе.

Подпись подтверждает происхождение, а не юрисдикцию

AUTHENTICATION_DATA защищает предшествующие данные. Историческая спецификация описывает общий ключ, Kerberos и открытый ключ; для последнего требуются обработка цепочки сертификатов, отзыв и проверка подписи.

Затем маршрутизатор или Policy Decision Point обязан обратиться к локальным policy-таблицам. Их содержимое — местное дело. Дополнительные сведения для решения тоже следует получать безопасно.

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

Перечисленные в 2003 году алгоритмы следует читать как часть исторического механизма, а не как современный совет по криптографическому развёртыванию.

Семантика находится внутри полей

AUTH_SESSION может содержать авторизующую сторону, идентификатор сеанса, адреса источника и назначения, время начала и конца, ресурс и данные аутентификации. Ресурс выражается предельной полосой, RSVP flow spec, SDP-описанием медиа или DSCP.

В non-associated model все поля должны совпасть с запросом. Адреса датаграммы должны соответствовать разрешённым, а запрошенное QoS не может превышать предел. Несовпадение ведёт к отказу даже при безупречной подписи.

Отсутствие списка портов тоже имеет смысл. Если списка для стороны нет, правила считают допустимыми все её порты. Если список есть, допустимы только перечисленные. Журналу нужны исходное значение или отсутствие, правило нормализации, наблюдаемый запрос и результат сравнения.

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

Защита от повтора зависит от времени или памяти

При создании элемента требуется START_TIME либо SESSION_ID. Время начала связывает безопасность с источником часов, смещением и окном приёма. В non-associated model policy server должен поддерживать NTP-синхронизацию; RFC предупреждает, что несогласованные часы могут разрешить replay.

Идентификатор переносит зависимость в состояние: когда создан, использован ли, дошла ли запись до реплик, уцелела ли после перезапуска. При повторной отправке тех же байтов подпись остаётся верной. Криптография не помнит первый показ.

В квитанции нужны источник времени, измеренное смещение, окно и решение replay-cache либо создание, прежнее использование и долговечная репликация идентификатора. RFC 5905 даёт более поздний контекст NTP, но не свидетельство о конкретной системе.

Не каждый узел обязан понять policy-объект

Policy-aware RSVP-маршрутизатор отправляет сообщение PDP и ждёт ответа. Policy-unaware маршрутизатор игнорирует объекты policy-data и продолжает обработку. Наличие AUTH_SESSION на пути не доказывает исполнение на каждом переходе.

Нужно указать PEP, соответствующие PDP, узлы, проигнорировавшие объект, и фактически установленное состояние резервирования. Маршрут токена и область принуждения — разные факты топологии.

Если PDP не может проверить элемент, RFC 3520 требует Policy Control Failure, Error Code 02, и рекомендует подробность в AUTH_DATA. Этот код доказывает конкретный отказ проверки. Его отсутствие не доказывает одобрение локальной политикой, наличие ресурса, завершённый путь или рабочее приложение.

Резервирование не является результатом сеанса

RFC 3521 рисует поэтапный процесс. Управление сеансом может сообщить о завершении либо ходе настройки и выдать токен. Хост посылает PATH. Пограничный узел обращается к policy server, который может изменить ресурс. Затем RESV сообщает, что резервирование завершено либо ещё продолжается.

RFC 3312 отдельно ведёт desired status и current status для QoS-предусловий SIP. Пока обязательное условие не выполнено, установление сеанса приостановлено и медиа не должно идти. Событие ресурса способно обновить current status, но не заменяет продолжение сигнализации, наблюдение трафика и итог приложения.

Зарезервированная очередь — не декодированный голос. Допуск — не согласие пользователя. Ответ SIP — не доказательство устойчивой услуги. Последняя квитанция должна совпадать с обещанным результатом.

Цепочка, которую можно восстановить после сбоя

Сохраняются исходный запрос, аутентифицированный актор и представляемый им субъект. Фиксируются идентичность авторизатора, область власти, версия решения, сохранённое состояние и hash точных байтов; затем ключ, сертификат, отзыв и replay-решение.

Источник, назначение, порты, предел ресурса и срок сравниваются между токеном и запросом. Любое изменение PDP остаётся видимым. Записываются решавший PDP, исполнявший PEP и игнорировавшие узлы; PATH, RESV и ошибки получают общую корреляцию.

В конце добавляются desired/current состояния SIP, наблюдаемый транспорт и аутентифицированное подтверждение приложения. Система биллинга должна назвать квитанцию, которая означает «завершено».

После failover новый сервер не должен принять replay из-за утраченной истории. Скачок часов не должен молча расширить срок, а новый маршрут — сохранить слово «admitted» за пределами известного исполнения.

Граница доказательств

Статья не называет продукт, поставщика, оператора, маршрутизатор, policy server, клиента, пользователя, сеанс, поток, инцидент или внедрение. Она не утверждает текущее использование, соответствие, безопасность, производительность, QoS или деловой результат какой-либо реальной системы.

RFC 3520 рассматривается как документ Standards Track апреля 2003 года с текущим статусом Proposed Standard. RFC 3521, 3313 и 5866 сохраняют собственные статусы и рамки. Специализированная административная область RFC 3313 не обобщается на публичный интернет. Более поздние NTP и Diameter используются только для сравнения.

Тексты Heng Lu об авторитете и running code — заявленные редакционные линзы, помогающие отделять формальное утверждение от наблюдаемого управления. Они не служат источником намерений IETF.

Вывод узок: токен может быть подлинным, свежим, совпавшим и допущенным, а результат сеанса всё ещё не доказан.

Источники