Кратко

  • RFC 1509 определила gss_cred_id_t как атомарное, непрозрачное для вызывающей стороны значение. Реальные учётные данные оставались внутри GSS-API, а одинаковое значение дескриптора у разных вызывающих сторон могло разрешаться по-разному.
  • Область действия могла ограничиваться процессом, охватывать его потомков либо процессы с общей локальной идентификацией вроде UID. GSS_C_NO_CREDENTIAL могло означать запрос на выбор стандартных учётных данных, а не отсутствие principal.
  • Дескриптор, credential, внутреннее имя, контекст безопасности, передаваемый token и решение приложения о доступе были разными свидетельствами. Их нельзя было заменить одним сохранённым значением.

Совпадение начиналось слишком поздно

Предположим, две строки аудита содержат handle 7. Первая появилась у демона до перезапуска, вторая — у дочернего процесса после него. Сравнение значений даёт точный ответ на узкий вопрос: представления равны. Но вопрос о том, какие учётные данные использовались, начинается раньше — с того, кто и у какой локальной системы просил разрешить значение.

RFC 1509 допускала реализацию gss_cred_id_t арифметическим или указательным типом. Для приложения это был непрозрачный атомарный объект. Спецификация отдельно предупреждала, что одна и та же величина может ссылаться на разные credentials, если её предъявляют разные callers.

Конкретная реализация могла сделать дескриптор доступным только процессу, который его получил. Могла распространить его на дочерние процессы. Могла считать общим для процессов с одной локальной идентичностью, например UID. На другом хосте значение могло не разрешиться вовсе.

Полное отношение выглядело так:

вызывающая сторона + эпоха локальной реализации + значение + механизм → credential

Если не записаны первые два элемента, число нельзя превратить в долговечное свидетельство. Оно может остаться прежним после освобождения внутренней ячейки и появления в ней нового объекта. Равенство битов не переносит прежний namespace в настоящее.

Настоящие учётные данные не выдавались приложению

Credential описывал principal и позволял действовать от его имени. Однако приложение получало не обязательно ключи, tickets или структуры конкретного механизма. Оно получало ссылку на состояние, которым управляла GSS-API либо нижележащий механизм.

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

Поэтому RFC 1509 могла сказать, что сам handle не содержит информации, связанной с безопасностью, и не требует особой защиты в приложении. Это не означало, что credential несекретен или что копия handle передаёт полномочие. Защитный рубеж находился у resolver: операционная система и механизм решали, какой caller вправе использовать состояние за ссылкой.

RFC 1508 прямо относила ограничение получения и использования credentials к системным средствам. Возможность применить credential некоторого principal означала возможность заявить его идентичность. Переносимость между процессами оставалась локальным свойством, а не универсальной гарантией общего API.

Пустой аргумент выбирал непустую идентичность

Константа GSS_C_NO_CREDENTIAL выглядела как отсутствие. При установлении контекста она могла просить реализацию использовать credential по умолчанию. Приложение не называло его явно, но механизм всё равно мог выбрать principal.

RFC 1509 оставила способ создания и область действия default credential реализации. RFC 2078, опираясь на опыт первых реализаций, перечислила более конкретные варианты: единственный principal, разрешённый приложению; стандартная сетевая идентичность; сетевое отображение локальной идентичности; пользовательская настройка. Невозможность найти подходящий вариант имела собственный путь ошибки.

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

Запись «credential не передан» фиксирует синтаксис запроса, но ничего не доказывает об итоговой идентичности. Нужны признак default resolution, использованная policy, выбранный principal, механизм, назначение initiator или acceptor и срок действия.

У ссылки было два срока жизни

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

Поэтому время дескриптора состояло как минимум из двух часов: срока самого credential и эпохи resolver. Метка времени без идентификатора инстанса не закрывает разрыв перезапуска. Имя процесса без эпохи не доказывает, что его внутреннее состояние осталось тем же.

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

Контекст безопасности жил отдельно от соединения

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

Сам security context не равнялся транспортному соединению. Сеанс связи мог проходить через несколько соединений; несколько контекстов могли по очереди или одновременно существовать в одной коммуникационной ассоциации. Номер socket не доказывал, какой контекст защитил сообщение. Установленный контекст не доказывал, что каждое сообщение действительно получило confidentiality или integrity.

Приложение отвечало за перенос tokens, их правильную привязку, чтение major status и статуса механизма, сравнение запрошенных и возвращённых флагов. После этого оно принимало отдельное решение о том, что аутентифицированному peer разрешено сделать.

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

Для переноса состояния понадобился другой артефакт

Authentication token тоже был непрозрачен для приложения, но его назначение отличалось. Механизм на одном конце создавал битовую строку, приложение доставляло её, механизм peer обрабатывал. Token имел протокольный путь через границу; локальный handle — нет.

Channel bindings связывали типы адресов, адреса и прикладные данные с установлением контекста. Если стороны подавали несовпадающие значения, мог появиться GSS_S_BAD_BINDINGS. Такой результат подтверждал согласие входов, но не все физические, административные или юридические свойства канала. RFC 1509 также предупреждала не включать конфиденциальные данные, поскольку некоторые механизмы могли поместить bindings в token.

Поздняя C-привязка RFC 2744 показала, как выглядит реальное перемещение контекста между процессами. gss_export_sec_context деактивировала контекст в исходном процессе и выпускала межпроцессный token; gss_import_sec_context восстанавливала его в целевом. Активным должен был оставаться один экземпляр, а локальная policy могла ограничивать получателя общей учётной записью или группой процессов.

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

Отображаемое имя было ещё одной проекцией

RFC 1509 разделяла printable names для людей и внутренние имена для API. Видимая форма могла зависеть от локальной настройки или предпочтения пользователя. Object identifier обозначал namespace, а внутреннее представление сохраняло тип, чтобы реализация не смешивала несовместимые пространства имён.

Импортировать, отображать и сравнивать имена следовало операциями GSS-API. Равенство строк не было универсальным правилом идентичности. RFC 2744 позднее подчеркнула, что display импортированного внутреннего имени не обязан возвращать исходную строку. DNS-форма могла быть преобразована в X.500 и показана в новом виде.

Знакомая надпись на экране поэтому не доказывала внутренний principal, механизм, локальное отображение на аккаунт или прикладную авторизацию. Одинаковые строки могли принадлежать разным namespaces; разные строки могли быть проекциями одного внутреннего объекта.

Человеческое имя необходимо интерфейсу, но оно отвечает на вопрос о представлении. Криптографическая идентичность и право на действие отвечают на другие вопросы и требуют других receipts.

Общим стал способ обратиться к локальной власти

RFC 1511 описывала замысел рабочей группы Common Authentication Technology как разделение труда. Специалисты по безопасности создают повторно используемые механизмы; авторы протоколов подключают общий интерфейс. RFC 1508 задала независимую от языка модель, RFC 1509 — её конкретные C-типы и вызовы.

Общими стали операции, а не все правила хранения credentials. Опека над ключами, права процессов, principal по умолчанию, преобразование имён и область действия handles остались локальными. RFC 2078 пересмотрела абстрактный API после опыта реализации; RFC 2743 и RFC 2744 затем заменили ранние документы версией 2 Update 1 и её C-привязкой.

Последующие спецификации добавили функции и точность, но сохранили основную границу: само использование GSS-API не даёт определённого уровня assurance. Он зависит от механизма и от того, какие услуги запросил caller, какие получил и как обработал результаты.

Узкий общий контракт был способом координации, а не недостатком. Минимальная исходная спецификация оставляла будущие решения платформам и позволяла добровольное внедрение. Однако локальный посредник получал значительную власть — выбирать default principal, разрешать handle и сопоставлять имя. Её нельзя стирать из операционной истории.

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

Источники доказывают опубликованный контракт и его преемственность. Они показывают, что RFC 1509 сознательно допустила зависящий от caller смысл одного handle, отделила handles от credentials и transport tokens и оставила существенные меры контроля локальной реализации. Поздние RFC уточнили defaults, имена и явный перенос contexts.

Они не доказывают, как конкретная библиотека представляла таблицы, какой scope выбрала конкретная ОС, корректно ли приложение проверяло результаты и произошла ли уязвимость. Статус Proposed Standard — это состояние документа, а не статистика внедрения или receipt работающей системы.

Но архитектурный вывод определён. Уже в 1993 году общий security API не позволял приравнять одинаковый маленький reference к одинаковому полномочию. Для атрибуции нужны caller, локальный resolver и его эпоха, mechanism, principal, context, прикладное решение и наблюдаемый эффект. Одинокое число сохранило слишком мало реальности.

Источники