Кратко

  • Редакция 07 индивидуального Internet-Draft draft-howard-virp представлена 6 сентября 2026 года и датирована 7 сентября. Это не стандарт IETF, не документ, принятый рабочей группой, и не одобренная IETF архитектура.
  • Новый профиль External Authorization Binding оставляет шлюзу постоянную идентичность только для наблюдения. Команды записи разрешает служба, неподконтрольная шлюзу, а решение применяет само устройство.
  • Модель сопоставляет намерение и отчёт об исполнении со стороны шлюза, permit или deny внешней службы и командный учёт устройства. Пробелы получают отдельный статус и не превращаются автоматически в успех либо отказ.
  • Автор сообщает, что статическая покомандная политика и сверка с учётом устройства реализованы и испытаны на Cisco IOS и IOS-XE. Это первичное утверждение автора, не независимое воспроизведение и не доказательство массового развёртывания.
  • Самая важная динамическая часть отсутствует: ограниченный одобрением, сроком и однократным потреблением допуск к записи не реализован; решения внешней авторизации ещё не являются штатными записями цепочки.

Ограничение должно пережить захват шлюза

История Datatracker фиксирует загрузку, принятие и публикацию редакции 07 6 сентября. Текст от 7 сентября задаёт практический вопрос: если злоумышленник захватил шлюз, через который автономный агент просит изменить сеть, получил ли он одновременно постоянные реквизиты для изменения устройства?

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

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

Компоненты давно известны. RFC 8907 определяет покомандную авторизацию и accounting в TACACS+; административные учётные записи только для чтения обычны. Заявленный вклад VIRP состоит в композиции: автоматизированный запросчик становится ограниченным принципалом, чтение и запись используют разные идентичности, а рассказ шлюза сверяется со сведениями, возникшими вне него.

Институциональный статус нужно держать отдельно. Страница Datatracker называет документ индивидуальным Internet-Draft без RFC stream и Responsible AD. Там прямо сказано: такой текст может представить любой, он не одобрен IETF и не имеет формального положения в процессе стандартизации. Формат документа не создаёт мандат.

Четыре вида свидетельств не равны по происхождению

gate_intent/1 до обращения к устройству описывает намерение шлюза, а gate_execution/1 после действия — его собственный отчёт об исполнении. Оба обозначены как реализованные. device_accounting/1 создаётся устройством, поступает через независимо достижимый коллектор и включается в цепочку при получении; этот путь тоже отмечен как реализованный.

У authorization_decision/1 иной статус. Запись должна содержать решение внешней службы, устройство, принципала, каноническую команду или digest и время. Семантика задана, но эталонная реализация пока не добавляет запись в цепочку. Решение хранится в локальном журнале службы и прикладывается к проверочному набору как материал отдельного происхождения.

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

Для сверки нужны идентификатор устройства, идентичность принципала, точный digest канонической команды и заранее объявленное временное окно. Ненадёжные часы дают UNRESOLVED. Согласованные квалифицированные записи дают MATCHED; заявление только шлюза — GATE-ONLY; событие только устройства — DEVICE-ONLY; DENIED устанавливается решением авторизации, а не отсутствием учёта.

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

Учёт TACACS+ не всегда доказывает исполнение

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

Поэтому VIRP требует установить смысл учёта для каждого класса устройств: команда введена, авторизована, исполнена либо имеет неизвестную семантику исполнения. Классификацию исполнения могут поддерживать лишь записи, для которых подтверждено значение «исполнено».

Документ сообщает более узкое наблюдение на Cisco IOS и IOS-XE: в описанных испытаниях учёт соответствовал исполненной команде, а отклонение не создавало такую запись. Затем текст запрещает переносить это соответствие на другие платформы. Репозиторий VIRP ведёт тот же проект; он показывает заявленное состояние реализации, но не является независимой проверкой.

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

Одноразовый допуск подробно задан, но ещё не построен

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

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

Редакция 07 прямо называет этот approval-scoped grant нереализованным. По её словам, сегодня имеется статическая политика: идентичность для чтения, операторская идентичность и запрет всего остального, плюс сверка с устройством. Это способно уменьшить ущерб, но не равно короткоживущей способности, возникшей из одного одобрения и исчезнувшей после потребления.

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

Квитанция о хранении права записи

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

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

Эта квитанция — предложение Daniel Kade, а не требование VIRP, RFC 8907, RFC 9887 или IETF. Она не позволяет одному центральному интерфейсу одновременно присвоить власть службы авторизации и доказательную силу устройства.

Источники