[要約] RFC 4422は、SASLプロトコルの仕様を定義しており、認証とセキュリティのための簡単なレイヤーを提供します。その目的は、クライアントとサーバー間の安全な通信を確保し、認証情報の交換やデータの保護を行うことです。
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)
シンプルな認証とセキュリティレイヤー（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).
Copyright（c）The Internet Society（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.
Simple Authentication and 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のサポートをどのように含めるかを説明し、接続上にデータセキュリティレイヤーを運ぶためのプロトコルを定義します。さらに、このドキュメントでは、1つの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.
Simple Authentication and Security Layer（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チケット、証明書などを使用します。フォームがメカニズム固有である認証アイデンティティと、フォームがアプリケーションプロトコル固有の認証アイデンティティとの間でアイデンティティマッピングを実装する。セクション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外部メカニズムを定義しています。
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].
このドキュメントはRFC 2222を廃止します。セクション7.1（Kerberos_IVメカニズム）、7.2（GSSAPIメカニズム）、7.3（SKEYメカニズム）を除き、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]のコードポイントと名前の表記を使用します。たとえば、文字「a」は<u 0061>または<ラテンの小さな文字a>として表される場合があります。
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の著名な名前など）の複数のアイデンティティが含まれる場合があります。ベルエンコードされた著名な名前）。技術的な仕様は、多くの場合、ネットワークで使用されるIDフォームと表現の両方を規定していますが、実装内で異なるIDフォームおよび/または表現が使用される（多くの場合）使用される場合があります。さまざまな形のアイデンティティが互いにどのように関連するかは、一般的に、地元の問題です。さらに、実装内で使用されるフォームと表現は、ローカルな問題です。
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と呼ばれる）に関連付けられた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プロトコル仕様は、承認で使用されるIDフォームを説明し、特に、メカニズムによって転送される認証ID文字文字列の構文とセマンティクスを規定します。
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).
クライアントは、資格情報（認証アイデンティティを含む、または暗示する）と、オプションでは、SASL Exchangeの一部として要求された承認IDを表す文字文字列を提供します。この文字文字列が省略または空の場合、クライアントは資格情報に関連付けられたIDとして行動することを要求しています（たとえば、ユーザーは認証アイデンティティとして行動することを要求しています）。
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）に関連するIDが認証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.)
各認証交換は、特定のメカニズムを介して認証を要求するクライアントからサーバーへのメッセージで構成され、その後、サーバーからの1つ以上の課題とクライアントからの応答が続き、その後、認証の結果を示すサーバーからのメッセージが続きます。交換。（注：セクション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
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:
一部のメカニズムは、認証交換で最初に送信されたデータがクライアントからサーバーへであることを指定しています。プロトコルは、要求メッセージにオプションの初期応答フィールドを提供して、このデータを携帯する場合があります。メカニズムが交換で送信された最初のデータがクライアントからサーバーにあることを指定する場合、プロトコルはオプションの初期応答フィールドを提供し、クライアントはこのフィールドを使用します。
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
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
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:
一部のメカニズムは、成功した結果を示すときに、サーバーがクライアントに追加データを送信することであることを指定しています。プロトコルは、このデータを携帯するために、結果メッセージにオプションの追加データフィールドを提供する場合があります。メカニズムが、サーバーが成功した結果を得て追加データを返すことであることを指定する場合、プロトコルは結果メッセージにオプションの追加データフィールドを提供し、サーバーはこのフィールドを使用します。
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange with
additional data with success
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
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つのラウンドトリップを2つ少なくします：
C: Request authentication exchange + Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
with additional data with success
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
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メカニズムは、長さが1〜20文字の文字文字列によって命名され、ASCII [ASCII]大文字、数字、ハイフン、および/またはアンダースコアで構成されています。次の拡張されたバックスノールフォーム（ABNF）[RFC4234]文法では、<SASL-Mech>生産は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.
UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)
SASL mechanism names are registered as discussed in Section 7.1.
SASLメカニズム名は、セクション7.1で説明されているように登録されています。
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.
認証交換には、1つ以上のサーバーチャレンとクライアントの応答が含まれ、その詳細はメカニズム固有です。これらの課題と応答は、プロトコルメッセージに囲まれており、その詳細はプロトコル固有です。
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,
- 承認ID文字列を転送し、
- 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.
認証要求またはクライアントの応答を受信した後、サーバーはチャレンジを発行したり、交換を中止したり、交換の結果を示したりすることがあります。課題を受け取った後、クライアントメカニズムは応答を発行したり、交換を中止したりする場合があります。
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.
Authorization Identity文字列は、ゼロ以上のUnicode [Unicode]文字のシーケンスであり、NUL（U 0000）文字を除く、そのように動作するアイデンティティを表します。
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.
承認IDの文字列が存在しない場合、クライアントは、サーバーがクライアントの資格情報に関連付けているアイデンティティとして行動することを要求しています。空の文字列は、承認のないアイデンティティに相当します。
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.
空でない認証ID文字列は、クライアントが文字列で表されるアイデンティティとして行動することを望んでいることを示します。この場合、文字列で表されるアイデンティティの形式と、文字列の正確な構文とセマンティクスはプロトコル固有です。
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).
認証交換で認証IDINTINCE文字列を転送するために使用されるスキーマをコードするキャラクターをコードするスキーマは、メカニズムに固有ですが、メカニズムはUnicodeレパートリー全体を運ぶことができると予想されます（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.
認証交換の終わりに、サーバーはメッセージを送信します。その詳細は、プロトコル固有であり、クライアントに交換の結果を示します。
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,
- サーバーは、アイデンティティをクライアントの資格情報に関連付けることはできません。
- the client-provided authorization identity string is malformed,
- クライアントが提供する承認Identity文字列は奇形で、
- the identity associated with the client's credentials is not authorized to act as the requested authorization identity,
- クライアントの資格情報に関連付けられているIDは、要求された承認アイデンティティとして行動することを許可されていません。
- 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 POP応答コード[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.
プロトコルで明示的に許可されていない限り（プロトコルの技術仕様に記載されているように）、プロトコルセッションで1つの成功した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番目のセキュリティレイヤーが最初のセキュリティレイヤーを置き換えます。セキュリティレイヤーが有効であり、その後の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 Exchangeの開始前と、サーバーがクライアントが利用できる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) 空ではない認証ID文字列の構文とセマンティクスを規定しています（セクション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.
相互運用性の問題を回避するために、正規化が異なるため、プロトコルの仕様は、適切な機能を確保するために、すべての正規化やその他の適用機能のために、すべての正規化を含む（クライアントまたはサーバー）非空白の認証文字列を正確に詳細に説明する必要があります。
Specifications are encouraged to prescribe use of existing authorization identity forms as well as existing string representations, such as simple user names [RFC4013].
仕様は、既存の認証IDフォームの使用と、単純なユーザー名[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).
6) 新たに交渉されたセキュリティレイヤーが両方向に有効になり始める場所を正確に特定します（セクション3.7を参照）。
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を参照）。その場合、プロトコルは、失敗した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
- 認証のアイデンティティ（メカニズム固有）と認証のアイデンティティ（プロトコル固有）が互いにどのように関連するかを詳述し、
- 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) メカニズムが認証ID文字列を転送できるかどうかを示すことを示しています（セクション3.4.1を参照）。一部のレガシーメカニズムは、認証アイデンティティ（これらのメカニズムの場合、認証アイデンティティは常に空の文字列であることを意味します）を送信することはできませんが、新たに定義されたメカニズムは認証ID文字列を転送できる必要があります。メカニズムは、認証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].
認証IDINTINCE文字列を転送できるメカニズムは、NUL（U 0000）文字を含むものを除き、Unicode文字の任意の非空白シーケンスを転送できる必要があります。メカニズムは、UTF-8 [RFC3629]変換形式を使用する必要があります。仕様は、認証ID文字列のデコード中に曖昧さを避けるために、認証ID文字列に表示される可能性のあるメカニズムに特別なユニコードコードポイントをどのようにポイントするかを詳しく説明する必要があります。通常、特殊文字を持っているメカニズムは、これらの特殊文字を、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) 仕様は、メカニズムがセキュリティレイヤーを提供するかどうかを詳しく説明する必要があります。メカニズムが行われた場合、仕様は、レイヤーで提供されるセキュリティおよびその他のサービス、およびこれらのサービスの実装方法を詳細に詳細にする必要があります。
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) メカニズムが使用する基礎となる暗号化技術がデータの整合性をサポートする場合、メカニズム仕様は、整合性の承認IDの送信とセキュリティ層の交渉を保護する必要があります。
SASL mechanisms SHOULD be protocol neutral.
SASLメカニズムはプロトコルニュートラルでなければなりません。
SASL mechanisms SHOULD reuse existing credential and identity forms, as well as associated syntaxes and semantics.
SASLメカニズムは、既存の資格情報とIDフォーム、および関連する構文とセマンティクスを再利用する必要があります。
SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] for encoding Unicode [Unicode] code points for transfer.
SASLメカニズムは、Unicode [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.
相互運用性の問題を回避するために、正規化が異なるため、メカニズムが文字データ（承認ID文字列以外）を暗号化および/または比較関数への入力として使用する場合、仕様は正確にどのように、どこで詳細に詳述する必要があります（クライアント）またはサーバー）関数に入力するために、適切な動作を確保するために、すべての正規化を含む、キャラクターデータを準備する必要があります。
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.
メカニズムは、承認IDの文字列が正規であるという要件がないため、長期的な暗号化キーまたはハッシュの生成に認証ID文字列を使用すべきではありません。ここでの長期は、生成された認証交換の期間よりも長い用語を意味します。つまり、（同じまたは異なるプロトコルの異なるクライアントが、意味的に同等の異なる認証ID文字列を提供する可能性があるため、暗号化キーとハッシュの生成における認証ID文字列の使用は、相互運用性やその他の問題につながる可能性があります。
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（TLSなどのTLSなど）の外部のデータ整合性保護サービスを使用して、SASLのダウングレード攻撃から保護することが適切です。利用可能なメカニズム自体が認証交換および/またはプロトコルデータの適切な整合性および/または機密保護を提供しない場合、外部保護セキュリティサービスの使用も重要です。
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交換のクライアントの開始は、明確に行われ、アクティブな攻撃者によって変更される場合があります。Active Attackerが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メカニズムのセキュリティ層の安全または管理上許可された寿命は有限です。暗号化キーは、使用するにつれて弱くなり、時間が経つにつれて弱くなります。CryptanalystがAキーを最初に使用した後に持っている時間および/または暗号テキストが多いほど、暗号分析学者がキーに攻撃を取り付けるのは簡単になります。
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.
セキュリティレイヤーの寿命の管理制限は、X.509証明書、Kerberos vチケット、またはディレクトリで表される時間制限の形をとることができ、しばしば望まれます。実際には、管理寿命の制限の効果の1つは、アプリケーションが、おそらく大規模なデータ転送中など、アプリケーションプロトコル操作の途中で動作を停止することがあることです。この結果、接続は閉じられます（セクション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).
メカニズムが再キーイングを提供しないSASLセキュリティレイヤーを再編成したい実装は、同じIDを再認証し、期限切れまたは間もなく発現するセキュリティレイヤーを置き換える必要があります。このアプローチでは、アプリケーションプロトコルでの再認証のサポートが必要です（セクション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メカニズム>で入手できます。
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.
IANAは、BCP 26 [RFC2434]で定義されているように、最初の提供ベースで新しい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:
詳細については、連絡先への個人およびメールアドレス：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図された使用法：（一般的な使用、限られた使用、または時代遅れの1つ）
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-などの一意のプレフィックスによって識別されます。新しいSASLメカニズム姓の登録には、BCP 26 [RFC2434]で定義されている専門家のレビューが必要です。
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:
詳細については、連絡先への個人およびメールアドレス：
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
意図された使用法：（一般的な使用、限られた使用、または時代遅れの1つ）
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.
電子メールで<ietf-sasl@imc.org>のIETF SASLメーリングリストに送信し、<iana@iana.org>のIANAをカーボンコピーします。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の考慮事項セクションなど、提供された技術仕様の関連する側面を考慮することを伴う場合があります。ただし、このレビューは、提供された技術仕様の全体的な健全性ではなく、要求された登録の適切性に狭く焦点を当てています。
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メカニズム/ファミリに関するコメントは、まずメカニズム/ファミリーの「所有者」に送信する必要があります。
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@iana.org>にメールを送信して、SASLメカニズム登録自体にコメントを添付するよう要求する場合があります。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メカニズムの登録は削除されない場合があります。使用に適していないと考えられていないメカニズムは、「意図した使用」フィールドの変更によって時代遅れと宣言できます。このような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) 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244] Newman、C。and J. G. Myers、「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] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、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] Crocker、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.
[ASCII]コード化された文字セット - 情報交換のための7ビットアメリカ標準コード、ANSI X3.4-1986。
[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コンソーシアム「Unicode Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201- 61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「Unicode Standard Annex＃28：Unicode 3.2」（http：//www.unicode.org/Reports/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] Whistler、K。and M. Davis、「Unicode Technical Report＃17、Character Encoding Model」、utr17、<http://www.unicode.org/unicode/reports/tr17/>、2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[用語集] Unicode Consortium、「Unicode 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] Kent、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Melnikov、A。（編集者）、「Kerberos 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] Davis、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メカニズム」、進行中の作業。
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest Authentication as a SASL Mechanism", Work in Progress, March 2006.
[Digest-MD5] Leach、P.、C。Newman、およびA. Melnikov、「SASLメカニズムとして消化認証を使用」、2006年3月、進行中の作業。
This document is a revision of RFC 2222 written by John Myers.
このドキュメントは、John Myersが書いたRFC 2222の改訂です。
This revision is a product of the IETF Simple Authentication and Security Layer (SASL) Working Group.
このリビジョンは、IETF Simple Authentication and Security Layer（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 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ジョセフソン、ティム・アルソップ、トニー・ハンセン。
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を介して確立した資格情報を使用すると想定できません。
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.
メカニズムは、認証ID文字列を転送できます。空の場合、クライアントは、サーバーがクライアントの資格情報に関連付けているIDとして行動することを要求しています。非空白の場合、クライアントは文字列で表されるアイデンティティとして行動することを要求しています。
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.
クライアントは、要求された承認Identity文字列をエンコードするUTF-8 [RFC3629]を含む初期応答を送信します。この応答は、クライアントが（空の）文字列で表されるアイデンティティとして行動することを要求している場合、空ではありません。この応答は、クライアントが認証資格情報に関連付けられたサーバーとしてIDとして動作することを要求しているときに空です。
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.
初期応答の構文は、拡張されたBackus-Naurフォーム（ABNF）[RFC4234]表記を使用して、以下で詳述されている<extern-Initial-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
where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined in [RFC3629].
ここで、<UTF8-2>、<UTF8-3>、および<UTF8-4>プロダクションは[RFC3629]で定義されています。
There are no additional challenges and responses.
追加の課題や応答はありません。
Hence, the server is to return the outcome of the authentication exchange.
したがって、サーバーは認証交換の結果を返すことです。
The exchange fails if
交換は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,
- クライアントは、該当するアプリケーションプロトコル仕様の構文要件に応じて無効である非空白の認証IDINTION文字列を提供しました。
- 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.
それ以外の場合は、交換が成功しています。成功した結果を示す場合、追加のデータは提供されません。
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.
最初の例は、空の承認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"
S: + ""
C: + ""
S: a002 OK "Authenticated"
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.
2番目の例は、「fred@example.com」の承認アイデンティティを備えた外部の使用を示しています。この例では、最初の応答は、認証交換を開始するというクライアントの要求とともに送信されます。これにより、往復が保存されます。
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"
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.
外部メカニズムはセキュリティ保護を提供しません。クライアントまたはサーバーのいずれかによるスプーフィング、アクティブな攻撃、盗聴に対して脆弱です。適切なセキュリティサービスが確立されている場合にのみ使用する必要があります。
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.
RFC 2222は、承認Identity文字列が単独データの文字列であり、キャラクターデータは言うまでもなく、承認IDINTION文字列がオクテットの文字列であることを暗示していることを述べないことによって。
- 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.
- 承認Identity文字列は、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.
- 承認IDINTION文字列は、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
アレクセイメルニコフアイソードリミテッド5キャッスルビジネスビレッジ36ステーションロードハンプトン、ミドルセックス、TW12 2BX、イギリス
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。