Independent Submission R. Hartmann
Request for Comments: 7194 August 2014
Updates: 1459
Category: Informational
ISSN: 2070-1721
TLS 経由のインターネットリレーチャット（IRC）のデフォルトポート
IRC
- RFC 1459 (Internet Relay Chat Protocol)
- RFC 2810 (Internet Relay Chat: Architecture)
- RFC 2811 (Internet Relay Chat: Channel Management)
- RFC 2812 (Internet Relay Chat: Client Protocol)
- RFC 2813 (Internet Relay Chat: Server Protocol)
- RFC 7194 (Default Port for Internet Relay Chat (IRC) via TLS/SSL)
概要
この文書では、TLS/SSL で暗号化されたインターネットリレーチャット（IRC）接続を TCP ポート6697でリッスンする一般的な方法について説明します。
本メモの位置づけ
この文書は、Internet Standards Track の仕様ではなく、情報提供を目的として公開されています。
これは、他の RFC の流れとは無関係に、RFC シリーズに貢献するものです。RFC 編集者は自らの裁量でこの文書を公開することを選択し、実装や配備のための価値について何ら表明するものではありません。RFC エディタによって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 5741 の 2 章を参照。
この文書の現在の状態、正誤表、それに対するフィードバックの方法に関する情報は、http://www.rfc-editor.org/info/rfc7194 で入手できます。
著作権について
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
この文書は、この文書の発行日に有効な BCP 78 および IETF トラストの IETF 文書に関する法的規定（http://trustee.ietf.org/license-info）に従うものとします。これらの文書は、この文書に関するあなたの権利と制限を記述しているので、 注意深く確認してください。
1. 根拠
プレーンテキスト（TCP/UDP ポート 194）または TLS/SSL で暗号化された（TCP/UDP ポート 994）[IANALIST] IRC トラフィック用のシステムポート割り当てが存在しますが、IRC ネットワークの間では、ルートアクセスが許可または望まれないシステムでの利便性と汎用性の理由でそれらを使用しないことが一般的な慣習となっています。
IRC ネットワークは、かなり以前からプレーンテキスト接続のために TCP ポート 6667 をデフォルトでリッスンしています。これは IRCU の TCP/UDP ポート 6665-6669 の割り当てによってカバーされています。
IRC コミュニティでは、TLS/SSL [RFC5246] を介して暗号化された IRC 接続のために TCP ポート 6697 をリッスンすることについて、同様の合意が得られています。
2. 技術的な詳細
2.1. 接続の確立
IRC クライアントが IRC サーバに接続します。その直後、通常の TLS/SSL ハンドシェイクが行われます。TLS/SSL 接続が確立されると、トンネルを経由して通常の IRC 接続が確立されます。オプションとして、IRC サーバはクライアントに特定のユーザモード（umode）を設定し、TLS/SSL を使用するようにマークすることができます。また、オプションとして、IRC サーバは、TLS/SSL で接続されたクライアントのみが参加できるようにチャネルを作成するオプションを提供することができます。
IRC の動作の詳細については、[RFC1459], [RFC2810], [RFC2811], [RFC2812], [RFC2813] を参照してください。IRC は非常に断片的であり、実装の詳細が大きく異なる可能性があることに注意してください。ほとんどの実装は後者の RFC を提案とみなしており、束縛するものではありません。
2.2. 証明書の詳細
2.2.1. サーバ証明書
IRC サーバの証明書は、一般的に信頼されている認証局（CA）から発行されたものである必要があります。
Common Name は、IRC サーバの FQDN（Fully Qualified Domain Name）と一致するか、該当する場合は適切なワイルドカードを持つ必要があります。
IRC クライアントは、証明書を検証する必要があります。
2.2.2. クライアント証明書
クライアントも証明書を使用する場合は、一般的に信頼されている CA または IRC ネットワークが指定した CA から発行されたものを使用する必要があります。
証明書の Common Name は、メインの IRC のニックネームと一致させる必要があります。
ネットワークがニックネーム登録を提供している場合、このニックネームを使用する必要があります。
ネットワークがグループ化されたニックネームを提供している場合、メインのニックネームまたはアカウント名を使用する必要があります。
ネットワークがニックネーム登録を提供している場合、クライアント証明書はニックネームデータベースに対してユーザを識別するために使用されるべきです。可能な実装については、[CERTFP] を参照してください。
3. セキュリティへの配慮
TLS/SSL 経由の IRC のための一般的で確立されたリスニングポートがないため、エンドユーザは、選択した IRC ネットワークが TLS/SSL をサポートしていることに気づかない可能性があります。したがって、彼らは暗号化を使用したくても使用しないかもしれません。
この文書では、単にクライアントからサーバへの暗号化について説明しているに過ぎないことに留意すべきです。悪意のある管理者、危険なサーバ、安全でないサーバ間通信、チャネルの全メンバに暗号化を強制しないチャネル、悪意のあるクライアント、ログが保存されているクライアントマシンの構成など、他の攻撃ベクトルがまだ存在します。
これらの攻撃は、その性質上、クライアントからサーバへの暗号化では対処できません。ユーザが上記のような脅威を恐れている場合は、さらなる保護措置が必要です。
一般的に受け入れられているポートやバックエンドプロトコルもないため、この文書ではサーバリンクについては触れていません。ポートやバックエンドプロトコルは通常、二国間協定で確立されます。すべてのオペレータは、エンドユーザに TLS/SSL 経由で IRC を提供するかどうかにかかわらず、バックエンドのトラフィックに強力な暗号化を使用することが推奨されます。
4. IANA に関する考察
IRC via TLS/SSL 用の TCP ポート 6697 の割り当てが行われました。サービス名は "ircs-u"、説明文は"Internet Relay Chat via TLS/SSL" です。
ircs-u 6697/tcp Internet Relay Chat via TLS/SSL
5. 規範となる参考文献
[RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
6. 有益な参考文献
[IANALIST] IANA, "Service Name and Transport Protocol Port Number Registry", http://www.iana.org/assignments/service-names-port-numbers.
[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.
[CERTFP] The Open and Free Technology Community, "OFTC - NickServ/CertFP", http://www.oftc.net/NickServ/CertFP.
7. 謝辞
IRC コミュニティ全体が合意に達したことに感謝します。
それぞれのネットワークでポート 6697 を熱心にサポートしてくれた IRC のオペレータに感謝します。
また、Nevil Brownlee 氏と James Schaad 氏には、それぞれ Independent Submissions Editor と Reviewer の立場でこの文書に携わっていただき、特別な謝意を表します。
8. 付録A. サポートデータ
2010年10月現在、IRC ネットワークのトップ20 [TOP100] [MAVERICK] のうち、10が TLS/SSL をサポートしています。そのうち1つだけが、ポート 6697 経由の TLS/SSL をサポートしておらず、サポートの予定もありません。それ以外のネットワークは、すでにサポートしているか、筆者が連絡を取ってからサポートするようになりました。より詳細な分析が可能であるが、このドキュメントの範囲には収まりません。
9. Authors' Address
Richard Hartmann
Munich
Germany
EMail: richih.mailinglist@gmail.com