* 仕様書 [REFS[ - [32] '''[CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) ''' -- [36] [CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) --- [44] [CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) --- [53] [CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) -- [63] [CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) - [34] [CITE[RFC Errata Report » RFC Editor]] ([TIME[2015-11-27 18:09:15 +09:00]] 版) - [5] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) - [26] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) ]REFS] * 意味 [37] [[ダイジェスト認証]]は、 challenge-response 型の[[認証方式]]です。 [[HTTP応答]]に含まれる [[challenge]] では、 [[nonce]] の値を伝達します。 それに対する[[HTTP要求]]に含まれる [[challenge]] への[RUBYB[[[応答]]]@en[response]]には、 [RUBYB[[[利用者名]]]@en[username]]、[RUBYB[[[合言葉]]]@en[password]]、 与えられた [[nonce]] 値、[[要求メソッド]]、[[要求URL]]の[[要約値]]を含めます。 [SRC[>>36]] [38] 従って[[合言葉]]そのものを転送する必要はありませんし、 [[利用者名]]も[[サーバー]]が対応していることを示した場合は[[ハッシュ化]]できます。 [SRC[>>36]] ;; [39] [[利用者名]]と[[合言葉]]について[[サーバー]]と[[クライアント]]の間で合意する方法は、 [[ダイジェスト認証]]の仕様の範囲外 [SRC[>>36]] とされています。 [64] [[合言葉]]は十分[[エントロピー]]の高い (例えば128ビット[[以上]]の) 値とする[['''べきです''']]。普通そんな[[合言葉]]は[[人間]]には覚えられませんが、 自動化された [[Webサービス]]なら使うことができます。 [SRC[>>63]] ;; [65] と [[RFC]] は言っていますが、実際に[[ダイジェスト認証]]がそういう使い方がされていることはあまりないようです。 そういう場面ではむしろ[[基本認証]]や [CODE[[[Bearer]]]] (あるいは古くは [[WSSE]]) が使われています。 * [CODE(ABNF)@en[auth-scheme]] [43] [CODE(ABNF)@en[[[auth-scheme]]]] は、 [CODE(HTTP)@en[[[Digest]]]] です。 * 引数 [41] [[challenge]] の [CODE(ABNF)@en[[[auth-param]]]] には、 次の[[引数]]を指定できます。 [FIG(short list)[ - [CODE(HTTP)@en[[[realm]]]] - [CODE(HTTP)@en[[[domain]]]] - [CODE(HTTP)@en[[[nonce]]]] - [CODE(HTTP)@en[[[opaque]]]] - [CODE(HTTP)@en[[[stale]]]] - [CODE(HTTP)@en[[[algorithm]]]] - [CODE(HTTP)@en[[[qop]]]] - [CODE(HTTP)@en[[[charset]]]] - [CODE(HTTP)@en[[[userhash]]]] ]FIG] [42] [[credentials]] の [CODE(ABNF)@en[[[auth-param]]]] には、 次の[[引数]]を指定できます。 [FIG(short list)[ - [CODE(HTTP)@en[[[response]]]] - [CODE(HTTP)@en[[[username]]]] - [CODE(HTTP)@en[[[username*]]]] - [CODE(HTTP)@en[[[realm]]]] - [CODE(HTTP)@en[[[uri]]]] - [CODE(HTTP)@en[[[qop]]]] - [CODE(HTTP)@en[[[cnonce]]]] - [CODE(HTTP)@en[[[nc]]]] - [CODE(HTTP)@en[[[userhash]]]] ]FIG] [62] [CODE(HTTP)@en[[[Authentication-Info:]]]] [[ヘッダー]]や [CODE(HTTP)@en[[[Proxy-Authentication-Info:]]]] [[ヘッダー]]については、 そちらの項を参照。 * 文脈 [35] [[Webブラウザー]]は、 [[Web互換性]]のため、[[ダイジェスト認証]]に対応しなければなりません。 [27] [[WebDAV]] [[応用]]は、 [[ダイジェスト認証]]に対応しなければ[['''なりません''']] [SRC[>>26]]。 [66] [[ダイジェスト認証]]は、 [[HTTPS]] など[[保安通信路]]上で使う[['''べきです''']]。 [SRC[>>63]] * ダイジェストアルゴリズム [40] [[ダイジェストアルゴリズム]]参照。 * 認証セッション [58] ある[[保護空間]]の[RUBYB[認証セッション]@en[authentication session]]は、 その[[保護空間]]の [CODE(HTTP)@en[[[WWW-Authenticate:]]]] の [[challenge]] に対して[[クライアント]]が[[応答]]するところから始まり、 [[クライアント]]が当該[保護空間]]の[[サーバー]]から他の [CODE(HTTP)@en[[[WWW-Authenticate:]]]] の [[challenge]] を受信することで終わります。 [SRC[>>53]] [59] [[クライアント]]は、 [[保護空間]]内の後の[[要求]]の [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]で使うための[[利用者名]]、[[合言葉]]、[[nonce]]、[[nonce]] の数 ([CODE[[[nc]]]])、 [CODE[[[opaque]]]] 値を[[認証セッション]]に関連付けて記憶する[['''べきです''']]。 [SRC[>>53]] * 処理 [45] [[credentials]] の[[引数]]やその値が不適切だったり、 必須のものが指定されていなかったりした時は、 [CODE(HTTP)[[[4xx]]]] [[応答]]を返すのが適切です [SRC[>>44]]。 [54] [[サーバー]]は、 [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]を受信したら、提出された[[利用者名]]に対応する[[合言葉]]を探し、 [[妥当性]]を検査して構いません。 次に、[[クライアント]]が行ったのと同じ[[ダイジェストアルゴリズム]]を適用し、 [CODE[[[response]]]] 値と比較しなければ[['''なりません''']]。 [SRC[>>53]] ;; [55] [[サーバー]]は、 [CODE[[VAR[[[H]]]] ([VAR[[[A1]]]])]] さえ覚えておけば、[[合言葉]]を[[平文]]で保存しておく必要はありません。 [SRC[>>53]] ;; [56] と [[RFC]] は言っていますが、そうすると [[MD5]] → [[SHA1]] → [[SHA2]] のような[[ダイジェストアルゴリズム]]の移行が不可能になってしまいます。 [46] [[ログイン]]の失敗は、記録する[['''べきです''']]。 特定の[[クライアント]]が失敗を繰り返す時は、 [[合言葉]]を推測する攻撃かもしれません。 [SRC[>>44]] [47] [[サーバー]]は、記録時には[[平文]]の[[合言葉]]が記録されないよう注意する[['''べきです''']] [SRC[>>44]]。 例えば[[利用者名]]に誤って[[合言葉]]が記入されるかもしれません [SRC[>>44]]。 ;; [57] そんな無茶な... [60] [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]を ([[challenge]] を受信せずに) 予め[[要求]]に含めておいても構いません。 [SRC[>>53]] [61] [[サーバー]]は、古い [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]を受け入れることとしても構いません。 [[nonce]] が[[新鮮]]でなくても受け入れて構いません。 あるいは新しい [CODE[[[nonce]]]] 値を含む [CODE(HTTP)[[[401]]]] [[応答]]を返して[[クライアント]]に再試行を求めても構いません。 [SRC[>>53]] * 関連 [31] [[HTTP認証]]では[[基本認証]]の方がよく使われています。[[ダイジェスト認証]]も広く実装されてはいますが、 さほど使われていないようです。 [25] [[ダイジェスト認証]]は[[本体]]や一部の[[ヘッダー]]の[[ダイジェスト値]]を使いますが、 同様に[[ダイジェスト値]]を使う [[HTTP]] の機能として [CODE(HTTP)@en[[[Content-MD5:]]]] [[ヘッダー]]や [CODE(HTTP)@en[[[Want-Digest:]]]] [[ヘッダー]]があります。 * 歴史 ** 第1世代 RFC 2069 [REFS[ - [1] [CITE@en[RFC 2069 - An Extension to HTTP : Digest Access Authentication]] ([TIME[2012-02-26 10:05:21 +09:00]] 版) ]REFS] [7] [CODE(HTTP)@en[[[Digest]]]] に関わる[[特許権]]の主張があったようですが (現在は削除されています。) [SRC[>>6]]、 [CODE(HTTP)@en[[[Digest]]]] ではなくそれを用いた技術に関するものらしく [SRC[>>8]]、しかも元の [[RFC]] の10年後の2008年の出願である [SRC[>>9]] ことから、明らかに不適当なものです。 そのためか主張は取下げられた [SRC[>>6]] ようです。 [REFS[ - [6] [CITE@en[IPR Details - CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11]] ([TIME[2014-10-21 14:36:27 +09:00]] 版) - [8] [CITE@en[Re: IPR Disclosure: CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11]] ([[Robert Collins]] 著, [TIME[2010-09-01 10:12:41 +09:00]] 版) - [9] [CITE[Fwd: IPR Disclosure: CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11]] ([TIME[2012-05-07 18:49:55 +09:00]] 版) ]REFS] ** 第2世代 RFC 2617 [REFS[ - [3] [2] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) ]REFS] [4] [[RFC 2068]] 世代の [[RFC 2069]] は [[Digest認証]]単独の仕様書でしたが、 次の [[RFC 2617]] は [[Basic認証]]と共通の仕様書になっています。 [23] [CITE@en[draft-ietf-http-digest-aa-00 - An Extension to HTTP : Digest Access Authentication]] ( ([TIME[2014-10-16 21:03:19 +09:00]] 版)) [12] [CITE@en[RFC 3310 - Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)]] ( ([TIME[2014-07-27 08:35:17 +09:00]] 版)) [14] [CITE@en[draft-santesson-digestbind-01 - Channel binding for HTTP Digest Authentication]] ( ([TIME[2014-10-20 03:22:56 +09:00]] 版)) [15] [CITE@en[RFC 2831 - Using Digest Authentication as a SASL Mechanism]] ( ([TIME[2014-09-28 07:45:48 +09:00]] 版)) [16] [CITE@en[RFC 6331 - Moving DIGEST-MD5 to Historic]] ( ([TIME[2014-09-14 08:29:19 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [30] [CITE@ja[HTTP クライアントを作ってみよう(6) - Digest 認証編 -]] ([TIME[2015-06-15 18:56:36 +09:00]] 版) ]FIGCAPTION] > 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 ]FIG] ** Atom [29] [[Atom]] は [[Digest認証]]がそのままでは実用に供せないとして、 [CODE(ABNF)@en[[[auth-scheme]]]] [DFN[[CODE(HTTP)@en[[[Atom]]]]]] を使おうとしました [SRC[>>28]]。これは [[WS-Security]] に影響されて [[WSSE]] となりました。 ;; [[WSSE]]、[[AtomPub]] を参照。 [FIG(quote)[ [FIGCAPTION[ [28] [CITE[New AtomAPI Implementation Release | BitWorking | Joe Gregorio]] ([TIME[2015-02-21 01:28:56 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] ** SIP [24] [CITE@en[draft-smith-sipping-auth-examples-01 - Digest Authentication Examples for Session Initiation Protocol (SIP)]] ( ([TIME[2014-10-16 12:01:47 +09:00]] 版)) [10] [CITE@en[draft-yusef-sipcore-digest-scheme-04 - The Session Initiation Protocol (SIP) Digest Authentication Scheme]] ( ([TIME[2014-10-21 20:31:07 +09:00]] 版)) [13] [CITE@en[draft-sen-sipping-onehop-digest-00 - Single Hop Message Authentication in SIP]] ( ([TIME[2014-10-16 22:15:52 +09:00]] 版)) [17] [CITE@en[RFC 5090 - RADIUS Extension for Digest Authentication]] ( ([TIME[2014-09-21 10:50:27 +09:00]] 版)) [18] [CITE@en[RFC 4976 - Relay Extensions for the Message Sessions Relay Protocol (MSRP)]] ( ([TIME[2014-10-18 23:44:47 +09:00]] 版)) [20] [CITE@en[draft-ivov-sipxmpp-auth-01 - Problem Statement and Possible Best Practices for Authentication of SIP+ XMPP Clients]] ( ([TIME[2014-10-14 11:37:53 +09:00]] 版)) ** 第3世代 RFC 7616 [33] [[ダイジェスト認証]]は [[RFC 723x]] と同時には改訂されてませんでしたが、 数ヶ月遅れて2015年に [DFN[[[RFC 7616]]]] となりました。 [[RFC 2617]] は[[廃止]]されました。 [22] [CITE@en[RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations]] ( ([TIME[2014-09-10 00:40:16 +09:00]] 版)) [11] [CITE@en[draft-ietf-httpauth-digest-08 - HTTP Digest Access Authentication]] ( ([TIME[2014-10-16 11:44:53 +09:00]] 版)) [19] [CITE@en[draft-veltri-sip-alt-auth-00 - HTTP digest authentication using alternate password storage schemes]] ( ([TIME[2014-10-19 13:09:02 +09:00]] 版)) [21] [CITE@en[draft-ietf-http-digest-auth-a3a8-01 - Hypertext Transfer Protocol (HTTP) Digest Authentication using Global System for Mobile Communications (GSM) A3 and A8]] ( ([TIME[2014-10-17 11:40:05 +09:00]] 版)) * メモ [48] [[ダイジェスト認証]]は、広く実装されている割に、あまり使われていません。 次のような点で中途半端な存在なのが原因かもしれません。 [FIG(list)[ - [49] [[合言葉]]を直接送信するという最大の危険は回避できるとはいえ、 [[合言葉]]方式の欠点 ([[利用者]]が適切に[[合言葉]]を決定・管理できなければならない) は[[基本認証]]その他と何ら変わりありません。 - [50] [[基本認証]]と同じく [[HTTP認証]]の[[利用者インターフェイス]]上の問題から、 [[Webアプリケーション]]では[[クッキー認証]]を使うのが主流です。 - [51] [[基本認証]]と比べて複雑で、独自の[[クライアント]]や[[サーバー]]で新たに実装するのは手間です。 [CODE[[[nonce]]]] などの状態を一時的に保持したり、複数台の[[サーバー]]間で共有したりする仕組みも必要となります。 (従って[[ライブラリー]]などでは[[ダイジェスト認証]]は実装していないこともあります。) - [52] [[合言葉]]の直接送信が危険だとは言っても、 [[TLS]] を使えば[[輸送路]]での盗聴の心配はなくなります。 特に[[APIキー]]の類の場合は、[[基本認証]]や [CODE[[[Bearer]]]] 方式で十分です。 ]FIG] [67] [CITE@en[rfc4169]], [TIME[2021-07-27T07:46:36.000Z]]