要約

  • RFC 927 は Telnet オプション26 TUID を提案し、すでにユーザーを認証したホストから、同意した接続先へ32ビットの利用者識別子を渡せるようにした。
  • 識別子より先に WILL TUID と DO TUID の合意が必要であり、WON'T と DON'T は拒否を通常のプロトコル結果として表現した。
  • 4オクテットは送信側が主張する利用者を指したにすぎない。パスワード確認、接続先での権限、暗号学的保護、アプリケーションの実行結果を単独では証明しない。

1984年12月、BBNのBrian A. Andersonは RFC 927 TACACS User Identification Telnet Option を公表した。課題は端末利用者にとって分かりやすい。Terminal Access Controller（TAC）へ名前とパスワードを入力して認証されたのに、TACが目的のホストへTelnet接続を開くと、もう一度ログインを求められることがあった。

提案された TUID のオプション番号は26だった。利用者側Telnetは、利用者を認証してUUIDを送る意思を表す。サーバー側Telnetは、その認証を受け入れる意思を表す。両者が合意すると、32ビットの二進数がサブネゴシエーションで送られた。

これはパスワードを4オクテットへ圧縮する仕組みではない。最初のホストが行った認証について、次のホストへ証言する仕組みだった。操作が一つ減る代わりに、接続先は証言者を信頼できるか判断することになった。

最初の認証は、次の運用者に向けた主張になった

RFC 927によれば、TACACSでは、利用者がTAC経由でホストへ接続する前に正しい名前とパスワードの組を示す必要があった。接続先による二度目の認証を避けるため、TACは利用者の「proven identity」、すなわちUUIDを渡せると説明された。

ただし、証明の手続きそのものは回線を渡らない。接続先は元のパスワード交換を観測せず、4オクテットから再検証することもできない。受け取るのは「このTACは、この番号の利用者を認証した」という主張である。

文書はその直後に境界を置く。ホストはTACの認証を受け入れてもよいし、受け入れなくてもよい。送信側は自分が行った確認を述べられるが、接続先のサービスを利用できる者を一方的に決められない。

値を送る前に、信頼を交渉した

RFC 854 のTelnetは、Network Virtual Terminalを基礎に、追加機能をオプションとして交渉する。WILL、DO、WON'T、DON'T により、提案、要求、承諾、拒否を表現した。RFC 855 はパラメーターを伴うオプションについて、まず双方がオプションの利用に合意し、その後で値をサブネゴシエーションする順序を定めた。

TUIDでは、IAC WILL TUID が利用者側による認証と識別子送信の提案を意味した。IAC DO TUID はサーバー側がその認証を受け入れて値を求めることを意味した。WON'T は送信側の役割を拒み、DON'T は接続先が信頼を拒んだ。

4オクテットを運ぶ形式は IAC SB TUID <uuid> IAC SE である。サーバーが先に要求しても、利用者側が先に申し出てもよい。しかし、識別子だけを先に送り、合意の代わりにすることはできない。

既定値も拒否だった。未実装の利用者側は DO に WON'T を返し、未実装のサーバー側は WILL に DON'T を返した。知らない機能が暗黙の信頼へ変わらず、通常のTelnetと接続先のローカル認証に戻れる設計である。

このUUIDは32ビットだった

現在のUUIDから128ビット形式を思い浮かべると、RFC 927を読み違える。文書が定義する <uuid> は「32 bit binary number」である。例では数値1、255、全ビットが1の値をそのままTelnetのサブネゴシエーションへ配置する。

Telnetではオクテット255が IAC なので、識別子の中に255が現れた場合は二重に送る必要があった。数値255なら、三つのゼロの後に IAC IAC が並ぶ。これは制御とデータを区別するバイト透過の規則であり、暗号化でも署名でもない。

RFC 927は、番号の世界的な発行者、衝突の処理、有効期限、再利用、nonce、時刻、MAC、署名、チャネルバインディングを定めていない。接続先のローカルアカウントへの対応付けも規定外である。正しく符号化された番号でも、既知の発行元、名前空間、信頼方針がなければ誰を指すかは確定しない。

したがって、パケット記録はTUID有効化後に4オクテットが利用者識別子として提示されたことを示せる。実際に誰がパスワードを入力したか、送信元が正しく運用されていたか、番号が再割当てされていないか、接続先が正しいアカウントを選んだかまでは示せない。

認証の受入れは、操作の許可ではない

上流の認証を受け入れることは、「この接続は誰を表すと扱うか」に答える。RFC 927は、その人にファイル、コマンド、特権モード、アプリケーション処理を許可する規則を与えていない。権限は接続先が別に決める。

後の RFC 1492 は、1993年にTACACSを再構成したInformational文書である。端末アクセス装置が名前とパスワードをdaemonへ問い合わせ、ホストが受理または拒否する流れを記す。一方、既存のログイン接続内で特定のアドレスとポートへの接続を許すかは、別の CONNECT 要求として扱われた。

この資料には明示的な限界がある。著者は著作権上の理由で元のTACACS仕様を入手できず、将来の情報によって記述の一部が誤りと判明する可能性を警告した。後世の文書を完全な同時代記録として扱ってはならない。

RFC 8907 はさらに後のTACACS+を記述し、認証、認可、アカウンティングを分離する。また、プロトコルレベルで認証要求と認可要求を関連付ける仕組みはないとする。TACACS+の意味を1984年へ戻すことはできないが、「誰か」と「何を許すか」が別の判断だと表す語彙にはなる。

拒否できることも相互運用だった

RFC 927は、同意する二つのホストならTUIDを使えるとし、同一拠点内のホストを例に挙げた。共通の中央ID機関を設けたのではない。標準化されたのは、提案、承諾、拒否、識別子の形式であり、信頼方針ではなかった。

IANA Telnet Optionsレジストリ は現在も26をTACACS User IdentificationとしてRFC 927に結び付ける。これは番号の一意な割当てを示す。広い実装、現在の利用、現代のフェデレーションとの直接の系譜を示すものではない。

DON'T TUID は相互運用の失敗ではなく、権限境界の表現である。接続先が拒否できるからこそ、送信元の利便性が接続先への命令へ変わらなかった。

画面を簡潔にするほど、記録は分けて残す

利用者には利点がすぐ見える。接続先の運用者には別の費用が生じる。信頼するTACを管理し、その番号空間を理解し、ローカル対応表を保ち、侵害や運用者変更が起きれば信頼を撤回しなければならない。

ログが「ログイン成功」だけなら、構造は失われる。ローカルパスワードを確認したのか、TUIDを受け入れたのか、どのアカウントへ対応付けたのか、コマンドを認可したのか、単に接続を開いたのかを区別できない。

送信元の認証結果、WILL/DO、TUID値と名前空間、接続先の信頼判断、アカウント対応、個別認可、アプリケーション結果は別々のイベントとして保持すべきである。一つの機械可読な成功値に、後段すべての権限を背負わせてはならない。

RFC 927の歴史的価値は、万能なデジタルIDを完成させたことではない。あるホストが自分の認証について語り、別のホストがそれを聞くと決めたときだけ、二度目のログインを省けると示したことにある。UUIDは接続を渡った。信頼する責任は接続先に残った。

資料と限界

本稿はRFC 854、855、927、IANAレジストリと、限定的な後代比較としてRFC 1492、8907を用いる。これらは構文、文書上の動機、番号割当て、後の概念区分を示す。導入規模、暗号学的安全性、現代のフェデレーテッドログインとの直系関係、実際のセッション成功は示さない。