要約

  • RFC 933 は Telnet オプション27 OUTMRK を提案し、サーバーが一度送った安全バナーをユーザー側 Telnet がアプリケーション領域の外に保つ構成を示した。
  • WILL/DO はオプション利用の合意であり、具体的なバナーにはさらに ACK または NAK が返された。画面配置は受信側の責任だった。
  • ACK は表示用データの受入れにすぎず、レベルの正しさ、利用者の権限、アクセス許可、暗号学的保護、物理画面での持続を証明しない。

1985年1月の RFC 933 は、遠隔ログイン画面の端にある表示を扱った。一部の軍用セキュリティ構成では Telnet 接続ごとに安全レベルが結び付けられ、対応するバナーを見せる必要があった。当時の方法は、その文字列を各画面のアプリケーション出力に混ぜることだった。

それでは、サーバーが遠隔端末の行数を知り、更新のたびに同じ表示を挿入しなければならない。画面消去やカーソル移動にも弱い。S. Silverman の提案は、サーバーが文字列と位置を一度渡し、実際の装置に近い User-Telnet が領域を確保するというものだった。

名称は OUTMRK、番号は27である。IANA の Telnet Options 登録簿 は現在もこの対応を記録する。登録が示すのは番号の一意性であり、実装、普及、バナーの真実性ではない。

機能への同意と文字列への同意は別だった

RFC 854 の規則に従い、WILL OUTMRK は標示情報を送る意思、DO OUTMRK は受ける意思を表す。WON'T と DON'T は拒否であり、交換しない状態が既定だった。

合意後、サーバーは IAC SB OUTMRK CNTL data IAC SE を送る。CNTL は位置、data は ASCII のバナーである。受信側は満足すれば ASCII 6 の ACK、異議があれば ASCII 21 の NAK を OUTMRK のサブネゴシエーションで返す。

NAK 後に何をするかはサーバーの選択だった。より受け入れやすい文字列を再提案してもよく、接続終了を含む別の対応も取り得る。拒否そのものは、侵害や権限不足を自動的に意味しない。

RFC 855 は、パラメータを話し合う合意と、SB/SE 内の具体的な交換を二段階に分ける。したがって、DO、バナーへの ACK、アプリケーション操作の許可を一つの「承認」にまとめてはならない。

クライアントは表示境界の保管者になった

ACK の後、User-Telnet はカーソル制御を変換し、アプリケーション出力を残りの領域に収める必要があった。バナーは通常の本文ではなく、クライアントが維持する画面状態になった。

D は配置をクライアントに任せ、T と B は上と下を指定する。L と R は左右を示すが、RFC はその正確な意味を未定義のまま残した。共通のコードが、異なる端末の幾何学まで統一したわけではない。

CRLF で複数行を作り、ASCII Group Separator で複数の表示を一つの交換に含められた。最終的な位置決めはすべて受信側が負った。ウィンドウ変更、消去命令、エミュレーターの不具合があれば、正しい ACK の後でもアプリケーションがバナーを覆い得る。

サーバーは WON'T で標示を終えられた。クライアントは DO で開始を求め、合意後にデータが来なければ DON'T で離脱できた。拒否と終了は相互運用の一部であり、例外ではない。

文字列は方針を表したが、執行しなかった

RFC 933 は米国国防総省の信頼できるコンピューター評価基準を動機として挙げる。NIST が公式保存する DoD 5200.28-STD は1985年12月版で、RFC が参照した1983年版を置き換えた後続文書である。RFC の完全な適合を証明する資料ではない。

ただし、そこでは人が読む出力ラベルと強制アクセス制御が別の要件として置かれる。前者は出力の機密性を適切に表し、既定表示の上書きを監査可能にする。後者が主体、客体、装置に対するアクセスを制御する。表示と判断は関係するが同一ではない。

OUTMRK には署名、MAC、鮮度、認証済みチャネル結合、レベル名前空間がない。構文通りのバナーは、ある端点が文字列を提案した証拠でしかない。その意味には、レベルを割り当てる権威、正しいセッションとの対応、信頼できる表示経路が必要である。

バナーは無価値ではない。予期しない環境を知らせ、情報の混在を避ける助けになる。しかし、その効力を支えるのは「方針の割当て、文字列生成、プロトコル受入れ、ローカル表示、別個のアクセス判断」の連鎖である。

反復を減らすと、端末の責任が増えた

サーバーは毎画面の再描画と装置寸法の推測を省けた。代わりにクライアントは、バナー保持、領域保護、カーソル変換、複数表示、サイズ変更を引き受けた。仕事は消えず、保管場所が移った。

監査記録が「オプション27有効」だけなら、提案文字列、応答、実際の位置、表示期間、根拠となるレベル、後続の許可が欠ける。RFC 933 の教訓は、目立つ画面要素を権限の近道にしないことにある。サーバーは提案を、クライアントは表示を、セキュリティ機構は決定を保管する。

出典と限界

根拠は RFC 933、RFC 854、RFC 855、IANA Telnet Options、NIST 公式保存版 DoD 5200.28-STD である。普及、現行対応、製品適合、実際の機密セッション、正しい表示、利用者の理解、運用結果は証明しない。