Кратко

  • RFC 9918 сохраняет взаимную аутентификацию X.509 для NETCONF поверх TLS и предупреждает: доверенный для NETCONF центр сертификации должен выдавать сертификаты только сторонам, которым разрешён доступ к таким серверам.
  • Проверка цепочки, идентичность сервиса, упорядоченное сопоставление сертификата с пользователем, NACM, RPC, фиксация в хранилище и изменение устройства образуют разные уровни доказательств.
  • Полезный журнал отвечает не только на вопрос «прошёл ли TLS», но и воспроизводит путь от предъявленного сертификата до наблюдаемого результата.

Аудит NETCONF часто начинается с привычного вопроса: была ли TLS-сессия взаимно аутентифицирована? Для RFC 9918 это лишь первая строка проверки. Следующий вопрос сложнее: имел ли доверенный центр сертификации право выдавать сертификаты только администраторам NETCONF или обслуживал заодно другие приложения, сотрудников и устройства?

RFC 9918 обновляет транспорт NETCONF поверх TLS. В TLS 1.2 взаимная аутентификация остаётся обязательной. В TLS 1.3 она рекомендуется и считается предпочтительной, когда доступна. Early Data запрещены. Установление и завершение соединения, кадрирование сообщений, а также проверка идентичности клиента и сервера по-прежнему опираются на RFC 7589.

Главное операционное предупреждение касается области действия доверия. RFC 9918 рекомендует, чтобы центры сертификации в списке доверия выдавали сертификаты только сторонам, которым разрешён доступ к серверам NETCONF. Если тот же центр выпускает сертификаты и для других целей, такие сертификаты могут быть приняты ненадлежащим образом. Для этого не требуется взломать алгоритм или похитить закрытый ключ сервера: достаточно смешать две разные популяции получателей под одним корнем доверия.

RFC 5280 задаёт правила проверки пути X.509: подписи, сроки действия, ограничения, политики, доверенный якорь и доступные данные об отзыве. Эти проверки нужны, чтобы установить происхождение и допустимость цепочки. Однако они не создают локальное право выполнять операции управления сетью. Хранилище доверенных корней не является списком администраторов.

После проверки пути сервер NETCONF должен получить имя пользователя. RFC 7589 описывает упорядоченный список правил сопоставления. Правило может сравнить отпечаток конечного сертификата либо отпечаток доверенного центра, участвующего в цепочке. Затем оно возвращает заранее заданное имя или извлекает его из rfc822Name, dNSName, IP-адреса, первого поддерживаемого subjectAltName либо, в устаревшем и не рекомендуемом варианте, из Common Name.

Порядок правил влияет на полномочия. Широкое правило для центра сертификации, поставленное перед точным правилом для конечного сертификата, способно получить другое имя из того же криптографического материала. Если правило совпало, но не сформировало допустимое имя NETCONF, поиск продолжается; если ни одно правило не сработало, сессия завершается. RFC 7407 представляет эту поверхность в модели YANG. Значит, для расследования нужны версия списка, порядок и фактические значения правил, а не только отпечаток сертификата.

Минимальная доказательная запись включает отпечатки конечного сертификата и цепочки, время проверки, доверенный якорь, политики и состояние отзыва. Далее нужны номер совпавшего правила, объект совпадения — конечный сертификат или центр, тип преобразования, исходное поле и полученное имя пользователя. Формулировка «сертификат принят» стирает именно те решения, по которым можно установить реальную ширину доступа.

Полученное имя всё ещё не является разрешением на операцию. RFC 6241 требует, чтобы транспорт передал аутентифицированную идентичность, а сервер знал её полномочия и применял их в течение сессии. RFC 8341 задаёт отдельную поверхность NACM: пользователя, группы, операцию, целевые данные или действие и правила, действующие в момент начала обработки.

Поэтому корректный сертификат совместим с отказом в RPC. Один и тот же пользователь может читать состояние и не иметь права менять конфигурацию. Доказательство аутентификации не заимствует результат авторизации, а авторизация задним числом не меняет валидность цепочки. Раздельные записи позволяют объяснить как допуск, так и отказ.

Даже успешный <edit-config> ещё не доказывает изменение сети. Идентификатор сообщения связывает запрос и ответ. Выбор candidate или running, блокировки, проверка, commit или confirmed-commit и последующее чтение подтверждают состояние хранилища. Применение конфигурации устройством, изменение пересылки пакетов и итог для сервиса требуют самостоятельных наблюдений. Ответ <ok> не измеряет трафик.

Та же логика действует при проверке сервера. RFC 9525 требует, чтобы клиент сформировал допустимые опорные идентификаторы независимо от идентификаторов, предъявленных сервером, и затем искал совпадение. Валидность, отзыв и полномочие представлять сервис остаются отдельными вопросами. RFC 9325 содержит актуальные рекомендации TLS, а RFC 9846 объясняет более слабые свойства Early Data. Их запрет не позволяет отправить операции NETCONF до завершения аутентификации, но не сужает назначение многоцелевого центра сертификации.

IANA регистрирует службу netconf-tls на TCP-порту 6513 со ссылками на RFC 7589 и RFC 9918. Эта запись доказывает назначение имени и порта. Она не доказывает, что сервис слушает порт, что источник разрешён, что выбрана конкретная версия TLS, что сработало определённое правило сопоставления, что NACM разрешил запрос или что состояние сети изменилось.

Идея Heng Lu о минимальной исходной спецификации поддерживает небольшую общую основу, которую можно проверить локально, не выдавая локальные полномочия за глобальные. Приоритет работающего кода переносит вес с ярлыка «доверенный» на воспроизводимые квитанции цепочки, сопоставления, NACM, RPC и хранилища. Слои реальности не позволяют валидности PKI, идентичности, полномочию и результату взаимно подменять доказательства. Это открыто заявленные редакционные линзы, а не дополнительные требования IETF.

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

Источники