要約

  • Identは、問い合わせ先のホストから見たサーバーポートとクライアントポートで一つの接続を指定し、そのホストがローカルのソケットに結び付けた識別文字列を返す仕組みだった。
  • RFC 931はFTPの自動ログインで実験的に使う案を示した。1993年のRFC 1413は名称をIdentification Protocolとし、返答は監査の補助にとどまり、認証やアクセス制御には使えないと明記した。

二つのポートが示す、片側からの眺め

RFC 1413に載った例は、単なる入力ミスの訂正のように見える。ある端点では接続が23, 6191と記録されるが、もう一方の端点に問い合わせるときは6191, 23と送る。接続自体は変わっていない。「ローカル」と「相手側」のポートをどのホストが名付けるかが変わったのだ。

この順序がIdentの実用上の鍵だった。クライアントは相手ホストのTCP 113番ポートに接続し、<サーバー側ポート>, <クライアント側ポート>を一行で送る。IPアドレスはIdentサービスへ接続したTCPセッションから得られ、二つのポートと組み合わせることで、すでに存在するTCP接続を指定できた。サーバーは、自分のマシン上でその接続に関連付けた、システム依存の利用者識別子を返す。

要求の範囲は意図的に狭い。インターネット全体から人を検索する中央サービスではない。あるホストのローカルシステムが、特定のソケットをどの利用者文字列に結び付けているかを尋ねる。USERIDはOS名と識別子を含み、所有者を判定できない場合はERRORを返せる。RFC 1413は、サーバーが利用者を特定できても本人の希望で情報を返さないHIDDEN-USERも定義した。

これは以前のName/Fingerとは異なる問い合わせ面である。空のFinger要求は、ホストにオンライン利用者の一覧を求めることがあった。Identはポート対で一つのTCP接続を選ぶ。利用者一覧とソケット所有者の文字列では、運用上の問いが違う。Name/Fingerを扱った記事は、前者のホスト単位の在席情報を説明している。

「Authentication Server」はアプリケーション上の構想だった

経緯は、Mike St. Johnsが1984年9月に公開したRFC 912から始まる。「Authentication Service」と題された提案は、TCP 113番で動くサービスが、特定のTCP接続の所有者識別子を返すとした。FTPでの利用者自動認証や、特権操作の確認などが用途として挙げられた。同時に、ホストの信頼性は一様でなく、返答をどこまで信頼するかは利用するアプリケーションが判断すべきだと警告していた。

1985年1月のRFC 931はRFC 912を置き換え、OS名に続けて利用者識別子を返す形式をより明確にした。FTPについては、引数なしのUSERコマンドを送れば、サーバーがこのサービスを使うかもしれないという案を示した。文書はそれを実験的な利用と明記し、ホストごとに信頼度が異なるとの注意も繰り返している。これは提案された統合方法の記録であり、FTPサーバーが広く採用したことの証明ではない。

プロトコルの応答とアプリケーションの決定を分けて読むことが肝心だ。Authentication Server自身がパスワードを独立して照合したり、端末の前に誰が座っているかを証明したりしたわけではない。返したのは、ホストがその接続のローカル所有者として記録した識別子だった。FTPサーバーがその文字列を使うかどうか、また結果に責任を負うかは、アプリケーションと相手ホストの信頼関係に委ねられていた。

1993年、名称が役割の境界を明らかにした

1993年2月のRFC 1413はRFC 931を廃止し、旧Authentication Server ProtocolをIdentification Protocol、略してIdentと呼び直した。「機能をより正確に表す」ためだという。TCP 113番と接続固有のポート対は維持しつつ、一つのIdent接続で複数の要求を扱う方法やHIDDEN-USERなどの応答を明確化した。

セキュリティの節は、これ以上強い読み方ができないよう釘を刺している。返る情報の信頼性は、最大でも提供元ホストまたはその運営組織の信頼性まで。Identは認可やアクセス制御を目的とせず、最善でもTCP接続に関する監査情報の補助であり、誤りや悪意のある誤情報になりうる。RFCは監査以外への利用を強く避けるよう求め、通常は私的とみなされる情報を露出させるおそれも指摘した。

この線引きはデータの出所から導かれる。識別子を作るのは、問い合わせ先ホストのOSだ。侵害されたホストなら誤解を招く回答を返せる。開放的な研究室のマシンでは、利用者がどんな識別子を出すか決められる場合もある。構文上正しいUSERIDが、サーバーの主張を独立検証済みの事実に変えるわけではない。クライアントが知るのは相手ホストの報告内容であり、人が別途認証されたかどうかではない。

名称の変更は重要な歴史上の境界を示すものの、以前に提案された利用がすべて終わった証拠ではない。RFC 1413はサービスを「認証」ではなく「識別」と呼び、返答から導いてよい推論の範囲を定めた。現存するRFCからは、Identを稼働させたサイト数、識別子を隠す要求の頻度、実際に依存したFTPソフトウェアを確認できない。標準文書はプロトコルの約束を記録するが、導入実績の全数調査ではない。

ポート対が支えられる判断

監査ログでは、ホスト、接続方向、ポート、時刻、返答を一緒に記録しておけば、ホストが返す識別子は手掛かりになる。相手側がどのローカルアカウントをソケットに結び付けたか調べる助けにはなる。しかし、名前が示す本人が通信を開始したこと、相手のマシンを支配していたこと、あるいはアプリケーションにアクセスする権限があったことまでは証明しない。

この分離がプロトコル史の核心だ。RFC 931は、アプリケーションが相手側の利用者文字列をどう使うかという案を記した。RFC 1413は、実際に返す「識別」に合わせて名称を変え、その報告を権威として扱わないよう求めた。二つのポートは、特定の接続をそのホストから読めるようにした。返答を信じて何をするかは、それを使うシステムの責任だった。

出典