要約

  • RFC 3045はLDAPサーバーのroot DSEに任意で置けるvendorNameとvendorVersionを定義し、実装元の表示や既知のソフトウェア異常の識別を可能にした。
  • ただし、これらの文字列で対応機能を発見することは禁じられた。サーバーが申告した製造元や版は、ソフトウェアの出所を認証せず、その接続やセッションで機能が使える証明にもならない。

LDAPクライアントは、接続先サーバー固有の情報を得るため、root DSA-specific Entry、通称root DSEを読むことができた。RFC 3045はこの応答にvendorNameとvendorVersionという二つの手掛かりを加えた。2001年1月に公開されたInformational RFCは、サーバー実装者と製品版を文字列で知らせることを認めた。いずれも単一値の運用属性であり、ディレクトリ利用者が変更する通常の項目ではない。

提案の用途は意図的に限定されていた。クライアントは製造元と版を運用者に表示したり、既知の不具合と結び付く版を見つけて回避策を検討したりできる。しかしRFC 3045は、その値から対応機能を推測することを禁じた。製造元名から、個々のサーバーがどのコントロール、拡張操作、仕組みを受け入れるかは分からない。版の文字列からも、機能が現在の設定で有効か、認証済みセッションで利用可能か、実際に動くかは判断できない。機能は、その機能に合わせた仕組みで広告するべきだった。

この線引きは、一見便利で危うい近道を防ぐ。クライアントが「製造元X、版Y」を機能交渉の代わりにすれば、その機能用に設けられたプロトコル上の証拠を飛ばしかねない。未対応の操作を呼び出したり、使える機能を捨てたりする可能性がある。RFC 3045で製品名が担うのは観測の背景であって、観測そのものではない。

バージョン文字列の比較も、偽の精密さを避けるよう設計されている。RFCは、版ごとにvendorVersion値を一意にするよう求めたが、書式や大小の順序は定めなかった。比較規則は等価一致で、「小さい」「大きい」ではない。既知の不具合向け回避策を選ぶとき、8.01が8.5より新しいか古いかを勝手に決めず、該当する文字列に正確に一致させる。版名は名前であり、必ずしも比較できる数値ではない。

完全一致しても実装の全体像は分からない。RFC 3045は、同じ版を報告するサーバーの一部だけで不具合が起こる場合があると述べた。プラットフォーム、設定、プラグインは同じとは限らない。また返された製造元名や版は、その会社がサーバーを実際に作ったことや、その版が本当に動いていることを保証しない。分かるのはサーバーの申告であり、実行バイナリーの認証や振る舞い全体ではない。

二つの属性は任意だ。サーバーはアクセスを制限でき、クライアントは属性があると期待してはならない。情報がないことは故障の意味ではなく、相互運用を止める根拠にもならない。トラブル対応に有用な情報は、攻撃者にソフトウェアの手掛かりを与えることもある。RFC 3045は、製造元や版の開示が弱点の探索に利用され得る点も明記した。

後のLDAP仕様も、識別情報と機能を分けている。RFC 4512はroot DSEを各サーバーに固有の運用エントリーとして説明し、supportedControl、supportedExtension、supportedFeaturesなど別の属性を列挙する。それらの値はセッション条件で変わることもある。現在のIANA LDAP Parameters登録簿にvendorNameとvendorVersionのOIDが残っているのは、識別番号が登録されている証拠であって、サーバーの申告や機能の証明ではない。RFC 3045の教訓は役割分担だ。ラベルは状況の理解に、機能固有の証拠は接続で実際に使えるものの判断に使う。

参照資料