識別プロトコル

RFC 1413 で規定されているIdent プロトコル(識別プロトコル、Ident ) は、特定のTCP接続のユーザーを識別するのに役立つインターネット プロトコルです。identサービスを提供する一般的なデーモン プログラムの1 つにidentdがあります。

Ident プロトコルは、ユーザーのコンピュータ上でサーバーデーモンとして機能するように設計されており、指定されたTCP ポート(通常は 113) への要求を受信します。クエリでは、クライアントはTCP ポートのペア(ローカル ポートとリモート ポート)を指定します。このポートはASCII 10 進数としてエンコードされ、カンマ (,) で区切られます。サーバーは、指定された TCP ポートのペアを使用するプログラムを実行しているユーザーのユーザー名を識別する応答、またはエラーを指定する応答を送信します。

ホスト A が、クライアント (ホスト B) のポート 6191 から TCP ポート 23 ( Telnet )に接続しているユーザーの名前を知りたいとします。この場合、ホスト A はホスト B の ident サービスへの接続を開き、次のクエリを発行します。

6191, 23

TCP 接続では通常、1 つの固有のローカル ポート (この場合は 6191) が使用されるため、ホスト B は、ホスト A のポート 23 への指定された接続を開始したプログラム (存在する場合) を明確に識別できます。次に、ホスト B は、この接続を開始したプログラムを所有するユーザー (この例では「stjohns」) と、そのローカルオペレーティング システムの名前を識別する応答を発行します。

6193, 23 : ユーザーID : UNIX : stjohns

しかし、ホスト B にそのような接続が存在しないことが判明した場合、代わりにエラー応答が発行されます。

6195, 23 : エラー : ユーザーなし

すべてのidentメッセージは、復帰文字と改行文字（CR+LF）で構成される行末シーケンスで区切られる必要があります。 ^[1]

ダイヤルアップ ホストや共有シェル サーバーは、多くの場合、不正使用を特定のユーザーまで追跡できるように ident を提供します。このホストで不正使用が処理される場合、ident デーモンを信頼するかどうかの懸念はほとんど無関係です。サービスのなりすましやプライバシーの懸念は、実際のユーザー名の代わりに さまざまな暗号化された強力なトークンを提供することで回避できます。

ユーザーが ident 提供ホストを使用して接続するサービスの管理者が不正使用に対処する場合、ident サービスは各ユーザーを識別する情報を提供する必要があります。通常、リモート サービスの管理者は、特定のユーザーが信頼できるサーバー経由で接続しているのか、または管理者自身が管理するコンピューターから接続しているのかを知ることはできません。後者の場合、ident サービスは信頼できる情報を提供しません。

Ident がリモート ホストに対して既知の ID を証明するために役立つのは、次の状況に限られます。

• 接続しているユーザーは、マシンの管理者ではありません。これは、Unix シェルアクセスを提供するホスト、suEXECのような構造を使用する共有サーバーなどでのみ発生する可能性があります。
• マシンの管理者を信頼し、そのユーザー ポリシーを把握している。これは、単一の組織内などの共通のセキュリティ ドメイン内のホストの場合に最もよく当てはまります。
• マシンが主張する通りのマシンであり、そのマシンを知っていることを信頼します。これは、ネットワーク上のすべてのホストが信頼されており、物理的に保護されているため新しいホストを簡単に追加できないローカル エリア ネットワークまたは仮想ネットワーク上のホストに対してのみ簡単に実現できます。リモート ネットワークおよび通常のローカル ネットワークでは、IP スプーフィングによって、また DNS が使用されている場合はあらゆる種類の DNS トリックによって、偽の ident 応答が実行されることがあります。ident デーモンは、暗号で署名された応答を提供することがあり、それが確認できれば、これらの最後の問題は解決しますが、最初の問題は解決しません。
• identd への接続には、ファイアウォール、NAT、プロキシ (Apache httpd で ident を使用している場合など) などの中間障害は存在しません。これらは、セキュリティ ドメイン間を移動するときによく発生します (パブリック HTTP サーバーまたはFTPサーバーの場合など)。

ident プロトコルは、クラッカーがコンピュータ システム上のユーザー名のリストを入手し、後で攻撃に使用できるため、危険であると考えられています。この問題に対する一般的な解決策は、汎用/生成識別子を設定し、ユーザー名ではなくノード情報または意味不明な文字列(要求者の観点から) を返すことです。この意味不明な文字列は、悪用の可能性について ident 管理者に連絡が入ったときに、実際のユーザー名に変換される可能性があります。つまり、悪用を追跡する有用性は保持されます。

Ident はIRCでは重要です。これは、多くの場合、バウンサーを使用して、複数のユーザーが共有するサーバーから多数のユーザーが IRC に接続するためです。Ident がなければ、ホスト全体を禁止せずに 1 人のユーザーを禁止する方法はありません。サーバー管理者は、この情報を使用して不正ユーザーを識別することもできます。

ほとんどの IRC ネットワークでは、サーバーが Ident 応答を取得できない場合、クライアントが指定したユーザー名に戻りますが、通常は先頭にチルダを付けるなどして「未検証」としてマークします (例: ~josh )。一部の IRC サーバーでは、ident 応答のないクライアントをブロックするところもあります。^[2]その主な理由は、「オープン プロキシ」や、何らかの形で単一のアカウントを侵害したがルート権限を持っていないシステム(Unix 系システムでは、1024 未満のポートでネットワーク接続をリッスンできるのはルート権限のみ) 経由で接続することが非常に困難になるためです。

しかし、Identは、ユーザーが自分のパソコンから直接接続する場合、Identデーモンを制御するのに十分な権限を持っているにもかかわらず、追加の認証を提供しません。^[1]

• oidentd (Unix系システム用)
• メール
• NNTP
• パスワード
• SOCKSプロキシ

• RFC 912 – 認証サービス
• RFC 931 – 認証サーバー
• ダニエル・J・バーンスタイン：TAP インターネット ドラフト、1992 年 6 月
• ダニエル・J・バーンスタイン：なぜTAPなのか？ホワイトペーパー、1992-08-20
• RFC 1413 – 識別プロトコル
• RFC 1414 – 識別 MIB
• ピーター・エリクソン: TAPvsIDENT、1993-11-03
• Damien Doligez : ident/TAP 応答を暗号化する理由、1994-02-22