[37] ダイジェスト認証は、 challenge-response 型の認証方式です。 HTTP応答に含まれる challenge では、 nonce の値を伝達します。 それに対するHTTP要求に含まれる challenge への応答には、 利用者名、合言葉、 与えられた nonce 値、要求メソッド、要求URLの要約値を含めます。 >>36
[38] 従って合言葉そのものを転送する必要はありませんし、 利用者名もサーバーが対応していることを示した場合はハッシュ化できます。 >>36
[64] 合言葉は十分エントロピーの高い (例えば128ビット以上の) 値とするべきです。普通そんな合言葉は人間には覚えられませんが、 自動化された Webサービスなら使うことができます。 >>63
auth-scheme[43] auth-scheme は、 Digest です。
[41] challenge の auth-param には、
次の引数を指定できます。
[42] credentials の auth-param には、
次の引数を指定できます。
[62] Authentication-Info: ヘッダーや
Proxy-Authentication-Info: ヘッダーについては、
そちらの項を参照。
[35] Webブラウザーは、 Web互換性のため、ダイジェスト認証に対応しなければなりません。
[40] ダイジェストアルゴリズム参照。
[58] ある保護空間の認証セッションは、
その保護空間の WWW-Authenticate:
の challenge に対してクライアントが応答するところから始まり、
クライアントが当該[保護空間]]のサーバーから他の
WWW-Authenticate:
の challenge を受信することで終わります。 >>53
[59] クライアントは、
保護空間内の後の要求の Authorization:
ヘッダーで使うための利用者名、合言葉、nonce、nonce の数
(nc)、 opaque 値を認証セッションに関連付けて記憶するべきです。
>>53
[45] credentials の引数やその値が不適切だったり、
必須のものが指定されていなかったりした時は、
4xx 応答を返すのが適切です >>44。
[54] サーバーは、 Authorization:
ヘッダーを受信したら、提出された利用者名に対応する合言葉を探し、
妥当性を検査して構いません。
次に、クライアントが行ったのと同じダイジェストアルゴリズムを適用し、
response 値と比較しなければなりません。 >>53
[46] ログインの失敗は、記録するべきです。 特定のクライアントが失敗を繰り返す時は、 合言葉を推測する攻撃かもしれません。 >>44
[47] サーバーは、記録時には平文の合言葉が記録されないよう注意するべきです >>44。 例えば利用者名に誤って合言葉が記入されるかもしれません >>44。
[60] Authorization: ヘッダーを (challenge を受信せずに)
予め要求に含めておいても構いません。 >>53
[61] サーバーは、古い Authorization:
ヘッダーを受け入れることとしても構いません。 nonce が新鮮でなくても受け入れて構いません。
あるいは新しい nonce 値を含む 401
応答を返してクライアントに再試行を求めても構いません。 >>53
[31] HTTP認証では基本認証の方がよく使われています。ダイジェスト認証も広く実装されてはいますが、 さほど使われていないようです。
[25] ダイジェスト認証は本体や一部のヘッダーのダイジェスト値を使いますが、
同様にダイジェスト値を使う HTTP の機能として
Content-MD5: ヘッダーや Want-Digest:
ヘッダーがあります。
[7] Digest に関わる特許権の主張があったようですが
(現在は削除されています。) >>6、 Digest
ではなくそれを用いた技術に関するものらしく >>8、しかも元の RFC
の10年後の2008年の出願である >>9 ことから、明らかに不適当なものです。
そのためか主張は取下げられた >>6 ようです。
[4] RFC 2068 世代の RFC 2069 は Digest認証単独の仕様書でしたが、 次の RFC 2617 は Basic認証と共通の仕様書になっています。
[23] draft-ietf-http-digest-aa-00 - An Extension to HTTP : Digest Access Authentication ( ( 版)) https://tools.ietf.org/html/draft-ietf-http-digest-aa-00
[12] RFC 3310 - Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) ( ( 版)) https://tools.ietf.org/html/rfc3310#section-3.4
[14] draft-santesson-digestbind-01 - Channel binding for HTTP Digest Authentication ( ( 版)) http://tools.ietf.org/html/draft-santesson-digestbind-01
[15] RFC 2831 - Using Digest Authentication as a SASL Mechanism ( ( 版)) http://tools.ietf.org/html/rfc2831
[16] RFC 6331 - Moving DIGEST-MD5 to Historic ( ( 版)) http://tools.ietf.org/html/rfc6331
IE6 では Digest 認証を使って foo.cgi?FOO=BAR のような URL にリクエストすると、 誤ったリクエストを送ってしまうバグがあります。 以下の URL は Mozilla や FireFox では正しく閲覧できますが、IE6 だと正しいユーザ名・パスワードを送信しても、 400 Bad Request になってしまいます (Windows XP SP2 + IE6 で確認)。
サンプル: http://X68000.q-e-d.net/~68user/net/sample/http-auth-digest/secret.cgi?FOO=BAR
[29] Atom は Digest認証がそのままでは実用に供せないとして、
auth-scheme Atom を使おうとしました
>>28。これは WS-Security に影響されて WSSE となりました。
Last week Mark Pilgrim and I released an implementation of the AtomAPI, both a client and a server. That implementation included a new authorization scheme that we came up with. Now we would have liked to used HTTP Digest authentication, and the AtomAPI should support Digest authentication, but for many users setting up Digest just isn't possible.
[24] draft-smith-sipping-auth-examples-01 - Digest Authentication Examples for Session Initiation Protocol (SIP) ( ( 版)) http://tools.ietf.org/html/draft-smith-sipping-auth-examples-01
[10] draft-yusef-sipcore-digest-scheme-04 - The Session Initiation Protocol (SIP) Digest Authentication Scheme ( ( 版)) https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-04
[13] draft-sen-sipping-onehop-digest-00 - Single Hop Message Authentication in SIP ( ( 版)) http://tools.ietf.org/html/draft-sen-sipping-onehop-digest-00
[17] RFC 5090 - RADIUS Extension for Digest Authentication ( ( 版)) https://tools.ietf.org/html/rfc5090
[18] RFC 4976 - Relay Extensions for the Message Sessions Relay Protocol (MSRP) ( ( 版)) https://tools.ietf.org/html/rfc4976#section-9.1
[20] draft-ivov-sipxmpp-auth-01 - Problem Statement and Possible Best Practices for Authentication of SIP+ XMPP Clients ( ( 版)) http://tools.ietf.org/html/draft-ivov-sipxmpp-auth-01
[33] ダイジェスト認証は RFC 723x と同時には改訂されてませんでしたが、 数ヶ月遅れて2015年に RFC 7616 となりました。 RFC 2617 は廃止されました。
[22] RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations ( ( 版)) https://tools.ietf.org/html/rfc7236#section-3
[11] draft-ietf-httpauth-digest-08 - HTTP Digest Access Authentication ( ( 版)) http://tools.ietf.org/html/draft-ietf-httpauth-digest-08
[19] draft-veltri-sip-alt-auth-00 - HTTP digest authentication using alternate password storage schemes ( ( 版)) http://tools.ietf.org/html/draft-veltri-sip-alt-auth-00
[21] draft-ietf-http-digest-auth-a3a8-01 - Hypertext Transfer Protocol (HTTP) Digest Authentication using Global System for Mobile Communications (GSM) A3 and A8 ( ( 版)) http://tools.ietf.org/html/draft-ietf-http-digest-auth-a3a8-01
[48] ダイジェスト認証は、広く実装されている割に、あまり使われていません。
次のような点で中途半端な存在なのが原因かもしれません。nonce などの状態を一時的に保持したり、複数台のサーバー間で共有したりする仕組みも必要となります。
(従ってライブラリーなどではダイジェスト認証は実装していないこともあります。)Bearer 方式で十分です。