Internet Engineering Task Force (IETF) S. Friedl
Request for Comments: 7301 Cisco Systems, Inc.
Category: Standards Track A. Popov
ISSN: 2070-1721 Microsoft Corp.
A. Langley
Google Inc.
E. Stephan
Orange
July 2014
Internet Engineering Task Force (IETF) S. Friedl
Request for Comments: 7301 Cisco Systems, Inc.
Category: Standards Track A. Popov
ISSN: 2070-1721 Microsoft Corp.
A. Langley
Google Inc.
E. Stephan
Orange
July 2014
Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
传输层安全（TLS）应用层协议协商扩展
Abstract
摘要
This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.
本文档描述了用于TLS握手中应用层协议协商的传输层安全性（TLS）扩展。对于在同一TCP或UDP端口上支持多个应用程序协议的实例，此扩展允许应用程序层协商将在TLS连接中使用哪个协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc7301.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7301.
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Application-Layer Protocol Negotiation . . . . . . . . . . . 3
3.1. The Application-Layer Protocol Negotiation Extension . . 3
3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 5
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Application-Layer Protocol Negotiation . . . . . . . . . . . 3
3.1. The Application-Layer Protocol Negotiation Extension . . 3
3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 5
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Increasingly, application-layer protocols are encapsulated in the TLS protocol [RFC5246]. This encapsulation enables applications to use the existing, secure communications links already present on port 443 across virtually the entire global IP infrastructure.
越来越多的应用层协议封装在TLS协议[RFC5246]中。这种封装使应用程序能够跨几乎整个全球IP基础设施使用端口443上现有的安全通信链路。
When multiple application protocols are supported on a single server-side port number, such as port 443, the client and the server need to negotiate an application protocol for use with each connection. It is desirable to accomplish this negotiation without adding network round-trips between the client and the server, as each round-trip will degrade an end-user's experience. Further, it would be advantageous to allow certificate selection based on the negotiated application protocol.
当单个服务器端端口号（例如端口443）上支持多个应用程序协议时，客户端和服务器需要协商应用程序协议以用于每个连接。希望在不增加客户端和服务器之间的网络往返的情况下完成此协商，因为每次往返都会降低最终用户的体验。此外，允许基于协商的应用协议选择证书将是有利的。
This document specifies a TLS extension that permits the application layer to negotiate protocol selection within the TLS handshake. This work was requested by the HTTPbis WG to address the negotiation of HTTP/2 ([HTTP2]) over TLS; however, ALPN facilitates negotiation of arbitrary application-layer protocols.
本文档指定了一个TLS扩展，该扩展允许应用层在TLS握手中协商协议选择。HTTPbis工作组要求开展这项工作，以解决HTTP/2（[HTTP2]）在TLS上的协商问题；然而，ALPN促进了任意应用层协议的协商。
With ALPN, the client sends the list of supported application protocols as part of the TLS ClientHello message. The server chooses a protocol and sends the selected protocol as part of the TLS ServerHello message. The application protocol negotiation can thus be accomplished within the TLS handshake, without adding network round-trips, and allows the server to associate a different certificate with each application protocol, if desired.
使用ALPN，客户端将支持的应用程序协议列表作为TLS ClientHello消息的一部分发送。服务器选择一个协议并将所选协议作为TLS ServerHello消息的一部分发送。因此，应用协议协商可以在TLS握手内完成，而无需添加网络往返，并且如果需要，允许服务器将不同的证书与每个应用协议相关联。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A new extension type ("application_layer_protocol_negotiation(16)") is defined and MAY be included by the client in its "ClientHello" message.
定义了一种新的扩展类型（“应用程序\层\协议\协商（16）”），客户机可以将其包含在其“ClientHello”消息中。
enum {
application_layer_protocol_negotiation(16), (65535)
} ExtensionType;
enum {
application_layer_protocol_negotiation(16), (65535)
} ExtensionType;
The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value.
“应用程序层协议协商（16）”扩展的“扩展数据”字段应包含“协议名称列表”值。
opaque ProtocolName<1..2^8-1>;
opaque ProtocolName<1..2^8-1>;
struct {
ProtocolName protocol_name_list<2..2^16-1>
} ProtocolNameList;
struct {
ProtocolName protocol_name_list<2..2^16-1>
} ProtocolNameList;
"ProtocolNameList" contains the list of protocols advertised by the client, in descending order of preference. Protocols are named by IANA-registered, opaque, non-empty byte strings, as described further in Section 6 ("IANA Considerations") of this document. Empty strings MUST NOT be included and byte strings MUST NOT be truncated.
“ProtocolNameList”包含客户端公布的协议列表，按首选项降序排列。协议由IANA注册、不透明、非空字节字符串命名，详见本文件第6节（“IANA注意事项”）。不能包含空字符串，也不能截断字节字符串。
Servers that receive a ClientHello containing the "application_layer_protocol_negotiation" extension MAY return a suitable protocol selection response to the client. The server will ignore any protocol name that it does not recognize. A new ServerHello extension type ("application_layer_protocol_negotiation(16)") MAY be returned to the client within the extended ServerHello message. The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension is structured the same as described above for the client "extension_data", except that the "ProtocolNameList" MUST contain exactly one "ProtocolName".
接收包含“应用程序\层\协议\协商”扩展的ClientHello的服务器可以向客户端返回适当的协议选择响应。服务器将忽略它无法识别的任何协议名称。新的ServerHello扩展类型（“应用程序\层\协议\协商（16）”）可以在扩展的ServerHello消息中返回给客户端。“应用程序\层\协议\协商（16）”扩展的“扩展\数据”字段的结构与上述客户机“扩展\数据”的结构相同，只是“协议名列表”必须仅包含一个“协议名”。
Therefore, a full handshake with the "application_layer_protocol_negotiation" extension in the ClientHello and ServerHello messages has the following flow (contrast with Section 7.3 of [RFC5246]):
因此，在ClientHello和ServerHello消息中使用“应用程序层协议协商”扩展的完全握手具有以下流程（与[RFC5246]第7.3节相反）：
Client Server
客户端服务器
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1
图1
* Indicates optional or situation-dependent messages that are not always sent.
* 指示并非始终发送的可选消息或情况相关消息。
An abbreviated handshake with the "application_layer_protocol_negotiation" extension has the following flow:
具有“应用程序\层\协议\协商”扩展的简化握手具有以下流程：
Client Server
客户端服务器
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2
图2
Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant, and only the values in the new handshake messages are considered.
与许多其他TLS扩展不同，此扩展不建立会话的属性，只建立连接的属性。当使用会话恢复或会话票证[RFC5077]时，此扩展先前的内容不相关，只考虑新握手消息中的值。
It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client. In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert.
预计服务器将按优先顺序列出它支持的协议列表，并且仅在客户端支持的情况下才会选择协议。在这种情况下，服务器应该选择它支持的、也是由客户机公布的最优先的协议。如果服务器不支持客户端公布的任何协议，则服务器应发出致命的“无应用程序协议”警报。
enum {
no_application_protocol(120),
(255)
} AlertDescription;
enum {
no_application_protocol(120),
(255)
} AlertDescription;
The protocol identified in the "application_layer_protocol_negotiation" extension type in the ServerHello SHALL be definitive for the connection, until renegotiated. The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange.
在重新协商之前，ServerHello中“应用程序层协议协商”扩展类型中标识的协议应是连接的最终协议。服务器不得使用选定的协议进行响应，并随后使用不同的协议进行应用程序数据交换。
The ALPN extension is intended to follow the typical design of TLS protocol extensions. Specifically, the negotiation is performed entirely within the client/server hello exchange in accordance with the established TLS architecture. The "application_layer_protocol_negotiation" ServerHello extension is intended to be definitive for the connection (until the connection is renegotiated) and is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP or UDP port number is not definitive for the application-layer protocol to be used in the connection. By placing ownership of protocol selection on the server, ALPN facilitates scenarios in which certificate selection or connection rerouting may be based on the negotiated protocol.
ALPN扩展旨在遵循TLS协议扩展的典型设计。具体地说，根据已建立的TLS体系结构，协商完全在客户机/服务器hello交换中执行。“应用程序\层\协议\协商”ServerHello扩展是连接的最终扩展（直到重新协商连接）并以明文形式发送，以便在TCP或UDP端口号对于连接中使用的应用层协议不确定时，允许网元为连接提供区分服务。通过将协议选择的所有权放在服务器上，ALPN促进了证书选择或连接重新路由可能基于协商协议的场景。
Finally, by managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence with respect to the ability to hide the negotiated protocol in advance of establishing the connection. If hiding the protocol is required, then renegotiation after connection establishment, which would provide true TLS security guarantees, would be a preferred methodology.
最后，作为握手的一部分，ALPN通过管理clear中的协议选择，避免了引入关于在建立连接之前隐藏协商协议的能力的错误置信度。如果需要隐藏协议，那么在建立连接后重新协商（这将提供真正的TLS安全保证）将是首选方法。
The ALPN extension does not impact the security of TLS session establishment or application data exchange. ALPN serves to provide an externally visible marker for the application-layer protocol associated with the TLS connection. Historically, the application-layer protocol associated with a connection could be ascertained from the TCP or UDP port number in use.
ALPN扩展不会影响TLS会话建立或应用程序数据交换的安全性。ALPN用于为与TLS连接相关的应用层协议提供外部可见标记。历史上，与连接关联的应用层协议可以通过使用的TCP或UDP端口号确定。
Implementers and document editors who intend to extend the protocol identifier registry by adding new protocol identifiers should consider that in TLS versions 1.2 and below the client sends these identifiers in the clear. They should also consider that, for at least the next decade, it is expected that browsers would normally use these earlier versions of TLS in the initial ClientHello.
通过添加新的协议标识符来扩展协议标识符注册表的实现者和文档编辑器应该考虑在TLS版本1.2和下面的客户端将这些标识符发送到清除中。他们还应该考虑到，至少在未来十年，预计浏览器通常会在最初的CeleTelo中使用这些早期版本的TLS。
Care must be taken when such identifiers may leak personally identifiable information, or when such leakage may lead to profiling or to leaking of sensitive information. If any of these apply to this new protocol identifier, the identifier SHOULD NOT be used in TLS configurations where it would be visible in the clear, and documents specifying such protocol identifiers SHOULD recommend against such unsafe use.
当此类标识符可能泄漏个人识别信息，或此类泄漏可能导致分析或敏感信息泄漏时，必须小心。如果其中任何一项适用于该新协议标识符，则该标识符不应在TLS配置中使用，因为在TLS配置中，该标识符将清晰可见，并且指定此类协议标识符的文件应建议避免此类不安全使用。
The IANA has updated its "ExtensionType Values" registry to include the following entry:
IANA已更新其“ExtensionType值”注册表，以包含以下条目：
16 application_layer_protocol_negotiation
16应用层协议协商
This document establishes a registry for protocol identifiers entitled "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" under the existing "Transport Layer Security (TLS) Extensions" heading.
本文件在现有的“传输层安全（TLS）扩展”标题下建立了一个名为“应用层协议协商（ALPN）协议ID”的协议标识符注册表。
Entries in this registry require the following fields:
此注册表中的条目需要以下字段：
o Protocol: The name of the protocol. o Identification Sequence: The precise set of octet values that identifies the protocol. This could be the UTF-8 encoding [RFC3629] of the protocol name. o Reference: A reference to a specification that defines the protocol.
o 协议：协议的名称。o标识序列：用于标识协议的精确八位字节值集。这可能是协议名称的UTF-8编码[RFC3629]。o引用：对定义协议的规范的引用。
This registry operates under the "Expert Review" policy as defined in [RFC5226]. The designated expert is advised to encourage the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations of the identified protocol.
该登记处按照[RFC5226]中定义的“专家审查”政策运作。建议指定专家鼓励包含对永久性且随时可用的规范的引用，该规范允许创建已识别协议的可互操作实现。
The initial set of registrations for this registry is as follows:
此注册表的初始注册集如下所示：
Protocol: HTTP/1.1 Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") Reference: [RFC7230]
协议：HTTP/1.1标识序列：0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31（“HTTP/1.1”）参考：[RFC7230]
Protocol: SPDY/1
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
Protocol: SPDY/1
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
Protocol: SPDY/2
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2
Protocol: SPDY/2
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2
Protocol: SPDY/3
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
Protocol: SPDY/3
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
This document benefitted specifically from the Next Protocol Negotiation (NPN) extension document authored by Adam Langley and from discussions with Tom Wesselman and Cullen Jennings, both of Cisco.
本文件特别受益于亚当·兰利（Adam Langley）编写的下一个协议协商（NPN）扩展文件，以及与思科公司的汤姆·韦塞尔曼（Tom Wesselman）和卡伦·詹宁斯（Cullen Jennings）的讨论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月。
[HTTP2] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol version 2", Work in Progress, June 2014.
[HTTP2]Belshe，M.，Pain，R.，和M.Thomson，“超文本传输协议版本2”，正在进行的工作，2014年6月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
Authors' Addresses
作者地址
Stephan Friedl Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Stephan Friedl Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: (720)562-6785 EMail: sfriedl@cisco.com
电话：（720）562-6785电子邮件：sfriedl@cisco.com
Andrei Popov Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA
安德烈·波波夫微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: andreipo@microsoft.com
EMail: andreipo@microsoft.com
Adam Langley Google Inc. USA
美国亚当·兰利谷歌公司
EMail: agl@google.com
EMail: agl@google.com
Emile Stephan Orange 2 avenue Pierre Marzin Lannion F-22307 France
埃米尔·斯蒂芬·奥兰治2大道皮埃尔·马津·拉尼翁F-22307法国
EMail: emile.stephan@orange.com
EMail: emile.stephan@orange.com