Кратко

  • Запрос Ident указывал на одно соединение: порты сервера и клиента записывались так, как их видел опрашиваемый узел, который возвращал свой локальный идентификатор для этого сокета.
  • RFC 931 предлагал экспериментально использовать ответ при автоматическом входе в FTP. В 1993 году RFC 1413 назвал службу протоколом идентификации и уточнил: ответ может дополнить аудит, но не должен служить для аутентификации или контроля доступа.

Два числа с точки зрения одного узла

Пример из RFC 1413 сначала похож на исправление опечатки. На одном конце соединение записано как 23, 6191; чтобы спросить о нём другой конец, нужно отправить 6191, 23. Само соединение не изменилось. Изменилось лишь то, какой компьютер считает свой порт локальным, а какой — удалённым.

Эта перестановка была рабочим ключом протокола. Клиент Ident подключался к TCP-порту 113 на узле и отправлял строку вида <порт-на-сервере>, <порт-на-клиенте>. IP-адреса брались из TCP-соединения с самой службой Ident. Вместе с двумя портами они задавали уже существующее TCP-соединение. После этого сервер мог вернуть системно-зависимый идентификатор, который его собственная машина связывала с этим соединением.

Область запроса намеренно была узкой. Клиент не просил центральную службу найти человека во всём интернете; он спрашивал узел, какую строку пользователя локальная система связала с конкретным сокетом. Ответ USERID содержал имя операционной системы и идентификатор; ERROR мог сообщить, что владелец порта неизвестен. RFC 1413 также определил HIDDEN-USER: сервер смог определить пользователя, но не вернул сведения по его просьбе.

Это был не тот же интерфейс запроса, что у более ранней службы Name/Finger. Пустой запрос Finger мог попросить узел вывести список пользователей, находящихся в сети; Ident выбирал по паре портов одно TCP-соединение. Список присутствующих и строка владельца сокета отвечают на разные операционные вопросы. Предыдущая статья о Name/Finger рассматривает именно границу присутствия на одном узле.

«Authentication Server» был идеей для приложения

История начинается с RFC 912 Майка Сент-Джонса, опубликованного в сентябре 1984 года под названием «Authentication Service». Он предлагал службу на TCP-порту 113, которая могла вернуть идентификатор владельца конкретного TCP-соединения. Среди возможных применений назывались автоматическая идентификация пользователя в FTP и проверка привилегированных сетевых операций. Документ предупреждал, что доверие к разным узлам неодинаково, и оставлял приложениям решение о том, насколько доверять ответу.

RFC 931, опубликованный в январе 1985 года, заменил это предложение. В нём формат ответа был описан формальнее: сначала имя операционной системы, затем пользовательский идентификатор. Для FTP автор наметил вариант, при котором клиент отправляет команду USER без аргумента, а сервер обращается к службе аутентификации. RFC прямо называл такое применение экспериментальным и повторял предупреждение о доверии к узлам. Это документ о предложенной интеграции, а не свидетельство массового использования в FTP-серверах.

Важно разделять ответ протокола и решение приложения. Authentication Server сам по себе не проверял пароль независимо и не доказывал, кто сидит за терминалом. Он возвращал локальный идентификатор, который узел связывал с соединением. FTP-сервер мог решить воспользоваться этой строкой, но выбор и его последствия зависели от приложения и его отношений доверия с другим узлом.

В 1993 году новое имя обозначило границу

RFC 1413, опубликованный в феврале 1993 года, заменил RFC 931 и переименовал прежний Authentication Server Protocol в Identification Protocol, или Ident, «чтобы точнее отразить его функцию». TCP-порт 113 и связь запроса с конкретной парой портов сохранились. Документ также яснее описал несколько запросов в одном соединении Ident и такие ответы, как HIDDEN-USER.

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

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

Переименование поэтому обозначает важную историческую границу, но не доказывает, что все прежние варианты применения прекратились. RFC 1413 назвал службу идентификацией, а не аутентификацией, и ограничил выводы, которые можно делать из ответа. Эти RFC не сообщают, сколько сайтов запускали Ident, как часто пользователи скрывали идентификатор и какие FTP-программы зависели от этой службы. Стандарт фиксирует условия протокола, а не подсчитывает внедрения.

Что позволяет установить пара портов

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

История протокола строится на этом разделении. RFC 931 описывал один из возможных способов использования удалённой пользовательской строки приложением. RFC 1413 назвал службу по тому, что она действительно возвращала, и предостерёг от использования отчёта как основания для решения. Пара портов делала конкретное соединение видимым для обслуживающего его узла. Решение о доверии всё равно принимала система, которая выбирала, что делать с ответом.

Источники