Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
この文書は RFC 3207 の邦訳です. 原文は, http://www.ietf.org/rfc/rfc3207.txt を参照してください. 参考訳なので,標準としての効力は無いことに注意してください. この翻訳の誤訳,誤記等によって生じた如何なる損害にも訳者は一切責任を負いません. RFC としての詳細は原文を参照してください. この翻訳の転載,引用,再配布等に関する条件は原文のそれと同じです. 最新版は http://hori.homelinux.net/rfc/ にて公開します. 連絡は 堀 豊 (Hori Yutaka) ( g440197@mail.ecc.u-tokyo.ac.jp )にお願いします. 誤訳,誤記の指摘や意見,感想を歓迎します. RFC 3207 は原文に訂正が発表されています. http://www.rfc-editor.org/errata.html から辿ってください. ------------------------------------------------------------------------- Network Working Group P. Hoffman Request for Comments: 3207 Internet Mail Consortium Obsoletes: 2487 February 2002 Category: Standards Track Transport Layer Security を用いたセキュアな SMTP の為の SMTP サービス拡張 この文書の状態 この文書はインターネットコミュニティにおけるインターネット標準化過程を 規定し,改良の為に議論や意見を要求するものである.標準化の状態およびこの プロトコルの状態は "Internet Official Protocol Standards" (STD 1) を 参照されたい.この文書の配布は制限されない. 著作権について Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 この文章は, SMTP (Simple Mail Transfer Protocol) サーバとクライアントが TLS (Trasport Layer Security) を用い，インターネットにおいて非公開,認証 付きの通信を可能にする為の SMTP サービスの拡張について言及したものである. これによって, SMTP エージェントは, SMTP の通信を盗み見たりアタックしようと したりする人達から通信のいくらか，または全てを守ることができる. 1. 導入 SMTP [RFC2821] サーバとクライアントは通常,インターネット上で平文で通信を 行う.多くの場合,この通信は送信者か受信者によってコントロールされたり 信用されたりしていない1つ以上のルータを経由する.そのような信用できない ルータの存在によって,第三者によるサーバ,クライアント間の通信の傍受や改変の おそれがある． さらに，2つの SMTP エージェントが相互に身元を認証しあうことが望まれる場合が しばしばある.例えば，安全な SMTP サーバは既知の SMTP エージェントからの 通信のみを許可しているかもしれないし，または，既知のエージェントから受信した メッセージと未知のエージェントから受信したメッセージとで異なる処理をするかも しれない. Hoffman Standards Track [Page 1]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 一般的には SSL として知られていることが多い TLS [TLS] は,プライバシーを 保ち,認証を行う高度な TCP 通信の為のメカニズムとして有名である. TLS は HTTP プロトコルで広く使用されており,また, TCP を用いた数多くの一般的 なプロトコルのセキュリティを向上させている． この文書は RFC 2487 を廃棄するものである. 1.1 用語の定義 この文章で用いられる以下のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL" , "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", そして "OPTIONAL" は [RFC2119] に言及されているように解釈されたい． 2. STARTTLS 拡張 SMTP を拡張した STARTTLS は以下のように設計されている． (1) SMTP サービスは，ここにおいては STARTTLS と定義される; (2) EHLO キーワードの拡張に関する値は STARTTLS である; (3) STARTTLS キーワードはパラメタを持たない; (4) どの SMTP コマンドに対しても新たなパラメタの追加は無い; 3. STARTTLS キーワード STARTTLS キーワードは SMTP クライアントに対して,その SMTP サーバが 現在, TLS の使用の交渉に応じられることを伝えるのに用いられる.この キーワードはパラメタを伴わない. 4. STARTTLS コマンド STARTTLS コマンドのフォーマットは: STARTTLS であり，パラメタは無い． クライアントが STARTTLS コマンドを発行した後，サーバは以下の応答コードの内の 1つを返答する． 220 Ready to start TLS 501 Syntax error (no parameters allowed) 454 TLS not available due to temporary reason Hoffman Standards Track [Page 2]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 もしもクライアントが 454 の返答を受けとった場合は,クライアントは SMTP セッションを継続するか否かを決めなければならない(MUST).その ような決断はローカルポリシーに基づく．例えば, TLS がクライアントの 認証の為に用いられた場合は,サーバがたとえ認証無しでもセッションの継続を 認める場合に限って,クライアントはセッションを継続しようとするであろう． しかし,もしも TLS が暗号化の為に用いられるということが取り決められていた 場合, 454 の返答を受けとったクライアントは TLS による暗号化無しで メッセージを送信するか，それともしばらく待って後で再度試みるか,それとも あきらめて送り主にエラーを知らせるかを決めなければならない． 公に参照される SMTP サーバはメールをローカルに配送する場合には STARTTLS 拡張を用いることを要求してはならない. (MUST NOT) このルールは, インターネット上のSMTP の構造基盤である相互操作性 (interoperability) が STARTTLS 拡張によって,損なわれることが無いようにする為のものである. 公に参照される SMTP サーバとは,インターネットメールアドレスの右手側に 書かれるドメインネームの代用として用いられるMXレコード (MXレコードが存在 しない場合はA レコード) に記載されているインターネットホストのポート 25 において実行されている SMTP サーバのことである． どの SMTP サーバも, TLS による交渉の間に提供された認証情報に基づいて， 中継の為のメッセージの受け入れを拒否するかもしれない (MAY) .公に参照 されない SMTP サーバは, TLSによる交渉の間に提供された認証情報に基づいて, 中継やローカル配送のための全てのメッセージの受け入れを拒否するかもしれない (MAY) . 公に参照されない SMTP サーバはあらゆるコマンドを受け入れる前に, クライアントがTLS による交渉を行うことを要求することにするかもしれない (MAY) .この場合,サーバは以下の応答コードを返答すべきである (SHOULD) : 530 Must issue a STARTTLS command first (530 はじめに，STARTTLS コマンドを発行しなければいけない) NOOP , EHLO , STARTTLS または QUIT コマンド以外の全てのコマンドよりも前に． もしもクライアントとサーバが ENHANCEDSTATUSCODES ESMTP 拡張 [RFC2034] を 利用している場合は，ステータスコードは 5.7.0 が返答されるべきである (SHOULD) ． STARTTLS コマンドに対して 220 の返答を受けとった後，クライアントは TLS による交渉を他のどの SMTP コマンドの発行よりも先に行わなければならない (MUST) .STARTTLS コマンドが発行された後に,もしもクライアントが,実際には TLS ハンドシェイクを行えない何らかの障害を発見した場合は，接続を中止すべき である (SHOULD) ． SMTP クライアントが RFC 2920 で定義されているパイプラインを用いている場合， STARTTLS コマンドはコマンド郡の最後のコマンドでなければならない (MUST) . Hoffman Standards Track [Page 3]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 4.1 STARTTLS コマンドの後の手順 TLS ハンドシェイクが完了した後，双方は完了した認証とプライバシーの程度に 基づいて即座に継続するか否かを決定しなければならない (MUST) .SMTP クライアントとサーバは，たとえ TLS による交渉の結果,認証とプライバシーの程度 のいずれかもしくは両方が達成されなくても継続するような決定を下すかもしれない (MAY) .なぜならば，大抵の SMTP サービスは認証とプライバシー無しで行われて いるからである．しかし, SMTP クライアントやサーバの中にはある特定のレベルの 認証とプライバシーのいずれかもしくは両方が達成された場合に限り継続したい ものもあるかもしれない (MAY) . もしも SMTP クライアントが,認証またはプライバシーのレベルが継続するのに 不十分であると決定した場合は, TLS による交渉が完了した後，即座に SMTP QUIT コマンドを発行すべきである (SHOULD) .もしも SMTP サーバが,認証または プライバシーのレベルが継続するのに不十分であると決定した場合は,クライアント からの全ての SMTP コマンド (QUIT コマンド以外)に対して ("Command refused due to lack of security" のようなふさわしいテキスト文字列と共に) 554 応答 コードを返答すべきである (SHOULD) . TLS による交渉において,相手の認証情報を信じるか否かはローカル側の問題である. しかし,その決定の為のいくつかの一般的なルールは: - SMTP クライアントは，接続先だとが考えているところのドメインネームが 記載されたサーバ証明書を持っている SMTP サーバを認証したいだけかもしれない. - 公に参照される SMTP サーバはおそらく, SMTP クライアントから,正当な証明書 は全て受け入れたいと考え,そして,中継されたりクライアントから送信されたり したメッセージの Received ヘッダに証明書の識別の情報をできる限り付加 したいと考えるであろう． 4.2 STARTTLS コマンドの結果 TLS ハンドシェイクの完了と同時に SMTP プロトコルは初期状態にリセットされる (SMTP はサーバが 220 service ready グリーティングを発行した後の状態である) サーバは, TLS による交渉自体によって得たのではない EHLO コマンドの引数の ようなクライアントから得た全ての情報を破棄しなければならない (MUST) . クライアントは TLS による交渉自体によって得たのではない SMTP サービス拡張 のリストのようなサーバから得た全ての情報を破棄しなければならない (MUST) . クライアントは TLS による交渉が成功した後,最初のコマンドとして EHLO を送信 すべきである (SHOULD) . TLS ハンドシェイクの後に, EHLO コマンドの返答として受けとられる SMTP サービス拡張のリストは TLS ハンドシェイクの前に返答されるリストと異なる かもしれない (MAY) . Hoffman Standards Track [Page 4]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 例えば, TLS ハンドシェイクの間にクライアントが適切なクライアント証明書を 送信しなければ, SMTP サーバはある特定の SASL [SASL] 機構のサポートを宣言 したくないかもしれない. クライアントとサーバは共に TLS セッションがアクティブであるか否かを 感知していなければならない (MUST) . TLS セッションがすでにアクティブである 場合は,クライアントは TLS セッションの開始を試みてはいけない (MUST NOT) . サーバは TLS ハンドシェイクが完了した後で受けとった EHLO コマンドの返答に STARTTLS 拡張を含めてはいけない (MUST NOT) . 4.3 サブミッションポートにおける STARTTLS STARTTLS が [RFC2476] に定義されているサブミッションポート (Submission port) 上で使用される場合は,正当な ESMTP である．実際,サブミッションポートは, その定義から公に参照されない SMTP サーバ であるから, STARTTLS 拡張はこの サーバのセキュリテリの確保と認証にとりわけ有効である． 5. 使用例 以下の対話はクライアントとサーバがどのようにして TLS セッションを開始するか を示しているものである: S: C: S: 220 mail.imc.org SMTP service ready C: EHLO mail.example.com S: 250-mail.imc.org offers a warm hug of welcome S: 250-8BITMIME S: 250-STARTTLS S: 250 DSN C: STARTTLS S: 220 Go ahead C: C & S: C & S: C: EHLO mail.example.com S: 250-mail.imc.org touches your hand gently for a moment S: 250-8BITMIME S: 250 DSN 6. セキュリテリの考慮 SMTP がエンド to エンド間の機構でないことに注意されたい．従って,もしも SMTP クライアントとサーバのペアが TLS によるプライバシーを付加した場合でも, それらは大元のメールユーザエージェント (mail user agent) から送り先までの 転送を安全にしているものではないということである． Hoffman Standards Track [Page 5]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 さらに,一通のメールの配送は2つ以上の SMTP サーバを経由することになるだろう から, 一組のサーバ間で TLS プライバシーを付加したとしても，それは SMTP による転送路の全てをプライベートなものにしたわけではない．さらに, SMTP サーバが SMTP クライアントの認証を行うことが可能であるからといって, クライアントはメールを受けとるときにその SMTP クライアントがそのメールを 認証したということにはならないのである． SMTP クライアントとサーバの双方が TLS による交渉の結果を確認し,認証と プライバシーのレベルが受け入れるに値するか否かを判断しなければならない (MUST) .このステップを無視すれば, TLS をセキュリテリの為に用いることが 無効になってしまう.認証やプライバシーの程度が受け入れに値するか否かを 決定するのはローカルの問題であって,実装依存であり,この文章の感知するところ ではない. SMTP クライアントとサーバは TLS による交渉の結果に注意をはらうべきである (SHOULD) .もしも交渉の結果としてプライバシーがなかったり,プライバシー保護の 為に利用されるアルゴリズムや鍵長の強度が足りないと思ったり,認証がどちらか 一方にとって不十分である場合には,クライアントは QUIT コマンドを即座に発行 してSMTP セッションを終了することにするだろうし,サーバはそれ以上 SMTP コマンドを受け入れないようにするであろう (MAY) . サーバからの "250 STARTTLS" の返答を取り除くことによって，仲介者攻撃 (man-in-the-middle attack) が可能である.こうすることで,クライアントが TLS セッションを開始しないようになる.また別の仲介者攻撃の例では,サーバは STARTTLS が可能である旨をアナウンスすることはできても,クライアントの TLS 開始のリクエストとサーバの返答を変更してしまうのである.このような攻撃から 守る為にクライアントとサーバの双方はメッセージが正常に転送される前に,選択 されたホストとの適切な暗号に関する,正常な TLS による交渉の要求が構築される ようにしなければならない (MUST) .TLS の利用の際には可能ならば追加オプション も提供されるべきである (SHOULD) . TLS による交渉の結果が失敗であったり，クライアントが 454 の返答を受けとった りした場合は,クライアントは次に何をすべきかを決めなければならない． それには，主に3つの選択がある : 残りの SMTP セッションを続けるか,後で TLS を再度試みるか,あきらめて送り主にメールを送り返すか,である. 失敗やエラーが生じている場合,クライアントは,将来的にはサーバが TLS による 交渉が可能になるものだと仮定でき,ローカルで定めるタイムアウトをするまでの間, 後のセッションで TLS による交渉を試みるべきである (SHOULD) .そして, タイムアウトをした時点で，そのクライアントはメールを送り主に送り返すべきで ある (SHOULD).しかし，もしもクライアントとサーバが TLS を認証の為だけに 用いている場合は,クライアントがしようとしている操作のいくらかが,認証無しでも サーバに受け入れられる場合に,クライアントは SMTP セッションを継続しようと するかもしれない (MAY) . TLS ハンドシェイクの開始前に,プロトコルのどの通信も消去され，能動的な攻撃者 によって改ざんされるかもしれない (MAY) . Hoffman Standards Track [Page 6]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 この理由により,クライアントとサーバは TLS ハンドシェイクの開始から終了 の間に得た全ての情報を破棄しなければならない (MUST) . STARTTLS 拡張は，一番はじめの SMTP サーバへのメッセージの提出を含めて 一連のメール配送の全ての段階で認証が行われない限り,メールメッセージの著者の 認証に用いるのは不適当なものである.配送を認証するために用いることができる [SMTP-AUTH] やメールメッセージの著者の認証の為に用いることができるMIME security multiparts [MIME-SEC] が別途提案されている.さらにいえば, [SMTP-AUTH] では, SMTP クライアントを認証するためのより簡潔でより フレキシブルなオプションが提供されているし,SASL EXTERNAL [SASL] のメカニズム は STARTTLS コマンドと共同で本人の認証のために用いられるだろう (MAY) . 7. 参考文献 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Hoffman Standards Track [Page 7]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 付録 この文書は Proposed Standard である RFC 2487 の改訂版である.この文書で 変更した点は : - セクション 5 と 7: 仲介者攻撃に関する更なる言及 - セクション 5: サーバが STARTTLS 拡張を宣言すべき時とすべきでない時に 関する言及の追加 - セクション 5: SMTP クライアントが 220 の返答を受けとった後の要求の変更 - セクション 5.1: 証明書の認証に関する言及の明確化 - セクション 5.3: 「サブミッションポートにおける STARTTLS」("STARTTLS on the Submission Port") を追加 - セクション 6: セクション 5.2 ですでに言及しているクライアントが新規に EHLO コマンドを発行する必要がある場合を示す例のバグの修正 - セクション 7: 受け入れ可能なプライバシーの程度に関するパラグラフの明確化 仲介者攻撃の回避の仕方に関する言及の重要な変更 - セクション A: 参考文献を RFC 821 から RFC 2821 へ変更 著者のアドレス Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 電話: (831) 426-9827 Eメール: phoffman@imc.org 訳者のアドレス 堀 豊 (Hori Yutaka) Eメール: g440197@mail.ecc.u-tokyo.ac.jp Hoffman Standards Track [Page 8]  RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 著作権表記全文 Copyright (C) The Internet Society (2002). 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. 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. 謝辞 RFC 編集者の為の資金は現在 Internet Society によって提供されている. Hoffman Standards Track [Page 9]