HTTP ダイジェストアクセス認証

本書で使用されるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は [RFC2119] に記載されたとおりに解釈されます。

明瞭性と可読性のために、本書の例中の拡張パラメータやヘッダーフィールドおよびパラメータは複数行に分けられることがあります。本書でインデントされた行は、前の行の継続であることを意味します。

本仕様は、[RFC5234] の拡張 Backus-Naur Form (ABNF) 表記法および [RFC7230] の ABNF List 拡張を使用します。

ダイジェストスキームは単純なチャレンジ・レスポンスパラダイムに基づいています。ダイジェストスキームは nonce 値を用いてチャレンジを行い、ユーザー名のハッシュ化がサポートされることを示す場合があります。有効なレスポンスは、ユーザー名、パスワード、与えられた nonce 値、HTTP メソッド、および要求された URI の非鍵付きダイジェストを含みます。このようにしてパスワードは平文で送信されず、サーバーからの指示に応じてユーザー名はハッシュ化できます。ユーザー名とパスワードは、本書で扱わない方法で事前に取り決められている必要があります。

オプションのヘッダーフィールドにより、サーバーは非鍵付きダイジェストまたはダイジェストを生成するために使用するアルゴリズムを指定できます。本書は SHA-256 および SHA-512/256 アルゴリズムを追加します。後方互換性を保つために、MD5 アルゴリズムは依然としてサポートされますが、推奨されません。

ダイジェストのサイズは使用されるアルゴリズムに依存します。ダイジェスト内のビットは、最上位ビットから最下位ビットへ、4 ビットずつ ASCII 表現に変換されます。各 4 ビットの列は 0123456789abcdef の親しみのある 16 進表記で表されます。すなわち、2 進 0000 は '0'、0001 は '1'、...、1111 は 'f' です。MD5 アルゴリズムを用いるとダイジェストは 32 文字の 16 進表現になり、SHA-256 と SHA-512/256 は 64 文字の 16 進表現になります。

realm

• ユーザーにどのユーザー名とパスワードを使うべきかを示すために表示される文字列です。この文字列は、認証を行うホストの名前を少なくとも含め、さらにアクセス可能なユーザーの集合を示すこともあります。例として "registered_users@example.com" があります。（詳細は RFC7235 セクション 2.2 を参照。）

domain

• 保護領域を定義する URI の引用符で囲まれた空白区切りのリスト（[RFC3986] で指定）です。URI が path-absolute の場合、それは正規ルート URL に対する相対です。（詳細は RFC7235 セクション 2.2 を参照。）このリスト中の絶対 URI は、ウェブオリジンとは異なるサーバーを参照することがあります。クライアントは、このリストを使用して同じ認証情報を送信できる URI の集合を決定できます：このリスト中の URI がプレフィックスとなる任意の URI（両者を絶対化した後）は同じ保護領域に属すると見なすことができます。このパラメータが省略されるか値が空の場合、クライアントは保護領域がウェブオリジン上のすべての URI で構成されると仮定するべきです。
• このパラメータは Proxy-Authenticate ヘッダーフィールドでは意味を持ちません（プロキシの保護領域は常にプロキシ全体です）。存在する場合は無視されなければなりません。

nonce

• サーバーが指定する文字列で、401 応答が行われるたびに一意に生成されるべきものです。この文字列は Base64 または 16 進データであることが望まれます。具体的には、ヘッダーフィールド行内で引用符付き文字列として渡されるため、ダブルクォート文字は適切にエスケープされない限り使用できません。
• nonce の内容は実装依存です。良好な実装の品質は適切な選択に依存します。例えば nonce は次のように構成されることがあります：

           timestamp H(timestamp ":" ETag ":" secret-data)
  

• ここで timestamp はサーバー生成の時刻で、好ましくはマイクロ秒やナノ秒などの非反復値を含みます；ETag は要求された実体に関連する HTTP ETag ヘッダーフィールドの値；secret-data はサーバーのみが知るデータです。この形式の nonce を用いる場合、サーバーはクライアントの認証ヘッダーフィールドを受け取った後にハッシュ部分を再計算し、それがヘッダーフィールドの nonce と一致しない場合、または timestamp 値が十分に新しくない場合はリクエストを拒否できます。これによりサーバーは nonce の有効期間を制限できます。ETag の含有は、リソースが更新された場合のリプレイ要求を防ぎます。nonce にクライアントの IP アドレスを含めると nonce の再利用を同じクライアントに限定できるように見えますが、単一ユーザーのリクエストが異なるプロキシを経由することが多く、IP アドレス偽装も容易なため問題があります。
• 実装はリプレイ攻撃から保護するために以前使用された nonce や以前使用されたダイジェストを受け付けない選択をするかもしれません。また、POST や PUT のためにワンタイム nonce/ダイジェストを使用し、GET にはタイムスタンプを使う選択もあります。詳細は本書の セクション 5 を参照してください。
• nonce はクライアントにとって不透明です。

opaque

• サーバーが指定するデータ文字列で、クライアントは同一の保護領域内の後続リクエストの Authorization ヘッダーフィールドでこの値を変更せずに返すべきです。Base64 や 16 進データであることが推奨されます。

stale

• 前回のクライアントからのリクエストが nonce 値の陳腐化により拒否されたことを示す大文字小文字を区別しないフラグです。stale が true の場合、クライアントはユーザーに再プロンプトすることなく新しい暗号化レスポンスで単にリクエストを再試行することを望むかもしれません。サーバーは nonce が無効であるリクエストを受け取った場合にのみ stale を true に設定するべきです。stale が false、あるいは true 以外の値、または stale パラメータが存在しない場合は、ユーザー名および/またはパスワードが無効であり、新しい値が取得されなければなりません。

algorithm

• ダイジェストおよび非鍵付きダイジェストを生成するために使用されたアルゴリズムを示す文字列です。存在しない場合は "MD5" と見なされます。アルゴリズムが理解できない場合、チャレンジは無視されるべきです（複数ある場合は別のものを使用する）。
• ダイジェスト機構で使用されるとき、各アルゴリズムにはセッション変種と非セッション変種の 2 つのバリアントがあります。非セッション変種は "<algorithm>"（例："SHA-256"）で表され、セッション変種は "<algorithm>-sess"（例："SHA-256-sess"）で表されます。
• 本書では、ダイジェストアルゴリズムを "data" に適用して得られる文字列を H(data) と表し、秘密 "secret" とデータ "data" に対してダイジェストアルゴリズムを鍵付きで適用して得られる文字列を KD(secret, data) と表します。KD は Keyed Digest を意味し、unq(X) は引用符付き文字列 X から周囲の引用符を取り、引用用スラッシュを除去した値を意味します。

       For "<algorithm>" and "<algorithm>-sess"
  
           H(data) = <algorithm>(data)
  
       and
  
           KD(secret, data) = H(concat(secret, ":", data))
  

• 例えば：

       For the "SHA-256" and "SHA-256-sess" algorithms
  
           H(data) = SHA-256(data)
  

• すなわち、ダイジェストは秘密とコロンとデータを連結したものに対する "<algorithm>" の適用結果です。"<algorithm>-sess" は効率的なサードパーティ認証サーバーを可能にすることを意図しています；使用上の差異は セクション 3.4.2 の記述を参照してください。

qop

• このパラメータは全ての実装で使用される MUST です。これはサーバーがサポートする "quality of protection" 値を示す一つ以上のトークンの引用符付き文字列です。"auth" は認証を示し、"auth-int" は完全性保護を伴う認証を示します。レスポンスパラメータ値の計算については以下を参照してください。未認識のオプションは無視されなければなりません。

charset

• これはサーバーがサポートするエンコーディング方式を示すオプションのパラメータです。許可される値は "UTF-8" のみです。

userhash

• これはサーバーがユーザー名のハッシュ化をサポートすることを示すオプションのパラメータです。有効な値は "true" または "false" です。デフォルトは "false" です。

歴史的理由により、送信者は次のパラメータについて引用符付き文字列構文のみを生成する MUST です：realm, domain, nonce, opaque, qop。

歴史的理由により、送信者は次のパラメータについて引用符付き文字列構文を生成してはならない MUST NOT です：stale, algorithm。

クライアントはリクエストを再試行し、Digest スキームによる Authorization ヘッダーフィールド行を送信することが期待されます。opaque および algorithm フィールドの値は、要求されるエンティティに対する WWW-Authenticate 応答ヘッダーフィールドで提供されたものと一致しなければなりません。

response

• 以下で定義されたように計算された 16 進数字列の文字列で、ユーザーがパスワードを知っていることを証明します。

username

• 指定された realm 内のユーザー名。引用符付き文字列は平文の名前か、16 進表記のハッシュコードを含みます。ユーザー名に ABNF quoted-string で許されない文字が含まれる場合は username* パラメータを使用できます。同じヘッダーオプションで username と username* を両方送ることはエラーとして扱われなければなりません。

username*

• userhash パラメータ値が "false" に設定されていて、ユーザー名に ABNF quoted-string で許されない文字が含まれる場合、ユーザー名は [RFC5987] の拡張表記を用いてこのパラメータで送信できます。

realm

• セクション 3.3 の "realm" 定義を参照してください。

uri

• HTTP リクエストの有効なリクエスト URI（RFC7230 セクション 5.5）。プロキシが転送中に要求ターゲット（"request-target", RFC7230 セクション 3.1.1）を変更することがあるためここに重複して示しています。

qop

• クライアントがメッセージに適用した "quality of protection" を示します。値は WWW-Authenticate ヘッダーフィールドでサーバーが示した代替の一つでなければなりません。これらの値は response の計算に影響します。これは単一トークンであり、WWW-Authenticate のような引用符付きの代替リストではないことに注意してください。

cnonce

• このパラメータは全ての実装で使用される MUST です。cnonce 値はクライアントが提供する不透明な引用符付き ASCII のみの文字列で、選択平文攻撃を回避し、相互認証を提供し、ある程度のメッセージ完全性保護を行うためにクライアントとサーバー両方で使用されます。rspauth および response 値の計算の説明を参照してください。

nc

• このパラメータは全ての実装で使用される MUST です。nc は "nonce count" を意味します。nc 値は、このリクエストで使用されている nonce 値でクライアントが送信したリクエスト数（現在のリクエストを含む）の 16 進カウントです。例えば、ある nonce 値に対する最初のリクエストではクライアントは "nc=00000001" を送信します。このパラメータの目的は、サーバーが自身のカウントを保持して同じ nc 値が二度見られた場合にリプレイを検出できるようにすることです。response 値の構成の説明を参照してください。

userhash

• このオプションのパラメータはクライアントがユーザー名がハッシュ化されていることを示すために使用します。有効な値は "true" または "false" で、デフォルトは "false" です。

歴史的理由により、送信者は次のパラメータについて引用符付き文字列構文のみを生成する MUST です：username, realm, nonce, uri, response, cnonce, opaque。

歴史的理由により、送信者は次のパラメータについて引用符付き文字列構文を生成してはならない MUST NOT です：algorithm, qop, nc。

パラメータまたはその値が不適切であるか、必須パラメータが欠けている場合、適切な応答は 4xx エラーコードです。レスポンスが無効な場合、ログにログイン失敗を記録することが SHOULD です。単一クライアントからの繰り返されるログイン失敗は攻撃者によるパスワード推測の試みを示す可能性があります。サーバー実装はログに平文のパスワード（例えば username フィールドに入力されたもの）が入らないよう注意するべきです。

上記の response の定義はその値のエンコーディングを示します。以下の定義はその値がどのように計算されるかを示します。

Authentication-Info ヘッダーフィールドおよび Proxy-Authentication-Info ヘッダーフィールド（RFC7615）は、サーバーがクライアントレスポンスの認証成功に関する情報の一部を伝えるために MAY 使用できる汎用フィールドです。

nextnonce

• nextnonce パラメータの値は、サーバーがクライアントに将来の認証レスポンスで使用してほしいと望む nonce です。サーバーはワンタイム nonce を実装する手段として、または nonce を変更するために Authentication-Info ヘッダーフィールドを nextnonce フィールド付きで送ることが MAY あります。nextnonce フィールドが存在する場合、クライアントは次回のリクエストで Authorization ヘッダーフィールドを構築する際にそれを使用すべきである（SHOULD）とされています。クライアントがそれを使用しなかった場合、サーバーが "stale=true" を付した再認証要求を行うことが MAY あります。
  • サーバー実装はこのメカニズムの使用が性能に与える影響を慎重に考慮するべきです；もし全てのレスポンスが次のリクエストで MUST 使用される nextnonce パラメータを含むなら、パイプライン化されたリクエストは不可能になります。要求のパイプライン化を可能にするために、古い nonce 値を制限時間内に許容するなどの性能とセキュリティのトレードオフを考慮するべきです。nc パラメータを使用すれば、新しいサーバー nonce の大部分のセキュリティ上の利点を保持しつつパイプライン化への悪影響を軽減できます。

qop

• サーバーがレスポンスに適用した "quality of protection" オプションを示します。値 "auth" は認証を示し、"auth-int" は整合性保護付き認証を示します。サーバーはレスポンス中の qop パラメータに、対応するリクエストでクライアントが送った値と同じ値を使用するべきです（SHOULD）。

rspauth

• rspauth パラメータのオプションのレスポンスダイジェストは相互認証をサポートします—サーバーはユーザーの秘密を知っていることを証明し、qop=auth-int の場合はレスポンスの限定的な整合性保護も提供します。rspauth 値は Authorization ヘッダーフィールド内の response と同様の方法で計算されますが、qop が "auth" に設定されているか Authorization ヘッダーフィールドで指定されていない場合、A2 は

•       A2       = ":" request-uri
  

  となり、"qop=auth-int" の場合は A2 は

        A2       = ":" request-uri ":" H(entity-body)
  

  となります。

cnonce および nc

• cnonce 値と nc 値は、このメッセージがレスポンスであるクライアントリクエストのためのものである値でなければなりません（MUST）。rspauth、cnonce、および nc パラメータは、"qop=auth" または "qop=auth-int" が指定されている場合に存在していなければなりません（MUST）。

Authentication-Info ヘッダーフィールドは、chunked transfer coding で転送される HTTP メッセージのトレーラに含めることができます。

歴史的理由により、送信者は次のパラメータについて引用符付き文字列構文のみを生成する MUST です：nextnonce、rspauth、および cnonce。

歴史的理由により、送信者は次のパラメータについて引用符付き文字列構文を生成してはならない MUST NOT です：qop および nc。

歴史的理由により、nc 値は正確に 8 桁の 16 進数字でなければなりません（MUST）。

Authorization ヘッダーフィールドを受け取った際、サーバーは提出された username に対応するパスワードを参照してその妥当性をチェックすることが MAY あります。次にサーバーはクライアントが行ったのと同じダイジェスト操作（例：MD5、SHA-256）を MUST 行い、その結果を与えられた response 値と比較しなければなりません。

HTTP サーバーは実際にユーザーの平文パスワードを知る必要はないことに注意してください。サーバーが H(A1) を利用できる限り、Authorization ヘッダーフィールドの有効性は検証できます。

WWW-Authenticate チャレンジに対するクライアントのレスポンスは、その保護領域との認証セッションを開始します。認証セッションは、クライアントが保護領域内の任意のサーバーから別の WWW-Authenticate チャレンジを受け取るまで続きます。クライアントはユーザー名、パスワード、nonce、nonce count、および opaque 値を認証セッションに関連付けて記憶し、同一の保護領域内の今後のリクエストで Authorization ヘッダーフィールドを構築するために使用することが SHOULD です。Authorization ヘッダーフィールドは事前に送信することが MAY されており、これによりサーバーの効率が向上し、認証チャレンジのための往復が回避されます。サーバーは古い Authorization ヘッダーフィールド情報を受け入れることが MAY ありますが、その場合含まれる nonce 値が新鮮でない可能性があります。あるいはサーバーは新しい nonce 値を含む 401 応答を返してクライアントにリクエストの再試行を促すことが MAY あります；この応答に "stale=true" を指定することで、サーバーはクライアントに新しい nonce で再試行するよう伝えますが、ユーザー名とパスワードの再入力は不要です。

クライアントがセッション期間中にサーバーから与えられた opaque パラメータの値を返すことが要求されるため、opaque データは認証セッション状態情報を運ぶために使用できます（ただし、そのような使用は nonce に状態を含めることでより簡単かつ安全に実現できます）。例えば、あるサーバーが実際のコンテンツを別のサーバー上で認証する責任を持つ場合、最初の 401 応答に domain パラメータで第2のサーバー上の URI を含め、opaque パラメータに状態情報を含めることでこれを達成できます。クライアントはリクエストを再試行し、その際サーバーは第2のサーバー上の URI を指す "HTTP Redirection" を返すかもしれません。クライアントはリダイレクトに従い、opaque データを含む Authorization ヘッダーフィールドを渡します。

プロキシは Digest アクセス認証スキームにおいて完全に透過的でなければなりません（MUST）。つまり、WWW-Authenticate、Authentication-Info、および Authorization ヘッダーフィールドを変更せずに転送しなければなりません。プロキシがリクエストを転送する前にクライアントを認証したい場合は、下記の セクション 3.8 に記述される Proxy-Authenticate および Proxy-Authorization ヘッダーフィールドを用いて行うことができます。

サーバーがクライアントが扱えるセキュリティスキームを把握できることは有用です。

サーバーが Digest を認証方法として要求したいが、クライアントがそれをサポートしているかどうかをサーバーが知らない可能性があります。クライアントは、サーバーが自分で扱えない認証スキームのみを指定した場合でも、穏やかにフォールバックすることが推奨されます。

サーバーがリソースへのアクセスリクエストを受け取った際、サーバーは "401 Unauthorized" 応答でクライアントにチャレンジすることがあり、1 個以上の WWW-Authenticate ヘッダーフィールドを含めます。サーバーが複数のチャレンジで応答する場合、それらそれぞれは MUST 異なるダイジェストアルゴリズムを使用しなければなりません。サーバーは優先順（最も好ましいアルゴリズムから順）でこれらのチャレンジを応答に追加する MUST があります。

本仕様は次のアルゴリズムを定義します：

• SHA2-256（実装必須）
• SHA2-512/256（バックアップアルゴリズムとして）
• MD5（後方互換性のため）。

クライアントが最初のチャレンジを受け取ったとき、ローカルポリシーが別段定めない限り、クライアントはサポートする最初のチャレンジを使用するべきです（SHOULD）。

Digest 認証スキームは、Proxy-Authenticate および Proxy-Authorization ヘッダーフィールドを用いて、ユーザーからプロキシへの認証、プロキシ間の認証、またはプロキシからオリジンサーバーへの認証にも使用できます。これらのヘッダーフィールドは HTTP/1.1 仕様（RFC7235）のセクション 4.3 および 4.4 に規定された Proxy-Authenticate/Proxy-Authorization ヘッダーフィールドのインスタンスであり、その振る舞いはそこで述べられた制約の対象になります。プロキシ認証のトランザクションはここで既に述べたものと非常に類似しています。認証が必要なリクエストを受け取った場合、プロキシ/サーバーは "407 Proxy Authentication Required" 応答と "Proxy-Authenticate" ヘッダーフィールドを発行しなければなりません（MUST）。Proxy-Authenticate ヘッダーフィールドで使用される digest-challenge は、上で定義した WWW-Authenticate ヘッダーフィールドのものと同一です（セクション 3.3 を参照）。

クライアント/プロキシはその後、Proxy-Authorization ヘッダーフィールドを付けてリクエストを再送しなければなりません（MUST）。パラメータは前述の Authorization ヘッダーフィールドに指定されたものと同様です（セクション 3.4）。

後続のレスポンスでは、サーバーは Authentication-Info ヘッダーフィールドと同じパラメータを持つ Proxy-Authentication-Info を送信します。

原理的には、クライアントはプロキシとエンドサーバーの両方に認証を求められることがありますが、同一のレスポンスで両方に求められることはありません。

人間が記憶しやすいパスワードと組み合わせて使用される場合、HTTP ダイジェスト認証は辞書攻撃に対して脆弱です。このような攻撃は、広く使われているアルゴリズム（安全とは見なされなくなったものを含む）に対する暗号解析攻撃よりはるかに容易です。言い換えれば、アルゴリズムの可変性はこの用途をより安全にはしません。

したがって、ダイジェスト認証は十分なエントロピー（例：128 ビット以上）を持つパスワードと共にのみ使用することが SHOULD 推奨されます。そのようなパスワードは通常人間が記憶できませんが、自動化されたウェブサービスには適しています。

ダイジェスト認証を使用する場合、それは HTTPS のような安全なチャネル上で行われることが SHOULD 推奨されます（RFC2818）。

ダイジェスト認証では、認証エージェント（通常はサーバー）が特定の realm に関連付けられた「パスワードファイル」にユーザー名とパスワードに由来するデータを保存することが必要です。通常、これは username と H(A1) の対を含みます。ここで H(A1) は前述のとおりユーザー名、realm、およびパスワードのダイジェスト値です。

このことのセキュリティ上の含意は、このパスワードファイルが侵害された場合、攻撃者はその realm に属するサーバー上のドキュメントに即座にアクセスできる点です。標準的な UNIX パスワードファイルとは異なり、この情報は復号せずともサーバー上のドキュメントにアクセスするために利用され得ます。一方で、ユーザーのパスワードを得るには復号、あるいはより可能性が高いブルートフォース攻撃が必要です。このため、realm はパスワードファイルに保存されるダイジェストデータの一部になっています。これにより、あるダイジェスト認証パスワードファイルが侵害されても、同じユーザー名とパスワードを持つ他の realm が自動的に侵害されるわけではありません（ただしブルートフォース攻撃に晒される点には注意）。

重要なセキュリティ上の結果が二つあります。第一に、パスワードファイルは未暗号化パスワードを含むかのように保護されなければなりません。なぜなら、その realm に属するドキュメントへアクセスする目的では事実上そのように機能するからです。

第二の結果として、realm 文字列は単一ユーザーが使用する可能性のあるすべての realm の中で一意であることが SHOULD 推奨されます。特に、realm 文字列は認証を行うホストの名前を含むべきです。クライアントがサーバーを認証できないことはダイジェスト認証の弱点です。

ダイジェスト認証は、公開鍵ベースのメカニズムと比べると強い認証メカニズムを提供しません。

しかし、それは LDAP 用に提案された CRAM-MD5 のような方式よりはかなり強力です（参考：RFC4513 および RFC2195）。本仕様はより弱く危険な Basic 機構を置き換えることを意図しています。

ダイジェスト認証はユーザー名とパスワード自体を保護しますが、それ以外のリクエストおよびレスポンスに対する機密性保護は提供しません。盗聴者はそれらを取得できます。

ダイジェスト認証は双方向のメッセージに対して限定的な整合性保護を提供するのみです。もし "qop=auth-int" を使用する場合、WWW-Authenticate および Authorization ヘッダーフィールドの response パラメータ値計算に使用されるメッセージ部分（セクション 3.2 を参照）は保護されます。しかしほとんどのヘッダーフィールドとその値は中間者攻撃によって改変され得ます。

安全な HTTP トランザクションに必要な多くの要件はダイジェスト認証では満たされません。そのような場合は TLS の方が適切です。特に、機密性保護が必要な取引はダイジェスト認証では実現できません。それでも、ダイジェスト認証が有用かつ適切な多くの機能は残ります。

ダイジェストスキームはレスポンス値の生成にサーバー指定の nonce を用います（セクション 3.4.1 を参照）。前述の nonce の例（セクション 3.3）に示されるように、サーバーは nonce を特定のクライアント、特定のリソース、限定された期間または使用回数などにのみ使用できるよう構成することが MAY あります。こうすることでリプレイ攻撃に対する保護が強化されます（セクション 5.5 を参照）。しかし nonce の生成と検証方法には性能およびリソースの影響があります。例えば、サーバーは最近発行した各 nonce が返されたかどうかの記録を保持し、各レスポンスの Authentication-Info ヘッダーフィールドに next-nonce パラメータを送ることで各 nonce を一度だけ使用可能にすることが MAY あります。これは即時のリプレイ攻撃から保護しますが、nonce 値をチェックするコストが高く、パイプライン化されたリクエストに対して認証失敗を引き起こす可能性があります（結果として stale nonce 表示を返すことになります）。同様に、ETag 値のようなリクエスト固有の要素を取り込むと nonce の使用をそのバージョンのリソースに限定し、パイプライン化を妨げます。したがって、副作用のあるメソッドには有用ですが、副作用のないメソッドでは性能上受け入れ難いことがある点に注意してください。

ダイジェスト認証に対するリプレイ攻撃は、単純な GET リクエストに対しては通常無意味です。なぜなら、盗聴者はリプレイで得られる唯一のドキュメントを既に見ているからです。これは要求されたドキュメントの URI がクライアントリクエストでダイジェスト化され、サーバーはそのドキュメントのみを配信するためです。対照的に Basic 認証では、盗聴者がユーザーのパスワードを得ると、そのパスワードで保護された任意のドキュメントにアクセス可能になります。

したがって、用途によってはリプレイ攻撃に対する保護が必要です。良好なダイジェスト実装はこれを様々な方法で実現できます。サーバー生成の nonce 値は実装依存ですが、クライアント IP、タイムスタンプ、リソースの ETag、およびサーバー秘密鍵のダイジェストを含めると（前述の推奨のように）リプレイ攻撃は容易ではありません。攻撃者はサーバーを偽装して異なる IP にドキュメントを配信させる必要があり、またタイムスタンプが期限切れになる前に攻撃を成功させなければなりません。nonce にクライアント IP とタイムスタンプを取り込み、トランザクション間で状態を保持しない実装を可能にすることができます。

リプレイを完全に許容しないアプリケーションでは、サーバーは二度目の使用が認められないワンタイム nonce 値を使用できます。これは nonce が期限切れになるまでサーバーがどの nonce が使用されたかを記憶するオーバーヘッドを必要としますが、リプレイ攻撃に対する有効な保護となります。

実装は POST や PUT リクエストに対するリプレイ攻撃の可能性に特別な注意を払う必要があります。サーバーがワンタイムまたは限定使用の nonce を用いない、あるいは "qop=auth-int" の整合性保護を要求しない限り、攻撃者は成功したリクエストから有効な資格情報を再生して偽のデータや別のメッセージ本文を送る可能性があります。整合性保護を使用しても、多くのヘッダーフィールドのメタデータは保護されません。適切な nonce の生成と検証は以前に使用された有効な資格情報の再生に対するいくつかの保護を提供しますが、セクション 5.8 を参照してください。

HTTP/1.1 サーバーは 401 応答で複数のチャレンジを返すことが MAY あります。各チャレンジは異なる認証スキームを使うことが MAY あります。ユーザーエージェントは理解する中で最も強力な認証スキームを選択し、そのチャレンジに基づいてユーザーから資格情報を要求しなければなりません（MUST）。

サーバーが WWW-Authenticate ヘッダーフィールドで複数の認証スキームを提示する場合、結果として得られる認証の強度は提示されたスキームの中で最も弱いものと同じであることに注意してください。特定の攻撃シナリオについては下記の セクション 5.7 を参照してください。

攻撃者が盗聴できる場合、盗聴者は傍受した nonce/response ペアを用いて一般的な単語リストに対してテストできます。そのようなリストは通常、可能なすべてのパスワード数よりはるかに小さいです。各単語に対する response を計算するコストはチャレンジごとに一度支払われます。

サーバーはユーザーが辞書に載っているパスワードを選択できないように制限することでこの攻撃を軽減できます。

ダイジェスト認証は敵対的または乗っ取られたプロキシなどによる中間者（MITM）攻撃に対して脆弱です。これは盗聴のすべての問題を引き起こしますが、加えて攻撃者にいくつかの追加の機会を与えます。

可能な MITM 攻撃の一つは、意図的に弱い認証スキームを選択肢に追加し、クライアントが資格情報を露出するスキームを使用することを期待するものです（例えばパスワードを露出するもの）。このためクライアントは提示された選択肢の中で理解する最も強力なスキームを常に使用することが SHOULD 推奨されます。

さらに悪質な MITM 攻撃は、提示されたすべての選択肢を削除して Basic 認証のみを要求するチャレンジに置き換え、そこで得た平文資格情報を使ってオリジンサーバーに対してより強いスキームで認証するという方法です。特に悪質なのは、攻撃者が「無料」のプロキシキャッシュサービスを提供して騙す場合です。

ユーザーエージェントは、資格情報要求時に使用される認証スキームを視覚的に示したり、サーバーから要求された最強の認証スキームを記憶してより弱いものを使用する前に警告を出すなどの対策を検討すべきです。特定のサイトに対してダイジェスト認証を要求するようユーザーエージェントを設定することも有用かもしれません。

あるいは、敵対的なプロキシがクライアントをだまして攻撃者が望むリクエストを送らせる可能性もあります。もちろんこれは Basic 認証に対する同等の攻撃よりは難しいですが、依然として現実的なリスクです。

ダイジェスト認証では、MITM や悪意のあるサーバーがクライアントがレスポンスを計算するために使用する nonce を任意に選べます。これを「選択平文」攻撃と呼びます。nonce を選べる能力は暗号解析を容易にすることが知られています。

しかし、選択平文を用いたダイジェストで使用される単方向関数を解析する方法は現時点では知られていません。

この攻撃への対策は、クライアントが cnonce パラメータを使用することです。これによりクライアントがハッシュへの入力を攻撃者に選ばせないように変化させることができます。

選択平文攻撃が可能な場合、攻撃者は任意の nonce に対して多くの一般的な単語のレスポンスを事前計算し、レスポンス/パスワードの辞書を保存できます。この事前計算は複数のマシンで並列に行えることが多く、選択平文攻撃を使ってそのチャレンジに対応するレスポンスを取得し、辞書からパスワードを参照するだけで済みます。パスワードが辞書に含まれていない場合でも一部は当てはまる可能性があります。攻撃者がチャレンジを選べるため、各パスワードに対するレスポンス計算コストは多くのパスワードを見つける際に分散されます。1 億のパスワード/レスポンスペアを持つ辞書でも約 3.2 ギガバイトのディスク容量で済むと報告されています。

この攻撃への対策はクライアントが cnonce パラメータを使用することです。

MITM は選択平文攻撃を実行して多くのユーザーから同じ nonce に対するレスポンスを収集できます。これにより、パスワード空間の任意の部分集合について一度の走査でその中のいずれかの nonce/response ペアを生成するすべてのパスワードを見つけられます。集めた nonce/response ペアの数に応じて、最初のパスワードを見つける時間が短縮されます。この探索は多くのマシンで並列に実行可能であり、単一のマシンでも大きなパスワード空間の部分集合を非常に短時間で検索できます—例えば 6 文字以下のすべてのパスワード検索が数時間で完了したという報告があります。

この攻撃への対策はクライアントが cnonce パラメータを使用することです。

このプロトコルのセキュリティは、クライアントおよびサーバーの nonce のようなランダムに選ばれるパラメータの乱数性に依存します。これらは強力なランダム源または適切にシードされた擬似乱数源によって生成されるべきです（詳細は RFC4086 を参照）。

現代の暗号基準から見ると、ダイジェスト認証は弱いものです。しかし、多くの用途において Basic 認証の代替として有用です。Basic のいくつかの弱点を改善しますが、すべてを解消するわけではありません。その強度は実装に依存します。特に nonce の構造（サーバー実装に依存する）はリプレイ攻撃の難易度に影響を与えます。サーバー側でワンタイム nonce やダイジェストを受け入れることでリプレイの可能性を排除する実装もあれば、上で推奨したように単一 IP と単一 ETag または限定寿命に制限した nonce で満足する実装もあります。

要するに、どの準拠実装であっても暗号学的基準では相対的に弱いですが、どの準拠実装であっても Basic 認証よりははるかに優れているという点が重要です。

本仕様は既存の "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" カテゴリの下に "Hash Algorithms for HTTP Digest Authentication" という新しい IANA レジストリを作成します。このレジストリは HTTP ダイジェスト認証で使用できるハッシュアルゴリズムを一覧化します。

Hash Algorithm

• ハッシュアルゴリズムのテキスト名。

Digest Size

• アルゴリズムの出力サイズ（ビット単位）。

Reference

• このレジストリにアルゴリズムを追加する仕様への参照。

このレジストリの更新ポリシーは Specification Required とします（RFC5226 を参照）。

レジストリで定義される各アルゴリズムには "-sess" 変種（例：MD5-sess、SHA-256-sess 等）が存在し得ます。

既存の "HTTP Digest Algorithm Values" レジストリの目的を明確にし、二つのレジストリ間の混乱を避けるために、IANA は既存レジストリに以下の説明を追加しました：

• このレジストリは、RFC 3230 に記載されるとおり、HTTP メッセージ本文のダイジェストを作成する際に使用できるアルゴリズムを一覧化します。

本仕様は "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" における Digest スキームの既存エントリを更新し、本仕様への新しい参照を追加します。

• Authentication Scheme Name: Digest
• Pointer to specification text: RFC 7616

7.1. ノルマティブ参考文献

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2978]

Freed, N. and J. Postel, “IANA Charset Registration Procedures”, BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <http://www.rfc-editor.org/info/rfc2978>.

[RFC3629]

Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC4086]

Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.

[RFC5198]

Klensin, J. and M. Padlipsky, “Unicode Format for Network Interchange”, RFC 5198, DOI 10.17487/RFC5198, March 2008, <http://www.rfc-editor.org/info/rfc5198>.

[RFC5234]

Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5987]

Reschke, J., “Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters”, RFC 5987, DOI 10.17487/RFC5987, August 2010, <http://www.rfc-editor.org/info/rfc5987>.

[RFC6454]

Barth, A., “The Web Origin Concept”, RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.

[RFC7230]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7231]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7234]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.

[RFC7235]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.

[RFC7613]

Saint-Andre, P. and A. Melnikov, “Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords”, RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.

[RFC7615]

Reschke, J., “HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields”, RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.

7.2. 参考文献（参考資料）

[RFC2195]

Klensin, J., Catoe, R., and P. Krumviede, “IMAP/POP AUTHorize Extension for Simple Challenge/Response”, RFC 2195, DOI 10.17487/RFC2195, September 1997, <http://www.rfc-editor.org/info/rfc2195>.

[RFC2617]

Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication”, RFC 2617, DOI 10.17487/RFC2617, June 1999, <http://www.rfc-editor.org/info/rfc2617>.

[RFC2818]

Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[RFC4513]

Harrison, R., Ed., “Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms”, RFC 4513, DOI 10.17487/RFC4513, June 2006, <http://www.rfc-editor.org/info/rfc4513>.

[RFC5226]

Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC7617]

Reschke, J., “The 'Basic' HTTP Authentication Scheme”, RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.