Network Working Group K. Murchison
Request for Comments: 4642 Carnegie Mellon University
Category: Standards Track J. Vinocur
Cornell University
C. Newman
Sun Microsystems
October 2006
Using Transport Layer Security (TLS)
with Network News Transfer Protocol (NNTP)
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible.
このメモは、トランスポート層セキュリティ（TLS）を使用するNNTPクライアントとサーバーを可能にするネットワークニュース転送プロトコル（NNTP）への拡張を定義します。主な目的は、シングルリンクの機密性のために暗号化を提供することですが、データの整合性、（オプション）証明書ベースのピア・エンティティ認証、および（オプション）データ圧縮も可能です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. The STARTTLS Extension ..........................................3
2.1. Advertising the STARTTLS Extension .........................3
2.2. STARTTLS Command ...........................................4
2.2.1. Usage ...............................................4
2.2.2. Description .........................................4
2.2.3. Examples ............................................6
3. Augmented BNF Syntax for the STARTTLS Extension .................8
3.1. Commands ...................................................8
3.2. Capability entries .........................................8
4. Summary of Response Codes .......................................8
5. Security Considerations .........................................8
6. IANA Considerations ............................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
8. Acknowledgements ...............................................12
Historically, unencrypted NNTP [NNTP] connections were satisfactory for most purposes. However, sending passwords unencrypted over the network is no longer appropriate, and sometimes integrity and/or confidentiality protection are desired for the entire connection.
歴史的に、暗号化されていないNNTP [NNTP]接続は、ほとんどの目的のために良好でした。しかし、ネットワーク上で暗号化されていないパスワードを送信することはもはや適切ではない、時には完全性および/または機密保護は全体の接続のために望まれています。
The TLS protocol (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. Although advanced SASL authentication mechanisms [NNTP-AUTH] can provide a lightweight version of this service, TLS is complimentary to both simple authentication-only SASL mechanisms and deployed clear-text password login commands.
（以前のSSLとして知られている）TLSプロトコルが改ざんや盗聴からアプリケーションプロトコルを確保する方法を提供します。高度なSASL認証メカニズム[NNTP-AUTH]は、このサービスの軽量バージョンを提供することができるが、TLSは簡単な認証のみのSASLメカニズムと展開平文パスワードログインコマンドの両方に無料でご利用いただけます。
In some existing implementations, TCP port 563 has been dedicated to NNTP over TLS. These implementations begin the TLS negotiation immediately upon connection and then continue with the initial steps of an NNTP session. This use of TLS on a separate port is discouraged for the reasons documented in Section 7 of "Using TLS with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
いくつかの既存の実装では、TCPポート563は、TLS上でNNTPに専念してきました。これらの実装は、接続直後にTLSネゴシエーションを開始し、その後、NNTPセッションの最初のステップに進みます。別々のポート上のTLSのこの使用は、[TLS-IMAPPOP「IMAP、POP3、およびACAPとTLSの使用方法」のセクション7に記載の理由のために推奨されます。
This specification formalizes the STARTTLS command already in occasional use by the installed base. The STARTTLS command rectifies a number of the problems with using a separate port for a "secure" protocol variant; it is the preferred way of using TLS with NNTP.
この仕様は、インストールベースで時折すでに使用されてSTARTTLSコマンドを形式化。 STARTTLSコマンドは、「安全な」プロトコルバリアントに対して別々のポートを使用すると多くの問題を整流します。それは、NNTPでTLSを使用する好ましい方法です。
The notational conventions used in this document are the same as those in [NNTP], and any term not defined in this document has the same meaning as in that one.
本書で使用される表記規則は、[NNTP]と同様であるが、この文書で定義されていない任意の用語は、1つの場合と同じ意味を有します。
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].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」RFCsにおける使用のためのキーワード」で説明したように、このドキュメントの「MAY」、および「OPTIONAL」は解釈されるべきです要件レベル」[KEYWORDS]を示すために。
In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S].
実施例では、クライアントからのコマンドは、[C]で示され、そしてサーバからの応答は、[S]で示されています。
This extension provides a new STARTTLS command and has the capability label STARTTLS.
この拡張は、新しいSTARTTLSコマンドを提供し、機能ラベルSTARTTLSを持っています。
A server supporting the STARTTLS command as defined in this document will advertise the "STARTTLS" capability label in response to the CAPABILITIES command ([NNTP] Section 5.2). However, this capability MUST NOT be advertised once a TLS layer is active (see Section 2.2.2) or after successful authentication [NNTP-AUTH]. This capability MAY be advertised both before and after any use of the MODE READER command ([NNTP] Section 5.3), with the same semantics.
この文書で定義されるようにSTARTTLSコマンドをサポートするサーバは、capabilitiesコマンド（[NNTP]セクション5.2）に応じて、「STARTTLS」機能ラベルをアドバタイズします。ただし、この機能は、TLS層がアクティブ（2.2.2項を参照）または[NNTP-AUTH]認証が成功した後で一度広告を出してはなりません。この機能は、同じ意味で、MODEのREADERコマンド（[NNTP]セクション5.3）のいずれかの使用前と後の両方公示されるかもしれません。
As the STARTTLS command is related to security, cached results of CAPABILITIES from a previous session MUST NOT be relied on, as per Section 12.6 of [NNTP].
STARTTLSコマンドは、セキュリティに関連していると、前のセッションからの能力をキャッシュされた結果は、[NNTP]のセクション12.6に従って、当てにしてはなりません。
Example:
例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] IHAVE [S] STARTTLS [S] LIST ACTIVE NEWSGROUPS [S] .
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] IHAVE [S] STARTTLS [S] LIST ACTIVE NEWSGROUPS [S]。
This command MUST NOT be pipelined.
このコマンドは、パイプライン化されてはなりません。
Syntax STARTTLS
構文STARTTLS
Responses
反応
382 Continue with TLS negotiation 502 Command unavailable [1] 580 Can not initiate TLS negotiation
382は使用できないTLS交渉502コマンドを続行します[1] 580は、TLS交渉を開始することはできません
[1] If a TLS layer is already active, or if authentication has occurred, STARTTLS is not a valid command (see Section 2.2.2).
TLS層がすでにアクティブになっている、または認証が発生した場合、STARTTLSは有効なコマンドでない場合は、[1]（2.2.2項を参照してください）。
NOTE: Notwithstanding Section 3.2.1 of [NNTP], the server MUST NOT return either 480 or 483 in response to STARTTLS.
注：[NNTP]の3.2.1項にかかわらず、サーバがSTARTTLSに応じて480または483のいずれかを返してはなりません。
A client issues the STARTTLS command to request negotiation of TLS. The STARTTLS command is usually used to initiate session security, although it can also be used for client and/or server certificate authentication and/or data compression.
クライアントは、STARTTLSは、TLSのネゴシエーションを要求するコマンドを発行します。それはまた、クライアントおよび/またはサーバ証明書の認証および/またはデータ圧縮のために使用することができるが、STARTTLSコマンドは通常、セッションセキュリティを開始するために使用されます。
An NNTP server returns the 483 response to indicate that a secure or encrypted connection is required for the command sent by the client. Use of the STARTTLS command as described below is one way to establish a connection with these properties. The client MAY therefore use the STARTTLS command after receiving a 483 response.
NNTPサーバは、セキュアまたは暗号化された接続がクライアントによって送信されたコマンドのために必要であることを示すために483応答を返します。後述のようにSTARTTLSコマンドを使用すると、これらの性質との接続を確立する一つの方法です。クライアントは、したがって、483応答を受信した後、STARTTLSコマンドを使用するかもしれません。
If a server advertises the STARTTLS capability, a client MAY attempt to use the STARTTLS command at any time during a session to negotiate TLS without having received a 483 response. Servers SHOULD accept such unsolicited TLS negotiation requests.
サーバがSTARTTLS機能をアドバタイズした場合、クライアントは483応答を受信したことなく、TLSを交渉するために、セッション中にいつでもSTARTTLSコマンドを使用しようとするかもしれません。サーバーは、このような迷惑TLSネゴシエーション要求を受け入れる必要があります。
If the server is unable to initiate the TLS negotiation for any reason (e.g., a server configuration or resource problem), the server MUST reject the STARTTLS command with a 580 response. Then, it SHOULD either reject subsequent restricted NNTP commands from the client with a 483 response code (possibly with a text string such as "Command refused due to lack of security") or reject a subsequent restricted command with a 400 response code (possibly with a text string such as "Connection closing due to lack of security") and close the connection. Otherwise, the server issues a 382 response, and TLS negotiation begins. A server MUST NOT under any circumstances reply to a STARTTLS command with either a 480 or 483 response.
サーバが何らかの理由（例えば、サーバ構成またはリソースの問題）のためにTLSネゴシエーションを開始することができない場合、サーバは580応答でSTARTTLSコマンドを拒絶しなければなりません。次に、それはSHOULDのどちらか（おそらく「コマンドにより、セキュリティの欠如に拒否した」などのテキスト文字列で）483応答コードとクライアントからの後続の制限されたNNTPコマンドを拒否したりして、おそらく（400応答コードとそれに続く制限されたコマンドを拒否そのような）「セキュリティの欠如に起因する閉じた接続」などのテキスト文字列、接続を閉じます。そうでなければ、サーバは382応答を発行し、TLSネゴシエーションが開始されます。サーバは、どのような状況下でのいずれかで480または483応答でSTARTTLSコマンドに応答してはいけません。
If the client receives a failure response to STARTTLS, the client must decide whether or not to continue the NNTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session in case the server allows it to do so even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a failure response needs to decide whether to continue without TLS encryption, to wait and try again later, or to give up and notify the user of the error.
クライアントがSTARTTLSに失敗応答を受信した場合、クライアントは、NNTPセッションを継続するかどうかを決定する必要があります。このような決定は、ローカルポリシーに基づいています。 TLSは、クライアント認証に使用されていた場合たとえば、クライアントは、サーバが、それがなくても、認証にそうすることを可能にする場合にはセッションを継続しようとするかもしれません。 TLS暗号化のために交渉されていた場合は、失敗応答を取得するクライアントが待機した後に再度お試し、またはあきらめてエラーをユーザに通知するために、TLS暗号化せずに続行するかどうかを決定する必要があります。
Upon receiving a 382 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other NNTP commands. The TLS negotiation begins for both the client and server with the first octet following the CRLF of the 382 response. If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD immediately close the connection.
STARTTLSコマンドへの382応答を受信すると、クライアントは他のNNTPコマンドを与える前にTLSネゴシエーションを開始する必要があります。 TLSネゴシエーションは382応答のCRLF下記の最初のオクテットで、クライアントとサーバの両方のために開始されます。 STARTTLSコマンドを発行した後、クライアントはいくつかの障害が実際にTLSハンドシェイクを開始することを防止することを見つけた場合、それはすぐに接続を閉じる必要があります。
Servers MUST be able to understand backwards-compatible TLS Client Hello messages (provided that client_version is TLS 1.0 or later), and clients MAY use backwards-compatible Client Hello messages. Neither clients nor servers are required to actually support Client Hello messages for anything other than TLS 1.0. However, the TLS extension for Server Name Indication ("server_name") [TLS-EXT] SHOULD be implemented by all clients; it also SHOULD be implemented by any server implementing STARTTLS that is known by multiple names. (Otherwise, it is not possible for a server with several hostnames to present the correct certificate to the client.)
サーバは（クライアント_が後でTLS 1.0以上であることを提供する）下位互換性TLSクライアントHelloメッセージを理解できなければならない、そしてクライアントは、後方互換性クライアントのHelloメッセージを使用するかもしれません。クライアントもサーバが実際にTLS 1.0以外のクライアントHelloメッセージをサポートするために必要とされます。しかし、サーバ名表示のTLS拡張子（「サーバ名」）[TLS-EXT]すべてのクライアントによって実装されるべきです。それはまた、複数の名前で知られている任意のサーバ実装STARTTLSで実装する必要があります。 （それ以外の場合は、クライアントへの正しい証明書を提示するには、いくつかのホスト名を持つサーバー用にはできません。）
If the TLS negotiation fails, both client and server SHOULD immediately close the connection. Note that while continuing the NNTP session is theoretically possible, in practice a TLS negotiation failure often leaves the session in an indeterminate state; therefore, interoperability can not be guaranteed.
TLSネゴシエーションが失敗した場合、クライアントとサーバーの両方がすぐに接続を閉じる必要があります。 NNTPセッションを継続することは理論的には可能であるが、実際にはTLSネゴシエーションの失敗は、多くの場合、不確定な状態でセッションを去ることに注意してください。そのため、相互運用性を保証することはできません。
Upon successful completion of the TLS handshake, the NNTP protocol is reset to the state immediately after the initial greeting response (see 5.1 of [NNTP]) has been sent, with the exception that if a MODE READER command has been issued, its effects (if any) are not reversed. At this point, as no greeting is sent, the next step is for the client to send a command. The server MUST discard any knowledge obtained from the client, such as the current newsgroup and article number, that was not obtained from the TLS negotiation itself. Likewise, the client SHOULD discard and MUST NOT rely on any knowledge obtained from the server, such as the capability list, which was not obtained from the TLS negotiation itself.
TLSハンドシェイクが正常に完了すると、NNTPプロトコルは初期の挨拶応答が（[NNTP]の5.1を参照）であればMODEリーダコマンドが発行されたことを除いて、送信された直後の状態にリセットされ、その効果（ ）いずれかの場合は逆になっていません。何の挨拶が送信されないよう、この時点では、次のステップでは、コマンドを送信するクライアントのためです。サーバーは、TLS交渉自体から得られなかった現在のニュースグループと記事数、として、クライアントから得た知識を捨てなければなりません。同様に、クライアントが破棄すべきであると、このようなTLS交渉自体から得られなかった機能のリストとして、サーバから取得したすべての知識に頼ってはなりません。
The server remains in the non-authenticated state, even if client credentials are supplied during the TLS negotiation. The AUTHINFO SASL command [NNTP-AUTH] with the EXTERNAL mechanism [SASL] MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support AUTHINFO in general or the EXTERNAL mechanism in particular. The server MAY use information from the client certificate for identification of connections or posted articles (either in its logs or directly in posted articles).
サーバーは、クライアントの資格情報は、TLSネゴシエーション中に供給されていても、非認証状態のまま。 EXTERNALメカニズム[SASL]とAUTHINFO SASLコマンド[NNTP-AUTH]はTLSクライアントの資格情報が正常に交換された後の認証に使用することができるが、STARTTLSコマンドをサポートするサーバは、一般的または具体的には外部機構にAUTHINFOをサポートする必要はありません。サーバーは接続または掲載記事（そのログに直接投稿記事中のいずれか）を識別するためのクライアント証明書からの情報を使用することができます。
Both the client and the server MUST know if there is a TLS session active. A client MUST NOT attempt to start a TLS session if a TLS session is already active. A server MUST NOT return the STARTTLS capability label in response to a CAPABILITIES command received after a TLS handshake has completed, and a server MUST respond with a 502 response code if a STARTTLS command is received while a TLS session is already active. Additionally, the client MUST NOT issue a MODE READER command while a TLS session is active, and a server MUST NOT advertise the MODE-READER capability.
アクティブなTLSセッションがある場合は、クライアントとサーバの両方が知っている必要があります。 TLSセッションが既にアクティブである場合、クライアントはTLSセッションを開始するのを試みてはいけません。 TLSハンドシェイクが完了した後に、サーバは、受信したコマンド機能に応じて、STARTTLS機能ラベルを返してはならない、とTLSセッションがすでにアクティブである間STARTTLSコマンドを受信した場合、サーバーは502応答コードで応じなければなりません。また、TLSセッションがアクティブな間、クライアントは、MODEのREADERコマンドを発行してはならない、とサーバはMODE-READERの機能をアドバタイズしてはなりません。
The capability list returned in response to a CAPABILITIES command received after a successful TLS handshake MAY be different from the list returned before the TLS handshake. For example, an NNTP server supporting SASL [NNTP-AUTH] might not want to advertise support for a particular mechanism unless a client has sent an appropriate client certificate during a TLS handshake.
機能への応答で返さ機能リストは、TLSハンドシェイクの前に返されたリストは異なる場合があり成功TLSハンドシェイクの後に受信したコマンド。たとえば、SASL [NNTP-AUTH]をサポートするNNTPサーバは、クライアントがTLSハンドシェイク中に、適切なクライアント証明書を送信した場合を除き、特定のメカニズムをサポートすることを通知したくない場合があります。
Example of a client being prompted to use encryption and negotiating it successfully (showing the removal of STARTTLS from the capability list once a TLS layer is active), followed by a successful selection of the group and an (inappropriate) attempt by the client to initiate another TLS negotiation:
グループの成功選択及び開始するためにクライアントによって（不適切な）試みが続く暗号化及び（TLS層がアクティブになると能力リストからSTARTTLSの除去を示す）正常に交渉を使用するように指示されているクライアントの例別のTLSネゴシエーション：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] STARTTLS [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] OVER [S] . [C] GROUP local.confidential [S] 483 Encryption or stronger authentication required
[C] CAPABILITIES [S] 101の能力リスト：[S] OVER [S] VERSION 2 [S] READER [S] STARTTLS [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S]。 [C]グループlocal.confidential [S] 483暗号化または強力な認証が必要
[C] STARTTLS [S] 382 Continue with TLS negotiation [TLS negotiation occurs here] [Following successful negotiation, traffic is protected by TLS] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] OVER [S] . [C] GROUP local.confidential [S] 211 1234 3000234 3002322 local.confidential [C] STARTTLS [S] 502 STARTTLS not allowed with active TLS layer
[C] STARTTLS [S] 382は、TLS交渉を続行し、[TLSネゴシエーションがここで起こる] [成功した交渉の後、トラフィックがTLSで保護されている] [C]ケーパ[S] 101機能リスト：[S] VERSION 2 [S] READER [ [OVER S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] S]。 [C]グループlocal.confidential [S] 211 1234 3000234 3002322 local.confidential [C] STARTTLS [S]活性TLS層が許可されていない502のSTARTTLS
Example of a request to begin TLS negotiation declined by the server:
TLSネゴシエーションを開始する要求の例では、サーバーによって減少しました：
[C] STARTTLS [S] 580 Can not initiate TLS negotiation
[C] STARTTLS [S] 580は、TLS交渉を開始することはできません
Example of a failed attempt to negotiate TLS, followed by two attempts at selecting groups only available under a security layer (in the first case, the server allows the session to continue; in the second, it closes the connection). Note that unrestricted commands such as CAPABILITIES are unaffected by the failure:
セキュリティ層（;第二に、それは接続を閉じ最初のケースでは、サーバはセッションを継続することを可能にする）の下でのみ使用可能なグループを選択する2つの試みに続いてTLSを交渉するために失敗した、例。そのような能力として無制限のコマンドは失敗の影響を受けないことに注意してください。
[C] STARTTLS [S] 382 Continue with TLS negotiation [TLS negotiation is attempted here] [Following failed negotiation, traffic resumes without TLS] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] STARTTLS [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] OVER [S] . [C] GROUP local.confidential [S] 483 Encryption or stronger authentication required [C] GROUP local.private [S] 400 Closing connection due to lack of security
[C] STARTTLS [S] 382は、TLS交渉を続行し、[TLS交渉がここにしようとしている] [失敗した交渉の後、トラフィックはTLSなしで再開] [C]ケーパ[S] 101機能リスト：[S] VERSION 2 [S] READER [ S] STARTTLS [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT [S] S [OVER。 [C] GROUP local.confidential [S] 483暗号化または強力な認証に必要な[C]グループlocal.private [S] 400クロージング接続によるセキュリティの欠如に
This section describes the formal syntax of the STARTTLS extension using ABNF [ABNF]. It extends the syntax in Section 9 of [NNTP], and non-terminals not defined in this document are defined there. The [NNTP] ABNF should be imported first before attempting to validate these rules.
このセクションでは、ABNF [ABNF]を使用してSTARTTLS拡張の正式な構文について説明します。これは、[NNTP]のセクション9の構文を拡張し、この文書で定義されていない非端末はそこに定義されています。 [NNTP] ABNFはこれらの規則を検証しようとする前に、最初にインポートする必要があります。
This syntax extends the non-terminal "command", which represents an NNTP command.
この構文は、NNTPコマンドを表す非終端「コマンド」、延びています。
command =/ starttls-command
コマンド= / STARTTLSコマンド
starttls-command = "STARTTLS"
STARTTLSコマンド= "STARTTLS"
This syntax extends the non-terminal "capability-entry", which represents a capability that may be advertised by the server.
この構文は、サーバによって通知することができる能力を表す非末端「機能エントリ」を、延びています。
capability-entry =/ starttls-capability
機能-エントリ= / STARTTLS-機能
starttls-capability = "STARTTLS"
STARTTLS-機能= "STARTTLS"
This section contains a list of each new response code defined in this document and indicates whether it is multi-line, which commands can generate it, what arguments it has, and what its meaning is.
このセクションでは、この文書で定義されたそれぞれの新しい応答コードのリストが含まれ、それが持っているものの引数、それはそれを生成できるコマンドを複数行、であるかどうかを示す、と何の意味があります。
Response code 382 Generated by: STARTTLS Meaning: continue with TLS negotiation
STARTTLS意味：：によって生成された応答コード382は、TLS交渉を続けます
Response code 580 Generated by: STARTTLS Meaning: can not initiate TLS negotiation
STARTTLS意味：：によって生成された応答コード580は、TLS交渉を開始することはできません
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ中で議論されています。
In general, the security considerations of the TLS protocol [TLS] and any implemented extensions [TLS-EXT] are applicable here; only the most important are highlighted specifically below. Also, this extension is not intended to cure the security considerations described in Section 12 of [NNTP]; those considerations remain relevant to any NNTP implementation.
一般的に、TLSプロトコルのセキュリティ上の考慮事項[TLS]と任意の実装の拡張[TLS-EXT]はここで適用可能です。唯一の最も重要なのは、以下に具体的に強調表示されます。また、この拡張は、[NNTP]のセクション12に記載のセキュリティ問題を硬化することを意図していません。これらの考察は任意のNNTP実装に関連したまま。
NNTP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is important, as it assures that any two compliant implementations can be configured to interoperate. All other cipher suites are OPTIONAL.
NNTPクライアントとサーバの実装はTLS_RSA_WITH_RC4_128_MD5 [TLS]暗号スイートを実装しなければならないとTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS]暗号スイートを実装する必要があります。それは任意の二つの準拠する実装は、相互運用するように構成することができることを保証するため、これは重要です。他のすべての暗号スイートはオプションです。
Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any sensitive knowledge obtained prior to the start of the TLS handshake upon the establishment of a security layer. Furthermore, the CAPABILITIES command SHOULD be re-issued upon the establishment of a security layer, and other protocol state SHOULD be re-negotiated as well.
TLSハンドシェイクが開始される前に、任意のプロトコル相互作用は明確に行われ、活発な攻撃者によって修正されてもよいです。このため、クライアントとサーバは、前のセキュリティ層の確立時にTLSハンドシェイクの開始を得た機密知識を捨てなければなりません。また、capabilitiesコマンドは、セキュリティ層の確立時に再発行されるべきであり、他のプロトコル状態は、同様に再ネゴシエートされるべきです。
Note that NNTP is not an end-to-end mechanism. Thus, if an NNTP client/server pair decide to add TLS confidentiality, they are securing the transport only for that link. Similarly, because delivery of a single Netnews article may go between more than two NNTP servers, adding TLS confidentiality to one pair of servers does not mean that the entire NNTP chain has been made private. Furthermore, just because an NNTP server can authenticate an NNTP client, it does not mean that the articles from the NNTP client were authenticated by the NNTP client when the client itself received them (prior to forwarding them to the server).
NNTPは、エンドツーエンドのメカニズムではないことに注意してください。 NNTPクライアント/サーバのペアは、TLSの機密性を追加することにした場合このように、彼らはそのリンクのための輸送を確保しています。同様に、単一のネットニュース記事の配信は全体NNTPチェーンがプライベートなされていることを意味するものではありませんサーバーのいずれかのペアにTLSの機密性を追加し、二つ以上のNNTPサーバ間で行くかもしれないので。さらに、NNTPサーバーは、NNTPクライアントを認証できるという理由だけで、それはクライアント自身がそれらを受け取ったとき、NNTPクライアントからの記事をNNTPクライアントによって認証されたことを意味するものではありません（サーバーにそれらを転送する前に）。
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:
man-in-the-middle攻撃を防ぐために、サーバ証明書メッセージに提示されるTLSネゴシエーション中に、クライアントはサーバーのIDに対するサーバーのホスト名のその理解をチェックしなければなりません。マッチングは、これらの規則に従って実行されます。
- The client MUST use the server hostname it used to open the connection (or the hostname specified in TLS "server_name" extension [TLS-EXT]) 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.
- クライアントは、接続（またはTLS「サーバ名」拡張子[TLS-EXT]で指定されたホスト名）サーバ証明書で表される値は、サーバ名と比較するように開くために使用されるサーバのホスト名を使用しなければなりません。クライアントは、安全でないリモートソース（例えば、安全でないDNSルックアップ）に由来するサーバのホスト名のいずれかの形式を使用してはなりません。 CNAMEの正規化が行われていません。
- 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拡張が証明書に存在している場合、それはサーバのアイデンティティの源として使用する必要があります。
- 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.
- A「*」ワイルドカード文字は、証明書内の一番左の名前の成分として使用することができます。たとえば、* .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.
- 証明書が複数の名前が含まれている場合（例えば、複数のdNSNameフィールドが）、その後のフィールドのいずれかとの一致が許容されると考えられます。
If the match fails, the client SHOULD either ask for explicit user confirmation or terminate the connection with a QUIT command and indicate the server's identity is suspect.
マッチが失敗した場合、クライアントは、明示的なユーザの確認を求めるか、QUITコマンドとの接続を終了し、サーバのアイデンティティが疑わしいであることを示すべきです。
Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKI-CERT] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
さらに、クライアントは接続先のサーバとそれらのサーバが提示する公開鍵のアイデンティティ間の結合を確かめなければなりません。クライアントは、一般的な証明書の検証のために[PKI-CERT]のセクション6にアルゴリズムを実装する必要があり、そのような検査済みの証明書のローカルストアに対してサーバ証明書を比較するよう検証の等価レベルを（達成する他の検証方法とそのアルゴリズムを補うMAYそして、アイデンティティバインディング）。
A man-in-the-middle attack can be launched by deleting the STARTTLS capability label in the CAPABILITIES response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack would allow the server to announce its STARTTLS capability, but alter the client's request to start TLS and the server's response. An NNTP client can partially protect against these attacks by recording the fact that a particular NNTP server offers TLS during one session and generating an alarm if it does not appear in the CAPABILITIES response for a later session. (Of course, the STARTTLS capability would not be listed after a security layer is in place.)
man-in-the-middle攻撃は、サーバからのケーパビリティ応答でSTARTTLS機能ラベルを削除することによって起動することができます。これは、TLSセッションを開始しようとしていないクライアントを引き起こします。別のman-in-the-middle攻撃は、サーバがSTARTTLS機能を発表することができますが、TLSを開始するためのクライアントの要求とサーバの応答を変更するであろう。 NNTPクライアントは、部分的に、特定のNNTPサーバが1つのセッション中にTLSを提供しているという事実を記録し、それが後のセッションのためのケーパビリティ応答に表示されていない場合にアラームを生成することにより、これらの攻撃から守ることができます。 （セキュリティ層が配置された後もちろん、STARTTLS機能は表示されません。）
If the client receives a 483 or 580 response, the client has to decide what to do next. The client has to choose among three main options: to go ahead with the rest of the NNTP session, to (re)try TLS later in the session, or to give up and postpone newsreading/transport activity. If an error occurs, the client can assume that the server may be able to negotiate TLS in the future and should try to negotiate TLS in a later session. However, if the client and server were only using TLS for authentication and no previous 480 response was received, the client may want to proceed with the NNTP session, in case some of the operations the client wanted to perform are accepted by the server even if the client is unauthenticated.
クライアントが483または580応答を受信した場合、クライアントは次に何をすべきかを決定する必要があります。 （再）以降のセッションでTLSを試すか、あきらめとニュースリーダー/輸送活性を延期することに、NNTPセッションの残りの部分と先に行くには：クライアントは、3つの主要なオプションから選択する必要があります。エラーが発生した場合、クライアントは、サーバが、将来的にTLSを交渉することがあり得ることを想定することができ、後のセッションでTLSを交渉してみてください。クライアントとサーバが唯一の認証にTLSを使用していたし、以前の480応答が受信されなかった場合は、クライアントがサーバーとしても受け入れられている場合には、NNTPセッションでクライアントを実行したい操作のいくつかを続行することができますクライアントが認証されていないです。
This section gives a formal definition of the STARTTLS extension as required by Section 3.3.3 of [NNTP] for the IANA registry.
IANAレジストリのために[NNTP]のセクション3.3.3で必要とされるこのセクションでは、STARTTLS拡張の正式な定義を与えます。
o The STARTTLS extension provides connection-based security via the Transport Layer Security (TLS).
O STARTTLS拡張機能は、トランスポート層セキュリティ（TLS）を介して接続ベースのセキュリティを提供します。
o The capability label for this extension is "STARTTLS".
Oこの拡張のための能力ラベルは、「STARTTLS」です。
o The capability label has no arguments.
O機能のラベルには引数がありません。
o This extension defines one new command, STARTTLS, whose behavior, arguments, and responses are defined in Section 2.2.
Oこの拡張は、その行動、引数、および応答は、セクション2.2で定義されている1つの新しいコマンド、STARTTLSを定義します。
o This extension does not associate any new responses with pre-existing NNTP commands.
Oこの拡張は、既存のNNTPコマンドで、新しい応答を関連付けることはありません。
o This extension does affect the overall behavior of both server and client, in that after successful use of the STARTTLS command, all communication is transmitted with the TLS protocol as an intermediary.
Oこの拡張は、サーバとクライアントの両方の全体的な動作に影響を与えない、STARTTLSコマンドの使用の成功した後、その中で、すべての通信を媒介としてTLSプロトコルで送信されます。
o This extension does not affect the maximum length of commands or initial response lines.
Oこの拡張は、コマンドや初期応答行の最大長さに影響を与えることはありません。
o This extension does not alter pipelining, but the STARTTLS command cannot be pipelined.
Oこの拡張は、パイプラインを変更しませんが、STARTTLSコマンドをパイプライン化することができません。
o Use of this extension does alter the capabilities list; once the STARTTLS command has been used successfully, the STARTTLS capability can no longer be advertised by CAPABILITIES.
Oこの拡張機能を使用すると、機能のリストを変更しません。 STARTTLSコマンドが正常に使用された後、STARTTLS機能は、もはや性能によって宣伝することはできません。
Additionally, the MODE-READER capability MUST NOT be advertised after a successful TLS negotiation.
また、MODE-READER機能は成功したTLSネゴシエーション後に広告を出してはなりません。
o This extension does not cause any pre-existing command to produce a 401, 480, or 483 response.
Oこの拡張機能は、任意の既存のコマンドでは、401、480、または483応答を生成することはありません。
o This extension is unaffected by any use of the MODE READER command, however the MODE READER command MUST NOT be used in the same session following a successful TLS negotiation.
Oこの拡張は、しかし、MODEのREADERコマンドが成功したTLSネゴシエーション以下同じセッションで使用してはいけません、MODEのREADERコマンドのいずれかを使用することによって影響を受けません。
o Published Specification: This document.
O発行仕様：このドキュメント。
o Contact for Further Information: Authors of this document.
詳しい情報についてはO接点：この文書の著者。
o Change Controller: IESG <iesg@ietf.org>.
Oの変更コントローラ：IESG <iesg@ietf.org>。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP]フェザー、C.、 "ネットワークニュース転送プロトコル（NNTP）"、RFC 3977、2006年10月。
[PKI-CERT] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKI-CERT] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[TLS-EXT]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[NNTP-AUTH] Vinocur, J., Murchison, K., and C. Newman, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, October 2006.
[NNTP-AUTH] Vinocur、J.、マーチソン、K.、およびC.ニューマン、 "認証のためのネットワークニュース転送プロトコル（NNTP）拡張子"、RFC 4643、2006年10月。
[SASL] Melninov, A., Ed. and K. Zeilenga, Ed, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] Melninov、A.編。そして、K. Zeilenga、エド、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[TLS-IMAPPOP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
"IMAP、POP3およびACAPとTLSを使用する" [TLS-IMAPPOP]ニューマン、C.、RFC 2595、1999年6月。
A significant amount of the text in this document was lifted from RFC 2595 by Chris Newman and RFC 3207 by Paul Hoffman.
この文書内のテキスト、かなりの量は、ポール・ホフマンによってクリス・ニューマンによってRFC 2595およびRFC 3207から持ち上げました。
Special acknowledgement goes also to the people who commented privately on intermediate revisions of this document, as well as the members of the IETF NNTP Working Group for continual insight in discussion.
特別な承認は、議論の継続的な洞察力のために、この文書の改訂中間に私的コメントの人々だけでなく、IETF NNTPワーキンググループのメンバーにもなります。
Authors' Addresses
著者のアドレス
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
ケネス・マーチソンカーネギーメロン大学5000フォーブス・アベニューCyertホール285ピッツバーグ、PA 15213 USA
EMail: murch@andrew.cmu.edu
メールアドレス：murch@andrew.cmu.edu
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853
コンピュータサイエンスアップソンホールコーネル大学イサカ、NY 14853のジェフリーM. Vinocur部門
EMail: vinocur@cs.cornell.edu
メールアドレス：vinocur@cs.cornell.edu
Chris Newman Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761
クリス・ニューマンSun Microsystemsの3401 Centrelake博士は、スイート410オンタリオ、CA 91761
EMail: Chris.Newman@sun.com
メールアドレス：Chris.Newman@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。