メインコンテンツまでスキップ

3. ダイジェストアクセス認証方式 (Digest Access Authentication Scheme)

3.1 序論 (Introduction)​

3.1.1 目的 (Purpose)​

「HTTP/1.0」と呼ばれるプロトコルには、基本アクセス認証方式 (Basic Access Authentication Scheme) [1] の仕様が含まれています。この方式は、ユーザー名とパスワードが暗号化されていない形式でネットワーク上を渡されるため、安全なユーザー認証方法とは見なされていません。本節では、パスワードを平文で送信せず、代わりにチェックサム技術を使用する方式の仕様を提供します。これを「ダイジェストアクセス認証」(Digest Access Authentication) と呼びます。

ダイジェストアクセス認証方式は、ワールドワイドウェブのセキュリティニーズに対する完全な答えとなることを意図していません。この方式はメッセージ内容の暗号化を提供しません。その意図は単に、基本認証の最も深刻な欠陥を回避するアクセス認証方法を作成することです。

3.1.2 全体的な動作 (Overall Operation)​

基本アクセス認証 (Basic Access Authentication) と同様に、ダイジェスト方式は単純なチャレンジ-レスポンスパラダイム (Challenge-Response Paradigm) に基づいています。ダイジェスト方式は、nonce値を使用してチャレンジします。有効なレスポンスには、ユーザー名、パスワード、与えられたnonce値、HTTPメソッド、および要求されたURIのチェックサム（デフォルトではMD5チェックサム）が含まれます。このようにして、パスワードは決して平文で送信されません。基本方式と同様に、ユーザー名とパスワードは、本文書で扱われていない何らかの方法で事前に手配されなければなりません。

3.1.3 ダイジェスト値の表現 (Representation of digest values)​

オプションのヘッダーにより、サーバーはチェックサムまたはダイジェストの作成に使用されるアルゴリズムを指定できます。デフォルトではMD5アルゴリズムが使用され、これは本文書で説明されている唯一のアルゴリズムです。

本文書の目的上、128ビットのMD5ダイジェストは32のASCII印刷可能文字として表現されます。128ビットダイジェストのビットは、最上位ビットから最下位ビットへ、一度に4ビットずつ、以下のようにASCII表現に変換されます。各4ビットは、文字0123456789abcdefからその馴染みのある16進表記で表されます。つまり、バイナリ0000は文字'0'で表され、0001は'1'で表され、1111が'f'として表されるまで続きます。

3.1.4 制限事項 (Limitations)​

本文書で説明されているダイジェスト認証方式には、多くの既知の制限があります。これは基本認証を置き換えることを意図しており、それ以上のものではありません。これはパスワードベースのシステムであり、（サーバー側では）あらゆるパスワードシステムと同じ問題に悩まされます。特に、ユーザーとサーバー間でユーザーのパスワードを確立するための初期の安全な取り決めについて、本プロトコルでは規定されていません。

ユーザーと実装者は、このプロトコルがKerberosほど安全ではなく、クライアント側の秘密鍵方式ほど安全ではないことを認識すべきです。それにもかかわらず、何もないよりは良く、telnetやftpで一般的に使用されているものよりも良く、基本認証よりも良いものです。

3.2 ダイジェストヘッダーの仕様 (Specification of Digest Headers)​

ダイジェストアクセス認証方式は、概念的には基本方式に似ています。変更されたWWW-Authenticateヘッダー行とAuthorizationヘッダー行の形式を以下に指定します。さらに、新しいヘッダーであるAuthentication-Infoも指定されます。

3.2.1 WWW-Authenticateレスポンスヘッダー (The WWW-Authenticate Response Header)​

サーバーがアクセス保護されたオブジェクトへのリクエストを受信し、受け入れ可能なAuthorizationヘッダーが送信されていない場合、サーバーは「401 Unauthorized」ステータスコードで応答し、上記で定義されたフレームワークに従ってWWW-Authenticateヘッダーを使用します。ダイジェスト方式では次のように利用されます:

challenge        =  "Digest" digest-challenge

digest-challenge  = 1#( realm | [ domain ] | nonce |
                    [ opaque ] |[ stale ] | [ algorithm ] |
                    [ qop-options ] | [auth-param] )

domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
URI               = absoluteURI | abs_path
nonce             = "nonce" "=" nonce-value
nonce-value       = quoted-string
opaque            = "opaque" "=" quoted-string
stale             = "stale" "=" ( "true" | "false" )
algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" | token )
qop-options       = "qop" "=" <"> 1#qop-value <">
qop-value         = "auth" | "auth-int" | token

上記で使用される指令の値の意味は次のとおりです:

realm (領域)

  • ユーザーに表示される文字列で、使用するユーザー名とパスワードを知らせます。この文字列には、少なくとも認証を実行するホストの名前が含まれ、さらにアクセス権を持つ可能性のあるユーザーのコレクションを示す場合があります。

domain (ドメイン)

  • 保護空間 (Protection Space) を定義するURIの引用符で囲まれた、スペース区切りのリストです。URIがabs_pathの場合、アクセスされているサーバーの正規ルートURLに対して相対的です。

nonce (ノンス)

  • サーバーが指定するデータ文字列で、401レスポンスが作成されるたびに一意に生成されるべきです (SHOULD)。この文字列はbase64または16進数データであることが推奨されます。

opaque (不透明)

  • サーバーによって指定されるデータの文字列で、同じ保護空間内のURIを持つ後続のリクエストのAuthorizationヘッダーでクライアントによって変更されずに返されるべきです (SHOULD)。

stale (古い)

  • クライアントからの以前のリクエストがnonce値が古いために拒否されたことを示すフラグです。staleがTRUE（大文字小文字を区別しない）の場合、クライアントは新しいユーザー名とパスワードをユーザーに再度プロンプトすることなく、新しい暗号化されたレスポンスでリクエストを単に再試行してもよい (MAY)。

algorithm (アルゴリズム)

  • ダイジェストとチェックサムを生成するために使用されるアルゴリズムのペアを示す文字列です。これが存在しない場合、「MD5」であると想定されます。

qop-options (保護品質オプション)

  • この指令はオプションですが、RFC 2069 [6] との下位互換性のためだけにオプションになっています。このバージョンのダイジェスト方式に準拠するすべての実装で使用すべきです (SHOULD)。存在する場合、サーバーがサポートする「保護品質」値を示す1つ以上のトークンの引用符で囲まれた文字列です。

3.2.2 Authorizationリクエストヘッダー (The Authorization Request Header)​

クライアントは、以下に指定されているように計算されたresponse指令を渡して、Authorizationヘッダー行を使用してリクエストを再試行することが期待されます。

credentials      = "Digest" digest-response
digest-response  = 1#( username | realm | nonce | digest-uri
                   | response | [ algorithm ] | [cnonce] |
                   [opaque] | [message-qop] |
                   [nonce-count]  | [auth-param] )

username         = "username" "=" username-value
username-value   = quoted-string
digest-uri       = "uri" "=" digest-uri-value
digest-uri-value = request-uri
message-qop      = "qop" "=" qop-value
cnonce           = "cnonce" "=" cnonce-value
cnonce-value     = nonce-value
nonce-count      = "nc" "=" nc-value
nc-value         = 8LHEX
response         = "response" "=" request-digest
request-digest   = <"> 32LHEX <">
LHEX             = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                   "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"

3.2.3 Authentication-Infoヘッダー (The Authentication-Info Header)​

Authentication-Infoヘッダーフィールドは、認証が成功した後のレスポンスで、認証の成功に関する情報を送信するためにサーバーによって使用されてもよい (MAY)。このヘッダーは、「auth-int」保護品質で特に有用です。

AuthenticationInfo = "Authentication-Info" ":" auth-info
auth-info          = 1#(nextnonce | [ message-qop ]
                     | [ response-auth ] | [ cnonce ]
                     | [nonce-count] )
nextnonce          = "nextnonce" "=" nonce-value
response-auth      = "rspauth" "=" response-digest
response-digest    = <"> *LHEX <">

3.3 ダイジェスト操作 (Digest Operation)​

ダイジェストアクセス認証の動作は次のとおりです。クライアントがサーバーにリクエストを行い、サーバーは401レスポンスでチャレンジし、nonceおよびその他のパラメータを提供します。クライアントはこれらのパラメータを使用してresponse値を計算し、それを他の情報とともにサーバーへの後続のリクエストで送信します。サーバーはresponse値を検証し、正しい場合はアクセスを許可します。

3.4 セキュリティプロトコル交渉 (Security Protocol Negotiation)​

サーバーは、WWW-Authenticateヘッダーに複数のチャレンジを提供してもよく (MAY)、それぞれが異なる認証方式を使用します。クライアントは、サポートする最も強力な方式を選択すべきです (SHOULD)。

3.5 例 (Example)​

次の例では、保護されたドキュメントへのアクセスに認証が必要であると仮定します。サーバーは401レスポンスでチャレンジします:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
    realm="[email protected]",
    qop="auth,auth-int",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

クライアントは次のAuthorizationヘッダーで応答してもよい (MAY):

Authorization: Digest username="Mufasa",
    realm="[email protected]",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    uri="/dir/index.html",
    qop=auth,
    nc=00000001,
    cnonce="0a4f113b",
    response="6629fae49393a05397450978507c4ef1",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

3.6 プロキシ認証とプロキシ承認 (Proxy-Authentication and Proxy-Authorization)​

プロキシ認証と承認は、オリジンサーバー認証と承認と同様に機能しますが、Proxy-AuthenticateおよびProxy-Authorizationヘッダーフィールドを使用します。プロキシは、クライアントとオリジンサーバー間の認証を処理する際に完全に透過的でなければなりません (MUST)。

に最終更新