Network Working Group J. Franks
Request for Comments: 2617 Northwestern University
Obsoletes: 2069 P. Hallam-Baker
Category: Standards Track Verisign, Inc.
J. Hostetler
AbiSource, Inc.
S. Lawrence
Agranat Systems, Inc.
P. Leach
Microsoft Corporation
A. Luotonen
Netscape Communications Corporation
L. Stewart
Open Market, Inc.
June 1999
HTTP Authentication: Basic and Digest Access Authentication
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
"HTTP/1.0", includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
「HTTP / 1.0」は、基本アクセス認証スキームのための仕様を含んでいます。 （SSLなどのいくつかの外部の安全なシステム[5]と組み合わせて使用しない限り）、ユーザ名とパスワードを平文としてネットワークを介して渡されるように、この方式は、ユーザー認証の安全な方法であるとは考えられません。
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
また、このドキュメントでは、HTTPの認証フレームワーク、オリジナルの基本認証スキームと「ダイジェストアクセス認証」と呼ばれる暗号化ハッシュに基づくスキームのための仕様を提供します。したがって、また、RFC 2069の代替として機能することが意図されている[6]。 RFC 2069で指定されたいくつかのオプションの要素は、その出版以来、検出された問題には、この仕様から削除されています。他の新しい要素は互換性のために追加された、これらの新しい要素はオプションで行われているが、強く推奨されています。
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.
基本のように、ダイジェストアクセス認証は、通信の両当事者は、共有シークレット（パスワード）を知っていることを確認します。基本とは異なり、この検証は、Basicの最大の弱点である平文でパスワードを送信することなく行うことができます。他のほとんどの認証プロトコルと同様に、リスクの最大の発生源は、通常はコアプロトコル自体ではなく、その使用を囲む方針と手順で発見されています。
Table of Contents
目次
1 Access Authentication................................ 3
1.1 Reliance on the HTTP/1.1 Specification............ 3
1.2 Access Authentication Framework................... 3
2 Basic Authentication Scheme.......................... 5
3 Digest Access Authentication Scheme.................. 6
3.1 Introduction...................................... 6
3.1.1 Purpose......................................... 6
3.1.2 Overall Operation............................... 6
3.1.3 Representation of digest values................. 7
3.1.4 Limitations..................................... 7
3.2 Specification of Digest Headers................... 7
3.2.1 The WWW-Authenticate Response Header............ 8
3.2.2 The Authorization Request Header................ 11
3.2.3 The Authentication-Info Header.................. 15
3.3 Digest Operation.................................. 17
3.4 Security Protocol Negotiation..................... 18
3.5 Example........................................... 18
3.6 Proxy-Authentication and Proxy-Authorization...... 19
4 Security Considerations.............................. 19
4.1 Authentication of Clients using Basic
Authentication.................................... 19
4.2 Authentication of Clients using Digest
Authentication.................................... 20
4.3 Limited Use Nonce Values.......................... 21
4.4 Comparison of Digest with Basic Authentication.... 22
4.5 Replay Attacks.................................... 22
4.6 Weakness Created by Multiple Authentication
Schemes........................................... 23
4.7 Online dictionary attacks......................... 23
4.8 Man in the Middle................................. 24
4.9 Chosen plaintext attacks.......................... 24
4.10 Precomputed dictionary attacks.................... 25
4.11 Batch brute force attacks......................... 25
4.12 Spoofing by Counterfeit Servers................... 25
4.13 Storing passwords................................. 26
4.14 Summary........................................... 26
5 Sample implementation................................ 27
6 Acknowledgments...................................... 31
7 References........................................... 31
8 Authors' Addresses................................... 32
9 Full Copyright Statement............................. 34
1 Access Authentication
1アクセス認証
This specification is a companion to the HTTP/1.1 specification [2]. It uses the augmented BNF section 2.1 of that document, and relies on both the non-terminals defined in that document and other aspects of the HTTP/1.1 specification.
この仕様は、HTTP / 1.1仕様書[2]の仲間です。その文書の拡張BNFセクション2.1を使用し、その文書とHTTP / 1.1仕様の他の態様で定義された非末端の両方に依存しています。
HTTP provides a simple challenge-response authentication mechanism that MAY be used by a server to challenge a client request and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
HTTPは認証情報を提供するために、クライアントの要求に挑戦するためにサーバーが使用すると、クライアントによることができる簡単なチャレンジレスポンス認証メカニズムを提供します。その方式による認証を達成するために必要なパラメータを搬送する属性と値のペアのカンマ区切りリストが続く認証方式を識別するために、拡張可能、大文字と小文字を区別しないトークンを使用します。
auth-scheme = token auth-param = token "=" ( token | quoted-string )
auth-スキーム=トークンのauth-PARAM =トークン "="（トークン|引用符で囲まれた文字列）
The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and MUST include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
401（不正な）応答メッセージはユーザエージェントの権限に挑戦するオリジンサーバによって使用されます。この応答は、要求されたリソースに適用可能な少なくとも一つのチャレンジを含むWWW-Authenticateヘッダフィールドを含まなければなりません。 407（プロキシ認証が必要）応答メッセージは、クライアントの権限に挑戦するためにプロキシによって使用され、要求されたリソースのプロキシに適用少なくとも一つの挑戦を含むプロキシ認証ヘッダフィールドを含まなければなりません。
challenge = auth-scheme 1*SP 1#auth-param
挑戦=のauth-スキーム1 *のSP 1つの＃1のauth-PARAM
Note: User agents will need to take special care in parsing the WWW-Authenticate or Proxy-Authenticate header field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.
注：ユーザー・エージェントは、それが複数の課題が含まれている場合、WWW認証またはプロキシ-Authenticateヘッダフィールド値を解析するには、特別な世話をする必要があります、または複数のWWW-Authenticateヘッダフィールドが用意されている場合、課題の内容から自身が認証パラメータをカンマで区切ったリストが含まれていてもよいです。
The authentication parameter realm is defined for all authentication schemes:
認証パラメータレルムがすべての認証スキームのために定義されています。
realm = "realm" "=" realm-value realm-value = quoted-string
分野=「王国」「=」レルム値レルム値=引用符で囲まれた文字列
The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.
レルムディレクティブは（大文字と小文字を区別しない）の挑戦を発行するすべての認証スキームのために必要とされます。レルム値（大文字と小文字を区別）は、正規のルートURL（腹筋_経路空であるサーバのabsoluteURIで、[2]のセクション5.1.2を参照）と組み合わせてアクセスされるサーバの、保護空間を画定します。これらのレルムは、サーバー上の保護されたリソースは、保護スペースのセットに分割することを可能にする独自の認証スキームおよび/または認証データベースを持つ各。レルム値は、認証方式に固有の追加の意味を有していてもよく、一般的にオリジンサーバによって割り当てられた文字列、です。同じAUTH-スキームが、異なるレルムを持つ複数の課題が存在してもよいことに留意されたいです。
A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy--usually, but not necessarily, after receiving a 407 (Proxy Authentication Required)--MAY do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication information of the client for the realm of the resource being requested. The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based upon that challenge.
401（不正）を受信した後、必ずしも通常ではなく、 - - オリジンサーバに自身を認証することを望むユーザエージェントは、リクエストにAuthorizationヘッダフィールドを含めることでそれを行うことができます。 407（プロキシ認証が必要）を受信した後、必ずしも通常ではなく、 - - プロキシでそれ自体を認証することを望むクライアントは、要求にProxy-Authorizationヘッダフィールドを含めることでそれを行うことができます。 Authorizationフィールド値とプロキシ-Authorizationフィールド値の両方が要求されたリソースのレルムのクライアントの認証情報を含む資格情報で構成されています。ユーザエージェントは、それが理解して最強のauth-スキームでの課題のいずれかを使用し、その挑戦に基づいて、ユーザーの資格情報を要求するために選択する必要があります。
credentials = auth-scheme #auth-param
資格情報=のauth-スキーム＃1のauth-PARAM
Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include Basic if it is minimally acceptable.
多くのブラウザが唯一の基本的な認識し、それが最初のauth-スキームを提示することを必要とすることに注意してください。それが最低限許容されている場合、サーバーが唯一の基本を含める必要があります。
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.
保護空間は、資格情報が自動的に適用することができ、その上のドメインを決定します。事前のリクエストが許可されている場合は、同じ資格情報が認証スキーム、パラメータ、および/またはユーザの好みによって決定された時間の間、その保護空間内の他のすべての要求のために再利用することができます。それ以外の場合は認証スキームによって定義されない限り、単一の保護領域は、そのサーバーの範囲外で拡張することはできません。
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.
オリジンサーバがリクエストと共に送られた資格証明書を受け入れたくない場合は、401（無許可）レスポンスを返すべきです。応答は、要求されたリソースに適用可能な少なくとも一つの（おそらく新しい）チャレンジを含むWWW-Authenticateヘッダフィールドを含まなければなりません。プロキシはリクエストで送られた資格証明書を受け入れない場合は、407（プロキシ認証が必要）を返すべきです。応答は、要求されたリソースのプロキシに適用（おそらく新しい）チャレンジを含むプロキシ認証ヘッダフィールドを含まなければなりません。
The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.
HTTPプロトコルでは、アクセス認証のためにこの簡単なチャレンジレスポンスメカニズムへの応用を制限するものではありません。付加的なメカニズムは、トランスポート・レベルまたはメッセージのカプセル化を介して、認証情報を指定する追加のヘッダフィールドと暗号化などを使用することができます。しかし、これらの追加のメカニズムはこの仕様で定義されていません。
Proxies MUST be completely transparent regarding user agent authentication by origin servers. That is, they must forward the WWW-Authenticate and Authorization headers untouched, and follow the rules found in section 14.8 of [2]. Both the Proxy-Authenticate and the Proxy-Authorization header fields are hop-by-hop headers (see section 13.5.1 of [2]).
プロキシは、オリジンサーバによるユーザエージェント認証に関して完全に透明でなければなりません。つまり、彼らはそのままWWW認証及び認可ヘッダを転送し、[2]のセクション14.8に見られる規則に従わなければなりません。プロキシ認証およびプロキシ認証ヘッダフィールドの両方は、ホップバイホップヘッダである（[2]のセクション13.5.1を参照されたいです）。
2 Basic Authentication Scheme
2基本認証スキーム
The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.
「基本」認証方式は、クライアントは、ユーザーIDおよび各レルムのパスワードを使用して自身を認証しなければならないモデルに基づいています。レルム値は、そのサーバー上の他のレルムと等しいかどうかを比較することができ、不透明な文字列を考慮しなければなりません。それは要求URIの保護空間のためのユーザーIDとパスワードを検証できる場合にのみ、サーバは要求を処理します。何のオプションの認証パラメータはありません。
For Basic, the framework above is utilized as follows:
次のように基本のために、上記フレームワークが利用されます。
challenge = "Basic" realm credentials = "Basic" basic-credentials
挑戦=「基本」レルムの資格情報=「基本」基本資格証明書
Upon receipt of an unauthorized request for a URI within the protection space, the origin server MAY respond with a challenge like the following:
保護空間内のURIのための不正な要求を受信すると、オリジンサーバは、以下のような課題に応えることがあります。
WWW-Authenticate: Basic realm="WallyWorld"
WWW認証：基本レルム=「WallyWorld」
where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond with the same challenge using the Proxy-Authenticate header field.
ここで、「WallyWorldは、」要求-URIの保護空間を識別するために、サーバによって割り当てられた文字列です。プロキシは、プロキシ認証ヘッダフィールドを使用して、同じチャレンジで応答することができます。
To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials.
base64の資格情報で、[7]エンコードされた文字列内の文字、：承認を受けるために、クライアントは、ユーザーIDとパスワード、単一のコロン（「」）で区切って送信します。
basic-credentials = base64-user-pass base64-user-pass = <base64 [4] encoding of user-pass,
ユーザパスの基本クレデンシャル= BASE64ユーザパスBASE64ユーザパス= <BASE64 [4]符号化、
except not limited to 76 char/line> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT
「：」を除くパスワードユーザーID = * <TEXT「：」>パスワード= * TEXT 76文字/行>ユーザーパス=ユーザーIDに限定されない以外
Userids might be case sensitive.
ユーザIDは大文字と小文字を区別している可能性があります。
If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:
ユーザエージェントはユーザID「アラジン」、パスワード「開けゴマ」を送信したい場合は、以下のヘッダフィールドを使用します。
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
認証：基本QWxhZGRpbjpvcGVuIHNlc2FtZQ ==
A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See section 4 for security considerations associated with Basic authentication.
クライアントは、Request-URIのパス・フィールドの最後の象徴的要素の深さよりも、すべてのパスや深いも現在の課題の基本的なレルム値で指定された保護空間内にあることを前提とすべきです。クライアントが先制サーバーから別の挑戦を受領せずにそのスペース内のリソースに対する要求と対応するAuthorizationヘッダを送信することができます。クライアントはプロキシにリクエストを送信する場合も同様に、それはプロキシサーバから別の挑戦を受けることなく、Proxy-AuthorizationヘッダフィールドでユーザーIDとパスワードを再利用することができます。基本認証に関連するセキュリティ上の考慮事項のためのセクション4を参照してください。
3 Digest Access Authentication Scheme
3ダイジェストアクセス認証スキーム
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme[1]. That scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network in an unencrypted form. This section provides the specification for a scheme that does not send the password in cleartext, referred to as "Digest Access Authentication".
「HTTP / 1.0」が基本的なアクセス認証方式のための仕様書[1]を含むようなプロトコルを称します。ユーザー名とパスワードが暗号化されていない形式でネットワーク上を通過しているように、そのスキームは、ユーザー認証の安全な方法ではないと考えられます。このセクションでは、クリアテキストでパスワードを送信しないスキームのための仕様を提供し、「ダイジェストアクセス認証」と呼ばれます。
The Digest Access Authentication scheme is not intended to be a complete answer to the need for security in the World Wide Web. This scheme provides no encryption of message content. The intent is simply to create an access authentication method that avoids the most serious flaws of Basic authentication.
ダイジェストアクセス認証スキームは、ワールド・ワイド・ウェブでのセキュリティの必要性に完全な答えであることを意図したものではありません。この方式は、メッセージ内容のない暗号化を提供していません。その意図は、基本認証の最も重大な欠陥を回避したアクセス認証方法を作成するだけです。
Like Basic Access Authentication, the Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value. A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear. Just as with the Basic scheme, the username and password must be prearranged in some fashion not addressed by this document.
基本アクセス認証と同様に、ダイジェストスキームは、単純なチャレンジ・レスポンスパラダイムに基づいています。ダイジェスト方式はナンス値を使用して挑戦します。有効な応答は、ユーザー名、パスワード、与えられたノンス値、HTTPメソッド、および要求されたURIの（デフォルトでは、MD5チェックサム）チェックサムが含まれています。このように、パスワードが平文で送信されることはありません。ただ、基本的なスキームと同様に、ユーザ名とパスワードは、この文書で扱われていない何らかの方法で事前に決められなければなりません。
An optional header allows the server to specify the algorithm used to create the checksum or digest. By default the MD5 algorithm is used and that is the only algorithm described in this document.
オプションヘッダは、サーバがチェックサムを作成するか、または消化するために使用されるアルゴリズムを指定することを可能にします。デフォルトでは、MD5アルゴリズムが使用され、それは、この文書で説明する唯一のアルゴリズムです。
For the purposes of this document, an MD5 digest of 128 bits is represented as 32 ASCII printable characters. The bits in the 128 bit digest are converted from most significant to least significant bit, four bits at a time to their ASCII presentation as follows. Each four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef. That is, binary 0000 gets represented by the character '0', 0001, by '1', and so on up to the representation of 1111 as 'f'.
本文書の目的のために、128ビットのMD5ダイジェストは32 ASCII印刷可能文字として表現されます。次のように128ビットのダイジェストのビットは、最下位ビットへの重要なほとんどの時間で4ビットから自分のASCII表現に変換されます。各4ビットは0123456789ABCDEF文字からその馴染み16進表記で表されます。すなわち、「1」で、「0」文字で0001表される、というように「F」として1111表現に立ち上がる0000バイナリです。
The Digest authentication scheme described in this document suffers from many known limitations. It is intended as a replacement for Basic authentication and nothing more. It is a password-based system and (on the server side) suffers from all the same problems of any password system. In particular, no provision is made in this protocol for the initial secure arrangement between user and server to establish the user's password.
この文書で説明したダイジェスト認証方式は、多くの既知の制限を受けます。これは、基本認証と何よりもの代替として意図されています。これは、パスワードベースのシステムであり、（サーバ側の）任意のパスワードシステムのすべてが同じ問題に苦しんでいます。具体的には、何の規定は、ユーザーのパスワードを確立するために、ユーザとサーバ間の初期の安全な配置のために、このプロトコルでは行われません。
Users and implementors should be aware that this protocol is not as secure as Kerberos, and not as secure as any client-side private-key scheme. Nevertheless it is better than nothing, better than what is commonly used with telnet and ftp, and better than Basic authentication.
ユーザと実装者は、このプロトコルは、Kerberosほど安全ではないことを認識し、任意のクライアント側の秘密鍵方式ほど安全ではないはずです。それにもかかわらず、何もないよりはまし一般のtelnetとftpで使用されているものよりも良い、と基本認証よりも優れています。
The Digest Access Authentication scheme is conceptually similar to the Basic scheme. The formats of the modified WWW-Authenticate header line and the Authorization header line are specified below. In addition, a new header, Authentication-Info, is specified.
ダイジェストアクセス認証スキームは、基本的なスキームと概念的に類似しています。修飾されたWWW-Authenticateヘッダ行とAuthorizationヘッダ行のフォーマットは以下に指定されています。また、新たなヘッダ、認証-INFOは、指定されています。
If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code, and a WWW-Authenticate header as per the framework defined above, which for the digest scheme is utilized as follows:
サーバがアクセス保護されたオブジェクトのための要求を受信し、許容されるAuthorizationヘッダが送信されていない場合、サーバは「401不正」ステータスコードで応答し、そして上記で定義されたフレームワークの通りWWW-Authenticateヘッダ、そのため次のようにダイジェスト方式が利用されています：
challenge = "Digest" digest-challenge
挑戦=「ダイジェスト」ダイジェスト挑戦を
digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] )
ダイジェスト挑戦= 1＃（王国| [ドメイン] |ナンス| [不透明] | [古い] | [アルゴリズム] | [QOP-オプション] | [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
ドメイン= "ドメイン" "=" < "> URI（1 * SP URI）<"> URI = absoluteURIで|腹筋_経路ナンス=「ナンス」「=」ナンス値ナンス値=引用符で囲まれた文字列不透明=「不透明」「=」引用符で囲まれた文字列古い=「古い」「=」（「真」|「偽」）アルゴリズム= "アルゴリズム」 "="（ "MD5" | "MD5-のSES" |トークン） "QOP-オプション= "QOP"=" < "> 1＃QOP値<"> QOP値= "認証" | "AUTH-INT" |トークン
The meanings of the values of the directives used above are as follows:
以下のように使用ディレクティブの値の意味は以下のとおりです。
realm A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com".
彼らは、ユーザー名とパスワードを使用するかを知っているので、領域文字列がユーザーに表示されます。この文字列は、少なくとも認証を実行するホストの名前が含まれている必要があり、さらにアクセス権を持っている可能性があるユーザーの集合を示している可能性があります。例では、「registered_users@gotham.news.com」かもしれません。
domain A quoted, space-separated list of URIs, as specified in RFC XURI [7], that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL (see section 1.2 above) of the server being accessed. An absoluteURI in this list may refer to a different server than the one being accessed. The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI that has a URI in this list as a prefix (after both have been made absolute) may be assumed to be in the same protection space. If this directive is omitted or its value is empty, the client should assume that the protection space consists of all URIs on the responding server.
保護空間を定義するRFC XURI [7]で指定されたドメインAは、URIのスペースで区切られたリストを引用しました。 URIは腹筋_経路である場合、それは正規のルートURLに対する相対サーバがアクセスされた（セクション1.2上記を参照のこと）。このリスト内のabsoluteURIでは、アクセスされているものとは別のサーバを指すことができます。同じであると仮定することができる（両方が絶対行われた後）の接頭辞としてこのリストにURIを持つ任意のURI：クライアントが同じ認証情報を送信することができるためURIの組を決定するために、このリストを使用することができ保護空間。このディレクティブを省略するか、その値が空の場合、クライアントは保護空間が応答し、サーバー上のすべてのURIで構成されていることを前提とすべきです。
This directive is not meaningful in Proxy-Authenticate headers, for which the protection space is always the entire proxy; if present it should be ignored.
このディレクティブは、保護空間は、常に全体のプロキシであるためにプロキシ認証ヘッダには意味がありません。存在する場合、それは無視されるべきです。
nonce A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string, the double-quote character is not allowed.
ノンス一意に401応答がなされるたびに生成されるべきサーバが指定したデータ列。この文字列をbase64でまたは16進数のデータにすることをお勧めします。文字列は引用符で囲まれた文字列としてヘッダ行に渡されているので具体的には、二重引用符文字は許可されていません。
The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. A nonce might, for example, be constructed as the base 64 encoding of
ナンスの内容は実装に依存しています。実装の品質は良い選択に依存します。ノンスは、例えば、のベース64符号化のように構成されるかもしれません
time-stamp H(time-stamp ":" ETag ":" private-key)
タイム・スタンプH（タイムスタンプ「：」ETagを「：」秘密鍵）
where time-stamp is a server-generated time or other non-repeating value, ETag is the value of the HTTP ETag header associated with the requested entity, and private-key is data known only to the server. With a nonce of this form a server would recalculate the hash portion after receiving the client authentication header and reject the request if it did not match the nonce from that header or if the time-stamp value is not recent enough. In this way the server can limit the time of the nonce's validity. The inclusion of the ETag prevents a replay request for an updated version of the resource. (Note: including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard.)
タイムスタンプは、サーバが生成した時刻または他の非反復値である、のETagは要求されたエンティティに関連付けられたHTTP ETagヘッダの値であり、秘密鍵は、サーバに知られているデータです。この形式のナンスを持つサーバーは、クライアント認証ヘッダを受信した後、ハッシュ部分を再計算し、それがそのヘッダからナンスと一致しなかった場合やタイムスタンプ値が十分に最近でない場合は、要求を拒否します。このように、サーバは、ナンスの有効性の時間を制限することができます。 ETagの包含は、リソースの更新バージョン用の再生要求を阻止します。 （注：プロキシファームを破るただし、サーバーにもともとそれを得た同じクライアントへのナンスの再利用を制限する機能を提供するように思われるナンスで、クライアントのIPアドレス、単一の要求を含みますユーザーは、多くの場合、ファーム内の別のプロキシを通過します。また、IPスプーフィングは難しいことではありません。）
An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a time-stamp for GET requests. For more details on the issues involved see section 4. of this document.
実装は、リプレイ攻撃から保護するために、以前使用したnonceまたは以前に使用さダイジェストを受け入れない選択することがあります。または、実装は、POSTのためのワンタイムナンスやダイジェストを使用するか、または要求とGET要求のためのタイムスタンプを置くこともできます。関連する問題の詳細については、このドキュメントのセクション4を参照してください。
The nonce is opaque to the client.
ナンスは、クライアントには不透明です。
opaque A string of data, specified by the server, which should be returned by the client unchanged in the Authorization header of subsequent requests with URIs in the same protection space. It is recommended that this string be base64 or hexadecimal data.
同じ保護空間内のURIを持つ以降のリクエストのAuthorizationヘッダに変更せず、クライアントによって返されるべきであるサーバーで指定されたデータの不透明な文字列、。この文字列をbase64でまたは16進数のデータにすることをお勧めします。
stale A flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE (case-insensitive), the client may wish to simply retry the request with a new encrypted response, without reprompting the user for a new username and password. The server should only set stale to TRUE if it receives a request for which the nonce is invalid but with a valid digest for that nonce (indicating that the client knows the correct username/password). If stale is FALSE, or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid, and new values must be obtained.
ノンス値が古くなったため、クライアントからの前の要求が拒否されたことを示すフラグをSTALE。古くは（大文字と小文字を区別しない）TRUEの場合、クライアントは単に新しいユーザのユーザ名とパスワードをrepromptingせずに、新しい暗号化された応答でリクエストを再試行することを望むかもしれません。サーバーは（クライアントが正しいユーザ名/パスワードを知っていることを示す）そのナンスのために、それはnonceが無効である要求を受信した場合にTRUEに古い設定が、有効なダイジェストを持つ必要があります。古いがFALSE、またはTRUE、または古いディレクティブ以外の場合は、ユーザー名および/またはパスワードが無効であり、そして新しい値を取得する必要があり、存在しません。
algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to be "MD5". If the algorithm is not understood, the challenge should be ignored (and a different one used, if there is more than one).
ダイジェストとチェックサムを生成するために使用されるアルゴリズムのペアを示す文字列アルゴリズムこれが存在しない場合、「MD5」であると想定されます。アルゴリズムが理解されていない場合は、挑戦は無視されるべきである（と複数ある場合は、別の一つは、使用されます）。
In this document the string obtained by applying the digest algorithm to the data "data" with secret "secret" will be denoted by KD(secret, data), and the string obtained by applying the checksum algorithm to the data "data" will be denoted H(data). The notation unq(X) means the value of the quoted-string X without the surrounding quotes.
本文書内の文字列を秘密「秘密」KDで示されるであろう（秘密データ）とデータ「データ」、及び「データ」のデータにチェックサムアルゴリズムを適用して得られた文字列にダイジェストアルゴリズムを適用することによって得られるであろう示されるH（データ）。表記UNQ（X）は、周囲の引用符引用符で囲まれた文字列Xの値を意味します。
For the "MD5" and "MD5-sess" algorithms
「MD5」と「MD5-SESの」アルゴリズムの
H(data) = MD5(data)
H（データ）= MD5（データ）
and
そして
KD(secret, data) = H(concat(secret, ":", data))
KD（秘密、データ）= H（CONCAT（秘密、 "："、データ））
i.e., the digest is the MD5 of the secret concatenated with a colon concatenated with the data. The "MD5-sess" algorithm is intended to allow efficient 3rd party authentication servers; for the difference in usage, see the description in section 3.2.2.2.
すなわち、ダイジェストは、データと連結コロンで連結秘密のMD5です。 「MD5-SESの」アルゴリズムは、効率的なサードパーティの認証サーバーを可能にすることを意図しています。用法の違いのために、セクション3.2.2.2で説明を参照してください。
qop-options This directive is optional, but is made so only for backward compatibility with RFC 2069 [6]; it SHOULD be used by all implementations compliant with this version of the Digest scheme. If present, it is a quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection; see the descriptions below for calculating the response directive value for the application of this choice. Unrecognized options MUST be ignored.
QOP-オプションこのディレクティブは任意であるが、RFC 2069との下位互換性のためにこれだけ行われる[6]。それはダイジェストスキームのこのバージョンに準拠したすべての実装で使用されるべきです。存在する場合は、サーバーでサポートされている値「保護の品質」を示す1つの以上のトークンの引用符で囲まれた文字列です。値「AUTHは、」認証を示します。値「のauth-intが」完全性保護と認証を示します。この選択のアプリケーションの応答指令値を算出するため、以下の説明を参照してください。認識できないオプションは無視しなければなりません。
auth-param This directive allows for future extensions. Any unrecognized directive MUST be ignored.
auth-PARAMこのディレクティブは、将来の拡張が可能になります。認識されないディレクティブは無視しなければなりません。
The client is expected to retry the request, passing an Authorization header line, which is defined according to the framework above, utilized as follows.
クライアントは、次のように利用する上記フレームワークに従って定義される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 ; As specified by HTTP/1.1 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"
ユーザ名= "ユーザ名" "=" ユーザ名値名値=引用符で囲まれた文字列のダイジェスト-URI = "URI" "=" ダイジェスト-uriの値ダイジェスト-uriの値=のRequest-URI; HTTP / 1.1メッセージQOP = "QOP" "=" QOP値cnonce = "cnonce" "=" cnonce値cnonce値=ノンス値ナンスカウント= "NC" "=" NC-値によって指定されるようにNC-値= 8LHEX応答= "レスポンス" "=" 要求 - ダイジェスト要求ダイジェスト= < "> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | 「」| "B" | "C" | "D" | "E" | "F"
The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header for the entity being requested.
不透明なアルゴリズムフィールドの値は、要求されたエンティティのWWW認証応答ヘッダで供給されるものでなければなりません。
response A string of 32 hex digits computed as defined below, which proves that the user knows a password
ユーザがパスワードを知っていることを証明以下に定義されるように計算された32進数の文字列を、対応
username The user's name in the specified realm.
指定されたレルムにユーザーの名前をユーザ名。
digest-uri The URI from Request-URI of the Request-Line; duplicated here because proxies are allowed to change the Request-Line in transit.
ダイジェスト-URIリクエストラインの要求URIからのURI。プロキシが輸送中のリクエストラインを変更することが許可されているので、ここでは重複。
qop Indicates what "quality of protection" the client has applied to the message. If present, its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header. These values affect the computation of the request-digest. Note that this is a single token, not a quoted list of alternatives as in WWW- Authenticate. This directive is optional in order to preserve backward compatibility with a minimal implementation of RFC 2069 [6], but SHOULD be used if the server indicated that qop is supported by providing a qop directive in the WWW-Authenticate header field.
QOPは、クライアントがメッセージに適用されたものを「保護の品質」を示します。存在する場合、その値は、サーバがWWW-Authenticateヘッダにサポートしてい示された選択肢のうちの1つでなければなりません。これらの値は、要求 - ダイジェストの計算に影響を与えます。これは単一のトークンではなく、WWW-認証のように、代替の引用されたリストであることに注意してください。この指令は、[6] RFC 2069の最小限の実装との下位互換性を維持するために任意であるが、サーバはQOPがWWW-AuthenticateヘッダフィールドにQOP指示を提供することによってサポートされていることが示された場合に使用されるべきです。
cnonce This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. The cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, to provide mutual authentication, and to provide some message integrity protection. See the descriptions below of the calculation of the response-digest and request-digest values.
cnonceこれはQOPディレクティブが送信された場合（上記参照）を指定する必要があり、かつサーバがWWW-AuthenticateヘッダフィールドにQOPディレクティブを送信しなかった場合は指定してはいけません。 cnonce値は、クライアントによって提供され、相互認証を提供する、といくつかのメッセージの完全性保護を提供するために、選択平文攻撃を避けるために、クライアントとサーバーの両方で使用される不透明な引用符で囲まれた文字列値です。応答ダイジェスト要求ダイジェスト値の算出の以下の説明を参照。
nonce-count This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay. See the description below of the construction of the request-digest value.
qopの指示が送信される場合、これは指定されなければならないnonceがカウント（上記参照）、およびサーバがWWW-Authenticateヘッダフィールド内のQOPディレクティブを送信しなかった場合は指定してはいけません。 NC-値は、クライアントがこの要求にナンス値を送信したことを（現在の要求を含む）のリクエスト数を16進数です。例えば、所与のノンス値に応じて送信された最初の要求では、クライアントは「NC = 00000001」を送信します。同じNC-値が二度見された場合、その要求はリプレイである - このディレクティブの目的は、サーバーがこのカウントの独自のコピーを維持することによって、要求のリプレイを検出することができるようにすることです。要求 - ダイジェスト値の建設の以下の説明を参照してください。
auth-param This directive allows for future extensions. Any unrecognized directive MUST be ignored.
auth-PARAMこのディレクティブは、将来の拡張が可能になります。認識されないディレクティブは無視しなければなりません。
If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request. If the request-digest is invalid, then a login failure should be logged, since repeated login failures from a single client may indicate an attacker attempting to guess passwords.
ディレクティブまたはその値が不適切である、または必要なディレクティブが含まれていない場合、適切な応答が400不正な要求です。要求 - ダイジェストが無効である場合、単一のクライアントからの繰り返しのログイン失敗がパスワードを推測しようとする攻撃を示す可能性があるため、ログインの失敗は、ログに記録されなければなりません。
The definition of request-digest above indicates the encoding for its value. The following definitions show how the value is computed.
上記ダイジェスト要求の定義は、その値が符号化を示しています。以下の定義は、値が計算される方法を示しています。
If the "qop" value is "auth" or "auth-int":
"QOP" の値は、 "認証" または "のauth-int型" の場合：
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <">
要求ダイジェスト= < "> <KD（H（A1）、UNQ（ノンス値） "：" NC-値 "：" UNQ（cnonce値） "：" UNQ（QOP値） "：" H（ A2））< ">
If the "qop" directive is not present (this construction is for compatibility with RFC 2069):
「QOP」ディレクティブが存在しない場合（この構造は、RFC 2069との互換性のためです）：
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
要求ダイジェスト= < "> <KD（H（A1）、UNQ（ノンス値） "：" H（A2））> <">
See below for the definitions for A1 and A2.
A1とA2の定義については、以下を参照してください。
If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is:
「アルゴリズム」ディレクティブの値が「MD5」であるか、指定されていない場合には、A1は次のようになります。
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
A1 = UNQ（ユーザ名-値） "：" UNQ（レルム値） "：" passwdの
where
どこ
passwd = < user's password >
passwdファイル= <ユーザのパスワード>
If the "algorithm" directive's value is "MD5-sess", then A1 is calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from that challenge, and the first client nonce value to construct A1 as follows:
「アルゴリズム」ディレクティブの値は「MD5-のSES」であれば、A1は一度だけ計算されます - サーバからWWW認証チャレンジを受けた後、クライアントによる最初の要求に。それは次のようにA1を構築するためにその挑戦からサーバーナンス、および最初のクライアントのnonce値を使用しています。
A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":" unq(nonce-value) ":" unq(cnonce-value)
A1 = H（UNQ（ユーザ名値） "：" UNQ（レルム値） "：" passwdの） "：" UNQ（ノンス値） "：" UNQ（cnonce値）
This creates a 'session key' for the authentication of subsequent requests and responses which is different for each "authentication session", thus limiting the amount of material hashed with any one key. (Note: see further discussion of the authentication session in
これは、このようにいずれかのキーを使用してハッシュ材料の量を制限し、それぞれの「認証セッション」で異なり、後続の要求と応答の認証のための「セッションキー」を作成します。 （注：で認証セッションの更なる議論を参照してください
section 3.3.) Because the server need only use the hash of the user credentials in order to create the A1 value, this construction could be used in conjunction with a third party authentication service so that the web server would not need the actual password value. The specification of such a protocol is beyond the scope of this specification.
セクション3.3。）サーバーが唯一のA1の値を作成するために、ユーザーの資格情報のハッシュを使用する必要があるため、Webサーバーは、実際のパスワード値を必要としないように、この構造は、サードパーティの認証サービスと組み合わせて使用することができます。そのようなプロトコルの仕様は、本明細書の範囲外です。
If the "qop" directive's value is "auth" or is unspecified, then A2 is:
「QOP」ディレクティブの値が「認証」であるか、指定されていない場合は、A2は次のようになります。
A2 = Method ":" digest-uri-value
A2 =メソッド "：" ダイジェスト-URI値
If the "qop" value is "auth-int", then A2 is:
「QOP」の値が「のauth-int型」の場合は、A2は次のようになります。
A2 = Method ":" digest-uri-value ":" H(entity-body)
A2 =法 "：" ダイジェスト-URI値を "：" H（エンティティ本体）
Note that the value of many of the directives, such as "username-value", are defined as a "quoted-string". However, the "unq" notation indicates that surrounding quotation marks are removed in forming the string A1. Thus if the Authorization header includes the fields
例えば、「ユーザ名値」、などのディレクティブの多くの値が「引用符で囲まれた文字列」として定義されていることに注意してください。しかし、「UNQ」表記は、周囲の引用符は、文字列A1を形成する際に除去されることを示しています。したがってAuthorizationヘッダフィールドを含む場合
username="Mufasa", realm=myhost@testrealm.com
ユーザ名= "ムファサ"、realm=myhost@testrealm.com
and the user Mufasa has password "Circle Of Life" then H(A1) would be H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks in the digested string.
消化された文字列の引用符なしで、ユーザーはムファサにパスワードが設定されている「生命のサークル」その後、H（A1）は、H（ライフサークル：myhost@testrealm.comムファサ）になります。
No white space is allowed in any of the strings to which the digest function H() is applied unless that white space exists in the quoted strings or entity body whose contents make up the string to be digested. For example, the string A1 illustrated above must be
いいえホワイトスペースは、そのホワイトスペースは、そのコンテンツの文字列を構成して消化される引用符で囲まれた文字列またはエンティティボディ内に存在しない限り、そのダイジェスト関数H（）が適用される文字列のいずれかで許可されていません。例えば、A1は、上に示した文字列でなければなりません
Mufasa:myhost@testrealm.com:Circle Of Life
ムファサ：myhost@testrealm.com：生命のサークル
with no white space on either side of the colons, but with the white space between the words used in the password value. Likewise, the other strings digested by H() must not have white space on either side of the colons which delimit their fields unless that white space was in the quoted strings or entity body being digested.
コロンのいずれかの側で空白ではなく、パスワード値で使われる単語間の空白を持ちます。同様に、H（）によって消化された他の文字列は、その空白を引用符で囲まれた文字列またはエンティティボディに消化されていた場合を除き、そのフィールドを区切るコロンの両側に空白があってはなりません。
Also note that if integrity protection is applied (qop=auth-int), the H(entity-body) is the hash of the entity body, not the message body - it is computed before any transfer encoding is applied by the sender and after it has been removed by the recipient. Note that this includes multipart boundaries and embedded headers in each part of any multipart content-type.
また、注意して完全性保護が適用された場合（QOP = AUTH-INT）、H（エンティティボディ）は、エンティティ本体はなく、メッセージ本体のハッシュは - 任意の転送符号化が送信者と後に適用される前に、それが計算されそれは、受信者によって削除されました。これは、マルチパート境界および任意のマルチコンテンツ・タイプの各部分に埋め込まれたヘッダを含むことに留意されたいです。
The "Method" value is the HTTP request method as specified in section 5.1.1 of [2]. The "request-uri" value is the Request-URI from the request line as specified in section 5.1.2 of [2]. This may be "*", an "absoluteURL" or an "abs_path" as specified in section 5.1.2 of [2], but it MUST agree with the Request-URI. In particular, it MUST be an "absoluteURL" if the Request-URI is an "absoluteURL". The "cnonce-value" is an optional client-chosen value whose purpose is to foil chosen plaintext attacks.
「メソッド」値は、[2]のセクション5.1.1で指定されたHTTPリクエストメソッドです。 「リクエストURI」の値は、[2]のセクション5.1.2で指定されるように要求ラインからのRequest-URIです。これは、「*」[2]のセクション5.1.2で指定され、それがRequest-URIと一致しなければならないので、「absoluteURL」または「腹筋_経路」であってもよいです。特に、「absoluteURL」のRequest-URIが「absoluteURL」でなければなりません。 「cnonce値」とは、その目的は選択平文攻撃を箔にあるオプションのクライアントが選択した値です。
The authenticating server must assure that the resource designated by the "uri" directive is the same as the resource specified in the Request-Line; if they are not, the server SHOULD return a 400 Bad Request error. (Since this may be a symptom of an attack, server implementers may want to consider logging such errors.) The purpose of duplicating information from the request URL in this field is to deal with the possibility that an intermediate proxy may alter the client's Request-Line. This altered (but presumably semantically equivalent) request would not result in the same digest as that calculated by the client.
認証サーバは、「URI」ディレクティブで指定されたリソースが、リクエストラインで指定されたリソースと同じであることを保証しなければなりません。そうでない場合、サーバは400不正な要求エラーを返すべきです。 （これは攻撃の兆候かもしれないので、サーバーの実装者は、このようなエラーを記録することを検討してください。）このフィールドには、リクエストURLから情報を複製する目的は、中間プロキシが、クライアントの要求 - を変更することができるという可能性に対処するためでありますライン。この改変された（しかしおそらく意味的に等価な）要求が同じクライアントによって計算されるようなダイジェストをもたらさないであろう。
Implementers should be aware of how authenticated transactions interact with shared caches. The HTTP/1.1 protocol specifies that when a shared cache (see section 13.7 of [2]) has received a request containing an Authorization header and a response from relaying that request, it MUST NOT return that response as a reply to any other request, unless one of two Cache-Control (see section 14.9 of [2]) directives was present in the response. If the original response included the "must-revalidate" Cache-Control directive, the cache MAY use the entity of that response in replying to a subsequent request, but MUST first revalidate it with the origin server, using the request headers from the new request to allow the origin server to authenticate the new request. Alternatively, if the original response included the "public" Cache-Control directive, the response entity MAY be returned in reply to any subsequent request.
実装者は、認証されたトランザクションが共有キャッシュとの対話方法を知っておく必要があります。 HTTP / 1.1プロトコルは、共有キャッシュは、Authorizationヘッダとその要求を中継からの応答を含む要求を受信した（[2]のセクション13.7を参照）場合、それは他の要求に対する応答として、その応答を返してはならないことを指定します2つのキャッシュ・コントロールのない限り指示（[2]のセクション14.9を参照）応答中に存在しました。元の応答が「-再検証しなければならない」のCache-Controlディレクティブが含まれている場合、キャッシュは、後続の要求に応答してそのレスポンスのエンティティを使用することができるが、最初に新しいリクエストからリクエストヘッダを使用して、オリジンサーバでそれを再検証しなければなりませんオリジンサーバが新しい要求を認証できるようにします。元の応答が「公共」のCache-Controlディレクティブが含まれている場合あるいは、応答エンティティは、任意の後続の要求への応答で返されることがあります。
The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response.
認証-Infoヘッダは、応答に成功した認証に関するいくつかの情報を通信するためにサーバによって使用されます。
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 <">
The value of the nextnonce directive is the nonce the server wishes the client to use for a future authentication response. The server may send the Authentication-Info header with a nextnonce field as a means of implementing one-time or otherwise changing nonces. If the nextnonce field is present the client SHOULD use it when constructing the Authorization header for its next request. Failure of the client to do so may result in a request to re-authenticate from the server with the "stale=TRUE".
nextnonceディレクティブの値は、サーバは、クライアントが将来の認証応答のために使用したいナンスです。サーバは、ワンタイムを実現するか、そうでなければ一回だけを変化させる手段としてnextnonceフィールドと認証-Infoヘッダを送信することができます。 nextnonceフィールドが存在する場合はその次の要求のためにAuthorizationヘッダを構築する場合、クライアントはそれを使用する必要があります。そうしないと、クライアントの失敗は、「古くなった= TRUE」でサーバから再認証するように要求することがあります。
Server implementations should carefully consider the performance implications of the use of this mechanism; pipelined requests will not be possible if every response includes a nextnonce directive that must be used on the next request received by the server. Consideration should be given to the performance vs. security tradeoffs of allowing an old nonce value to be used for a limited time to permit request pipelining. Use of the nonce-count can retain most of the security advantages of a new server nonce without the deleterious affects on pipelining.
サーバ実装は慎重にこのメカニズムの使用のパフォーマンスへの影響を考慮する必要があります。すべての応答は、サーバが受信した次のリクエストで使用する必要がありnextnonceディレクティブが含まれている場合、パイプラインの要求はできません。対価は、要求パイプライン化を可能にするために、限られた時間のために使用される古いナンス値を可能にするセキュリティトレードオフのパフォーマンスに与えられるべきです。ナンスカウントの使用は有害せずに新しいサーバナンスのセキュリティ上の利点のほとんどを維持することができ、パイプラインに影響します。
message-qop Indicates the "quality of protection" options applied to the response by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection. The server SHOULD use the same value for the message-qop directive in the response as was sent by the client in the corresponding request.
メッセージQOPは、サーバーの応答に適用される「保護の品質」のオプションを示します。値「AUTHは、」認証を示します。値「のauth-intが」完全性保護と認証を示します。対応する要求にクライアントによって送信されたように、サーバは、応答メッセージQOPディレクティブに同じ値を使用すべきです。
The optional response digest in the "response-auth" directive supports mutual authentication -- the server proves that it knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response. The "response-digest" value is calculated as for the "request-digest" in the Authorization header, except that if "qop=auth" or is not specified in the Authorization header for the request, A2 is
オプションの応答が「応答-AUTH」でダイジェストディレクティブは、相互認証をサポートしています - サーバーは、ユーザーの秘密を知っていることを証明し、QOPと=のauth-intが、応答の限定された完全性保護を提供します。値が「QOP = AUTH」または要求のAuthorizationヘッダに指定されていない場合、A2であることを除いて、Authorizationヘッダの「要求ダイジェスト」のように計算され、「応答は、ダイジェスト」
A2 = ":" digest-uri-value
A2 = "：" ダイジェスト-URI値
and if "qop=auth-int", then A2 is
"QOP =のauth-int型" 場合と、その後、A2は、
A2 = ":" digest-uri-value ":" H(entity-body)
A2 = "：" ダイジェスト-URI値を "：" H（エンティティ本体）
where "digest-uri-value" is the value of the "uri" directive on the Authorization header in the request. The "cnonce-value" and "nc-value" MUST be the ones for the client request to which this message is the response. The "response-auth", "cnonce", and "nonce-count" directives MUST BE present if "qop=auth" or "qop=auth-int" is specified.
ここで、「ダイジェストURI値」リクエストにAuthorizationヘッダの「URI」指令の値です。 「cnonce値」と「NC-値が」このメッセージが応答であるにクライアント要求のためのものでなければなりません。 "QOP = AUTH" または "QOP =のauth-intは、" 指定されている場合は、 "応答-AUTH"、 "cnonce"、および "ナンスカウント" ディレクティブが存在しなければなりません。
The Authentication-Info header is allowed in the trailer of an HTTP message transferred via chunked transfer-coding.
認証-Infoヘッダは、チャンク転送符号化を介して転送されるHTTPメッセージのトレーラーで許可されています。
Upon receiving the Authorization header, the server may check its validity by looking up the password that corresponds to the submitted username. Then, the server must perform the same digest operation (e.g., MD5) performed by the client, and compare the result to the given request-digest value.
Authorizationヘッダーを受信すると、サーバは、送信されたユーザ名に対応するパスワードを調べることによって、その有効性を確認することがあります。次いで、サーバは、クライアントによって実行される同じダイジェスト動作（例えば、MD5）を実行し、与えられた要求ダイジェスト値と結果を比較しなければなりません。
Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified.
HTTPサーバは、実際のユーザーの平文パスワードを知っている必要はないことに注意してください。限り、H（A1）がサーバに利用可能であるように、Authorizationヘッダの正当性を検証することができます。
The client response to a WWW-Authenticate challenge for a protection space starts an authentication session with that protection space. The authentication session lasts until the client receives another WWW-Authenticate challenge from any server in the protection space. A client should remember the username, password, nonce, nonce count and opaque values associated with an authentication session to use to construct the Authorization header in future requests within that protection space. The Authorization header may be included preemptively; doing so improves server efficiency and avoids extra round trips for authentication challenges. The server may choose to accept the old Authorization header information, even though the nonce value included might not be fresh. Alternatively, the server may return a 401 response with a new nonce value, causing the client to retry the request; by specifying stale=TRUE with this response, the server tells the client to retry with the new nonce, but without prompting for a new username and password.
保護空間のためのWWW認証チャレンジに対するクライアントの応答は、その保護空間との認証セッションを開始します。クライアントは、保護空間内の任意のサーバーから別のWWW認証チャレンジを受信するまで認証セッションが続きます。クライアントは、その保護空間内の将来の要求にAuthorizationヘッダーを構築するために使用する認証セッションに関連付けられているユーザ名、パスワード、ナンス、ナンス数と不透明な値を覚えておく必要があります。 Authorizationヘッダは、先制含まれていてもよいです。そうすることは、サーバーの効率を向上させ、認証チャレンジのための余分なラウンドトリップを回避します。サーバが含まナンス値が新鮮ではないかもしれないにもかかわらず、古いAuthorizationヘッダー情報を受け入れることを選択することもできます。代替的に、サーバは、クライアントが要求を再試行させる、新しいノンス値と401応答を返すことができます。この応答でTRUE =古い指定することで、サーバは、新しいユーザ名とパスワードの入力を求めることなく、新しいナンスを再試行するようにクライアントに指示します。
Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may be used to transport authentication session state information. (Note that any such use can also be accomplished more easily and safely by including the state in the nonce.) For example, a server could be responsible for authenticating content that actually sits on another server. It would achieve this by having the first 401 response include a domain directive whose value includes a URI on the second server, and an opaque directive whose value contains the state information. The client will retry the request, at which time the server might respond with a 301/302 redirection, pointing to the URI on the second server. The client will follow the redirection, and pass an Authorization header , including the <opaque> data.
クライアントは、セッションの間、サーバによってそれに与えられた不透明なディレクティブの値を返すために必要とされるため、不透明なデータは、認証セッション状態情報を転送するために使用することができます。 （そのような使用もナンス状態を含めることにより、より容易かつ安全に行うことができることに留意されたい。）例えば、サーバは、実際には別のサーバ上に座ったコンテンツを認証する責任を負うかもしれません。これは、値第二のサーバ、及びその値の状態情報を含んでいる不透明なディレクティブにURIを含むドメインディレクティブを含む最初の401応答を有することによって、これを達成するであろう。クライアントは、サーバが第二のサーバ上のURIを指し、301/302リダイレクトで応答可能性がある時点で、要求を再試行します。クライアントは、リダイレクトに従い、<不透明>データを含む、Authorizationヘッダを通過します。
As with the basic scheme, proxies must be completely transparent in the Digest access authentication scheme. That is, they must forward the WWW-Authenticate, Authentication-Info and Authorization headers untouched. If a proxy wants to authenticate a client before a request is forwarded to the server, it can be done using the Proxy-Authenticate and Proxy-Authorization headers described in section 3.6 below.
基本的なスキームと同じように、プロキシはダイジェストアクセス認証スキームでは完全に透明でなければなりません。つまり、彼らはそのままWWW認証、認証、情報および認証ヘッダを転送する必要があります。プロキシは、要求をサーバに転送される前にクライアントを認証したい場合は、以下のセクション3.6で説明したプロキシ認証およびプロキシ認証ヘッダを使用して行うことができます。
It is useful for a server to be able to know which security schemes a client is capable of handling.
サーバは、クライアントが処理可能であるセキュリティ方式を知ることができることは便利です。
It is possible that a server may want to require Digest as its authentication method, even if the server does not know that the client supports it. A client is encouraged to fail gracefully if the server specifies only authentication schemes it cannot handle.
サーバーは、サーバーは、クライアントがそれをサポートしていることを知らなくても、その認証方法としてダイジェストを要求したいことが可能です。クライアントは、サーバが処理できない唯一の認証スキームを指定する場合は正常に失敗することが奨励されます。
The following example assumes that an access-protected document is being requested from the server via a GET request. The URI of the document is "http://www.nowhere.org/dir/index.html". Both client and server know that the username for this document is "Mufasa", and the password is "Circle Of Life" (with one space between each of the three words).
次の例では、アクセス保護された文書はGETリクエストを介してサーバから要求されていることを前提としています。文書のURIは「http://www.nowhere.org/dir/index.html」です。クライアントとサーバの両方が、この文書のユーザー名は「ムファサ」で、パスワードは（三つの言葉のそれぞれの間に1つのスペースで）「生命のサークル」であることを知っています。
The first time the client requests the document, no Authorization header is sent, so the server responds with:
クライアントがドキュメントを要求初めて、何のAuthorizationヘッダは送信されませんので、サーバがで応答します。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
The client may prompt the user for the username and password, after which it will respond with a new request, including the following Authorization header:
クライアントは、以下のAuthorizationヘッダを含む、新しい要求に応答する後、ユーザー名とパスワードをユーザに促すことができます。
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
The digest authentication scheme may also be used for authenticating users to proxies, proxies to proxies, or proxies to origin servers by use of the Proxy-Authenticate and Proxy-Authorization headers. These headers are instances of the Proxy-Authenticate and Proxy-Authorization headers specified in sections 10.33 and 10.34 of the HTTP/1.1 specification [2] and their behavior is subject to restrictions described there. The transactions for proxy authentication are very similar to those already described. Upon receiving a request which requires authentication, the proxy/server must issue the "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header. The digest-challenge used in the Proxy-Authenticate header is the same as that for the WWW-Authenticate header as defined above in section 3.2.1.
ダイジェスト認証方式は、プロキシ認証およびプロキシ認証ヘッダの使用によってオリジンサーバにプロキシ、プロキシにプロキシ、またはプロキシにユーザーを認証するために使用することができます。これらのヘッダーは、セクション10.33およびHTTP / 1.1仕様書[2]の10.34で指定されたプロキシ認証およびプロキシ認証ヘッダのインスタンスであり、その動作は、そこに記載の制限を受けます。プロキシ認証のための取引は、すでに説明したものと非常によく似ています。認証を必要とする要求を受信すると、プロキシ/サーバは、「プロキシ認証」ヘッダーと「407プロキシ認証が必要」の応答を発行しなければなりません。プロキシ認証ヘッダで使用されるダイジェストチャレンジは、セクション3.2.1において上で定義したとおりWWW-Authenticateヘッダのためのものと同じです。
The client/proxy must then re-issue the request with a Proxy-Authorization header, with directives as specified for the Authorization header in section 3.2.2 above.
上記セクション3.2.2でAuthorizationヘッダに指定されたクライアント/プロキシは次いでディレクティブと、プロキシ認証ヘッダを有する要求を再発行しなければなりません。
On subsequent responses, the server sends Proxy-Authentication-Info with directives the same as those for the Authentication-Info header field.
その後の応答に、サーバは認証-Infoヘッダフィールドと同じディレクティブとプロキシ認証、情報を送信します。
Note that in principle a client could be asked to authenticate itself to both a proxy and an end-server, but never in the same response.
原則的に、クライアントは決して同じ応答では、プロキシとエンドサーバーの両方に自分自身を認証するように要求することができることに注意してください。
4 Security Considerations
4つのセキュリティの考慮事項
The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security or the addition of enhancements (such as schemes to use one-time passwords) to Basic authentication.
基本認証方式は、ユーザ認証の安全な方法ではない、またそれはどのような方法で担体として使用される物理的なネットワークを介して平文で送信されるエンティティを保護ありません。 HTTPは、セキュリティまたは基本認証に（例えばワンタイムパスワードを使用するためのスキームなど）の拡張機能の追加を増加させるために使用されることから、追加の認証方式と暗号化メカニズムを防ぐことはできません。
The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.
基本認証で最も重大な欠陥は、それが物理的なネットワーク上でユーザのパスワードの基本的クリアテキストの送信につながるということです。これは、ダイジェスト認証が対処しようとするこの問題です。
Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements) to protect sensitive or valuable information.
基本認証は、パスワードの平文送信を含むので、機密情報や貴重な情報を保護するために（拡張機能なし）で使用されるべきではありません。
A common use of Basic authentication is for identification purposes -- requiring the user to provide a user name and password as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major concern. This is only correct if the server issues both user name and password to the users and in particular does not allow the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid the task of maintaining multiple passwords.
基本認証の一般的な用途は、識別目的のためのものである - 識別の手段として、例えば、サーバ上の正確な使用状況の統計を収集する目的のためにユーザ名とパスワードを提供するようにユーザに要求します。このように使用する場合には、保護されたドキュメントへの不正アクセスが主要な関心事でない場合は、その使用中に危険がないことを考えがちです。ユーザーに、特にサーバーの問題のユーザー名とパスワードの両方が、ユーザが自分のパスワードを選択することはできません場合、これが唯一の正しいです。ナイーブユーザーが頻繁に複数のパスワードを維持するための作業を避けるために、単一のパスワードを再利用するため、危険が生じます。
If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the server but also unauthorized access to any other resources on other systems that the user protects with the same password. Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all those sites if this information is not maintained in a secure fashion.
サーバが自分のパスワードを選択することをユーザーに許可する場合は、脅威は、サーバー上のドキュメントへの不正アクセスだけでなく、ユーザーが同じパスワードで保護され、他のシステム上の他のリソースへの不正アクセスだけではありません。さらに、サーバーのパスワードデータベースに、パスワードの多くは、他のサイトのユーザーのパスワードかもしれません。この情報は安全な方法で維持されていない場合は、このようなシステムの所有者や管理者は、したがって、すべてのこれらのサイトへの不正アクセスのリスクにシステムのすべてのユーザーに公開することができます。
Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with Digest Authentication. Server implementers SHOULD guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable by the client.
基本認証も偽造サーバによってスプーフィングに対して脆弱です。ユーザーが実際には、彼は敵対的なサーバやゲートウェイに接続されたとき、彼は基本認証で保護された情報を含むホストに接続されていることを信じるように導くことができるならば、攻撃者は、後で使用するためにそれを保存し、パスワードを要求することができますそして、エラーを装います。このタイプの攻撃はダイジェスト認証では不可能です。サーバーの実装者はゲートウェイやCGIスクリプトによって偽造のこの種の可能性を防ぐべきです。サーバは単にゲートウェイへの接続を介してオンにするために特にそれは非常に危険です。クライアントによって検出されないように、元のサーバを偽装しながら、そのゲートウェイは、クライアントと複数のトランザクションに従事する永続的な接続機構を使用することができます。
Digest Authentication does not provide a strong authentication mechanism, when compared to public key based mechanisms, for example.
公開鍵ベースの機構と比較した場合、ダイジェスト認証は、例えば、強力な認証メカニズムを提供しません。
However, it is significantly stronger than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and even more dangerous Basic mechanism.
しかし、それは（例えば）CRAM-MD5 LDAPで使用するために提案されている、[10]、POPおよびIMAPよりも有意に強力である（[9] RFC 2195を参照）。はるかに弱いとさらに危険の基本的なメカニズムを置き換えることを意図しています。
Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the request and response are available to an eavesdropper.
ダイジェスト認証は、実際のパスワードを保護する以上の機密保護を提供しています。リクエストとレスポンスの残りのすべては、盗聴者にご利用いただけます。
Digest Authentication offers only limited integrity protection for the messages in either direction. If qop=auth-int mechanism is used, those parts of the message used in the calculation of the WWW-Authenticate and Authorization header field response directive values (see section 3.2 above) are protected. Most header fields and their values could be modified as a part of a man-in-the-middle attack.
ダイジェスト認証は、どちらの方向にもメッセージにのみ限定された完全性保護を提供しています。 QOP = AUTH-INTのメカニズムが使用される場合、WWW認証及び認可ヘッダーフィールド応答指令値（上記のセクション3.2を参照）の計算に使用されるメッセージの部分が保護されます。ほとんどのヘッダフィールドとその値は、man-in-the-middle攻撃の一環として変更することができます。
Many needs for secure HTTP transactions cannot be met by Digest Authentication. For those needs TLS or SHTTP are more appropriate protocols. In particular Digest authentication cannot be used for any transaction requiring confidentiality protection. Nevertheless many functions remain for which Digest authentication is both useful and appropriate. Any service in present use that uses Basic should be switched to Digest as soon as practical.
セキュアなHTTPトランザクションのための多くのニーズがダイジェスト認証によって満たすことができません。それらのニーズのためにTLSまたはSHTTPがより適切なプロトコルです。特に、ダイジェスト認証は、機密性の保護を必要とするすべてのトランザクションのために使用することはできません。それにも関わらず多くの機能は、ダイジェスト認証が有用かつ適切な両方であるために残ります。 Basicを使用して現在使用中のサービスは、すぐに実用として消化するために切り替える必要があります。
The Digest scheme uses a server-specified nonce to seed the generation of the request-digest value (as specified in section 3.2.2.1 above). As shown in the example nonce in section 3.2.1, the server is free to construct the nonce such that it may only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks (see 4.5). However, it should be noted that the method chosen for generating and checking the nonce also has performance and resource implications. For example, a server may choose to allow each nonce value to be used only once by maintaining a record of whether or not each recently issued nonce has been returned and sending a next-nonce directive in the Authentication-Info header field of every response. This protects against even an immediate replay attack, but has a high cost checking nonce values, and perhaps more important will cause authentication failures for any pipelined requests (presumably returning a stale nonce indication). Similarly, incorporating a request-specific element such as the Etag value for a resource limits the use of the nonce to that version of the resource and also defeats pipelining. Thus it may be useful to do so for methods with side effects but have unacceptable performance for those that do not.
ダイジェストスキームは、（上記セクション3.2.2.1で指定されるように）要求ダイジェスト値の生成をシードするサーバが指定nonceを使用します。セクション3.2.1例示的ナンスに示すように、サーバは、それが唯一の用途の時間または数の限られた期間のために、特定のリソースのために、特定のクライアントから使用することができるように、nonceを構築するために自由であるか、または任意の他の制限。そうすることで、たとえば、に対して提供された保護、リプレイ攻撃を（4.5を参照）を強化しています。しかし、nonceを生成し、チェックするために選ばれた方法は、パフォーマンスとリソースの意味を持っていることに留意すべきです。例えば、サーバは、各ナンス値はそれぞれ最近発行されたnonceが返ってきたかどうかの記録を維持し、すべての応答の認証-Infoヘッダーフィールドに次ナンスディレクティブを送信することにより、一度だけ使用できるようにすることもできます。これはさえ即時リプレイ攻撃から保護するが、ナンス値をチェックし、高いコストを持って、そしておそらくもっと重要なのは（おそらく古いナンス表示を返す）任意のパイプライン化された要求の認証が失敗する原因になります。同様に、そのようなリソースのETag値として要求固有の要素を組み込むことは、リソースのそのバージョンに一回だけの使用を制限し、またパイプラインを破ります。したがって、副作用を持つメソッドのためにそうすることが有用であるが、そうでないもののために許容できないパフォーマンスを有することができます。
Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum. But a comparison between the two points out the utility, even necessity, of replacing Basic by Digest.
ダイジェストおよび基本認証の両方がセキュリティ強度スペクトルの弱い端に非常に多くあります。しかし、ダイジェストで基本を置き換えるの有用性も必要性、うち2点間の比較。
The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a database whose use is restricted to paying subscribers. With Basic authentication an eavesdropper can obtain the password of the user. This not only permits him to access anything in the database, but, often worse, will permit access to anything else the user protects with the same password.
これらのプロトコルが使用されるトランザクションの種類への最大の脅威は、ネットワークスヌーピングです。トランザクションのこの種は、例えば、使用契約者を支払うに制限されているデータベースへのオンラインアクセスを必要とするかもしれません。基本認証では、盗聴者は、ユーザーのパスワードを取得することができます。これは、多くの場合、悪化したデータベースで何かをアクセスするために彼を許可するだけでなく、ユーザーが同じパスワードで保護何かへのアクセスを許可します。
By contrast, with Digest Authentication the eavesdropper only gets access to the transaction in question and not to the user's password. The information gained by the eavesdropper would permit a replay attack, but only with a request for the same document, and even that may be limited by the server's choice of nonce.
これとは対照的に、ダイジェスト認証と盗聴者が唯一の問題ではなく、ユーザーのパスワードへのトランザクションへのアクセス権を取得します。盗聴者によって得られた情報は、ナンスのサーバの選択によって制限されることがあっても、リプレイ攻撃を可能にするが、唯一の同じ文書の要求に、となります。
A replay attack against Digest authentication would usually be pointless for a simple GET request since an eavesdropper would already have seen the only document he could obtain with a replay. This is because the URI of the requested document is digested in the client request and the server will only deliver that document. By contrast under Basic Authentication once the eavesdropper has the user's password, any document protected by that password is open to him.
ダイジェスト認証に対するリプレイ攻撃は通常、盗聴者は、すでに彼はリプレイで得ることができる唯一の文書を見ているであろうから、単純なGETリクエストのために無意味だろう。要求されたドキュメントのURIがクライアント要求に消化され、サーバが唯一のそのドキュメントをお届けするためです。盗聴者がユーザーのパスワードを持っていたら、基本認証の下でこれとは対照的に、そのパスワードで保護された文書は彼に開かれています。
Thus, for some purposes, it is necessary to protect against replay attacks. A good Digest implementation can do this in various ways. The server created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a time-stamp, the resource ETag, and a private server key (as recommended above) then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation which does not maintain state between transactions.
このように、いくつかの目的のために、リプレイ攻撃から保護する必要があります。良いダイジェスト実装は、さまざまな方法でこれを行うことができます。サーバー作成された「ナンス」値は実装に依存するが、（上記の推奨のように）、それは、クライアントのIP、タイムスタンプ、リソースのETag、およびプライベートサーバキーのダイジェストが含まれているならば、リプレイ攻撃は簡単ではありません。攻撃者は、要求が偽のIPアドレスから来ていると、サーバは、それが文書を送信していると考えているためにアドレスとは異なるIPアドレスに文書を届けるために起こす必要があるサーバーを説得しなければなりません。タイムスタンプの有効期限が切れる前に攻撃が期間だけで成功することができます。ナンスで、クライアントのIPおよびタイムスタンプを消化することは、トランザクション間の状態を維持しない実装が可能になります。
For applications where no possibility of replay attack can be tolerated the server can use one-time nonce values which will not be honored for a second use. This requires the overhead of the server remembering which nonce values have been used until the nonce time-stamp (and hence the digest built with it) has expired, but it effectively protects against replay attacks.
リプレイ攻撃の可能性が第二の使用のために表彰されることはありません1回のナンス値を使用することができ、サーバーを容認することはできないアプリケーションの場合。これは、ナンス値はナンスタイムスタンプ（ひいてはそれで構築されたダイジェスト）が期限切れになるまで使用されているサーバー思い出すのオーバーヘッドを必要とするが、それは効果的にリプレイ攻撃から保護します。
An implementation must give special attention to the possibility of replay attacks with POST and PUT requests. Unless the server employs one-time or otherwise limited-use nonces and/or insists on the use of the integrity protection of qop=auth-int, an attacker could replay valid credentials from a successful request with counterfeit form data or other message body. Even with the use of integrity protection most metadata in header fields is not protected. Proper nonce generation and checking provides some protection against replay of previously used valid credentials, but see 4.8.
実装は、POSTとPUT要求にリプレイ攻撃の可能性に特別な注意を払う必要があります。サーバは、ワンタイムまたはその他の限定使用ナンスを採用し、および/またはQOP =のauth-int型の完全性保護の使用を主張しない限り、攻撃者は偽造フォームデータやその他のメッセージボディを持つ成功したリクエストから有効な資格情報を再生することができます。でも、完全性保護を使用してヘッダフィールドの中で最もメタデータは保護されていません。適切なノンス生成とチェックが以前に使用有効な資格情報のリプレイに対するいくつかの保護を提供しますが、4.8を参照してください。
An HTTP/1.1 server may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge.
HTTP / 1.1サーバは、401（認証）応答で複数のチャレンジを返すことができ、各課題は異なるAUTH-スキームを使用することができます。ユーザエージェントは、それが理解して最強のauth-スキームを使用し、その挑戦に基づいて、ユーザーの資格情報を要求するために選択する必要があります。
Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include Basic if it is minimally acceptable.
多くのブラウザが唯一の基本的な認識し、それが最初のauth-スキームを提示することを必要とすることに注意してください。それが最低限許容されている場合、サーバーが唯一の基本を含める必要があります。
When the server offers choices of authentication schemes using the WWW-Authenticate header, the strength of the resulting authentication is only as good as that of the of the weakest of the authentication schemes. See section 4.8 below for discussion of particular attack scenarios that exploit multiple authentication schemes.
サーバは、WWW-Authenticateヘッダを使用して認証方式の選択肢を提供する場合、得られた認証の強度は、認証方式の最も弱いののものとのみとして良好です。複数の認証方式を利用する特定の攻撃シナリオの議論については、以下のセクション4.8を参照してください。
If the attacker can eavesdrop, then it can test any overheard nonce/response pairs against a list of common words. Such a list is usually much smaller than the total number of possible passwords. The cost of computing the response for each password on the list is paid once for each challenge.
攻撃者が盗聴することができた場合、それは一般的な単語のリストに対して任意の耳にナンス/応答のペアをテストすることができます。このようなリストは、通常、可能なパスワードの総数よりもはるかに小さいです。リスト上の各パスワードの応答を計算するコストは、各チャレンジのために一度支払われます。
The server can mitigate this attack by not allowing users to select passwords that are in a dictionary.
サーバーは、ユーザーが辞書にあるパスワードを選択することができないことによって、この攻撃を軽減することができます。
Both Basic and Digest authentication are vulnerable to "man in the middle" (MITM) attacks, for example, from a hostile or compromised proxy. Clearly, this would present all the problems of eavesdropping. But it also offers some additional opportunities to the attacker.
基本とダイジェスト認証の両方が敵対的または危険にさらさプロキシから、例えば「中間者」（MITM）攻撃に対して脆弱です。明らかに、これは盗聴のすべての問題を提示します。しかし、それはまた、攻撃者にいくつかの追加の機会を提供しています。
A possible man-in-the-middle attack would be to add a weak authentication scheme to the set of choices, hoping that the client will use one that exposes the user's credentials (e.g. password). For this reason, the client should always use the strongest scheme that it understands from the choices offered.
可能man-in-the-middle攻撃は、クライアントがユーザーの資格情報（たとえば、パスワード）を公開するものを使用することを期待して、選択肢のセットに弱い認証スキームを追加することです。このため、クライアントは常にそれが提供する選択肢の中から理解最強のスキームを使用する必要があります。
An even better MITM attack would be to remove all offered choices, replacing them with a challenge that requests only Basic authentication, then uses the cleartext credentials from the Basic authentication to authenticate to the origin server using the stronger scheme it requested. A particularly insidious way to mount such a MITM attack would be to offer a "free" proxy caching service to gullible users.
より良いMITM攻撃は、それが要求された強力な方式を使用して、オリジンサーバへの認証に基本認証から平文の資格情報を使用し、基本認証のみを要求挑戦に置き換える、提供されるすべての選択肢を削除することです。そのようなMITM攻撃を仕掛けるために特に油断のならない方法はだまされやすいユーザに「自由」プロキシキャッシングサービスを提供することです。
User agents should consider measures such as presenting a visual indication at the time of the credentials request of what authentication scheme is to be used, or remembering the strongest authentication scheme ever requested by a server and produce a warning message before using a weaker one. It might also be a good idea for the user agent to be configured to demand Digest authentication in general, or from specific sites.
ユーザエージェントは、このような認証スキームを使用し、またはこれまでに、サーバから要求された最も強力な認証スキームを思い出し、弱いものを使用する前に、警告メッセージを生成するものの資格情報を要求時に視覚的表示を提示するなどの対策を検討すべきです。また、一般的に、または特定のサイトからDigest認証を要求するように設定されるユーザーエージェントのために良いアイデアかもしれません。
Or, a hostile proxy might spoof the client into making a request the attacker wanted rather than one the client wanted. Of course, this is still much harder than a comparable attack against Basic Authentication.
または、敵対的なプロキシは、攻撃者が1つのクライアントが望んでいたのではなく、望んでいた要求を行うにクライアントを偽装することがあります。もちろん、これはまだ基本認証に対して同等の攻撃よりもはるかに困難です。
With Digest authentication, a MITM or a malicious server can arbitrarily choose the nonce that the client will use to compute the response. This is called a "chosen plaintext" attack. The ability to choose the nonce is known to make cryptanalysis much easier [8].
ダイジェスト認証では、MITMあるいは悪意のあるサーバは、任意のクライアントが応答を計算するために使用するnonceを選択することができます。これは、「選択平文」攻撃と呼ばれています。 nonceを選択する能力は、[8]暗号解読がはるかに簡単に作ることが知られています。
However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known.
しかし、選択された平文を使用してダイジェストで使用されるMD5一方向関数を分析する方法は、現在知られていません。
The countermeasure against this attack is for clients to be configured to require the use of the optional "cnonce" directive; this allows the client to vary the input to the hash in a way not chosen by the attacker.
クライアントは、オプションの「cnonce」ディレクティブの使用を必要とするように設定するために、この攻撃対策です。これは、クライアントが攻撃者によって選ばれていない方法で、ハッシュへの入力を変化させることができます。
With Digest authentication, if the attacker can execute a chosen plaintext attack, the attacker can precompute the response for many common words to a nonce of its choice, and store a dictionary of (response, password) pairs. Such precomputation can often be done in parallel on many machines. It can then use the chosen plaintext attack to acquire a response corresponding to that challenge, and just look up the password in the dictionary. Even if most passwords are not in the dictionary, some might be. Since the attacker gets to pick the challenge, the cost of computing the response for each password on the list can be amortized over finding many passwords. A dictionary with 100 million password/response pairs would take about 3.2 gigabytes of disk storage.
攻撃者が選択平文攻撃を実行することができれば、ダイジェスト認証では、攻撃者は、その選択肢のナンスに多くの一般的な単語のための応答を事前計算し、（レスポンス、パスワード）のペアの辞書を格納することができます。このような事前計算は、多くの場合、多くのマシン上で並行して行うことができます。その後、その挑戦に対応するレスポンスを取得するために選ばれた平文攻撃を使用して、ちょうど辞書でパスワードを調べることができます。ほとんどのパスワードが辞書にない場合でも、いくつかはあるかもしれません。攻撃者が挑戦を選ぶことを得るので、リスト上の各パスワードの応答を計算するコストは、多くのパスワードを見つけることで償却することができます。億パスワード/レスポンスのペアと辞書は、ディスクストレージのおよそ3.2ギガバイトを取るだろう。
The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.
この攻撃に対する対策は、クライアントは、オプションの「cnonce」ディレクティブの使用を必要とするように設定するためにです。
With Digest authentication, a MITM can execute a chosen plaintext attack, and can gather responses from many users to the same nonce. It can then find all the passwords within any subset of password space that would generate one of the nonce/response pairs in a single pass over that space. It also reduces the time to find the first password by a factor equal to the number of nonce/response pairs gathered. This search of the password space can often be done in parallel on many machines, and even a single machine can search large subsets of the password space very quickly -- reports exist of searching all passwords with six or fewer letters in a few hours.
ダイジェスト認証では、MITMは選択平文攻撃を実行することができ、かつ同じナンスに多くのユーザーからの応答を収集することができます。それは、そのスペース上の単一パスでナンス/応答のペアのいずれかを生成するパスワード空間の任意のサブセット内のすべてのパスワードを見つけることができます。また、集まったnonce /レスポンスペアの数に等しい係数による最初のパスワードを見つけるための時間が短縮されます。パスワードスペースのこの検索は、多くの場合、多くのマシン上で並行して行うことができ、さらに、単一のマシンは非常に迅速に、パスワードスペースの大部分集合を検索することができます - レポートは数時間で6文字以下で、すべてのパスワードを検索するので存在します。
The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.
この攻撃に対する対策は、クライアントは、オプションの「cnonce」ディレクティブの使用を必要とするように設定するためにです。
Basic Authentication is vulnerable to spoofing by counterfeit servers. If a user can be led to believe that she is connecting to a host containing information protected by a password she knows, when in fact she is connecting to a hostile server, then the hostile server can request a password, store it away for later use, and feign an error. This type of attack is more difficult with Digest Authentication -- but the client must know to demand that Digest authentication be used, perhaps using some of the techniques described above to counter "man-in-the-middle" attacks. Again, the user can be helped in detecting this attack by a visual indication of the authentication mechanism in use with appropriate guidance in interpreting the implications of each scheme.
基本認証は偽造サーバによってスプーフィングに対して脆弱です。ユーザーが実際に彼女が敵対的なサーバーに接続しているとき、彼女は、彼女が知っているパスワードで保護された情報を含むホストに接続されていることを信じるように導くことができる場合には、敵対的なサーバは、後の使用のためにそれを離れて保存し、パスワードを要求することができます、およびエラーを装います。このタイプの攻撃はダイジェスト認証とより困難である - しかし、クライアントがダイジェスト認証が、おそらく「のman-in-the-middle」攻撃に対抗するために、上述の技術の一部を使用して、使用することを要求する知っている必要があります。再び、ユーザは、各スキームの意味を解釈する際に適切なガイダンスに使用されている認証メカニズムを視覚的に表示することにより、この攻撃を検出する際に助けすることができます。
Digest authentication requires that the authenticating agent (usually the server) store some data derived from the user's name and password in a "password file" associated with a given realm. Normally this might contain pairs consisting of username and H(A1), where H(A1) is the digested value of the username, realm, and password as described above.
ダイジェスト認証は、認証エージェント（通常はサーバー）が与えられたレルムに関連付けられ、「パスワードファイル」でユーザ名とパスワードから派生し、いくつかのデータを格納する必要があります。通常、これは、ユーザ名と上記のようにH（A1）は、ユーザ名、レルム、およびパスワードの消化された値であり、H（A1）からなるペアを含むかもしれません。
The security implications of this are that if this password file is compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say a standard UNIX password file, this information need not be decrypted in order to access documents in the server realm associated with this file. On the other hand, decryption, or more likely a brute force attack, would be necessary to obtain the user's password. This is the reason that the realm is part of the digested data stored in the password file. It means that if one Digest authentication password file is compromised, it does not automatically compromise others with the same username and password (though it does expose them to brute force attack).
このによるセキュリティへの影響は、このパスワード・ファイルが侵害された場合、攻撃者がこのレルムを使用して、サーバー上のドキュメントへの即時アクセスを得ることです。標準のUNIXパスワードファイルを言うとは異なり、この情報は、このファイルに関連付けられたサーバーレルム内のドキュメントにアクセスするためには、復号化する必要はありません。一方、復号化、またはそれ以上の可能性がブルートフォース攻撃では、ユーザーのパスワードを取得する必要があります。これは、レルムがパスワードファイルに保存されている消化されるデータの一部である理由です。これは、1つのダイジェスト認証パスワードファイルが危険にさらされている場合（これは、ブルートフォース攻撃にそれらを公開んが）、それは自動的に同じユーザー名とパスワードで他人を損なわないことを意味します。
There are two important security consequences of this. First the password file must be protected as if it contained unencrypted passwords, because for the purpose of accessing documents in its realm, it effectively does.
この2つの重要なセキュリティ上の影響があります。それは暗号化されていないパスワードが含まれているかのようにその領域で文書にアクセスする目的のために、それが効果的に行いますので、まずパスワードファイルは、保護されなければなりません。
A second consequence of this is that the realm string should be unique among all realms which any single user is likely to use. In particular a realm string should include the name of the host doing the authentication. The inability of the client to authenticate the server is a weakness of Digest Authentication.
この第二の結果は、レルム文字列は、任意の単一のユーザが使用する可能性があるすべてのレルムの中で一意でなければならないということです。特に、realm文字列は、認証を行うホストの名前を含める必要があります。サーバを認証するためのクライアントのできないことは、ダイジェスト認証の弱さです。
By modern cryptographic standards Digest Authentication is weak. But for a large range of purposes it is valuable as a replacement for Basic Authentication. It remedies some, but not all, weaknesses of Basic Authentication. Its strength may vary depending on the implementation. In particular the structure of the nonce (which is dependent on the server implementation) may affect the ease of mounting a replay attack. A range of server options is appropriate since, for example, some implementations may be willing to accept the server overhead of one-time nonces or digests to eliminate the possibility of replay. Others may satisfied with a nonce like the one recommended above restricted to a single IP address and a single ETag or with a limited lifetime.
現代の暗号規格でダイジェスト認証は弱いです。しかし、目的の広い範囲のためには、基本認証の代替品として貴重です。この救済いくつかの、すべてではないが、基本認証の弱点。その強さは、実装によって異なる場合があります。具体的には（サーバの実装に依存する）ナンスの構造は、リプレイ攻撃を搭載性に影響を及ぼし得ます。例えば、いくつかの実装は、再生の可能性を排除するために、ワンタイムノンス又はダイジェストのサーバーのオーバーヘッドを受け入れることができる、ので、サーバー・オプションの範囲が適当です。その他は、単一のIPアドレスおよび単一のETag、あるいは限られた寿命で制限上記の推奨のようなナンスに満足します。
The bottom line is that *any* compliant implementation will be relatively weak by cryptographic standards, but *any* compliant implementation will be far superior to Basic Authentication.
一番下の行は、任意の*準拠した実装は、暗号化基準では比較的弱くなりますが、*は任意の*準拠した実装は、基本認証よりはるかに優れだろう*ということです。
5 Sample implementation
5サンプル実装
The following code implements the calculations of H(A1), H(A2), request-digest and response-digest, and a test program which computes the values used in the example of section 3.5. It uses the MD5 implementation from RFC 1321.
次のコードは、H（A1）、H（A2）、要求ダイジェストと応答ダイジェスト、およびセクション3.5の例で使用される値を計算するテストプログラムの計算を実現します。これは、RFC 1321からMD5実装を使用しています。
File "digcalc.h":
"digcalc.hを" ファイル：
#define HASHLEN 16
typedef char HASH[HASHLEN];
#define HASHHEXLEN 32
typedef char HASHHEX[HASHHEXLEN+1];
#define IN
#define OUT
/* calculate H(A1) as per HTTP Digest spec */
void DigestCalcHA1(
IN char * pszAlg,
IN char * pszUserName,
IN char * pszRealm,
IN char * pszPassword,
IN char * pszNonce,
IN char * pszCNonce,
OUT HASHHEX SessionKey
);
/* calculate request-digest/response-digest as per HTTP Digest spec */
void DigestCalcResponse(
IN HASHHEX HA1, /* H(A1) */
IN char * pszNonce, /* nonce from server */
IN char * pszNonceCount, /* 8 hex digits */
IN char * pszCNonce, /* client nonce */
IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
IN char * pszMethod, /* method from the request */
IN char * pszDigestUri, /* requested URL */
IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
OUT HASHHEX Response /* request-digest or response-digest */
);
File "digcalc.c":
"digcalc.cを" ファイル：
#include <global.h> #include <md5.h>
書式#include <GLOBAL.H>書式#include <md5.h>
#include <string.h> #include "digcalc.h"
書式#include <string.hの>の#include "digcalc.h"
void CvtHex(
IN HASH Bin,
OUT HASHHEX Hex
)
{
unsigned short i;
unsigned char j;
for (i = 0; i < HASHLEN; i++) {
j = (Bin[i] >> 4) & 0xf;
if (j <= 9)
Hex[i*2] = (j + '0');
else
Hex[i*2] = (j + 'a' - 10);
j = Bin[i] & 0xf;
if (j <= 9)
Hex[i*2+1] = (j + '0');
else
Hex[i*2+1] = (j + 'a' - 10);
};
Hex[HASHHEXLEN] = '\0';
};
/* calculate H(A1) as per spec */
void DigestCalcHA1(
IN char * pszAlg,
IN char * pszUserName,
IN char * pszRealm,
IN char * pszPassword,
IN char * pszNonce,
IN char * pszCNonce,
OUT HASHHEX SessionKey
)
{
MD5_CTX Md5Ctx;
HASH HA1;
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword));
MD5Final(HA1, &Md5Ctx);
if (stricmp(pszAlg, "md5-sess") == 0) {
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, HA1, HASHLEN);
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
MD5Final(HA1, &Md5Ctx);
};
CvtHex(HA1, SessionKey);
};
/* calculate request-digest/response-digest as per HTTP Digest spec */
void DigestCalcResponse(
IN HASHHEX HA1, /* H(A1) */
IN char * pszNonce, /* nonce from server */
IN char * pszNonceCount, /* 8 hex digits */
IN char * pszCNonce, /* client nonce */
IN char * pszQop, /* qop-value: "", "auth", "auth-int" */
IN char * pszMethod, /* method from the request */
IN char * pszDigestUri, /* requested URL */
IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */
OUT HASHHEX Response /* request-digest or response-digest */
)
{
MD5_CTX Md5Ctx;
HASH HA2;
HASH RespHash;
HASHHEX HA2Hex;
// calculate H(A2)
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri));
if (stricmp(pszQop, "auth-int") == 0) {
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, HEntity, HASHHEXLEN);
};
MD5Final(HA2, &Md5Ctx);
CvtHex(HA2, HA2Hex);
// calculate response
MD5Init(&Md5Ctx);
MD5Update(&Md5Ctx, HA1, HASHHEXLEN);
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));
MD5Update(&Md5Ctx, ":", 1);
if (*pszQop) {
MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce));
MD5Update(&Md5Ctx, ":", 1);
MD5Update(&Md5Ctx, pszQop, strlen(pszQop));
MD5Update(&Md5Ctx, ":", 1);
};
MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN);
MD5Final(RespHash, &Md5Ctx);
CvtHex(RespHash, Response);
};
File "digtest.c":
"digtest.cを" ファイル：
#include <stdio.h> #include "digcalc.h"
書式#include <stdio.hに>の#include "digcalc.h"
void main(int argc, char ** argv) {
ボイドメイン（int型ARGC、チャー** ARGV）{
char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093";
char * pszCNonce = "0a4f113b";
char * pszUser = "Mufasa";
char * pszRealm = "testrealm@host.com";
char * pszPass = "Circle Of Life";
char * pszAlg = "md5";
char szNonceCount[9] = "00000001";
char * pszMethod = "GET";
char * pszQop = "auth";
char * pszURI = "/dir/index.html";
HASHHEX HA1;
HASHHEX HA2 = "";
HASHHEX Response;
DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
pszCNonce, HA1);
DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
pszMethod, pszURI, HA2, Response);
printf("Response = %s\n", Response);
};
6 Acknowledgments
6つの謝辞
Eric W. Sink, of AbiSource, Inc., was one of the original authors before the specification underwent substantial revision.
仕様はかなりの改訂を受けた前AbiSource社のエリック・W.シンクは、原作者の一つでした。
In addition to the authors, valuable discussion instrumental in creating this document has come from Peter J. Churchyard, Ned Freed, and David M. Kristol.
作者に加えて、この文書を作成する際に、貴重な議論の楽器は、ピーターJ.教会墓地、ネッドフリード、とDavid M.クリストルから来ています。
Jim Gettys and Larry Masinter edited this document for update.
ジム・ゲティーズとラリーMasinterが更新のためにこの文書を編集しました。
7 References
7つの参考文献
[1] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[1]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[2] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[2]フィールディング、R.、ゲティス、J.、モーグル、J.、Frysyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[3]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[4] Freed, N. and N. Borenstein. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[4]フリード、N.、およびN. Borenstein。 「多目的インターネットメール拡張（MIME）第一部：インターネットメッセージ本体のフォーマット」、RFC 2045、1996年11月。
[5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[5]ダークス、T.とC.アレン "TLSプロトコル、バージョン1.0"、RFC 2246、1999年1月。
[6] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[6]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、シンク、E.およびL.スチュワート、 "HTTPへの拡張：ダイジェストアクセス認証"、 RFC 2069、1997年1月。
[7] Berners Lee, T, Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]バーナーズ・リー、T、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", CryptoBytes, Sping 1995, RSA Inc, (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
[8] Kaliski、B.、Robshaw、M.、 "MD5とメッセージ認証"、CryptoBytes、SPING 1995、RSA社、（http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm ）
[9] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[9] Klensin、J.、Catoe、R.及びP. Krumviede、 "IMAP / SIMPLEチャレンジ/レスポンスのためのPOP許可拡張子"、RFC 2195、1997年9月。
[10] Morgan, B., Alvestrand, H., Hodges, J., Wahl, M., "Authentication Methods for LDAP", Work in Progress.
[10]モルガン、B.、Alvestrand、H.、ホッジス、J.、ワール、M.、 "LDAPのための認証方法"、ProgressのWork。
8 Authors' Addresses
8本の著者のアドレス
John Franks Professor of Mathematics Department of Mathematics Northwestern University Evanston, IL 60208-2730, USA
数学ノースウェスタン大学エバンストン、IL 60208-2730、USAの数学部門のジョン・フランクス教授
EMail: john@math.nwu.edu
メールアドレス：john@math.nwu.edu
Phillip M. Hallam-Baker Principal Consultant Verisign Inc. 301 Edgewater Place Suite 210 Wakefield MA 01880, USA
フィリップM.ハラム - ベイカープリンシパルコンサルタントベリサイン株式会社301エッジウォータープレイススイート210ウェイクフィールドMA 01880、USA
EMail: pbaker@verisign.com
メールアドレス：pbaker@verisign.com
Jeffery L. Hostetler Software Craftsman AbiSource, Inc. 6 Dunlap Court Savoy, IL 61874
ジェフリーL. Hostetlerソフトウェア職人AbiSource、Inc.の6ダンラップ裁判所サヴォイ、IL 61874
EMail: jeff@AbiSource.com
メールアドレス：jeff@AbiSource.com
Scott D. Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
スコット・D.ローレンスAgranat Systems、Inc.の5クロックタワープレイス、スイート400メイナード、MA 01754、USA
EMail: lawrence@agranat.com
メールアドレス：lawrence@agranat.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
ポール・J.リーチマイクロソフト社1マイクロソフト道レドモンド、WA 98052、USA
EMail: paulle@microsoft.com
メールアドレス：paulle@microsoft.com
Ari Luotonen Member of Technical Staff Netscape Communications Corporation 501 East Middlefield Road Mountain View, CA 94043, USA
テクニカルスタッフNetscape Communications Corporationのアリ・ルオトナンメンバー501東ミドルロード、マウンテンビュー、CA 94043、USA
Lawrence C. Stewart Open Market, Inc. 215 First Street Cambridge, MA 02142, USA
ローレンスC.スチュワート公開市場、Inc.の215まずストリート、ケンブリッジ、MA 02142、USA
EMail: stewart@OpenMarket.com
メールアドレス：stewart@OpenMarket.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。