Кратко

  • draft-cel-nfsv4-rpc-tls-othername-04 от 5 сентября 2026 года предлагает помещать одного пользователя RPC в otherName расширения X.509 subjectAltName. Это индивидуальный Internet-Draft, а не RFC, консенсус IETF или свидетельство внедрения.
  • Сервер с включённым механизмом заменяет идентификатор из заголовка AUTH_NONE либо AUTH_SYS проверенным идентификатором сертификата. Ошибка преобразования или авторизации ведёт к AUTH_TOOWEAK; возврат к заголовку запрещён.
  • Сервер без поддержки и сервер с отключённой функцией игнорируют поле и используют обычные RPC-реквизиты. Клиент не отличает один случай от другого, поэтому выпуск сертификата не доказывает, что ограничение сработало.

Представим агент резервного копирования, которому сертификат разрешает действовать только как backup. Первый файловый узел проигнорирует другую UID в RPC-заголовке и выполнит запрос от указанной учётной записи. Второй, устаревший узел, успешно аутентифицирует тот же TLS-сеанс, пропустит незнакомый тип имени и снова рассмотрит UID из заголовка.

Подпись осталась прежней. Изменился исполняемый код, превращающий её в решение о доступе.

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

Определены три формы. RPCAuthSys содержит числовые UID и GID. GSSExportedName переносит экспортированное имя конкретного механизма; для Kerberos контекст даёт RFC 4121. NFSv4Principal использует запись user@domain из RFC 8881, которую сервер разрешает через локальную таблицу владельцев.

Это не три взаимозаменяемых варианта. Числа требуют согласованных баз пользователей и групп, имя GSS — полной поддержки механизма, а NFSv4 principal — локальных правил домена. Если сертификат содержит более одной squashing-идентичности, его следует отвергнуть. Криптографическая подпись не устраняет смысловую неоднозначность.

Контроль держится на запрете запасного пути

Исполняющий сервер сначала проверяет цепочку X.509 по RFC 5280 и правилам RPC-with-TLS. Затем он разбирает единственную идентичность, сопоставляет её локальному пользователю и выясняет, вправе ли аутентифицированная сторона применять этого пользователя. В решение могут входить ACL по subject сертификата, допустимые UID/GID и группы, шаблоны доменов, доверенные механизмы и principals GSS.

Одобренный результат привязывается к TLS-сеансу. Для всех запросов AUTH_NONE и AUTH_SYS сервер игнорирует идентичность в заголовке RPC, определённом RFC 5531. На RPCSEC_GSS это не распространяется: контекст безопасности из RFC 2203 уже доказал собственного субъекта.

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

Однако старый бинарный файл не знает этого требования. Профиль требует непустой subject и некритическое SAN, а новое значение размещается в type-id элемента otherName. Старое приложение может распознать само расширение SAN, проигнорировать неизвестный внутренний тип и продолжить обработку заголовка. Современный сервер с выключенной функцией ведёт себя так же; клиент не видит, встретил ли он отсутствие реализации или локальное отключение.

Это плата за совместимость. Критическое SAN могло бы заставить старые системы отвергать сертификат вместе с другими корректными именами. Некритический вариант облегчает смешанное развёртывание, но превращает подписанное ограничение в запрос к серверу, а не в переносимую гарантию.

Проверять надо обслуживший узел, а не класс сертификата

Настоящий контур контроля соединяет профиль и цель выпуска, trust anchor, версию узла, состояние функции, область политики, таблицы сопоставления, flavor RPC и конкретный сеанс. Проект разрешает включать механизм для всего сервера, отдельного export или иной локальной единицы. Флаг «поддерживается» не показывает, где он действует.

За балансировщиком соседние сеансы могут попасть на узлы с противоположной семантикой: один заменит UID, второй оставит её. Оба ответят вовремя, поэтому доступность останется зелёной. Различие проявится лишь в том, чей пользователь получил власть над ресурсом.

Срок и отзыв сертификата также покрывают только часть цепи. Там, где поле исполняется, оно открывает доступ уровня пользователя, поэтому важны свежесть CRL/OCSP и длительность действия. Редакция 04 рекомендует отдельные trust anchors для squashing-сертификатов и сертификатов простой TLS-аутентификации. Но свежая проверка отзыва не доказывает разбор OID, а правильный разбор — корректное разрешение UID или группы.

В разделе реализаций записано сообщение участников о завершённой поддержке формы user@domain во FreeBSD. Там же сказано, что список не является одобрением IETF, не проверен независимо и не служит каталогом продуктов; опыт эксплуатации не заявлен. RFC 7942 объясняет, зачем сведения о running code полезны для стандартизации, но само сообщение не становится замером производственной среды.

Здесь полезно разделение слоёв реальности у Heng Lu: подписанное поле, решение сервера и эффект на ресурсе — разные доказательства. Приоритет работающего кода переносит проверку на фактически обслуживший бинарный файл. Минимальная исходная спецификация задаёт общий минимум, но публикация документа не равна обновлению каждого узла.

Поэтому аудит должен спрашивать не «есть ли пользователь в сертификате?», а «какой узел подтвердил, что выбрал этого пользователя в данном сеансе и отверг конкурирующее значение заголовка?»

Источники