要約

  • RFC 1258 は BSD rlogin を、Internet 標準ではないが広く使われた共通実装として記録した。接続開始時には空文字列、client user 名、server user 名、端末種別/速度の四つの文字列が送られる。
  • 信頼済みの user または host を設定すればパスワード入力を省けた。しかし RFC は、一つの信頼済み host の侵害が設定済みの全システムを開き得ること、信頼 host が通常 host 名で指定されること、書込み可能な信頼リストが追加を受け得ることを明記した。

接続開始は要求を読める形にした

rlogin の最初の交換は簡潔だった。TCP 接続のあと、client は nul 終端の文字列を四つ送る。最初は空、続いて client user 名、server user 名、端末の種別と速度である。server はゼロの一バイトを返し、文字列を受け取り data transfer mode に入ったことを知らせる。

この並びは、見た目には完結した身元表現に見える。二つの user 名があり、要求する account があり、server の応答もある。しかし各要素の範囲は小さい。client user 名は client が提示した名であり、server user 名は求めた account であり、端末情報は表示方法に関するものだ。ゼロの応答は、認証済みという宣言ではなく、開始部分を受け取って次の protocol 段階へ移ったという合図である。

RFC 1258 が既存の common implementation を文書化したのであって Internet standard を指定しなかったことも、この差を見えやすくする。Unix host 間で Telnet より多くの端末意味論を運べたことは使われた理由を説明する。けれども、そこに並ぶ文字列は、送信 host を誰が操作していたか、提示された user が正しいか、ローカルの規則が誰により変えられたか、session が後に何をしたかを独立には証明しない。

信頼されたのは name ではなく受信側の判断だった

password を省く働きは開始文字列ではなく、受信側の trust configuration にあった。RFC 1258 は、trusted users and/or hosts の class を用意して、password entry なしに本人として log on できるようにすると説明する。これは server 側の admission 判断であって、connection が持ち運ぶ認証済みの身分証ではない。

RFC の cautionary tale は、その判断の材料を host name と呼ぶ。host name は管理にも到達先の表現にも役立つ。しかし rule に書かれた name は、名前解決、network、実在の機械、操作している人を一つの確認済み事実にはしない。組織の domain name server または network が compromise されれば、untrusted host が trusted system を装える、と RFC は言う。特定の事件を報告しているのではない。hostname による便宜を、独力で十分な authentication と呼ばないための境界を示している。

もう一つの境界は trust record の書込み権である。user の trusted logins の file が他の user に writeable のままなら、untrustworthy な追加が可能になる。接続文字列と server の応答が正しく見えても、password skip の根拠となるリストそのものが既に別の状態にあるかもしれない。protocol 上の可視性と設定の保全は別の問題である。

一台の侵害は一回の login より広く作用する

RFC 1258 の重要な指摘は範囲にある。trusted host からの password authentication bypass は、一台が compromised されただけで、その host を信頼する全 system を開くことがある。問題は password を一度入力しなかったことではない。一つのローカル設定が、複数の machine の結果を結びつけたことである。

workstation 一台、user の list 一つ、既知の origin を受け入れる server 一台は、それぞれなら小さな手間の削減に見える。組み合わされると admission の graph になる。最初の machine が変化すると、直接変更されていない system にも意味を持つ。そこでは同じ由来の主張を継承して受け入れるからである。

RFC は、すべての system を相互に passwordless にする代わりに、一台の workstation から他の常用 system へという、より狭い arrangement に触れる。それは host の本人性を証明する設計でも、危険を消す保証でもない。信頼の scope は一回の端末操作ではなく、edge がどう結ばれているかで決まるという観察である。

端末が使えても、前提は証明されない

rlogin は remote echo、flow control、window size、output flushing、local escape を扱った。遠隔の画面が自然に動けば、本来の作業が続いているように感じる。だが terminal stream は data transfer mode と byte 処理について何かを示すだけである。trust file の writer に権限があったこと、name が期待する host を指したこと、skip の条件が保たれたこと、あるいは application の結果を保証しない。

RFC 1258 は Kerberos などの secure authentication extensions にも触れ、password を省く便利さを残しつつ compromise の可能性を減らし得ると述べる。これは四つの初期文字列が既にその authentication を含んでいたという話ではない。便利な source rule と、より強い根拠の間に層が残っていたという同時代の認識である。

出典と証拠の限界

本文は RFC 1258 — BSD Rlogin のみを使う。1991 年の文書状態、terminal protocol、当時の TCP contact port、開始文字列、data-mode 応答、trusted-host password bypass と、名前・network・writeable file・authentication extension の注意を支える。現在の利用、現行の port 状態、特定 host の侵害、個人の身元、権限、実行結果を証明するものではない。