要約

  • IDENTは人名簿を検索する仕組みではない。接続を受けた側が相手ホストのTCP 113番ポートへ接続し、同じ二つのIPアドレスと元のTCP接続のポート対を使って、相手のローカル状態を照会した。
  • 1984年のAuthentication Service、1985年のAuthentication Server Protocolは、1993年にIdentification Protocolへ改称された。RFC 1413はUSERID応答をアクセス制御に使うことを明確に禁じた。
  • USERIDもHIDDEN-USERもUNKNOWN-ERRORも、相手ホストが自分の制度とプライバシーポリシーに従って出す報告である。監査の手掛かりにはなるが、人の真正性や権限を証明しない。

接続を受けた側が折り返す

Aがローカルポート6191からBのTelnet用ポート23へ接続したとする。Bは送信元アドレスとポートを知っている。だが、Bのログ担当者が知りたいのは別のことだ。AのOSは、その接続をどのローカルユーザーに結び付けているのか。

BはTelnetの会話に新しい認証欄を足さない。中央の身元台帳にも問い合わせない。AのTCP 113番ポートへ別の接続を開き、6191, 23と送る。最初の数字は回答側Aのローカルポート、次は照会側Bのポートである。Aが接続表に対応する状態を見つければ、USERIDとOS種別、Aが選んだ識別子を返せる。

RFC 1413 が規定したこの構造では、一本目の接続が業務を運び、二本目が一本目について尋ねる。名前は元の接続から自然に現れるのではない。相手ホストが内部の対応表を調べて作る追加証言である。

対象範囲は狭い。IPアドレスの組は照会用TCP接続から得られ、ポートの組は問い合わせ行から得られる。同じ二台のホストの間にある特定のTCP接続だけが候補になる。A上の全ユーザーを列挙する機能でも、第三のホストに関する質問でもない。

「認証」という名に先行した期待

RFC 912 は1984年9月、113番ポートの仕組みをAuthentication Serviceと呼んだ。FTPサーバーが、アプリケーションで申告されたユーザー名とTCP接続を作ったユーザーを照合する用途や、特権操作に関わる利用まで想定していた。

同時に、制約も書かれていた。回答が役立つには、相手ホストが接続とアカウントを正しく管理し、正直に答え、ローカル利用者による操作を防げると信頼しなければならない。相手が侵害されていれば、プロトコル自身に訂正する独立証拠はない。

1985年1月の RFC 931 はAuthentication Server Protocolとして形式を整えた。ポート対の照会、USERIDまたはERRORという応答、OS種別が現れ、返された名前からローカル権限へ対応付ける案も示された。

発想は魅力的だった。接続を作ったホストが利用者を知っているなら、各アプリケーションが改めて尋ねなくてもよい。しかし、ホスト内部の「知っている」は、受信側にとっての認証済み事実ではない。鍵盤の前の人を証明せず、応答経路を保護せず、同じ文字列が二組織で同じ意味を持つことも保証しないからだ。

改称で捨てられたのは、もともと存在しない権限だった

1993年2月、IETFのIDENT作業部会はRFC 931を廃し、RFC 1413を公開した。名称はIdentification Protocolに変わった。文書は、機能をより正確に表すための改称だと説明する。

この修正は大きい。RFC 1413は、得られる情報はせいぜい監査に有用であり、アクセス制御の識別子として使ってはならないとする。Bがaliceという応答だけで資源を開けば、支配されたAは誰の接続にもaliceと返せる。折り返し照会は、Aから独立した信頼源を一つも増やしていない。

Identificationが意味するのは、AがあるTCP接続とローカル識別子を関連付けているという主張である。ネットワークが人を認証したという意味でも、二つの組織が同じ名前を同じ人物に割り当てたという意味でも、操作の許可が得られたという意味でもない。

限定したからこそ、実務上の使い道は明確になる。Bは名前をアドレス、ポート、時刻と一緒に記録できる。問題が起きたらAの管理者がログイン履歴やプロセス記録と照合する。二人の運用者が同じ出来事へ近づく索引にはなるが、単独で判決を下す材料ではない。

ポートの順序が方向を保存する

二つの数字だけの書式は簡単に見える。難しいのは視点が反転することだ。Aから見れば6191はローカルで23はリモート、Bから見れば23がローカルで6191がリモートである。

BがAに問い合わせるとき、順序は回答者Aの視点で書く。そのため6191, 23となる。23, 6191と送れば別の組を尋ねることになり、INVALID-PORTか、有用でない結果になる。

IPアドレスは照会行に書かず、その行を運ぶTCP接続から導く。これでテキスト上の曖昧さは減るが、暗号学的な結合にはならない。経路は通常のネットワークで、返答内容は依然としてAが決める。

ポートは再利用される。時刻のない記録では、同じ番号を後に使った別接続と誤対応する。したがって監査には元接続の両アドレス、両ポート、方向、時刻と、IDENT交換の全体が必要だ。名前はある瞬間の観測値であり、ポートの永久所有者ではない。

USERIDはローカルな名前空間を外へ運ぶ

成功応答には、ポート対の反復、USERID、OS種別、文字列が入る。OS種別は識別子の解釈を助け、任意の文字集合パラメータは同じバイトを双方が同じ文字として読めるかという問題を扱う。

RFC 1413はOS値OTHERも認める。この場合は通常のユーザー名ではなく、形式を限定しないトークンを返せる。受信側はUnixアカウント、世界で一意な人物、永続的な従業員番号だと決めつけられない。

推奨されるのは、回答側の管理者が後から関連付けられる識別子であって、プロセス名やコマンドの過剰な開示ではない。目的は相手の内部を覗くことではなく、相手が自分の出来事を見つけるための手掛かりを渡すことだった。

エラーは故障だけでなく方針を語る

INVALID-PORTは形式または範囲の誤り、NO-USERは指定接続に対応するユーザーを示せない状態を表す。HIDDEN-USERは、分かっていてもポリシー上開示しないという回答である。UNKNOWN-ERRORは内部事情を詳しく公開せずに失敗を伝える。応答前に接続が閉じられた場合も、問い合わせ側は同じ扱いにする。

これらから過大な結論は引けない。NO-USERは匿名利用の証明ではない。HIDDEN-USERは不正の証拠ではない。UNKNOWN-ERRORは対応関係が存在しないことを証明しない。回答サービスがその時点で何を言えるか、何を言う意思があるかを示すだけだ。

RFC 1413はプライバシー問題をCallerIDやFingerになぞらえた。ホスト内部では平凡なユーザー名でも、接続先のすべてが照会できれば新しい開示になる。サービス停止、選択的秘匿、別トークンの採用はそれぞれ保護になるが、監査ログの意味も変える。

MIBに入っても証拠の強さは変わらない

RFC 1414 はIdentification ProtocolのMIBを定義した。表の索引はローカルアドレス、ローカルポート、リモートアドレス、リモートポートで、ユーザー識別子と状態を持つ。113番ポート上の問答を、管理データの四項目へ写した形である。

RFC 1414は現在Historic、RFC 1413はRFC Editor上でProposed Standardである。この違いは現在の普及率を示さない。文書が与えるのは仕様史であり、稼働台数の調査ではない。

MIBも、IDENT情報は権威的でなくアクセス制御に使うべきでないと繰り返す。値を表の列に格納すれば検索は容易になるが、真実性は増えない。

登録されたのは入口であって回答ではない

現在の IANA Service Name and Transport Protocol Port Number Registry はTCP 113にidentと旧称authの双方を載せている。実装がどこへ接続するかを共有し、改称の履歴も残す。

レジストリは返されたユーザーを保証しない。調整するのは待受場所であり、OS、アカウント台帳、開示方針、回答者の誠実さではない。共通の文法は質問を標準化できても、各ホストの返事を中央の真実にはできない。

名前から許可を取り除くことで用途が明瞭になった

IDENTの歴史が残したのは、すべてのサービスが今も逆照会すべきだという命令ではない。名前らしい値が返ってきても、接続帰属とアクセス許可を別の操作として扱うべきだという教訓である。

照会は同じ二ホスト、正しい方向のポート対、ある時点の接続に限られる。回答はローカル状態を持つ相手が作る。エラーは「分からない」を、HIDDEN-USERは「言わない」を、安全性節は「嘘をつける」を認める。

この範囲なら、回答は運用者同士の照合を速める。範囲を越えれば、相手が自由に作れる文字列を受信側の権限に変換する危険な近道になる。AuthenticationからIdentificationへの改称は敗北ではない。仕様の名前が、実際の証拠連鎖に追いついたのである。

情報源と証拠の限界

これらは仕様の変遷、管理モデル、登録名を示すが、現在の配備数、回答精度、プライバシー運用、攻撃頻度を測定しない。本稿はIDENTが現在広く有効だとは主張せず、閉じた資料が扱わないNAT、プロキシ、コンテナの挙動も推測しない。