The Finger User Information Protocol
Takami Torao
Network Working Group D. Zimmerman
Request for Comments: 1288 Center for Discrete Mathematics and
Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science
December 1991
The Finger User Information Protocol
この記述について
この記述はユーザ情報の交換のためのプロトコルを定義している。この RFC
はインターネットコミュニティのための IAB 標準トラックプロトコルを記述
し、論議の要求と改善の要求を行う。このプロトコルの標準化の状態と状況の
ため "IAB Official Protocol Standards" の最新版を参照してください。こ
の記述の配布は無制限である。
概要
この記述は Finger ユーザ情報プロトコルを記述している。これはリモート
ユーザ情報プログラムへのインターフェースを供給する簡単なプロトコルであ
る。
オリジナルの Finger プロトコルの記述である RFC 742 に基づき、この記述
は Finger 接続の両端末間において期待されるコミュニケーションを明確にす
る事を試みている。これはオリジナルのプロトコル定義に対し、多くの既存イ
ンプリメンテーリョンの無効化や、不必要な制限を追加を試みるものではない。
この版は RFC 1196 を正確に、明確にしている。
Table of Contents
1. Introduction ........................................... 2
1.1. Intent ............................................... 2
1.2. History .............................................. 3
1.3. Requirements ......................................... 3
1.4. Updates .............................................. 3
2. Use of the protocol .................................... 4
2.1. Flow of events ....................................... 4
2.2. Data format .......................................... 4
2.3. Query specifications ................................. 4
2.4. RUIP {Q2} behavior ................................... 5
2.5. Expected RUIP response ............................... 6
2.5.1. {C} query .......................................... 6
2.5.2. {U}{C} query ....................................... 6
2.5.3. {U} ambiguity ...................................... 7
2.5.4. /W query token ..................................... 7
2.5.5. Vending machines ................................... 7
3. Security ............................................... 7
3.1. Implementation security .............................. 7
3.2. RUIP security ........................................ 8
3.2.1. {Q2} refusal ....................................... 8
3.2.2. {C} refusal ........................................ 8
3.2.3. Atomic discharge ................................... 8
3.2.4. User information files ............................. 9
3.2.5. Execution of user programs ......................... 9
3.2.6. {U} ambiguity ...................................... 9
3.2.7. Audit trails ....................................... 9
3.3. Client security ...................................... 9
4. Examples ............................................... 10
4.1. Example with a null command line ({C}) ............... 10
4.2. Example with name specified ({U}{C}) ................. 10
4.3. Example with ambiguous name specified ({U}{C}) ....... 11
4.4. Example of query type {Q2} ({U}{H}{H}{C}) ............ 11
5. Acknowledgments ........................................ 12
6. Security Considerations ................................ 12
7. Author's Address ....................................... 12
1. イントロダクション
1.1. 趣旨
この記述は Finger 情報プロトコルを記述している。これはリモートユーザ情
報プログラム (RUIP) にインターフェースを供給する簡単なプロトコルである。
オリジナルの Finger プロトコルの記述である RFC 742 に基づき、この記述
は Finger 接続の両端末間において期待されるコミュニケーションを明確にす
る事を試みている。これはオリジナルのプロトコル定義に対し、多くの既存イ
ンプリメンテーリョンの無効化や、不必要な制限を追加を試みるものではない。
今日もっとも行われている Finger の実装は主にカリフォルニアバークレイ大
学での BSD UNIX ワークから配布されているものであろう。したがって、この
記述は BSD バージョンの動作を元にしている。
しかしながら、BSD バージョンは特定サイトのセキュリティポリシーに対して
Finger RUIP を合わせたり、危険なデータからユーザを守るためのいくつかの
オプションを供給している。さらに、実装者や管理者が、最良な敏感な問題を
知っておくべき *たくさんの* 潜在的セキュリティホール、特にこのプロトコ
ルの意図がシステムのユーザに関する情報を返すためのものであるということ
が存在する。それゆえ、この記述ではいくつかの重要なセキュリティコメント
と推奨を行っている。
1.2. 履歴
Les Earnest によって SAIL で書かれた FINGER プログラムは、ITS 上での
NAME プログラムに対するインスピレーションとなった。MIT の Earl Killian
と SAIL の Brian Harvey は共同で元のプロトコルを実装する発端となった。
ken Harrenstain はこの記述の源となる RFC 742, "Name/Finger" の著者であ
る。
1.3. 必要条件
In this document, the words that are used to define the significance
of each particular requirement are capitalized. These words are:
* "MUST"
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of the specification.
* "SHOULD"
This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
* "MAY"
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements. An implementation that satisfies all the
MUST and all the SHOULD requirements is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all
the SHOULD requirements is said to be "conditionally compliant".
1.4. 更新
RFC 1196 とこの記述の違いは以下である。
o Finger 要求仕様におけるオプション /W スイッチは間違って行末に
置かれていた。4.3BSC Finger はこれを先頭に記述しているため、
この記述でもそうしている。
o Finger 要求仕様における BNF はブランクスペースの扱いが明確でな
かった。この記述ではそれに対して明確なトークンを含める事でより
正確にしている。
o Finger 接続における処理の流れは Finger 接続のクローズのトピッ
クでより良く定義されている。
2. プロトコルの使用
2.1. 事象の流れ
Finger は Transmission Control Protocol を基にし、TCP ポート 79 (8進数
で 117) を使用する。ローカルホストはリモートホストの Finger ポートに
TCP 接続する。RUIP はリクエストを処理するための接続のリモート端末が利
用可能になる。ローカルホストは RUIP に Finger 要求仕様に基づく 1行の要
求を送り、RUIP に対する応答を待つ。RUIP は要求を受け取って処理し、応答
を返し、それから接続のクローズを始める。ローカルホストは応答とクローズ
シグナルを受け取り、それからその接続の終了で処理をクローズする。
2.2. データフォーマット
転送されるどんなデータもパリティがつかない ASCII であり、行末に CRLF
(ASCII 10 に続く ASCII 13) を用いなければ *ならない*。これは EBCDIC の
ような別のお文字フォーマットでは除外される。これはまた、パリティビット
がセットされた 7ビット ASCII でない、ASCII 128 から ASCII 255 までの間
のいかなる文字も国際的なデータであるべきだという事を意味する。
2.3. 要求の仕様
RUIP は Finger 要求仕様をすべて受け入れなければ *ならない*。
Finger 要求仕様は以下のようになる。
{Q1} ::= [{W}|{W}{S}{U}]{C}
{Q2} ::= [{W}{S}][{U}]{H}{C}
{U} ::= username
{H} ::= @hostname | @hostname{H}
{W} ::= /W
{S} ::= <SP> | <SP>{S}
{C} ::= <CRLF>
反復的な {H} は、要求の中の @hostname トークンの数に任意の制限が存在し
ない事を意味する。{Q2} 要求仕様の例として、動作に対する簡潔さから
@hostname トークンの数は 2つに制限される。
{Q1} と {Q2} はオペレーティングシステムのプロンプトから "finger user@host"
とタイプしているユーザの参照ではないことに注意。これは RUIP が実際に受
信している行を参照する。それで、もしユーザが "finger user@host<CRLF>"
とタイプするなら、リモートホスト上の RUIP は {Q1} に相当する "user<CRLF>"
を受け取る。
IP プロトコルにおけるどんな事も、"受け入れる事に自由であれ"。
2.4. RUIP {Q2} の動作
{Q2} の要求は別の RUIP に要求を転送するためのものである。RUIP はこの転
送サービス (セクション 3.2.1 参照) を供給するか、能動的に拒むかしなけ
れば *ならない*。もし RUIP がこのサービスを供給するなら、以下の動作に
従わなければ *ならない*。
Given that:
ホスト <H1> はホスト <H2> 上の RUIP に Finger 接続 <F1-2> を開く。
<H1> は <H2> RUIP に (FOO@HOST1@HOST2 のような) タイプ {Q2} の要求
<Q1-2> を与える。
It should be derived that:
ホスト <H3> は <Q1-2> における一番右側 (HOST2 のような) である。
要求 <Q2-3> は要求において一番右の "@hostname" を取り除いた
(FOO@HOST1 のような) 後の <Q1-2> の残りである。
And so:
それから <H2> RUIP は <Q2-3> を用いて <H3> に Finger 接続 <F2-3>
を自身でオープンしなければならない。
<H2> RUIP は <F1-2> 経由で <F2-3> から受信したすべての情報を <H1>
に返さなければならない。
<H2> RUIP は <H3> RUIP が <F2-3> をクローズする時にのみ通常の状況
で <F1-2> をクローズしなければならない。
2.5. 期待される RUIP レスポンス
ほとんどの場合、プログラム出はなく人が読むために設計されているため、
RUIP の出力は厳密な仕様を適用しない。それは主に有益であるように努力す
るべきである。
どんな要求の出力もセキュリティセクションにおける討論に従うべきである。
2.5.1. {C} 要求
{C} の要求はすべてのオンラインユーザのリストに対するものである。RUIP
は応答するか能動的に拒絶する (セクション 3.2.2 参照) かを行わなければ
*ならない*。もし応答するのであれば、少なくともユーザのフルネームを供給
しなければ *ならない*。システム管理者は以下のような別の有用な情報 (セ
クション 3.2.3 に基づく) を含める事を認めさせる *べきである*。
- 端末の場所
- オフィスの場所
- オフィスの電話番号
- ジョブの名前
- アイドル時間 (最後の入力や最後に実行されたジョブからの分数)
2.5.2. {U}{C} 要求
{U}{C} の要求は指定されたユーザ {U} の詳細に対するリクエストである。も
し本当にこのサービスを拒絶する事を望むなら、多分最初から Finger を実行
することは望まないだろう。
応答は少なくともユーザのフルネームを含まなければ *ならない*。もしユー
ザがログインしているなら、ユーザも {U}{C} によって返されなければならな
いため、少なくとも {C} によって返される情報と同じものである。
これが指定されたユーザの情報に対する要求であるため、システム管理者は以
下のような追加的で有用な情報 (セクション 3.2.3 に基づく) を返せるよう
に選択できる事を許可する *べきである*。
- 端末の場所
- オフィスの電話番号
- 自宅の電話番号
- ログインの状態 (ログインしていないか、ログアウト時刻など)
- ユーザ情報ファイル
ユーザ情報ファイルは、ユーザが Finger リクエストへの応答に含まれる短い
メッセージを入れておく事ができる機能である。(これはよく "plan" ファイ
ルと呼ばれる。) これは (たとえば) ユーザのホームディレクトリや共用エリ
アで特別に名前がつけられたテキストファイルをプログラムが探すことで簡単
に実装される。正確な方法は実装を行う者に任される。システム管理者はこの
機能のオン・オフを変える事を明確に許可する *べきである*。警告に対して
セクション 3.2.4 を参照。
ユーザに対して Finger 要求への応答において、プログラムを実行させる方法
が存在する *可能性がある*。もしこの機能が存在するなら、システム管理者
はこの機能のオン・オフを明確に許可 *すべきである*。警告に対してセク
ション 3.2.5 を参照。
2.5.3. {U} 多義性
コマンドラインにおいて許可される "names" はシステムによって定義されて
いるような "user names" もしくは "login names" を含まなければ *ならな
い*。もし名前があいまいであれば、システム管理者は幾つかの流儀 (セク
ション 3.2.6 に基づく) で返されるべきすべての可能な誘導を行うかどうか
選択する事を許可 *すべきである*。
2.5.4. /W 要求トークン
{Q1} もしくは {Q2} 要求型におけるトークン /W はユーザ情報出力における
回りくどさのより高いレベルを示すため、最良で最後の RUIP によって処理
されるか最悪でも無視されるべきである。
2.5.5. ベンディングマシーン
ベンディングマシーンは {C} リクエストに購入と可能な消費に対して現在利
用できるすべてのアイテムのリストを答える *べきである*。ベンディングマ
シーンは {U}{C} リクエストに個別の製品もしくは製品料金の払い先の詳細な
総計やリストで答えるべきである。ベンディングマシーンは決して決して決し
てお金を消費してはならない。
3. セキュリティ
3.1. セキュリティ実装
Finger のしっかりした実装は最も重要である。実装は攻撃のさまざまな形態
に対してテストされるべきである。特に、RUIP は不正な入力に対してそれ自
身を守るべきである。オペレーティングシステムやネットワークソフトウェア
とともに Finger を供給するベンダはそれらの潜入テストへの実装に従うべき
である。
Finger は Morris worm が全く鮮やかに指摘するように、直接潜入のための
手段の一つである。Telnet, FTP や SMTP のように、Finger はホストのセ
キュリティ近辺のプロトコルの一つである。実装は Telnet, FTP や SMTP の
ように設計、実装およびテストの間のセキュリティ精査を受けるべきである。
3.2. RUIP セキュリティ
警告!! Finger はユーザに関する情報を明らかにする。さらに、そのような情
報は注意深く検討されるであろう。セキュリティ管理者は Finger を実行する
かどうか、どのような情報が応答で供給されるべきかに関して明確な決定をす
べきである。ある既存の実装ではユーザが最後にログインした時刻、最後に
メールを読んだ時刻、読まれていないメールがあるかどうか、一番最近の読ま
れていないメールが誰から来たものかを供給する! これは過程において会話を
探知し、誰かの注意が向けられている所を見つける事を可能にする。情報セキュ
リティを考慮しているサイトは、どのくらいの情報を離れた場所に与えている
かを明確に意識しないで Finger を実行すべきではない。
3.2.1. {Q2} の拒絶
個々のサイトセキュリティ信念に対して、システム管理者は {Q2} の処理を行
う RUIP のオン・オフを個別に変えるためのオプションを与えるべきである。
もし {Q2} の RUIP 処理がオフにされているなら、RUIP は短いサービス拒絶
のメッセージを送らなければならない。"Finger forwarding service denied"
で十分である。この目的は個々のホストに Finger リクエストを転送しない事
の選択を許可する事であるが、もしそれらがそうする事を選択するなら、堅実
に行う事。
全体として、すべてにおいて {Q2} の処理を保証する場合はほとんどなく、
{Q2} 処理を拒絶する方がはるかに勝っている。特に、もしマシーンがセキュ
リティ近辺 (これは、それが外部から内部マシーンのいくつかのセットへの
ゲートウェイである) の部分であるなら、{Q2} を動かす事はそのセキュリティ
近辺を通過する道を供給するという事を知らなければならない。それゆえ、
{Q2} 処理オプションのデフォルトが処理を拒絶することであることを強く推
奨する。これならセキュリティ抱合の注意深い考慮なしにゲートウェイマシー
ンでは利用できなくなるだろう。
3.2.2. {C} の拒絶
それぞれのサイトセキュリティ信念に対して、システム管理者は個別に RUIP
の {C} 受け入れのオン・オフするオプションを与えるべきである。もし {C}
の RUIP 処理がオフになっているなら、RUIP は短いサービス拒絶メッセージ
を返さなければならない。"Finger online user list denied" で十分である。
この意図は、現在オンラインのユーザをりすとしない事を個々のホストに選択
できるようにする事である。
3.2.3. 微少な流出
Finger のすべての実装は、システム管理者に情報アトムが要求に返されるこ
とを合わせられるようにすべきである。たとえば
- 管理者 A はオフィスの場所、オフィスの電話番号、自宅の電話番号、
ログイン/ログアウト時刻を返ことの特別な選択を許されている。
- 管理者 B はオフィスの場所とオフィスの電話番号のみを返す選択が特
別に許されている。
- 管理者 C は要求された情報の最小量、個人のフルネームを返す選択が
特別に許されている。
3.2.4. ユーザ情報ファイル
ユーザが置き換え可能なファイルで配布される情報を RUIP に返す事ようにす
るのは、システムに関するすべての情報を自由に配布できるようにする事と等
しいとみなされる。これは、記述可能なすべてのオプションをつける事と潜在
的に同じである。この情報セキュリティの突破はいくつかの方法で行われる。
ある者はずるがしこく、別のものは直接的にである。これは返された情報を制
御する事を望むシステム管理者の安眠を妨害するだろう。
3.2.5. ユーザプログラムの制作
RUIP に Finger 要求の応答でユーザプログラムの実行を許可する事は潜在的
に危険である。*注意!!* -- RUIP はそのプログラムによって損なわれるシス
テムセキュリティを許可する *べきでない*。この機能の実装は、常にオペ
レーティングシステムにバグがあるため、そのメカニズムのタイプで利用され
うる価値よりももっと大きなトラブルを起こすかもしれない。
3.2.6. {U} の曖昧性
この機能の、悪意のあるユーザの巧妙で粘り強い使用はシステム上のほとんど
のユーザ名リストを渡す事になる。あいまいな {U} の拒絶は {C} リクエスト
の拒絶 (セクション 3.2.2 参照) と同じ傾向を考慮すべきである。
3.2.7. 痕跡の検査
実装はシステム管理者が Finger 要求をログに取れるようにすべきである。
3.3. クライアントセキュリティ
ユーザが初めの RUIP へ要求を実行する、いくつかのクライアントプログラム
普通に存在するだろう。デフォルトにより、このプログラムはすべての非印字
文字をフィルタリングすべきであり、印字可能な 7ビット文字 (ASCII 32 か
ら ASCII 126)、タブ (ASCII 9) と CRLF のみを残すべきである。これは端末
エスケープコードで遊んでいる人、他の人の X ウィンドウ名に変えている人、
もしくは別の卑劣で混乱をもたらす行為を行う人から守るためである。ユーザ
が国際的な文字もしくはコントロール文字を見られるように、二つの別々な
ユーザオプションがこの動作と置き換えられるべきである。
- 一つは ASCII 32 以下のすべての文字を許す
- もう一つは ASCII 126 以上のすべての文字を許す
国際的なデータが使われているような環境に対して、システム管理者は特有な
システム上のすべてのユーザに対してデフォルトである文字オプションを可能
にするためのメカニズムを与えるべきである。これはグローバルな環境変数も
しくは類似したメカニズムで行う事ができる。
4. 例
4.1. null コマンドライン ({C}) の例
Site: elbereth.rutgers.edu
Command line: <CRLF>
Login Name TTY Idle When Office
rinehart Mark J. Rinehart p0 1:11 Mon 12:15 019 Hill x3166
greenfie Stephen J. Greenfiel p1 Mon 15:46 542 Hill x3074
rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
brisco Thomas P. Brisco pe 2:09 Mon 13:37 h055 x2351
laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413
4.2. 名前が指定された ({U}{C}) 例
Site: dimacs.rutgers.edu
Command line: pirmann<CRLF>
Login name: pirmann In real life: David Pirmann
Office: 016 Hill, x2443 Home phone: 989-8482
Directory: /dimacs/u1/pirmann Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
No unread mail
Project:
Plan:
Work Schedule, Summer 1990
Rutgers LCSR Operations, 908-932-2443
Monday 5pm - 12am
Tuesday 5pm - 12am
Wednesday 9am - 5pm
Thursday 9am - 5pm
Saturday 9am - 5pm
larf larf hoo hoo
4.3. あいまいな名前が指定された ({U}{C}) 例
Site: elbereth.rutgers.edu
Command line: ron<CRLF>
Login name: spinner In real life: Ron Spinner
Office: Ops Cubby, x2443 Home phone: 463-7358
Directory: /u1/spinner Shell: /bin/tcsh
Last login Mon May 7 16:38 on ttyq7
Plan:
ught i
ca n
m a
' ... t
I . . i
! m
! ! e
p !pool
l
e
H
Login name: surak In real life: Ron Surak
Office: 000 OMB Dou, x9256
Directory: /u2/surak Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.
Login name: etter In real life: Ron Etter
Directory: /u2/etter Shell: /bin/tcsh
Never logged in.
No Plan.
4.4. 要求タイプ {Q2} ({U}{H}{H}{C}) の例
Site: dimacs.rutgers.edu
Command line: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>
[pilot.njin.net]
[math.rutgers.edu]
Login name: hedrick In real life: Charles Hedrick
Office: 484 Hill, x3088
Directory: /math/u2/hedrick Shell: /bin/tcsh
Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
No unread mail
No Plan.
5. 謝辞
Thanks to everyone in the Internet Engineering Task Force for their
comments. Special thanks to Steve Crocker for his security
recommendations and prose.
6. セキュリティ考察
セキュリティ問題はセクション 3 で論議されている。
7. 著者のアドレス
David Paul Zimmerman
Center for Discrete Mathematics and
Theoretical Computer Science (DIMACS)
Rutgers University
P.O. Box 1179
Piscataway, NJ 08855-1179
Phone: (908)932-4592
EMail: dpz@dimacs.rutgers.edu