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