Кратко

  • RFC 9887 выделяет TACACS+ поверх TLS в отдельную службу, требует TLS 1.3 и взаимную аутентификацию, запрещает данные 0-RTT и возврат к соединению без TLS после отказа.
  • Старый и новый пути могут временно сосуществовать, но этот период считается небезопасным до завершения; доступность старого сервера не доказывает непрерывность защищённой службы.

Ключевая фраза миграции часто описывает не включение нового пути, а его отказ. RFC 9887 требует, чтобы клиент TACACS+ не возвращался к соединению без TLS, если защищённое соединение не установилось, в том числе во время перехода.

TACACS+ обслуживает администрирование устройств. RFC 8907 разделяет аутентификацию, авторизацию и учёт, однако старый механизм тела пакета является обфускацией. RFC 9887 заменяет его в защищённом варианте аутентификацией и шифрованием TLS.

Две службы должны оставаться разными

Сразу после TCP начинается TLS; обновление уже открытого слабого соединения запрещено. По умолчанию прежний TACACS+ использует TCP 49, а новая служба tacacss — TCP 300, что фиксирует реестр IANA. Рекомендуются и отдельные хосты.

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

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

Аутентификация канала не выдаёт права пользователю

Минимумом является TLS 1.3. Текущая спецификация — RFC 9846, рекомендации по эксплуатации — RFC 9325. Реализации поддерживают взаимную аутентификацию сертификатами.

Каждая сторона проверяет цепочку и отзыв по профилю X.509, а идентичность службы — по RFC 9525. Успех подтверждает узел TLS. Локальная политика может добавить ограничения, после чего TACACS+ отдельно решает, что разрешено пользователю или команде.

Действительный сертификат не является авторизацией команды. Завершённое рукопожатие не является учётной записью. Положительный ответ не доказывает выполнение и конечное состояние. Запрещены и ранние данные: стороны не включают early_data, сервер отключает клиента с 0-RTT. Билет возобновления не разрешает преждевременный ввод AAA.

Отказ не переписывает правило

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

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

Сосуществование ещё не завершение

RFC 9887 допускает переходное сосуществование, но считает фазу небезопасной до конца и требует сокращать время двойной конфигурации. Девяносто процентов мигрированных клиентов не означают девяносто процентов безопасности. Слабый путь всё ещё способен принять чувствительный трафик, а его использование можно попытаться вызвать отказом TLS.

Завершение доказывается тем, что мигрированные клиенты не возвращаются на порт 49, а старые серверы изолированы для явной группы. SNI виден в начальном сообщении, wildcard-сертификат расширяет область общей ошибки, обнаружение службы остаётся вне RFC. Это входные данные местного управления, не автоматическое доказательство институциональной власти.

Источники