RFC2617 日本語訳
2617 HTTP Authentication: Basic and Digest Access Authentication. J.Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.Luotonen, L. Stewart. June 1999. (Format: TXT=77638 bytes) (Obsoletes RFC2069) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
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
フランクフルトソーセージがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2617年のノースウェスタン大学は以下を時代遅れにします。 2069年のP.ハラム-ベイカーカテゴリ: 市場Inc.1999年6月にオープンな標準化過程Verisign Inc.J.Hostetler AbiSource Inc.S.ローレンスAgranatシステムInc.P.リーチマイクロソフト社のA.Luotonenネットスケープ社のL.スチュワート
HTTP Authentication: Basic and Digest Access Authentication
HTTP認証: 基本的、そして、ダイジェストアクセス認証
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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インチ、Basic Access Authenticationのための仕様が計画するインクルード。」 この体系はユーザー認証の安全なメソッドであると考えられません。(SSLなどの外部の安全な何らかのシステムに関連して使用されない場合、ユーザ名とパスワードとしての[5])はcleartextとしてネットワークの上に通過されます。
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の認証フレームワークとオリジナルのBasic認証体系と「ダイジェストアクセス認証」と呼ばれた暗号のハッシュに基づく体系のための仕様を提供します。 したがって、また、それがRFC2069[6]との交換として機能することを意図します。 公表以来見つけられた問題のためこの仕様からRFC2069によって指定されたいくつかの随意的な要素を取り除きました。 他の新しい要素が互換性のために加えられて、それらの新しい要素は、任意に作られていますが、強く推薦されました。
Franks, et al. Standards Track [Page 1] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[1ページ]。
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のように、Digestアクセス認証は、コミュニケーションへの双方が共有秘密キー(パスワード)を知っていることを確かめます。 Basic、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
1 認証にアクセスしてください… 3 HTTP/1.1仕様への1.1信用… 3 1.2 認証フレームワークにアクセスしてください… 3 2基本認証体系… 5 3はアクセス認証体系を読みこなします… 6 3.1序論… 6 3.1 .1目的… 6 3.1 .2 総合的な操作… 6 3.1 .3 ダイジェスト値の表現… 7 3.1 .4の制限… 7 3.2 ダイジェストヘッダーの仕様… 7 3.2 .1、応答ヘッダをWWW認証してください… 8 3.2 .2 承認要求ヘッダー… 11 3.2 .3 認証インフォメーションヘッダー… 15 3.3 操作を読みこなしてください… 17 3.4 セキュリティは交渉について議定書の中で述べます… 18 3.5の例… 18 3.6のプロキシ認証とプロキシ承認… 19 4 セキュリティ問題… 19 4.1 基本認証を使用しているクライアントの認証… 19 4.2 ダイジェスト認証を使用しているクライアントの認証… 4.3が制限した20は一回だけの値を使用します… 21 4.4 基本認証とのダイジェストの比較… 22 4.5の反射攻撃… 22 複数の認証体系によって作成された4.6弱点… 23 4.7のオンライン辞書は攻撃されます… 23 4.8 中央でやれやれ… 24 4.9の選ばれた平文は攻撃されます… 24 4.10は辞書攻撃をPrecomputedしました… 25 4.11 バッチブルートフォースアタック… 25 4.12 にせのサーバで、だまします… 25 4.13 パスワードを保存します… 26 4.14概要… 26 5 実装を抽出してください… 27 6つの承認… 31
Franks, et al. Standards Track [Page 2] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[2ページ]。
7 References........................................... 31 8 Authors' Addresses................................... 32 9 Full Copyright Statement............................. 34
7つの参照箇所… 31 8人の作者のアドレス… 32 9 完全な著作権宣言文… 34
1 Access Authentication
1 アクセス認証
1.1 Reliance on the HTTP/1.1 Specification
1.1 HTTP/1.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仕様の他の局面を当てにします。
1.2 Access Authentication Framework
1.2 アクセス認証フレームワーク
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の(権限のない)の応答メッセージは発生源サーバによって使用されて、ユーザエージェントの承認に挑戦します。 この応答はaを含まなければなりません。要求されたリソースに適切な少なくとも1つの挑戦を含んで、ヘッダーフィールドをWWW認証してください。 407(プロキシAuthentication Required)応答メッセージはクライアントの承認に挑戦するのにプロキシによって使用されます、そして、インクルードa Proxyは要求されたリソースに、プロキシに適切な少なくとも1つの挑戦を含むヘッダーフィールドを認証しなければなりませんか?
challenge = auth-scheme 1*SP 1#auth-param
auth-体系1*SP1挑戦=#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.
以下に注意してください。 1つ以上の挑戦を含んでいるか、または1以上がヘッダーをWWW認証するなら挑戦のコンテンツが供給するのでそれ自体で野原を供給するならエージェントがWWWが認証する構文解析で特別に注意を払うか、またはヘッダーフィールド値をProxy認証する必要があるユーザは、認証パラメタのコンマで切り離されたリストを含みます。
The authentication parameter realm is defined for all authentication schemes:
認証パラメタ分野はすべての認証体系のために定義されます:
realm = "realm" "=" realm-value
realm-value = quoted-string
分野=「分野」「=」分野価値の分野価値は引用文字列と等しいです。
Franks, et al. Standards Track [Page 3] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[3ページ]。
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を見て、保護スペースを定義します。 これらの分野は、サーバに関する保護されたリソースが1セットの保護空間に仕切られるのを許容します、それぞれそれ自身の認証体系、そして/または、承認データベースで。 分野値は追加意味論を認証体系に特定にするかもしれない一般に、発生源サーバによって割り当てられたストリングです。 同じ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(プロキシAuthentication Required)--要求でProxy承認ヘッダーフィールドを含んでいることによってそうするかもしれないのを受けた後に通常、プロキシと共にそれ自体を認証することを願っていますが、必ず認証するというわけではないクライアント。 Authorization分野価値とProxy-承認分野価値の両方が要求されているリソースの分野にクライアントの認証情報を含む資格証明書から成ります。 ユーザエージェントは、理解して、ユーザからの要求資格証明書がその挑戦に基づかせた中で最も強いauth-体系がある挑戦の1つを使用するのを選ばなければなりません。
credentials = auth-scheme #auth-param
資格証明書はauth-体系#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.
多くのブラウザが、Basicを認めるだけであり、それが提示された最初のauth-体系であることを必要とすることに注意してください。 それが最少量で許容できる場合にだけ、サーバはBasicを含むべきです。
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
発生源サーバが受け入れたくないなら、資格証明書は要求と共に発信して、それはSHOULDリターンa401(権限のない)応答です。 応答はaを含まなければなりません。要求されたリソースに適切な少なくとも1つの(ことによると新しい)の挑戦を含んで、ヘッダーフィールドをWWW認証してください。 プロキシが受け入れないなら、資格証明書は要求と共に発信して、それはSHOULDリターンa407(プロキシAuthentication Required)です。 応答が含まなければならない、aはaを含むヘッダーフィールドをProxy認証します。
Franks, et al. Standards Track [Page 4] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[4ページ]。
(possibly new) challenge applicable to the proxy for the requested resource.
(ことによると新しい) 要求されたリソースにプロキシに適切な状態で、挑戦してください。
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認証、Authorizationヘッダー、触れない、そして、規則が[2]のセクション14.8で見つけた尾行。 Proxy-承認ヘッダーフィールドはホップごとのヘッダーです。そして、両方、Proxy認証、([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と各分野のためのパスワードでそれ自体でクライアントが認証しなければならないモデルに基づいています。 分野値は平等のためにそのサーバの他の分野にたとえることができるだけである不透明なストリングであると考えられるべきです。Request-URIの保護スペースのためのユーザIDとパスワードを有効にすることができる場合にだけ、サーバは要求を修理するでしょう。 どんな任意の認証パラメタもありません。
For Basic, the framework above is utilized as follows:
Basicにおいて、上のフレームワークは以下の通り利用されます:
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"がサーバによって割り当てられた、Request-URIの保護スペースを特定したストリングであるところ。 プロキシが同じ挑戦使用で応じるかもしれない、ヘッダーフィールドをProxy認証してください。
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.
承認を受けるために、クライアントが1コロンによって切り離されたユーザIDとパスワードを送る、(「:」、)、キャラクタ、base64の中では、[7]は資格証明書でストリングをコード化しました。
basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass,
基本的な資格証明書はユーザパスのbase64ユーザパスbase64ユーザパス=<base64[4]コード化と等しいです。
Franks, et al. Standards Track [Page 5] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[5ページ]。
except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
「76系列>ユーザ炭/パス=ユーザIDに制限されない」:、」 「パスワードユーザID=*<TEXT除外」: 「>パスワード=*テキスト」
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のすべてをいるSHOULDが仮定するクライアントは現在の挑戦のBasic分野価値で指定しました。 クライアントはそのスペースのリソースに関する要求と共にサーバから別の挑戦の領収書なしで対応するAuthorizationヘッダーを先制的に送るかもしれません。クライアントが要求をプロキシに送るとき、プロキシサーバから別の挑戦を受けないで、同様に、それはProxy-承認ヘッダーフィールドにおけるユーザIDとパスワードを再利用するかもしれません。Basic認証に関連しているセキュリティ問題に関してセクション4を見てください。
3 Digest Access Authentication Scheme
3ダイジェストアクセス認証体系
3.1 Introduction
3.1 序論
3.1.1 Purpose
3.1.1 目的
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インチは基本的なアクセス認証体系[1]のための仕様を含んでいる」と呼ばれたプロトコル。 その体系はユーザー認証の安全なメソッドであると考えられません、ユーザ名とパスワードが非暗号化されたフォームでネットワークの上に通過されるとき。 このセクションは「ダイジェストアクセス認証」と呼ばれたcleartextのパスワードを送らない体系のための仕様を提供します。
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.
Digest Access Authentication体系はWWWにおけるセキュリティの必要性の完全な答えであることを意図しません。 この体系はメッセージ内容の暗号化を全く提供しません。 意図は単にBasic認証の最も多くの重大な欠陥を避けるアクセス認証方法を作成することです。
3.1.2 Overall Operation
3.1.2 総合的な操作
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
Basic Access Authenticationのように、Digest体系は簡単なチャレンジレスポンスパラダイムに基づいています。 一回だけの値を使用することでDigest体系は挑戦します。 有効回答がチェックサムを含んでいる、(
Franks, et al. Standards Track [Page 6] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[6ページ]。
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.
デフォルト、MD5チェックサム) ユーザ名、パスワード、与えられた一回だけの値、HTTPメソッド、および要求されたURIについて。 このように、明確でパスワードを決して送りません。 ちょうどBasic体系なら、このドキュメントによって扱われなかった何らかのファッションでユーザ名とパスワードについて根回ししなければなりません。
3.1.3 Representation of digest values
3.1.3 ダイジェスト値の表現
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ビットのダイジェストのビットは最下位ビットに最も重要な状態で変えられます、一度に以下の彼らのASCIIプレゼンテーションへの4ビット。 各4ビットは身近な16進法によってキャラクタ0123456789abcdefから表されます。 すなわち、2進の0000はキャラクタ'0'、0001によって表されます、'1''f'としての1111年の表現までのなどで。
3.1.4 Limitations
3.1.4 制限
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.
本書では説明されたDigest認証体系は多くの知られている制限に苦しみます。 それはBasic認証とそれ以上何もとの交換として意図します。 それは、パスワードベースのシステムであり、どんなパスワードシステムのちょうど同じ問題にも苦しみます(サーバ側で)。 このプロトコルでユーザとサーバの間の初期の安全な配置がユーザのパスワードを確立するのを設備を全く特に、しません。
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.
ユーザと作成者はこのプロトコルがケルベロスほど安全でなくて、またどんなクライアントサイド秘密鍵体系ほども安全でないことを意識しているべきです。 それにもかかわらず、それは、ないよりましで、telnetと共に一般的に使用されることとftpより良くて、Basic認証より良いです。
3.2 Specification of Digest Headers
3.2 ダイジェストヘッダーの仕様
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.
Digest Access Authentication体系は概念的にBasic体系と同様です。 変更の形式はヘッダー系列をWWW認証します、そして、Authorizationヘッダー系列は以下で指定されます。 さらに、新しいヘッダー(Authentication-インフォメーション)は指定されます。
Franks, et al. Standards Track [Page 7] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[7ページ]。
3.2.1 The WWW-Authenticate Response Header
3.2.1、応答ヘッダをWWW認証してください。
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ヘッダーが送られないなら、サーバがaで反応する、「401、権限のなさ、」 ステータスコード、aがヘッダーをWWW認証する、上で定義されたフレームワークに従って:フレームワークは以下の通りダイジェスト体系に利用されます。
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=absoluteURI」| 腹筋..経路..一回だけ..一回だけ..等しい..一回だけ..値..一回だけ..値..引用文字列..不透明なもの..不透明..引用文字列..聞き古した..聞き古した..本当に..虚偽..アルゴリズム..アルゴリズム..トークン..オプション..等しい..値..値| "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".
彼らが、どのユーザ名とパスワードを使用したらよいかを知っていて、Aがユーザに表示するために結ぶ分野。 このストリングは、少なくとも認証を実行しているホストの名前を含むべきであり、さらに、アクセサリーを持っているかもしれないユーザの収集を示すかもしれません。 例は" 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.
Aが引用したドメイン、RFC XURI[7]の指定されるとしての保護スペースを定義するURIのスペースで切り離されたリスト。 URIが腹筋_経路であるなら、アクセスされていて、それはサーバの正準な根のURL(セクション1.2が上であることを見る)に比例しています。 このリストのabsoluteURIはアクセスされるものと異なったサーバを示すかもしれません。 クライアントは同じ認証情報が送られるかもしれないURIのセットを決定するのにこのリストを使用できます: 接頭語(両方を絶対にした後に)としてこのリストのURIを持っているどんなURIも同じ保護スペースにあると思われるかもしれません。 この指示が省略されるか、または値が空であるなら、クライアントは、保護スペースが応じるサーバに関するすべてのURIから成ると仮定するべきです。
Franks, et al. Standards Track [Page 8] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[8ページ]。
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.
この指示は重要なコネがいつも保護が区切るものが全体のプロキシであるのでヘッダーをProxy認証するということではありません。 プレゼントであるなら、それは無視されるべきです。
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応答がされる各回であると唯一生成されるべきである一回だけのAサーバで指定されたデータ列。 このストリングが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.
実装は、以前中古の一回だけか以前中古のダイジェストを受け入れないのを選ぶかもしれません、反射攻撃から守るために。 または、実装は、GET要求のためのポストのための1回の一回だけかダイジェストかPUT要求とタイムスタンプを使用するのを選ぶかもしれません。 かかわった問題に関するその他の詳細に関しては、このドキュメントのセクション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.
その後の要求のAuthorizationヘッダーで変わりのないURIが同じ保護スペースにある状態でクライアントによって返されるべきであるサーバによって指定されたA一連のデータについて不透明にしてください。 このストリングがbase64か16進データであることがお勧めです。
Franks, et al. Standards Track [Page 9] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[9ページ]。
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.
一回だけの値が聞き古したであったクライアントからの前の要求が拒絶されたのを示して、A旗は聞き古したになってください。 クライアントは、聞き古したであるTRUEが(大文字と小文字を区別しない)であると再試行したがっているかもしれません。新しいユーザ名とパスワードのためにユーザを「再-うなが」さないで、新しい暗号化された応答で単に要求を再試行してください。 一回だけが無効である要求を受け取りますが、それがその一回だけのために有効なダイジェストでセットする場合にだけ、サーバはTRUEに聞き古したであるセットするべきです(クライアントが正しいユーザ名/パスワードを知っているのを示して)。 聞き古したである、TRUE以外に、FALSE、または何かがあるか、聞き古した指示はプレゼント、ユーザ名、そして/または、パスワードが無効であり、新しい値を得なければならないということではありません。
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).
1組のアルゴリズムを示すアルゴリズムAストリングが以前はよくダイジェストとチェックサムを製作していました。 これが存在していないなら、それは"MD5""であると思われます。 アルゴリズムが理解されていないなら、挑戦は無視されるべきです(そして、1つ以上があれば使用される異なったもの)。
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-sess」アルゴリズム」のために
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-sess」アルゴリズムが3番目の効率的なパーティー認証サーバを許容することを意図します。 用法の違いに関しては、.2にセクション3.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
qop-オプションThis指示を任意ですが、RFC2069[6]との後方の互換性のためだけにそのようにします。 それ、SHOULD、Digest体系のこのバージョンによる対応することのすべての実装で、使用されてください。 存在しているなら、それはサーバによってサポートされた「保護の品質」値を示す1つ以上のトークンに関する引用文字列です。値の"auth"は認証を示します。 値の"auth-int"は保全保護で認証を示します。 見る
Franks, et al. Standards Track [Page 10] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[10ページ]。
descriptions below for calculating the response directive value for
the application of this choice. Unrecognized options MUST be
ignored.
この選択の応用のために応答指示価値について計算するための以下での記述。 認識されていないオプションを無視しなければなりません。
auth-param
This directive allows for future extensions. Any unrecognized
directive MUST be ignored.
auth-param This指示は今後の拡大を考慮します。 どんな認識されていない指示も無視しなければなりません。
3.2.2 The Authorization Request Header
3.2.2 承認要求ヘッダー
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] )
資格証明書は「ダイジェスト」ダイジェスト応答ダイジェスト応答=1#、と等しいです。(ユーザ名|分野|一回だけ| ダイジェスト-uri| 応答|[アルゴリズム]|[cnonce]| [不透明な]| [メッセージ-qop]| [一回だけのカウントしている]| [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ユーザ名=「ユーザ名」「=」ユーザ名価値のユーザ名価値=価値は要求-uriと等しいです。 HTTP/1.1メッセージ-qop="qop"「=」qop-値cnonce="nc"一回だけの値の一回だけの"cnonce"「=」cnonce-値のcnonce-価値=カウント=「=」nc-値のnc-値=8LHEX応答=「応答」「=」要求ダイジェスト要求ダイジェスト=<によって指定される、「>32LHEX<、「>LHEXは「0インチ」等しいです。| "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a"| 「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十六進法ケタの応答Aストリング。(そのストリングは、ユーザがパスワードを知っていると立証します)。
username
The user's name in the specified realm.
ユーザのものが指定された分野で命名するユーザ名。
Franks, et al. Standards Track [Page 11] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[11ページ]。
digest-uri
The URI from Request-URI of the Request-Line; duplicated here
because proxies are allowed to change the Request-Line in transit.
Request-線のRequest-URIからURIを-uriに読みこなしてください。 プロキシがトランジットでRequest-線を変えることができるので、ここにコピーされます。
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 Indicates、何、「」 クライアントがメッセージに適用した保護の品質。 存在しているなら、値がサーバが中でサポートするのを示した代替手段の1つでなければならない、ヘッダーをWWW認証してください。 これらの値は要求ダイジェストの計算に影響します。 これが同じくらい中のWWWが認証する代替手段の引用されたリストではなく、ただ一つのトークンであることに注意してください。 この指示がしかし、RFC2069[6]の最小限の器具、SHOULDとの後方の互換性を保存するために任意である、サーバが、qopがqop指示を中に提供することによってサポートされるのを示したなら使用されてください、ヘッダーフィールドをWWW認証してください。
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 Thisがqop指示を送るなら(上を見てください)指定していなければならなくて、サーバがqop指示を送らなかったなら指定しているはずがない、ヘッダーフィールドをWWW認証してください。 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.
一回だけのカウントThisがqop指示を送るなら(上を見てください)指定していなければならなくて、サーバがqop指示を送らなかったなら指定しているはずがない、ヘッダーフィールドをWWW認証してください。 nc-値はクライアントがこの要求における一回だけの値と共に発信したという要求(現在の要求を含んでいる)の数の16進カウントです。 例えば、与えられた一回だけの値に対応して送られた最初の要求では、クライアントは「nc=1インチ」発信します。 この指示の目的はサーバがそれ自身のこのカウントのコピーを維持することによって要求再生を検出するのを許容することです--同じnc-値が二度見られるなら、要求は再生です。 要求ダイジェスト価値の構造における以下の記述を見てください。
auth-param
This directive allows for future extensions. Any unrecognized
directive MUST be ignored.
auth-param This指示は今後の拡大を考慮します。 どんな認識されていない指示も無視しなければなりません。
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.
指示かその値が不適当であるか、または必要な指示がなくなるなら、適切な応答は400Bad Requestです。 要求ダイジェストが無効であるなら、ログイン失敗は登録されるべきです、独身のクライアントからの繰り返されたログイン失敗がパスワードを推測するのを試みる攻撃者を示すかもしれないので。
Franks, et al. Standards Track [Page 12] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[12ページ]。
The definition of request-digest above indicates the encoding for its value. The following definitions show how the value is computed.
要求ダイジェストの上の定義は値のためのコード化を示します。 以下の定義は値がどう計算されるかを示しています。
3.2.2.1 Request-Digest
3.2.2.1 -読みこなすよう要求してください。
If the "qop" value is "auth" or "auth-int":
"qop"値は"auth"であるかどうかか"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"指示が存在していないなら(この工事はRFC2069との互換性のためのものです):
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に関して以下を見てください。
3.2.2.2 A1
3.2.2.2 A1
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:
aは挑戦をWWW認証します。A1が指示のものが、評価する「アルゴリズムはMD5-sessです」であるなら最初の要求のときに一度だけクライアントの次の領収書によって計算される、サーバから、その挑戦、および以下のA1を組み立てるクライアントの最初の一回だけ価値からサーバ一回だけを使用します:
A1 = H( unq(username-value) ":" unq(realm-value)
":" passwd )
":" unq(nonce-value) ":" unq(cnonce-value)
「A1がHと等しい、(」 : 」 (ユーザ名値)unq(分野値) 」 : 」 passwd)をunqする、」、:、」 「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
これはその後の要求と応答の各「認証セッション」のために異なった認証のための'セッションキー'を作成します、その結果、どんなキーでも論じ尽くされた材料の量を制限します。 (注意: 中で認証セッションのさらなる議論を見てください。
Franks, et al. Standards Track [Page 13] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[13ページ]。
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値を作成するのにユーザ資格証明書のハッシュを使用するだけでよいので、ウェブサーバーが実際のパスワード値を必要としないように、第三者認証サービスに関連してこの工事を使用できました。 そのようなプロトコルの仕様はこの仕様の範囲を超えています。
3.2.2.3 A2
3.2.2.3 A2
If the "qop" directive's value is "auth" or is unspecified, then A2 is:
"qop"指示の値が"auth"であるか不特定であるなら、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(実体本体)
3.2.2.4 Directive values and quoted-string
3.2.2.4 指示の値と引用文字列
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
ユーザ名="Mufasa"、分野= 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.
そして、ユーザMufasaには、「寿命の円」というパスワードがあって、次に、H(A1)は読みこなされたストリングの引用符がなければH(Mufasa: myhost@testrealm.com :円のOf Life)でしょう。
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
寿命のMufasa: 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
また、保全保護が適用されているなら(qop=auth-int)、H(実体本体)がメッセージ本体ではなく、実体本体のハッシュであることに注意してください--どんな転送コード化も送付者によって適用される前にそれは計算されます。
Franks, et al. Standards Track [Page 14] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[14ページ]。
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.
そして、後に、それは受取人によって取り除かれました。 これがどんな複合content typeの各部分にも複合境界と埋め込まれたヘッダーを含んでいることに注意してください。
3.2.2.5 Various considerations
3.2.2.5 様々な問題
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です。 これは、セクション5.1.2で、[2]の「*」、"absoluteURL"または指定されるとして「腹筋_経路」であるかもしれませんが、それは要求URIに同意しなければなりません。 Request-URIが"absoluteURL"であるなら、それは特に、"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.
リソースがRequest-線で指定したように認証サーバは、"uri"指示で指定されたリソースが同じであることを保証しなければなりません。 それらがそうでないなら、サーバSHOULDは400Bad Request誤りを返します。 (サーバimplementersは、これが攻撃の兆候であるかもしれないので、そのような誤りを登録すると考えたがっているかもしれません。) この分野で要求URLから情報を二重化する目的は中間的プロキシがクライアントのRequest-線を変更するかもしれない可能性に対処することです。 この変更されて(おそらく意味的に同等)の要求はクライアントによるそんなに計算されるのと同じダイジェストをもたらさないでしょう。
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.
Implementersは認証されたトランザクションがどう共有されたキャッシュと対話するかを意識しているべきです。 [2])のセクション13.7がその要求をリレーするのからAuthorizationヘッダーと応答を含む要求を受け取ったのを確実にしてください、そして、回答としてその応答をいかなる他の要求にも返してはいけません、2の1つがCache制御されないなら。共有されたキャッシュであるときに、HTTP/1.1プロトコルがそれを指定する、((セクション14.9の[2])指示が応答で存在していたのを確実にしてください。 しかし、その後の要求に答えることにおける、その応答の実体がそうしなければならない使用が最初に、それを再有効にしますように。応答はオリジナルであるなら「必須-revalidate」Cache-コントロール指示を含んでいました、キャッシュ、発生源サーバが新しい要求を認証するのを許容するという新しい要求から要求ヘッダーを使用する発生源サーバで。 あるいはまた、オリジナルの応答が「公共」のCache-コントロール指示を含んでいたなら、応答実体はどんなその後の要求に対して返されるかもしれません。
3.2.3 The Authentication-Info Header
3.2.3 認証インフォメーションヘッダー
The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response.
Authentication-インフォメーションヘッダーはサーバによって使用されて、応答におけるうまくいっている認証の何らかの情報を伝えます。
Franks, et al. Standards Track [Page 15] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[15ページ]。
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 <">
「AuthenticationInfoは「認証インフォメーション」と等しい」:、」 1#nextnonce| ([メッセージ-qop]| [応答-auth]| [cnonce]| [一回だけのカウント])nextnonce="nextnonce"「=」一回だけの値の応答-auth="rspauth"「=」応答ダイジェスト応答auth-インフォメーションauth-インフォメーション=ダイジェストが<と等しい、「>*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指示の値は今後の認証応答に使用するサーバがクライアントが必要である一回だけです。 サーバは一回だけを変えながら1回である、またはそうでない状態で実装する手段としてnextnonce分野があるAuthentication-インフォメーションヘッダーを送るかもしれません。 次の要求のためにAuthorizationヘッダーを組み立てるとき、nextnonce分野が存在しているなら、クライアントSHOULDはそれを使用します。 クライアントがそうしない場合、「= 本当に古くさくなってください」でサーバから再認証する要求をもたらすかもしれません。
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指示を含んでいるなら、pipelined要求は可能にならないでしょう。性能対古い一回だけの値が要求パイプライン処理を可能にする限られた時間使用されるのを許容するセキュリティ見返りに対して考慮を払うべきです。 一回だけのカウントの使用は有害のない新しいサーバ一回だけの利点がパイプライン処理で影響するセキュリティの大部分を保有できます。
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.
「保護の品質」オプションが. 値の"auth"が示すサーバで応答に適用したメッセージ-qop Indicates認証。 値の"auth-int"は保全保護で認証を示します。 サーバSHOULDは対応する要求でクライアントによって送られた応答におけるメッセージ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に供給すると立証します。 「応答ダイジェスト」値は、「要求ダイジェスト」のようにAuthorizationヘッダーで計算されるか、"qop=auth"であるならそれを除くか、またはAuthorizationヘッダーで要求に指定されないで、A2はそうです。
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(実体本体)
Franks, et al. Standards Track [Page 16] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[16ページ]。
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.
Authentication-インフォメーションヘッダーはchunked転送コード化を通して移されたHTTPメッセージのトレーラに許容されています。
3.3 Digest Operation
3.3 ダイジェスト操作
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サーバが実際にユーザのcleartextパスワードを知る必要はないことに注意してください。 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.
aは挑戦を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
クライアントがセッションの持続時間のためにサーバによってそれに与えられた不透明な指示の値を返さなければならないので、不明瞭なデータは認証セッション州の情報を輸送するのに使用されるかもしれません。 (また、一回だけに状態を含んでいることによって、より簡単に安全にどんなそのような使用も実行できることに注意してください。) 例えば、サーバは実際に別のサーバに座る内容を認証するのに原因となるかもしれません。最初の401応答に2番目のサーバに値がURIを含んでいるドメイン指示を含ませることによって、これを達成するでしょう、そして、不透明な指示は値を達成します。
Franks, et al. Standards Track [Page 17] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[17ページ]。
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.
州の情報を含んでいます。 クライアントは要求を再試行するでしょう、2番目のサーバにURIを示して。クライアントは、リダイレクションの後をつけて、Authorizationヘッダーを渡すでしょう、<の不明瞭な>データを含んでいて。(サーバはその時に要求のために301/302リダイレクションで反応するかもしれません)。
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.
基本的な体系なら、プロキシはDigestアクセス認証体系で完全に透明でなければなりません。 すなわち、前方にそうしなければならない、WWW認証、Authentication-インフォメーションとAuthorizationヘッダー、触れません。 要求をサーバに転送する前にプロキシがクライアントを認証したいなら、Proxyが認証する使用と下のセクション3.6で説明されたProxy-承認ヘッダーにそれができます。
3.4 Security Protocol Negotiation
3.4 セキュリティ議定書交渉
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.
サーバが認証方法としてDigestを必要としたがっているのは、可能です、サーバが、クライアントがそれをサポートするのを知らないでも。 サーバがそれが扱うことができない認証体系だけを指定するなら、クライアントが優雅に失敗するよう奨励されます。
3.5 Example
3.5 例
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 "です。 クライアントとサーバの両方がこのドキュメントのためのユーザ名が"Mufasa"であり、パスワードが「寿命の円」(それぞれの3つの単語の間には、1つのスペースがある)であると知っています。
The first time the client requests the document, no Authorization header is sent, so the server responds with:
1回目に、クライアントはドキュメントを要求します、Authorizationヘッダーを全く送りません、したがって、サーバが以下で反応します。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="testrealm@host.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
HTTP、/1.1 401権限のない、以下をWWW認証してください。 分野=" testrealm@host.com "、qop=「auth、auth-int」一回だけ=を読みこなしてください、「dcd98b7102dd2f0e8b11d0f600bfb0c093"、不透明な="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ヘッダーを含んでいて:
Franks, et al. Standards Track [Page 18] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[18ページ]。
Authorization: Digest username="Mufasa",
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
承認: ユーザ名="Mufasa"、分野=" testrealm@host.com "一回だけ=を読みこなしてください、「dcd98b7102dd2f0e8b11d0f600bfb0c093"、uri="/dir/index.html"qop=auth、nc=00000001、cnonce="0a4f113b"応答=、「6629fae49393a05397450978507c4ef1"、不透明な="5ccc069c403ebaf9f0171e9517f40e41""
3.6 Proxy-Authentication and Proxy-Authorization
3.6 プロキシ認証とプロキシ承認
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.
また、体系がプロキシ、プロキシのプロキシにユーザを認証しながら使用されるかもしれないか、または発生源サーバへのプロキシが使用する認証を読みこなす、Proxy認証、そして、Proxy-承認ヘッダー。 これらのヘッダーがインスタンスである、Proxy認証、そして、そこで説明されたHTTP/1.1仕様[2]と彼らの振舞いのセクション10.33と10.34で指定された承認ヘッダーを条件としているProxy制限。 プロキシ認証のためのトランザクションは既に説明されたものと非常に同様です。 プロキシ/サーバは、要求を受け取るときどれが認証を必要とするかを「認証が必要とした407プロキシ」応答を発行しなければなりません。aはヘッダーを「プロキシで認証します」。 ダイジェスト挑戦が中で使用した、ヘッダーをProxy認証してください、WWWのためのそれが上でセクション3.2で.1に定義されるようにヘッダーを認証するのと同じです。
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.
次に、クライアント/プロキシはProxy承認ヘッダーと共に要求を再発行しなければなりません、セクション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.
その後の応答のときに、サーバはAuthentication-インフォメーションヘッダーフィールドのためのそれらとしての指示が同じのProxy認証インフォメーションを送ります。
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 セキュリティ問題
4.1 Authentication of Clients using Basic Authentication
4.1 基本認証を使用しているクライアントの認証
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.
Basic認証体系はユーザー認証の安全なメソッドではありません、そして、それは何らかの方法で実体を保護しません。(それは、物理ネットワークの向こう側にキャリヤーとして使用されるcleartextで伝えられます)。 HTTPは増進(ワンタイムパスワードを使用する体系などの)のセキュリティか追加を増強するのに使われるのからBasic認証まで追加認証体系と暗号化メカニズムを防ぎません。
Franks, et al. Standards Track [Page 19] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[19ページ]。
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.
Basic認証における最も多くの重大な欠陥は物理ネットワークの上でユーザのパスワードの本質的にはcleartextな伝達をもたらすということです。 それは訴えるDigest Authenticationが、試みるこのその問題です。
Because Basic authentication involves the cleartext transmission of passwords it SHOULD NOT be used (without enhancements) to protect sensitive or valuable information.
Basic認証がパスワードのcleartext伝達にかかわる、それ、SHOULD NOT、使用されて(増進なしで)、敏感であるか貴重な情報を保護してください。
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.
例えば、ユーザが識別の手段として正確な用法統計をサーバに集める目的にユーザ名とパスワードを提供するのが必要であることで、Basic認証の一般の使用は識別目的のためのものです。このように使用されると、それは使用中である危険が全く保護されたドキュメントへの不法なアクセスが主要な関心事でないならないと思うのに誘惑しています。 サーバが、ユーザ名とパスワードの両方をユーザに発行して、ユーザがその人の自己のパスワードを選ぶのを特に許容しない場合にだけ、これは正しいです。 ナイーブなユーザが複数のパスワードを維持するタスクを避けるために頻繁にただ一つのパスワードを再利用するので、危険は起こります。
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.
また、基本的なAuthenticationもにせのサーバでだますのに被害を受け易いです。 ユーザが、彼が事実上、彼が敵対的なサーバかゲートウェイに接続しているときBasic認証で保護された情報を含むホストに接していると信じているように導くことができるなら、攻撃者は、パスワードを要求して、後の使用のためにそれを保存して、誤りのふりをすることができます。 このタイプの攻撃はDigest Authenticationで可能ではありません。 サーバimplementers SHOULDはゲートウェイかCGIスクリプトによるこの種類の偽物の可能性に用心します。 特に、サーバが単に接続をゲートウェイに引き渡すのは、非常に危険です。 そして、そのゲートウェイは、クライアントが検出可能でない方法でオリジナルのサーバをまねている間、多数の取引にクライアントと共に従事するのにパーシステントコネクションメカニズムを使用できます。
4.2 Authentication of Clients using Digest Authentication
4.2 ダイジェスト認証を使用しているクライアントの認証
Digest Authentication does not provide a strong authentication mechanism, when compared to public key based mechanisms, for example.
例えば、公開鍵に基づいているメカニズムと比べる場合、ダイジェストAuthenticationは強い認証機構を提供しません。
Franks, et al. Standards Track [Page 20] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[20ページ]。
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のために提案されたか。(RFC2195[9])を見てください。 はるかに弱くてさらに危険なBasicメカニズムを置き換えるのは意図しています。
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.
実際のパスワードを保護することを超えてダイジェストAuthenticationは秘密性保護を全く提供しません。 立ち聞きする者にとって、要求と応答の残りのすべてが利用可能です。
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.
ダイジェストAuthentication申し出はどちらかの方向によるメッセージのための保全保護を制限しただけです。 qop=auth-intメカニズムが使用されているなら、メッセージのそれらの部分はWWWの計算が認証するコネを使用しました、そして、Authorizationヘッダーフィールド応答指示値(セクション3.2が上であることを見る)は保護されます。 介入者攻撃の一部としてほとんどのヘッダーフィールドとそれらの値を変更できました。
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.
Digest Authenticationは安全なHTTPトランザクションの多くの需要を満たすことができません。 それらの必要性のために、TLSかSHTTPが、より適切なプロトコルです。 特に、秘密性保護を必要とするどんなトランザクションにもDigest認証を使用できません。 どのDigest認証が役に立って、かつ適切であるかので、それにもかかわらず、多くの機能が残っています。 Basicを使用する現在の使用におけるどんなサービスも同じくらいすぐ、Digestに実用的に切り換えられるべきです。
4.3 Limited Use Nonce Values
制限された4.3は一回だけの値を使用します。
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.
Digest体系は、要求ダイジェスト価値の世代をシードするのにサーバで指定された一回だけを使用します(セクション3.2.2で上の.1を指定するので)。 セクション3.2.1における例の一回だけに示されるように、サーバは特定のクライアントからそれを使用できるだけであるように無料で一回だけを組み立てることができます、特定のリソースのために、限定期間の用途の時間か数、またはいかなる他の制限のためにも。 そうするのは例えば、反射攻撃に対して提供された保護を強化します(4.5を見てください)。 しかしながら、また、一回だけを生成して、チェックするのに選ばれたメソッドが性能とリソース意味を持っていることに注意されるべきです。 例えば、サーバは、それぞれの一回だけの値があらゆる応答のAuthentication-インフォメーションヘッダーフィールドにそれぞれの最近発行された一回だけが次の一回だけ指示を返されて、送ったかどうかに関する記録を保守することによって一度だけ使用されるのを許容するのを選ぶかもしれません。 これには、即座の反射攻撃さえ守りますが、一回だけの値をチェックする高い費用があります、そして、恐らく、より重要であるのはどんなpipelined要求のためにも認証失敗を引き起こすでしょう(おそらく、聞き古した一回だけの指示を返して)。 同様に、リソースのためのEtag値などの要求特有の要素を組み込むと、一回だけの使用がリソースのそのバージョンに制限されて、また、パイプライン処理は破られます。 したがって、メソッドのために副作用でそうしますが、そうしないそれらのために容認できない性能を持っているのは役に立つかもしれません。
Franks, et al. Standards Track [Page 21] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[21ページ]。
4.4 Comparison of Digest with Basic Authentication
4.4 基本認証とのダイジェストの比較
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.
DigestとBasic Authenticationの両方がセキュリティ強さスペクトルの弱い終わりのまさしくそのいろいろな事です。 しかし、2での比較はユーティリティ、BasicをDigestに取り替えるという必要性さえ指摘します。
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.
これらのプロトコルが使用されているトランザクションのタイプへの最大の脅威はネットワーク詮索です。 この種類のトランザクションは使用が加入者に支払うのに制限されるデータベースへの例えば、オンラインのアクセスにかかわるかもしれません。 Basic認証で、立ち聞きする者はユーザのパスワードを得ることができます。 彼がデータベースの何にでもアクセスすることを許可するだけではなく、これはしばしばよりひどくユーザが同じパスワードで保護する他の何かへのアクセスを可能にするでしょう。
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.
対照的に、Digest Authenticationと共に、立ち聞きする者はユーザのパスワードではなく、問題のトランザクションへのアクセスを得るだけです。 立ち聞きする者によって獲得された情報は、反射攻撃を可能にするでしょうが、単に同じドキュメント、さらにおよびそれさえを求める要求で一回だけのサーバの選択で制限されるかもしれません。
4.5 Replay Attacks
4.5の反射攻撃
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要求には、通常、Digest認証に対する反射攻撃が無意味でしょう。 これは要求されたドキュメントのURIがクライアント要求で読みこなされて、サーバがそのドキュメントを提供するだけであるからです。 対照的に、立ち聞きする者にユーザのパスワードがいったんあると、Basic Authenticationの下では、彼にとって、そのパスワードによって保護されたどんなドキュメントも開いています。
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.
したがって、いくつかの目的に、反射攻撃から守るのが必要です。 良いDigest実装はいろいろこれができます。 サーバの作成された「一回だけ」値は実装に依存していますが、クライアント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
反射攻撃の可能性を全く許容できないアプリケーションのために、サーバは2番目の使用のために光栄に思われない1回の一回だけの値を使用できます。 これはサーバのオーバーヘッドを必要とします。
Franks, et al. Standards Track [Page 22] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[22ページ]。
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.
一回だけの時間スタンプ(したがって、ダイジェストはそれで建てられた)が期限が切れましたが、事実上、反射攻撃から守るまでどの一回だけの値が使用されたかを覚えています。
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.
実装はポストとPUT要求による反射攻撃の可能性に関する特別な注意を与えなければなりません。 サーバが1回の、または、限られた使用しているそうでなければ、一回だけを使う、そして/または、qop=auth-intの保全保護の使用を主張しない場合、攻撃者はにせのフォームデータか他のメッセージ本体でうまくいっている要求から正当な証明書を再演するかもしれません。 保全保護の使用があっても、ヘッダーフィールドにおけるほとんどのメタデータは保護されません。 適切な一回だけの世代と照合は以前中古の正当な証明書の再生に対する何らかの保護を提供しますが、4.8を見てください。
4.6 Weakness Created by Multiple Authentication Schemes
4.6 複数の認証体系によって作成された弱点
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.
多くのブラウザが、Basicを認めるだけであり、それが提示された最初のauth-体系であることを必要とすることに注意してください。 それが最少量で許容できる場合にだけ、サーバはBasicを含むべきです。
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認証してください、結果として起こる認証の強さが単にそれと同じくらい良い、最も弱い認証体系について。 複数の認証体系を利用する特定の攻撃シナリオの議論に関して下のセクション4.8を見てください。
4.7 Online dictionary attacks
4.7 オンライン辞書攻撃
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.
ユーザが辞書にあるパスワードを選択するのを許容しないことによって、サーバはこの攻撃を緩和できます。
Franks, et al. Standards Track [Page 23] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[23ページ]。
4.8 Man in the Middle
4.8 中央でやれやれ
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.
BasicとDigest認証の両方は例えば敵対的であるか感染しているプロキシからの「中央の男性」に、被害を受け易い(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.
可能な介入者攻撃は弱い認証体系を選択のセットに追加するだろうことです、クライアントがユーザの資格証明書が(例えば、パスワード)であると暴露するものを使用することを望んでいて。 この理由のために、クライアントはいつも提供された選択から理解している中で最も強い体系を使用するべきです。
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攻撃はすべての提供された選択を取り除くだろうことです、それが要求したより強い体系を使用することで認証するBasic認証から発生源サーバまでそれらをBasic認証だけを要求して、次にcleartext資格証明書を使用する挑戦に取り替えて。 そのような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つよりむしろ指名手配中である攻撃者であると偽造するかもしれません。 もちろん、これはまだBasic Authenticationに対する匹敵する攻撃より一生懸命多いです。
4.9 Chosen plaintext attacks
4.9 選ばれた平文攻撃
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].
Digest認証で、MITMか悪意があるサーバが任意に、クライアントが応答を計算するのに使用する一回だけを選ぶことができます。 これは「選ばれた平文」攻撃と呼ばれます。 一回だけを選ぶ能力が暗号文解読術をはるかに簡単な[8]にするのが知られています。
However, no way to analyze the MD5 one-way function used by Digest using chosen plaintext is currently known.
しかしながら、選ばれた平文を使用することでDigestによって使用された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"指示の使用を必要とするように構成されることです。 これで、クライアントはある意味で攻撃者によって選ばれなかったハッシュに入力を変えることができます。
Franks, et al. Standards Track [Page 24] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[24ページ]。
4.10 Precomputed dictionary attacks
4.10 Precomputed辞書攻撃
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.
Digest認証で、攻撃者が平文攻撃が選ばれたaを実行できるなら、攻撃者は、多くの一般的な語のための応答を選択の一回だけに前計算して、(応答、パスワード)組の辞書を保存できます。 多くのマシンで平行でしばしばそのような前計算ができます。 それは、次に、その挑戦に対応する応答を取得するのに選ばれた平文攻撃を使用して、ただ辞書のパスワードを調べることができます。 ほとんどのパスワードが辞書になくても、何かがあります。 攻撃者が、挑戦を選び始めるので、多くのパスワードを見つける上でリストの上の各パスワードのための応答を計算する費用を清算できます。 1億パスワード/応答組がある辞書はディスクストレージのおよそ3.2のギガバイトを取るでしょう。
The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.
クライアントが任意の使用を必要とするように構成されるためには、「cnonce」という指示にはこの攻撃に対する対策があります。
4.11 Batch brute force attacks
4.11 バッチブルートフォースアタック
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.
Digest認証で、MITMは選ばれた平文攻撃を実行できて、多くのユーザから同じ一回だけまでの応答を集めることができます。 そして、それは、シングルで一回だけ/応答組のひとりを生成するパスワードスペースのどんな部分集合の中のすべてのパスワードがそのスペースを通り過ぎるのを見つけることができます。 また、それは一回だけ/応答組の数と等しい要素による最初のパスワードが集まったのがわかる時間を短縮します。 単一マシンさえ非常にすぐにパスワードスペースの大きい部分集合を捜すことができます--多くのマシンで平行でしばしばパスワードスペースのこの検索ができます、そして、レポートは数時間後に6か、より少ない手紙ですべてのパスワードを捜すのを存在させています。
The countermeasure against this attack is to for clients to be configured to require the use of the optional "cnonce" directive.
クライアントが任意の使用を必要とするように構成されるためには、「cnonce」という指示にはこの攻撃に対する対策があります。
4.12 Spoofing by Counterfeit Servers
4.12 にせのサーバでだますこと。
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.
基本的なAuthenticationはにせのサーバでだますのに被害を受け易いです。 ユーザが、彼女がパスワードによって保護された情報を含むホストに接していると信じているように導くことができるなら、彼女は知っています、事実上、彼女が敵対的なサーバに接続していて、次に、敵対的なサーバがパスワードを要求して、後の使用のためにそれを蓄えて、誤りのふりをすることができるとき。 このタイプの攻撃はDigest Authenticationによって、より難しいです--クライアントだけが、Digest認証が使用されるのを要求するのを知らなければなりません、恐らく「中央の男性」攻撃に対抗するために上で説明されたテクニックのいくつかを使用して。 一方、ユーザでは、それぞれの体系の含意を解釈する際に適切な指導で使用中の認証機構の視覚しるしでこの攻撃を検出して、助けることができます。
Franks, et al. Standards Track [Page 25] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[25ページ]。
4.13 Storing passwords
4.13 パスワードを保存すること。
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個のDigest認証パスワードファイルが感染されるなら、同じユーザ名とパスワードで自動的に他のものに感染しないことを意味します(ブルートフォースアタックに彼らを暴露しますが)。
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.
この2番目の結果は分野ストリングがどんなシングルユーザーも使用しそうであるすべての分野の中でユニークであるべきであるということです。 特に、分野ストリングは認証をしているホストの名前を含んでいるはずです。 クライアントがサーバを認証できないことはDigest Authenticationの弱点です。
4.14 Summary
4.14 概要
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.
現代の暗号の規格で、Digest Authenticationは弱いです。 しかし、広範囲な目的のために、それはBasic Authenticationとの交換として貴重です。 それは弱点ではなく、いくらかのBasic Authenticationを治します。 実装によって、強さは異なるかもしれません。 特に、一回だけ(サーバ実装に依存している)の構造は反射攻撃を取り付ける容易さに影響するかもしれません。 例えば、いくつかの実装が、再生の可能性を排除するために1回の一回だけかダイジェストのサーバオーバーヘッドを受け入れても構わないと思っているかもしれないので、さまざまなサーバオプションが適切です。 上のお勧めのものがETagか限られた生涯があるアドレスとシングルを単一のIPに制限したように一回だけに満たされて、他のものはそうするかもしれません。
Franks, et al. Standards Track [Page 26] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[26ページ]。
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.
結論は*どんな*対応することの実装も暗号の規格で比較的弱くなりますが、*どんな*対応することの実装も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に関する例で使用される値を計算するテストプログラムであると実装します。 それはRFC1321から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
#HASHLEN16typedef炭のHASH[HASHLEN]を定義してください。 #HASHHEXLEN32typedef炭のHASHHEX[HASHHEXLEN+1]を定義してください。 #定義、IN#は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
);
/*はHTTP Digest仕様*/空間DigestCalcHA1に従ってH(A1)について計算します(IN炭*pszAlg、INが*pszUserNameを炭にします、IN炭*pszRealm、IN炭*pszPassword、IN炭*pszNonce、IN炭*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 */
);
/*はHTTP Digest仕様*/空間に従って応答要求ダイジェスト/ダイジェストについて計算します; 焦げる..一回だけ..サーバ..炭..十六進法..ケタ..炭..クライアント..一回だけ..炭..値..炭..メソッド..要求..炭..要求..URL..実体..ボディー..等しい..出かける..応答..要求..ダイジェスト..応答..ダイジェスト
File "digcalc.c":
ファイル"digcalc.c":
#include <global.h> #include <md5.h>
#<global.h>#インクルード<md5.h>を含めてください。
Franks, et al. Standards Track [Page 27] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[27ページ]。
#include <string.h> #include "digcalc.h"
#<string.h>#インクルード"digcalc.h"を含めてください。
void CvtHex(
IN HASH Bin,
OUT HASHHEX Hex
)
{
unsigned short i;
unsigned char j;
CvtHex(IN HASHビン、OUT HASHHEX Hex)を欠如させてください、未署名の短いi(未署名の炭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] = '%%BODY%%';
};
容器..十六進法..等しい..ほか..容器..十六進法..ほか '[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;
/*が仕様*/空間DigestCalcHA1に従ってH(A1)について計算する、(IN炭*pszAlg、INは*pszUserNameを炭にします、IN炭*pszRealm、IN炭*pszPassword、IN炭*pszNonce、IN炭*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(pszUserName)は(pszUserName)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszRealm)は(pszRealm)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszPassword)は(pszPassword)をstrlenします)。 MD5Final(HA1&Md5Ctx)。 (stricmp(pszAlg、"md5-sess")=0)です。
Franks, et al. Standards Track [Page 28] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[28ページ]。
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);
};
MD5Init(Md5Ctx)。 MD5Update(Md5Ctx、HA1、HASHLEN)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszNonce)は(pszNonce)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszCNonce)は(pszCNonce)をstrlenします)。 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;
/*はHTTP Digest仕様*/空間に従って応答要求ダイジェスト/ダイジェストについて計算します; 焦げる..一回だけ..サーバ..炭..十六進法..ケタ..炭..クライアント..一回だけ..炭..値..炭..メソッド..要求..炭..要求..URL..実体..ボディー..等しい..出かける..応答..要求..ダイジェスト..応答..ダイジェスト; ハッシュHA2; 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);
//はH(A2)MD5Init(Md5Ctx)について計算します。 MD5Update(Md5Ctx(pszMethod)は(pszMethod)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszDigestUri)は(pszDigestUri)をstrlenします)。 「(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) {
//は応答MD5Init(Md5Ctx)について計算します。 MD5Update(Md5Ctx、HA1、HASHHEXLEN)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszNonce)は(pszNonce)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 (*pszQop)です。
Franks, et al. Standards Track [Page 29] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[29ページ]。
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);
};
MD5Update(Md5Ctx(pszNonceCount)は(pszNonceCount)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszCNonce)は(pszCNonce)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 MD5Update(Md5Ctx(pszQop)は(pszQop)をstrlenします)。 「MD5Update、(Md5Ctx、」、:、」、1)。 }; MD5Update(Md5Ctx、HA2Hex、HASHHEXLEN)。 MD5Final(RespHash&Md5Ctx)。 CvtHex(RespHash、応答)。 };
File "digtest.c":
ファイル"digtest.c":
#include <stdio.h> #include "digcalc.h"
#<stdio.h>#インクルード"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;
炭*pszNonceは"dcd98b7102dd2f0e8b11d0f600bfb0c093""と等しいです。 炭*pszCNonceは"0a4f113b"と等しいです。 炭*pszUserは"Mufasa"と等しいです。 炭*pszRealmは" testrealm@host.com "と等しいです。 炭*pszPassは「人生の円」と等しいです。 炭*pszAlgは"md5""と等しいです。 szNonceCount[9]=「1インチ」焦げてください。 pszMethod=が「得る」炭*。 炭*pszQopは"auth"と等しいです。 炭*pszURIは"/dir/index.html"と等しいです。 HASHHEX HA1。 HASHHEX HA2が等しい、「「;」 HASHHEX応答。
DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce,
pszCNonce, HA1);
DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop,
pszMethod, pszURI, HA2, Response);
printf("Response = %s\n", Response);
};
DigestCalcHA1(pszAlg、pszUser、pszRealm、pszPass、pszNonce、pszCNonce、HA1)。 DigestCalcResponse(HA1、pszNonce、szNonceCount、pszCNonce、pszQop、pszMethod、pszURI、HA2、応答)。 printf、(「応答=%、s\n」、応答)、。 };
Franks, et al. Standards Track [Page 30] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[30ページ]。
6 Acknowledgments
6つの承認
Eric W. Sink, of AbiSource, Inc., was one of the original authors before the specification underwent substantial revision.
AbiSource Inc.、仕様がかなりの改正を受ける前にエリックW.Sinkは原作者のひとりでした。
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.Churchyard、ネッド・フリード、およびデヴィッド・M.クリストルから来ました。
Jim Gettys and Larry Masinter edited this document for update.
ジムGettysとラリー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インチ、RFC1945、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.、Gettys、J.、ムガール人、J.、Frysyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[3] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[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)は1つを分けます」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC
2246, January 1999.
[5] Dierks、T.、およびC.アレン「TLSプロトコル、バージョン1インチ、RFC2246、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への拡大:」 「ダイジェストアクセス認証」、RFC2069、1997年1月。
[7] Berners Lee, T, Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]Bernersリー、T、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、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、Sping1995、RSA Incとの通報認証」( 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は簡単な挑戦/応答のための拡大を認可する」RFC2195、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のための認証方法」が進行中で働いています。
Franks, et al. Standards Track [Page 31] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[31ページ]。
8 Authors' Addresses
8人の作者のアドレス
John Franks Professor of Mathematics Department of Mathematics Northwestern University Evanston, IL 60208-2730, USA
数学ノースウェスタン大学エバンストン、IL60208-2730(米国)の数学部のジョンフランクス教授
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.ハラム-ベイカーコンサルタントVerisign Inc.301Edgewater校長はMA 01880、スイート210ウェークフィールド米国を置きます。
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ダンラップ法廷Savoy、不-61874
EMail: jeff@AbiSource.com
メール: jeff@AbiSource.com
Scott D. Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
Inc.5Clocktowerが置くスコットD.ローレンスAgranatシステム、Suite400メイナード、MA 01754、米国
EMail: lawrence@agranat.com
メール: lawrence@agranat.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
ポールJ.リーチマイクロソフト社1マイクロソフト道、ワシントン 98052、レッドモンド(米国)
EMail: paulle@microsoft.com
メール: paulle@microsoft.com
Franks, et al. Standards Track [Page 32] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[32ページ]。
Ari Luotonen Member of Technical Staff Netscape Communications Corporation 501 East Middlefield Road Mountain View, CA 94043, USA
技術スタッフのネットスケープ社501の東Middlefield Roadマウンテンビュー、カリフォルニア 94043、米国のアリLuotonenメンバー
Lawrence C. Stewart Open Market, Inc. 215 First Street Cambridge, MA 02142, USA
通りケンブリッジ、最初に、MA 02142、ローレンスC.スチュワートオープンマーケットInc.215米国
EMail: stewart@OpenMarket.com
メール: stewart@OpenMarket.com
Franks, et al. Standards Track [Page 33] RFC 2617 HTTP Authentication June 1999
フランクス、他 規格はHTTP認証1999年6月にRFC2617を追跡します[33ページ]。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Franks, et al. Standards Track [Page 34]
フランクス、他 標準化過程[34ページ]
一覧
スポンサーリンク
