Network Working Group P. Leach
Request for Comments: 2831 Microsoft
Category: Standards Track C. Newman
Innosoft
May 2000
Using Digest Authentication as a SASL Mechanism
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols.
この仕様は、HTTPダイジェスト認証[ダイジェスト] SASLプロファイルを有する任意のプロトコルのSASL [RFC 2222]のメカニズムとして使用することができる方法を定義します。これは、CRAM-MD5 [RFC 2195]に比べて改善としてやWeb、メール、LDAP、および他のプロトコルのための単一の認証メカニズムをサポートする便利な方法として、両方を意図しています。
Table of Contents
目次
1 INTRODUCTION.....................................................2
1.1 CONVENTIONS AND NOTATION......................................2
1.2 REQUIREMENTS..................................................3
2 AUTHENTICATION...................................................3
2.1 INITIAL AUTHENTICATION........................................3
2.1.1 Step One...................................................3
2.1.2 Step Two...................................................6
2.1.3 Step Three................................................12
2.2 SUBSEQUENT AUTHENTICATION....................................12
2.2.1 Step one..................................................13
2.2.2 Step Two..................................................13
2.3 INTEGRITY PROTECTION.........................................13
2.4 CONFIDENTIALITY PROTECTION...................................14
3 SECURITY CONSIDERATIONS.........................................15
3.1 AUTHENTICATION OF CLIENTS USING DIGEST AUTHENTICATION........15
3.2 COMPARISON OF DIGEST WITH PLAINTEXT PASSWORDS................16
3.3 REPLAY ATTACKS...............................................16
3.4 ONLINE DICTIONARY ATTACKS....................................16
3.5 OFFLINE DICTIONARY ATTACKS...................................16
3.6 MAN IN THE MIDDLE............................................17
3.7 CHOSEN PLAINTEXT ATTACKS.....................................17
3.8 SPOOFING BY COUNTERFEIT SERVERS..............................17
3.9 STORING PASSWORDS............................................17
3.10 MULTIPLE REALMS.............................................18
3.11 SUMMARY.....................................................18
4 EXAMPLE.........................................................18
5 REFERENCES......................................................20
6 AUTHORS' ADDRESSES..............................................21
7 ABNF............................................................21
7.1 AUGMENTED BNF................................................21
7.2 BASIC RULES..................................................23
8 SAMPLE CODE.....................................................25
9 FULL COPYRIGHT STATEMENT........................................27
1 Introduction
1はじめに
This specification describes the use of HTTP Digest Access Authentication as a SASL mechanism. The authentication type associated with the Digest SASL mechanism is "DIGEST-MD5".
この仕様はSASL機構としてHTTPダイジェストアクセス認証の使用を記載しています。ダイジェストSASLメカニズムに関連した認証タイプは、「DIGEST-MD5」です。
This specification is intended to be upward compatible with the "md5-sess" algorithm of HTTP/1.1 Digest Access Authentication specified in [Digest]. The only difference in the "md5-sess" algorithm is that some directives not needed in a SASL mechanism have had their values defaulted.
この仕様は、[ダイジェスト]で指定されたHTTP / 1.1ダイジェストアクセス認証の「MD5-のSES」アルゴリズムと上位互換性があるように意図されています。 「MD5-SESの」アルゴリズムの唯一の違いは、SASLメカニズムでは必要ありませんいくつかのディレクティブは、その値がデフォルトに持っていたということです。
There is one new feature for use as a SASL mechanism: integrity protection on application protocol messages after an authentication exchange.
認証交換後のアプリケーションプロトコルメッセージの整合性の保護：SASLメカニズムとして使用するための1つの新しい機能があります。
Also, compared to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext attacks, and permits the use of third party authentication servers, mutual authentication, and optimized reauthentication if a client has recently authenticated to a server.
また、CRAM-MD5に比べ、DIGEST-MD5は、選択された平文攻撃を防ぎ、そしてクライアントが最近サーバーに認証された場合には、サードパーティの認証サーバー、相互認証、および最適化された再認証を使用することが可能になります。
This specification uses the same ABNF notation and lexical conventions as HTTP/1.1 specification; see appendix A.
この仕様は、HTTP / 1.1の仕様と同じABNF表記及び字句規則を使用します。付録Aを参照してください。
Let { a, b, ... } be the concatenation of the octet strings a, b, ...
{A、Bは、...}オクテットストリングの連結とする、B、...
Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
H（s）は、オクテットストリングSの16オクテットMD5ハッシュ[RFC 1321]とします。
Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the string k, a colon and the string s.
すなわち、文字列kの16オクテットのハッシュ、結腸および列S：KD（K、S）はH（{ ""、S K}）とします。
Let HEX(n) be the representation of the 16 octet MD5 hash n as a string of 32 hex digits (with alphabetic characters always in lower case, since MD5 is case sensitive).
（MD5は大文字と小文字が区別されるので、常に小文字アルファベット文字を有する）HEX（n）が16オクテットMD5ハッシュのN個の32進数字の文字列として表現とします。
Let HMAC(k, s) be the 16 octet HMAC-MD5 [RFC 2104] of the octet string s using the octet string k as a key.
HMAC（K、S）をキーとしてオクテットストリングkを用いてオクテット列sの16オクテットHMAC-MD5 [RFC 2104]とします。
The value of a quoted string constant as an octet string does not include any terminating null character.
オクテット文字列定数として引用符で囲まれた文字列の値は、いずれかの終端のNULL文字が含まれていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC 2119]に記載されているように解釈されます。
An implementation is not compliant if it fails to satisfy one or more of the MUST level requirements for the protocols it implements. An implementation that satisfies all the MUST level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
それが実装されたプロトコルのためのMUSTレベルの要件の一つ以上を満たすために失敗した場合、実装は準拠していません。すべてのMUSTレベルとそのプロトコルのためのすべてのSHOULDレベルの要件を満たす実装は「無条件に準拠した」と言われて。すべてのMUSTレベルの要件を満たしているが、そのプロトコルのためではない、すべてのSHOULDレベルの要件があると言われて一つの「条件付きで準拠しています。」
2 Authentication
2認証
The following sections describe how to use Digest as a SASL authentication mechanism.
次のセクションでは、SASL認証メカニズムとしてダイジェストを使用する方法について説明します。
If the client has not recently authenticated to the server, then it must perform "initial authentication", as defined in this section. If it has recently authenticated, then a more efficient form is available, defined in the next section.
クライアントは最近、サーバーに認証されていない場合、それは、このセクションで定義されているように、「初期認証」を実行する必要があります。それが最近認証されている場合は、より効率的な形式は、次のセクションで定義され、使用可能です。
The server starts by sending a challenge. The data encoded in the challenge contains a string formatted according to the rules for a "digest-challenge" defined as follows: digest-challenge = 1#( realm | nonce | qop-options | stale | maxbuf | charset algorithm | cipher-opts | auth-param )
サーバーは、チャレンジを送信することにより開始します。チャレンジでエンコードされたデータは、以下のように定義される「ダイジェストチャレンジ」の規則に従って書式設定された文字列が含まれます|ナンス| QOP-オプション|失効| MAXBUF |文字セットアルゴリズム|ダイジェストチャレンジ= 1＃（レルムを暗号OPTS |のauth-PARAM）
realm = "realm" "=" <"> realm-value <">
realm-value = qdstr-val
nonce = "nonce" "=" <"> nonce-value <">
nonce-value = qdstr-val
qop-options = "qop" "=" <"> qop-list <">
qop-list = 1#qop-value
qop-value = "auth" | "auth-int" | "auth-conf" |
token
stale = "stale" "=" "true"
maxbuf = "maxbuf" "=" maxbuf-value
maxbuf-value = 1*DIGIT
charset = "charset" "=" "utf-8"
algorithm = "algorithm" "=" "md5-sess"
cipher-opts = "cipher" "=" <"> 1#cipher-value <">
cipher-value = "3des" | "des" | "rc4-40" | "rc4" |
"rc4-56" | token
auth-param = token "=" ( token | quoted-string )
The meanings of the values of the directives used above are as follows:
以下のように使用ディレクティブの値の意味は以下のとおりです。
realm Mechanistically, a string which can enable users to know which username and password to use, in case they might have different ones for different servers. Conceptually, it is the name of a collection of accounts that might include the user's account. 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.example.com". This directive is optional; if not present, the client SHOULD solicit it from the user or be able to compute a default; a plausible default might be the realm supplied by the user when they logged in to the client system. Multiple realm directives are allowed, in which case the user or client must choose one as the realm for which to supply to username and password.
分野機構的に、使用するユーザ名とパスワードを知っているユーザーを有効にすることができた場合には、彼らは異なるサーバーに異なるものがあるかもしれません文字列。概念的には、ユーザーのアカウントが含まれる場合がありますアカウントのコレクションの名前です。この文字列は、少なくとも認証を実行するホストの名前が含まれている必要があり、さらにアクセス権を持っている可能性があるユーザーの集合を示している可能性があります。例では、「registered_users@gotham.news.example.com」かもしれません。このディレクティブはオプションです。存在しない場合、クライアントは、ユーザーからそれを求めるか、デフォルトを計算することができるべきです。もっともらしいデフォルトでは、彼らは、クライアントシステムにログインしたときに、ユーザーによって提供される分野であるかもしれません。複数のレルムディレクティブは、ユーザーまたはクライアントがユーザ名とパスワードを供給するためのレルムとして1を選択する必要があり、その場合には、許可されています。
nonce A server-specified data string which MUST be different each time a digest-challenge is sent as part of initial authentication. It is recommended that this string be base64 or hexadecimal data. Note that since the string is passed as a quoted string, the double-quote character is not allowed unless escaped (see section 7.2). The contents of the nonce are implementation dependent. The
ナンスダイジェスト・チャレンジが初期認証の一部として送信されるたびに異なるでなければならないサーバーが指定したデータ列。この文字列をbase64でまたは16進数のデータにすることをお勧めします。文字列は引用符で囲まれた文字列として渡されているので（セクション7.2を参照してください）エスケープしない限り、二重引用符文字が許可されていないことに注意してください。ナンスの内容は実装に依存しています。ザ・
security of the implementation depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy. The nonce is opaque to the client. This directive is required and MUST appear exactly once; if not present, or if multiple instances are present, the client should abort the authentication exchange.
実装のセキュリティは良い選択に依存します。エントロピーの少なくとも64ビットを含むことが推奨されます。ナンスは、クライアントには不透明です。このディレクティブは必須であり、正確に一度出現しなければなりません。存在しない場合は、複数のインスタンスが存在する場合、または、クライアントが認証交換を中止すべきです。
qop-options 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; the value "auth-conf" indicates authentication with integrity protection and encryption. This directive is optional; if not present it defaults to "auth". The client MUST ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange.
QOP-オプション「保護の品質」を示す1つの以上のトークンの引用符で囲まれた文字列の値は、サーバーでサポートされています。値「AUTHは、」認証を示します。値「のauth-intが」完全性保護と認証を示します。値「のauth-confが」完全性保護と暗号化と認証を示します。このディレクティブはオプションです。 「AUTH」にデフォルト値を提示していない場合。クライアントが認識できないオプションを無視しなければなりません。クライアントは、noオプションを認識していない場合、それは認証交換を中止すべきです。
stale The "stale" directive is not used in initial authentication. See the next section for its use in subsequent authentications. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
古くなった「古い」ディレクティブは、最初の認証に使用されていません。その後の認証での使用については、次のセクションを参照してください。このディレクティブは、ほとんど一度に表示されることがあります。複数のインスタンスが存在する場合、クライアントは認証交換を中止すべきです。
maxbuf A number indicating the size of the largest buffer the server is able to receive when using "auth-int" or "auth-conf". If this directive is missing, the default value is 65536. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
最大の大きさを示す数値は、サーバが「AUTH-INT」または「AUTH-CONF」を用いた場合に受信することができるバッファMAXBUF。このディレクティブが欠落している場合、デフォルト値は65536です。このディレクティブは、最高1回表示されることがありますされます。複数のインスタンスが存在する場合、クライアントは認証交換を中止すべきです。
charset This directive, if present, specifies that the server supports UTF-8 encoding for the username and password. If not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset). The directive is needed for backwards compatibility with HTTP Digest, which only supports ISO 8859-1. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
存在する場合、このディレクティブを文字セット、サーバはユーザ名とパスワードのためのUTF-8エンコーディングをサポートすることを指定します。存在しない場合は、ユーザー名とパスワードは（US-ASCIIのサブセットとなっている）ISO 8859-1でエンコードする必要があります。ディレクティブは唯一のISO 8859-1をサポートしてHTTPダイジェスト、との後方互換性のために必要とされています。このディレクティブは、ほとんど一度に表示されることがあります。複数のインスタンスが存在する場合、クライアントは認証交換を中止すべきです。
algorithm This directive is required for backwards compatibility with HTTP Digest., which supports other algorithms. . This directive is required and MUST appear exactly once; if not present, or if multiple instances are present, the client should abort the authentication exchange.
アルゴリズムこのディレクティブは、HTTPダイジェスト。、他のアルゴリズムをサポートしているとの後方互換性のために必要とされます。 。このディレクティブは必須であり、正確に一度出現しなければなりません。存在しない場合は、複数のインスタンスが存在する場合、または、クライアントが認証交換を中止すべきです。
cipher-opts A list of ciphers that the server supports. This directive must be present exactly once if "auth-conf" is offered in the "qop-options" directive, in which case the "3des" and "des" modes are mandatory-to-implement. The client MUST ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange.
サーバーがサポートする暗号のリストを暗号付き合えません。このディレクティブは、「AUTH-confのは」、「QOP・オプション」ディレクティブで提供されている場合には、「3DES」と「DES」モードが実装に必須のある一度だけならば存在しなければなりません。クライアントが認識できないオプションを無視しなければなりません。クライアントは、noオプションを認識していない場合、それは認証交換を中止すべきです。
des the Data Encryption Standard (DES) cipher [FIPS] in cipher block chaining (CBC) mode with a 56 bit key.
DES 56ビット鍵で暗号ブロック連鎖（CBC）モードでのデータ暗号化規格（DES）の暗号[FIPS]。
3des the "triple DES" cipher in CBC mode with EDE with the same key for each E stage (aka "two keys mode") for a total key length of 112 bits.
112ビットの合計鍵長に対する各Eステージ（別名「二キーモード」）のために同じキーを持つEDEとCBCモードで「トリプルDES」暗号を3DES。
rc4, rc4-40, rc4-56 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively.
RC4、RC4-40は、それぞれ、128ビット、40ビット、および56ビット鍵でRC4暗号をrc4-56。
auth-param This construct allows for future extensions; it may appear more than once. The client MUST ignore any unrecognized directives.
この構築物は、将来の拡張が可能になりますのauth-PARAM。それが複数回表示されることがあります。クライアントが認識されないディレクティブを無視しなければなりません。
For use as a SASL mechanism, note that the following changes are made to "digest-challenge" from HTTP: the following Digest options (called "directives" in HTTP terminology) are unused (i.e., MUST NOT be sent, and MUST be ignored if received):
SASLメカニズムとして使用するために、以下の変更がHTTPから「チャレンジを消化」するために作られていますのでご注意：以下のダイジェストオプション（HTTP用語で「ディレクティブ」と呼ばれる）が使用されていない（すなわち、送ってはいけませんし、無視しなければなりません）受信の場合：
opaque domain
不透明なドメイン
The size of a digest-challenge MUST be less than 2048 bytes.
ダイジェストチャレンジのサイズ未満2048バイトでなければなりません。
The client makes note of the "digest-challenge" and then responds with a string formatted and computed according to the rules for a "digest-response" defined as follows: digest-response = 1#( username | realm | nonce | cnonce | nonce-count | qop | digest-uri | response | maxbuf | charset | cipher | authzid | auth-param )
クライアントは、「ダイジェスト・チャレンジ」のノートを作成してから、次のように定義された「ダイジェスト・レスポンス」のための規則に従って書式設定と計算された文字列で応答：ダイジェスト・レスポンス= 1＃（ユーザ名|分野|ナンス| cnonceを|ナンスカウント| QOP |ダイジェスト-URI |応答| MAXBUF |文字セット|暗号| authzidは|のauth-PARAM）
username = "username" "=" <"> username-value <">
username-value = qdstr-val
cnonce = "cnonce" "=" <"> cnonce-value <">
cnonce-value = qdstr-val
nonce-count = "nc" "=" nc-value
nc-value = 8LHEX
qop = "qop" "=" qop-value
digest-uri = "digest-uri" "=" <"> digest-uri-value <">
digest-uri-value = serv-type "/" host [ "/" serv-name ]
serv-type = 1*ALPHA
host = 1*( ALPHA | DIGIT | "-" | "." )
serv-name = host
response = "response" "=" response-value
response-value = 32LHEX
LHEX = "0" | "1" | "2" | "3" |
"4" | "5" | "6" | "7" |
"8" | "9" | "a" | "b" |
"c" | "d" | "e" | "f"
cipher = "cipher" "=" cipher-value
authzid = "authzid" "=" <"> authzid-value <">
authzid-value = qdstr-val
username The user's name in the specified realm, encoded according to the value of the "charset" directive. This directive is required and MUST be present exactly once; otherwise, authentication fails.
「文字セット」ディレクティブの値に応じてエンコードされた指定されたレルムにユーザーの名前をユーザ名。このディレクティブは必須であり、一度だけ存在する必要があります。そうでない場合、認証は失敗します。
realm The realm containing the user's account. This directive is required if the server provided any realms in the "digest-challenge", in which case it may appear exactly once and its value SHOULD be one of those realms. If the directive is missing, "realm-value" will set to the empty string when computing A1 (see below for details).
領域ユーザーのアカウントを含む領域。サーバは、それが正確に一度現れることがあり、その値は、これらのレルムのいずれかにする必要があり、その場合には、「ダイジェスト・チャレンジ」のいずれかのレルムを、提供された場合、このディレクティブは必要とされます。ディレクティブが欠落している場合はA1を計算するときに、「レルム値は」（詳細は下記参照）、空の文字列に設定します。
nonce The server-specified data string received in the preceding digest-challenge. This directive is required and MUST be present exactly once; otherwise, authentication fails.
ナンス前のダイジェストチャレンジで受信したサーバが指定したデータ列。このディレクティブは必須であり、一度だけ存在する必要があります。そうでない場合、認証は失敗します。
cnonce A client-specified data string which MUST be different each time a digest-response is sent as part of initial authentication. 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, and to provide mutual authentication. The security of the implementation depends on a good choice. It is RECOMMENDED that it contain at least 64 bits of entropy. This directive is required and MUST be present exactly once; otherwise, authentication fails.
ダイジェスト応答は、初期認証の一部として送信されるたびに異なっていなければなりませんクライアント指定されたデータ列をcnonce。 cnonce値は、クライアントによって提供され、選択平文攻撃を避けるために、相互認証を提供するために、クライアントとサーバの両方で使用される不透明な引用符で囲まれた文字列値です。実装のセキュリティは良い選択に依存します。エントロピーの少なくとも64ビットを含むことが推奨されます。このディレクティブは必須であり、一度だけ存在する必要があります。そうでない場合、認証は失敗します。
nonce-count 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 response value. This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
NC値は、クライアントがこの要求にノンス値を用いて送信した（現在の要求を含む）リクエストの数の16進数のカウントであるナンスカウント。例えば、所与のノンス値に応じて送信された最初の要求では、クライアントは「NC = 00000001」を送信します。同じNC-値が二度見された場合、その要求はリプレイである - このディレクティブの目的は、サーバーがこのカウントの独自のコピーを維持することによって、要求のリプレイを検出することができるようにすることです。応答値の建設の以下の説明を参照してください。このディレクティブは、ほとんど一度に表示されることがあります。複数のインスタンスが存在する場合、クライアントは認証交換を中止すべきです。
qop Indicates what "quality of protection" the client accepted. If present, it may appear exactly once and its value MUST be one of the alternatives in qop-options. If not present, it defaults to "auth". These values affect the computation of the response. Note that this is a single token, not a quoted list of alternatives.
QOPは、クライアントが受け入れたものを「保護の品質」を示します。存在する場合、それは一度だけ表示されることがあり、その値は、QOP、オプションで代替案の一つでなければなりません。 「AUTH」に存在しない場合は、それがデフォルトになります。これらの値は、応答の計算に影響を与えます。これは単一のトークンではなく、代替の引用されたリストであることに注意してください。
serv-type Indicates the type of service, such as "www" for web service, "ftp" for FTP service, "smtp" for mail delivery service, etc. The service name as defined in the SASL profile for the protocol see section 4 of [RFC 2222], registered in the IANA registry of "service" elements for the GSSAPI host-based service name form [RFC 2078].
プロトコル用のSASLプロファイルで定義されているSERV型は、など、Webサービスのための「WWW」、FTPサービスの「FTP」、メール配信サービスの「SMTP」、として、サービス名をサービスの種類を示しセクション4を参照してくださいGSSAPIホストベースのサービス名形式[RFC 2078]は、「サービス」要素のIANAレジストリに登録された[RFC 2222]の。
host The DNS host name or IP address for the service requested. The DNS host name must be the fully-qualified canonical name of the host. The DNS host name is the preferred form; see notes on server processing of the digest-uri.
要求されたサービスのためのDNSホスト名またはIPアドレスをホストします。 DNSホスト名は、ホストの完全修飾正規の名前でなければなりません。 DNSホスト名は好ましい形態です。ダイジェスト-URIのサーバ処理上のノートを参照してください。
serv-name Indicates the name of the service if it is replicated. The service is considered to be replicated if the client's service-location process involves resolution using standard DNS lookup operations, and if these operations involve DNS records (such as SRV, or MX) which resolve one DNS name into a set of other DNS names. In this case, the initial name used by the client is the "serv-name", and the final name is the "host" component. For example, the incoming mail service for "example.com" may be replicated through the use of MX records stored in the DNS, one of which points at an SMTP server called "mail3.example.com"; it's "serv-name" would be "example.com", it's "host" would be "mail3.example.com". If the service is not replicated, or the serv-name is identical to the host, then the serv-name component MUST be omitted.
それが複製されている場合SERV-nameはサービスの名前を示します。サービスは、クライアントのサービス・ロケーション・プロセスは、標準的なDNSルックアップ操作を使用して解像度を必要とする場合は、複製されたと見なされており、これらの操作は、他のDNS名のセットに1つのDNS名を解決（たとえば、SRV、またはMXなど）DNSレコードを伴う場合。この場合、クライアントが使用する最初の名前は「SERV-名」であり、最終的な名前は、「ホスト」コンポーネントです。 「example.com」「mail3.example.com」と呼ばれるSMTPサーバを指し一つは、DNSに格納されたMXレコードの使用を介して複製することができるため、例えば、受信メールサービス。それは「SERV-nameは」「example.com」になり、それが「mail3.example.com」だろう「ホスト」だのです。サービスが複製されていない、またはSERV-nameがホストと同一である場合には、SERV名コンポーネントが省略されなければなりません。
digest-uri Indicates the principal name of the service with which the client wishes to connect, formed from the serv-type, host, and serv-name. For example, the FTP service on "ftp.example.com" would have a "digest-uri" value of "ftp/ftp.example.com"; the SMTP server from the example above would have a "digest-uri" value of "smtp/mail3.example.com/example.com".
ダイジェスト-URI SERV型、ホスト、およびSERV-名から形成され、クライアントが接続を希望するとサービスのプリンシパル名を指定します。たとえば、「ftp.example.com」のFTPサービスでは、「FTP / ftp.example.com」の「ダイジェスト-URI」の値を持っているでしょう。上記の例からのSMTPサーバーは、「SMTP / mail3.example.com / example.com」の「ダイジェスト-URI」の値を持っているでしょう。
Servers SHOULD check that the supplied value is correct. This will detect accidental connection to the incorrect server. It is also so that clients will be trained to provide values that will work with implementations that use a shared back-end authentication service that can provide server authentication.
サーバは指定された値が正しいことを確認する必要があります。これは間違ったサーバーへ誤って接続を検出します。クライアントがサーバー認証を提供することができ、共有バックエンドの認証サービスを使用する実装で動作する値を提供するように訓練されるように、それはまたです。
The serv-type component should match the service being offered. The host component should match one of the host names of the host on which the service is running, or it's IP address. Servers SHOULD NOT normally support the IP address form, because server authentication by IP address is not very useful; they should only do so if the DNS is unavailable or unreliable. The serv-name component should match one of the service's configured service names.
SERV型コンポーネントが提供されるサービスと一致する必要があります。ホストコンポーネントは、サービスが動作しているホストのホスト名のいずれかと一致する必要があります、またはそれはIPアドレスです。 IPアドレスによるサーバー認証は非常に有用ではありませんので、サーバは通常、IPアドレスの形式をサポートするべきではありません。 DNSが使用できないか、信頼できない場合、彼らは唯一そうする必要があります。 SERV-名コンポーネントは、サービスの設定されたサービス名のいずれかと一致する必要があります。
This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
このディレクティブは、ほとんど一度に表示されることがあります。複数のインスタンスが存在する場合、クライアントは認証交換を中止すべきです。
Note: In the HTTP use of Digest authentication, the digest-uri is the URI (usually a URL) of the resource requested -- hence the name of the directive.
注意：ダイジェスト認証のHTTPの使用では、ダイジェスト-URIが要求されたリソースのURI（通常はURL）である - ディレクティブの名前の由来。
response A string of 32 hex digits computed as defined below, which proves that the user knows a password. This directive is required and MUST be present exactly once; otherwise, authentication fails.
ユーザがパスワードを知っていることを証明以下に定義されるように計算された32進数の文字列を、応答。このディレクティブは必須であり、一度だけ存在する必要があります。そうでない場合、認証は失敗します。
maxbuf A number indicating the size of the largest buffer the client is able to receive. If this directive is missing, the default value is 65536. This directive may appear at most once; if multiple instances are present, the server should abort the authentication exchange.
最大の大きさを示す数値は、クライアントが受信することができるバッファMAXBUF。このディレクティブが欠落している場合、デフォルト値は65536です。このディレクティブは、最高1回表示されることがありますされます。複数のインスタンスが存在する場合、サーバーは認証交換を中止すべきです。
charset This directive, if present, specifies that the client has used UTF-8 encoding for the username and password. If not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset). The client should send this directive only if the server has indicated it supports UTF-8. The directive is needed for backwards compatibility with HTTP Digest, which only supports ISO 8859-1.
存在する場合、クライアントはユーザ名とパスワードの入力をUTF-8エンコーディングを使用していることを指定し、このディレクティブを文字セット。存在しない場合は、ユーザー名とパスワードは（US-ASCIIのサブセットとなっている）ISO 8859-1でエンコードする必要があります。クライアントは、サーバがUTF-8をサポートして示している場合にのみ、このディレクティブを送信する必要があります。ディレクティブは唯一のISO 8859-1をサポートしてHTTPダイジェスト、との後方互換性のために必要とされています。
LHEX 32 hex digits, where the alphabetic characters MUST be lower case, because MD5 is not case insensitive.
アルファベット文字は小文字でなければなりませんLHEX 32進数字、MD5は、大文字小文字を区別しないからです。
cipher The cipher chosen by the client. This directive MUST appear exactly once if "auth-conf" is negotiated; if required and not present, authentication fails.
クライアントが選択した暗号を暗号化。このディレクティブは正確に一度「のauth-confのは」交渉されている場合に表示されなければなりません。必要と存在しない場合、認証は失敗します。
authzid The "authorization ID" as per RFC 2222, encoded in UTF-8. This directive is optional. If present, and the authenticating user has sufficient privilege, and the server supports it, then after authentication the server will use this identity for making all accesses and access checks. If the client specifies it, and the server does not support it, then the response-value will be incorrect, and authentication will fail.
UTF-8でエンコードされたRFC 2222あたりとして "認証ID" を、authzidは。このディレクティブはオプションです。現在、および認証ユーザーが十分な権限を持っているし、サーバーがサポートしている場合、認証後にサーバがすべてのアクセスとアクセスのチェックを行うため、このIDを使用します。クライアントは、それを指定し、サーバはそれをサポートしていない場合は、応答値が不正確になり、認証が失敗します。
The size of a digest-response MUST be less than 4096 bytes.
ダイジェスト応答の大きさは、4096バイト未満でなければなりません。
The definition of "response-value" above indicates the encoding for its value -- 32 lower case hex characters. The following definitions show how the value is computed.
32下部ケース六角文字 - 上記「応答値」の定義は、その値の符号化を示しています。以下の定義は、値が計算される方法を示しています。
Although qop-value and components of digest-uri-value may be case-insensitive, the case which the client supplies in step two is preserved for the purpose of computing and verifying the response-value.
QOP値とダイジェスト-URI値のコンポーネントは大文字と小文字を区別しない、ステップ2において、クライアントの供給は、コンピューティングの目的と応答値を検証するために保存されている場合であってもよいが。
response-value =
応答値=
HEX( KD ( HEX(H(A1)), { nonce-value, ":" nc-value, ":", cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
HEX（KD（HEX（H（A1））、{ノンス値、 "：" NC-値、 "："、cnonce値、 "："、QOP値、 "："、HEX（H（A2） ）}））
If authzid is specified, then A1 is
authzidはが指定されている場合、A1は、
A1 = { H( { username-value, ":", realm-value, ":", passwd } ), ":", nonce-value, ":", cnonce-value, ":", authzid-value }
A1 = {H（{ユーザー名値、 "："、レルム値、 "：" は、passwd}）、 "："、ノンス値、 "："、cnonce値、 "："、authzidは、値}
If authzid is not specified, then A1 is
authzidはを指定しない場合、A1は、
A1 = { H( { username-value, ":", realm-value, ":", passwd } ), ":", nonce-value, ":", cnonce-value }
A1 = {H（{ユーザー名値、 "："、レルム値、 "：" は、passwd}）、 "："、ノンス値、 "："、cnonce値}
where
どこ
passwd = *OCTET
passwdの= * OCTET
The "username-value", "realm-value" and "passwd" are encoded according to the value of the "charset" directive. If "charset=UTF-8" is present, and all the characters of either "username-value" or "passwd" are in the ISO 8859-1 character set, then it must be converted to ISO 8859-1 before being hashed. This is so that authentication databases that store the hashed username, realm and password (which is common) can be shared compatibly with HTTP, which specifies ISO 8859-1. A sample implementation of this conversion is in section 8.
「ユーザ名値」、「レルム値」および「passwdの」は、「文字セット」指令の値に応じて符号化されます。 ISO 8859-1文字セットである「文字セットは= UTF-8」が存在し、いずれかの「ユーザ名・値」または「passwdの」のすべての文字ならば、それはハッシュ化される前に、ISO 8859-1に変換する必要があります。これは（一般的である）ハッシュ化されたユーザ名、レルムとパスワードを保存するので、認証データベースであるISO 8859-1を指定するHTTP、との互換共有することができます。この変換のサンプル実装がセクション8です。
If the "qop" directive's value is "auth", then A2 is:
「QOP」ディレクティブの値が「認証」であれば、A2は次のようになります。
A2 = { "AUTHENTICATE:", digest-uri-value }
A2 = { "認証："、ダイジェスト-URI値を}
If the "qop" value is "auth-int" or "auth-conf" then A2 is:
「QOP」の値が「AUTH-INT」または「AUTH-confの」であれば、A2は以下のとおりです。
A2 = { "AUTHENTICATE:", digest-uri-value, ":00000000000000000000000000000000" }
A2 = { "AUTHENTICATE："、ダイジェスト-URI値、 "00000000000000000000000000000000"}
Note that "AUTHENTICATE:" must be in upper case, and the second string constant is a string with a colon followed by 32 zeros.
大文字である必要があり、かつ一定の第2のストリングは、32個のゼロに続くコロンの文字列である「認証」ことに留意されたいです。
These apparently strange values of A2 are for compatibility with HTTP; they were arrived at by setting "Method" to "AUTHENTICATE" and the hash of the entity body to zero in the HTTP digest calculation of A2.
A2のこれらの一見奇妙な値は、HTTPとの互換性のためのものです。彼らは、A2の計算をダイジェストHTTPゼロに「認証」とエンティティボディのハッシュに「メソッド」を設定することでに到着されました。
Also, in the HTTP usage of Digest, several directives in the
また、ダイジェストのHTTPの使用、のいくつかのディレクティブで
"digest-challenge" sent by the server have to be returned by the client in the "digest-response". These are:
サーバーから送信された「ダイジェストチャレンジ」は「ダイジェスト応答」に、クライアントによって返される必要があります。これらは：
opaque algorithm
不透明なアルゴリズム
These directives are not needed when Digest is used as a SASL mechanism (i.e., MUST NOT be sent, and MUST be ignored if received).
ダイジェストは、SASL機構として使用される（即ち、送信してはいけません、受信した場合は無視する必要がある）場合、これらの指令は必要とされません。
The server receives and validates the "digest-response". The server checks that the nonce-count is "00000001". If it supports subsequent authentication (see section 2.2), it saves the value of the nonce and the nonce-count. It sends a message formatted as follows:
サーバが受信して、「ダイジェスト・レスポンス」を検証します。サーバーは、ナンスカウントが「00000001」であることを確認します。それは（セクション2.2を参照）、その後の認証をサポートしている場合、それはナンスの値とナンスカウントを保存します。それは次のようにフォーマットされたメッセージを送信します。
response-auth = "rspauth" "=" response-value
応答-AUTH = "rspauth" "=" 応答値
where response-value is calculated as above, using the values sent in step two, except that if qop is "auth", then A2 is
応答値はQOPが「認証」である場合、A2であることを除いて、ステップ2で送信された値を使用して、上記のように計算されます
A2 = { ":", digest-uri-value }
A2 = { "："、ダイジェスト-URI値を}
And if qop is "auth-int" or "auth-conf" then A2 is
QOPは "AUTH-INT" または "AUTH-confの" であれば、その後、A2があります
A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
A2 = { "："、ダイジェスト-URI値、 "00000000000000000000000000000000"}
Compared to its use in HTTP, the following Digest directives in the "digest-response" are unused:
HTTPでの使用と比較すると、「ダイジェスト・レスポンス」で、次のダイジェストディレクティブが使用されていません。
nextnonce
qop
cnonce
nonce-count
If the client has previously authenticated to the server, and remembers the values of username, realm, nonce, nonce-count, cnonce, and qop that it used in that authentication, and the SASL profile for a protocol permits an initial client response, then it MAY perform "subsequent authentication", as defined in this section.
クライアントは、以前のサーバに認証し、ユーザ名、分野、ナンス、ナンスカウント、cnonceの値を覚えて、それがその認証に使用することQOP、およびプロトコルのSASLプロファイルは、その後、最初のクライアント応答を許可している場合このセクションで定義されたそれは、「以降の認証」を実行するかもしれません。
The client uses the values from the previous authentication and sends an initial response with a string formatted and computed according to the rules for a "digest-response", as defined above, but with a nonce-count one greater than used in the last "digest-response".
クライアントは、以前の認証からの値を使用して、上記で定義した通り、「ダイジェスト応答」の規則に従ってフォーマットされ、計算された文字列で初期応答を送信するが、ナンスカウントと最後で使用されるより1大きいです」 「応答を消化。
The server receives the "digest-response". If the server does not support subsequent authentication, then it sends a "digest-challenge", and authentication proceeds as in initial authentication. If the server has no saved nonce and nonce-count from a previous authentication, then it sends a "digest-challenge", and authentication proceeds as in initial authentication. Otherwise, the server validates the "digest-response", checks that the nonce-count is one greater than that used in the previous authentication using that nonce, and saves the new value of nonce-count.
サーバーは、「ダイジェスト・レスポンス」を受信します。サーバは、その後の認証をサポートしていない場合、それは「ダイジェストチャレンジ」を送信し、認証は初期の認証のように進行します。サーバが以前の認証からの保存されたナンスとナンスカウントを持っていない場合、それは初期の認証のように、「ダイジェストチャレンジ」を送信し、認証を進めます。そうしないと、サーバは「応答ダイジェスト」、ナンス・カウントがそのnonceを使用して以前の認証に使用されるよりも1大きいことを確認し検証し、ナンスカウントの新しい値を保存します。
If the response is invalid, then the server sends a "digest-challenge", and authentication proceeds as in initial authentication (and should be configurable to log an authentication failure in some sort of security audit log, since the failure may be a symptom of an attack). The nonce-count MUST NOT be incremented in this case: to do so would allow a denial of service attack by sending an out-of-order nonce-count.
応答が無効である場合、サーバーは、「ダイジェストチャレンジ」を送信し、認証を進める最初の認証のように（と失敗がの症状かもしれないので、セキュリティ監査ログのいくつかの並べ替えに認証失敗をログに記録するように設定する必要があります攻撃）。ナンスカウントは、この場合にはインクリメントされてはならない。そうするために、アウトオブオーダーナンスカウントを送信することにより、サービス拒否攻撃が可能になります。
If the response is valid, the server MAY choose to deem that authentication has succeeded. However, if it has been too long since the previous authentication, or for any other reason, the server MAY send a new "digest-challenge" with a new value for nonce. The challenge MAY contain a "stale" directive with value "true", which says that the client may respond to the challenge using the password it used in the previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except for the handling of "stale", after sending the "digest-challenge" authentication proceeds as in the case of initial authentication.
応答が有効な場合、サーバーは認証が成功したものとみなすのを選ぶかもしれ。それは以前の認証以降、またはその他の理由のためにあまりにも長い間されている場合は、サーバーはナンスのための新しい値を持つ新しい「ダイジェストチャレンジ」を送るかもしれません。課題は、クライアントが以前の応答に使用されるパスワードを使用しての挑戦に応答することができると述べている値「真」と「古い」ディレクティブを含むことができます。そうでない場合、クライアントは、ユーザから新たにパスワードを要求しなければなりません。これは、ユーザーが最近、自分のパスワードを提示したことを確認するためにサーバーを許可します。 （ディレクティブ名は、以前のnonceが古くなったことに、ないパスワードの最後の使用をいう。）「古い」の取り扱いを除き、初期認証の場合のように、「ダイジェストチャレンジを」認証進行を送信した後。
If the server offered "qop=auth-int" and the client responded "qop=auth-int", then subsequent messages, up to but not including the next subsequent authentication, between the client and the server
サーバーは、「QOP =のauth-int型」提供され、次回以降の認証を含めないまでが、クライアントは、クライアントとサーバーの間で、その後、「QOP =のauth-INT」、後続のメッセージを応答した場合
MUST be integrity protected. Using as a base session key the value of H(A1) as defined above the client and server calculate a pair of message integrity keys as follows.
完全性保護されなければなりません。次のようにクライアントとサーバー上で定義されたように、ベースセッション鍵としてH（A1）の値を使用して、メッセージの完全性キーのペアを計算します。
The key for integrity protecting messages from client to server is:
クライアントからサーバへのメッセージを完全性保護のためのキーは、次のとおりです。
Kic = MD5({H(A1), "Digest session key to client-to-server signing key magic constant"})
KICは= MD5（{H（A1）、「クライアントからサーバーへの署名キー魔法定数にダイジェストセッションキー」}）
The key for integrity protecting messages from server to client is:
サーバからクライアントへのメッセージを完全性保護のためのキーは、次のとおりです。
Kis = MD5({H(A1), "Digest session key to server-to-client signing key magic constant"})
KIS = MD5（{H（A1）、「サーバーからクライアントへの署名キー魔法定数にダイジェストセッションキー」}）
where MD5 is as specified in [RFC 1321]. If message integrity is negotiated, a MAC block for each message is appended to the message. The MAC block is 16 bytes: the first 10 bytes of the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number in network byte order with value 1, and the 4-byte sequence number in network byte order. The message type is to allow for future extensions such as rekeying.
MD5は、[RFC 1321]で指定されるようです。メッセージの整合性がネゴシエートされている場合、各メッセージのMACブロックは、メッセージに添付されています。ネットワークバイト順でメッセージ、値1、及び4バイトのシーケンス番号を有するネットワークバイト順に2バイトのメッセージタイプ番号のHMAC-MD5 [RFC 2104]の最初の10バイト：MACブロックは16バイトであります。メッセージタイプは、キーの再発行など、将来の拡張を可能にすることです。
MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001, SeqNum)
MAC（KI、SEQNUM、MSG）=（HMAC（KI、{SEQNUM、MSG}）[0..9]、0x0001の、SEQNUM）
where Ki is Kic for messages sent by the client and Kis for those sent by the server. The sequence number is initialized to zero, and incremented by one for each message sent.
どこKiは、サーバによって送信されたもののために、クライアントとキシュによって送信されるメッセージのKICです。シーケンス番号はゼロに初期化され、送信されるメッセージごとに1だけインクリメントされます。
Upon receipt, MAC(Ki, SeqNum, msg) is computed and compared with the received value; the message is discarded if they differ.
受信すると、MAC（KI、SEQNUM、MSG）を計算し、受信した値と比較されます。それらが異なる場合は、メッセージが破棄されます。
If the server sent a "cipher-opts" directive and the client responded with a "cipher" directive, then subsequent messages between the client and the server MUST be confidentiality protected. Using as a base session key the value of H(A1) as defined above the client and server calculate a pair of message integrity keys as follows.
サーバは、「暗号OPTS」ディレクティブを送信し、クライアントは「暗号」ディレクティブで応答した場合、クライアントとサーバの間のその後のメッセージは、機密保護されなければなりません。次のようにクライアントとサーバー上で定義されたように、ベースセッション鍵としてH（A1）の値を使用して、メッセージの完全性キーのペアを計算します。
The key for confidentiality protecting messages from client to server is:
機密性がクライアントからサーバにメッセージを保護するための鍵は、次のとおりです。
Kcc = MD5({H(A1)[0..n], "Digest H(A1) to client-to-server sealing key magic constant"})
KCC = MD5（{H（A1）[0..N]、 "ダイジェストH（A1）は、クライアントからサーバーへのシールキー魔法定数に"}）
The key for confidentiality protecting messages from server to client is:
サーバからクライアントへのメッセージを保護する機密保持のためのキーは、次のとおりです。
Kcs = MD5({H(A1)[0..n], "Digest H(A1) to server-to-client sealing key magic constant"})
KCS = MD5（{H（A1）[0..N]、 "ダイジェストH（A1）サーバからクライアントへのシールキー魔法定数に"}）
where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for "rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers is all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the key for "3des" is the first 14 bytes. The IV for "des" and "3des" is the last 8 bytes of Kcc or Kcs.
MD5は、[RFC 1321]で指定されるようです。暗号は、「RC4-40」nが5です。 「rc4-56」Nは7です。残りのnの「RC-*」暗号の鍵はKccをまたはKCSの全16バイトで16です。 「DES」のためのキーは、最初の7バイトです。 「3DES」のためのキーは、最初の14バイトです。 「DES」と「3DES」のためのIVは、KccをまたはKCSの最後の8バイトです。
If message confidentiality is negotiated, each message is encrypted with the chosen cipher and a MAC block is appended to the message.
メッセージの機密性がネゴシエートされている場合、各メッセージは、選択された暗号を用いて暗号化され、MACブロックは、メッセージに添付されています。
The MAC block is a variable length padding prefix followed by 16 bytes formatted as follows: the first 10 bytes of the HMAC-MD5 [RFC 2104] of the message, a 2-byte message type number in network byte order with value 1, and the 4-byte sequence number in network byte order. If the blocksize of the chosen cipher is not 1 byte, the padding prefix is one or more octets each containing the number of padding bytes, such that total length of the encrypted part of the message is a multiple of the blocksize. The padding and first 10 bytes of the MAC block are encrypted along with the message.
MACブロックは、次のようにフォーマットされた16バイトに続く可変長のパディング接頭辞である：メッセージのHMAC-MD5 [RFC 2104]の最初の10バイト、値1を持つネットワークバイト順の2バイトのメッセージタイプ番号を、及びネットワークバイト順で4バイトのシーケンス番号。選択された暗号のブロックサイズが1つのバイトでない場合、パディングプレフィックスは、一個の以上のオクテットメッセージの暗号化された部分の合計の長さがブロックサイズの倍数になるようにパディングバイトの数を含む各あります。パディングとMACブロックの最初の10のバイトは、メッセージと共に暗号化されています。
SEAL(Ki, Kc, SeqNum, msg) = {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001, SeqNum}
SEAL（KI、Kcを、SEQNUM、MSG）= {CIPHER（Kcを、{MSG、パッド、HMAC（KI、{SEQNUM、MSG}）[0..9]）}）、0x0001の、SEQNUM}
where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for messages sent by the client and Kis and Kcs for those sent by the server. The sequence number is initialized to zero, and incremented by one for each message sent.
CIPHERは、選択された暗号であり、のKiとKcがKICとKCCはサーバーによって送信されたもののために、クライアントとキシュとKCSによって送信されたメッセージのためのものです。シーケンス番号はゼロに初期化され、送信されるメッセージごとに1だけインクリメントされます。
Upon receipt, the message is decrypted, HMAC(Ki, {SeqNum, msg}) is computed and compared with the received value; the message is discarded if they differ.
受信すると、メッセージが復号化され、HMAC（KI、{SEQNUM、MSGは}）を計算し、受信した値と比較されます。それらが異なる場合は、メッセージが破棄されます。
3 Security Considerations
3つのセキュリティの考慮事項
Digest Authentication does not provide a strong authentication mechanism, when compared to public key based mechanisms, for example. However, since it prevents chosen plaintext attacks, it is 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 use of plaintext passwords; however, since it is still a password based mechanism it avoids some of the potential deployabilty issues with public-key, OTP or similar mechanisms.
公開鍵ベースの機構と比較した場合、ダイジェスト認証は、例えば、強力な認証メカニズムを提供しません。しかし、選択平文攻撃を防止するため、それは（例えば）CRAM-MD5 LDAPで使用するために提案されている、[10]、POPおよびIMAPよりも強い（[9] RFC 2195を参照）。平文パスワードのはるかに弱いとさらに危険の使用を置き換えるためのものです。それはまだ、パスワードベースのメカニズムであるため、しかし、それは、公開鍵、OTPまたは類似のメカニズムの潜在的なdeployabiltyの問題のいくつかを回避することができます。
Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the challenge and response are available to an eavesdropper, including the user's name and authentication realm.
ダイジェスト認証は、実際のパスワードを保護する以上の機密保護を提供しています。チャレンジとレスポンスの残りのすべては、ユーザーの名前と認証領域を含め、盗聴者に利用可能です。
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 mail service whose use is restricted to paying subscribers. With plaintext password 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.
これらのプロトコルが使用されるトランザクションの種類への最大の脅威は、ネットワークスヌーピングです。トランザクションのこの種は、例えば、使用契約者を支払うに制限されているメールサービスへのオンラインアクセスを必要とするかもしれません。平文パスワード認証では、盗聴者は、ユーザーのパスワードを取得することができます。これは、多くの場合、悪化したデータベースで何かをアクセスするために彼を許可するだけでなく、ユーザーが同じパスワードで保護何かへのアクセスを許可します。
Replay attacks are defeated if the client or the server chooses a fresh nonce for each authentication, as this specification requires.
クライアントまたはサーバが各認証のために新鮮なnonceを選択した場合は、この仕様が必要とリプレイ攻撃は、敗北しています。
If the attacker can eavesdrop, then it can test any overheard nonce/response pairs against a (potentially very large) 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.
サーバーは、ユーザーが辞書にあるパスワードを選択することができないことによって、この攻撃を軽減することができます。
If the attacker can choose the challenge, then it can precompute the possible responses to that challenge for 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 just once.
攻撃者が挑戦を選ぶことができるなら、それは一般的な単語のリストについては、その挑戦への可能な応答を事前に計算することができます。このようなリストは、通常、可能なパスワードの総数よりもはるかに小さいです。リスト上の各パスワードの応答を計算するコストは一度だけ支払われます。
Offline dictionary attacks are defeated if the client chooses a fresh nonce for each authentication, as this specification requires.
この仕様が必要なため、クライアントは、各認証のための新鮮なnonceを選択した場合、オフライン辞書攻撃は敗北しています。
Digest authentication is vulnerable to "man in the middle" (MITM) attacks. Clearly, a MITM would present all the problems of eavesdropping. But it also offers some additional opportunities to the attacker.
ダイジェスト認証は、「中間者」（MITM）攻撃に対して脆弱です。明らかに、MITMは盗聴のすべての問題を提示します。しかし、それはまた、攻撃者にいくつかの追加の機会を提供しています。
A possible man-in-the-middle attack would be to substitute a weaker qop scheme for the one(s) sent by the server; the server will not be able to detect this attack. For this reason, the client should always use the strongest scheme that it understands from the choices offered, and should never choose a scheme that does not meet its minimum requirements.
可能な中間者攻撃は、サーバによって送信された1（または複数）のためのより弱いQOPスキームを置換することであろう。サーバーは、この攻撃を検出することができません。このため、クライアントは常にそれが提供する選択肢の中から理解最強のスキームを使用する必要があり、その最小要件を満たしていないスキームを選択することはありません。
A chosen plaintext attack is where a MITM or a malicious server can arbitrarily choose the challenge that the client will use to compute the response. The ability to choose the challenge is known to make cryptanalysis much easier [8].
MITMあるいは悪意のあるサーバが任意にクライアントが応答を計算するために使用する挑戦を選択することができる場所選択平文攻撃があります。挑戦を選択する能力は、[8]暗号解読がはるかに簡単に作ることが知られています。
However, Digest does not permit the attack to choose the challenge as long as the client chooses a fresh nonce for each authentication, as this specification requires.
しかし、ダイジェストは限りこの仕様が必要なため、クライアントは、各認証のための新鮮なnonceを選ぶような課題を選択し、攻撃を許可していません。
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 obtain challenge/response pairs where it was able to partly choose the challenge. There is no known way that this can be exploited.
ユーザーは、彼女が実際に彼女が敵対的なサーバーに接続している彼女が知っているパスワードで保護された情報を含むホストに接続されていることを信じるように導くことができる場合には、敵対的なサーバはそれができたチャレンジ/レスポンスのペアを入手することができます一部の挑戦を選択してください。これが悪用されることを既知の方法はありません。
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({ username-value, ":", realm-value, ":", passwd }), which is adequate to compute H(A1) as described above without directly exposing the user's password.
ダイジェスト認証は、認証エージェント（通常はサーバー）が与えられたレルムに関連付けられ、「パスワードファイル」でユーザ名とパスワードから派生し、いくつかのデータを格納する必要があります。直接ユーザーのパスワードをさらすことなく、上述したようにH（A1）を計算するのに十分であり、通常、これは、ユーザ名及びHからなるペア（{passwdの「：」、レルム値「」ユーザ名値}）が含まれているかもしれません。
The security implications of this are that if this password file is compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say a standard UNIX password file, this information need not be decrypted in order to access documents in the server realm associated with this file. On the other hand, decryption, or more likely a brute force attack, would be necessary to obtain the user's password. This is the reason that the realm is part of the digested data stored in the password file. It means that if one Digest authentication password file is compromised, it does not automatically compromise others with the same username and password (though it does expose them to brute force attack).
このによるセキュリティへの影響は、このパスワード・ファイルが侵害された場合、攻撃者がこのレルムを使用して、サーバー上のドキュメントへの即時アクセスを得ることです。標準のUNIXパスワードファイルを言うとは異なり、この情報は、このファイルに関連付けられたサーバーレルム内のドキュメントにアクセスするためには、復号化する必要はありません。一方、復号化、またはそれ以上の可能性がブルートフォース攻撃では、ユーザーのパスワードを取得する必要があります。これは、レルムがパスワードファイルに保存されている消化されるデータの一部である理由です。これは、1つのダイジェスト認証パスワードファイルが危険にさらされている場合（これは、ブルートフォース攻撃にそれらを公開んが）、それは自動的に同じユーザー名とパスワードで他人を損なわないことを意味します。
There are two important security consequences of this. First the password file must be protected as if it contained plaintext 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 that any single user is likely to use. In particular a realm string should include the name of the host doing the authentication.
この第二の結果は、レルム文字列は、任意の単一のユーザが使用する可能性があるすべてのレルムの中で一意でなければならないということです。特に、realm文字列は、認証を行うホストの名前を含める必要があります。
Use of multiple realms may mean both that compromise of a the security database for a single realm does not compromise all security, and that there are more things to protect in order to keep the whole system secure.
複数のレルムの使用は、安全なシステム全体を維持するために保護するために、より多くのものがあること、およびすべてのセキュリティを侵害しない単一レルムのセキュリティデータベースの妥協の両方を意味するかもしれません。
By modern cryptographic standards Digest Authentication is weak, compared to (say) public key based mechanisms. But for a large range of purposes it is valuable as a replacement for plaintext passwords. Its strength may vary depending on the implementation.
現代の暗号規格でダイジェスト認証は、公開鍵ベースのメカニズム（例えば）に比べて、弱いです。しかし、目的の広い範囲のためには、平文パスワードの代替品として貴重です。その強さは、実装によって異なる場合があります。
4 Example
4例
This example shows the use of the Digest SASL mechanism with the IMAP4 AUTHENTICATE command [RFC 2060].
この例ではIMAP4 AUTHENTICATEコマンド[RFC 2060]とのダイジェストSASL機構の使用を示します。
In this example, "C:" and "S:" represent a line sent by the client or server respectively including a CRLF at the end. Linebreaks and indentation within a "C:" or "S:" are editorial and not part of the protocol. The password in this example was "secret". Note that the base64 encoding of the challenges and responses is part of the IMAP4 AUTHENTICATE command, not part of the Digest specification itself.
この例では、「C：」および「S：」は、それぞれの端部にCRLFを含むクライアントまたはサーバによって送信されたラインを表します。改行やインデント内の「C：」または「Sは、」プロトコルの編集と一部ではありません。この例では、パスワードは「秘密」でした。チャレンジとレスポンスのbase64エンコーディングはIMAP4 AUTHENTICATEコマンドの一部ではなく、ダイジェスト仕様自体の一部であることに注意してください。
S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9 C: c CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN S: c OK Completed
S：* OK elwood.innosoft.com PMDFのIMAP4rev1 V6.0-9 C：C能力S：* CAPABILITY IMAP4のIMAP4rev1 ACL LITERAL +ネームスペースクォータUIDPLUS AUTH = CRAM-MD5 AUTH = DIGEST-MD5 AUTH = PLAIN S：OK完了cは
C: a AUTHENTICATE DIGEST-MD5
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C:
S: a OK User logged in
---
The base64-decoded version of the SASL exchange is:
SASL交換のbase64でデコードされたバージョンです。
S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth", algorithm=md5-sess,charset=utf-8 C: charset=utf-8,username="chris",realm="elwood.innosoft.com", nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", digest-uri="imap/elwood.innosoft.com", response=d388dad90d4bbd760a152321f2143af7,qop=auth S: rspauth=ea40f60335c427b5527b84dbabcdfffd
S：レルム= "elwood.innosoft.com"、ノンス= "OA6MG9tEQGm2hh"、QOP = "認証"、アルゴリズム= MD5-SESの、文字セット= UTF-8 C：のcharset = UTF-8、ユーザ名= "クリス"、レルム= "elwood.innosoft.com"、ノンス= "OA6MG9tEQGm2hh"、NC = 00000001、cnonce = "OA6MHXh6VqTrRk"、ダイジェスト-URI = "IMAP / elwood.innosoft.com"、応答= d388dad90d4bbd760a152321f2143af7、QOP = AUTH S：rspauth = ea40f60335c427b5527b84dbabcdfffd
The password in this example was "secret".
この例では、パスワードは「秘密」でした。
This example shows the use of the Digest SASL mechanism with the ACAP, using the same notational conventions and password as in the previous example. Note that ACAP does not base64 encode and uses fewer round trips that IMAP4.
この例では、前の例と同じ表記規則とパスワードを使用して、ACAPとダイジェストSASLメカニズムの使用を示しています。 ACAPは、base64でエンコードをせず、少ない往復IMAP4を使用することに注意してください。
S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5"
"DIGEST-MD5" "PLAIN")
C: a AUTHENTICATE "DIGEST-MD5"
S: + {94}
S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth",
algorithm=md5-sess,charset=utf-8
C: {206}
C: charset=utf-8,username="chris",realm="elwood.innosoft.com",
nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m",
digest-uri="acap/elwood.innosoft.com",
response=6084c6db3fede7352c551284490fd0fc,qop=auth
S: a OK (SASL {40}
S: rspauth=2f0b3d7c3c2e486600ef710726aa2eae) "AUTHENTICATE
Completed"
---
The server uses the values of all the directives, plus knowledge of the users password (or the hash of the user's name, server's realm and the user's password) to verify the computations above. If they check, then the user has authenticated.
サーバーは、上記の計算を確認するために、すべてのディレクティブの値は、プラスのユーザーのパスワードの知識（またはユーザ名のハッシュ、サーバーのレルムとユーザーのパスワード）を使用しています。彼らはチェックしている場合、ユーザーが認証されています。
5 References
5つの参考文献
[Digest] Franks, J., et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
【ダイジェスト】フランク、J.ら、「HTTP認証：基本とダイジェストアクセス認証」、RFC 2617、1999年6月。
[ISO-8859] ISO-8859. International Standard--Information Processing-- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[ISO-8859] ISO-8859。国際規格 - 情報Processing-- 8ビット・シングルバイト・コード化図形文字セット - パート1：ラテンアルファベット1号、ISO-8859-1：1987。パート2：ラテンアルファベット番号2、ISO-8859-2、1987パート3：ラテンアルファベット3号、ISO-8859-3、1988パート4：ラテンアルファベット番号4、ISO-8859-4、1988その5：ラテン/キリル文字、ISO-8859-5、1988パート6：ラテン/アラビア文字、ISO-8859-6、1987パート7：ラテン/ギリシャ語のアルファベット、ISO-8859-7、1987年パート8：ラテン/ヘブライ語のアルファベット、ISO-8859-8、1988年パート9：ラテンアルファベット5号、ISO-8859-9、1990。
[RFC 822] Crocker, D., "Standard for The Format of ARPA Internet Text Messages," STD 11, RFC 822, August 1982.
[RFC 822]クロッカー、D.、STD 11、RFC 822、1982年8月 "アルパインターネットテキストメッセージの形式、のための標準"。
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC 1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC 2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC 2052] Gulbrandsenの、A.及びP.いるVixie、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2052、1996年10月。
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC 2060]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年12月。
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[RFC 2195] Klensin、J.、Catoe、R.及びP. Krumviede、 "単純なチャレンジ/レスポンスのためのIMAP / POP許可拡張子"、RFC 2195、1997年9月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC 2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[USASCII] USASCII。コード化文字セット - 情報交換のための7ビットの米国標準コード。標準ANSI X3.4-1986、ANSI、1986。
6 Authors' Addresses
6本の著者のアドレス
Paul Leach Microsoft 1 Microsoft Way Redmond, WA 98052
ポール・リーチマイクロソフト1マイクロソフト道レドモンド、WA 98052
EMail: paulle@microsoft.com
メールアドレス：paulle@microsoft.com
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
クリス・ニューマンInnosoftの国際、Inc.の1050湖ドライブウェストコヴィナ、CA 91790 USA
EMail: chris.newman@innosoft.com
メールアドレス：chris.newman@innosoft.com
7 ABNF
7 ABNF
What follows is the definition of the notation as is used in the HTTP/1.1 specification (RFC 2616) and the HTTP authentication specification (RFC 2617); it is reproduced here for ease of reference. Since it is intended that a single Digest implementation can support both HTTP and SASL-based protocols, the same notation is used in both to facilitate comparison and prevention of unwanted differences. Since it is cut-and-paste from the HTTP specifications, not all productions may be used in this specification. It is also not quite legal ABNF; again, the errors were copied from the HTTP specifications.
以下は、HTTP / 1.1仕様（RFC 2616）およびHTTP認証仕様（RFC 2617）で使用される表記法の定義です。それは、参照を容易にするために、ここで再現されます。単一のダイジェスト実装はHTTPとSASLベースのプロトコルの両方をサポートすることができることが意図されているため、同じ表記法は、望ましくない差異の比較および予防を促進するための両方で使用されています。それはカットアンドペーストHTTP仕様からのものであるので、全ての制作は、本明細書で使用されてもよいです。また、ABNF非常に有効ではありません。再び、エラーがHTTPの仕様からコピーされました。
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [RFC 822]. Implementers will need to be familiar with the notation in order to understand this specification.
この文書で指定された機構の全ては、RFC 822 [RFC 822]によって使用されるものと同様の散文と拡張バッカスナウア記法（BNF）の両方に記載されています。実装者はこの仕様を理解するために、表記法に精通している必要があります。
The augmented BNF includes the following constructs:
増補BNFは、以下の構造が含まれています。
name = definition The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
名前ルールの名前は、単に名前自体である=定義（任意封入せずに「<」と「>」）と等しい「=」キャラクタによってその定義から分離されます。ホワイトスペースは、継続行のインデントが複数行にわたるルールの定義を示すために使用されている中で唯一重要です。特定の基本的なルールは、アングルブラケットは、その存在がルール名の使用を見分ける容易にするたびに定義内で使用される等SP、LWS、HT、CRLF、DIGIT、ALPHA、として、大文字です。
"literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
「リテラル」引用符はリテラルテキストを囲みます。特に明記しない限り、テキストは大文字と小文字を区別しません。
rule1 | rule2 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
ルール1 |バーで区切らRULE2 Elementsは（「|」）の選択肢は、例えば、「はい|いいえ」はい受け入れる、あるいは全くます。
(rule1 rule2) Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
（rule1 rule2）括弧で囲まれた要素は単一の要素として扱われます。したがって、 "（elemは（FOO |バー）のelem）は、" 可能にトークンシーケンス "elemはfooというのelem" と "elem bar elem"。
*rule The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
*「*」要素に先行する繰り返しを示す文字を支配。完全形は素子の少なくとも<N>と高々<M>の発生を示す「<N> * <M>要素」です。 「*（要素）」はゼロを含む任意の数を、可能にするようにデフォルト値は0と無限大です。 「1 *要素」とは、少なくとも1つが必要です。そして「1 *の2element」は1か2を可能にします。
[rule] Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
[ルール]角括弧は、オプションの要素を囲みます。 "[FOOバー]は" "* 1（FOOバー）" に相当します。
N rule Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
N特定の繰り返しルール： "<N>（要素）は" "<N> * <N>（要素）" に相当します。つまり、正確に<N>（要素）の発生。したがって2DIGITは、2桁の数字であり、そして3ALPHAはアルファベット3文字の文字列です。
#rule A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as
#rule構築物「＃」の要素のリストを定義するために、「*」に似た、定義されます。完全形は（「」）それぞれが1つ以上のカンマで区切られた、少なくとも<n>は、ほとんど<M>要素に示す「<N>＃<M>要素」であり、任意の線形空白（LWS）。これは、リストの通常の形は非常に簡単になります。このようなルール
( *LWS element *( *LWS "," *LWS element )) can be shown as 1#element Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
（* LWS要素*（* LWS「」* LWS要素））は、この構築物が使用されている場合はいつでも、null要素が許可されている1＃要素として示すことができるが、本要素の数に寄与しません。すなわち、「（要素）、（要素）」許可、2つだけの要素としてカウントされます。少なくとも一つの要素が必要とされるため、少なくとも一つの非ヌル要素が存在しなければなりません。 「#element」はゼロを含む、任意の数のを可能にするようにデフォルト値は0と無限大です。 「1＃要素」とは、少なくとも1つが必要です。そして「1つの＃の2element」は1か2を可能にします。
; comment A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
;セミコロンコメント、ルールテキストの右にある距離をオフに設定し、行の終わりまで続くコメントを開始します。これは仕様に対して有用な注釈をつけるための簡単な方法です。
implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
暗示*この仕様で記述文法は単語ベースでLWS。特記する場合を除いて、線形空白（LWS）は、フィールドの解釈を変えることなく、任意の2つの隣接する単語（トークンまたは引用文字列）の間に、隣接する単語とセパレータとの間に含めることができます。それらがそうでなければ、単一のトークンとして解釈されるので、少なくとも一つのデリミタ（LWS及び/又はセパレータ）は、任意の2つのトークン（「トークン」は、以下の定義用）の間に存在しなければなりません。
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [USASCII].
次のルールは、基本的な構文解析構造を記述するために本明細書を通して使用されています。 USASCIIコード化文字セットは、ANSI X3.4-1986 [USASCII]によって定義されます。
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
折りたたみを含むすべてのリニアホワイトスペースは、SPと同じ意味を持っています。受信者は、フィールドの値を解釈するか、下流のメッセージを転送する前に、単一のSPを持つ任意の線形空白を置き換えることができます。
LWS = [CRLF] 1*( SP | HT )
LWS = [CRLF] 1 *（SP | HT）
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [ISO 8859] only when encoded according to the rules of RFC 2047 [RFC 2047].
TEXTルールは、メッセージパーサによって解釈されることを意図するものではない記述フィールドの内容と値のために使用されます。 TEXT *の言葉は、文字から文字を含めることがRFC 2047の規則に従ってエンコードされた唯一のISO-8859-1 [ISO 8859]、[RFC 2047]以外に設定します。
TEXT = <any OCTET except CTLs,
but including LWS>
A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.
CRLFだけヘッダーフィールド継続の一部としてテキストの定義で許可されています。折りたたみLWSはTEXT値の解釈前に、単一のSPに置き換えされることが期待されます。
Hexadecimal numeric characters are used in several protocol elements.
進数字は、いくつかのプロトコル要素で使用されています。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value.
多くのHTTP / 1.1ヘッダフィールドの値は、LWSまたは特殊文字で区切られた単語から成ります。これらの特殊文字は、パラメータ値内で使用されるように引用符で囲まれた文字列でなければなりません。
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
A string of text is parsed as a single word if it is quoted using double-quote marks.
それは、二重引用符を使用して引用されている場合は、テキストの文字列は、単一の単語として解析されます。
quoted-string = ( <"> qdstr-val <"> ) qdstr-val = *( qdtext | quoted-pair ) qdtext = <any TEXT except <">>
引用符で囲んだ文字列=（< "> qdstr-ヴァル<">）qdstr-VAL = *（qdtext |引用されたペア）qdtext = < "<以外の任意のTEXT >>
Note that LWS is NOT implicit between the double-quote marks (<">) surrounding a qdstr-val and the qdstr-val; any LWS will be considered part of the qdstr-val. This is also the case for quotation marks surrounding any other construct.
qdstr-VALとqdstr-VALを囲む（< ">）LWSは、二重引用符の間の暗黙ないことに注意してください。qdstr-VALの任意LWSを考える一部これは、任意の周囲の引用符の場合です。他の構築物。
The backslash character ("\") MAY be used as a single-character quoting mechanism only within qdstr-val and comment constructs.
バックスラッシュ文字（「\」）は唯一qdstr-VALとコメント構文内の単一文字引用メカニズムとして使用することができます。
quoted-pair = "\" CHAR
引用されたペア=「\」CHAR
The value of this construct is CHAR. Note that an effect of this rule is that backslash must be quoted.
この構築物の値はCHARです。このルールの効果はバックスラッシュを引用しなければならないということであることに注意してください。
8 Sample Code
8サンプルコード
The sample implementation in [Digest] also applies to DIGEST-MD5.
[ダイジェスト]のサンプルインプリメンテーションはまた、MD5を消化するために適用されます。
The following code implements the conversion from UTF-8 to 8859-1 if necessary.
必要であれば、次のコードは、8859にUTF-8の変換を実現します。
/* if the string is entirely in the 8859-1 subset of UTF-8, then
* translate to 8859-1 prior to MD5
*/
void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base,
int len)
{
const unsigned char *scan, *end;
unsigned char cbuf;
end = base + len;
for (scan = base; scan < end; ++scan) {
if (*scan > 0xC3) break; /* abort if outside 8859-1 */
if (*scan >= 0xC0 && *scan <= 0xC3) {
if (++scan == end || *scan < 0x80 || *scan > 0xBF)
break;
}
}
/* if we found a character outside 8859-1, don't alter string
*/
if (scan < end) {
MD5Update(ctx, base, len);
return;
}
/* convert to 8859-1 prior to applying hash
*/
do {
for (scan = base; scan < end && *scan < 0xC0; ++scan)
;
if (scan != base) MD5Update(ctx, base, scan - base);
if (scan + 1 >= end) break;
cbuf = ((scan[0] & 0x3) << 6) | (scan[1] & 0x3f);
MD5Update(ctx, &cbuf, 1);
base = scan + 2;
} while (base < end);
}
9 Full Copyright Statement
9完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。