Кратко

  • RFC 927 предложил опцию Telnet 26 TUID: хост, уже аутентифицировавший пользователя, мог передать согласному получателю его 32-битный двоичный идентификатор.
  • До передачи требовалось согласование WILL TUID и DO TUID; команды WON'T и DON'T делали отказ штатным результатом протокола.
  • Четыре октета называли пользователя, заявленного источником. Они не доказывали проверку пароля, не давали разрешений на целевом хосте и не подтверждали действие приложения.

В декабре 1984 года Brian A. Anderson из BBN опубликовал RFC 927TACACS User Identification Telnet Option. Задача была практической. Пользователь уже сообщил имя и пароль Terminal Access Controller, или TAC, но после открытия Telnet-соединения к нужному хосту мог получить ещё одно приглашение ко входу.

Предложенная опция называлась TUID и получила код 26. Telnet на стороне пользователя сообщал о готовности аутентифицировать человека и передать его UUID. Серверная сторона сообщала о готовности принять эту аутентификацию. После согласия передавалось 32-битное двоичное число.

Пароль не превращался в короткий номер. Источник свидетельствовал о проверке, выполненной у себя. Получатель решал, достаточно ли такого свидетельства для его собственной системы.

Вместо второго секрета появилась зависимость от первого хоста

RFC 927 объясняет, что TACACS требовал правильную пару имя/пароль до соединения через TAC. Чтобы не повторять аутентификацию на целевом хосте, TAC мог передать названную в документе «доказанную личность» пользователя — его UUID.

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

Спецификация тут же ограничивала силу утверждения. Хосты могли принять аутентификацию TAC или не принять её по своему выбору. Источник распоряжался своей проверкой; цель продолжала распоряжаться доступом к своей службе.

Сначала согласие, затем значение

RFC 854 построил дополнительные возможности Telnet на командах WILL, DO, WON'T и DON'T. Стороны могли предложить, запросить, принять или отвергнуть режим сверх базового Network Virtual Terminal. RFC 855 установил порядок для параметров: сначала оба конца соглашаются использовать опцию, затем начинается подпереговорный обмен значениями.

В TUID команда IAC WILL TUID означала, что пользовательская сторона берётся аутентифицировать пользователя и послать идентификатор. IAC DO TUID означала, что серверная сторона хочет получить его и согласна принять аутентификацию собеседника. WON'T отказывался от роли источника, DON'T — от доверия цели.

Только после этого строка IAC SB TUID <uuid> IAC SE несла четыре октета. Первым мог обратиться сервер, а могла сначала предложить пользовательская сторона. Но значение не заменяло согласование.

По умолчанию действовал отказ. Не знавший TUID пользовательский Telnet отвечал WON'T, не знавший его сервер — DON'T. Отсутствие поддержки не становилось молчаливым доверием: соединение оставалось обычным Telnet, а цель могла провести локальный вход.

UUID в этом документе имел 32 бита

Современное слово UUID обычно вызывает представление о 128-битном формате. RFC 927 определяет <uuid> как 32-битное двоичное число. Примеры помещают значения 1, 255 и все единичные биты прямо в подпереговорный поток.

В Telnet октет 255 обозначает IAC, поэтому внутри параметра его следовало удваивать. Число 255 передавалось тремя нулевыми октетами и парой IAC IAC. Это правило прозрачности данных, а не шифрование и не подпись.

Документ не определял глобального распределителя, срок жизни, предотвращение коллизий, повторное использование, nonce, отметку времени, защиту от воспроизведения или привязку к каналу. Не был определён и способ сопоставления с локальной учётной записью. Правильная длина не делала номер универсальной истиной.

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

Признать пользователя — не значит разрешить действие

Принятие исходной аутентификации отвечало на узкий вопрос: кого, по утверждению доверенного хоста, представляет соединение? RFC 927 не давал этому человеку прав на файлы, команды, привилегированный режим или результат приложения.

Поздний RFC 1492, информационная реконструкция TACACS 1993 года, помогает увидеть границу. В нём клиент посылает daemon имя и пароль, а хост решает принять или отвергнуть запрос. Отдельный CONNECT в уже существующем контексте входа спрашивает, можно ли открыть соединение к конкретному адресу и порту.

У источника есть важное ограничение. Автор не смог получить первоначальную спецификацию TACACS из-за авторских прав и предупредил, что последующие сведения могут выявить ошибки. Эту неопределённость нельзя вычеркивать из исторического вывода.

RFC 8907 описывает гораздо более поздний TACACS+. Он разделяет аутентификацию, авторизацию и учёт и отмечает, что протокол не связывает запрос аутентификации с запросом авторизации. Это не обратное описание TUID, а удобный язык для постоянного различия: заявленная личность и разрешённое действие — не одно событие.

Возможность отказать тоже была совместимостью

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

Реестр опций Telnet IANA по-прежнему закрепляет код 26 за TACACS User Identification со ссылкой на RFC 927. Реестр доказывает назначение параметра, но не распространённость внедрения и не нынешнее использование.

Команда DON'T TUID не разрушала совместимость. Она выражала предел сотрудничества. Пока цель могла сказать «нет», удобство источника не превращалось в власть над чужой системой.

Чем проще экран, тем подробнее должна быть история решения

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

Запись «вход успешен» стирает эти решения. Она не говорит, проверялся ли локальный пароль, принимался ли TUID, какой аккаунт был выбран, разрешалась ли команда или только открывался транспорт. Удобство интерфейса не оправдывает бедность доказательств.

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

RFC 927 не решил задачу всеобщей цифровой идентичности. Он показал меньшую и честную сделку: повтор исчезал, когда один хост отвечал за собственную проверку, а другой добровольно принимал его слово. UUID пересекал соединение. Ответственность за доверие оставалась у цели.

Источники и пределы

Материал опирается на RFC 854, 855 и 927, реестр IANA и ограниченные поздние сравнения из RFC 1492 и 8907. Они устанавливают синтаксис, заявленную мотивацию, назначение кода и последующие различия. Они не доказывают массового внедрения, криптографической защиты, прямого происхождения современной федерации или успеха реальной сессии.