RFC2245 日本語訳

Network Working Group                                          C. Newman
Request for Comments: 2245                                      Innosoft
Category: Standards Track                                  November 1997

コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 2245年のInnosoftカテゴリ: 標準化過程1997年11月

                        Anonymous SASL Mechanism

匿名のSASLメカニズム

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Copyright(C)インターネット協会(1997)。 All rights reserved。

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.

様々なサービスへの匿名のアクセスを可能にするのは、インターネットにおける一般的な習慣です。 伝統的に、プレーンテキストパスワードメカニズムでパスワードとしてEメールアドレスなどのユーザ名と任意のトレース情報として「匿名」で使用することでこれをしました。 平文ログインコマンドが新しいIETFプロトコルで受入れられないとき、匿名のログインを提供する新しい方法がSASL[SASL]フレームワークの文脈の中で必要です。

1. Conventions Used in this Document

1. このDocumentのコンベンションUsed

   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"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように本書では解釈されることになっているべきです。

2. Anonymous SASL mechanism

2. 匿名のSASLメカニズム

   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.

匿名のアクセスに関連しているメカニズム名は「匿名です」。 メカニズムはただ一つのクライアントからサーバまでのメッセージから成ります。クライアントは人間の読み込み可能なストリングの形で任意のトレース情報を送ります。 トレース情報は3つのフォームの1つを取るべきです: インターネットEメールアドレス、'@'キャラクタを含んでいて、クライアントのドメインのシステム管理者が解釈できない、不透明なストリング、または何でもない。 プライバシー理由のために、インターネットEメールアドレスは許可と共にユーザから使用されるだけであるべきです。

Newman                      Standards Track                     [Page 1]

RFC 2245                Anonymous SASL Mechanism           November 1997

SASLメカニズム1997年11月の匿名のニューマン標準化過程[1ページ]RFC2245

   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.

匿名のアクセスを可能にするサーバは、更生会メカニズムのサポートを発表して、そのメカニズムを使用することでログインするためにだれでも許容するでしょう、通常制限されたアクセサリーで

   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 '@'

TCHARは%x20とx41-7-3F/%E等しいです。 '@'を除いたどんな印刷可能な米国-ASCII文字

   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

メールはaddr-仕様と等しいです。 無料のノーを除いて、[IMAIL]で定義されるように。 そして、直線的な余白の挿入、。 中に地方の部分を完全に同封しなければなりません。 引用文か完全に引用を終わられます。

   token           = 1*255TCHAR

トークン=1*255TCHAR

3. Example

3. 例

   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:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 そのような系列が新しいaなしで包装される、「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.

S: * OK IMAP4のサーバ持ち合わせのC: A001能力S: * 能力IMAP4 IMAP4rev1 AUTH=一夜漬け-MD5 AUTHは匿名のSと等しいです: Cが行われたA001 OK: A002は匿名のSを認証します: + C: c2lyaGMはSと等しいです: A003 OK Welcome、トレース情報を登録してあります。

Newman                      Standards Track                     [Page 2]

RFC 2245                Anonymous SASL Mechanism           November 1997

SASLメカニズム1997年11月の匿名のニューマン標準化過程[2ページ]RFC2245

4. Security Considerations

4. セキュリティ問題

   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.

トレース情報として明白な許可なしでユーザの正しいEメールアドレスを使用するクライアントはそのユーザのプライバシーに違反するかもしれません。 だれがデリケートな話題(例えば、性的虐待)に関する匿名のアーカイブにアクセスするかに関する情報には、強いプライバシーの必要性があります。 クライアントは、ユーザの明白な許可なしでEメールアドレスを送るべきでなくて、跡のトークンを全く供給して、その結果、ソース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

不法侵入には、ある一般的な実装のテクニックを考えて、明白な匿名のログインを必要としないプロトコルは、より影響されやすいです。 明確に、ユーザログインを提供するUnixサーバーはそうするかもしれません。

Newman                      Standards Track                     [Page 3]

RFC 2245                Anonymous SASL Mechanism           November 1997

SASLメカニズム1997年11月の匿名のニューマン標準化過程[3ページ]RFC2245

   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 chroot機能)に入るかもしれません。 匿名のアクセスが明らかに要求されないなら、全体のデータ・アクセス機械は明白な保護処分のために機会なしで対外安全保障攻撃に暴露されます。 秘密データアクセスを提供するプロトコルは明白なログイン手順なしで匿名のデータ・アクセスを許容するべきではありません。

5. References

5. 参照

   [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.

[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
   Messages", STD 11, RFC 822, August 1982.

[IMAIL] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 2060, December 1996.

[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。

   [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
   RFC 2222, October 1997.

[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。

6. Author's Address

6. 作者のアドレス

   Chris Newman
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790 USA

クリスニューマンInnosoftの国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。

   Email: chris.newman@innosoft.com

メール: chris.newman@innosoft.com

Newman                      Standards Track                     [Page 4]

RFC 2245                Anonymous SASL Mechanism           November 1997

SASLメカニズム1997年11月の匿名のニューマン標準化過程[4ページ]RFC2245

7.  Full Copyright Statement

7. 完全な著作権宣言文

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Copyright(C)インターネット協会(1997)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Newman                      Standards Track                     [Page 5]

ニューマン標準化過程[5ページ]