要約

  • RFC 1492 の著者は、存在していたTACACS原仕様を著作権上の事情で入手できず、Ciscoの単純版実装を手掛かりに説明を再構成した。
  • その実装は原仕様と互換だと「考えられていた」にすぎず、RFC自身が、原文の発見によって記述の一部が誤りと判明し得ると警告した。
  • UDPのnonce、デーモンの応答、端末サーバーの実行、接続先の成立、アカウンティングは、それぞれ別の証拠である。

Informational という分類は脇役ではない。RFC 1492 は Internet Standard を定めていない。公開されたのは、運用されていた仕組みを他者が調べられる形にした記録であり、失われた原文を認証する証書ではなかった。

本文によれば、TACACSの原仕様は存在した。しかし著者は著作権上の問題から入手できず、そのことが新しい文書を書く主な理由になった。Cisco Systemsとの協力で、原仕様と互換だと考えられていた単純版の実装を観察できた。ただし比較対象の原文がない以上、互換性は実証済みの同一性ではない。

実装は記憶より強い証人になり得る。入力に対する出力、フィールドの幅、分岐を再現できるからだ。一方で、コードは仕様の省略、製品固有の拡張、あるいは長く残ったバグも含み得る。RFC 1492 は、後日原仕様が見つかれば自らの一部が誤りになる可能性を明記した。これは欠点の隠蔽ではなく、証拠の範囲を固定する操作だった。

単純版と拡張版は同じ証明を持たない

文書は単純TACACSと拡張TACACSを分けている。原仕様との互換が想定されたのはCiscoの単純版である。拡張プロトコルはCiscoの端末サーバーで使われ、ミネソタ大学の分散認証システムでも採用された。これは名前のある環境での利用証拠だが、普及率や全実装の一致を示す統計ではない。

原文が読めないと、最も入手しやすい実装が事実上の基準になりやすい。相互運用を急ぐ開発者は、その実装の癖まで模倣する。やがて「この製品とつながる」が「原仕様に従う」に置き換わる。RFCが残した留保は、この置換を見抜くための目印である。

LOGINの後にもCONNECTの判断があった

基本単位はクライアント要求とデーモン応答である。すべての要求には応答が必要で、したがって拒否も可能だった。LOGINは資格情報を認証し、成功すれば端末サーバーがログイン接続を開始できた。CONNECTはすでに存在する接続の内部で、特定の宛先アドレスとTCPポートへの接続を開いてよいか尋ねた。

LOGINの成功は、あらゆる宛先への包括的許可ではない。CONNECTの肯定応答も、宛先接続の成立を証明しない。デーモンがローカルなデータとアルゴリズムで判断し、端末サーバーがそれを実行し、ネットワークと宛先が結果を決める。会計記録があるなら、それもさらに別のレシートである。

判断アルゴリズムとデータはデーモン運用者が管理した。同じ書式を話す二つのサイトが異なる答えを返しても不思議ではない。プロトコルは判断を運べるようにしたが、世界共通のポリシーを供給したわけではない。

nonceが証明したのは対応関係だけ

歴史的なUDP形式はポート49を使い、要求にnonceを入れ、応答がそれをコピーした。クライアントは到着したdatagramを未完了の要求に対応付けられる。nonce一致は利用者やサーバーを認証せず、改ざん防止や暗号化も提供しない。

タイムアウト後、UDPクライアントは再送できた。サーバー側は再送しない。RFCは、この構造が冪等な要求を前提にするように見える一方、実際の要求は冪等ではないと指摘する。最初の応答だけが失われ、処理はすでに大きな接続状態を変えていたかもしれない。二つの同一datagramを一つの無害な操作にまとめるには、時刻、状態、再送理由、端末側の実行記録が要る。

平文の資格情報は先に流れていた

UDP形式もTCP形式も、ユーザー名とパスワードを平文で運んだ。セキュリティ節は、ネットワーク監視者がその組を収集できること、サービスが資格情報を探る面を作ることを警告している。後からACCEPTが返っても、先に通過した平文は保護されない。

TCP形式が解いたのは配送とフレーミングの問題だった。歴史的TACACSとは明示的に非互換で、TCPに配送を任せ、より単純な枠と広い応答領域を選んだ。順序どおりの受信は、相手の真正性、秘密性、ポリシーの正しさ、実行結果を保証しない。

TACACS+は後世の比較である

RFC 8907 は後に、TACACS+を認証・認可・アカウンティングを分けるスイートとして記録した。同時に、プロトコルセッションが必ずしも利用者や利用者行為に対応せず、認証要求が認可要求と自動的に関連付くわけではないとも述べる。この整理は証拠を分離する助けになるが、1993年のTACACSを遡及的にTACACS+へ変えてはならない。

RFC 927 のTELNET TUID引き渡しも別の課題である。RFC 1492が所有する歴史は、入手不能な仕様と観察可能なデーモン実装の間をどう記述したかにある。

結局、標準化と記録、ソースと実装、判断と効果を一語に畳まないことが重要だ。動くコードは有力な証拠である。しかし、その強さは証明できる範囲を正確に狭めたときに初めて役に立つ。

出典