[要約] RFC 7301は、Transport Layer Security (TLS) Application-Layer Protocol Negotiation (ALPN) Extensionに関する文書です。この拡張機能の主な目的は、TLSハンドシェイクの一部としてクライアントとサーバー間でアプリケーション層のプロトコルを効率的にネゴシエートするメカニズムを提供することです。これにより、特にHTTPSを使用するWebサーバーでHTTP/2やその他のプロトコルを選択する際の遅延を減らすことができます。ALPNは、以前のプロトコルネゴシエーションメカニズムであるNPN（Next Protocol Negotiation）を置き換える形で導入されました。関連するRFCには、TLSプロトコルを定義するRFC 5246（TLS 1.2）や、HTTP/2を定義するRFC 7540などがあります。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
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. 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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
1つのサーバー側ポート番号（ポート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拡張を指定しています。この作業は、TLSを介したHTTP / 2（[HTTP2]）のネゴシエーションに対処するためにHTTPbis WGから要求されました。ただし、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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
A new extension type ("application_layer_protocol_negotiation(16)") is defined and MAY be included by the client in its "ClientHello" message.
新しい拡張タイプ（ "application_layer_protocol_negotiation（16）"）が定義されており、クライアントがその「ClientHello」メッセージに含めることができます（MAY）。
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.
（ "application_layer_protocol_negotiation（16）"）拡張の "extension_data"フィールドには、 "ProtocolNameList"値が含まれている必要があります（SHALL）。
opaque ProtocolName<1..2^8-1>;
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"には、クライアントによってアドバタイズされたプロトコルのリストが、優先度の高い順に含まれています。このドキュメントのセクション6（「IANAに関する考慮事項」）でさらに説明されているように、プロトコルは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".
「application_layer_protocol_negotiation」拡張を含むClientHelloを受信するサーバーは、適切なプロトコル選択応答をクライアントに返します。サーバーは、認識しないプロトコル名を無視します。新しいServerHello拡張タイプ（ "application_layer_protocol_negotiation（16）"）は、拡張されたServerHelloメッセージ内でクライアントに返される場合があります。 （ "application_layer_protocol_negotiation（16）"）拡張の "extension_data"フィールドは、 "ProtocolNameList"に1つの "ProtocolName"が含まれていなければならないことを除いて、クライアント "extension_data"について上記で説明したものと同じ構造です。
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メッセージの「application_layer_protocol_negotiation」拡張機能を使用した完全なハンドシェイクは、次のフローになります（[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
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:
「application_layer_protocol_negotiation」拡張を使用した短縮ハンドシェイクのフローは次のとおりです。
Client Server
クライアントサーバー
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.
サーバーは、サポートするプロトコルのリストを優先順に並べ、クライアントがサポートする場合にのみプロトコルを選択することが期待されています。その場合、サーバーは、サーバーがサポートする最も優先度の高いプロトコルを選択する必要があります（SHOULD）。これもクライアントによってアドバタイズされます。サーバーがクライアントがアドバタイズするプロトコルをサポートしない場合、サーバーは致命的な「no_application_protocol」アラートで応答する必要があります（SHALL）。
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の「application_layer_protocol_negotiation」拡張タイプで識別されるプロトコルは、再ネゴシエーションされるまで、接続の決定的なものである必要があります（SHALL）。サーバーは、選択されたプロトコルで応答しないものとし（SHALL NOT）、その後、アプリケーションデータ交換に別のプロトコルを使用します。
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交換内で実行されます。 「application_layer_protocol_negotiation」ServerHello拡張は、接続の最終的なものであることが意図されており（接続が再ネゴシエーションされるまで）プレーンテキストで送信され、TCPまたはUDPポート番号がアプリケーションの最終的なものでない場合に、ネットワーク要素が接続に対して差別化されたサービスを提供できるようにします。接続で使用される-layerプロトコル。サーバー上にプロトコル選択の所有権を置くことにより、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は、接続を確立する前に、ネゴシエートされたプロトコルを非表示にする機能に関して誤った信頼をもたらすことを回避します。プロトコルを非表示にする必要がある場合は、接続確立後の再ネゴシエーションが真の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以前では、クライアントがこれらの識別子を平文で送信することを考慮する必要があります。また、少なくとも次の10年間は、ブラウザが通常、初期のClientHelloでこれらの以前のバージョンの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構成で使用してはならず（SHOULD NOT）、それは平文で表示され、そのようなプロトコル識別子を指定するドキュメントはそのような安全でない使用に対して推奨すべきです（SHOULD）。
The IANA has updated its "ExtensionType Values" registry to include the following entry:
IANAは「ExtensionType値」レジストリを更新して、次のエントリを含めました。
16 application_layer_protocol_negotiation
16 application_layer_protocol_negotiation
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/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
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が作成したNext Protocol Negotiation（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、「RFCで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、「The Transport Layer Security（TLS）Protocol Version 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、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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.、Peon、R。、およびM. Thomson、「Hypertext Transfer Protocol version 2」、Work in Progress、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、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、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 West Tasman Drive San Jose、CA 95134 USA
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
アンドレイポポフマイクロソフトOne Microsoft Way Redmond、WA 98052 USA
EMail: andreipo@microsoft.com
Adam Langley Google Inc. USA
Adam Langley Google Inc.米国
EMail: agl@google.com
Emile Stephan Orange 2 avenue Pierre Marzin Lannion F-22307 France
エミールステファンオレンジ2アベニューピエールマルザンラニオンF-22307フランス
EMail: emile.stephan@orange.com