Independent Submission R. Hartmann
Request for Comments: 7194 August 2014
Updates: 1459
Category: Informational
ISSN: 2070-1721
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进行Internet中继聊天（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.
本文档介绍了在TCP端口6697上侦听通过TLS/SSL加密的传入Internet中继聊天（IRC）连接的常见做法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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
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网络中的常见做法是，出于方便和通用性的原因，在没有授予或需要根访问权限的系统上不使用这些端口。
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社区也达成了类似的共识，即在TCP端口6697上侦听通过TLS/SSL加密的传入IRC连接[RFC5246]。
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.
如果网络提供nick注册，则应使用此nick。
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.
如果网络提供nick注册，则应使用客户端证书根据nick数据库识别用户。有关可能的实现，请参阅[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进行Internet中继聊天”：
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.，“互联网中继聊天：架构”，RFC28102000年4月。
[RFC2811] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[RFC2811]Kalt，C.，“互联网中继聊天：频道管理”，RFC281112000年4月。
[RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[RFC2812]Kalt，C.，“互联网中继聊天：客户端协议”，RFC2812，2000年4月。
[RFC2813] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[RFC2813]Kalt，C.，“互联网中继聊天：服务器协议”，RFC2813，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，“传输层安全（TLS）协议版本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/ 服务名称端口号>。
[TOP100] netsplit.de, "IRC Networks - Top 100", <http://irc.netsplit.de/networks/top100.php>.
[TOP100]netsplit.de，“IRC网络-前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.
特别感谢IRC运营商，他们渴望在各自的网络上支持端口6697。
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月，在排名前二十的IRC网络[TOP100][MAVERICK]中，有十个支持TLS/SSL。这些网络中只有一个不支持通过端口6697的TLS/SSL，并且没有支持它的计划。所有其他人都已经支持它，或者在作者联系后正在支持它。可提供更详细的分析，但不在本文件范围内。
Authors' Address
作者地址
Richard Hartmann Munich Germany
德国慕尼黑理查德·哈特曼
EMail: richih.mailinglist@gmail.com
URI: http://richardhartmann.de
EMail: richih.mailinglist@gmail.com
URI: http://richardhartmann.de