RFC 1472：有効な秘密情報の行は認証の証拠ではない

要約

1993年6月の RFC 1472 は、PPPの秘密情報を管理可能にした文書である。しかし、その表を認証結果に見せかけなかった点のほうが重要だ。

同時期の RFC 1471 はLCPの管理対象を定義した。RFC 1472は認証設定を独立した任意グループに置いた。そこにはIDと秘密だけでなく、どの認証方式をどの順で試すかを変える変数もあったからである。

pppSecurityConfigTable はリンク番号と優先順位で行を識別した。小さい順位の方式から試す。リンク番号0は、個別行のないリンクに適用する既定値だった。

優先順位は強度評価ではない。プロトコル欄は「試す方式」であって、すでに交渉・実行された方式ではない。既定値も全リンクの実績ではなく、個別設定によって上書きされ得る規則だった。

各行には valid または invalid が付く。無効にした行を実際に削除するかは実装依存だった。したがって管理局は、表に残っていても現在は使われていない行を受け取る前提で、状態欄まで確認しなければならない。

「存在する」と「現用である」は、同じ事実ではなかった。

秘密情報表には、1リンクにつき複数のID/Secret組を置けた。索引は組を区別するが、どれを選ぶかはローカル実装の判断だった。

方向には二つの意味があった。local-to-remote はローカル側が相手に自分を認証させるための組、remote-to-local は相手が提示するとローカル側が期待する組である。同じ値でも方向が違えば、想定される行為者が変わる。

プロトコルも意味を決める。PAPならIDはPeer-ID、秘密はパスワードになり得る。CHAP-MD5ならIDはCHAP Name、秘密は応答計算の材料になる。RFC 1472が両者をオクテット列としたのは、列の型だけでは意味が完結しないからだ。

設定されたIDは人間の身元証明ではない。秘密の保存は、その時点で誰が秘密を保有したかを証明しない。valid も、どの組が選ばれ、相手が何を送り、認証側がどう判断したかを語らない。

RFC 1334 のPAPでは、リンク確立後にPeer-IDとパスワードを送り、Authenticate-AckまたはNakを受ける。後の RFC 1994 のCHAPでは、チャレンジ、計算した応答、認証側の照合、成功または失敗という交換がある。

これらが認証試行の出来事を作る。監査には、リンク、交渉方式、要求またはチャレンジの識別子、応答、資格情報の版、判断を結び付ける必要がある。MIBの一行だけでは、その連鎖を復元できない。

RFC 1661 はさらに段階を分けた。データリンクを確立・試験し、必要なら相手を認証し、その後NCPでネットワーク層を設定する。対応するNCPが開いて初めて、そのネットワーク層のデータグラムを送れる。

資格情報の設定は認証を、認証はIPCPの完了を、IPCPの完了は経路や受信やアプリケーション結果を証明しない。

RFC 1472は、SNMPv2のprivacyを伴わないならこのグループを実装しないよう強く勧めた。MIB viewで機密サブツリーを隔離できた。読み取り専用にすれば書換え権限は減るが、秘密を読まれる危険は残る。

これは管理経路の保護であり、PPPの相手を認証した証拠ではない。保護された書込みが成功しても、相手が後で現れる保証はない。認証イベントがあっても、実際に選ばれた行へ結び付かなければならない。

集中管理は運用を簡単にする一方、誤った既定値、順位変更、公開されたview、古い行の誤読の影響を集中させた。

設定側には、操作者、時刻、リンク範囲、既定値の継承、順位、方式、索引、方向、状態遷移、agentからの読戻しを残す。実行側には、LCP段階、交渉方式、要求やチャレンジ、応答、判断、資格情報の版、NCP状態、トラフィックを残す。

選ばれなかった有効行は在庫であり、認証失敗ではない。無効行が選ばれ続ければ実行ずれである。成功記録を資格情報の版へ結べなければ帰属が欠ける。認証後にIPCPが開かなければ、原因は次の段階にある。

RFC 1472は、管理表が準備状態を語れる一方、まだ起きていない出来事の証明を借りられないことを示していた。