[要約] RFC 2245は、匿名のSASLメカニズムに関する仕様であり、クライアントとサーバー間の認証を行うための方法を提供します。このRFCの目的は、匿名での認証をサポートすることで、ユーザーのプライバシーを保護し、セキュリティを向上させることです。
Network Working Group C. Newman
Request for Comments: 2245 Innosoft
Category: Standards Track November 1997
Anonymous 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 (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
Abstract
概要
It is common practice on the Internet 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 optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.
インターネットでは、さまざまなサービスへの匿名アクセスを許可するのが一般的です。従来、これは、ユーザー名として「anonymous」を使用し、パスワードとして電子メールアドレスなどのオプションのトレース情報を使用するプレーンテキストのパスワードメカニズムで行われていました。新しいIETFプロトコルではプレーンテキストのログインコマンドが許可されないため、SASL [SASL]フレームワークのコンテキスト内で匿名ログインを提供する新しい方法が必要です。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、「要件レベルを示すRFCで使用するキーワード」[キーワード]で定義されているように解釈されます。 。
The mechanism name associated with anonymous access is "ANONYMOUS". The mechanism consists of a single message from the client to the server. The client sends optional trace information in the form of a human readable string. The trace information should take one of three forms: an Internet email address, an opaque string which does not contain the '@' character and can be interpreted by the system administrator of the client's domain, or nothing. For privacy reasons, an Internet email address should only be used with permission from the user.
匿名アクセスに関連付けられているメカニズム名は「ANONYMOUS」です。このメカニズムは、クライアントからサーバーへの単一のメッセージで構成されます。クライアントは、オプションのトレース情報を人間が読める文字列の形式で送信します。トレース情報は、インターネット電子メールアドレス、「@」文字を含まず、クライアントのドメインのシステム管理者が解釈できる不透明な文字列、または何もない3つの形式のいずれかである必要があります。プライバシー上の理由から、インターネットメールアドレスは、ユーザーの許可を得た場合にのみ使用してください。
A server which permits anonymous access will announce support for the ANONYMOUS mechanism, and allow anyone to log in using that mechanism, usually with restricted access.
匿名アクセスを許可するサーバーは、ANONYMOUSメカニズムのサポートを発表し、通常は制限付きアクセスで、そのメカニズムを使用して誰でもログインできるようにします。
The formal grammar for the client message using Augmented BNF [ABNF] follows.
Augmented BNF [ABNF]を使用したクライアントメッセージの正式な文法は次のとおりです。
message = [email / token]
TCHAR = %x20-3F / %x41-7E
;; any printable US-ASCII character except '@'
email = addr-spec
;; as defined in [IMAIL], except with no free
;; insertion of linear-white-space, and the
;; local-part MUST either be entirely enclosed in
;; quotes or entirely unquoted
token = 1*255TCHAR
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. Newer profiles of SASL will include the client message with the AUTHENTICATE command itself so the extra round trip below (the server response with an empty "+ ") can be eliminated.
この例では、SASLのIMAPプロファイル[IMAP4]を使用していることに注意してください。チャレンジとレスポンスのbase64エンコーディング、およびレスポンスの前の「+」は、SASL自体の一部ではなく、IMAP4プロファイルの一部です。 SASLの新しいプロファイルには、AUTHENTICATEコマンド自体を含むクライアントメッセージが含まれるため、以下の余分なラウンドトリップ（空の "+"を含むサーバーの応答）を排除できます。
In this example, the user's opaque identification token is "sirhc".
この例では、ユーザーの不透明な識別トークンは「sirhc」です。
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-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 information by anyone. For this reason it should be disabled by default so 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 anonymously exchange information. Servers which 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 limit the number of anonymous users and reduce their priority or limit their resource usage.
匿名ユーザーが多くの負荷の高い操作（IMAP SEARCH BODYコマンドなど）を実行できる場合、これによりサービス拒否攻撃が可能になります。サーバーでは、匿名ユーザーの数を制限し、優先順位を下げるか、リソースの使用を制限することをお勧めします。
If there is no idle timeout for the anonymous user and there is a limit on the number of anonymous users, a denial of service attack is enabled. Servers should implement an idle timeout for anonymous users.
匿名ユーザーのアイドルタイムアウトがなく、匿名ユーザーの数に制限がある場合、サービス拒否攻撃が有効になります。サーバーは、匿名ユーザーのアイドルタイムアウトを実装する必要があります。
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 trying to trace abuse need to realize this information may be falsified.
トレース情報は認証されないため、改ざんされる可能性があります。これは、疑わしい情報にアクセスするために他の誰かを困らせる試みとして使用できます。この情報を理解するために悪用を追跡しようとする管理者は、改ざんされる可能性があります。
A client which uses the user's correct email address as trace information without explicit permission may violate that user's privacy. Information about who accesses an anonymous archive on a sensitive subject (e.g., sexual abuse) has strong privacy needs. Clients should not send the email address without explicit permission of the user and should offer the option of supplying no trace token -- thus only exposing the source IP address and time. Anonymous proxy servers could enhance this privacy, but would have to consider the resulting potential denial of service attacks.
明示的な許可なしにユーザーの正しい電子メールアドレスをトレース情報として使用するクライアントは、そのユーザーのプライバシーを侵害する可能性があります。機密性の高い主題（性的虐待など）の匿名アーカイブに誰がアクセスするかに関する情報には、強力なプライバシーのニーズがあります。クライアントは、ユーザーの明示的な許可なしに電子メールアドレスを送信してはならず、トレーストークンを提供しないオプションを提供する必要があります-したがって、ソースIPアドレスと時間のみを公開します。匿名プロキシサーバーはこのプライバシーを強化できますが、結果として生じる可能性のあるサービス拒否攻撃を考慮する必要があります。
Anonymous connections are susceptible to man in the middle attacks which view or alter the data transferred. Clients and servers are encouraged to support external integrity and encryption mechanisms.
匿名接続は、転送されたデータを表示または変更する中間者攻撃に対して脆弱です。クライアントとサーバーは、外部の整合性と暗号化メカニズムをサポートすることが推奨されます。
Protocols which fail to require an explicit anonymous login are more susceptible to break-ins given certain common implementation techniques. Specifically, Unix servers which 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 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 which offer restricted data access should not allow anonymous data access without an explicit login step.
明示的な匿名ログインを必要としないプロトコルは、特定の一般的な実装技術を考えると、侵入の影響を受けやすくなります。特に、ユーザーログインを提供するUnixサーバーは、最初にrootとして起動し、明示的なログインコマンドの後で適切なユーザーIDに切り替える場合があります。通常、このようなサーバーは明示的なログインの前にすべてのデータアクセスコマンドを拒否し、匿名ユーザーの制限されたセキュリティ環境（Unix chroot関数など）に入る場合があります。匿名アクセスが明示的に要求されない場合、データアクセス機構全体が外部のセキュリティ攻撃にさらされ、明示的な保護対策が講じられる機会はありません。制限されたデータアクセスを提供するプロトコルでは、明示的なログイン手順なしに匿名データアクセスを許可しないでください。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", STD 11, RFC 822, August 1982.
[画像] Crocker、D。、「Arpaインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 2060、1996年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Chris Newman Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA
Email: chris.newman@innosoft.com
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。