Кратко

  • Принявший соединение сервер открывал второе TCP-соединение в обратном направлении к порту 113. Адреса нового соединения и пара портов исходного, записанная с точки зрения отвечающего хоста, указывали на локальное состояние.
  • В 1984 году механизм назывался Authentication Service, в 1985-м — Authentication Server Protocol, а в 1993-м — Identification Protocol. Переименование сузило обещание до реальной функции.
  • RFC 1413 разрешал использовать USERID для аудита, но запрещал считать его идентификатором управления доступом. HIDDEN-USER, NO-USER и UNKNOWN-ERROR показывали зависимость результата от чужой системы и политики.

Что на самом деле означал ответ alice

Пусть A устанавливает TCP-соединение со своего локального порта 6191 на порт 23 хоста B. B видит адреса и порты, но не знает, какой локальной учётной записи операционная система A приписала соединение. B открывает отдельное соединение на TCP 113 хоста A и отправляет 6191, 23.

Порядок задаётся с точки зрения отвечающего A: сначала его локальный порт, затем удалённый. B видел исходное соединение наоборот. Запрос 23, 6191 относится к другой записи.

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

Ответ USERID повторяет порты, содержит тип ОС и строку идентификатора. Может быть указан набор символов. Значение OTHER позволяет вернуть непрозрачный токен, а не обычное имя. Получатель не вправе автоматически считать его Unix-аккаунтом, всемирно уникальным человеком или постоянной кадровой записью.

Сильное слово в раннем названии

RFC 912 в сентябре 1984 года описал Authentication Service на порту 113. Предлагалось, например, чтобы FTP-сервер сравнивал имя из прикладного диалога с пользователем, которому удалённый хост приписывал TCP-соединение. Рассматривались и привилегированные действия.

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

В январе 1985 года RFC 931 формализовал Authentication Server Protocol. Появились запрос пары портов, ответы USERID и ERROR, поле OPSYS и идеи локального отображения в права.

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

Переименование как исправление модели доверия

В феврале 1993 года рабочая группа IETF IDENT выпустила RFC 1413 вместо RFC 931. Название изменилось на Identification Protocol, чтобы точнее отражать функцию.

Раздел безопасности провёл границу: сведения могут быть полезны для аудита, но не должны служить идентификатором контроля доступа. Если B открывает ресурс после ответа A alice, A способен написать alice для любого соединения. Второй канал не добавил источника, независимого от A.

Identification означает лишь заявление A о связи потока с локальным идентификатором. Оно не аутентифицирует человека, не уравнивает учётные записи двух организаций и не разрешает действие.

В этой ограниченной роли ответ полезен. B сохраняет имя, время, адреса, порты и прикладное событие. Администратор A сопоставляет их с сеансами, процессами и локальными журналами. Запись помогает двум операторам найти один эпизод, но не выносит окончательного решения.

Направление и время сохраняют смысл

Разворот пары портов фиксирует роли сторон. Время фиксирует само соединение. Эфемерные порты используются повторно, поэтому пара без временной отметки может позже относиться к другому потоку. Проверяемая трасса требует обоих адресов, обоих портов, направления и времени исходного соединения, а также полного обмена IDENT.

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

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

Ошибка могла быть политикой конфиденциальности

INVALID-PORT означает неверный формат или диапазон. NO-USER сообщает, что пользователь для соединения не определён. HIDDEN-USER означает сознательный отказ раскрыть известное сопоставление. UNKNOWN-ERROR скрывает внутреннюю причину; закрытие до ответа трактуется так же.

NO-USER не доказывает анонимность. HIDDEN-USER не доказывает подозрительность. UNKNOWN-ERROR не доказывает отсутствие связи. Они описывают, что удалённая служба способна или согласна сообщить сейчас.

RFC 1413 сравнивал риск конфиденциальности с CallerID и Finger. Обычное локальное имя становится новым раскрытием, если любой сервер назначения может запросить его. Отключение службы, сокрытие отдельных пользователей или выдача токена — допустимые решения, каждое меняет ценность аудита.

Таблица не усилила доказательство

RFC 1414 определил MIB с индексами: локальный адрес и порт, удалённый адрес и порт. Та же четырёхчастная геометрия стала строкой управления с идентификатором и состоянием.

RFC 1414 теперь имеет статус Historic, RFC 1413 указан RFC Editor как Proposed Standard. Это не статистика современного использования. MIB повторяет, что сведения не авторитетны и не подходят для контроля доступа. Структура облегчает поиск заявления, но не делает его истинным.

Текущий реестр IANA имён служб и транспортных портов сохраняет ident и прежнее auth для TCP 113. Он координирует место встречи и историю названия, но не сертифицирует аккаунт, ОС, политику или ответ.

Полезное имя без права открыть дверь

Атрибуция спрашивает, какую локальную метку A связывает с потоком. Авторизация спрашивает, что B позволяет по собственным правилам и доказательствам. Одинаковая строка не объединяет полномочия.

IDENT ограничивал вопрос двумя хостами, двумя портами и моментом. Ошибки признавали незнание, HIDDEN-USER — секретность, правила безопасности — возможность лжи. В этих границах USERID дополняет хронологию. За их пределами удалённый хост чеканит слово, которое запускает привилегию.

Переход от Authentication к Identification не отказался от доказанной силы. Он убрал из названия силу, которой у обмена никогда не было.

Источники и границы доказательств

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