One document matched: draft-ietf-tls-applayerprotoneg-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tls-applayerprotoneg-05" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="TLS App Layer Protocol Negotiation Ext">Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Stephan Friedl" initials="S.F."
surname="Friedl">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>(720)562-6785</phone>
<email>sfriedl@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Andrei Popov" initials="A."
surname="Popov">
<organization>Microsoft Corp.</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<!-- Reorder these if your country does things differently -->
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country>
</postal>
<email>andreipo@microsoft.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Adam Langley" initials="A."
surname="Langley">
<organization>Google Inc.</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>agl@google.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Emile Stephan" initials="E."
surname="Stephan">
<organization>Orange</organization>
<address>
<postal>
<street>2 avenue Pierre Marzin</street>
<!-- Reorder these if your country does things differently -->
<city>Lannion</city>
<code>F-22307</code>
<country>France</country>
</postal>
<email>emile.stephan@orange.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>draft</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document describes a Transport Layer Security (TLS) extension for application layer protocol
negotiation within the TLS handshake. For instances in which the TLS connection is established over
a well known TCP or UDP port not associated with the desired application layer protocol, this extension
allows the application layer to negotiate which protocol will be used within the TLS connection.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Increasingly, application layer protocols are encapsulated in the TLS security protocol <xref target="RFC5246"/>.
This encapsulation enables applications to use the existing, secure communications links already present on
port 443 across virtually the entire global IP infrastructure.</t>
<t>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.</t>
<t>This document specifies a TLS extension which 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 version
(<xref target="RFC2616"/>, <xref target="I-D.ietf-httpbis-http2"/>) over TLS, however ALPN facilitates negotiation
of arbitrary application layer protocols.</t>
<t>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.</t>
</section>
<section title="Requirements Language">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Application Layer Protocol Negotiation">
<section title="The Application Layer Protocol Negotiation Extension">
<t>
A new extension type ("application_layer_protocol_negotiation(16)") is defined and MAY be included by the client in
its "ClientHello" message.
</t>
<figure>
<artwork align="left"><![CDATA[
enum {
application_layer_protocol_negotiation(16), (65535)
} ExtensionType;
]]></artwork>
</figure>
<t>The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL contain a "ProtocolNameList" value.</t>
<figure>
<artwork align="left"><![CDATA[
opaque ProtocolName<1..2^8-1>;
struct {
ProtocolName protocol_name_list<2..2^16-1>
} ProtocolNameList;
]]></artwork>
</figure>
<t>"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
.</t>
<t>Servers that receive a client hello 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".
</t>
<t>
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 <xref target="RFC5246"/>):
</t>
<figure align="center" anchor="full_handshake">
<artwork align="left"><![CDATA[
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
]]></artwork>
</figure>
<t>
An abbreviated handshake with the "application_layer_protocol_negotiation"
extension has the following flow:
</t>
<figure align="center" anchor="abbreviated_handshake">
<artwork align="left"><![CDATA[
Client Server
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
]]></artwork>
</figure>
<t>Unlike many other TLS extensions, this extension does not establish properties of the session,
only of the connection. When session resumption or session tickets <xref target="RFC5077"/>
are used, the previous contents of this extension are irrelevant and only the values in the new
handshake messages are considered.</t>
</section>
<section title="Protocol Selection">
<t>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 it supports which 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.</t>
<figure>
<artwork align="left"><![CDATA[
enum {
no_application_protocol(120),
(255)
} AlertDescription;
]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Design Considerations">
<t>
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
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.
</t>
<t>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.
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t> 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, and 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.
</t>
<t>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.
</t>
</section>
<section title="IANA Considerations">
<t>The IANA has updated its Registry of TLS ExtensionType Values to include the following entry:
<list style="empty">
<t>16 application_layer_protocol_negotiation</t>
</list>
</t>
<t>This document establishes a registry for protocol identifiers entitled "Application Layer Protocol Negotiation (ALPN)
Protocol IDs" under the existing "Transport Layer Security (TLS)" heading.</t>
<t>Entries in this registry require the following fields:
<list style="symbols">
<t>Protocol: The name of the protocol.</t>
<t>Identification Sequence: The precise set of octet values that identifies the protocol.
This could be the UTF-8 encoding <xref target="RFC3629"/> of the protocol name.</t>
<t>Specification: A reference to a specification that defines the protocol.</t>
</list>
</t>
<t>This registry operates under the "Expert Review" policy as defined in <xref target="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.</t>
<t>An initial set of registrations for this registry follows:
<list style="empty">
<t>Protocol: HTTP/1.1</t>
<t>Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")</t>
<t>Specification: http://tools.ietf.org/html/rfc2616</t>
</list>
<list style="empty">
<t>Protocol: SPDY/1</t>
<t>Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")</t>
<t>Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1</t>
</list>
<list style="empty">
<t>Protocol: SPDY/2</t>
<t>Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")</t>
<t>Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2</t>
</list>
<list style="empty">
<t>Protocol: SPDY/3</t>
<t>Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")</t>
<t>Specification: http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3</t>
</list>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
This document benefitted specifically from the NPN extension draft authored by Adam Langley and
from discussions with Tom Wesselman and Cullen Jennings both of Cisco.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC5246;
&RFC2616;
&RFC3629;
&RFC5226;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC5077;
<!-- A reference written by by an organization not a person. -->
<?rfc include="reference.I-D.ietf-httpbis-http2.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:32:18 |