[要約] RFC 7194は、IRCをTLS/SSL経由で実行するためのデフォルトポートに関する要件を定義しています。その目的は、セキュアな通信を確保し、IRCサーバーとクライアント間のデータの機密性と完全性を保護することです。
Independent Submission R. Hartmann
Request for Comments: 7194 August 2014
Updates: 1459
Category: Informational
ISSN: 2070-1721
Default Port for Internet Relay Chat (IRC) via TLS/SSL
TLS / SSLを介したインターネットリレーチャット（IRC）のデフォルトポート
Abstract
概要
This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.
このドキュメントでは、TLS / SSLを介して暗号化された受信インターネットリレーチャット（IRC）接続をTCPポート6697でリッスンする一般的に受け入れられている方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7194.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7194で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Rationale .......................................................2
2. Technical Details ...............................................2
2.1. Connection Establishment ...................................2
2.2. Certificate Details ........................................3
2.2.1. Server Certificate ..................................3
2.2.2. Client Certificate ..................................3
3. Security Considerations .........................................3
4. IANA Considerations .............................................4
5. Normative References ............................................4
6. Informative References ..........................................4
7. Acknowledgements ................................................5
Appendix A. Supporting Data ........................................6
Although system port assignments exist for IRC traffic that is plain text (TCP/UDP port 194) or TLS/SSL encrypted (TCP/UDP port 994) [IANALIST], it is common practice amongst IRC networks not to use them for reasons of convenience and general availability on systems where no root access is granted or desired.
システムポートの割り当ては、プレーンテキスト（TCP / UDPポート194）またはTLS / SSL暗号化（TCP / UDPポート994）[IANALIST]であるIRCトラフィック用に存在しますが、IRCネットワークでは、便宜上これらを使用しないのが一般的です。また、rootアクセスが許可または要求されていないシステムでの一般的な可用性。
IRC networks have defaulted to listening on TCP port 6667 for plain text connections for a considerable time now. This is covered by the IRCU assignment of TCP/UDP ports 6665-6669.
IRCネットワークは、かなり長い間、プレーンテキスト接続をTCPポート6667でリッスンするようにデフォルト設定されています。これは、TCP / UDPポート6665-6669のIRCU割り当てによってカバーされます。
Similar consensus has been reached within the IRC community about listening on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL [RFC5246].
IRCコミュニティ内でも、TLS / SSL [RFC5246]を介して暗号化された着信IRC接続をTCPポート6697でリッスンすることについて、同様のコンセンサスが得られています。
An IRC client connects to an IRC server. Immediately after that, a normal TLS/SSL handshake takes place. Once the TLS/SSL connection has been established, a normal IRC connection is established via the tunnel. Optionally, the IRC server may set a specific user mode (umode) for the client, marking it as using TLS/SSL. Again, optionally, an IRC server might offer the option to create channels in such a way that only clients connected via TLS/SSL may join.
IRCクライアントはIRCサーバーに接続します。その直後に、通常のTLS / SSLハンドシェイクが行われます。 TLS / SSL接続が確立されると、通常のIRC接続がトンネル経由で確立されます。オプションで、IRCサーバーはクライアントに特定のユーザーモード（umode）を設定し、TLS / SSLを使用するものとしてマークを付けることができます。この場合も、オプションで、IRCサーバーは、TLS / SSLを介して接続されたクライアントのみが参加できるような方法でチャネルを作成するオプションを提供する場合があります。
For details on how IRC works, see [RFC1459], [RFC2810], [RFC2811], [RFC2812], and [RFC2813]. Please note that IRC is extremely fragmented, and implementation details can vary wildly. Most implementations regard the latter RFCs as suggestions, not as binding.
IRCの動作の詳細については、[RFC1459]、[RFC2810]、[RFC2811]、[RFC2812]、および[RFC2813]を参照してください。 IRCは非常に断片化されており、実装の詳細は大幅に異なる可能性があることに注意してください。ほとんどの実装では、後者のRFCをバインディングではなく提案と見なしています。
The IRC server's certificate should be issued by a commonly trusted certification authority (CA).
IRCサーバーの証明書は、一般的に信頼されている証明機関（CA）によって発行される必要があります。
The Common Name should match the Fully Qualified Domain Name (FQDN) of the IRC server or have appropriate wildcards, if applicable.
共通名は、IRCサーバーの完全修飾ドメイン名（FQDN）と一致するか、該当する場合は適切なワイルドカードを使用する必要があります。
The IRC client should verify the certificate.
IRCクライアントは証明書を確認する必要があります。
If the client is using a certificate as well, it should be issued by a commonly trusted CA or a CA designated by the IRC network.
クライアントが証明書も使用している場合は、一般的に信頼されているCAまたはIRCネットワークによって指定されたCAが発行する必要があります。
The certificate's Common Name should match the main IRC nickname.
証明書の共通名は、メインのIRCニックネームと一致する必要があります。
If the network offers nick registration, this nick should be used.
ネットワークがニック登録を提供している場合は、このニックを使用する必要があります。
If the network offers grouped nicks, the main nick or account name should be used.
ネットワークがグループ化されたニックネームを提供する場合、メインのニックネームまたはアカウント名を使用する必要があります。
If the network offers nick registration, the client certificate should be used to identify the user against the nick database. See [CERTFP] for a possible implementation.
ネットワークがニック登録を提供している場合は、クライアント証明書を使用して、ニックデータベースに対してユーザーを識別します。可能な実装については、[CERTFP]を参照してください。
The lack of a common, well-established listening port for IRC via TLS/SSL could lead to end users being unaware of their IRC network of choice supporting TLS/SSL. Thus, they might not use encryption even if they wanted to.
TLS / SSLを介したIRCの一般的な確立されたリスニングポートがないと、エンドユーザーはTLS / SSLをサポートするIRCネットワークの選択に気付かない可能性があります。したがって、暗号化を使用したい場合でも、使用しない可能性があります。
It should be noted that this document merely describes client-to-server encryption. There are still other attack vectors like malicious administrators, compromised servers, insecure server-to-server communication, channels that do not enforce encryption for all channel members, malicious clients, or comprised client machines on which logs are stored.
このドキュメントでは、クライアントからサーバーへの暗号化についてのみ説明していることに注意してください。悪意のある管理者、侵害されたサーバー、安全でないサーバー間通信、すべてのチャネルメンバーに暗号化を適用しないチャネル、悪意のあるクライアント、またはログが保存されている構成されたクライアントマシンのような他の攻撃ベクトルがあります。
Those attacks can by their very nature not be addressed by client-to-server encryption. Additional safeguards are needed if a user fears any of the threats above.
これらの攻撃は、その性質上、クライアントからサーバーへの暗号化では対処できません。ユーザーが上記の脅威のいずれかを恐れている場合は、追加の保護手段が必要です。
This document does not address server links as there are no commonly accepted ports or even back-end protocols. Ports and back-end protocols are normally established in a bilateral agreement. All operators are encouraged to use strong encryption for back-end traffic, no matter if they offer IRC via TLS/SSL to end users.
一般的に受け入れられているポートやバックエンドプロトコルさえないため、このドキュメントではサーバーリンクについては扱いません。ポートとバックエンドプロトコルは通常、二国間協定で確立されます。 TLS / SSLを介してIRCをエンドユーザーに提供するかどうかに関係なく、すべてのオペレーターは、バックエンドトラフィックに強力な暗号化を使用することが推奨されます。
An assignment of TCP port 6697 for IRC via TLS/SSL has been made. The service name is "ircs-u" and the description "Internet Relay Chat via TLS/SSL":
TLS / SSLを介したIRCのTCPポート6697の割り当てが行われました。サービス名は「ircs-u」で、説明は「TLS / SSLを介したインターネットリレーチャット」です。
ircs-u 6697/tcp Internet Relay Chat via TLS/SSL
ircs-u 6697 / tcp TLS / SSLによるインターネットリレーチャット
[RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[RFC1459] Oikarinen、J。およびD. Reed、「インターネットリレーチャットプロトコル」、RFC 1459、1993年5月。
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[RFC2810] Kalt、C。、「インターネットリレーチャット：アーキテクチャ」、RFC 2810、2000年4月。
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[RFC2811] Kalt、C。、「インターネットリレーチャット：チャネル管理」、RFC 2811、2000年4月。
[RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[RFC2812] Kalt、C。、「インターネットリレーチャット：クライアントプロトコル」、RFC 2812、2000年4月。
[RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[RFC2813] Kalt、C。、「インターネットリレーチャット：サーバープロトコル」、RFC 2813、2000年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[IANALIST] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>.
[IANALIST] IANA、「サービス名およびトランスポートプロトコルのポート番号レジストリ」、<http://www.iana.org/assignments/ service-names-port-numbers>。
[TOP100] netsplit.de, "IRC Networks - Top 100", <http://irc.netsplit.de/networks/top100.php>.
[TOP100] netsplit.de、「IRC Networks-Top 100」、<http://irc.netsplit.de/networks/top100.php>。
[MAVERICK] netsplit.de, "IRC Networks - in alphabetical order", <http://irc.netsplit.de/networks/ lists.php?query=maverick>.
[MAVERICK] netsplit.de、「IRCネットワーク-アルファベット順」、<http://irc.netsplit.de/networks/lists.php?query=maverick>。
[CERTFP] The Open and Free Technology Community, "OFTC - NickServ/CertFP", <http://www.oftc.net/oftc/NickServ/CertFP>.
[CERTFP]オープンで無料のテクノロジーコミュニティ、「OFTC-NickServ / CertFP」、<http://www.oftc.net/oftc/NickServ/CertFP>。
Thanks go to the IRC community at large for reaching a consensus.
合意に達してくれたIRCコミュニティ全体に感謝します。
Special thanks go to the IRC operators who were eager to support port 6697 on their respective networks.
それぞれのネットワークでポート6697をサポートすることを熱望していたIRCオペレーターに特に感謝します。
Special thanks also go to Nevil Brownlee and James Schaad for working on this document in their capacities as Independent Submissions Editor and Reviewer, respectively.
また、このドキュメントを独立した投稿の編集者およびレビュー担当者としてそれぞれ機能させてくれたNevil BrownleeとJames Schaadにも感謝します。
As of October 2010, out of the top twenty IRC networks [TOP100] [MAVERICK], ten support TLS/SSL. Only one of those networks does not support TLS/SSL via port 6697 and has no plans to support it. All others supported it already or are supporting it since being contacted by the author. A more detailed analysis is available but does not fit within the scope of this document.
2010年10月現在、上位20のIRCネットワーク[TOP100] [MAVERICK]のうち、10がTLS / SSLをサポートしています。これらのネットワークの1つだけが、ポート6697を介したTLS / SSLをサポートしておらず、サポートする予定もありません。他のすべての人はすでにサポートしているか、作者から連絡を受けてからサポートしています。より詳細な分析が利用可能ですが、このドキュメントの範囲内には収まりません。
Authors' Address
著者のアドレス
Richard Hartmann Munich Germany
リチャードハートマンミュンヘンドイツ
EMail: richih.mailinglist@gmail.com
URI: http://richardhartmann.de