原文：ftp://ftp.rfc-editor.org/in-notes/rfc4422.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
サイト内関連リンク：RFC 5034 POP3 SASL
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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "Internet Official Protocol Standards" (STD 1)を参照してほしい。この文書の配布に制限はない。
Copyright (C) The Internet Society (2006).
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)は、置換可能なメカニズムを使用して認証とデータ保護とを提供するフレームワークである。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 メカニズムのひとつである EXTERNAL メカニズムを定義する。
This document obsoletes RFC 2222. この文書は RFC 2222 を廃止する。
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 ...
SMTP LDAP XMPP 他のプロトコル ...
\ | | /
\ | | /
SASL 抽象レイヤ
/ | | \
/ | | \
EXTERNAL GSSAPI PLAIN 他のメカニズム ...
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. この抽象レイヤのインターフェイスを通すことで、このフレームワークは任意のプロトコルが任意のメカニズムを利用することを可能にしている。一般にこのレイヤはプロトコルの詳細をメカニズムから隠蔽し、メカニズムの詳細をプロトコルから隠蔽する。その一方で、通常このレイヤはメカニズムの詳細をプロトコル実装から隠蔽しない。例えば異なるメカニズムは異なる情報を必要とする。あるものはパスワードベースの認証を利用し、またあるものは領域情報を利用し、ケルベロス認証のチケットや証明書などを利用するものもある。また一般にサーバー実装は、権限付与を実行するために、認証アイデンティティ(これはメカニズム固有である)と権限アイデンティティ(これはアプリケーションプロトコル固有である)との間のマッピングを実装する必要がある。アイデンティティの概念はセクション 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. このフレームワークには、認証交換が実行されるプロトコル及びメカニズムの両方とのインターフェイスが組み込まれている。SASL の認証交換はセクション 3 で議論されている。
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 を利用するために、どのメカニズムが使用されるべきかを特定するメソッド、メカニズム固有のサーバーチャレンジとクライアントレスポンスとを交換するためのメソッド、認証交換の結果を伝えるメソッドを(他のメソッドと共に)提供する。SASL プロトコルの要求事項はセクション 4 で議論されている。
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 メカニズムは、認証サービスを提供しデータセキュリティサービスを交渉する一連のサーバーチャレンジとクライアントレスポンスとを(他の項目と共に)定義する。SASL メカニズムの要求事項はセクション 5 で定義されている。
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: この文書は以下のような読者に向けて書かれている：
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 を廃止する。RFC 2222 のセクション 7.1(KERBEROS_IV メカニズム)、7.2(GSSAPI メカニズム)、7.3(SKEY メカニズム)を除き、この文書は RFC 2222 のすべてを置き換える。KERBEROS_IV メカニズムと SKEY メカニズムとは現在では時代遅れと見なされており、RFC 2222 で提供されているそれらの仕様は歴史的なのもの(Historic)である。GSSAPI メカニズムは現在、独立して規定されている[SASL-GSSAPI]。
Appendix B provides a summary of changes since RFC 2222. RFC 2222 からの変更点の概要は付録 B に示されている。
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"、"SHALL"、"SHALL NOT""SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"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>. 文書内の文字名称(Character name)は、Unicocde Standard [Unicode] に由来する文字コードポイントと名称との表記を使用している。例えば文字 "a" は、<U+0061> または <LATIN SMALL LETTER 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]. 注意：ユニコードで使用されている用語の説明は [Glossary] に示されている。ユニコード文字をエンコードするモデルは [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. 実際問題として、認証と権限とは複数のアイデンティティを含む可能性がある。それらは異なる形式(単純なユーザー名、ケルベロス主体、X.500 の識別名など)でもよいし、異なる表現(ABNF で記述された UTF-8 形式のユニコード文字列、BER エンコードされた識別名など)でもよい。しばしば技術仕様はネットワーク上で使用されるアイデンティティの形式と表現とを規定するが、実装内部ではそれと異なるアイデンティティの形式や表現を使用してもよい。異なる形式のアイデンティティを互いに関連付ける方法は、一般にローカルの問題である。また実装内部で使用される形式と表現も、ローカルの問題である。
However, conceptually, the SASL framework involves two identities: しかしながら概念的には、SASL のフレームワークは次の二つのアイデンティティを必要とする：
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 証明書、ケルベロスチケット、単純なユーザー名/パスワードなど)を記述する。(適切であれば)これには証明書で運ばれる認証アイデンティティの文法と意味とが含まれる。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). クライアントは、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.) サーバーはクライアント証明書の検証と、クライアント証明書に対応するアイデンティティ(すなわち権限アイデンティティ)がその権限アイデンティティとして振る舞うことを許可されているかどうかの検証とに責任を持つ。これらの検証のどちらか(または両方)に失敗すると、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: 認証交換において最初に送信されるデータがクライアントからサーバーへのものであると規定するメカニズムもある。プロトコルは、リクエストメッセージにおける最初のレスポンス内にそのデータを含めて送信することをオプションで許可してもよい。最初のデータがクライアントからサーバーへと送信されるとメカニズムが規定し、プロトコルがオプションの初期レスポンスフィールドを提供し、クライアントがそのフィールドを使用する場合、やり取りが一往復省略される。
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: 一部のメカニズムは、結果が成功の場合にサーバーがクライアントに追加情報を送信すると規定している。この追加情報を伝えるために、プロトコルは結果メッセージにオプションの追加情報フィールドを提供してよい。成功の結果とともに追加データを返すことをメカニズムが規定し、プロトコルが結果メッセージにおけるオプションの追加情報フィールドを提供し、サーバーがそのフィールドを使用する場合、やり取りが一往復省略される：
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: 認証交換における最初のデータがクライアントからサーバーへ送信されとメカニズムが規定し、かつ成功の結果とともに追加データがクライアントへ送信され、両方をサポートするフィールドをプロトコルが提供している場合、その認証交換のやり取りは二往復短くなる：
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 メカニズムは文字列で名前を付けられ、長さは 1 〜 20、ASCII [ASCII] の大文字・数字・ハイフン・アンダースコアから構成される。拡張バッカス記法(ABNF) [RFC4234]による SASL メカニズム名の文法は、以下の <sasl-mech> で定義される。
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-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char は ASCII 文字セットのうち、A-Z(大文字のみ)、0-9、-、_
; だけに制限される
UPPER-ALPHA = %x41-5A ; A-Z (大文字のみ)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; ハイフン (-)
UNDERSCORE = %x5F ; アンダースコア (_)
SASL mechanism names are registered as discussed in Section 7.1. SASL メカニズムの名称は、セクション 7.2 で議論されている方法で登録される。
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. 一般にプロトコルは、サーバーがサポートしており利用可能なメカニズムを、そのプロトコルが提供する機能によってクライアントに通知すると規定し、クライアントはそのリストの中から自身がサポートしており適用可能な "最良の(best)" メカニズムを選択する。
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: これらのチャレンジとレスポンスとを通してメカニズムは：
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. 権限アイデンティティ文字列はゼロ文字以上の一連のユニコード[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. クライアントからの認証アイデンティティ文字列が省略されている場合、そのクライアントは、サーバーがそのクライアントの証明書に関連付けているアイデンティティとして振る舞うことを要求している。空文字列は認証アイデンティティが省略されているのと同じ意味である。
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. サーバーは認証交換の終わりに、その交換の結果を表すメッセージをクライアントに送信する。このメッセージの詳細はプロトコル固有である。
The outcome is not successful if 以下の場合、認証は不成功となる：
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. サーバーから返されるエラーには、ユーザーに再び証明書を促すのが最良のエラー、しばらく後に再試行するようにユーザーに伝えるのが最良のエラー、ユーザーがシステム管理者に連絡を取るべきエラー(The SYS and AUTH POP Response Codes [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. 効果を現したセキュリティレイヤは、保護された複数のデータバッファ内でプロトコルデータを処理する。セキュリティレイヤがこのバッファを生成できなくなった場合、または生成を望まない場合には常に、下層のトランスポート接続は閉じられなければならない(MUST)。セキュリティレイヤが受信バッファをデコードできない場合、下層の接続は閉じられなければならない(MUST)。どちらの場合も、下層のトランスポート接続は通常の手順通りに閉じられるべきである(SHOULD)。
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 オクテットのレングスフィールドが付加される。バッファの長さは通信相手が期待する最大サイズを超えてはならない(MUST)。最大サイズを超える長さのレングスフィールドは攻撃の兆候である可能性があるため、受信者は接続を閉じるべきである(SHOULD)。
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 認証交換が第二のセキュリティレイヤを選択した場合、第二のセキュリティレイヤが最初のセキュリティレイヤに取って代わることになる。あるセキュリティレイヤが有効なときに別の 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 サービスを提供するプロトコルの仕様は、以下の情報を提供しなければならない(MUST)：
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 メカニズムの名前をクライアントが見つけられる機能を規定すべきである(SHOULD)。導入後にも示すのは、クライアントがダウングレード攻撃を検出できるようにするために重要なことである。一般にこの機能は、そのプロトコルの拡張または能力検索機能を通して提供される。
This message MUST contain a field for carrying the name of the mechanism selected by the client. このメッセージは、クライアントが選択したメカニズムの名前を運ぶためのフィールドを含まなければならない(MUST)。
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). このメッセージは初期レスポンスを運ぶためのオプションフィールドを持つべきである(SHOULD)。メッセージがこのオプションフィールドを持つと定義する仕様は、空の初期レスポンスを持つメッセージと初期レスポンスを持たないメッセージとを区別する方法を記述しなければならない(MUST)。このフィールドは任意のオクテットシーケンス(長さゼロのシーケンス、値ゼロのオクテットが含まれるシーケンスを含む)を運ぶことが出来なければならない(MUST)。
Each of these messages MUST be capable of carrying arbitrary sequences of octets (including zero-length sequences and sequences containing zero-valued octets). これらのメッセージは任意のオクテットシーケンス(長さゼロのシーケンス、値ゼロのオクテットが含まれるシーケンスを含む)を伝えることが出来なければならない(MUST)。
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). このメッセージは、認証が成功した場合に追加データを伝えるためのオプションフィールドを含むべきである(SHOULD)。メッセージがこのオプションフィールドを持つと定義する仕様は、空の追加データを持つメッセージと追加メッセージを持たないメッセージとを区別する方法を記述しなければならない(MUST)。このフィールドは任意のオクテットシーケンス(長さゼロのシーケンス、値ゼロのオクテットが含まれるシーケンスを含む)を伝えることが出来なければならない(MUST)。
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 におけるアイデンティティとプロトコル内の別の場所(例えばアクセス制御ポリシーの宣言)で使用されるアイデンティティとを関連付ける方法をプロトコル仕様が正確に記述していない場合、確立されたアイデンティティの使用方法に関する情報(アクセス制御を決定するときに使われるアイデンティティの表現など)をクライアントが見つけられる機能を提供するのが適切だろう。
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. 一般にプロトコルは、サーバーが不成功の結果メッセージを返すことで進行中の認証交換を中止することを許可している。
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. 一般に仕様は、サーバーの場合は結果メッセージ直後の最初のオクテットから、クライアントの場合は結果メッセージ受信後の最初のオクテットから、セキュリティレイヤが効果を現すことを要求する。
For instance, where a protocol supports both TLS and SASL security layers, the specification could prescribe any of the following: 例えば、TLS と 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 プロトコル仕様は、適用可能なメカニズムの置換を阻害するような実装要求を避けるべきである(SHOULD)。一般にプロトコル仕様はメカニズムに中立であるべきである(SHOULD)。ただしこの推奨事項には、以下の事項を含むことによる多くの合理的な例外ある：
SASL mechanism specifications MUST supply the following information: SASL メカニズムの仕様は以下の情報を提供しなければならない(MUST)：
SASL mechanisms SHOULD be designed to minimize the number of challenges and responses necessary to complete the exchange. 交換を完了するために必要とされるチャレンジとレスポンスとの数が最小限になるように SASL メカニズム設計するべきである(SHOULD)。
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)を含むシーケンスを除く)を送信する能力を持たなければならない(MUST)。メカニズムは UTF-8 [RFC3629] 変換フォーマットを使用するべきである(SHOULD)。認証アイデンティティ文字列のデコード中のあいまいさを回避するために、メカニズムの仕様は認証アイデンティティ文字列中に現れる可能性のある特殊文字をエスケープする方法を詳述しなければならない(MUST)。特殊文字を持つメカニズムは通常、例えば Base64 [RFC3548]のようなデータエンコード手法を使用して、(何らかのユニコード変換フォーマットにしたがってエンコードした後の)文字列中の特殊文字がエスケープされることを必要とする。
SASL mechanisms SHOULD be protocol neutral. SASL メカニズムはプロトコルに中立であるべきである(SHOULD)。
SASL mechanisms SHOULD reuse existing credential and identity forms, as well as associated syntaxes and semantics. SASL メカニズムは既存の証明書とアイデンティティとの形式だけではなく、それに対応する文法と意味も再利用するべきである(SHOULD)。
SASL mechanisms SHOULD use the UTF-8 transformation format [RFC3629] for encoding Unicode [Unicode] code points for transfer. 転送のためにユニコード[Unicode]のコードポイントをエンコードするとき、SASL メカニズムは UTF-8 変換フォーマット[RFC3629]を使用するべきである(SHOULD)。
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] のプロファイル)が規定されるべきである(SHOULD)。
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. 権限アイデンティティ文字列は正規化される必要がないため、メカニズムはそれを長期にわたる暗号鍵やハッシュの生成に使用するべきではない(SHOULD NOT)。この場合の「長期」とは、権限アイデンティティ文字列を生成する認証交換の間隔よりも長い期間を表す。つまり、(同一または異なるプロトコルを使用する)複数のクライアントが意味的に等しい異なる権限アイデンティティ文字列を生成する可能性があるため、暗号鍵やハッシュの生成に権限アイデンティティ文字列を使用すると、相互運用上の問題を引き起こす可能性があるということである。
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 セキュリティレイヤ内のセキュリティサービスがプロトコルデータの完全性が欠落していることを報告した場合、実装はその接続を閉じるべきである(SHOULD)。
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. クライアントが認証メカニズムやその他のセキュリティ機能をサーバーと交渉するとき、能動的攻撃者は利用可能な中で最低のセキュリティサービスを参加者に使用させることが可能である。例えば攻撃者は、サーバーが通知するメカニズムの一覧を改謬したり、レスポンス中でクライアントが通知するセキュリティ機能の一覧を改謬したりすることができる。この種の攻撃を防ぐために実装は、自身の要求する最低限のセキュリティに見合わないメカニズムや機能を通知しないべき(SHOULD NOT)であり、最低限のセキュリティに見合わない認証交換を開始したり継続したりしないべき(SHOULD NOT)であり、完了した認証交換が自身の要求する最低限のセキュリティに見合う能力を持っていることを確認するべきである(SHOULD)。これらは各参加者がそれぞれ独立して確認する必要があることに注意してほしい。
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 メカニズムを調べることができる。完全性を保護されたメカニズムの一覧(セキュリティレイヤ導入後に取得された一覧)に、以前に取得した一覧に含まれていたものより強いメカニズムが含まれていることを発見した場合、以前に取得した一覧は攻撃者によって改謬されていたと見なし、クライアントは下層のトランスポート接続を閉じるべきである(SHOULD)。
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. 認証プロトコル交換によってセキュリティレイヤの使用が交渉されている場合、定義/交渉された最大サイズより保護データバッファが大きかったとしても、受信者はそれを正常に扱えるべきである(SHOULD)。特に、バッファサイズフィールドで指定されたメモリ量を無分別に割り当てることは "メモリ不足(out of memory)" の状態を起こす可能性があるため、行ってはならない(MUST NOT)。大き過ぎるブロックを検出した受信者は接続を閉じるべきである(SHOULD)。
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. セキュリティレイヤの管理上の有効期限は、X.509 証明書・Kerberos V チケット・ディレクトリの何れかで表された形式を取ることを許されており、しばしばそれが望ましい。実際問題として管理上の有効期限が与えうる影響としては、例えば大きなデータの転送のようなアプリケーションプロトコルの操作中に、セキュリティレイヤの効果が消えたことをアプリケーションが見つける可能性がある。その結果として接続は閉じられ(セクション 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 を再度認証し、期限切れまたはもうすぐ期限の切れるセキュリティレイヤを置き換えるべきである(SHOULD)。この手法は、アプリケーションプロトコルにおける再認証のサポートを必要とする(セクション 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 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. 認証アイデンティティ文字列にはユニコードのセキュリティ考察[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:
(詳細情報の窓口となる個人とメールアドレス：)
Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
(使用目的：(COMMON、LIMITED USE、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@iana.org> に送信する。
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 メカニズムの "ファミリ(family)")のために、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)
(使用目的：(COMMON、LIMITED USE、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. そしてこれを電子メールで IETF SASL メーリングリスト <ietf-sasl@imc.org> 宛てに、カーボンコピーを IANA <iana@iana.org> 宛てに送信する。IETF SASL メーリングリスト上でコミュニティからの投稿に二週間を掛けた後、専門家がその登録要求の妥当性を判断し、要求者・メーリングリスト・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 メカニズム/ファミリに関するコメントは、まず最初にそのメカニズム/ファミリの "所有者(owner)" とメーリングリスト <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 メカニズムを削除することは許されない。使用するのが適切ではなくなったと考えられるメカニズムは、その "使用目的(intended usage)" を OBSOLETE に変更することができる。そのようなメカニズムは、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 メカニズムの登記を次のように更新した：
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
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) Working Group によるものである。
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 Josefsson, Tim Alsop, Tony Hansen
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. クライアントは EXTERNAL メカニズムを利用することで、メカニズム外部の手段によって確立された証明書を使ってクライアントを認証するようにサーバーに要求できる。外部の手段とは、例えば IP Security [RFC4301] や TLS [RFC4346] である。クライアントとサーバーとの間に何らかの事前の合意がないかぎり、クライアントは、クライアントの証明書を取得するためにサーバーが使用した外部の手段が何であるかを推測することはできないし、証明書の書式を推測することもできない。クライアントは、例えば TLS を通して確立された証明書をサーバーが使用するだろうと仮定することはできない。
The name of this mechanism is "EXTERNAL". このメカニズムの名称は "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-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 以下の場合、交換は失敗する。
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. このセクションでは EXTERNAL メカニズムの認証交換の例を提供する。これらの例は読者がこれまでの内容を理解する手助けとなることを目的とたものであり、最も信頼のおけるものというわけではない。例の中で、Application Configuration Access Protocol (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. 最初の例は、空の認証アイデンティティと供に EXTERNAL メカニズムを使用するケースである。この例では、認証交換を開始するクライアントの要求の中で初期レスポンスは送信されていない。
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"
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS 交渉、追加の命令は TLS レイヤの下で行われる>
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. 二番目の例は、"fred@example.com" という認証アイデンティティと供に EXTERNAL メカニズムを使用するケースである。この例では、認証交換を開始するクライアントのリクエストが初期レスポンスを伴って送信されており、それによってやり取りが一往復省略されている。
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 "Begin TLS negotiation now"
<TLS 交渉、追加の命令は TLS レイヤの下で行われる>
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. EXTERNAL メカニズムはセキュリティ保護を提供しないため、クライアントまたはサーバーによるなりすましや、能動的攻撃、盗聴に対して脆弱である。このメカニズムは適切なセキュリティサービスが確立済みの場合にのみ使用されるべきである。
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 は、認証アイデンティティ文字列がユニコード文字であると記述しないのはもちろん、文字データであるとも記述しないことで、認証アイデンティティ文字列が単なるオクテット文字列であることを暗示していた。
The following technical change was made to the EXTERNAL mechanism: EXTERNAL メカニズムに対して以下の変更が行われた：
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. プロトコル仕様及びメカニズム仕様に対する要求事項がかなり厳しくなったことに注意してほしい。既存のプロトコル仕様とメカニズム仕様は、これらの要求事項に合うように更新される必要があるだろう。
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX, United Kingdom EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/ Kurt D. Zeilenga OpenLDAP Foundation EMail: Kurt@OpenLDAP.org
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.
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.
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.
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). RFC 編集者の働きに対する資金拠出は、IETF Administrative Support Activity (IASA)によって提供されている。