要約

  • RFC 2384 は POP3 のホスト、ポート、メールボックスの識別子、認証方式を一つの URL に収めたが、平文パスワードは構文から除外した。
  • それでも URL 自体に保存済み秘密を使う権限はない。信頼済みの出所、ローカル方針、利用者確認、サーバー検証、または再利用可能な情報を漏らさない方式が別途必要だった。

持ち運べる設定が生んだ境界

POP3 のメールボックスへ接続するには、単なるアカウント名以上の情報が要る。サーバー、場合によっては標準外のポート、対象メールボックスを示す識別子、そして認証方式である。RFC 2384 はそれらを pop://<user>;auth=<auth>@<host>:<port> という形にまとめた。

省略できないのはホストだけだった。ポートを省けば 110 になる。利用者と認証方式は書いても書かなくてもよい。URL の文字集合に直接入らないものは符号化できる。プログラムは一本の文字列を受け取り、接続を始めるのに必要な要素を取り出せた。

しかし、始められることと正当であることは違う。文字列を解析できても、出所が信頼できるとは限らない。完全なホスト名があっても、そのホストへ秘密を渡してよいとは限らない。接続できても認証成功ではなく、認証成功も目的のメールボックスを開いた証拠ではない。

RFC 2384 の重要性は POP 用 URL を定義したことだけではない。設定の見た目が完成していても、現実の結果まで完成したことにはしなかった点にある。

URL にパスワードがなくても、パスワードは動き得る

仕様は URL 内の平文パスワードを許さなかった。URL は文書や設定データ、ログ、画面を経由しやすい。そこへ秘密そのものを埋め込まないという最低線には明確な意味がある。

一方で、クライアントは以前の接続で得たパスワードを保存しているかもしれない。URL を開いた時点で利用者へ入力を求めることもできる。APOP を使うことも、AUTH を通して SASL 方式を呼ぶこともできる。つまり、URL が秘密を含まなくても、秘密を送る原因にはなり得た。

RFC はこの差を正面から扱った。URL は容易に信頼できない出所から届く。誤ったサーバーへ資格情報を送ればアカウントが危険になる。そして平文パスワードを保存するクライアントは、指定ホストへそのパスワードを渡す明示的な許可なしに、POP URL への反応として使用してはならなかった。

「リンクに秘密を書くな」だけではない。リンクを受け取ったソフトウェアが、手元の秘密に対して何をしてよいかが問われていた。

同じ文字列でも、認可と認証は別の役割

文書は簡便のため両方を「user name」と呼びつつ、機能の違いを説明した。認可識別子は、どのメールボックスへ入るかを決める。認証識別子は、誰の資格情報を照合するかを決める。値が同じでも、そこで発行される判断は同じではない。

認証方式も独立した指定だった。URL は SASL 方式、APOP、あるいは拡張コマンドを示せる。特定方式が指定されたなら、利用者の明示的な許可なしに別方式へ置き換えるべきではない。指定は提案を狭めるものであり、クライアントに見えない変更権を与えるものではなかった。

対照的に ;AUTH=* は選択を開いた。クライアントは適切な方式を選び、サーバーが対応する方式を利用できる。さらに、利用者名だけがあり方式が省かれた URL では、このワイルドカードが暗黙に仮定された。短い表記ほど、かえって未記述の方針を多く抱える場合があった。

仕様がワイルドカードに特別な注意を求めたのは、弱い方式へフォールバックする可能性があるからだ。56 ビットを超える暗号を「強い」とした記述は 1998 年の歴史的表現であり、現在の安全基準ではない。ただし、省略が方式選択権を移し、フォールバックが安全性を決めるという構造は残る。

資格情報を動かすための五つの根拠

RFC 2384 は、URL 構文だけで信頼を解決しようとしなかった。認証を要求する URL を処理するとき、少なくとも一つ満たすべき条件を五つ示した。

URL が、クライアントによって検証されサイト方針上も信頼された参照サービスから来ていること。明示的なローカル方針が、URL 内のサーバーへの接続を許していること。利用者が、そのドメインへ指定資格情報または方式を使うことを確認すること。危険なクライアント情報を渡す前に、認証方式がサーバーを検証すること。あるいは、その方式が将来の接続を侵害するために再利用できる情報を相手へ明かさないこと。

五つは同じ信頼を言い換えたものではない。検証済み参照は出所の証拠、ローカル方針は管理上の委任、確認は特定状況への人の判断、サーバー検証は相手の同一性、不開示型の方式は誤接続時の損失上限を扱う。

URL の作成者は接続先を提案できる。しかし、その事実だけで資格情報保管庫を操作する権利までは得ない。設定の可搬性と権限の可搬性を分ける設計だった。

相対 URL を禁じても、絶対 URL が信頼済みになるわけではない

POP URL は相対形式を許されなかった。文書の基底 URL からホストを借りることはできず、接続先を絶対形式で書く必要があった。これによって周辺文脈に依存する曖昧さは一つ減った。

それでも、完全なホスト名は信頼の証明ではない。攻撃者も絶対 URL を書ける。正しく符号化された文字列が誤った運営者を指すこともある。ドメイン末尾だけを信頼する規則は、想定より広い範囲を許可し得る。構文が完全であることは解釈可能性の証拠であって、実行許可の証拠ではない。

したがって二つの記録が要る。パーサーが何を読み取ったか。そして、どの根拠でその宛先へ資格情報を渡したか。前者だけを残して後者を推測してはいけない。

印刷された例を、実行が訂正した

RFC 2384 の二件の正誤情報は、この境界を数字で示す。APOP の例にあるダイジェストは、同じ例のサーバーチャレンジとパスワードから得られる値に一致しなかった。Verified の Errata 2943 が正しい値を示した。別の例は SCRAM-MD5 と書いたが、当時該当する方式は CRAM-MD5 だった。Errata 2942 は、名称変更だけでなく符号化された交換も直す必要があるため、文書更新待ちとなった。

これは実運用の侵害を示す資料ではなく、URL 方式全体を否定するものでもない。示すのは、もっと狭く強い事実だ。プロトコルらしい転記であっても、バイトを検証すれば実行不能な場合がある。方式名、応答計算、認証結果、メールボックスへの到達は、それぞれ別の証拠である。

動くコードは見た目を受理しない。ダイジェストは入力と合うか合わないかのどちらかであり、実装は正しい名前の方式を認識するかしないかのどちらかだ。現実は整った誌面ではなく、計算と相互作用の境界で確定する。

最小の共通仕様と、局所に残された判断

POP3 は意図的に単純だった。RFC 1939 は認可、トランザクション、更新の状態を分けた。RFC 1734 は AUTH を定義し、RFC 2222 は SASL の枠組みを与え、RFC 2449 は後に能力の通知を加えた。RFC 2384 はそれらを一つの巨大な URL へ押し込まなかった。

共通に決めたのは、サービスをどう表現し、どの方式を提案するかまでだった。出所の信頼、接続先の認可、利用者の確認、サーバーの検証、資格情報の放出は、現実の証拠を扱えるクライアントとローカル方針に残した。

この薄い共通層が設定の移動を可能にした一方、受け取った文字列へ無条件の執行力を与えなかった。将来の判断を局所に置くことで、同じ表現を使う実装同士が異なる安全境界を維持できた。

接続後も証拠は分ける必要がある。ホストへの到達は秘密送信の認可ではない。認証成功は目的メールボックスの開放ではない。メールボックスを開いても目的メッセージを取得したとは限らない。取得したバイトがアプリケーションで正しく保存・表示されたとも限らない。

RFC 2384 はメールボックスを指し示しやすくした。そのうえで、指し示すことを鍵の引き渡し命令にしなかった。

情報源