要約

  • 安全でないサービス発見は、自分自身として正しく認証できる別のホストへ利用者を誘導できる。RFC 5178 は service [AT] domain [AT] hostname を認証対象にする。ここで [AT] は RFC 構文に現れる ASCII の at 記号そのものを示す。この名前により、ホストが対象ドメインのサービスを担う権限まで要求する。
  • この名前の acceptor 資格情報を発行する管理者は、文字列を登録しているのではない。特定ホストへ限定された実行可能な委任を作っている。

事故報告が DNS の改ざんで終わると、次の問いが抜け落ちる。誘導先のサーバーは、なぜ認証を通過できたのか。

答えは二通りある。サーバーは自分のホスト名に対する正当な資格情報だけを持ち、クライアントが発見結果をそのまま認証名にしてしまったのかもしれない。あるいは、対象ドメインのサービスを表す資格情報まで誤って発行されていたのかもしれない。同じ「認証成功」でも、責任の所在は全く違う。

RFC 5178 はこの違いを名前に残した。

発見されたホストは、まだ代表者ではない

DNS SRV は、サービスの場所を柔軟に変えるための有力な仕組みである。複数候補、優先度、重み、ポートを公開できる。しかし DNSSEC のない応答は、誤った候補へ書き換えられ得る。

ここでホストベース名だけを使うと、クライアントは発見によって得た hostname から service [AT] hostname を作る。誘導先がその hostname の正当な所有者なら、認証は成功する。証明されたのは応答に書かれた機械の身元であり、利用者が意図したドメインサービスの委任ではない。

ドメインベース名は三つの必須要素を持つ。サービスは機能、domain は提供対象、hostname は具体的な acceptor を示す。表示形式は service [AT] domain [AT] hostname で、IANA は GSS_C_NT_DOMAINBASED_SERVICE に対応する名前型を値 5 として登録している。

発見は候補を提案する。三つ組の資格情報は、その候補が対象ドメインを代表できることを示す。この二段階を保つからこそ、発見機構を中央の最終権威にしなくて済む。

発行記録が権限の原点になる

RFC 5178 は、ドメインベース名を認証できる有効な資格情報の存在が、サーバーへの承認を具体化すると説明する。したがって ldap [AT] example.net [AT] ds1.example.net を発行する操作は、設定同期ではない。ds1 が example.net の LDAP サービスとして話すことを認める操作である。

この観点では、証明書や Kerberos principal の棚卸しは容量管理よりも権限管理に近い。誰が申請し、誰が承認し、どのホストへ配置し、いつ失効し、クラスタ離脱時にいつ撤回したかを残さなければならない。

SRV から削除しただけでは委任は消えない。通常の探索から見えなくなるだけで、キャッシュ、固定設定、あるいは改ざんされた応答を通じて到達すれば、古い資格情報がなお応答できる。逆に、SRV に追加して資格情報をまだ発行していなければ、見つかるが認証できないサーバーが生まれる。

発見メンバー集合と有効資格情報集合は照合すべきだが、同じ表に潰してはならない。差分こそが作業中、取り残し、撤回遅延を示すからである。

フォールバックには代替の承認が要る

新しい名前型は、クライアントだけを更新して完成するものではない。GSS mechanism が扱えないことも、acceptor が対応しないこともある。既存 LDAP サーバーにドメイン資格情報がなければ、切り替えは相互運用を壊す。

RFC 5178 は host-based name へのフォールバックを想定する。ただし、そのホストが対象ドメインのサービスを提供する権限を持つことを別途確認しなければならない。名前型を実装していないクライアントにも同じ責任がある。

ここで「二回目の接続が成功した」は承認証拠にならない。どのローカル一覧、署名済み設定、管理者決裁が host と domain-service を結び付けたのかが必要である。同じ安全でない SRV 応答を承認一覧として使えば、循環確認になる。

互換性モードは接続の仕方だけでなく、証明する命題を変える。自動ライブラリ任せにせず、どの命題を失い、何で補うかを運用方針として決める必要がある。

表示された文字列は比較結果ではない

国際化の規則も、権限と表現の境界を示す。通常の import は domain と hostname の ACE 表現を受け入れなければならない。推奨される UTF-8 import は UTF-8 と ACE の双方を受け入れる。通常の display は ASCII または ACE、UTF-8 display は UTF-8 を出力し ACE を出力しない。

しかし表示変換は、同一性判定ではない。GSS-API には内部名、機構名、表示名、exported name がある。RFC 2743 は、import した名前を display しても元の文字列や元の name type が戻る保証はないとする。認可用比較は GSS_Compare_name() や機構の canonicalization に従うべきで、画面上の二文字列を直接比べてはならない。

RFC 5178 が参照した RFC 3490 の IDNA2003 は後に置き換えられた。IDNA2008 は A-label と U-label などを区別する。現行実装はこの歴史を処理しなければならないが、後の仕様を旧文書へ遡及適用したことにしてはいけない。入力 profile、ACE/Unicode の両表現、最終 principal を一緒に保存するのが安全である。

Kerberos の realm は domain 欄そのものではない

RFC 5179 は三つ組を Kerberos V principal に写像する。service が第1 component、hostname が第2、domain が第3となり、NT-SRV-HST-DOMAIN 値 12 が推奨される。

realm の導出は別である。安全上、入力の domain 欄ではなく hostname から導くことが重要だとされる。サービス範囲を主張する欄が、自分を検証する認証 realm まで自由に指定できないようにする境界である。

運用確認では、設定文字列だけでなく、ライブラリが生成した principal、選択した realm、応答した資格情報を取得する必要がある。ACE を要求した当時の Kerberos 国際化条件も含め、構文受理と意味の一致は別の試験である。

NFS の後続仕様が示した構成

RFC 6641 は NFSv4 の組織ルートを DNS SRV で発見する際に、この名前を具体的に使う。DNSSEC が利用できるなら使うべきであり、ドメインベース principal は追加の防御となる。クライアントは nfs [AT] 組織ドメイン [AT] SRVで選んだホスト を認証する。

DNS は場所を示す。資格情報は委任を示す。NFS は操作を許可し、実際の mount とファイル内容が結果を示す。どれか一つを残して他を推定すると、後から誤った発見、誤発行、アプリ拒否、内容異常を区別できない。

三つ組は小さな共有仕様に見える。だがその価値は、責任を一つの曖昧な「信頼」へ集約しないことにある。各参加者が自分の層で検証し、発行した権限に責任を持てる。正しいホスト名を証明することと、正しいドメインを代表することは、最後まで別の事実である。

出典