[要約] RFC 2831は、SASLメカニズムとしてダイジェスト認証を使用するための仕様です。このRFCの目的は、セキュアな認証プロセスを提供し、ユーザーの認証情報を保護することです。
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
SASLメカニズムとして消化認証を使用します
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.
Copyright（c）The Internet Society（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 Digest Authentication [Digest]を、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ダイジェストアクセス認証の使用について説明します。Digest 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.
この仕様は、[DIGEST]で指定されたHTTP/1.1 Digest Access認証の「MD5-SESS」アルゴリズムと上方に互換性があることを目的としています。「MD5-SESS」アルゴリズムの唯一の違いは、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、...}は、オクテット弦a、b、...の連結とします。
Let H(s) be the 16 octet MD5 hash [RFC 1321] of the octet string s.
h（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.
kd（k、s）をh（{k、 "："、s}）、すなわち、ひもkの16オクテットハッシュ、コロン、弦sとします。
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).
hex（n）を32ヘクス桁のストリングとして16オクテットmd5ハッシュnの表現とします（md5は症例に敏感であるため、常に小文字でアルファベット文字を使用します）。
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.
octet string kをキーとして使用して、occet string sの16 Octet HMAC-MD5 [RFC 2104]とHMAC（k、s）を16個のOctet HMAC-MD5 [RFC 2104]とします。
The value of a quoted string constant as an octet string does not include any terminating null character.
Octet文字列としての引用された文字列定数の値には、終端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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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."
実装するプロトコルの1つ以上の必須要件を満たすことができない場合、実装は準拠していません。すべてのマストレベルを満たす実装と、そのプロトコルのすべてのレベルの要件が「無条件に準拠している」と言われています。すべての必須要件を満たすものは、そのプロトコルのレベル要件をすべてレベルの要件を満たしているものではなく、「条件付きに準拠」していると言われています。
2 Authentication
2認証
The following sections describe how to use Digest as a SASL authentication mechanism.
次のセクションでは、SASL認証メカニズムとしてDigestを使用する方法について説明します。
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 )
サーバーは、チャレンジを送信することから始めます。チャレンジでエンコードされたデータには、次のように定義された「ダイジェストチャレンジ」のルールに従ってフォーマットされた文字列が含まれています：Digest-Challenge = 1＃（nonce | qop-options | stale | maxbuf | charset algorithm | cipher-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.
メカニズム的には、ユーザーが使用するユーザー名とパスワードが異なるサーバーに異なるものを持っている可能性がある場合に備えて、ユーザーが使用するユーザー名とパスワードを知ることができる文字列。概念的には、ユーザーのアカウントを含む可能性のあるアカウントのコレクションの名前です。この文字列には、少なくとも認証を実行するホストの名前が含まれている必要があり、さらにアクセスできるユーザーのコレクションを示す場合があります。例には、「登録済み@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 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.
NONCE初期認証の一部としてDigest-Challengeが送信されるたびに異なる必要があるサーバー指定のデータ文字列。この文字列は、base64または16進数データであることをお勧めします。文字列は引用された文字列として渡されるため、脱出しない限り、二重引用文字は許可されていません（セクション7.2を参照）。NONCEの内容は実装依存です。実装のセキュリティは、良い選択に依存します。少なくとも64ビットのエントロピーを含めることをお勧めします。ノンセはクライアントに不透明です。この指令が必要であり、正確に1回表示する必要があります。存在しない場合、または複数のインスタンスが存在する場合、クライアントは認証交換を中止する必要があります。
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-Optionsサーバーがサポートする「保護の品質」値を示す1つ以上のトークンの引用された文字列。値「auth」は認証を示します。値「auth-int」は、整合性保護を伴う認証を示します。値「auth-conf」は、整合性保護と暗号化による認証を示します。この指令はオプションです。存在しない場合は、デフォルトで「auth」になります。クライアントは、認識されていないオプションを無視する必要があります。クライアントがオプションを認識しない場合、認証交換を中止する必要があります。
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.
「古い」指令は、初期認証では使用されません。後続の認証での使用については、次のセクションを参照してください。この指令は、せいぜい1回表示される場合があります。複数のインスタンスが存在する場合、クライアントは認証交換を中止する必要があります。
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.
maxbuf「auth-int」または「auth-conf」を使用するときにサーバーが受信できる最大バッファのサイズを示す数字。この指令が欠落している場合、デフォルト値は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エンコードをサポートすることを指定します。存在しない場合、ユーザー名とパスワードはISO 8859-1（そのうちUS-ASCIIはサブセットです）でエンコードする必要があります。この指令は、ISO 8859-1のみをサポートするHTTP Digestとの逆方向の互換性に必要です。この指令は、せいぜい1回表示される場合があります。複数のインスタンスが存在する場合、クライアントは認証交換を中止する必要があります。
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ダイジェストとの逆方向の互換性に必要です。。この指令が必要であり、正確に1回表示する必要があります。存在しない場合、または複数のインスタンスが存在する場合、クライアントは認証交換を中止する必要があります。
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.
cipher-optsサーバーがサポートする暗号のリスト。この指令は、「auth-conf」が「qop-options」指令で提供される場合、正確に1回存在する必要があります。クライアントは、認識されていないオプションを無視する必要があります。クライアントがオプションを認識しない場合、認証交換を中止する必要があります。
des the Data Encryption Standard (DES) cipher [FIPS] in cipher block chaining (CBC) mode with a 56 bit key.
DESデータ暗号化標準（DES）Cipher [FIPS] 56ビットキーを備えた暗号ブロックチェーン（CBC）モード。
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.
3DES合計キーの長さ112ビットで、各Eステージ（別名「2つのキーモード」）に同じキーを持つEDEを備えたCBCモードの「トリプルデス」暗号。
rc4, rc4-40, rc4-56 the RC4 cipher with a 128 bit, 40 bit, and 56 bit key, respectively.
RC4、RC4-40、RC4-56それぞれ128ビット、40ビット、56ビットキーのRC4暗号。
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 )
クライアントは、「Digest-Challenge」に注意を払い、次のように定義された「Digest-Response」のルールに従ってフォーマットおよび計算された文字列で応答します。Nonce-Count | Qop | Digest-uri | Response | Maxbuf | Charset | cipher | 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.
ユーザー名指定された領域のユーザー名は、「charset」ディレクティブの値に従ってエンコードされています。この指令が必要であり、正確に1回存在する必要があります。それ以外の場合、認証は失敗します。
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.
以前のダイジェストチャレンジで受信したサーバー指定のデータ文字列。この指令が必要であり、正確に1回存在する必要があります。それ以外の場合、認証は失敗します。
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初期認証の一部としてDigest-Responseが送信されるたびに異なる必要があるクライアント指定のデータ文字列が必要です。Cnonce-Valueは、クライアントが提供し、選択したプレーンテキスト攻撃を避け、相互認証を提供するためにクライアントとサーバーの両方が使用する不透明な引用文字列値です。実装のセキュリティは、良い選択に依存します。少なくとも64ビットのエントロピーを含めることをお勧めします。この指令が必要であり、正確に1回存在する必要があります。それ以外の場合、認証は失敗します。
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.
NonCe-Count NC値は、クライアントがこのリクエストのNONCE値で送信した要求数（現在の要求を含む）の16進数です。たとえば、特定のNONCE値に応じて送信された最初の要求で、クライアントは「NC = 00000001」を送信します。この指令の目的は、このカウントの独自のコピーを維持することにより、サーバーがリクエストリプレイを検出できるようにすることです。同じNC値が2回見られた場合、リクエストはリプレイです。応答値の構築の以下の説明を参照してください。この指令は、せいぜい1回表示される場合があります。複数のインスタンスが存在する場合、クライアントは認証交換を中止する必要があります。
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オプションの代替案の1つでなければなりません。存在しない場合、デフォルトは「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].
Serv-Typeは、Webサービスの「www」、FTPサービスの「FTP」、メール配信サービスの「SMTP」などのサービスの種類を示します。[RFC 2222]のof、GSSAPIホストベースのサービス名[RFC 2078]の「サービス」要素のIANAレジストリに登録されています。
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ホスト名は推奨フォームです。Digest-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.
サーブ名は、サービスの名前を複製する場合、サービスの名前を示します。サービスは、クライアントのサービスロケーションプロセスに標準のDNSルックアップ操作を使用した解像度を伴う場合、およびこれらの操作が1つのDNS名を他のDNS名のセットに解決するDNSレコード（SRVやMXなど）が含まれる場合、複製されると見なされます。この場合、クライアントが使用する最初の名前は「サーブ名」であり、最終名は「ホスト」コンポーネントです。たとえば、「Example.com」の着信メールサービスは、DNSに保存されたMXレコードを使用して再現できます。「servname」は「emple.com」であり、「ホスト」は「mail3.example.com」です。サービスが複製されていない場合、またはサーブ名がホストと同一である場合、サーブ名コンポーネントを省略する必要があります。
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".
Digest-uriは、クライアントが接続したいサービスの主な名前を示しています。これは、サーブタイプ、ホスト、およびサーブ名から形成されます。たとえば、「ftp.example.com」のFTPサービスには、「FTP/ftp.example.com」の「ダイジェストリ」値があります。上記の例からのSMTPサーバーには、「SMTP/Mail3.example.com/Example.com」の「Digest-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.
サーブタイプのコンポーネントは、提供されているサービスと一致する必要があります。ホストコンポーネントは、サービスが実行されているホストのホスト名の1つ、またはIPアドレスである必要があります。IPアドレスによるサーバー認証はあまり役に立たないため、サーバーは通常、IPアドレスフォームをサポートしてはなりません。DNSが利用できないか信頼できない場合にのみ、そうする必要があります。サーブ名コンポーネントは、サービスの設定されたサービス名の1つと一致する必要があります。
This directive may appear at most once; if multiple instances are present, the client should abort the authentication exchange.
この指令は、せいぜい1回表示される場合があります。複数のインスタンスが存在する場合、クライアントは認証交換を中止する必要があります。
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.
注：Digest認証のHTTP使用では、Digest-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ヘクスの桁の文字列。これは、ユーザーがパスワードを知っていることを証明しています。この指令が必要であり、正確に1回存在する必要があります。それ以外の場合、認証は失敗します。
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エンコードを使用していることを指定します。存在しない場合、ユーザー名とパスワードはISO 8859-1（そのうちUS-ASCIIはサブセットです）でエンコードする必要があります。クライアントは、サーバーがUTF-8をサポートしていることを示している場合にのみ、この指令を送信する必要があります。この指令は、ISO 8859-1のみをサポートするHTTP Digestとの逆方向の互換性に必要です。
LHEX 32 hex digits, where the alphabetic characters MUST be lower case, because MD5 is not case insensitive.
LHEX 32 HEX桁。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」が交渉された場合、正確に1回表示する必要があります。必要に応じて存在しない場合、認証は失敗します。
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小文字の160文字）を示しています。次の定義は、値の計算方法を示しています。
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値とコンポーネントは症例に依存しない場合がありますが、ステップ2でクライアントが提供する場合は、応答値を計算して検証する目的で保存されます。
response-value =
応答値=
HEX( KD ( HEX(H(A1)),
{ nonce-value, ":" nc-value, ":",
cnonce-value, ":", qop-value, ":", 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 }
If authzid is not specified, then A1 is
Authzidが指定されていない場合、A1はそうです
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
":", nonce-value, ":", cnonce-value }
where
ただし
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.
「username-value」、「Realm-Value」、および「PassWD」は、「charset」指令の値に従ってエンコードされます。「charset = utf-8」が存在し、「username-value」または「passwd」のすべての文字がISO 8859-1文字セットにある場合、ハッシュする前に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 }
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" }
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
また、Digestの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).
これらの指令は、Digestが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:
サーバーは、「消化反応」を受信して検証します。サーバーは、NonCe-Countが「00000001」であることを確認します。後続の認証をサポートする場合（セクション2.2を参照）、NonCeとNonCe-Countの値を節約します。次のようにフォーマットされたメッセージを送信します。
response-auth = "rspauth" "=" response-value
Response-auth = "rspauth" "=" respons-value
where response-value is calculated as above, using the values sent in step two, except that if qop is "auth", then A2 is
応答値が上記のように計算される場合、QOPが「auth」である場合、a2はa2がある場合を除き、ステップ2で送信された値を使用します。
A2 = { ":", digest-uri-value }
And if qop is "auth-int" or "auth-conf" then A2 is
QOPが「auth-int」または「auth-conf」の場合、a2は
A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" }
Compared to its use in HTTP, the following Digest directives in the "digest-response" are unused:
HTTPでの使用と比較して、「Digest Response」の次のDigest指令は未使用です。
nextnonce qop cnonce nonce-count
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".
クライアントは、以前の認証の値を使用し、上記のように、「消化反応」のルールに従ってフォーマットおよび計算された文字列を使用して初期応答を送信しますが、最後に使用されるよりも大きいノンセカウントでは」消化反応」。
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.
サーバーは「消化反応」を受信します。サーバーが後続の認証をサポートしていない場合、「Digest-Challenge」を送信し、初期認証のように認証が進みます。サーバーが以前の認証からNonCeとNonCe-Countを保存していない場合、「Digest-Challenge」を送信し、認証は初期認証のように進行します。それ以外の場合、サーバーは「ダイジェスト応答」を検証し、その非CEを使用して以前の認証で使用されたものよりもノンセカウントよりも大きいことをチェックし、NonCe-Countの新しい値を保存します。
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.
応答が無効な場合、サーバーは「ダイジェストチャレンジ」を送信し、認証は初期認証のように進行します（障害はの症状である可能性があるため、何らかのセキュリティ監査ログで認証障害を記録するように設定可能である必要があります。攻撃）。この場合、NonCe-Countを増分してはなりません。これを行うことで、オーダーのない非CEカウントを送信することにより、サービス拒否攻撃が可能になります。
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の新しい値で新しい「Digest-Challenge」を送信する場合があります。課題には、「価値のある」という「古い」ディレクティブが含まれる場合があります。これには、クライアントが以前の応答で使用したパスワードを使用してチャレンジに応答する場合があります。それ以外の場合、クライアントはユーザーからパスワードを新たに求める必要があります。これにより、サーバーはユーザーが最近パスワードを提示したことを確認できます。（ディレクティブ名は、以前のNonceが古くなっていることを指します。これは、パスワードの最後の使用ではありません。）初期認証の場合のように、「Digest-Challenge」認証の収益を送信した後の「古い」の処理を除きます。
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 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.
サーバーが「QOP = auth-int」を提供し、クライアントが「qop = auth-int」と応答した場合、次のメッセージは、クライアントとサーバーの間に次の後続の認証を含めないようにしますが、整合性保護されている必要があります。基本セッションキーとして使用して、クライアントの上に定義されている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"})
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"})
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ブロックがメッセージに追加されます。Macブロックは16バイトです。メッセージのHMAC-MD5 [RFC 2104]の最初の10バイト、値1のネットワークバイト順序の2バイトメッセージタイプ番号、ネットワークバイト順序の4バイトシーケンス番号。メッセージタイプは、再キーイングなどの将来の拡張機能を可能にすることです。
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とサーバーによって送信されたもののKISとKISです。シーケンス番号はゼロに初期化され、送信されるメッセージごとに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.
サーバーが「cipher-opts」指令を送信し、クライアントが「cipher」ディレクティブで応答した場合、クライアントとサーバーの間の後続のメッセージは機密保護されている必要があります。基本セッションキーとして使用して、クライアントの上に定義されている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"})
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"})
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]で指定されています。cipher "rc4-40" nは5です。「RC4-56」の場合は7です。残りのNは16です。「rc-*」暗号の鍵は、すべて16バイトのKCCまたはKCSです。「DES」のキーは最初の7バイトです。「3DES」のキーは、最初の14バイトです。「DES」および「3DES」のIVは、KCCまたはKCの最後の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バイトメッセージタイプ番号、および2バイトのメッセージタイプ番号、およびネットワークバイト順序の4バイトシーケンス番号。選択した暗号のブロックサイズが1バイトではない場合、パディングプレフィックスはそれぞれパディングバイトの数を含む1つ以上のオクテットであり、メッセージの暗号化された部分の全長がブロックサイズの倍数です。パディングとMacブロックの最初の10バイトは、メッセージとともに暗号化されています。
SEAL(Ki, Kc, SeqNum, msg) =
{CIPHER(Kc, {msg, pad, 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が選択されたCipherである場合、KiとKCは、クライアントから送信されたメッセージのKICとKCCと、サーバーが送信したもののKISと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.
たとえば、公開キーベースのメカニズムと比較した場合、Digest認証は強力な認証メカニズムを提供しません。ただし、選択したプレーンテキスト攻撃を防ぐため、LDAP [10]、POP、およびIMAPで使用することが提案されているCRAM-MD5よりも強いです（RFC 2195 [9]を参照）。これは、平文パスワードのはるかに弱く、さらに危険な使用を交換することを目的としています。ただし、まだパスワードベースのメカニズムであるため、Public-Key、OTP、または同様のメカニズムに関する潜在的な展開された問題のいくつかを回避します。
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.
Digest Authenticationは、実際のパスワードを保護する以外に機密保護を提供しません。課題と対応の残りはすべて、ユーザーの名前や認証の領域を含む盗聴者が利用できます。
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.
これらのプロトコルが使用されるトランザクションのタイプに対する最大の脅威は、ネットワークスヌーピングです。この種のトランザクションには、たとえば、サブスクライバーの支払いに限定されているメールサービスへのオンラインアクセスが含まれる場合があります。Plantextパスワード認証を使用すると、盗聴者はユーザーのパスワードを取得できます。これにより、データベース内の何かにアクセスできるだけでなく、さらに悪いことに、ユーザーが同じパスワードで保護する他のものにアクセスできます。
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.
消化認証は、「Man in the Middle」（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.
中間の攻撃の可能性は、サーバーが送信したものの弱い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.
ただし、Digestは、クライアントがこの仕様が必要とするように、認証ごとに新鮮な非CEを選択する限り、攻撃を選択することを許可しません。
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.
Digest認証では、認証エージェント（通常はサーバー）が、特定の領域に関連付けられた「パスワードファイル」にユーザーの名前とパスワードから派生したデータを保存する必要があります。通常、これにはユーザー名とh（{username-value、 "："、realm-value、 "："、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パスワードファイルなどとは異なり、このファイルに関連付けられたサーバーレルムのドキュメントにアクセスするために、この情報を復号化する必要はありません。一方、ユーザーのパスワードを取得するには、復号化、またはブルートフォース攻撃の可能性が高くなります。これが、領域がパスワードファイルに保存されている消化データの一部である理由です。つまり、認証パスワードファイルが損なわれている場合、同じユーザー名とパスワードで他の人を自動的に侵害しないことを意味します（ただし、ブルートフォース攻撃にさらされます）。
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.
これの2番目の結果は、単一のユーザーが使用する可能性のあるすべてのレルムの中で、レルムストリングが一意であることです。特に、レルム文字列には、認証を行うホストの名前を含める必要があります。
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認証コマンド[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認証コマンドの一部であることに注意してください。
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
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 ExchangeのBase64-Decodedバージョンは次のとおりです。
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
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.
[Digest] Franks、J.、et al。、「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。国際標準 - 情報処理 - 8ビットシングルバイトコード化されたグラフィック文字セット - パート1：ラテンアルファベットNo. 1、ISO-8859-1：1987。パート2：ラテンアルファベットNo. 2、ISO-8859-2、1987。パート3：ラテンアルファベットNo. 3、ISO-8859-3、1988。パート4：ラテンアルファベットNo. 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：ラテンアルファベットNo. 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] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、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：ASSASCII以外のテキスト用のメッセージヘッダー拡張機能」、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.、Bellare、M。、およびR. CaNetti、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC 2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC 2222] Myers、J。、「Simple Authentication and Security Layer（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] us-ascii。コード化された文字セット-Interchangeのための7ビットAmerican Standard Code。標準ANSI X3.4-1986、ANSI、1986。
6 Authors' Addresses
6著者のアドレス
Paul Leach Microsoft 1 Microsoft Way Redmond, WA 98052
Paul Leach Microsoft 1 Microsoft Way Redmond、WA 98052
EMail: paulle@microsoft.com
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
クリスニューマンイノソフトインターナショナル、インク1050レイクスドライブウェストコヴィナ、カリフォルニア州91790 USA
EMail: 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 |バー（ "|"）で区切られたルール2要素は、例えば「はい| no」はyesまたはnoを受け入れます。
(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 | bar）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 bar]」は「*1（foo bar）」に相当します。
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
( *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要素））は、このコンストラクトが使用されている場合は1＃要素として表示できますが、ヌル要素は許可されますが、存在する要素のカウントには寄与しません。つまり、「（要素）、（要素）」は許可されていますが、2つの要素のみをカウントします。したがって、少なくとも1つの要素が必要な場合、少なくとも1つの非ヌル要素が存在する必要があります。デフォルト値は0および無限であるため、「#Element」によりゼロを含む任意の数値が許可されます。「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この仕様で説明されている文法は単語ベースです。特に指摘されている場合を除き、線形ホワイトスペース（LW）は、フィールドの解釈を変更することなく、隣接する単語（トークンまたは引用されたストリング）、および隣接する単語とセパレーターの間に含めることができます。少なくとも1つの区切り文字（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].
この仕様全体で、基本的な解析構造を説明するために、次のルールが使用されます。US-ASCIIコード化された文字セットは、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 )
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].
テキストルールは、メッセージパーサーによって解釈されることを意図していない記述フィールドの内容と値にのみ使用されます。*テキストの単語には、RFC 2047 [RFC 2047]のルールに従ってエンコードされた場合にのみ、ISO-8859-1 [ISO 8859]以外の文字セットからの文字を含めることができます。
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を単一のSPに置き換えることが予想されます。
Hexadecimal numeric characters are used in several protocol elements.
16進数文字は、いくつかのプロトコル要素で使用されます。
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ヘッダーフィールド値は、LWまたは特殊文字で区切られた単語で構成されています。これらの特殊文字は、パラメーター値内で使用されるために引用された文字列にある必要があります。
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 <">>
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.
LWSは、QDSTR-ValとQDSTR-Valを囲む二重引用符（<">）の間で暗黙的ではないことに注意してください。すべてのLWはQDSTR-Valの一部と見なされます。その他の構成。
The backslash character ("\") MAY be used as a single-character quoting mechanism only within qdstr-val and comment constructs.
バックスラッシュ文字（ "\"）は、QDSTR-valおよびコメントコンストラクト内のみ内でのみ、単一の特徴を引用するメカニズムとして使用できます。
quoted-pair = "\" CHAR
quoted-pair = "\" 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.
[Digest]のサンプル実装は、Digest-MD5にも適用されます。
The following code implements the conversion from UTF-8 to 8859-1 if necessary.
次のコードは、必要に応じてUTF-8から8859-1から8859-1への変換を実装します。
/* 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。