RFC 7616

Digest 認証 (HTTP)

仕様書

意味

[37] ダイジェスト認証は、 challenge-response 型の認証方式です。 HTTP応答に含まれる challenge では、 nonce の値を伝達します。 それに対するHTTP要求に含まれる challenge への応答 (response) には、 利用者名 (username) 合言葉 (password) 、 与えられた nonce 値、要求メソッド要求URL要約値を含めます。 >>36

[38] 従って合言葉そのものを転送する必要はありませんし、 利用者名サーバーが対応していることを示した場合はハッシュ化できます。 >>36

[39] 利用者名合言葉についてサーバークライアントの間で合意する方法は、 ダイジェスト認証の仕様の範囲外 >>36 とされています。

[64] 合言葉は十分エントロピーの高い (例えば128ビット以上の) 値とするべきです。普通そんな合言葉人間には覚えられませんが、 自動化された Webサービスなら使うことができます。 >>63

[65]RFC は言っていますが、実際にダイジェスト認証がそういう使い方がされていることはあまりないようです。 そういう場面ではむしろ基本認証Bearer (あるいは古くは WSSE) が使われています。

auth-scheme

[43] auth-scheme は、 Digest です。

引数

[41] challengeauth-param には、 次の引数を指定できます。

[42] credentialsauth-param には、 次の引数を指定できます。

[62] Authentication-Info: ヘッダーProxy-Authentication-Info: ヘッダーについては、 そちらの項を参照。

文脈

[35] Webブラウザーは、 Web互換性のため、ダイジェスト認証に対応しなければなりません。

[27] WebDAV 応用は、 ダイジェスト認証に対応しなければなりません >>26

[66] ダイジェスト認証は、 HTTPS など保安通信路上で使うべきです>>63

ダイジェストアルゴリズム

[40] ダイジェストアルゴリズム参照。

認証セッション

[58] ある保護空間認証セッション (authentication session) は、 その保護空間WWW-Authenticate:challenge に対してクライアント応答するところから始まり、 クライアントが当該[保護空間]]のサーバーから他の WWW-Authenticate:challenge を受信することで終わります。 >>53

[59] クライアントは、 保護空間内の後の要求Authorization: ヘッダーで使うための利用者名合言葉noncenonce の数 (nc)、 opaque 値を認証セッションに関連付けて記憶するべきです>>53

処理

[45] credentials引数やその値が不適切だったり、 必須のものが指定されていなかったりした時は、 4xx 応答を返すのが適切です >>44

[54] サーバーは、 Authorization: ヘッダーを受信したら、提出された利用者名に対応する合言葉を探し、 妥当性を検査して構いません。 次に、クライアントが行ったのと同じダイジェストアルゴリズムを適用し、 response 値と比較しなければなりません>>53

[55] サーバーは、 H (A1) さえ覚えておけば、合言葉平文で保存しておく必要はありません。 >>53
[56]RFC は言っていますが、そうすると MD5SHA1SHA2 のようなダイジェストアルゴリズムの移行が不可能になってしまいます。

[46] ログインの失敗は、記録するべきです。 特定のクライアントが失敗を繰り返す時は、 合言葉を推測する攻撃かもしれません。 >>44

[47] サーバーは、記録時には平文合言葉が記録されないよう注意するべきです >>44。 例えば利用者名に誤って合言葉が記入されるかもしれません >>44

[57] そんな無茶な...

[60] Authorization: ヘッダーを (challenge を受信せずに) 予め要求に含めておいても構いません。 >>53

[61] サーバーは、古い Authorization: ヘッダーを受け入れることとしても構いません。 nonce新鮮でなくても受け入れて構いません。 あるいは新しい nonce 値を含む 401 応答を返してクライアントに再試行を求めても構いません。 >>53

関連

[31] HTTP認証では基本認証の方がよく使われています。ダイジェスト認証も広く実装されてはいますが、 さほど使われていないようです。

[25] ダイジェスト認証本体や一部のヘッダーダイジェスト値を使いますが、 同様にダイジェスト値を使う HTTP の機能として Content-MD5: ヘッダーWant-Digest: ヘッダーがあります。

歴史

第1世代 RFC 2069

[7] Digest に関わる特許権の主張があったようですが (現在は削除されています。) >>6Digest ではなくそれを用いた技術に関するものらしく >>8、しかも元の RFC の10年後の2008年の出願である >>9 ことから、明らかに不適当なものです。 そのためか主張は取下げられた >>6 ようです。

第2世代 RFC 2617

[4] RFC 2068 世代の RFC 2069Digest認証単独の仕様書でしたが、 次の RFC 2617Basic認証と共通の仕様書になっています。

[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

[30] HTTP クライアントを作ってみよう(6) - Digest 認証編 - ( 版) http://x68000.q-e-d.net/~68user/net/http-auth-2.html

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

Atom

[29] AtomDigest認証がそのままでは実用に供せないとして、 auth-scheme Atom を使おうとしました >>28。これは WS-Security に影響されて WSSE となりました。

WSSEAtomPub を参照。
[28] New AtomAPI Implementation Release | BitWorking | Joe Gregorio ( 版) http://web.archive.org/web/20101213023745/http://bitworking.org/news/New_AtomAPI_Implementation_Release2

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.

SIP

[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

第3世代 RFC 7616

[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] ダイジェスト認証は、広く実装されている割に、あまり使われていません。 次のような点で中途半端な存在なのが原因かもしれません。

[67] rfc4169, https://datatracker.ietf.org/doc/html/rfc4169