要約

  • RFC 7616のncは、クライアントがその要求に含まれるサーバーnonceを使って送った要求数である。サーバーが対応する状態を保てば、同じ値の再出現からリプレイを検出できる。
  • Digest計算はその値を資格情報由来の材料、nonce、HTTPメソッド、要求URIなどに結び付けるが、グローバルな要求ID、認可判断、アプリケーション実行記録には変えない。
  • 重大な処理には別の操作IDと永続的な結果照会が要る。新しい正しいDigest認証は再試行者が秘密を知ることを示しても、前回の試行が無効だったとは示さない。

00000001が台帳に見えてしまう理由

運用画面は順序のある数を好む。増分があれば履歴があり、認証計算に入っていれば履歴まで検証されたように感じる。HTTP Digestでは、クライアントが00000001から始め、同じサーバーnonceに対してncを増やし、client nonceとともに送る。サーバーが自分のカウントを保持していれば、同じ値を二度見た時にリプレイと判断できる。

これは確かな利点である。同時に、射程が決まった利点でもある。

RFC 7616が数えるのは、その要求が持つnonceでクライアントが送ったとする要求の本数で、現在の要求も含む。サーバーがそれらを受理したとも、一つのプロセスに届いたとも、同じ順番で業務状態が変わったとも書かれていない。nonceの外で一意になるわけでもない。nonceが更新されれば数列は始まり直し、別クライアントや別のprotection spaceにもそれぞれの系列がある。認証の文脈が切り替わったのであって、業務の歴史がリセットされたのではない。

従ってncが答えられるのは、認証器がそのnonce交換に結び付けて持つ状態の中で、同じカウントを既に見たか、という問いだ。どの永続取引が生じたかという問いには答えない。

カウンターには状態を持つ相手が要る

クライアントが申告した数は、サーバー側のコピーと比較されて初めてリプレイ証拠になる。Digest計算から切り離したncは自己証明ではない。ログに8桁だけ残っても、nonceの寿命や適用範囲は復元できない。

nonceの中身と運用は実装に委ねられている。サーバーはクライアントから見て不透明なnonceを発行し、利用できるクライアント、資源、時間、回数を制限できる。一回限りにして使用済み状態を記憶すれば即時のリプレイに強いが、状態コストが増え、パイプライン要求とは相性が悪い。長めのnonceとncを組み合わせれば、複数要求が一つのchallengeを共有しつつ、多くの防御効果を残せる。

この選択幅こそ、ncを普遍的な台帳にできない理由だ。適合する二つのサービスでも寿命と保持範囲は異なり得る。クラスタではリプレイ状態を共有するか分割するかを決めなければならない。フェイルオーバー、状態喪失、nonce更新は認証層の記憶を変えるが、アプリケーションDBの状態は語らない。仕様は比較の材料を与え、配備がその材料の保管責任を持つ。

Digestが実際に結合する範囲

qopを使う場合、応答値はパスワード由来の材料、サーバーnonce、nc、client nonce、qop、A2のハッシュから計算される。qop=authのA2はHTTPメソッドと要求URI、qop=auth-intではさらにentity bodyのハッシュを含む。これにより、protection space内で秘密を知っていることを示し、特定のリプレイや変更を検出可能にする。

境界は二重に重要だ。第一に、auth-intでも大半のHTTPヘッダーは完全性保護の外にあり、RFC 7616は中間者が変更できると警告する。第二に、認証はアプリケーションの認可ではない。正しいDigestは設定された秘密を知る主体だと判断する材料になるが、その主体に送金、削除、鍵更新を許すかは現在の業務方針が決める。

Rifaat Shekh-YusefはIETF合意文書の編集者かつ共同著者であり、全機構の発明者ではない。nonce countはRFC 2617にも既にあった。RFC 7616はそれを維持しながら、SHA-256とSHA-512/256、アルゴリズム交渉、username hash、詳しい安全性分析を加えた。強いハッシュは規定された計算を改善する一方、人が覚えられるパスワードへの辞書攻撃をalgorithm agilityだけで解決できないことも明記した。

認証の応答は業務の受領証ではない

Digestには応答側の仕組みもある。Authentication-Infoはrspauthを含められ、対応する要求のclient nonceとncも示す。サーバーがユーザーの秘密を知ることを示す相互認証に使え、auth-intなら限定的な応答完全性も得られる。

それでも業務受領証ではない。再掲されたncは認証応答と要求を対応付けるが、決済ID、ジョブID、コミット順序、ロールバック状態、照会可能な結果は定義しない。認証後に要求がキューへ渡り、workerが確定した後でHTTP応答だけ失われることがある。クライアントは新しいchallengeを受け、正しい再試行を作れる。二つのDigest交換がともに正しくても、業務処理は二度起こり得る。

これはnonce countの欠陥ではなく、周辺の自動化が分類を誤った結果だ。資格情報のリプレイと効果の重複は関係するが、同じ制御面ではない。

一つの成功表示を五つの記録に分ける

重大なサービスは少なくとも、認証結果、nonce文脈に対するリプレイ判断、アプリケーション認可、永続的な操作ID、確定したpostconditionを別々に記録すべきだ。操作が完了しても応答が観測されない場合があるため、配送記録まで必要なシステムもある。

アプリケーション層のidempotency keyなら、複数の再試行を一つの意図へ結び付けられる。そのIDで結果を照会できれば、timeout後に新しい認証成功から推測せず「何が起きたか」を確認できる。RFC 7616はどちらも定義しない。サービス設計と永続化、運用ガバナンスの仕事であり、ncの意味を膨らませて得る機能ではない。

厳密な読み方はこのカウンターを軽視しない。観測できるリプレイのために使い、意味を与えるサーバー状態を守り、適切ならauth-intを使い、機密性がないためHTTPSを併用する。その先で止まることが重要だ。認証カウンターに、観測していないアプリケーション結果を証言させてはならない。

出典