要約

  • RFC 2069はBasicの平文パスワード送信をchallenge-responseへ置き換えた一方、サーバーに残るH(A1)を、そのrealmではパスワード同様に扱うべき実行可能な秘密と位置づけた。
  • 基本responseが結び付けたのはnonce、HTTPメソッド、要求URI、realm内の秘密知識であり、内容の暗号化、全フィールドの完全性、利用者の意思、認可、処理結果ではなかった。
  • IPアドレスと時刻を含むnonceは状態を持たずに利用範囲を狭められる。しかし再利用を確実に拒むには、期限まで使用済みresponseを覚える必要があった。

二つの正しい計算

RFC 1945のBasic認証では、利用者名とパスワードはBase64で表現されて送られた。表現を変えても暗号化にはならず、通信を見た者は再利用可能なパスワードを得られた。1997年1月のRFC 2069は、サーバーのnonceに対してクライアントが計算したresponseを返す方式を示し、パスワードそのものを回線から外した。同時期のRFC 2068がHTTP/1.1の文脈を与えている。

この変更は盗聴への明確な改善だった。ただし仕様は自らを弱いアクセス認証と呼び、本文を暗号化せず、パスワードを最初に安全に共有する方法も規定しなかった。中間者、偽サーバー、辞書攻撃、replayも残る。公式記録が示す標準史と、実際の製品採用や設定状況も区別しなければならない。

responseが語れる範囲

RFC 2069で具体化されたHは、RFC 1321のMD5だった。主要な式は次の通りである。

A1 = username : realm : password
A2 = Method : request-URI
response = KD(H(A1), nonce : H(A2))

realmはA1の内部にあり、保護空間を分ける。A2にはメソッドとURIが入る。nonceはサーバーが発行したchallengeである。したがって一致したresponseは、「このrealmの有効な秘密材料を持つ者が、このnonce、メソッド、URIに対応する値を作った」という限定的な証拠になる。

サーバーはAuthorization中のuriが実際に扱う資源と一致することも確認しなければならない。途中のproxyがrequest lineを変え得るからだ。数式だけ合っても、別の資源に結び付けてはならない。

一方、基本式には他の要求ヘッダー、通信経路、応答本文、利用者の意思、権限判定、データベースのcommitは含まれない。RFC 2069はPOST/PUTの本文と一部メタデータに対して別の任意digestを定義した。任意の追加項目が必要だった事実は、基本responseがメッセージ全体の署名ではないことを示す。

読めない値にも鍵の力がある

サーバーは平文パスワードを保持せず、usernameとH(A1)だけで検証できた。ここで「ハッシュだけ」という説明が生まれる。しかしRFC 2069の保存に関する節は、その説明を許さない。H(A1)のファイルを盗んだ者は、パスワードを復元しなくても、そのrealmの文書へ直ちにアクセスできる。ゆえにファイルは平文パスワードを含むかのように保護しなければならない。

これは範囲付きの等価性である。realmが計算に入るため、一つのH(A1)が同じパスワードを使う別realmへ自動的に通用するわけではない。だが元のrealmでは、受理されるresponseを生成する能力になる。さらに弱いパスワードなら、候補をオフラインで試す余地も残る。

秘密を「読めるか」ではなく「何を実行できるか」で分類すると、backupやreplicaの意味も変わる。可用性のための複製は、そのまま認証能力を持つ場所の増加である。

期限と使用回数は別の状態

RFC 2069が推奨したnonceは、おおむね次の材料を含む。

H(client-IP : timestamp : server-private-key)

受信時に再計算すれば、サーバーは発行元、アドレス、時限を確認できる。challengeを一件ずつ保存しなくてよい。しかしこの方式が証明するのは「まだ時間窓の内側」ということまでで、「初めて提示された」ことではない。

仕様は通常のGETなら、盗聴者はすでに同じ文書を見ているのでreplayの価値は低いと説明した。それでも動作を起こすGETはあり、POST/PUTの再送は偽のform dataやファイルを生み得る。副作用の有無はメソッド名だけでも決められない。

再送を一切許さない用途では、一回限りのresponseを用い、nonceの期限まで使用済みdigestを記憶して二回目を拒否する。その強い判定には保存、検索、期限切れ処理、衝突処理が必要で、複数ノードなら整合性も必要になる。一回性は暗号文字列の属性ではなく、運用状態が提供する機能だった。

後の修正を初版へ書き戻さない

1999年のRFC 2617は2069を置き換えた。RFC Editorの記録はその関係と、旧版の一部任意要素に問題が見つかったことを明記する。新しいqop経路にはclient nonceであるcnonceと、同じnonceに対する要求数ncが入った。サーバーが自分のcountを維持し、同じncを再び見ればreplayを検知できる。qop=auth-intでは本文hashもA2に入る。

ただしqopがなければ、互換性のためRFC 2069式が残る。したがってcnonce、nc、統合された本文保護を1997年の基本方式の保証として語ることはできない。

2015年のRFC 7616とその公式記録はSHA-256とSHA-512/256を追加し、MD5を非推奨とした。それでもH(A1)ファイルがrealm内で平文パスワード同様の力を持つという警告は残った。人が覚えられる弱いパスワードは算法変更だけでは守れず、HTTPSの利用も推奨された。

RFC 9110の現代HTTP意味論に照らしても、credentialsの受理と、資源へのauthorization、処理のcommitは別である。

ログを結果へ飛躍させない

有効なDigestの記録から、「ある検証ノードが、特定のsecret、nonce、method、URIの関係を受け入れた」とは言える。本文が覆われたか、nonceが未使用だったか、全ノードが同じstateを見たか、usernameが誰に対応したか、その主体が許可されたか、処理が一度だけ完了したかは別の証拠を要する。

Lu HengのRunning-Code Primacyは、文書ではなく実際に動く検証を見ることを求める。Minimum Initial Specificationは、共通の決定的規則と各参加者の将来判断を分ける。ここでは式が共通で、nonceの寿命、state予算、realm運用、authorizationがローカルな決定である。

Reality Layersの視点を加えると、ハッシュ一致という記号を、意思や効果という実行層へ昇格させてはならない。証拠は、自分が観測した境界で止まるべきだ。

参照資料