[要約] RFC 4505は、匿名のSimple Authentication and Security Layer（SASL）メカニズムに関する仕様です。このRFCの目的は、SASLを使用して匿名の認証とセキュリティを提供するためのメカニズムを定義することです。
Network Working Group K. Zeilenga, Ed.
Request for Comments: 4505 OpenLDAP Foundation
Obsoletes: 2245 June 2006
Category: Standards Track
Anonymous Simple Authentication and Security Layer (SASL) Mechanism
匿名のシンプルな認証とセキュリティレイヤー（SASL）メカニズム
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework.
インターネットでは、さまざまなサービスへの匿名のアクセスを許可することが一般的です。伝統的に、これはユーザー名として「匿名」を使用して、電子メールアドレスなどのオプションのトレース情報をパスワードとして使用して、プレーンテキストパスワードメカニズムで行われてきました。新しいIETFプロトコルでは、プレーンテキストログインコマンドが許可されていないため、Simple Authentication and Security Layer（SASL）フレームワークのコンテキスト内で匿名ログインを提供する新しい方法が必要です。
This document defines an anonymous mechanism for the Simple Authentication and Security Layer ([SASL]) framework. The name associated with this mechanism is "ANONYMOUS".
このドキュメントは、単純な認証およびセキュリティ層（[SASL]）フレームワークの匿名メカニズムを定義します。このメカニズムに関連付けられた名前は「匿名」です。
Unlike many other SASL mechanisms, whose purpose is to authenticate and identify the user to a server, the purpose of this SASL mechanism is to allow the user to gain access to services or resources without requiring the user to establish or otherwise disclose their identity to the server. That is, this mechanism provides an anonymous login method.
ユーザーをサーバーに認証および識別することを目的とする他の多くのSASLメカニズムとは異なり、このSASLメカニズムの目的は、ユーザーが自分の身元を確立または開示することを要求することなく、ユーザーがサービスまたはリソースにアクセスできるようにすることです。サーバ。つまり、このメカニズムは匿名のログイン方法を提供します。
This mechanism does not provide a security layer.
このメカニズムは、セキュリティレイヤーを提供しません。
This document replaces RFC 2245. Changes since RFC 2245 are detailed in Appendix A.
このドキュメントはRFC 2245に取って代わります。RFC2245以降の変更については、付録Aに詳述しています。
The mechanism consists of a single message from the client to the server. The client may include in this message trace information in the form of a string of [UTF-8]-encoded [Unicode] characters prepared in accordance with [StringPrep] and the "trace" stringprep profile defined in Section 3 of this document. The trace information, which has no semantical value, should take one of two forms: an Internet email address, or an opaque string that does not contain the '@' (U+0040) character and that can be interpreted by the system administrator of the client's domain. For privacy reasons, an Internet email address or other information identifying the user should only be used with permission from the user.
メカニズムは、クライアントからサーバーへの単一のメッセージで構成されています。クライアントは、このドキュメントのセクション3で定義されている[StringPrep]と「Trace」StringPrepプロファイルに従って調製された[UTF-8]エンコードされた[Unicode]文字の文字列の形で、このメッセージトレース情報を含めることができます。セマンティック値を持たないトレース情報は、インターネットメールアドレス、または「@」（u 0040）文字を含まず、システム管理者が解釈できる不透明な文字列の2つのフォームのいずれかを取得する必要があります。クライアントのドメイン。プライバシー上の理由から、インターネットのメールアドレスまたはユーザーを識別するその他の情報は、ユーザーの許可を得てのみ使用する必要があります。
A server that permits anonymous access will announce support for the ANONYMOUS mechanism and allow anyone to log in using that mechanism, usually with restricted access.
匿名のアクセスを許可するサーバーは、匿名メカニズムのサポートを発表し、通常はアクセスが制限されているそのメカニズムを使用して誰でもログインできるようにします。
A formal grammar for the client message using Augmented BNF [ABNF] is provided below as a tool for understanding this technical specification.
拡張BNF [ABNF]を使用したクライアントメッセージの正式な文法は、この技術仕様を理解するためのツールとして以下に提供されます。
message = [ email / token ]
;; to be prepared in accordance with Section 3
UTF1 = %x00-3F / %x41-7F ;; less '@' (U+0040)
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
UTF0 = %x80-BF
TCHAR = UTF1 / UTF2 / UTF3 / UTF4
;; any UTF-8 encoded Unicode character
;; except '@' (U+0040)
email = addr-spec ;; as defined in [IMAIL]
email = addr-spec ;;[imail]で定義されています
token = 1*255TCHAR
Note to implementors: The <token> production is restricted to 255 UTF-8-encoded Unicode characters. As the encoding of a characters uses a sequence of 1 to 4 octets, a token may be as long as 1020 octets.
実装者への注意：<token>プロダクションは、255のUTF-8エンコードされたUnicode文字に制限されています。文字のエンコードは1〜4オクテットのシーケンスを使用するため、トークンは1020オクテットである可能性があります。
This section defines the "trace" profile of [StringPrep]. This profile is designed for use with the SASL ANONYMOUS Mechanism. Specifically, the client is to prepare the <message> production in accordance with this profile.
このセクションでは、[StringPrep]の「トレース」プロファイルを定義します。このプロファイルは、SASL匿名メカニズムで使用するために設計されています。具体的には、クライアントは、このプロファイルに従って<メッセージ>制作を準備することです。
The character repertoire of this profile is Unicode 3.2 [Unicode].
このプロファイルの文字レパートリーは、Unicode 3.2 [Unicode]です。
No mapping is required by this profile.
このプロファイルではマッピングは必要ありません。
No Unicode normalization is required by this profile.
このプロファイルでは、ユニコードの正規化は必要ありません。
The list of unassigned code points for this profile is that provided in Appendix A of [StringPrep]. Unassigned code points are not prohibited.
このプロファイルの未割り当てコードポイントのリストは、[StringPrep]の付録Aに提供されているものです。割り当てられていないコードポイントは禁止されていません。
Characters from the following tables of [StringPrep] are prohibited:
[StringPrep]の次の表の文字は禁止されています。
- C.2.1 (ASCII control characters) - C.2.2 (Non-ASCII control characters) - C.3 (Private use characters) - C.4 (Non-character code points) - C.5 (Surrogate codes) - C.6 (Inappropriate for plain text) - C.8 (Change display properties are deprecated) - C.9 (Tagging characters)
- c.2.1（ASCII制御文字）-C.2.2（非ASCII制御文字）-C.3（プライベート使用文字）-C.4（非特徴コードポイント）-C.5（代理コード）-C。6（プレーンテキストには不適切）-c.8（ディスプレイプロパティの変更は非推奨）-c.9（タグ付け文字）
No additional characters are prohibited.
追加の文字は禁止されていません。
This profile requires bidirectional character checking per Section 6 of [StringPrep].
このプロファイルでは、[StringPrep]のセクション6ごとに双方向の文字チェックが必要です。
Here is a sample ANONYMOUS login between an IMAP client and server. In this example, "C:" and "S:" indicate lines sent by the client and server, respectively. If such lines are wrapped without a new "C:" or "S:" label, then the wrapping is for editorial clarity and is not part of the command.
これは、IMAPクライアントとサーバーの間のサンプル匿名ログインです。この例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。そのような行が新しい「c： "または「s：」のラベルなしで包まれている場合、ラッピングは編集上の明確さのためであり、コマンドの一部ではありません。
Note that this example uses the IMAP profile [IMAP4] of SASL. The base64 encoding of challenges and responses as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of SASL itself. Additionally, protocols with SASL profiles permitting an initial client response will be able to avoid the extra round trip below (the server response with an empty "+ ").
この例では、SASLのIMAPプロファイル[IMAP4]を使用していることに注意してください。base64課題と応答のエンコード、および応答の前の「」は、SASL自体の一部ではなく、IMAP4プロファイルの一部です。さらに、SASLプロファイルを使用したプロトコルは、最初のクライアントの応答を許可することで、以下の余分な往復を避けることができます（空の ""を使用したサーバーの応答）。
In this example, the trace information is "sirhc".
この例では、トレース情報は「SIRHC」です。
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
S: A001 OK done
C: A002 AUTHENTICATE ANONYMOUS
S: +
C: c2lyaGM=
S: A003 OK Welcome, trace information has been logged.
The ANONYMOUS mechanism grants access to services and/or resources by anyone. For this reason, it should be disabled by default so that the administrator can make an explicit decision to enable it.
匿名のメカニズムは、誰もがサービスやリソースへのアクセスを付与します。このため、管理者がそれを有効にするために明示的な決定を下すことができるように、デフォルトで無効にする必要があります。
If the anonymous user has any write privileges, a denial-of-service attack is possible by filling up all available space. This can be prevented by disabling all write access by anonymous users.
匿名のユーザーが書き込み特権を持っている場合、利用可能なすべてのスペースを埋めることにより、サービス拒否攻撃が可能になります。これは、匿名ユーザーによるすべての書き込みアクセスを無効にすることで防止できます。
If anonymous users have read and write access to the same area, the server can be used as a communication mechanism to exchange information anonymously. Servers that accept anonymous submissions should implement the common "drop box" model, which forbids anonymous read access to the area where anonymous submissions are accepted.
匿名のユーザーが同じ領域への読み取りおよび書き込みアクセスを持っている場合、サーバーは情報を匿名で交換するための通信メカニズムとして使用できます。匿名の提出物を受け入れるサーバーは、匿名の提出物が受け入れられる領域への匿名の読み取りアクセスを禁止する一般的な「ドロップボックス」モデルを実装する必要があります。
If the anonymous user can run many expensive operations (e.g., an IMAP SEARCH BODY command), this could enable a denial-of-service attack. Servers are encouraged to reduce the priority of anonymous users or limit their resource usage.
匿名のユーザーが多くの高価な操作を実行できる場合（たとえば、IMAP検索ボディコマンド）、これにより、サービス拒否攻撃が可能になります。サーバーは、匿名のユーザーの優先順位を減らすか、リソースの使用を制限することをお勧めします。
While servers may impose a limit on the number of anonymous users, note that such limits enable denial-of-service attacks and should be used with caution.
サーバーは匿名ユーザーの数に制限を課す場合がありますが、そのような制限により、サービス拒否攻撃が可能になり、注意して使用する必要があることに注意してください。
The trace information is not authenticated, so it can be falsified. This can be used as an attempt to get someone else in trouble for access to questionable information. Administrators investigating abuse need to realize that this trace information may be falsified.
トレース情報は認証されていないため、偽造することができます。これは、疑わしい情報にアクセスするために他の誰かをトラブルに巻き込む試みとして使用できます。虐待を調査している管理者は、このトレース情報が偽造される可能性があることを認識する必要があります。
A client that uses the user's correct email address as trace information without explicit permission may violate that user's privacy. Anyone who accesses an anonymous archive on a sensitive subject (e.g., sexual abuse) likely has strong privacy needs. Clients should not send the email address without the explicit permission of the user and should offer the option of supplying no trace information, thus only exposing the source IP address and time.
明示的な許可なしにトレース情報としてユーザーの正しい電子メールアドレスを使用するクライアントは、そのユーザーのプライバシーに違反する可能性があります。デリケートな主題について匿名のアーカイブにアクセスする人（たとえば、性的虐待）は、おそらく強いプライバシーニーズを持っている可能性があります。クライアントは、ユーザーの明示的な許可なしに電子メールアドレスを送信しないでください。トレース情報を提供しないオプションを提供する必要があります。したがって、ソースIPアドレスと時間のみを公開します。
Anonymous proxy servers could enhance this privacy but would have to consider the resulting potential denial-of-service attacks.
匿名のプロキシサーバーはこのプライバシーを強化する可能性がありますが、結果として生じる潜在的なサービス拒否攻撃を考慮する必要があります。
Anonymous connections are susceptible to man-in-the-middle attacks that view or alter the data transferred. Clients and servers are encouraged to support external data security services.
匿名の接続は、転送されたデータを表示または変更する中間の攻撃の影響を受けやすくなります。クライアントとサーバーは、外部のデータセキュリティサービスをサポートすることをお勧めします。
Protocols that fail to require an explicit anonymous login are more susceptible to break-ins given certain common implementation techniques. Specifically, Unix servers that offer user login may initially start up as root and switch to the appropriate user id after an explicit login command. Normally, such servers refuse all data access commands prior to explicit login and may enter a restricted security environment (e.g., the Unix chroot(2) function) for anonymous users. If anonymous access is not explicitly requested, the entire data access machinery is exposed to external security attacks without the chance for explicit protective measures. Protocols that offer restricted data access should not allow anonymous data access without an explicit login step.
明示的な匿名ログインを必要としないプロトコルは、特定の一般的な実装手法を考慮して、侵入の影響を受けやすくなります。具体的には、ユーザーログインを提供するUNIXサーバーは、最初にRootとして起動し、明示的なログインコマンドの後に適切なユーザーIDに切り替えることができます。通常、このようなサーバーは、明示的なログインの前にすべてのデータアクセスコマンドを拒否し、匿名のユーザーのために制限されたセキュリティ環境（例：UNIX Chroot（2）機能）を入力する場合があります。匿名のアクセスが明示的に要求されていない場合、データアクセス機械全体が明示的な保護対策の機会なしに外部のセキュリティ攻撃にさらされます。制限されたデータアクセスを提供するプロトコルは、明示的なログインステップなしで匿名のデータアクセスを許可してはなりません。
General [SASL] security considerations apply to this mechanism.
一般[SASL]セキュリティ上の考慮事項は、このメカニズムに適用されます。
[StringPrep] security considerations and [Unicode] security considerations discussed in [StringPrep] apply to this mechanism. [UTF-8] security considerations also apply.
[StringPrep]セキュリティ上の考慮事項と[unicode] [StringPrep]で議論されているセキュリティの考慮事項は、このメカニズムに適用されます。[UTF-8]セキュリティ上の考慮事項も適用されます。
The SASL Mechanism registry [IANA-SASL] entry for the ANONYMOUS mechanism has been updated by the IANA to reflect that this document now provides its technical specification.
匿名メカニズムのSASLメカニズムレジストリ[IANA-SASL]エントリは、IANAによって更新され、このドキュメントが現在の技術仕様を提供することを反映しています。
To: iana@iana.org Subject: Updated Registration of SASL mechanism ANONYMOUS
宛先：iana@iana.org件名：saslメカニズムの更新匿名の登録
SASL mechanism name: ANONYMOUS
Security considerations: See RFC 4505.
Published specification (optional, recommended): RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <Kurt@OpenLDAP.org>
Chris Newman <Chris.Newman@sun.com>
Intended usage: COMMON
Author/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for ANONYMOUS
The [StringPrep] profile "trace", first defined in this RFC, has been registered:
このRFCで最初に定義された[StringPrep]プロファイル「Trace」が登録されています。
To: iana@iana.org Subject: Initial Registration of Stringprep "trace" profile
宛先：iana@iana.org件名：stringprep "trace"プロファイルの初期登録
Stringprep profile: trace
Published specification: RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
This document is a revision of RFC 2245 by Chris Newman. Portions of the grammar defined in Section 1 were borrowed from RFC 3629 by Francois Yergeau.
このドキュメントは、クリスニューマンによるRFC 2245の改訂です。セクション1で定義された文法の一部は、フランソワヤーゴーによってRFC 3629から借用されました。
This document is a product of the IETF SASL WG.
このドキュメントは、IETF SASL WGの製品です。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[imail] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] Melnikov、A.、ed。K. Zeilenga編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
[StringPrep] Hoffman、P。and M. Blanchet、「国際化された文字列の準備（「StringPrep '）」、RFC 3454、2002年12月。
[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 Consortium、「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/）。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 3629（STD 63）、2003年11月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", <http://www.iana.org/assignments/sasl-mechanisms>.
[IANASASL] IANA、「単純な認証とセキュリティレイヤー（SASL）メカニズム」、<http://www.iana.org/assignments/sasl-mechanisms>。
This appendix is non-normative.
この付録は非規範的です。
RFC 2245 allows the client to include optional trace information in the form of a human readable string. RFC 2245 restricted this string to US-ASCII. As the Internet is international, this document uses a string restricted to UTF-8 encoded Unicode characters. A "stringprep" profile is defined to precisely define which Unicode characters are allowed in this string. While the string remains restricted to 255 characters, the encoded length of each character may now range from 1 to 4 octets.
RFC 2245を使用すると、クライアントは人間の読み取り可能な文字列の形でオプションのトレース情報を含めることができます。RFC 2245は、この文字列をus-asciiに制限しました。インターネットは国際的であるため、このドキュメントはUTF-8エンコードされたUnicode文字に制限された文字列を使用します。「stringprep」プロファイルは、この文字列で許可されているユニコード文字を正確に定義するために定義されています。文字列は255文字に制限されたままですが、各文字のエンコードされた長さは1〜4オクテットの範囲になります。
Additionally, a number of editorial changes were made.
さらに、多くの編集上の変更が行われました。
Editor's Address
編集者のアドレス
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）によって提供されます。