RFC2595 日本語訳
2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT=32440 bytes) (Updated by RFC4616) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Newman Request for Comments: 2595 Innosoft Category: Standards Track June 1999
コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 2595年のInnosoftカテゴリ: 標準化過程1999年6月
Using TLS with IMAP, POP3 and ACAP
IMAP、POP3、およびACAPとTLSを使用します。
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Motivation
1. 動機
The TLS protocol (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. The option of using such security is desirable for IMAP, POP and ACAP due to common connection eavesdropping and hijacking attacks [AUTH]. Although advanced SASL authentication mechanisms can provide a lightweight version of this service, TLS is complimentary to simple authentication-only SASL mechanisms or deployed clear-text password login commands.
TLSプロトコル(以前、SSLとして知られている)は改ざんと盗聴からアプリケーション・プロトコルを保証する方法を提供します。 IMAP、POP、およびACAPに、そのようなセキュリティを使用するオプションは攻撃[AUTH]を盗み聞いて、ハイジャックしている共通接続のために望ましいです。 高度なSASL認証機構はこのサービスの軽量のバージョンを提供できますが、TLSは簡単な認証だけSASLメカニズムか配布しているクリアテキストパスワードログインコマンドに賞賛です。
Many sites have a high investment in authentication infrastructure (e.g., a large database of a one-way-function applied to user passwords), so a privacy layer which is not tightly bound to user authentication can protect against network eavesdropping attacks without requiring a new authentication infrastructure and/or forcing all users to change their password. Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. (Note there is a separate RFC for the STARTTLS command in SMTP [SMTPTLS].)
多くのサイトが認証インフラストラクチャに高い投資を持っているので(例えば一方向機能の大容量データベースはユーザパスワードに適用されました)、新しい認証インフラストラクチャを必要とする、そして/または、すべてのユーザに彼らのパスワードを変えさせないで、しっかりユーザー認証に縛られないプライバシー層はネットワーク盗聴攻撃から守ることができます。 そのようなサイトがTLS暗号化と組み合わせて簡単なパスワード認証を望むと認めて、この仕様は使用のためにACAPやSMTPなどの簡単なパスワード認証コマンドを欠いているプロトコルでPLAIN SASLメカニズムを定義します。 (SMTP[SMTPTLS]のSTARTTLSコマンドのための別々のRFCがあることに注意してください。)
There is a strong desire in the IETF to eliminate the transmission of clear-text passwords over unencrypted channels. While SASL can be used for this purpose, TLS provides an additional tool with different deployability characteristics. A server supporting both TLS with
非暗号化されたチャンネルの上にクリアテキストパスワードの伝達を排除するために、強い願望がIETFにあります。 このためにSASLを使用できますが、TLSは異なったdeployabilityの特性を追加ツールに提供します。 両方のTLSをサポートするサーバ
Newman Standards Track [Page 1] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[1ページ]RFC2595
simple passwords and a challenge/response SASL mechanism is likely to interoperate with a wide variety of clients without resorting to unencrypted clear-text passwords.
SASLメカニズムがさまざまなクライアントと共に非暗号化されたクリアテキストパスワードに訴えないで共同利用しそうである簡単なパスワードと挑戦/応答。
The STARTTLS command rectifies a number of the problems with using a separate port for a "secure" protocol variant. Some of these are mentioned in section 7.
STARTTLSコマンドは「安全な」プロトコル異形に別々のポートを使用することに関する多くの問題を調整します。 セクション7でこれらの或るものは言及されます。
1.1. Conventions Used in this Document
1.1. このDocumentのコンベンションUsed
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」、「5月」、このドキュメントで「任意」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように解釈されることであるべきです。
Terms related to authentication are defined in "On Internet Authentication" [AUTH].
認証に関連する用語は「インターネット認証」[AUTH]で定義されます。
Formal syntax is defined using ABNF [ABNF].
正式な構文は、ABNF[ABNF]を使用することで定義されます。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
2. Basic Interoperability and Security Requirements
2. 基本的な相互運用性とセキュリティ要件
The following requirements apply to all implementations of the STARTTLS extension for IMAP, POP3 and ACAP.
以下の要件はIMAP、POP3、およびACAPのためにSTARTTLS拡張子のすべての実装に適用されます。
2.1. Cipher Suite Requirements
2.1. 暗号スイート要件
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite is REQUIRED. This is important as it assures that any two compliant implementations can be configured to interoperate.
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA[TLS]暗号スイートの実装はREQUIREDです。 共同利用するためにどんな2つの対応する実装も構成できることを保証するので、これは重要です。
All other cipher suites are OPTIONAL.
他のすべての暗号スイートがOPTIONALです。
2.2. Privacy Operational Mode Security Requirements
2.2. プライバシーの操作上のモードセキュリティ要件
Both clients and servers SHOULD have a privacy operational mode which refuses authentication unless successful activation of an encryption layer (such as that provided by TLS) occurs prior to or at the time of authentication and which will terminate the connection if that encryption layer is deactivated. Implementations are encouraged to have flexability with respect to the minimal encryption strength or cipher suites permitted. A minimalist approach to this recommendation would be an operational mode where the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to permitting authentication.
クライアントとサーバSHOULDの両方には、暗号化層(TLSによって提供されたそれなどの)のうまくいっている起動が認証の前か認証時点に起こらない場合認証を拒否して、その暗号化層が非活性化されるなら接続を終えるプライバシーの操作上のモードがあります。 実装で最小量の暗号化の強さか暗号スイートに関するflexabilityを受入れるよう奨励されます。 この推薦への最小主義アプローチは認証を可能にする前にTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートが義務的である操作上のモードでしょう。
Newman Standards Track [Page 2] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[2ページ]RFC2595
Clients MAY have an operational mode which uses encryption only when it is advertised by the server, but authentication continues regardless. For backwards compatibility, servers SHOULD have an operational mode where only the authentication mechanisms required by the relevant base protocol specification are needed to successfully authenticate.
それがサーバによって広告に掲載されるときだけ、クライアントには、暗号化を使用する操作上のモードがあるかもしれませんが、認証は不注意に続きます。 遅れている互換性のために、サーバSHOULDには、認証機構だけが首尾よく認証するプロトコル仕様が必要である関連ベースが必要である操作上のモードがあります。
2.3. Clear-Text Password Requirements
2.3. クリアテキストパスワード要件
Clients and servers which implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active. Servers which allow unencrypted clear-text logins SHOULD be configurable to refuse clear-text logins both for the entire server, and on a per-user basis.
構成可能な廃物への明確なテキストのログインがコマンドかメカニズムであり、適切な強さの暗号化層が活性でないならSTARTTLS MUSTを実装する(標準化過程と標準的でないメカニズムの両方を含んでいます)クライアントとサーバ。 構成可能な廃物への明確なテキストのログインが全体のサーバと、1ユーザあたり1個のベースの上の両方であったなら非暗号化されたクリアテキストログインSHOULDを許容するサーバ。
2.4. Server Identity Check
2.4. サーバ身元確認
During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:
TLS交渉の間、クライアントはサーバCertificateメッセージに示されるようにサーバのアイデンティティに対してサーバホスト名の理解をチェックしなければなりません、介入者攻撃を防ぐために。 これらの規則に従って、マッチングは実行されます:
- The client MUST use the server hostname it used to open the
connection as the value to compare against the server name as
expressed in the server certificate. The client MUST NOT use any
form of the server hostname derived from an insecure remote source
(e.g., insecure DNS lookup). CNAME canonicalization is not done.
- クライアントはそれがサーバ証明書で言い表されるようにサーバー名に対して比較するために値として接続を開くのに使用したサーバホスト名を使用しなければなりません。 クライアントは不安定なリモートソース(例えば、不安定なDNSルックアップ)から得られたサーバホスト名のどんなフォームも使用してはいけません。 CNAME canonicalizationは完了していません。
- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
- タイプdNSNameの拡大はsubjectAltNameであるなら証明書に存在していて、それはSHOULDです。サーバのアイデンティティの源として、使用されます。
- Matching is case-insensitive.
- マッチングは大文字と小文字を区別しないです。
- A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc. but would not match
example.com.
- 「*」ワイルドカードキャラクタはコンポーネントという最も左の名として証明書で使用されるかもしれません。 *例えば、.example.comはa.example.com、foo.example.comなどを合わせるでしょうが、example.comは合っていないでしょう。
- If the certificate contains multiple names (e.g. more than one
dNSName field), then a match with any one of the fields is
considered acceptable.
- 証明書が複数の名前(例えば、1つ以上のdNSName分野)を含んでいるなら、分野のどれかとのマッチは許容できると考えられます。
If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect.
マッチが失敗するなら、クライアントSHOULDは、明白なユーザ確認を求めるか、接続を終えて、またはサーバのアイデンティティが疑わしいのを示します。
Newman Standards Track [Page 3] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[3ページ]RFC2595
2.5. TLS Security Policy Check
2.5. TLS安全保障政策チェック
Both the client and server MUST check the result of the STARTTLS command and subsequent TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.
ともに、クライアントとサーバは、許容できる認証かプライバシーが達成されたかどうかを見るためにSTARTTLSコマンドとその後のTLS交渉の結果をチェックしなければなりません。 このステップを無視すると、使用TLSはセキュリティのために完全に無効にされます。 許容できる認証かプライバシーが達成されたかどうかに関する決定は、局所的に作られていて、実装依存していて、このドキュメントの範囲を超えています。
3. IMAP STARTTLS extension
3. IMAP STARTTLS拡張子
When the TLS extension is present in IMAP, "STARTTLS" is listed as a capability in response to the CAPABILITY command. This extension adds a single command, "STARTTLS" to the IMAP protocol which is used to begin a TLS negotiation.
TLS拡張子がIMAPに存在しているとき、「STARTTLS」は能力として能力コマンドに対応して記載されます。 この拡大はTLS交渉を始めるのに使用されるIMAPプロトコルにただ一つのコマンド、「STARTTLS」を追加します。
3.1. STARTTLS Command
3.1. STARTTLSコマンド
Arguments: none
議論: なし
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - begin TLS negotiation
BAD - command unknown or arguments invalid
結果: OK--TLS交渉BADを始めてください--未知か議論病人を命令してください。
A TLS negotiation begins immediately after the CRLF at the end of
the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the TLS negotiation is complete.
TLS交渉はCRLF直後タグ付けをされたOK応答の終わりにサーバから始まります。クライアントがいったんSTARTTLSコマンドを発行すると、サーバ応答が見られて、TLS交渉が終了するまで、それはさらなるコマンドを発行してはいけません。
The STARTTLS command is only valid in non-authenticated state.
The server remains in non-authenticated state, even if client
credentials are supplied during the TLS negotiation. The SASL
[SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
client credentials are successfully exchanged, but servers
supporting the STARTTLS command are not required to support the
EXTERNAL mechanism.
STARTTLSコマンドは非認証された状態だけで有効です。 TLS交渉の間、クライアント資格証明書を供給しても、サーバは非認証された州に残っています。 いったん首尾よくTLSクライアント資格証明書を交換すると、SASL[SASL]EXTERNALメカニズムは認証するのにおいて使用されているかもしれませんが、STARTTLSがコマンドであるとサポートするサーバは、EXTERNALメカニズムをサポートするのに必要ではありません。
Once TLS has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list prior
to STARTTLS. The server MAY advertise different capabilities
after STARTTLS.
TLSがいったん始動されると、クライアントはサーバ能力のキャッシュされた情報を捨てなければなりません、そして、SHOULDはCAPABILITYコマンドを再発行します。 これが、STARTTLSの前で能力リストを変更する介入者攻撃から守るのに必要です。 サーバはSTARTTLSの後に異なった能力の広告を出すかもしれません。
The formal syntax for IMAP is amended as follows:
IMAPに、正式な構文は以下の通り改正されます:
Newman Standards Track [Page 4] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[4ページ]RFC2595
command_any =/ "STARTTLS"
_あらゆる=/「STARTTLS」を命令してください。
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under TLS layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
例: C: a001 CAPABILITY S: * 能力IMAP4rev1 STARTTLS LOGINDISABLED S: a001OK CAPABILITYはCを完成しました: a002 STARTTLS S: a002は現在、Begin TLS交渉を承認します。TLS層の>Cの下に<TLS交渉、より遠いコマンドがあります: a003 CAPABILITY S: * 能力IMAP4rev1 AUTHは外部のSと等しいです: a003OK CAPABILITYはCを完成しました: a004 LOGIN joeパスワードS: OK LOGINが完成したa004
3.2. IMAP LOGINDISABLED capability
3.2. IMAP LOGINDISABLED能力
The current IMAP protocol specification (RFC 2060) requires the implementation of the LOGIN command which uses clear-text passwords. Many sites may choose to disable this command unless encryption is active for security reasons. An IMAP server MAY advertise that the LOGIN command is disabled by including the LOGINDISABLED capability in the capability response. Such a server will respond with a tagged "NO" response to any attempt to use the LOGIN command.
現在のIMAPプロトコル仕様(RFC2060)はクリアテキストパスワードを使用するLOGINコマンドの実装を必要とします。 暗号化が安全保障上の理由で活発でない場合、多くのサイトが、このコマンドを無効にするのを選ぶかもしれません。 IMAPサーバは、LOGINコマンドが能力応答にLOGINDISABLED能力を含んでいることによって無効にされるのは広告を出すかもしれません。 そのようなサーバはログインコマンドを使用するどんな試みへのタグ付けをされた「いいえ」応答でも反応するでしょう。
An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections.
STARTTLS MUSTがLOGINDISABLED能力における、進行中の道具サポートであると実装するIMAPサーバは接続を非暗号化しました。
An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present.
この能力が存在しているなら、この仕様に従うIMAPクライアントはLOGINコマンドを発行してはいけません。
This capability is useful to prevent clients compliant with this specification from sending an unencrypted password in an environment subject to passive attacks. It has no impact on an environment subject to active attacks as a man-in-the-middle attacker can remove this capability. Therefore this does not relieve clients of the need to follow the privacy mode recommendation in section 2.2.
この能力は、この仕様で言いなりになっているクライアントが受け身の攻撃を条件として環境における非暗号化されたパスワードを送るのを防ぐために役に立ちます。 中央の男性攻撃者がこの能力を取り除くことができるようにそれは環境に活発な攻撃を条件として影響力を全く持っていません。 したがって、これはセクション2.2でプライバシーモード推薦に続く必要性をクライアントに取り除きません。
Servers advertising this capability will fail to interoperate with many existing compliant IMAP clients and will be unable to prevent those clients from disclosing the user's password.
この能力の広告を出すサーバによって、多くの存在対応することのIMAPクライアントと共に共同利用しないで、それらのクライアントはユーザのパスワードを明らかにすることができないでしょう。
4. POP3 STARTTLS extension
4. POP3 STARTTLS拡張子
The POP3 STARTTLS extension adds the STLS command to POP3 servers. If this is implemented, the POP3 extension mechanism [POP3EXT] MUST also be implemented to avoid the need for client probing of multiple commands. The capability name "STLS" indicates this command is present and permitted in the current state.
POP3 STARTTLS拡張子はSTLSコマンドをPOP3サーバに追加します。 また、これが実装されるなら、複数のコマンドのクライアントの調べの必要性を避けるために、POP3拡張機能[POP3EXT]を実装しなければなりません。 「STLS」という能力名は、このコマンドが現在であって現状のときに受入れられるのを示します。
Newman Standards Track [Page 5] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[5ページ]RFC2595
STLS
STLS
Arguments: none
議論: なし
Restrictions:
Only permitted in AUTHORIZATION state.
制限: AUTHORIZATION状態で受入れられるだけです。
Discussion:
A TLS negotiation begins immediately after the CRLF at the
end of the +OK response from the server. A -ERR response
MAY result if a security layer is already active. Once a
client issues a STLS command, it MUST NOT issue further
commands until a server response is seen and the TLS
negotiation is complete.
議論: TLS交渉はCRLF直後+OK応答の終わりにサーバから始まります。セキュリティ層が既に活性であるなら、-ERR応答は結果として生じるかもしれません。 クライアントがいったんSTLSコマンドを発行すると、サーバ応答が見られて、TLS交渉が終了するまで、それはさらなるコマンドを発行してはいけません。
The STLS command is only permitted in AUTHORIZATION state
and the server remains in AUTHORIZATION state, even if
client credentials are supplied during the TLS negotiation.
The AUTH command [POP-AUTH] with the EXTERNAL mechanism
[SASL] MAY be used to authenticate once TLS client
credentials are successfully exchanged, but servers
supporting the STLS command are not required to support the
EXTERNAL mechanism.
STLSコマンドはAUTHORIZATION状態で受入れられるだけです、そして、サーバはAUTHORIZATION州に残っています、TLS交渉の間、クライアント資格証明書を供給しても。 いったん首尾よくTLSクライアント資格証明書を交換すると、EXTERNALメカニズム[SASL]によるAUTHコマンド[POP-AUTH]は認証するのにおいて使用されているかもしれませんが、STLSがコマンドであるとサポートするサーバは、EXTERNALメカニズムをサポートするのに必要ではありません。
Once TLS has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue
the CAPA command. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list
prior to STLS. The server MAY advertise different
capabilities after STLS.
TLSがいったん始動されると、クライアントはサーバ能力のキャッシュされた情報を捨てなければなりません、そして、SHOULDはキャパコマンドを再発行します。 これが、STLSの前で能力リストを変更する介入者攻撃から守るのに必要です。 サーバはSTLSの後に異なった能力の広告を出すかもしれません。
Possible Responses:
+OK -ERR
可能な応答: +OKは間違えます。
Examples:
C: STLS
S: +OK Begin TLS negotiation
<TLS negotiation, further commands are under TLS layer>
...
C: STLS
S: -ERR Command not permitted when TLS active
例: C: STLS S: +はBegin TLS交渉<TLS交渉を承認して、TLS層の>の下にさらなるコマンドがあります… C: STLS S: -TLSアクティブであるときに受入れられなかったERR Command
Newman Standards Track [Page 6] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[6ページ]RFC2595
5. ACAP STARTTLS extension
5. ACAP STARTTLS拡張子
When the TLS extension is present in ACAP, "STARTTLS" is listed as a capability in the ACAP greeting. No arguments to this capability are defined at this time. This extension adds a single command, "STARTTLS" to the ACAP protocol which is used to begin a TLS negotiation.
TLS拡張子がACAPに存在しているとき、「STARTTLS」はACAP挨拶における能力として記載されます。 この能力への議論は全くこのとき、定義されません。 この拡大はTLS交渉を始めるのに使用されるACAPプロトコルにただ一つのコマンド、「STARTTLS」を追加します。
5.1. STARTTLS Command
5.1. STARTTLSコマンド
Arguments: none
議論: なし
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - begin TLS negotiation
BAD - command unknown or arguments invalid
結果: OK--TLS交渉BADを始めてください--未知か議論病人を命令してください。
A TLS negotiation begins immediately after the CRLF at the end of
the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the TLS negotiation is complete.
TLS交渉はCRLF直後タグ付けをされたOK応答の終わりにサーバから始まります。クライアントがいったんSTARTTLSコマンドを発行すると、サーバ応答が見られて、TLS交渉が終了するまで、それはさらなるコマンドを発行してはいけません。
The STARTTLS command is only valid in non-authenticated state.
The server remains in non-authenticated state, even if client
credentials are supplied during the TLS negotiation. The SASL
[SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
client credentials are successfully exchanged, but servers
supporting the STARTTLS command are not required to support the
EXTERNAL mechanism.
STARTTLSコマンドは非認証された状態だけで有効です。 TLS交渉の間、クライアント資格証明書を供給しても、サーバは非認証された州に残っています。 いったん首尾よくTLSクライアント資格証明書を交換すると、SASL[SASL]EXTERNALメカニズムは認証するのにおいて使用されているかもしれませんが、STARTTLSがコマンドであるとサポートするサーバは、EXTERNALメカニズムをサポートするのに必要ではありません。
After the TLS layer is established, the server MUST re-issue an
untagged ACAP greeting. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list prior
to STARTTLS. The client MUST discard cached capability
information and replace it with the information from the new ACAP
greeting. The server MAY advertise different capabilities after
STARTTLS.
TLS層が確立された後に、サーバはuntagged ACAP挨拶を再発行しなければなりません。 これが、STARTTLSの前で能力リストを変更する介入者攻撃から守るのに必要です。 クライアントは、新しいACAP挨拶からキャッシュされた能力情報を捨てて、それを情報に取り替えなければなりません。 サーバはSTARTTLSの後に異なった能力の広告を出すかもしれません。
The formal syntax for ACAP is amended as follows:
ACAPに、正式な構文は以下の通り改正されます:
command_any =/ "STARTTLS"
_あらゆる=/「STARTTLS」を命令してください。
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
例: S: * ACAP、(SASL、「一夜漬け-MD5") (STARTTLS)C:、」 a002 STARTTLS S: TLS層の>Sの下にa002OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります: * ACAP(SASL、「一夜漬け-MD5"の「明瞭である」「外部」)」
Newman Standards Track [Page 7] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[7ページ]RFC2595
6. PLAIN SASL mechanism
6. PLAIN SASLメカニズム
Clear-text passwords are simple, interoperate with almost all existing operating system authentication databases, and are useful for a smooth transition to a more secure password-based authentication mechanism. The drawback is that they are unacceptable for use over an unencrypted network connection.
クリアテキストパスワードは、簡単であり、ほとんどすべての既存のオペレーティングシステム認証データベースで共同利用して、より安全なパスワードベースの認証機構へのスムーズな移行の役に立ちます。 欠点は非暗号化されたネットワーク接続の上の使用に、それらが容認できないということです。
This defines the "PLAIN" SASL mechanism for use with ACAP and other protocols with no clear-text login command. The PLAIN SASL mechanism MUST NOT be advertised or used unless a strong encryption layer (such as the provided by TLS) is active or backwards compatibility dictates otherwise.
これはACAPとの使用のために「明瞭な」SASLメカニズムを定義します、そして、他のプロトコルはクリアテキストログインなしで命令します。 PLAIN SASLメカニズムの広告を出してはいけない、強い暗号化層(TLSによる提供などの)が後方に活性でないなら使用されて、さもなければ、互換性は別の方法で命令します。
The mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity.
メカニズムはただ一つのクライアントからサーバまでのメッセージから成ります。クライアントが承認のアイデンティティを送る、(ログインするアイデンティティ、)、米国-ASCII NULキャラクタによって後をつけられて、米国-ASCII NULキャラクタによって後をつけられたアイデンティティ(パスワードが使用されるアイデンティティ)がクリアテキストパスワードを続けた認証で続きました。 クライアントは承認のアイデンティティをそれが認証のアイデンティティと同じであることを示すために空の状態でおくかもしれません。
The server will verify the authentication identity and password with the system authentication database and verify that the authentication credentials permit the client to login as the authorization identity. If both steps succeed, the user is logged in.
サーバは、システム認証データベースがある認証のアイデンティティとパスワードについて確かめて、認証資格証明書が、クライアントが承認のアイデンティティとしてログインすることを許可することを確かめるでしょう。 両方のステップが成功するなら、ユーザはログインされます。
The server MAY also use the password to initialize any new authentication database, such as one suitable for CRAM-MD5 [CRAM-MD5].
また、サーバは、CRAM-MD5[CRAM-MD5]に適当な1つなどのどんな新しい認証データベースも初期化するのにパスワードを使用するかもしれません。
Non-US-ASCII characters are permitted as long as they are represented in UTF-8 [UTF-8]. Use of non-visible characters or characters which a user may be unable to enter on some keyboards is discouraged.
彼らがUTF-8[UTF-8]に表される限り、非米国のASCII文字は受入れられます。 非目に見えるキャラクタかユーザがいくつかのキーボードに入れることができないかもしれないキャラクタの使用はお勧めできないです。
The formal grammar for the client message using Augmented BNF [ABNF] follows.
Augmented BNF[ABNF]を使用するクライアントメッセージのための形式文法は従います。
message = [authorize-id] NUL authenticate-id NUL password
authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
password = 1*UTF8-SAFE ; MUST accept up to 255 octets
NUL = %x00
UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
メッセージはイドを認証しているイドを認証している[イドを認可している]NUL NULパスワード=1*UTF8-SAFEと等しいです。 イドを認可している=1*UTF8-SAFEは、255の八重奏に上がると受け入れなければなりません。 最大255八重奏パスワード=1*UTF8-SAFEは受け入れなければなりません。 最大255八重奏NUL=%x00 UTF8-SAFE=%x01-09/%x0E-7x0B-0C/%F/UTF8-2/UTF8-3/UTF8-4/UTF8-5/UTF8-6 UTF8-1=%x80-BF UTF8-2=%xC0-DF UTF8-1 UTF8-3=%xE0-EF 2UTF8-1は受け入れなければなりません。
Newman Standards Track [Page 8] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[8ページ]RFC2595
UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1
UTF8-4=%xF0-F7 3UTF8-1 UTF8-5=%xF8-FB 4UTF8-1 UTF8-6=%xFC-FD 5UTF8-1
Here is an example of how this might be used to initialize a CRAM-MD5 authentication database for ACAP:
ここに、これがACAPのためのCRAM-MD5認証データベースを初期化するのにどう使用されるかもしれないかに関する例があります:
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 AUTHENTICATE "CRAM-MD5"
S: + "<1896.697170952@postoffice.reston.mci.net>"
C: "tim b913a602c7eda7a495b4e6e7334d3890"
S: a001 NO (TRANSITION-NEEDED)
"Please change your password, or use TLS to login"
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
C: a003 AUTHENTICATE "PLAIN" {21+}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a003 OK CRAM-MD5 password initialized
例: S: * ACAP、(SASL、「一夜漬け-MD5") (STARTTLS)C:、」 a001 AUTHENTICATE、「一夜漬け-MD5"S:」 「+ "<1896.697170952@postoffice.reston.mci.net 、gt;、」 C: "tim b913a602c7eda7a495b4e6e7334d3890"S: 「パスワードを変えるか、またはログインするのにTLSを使用してください」a001ノー(TRANSITIONによって必要な)C: a002 STARTTLS S: TLS層の>Sの下にa002OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります: * ACAP、(SASL、「一夜漬け-MD5"の「明瞭である」「外部」) C:、」 a003 AUTHENTICATE「平野」21+、C: <NUL>tim<NUL>tanstaaftanstaaf S: OK CRAM-MD5パスワードが初期化したa003
Note: In this example, <NUL> represents a single ASCII NUL octet.
以下に注意してください。 この例では、<NUL>はただ一つのASCII NUL八重奏を表します。
7. imaps and pop3s ports
7. imapsとpop3sポート
Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands.
別々の"imaps"と"pop3s"ポートは使用のためにSSLに登録されました。 これらのポートの使用はSTARTTLSかSTLSコマンドを支持してお勧めできないです。
A number of problems have been observed with separate ports for "secure" variants of protocols. This is an attempt to enumerate some of those problems.
多くの問題がプロトコルの「安全な」異形のために別々のポートで観測されました。 これはそれらの問題のいくつかを列挙する試みです。
- Separate ports lead to a separate URL scheme which intrudes into
the user interface in inappropriate ways. For example, many web
pages use language like "click here if your browser supports SSL."
This is a decision the browser is often more capable of making than
the user.
- 別々のポートは不適当な方法でユーザーインタフェースに押し入る別々のURL体系に通じます。 例えば、多くのウェブページが「ここのクリックはあなたのブラウザであるならSSLをサポートします」のように言語を使用します。 これはブラウザがユーザよりしばしばすることができる決定です。
- Separate ports imply a model of either "secure" or "not secure."
This can be misleading in a number of ways. First, the "secure"
port may not in fact be acceptably secure as an export-crippled
cipher suite might be in use. This can mislead users into a false
sense of security. Second, the normal port might in fact be
secured by using a SASL mechanism which includes a security layer.
Thus the separate port distinction makes the complex topic of
security policy even more confusing. One common result of this
confusion is that firewall administrators are often misled into
- 別々のポートは「安全である」か「安全でなく」どちらかのモデルを含意します。 これは多くの方法で紛らわしい場合があります。 まず最初に、輸出で不具な暗号スイートが使用中であるかもしれないように事実上、「安全な」ポートは許容できて安全でないかもしれません。 これは大丈夫だという誤った感覚にユーザをミスリードすることができます。 2番目に、事実上、正常なポートは、セキュリティ層を含んでいるSASLメカニズムを使用することによって、固定されるかもしれません。 したがって、別々のポート区別で、安全保障政策の複雑な話題はさらに紛らわしくなります。 ファイアウォール管理者がしばしばミスリードされるこの混乱の1つの一般的な結果があります。
Newman Standards Track [Page 9] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[9ページ]RFC2595
permitting the "secure" port and blocking the standard port. This
could be a poor choice given the common use of SSL with a 40-bit
key encryption layer and plain-text password authentication is less
secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
「安全な」ポートを可能にして、標準のポートを妨げます。 40ビットの主要な暗号化層によるSSLの一般の使用を考えて、これが不十分な選択であるかもしれなく、プレーンテキストパスワード認証はケルベロス5があるGSSAPIなどの強いSASLメカニズムほど安全ではありません。
- Use of separate ports for SSL has caused clients to implement only
two security policies: use SSL or don't use SSL. The desirable
security policy "use TLS when available" would be cumbersome with
the separate port model, but is simple with STARTTLS.
- 別々のポートのSSLの使用で、クライアントは2つの安全保障政策だけを実装しました: SSLを使用するか、またはSSLを使用しないでください。 望ましい安全保障政策が「利用可能であるときに、TLSを使用する」、別々のポートモデルと共に厄介でしょうが、STARTTLSでは、簡単です。
- Port numbers are a limited resource. While they are not yet in
short supply, it is unwise to set a precedent that could double (or
worse) the speed of their consumption.
- ポートナンバーは限られたリソースです。 まだ不足していませんが、彼らの消費の速度を倍にすることができた(よりひどい)先例を設定するのは賢明ではありません。
8. IANA Considerations
8. IANA問題
This constitutes registration of the "STARTTLS" and "LOGINDISABLED" IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
.1セクション7.2RFC2060[IMAP]でこれは必要に応じて「STARTTLS」と"LOGINDISABLED"IMAP能力の登録を構成します。
The registration for the POP3 "STLS" capability follows:
POP3「STLS」能力のための登録は続きます:
CAPA tag: STLS
Arguments: none
Added commands: STLS
Standard commands affected: May enable USER/PASS as a side-effect.
CAPA command SHOULD be re-issued after successful completion.
Announced states/Valid states: AUTHORIZATION state only.
Specification reference: this memo
キャパタグ: STLS議論: Addedのいずれも命令しません: STLS Standardコマンドは影響しました: 副作用としてUSER/PASSを有効にするかもしれません。 キャパは、SHOULDが無事終了の後に再発行されると命令します。 州/有効な州は発表しました: AUTHORIZATION状態専用。 仕様参照: このメモ
The registration for the ACAP "STARTTLS" capability follows:
ACAP「STARTTLS」能力のための登録は続きます:
Capability name: STARTTLS
Capability keyword: STARTTLS
Capability arguments: none
Published Specification(s): this memo
Person and email address for further information:
see author's address section below
能力名: STARTTLS Capabilityキーワード: STARTTLS Capability議論: Published Specification(s)のいずれも:でない このメモPersonと詳細のためのEメールアドレス: 下の作者のアドレス部を見てください。
The registration for the PLAIN SASL mechanism follows:
PLAIN SASLメカニズムのための登録は続きます:
SASL mechanism name: PLAIN
Security Considerations: See section 9 of this memo
Published specification: this memo
Person & email address to contact for further information:
see author's address section below
Intended usage: COMMON
Author/Change controller: see author's address section below
SASLメカニズム名: 明瞭なセキュリティ問題: このメモPublished仕様のセクション9を見てください: 詳細のために連絡するこのメモPersonとEメールアドレス: Intended用法の下で作者のアドレス部を見てください: COMMON Author/変化コントローラ: 下の作者のアドレス部を見てください。
Newman Standards Track [Page 10] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[10ページ]RFC2595
9. Security Considerations
9. セキュリティ問題
TLS only provides protection for data sent over a network connection. Messages transferred over IMAP or POP3 are still available to server administrators and usually subject to eavesdropping, tampering and forgery when transmitted through SMTP or NNTP. TLS is no substitute for an end-to-end message security mechanism using MIME security multiparts [MIME-SEC].
TLSはネットワーク接続の上に送られたデータのための保護を提供するだけです。 SMTPかNNTPを通して伝えられると、IMAPかPOP3の上に移されたメッセージはまだサーバアドミニストレータ、通常盗聴、改ざん、および偽造およびを条件として利用可能です。 TLSは終わりから終わりへのメッセージMIMEセキュリティの「マルチ-部品」[MIME SEC]を使用するセキュリティー対策の代用品ではありません。
A man-in-the-middle attacker can remove STARTTLS from the capability list or generate a failure response to the STARTTLS command. In order to detect such an attack, clients SHOULD warn the user when session privacy is not active and/or be configurable to refuse to proceed without an acceptable level of security.
中央の男性攻撃者は、ケイパビリティ・リストからSTARTTLSを取り外すか、またはSTARTTLSコマンドへの失敗応答を生成することができます。 そのような攻撃を検出するには、クライアントSHOULDは、セッションプライバシーがいつアクティブでないかをユーザに警告します、そして、合格水準のセキュリティなしで続くのを拒否するのにおいて、構成可能であってください。
A man-in-the-middle attacker can always cause a down-negotiation to the weakest authentication mechanism or cipher suite available. For this reason, implementations SHOULD be configurable to refuse weak mechanisms or cipher suites.
中央の男性攻撃者はいつも利用可能な最も弱い認証機構か暗号スイートに下がっている交渉を引き起こす場合があります。 この理由で、実装SHOULDは弱いメカニズムを拒否するのにおいて構成可能であるか、またはスイートを解きます。
Any protocol interactions prior to the TLS handshake are performed in the clear and can be modified by a man-in-the-middle attacker. For this reason, clients MUST discard cached information about server capabilities advertised prior to the start of the TLS handshake.
TLS握手の前のどんなプロトコル相互作用も明確で実行して、中央の男性攻撃者は変更できます。 この理由で、クライアントはTLS握手の始まりの前に広告に掲載されたサーバ能力のキャッシュされた情報を捨てなければなりません。
Clients are encouraged to clearly indicate when the level of encryption active is known to be vulnerable to attack using modern hardware (such as encryption keys with 56 bits of entropy or less).
クライアントが、いつ暗号化アクティブのレベルが近代的なハードウェア(エントロピーか以下の56ビットがある暗号化キーなどの)を使用することで攻撃するために被害を受け易いのが知られているかを明確に示すよう奨励されます。
The LOGINDISABLED IMAP capability (discussed in section 3.2) only reduces the potential for passive attacks, it provides no protection against active attacks. The responsibility remains with the client to avoid sending a password over a vulnerable channel.
LOGINDISABLED IMAP能力(セクション3.2で、議論する)は受け身の攻撃の可能性を減少させるだけです、とそれが活発な攻撃に対してノー・プロテクションを前提とします。 責任は、被害を受け易いチャンネルの上にパスワードを送るのを避けるためにクライアントと共に残っています。
The PLAIN mechanism relies on the TLS encryption layer for security. When used without TLS, it is vulnerable to a common network eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used unless a suitable TLS encryption layer is active or backwards compatibility dictates otherwise.
PLAINメカニズムはセキュリティのためにTLS暗号化層を当てにします。 TLSなしで使用されると、それは一般的なネットワーク盗聴攻撃に被害を受け易いです。 したがって、そうでなければ、適当なTLS暗号化が層にされないなら、広告を出すか、または使用するPLAIN MUST NOTはアクティブであるか遅れている互換性命令です。
When the PLAIN mechanism is used, the server gains the ability to impersonate the user to all services with the same password regardless of any encryption provided by TLS or other network privacy mechanisms. While many other authentication mechanisms have similar weaknesses, stronger SASL mechanisms such as Kerberos address this issue. Clients are encouraged to have an operational mode where all mechanisms which are likely to reveal the user's password to the server are disabled.
PLAINメカニズムが使用されているとき、サーバはTLSによって提供されたどんな暗号化か他のネットワークプライバシーメカニズムにかかわらず同じパスワードですべてのサービスにユーザをまねる能力を獲得します。他の多くの認証機構には同様の弱点がある間、ケルベロスなどの、より強いSASLメカニズムはこの問題を扱います。 クライアントにはユーザのパスワードをサーバに明らかにしそうなすべてのメカニズムが障害がある操作上のモードがあるよう奨励されます。
Newman Standards Track [Page 11] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[11ページ]RFC2595
The security considerations for TLS apply to STARTTLS and the security considerations for SASL apply to the PLAIN mechanism. Additional security requirements are discussed in section 2.
TLSのためのセキュリティ問題はSTARTTLSに適用されます、そして、SASLのためのセキュリティ問題はPLAINメカニズムに適用されます。 セクション2で追加担保要件について議論します。
10. References
10. 参照
[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。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[AUTH] Haller, N. and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[AUTH] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[一夜漬け-MD5] KlensinとJ.とCatoeとR.とP.Krumviede、「/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[MIME秒] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[POP3] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998.
[POP3EXT] GellensとR.とニューマンとC.とL.Lundblade、「POP3拡張機能」、RFC2449、1998年11月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[POP-AUTH] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
TLS", RFC 2487, January 1999.
[SMTPTLS]ホフマン、P.、「TLSの上の安全なSMTPのためのSMTPサービス拡張子」、RFC2487、1999年1月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
Newman Standards Track [Page 12] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[12ページ]RFC2595
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[UTF-8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
11. Author's Address
11. 作者のアドレス
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
A. Appendix -- Compliance Checklist
A。 付録--承諾チェックリスト
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant".
1つか以上を満たさないなら実装が対応でない、それが実装するプロトコルのための要件はそうしなければなりません。 そして、すべてを満たす実装、プロトコルのためのすべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、プロトコルのためのすべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。
Rules Section
----- -------
Mandatory-to-implement Cipher Suite 2.1
SHOULD have mode where encryption required 2.2
server SHOULD have mode where TLS not required 2.2
MUST be configurable to refuse all clear-text login
commands or mechanisms 2.3
server SHOULD be configurable to refuse clear-text
login commands on entire server and on per-user basis 2.3
client MUST check server identity 2.4
client MUST use hostname used to open connection 2.4
client MUST NOT use hostname from insecure remote lookup 2.4
client SHOULD support subjectAltName of dNSName type 2.4
client SHOULD ask for confirmation or terminate on fail 2.4
MUST check result of STARTTLS for acceptable privacy 2.5
client MUST NOT issue commands after STARTTLS
until server response and negotiation done 3.1,4,5.1
client MUST discard cached information 3.1,4,5.1,9
client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2
IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2
POP server MUST implement POP3 extensions 4
ACAP server MUST re-issue ACAP greeting 5.1
セクションを統治します。----- ------- 実装するために義務的なCipher Suite2.1SHOULDは暗号化が2.2サーバSHOULDを必要としたモードに2.2に必要でないTLSがログインコマンドかメカニズム2をすべてのクリアテキストに拒否するのにおいて構成可能であるに違いないモードを持たせます; 3サーバSHOULD、全体のサーバの上と、そして、2.3クライアントがチェックしなければならない1ユーザあたりのベースにおける構成可能な廃物への明確なテキストのログインコマンドが2.4クライアントが使用しなければならないサーバのアイデンティティであったなら、接続2.4クライアントを開くのに使用されるホスト名はdNSNameタイプ2の不安定なリモートルックアップ2.4クライアントSHOULDサポートsubjectAltNameからホスト名を使用してはいけません; 4 LOGINDISABLED3.2POPサーバが、POP3拡張子が4ACAPサーバであると実装しなければならないならサーバ応答と3.1、4、5.1クライアントに行われた交渉が捨てられなければならないまでSTARTTLSがSTARTTLS MUST道具LOGINDISABLED3.2IMAPクライアントとのCAPABILITY/キャパコマンド3.1、4IMAPサーバがLOGINを発行してはいけない情報3.1、4、5.1、9クライアントSHOULD再発行をキャッシュした後にSHOULDが確認のために尋ねるか、またはやり損な2.4いで終えるクライアントは2.5クライアントがコマンドを発行してはいけない許容できるプライバシーがないかどうかSTARTTLSの結果をチェックしなければなりません。再発行ACAPが5.1を迎えて、そうしなければなりません。
Newman Standards Track [Page 13] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[13ページ]RFC2595
client SHOULD warn when session privacy not active and/or
refuse to proceed without acceptable security level 9
SHOULD be configurable to refuse weak mechanisms or
cipher suites 9
クライアントSHOULDは、許容できるセキュリティー・レベル9SHOULDなしで続くように、能動態、そして/または、廃物ではなく、セッションプライバシーであるときには弱いメカニズムか暗号スイート9を拒否するのにおいて構成可能であるように警告します。
The PLAIN mechanism is an optional part of this specification. However if it is implemented the following rules apply:
PLAINメカニズムはこの仕様の任意の部分です。 しかしながら、それが以下であると実装されるなら、規則は適用されます:
Rules Section
----- -------
MUST NOT use PLAIN unless strong encryption active
or backwards compatibility dictates otherwise 6,9
MUST use UTF-8 encoding for characters in PLAIN 6
セクションを統治します。----- ------- 強い暗号化アクティブであるか遅れている互換性命令そうでなければ、6、9がPLAIN6でキャラクタのためのUTF-8コード化を使用してはいけないなら、NOTはPLAINを使用しなければなりませんか?
Newman Standards Track [Page 14] RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999
1999年6月にIMAP、POP3、およびACAPとTLSを使用するニューマン標準化過程[14ページ]RFC2595
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Newman Standards Track [Page 15]
ニューマン標準化過程[15ページ]
一覧
スポンサーリンク
