Кратко

  • RFC 1510 описала межrealm-аутентификацию через ключи и билеты TGT. При прямом переходе transited пуст: инженер восстанавливает обе стороны пути по отдельным полям билета.
  • RFC 4120 возложила последнюю проверку на сервер приложения: при отсутствии отметки KDC он сам проверяет участников пути или отклоняет билет.

Разбор

Оба конца пути записаны отдельно

Возьмём схематичный пример: пользователь зарегистрирован в ALPHA.EXAMPLE и запрашивает билет для файловой службы в BETA.EXAMPLE. Если realm разделяют нужный межrealm-ключ и между ними нет третьего realm, поле transited может быть пустым. Другие поля билета указывают оба конца; пустое значение фиксирует прямой переход без посредника.

transited кратко перечисляет промежуточные realm. Конечные realm записаны отдельно, поэтому при прямом переходе средняя часть остаётся пустой.

RFC 1510 описывает realm как административную область со своей службой Kerberos. Realm входит в имя субъекта, а принимающая служба может учитывать его, решая, обслуживать ли запрос. Чтобы пересекать границу realm, администраторы устанавливают межrealm-ключ; для каждого направления можно использовать отдельный ключ. Удалённый realm регистрирует службу выдачи билетов соседнего realm как субъект. Его KDC расшифровывает билет партнёра с помощью общего ключа.

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

Промежуточные realm перечислены без очередности

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

RFC 1510 хранит промежуточные realm как неупорядоченное множество и сжимает распространённые иерархические имена. Порядок переходов остаётся за пределами поля; для хронологии оператору нужен отдельный журнал.

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

В июле 2005 года RFC 4120 заменила RFC 1510 и закрепила последнее решение за сервером приложения: он принимает или отклоняет аутентификацию. KDC целевого realm может проверить путь по местной политике и поставить TRANSITED-POLICY-CHECKED. Если отметки нет, приложение само проверяет доверие к участвовавшим KDC или отклоняет билет. RFC 4120 отдельно предупреждает, что недоверенный KDC способен подделать список, даже перечислив в нём известные доверенные KDC.

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

В сентябре 1993 года RFC 1510 сообщала, что протокол ещё рассматривается и тогда не предлагался к стандартизации Интернета. RFC 4120 вошла в Standards Track в 2005 году и точнее описала обязанности реализации. Не хватает журнала внедрения за 1990-е, который показал бы, какие серверы приложений проверяли transited; он позволил бы судить о работе контроля в реальных системах, тогда как RFC фиксируют проект протокола.

Источники