Network Working Group S.F. Friedl
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Popov
Expires: October 27, 2013 Microsoft Corp.
A. Langley
Google Inc.
E. Stephan
France Telecom - Orange
April 25, 2013
Transport Layer Security (TLS) Application Layer Protocol Negotiation
Extension
draft-ietf-tls-applayerprotoneg-01
Abstract
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/IP 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 session.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Friedl, et al. Expires October 27, 2013 [Page 1]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
(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.
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 . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Increasingly, application layer protocols are encapsulated in the TLS
security 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.
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.
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 ([RFC2616], [I-D.ietf-httpbis-http2]) over TLS, however
ALPN facilitates negotiation of arbitrary application layer
protocols.
Friedl, et al. Expires October 27, 2013 [Page 2]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
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.
2. Requirements Language
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].
3. Application Layer Protocol Negotiation
3.1. The Application Layer Protocol Negotiation Extension
A new extension type ("application_layer_protocol_negotiation(16)")
is defined and MAY be included by the client in its "ClientHello"
message.
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.
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. Implementations
MUST ensure that an empty string is not included and that no byte
strings are truncated.
Experimental protocol names, which are not registered by IANA, will
start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp").
Friedl, et al. Expires October 27, 2013 [Page 3]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
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
SHALL be structured the same as described above for the client
"extension_data", except that the "ProtocolNameList" MUST contain
exactly one "ProtocolName".
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]):
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
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
Friedl, et al. Expires October 27, 2013 [Page 4]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 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.
3.2. Protocol Selection
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.
enum {
no_application_protocol(120),
(255)
} AlertDescription;
The "no_application_protocol" fatal alert is only defined for the
"application_layer_protocol_negotiation" extension and MUST NOT be
sent unless the server has received a ClientHello message containing
this extension.
The protocol identified in the
"application_layer_protocol_negotiation" extension type in the
ServerHello SHALL be definitive for the connection. The server SHALL
NOT respond with a selected protocol and subsequently use a different
protocol for application data exchange.
4. Design Considerations
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 and is sent in plaintext
to permit network elements to provide differentiated service for the
Friedl, et al. Expires October 27, 2013 [Page 5]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
connection when the TCP/IP 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.
Finally, by managing protocol selection in the clear as part of the
handshake, ALPN avoids introducing false confidence with respect to
the 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.
A namespace will be assigned for experimental protocols, comprising
byte strings which start with the following sequence of bytes: 0x65,
0x78, 0x70 ("exp"). Assignments in this namespace do not need IANA
registration.
5. Security Considerations
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/IP port number in use.
6. IANA Considerations
The IANA has updated its Registry of TLS ExtensionType Values to
include the following entry:
- 16 application_layer_protocol_negotiation
This document also requires the IANA to create a registry of
Application Layer Protocol Negotiation protocol byte strings,
initially containing the following entries:
- "http/1.1": HTTP/1.1 [RFC2616];
- "http/2.0": HTTP/2.0 [I-D.ietf-httpbis-http2];
- "spdy/1": (obsolete) SPDY version 1;
- "spdy/2": SPDY version 2;
- "spdy/3": SPDY version 3.
Friedl, et al. Expires October 27, 2013 [Page 6]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
We propose that this new registry be created in a new page entitled:
"Application Layer Protocol Negotiation (ALPN) Protocol IDs" beneath
the existing heading of "Transport Layer Security (TLS)".
7. Acknowledgements
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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
8.2. Informative References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., Thomson, M., and A. Melnikov,
"Hypertext Transfer Protocol version 2.0", draft-ietf-
httpbis-http2-02 (work in progress), April 2013.
[I-D.mbelshe-httpbis-spdy]
Belshe, M. and R. Peon, "SPDY Protocol", draft-mbelshe-
httpbis-spdy-00 (work in progress), February 2012.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
Authors' Addresses
Friedl, et al. Expires October 27, 2013 [Page 7]
Internet-Draft TLS App Layer Protocol Negotiation Ext April 2013
Stephan Friedl
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: (720)562-6785
Email: sfriedl@cisco.com
Andrei Popov
Microsoft Corp.
One Microsoft Way
Redmond, WA 98052
USA
Email: andreipo@microsoft.com
Adam Langley
Google Inc.
USA
Email: agl@google.com
Emile Stephan
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange.com
Friedl, et al. Expires October 27, 2013 [Page 8]