Кратко

  • RFC 1492 опубликован в июле 1993 года со статусом Informational: автор не смог получить существовавшую исходную спецификацию TACACS из-за вопросов авторского права.
  • Простая реализация Cisco считалась совместимой с оригиналом, но сравнение не проводилось; RFC прямо допускал, что найденный позже текст выявит ошибки реконструкции.
  • Nonce связывал UDP-ответ с запросом, а решение daemon, действие терминального сервера, соединение с целью и учёт оставались отдельными свидетельствами.

Управлять данными и алгоритмами решения — значит обладать реальной операционной властью. Оператор мог выбрать парольную базу, правила и условия отказа. Но формат сообщения не делал эти правила общими для всех. Два daemon могли правильно обмениваться одинаковыми полями и давать разные ответы на похожие запросы.

Та же дисциплина нужна для происхождения самого протокола. RFC 1492 сообщает, что оригинальная спецификация TACACS существовала, однако автор не смог получить её из-за вопросов авторского права. Это было главной причиной написания нового документа. В сотрудничестве с Cisco Systems использовали простую реализацию, которая считалась совместимой с оригиналом.

«Считалась» — граница доказательства. Исполняемый код показывает ветви и ответы при наблюдаемых входах. Он не сообщает, является ли поведение исходным замыслом, расширением продукта, пропуском или старой ошибкой. Поэтому RFC предупредил: если оригинальная спецификация будет найдена, некоторые части реконструкции могут оказаться неверными.

Статус Informational закрепляет ещё одну границу. Документ не определял Internet Standard. Он сделал рабочее описание публичным, не присвоив реализации Cisco всемирную нормативную силу.

Простая и расширенная версии имели разное происхождение

RFC разделял simple и extended TACACS. Предполагаемая совместимость с оригиналом относилась к простой реализации Cisco. Компания поддерживала и расширенную форму; её использовали терминальные серверы Cisco и распределённая система аутентификации Университета Миннесоты. Это конкретные свидетельства эксплуатации, а не статистика распространения или доказательство единой версии у всех участников.

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

LOGIN и CONNECT не были одним разрешением

Клиент посылал запрос, daemon обязан был ответить и мог отказать. LOGIN передавал учётные данные; положительный результат позволял терминальному серверу начать login-соединение. CONNECT выполнялся внутри уже существующего соединения и спрашивал, можно ли открыть TCP-соединение к конкретному адресу и порту назначения.

Успешный LOGIN не давал бессрочного разрешения на любое направление. Положительный CONNECT не доказывал, что терминальный сервер выполнил решение, сеть доставила попытку, а цель приняла соединение. Последующая запись accounting, если она существовала, была ещё одним событием.

Ответ daemon свидетельствовал лишь о локальном вычислении по локальным данным. Для полного утверждения нужны отдельные квитанции транспорта, исполнения и внешнего эффекта.

Nonce отвечал за корреляцию, не за подлинность

Историческая UDP-кодировка использовала порт 49. Клиент помещал nonce в запрос, сервер копировал его в ответ. Так полученная datagram сопоставлялась с ожидающим запросом. Совпадение не аутентифицировало пользователя или сервер, не обеспечивало целостность и не скрывало содержимое.

После timeout клиент мог повторить запрос; сервер не делал повторов. RFC заметил противоречие: схема как будто предполагала idempotent-запросы, хотя на деле запросы не были идемпотентными. Первый ответ мог потеряться после изменения состояния более крупного соединения. Поэтому одинаковые пакеты нельзя автоматически свести к одной безопасной операции без времени, состояния, причины повтора и журнала терминального сервера.

Открытый пароль оставался открытым и в TCP

И UDP-, и TCP-кодировка переносили имя пользователя и пароль открытым текстом. Раздел безопасности предупреждал, что наблюдатель сети способен собирать такие пары, а служба создаёт поверхность для проверки учётных данных. Поздний ACCEPT не защищает уже переданный запрос.

TCP-кодировка решала доставку и кадрирование. Она была явно несовместима с историческим TACACS, выбирала более простую структуру, доставку средствами TCP и большее пространство ответа. Упорядоченные байты не устанавливают подлинность сторон, не дают конфиденциальность и не подтверждают исполнение решения.

TACACS+ — позднее сравнение, не обратная редакция

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

Более ранний RFC 927 относился к передаче TELNET-идентификатора TUID. Собственная тема RFC 1492 — реконструкция daemon-протокола между недоступным исходным текстом и доступной реализацией поставщика.

Документ ценен тем, что не смешал полезность и окончательность. Хранение источника, поведение программы, опубликованное описание, доставка запроса, локальное решение, действие устройства и итог в мире имеют разные полномочия.

Источники