RFC2831 日本語訳
2831 Using Digest Authentication as a SASL Mechanism. P. Leach, C.Newman. May 2000. (Format: TXT=58124 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Leach
Request for Comments: 2831 Microsoft
Category: Standards Track C. Newman
Innosoft
May 2000
コメントを求めるワーキンググループP.リーチの要求をネットワークでつないでください: 2831年のマイクロソフトカテゴリ: 標準化過程C.ニューマンInnosoft2000年5月
Using Digest Authentication as a SASL Mechanism
SASLメカニズムとしてダイジェスト認証を使用します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
この仕様はSASLプロフィールを持っているどんなプロトコルにもSASL[RFC2222]メカニズムとしてどうHTTP Digest Authentication[ダイジェスト]を使用できるかを定義します。 それはCRAM-MD5[RFC2195]の上の改良、およびメール、ウェブのためにただ一つの認証機構をサポートする便利な方法としての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
1つの序論…2 1.1 コンベンションAND記法…2 1.2の要件…3 2認証…3 2.1 認証に頭文字をつけてください…3 2.1 .1 1つを踏んでください…3 2.1 .2 ステップTwo…6 2.1 .3 ステップThree…12 2.2 その後の認証…12 2.2 .1 1つを踏んでください…13 2.2 .2 ステップTwo…13 2.3 保全保護…13 2.4 秘密性保護…14 3 セキュリティ問題…15 3.1 ダイジェスト認証を使用しているクライアントの認証…15 3.2 平文パスワードとのダイジェストの比較…16 3.3の反射攻撃…16
Leach & Newman Standards Track [Page 1] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[1ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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
3.4のオンライン辞書は攻撃されます…16 3.5のオフライン辞書は攻撃されます…16 3.6 中央でやれやれ…17 3.7の選ばれた平文は攻撃されます…17 3.8 にせのサーバで、だまします…17 3.9 パスワードを保存します…17 3.10 倍数分野…18 3.11概要…18 4の例…18 5つの参照箇所…20 6人の作者のアドレス…21 7ABNF…21 7.1はBNFを増大させました…21 7.2 基本的な規則…23 8 コードを抽出してください…25 9 完全な著作権宣言文…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".
この仕様はHTTP Digest Access Authenticationの使用をSASLメカニズムとして記述します。 Digest SASLメカニズムに関連づけられた認証タイプは「ダイジェスト-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.1Digest Access Authenticationの"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は選ばれた平文攻撃を防いで、クライアントが最近サーバに認証されていた状態で可能にしたなら、第三者認証サーバ、互いの認証、および最適化された再認証の使用を可能にします。
1.1 Conventions and Notation
1.1のコンベンションと記法
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)が八重奏ストリングsの16八重奏MD5ハッシュ[RFC1321]であることをさせてください。
Leach & Newman Standards Track [Page 2] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[2ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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、コロン、およびストリングsの16八重奏ハッシュ。
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).
一連の32十六進法ケタ(いつもMD5が大文字と小文字を区別する時から低い場合における英字がある)としてHEX(n)が16八重奏MD5ハッシュnの表現であることをさせてください。
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.
キーとして八重奏ストリングkを使用して、HMAC(k、s)が八重奏ストリングsの16八重奏HMAC-MD5[RFC2104]であることをさせてください。
The value of a quoted string constant as an octet string does not include any terminating null character.
八重奏ストリングとしての引用文字列定数の値は少しの終端空文字も含んでいません。
1.2 Requirements
1.2 要件
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
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つか以上を満たさないなら実装が対応でない、それが実装するプロトコルのための平らな要件はそうしなければなりません。 すべてを満たす実装、レベルとプロトコルのための平らな要件が言われているすべてのSHOULDが「無条件に言いなりになっていなければなりません」。 すべてを満たすもの、プロトコルのためのすべてのSHOULDの平らな要件だけが「条件付きに言いなりになる」と言われているというわけではないという平らな要件はそうしなければなりません。
2 Authentication
2 認証
The following sections describe how to use Digest as a SASL authentication mechanism.
以下のセクションはどうDigestを使用するかをSASL認証機構として記述します。
2.1 Initial Authentication
2.1 初期の認証
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.
クライアントが最近サーバに認証されていた状態でそうしていないなら、「初期の認証」を実行しなければなりません、このセクションで定義されるように。 そうしたなら、最近認証されていて、より効率的なフォームは、次のセクションで利用可能で、定義されています。
2.1.1 Step One
2.1.1 ステップ1
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:
サーバは、挑戦状を送ることによって、始まります。 挑戦でコード化されたデータは以下の通り定義された「ダイジェスト挑戦」のための規則に従ってフォーマットされたストリングを含んでいます:
Leach & Newman Standards Track [Page 3] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[3ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
digest-challenge =
1#( realm | nonce | qop-options | stale | maxbuf | charset
algorithm | cipher-opts | auth-param )
ダイジェスト挑戦=1#(分野| 一回だけ| qop-オプション| | maxbuf| charsetアルゴリズムの聞き古したになってください|、| 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 )
分野=「分野」「=」<、「>分野価値の<、「qdstr-val>分野価値=一回だけ=の「一回だけ」の「=」<、「>一回だけの値の<、「qdstr-val qop-オプション=>の一回だけの値="qop"が<と「等しい」、「「>qop-リスト=1#qop-価値のqop-値="auth"」という>qop-リスト<。| "auth-int"| "auth-conf"| 1*ケタcharsetトークン聞き古した=「聞き古した」「=」「本当」のmaxbuf="maxbuf"「=」maxbuf-値maxbuf-価値=="charset"が「等しい」、「utf-8インチのアルゴリズム=「アルゴリズム」「=」"md5-sess"が=「暗号」「=」<を暗号で選ぶ、「>1#暗号価値の<「>暗号価値="3des"」| "des"| 「rc4-40インチ」| "rc4""| 「rc4-56インチ」| トークンauth-param=トークン「=」(トークン| 引用文字列)
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.
分野Mechanistically、ユーザが、どのユーザ名とパスワードを使用したらよいかを知っているのを可能にすることができるストリング、場合では、彼らは異なったサーバのための異なったものを持っているかもしれません。 概念的に、それはユーザのアカウントを含むかもしれないアカウントの収集の名前です。 このストリングは、少なくとも認証を実行しているホストの名前を含むべきであり、さらに、アクセサリーを持っているかもしれないユーザの収集を示すかもしれません。 例は" registered_users@gotham.news.example.com "であるかもしれません。 この指示は任意です。 プレゼントでないなら、クライアントSHOULDはユーザからそれに請求するか、またはデフォルトを計算できてください。 もっともらしいデフォルトは彼らがクライアントシステムにログインしたときユーザによって供給された分野であるかもしれません。 ユーザかクライアントがどのケースのために分野として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
初期の認証の一部としてダイジェスト挑戦を送る各回に異なるに違いない一回だけのAサーバで指定されたデータ列。 このストリングがbase64か16進データであることがお勧めです。 逃げられない場合ストリングが引用文字列として渡されるので二重引用文字が許容されていないことに注意してください(セクション7.2を見てください)。 一回だけの内容は実装に依存しています。 The
Leach & Newman Standards Track [Page 4] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[4ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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ビットを含んでいるのは、RECOMMENDEDです。 クライアントにとって、一回だけは不透明です。 この指示は、必要であり、まさに一度現れなければなりません。 プレゼントでない、または複数のインスタンスが存在しているなら、クライアントは認証交換を中止するべきです。
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.
「保護の品質」値が、サーバで. 値が"auth"であるとサポートしたのを示す1つ以上のトークンに関するqop-オプションA引用文字列は認証を示します。 値の"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.
「聞き古した」聞き古した指示は初期の認証に使用されません。 その後の認証における使用に関して次のセクションを見てください。 この指示は高々一度現れるかもしれません。 複数のインスタンスが存在しているなら、クライアントは認証交換を中止するべきです。
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 A番号。 この指示がなくなるなら、デフォルト値は65536です。 この指示は高々一度現れるかもしれません。 複数のインスタンスが存在しているなら、クライアントは認証交換を中止するべきです。
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.
存在しているなら、charset This指示は、サーバがユーザ名とパスワードのためのUTF-8コード化をサポートすると指定します。 そうでなければ、ISO8859-1(米国-ASCIIはそこで部分集合です)でプレゼント、ユーザ名、およびパスワードをコード化しなければなりません。 指示がHTTP Digestとの遅れている互換性に必要です。(DigestはISOが8859-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.
アルゴリズムThis指示がHTTP Digestとの遅れている互換性に必要である、どれが他のアルゴリズムこの指示をサポートするかは、必要であり、まさに一度現れなければなりません。 プレゼントでない、または複数のインスタンスが存在しているなら、クライアントは認証交換を中止するべきです。
Leach & Newman Standards Track [Page 5] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[5ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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.
サーバがサポートする暗号のAリストを暗号で選びます。 「qop-オプション」指示で"auth-conf"を提供するならこの指示がまさにかつて存在していなければならない、その場合、"3des"と"des"モードは、実装するために義務的です。 クライアントは認識されていないオプションを無視しなければなりません。 クライアントがオプションを全く認めないなら、それは認証交換を中止するべきです。
des
the Data Encryption Standard (DES) cipher [FIPS] in cipher
block chaining (CBC) mode with a 56 bit key.
56ビットのキーで(CBC)モードをチェーニングする暗号のデータ暗号化規格(DES)暗号[FIPS]が妨げるdes。
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ステージ(通称「2キーモード」)への同じキーがあるEDEがあるCBCモードによる3des「三重のDES」暗号。
rc4, rc4-40, rc4-56
the RC4 cipher with a 128 bit, 40 bit, and 56 bit key,
respectively.
rc4、rc4-40、RC4が128ビットで解くrc4-56、40ビット、および56はそれぞれキーに噛み付きました。
auth-param This construct allows for future extensions; it may appear
more than once. The client MUST ignore any unrecognized
directives.
構造物が今後の拡大のために許容するauth-param This。 それは一度より多く見えるかもしれません。 クライアントはどんな認識されていない指示も無視しなければなりません。
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から「ダイジェスト挑戦」にすることに注意してください: 以下のDigestオプション(HTTP用語における「指示」と呼ばれる)は未使用です(すなわち、送ってはいけなくて、受け取るなら、無視しなければなりません):
opaque
domain
不透明領域
The size of a digest-challenge MUST be less than 2048 bytes.
ダイジェスト挑戦のサイズは2048バイト未満でなければなりません。
2.1.2 Step Two
2.1.2 ステップTwo
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:
クライアントは、「ダイジェスト挑戦」のメモを作って、次に、以下の通り定義された「ダイジェスト応答」のための規則に従って、ストリングがフォーマットされて、計算されている状態で、応じます:
Leach & Newman Standards Track [Page 6] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[6ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
digest-response = 1#( username | realm | nonce | cnonce |
nonce-count | qop | digest-uri | response |
maxbuf | charset | cipher | authzid |
auth-param )
ダイジェスト応答=1#(ユーザ名|分野|一回だけ| cnonce| 一回だけのカウント| qop| ダイジェスト-uri| 応答|maxbuf|charset|暗号|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
ユーザ名=「ユーザ名」「=」<、「>ユーザ名価値の<、「qdstr-ヴァル>ユーザ名価値=cnonce="cnonce"が<と「等しい」、「>cnonce-値の<「"nc"qdstr-ヴァルの一回だけの>cnonce-値=カウント=「=」nc-値のnc-値=8LHEX qop="qop"「=」qop-値のダイジェスト-uri」; 「=「ダイジェスト-uri」 「=」<「>ダイジェストユリ価値の<「>ダイジェストユリ価値=serv-タイプ」/」ホスト」/」serv名前serv-タイプが1*アルファホスト=1*と等しい、(アルファ| ケタ| 「-」|、」、」、)、serv-名前=ホスト応答=「応答」は応答価値の応答価値と= 32LHEX LHEX=「0インチ」「等しいです」。| "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a"| 「b」| 「c」| 「d」| 「e」| 「暗号」「=」暗号価値の「f」暗号=authzid="authzid"が<と「等しい」、「>authzid-値の<「>authzid-値=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"指示の値に従ってコード化された指定された分野で命名するユーザ名。 この指示は、必要であり、まさにかつて存在していなければなりません。 さもなければ、認証は失敗します。
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).
分野、ユーザのアカウントを含む分野。 この指示が「ダイジェスト挑戦」でどんな分野にも提供されたサーバ、まさにどの場合にかつて現れるかもしれないか、そして、および値のSHOULDがそれらの分野の1つであるなら必要です。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.
サーバで指定されたデータが結ぶ一回だけは前のダイジェスト挑戦で受信されました。 この指示は、必要であり、まさにかつて存在していなければなりません。 さもなければ、認証は失敗します。
Leach & Newman Standards Track [Page 7] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[7ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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 Aは初期の認証の一部としてダイジェスト応答を送る各回に異なるに違いないデータ列をクライアントと同じくらい指定しました。 cnonce-値はクライアントによって提供されて、クライアントとサーバの両方によって使用される、選ばれた平文攻撃を避けて、互いの認証を提供する不透明な引用文字列値です。 実装のセキュリティは良い選択によります。 エントロピーの少なくとも64ビットを含んでいるのは、RECOMMENDEDです。 この指示は、必要であり、まさにかつて存在していなければなりません。 さもなければ、認証は失敗します。
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=1インチ」発信します。 この指示の目的はサーバがそれ自身のこのカウントのコピーを維持することによって要求再生を検出するのを許容することです--同じ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 Indicates、何、「」 クライアントが受け入れた保護の品質。 存在しているなら、まさに一度現れるかもしれません、そして、値は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].
ウェブサービスのための"www"、FTPサービスのための"ftp"、メール配信サービスのための"smtp"などのサービスのタイプのserv-タイプIndicates プロトコルのためのSASLプロフィールで定義されるサービス名はGSSAPIのホストベースのサービス名フォーム[RFC2078]のために「サービス」要素のIANA登録に登録された[RFC2222]のセクション4を見ます。
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.
サービスのためのホスト名かIPアドレスが要求したDNSを接待してください。 DNSホスト名はホストの完全に適切な正準な名前であるに違いありません。 DNSホスト名は好まれた形です。 ダイジェスト-uriのサーバ処理に関する注を見てください。
Leach & Newman Standards Track [Page 8] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[8ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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.
それが模写されるなら、サービスの名前とIndicatesをserv命名してください。 標準のDNSルックアップ操作を使用することでクライアントのサービス位置のプロセスが解決にかかわって、これらの操作が他のDNS名の1セットに1つのDNS名に変えるDNS記録(SRV、またはMXなどの)にかかわるなら、サービスが模写されると考えられます。 この場合、クライアントによって使用された初期の名前は「serv-名前」です、そして、最終的な名前は「ホスト」コンポーネントです。 例えば、"example.com"のための入って来るメールサービスはDNSに保存されたMX記録の使用で模写されるかもしれません、SMTPサーバーにおけるポイントが"mail3.example.com"と呼んだもの。 こと「serv-名前」が"example.com"であるだろうであるだろう、こと「ホスト」が"mail3.example.com"であるだろうでしょう。 サービスが模写されないか、またはホストにとって、serv-名前が同じであるなら、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".
主要なクライアントが接続したがっているサービスのserv-タイプから形成された名前がホスティングするダイジェスト-uri Indicates、および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.
サーバSHOULDは、供給値が正しいのをチェックします。 これは偶然の接続を不正確なサーバに検出するでしょう。また、クライアントがサーバ証明を提供できる共有されたバックエンド認証サービスを使用する実装を働いている値に提供するよう訓練されるのは、そのようにです。
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-タイプ成分は提供されるサービスに合うべきです。 ホストコンポーネントはサービスが稼働しているホストのホスト名の1つに合うべきですか、それがIPアドレスです。 IPアドレスによるサーバ証明がそれほど役に立たないので、通常、サーバSHOULD NOTはIPアドレスフォームをサポートします。 DNSが入手できないか、または頼り無い場合にだけ、彼らはそうするべきです。 serv-名前コンポーネントはサービスの構成されたサービス名の1つに合うべきです。
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.
以下に注意してください。 Digest認証の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十六進法ケタの応答Aストリング。(そのストリングは、ユーザがパスワードを知っていると立証します)。 この指示は、必要であり、まさにかつて存在していなければなりません。 さもなければ、認証は失敗します。
Leach & Newman Standards Track [Page 9] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[9ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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 A番号。 この指示がなくなるなら、デフォルト値は65536です。 この指示は高々一度現れるかもしれません。 複数のインスタンスが存在しているなら、サーバは認証交換を中止するべきです。
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.
存在しているなら、charset This指示は、クライアントがユーザ名とパスワードのためのUTF-8コード化を使用したと指定します。 そうでなければ、ISO8859-1(米国-ASCIIはそこで部分集合です)でプレゼント、ユーザ名、およびパスワードをコード化しなければなりません。 サーバが、UTF-8をサポートするのを示した場合にだけ、クライアントはこの指示を送るべきです。 指示がHTTP Digestとの遅れている互換性に必要です。(DigestはISOが8859-1であるとサポートするだけです)。
LHEX
32 hex digits, where the alphabetic characters MUST be lower case,
because MD5 is not case insensitive.
英字がMD5が大文字と小文字を区別しなくないのでケースを下ろすことであるに違いないところのLHEX32十六進法ケタ。
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でコード化されたauthzid RFCに従って「承認ID」2222。 この指示は任意です。 現在、認証しているユーザには、十分な特権があって、サーバはそれ(サーバがすべてのアクセスをしながらこのアイデンティティを使用して、アクセスがチェックする認証の後のその時)をサポートします。 クライアントがそれを指定して、サーバがそれをサポートしないと、応答値は不正確になるでしょう、そして、認証は失敗するでしょう。
The size of a digest-response MUST be less than 4096 bytes.
ダイジェスト応答のサイズは4096バイト未満でなければなりません。
2.1.2.1 Response-value
2.1.2.1 応答値
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.
ダイジェストuri価値のqop-値とコンポーネントは大文字と小文字を区別しないかもしれませんが、クライアントがステップtwoで供給するケースは応答値を計算して、確かめる目的のために保存されます。
response-value =
応答価値の=
Leach & Newman Standards Track [Page 10] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[10ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
HEX( KD ( HEX(H(A1)),
{ nonce-value, ":" nc-value, ":",
cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))
十六進法「(KD、(HEX(H(A1))、一回だけの値、」、: 」 nc-値、」、:、」、cnonce-値、」、:、」、qop-値、」、:、」、(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( { 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 }
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.
"charset"指示の値に従って、「ユーザ名値」、「分野値」、および"passwd"はコード化されます。 「charset=UTF-8インチがそうであるプレゼント、および「ISO8859-1文字集合には」 ユーザ名価値の"passwd"があって、論じ尽くされる前に次に、ISO8859-1にそれを変換しなければならない」すべてのキャラクタ。 これがそうであるので、論じ尽くされたユーザ名、分野、およびパスワード(一般的である)を保存するその認証データベースはHTTPと矛盾なく共有できます。(それは、ISO8859-1を指定します)。 この変換のサンプル実装がセクション8にあります。
If the "qop" directive's value is "auth", then A2 is:
"qop"指示の値が"auth"であるなら、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=「「以下を認証してください」、ダイジェストuri価値、」、: 0インチ
Note that "AUTHENTICATE:" must be in upper case, and the second string constant is a string with a colon followed by 32 zeros.
その「以下を認証してください」に注意してください。 ストリング定数が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との互換性のためのものです。 「認証する」「メソッド」を設定することによって、それらに達しました、そして、HTTPにおけるゼロへの実体本体のハッシュはA2の計算を読みこなします。
Also, in the HTTP usage of Digest, several directives in the
中のDigestのHTTP使用法によるいくつかの指示も
Leach & Newman Standards Track [Page 11] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[11ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
"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メカニズム(すなわち、送ってはいけなくて、受け取るなら、無視しなければならない)として使用されるとき、これらの指示は必要ではありません。
2.1.3 Step Three
2.1.3 ステップThree
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:
サーバは、「ダイジェスト応答」を受けて、有効にします。 サーバは、一回だけのカウントが「1インチ」であるとチェックします。 その後の認証をサポートするなら(セクション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
応答値が同じくらい上で計算されるところに、値を使用するのはステップtwoで発信しました、qopが"auth"であるならA2がそうを除いて
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値を読みこなしてください、」、: 0インチ
Compared to its use in HTTP, the following Digest directives in the "digest-response" are unused:
HTTPにおける使用と比べて、「ダイジェスト応答」における以下のDigest指示は未使用です:
nextnonce
qop
cnonce
nonce-count
nextnonce qop cnonceの一回だけのカウント
2.2 Subsequent Authentication
2.2 その後の認証
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プロフィールが初期のクライアント応答を可能にするなら、「その後の認証」を実行するかもしれません、このセクションで定義されるように。
Leach & Newman Standards Track [Page 12] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[12ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
2.2.1 Step one
2.2.1 ステップ1
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".
クライアントは、前の認証から値を使用して、「ダイジェスト応答」のための規則に従って、上で定義されるようにフォーマットされて、計算されたストリングにもかかわらず、一回だけのカウントものが最後の「ダイジェスト応答」に使用されるよりすばらしい状態で初期の応答を送ります。
2.2.2 Step Two
2.2.2 ステップTwo
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.
サーバは「ダイジェスト応答」を受けます。 サーバがその後の認証をサポートしないなら、「ダイジェスト挑戦」を送ります、そして、認証は初期の認証のように続きます。 サーバに前の認証からの保存している一回だけとどんな一回だけのカウントもないなら、「ダイジェスト挑戦」を送ります、そして、認証は初期の認証のように続きます。 さもなければ、サーバは、「ダイジェスト応答」を有効にして、一回だけのカウントが前の認証にその一回だけを使用することで使用されるそれよりすばらしい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.
応答が有効であるなら、サーバは、認証が成功したと考えるのを選ぶかもしれません。 しかしながら、それが前の認証、またはいかなる他の理由でも長過ぎたなら、サーバは一回だけのために新しい値がある新しい「ダイジェスト挑戦」を送るかもしれません。 挑戦は値が「本当」の「聞き古した」指示を含むかもしれません。(それは、クライアントがそれが前の応答に使用したパスワードを使用することで挑戦に応じるかもしれないと言います)。 さもなければ、クライアントはユーザからパスワードに新たに請求しなければなりません。 これは、サーバが、ユーザが最近それらのパスワードを提示したのを確実にすることを許可します。 (指示の名前は前のパスワードの最後の使用が聞き古したである聞き古した一回だけを参照します。) 「古くさくなってください」の取り扱いを除いて、発信した後に、「ダイジェスト挑戦」認証は初期の認証に関するケースのように続きます。
2.3 Integrity Protection
2.3 保全保護
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"、上がっていますが、クライアントとサーバの間に次のその後の認証を含んでいない当時のその後のメッセージを反応させたなら
Leach & Newman Standards Track [Page 13] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[13ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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)の値を使用して、以下の1組のメッセージの保全キーについて計算してください。
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"})
キシュは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が[RFC1321]で指定されるようにあるところで。 メッセージの保全を交渉するなら、各メッセージのためのMACブロックをメッセージに追加します。 MACブロックは16バイトです: メッセージのHMAC-MD5[RFC2104]の最初の10バイト、値1があるネットワークバイトオーダーにおける2バイトのメッセージ形式数、およびネットワークバイトオーダーにおける4バイトの系列番号。 メッセージタイプは「再-合わせ」などなどの今後の拡大を考慮することになっています。
MAC(Ki, SeqNum, msg) = (HMAC(Ki, {SeqNum, msg})[0..9], 0x0001,
SeqNum)
MAC(気、SeqNum、msg)=(HMAC(気、SeqNum、msg)[0 .9]、0×0001、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(気、SeqNum、msg)は容認された値と計算されて、比較されます。 彼らが異なるなら、メッセージは捨てられます。
2.4 Confidentiality Protection
2.4 秘密性保護
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.
サーバが発信したなら、aは「暗号」指示で反応する指示とクライアントを「暗号で選ん」で、そして、クライアントとサーバの間のその後のメッセージは保護された秘密性であるに違いありません。 クライアントとサーバを超えて定義されるようにベースセッションキーとしてH(A1)の値を使用して、以下の1組のメッセージの保全キーについて計算してください。
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:
サーバからクライアントまでメッセージを保護する秘密性のためのキーは以下の通りです。
Leach & Newman Standards Track [Page 14] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[14ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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が[RFC1321]で指定されるようにあるところで。 暗号のために、「rc4-40インチnは5です」。 「rc4-56インチnは7です」のために。 残りのために、nは16です。 「rc-*」暗号のためのキーは、すべての16バイトのKccかKcsです。 "des"のためのキーは最初の7バイトです。 "3des"のためのキーは最初の14バイトです。 "des"と"3des"のためのIVはバイトのベスト8のKccかKcsです。
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[RFC2104]の最初の10バイト、値1があるネットワークバイトオーダーにおける2バイトのメッセージ形式数、およびネットワークバイトオーダーにおける4バイトの系列番号。 blocksizeする、選ぶことでは、暗号が1バイトでない、詰め物接頭語はそれぞれ詰め物バイトの数を含む1つ以上の八重奏です、メッセージの暗号化された部分の全長が倍数であるようにblocksize MACブロックの詰め物の、そして、最初の10バイトはメッセージと共に暗号化されます。
SEAL(Ki, Kc, SeqNum, msg) =
{CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001,
SeqNum}
SEAL(気、Kc、SeqNum、msg)=CIPHER(Kc、msg、パッド、HMAC(気、SeqNum、msg)[0 .9))、0×0001、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はサーバによって送られたもののためにクライアント、キシュ、およびKcsによって送られたメッセージのためのKicとKccです。各メッセージが発信したので、一連番号は、ゼロに初期化されて、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(気、SeqNum、msg)は容認された値と計算されて、比較されます。 彼らが異なるなら、メッセージは捨てられます。
3 Security Considerations
3 セキュリティ問題
3.1 Authentication of Clients using Digest Authentication
3.1 ダイジェスト認証を使用しているクライアントの認証
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.
例えば、公開鍵に基づいているメカニズムと比べる場合、ダイジェストAuthenticationは強い認証機構を提供しません。 しかしながら、それが選ばれた平文攻撃を防ぐので、より強い、(例えば) CRAM-MD5、どれがLDAP[10]、POPとの使用とIMAPのために提案されたか。(RFC2195[9])を見てください。 平文パスワードのはるかに弱くてさらに危険な使用を取り替えるのは意図しています。 しかしながら、それでも、パスワードに基づいているメカニズムであるので、それは公開鍵、OTPまたは同様のメカニズムの潜在的deployabilty問題のいくつかを避けます。
Leach & Newman Standards Track [Page 15] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[15ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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.
実際のパスワードを保護することを超えてダイジェストAuthenticationは秘密性保護を全く提供しません。 立ち聞きする者にとって、挑戦と応答の残りのすべてが利用可能です、ユーザの名前と認証分野を含んでいて。
3.2 Comparison of Digest with Plaintext Passwords
3.2 平文パスワードとのダイジェストの比較
The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a 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.
これらのプロトコルが使用されているトランザクションのタイプへの最大の脅威はネットワーク詮索です。 この種類のトランザクションは使用が加入者に支払うのに制限されるメールサービスへの例えば、オンラインのアクセスにかかわるかもしれません。 平文パスワード認証で、立ち聞きする者はユーザのパスワードを得ることができます。 彼がデータベースの何にでもアクセスすることを許可するだけではなく、これはしばしばよりひどくユーザが同じパスワードで保護する他の何かへのアクセスを可能にするでしょう。
3.3 Replay Attacks
3.3の反射攻撃
Replay attacks are defeated if the client or the server chooses a fresh nonce for each authentication, as this specification requires.
クライアントかサーバが各認証のための新鮮な一回だけを選ぶなら、反射攻撃は破られます、この仕様が必要であるように。
3.4 Online dictionary attacks
3.4 オンライン辞書攻撃
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.
ユーザが辞書にあるパスワードを選択するのを許容しないことによって、サーバはこの攻撃を緩和できます。
3.5 Offline dictionary attacks
3.5 オフライン辞書攻撃
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.
攻撃者が挑戦を選ぶことができるなら、それはそれへの可能な応答が一般的な語のリストのために挑戦するprecomputeをそうすることができます。 通常、リストは可能なパスワードの総数とはるかに同じくらい小さいです。 一度だけリストの上の各パスワードのための応答を計算する費用を支払います。
Offline dictionary attacks are defeated if the client chooses a fresh nonce for each authentication, as this specification requires.
クライアントが新鮮な一回だけを選ぶなら、この仕様が必要であるようにオフライン辞書攻撃は各認証のために破られます。
Leach & Newman Standards Track [Page 16] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[16ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
3.6 Man in the Middle
3.6 中央でやれやれ
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.
可能な介入者攻撃は、より弱いqop体系をサーバによって送られたもの(s)の代わりに用いるだろうことです。 サーバはこの攻撃を検出できないでしょう。 この理由で、クライアントは、いつも提供された選択から理解している中で最も強い体系を使用するべきであり、必要最小限を満たさない体系を決して選ぶべきではありません。
3.7 Chosen plaintext attacks
3.7 選ばれた平文攻撃
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は、攻撃が挑戦を選ぶのを可能にしません、この仕様が必要であるように。
3.8 Spoofing by Counterfeit Servers
3.8 にせのサーバでだますこと。
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.
ユーザが、彼女が事実上、敵対的なサーバに接続しているとき彼女が知っているパスワードによって保護された情報を含むホストに接していると信じているように導くことができるなら、敵対的なサーバはそれが挑戦を一部選ぶことができたところで挑戦/応答組を得ることができます。 これを利用できる知られている方法が全くありません。
3.9 Storing passwords
3.9 パスワードを保存すること。
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から成る組を含むかもしれない、(ユーザ名値、」、:、」、分野値、」、:、」、passwd、)、上で直接ユーザのパスワードを暴露しないで説明されるようにH(A1)を計算するために適切な。
The security implications of this are that if this password file is compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say a standard UNIX password file, this information need not be decrypted in order to access documents in the server realm associated with this file. On the other
このセキュリティ含意はこのパスワードファイルが感染されるなら攻撃者がこの分野を使用することでサーバのドキュメントへの即座のアクセスを得るということです。 異なります、たとえば、標準のUNIXパスワードファイル、この情報は、このファイルに関連しているサーバ分野でドキュメントにアクセスするために解読される必要はありません。 もう片方に関して
Leach & Newman Standards Track [Page 17] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[17ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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).
手で、復号化、またはおそらくブルートフォースアタックが、ユーザのパスワードを得るのに必要でしょう。 これは分野がパスワードファイルに保存された読みこなされたデータの一部である理由です。 それは、1個のDigest認証パスワードファイルが感染されるなら、同じユーザ名とパスワードで自動的に他のものに感染しないことを意味します(ブルートフォースアタックに彼らを暴露しますが)。
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番目の結果は分野ストリングがどんなシングルユーザーも使用しそうであるすべての分野の中でユニークであるべきであるということです。 特に、分野ストリングは認証をしているホストの名前を含んでいるはずです。
3.10 Multiple realms
3.10 複数の分野
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.
複数の分野の使用は、そこのただ一つの分野のためのセキュリティデータベースがすべてのセキュリティに感染するというわけではないaのその感染とその両方が全体のシステムを安全に保つために保護するより多くのものであることを意味するかもしれません。
3.11 Summary
3.11 概要
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.
現代の暗号の規格で、Digest Authenticationが弱い、広範囲な目的のためにベースのメカニズム(言います)公開鍵Butと比べて、それは平文パスワードとの交換として貴重です。 実装によって、強さは異なるかもしれません。
4 Example
4の例
This example shows the use of the Digest SASL mechanism with the IMAP4 AUTHENTICATE command [RFC 2060].
この例はIMAP4 AUTHENTICATEコマンド[RFC2060]によるDigest 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を含むクライアントかサーバによって送られた台詞を表してください。 aの中のLinebreaksと刻み目、「C:」 または、「S:」 部分ではなく、プロトコルに関する社説がそうですか? この例のパスワードは「秘密でした」。 挑戦と応答のbase64コード化がDigest仕様の一部ではなく、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: * elwood.innosoft.com PMDF IMAP4rev1 V6.0-9Cを承認してください: c CAPABILITY S: * 能力IMAP4 IMAP4rev1 ACLリテラル+名前空間割当てUIDPLUS AUTH=一夜漬け-MD5 AUTHはダイジェスト-MD5 AUTH=平野Sと等しいです: c OK Completed
Leach & Newman Standards Track [Page 18] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[18ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
C: a AUTHENTICATE DIGEST-MD5
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im
ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=
S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C:
S: a OK User logged in
---
C: aはダイジェスト-MD5 Sを認証します: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh cnNldD11dGYtOA=C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= S: + cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA=C: S: ログインされたOK User---
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: 分野は"auth"、アルゴリズム=md5-sess、"elwood.innosoft.com"、一回だけ="OA6MG9tEQGm2hh"qop=charset=utf-8Cと等しいです: charset=utf-8、ユーザ名="chris"、分野="elwood.innosoft.com"一回だけ="OA6MG9tEQGm2hh"nc=00000001、cnonceはd388dad90d4bbd760a152321f2143af7、"OA6MHXh6VqTrRk"、ダイジェスト-uri="imap/elwood.innosoft.com"応答=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とのDigest 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"
---
S: * ACAP(IMPLEMENTATION「テストACAPサーバ」)、(SASL、「一夜漬け-MD5"、「ダイジェスト-MD5"「平野」) C:、」 aが認証する、「ダイジェスト-MD5"S:」 +94S: 分野は"auth"、アルゴリズム=md5-sess、"elwood.innosoft.com"、一回だけ="OA9BSXrbuRhWay"qop=charset=utf-8Cと等しいです: 206C: charset=utf-8、ユーザ名="chris"、分野="elwood.innosoft.com"一回だけ="OA9BSXrbuRhWay"nc=00000001、cnonceは6084c6db3fede7352c551284490fd0fc、"OA9BSuZWMSpW8m"、ダイジェスト-uri="acap/elwood.innosoft.com"応答=qop=auth Sと等しいです: (: SASL40S rspauth=2f0b3d7c3c2e486600ef710726aa2eae)が「完成されて、認証する」OK---
Leach & Newman Standards Track [Page 19] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[19ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、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.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
ムーア、[RFC2047]K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052] GulbrandsenとA.とP.Vixie、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2052、1996年10月。
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC2060] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC 2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[RFC2195] KlensinとJ.とCatoeとR.とP.Krumviede、「/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。
Leach & Newman Standards Track [Page 20] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[20ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC 2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2222] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[USASCII] US-ASCII. Coded Character Set - 7-Bit American Standard
Code for Information Interchange. Standard ANSI X3.4-1986,
ANSI, 1986.
[USASCII]米国-ASCII。 コード化文字集合--7ビットの情報交換用米国標準コード。 標準のANSI X3.4-1986、ANSI、1986。
6 Authors' Addresses
6人の作者のアドレス
Paul Leach Microsoft 1 Microsoft Way Redmond, WA 98052
ポールリーチマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: paulle@microsoft.com
メール: paulle@microsoft.com
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
クリスニューマンInnosoftの国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。
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仕様で使用される記法(RFC2616)とHTTP認証仕様(RFC2617)の定義です。 それはここで参照する場合に便利なように再生します。 ただ一つのDigest実装が、両方がHTTPとSASLベースのプロトコルであるとサポートすることができることを意図するので、同じ記法は求められていない違いの比較と防止を容易にするのに両方で使用されます。 それがHTTP仕様からのカットアンドペーストであるので、すべての創作がこの仕様で使用されるかもしれないというわけではありません。 また、それはかなり法的なABNFではありません。 一方、誤りはHTTP仕様からコピーされました。
7.1 Augmented BNF
7.1 増大しているBNF
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.
本書では指定されたメカニズムのすべてが散文とRFC822[RFC822]によって使用されたそれと同様の増大しているバッカス記法(BNF)の両方で説明されます。 Implementersは、この仕様を理解するために記法によく知られる必要があるでしょう。
Leach & Newman Standards Track [Page 21] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[21ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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.
aの名前が統治する名前=定義は、単に名前(いずれも"<"と">"を同封することのない)自体であり、等しい「=」キャラクタによって定義と切り離されます。 継続行の刻み目が1つ以上の線にかかる規則定義を示すのに使用されるので、余白は重要であるだけです。 SPなどの大文字、LWS、HT、CRLF、DIGIT、アルファーなどには、ある基本的なルールがあります。 それらの存在が、規則名の使用について明察するのを容易にするときはいつも、角ブラケットは定義の中で使用されます。
"literal"
Quotation marks surround literal text. Unless stated otherwise,
the text is case-insensitive.
「文字通り」のQuotationマークは文字通りのテキストを囲んでいます。 別の方法で述べられない場合、テキストは大文字と小文字を区別しないです。
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes |
no" will accept yes or no.
rule1| rule2Elementsがバーのそばで分離した、(「|」、)、代替手段、例えば、「はい」です。| 「いいえ」は諾否を受け入れるでしょう。
(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バー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はSpecific反復を統治します: 「<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
#規則A構造物「#」は、要素のリストを定義するための「*」と定義されていて、同様です。 完全形は少なくとも<n>と高々<m>を示す「<n>#<m>要素」要素です、1つ以上のコンマによって切り離されたそれぞれ、(「」、)、そして、任意の直線的な余白(LWS)。 これで、普通の形式のリストは非常に簡単になります。 aは統治します。
Leach & Newman Standards Track [Page 22] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[22ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
( *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であり、無限がそう、それ、」 #要素、」 ゼロを含むどんな数も許容します。 「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.
; 規則テキストの右への何らかの距離に引きたったコメントAセミコロンは行末に続くコメントを始めます。 これは仕様と平行して役に立つ注意を含む簡単な方法です。
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は単語ベースです。 別の方法で注意されるのを除いて、どんな2つの続いている語(象徴か引用文字列)の間とも、そして、続いている語と分離符の間に直線的な余白(LWS)を含むことができます、分野の解釈を変えないで。 少なくとも1つのデリミタ(LWS、そして/または、分離符)がどんな2つの象徴(以下の「象徴」の定義のための)の間にも存在しなければなりません、そうでなければ、それらは単一の象徴として解釈されるでしょう、したがって。
7.2 Basic Rules
7.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].
以下の規則は、基本的な構文解析構造物について説明するのにこの仕様中で使用されます。 米国-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
データ>CHAR=<において、どんな米国-ASCII文字(八重奏0--127)>UPALPHAも<と等しいです。「OCTETがどんな8ビットも配列する<と等しい、どんな米国-ASCII大文字「A」。」Z、「>LOALPHAがどんな米国-ASCIIも小文字で印刷する<と等しい、手紙“a"、」z「>アルファー=UPALPHA」| LOALPHA DIGITは<とどんな米国-ASCIIケタ「0インチ」等しいです。9インチの>CTL=<はどんな米国-ASCII制御文字(八重奏0--31)とデル(127)>CR=<米国-ASCII CR、復帰(13)>LF=<米国-ASCII LF、ラインフィード(10)>SP=<米国-ASCII SP(9) (32) スペース>HT=<米国-ASCII HT、水平タブ><「>=<米国-ASCII二重引用符(34)>CRLF=CR LF」です。
Leach & Newman Standards Track [Page 23] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[23ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
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規則は描写的である分野コンテンツとメッセージパーサによって解釈されることを意図しない値に使用されるだけです。 RFC2047[RFC2047]の規則に従ってコード化される場合にだけ、*TEXT MAYのワーズはISO-8859-1[ISO8859]以外の文字の組からのキャラクタを含んでいます。
TEXT = <any OCTET except CTLs,
but including LWS>
TEXT=<はCTLsの、しかし、含んでいるLWS>以外のあらゆるOCTETです。
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は単にヘッダーフィールド継続の一部としてTEXTの定義で許容されています。 折りたたみのLWSがTEXT価値の解釈の前の独身の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
十六進法=「A」| 「B」| 「C」| 「D」| 「E」| 「F」| "a"| 「b」| 「c」| 「d」| 「e」| 「f」| ケタ
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
象徴=1*<、CTLs以外のどんなCHARか分離符>分離符も等しい、「(「|」、)、」| "<"| ">"| "@" | "," | ";" | ":" | "\" | <">"| "/" | "[" | "]" | "?" | "=" | "{" | "}" | 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-val<、「>) 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.
LWSが二重引用符で暗に示されていないことに注意してください、(<、「>) qdstr-valとqdstr-valを囲みます」。 どんなLWSもqdstr-valの一部であると考えられるでしょう。 また、これはいかなる他の構造物も囲む引用符のためのそうです。
Leach & Newman Standards Track [Page 24] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[24ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within qdstr-val and comment constructs.
バックスラッシュキャラクタ(「\」)はqdstr-valとコメント構造物だけの中にメカニズムを引用する単独のキャラクタとして使用されるかもしれません。
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-MD5に適用されます。
The following code implements the conversion from UTF-8 to 8859-1 if necessary.
必要なら、以下のコードはUTF-8から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;
/、**完全なUTF-8の8859-1部分集合にストリングがあるならMD5*/空間MD5_UTF8_8859_1(MD5_CTX*ctx、const無記名の炭*ベース、int len)の前で8859-1に翻訳してください、constの無記名の炭*スキャン、*は終わります; 無記名の炭の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;
}
=ベース+lenを終わらせてください。 (スキャン=ベース;スキャン<エンド; + + スキャン)、8859-1 */の外で中断; (*>0xC3をスキャンしてください)/*であるなら中止になってください、(*>=0xC0をスキャンしてください、*スキャン<=0xC3)、(+ + スキャン=終わり| | *スキャン<0x80| | *スキャン>0xBF)であるなら、壊れてください;、/は*私たちであるなら8859-1の外でaキャラクタを見つけて、(スキャン<エンド)であるならストリング*/を変更しないでください。MD5Update(ctx、ベース、len)(リターン)
/* 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);
/*が細切れ肉料理*を適用する前に、8859-1に変えるか、またはする、(=ベースをスキャンしてください; <エンドをスキャンしてください、*<0xC0をスキャンしてください; + + スキャン) ; (ctx(ベース)はスキャンされます--ベース); (スキャン+1>=終わり)であるなら、壊れる;という(スキャン!=ベース)MD5Updateであるならcbuf=(([0]と0×3をスキャンします)<<6)| (スキャン[1]と0x3f);MD5Update(1をctxして、cbufします)
Leach & Newman Standards Track [Page 25] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[25ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
base = scan + 2;
} while (base < end);
}
=スキャン+2を基礎づけてください。 (ベース<エンド)である間。 }
Leach & Newman Standards Track [Page 26] RFC 2831 Digest SASL Mechanism May 2000
リーチとニューマン標準化過程[26ページ]RFC2831はSASLメカニズム2000年5月に読みこなします。
9 Full Copyright Statement
9 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Leach & Newman Standards Track [Page 27]
リーチとニューマン標準化過程[27ページ]
一覧
スポンサーリンク
