Кратко

  • DASS должна была сохранять контекст пользователя при переходе от входного узла к удалённой службе и далее к следующему ресурсу.
  • RFC 1507 связывал учётные данные с процессами и допускал делегирование, однако ограничивал его главным образом сроком действия, а не набором прав для конкретной задачи.
  • Документ 1993 года имеет статус Experimental. Он фиксирует проект архитектуры, но не подтверждает масштаб её реального применения.

Запрос, который проходит через несколько служб

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

Такую задачу описывает RFC 1507, опубликованный в сентябре 1993 года. Distributed Authentication Security Service (DASS) должен был переносить подтверждение личности вместе с работой пользователя. При входе операционная система создавала набор учётных данных и связывала его с процессами, запущенными пользователем или от его имени. Удалённая система, принимавшая делегирование, должна была запустить следующий процесс уже с переданными данными.

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

Человек и узел выступали разными субъектами

DASS называла субъектами (principals) и пользователей, и машины. У типового набора учётных данных могли быть два набора секретов: пользователя и узла. Оба могли подписать один запрос. Получатель проверял, кто просит услугу и с какого компьютера пришёл запрос.

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

RFC исходил из того, что локальные имена не совпадают автоматически. У человека с учётными записями на десяти машинах могло быть десять локальных идентификаторов. DASS предлагала глобальное имя, узнаваемое на разных узлах, но не объявляла локальные аккаунты ненужными. Хост всё ещё должен был сопоставлять сетевого пользователя с местной записью. В качестве переходного варианта упоминались правила, похожие на .rhosts, только уже на основе глобального имени.

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

Делегированная возможность не была узкой по назначению

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

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

Первый вход оставался отдельной проблемой. Пока не было смарт-карт, пароль пользователя всё ещё мог быть перехвачен на пути к узлу входа. Архитектура хотела, чтобы после этого первого участка пароль не появлялся в сети. Смарт-карта могла бы хранить закрытый ключ и подписывать начало сеанса. Это описанная возможность, а не свидетельство, что такие карты или DASS широко использовались.

Имена и ключи зависели от дерева доверия

Передача делегированных данных имеет смысл лишь в том случае, если получатель знает, какой ключ связан с глобальным именем. DASS использовала сертификаты, подписанные центрами сертификации (CA), и привязала CA к иерархии имён X.500. Каждый центр отвечал за каталог своего уровня; сертификаты родителей, дочерних каталогов и перекрёстные сертификаты соединяли ветви дерева.

По замыслу это ограничивало последствия компрометации. CA могла подменить имена в своём каталоге; нижний уровень затрагивал более узкий участок дерева, а верхний — более широкий круг доверительных связей. Перекрёстный сертификат позволял соединять отдельные «острова» имён, не требуя, чтобы одна мировая организация выдавала все сертификаты.

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

Отзыв и время оставались частями той же цепочки

RFC описывал два способа отозвать сертификат. Первый — срок действия и обновление. Для обычного использования предполагался срок около года; обновления могли происходить раз в несколько месяцев, чтобы не перегружать CA и пользователей. После компрометации ключа ожидание истечения сертификата было медленным ответом.

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

Против повторного использования сообщений DASS применяла временные метки. Сервер отклонял слишком старые запросы и запоминал уже принятые в пределах временного окна. Вызов не требовал дополнительного обмена вызовом и ответом, но нуждался в монотонном времени, синхронизированном между узлами с точностью до минут. Большое расхождение могло отвергнуть законный запрос; перевод часов назад мог вновь сделать старое сообщение приемлемым. Для проверки сроков сертификатов допускалось более грубое расхождение, в пределах часов.

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

Экспериментальный статус — граница исторического вывода

RFC 1507 прямо обозначен как Experimental и говорит, что не устанавливает стандарт Интернета. В приложении описана поддержка Generic Security Service API. RFC 1508 отдельно определяет общий интерфейс, независимый от конкретного механизма; RFC 1509 задаёт привязки для C. RFC 1510 того же периода описывает Kerberos V5 с центром распределения ключей. Позднее RFC 1704 рассматривает несколько механизмов аутентификации.

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

Замысел DASS заключался в том, чтобы пользовательская идентичность переходила между службами вместе с процессами. Делегирование делало это возможным, а глобальное имя уменьшало зависимость от набора локальных аккаунтов. Цена состояла в передаче временной способности действовать от имени пользователя и в зависимости от ОС, CA, каталога и правил получателя. Архитектура помогает увидеть эти границы; сведений о её реальном масштабе она не даёт.

Источники