RFC2095 日本語訳

Network Working Group                                       J. Klensin
Request for Comments: 2095                                    R. Catoe
Category: Standards Track                                 P. Krumviede
                                                                   MCI
                                                          January 1997

Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2095年のR.Catoeカテゴリ: 標準化過程P.Krumviede MCI1997年1月

       IMAP/POP AUTHorize Extension for Simple Challenge/Response

/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可します。

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)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   While IMAP4 supports a number of strong authentication mechanisms as
   described in RFC 1731, it lacks any mechanism that neither passes
   cleartext, reusable passwords across the network nor requires either
   a significant security infrastructure or that the mail server update
   a mail-system-wide user authentication file on each mail access.
   This specification provides a simple challenge-response
   authentication protocol that is suitable for use with IMAP4.  Since
   it utilizes Keyed-MD5 digests and does not require that the secret be
   stored in the clear on the server, it may also constitute an
   improvement on APOP for POP3 use as specified in RFC 1734.

IMAP4はRFC1731で説明されるように多くの強い認証機構をサポートしますが、それはネットワークの向こう側にcleartext、再使用可能パスワードを通過しないで、また重要なセキュリティインフラストラクチャと、メールサーバがそれぞれのメールアクセサリーの広い状態でシステムを郵送しているユーザー認証ファイルをアップデートするのを必要としないどんなメカニズムも欠いています。 この仕様は使用に適した簡単なチャレンジレスポンス認証プロトコルをIMAP4に供給します。 Keyed-MD5ダイジェストを利用して、秘密がサーバに関する明確に保存されるのが必要でないので、また、それはRFC1734における指定されるとしてのPOP3使用のためにAPOPより改良を構成するかもしれません。

1. Introduction

1. 序論

   Existing Proposed Standards specify an AUTHENTICATE mechanism for the
   IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
   intended to be extensible; the four methods specified in [IMAP-AUTH]
   are all fairly powerful and require some security infrastructure to
   support.  The base POP3 specification [POP3] also contains a
   lightweight challenge-response mechanism called APOP.  APOP is
   associated with most of the risks associated with such protocols: in
   particular, it requires that both the client and server machines have
   access to the shared secret in cleartext form. CRAM offers a method
   for avoiding such cleartext storage while retaining the algorithmic
   simplicity of APOP in using only MD5, though in a "keyed" method.

既存のProposed StandardsはPOP3プロトコル[POP3-AUTH]としてIMAP4プロトコル[IMAP、IMAP-AUTH]と平行なAUTHメカニズムにAUTHENTICATEメカニズムを指定します。 AUTHENTICATEメカニズムが広げることができることを意図します。 [IMAP-AUTH]で指定された4つのメソッドが、かなりすべて強力であり、サポートへの何らかのセキュリティインフラストラクチャを必要とします。 また、ベースPOP3仕様[POP3]はAPOPと呼ばれる軽量のチャレンジレスポンスメカニズムを含んでいます。 APOPはそのようなプロトコルに関連しているリスクの大部分に関連しています: 特に、それは、cleartextの共有秘密キーへのアクセスがクライアントとサーバマシンの両方によって形成されるのを必要とします。 CRAMはMD5だけを使用する際にAPOPのアルゴリズムの簡単さを保有している間、そのようなcleartextストレージを避けるためにメソッドを提供します、「合わせられた」メソッドで。

Klensin, Catoe & Krumviede  Standards Track                     [Page 1]

RFC 2095              IMAP/POP AUTHorize Extension          January 1997

標準化過程[1ページ]RFC2095IMAP/が飛び出させるKlensin、Catoe、およびKrumviedeは1997年1月に拡大を認可します。

   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
   The only alternative to the strong mechanisms identified in [IMAP-
   AUTH] is a presumably cleartext username and password, supported
   through the LOGIN command in [IMAP].  This document describes a
   simple challenge-response mechanism, similar to APOP and PPP CHAP
   [PPP], that can be used with IMAP (and, in principle, with POP3).

現在のところ、IMAP[IMAP]はAPOPに対応するどんな施設も欠いています。 [IMAP- AUTH]で特定された強いメカニズムへの唯一の選択肢が、[IMAP]のLOGINコマンドでサポートされたおそらくcleartextなユーザ名とパスワードです。 このドキュメントがIMAPと共に使用できるAPOPとPPP CHAP[PPP]と同様の簡単なチャレンジレスポンスメカニズムについて説明する、(原則としてPOP3、)

   This mechanism also has the advantage over some possible alternatives
   of not requiring that the server maintain information about email
   "logins" on a per-login basis.  While mechanisms that do require such
   per-login history records may offer enhanced security, protocols such
   as IMAP, which may have several connections between a given client
   and server open more or less simultaneous, may make their
   implementation particularly challenging.

また、このメカニズムには、サーバが、メールの情報が1ログインあたり1個のベースに「ログインする」と主張するのが必要でないことのいくつかの可能な選択肢より利点があります。 そのような1ログインあたりの歴史記録を必要とするメカニズムが警備の強化を提供しているかもしれない間、IMAPなどのプロトコルで彼らの実装は特にやりがいがあるようになるかもしれません。(IMAPは与えられたクライアントとサーバ戸外とのいくつかの接続を多少同時にするかもしれません)。

2. Challenge-Response Authentication Mechanism (CRAM)

2. チャレンジレスポンス認証メカニズム(一夜漬け)

   The authentication type associated with CRAM is "CRAM-MD5".

CRAMに関連づけられた認証タイプは「一夜漬け-MD5"」です。

   The data encoded in the first ready response contains an
   presumptively arbitrary string of random digits, a timestamp, and the
   fully-qualified primary host name of the server.  The syntax of the
   unencoded form must correspond to that of an RFC 822 'msg-id'
   [RFC822] as described in [POP3].

データが最初の持ち合わせの応答が含むコネをコード化した、仮に、乱数の任意のストリング、タイムスタンプ、および. 暗号化されていないフォームの構文がそうしなければならないサーバの完全に適切な一次ホスト名は[POP3]で説明されるようにRFC822'msg-イド'[RFC822]のものに対応しています。

   The client makes note of the data and then responds with a string
   consisting of the user name, a space, and a 'digest'.  The latter is
   computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
   the key is a shared secret and the digested text is the timestamp
   (including angle-brackets).

クライアントは、データのメモを作って、次に、ストリングがユーザ名、スペース、および'ダイジェスト'から成っていて、応じます。 後者は、キーが共有秘密キーであり、読みこなされたテキストがタイムスタンプ(角ブラケットを含んでいて)であるところで[KEYED-MD5]から合わせられたMD5アルゴリズムを適用することによって、計算されます。

   This shared secret is a string known only to the client and server.
   The `digest' parameter itself is a 16-octet value which is sent in
   hexadecimal format, using lower-case ASCII characters.

この共有秘密キーはクライアントとサーバだけに知られているストリングです。'ダイジェスト'パラメタ自体は16進形式で送られる16八重奏の値です、小文字のASCII文字を使用して。

   When the server receives this client response, it verifies the digest
   provided.  If the digest is correct, the server should consider the
   client authenticated and respond appropriately.

サーバがこのクライアント応答を受けるとき、それは提供されたダイジェストについて確かめます。 ダイジェストが正しいなら、サーバは、適切にクライアントが認証されていると考えて、反応するべきです。

   Keyed MD5 is chosen for this application because of the greater
   security imparted to authentication of short messages. In addition,
   the use of the techniques described in [KEYED-MD5] for precomputation
   of intermediate results make it possible to avoid explicit cleartext
   storage of the shared secret on the server system by instead storing
   the intermediate results which are known as "contexts".

合わせられたMD5は短いメッセージの認証に伝えられたよりすばらしいセキュリティのためにこのアプリケーションに選ばれています。 さらに、中間結果の前計算のために[KEYED-MD5]で説明されたテクニックの使用で、代わりに「文脈」として知られている中間結果を保存することによってサーバシステムにおける共有秘密キーの明白なcleartextストレージを避けるのは可能になります。

Klensin, Catoe & Krumviede  Standards Track                     [Page 2]

RFC 2095              IMAP/POP AUTHorize Extension          January 1997

標準化過程[2ページ]RFC2095IMAP/が飛び出させるKlensin、Catoe、およびKrumviedeは1997年1月に拡大を認可します。

   CRAM does not support a protection mechanism.

CRAMは保護メカニズムをサポートしません。

   Example:

例:

   The examples in this document show the use of the CRAM mechanism with
   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
   the challenges and responses is part of the IMAP4 AUTHENTICATE
   command, not part of the CRAM specification itself.

例は本書ではIMAP4 AUTHENTICATEコマンド[IMAP-AUTH]によるCRAMメカニズムの使用を示しています。 挑戦と応答のbase64コード化はCRAM仕様の一部ではなく、IMAP4 AUTHENTICATEコマンドの一部自体です。

     S: * OK IMAP4 Server
     C: A0001 AUTHENTICATE CRAM-MD5
     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
     S: A0001 OK CRAM authentication successful

S: * IMAP4サーバCを承認してください: A0001は一夜漬け-MD5 Sを認証します: +PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw S: A0001 OK CRAM認証うまくいきます。

      In this example, the shared secret is the string
      'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
      calculating

この例では、共有秘密キーはストリング'tanstaaftanstaaf'です。 したがって、Keyed MD5ダイジェストは、計算することによって、製作されます。

        MD5((tanstaaftanstaaf XOR opad),
            MD5((tanstaaftanstaaf XOR ipad),
            <1896.697170952@postoffice.reston.mci.net>))

MD5(tanstaaftanstaaf XOR opad)、MD5(tanstaaftanstaaf XOR ipad)、 <1896.697170952@postoffice.reston.mci.net 、gt;、)

      where ipad and opad are as defined in the keyed-MD5 Work in
      Progress [KEYED-MD5] and the string shown in the challenge is the
      base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
      shared secret is null-padded to a length of 64 bytes. If the
      shared secret is longer than 64 bytes, the MD5 digest of the
      shared secret is used as a 16 byte input to the keyed MD5
      calculation.

Progressの合わせられたMD5 Workの[KEYED-MD5]とストリングに挑戦で示されているのが、ipadとopadが定義されるとしてあるところでは、 of <1896.697170952@postoffice.reston.mci.net をコード化するbase64である、gt。 共有秘密キーはヌルに64バイトの長さにそっと歩いています。 共有秘密キーが64バイトより長いなら、共有秘密キーのMD5ダイジェストは16バイトの入力として合わせられたMD5計算に使用されます。

      This produces a digest value (in hexadecimal) of

aが値(16進の)を読みこなすこの生産物

           b913a602c7eda7a495b4e6e7334d3890

b913a602c7eda7a495b4e6e7334d3890

      The user name is then prepended to it, forming

そして、形成して、ユーザ名はそれにprependedされます。

           tim b913a602c7eda7a495b4e6e7334d3890

tim b913a602c7eda7a495b4e6e7334d3890

      Which is then base64 encoded to meet the requirements of the IMAP4
      AUTHENTICATE command (or the similar POP3 AUTH command), yielding

そして、どれが条件を満たすためにコード化されたIMAP4 AUTHENTICATEコマンド(または、同様のPOP3 AUTHコマンド)、もたらすことのbase64ですか。

           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

Klensin, Catoe & Krumviede  Standards Track                     [Page 3]

RFC 2095              IMAP/POP AUTHorize Extension          January 1997

標準化過程[3ページ]RFC2095IMAP/が飛び出させるKlensin、Catoe、およびKrumviedeは1997年1月に拡大を認可します。

3. References

3. 参照

   [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
       RFC 1334, October 1992.

[ひびが切れます] ロイド、B.とW.シンプソン、「ppp認証プロトコル」、RFC1334、1992年10月。

   [IMAP] Crispin, M., "Internet Message Access Protocol - Version
       4rev1", RFC 2060, University of Washington, December 1996.

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

   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
       RFC 1731, Carnegie Mellon, December 1994.

[IMAP-AUTH] マイアーズ、J.、「IMAP4認証機構」、RFC1731、カーネギー・メロン、1994年12月。

   [KEYED-MD5] Krawczyk, H., "HMAC-MD5: Keyed-MD5 for Message
       Authentication", Work in Progess.

[合わせられたMD5]のKrawczyk、H.、「HMAC-MD5:」 「通報認証のための合わせられたMD5」はProgessで働いています。

   [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
       RFC 1321, MIT Laboratory for Computer Science, April 1992.

[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、MITコンピュータサイエンス研究所、1992年4月。

   [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
       STD 53, RFC 1939, Carnegie Mellon, May 1996.

[POP3] マイアーズ、J.、およびM.ローズ、「バージョン3インチ、STD53、RFC1939、カーネギー・メロン、1996年POP--5月。」

   [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
       Carnegie Mellon, December, 1994.

[POP3-AUTH] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、カーネギー・メロン、1994年12月。

4. Security Considerations

4. セキュリティ問題

   It is conjectured that use of the CRAM authentication mechanism
   provides origin identification and replay protection for a session.
   Accordingly, a server that implements both a cleartext password
   command and this authentication type should not allow both methods of
   access for a given user.

CRAM認証機構の使用がセッションのために発生源識別と反復操作による保護を提供すると推測されます。 それに従って、両方がcleartextパスワードコマンドとこの認証タイプであると実装するサーバは与えられたユーザのためのアクセスの両方のメソッドを許容するべきではありません。

   While the saving, on the server, of "contexts" (see section 2) is
   marginally better than saving the shared secrets in cleartext as is
   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
   protect the secrets if the server itself is compromised.
   Consequently, servers that store the secrets or contexts must both be
   protected to a level appropriate to the potential information value
   in user mailboxes and identities.

サーバに関する「文脈」の節約はそのままでcleartextの共有秘密キーを保存するのがCHAP[CHAP]とAPOP[POP3]が必要であるというよりもわずかに良いのですが(セクション2を見ます)、サーバ自体が感染されるなら、秘密を保護するために十分ではありません。 その結果、ともにユーザメールボックスとアイデンティティにおける潜在的情報価値に適切なレベルに秘密か文脈を保存するサーバを保護しなければなりません。

   As the length of the shared secret increases, so does the difficulty
   of deriving it.

共有秘密キーの長さが増加するのに従って、それを引き出すという困難もそうします。

   While there are now suggestions in the literature that the use of MD5
   and keyed MD5 in authentication procedures probably has a limited
   effective lifetime, the technique is now widely deployed and widely
   understood.  It is believed that this general understanding may
   assist with the rapid replacement, by CRAM-MD5, of the current uses
   of permanent cleartext passwords in IMAP.   This document has been

現在、認証手順によるMD5と合わせられたMD5の使用には限られた有効な寿命がたぶんあるという文学における提案がある間、テクニックは、現在、広く配布されて、広く理解されています。 この一般的な意味解釈が急速な交換を助けるかもしれないと信じられています、CRAM-MD5IMAPの永久的なcleartextパスワードの現在の用途で。 このドキュメントはありました。

Klensin, Catoe & Krumviede  Standards Track                     [Page 4]

RFC 2095              IMAP/POP AUTHorize Extension          January 1997

標準化過程[4ページ]RFC2095IMAP/が飛び出させるKlensin、Catoe、およびKrumviedeは1997年1月に拡大を認可します。

   deliberately written to permit easy upgrading to use SHA (or whatever
   alternatives emerge) when they are considered to be widely available
   and adequately safe.

広く利用可能であって、適切に安全であると考えられるとき、簡単なアップグレードがSHA(どんな代替手段も現れる)を使用することを許可するために故意に書かれています。

   Even with the use of CRAM, users are still vulnerable to active
   attacks.  An example of an increasingly common active attack is 'TCP
   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].

CRAMの使用があっても、ユーザはまだ活発な攻撃に被害を受け易いです。 ますます一般的な活発な攻撃に関する例はCERT勧告カリフォルニア-95で説明されるように'TCP Session Hijacking'です: 01[CERT95]。

   See section 1 above for additional discussion.

追加議論において、セクション1が上であることを見てください。

5. Acknowledgements

5. 承認

   This memo borrows ideas and some text liberally from [POP3] and
   [RFC-1731] and thanks are due the authors of those documents.  Ran
   Atkinson made a number of valuable technical and editorial
   contributions to the document.

このメモは[POP3]と[RFC-1731]から考えと何らかのテキストを気前よく借ります、そして、感謝は当然です。それらのドキュメントの作者。 ドキュメントへのアトキンソン人工のa番号の貴重な技術的で編集の貢献を走らせました。

6. Authors' Addresses

6. 作者のアドレス

   John C. Klensin
   MCI Telecommunications
   800 Boylston St, 7th floor
   Boston, MA 02199
   USA

ジョンC.Klensin MCI Telecommunications800Boylston通り、7階のボストン、MA02199米国

   EMail: klensin@mci.net
   Phone: +1 617 960 1011

メール: klensin@mci.net 電話: +1 617 960 1011

   Randy Catoe
   MCI Telecommunications
   2100 Reston Parkway
   Reston, VA 22091
   USA

ランディのCatoe MCIテレコミュニケーション2100レストンParkwayヴァージニア22091レストン(米国)

   EMail: randy@mci.net
   Phone: +1 703 715 7366

メール: randy@mci.net 電話: +1 703 715 7366

   Paul Krumviede
   MCI Telecommunications
   2100 Reston Parkway
   Reston, VA 22091
   USA

ポールKrumviede MCIテレコミュニケーション2100レストンParkwayヴァージニア22091レストン(米国)

   EMail: paul@mci.net
   Phone: +1 703 715 7251

メール: paul@mci.net 電話: +1 703 715 7251

Klensin, Catoe & Krumviede  Standards Track                     [Page 5]

Klensin、Catoe、およびKrumviede標準化過程[5ページ]