要約

  • 2026年9月5日付の draft-cel-nfsv4-rpc-tls-othername-04 は、X.509 の subjectAltName にある otherName へ RPC 利用者を一つ格納する案だ。個人 Internet-Draft であり、RFC、IETF 合意、配備実績ではない。
  • 対応し実施するサーバーは、AUTH_NONE／AUTH_SYS ヘッダーの身元を検証済みの証明書身元で置き換える。変換や許可に失敗すれば AUTH_TOOWEAK で拒否し、ヘッダーへ戻ってはならない。
  • 非対応サーバーと機能を無効にしたサーバーは、そのフィールドを無視して通常の RPC 資格情報を使う。クライアントには両者を見分けられず、証明書の発行は制限実施の証拠にならない。

バックアップ端末に backup という一人分の権限だけを持たせたいとする。最初のファイルサーバーでは、RPC ヘッダーが別の UID を名乗っても証明書の利用者に固定される。次の旧式ノードでは TLS 認証こそ成功するが、新しい型は読み飛ばされ、ヘッダーの UID が再び判断材料になる。

署名された内容は同じである。それでもアクセスの意味は、セッションを受けたコードによって変わる。

ドラフト第04版は、RFC 9289 が意図して残した層の隙間を扱う。RPC-over-TLS は通信を暗号化し、完全性を守り、相手を認証する一方、個々の RPC 呼び出しがどの利用者を表すかは変えない。そこでクライアント証明書に RPC 利用者を載せ、TLS セッション開始時に検証・変換・許可して、弱いヘッダー主張の代わりに用いる。

表現は三つある。RPCAuthSys は UID と GID の数値、GSSExportedName は GSS 機構固有のエクスポート名を運ぶ。Kerberos の形式には RFC 4121 が背景を与える。NFSv4Principal は RFC 8881 の user@domain を使い、サーバー側の owner mapping で解決する。

三形式は予備回答ではない。数値は利用者・グループ台帳の整合、GSS 名は対応機構、NFSv4 principal はローカルのドメイン規則に依存する。証明書に複数の identity-squashing 形式があれば、サーバーは拒否する。署名が二つの意味を一つにしてくれるわけではない。

安全性を決めるのは失敗時の分岐

実施サーバーは RFC 5280 と RPC-with-TLS の規則で証明書経路を検証し、ただ一つの身元を解析する。次にローカル利用者へ変換し、その TLS ピアに利用資格があるかを判断する。証明書 subject の ACL、UID/GID 範囲、グループ、想定ドメイン、信頼する GSS 機構などはすべてローカル政策である。

成功した利用者は TLS セッションへ結び付く。同じセッション上の AUTH_NONE と AUTH_SYS では、RFC 5531 の要求ヘッダーにある身元を採らない。RPCSEC_GSS は対象外だ。RFC 2203 のセキュリティコンテキストが、すでに独自の主体を証明しているからである。

証明書内の身元が不正、変換不能、または無許可なら、非 NULL の該当手続きは AUTH_TOOWEAK で拒否される。ここでヘッダーへフォールバックしてはいけない。その経路は、証明書が奪うはずだった権限をその場で復活させる。

ところが、新規則を知らないサーバーにはこの必須条件が届かない。プロファイルは空でない subject と非 critical の SAN を要求し、新しい意味を otherName の type-id に置く。旧実装は SAN 自体を理解しても未知の内部型を無視できる。対応版でも機能を無効にすれば同じ結果になり、クライアントからは「実装なし」と「停止中」の区別がつかない。

これは互換性のための設計である。SAN 全体を critical にすれば、旧ソフトが他の正当な名前まで含む証明書を拒む恐れがある。混在運用を許す代わりに、証明書だけで最小権限を保証することはできなくなった。

対応製品ではなく、応答したノードを数える

管理すべき組み合わせは、証明書プロファイル、発行目的、信頼アンカー、ノードの版、機能状態、政策範囲、身元対応表、RPC flavor、TLS セッションである。ドラフトはサーバー全体、export 単位、その他のローカル単位で実施範囲を選べる。「製品が対応」という一項目では足りない。

負荷分散の背後に新旧ノードが並べば、最初のセッションではヘッダー UID が消え、次のセッションでは残ることがある。両方とも正常応答するので、可用性グラフは差異を示さない。アクセス意味論だけが揺れる。

失効管理も必要だが十分ではない。この証明書は実施される場所で利用者レベルのアクセスを与えるため、短い有効期間や CRL／OCSP の鮮度が重要になる。第04版は、単なる TLS ピア認証用とは別の信頼アンカーも推奨する。しかし最新の失効応答は OID の解釈を証明せず、正常な解釈はローカル mapping の妥当性を証明しない。

実装状況欄には、貢献者が FreeBSD の user@domain 対応を完了と報告したことが記される。同じ欄は、IETF の推奨でも独立検証でも製品一覧でもないと明記し、実装経験は報告されていない。RFC 7942 が running code の開示を標準化作業に役立てる理由を示しても、自己申告がフリートの実測値になることはない。

Heng Lu の現実レイヤー論にならえば、署名フィールド、サーバー判断、資源への効果は別々の証拠だ。稼働コードの優先は、実際に応答したバイナリへ検証を戻す。最小初期仕様は共通の出発点を定められるが、公開だけで全ノードを更新したことにはできない。

従って監査で問うべきは「証明書に身元があるか」ではない。「このセッションで証明書身元を採り、ヘッダーの別回答を拒んだと、どのノードが証明できるか」である。

出典