Network Working Group A. Melnikov, Ed.
Request for Comments: 4422 Isode Limited
Obsoletes: 2222 K. Zeilenga, Ed.
Category: Standards Track OpenLDAP Foundation
June 2006
Simple Authentication and Security Layer (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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.
簡易認証セキュリティー層（SASL）は、交換可能な機構を介して接続指向のプロトコルで認証とデータのセキュリティサービスを提供するためのフレームワークです。これは、プロトコルと機構との間の構造化されたインターフェースを提供します。結果のフレームワークは、既存のメカニズムを再利用する新しいプロトコルを可能にし、古いプロトコルが新しいメカニズムを利用することができます。フレームワークは、データセキュリティ層内の後続のプロトコル交換を確保するためのプロトコルを提供します。
This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.
この文書では、SASL機構が構成されている方法を説明したプロトコルは、SASLのサポートを含む方法を説明し、そして接続を介してデータセキュリティ層を担持するためのプロトコルを定義します。また、この文書は、一つSASL機構、外部機構を定義します。
This document obsoletes RFC 2222.
この文書はRFC 2222を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Audiences .........................................4
1.2. Relationship to Other Documents ............................4
1.3. Conventions ................................................5
2. Identity Concepts ...............................................5
3. The Authentication Exchange .....................................6
3.1. Mechanism Naming ...........................................8
3.2. Mechanism Negotiation ......................................9
3.3. Request Authentication Exchange ............................9
3.4. Challenges and Responses ...................................9
3.4.1. Authorization Identity String ......................10
3.5. Aborting Authentication Exchanges .........................10
3.6. Authentication Outcome ....................................11
3.7. Security Layers ...........................................12
3.8. Multiple Authentications ..................................12
4. Protocol Requirements ..........................................13
5. Mechanism Requirements .........................................16
6. Security Considerations ........................................18
6.1. Active Attacks ............................................19
6.1.1. Hijack Attacks .....................................19
6.1.2. Downgrade Attacks ..................................19
6.1.3. Replay Attacks .....................................20
6.1.4. Truncation Attacks .................................20
6.1.5. Other Active Attacks ...............................20
6.2. Passive Attacks ...........................................20
6.3. Re-keying .................................................21
6.4. Other Considerations ......................................21
7. IANA Considerations ............................................22
7.1. SASL Mechanism Registry ...................................22
7.2. Registration Changes ......................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
9. Acknowledgements ...............................................28
Appendix A. The SASL EXTERNAL Mechanism ..........................29
A.1. EXTERNAL Technical Specification ..........................29
A.2. SASL EXTERNAL Examples ....................................30
A.3. Security Considerations ...................................31
Appendix B. Changes since RFC 2222 ...............................31
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. SASL provides a structured interface between protocols and mechanisms. SASL also provides a protocol for securing subsequent protocol exchanges within a data security layer. The data security layer can provide data integrity, data confidentiality, and other services.
簡易認証セキュリティー層（SASL）は、交換可能な機構を介して接続指向のプロトコルで認証とデータのセキュリティサービスを提供するためのフレームワークです。 SASLはプロトコルと機構との間の構造化されたインターフェースを提供します。 SASLは、データセキュリティ層内に後続のプロトコル交換を確保するためのプロトコルを提供します。データセキュリティレイヤは、データの整合性、データの機密性、およびその他のサービスを提供することができます。
SASL's design is intended to allow new protocols to reuse existing mechanisms without requiring redesign of the mechanisms and allows existing protocols to make use of new mechanisms without redesign of protocols.
SASLのデザインは、新しいプロトコルはメカニズムの再設計を必要とせずに既存のメカニズムを再利用できるようにすることを目的と既存のプロトコルは、プロトコルの再設計することなく、新しいメカニズムを利用することができますされています。
SASL is conceptually a framework that provides an abstraction layer between protocols and mechanisms as illustrated in the following diagram.
SASLは、概念的に以下の図に示すように、プロトコルと機構との間の抽象化層を提供するフレームワークです。
SMTP LDAP XMPP Other protocols ...
\ | | /
\ | | /
SASL abstraction layer
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN Other mechanisms ...
It is through the interfaces of this abstraction layer that the framework allows any protocol to utilize any mechanism. While this layer does generally hide the particulars of protocols from mechanisms and the particulars of mechanisms from protocols, this layer does not generally hide the particulars of mechanisms from protocol implementations. For example, different mechanisms require different information to operate, some of them use password-based authentication, some of then require realm information, others make use of Kerberos tickets, certificates, etc. Also, in order to perform authorization, server implementations generally have to implement identity mapping between authentication identities, whose form is mechanism specific, and authorization identities, whose form is application protocol specific. Section 2 discusses identity concepts.
これは、フレームワークは任意のプロトコルは、任意の機構を利用することができ、この抽象化層のインターフェイスを介してです。この層は、一般的メカニズムおよびプロトコルからのメカニズムの詳細からのプロトコルの詳細を隠すんが、この層は、一般に、プロトコル実装から機構の詳細を隠蔽しません。承認を実行するために、例えば、異なるメカニズムは、それらのいくつかは、パスワードベースの認証を使用し、動作させるためのさまざまな情報を必要とし、レルム情報が必要なのいくつかは、他の人がサーバーの実装は、一般的に持っている、Kerberosチケット、証明書などの使用も作りますフォームアプリケーションプロトコルが特定され、フォームのメカニズム固有の認証アイデンティティ、および承認のアイデンティティとの間のIDマッピングを実装します。第2節では、アイデンティティの概念について説明します。
It is possible to design and implement this framework in ways that do abstract away particulars of similar mechanisms. Such a framework implementation, as well as mechanisms implementations, could be designed not only to be shared by multiple implementations of a particular protocol but to be shared by implementations of multiple protocols.
同様のメカニズムの抽象化細目を行う方法で、このフレームワークを設計し、実装することが可能です。このようなフレームワークの実装、ならびにメカニズムの実装は、特定のプロトコルの複数の実装によって共有されるが、複数のプロトコルの実装によって共有されるだけでなく、設計することができます。
The framework incorporates interfaces with both protocols and mechanisms in which authentication exchanges are carried out. Section 3 discusses SASL authentication exchanges.
フレームワークは、認証交換が行われた両方のプロトコル及びメカニズムとのインタフェースを内蔵しています。第3節ではSASL認証交換を説明します。
To use SASL, each protocol (amongst other items) provides a method for identifying which mechanism is to be used, a method for exchange of mechanism-specific server-challenges and client-responses, and a method for communicating the outcome of the authentication exchange. Section 4 discusses SASL protocol requirements.
SASLを使用するように、（他の項目の中で）各プロトコルが、使用されるべきメカニズム機構固有のサーバーチャレンジとクライアント応答の交換のための方法を同定するための方法を提供し、認証交換の結果を通信する方法。第4節では、SASLプロトコルの要件について説明します。
Each SASL mechanism defines (amongst other items) a series of server-challenges and client-responses that provide authentication services and negotiate data security services. Section 5 discusses SASL mechanism requirements.
（その他の項目の中で）各SASLメカニズムの定義認証サービスを提供し、データのセキュリティサービスを交渉するサーバ挑戦とクライアント一連の応答。第5節ではSASLメカニズムの要件について説明します。
Section 6 discusses security considerations. Section 7 discusses IANA considerations. Appendix A defines the SASL EXTERNAL mechanism.
第6節は、セキュリティ上の考慮事項について説明します。第7節は、IANAの考慮事項について説明します。付録Aは、SASL EXTERNALメカニズムを定義します。
This document is written to serve several different audiences:
この文書は、いくつかの異なる観客にサービスを提供するために書かれています：
- protocol designers using this specification to support authentication in their protocol,
- プロトコル設計者が自分のプロトコルで認証をサポートするために、この仕様を使用して、
- mechanism designers that define new SASL mechanisms, and
- 新しいSASLメカニズムを定義する機構設計者、および
- implementors of clients or servers for those protocols that support SASL.
- SASLをサポートするプロトコル用のクライアントまたはサーバの実装。
While the document organization is intended to allow readers to focus on details relevant to their engineering, readers are encouraged to read and understand all aspects of this document.
文書組織は、読者が自分のエンジニアリングに関連する詳細情報に集中できるように意図されている間、読者は、この文書のすべての側面を読んで理解することをお勧めします。
This document obsoletes RFC 2222. It replaces all portions of RFC 2222 excepting sections 7.1 (the KERBEROS_IV mechanism), 7.2 (the GSSAPI mechanism), 7.3 (the SKEY mechanism). The KERBEROS_IV and SKEY mechanisms are now viewed as obsolete and their specifications provided in RFC 2222 are Historic. The GSSAPI mechanism is now separately specified [SASL-GSSAPI].
このドキュメントは、セクション7.1（KERBEROS_IV機構）、7.2（GSSAPIメカニズム）、7.3（SKEY機構）を除いてRFC 2222の全ての部分を置換RFC 2222を時代遅れ。 KERBEROS_IVとSKEYメカニズムは廃止と見ていると、RFC 2222で提供その仕様は、歴史あります。 GSSAPIメカニズムは現在別々に指定されている[SASL-GSSAPI]。
Appendix B provides a summary of changes since RFC 2222.
付録Bは、RFC 2222からの変更の概要を示します。
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 BCP 14 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14 [RFC2119]に記載されているように解釈されます。
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
この文書における文字の名前は、Unicode標準[UNICODE]のコードポイントと名の表記を使用します。例えば、文字 "は" <LATIN SMALL LETTER A> <U + 0061>のいずれかとして表されてもよいです。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
注：Unicodeで使用される用語の用語集は、[用語]に見出すことができます。 Unicode文字エンコーディングモデルに関する情報は、[CharModel]で見つけることができます。
In examples, "C:" and "S:" indicate lines of data to be sent by the client and server, respectively. Lines have been wrapped for improved readability.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されるデータの行を示します。行は読みやすくするためにラップされています。
In practice, authentication and authorization may involve multiple identities, possibly in different forms (simple username, Kerberos principal, X.500 Distinguished Name, etc.), possibly with different representations (e.g., ABNF-described UTF-8 encoded Unicode character string, BER-encoded Distinguished Name). While technical specifications often prescribe both the identity form and representation used on the network, different identity forms and/or representations may be (and often are) used within implementations. How identities of different forms relate to each other is, generally, a local matter. In addition, the forms and representations used within an implementation are a local matter.
実際には、認証と認可はおそらく異なる表現（例で、おそらく異なる形（などの単純なユーザー名、Kerberosプリンシパル、X.500識別名）で、複数のアイデンティティを伴うことが、ABNF説明したUTF-8は、Unicode文字列をエンコードBERエンコードされた識別名）。技術仕様は、多くの場合、ネットワーク上で使用される同一の形態及び表現の両方を規定しながら、異なるアイデンティティ形態及び/又は表現であってもよい（しばしばされる）の実装内で使用されます。どのように異なる形式のアイデンティティが相互に関係することは、一般的に、ローカルの問題です。また、実装内で使用されるフォームや表現はローカルの問題です。
However, conceptually, the SASL framework involves two identities:
しかし、概念的には、SASLフレームワークは、2人のアイデンティティが含まれます。
1) an identity associated with the authentication credentials (termed the authentication identity), and
1）認証証明書に関連付けられたアイデンティティは（認証IDと呼ばれる）、及び
2) an identity to act as (termed the authorization identity).
2）として機能するアイデンティティは、（）認可IDと呼ばれます。
SASL mechanism specifications describe the credential form(s) (e.g., X.509 certificates, Kerberos tickets, simple username/password) used to authenticate the client, including (where appropriate) the syntax and semantics of authentication identities carried in the credentials. SASL protocol specifications describe the identity form(s) used in authorization and, in particular, prescribe the syntax and semantics of the authorization identity character string to be transferred by mechanisms.
SASLメカニズムの仕様は、資格フォーム（複数可）（例えば、X.509証明書、Kerberosチケット、簡単なユーザー名/パスワード）（該当する場合）の資格情報で運ばれる認証アイデンティティの構文と意味を含めて、クライアントを認証するために使用について説明します。 SASLプロトコル仕様は認証に使用される同一の形態（単数または複数）を記述し、具体的には、機構によって転送される認証アイデンティティ文字列の構文およびセマンティクスを規定します。
The client provides its credentials (which include or imply an authentication identity) and, optionally, a character string representing the requested authorization identity as part of the SASL exchange. When this character string is omitted or empty, the client is requesting to act as the identity associated with the credentials (e.g., the user is requesting to act as the authentication identity).
クライアントは、（includeまたは認証IDを暗示）、必要に応じて、SASL交換の一部として要求された認証アイデンティティを表す文字列を、その資格情報を提供します。この文字列が省略または空されている場合、クライアントは資格証明書（例えば、ユーザーが認証アイデンティティとして動作するように要求している）に関連付けられているアイデンティティとして動作するように要求しています。
The server is responsible for verifying the client's credentials and verifying that the identity it associates with the client's credentials (e.g., the authentication identity) is allowed to act as the authorization identity. A SASL exchange fails if either (or both) of these verifications fails. (The SASL exchange may fail for other reasons, such as service authorization failure.)
サーバーは、クライアントの資格情報を検証し、それがクライアントの資格情報（例えば、認証アイデンティティ）と関連付けアイデンティティが認可IDとして機能することが許可されていることを検証する責任があります。これらの検証のどちらか（あるいは両方）が失敗した場合、SASL交換は失敗します。 （SASL交換は、サービス許可の失敗のような他の理由で失敗することがあります。）
However, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) are beyond the scope of SASL and this specification. In some circumstances, the precise identity forms used in some context outside of the SASL exchange may be dictated by other specifications. For instance, an identity assumption authorization (proxy authorization) policy specification may dictate how authentication and authorization identities are represented in policy statements.
しかし、認証アイデンティティの正確な形態（複数可）（その検証にサーバー内で使用される、またはそれ以外）と（許可の決定を行う際、またはそれ以外で使用される）の認可アイデンティティの正確な形態（複数可）の範囲を超えていますSASL、この仕様。いくつかの状況では、SASL交換の外いくつかの文脈で使用される正確なアイデンティティ形態は、他の仕様によって決定されてもよいです。たとえば、アイデンティティ仮定認証（プロキシ認証）ポリシーの仕様は、認証と承認のアイデンティティがポリシー・ステートメントで表現されている方法を指示することができます。
Each authentication exchange consists of a message from the client to the server requesting authentication via a particular mechanism, followed by one or more pairs of challenges from the server and responses from the client, followed by a message from the server indicating the outcome of the authentication exchange. (Note: exchanges may also be aborted as discussed in Section 3.5.)
各認証交換は、認証の結果を示すサーバーからのメッセージに続いて、クライアントからサーバーと応答からの課題の一つ以上のペアが続く特定の機構を介して認証を要求するクライアントからサーバへのメッセージ、から成り交換。 （注：セクション3.5で議論するように交換も中止されてもよいです。）
The following illustration provides a high-level overview of an authentication exchange.
次の図は、認証交換の高レベルの概要を提供します。
C: Request authentication exchange S: Initial challenge C: Initial response <additional challenge/response messages> S: Outcome of authentication exchange
C：リクエストの認証交換S：初期チャレンジC：初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：認証交換の結果
If the outcome is successful and a security layer was negotiated, this layer is then installed (see Section 3.7). This also applies to the following illustrations.
結果は成功し、セキュリティレイヤが交渉された場合は、この層は、その後（3.7節を参照）がインストールされています。これはまた、次の図に適用されます。
Some mechanisms specify that the first data sent in the authentication exchange is from the client to the server. Protocols may provide an optional initial response field in the request message to carry this data. Where the mechanism specifies that the first data sent in the exchange is from the client to the server, the protocol provides an optional initial response field, and the client uses this field, the exchange is shortened by one round-trip:
いくつかのメカニズムは、認証交換に送られた最初のデータは、クライアントからサーバにあることを指定します。プロトコルは、このデータを伝送するために要求メッセージにオプションの初期応答フィールドを提供することができます。メカニズムは交換で送られた最初のデータは、クライアントからサーバにあることを指定する場合は、プロトコルは、オプションの初期応答場を提供し、クライアントは、交換は1往復だけ短縮され、このフィールドを使用しています。
C: Request authentication exchange + Initial response <additional challenge/response messages> S: Outcome of authentication exchange
C：要求の認証交換+初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：認証交換の結果
Where the mechanism specifies that the first data sent in the exchange is from the client to the server and this field is unavailable or unused, the client request is followed by an empty challenge.
メカニズムは交換で送られた最初のデータは、クライアントからサーバにあることを指定すると、このフィールドが使用できないか、未使用である場合には、クライアントの要求は、空の挑戦が続いています。
C: Request authentication exchange S: Empty Challenge C: Initial Response <additional challenge/response messages> S: Outcome of authentication exchange
C：リクエストの認証交換S：空のチャレンジC：初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：認証交換の結果
Should a client include an initial response in its request where the mechanism does not allow the client to send data first, the authentication exchange fails.
クライアントは、メカニズムは、クライアントが最初にデータを送信することはできません。その要求で初期応答が含まれている必要があり、認証交換が失敗します。
Some mechanisms specify that the server is to send additional data to the client when indicating a successful outcome. Protocols may provide an optional additional data field in the outcome message to carry this data. Where the mechanism specifies that the server is to return additional data with the successful outcome, the protocol provides an optional additional data field in the outcome message, and the server uses this field, the exchange is shortened by one round-trip:
いくつかのメカニズムは、サーバーが成功した結果を示す際に、クライアントに追加のデータを送信することであることを指定します。プロトコルは、このデータを運ぶために結果メッセージに任意の追加のデータフィールドを提供することができます。機構は、サーバーが成功した結果と追加のデータを返すことであることを指定する場合、プロトコルは、結果メッセージに任意の追加のデータフィールドを提供し、サーバは、このフィールドを使用し、交換が1往復することによって短縮されます。
C: Request authentication exchange S: Initial challenge C: Initial response <additional challenge/response messages> S: Outcome of authentication exchange with additional data with success
C：リクエストの認証交換S：初期チャレンジC：初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：成功と追加データとの認証交換の結果
Where the mechanism specifies that the server is to return additional data to the client with a successful outcome and this field is unavailable or unused, the additional data is sent as a challenge whose response is empty. After receiving this response, the server then indicates the successful outcome.
メカニズムは、サーバーが成功した結果をクライアントに追加のデータを返すことであることを指定すると、このフィールドが使用できないか、未使用である場合には、追加のデータは、そのレスポンス空で挑戦として送信されます。この応答を受け取った後、サーバーは、成功した結果を示しています。
C: Request authentication exchange S: Initial challenge C: Initial response <additional challenge/response messages> S: Additional data challenge C: Empty Response S: Outcome of authentication exchange
C：リクエストの認証交換S：初期チャレンジC：初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：追加データのチャレンジC：空のレスポンスS：認証交換の結果
Where mechanisms specify that the first data sent in the exchange is from the client to the server and additional data is sent to the client along with indicating a successful outcome, and the protocol provides fields supporting both, then the exchange takes two fewer round-trips:
メカニズムは交換で送信された最初のデータは、成功した結果を示すとともに、クライアントに送信され、プロトコルの両方をサポートするフィールドを提供しているクライアントからサーバ及び追加データであり、次いで、交換が2少ないラウンドトリップを取るように指定場所：
C: Request authentication exchange + Initial response <additional challenge/response messages> S: Outcome of authentication exchange with additional data with success
C：要求の認証交換+初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：成功と追加データとの認証交換の結果
instead of:
の代わりに：
C: Request authentication exchange S: Empty Challenge C: Initial Response <additional challenge/response messages> S: Additional data challenge C: Empty Response S: Outcome of authentication exchange
C：リクエストの認証交換S：空のチャレンジC：初期レスポンス<追加のチャレンジ/レスポンスメッセージ> S：追加データのチャレンジC：空のレスポンスS：認証交換の結果
SASL mechanisms are named by character strings, from 1 to 20 characters in length, consisting of ASCII [ASCII] uppercase letters, digits, hyphens, and/or underscores. In the following Augmented Backus-Naur Form (ABNF) [RFC4234] grammar, the <sasl-mech> production defines the syntax of a SASL mechanism name.
SASL機構はASCII [ASCII]大文字、数字、ハイフン、および/またはアンダーからなる、長さが1〜20文字、文字列によって指定されています。以下た拡張バッカスナウア記法（ABNF）[RFC4234]の文法では、<SASL-メック>生産はSASL機構名の構文を定義します。
sasl-mech = 1*20mech-char mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ ; from ASCII character set.
SASL-メック= 1 * 20mech-チャーメカ-チャー= UPPER-ALPHA / DIGIT /ハイフン/ UNDERSCORE。メカ-チャーは、-Z（大文字のみ）、0-9に制限され - 、および_。 ASCII文字セットから。
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only) DIGIT = %x30-39 ; 0-9 HYPHEN = %x2D ; hyphen (-) UNDERSCORE = %x5F ; underscore (_)
UPPER-ALPHA =％x41-5A。 -Z（大文字のみ）DIGIT =％x30-39。 0-9 HYPHEN =％x2D。ハイフン（ - ）アンダー=％x5F。アンダースコア（_）
SASL mechanism names are registered as discussed in Section 7.1.
7.1節で述べたようにSASLメカニズム名が登録されています。
Mechanism negotiation is protocol specific.
メカニズム交渉は、プロトコル固有のものです。
Commonly, a protocol will specify that the server advertises supported and available mechanisms to the client via some facility provided by the protocol, and the client will then select the "best" mechanism from this list that it supports and finds suitable.
一般的に、プロトコルは、サーバがプロトコルによって提供されるいくつかの施設を介してクライアントにサポートして利用できる仕組みをアドバタイズするように指定し、クライアントは、それがサポートしていると、適切な検索します。このリストから、「最良の」メカニズムを選択します。
Note that the mechanism negotiation is not protected by the subsequent authentication exchange and hence is subject to downgrade attacks if not protected by other means.
機構のネゴシエーションがその後の認証交換によって保護され、従って、他の手段によって保護されていない場合は攻撃をダウングレードする対象とされていないことに留意されたいです。
To detect downgrade attacks, a protocol can allow the client to discover available mechanisms subsequent to the authentication exchange and installation of data security layers with at least data integrity protection. This allows the client to detect changes to the list of mechanisms supported by the server.
ダウングレード攻撃を検出するために、プロトコルは、クライアントが、少なくともデータの整合性の保護とデータセキュリティ層の認証交換して、インストール後に利用可能なメカニズムを発見できるようにすることができます。これは、クライアントがサーバでサポートされているメカニズムのリストへの変更を検出することができます。
The authentication exchange is initiated by the client by requesting authentication via a mechanism it specifies. The client sends a message that contains the name of the mechanism to the server. The particulars of the message are protocol specific.
認証交換は、それが指定するメカニズムを介して認証を要求することにより、クライアントによって開始されます。クライアントは、サーバーへのメカニズムの名前を含むメッセージを送信します。メッセージの詳細は、プロトコル固有のものです。
Note that the name of the mechanism is not protected by the mechanism, and hence is subject to alteration by an attacker if not integrity protected by other means.
機構の名前はメカニズムによって保護されていないことに注意し、それゆえ、攻撃者によって改ざんならない他の手段によって保護された整合性の対象です。
Where the mechanism is defined to allow the client to send data first, and the protocol's request message includes an optional initial response field, the client may include the response to the initial challenge in the authentication request message.
メカニズムは、クライアントが最初にデータを送信できるようにするために定義され、プロトコルのリクエストメッセージは、オプションの初期応答フィールドを含んでいる場合は、クライアントは、認証要求メッセージの最初のチャレンジに対する応答を含むことができます。
The authentication exchange involves one or more pairs of server-challenges and client-responses, the particulars of which are mechanism specific. These challenges and responses are enclosed in protocol messages, the particulars of which are protocol specific.
認証交換は、サーバ挑戦とクライアントの応答の一つ以上のペア、機構固有であるの細目を含んでいます。これらの課題と応答がプロトコルメッセージで囲まれ、詳細はそのプロトコル固有のものです。
Through these challenges and responses, the mechanism may:
これらの課題と応答を通じて、メカニズムがあります。
- authenticate the client to the server,
- サーバにクライアントを認証し、
- authenticate the server to the client,
- クライアントにサーバーを認証し、
- transfer an authorization identity string,
- 認証アイデンティティ文字列を転送し、
- negotiate a security layer, and
- セキュリティ層を交渉し、
- provide other services.
- 他のサービスを提供しています。
The negotiation of the security layer may involve negotiation of the security services to be provided in the layer, how these services will be provided, and negotiation of a maximum cipher-text buffer size each side is able to receive in the layer (see Section 3.6).
セキュリティ層の交渉は、これらのサービスが提供されるか、層内に提供されるセキュリティサービスのネゴシエーションを含み、最大暗号テキストバッファサイズのネゴシエーションできる各側は、層（セクション3.6で受信することができます）。
After receiving an authentication request or any client response, the server may issue a challenge, abort the exchange, or indicate the outcome of an exchange. After receiving a challenge, a client mechanism may issue a response or abort the exchange.
認証要求または任意のクライアント応答を受け取った後、挑戦を発行することができるサーバは、交換を中止、またはExchangeの結果を示しています。挑戦を受けた後、クライアント機構は、応答を発行または交換を中止することがあります。
The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as.
認証アイデンティティ文字列は、として機能するアイデンティティを表すNUL（U + 0000）文字を除いた、ゼロ以上のUnicode [UNICODE]文字のシーケンスです。
If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. An empty string is equivalent to an absent authorization identity.
認証アイデンティティ文字列が存在しない場合、クライアントはアイデンティティとして、クライアントの資格情報を使用して、サーバーの仲間を動作するように要求しています。空の文字列は存在しない認証アイデンティティに相当します。
A non-empty authorization identity string indicates that the client wishes to act as the identity represented by the string. In this case, the form of identity represented by the string, as well as the precise syntax and semantics of the string, is protocol specific.
空でない認証アイデンティティ文字列は、クライアントが文字列で表さアイデンティティとして動作するように望んでいることを示しています。この場合、文字列で表される同一の形態、ならびにストリングの正確な構文およびセマンティクスは、プロトコル固有です。
While the character encoding schema used to transfer the authorization identity string in the authentication exchange is mechanism specific, mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character).
認証交換における認証アイデンティティ文字列を転送するために使用される文字エンコーディングスキーマ機構特異的であるが、機構は（NUL文字を除く）全ユニコードレパートリーを運ぶことができることが期待されます。
A client or server may desire to abort an authentication exchange if it is unwilling or unable to continue (or enter into).
クライアントまたはサーバが、それは不本意または継続（またはに入る）ことができない場合は認証交換を中止することを望むかもしれません。
A client may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the server, indicating that the exchange is aborted. The server may be required by the protocol to return a message in response to the client's abort message.
クライアントは、交換が中止されたことを示す、サーバに、プロトコル固有であるの詳細をメッセージを送信して認証交換を中止することができます。サーバは、クライアントのアボートメッセージに応答して、メッセージを返すために、プロトコルによって必要となる場合があります。
Likewise, a server may abort the authentication exchange by sending a message, the particulars of which are protocol specific, to the client, indicating that the exchange is aborted.
同様に、サーバは、交換が中止されたことを示す、クライアントに、プロトコル固有であるの詳細をメッセージを送信して認証交換を中止することができます。
At the conclusion of the authentication exchange, the server sends a message, the particulars of which are protocol specific, to the client indicating the outcome of the exchange.
認証交換の終了時に、サーバーは、Exchangeの結果を示すクライアントに、メッセージ、プロトコル固有であるの詳細を送信します。
The outcome is not successful if
結果は成功した場合ではありません
- the authentication exchange failed for any reason,
- 認証交換は、何らかの理由で失敗しました
- the client's credentials could not be verified,
- クライアントの資格情報を確認することができませんでした、
- the server cannot associate an identity with the client's credentials,
- サーバーがクライアントの資格情報を使用してIDを関連付けることはできません、
- the client-provided authorization identity string is malformed,
- クライアントが提供する認証アイデンティティ文字列は、不正な形式です
- the identity associated with the client's credentials is not authorized to act as the requested authorization identity,
- クライアントの資格情報に関連付けられているアイデンティティは、要求された認証アイデンティティとして動作するように許可されていません
- the negotiated security layer (or lack thereof) is not suitable, or
- ネゴシエートされたセキュリティ層（またはその欠如）が適していない、または
- the server is not willing to provide service to the client for any reason.
- サーバが何らかの理由でクライアントにサービスを提供して喜んではありません。
The protocol may include an optional additional data field in this outcome message. This field can only include additional data when the outcome is successful.
プロトコルは、この結果メッセージ内の任意の追加データフィールドを含むことができます。結果が成功した場合、このフィールドは唯一の追加データを含むことができます。
If the outcome is successful and a security layer was negotiated, this layer is then installed. If the outcome is unsuccessful, or a security layer was not negotiated, any existing security is left in place.
結果は成功し、セキュリティレイヤが交渉された場合は、この層がインストールされています。結果が失敗した場合、またはセキュリティ層がネゴシエートされなかった場合は、既存のセキュリティは、その場に残されています。
The outcome message provided by the server can provide a way for the client to distinguish between errors that are best dealt with by re-prompting the user for her credentials, errors that are best dealt with by telling the user to try again later, and errors where the user must contact a system administrator for resolution (see the SYS and AUTH POP Response Codes [RFC3206] specification for an example). This distinction is particularly useful during scheduled server maintenance periods as it reduces support costs. It is also important that the server can be configured such that the outcome message will not distinguish between a valid user with invalid credentials and an invalid user.
サーバが提供する成果のメッセージは、クライアントが最高の彼女の資格情報、最高後で再試行するユーザーに伝えることによって対処されたエラー、エラーについては、再プロンプトユーザーによって対処されたエラーを区別するための方法を提供することができますユーザは、解決のため、システム管理者に連絡しなければならない場合（例えばSYSとAUTHポップ応答コード[RFC3206]の仕様を参照）。この区別は、サポートコストを削減としてスケジュールサーバメンテナンス期間中に特に便利です。サーバーが結果メッセージが無効な資格情報を持つ有効なユーザーと無効なユーザを区別しないように設定することができることも重要です。
SASL mechanisms may offer a wide range of services in security layers. Typical services include data integrity and data confidentiality. SASL mechanisms that do not provide a security layer are treated as negotiating no security layer.
SASLメカニズムは、セキュリティ層に幅広いサービスを提供することがあります。典型的なサービスは、データの整合性とデータの機密性が含まれます。セキュリティレイヤを提供していないSASLメカニズムには、セキュリティ層を交渉していないものとして扱われています。
If use of a security layer is negotiated in the authentication protocol exchange, the layer is installed by the server after indicating the outcome of the authentication exchange and installed by the client upon receipt of the outcome indication. In both cases, the layer is installed before transfer of further protocol data. The precise position upon which the layer takes effect in the protocol data stream is protocol specific.
セキュリティ層の使用は、認証プロトコル交換で交渉される場合、層は、認証交換の結果を示した後に、サーバでインストールおよび結果指示を受信すると、クライアントがインストールされています。両方の場合において、層は、プロトコルデータの転送の前に設置されています。層プロトコル・データ・ストリームに有効になり、その上に正確な位置は、プロトコル固有です。
Once the security layer is in effect in the protocol data stream, it remains in effect until either a subsequently negotiated security layer is installed or the underlying transport connection is closed.
セキュリティ層はプロトコル・データ・ストリームに有効になると、それは続いてネゴシエートセキュリティ層のいずれかがインストールされるまで有効のままで、または基礎となるトランスポート接続が閉じられます。
When in effect, the security layer processes protocol data into buffers of protected data. If at any time the security layer is unable or unwilling to continue producing buffers protecting protocol data, the underlying transport connection MUST be closed. If the security layer is not able to decode a received buffer, the underlying connection MUST be closed. In both cases, the underlying transport connection SHOULD be closed gracefully.
ときに有効で、セキュリティ層は、保護されたデータのバッファにプロトコルデータを処理します。いつでもセキュリティ層はプロトコルのデータを保護するバッファを生産継続が不可能または不本意である場合には、基礎となるトランスポート接続をクローズする必要があります。セキュリティ層は、受信バッファをデコードできない場合、基礎となる接続が閉じられなければなりません。どちらの場合も、基礎となるトランスポート接続が正常に閉じれるべきです。
Each buffer of protected data is transferred over the underlying transport connection as a sequence of octets prepended with a four-octet field in network byte order that represents the length of the buffer. The length of the protected data buffer MUST be no larger than the maximum size that the other side expects. Upon the receipt of a length field whose value is greater than the maximum size, the receiver SHOULD close the connection, as this might be a sign of an attack.
保護されたデータの各バッファは、バッファの長さを表すネットワークバイト順の4オクテットフィールドに付加オクテットのシーケンスとして、基礎となるトランスポート接続を介して転送されます。保護されたデータバッファの長さは、他の側が期待する最大サイズよりも大きくてはなりません。これは攻撃の徴候であるかもしれないように値の最大サイズよりも大きい長さフィールドを受信すると、受信機は、接続を閉じる必要があります。
The maximum size that each side expects is fixed by the mechanism, either through negotiation or by its specification.
各側が期待する最大サイズは、交渉を介して、またはその仕様のいずれかによって、機構によって固定されています。
Unless explicitly permitted in the protocol (as stated in the protocol's technical specification), only one successful SASL authentication exchange may occur in a protocol session. In this case, once an authentication exchange has successfully completed, further attempts to initiate an authentication exchange fail.
（プロトコルの技術仕様書に記載されているように）明示的にプロトコルで許可されていない限り、一つだけ成功したSASL認証交換は、プロトコルセッション中に発生する可能性があります。この場合、一度認証交換は成功、失敗した認証交換を開始するためのさらなる試みを完了しました。
Where multiple successful SASL authentication exchanges are permitted in the protocol, then in no case may multiple SASL security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect.
複数成功したSASL認証交換をプロトコルで許可されている場合、その後、いかなる場合にも、複数のSASLセキュリティ層は、実質的に同時であってもよいです。セキュリティ層が有効であり、その後のSASL交渉が第2のセキュリティ層を選択した場合、第2のセキュリティ層は、第1に取って代わります。セキュリティ層が有効であると、その後のSASL交渉はセキュリティ層を選択しなかった場合は、元のセキュリティ層が有効になっています。
Where multiple successful SASL negotiations are permitted in the protocol, the effect of a failed SASL authentication exchange upon the previously established authentication and authorization state is protocol specific. The protocol's technical specification should be consulted to determine whether the previous authentication and authorization state remains in force, or changed to an anonymous state, or otherwise was affected. Regardless of the protocol-specific effect upon previously established authentication and authorization state, the previously negotiated security layer remains in effect.
複数の成功SASL交渉は、プロトコルに許可されている場合は、以前に確立された認証と承認の状態時に失敗したSASL認証交換の効果は、特定のプロトコルです。プロトコルの技術仕様は、以前の認証と承認の状態は力に残っているかどうかを決定するために相談、または匿名の状態に変更、またはその他の影響を受けたことがなければなりません。かかわらず、以前に確立された認証および許可状態にプロトコル特有の効果の、以前にネゴシエートされたセキュリティ層が有効のままです。
In order for a protocol to offer SASL services, its specification MUST supply the following information:
SASLサービスを提供するプロトコルのために、その仕様は、以下の情報を入力する必要があります。
1) A service name, to be selected from registry of "service" elements for the Generic Security Service Application Program Interface (GSSAPI) host-based service name form, as described in Section 4.1 of [RFC2743]. Note that this registry is shared by all GSSAPI and SASL mechanisms.
1）サービス名を、[RFC2743]のセクション4.1に記載されているように、汎用セキュリティサービスアプリケーションプログラムインタフェース（GSSAPI）ホストベースのサービス名フォームの「サービス」要素のレジストリから選択されます。このレジストリは、すべてのGSSAPIとSASLメカニズムによって共有されていることに注意してください。
2) Detail any mechanism negotiation facility that the protocol provides (see Section 3.2).
2）詳細プロトコルを提供する任意の機構ネゴシエーション機能（セクション3.2を参照）。
A protocol SHOULD specify a facility through which the client may discover, both before initiation of the SASL exchange and after installing security layers negotiated by the exchange, the names of the SASL mechanisms that the server makes available to the client. The latter is important to allow the client to detect downgrade attacks. This facility is typically provided through the protocol's extensions or capabilities discovery facility.
プロトコルは、クライアントが発見できるそこを通って施設を指定する必要SASL交換の開始前と交換によってネゴシエートセキュリティ層をインストールした後、両方のサーバがクライアントに提供するSASLメカニズムの名前。後者は、クライアントがダウングレード攻撃を検出できるようにすることが重要です。この施設は、通常、プロトコルの拡張や機能の発見機能を介して提供されます。
3) Definition of the messages necessary for authentication exchange, including the following: a) A message to initiate the authentication exchange (see Section 3.3).
3）以下を含む、認証交換のために必要なメッセージの定義：認証交換を開始するA）メッセージ（セクション3.3を参照）。
This message MUST contain a field for carrying the name of the
mechanism selected by the client.
This message SHOULD contain an optional field for carrying an initial response. If the message is defined with this field, the specification MUST describe how messages with an empty initial response are distinguished from messages with no initial response. This field MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets).
このメッセージは、初期応答を運ぶためのオプションのフィールドを含むべきです。メッセージは、このフィールドで定義されている場合、仕様は空の初期応答を持つメッセージはありません最初の応答とメッセージとは区別される方法を説明しなければなりません。このフィールドは、（ゼロ値のオクテットを含むゼロ長配列と配列を含む）のオクテットの任意のシーケンスを運ぶことができなければなりません。
b) Messages to transfer server challenges and client responses (see Section 3.4).
b）は、サーバー上の課題とクライアントの応答を転送するメッセージを（3.4節を参照してください）。
Each of these messages MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets).
これらのメッセージの各々は、（ゼロ値のオクテットを含むゼロ長配列と配列を含む）のオクテットの任意のシーケンスを運ぶことができなければなりません。
c) A message to indicate the outcome of the authentication exchange (see Section 3.6).
C）認証交換の結果を示すメッセージを（セクション3.6を参照）。
This message SHOULD contain an optional field for carrying additional data with a successful outcome. If the message is defined with this field, the specification MUST describe how messages with an empty additional data are distinguished from messages with no additional data. This field MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets).
このメッセージは、成功した結果で追加データを運ぶためのオプションのフィールドを含むべきです。メッセージは、このフィールドで定義されている場合、仕様が空の追加データとのメッセージがいない追加データを持つメッセージは区別されどのように説明しなければなりません。このフィールドは、（ゼロ値のオクテットを含むゼロ長配列と配列を含む）のオクテットの任意のシーケンスを運ぶことができなければなりません。
4) Prescribe the syntax and semantics of non-empty authorization identity strings (see Section 3.4.1).
4）（3.4.1項を参照）構文と非空の認証アイデンティティ文字列の意味を規定しています。
In order to avoid interoperability problems due to differing normalizations, the protocol specification MUST detail precisely how and where (client or server) non-empty authorization identity strings are prepared, including all normalizations, for comparison and other applicable functions to ensure proper function.
違いによる正規化への相互運用性の問題を避けるために、プロトコル仕様MUSTの詳細は、正確にどのように、どこで（クライアントまたはサーバ）空でない認証アイデンティティ文字列は適切な機能を確保するために、比較およびその他の適用可能な機能のために、すべての正規化を含む、用意されています。
Specifications are encouraged to prescribe use of existing authorization identity forms as well as existing string representations, such as simple user names [RFC4013].
仕様は、既存の認証アイデンティティ形の使用ならびにこのような簡単なユーザ名[RFC4013]などの既存の文字列表現を、処方することが奨励されています。
Where the specification does not precisely prescribe how identities in SASL relate to identities used elsewhere in the protocol, for instance, in access control policy statements, it may be appropriate for the protocol to provide a facility by which the client can discover information (such as the representation of the identity used in making access control decisions) about established identities for these uses.
仕様は正確SASLにおけるアイデンティティプロトコルの他の場所で使用されるIDに関連する方法を規定しない場合、プロトコルは、クライアントが情報を発見することが可能な機能を提供するために、例えば、アクセス制御ポリシー・ステートメントで、それが適切であり得る（例えば、これらの用途のために設立されアイデンティティに関するアクセス制御の決定を行う際に使用されるアイデンティティの表現）。
5) Detail any facility the protocol provides that allows the client and/or server to abort authentication exchange (see Section 3.5).
5）詳細は、プロトコルが提供するすべての施設が、それは、クライアントおよび/またはサーバが認証交換を（3.5節を参照）を中止することができます。
Protocols that support multiple authentications typically allow a client to abort an ongoing authentication exchange by initiating a new authentication exchange. Protocols that do not support multiple authentications may require the client to close the connection and start over to abort an ongoing authentication exchange.
複数の認証をサポートするプロトコルは、通常、クライアントは新しい認証交換を開始することにより、継続的な認証交換を中止することができます。複数の認証をサポートしていないプロトコルは、接続を閉じて、継続的な認証交換を中止して最初からやり直すためにクライアントが必要な場合があります。
Protocols typically allow the server to abort ongoing authentication exchanges by returning a non-successful outcome message.
プロトコルは通常、サーバーが非成功した結果メッセージを返すことにより、継続的な認証交換を中止することができます。
6) Identify precisely where newly negotiated security layers start to take effect, in both directions (see Section 3.7).
新たにネゴシエートセキュリティ層が両方向（セクション3.7を参照）で、有効にする開始場所6）正確に特定します。
Typically, specifications require security layers to start taking effect on the first octet following the outcome message in data being sent by the server and on the first octet sent after receipt of the outcome message in data being sent by the client.
一般的に、仕様は、サーバによって、クライアントによって送信されたデータに結果メッセージを受信した後に送られた最初のオクテットで送信されるデータで、結果メッセージに続く最初のオクテットに影響を取り始めるために、セキュリティの層を必要とします。
7) If the protocol supports other layered security services, such as Transport Layer Security (TLS) [RFC4346], the specification MUST prescribe the order in which security layers are applied to protocol data.
7）プロトコルは、トランスポート層セキュリティ（TLS）[RFC4346]などの他の階層型セキュリティサービスをサポートしている場合、仕様は、セキュリティ層はプロトコル・データに適用される順序を規定しなければなりません。
For instance, where a protocol supports both TLS and SASL security layers, the specification could prescribe any of the following:
プロトコルは、TLSとSASLセキュリティ層の両方をサポートする場合、例えば、本明細書は、次のいずれかを規定できます。
a) SASL security layer is always applied first to data being sent and, hence, applied last to received data,
A）SASLセキュリティ層は常に、送信されるデータに最初に適用さと、従って、受信したデータに最後に適用されます
b) SASL security layer is always applied last to data being sent and, hence, applied first to received data,
B）SASLセキュリティ層が常に送信されるデータの最後の適用と、それゆえ、受信されたデータに最初に適用され、
c) Layers are applied in the order in which they were installed,
C）層がそれらがインストールされた順序で適用され、
d) Layers are applied in the reverse order in which they were installed, or
D）層は、それらがインストールされた逆の順序で適用され、又は
e) Both TLS and SASL security layers cannot be installed.
E）TLSとSASLセキュリティ層の両方をインストールすることはできません。
8) Indicate whether the protocol supports multiple authentications (see Section 3.8). If so, the protocol MUST detail the effect a failed SASL authentication exchange will have upon a previously established authentication and authorization state.
8）（セクション3.8を参照）プロトコルは、複数の認証をサポートするかどうかを指定。その場合は、プロトコルのMUSTの詳細な効果は、失敗したSASL認証交換は、以前に確立された認証と承認の状態になります。
Protocol specifications SHOULD avoid stating implementation requirements that would hinder replacement of applicable mechanisms. In general, protocol specifications SHOULD be mechanism neutral. There are a number of reasonable exceptions to this recommendation, including
プロトコル仕様は、適用メカニズムの交換を妨げる実装要件を明記することは避けてください。一般的には、プロトコル仕様はメカニズム中立であるべきです。合理的な例外の数には、この勧告にあります。
- detailing how credentials (which are mechanism specific) are managed in the protocol,
- （メカニズム固有のもの）の資格情報は、プロトコルで管理されている方法を詳述し、
- detailing how authentication identities (which are mechanism specific) and authorization identities (which are protocol specific) relate to each other, and
- 、（機構特異的である）の認証IDおよび（プロトコル特異的である）許可アイデンティティが互いにどのように関係するかを詳細と
- detailing which mechanisms are applicable to the protocol.
- その詳細メカニズムは、プロトコルに適用可能です。
SASL mechanism specifications MUST supply the following information:
SASLメカニズムの仕様は、以下の情報を入力する必要があります。
1) The name of the mechanism (see Section 3.1). This name MUST be registered as discussed in Section 7.1.
1）メカニズムの名前を（3.1節を参照してください）。セクション7.1で説明したように、この名前を登録する必要があります。
2) A definition of the server-challenges and client-responses of the authentication exchange, as well as the following:
2）サーバ挑戦と認証交換のクライアント応答の定義だけでなく、次のとおりです。
a) An indication of whether the mechanism is client-first, variable, or server-first. If a SASL mechanism is defined as client-first and the client does not send an initial response in the authentication request, then the first server challenge MUST be empty (the EXTERNAL mechanism is an example of this case). If a SASL mechanism is defined as variable, then the specification needs to state how the server behaves when the initial client response in the authentication request is omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case). If a SASL mechanism is defined as server-first, then the client MUST NOT send an initial client response in the authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an example of this case).
A）メカニズムがクライアント最初、変数、またはサーバー最初であるか否かの指示を。 SASL機構がクライアント第として定義され、クライアントが認証要求で初期応答を送信しない場合、最初のサーバの課題は空である必要があります（外部機構は、この場合の一例です）。 SASL機構は変数として定義されている場合、明細書は、認証要求に初期クライアント応答が省略されているときに、サーバーがどのように動作するかを述べる必要がある（DIGEST-MD5機構は、[DIGEST-MD5は、この場合の一例です）。 SASL機構はサーバー最初として定義されている場合、クライアントは、認証要求（CRAM-MD5メカニズム[CRAM-MD5が、この場合の例である）で初期クライアントレスポンスを送ってはいけません。
b) An indication of whether the server is expected to provide additional data when indicating a successful outcome. If so, if the server sends the additional data as a challenge, the specification MUST indicate that the response to this challenge is an empty response.
b）は、サーバーが成功した結果を示す場合、追加のデータを提供することが期待されているかどうかの指示。その場合は、サーバーが課題として追加データを送信する場合、仕様はこの課題への応答が空の応答であることを示す必要があります。
SASL mechanisms SHOULD be designed to minimize the number of challenges and responses necessary to complete the exchange.
SASLメカニズムは、交換を完了するために必要なチャレンジとレスポンスの数を最小限に抑えるように設計する必要があります。
3) An indication of whether the mechanism is capable of transferring authorization identity strings (see Section 3.4.1). While some legacy mechanisms are incapable of transmitting an authorization identity (which means that for these mechanisms, the authorization identity is always the empty string), newly defined mechanisms SHOULD be capable of transferring authorization identity strings. The mechanism SHOULD NOT be capable of transferring both no authorization identity string and an empty authorization identity.
3）メカニズムは認証アイデンティティ文字列を転送することができるかどうかの指示を（セクション3.4.1を参照）。いくつかの従来の機構が認可ID（これらのメカニズムのために、認可アイデンティティが常に空の文字列であることを意味する）を送信することができないが、新たに定義されたメカニズムは、認証アイデンティティ文字列を転送することができなければなりません。メカニズムには認証アイデンティティ文字列と空の認可IDの両方を転送しない可能べきではありません。
Mechanisms that are capable of transferring an authorization identity string MUST be capable of transferring arbitrary non-empty sequences of Unicode characters, excluding those that contain the NUL (U+0000) character. Mechanisms SHOULD use the UTF-8 [RFC3629] transformation format. The specification MUST detail how any Unicode code points special to the mechanism that might appear in the authorization identity string are escaped to avoid ambiguity during decoding of the authorization identity string. Typically, mechanisms that have special characters require these special characters to be escaped or encoded in the character string (after encoding it in a particular Unicode transformation format) using a data encoding scheme such as Base64 [RFC3548].
認証アイデンティティ文字列を転送することができるメカニズムは、NUL（U + 0000）文字を含むものを除く、Unicode文字の任意の非空のシーケンスを転送することができなければなりません。メカニズムは、UTF-8 [RFC3629]変換フォーマットを使用すべきです。認証アイデンティティ文字列に表示される場合がありますメカニズムに特別な任意のUnicodeコードポイントは認証アイデンティティ文字列のデコード時にあいまいさを避けるためにエスケープされている方法を仕様MUST詳細。典型的には、特殊文字を持っているメカニズムは、これらの特殊文字は、Base64で、[RFC3548]のようなデータ符号化方式を使用してエスケープまたは（特定のユニコード変換フォーマットで符号化した後）文字列でエンコードされることを必要とします。
4) The specification MUST detail whether the mechanism offers a security layer. If the mechanism does, the specification MUST detail the security and other services offered in the layer as well as how these services are to be implemented.
4）機構は、セキュリティ層を提供するかどうかを指定MUST詳細。メカニズムがない場合、仕様MUST詳細セキュリティとこれらのサービスがどのようにだけでなく、層で提供される他のサービスが実装されます。
5) If the underlying cryptographic technology used by a mechanism supports data integrity, then the mechanism specification MUST integrity protect the transmission of an authorization identity and the negotiation of the security layer.
メカニズムによって使用される基本的な暗号化技術は、データの整合性をサポートしている場合5）、その後、機構仕様MUSTの整合性は、認証アイデンティティとセキュリティ層の交渉の伝送を保護します。
SASL mechanisms SHOULD be protocol neutral.
SASLメカニズムは、プロトコル中立であるべきです。
SASL mechanisms SHOULD reuse existing credential and identity forms, as well as associated syntaxes and semantics.
SASLメカニズムは、既存の資格と身元形態、ならびに関連する構文とセマンティクスを再利用する必要があります。
SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] for encoding Unicode [Unicode] code points for transfer.
SASLメカニズムは、転送のためにユニコード[UNICODE]コードポイントを符号化するためのUTF-8変換形式[RFC3629]を使用すべきです。
In order to avoid interoperability problems due to differing normalizations, when a mechanism calls for character data (other than the authorization identity string) to be used as input to a cryptographic and/or comparison function, the specification MUST detail precisely how and where (client or server) the character data is to be prepared, including all normalizations, for input into the function to ensure proper operation.
メカニズムは、文字データを要求する際の暗号化および/または比較関数への入力として使用される（認証アイデンティティ文字列を除く）、異なる正規化による相互運用性の問題を回避するためには、仕様MUSTの詳細を正確どのように、どこで（クライアントまたはサーバ）文字データが適切な動作を保証するために、関数への入力のために、すべての正規化を含む、調製されるべきです。
For simple user names and/or passwords in authentication credentials, SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation algorithm), SHOULD be specified as the preparation algorithm.
単純なユーザ名および/または認証証明書にパスワードを、SASLprep [RFC4013]（STRINGPREP [RFC3454]準備アルゴリズムのプロファイル）は、準備アルゴリズムとして指定されるべきです。
The mechanism SHOULD NOT use the authorization identity string in generation of any long-term cryptographic keys or hashes as there is no requirement that the authorization identity string be canonical. Long-term, here, means a term longer than the duration of the authentication exchange in which they were generated. That is, as different clients (of the same or different protocol) may provide different authorization identity strings that are semantically equivalent, use of authorization identity strings in generation of cryptographic keys and hashes will likely lead to interoperability and other problems.
認証アイデンティティ文字列が正規の可能要件がないようメカニズムは、任意の長期的な暗号鍵またはハッシュの生成に認証アイデンティティ文字列を使用しないでください。長期的には、ここでは、それらが生成された認証交換の持続時間よりも長い期間を意味します。それは、（同じまたは異なるプロトコルの）異なるクライアントは、意味的に等価である異なる認証アイデンティティ文字列を提供することができるよう、暗号鍵とハッシュの生成における認証アイデンティティ文字列の使用は可能性の高い相互運用性や他の問題につながる、です。
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ中で議論されています。
Many existing SASL mechanisms do not provide adequate protection against passive attacks, let alone active attacks, in the authentication exchange. Many existing SASL mechanisms do not offer security layers. It is hoped that future SASL mechanisms will provide strong protection against passive and active attacks in the authentication exchange, as well as security layers with strong basic data security features (e.g., data integrity and data confidentiality) services. It is also hoped that future mechanisms will provide more advanced data security services like re-keying (see Section 6.3).
多くの既存のSASLメカニズムは、受動的攻撃に対する十分な保護を提供するだけで認証交換に積極的に攻撃をさせてください。多くの既存のSASLメカニズムはセキュリティレイヤを提供していません。将来のSASLメカニズムは強力な基本的なデータセキュリティ機能（例えば、データの整合性とデータの機密性）サービスとの強力な認証交換における受動的および能動的な攻撃からの保護だけでなく、セキュリティの層を提供することが期待されます。また、将来のメカニズムは、再キーイング（6.3節を参照）のような、より高度なデータセキュリティサービスを提供することが期待されます。
Regardless, the SASL framework is susceptible to downgrade attacks. Section 6.1.2 offers a variety of approaches for preventing or detecting these attacks. In some cases, it is appropriate to use data integrity protective services external to SASL (e.g., TLS) to protect against downgrade attacks in SASL. Use of external protective security services is also important when the mechanisms available do not themselves offer adequate integrity and/or confidentiality protection of the authentication exchange and/or protocol data.
かかわらず、SASLフレームワークは、攻撃をダウングレードの影響を受けやすいです。 6.1.2項では、これらの攻撃を防止または検出するための様々なアプローチを提供しています。いくつかのケースでは、SASLでのダウングレード攻撃から保護するためにSASL（例えば、TLS）への外部データの整合性の保護サービスを使用することが適切です。利用可能なメカニズム自体は十分な整合性および/または認証交換および/またはプロトコルデータの機密性保護を提供しない場合は、外部の保護セキュリティサービスの使用も重要です。
When the client selects a SASL security layer with at least integrity protection, this protection serves as a counter-measure against an active attacker hijacking the connection and modifying protocol data sent after establishment of the security layer. Implementations SHOULD close the connection when the security services in a SASL security layer report protocol data report lack of data integrity.
クライアントは、少なくとも完全性保護とSASLセキュリティレイヤを選択すると、この保護は、接続をハイジャックし、セキュリティ層の確立後に送信されるプロトコルデータを変更するアクティブ攻撃に対する対策として役立ちます。実装は、接続時にセキュリティ・サービス、データの整合性のSASLセキュリティレイヤレポートプロトコル・データ・レポートの欠如を閉じる必要があります。
It is important that any security-sensitive protocol negotiations be performed after installation of a security layer with data integrity protection. Protocols should be designed such that negotiations performed prior to this installation should be revalidated after installation is complete. Negotiation of the SASL mechanism is security sensitive.
任意のセキュリティに敏感なプロトコルの交渉は、データの整合性の保護とセキュリティ層のインストール後に実行することが重要です。プロトコルはインストールが完了した後、前にこのインストールを行って交渉が再検証されなければならないように設計されなければなりません。 SASLメカニズムの交渉では、セキュリティに敏感です。
When a client negotiates the authentication mechanism with the server and/or other security features, it is possible for an active attacker to cause a party to use the least secure security services available. For instance, an attacker can modify the server-advertised mechanism list or can modify the client-advertised security feature list within a mechanism response. To protect against this sort of attack, implementations SHOULD NOT advertise mechanisms and/or features that cannot meet their minimum security requirements, SHOULD NOT enter into or continue authentication exchanges that cannot meet their minimum security requirements, and SHOULD verify that completed authentication exchanges result in security services that meet their minimum security requirements. Note that each endpoint needs to independently verify that its security requirements are met.
クライアントは、サーバおよび/または他のセキュリティ機能を備えた認証機構をネゴシエートすると、アクティブ、攻撃者は、当事者が利用できる最も安全なセキュリティ・サービスを使用させるために、それが可能です。例えば、攻撃者がサーバー・宣伝機構リストを変更することができますまたはメカニズム応答内のクライアント・宣伝セキュリティ機能のリストを変更することができます。この種の攻撃から保護するため、実装が彼らの最低限のセキュリティ要件を満たすことができないメカニズムおよび/または機能を宣伝すべきではない、に入るか、その最低限のセキュリティ要件を満たすことができない認証交換を継続し、完成した認証交換がにつながることを確認する必要がありますすべきではありません彼らの最低限のセキュリティ要件を満たすセキュリティサービス。各エンドポイントは、独立してそのセキュリティ要件が満たされていることを確認する必要があることに注意してください。
In order to detect downgrade attacks to the least (or less) secure mechanism supported, the client can discover the SASL mechanisms that the server makes available both before the SASL authentication exchange and after the negotiated SASL security layer (with at least data integrity protection) has been installed through the protocol's mechanism discovery facility. If the client finds that the integrity-protected list (the list obtained after the security layer was installed) contains a stronger mechanism than those in the previously obtained list, the client should assume that the previously obtained list was modified by an attacker and SHOULD close the underlying transport connection.
少なくとも（以下）にダウングレード攻撃を検出するための安全なメカニズムサポートでは、クライアントは、サーバがSASL認証交換前と（少なくともデータの整合性の保護と）交渉しSASLセキュリティ層を形成した後、両方利用できるようにするSASLメカニズムを発見することができますプロトコルのメカニズムの発見機能によってインストールされています。クライアントは、完全性保護されたリスト（セキュリティレイヤをインストールした後に得られたリスト）は、以前に取得したリストのものよりも強力なメカニズムが含まれていることを発見した場合、クライアントは、以前に取得したリストは、攻撃者によって変更されたことを想定すべきであると閉じてください基礎となるトランスポート接続。
The client's initiation of the SASL exchange, including the selection of a SASL mechanism, is done in the clear and may be modified by an active attacker. It is important for any new SASL mechanisms to be designed such that an active attacker cannot obtain an authentication with weaker security properties by modifying the SASL mechanism name and/or the challenges and responses.
SASL機構の選択を含むSASL交換のクライアントの開始は、明確に行われ、活発な攻撃者によって修正されてもよいです。どんな新しいSASLメカニズムはアクティブな攻撃者がSASLメカニズム名および/またはチャレンジとレスポンスを変更することによって、弱いセキュリティのプロパティで認証を取得できないように設計することが重要です。
Multi-level negotiation of security features is prone to downgrade attack. Protocol designers should avoid offering higher-level negotiation of security features in protocols (e.g., above SASL mechanism negotiation) and mechanism designers should avoid lower-level negotiation of security features in mechanisms (e.g., below SASL mechanism negotiation).
セキュリティ機能のマルチレベルの交渉は攻撃をダウングレードする傾向があります。プロトコル設計者は（例えば、SASL機構ネゴシエーション上記）プロトコルのセキュリティ機能の上位レベルの折衝を提供避けるべきであり、機構の設計者は、（例えば、SASL機構ネゴシエーション未満）メカニズムのセキュリティ機能の低レベルのネゴシエーションを避けるべきです。
Some mechanisms may be subject to replay attacks unless protected by external data security services (e.g., TLS).
外部データ・セキュリティ・サービス（例えば、TLS）によって保護されていない限り、いくつかのメカニズムがリプレイ攻撃の対象とすることができます。
Most existing SASL security layers do not themselves offer protection against truncation attack. In a truncation attack, the active attacker causes the protocol session to be closed, causing a truncation of the possibly integrity-protected data stream that leads to behavior of one or both the protocol peers that inappropriately benefits the attacker. Truncation attacks are fairly easy to defend against in connection-oriented application-level protocols. A protocol can defend against these attacks by ensuring that each information exchange has a clear final result and that each protocol session has a graceful closure mechanism, and that these are integrity protected.
ほとんどの既存のSASLセキュリティ層自体は切り捨て攻撃に対する保護を提供していません。切り捨て攻撃では、活発な攻撃者が不適切に攻撃者に利益をもたらす一方または両方のプロトコルピアの行動につながる可能性の整合性が保護されたデータストリームの切り捨てを引き起こし、プロトコルセッションがクローズされます。切り捨て攻撃は、接続指向のアプリケーションレベルのプロトコルで身を守るために非常に簡単です。プロトコルは、各情報交換が明確な最終結果を有し、各プロトコルセッションが優雅な閉鎖機構を有しており、これらは完全性を保護されていることをことを保証することによって、これらの攻撃を防御することができます。
When use of a security layer is negotiated by the authentication protocol exchange, the receiver SHOULD handle gracefully any protected data buffer larger than the defined/negotiated maximal size. In particular, it MUST NOT blindly allocate the amount of memory specified in the buffer size field, as this might cause the "out of memory" condition. If the receiver detects a large block, it SHOULD close the connection.
セキュリティ層の使用は、認証プロトコル交換によってネゴシエートされた場合、受信機は、任意の保護されたデータは、定義された/ネゴシエートされた最大サイズより大きなバッファ優雅に処理する必要があります。これは、「メモリ不足」状態を引き起こす可能性があるとして、特に、それは盲目的に、バッファサイズフィールドで指定されたメモリの量を割り当ててはなりません。受信機は、大きなブロックを検出した場合は、接続を閉じる必要があります。
Many mechanisms are subject to various passive attacks, including simple eavesdropping of unprotected credential information as well as online and offline dictionary attacks of protected credential information.
多くのメカニズムは、保護されていない資格情報の簡単な盗聴だけでなく、保護された認証情報のオンラインおよびオフライン辞書攻撃など、さまざまな受動的攻撃、対象となります。
The secure or administratively permitted lifetimes of SASL mechanisms' security layers are finite. Cryptographic keys weaken as they are used and as time passes; the more time and/or cipher-text that a cryptanalyst has after the first use of the a key, the easier it is for the cryptanalyst to mount attacks on the key.
SASLメカニズムのセキュリティレイヤのセキュリティ保護や管理上許さ寿命が有限です。彼らが使用されるような、時間の経過とともに暗号鍵は弱め。暗号解読キーへの攻撃をマウントするために暗号解読キーの最初の使用後に持っていることをより多くの時間および/または暗号文は、簡単にそれがあります。
Administrative limits on a security layer's lifetime may take the form of time limits expressed in X.509 certificates, in Kerberos V tickets, or in directories, and are often desired. In practice, one likely effect of administrative lifetime limits is that applications may find that security layers stop working in the middle of application protocol operation, such as, perhaps, during large data transfers. As the result of this, the connection will be closed (see Section 3.7), which will result in an unpleasant user experience.
セキュリティ層の寿命に対する管理限界は、Kerberos Vのチケットで、またはディレクトリでは、X.509証明書で表した時間制限の形をとることができる、としばしば望まれています。実際には、管理寿命限界の可能性効果は、アプリケーションがそのセキュリティ層は、大規模なデータ転送中に、このようなおそらく、として、アプリケーションプロトコルの動作の途中で動作を停止見つけることができることです。この結果、接続は、不快なユーザ体験をもたらすであろう（セクション3.7を参照）が閉鎖されます。
Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. The SASL framework does not itself provide for re-keying; SASL mechanisms may. Designers of future SASL mechanisms should consider providing re-keying services.
再キーイング（キー再ネゴシエーションプロセス）暗号鍵の弱体化に対処する方法です。 SASLフレームワークは、それ自体は再入力のために用意されていません。 SASLメカニズムは、があります。将来のSASLメカニズムの設計者は、再キーイングのサービスを提供することを検討すべきです。
Implementations that wish to re-key SASL security layers where the mechanism does not provide for re-keying SHOULD reauthenticate the same IDs and replace the expired or soon-to-expire security layers. This approach requires support for reauthentication in the application protocols (see Section 3.8).
メカニズムは同じIDを再認証し、有効期限が切れたか、間もなく期限切れとセキュリティ層を交換する必要があります再入力を提供しないSASLのセキュリティ層-キーを再実装したいです。このアプローチは、アプリケーションプロトコルでの再認証のためのサポートを必要とする（3.8節を参照してください）。
Protocol designers and implementors should understand the security considerations of mechanisms so they may select mechanisms that are applicable to their needs.
彼らは彼らのニーズに適用されるメカニズムを選択することができように、プロトコル設計者と実装者は、メカニズムのセキュリティの考慮事項を理解する必要があります。
Distributed server implementations need to be careful in how they trust other parties. In particular, authentication secrets should only be disclosed to other parties that are trusted to manage and use those secrets in a manner acceptable to the disclosing party. Applications using SASL assume that SASL security layers providing data confidentiality are secure even when an attacker chooses the text to be protected by the security layer. Similarly, applications assume that the SASL security layer is secure even if the attacker can manipulate the cipher-text output of the security layer. New SASL mechanisms are expected to meet these assumptions.
分散サーバの実装は、彼らが他の当事者を信頼する方法で注意する必要があります。具体的には、認証秘密はのみ開示当事者に受け入れられるようにしたものの秘密を管理し、使用するために、信頼されている他の当事者に開示されるべきです。 SASLを使用するアプリケーションは、攻撃者がセキュリティ層で保護するテキストを選択した場合でも、データの機密性を提供するSASLのセキュリティ層が固定されていることを前提としています。同様に、アプリケーションは、SASLのセキュリティ層は、攻撃者がセキュリティレイヤの暗号文の出力を操作することができた場合でも安全であることを前提としています。新しいSASLメカニズムは、これらの仮定を満たすことが期待されています。
Unicode security considerations [UTR36] apply to authorization identity strings, as well as UTF-8 [RFC3629] security considerations where UTF-8 is used. SASLprep [RFC4013] and StringPrep [RFC3454] security considerations also apply where used.
Unicodeのセキュリティの考慮事項は、[UTR36]認証アイデンティティ文字列だけでなく、UTF-8が使用されているUTF-8 [RFC3629]のセキュリティ上の考慮事項に適用されます。使用場所SASLprep [RFC4013]とSTRINGPREP [RFC3454]のセキュリティ上の考慮事項にも適用されます。
The SASL mechanism registry is maintained by IANA. The registry is currently available at <http://www.iana.org/assignments/sasl-mechanisms>.
SASLメカニズムのレジストリは、IANAによって維持されています。レジストリは、<http://www.iana.org/assignments/sasl-mechanisms>で現在入手可能です。
The purpose of this registry is not only to ensure uniqueness of values used to name SASL mechanisms, but also to provide a definitive reference to technical specifications detailing each SASL mechanism available for use on the Internet.
このレジストリの目的は、SASLメカニズムに名前を付けるために使用される値の一意性を保証するために、だけでなく、インターネット上で利用可能な各SASLメカニズムを詳細な技術仕様への決定的な基準を提供するだけではありません。
There is no naming convention for SASL mechanisms; any name that conforms to the syntax of a SASL mechanism name can be registered.
SASLメカニズムのための命名規則はありません。 SASLメカニズム名の構文に準拠する任意の名前を登録することができます。
The procedure detailed in Section 7.1.1 is to be used for registration of a value naming a specific individual mechanism.
7.1.1項で詳述した手順は、特定の個々のメカニズムを命名値の登録に使用されます。
The procedure detailed in Section 7.1.2 is to be used for registration of a value naming a family of related mechanisms.
7.1.2項で詳述した手順は、関連する機構のファミリーを命名値の登録に使用されます。
Comments may be included in the registry as discussed in Section 7.1.3 and may be changed as discussed in Section 7.1.4.
コメントは、セクション7.1.3で説明したように、レジストリに含まれていてもよい、セクション7.1.4で説明したように変更してもよいです。
The SASL mechanism registry has been updated to reflect that this document provides the definitive technical specification for SASL and that this section provides the registration procedures for this registry.
SASLメカニズムのレジストリは、この文書はSASLのための決定的な技術仕様を提供し、このセクションでは、このレジストリの登録手順を提供することをことを反映するように更新されました。
IANA will register new SASL mechanism names on a First Come First Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to reject obviously bogus registration requests, but will perform no review of claims made in the registration form.
BCP 26 [RFC2434]で定義されているIANAは、最初に来る最初に添え基づいて新しいSASLメカニズム名を登録します。 IANAは明らかに偽の登録要求を拒否する権利を持っていますが、登録フォームで作られた主張のない見直しを行いません。
Registration of a SASL mechanism is requested by filling in the following template:
SASL機構の登録は、以下のテンプレートを埋めることによって要求されます。
Subject: Registration of SASL mechanism X
件名：SASLメカニズムXの登録
SASL mechanism name (or prefix for the family):
SASLメカニズム名（または家族のための接頭辞）：
Security considerations:
セキュリティの考慮事項：
Published specification (recommended):
公開された仕様（推奨）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図している用法：（COMMONの一つ、限られた使用、またはOBSOLETE）
Owner/Change controller:
所有者/変更コントローラ：
Note: (Any other information that the author deems relevant may be added here.)
注意：（著者は、関連すると判断するその他の情報はここで追加することができます。）
and sending it via electronic mail to IANA at <iana@iana.org>.
そして、<iana@iana.org>でIANAに電子メール経由で送信します。
While this registration procedure does not require expert review, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an Internet-Draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate.
この登録手続きは、専門家の審査を必要としませんが、SASLメカニズムの作者は、コミュニティの見直しを求め、それが実現可能である時はいつでもコメントすることが奨励されています。著者は、インターネットドラフトとしての提案されたメカニズムの仕様を掲載することにより、コミュニティの見直しを求めることができます。適切な場合に広く使用を意図SASLメカニズムは、通常のIETFプロセスを通じて標準化されるべきです。
As noted above, there is no general naming convention for SASL mechanisms. However, specifications may reserve a portion of the SASL mechanism namespace for a set of related SASL mechanisms, a "family" of SASL mechanisms. Each family of SASL mechanisms is identified by a unique prefix, such as X-. Registration of new SASL mechanism family names requires expert review as defined in BCP 26 [RFC2434].
上述したように、SASLメカニズムのための一般的な命名規則はありません。しかし、仕様は、関連するSASL機構、SASL機構の「家族」のセットのためのSASL機構の名前空間の一部を予約することができます。 SASLメカニズムの各ファミリは、X-などユニークな接頭辞によって識別されます。 BCP 26 [RFC2434]で定義されている新しいSASLメカニズムファミリ名の登録は、専門家審査が必要です。
Registration of a SASL family name is requested by filling in the following template:
SASLファミリ名の登録は、以下のテンプレートを埋めることによって要求されます。
Subject: Registration of SASL mechanism family X
件名：SASLメカニズムファミリXの登録
SASL family name (or prefix for the family):
SASLファミリ名（または家族のための接頭辞）：
Security considerations:
セキュリティの考慮事項：
Published specification (recommended):
公開された仕様（推奨）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図している用法：（COMMONの一つ、限られた使用、またはOBSOLETE）
Owner/Change controller:
所有者/変更コントローラ：
Note: (Any other information that the author deems relevant may be added here.)
注意：（著者は、関連すると判断するその他の情報はここで追加することができます。）
and sending it via electronic mail to the IETF SASL mailing list at <ietf-sasl@imc.org> and carbon copying IANA at <iana@iana.org>. After allowing two weeks for community input on the IETF SASL mailing list, the expert will determine the appropriateness of the registration request and either approve or disapprove the request with notice to the requestor, the mailing list, and IANA.
そして、<iana@iana.org>で<ietf-sasl@imc.org>とカーボンコピーIANAでIETF SASLメーリングリストへの電子メール経由で送信します。 IETF SASLメーリングリスト上のコミュニティ入力の2週間を許可した後、専門家は、登録要求の妥当性を判断し、承認または要求者、メーリングリスト、およびIANAへの通知とのリクエストを不承認のいずれかになります。
The review should focus on the appropriateness of the requested family name for the proposed use and the appropriateness of the proposed naming and registration plan for existing and future mechanism names in the family. The scope of this request review may entail consideration of relevant aspects of any provided technical specification, such as their IANA Considerations section. However, this review is narrowly focused on the appropriateness of the requested registration and not on the overall soundness of any provided technical specification.
レビューは、提案された使用のために要求された家族の名前や家族での既存および将来のメカニズム名の提案命名と登録計画の妥当性の妥当性に焦点を当てるべきです。この要求レビューの範囲は、それらのIANA Considerations部などの任意の提供技術仕様の関連する側面の考慮を伴ってもよいです。ただし、この口コミは狭く任意の提供、技術仕様の全体的な健全性の要求された登録とないの妥当性に焦点を当てています。
Authors are encouraged to pursue community review by posting the technical specification as an Internet-Draft and soliciting comment by posting to appropriate IETF mailing lists.
著者は、インターネットドラフトとして技術仕様を掲載し、IETFメーリングリストを適切に投稿することでコメントを募集することにより、コミュニティのレビューを追求することをお勧めします。
Comments on a registered SASL mechanism/family should first be sent to the "owner" of the mechanism/family and/or to the <ietf-sasl@imc.org> mailing list.
登録済みのSASLメカニズム/ファミリへのコメントは、第一および/または<ietf-sasl@imc.org>メーリングリストへのメカニズム/ファミリの「所有者」に送信する必要があります。
Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself by sending mail to <iana@iana.org>. At IANA's sole discretion, IANA may attach the comment to the SASL mechanism's registration.
コメントの提出者は、所有者に連絡するために合理的な試みの後、<iana@iana.org>にメールを送ることによって、SASLメカニズム登録自体に自分のコメントを添付するIANAを要求することができます。 IANAの裁量で、IANAはSASL機構の登録にコメントを付けることがあります。
Once a SASL mechanism registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
SASLメカニズム登録はIANAによって公表された後、著者はその定義への変更を要求することができます。変更要求は、登録要求と同じ手順に従います。
The owner of a SASL mechanism may pass responsibility for the SASL mechanism to another person or agency by informing IANA; this can be done without discussion or review.
SASLメカニズムの所有者は、IANAに通知することにより、他の人や機関にSASLメカニズムの責任を渡すことができ、これは、議論や検討せずに行うことができます。
The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community.
IESGは、SASLメカニズムの責任を再割り当てすることができます。この最も一般的な場合は、登録の作者が死亡したメカニズムに行われる変更を可能にすることであろう、接触の外に移動、またはコミュニティへの重要な変更を行うことができないそうしました。
SASL mechanism registrations may not be deleted; mechanisms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field; such SASL mechanisms will be clearly marked in the lists published by IANA.
SASLメカニズム登録は削除できません。もはや使用するのに適したと考えられているメカニズムは、彼らの「使用目的」欄への変更によって、OBSOLETEと宣言することができます。このようSASLメカニズムは明らかにIANAによって公表リストにマークされます。
The IESG is considered to be the owner of all SASL mechanisms that are on the IETF standards track.
IESGは、IETF標準トラック上にあるすべてのSASLメカニズムの所有者であると考えられています。
The IANA has updated the SASL mechanisms registry as follows:
次のようにIANAはSASLメカニズムのレジストリを更新しました：
1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism registrations to OBSOLETE.
1）OBSOLETEにKERBEROS_V4とSKEY機構の登録の「使用目的」に変更。
2) Changed the "Published specification" of the EXTERNAL mechanism to this document as indicated below:
以下に示すように2）この文書への外部機構の「公開された仕様」に変更：
Subject: Updated Registration of SASL mechanism EXTERNAL Family of SASL mechanisms: NO SASL mechanism name: EXTERNAL Security considerations: See A.3 of RFC 4422 Published specification (optional, recommended): RFC 4422 Person & email address to contact for further information: Alexey Melnikov <Alexey.Melnikov@isode.com> Intended usage: COMMON Owner/Change controller: IESG <iesg@ietf.org> Note: Updates existing entry for EXTERNAL
件名：SASLメカニズムのSASLメカニズムEXTERNAL家族の更新登録：NO SASLメカニズム名：外部のセキュリティの考慮事項：（推奨オプション）RFC 4422公開された仕様のA.3を参照してください：詳細のために連絡するRFC 4422のとEメールアドレス：アレクセイメルニコフ<Alexey.Melnikov@isode.com>意図している用法：COMMON所有者/変更コントローラ：IESG <iesg@ietf.org>注：EXTERNALのアップデート既存のエントリ
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]ニューマン、C.およびJ. G.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
情報交換、ANSI X3.4-1986のために7ビットの米国標準コード - [ASCII]文字セットをコード化されました。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[UNICODE]ユニコードコンソーシアムは、 "Unicode標準、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、61633から5 2000. ISBN 0-201-）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ TR28 /）。
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[CharModel]ウィスラー、K.とM.デイヴィス、 "Unicodeの技術レポート＃17、文字エンコーディングモデル"、UTR17、<http://www.unicode.org/unicode/reports/tr17/>、2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[用語]ユニコードコンソーシアム、 "ユニコード用語"、<http://www.unicode.org/glossary/>。
[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
[RFC3206] Gellens、R.、 "SYSとAUTH POPレスポンスコード"、RFC 3206、2002年2月。
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[RFC3548] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 3548、2003年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL Mechanism", Work in Progress, May 2006.
[SASL-GSSAPI]メルニコフ、A.（編集）、 "ケルベロスV5（" GSSAPI "）SASLメカニズム"、進歩、2006年5月での作業。
[UTR36] Davis, M., "(Draft) Unicode Technical Report #36, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr36/>, February 2005.
[UTR36]デイビス、M.、 "（案）は、Unicodeのテクニカルレポート＃36、文字エンコーディングモデル"、UTR17、<http://www.unicode.org/unicode/reports/tr36/>、2005年2月。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in Progress.
[CRAM-MD5] Nerenberg、L.、 "CRAM-MD5 SASLメカニズム"、ProgressのWork。
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", Work in Progress, March 2006.
[DIGEST-MD5]リーチ、P.、C.ニューマン、およびA.メルニコフ、進歩、2006年3月にワーク "SASLメカニズムとしてダイジェスト認証を使用します"。
This document is a revision of RFC 2222 written by John Myers.
この文書では、ジョン・マイヤーズによって書かれたRFC 2222の改訂版です。
This revision is a product of the IETF Simple Authentication and Security Layer (SASL) Working Group.
この改正は、IETF簡易認証セキュリティー層（SASL）ワーキンググループの製品です。
The following individuals contributed significantly to this revision: Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers, Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL 'Bob' Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, and Tony Hansen.
以下の個人はこの改正に大きく貢献：Abhijitメノンセン、Hallvard Furuseth、ジェフリーHutzelman、ジョン・マイヤーズ、ルーク・ハワード、マグナスNystrom、ニコラス・ウィリアムズ、ピーター・サン・アンドレ、RL「ボブ・モーガン、ロブSiemborski、サム・ハートマン、サイモンJosefsson氏、ティム・オールソップ、そしてトニー・ハンセン。
Appendix A. The SASL EXTERNAL Mechanism
付録A. SASL EXTERNALメカニズム
This appendix is normative.
この付録は規範的です。
The EXTERNAL mechanism allows a client to request the server to use credentials established by means external to the mechanism to authenticate the client. The external means may be, for instance, IP Security [RFC4301] or TLS [RFC4346] services. In absence of some a priori agreement between the client and the server, the client cannot make any assumption as to what external means the server has used to obtain the client's credentials, nor make an assumption as to the form of credentials. For example, the client cannot assume that the server will use the credentials the client has established via TLS.
外部機構は、クライアントがクライアントを認証するためのメカニズムへの外部の手段によって確立された資格情報を使用するようにサーバーを要求することができます。外部手段は、例えば、IPセキュリティ[RFC4301]またはTLS [RFC4346]のサービスかもしれません。クライアントとサーバの間のいくつかのアプリオリの合意がない場合には、クライアントは、サーバがクライアントの資格情報を取得するために使用しているものを外部手段についてどのような仮定を作ることができない、また資格証明書の形にような仮定をします。例えば、クライアントは、サーバは、クライアントがTLSを介して確立している資格情報を使用すると仮定することはできません。
A.1. EXTERNAL Technical Specification
A.1。 EXTERNAL技術仕様
The name of this mechanism is "EXTERNAL".
このメカニズムの名前は、「外部」です。
The mechanism does not provide a security layer.
メカニズムはセキュリティレイヤを提供していません。
The mechanism is capable of transferring an authorization identity string. If empty, the client is requesting to act as the identity the server has associated with the client's credentials. If non-empty, the client is requesting to act as the identity represented by the string.
メカニズムは認証アイデンティティ文字列を転送することが可能です。空の場合、クライアントは、サーバがクライアントの資格情報に関連付けられているアイデンティティとして動作するように要求しています。空でない場合、クライアントは、文字列で表さアイデンティティとして動作するように要求しています。
The client is expected to send data first in the authentication exchange. Where the client does not provide an initial response data in its request to initiate the authentication exchange, the server is to respond to the request with an empty initial challenge and then the client is to provide its initial response.
クライアントが認証交換に最初にデータを送信することが期待されます。クライアントが認証交換を開始するその要求に初期応答データを提供していない場合は、サーバーは、空の最初の挑戦で要求に応答することで、クライアントはその初期応答を提供することです。
The client sends the initial response containing the UTF-8 [RFC3629] encoding of the requested authorization identity string. This response is non-empty when the client is requesting to act as the identity represented by the (non-empty) string. This response is empty when the client is requesting to act as the identity the server associated with its authentication credentials.
クライアントは、要求された認証アイデンティティ文字列のUTF-8 [RFC3629]エンコードを含む初期応答を送信します。クライアントは、（空でない）文字列で表さアイデンティティとして動作するように要求しているときに、この応答は非空です。この応答は、クライアントがサーバが認証資格情報に関連付けられているアイデンティティとして動作するように要求しているときは空です。
The syntax of the initial response is specified as a value of the <extern-initial-resp> production detailed below using the Augmented Backus-Naur Form (ABNF) [RFC4234] notation.
初期の応答の構文は増補バッカス - ナウアフォーム（ABNF）[RFC4234]の表記を用いて以下に詳述<のextern-初期RESP>生産の値として指定されています。
external-initial-resp = authz-id-string authz-id-string = *( UTF8-char-no-nul ) UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1-no-nul = %x01-7F
外部初期RESP =のauthz-ID列のauthz-ID列= *（UTF8-CHAR-NO-NUL）UTF8-CHAR-NO-NUL = UTF8-1-NO-NUL / UTF8-2 / UTF8-3ありません/ UTF8-4 UTF8-1-NO-NUL =％x01-7F
where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined in [RFC3629].
ここで、<UTF 8-2>、<UTF8-3>、および[RFC 3629]で定義されるように<UTF8-4>プロダクションです。
There are no additional challenges and responses.
追加のチャレンジと応答がありません。
Hence, the server is to return the outcome of the authentication exchange.
したがって、サーバーは認証交換の結果を返すことです。
The exchange fails if
交換があれば失敗します
- the client has not established its credentials via external means,
- クライアントは、外部手段を介してその資格情報を確立していません、
- the client's credentials are inadequate,
- クライアントの資格情報が不十分です、
- the client provided an empty authorization identity string and the server is unwilling or unable to associate an authorization identity with the client's credentials,
- 、クライアントは空の認証アイデンティティ文字列を提供し、サーバは不本意またはクライアントの資格情報を使用して認可IDを関連付けることができません
- the client provided a non-empty authorization identity string that is invalid per the syntax requirements of the applicable application protocol specification,
- クライアントは、該当するアプリケーションプロトコル仕様の構文の要件ごとに無効である非空の認証アイデンティティ文字列を提供しました
- the client provided a non-empty authorization identity string representing an identity that the client is not allowed to act as, or
- クライアントは、クライアントは次のように行動することが許可されていないというアイデンティティを表す空でない認証アイデンティティ文字列を提供し、または
- the server is unwilling or unable to provide service to the client for any other reason.
- サーバーは不本意またはその他の理由のためにクライアントにサービスを提供することができません。
Otherwise the exchange is successful. When indicating a successful outcome, additional data is not provided.
それ以外の場合は交換が成功しています。成功した結果を示す場合には、追加的なデータが提供されていません。
A.2. SASL EXTERNAL Examples
A.2。 SASL EXTERNAL例
This section provides examples of EXTERNAL authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive. The Application Configuration Access Protocol (ACAP) [RFC2244] is used in the examples.
ここでは、外部認証交換の例を提供します。例は読者が上記のテキストを理解しやすくすることを意図しています。例は決定的ではありません。アプリケーション設定アクセスプロトコル（ACAP）[RFC2244]は実施例で使用されています。
The first example shows use of EXTERNAL with an empty authorization identity. In this example, the initial response is not sent in the client's request to initiate the authentication exchange.
最初の例は、空の認証アイデンティティを持つ外部の使用を示しています。この例では、初期応答は、認証交換を開始するクライアントの要求で送信されていません。
S: * ACAP (SASL "DIGEST-MD5") C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer>
S：* ACAP（SASL "DIGEST-MD5"）C：A001 STARTTLS S：A001 OK "は今TLSネゴシエーションを開始します" <TLS折衝、さらにコマンドはTLS層の下にあります>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") C: a002 AUTHENTICATE "EXTERNAL" S: + "" C: + "" S: a002 OK "Authenticated"
S：* ACAP（SASL "DIGEST-MD5" "外部"）C：A002 AUTHENTICATE "外部" S：+ "" C：+ "" S：A002 OK "認証"
The second example shows use of EXTERNAL with an authorization identity of "fred@example.com". In this example, the initial response is sent with the client's request to initiate the authentication exchange. This saves a round-trip.
第二の例は、「fred@example.com」の認可IDを持つ外部の使用を示しています。この例では、初期応答は、認証交換を開始するクライアントの要求で送信されます。これは、ラウンドトリップを節約できます。
S: * ACAP (SASL "DIGEST-MD5") C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer> S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL") C: a002 AUTHENTICATE "EXTERNAL" {16+} C: fred@example.com S: a002 NO "Cannot assume requested authorization identity"
S：* ACAP（SASL "DIGEST-MD5"）C：A001 STARTTLSのS：A001 OK "今TLSネゴシエーション開始" <TLSネゴシエーションを、さらにコマンドはTLS層の下にある> S：* ACAP（SASL "DIGEST-MD5"「EXTERNAL 「）C：A002 AUTHENTICATE "EXTERNAL" {16+} C：fred@example.com S：A002 NO "要求されたと仮定することはできません認証アイデンティティ"
A.3. Security Considerations
A.3。セキュリティの考慮事項
The EXTERNAL mechanism provides no security protection; it is vulnerable to spoofing by either client or server, active attack, and eavesdropping. It should only be used when adequate security services have been established.
外部機構にはセキュリティ保護を提供していません。それは、クライアントまたはサーバー、積極的な攻撃、盗聴によるなりすましに対して脆弱です。十分なセキュリティサービスが確立されているときにのみ使用してください。
Appendix B. Changes since
付録B.からの変更点
This appendix is non-normative.
この付録は非規範的です。
The material in RFC 2222 was significantly rewritten in the production of this document.
RFC 2222での材料が大幅にこの文書の生産に書き直されました。
RFC 2222, by not stating that the authorization identity string was a string of Unicode characters, let alone character data, implied that the authorization identity string was a string of octets.
認証アイデンティティ文字列がUnicode文字の文字列があったと述べていないことにより、RFC 2222は、単独で文字データを聞かせて、認証アイデンティティ文字列がオクテットの文字列であったことを暗示しました。
- The authorization identity string is now defined as a string of Unicode characters. The NUL (U+0000) character is prohibited. While protocol specifications are responsible for defining the authorization identity form, as well as the Unicode string syntax and related semantics, mechanism specifications are responsible for defining how the Unicode string is carried in the authentication exchange.
- 認証アイデンティティ文字列は、現在Unicode文字の文字列として定義されています。 NUL（U + 0000）文字は禁止されています。プロトコル仕様が認可IDの形式だけでなく、Unicode文字列の構文と関連のセマンティクスを定義する責任がありますが、メカニズムの仕様は、Unicode文字列は、認証交換に運ばれる方法を定義する責任があります。
- Deleted "If so, when the client does not send data first, the initial challenge MUST be specified as being an empty challenge."
- 削除された「もしそうなら、クライアントは最初にデータを送信しないとき、最初の課題は、空の挑戦であるとして指定されなければなりません。」
The following technical change was made to the EXTERNAL mechanism:
以下の技術的変更は、外部機構に行われました。
- The authorization identity string is to be UTF-8 encoded.
- 認証アイデンティティ文字列はUTF-8でエンコードすることです。
Note that protocol and mechanism specification requirements have been significantly tightened. Existing protocol and mechanism specifications will need to be updated to meet these requirements.
プロトコルやメカニズム仕様要件が大幅に強化されていることに注意してください。既存のプロトコルとメカニズムの仕様は、これらの要件を満たすために更新する必要があります。
Editors' Addresses
エディタのアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX, United Kingdom
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルセックス、TW12 2BX、イギリス
EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
電子メール：Alexey.Melnikov@isode.com URI：http://www.melnikov.ca/
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。