Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Stephan Friedl , Andrei Popov 
Last updated 2013-01-28
Replaced by RFC 7301, RFC 7301
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          S. Friedl
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                A. Popov
Expires: August 1, 2013                                  Microsoft Corp.
                                                        January 28, 2013

 Transport Layer Security (TLS) Application Layer Protocol Negotiation


   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

   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 August 1, 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
   ( 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
     1.1.  Requirements Language
     1.2.  Application Layer Protocol Negotiation Extension
     1.3.  Protocol Selection
     1.4.  Design Considerations
     1.5.  Security Considerations
     1.6.  IANA Considerations
   2.  Acknowledgements
   3.  References
     3.1.  Normative References
     3.2.  Informative References
   Authors' Addresses

1.  Introduction

   Currently, the Next Protocol Negotiation extension (NPN) is used to
   establish a SPDY [spdy] protocol session within a TLS RFC 5246
   [RFC5246] session on port 443.  NPN is not specific to SPDY and can
   be used to negotiate sessions for a wide variety of protocols within
   the TLS handshake.

   NPN seeks to provide a reliable mechanism for application developers
   to establish secure sessions for arbitrary protocols without
   interference from firewalls, HTTP proxies and MITM proxies.  It
   addresses this goal by introducing a protocol negotiation process
   into the TLS handshake under the constraints that no additional
   roundtrips be added to the handshake and that the final protocol
   selection be opaque to the network carrying the TLS session.  Within
   the NPN extension, it is the server that first generates and
   transmits an offer of supported protocols to the client.  The offer
   is sent as part of the TLS ServerHello message before the
   [ChangeCipherSpec] subprotocol has been started, therefore the list
   of protocols supported by the server is transmitted in plaintext.
   The client chooses a protocol which may or may not appear in the
   offer from the server and then responds with the definitive protocol
   selection answer.  The client response is sent after the
   [ChangeCipherSpec] subprotocol has been initiated, so the protocol
   selected is encrypted in the client response.

   In many other application layer protocol negotiation processes, it is
   the client that first sends an offer of protocols it supports to the
   server.  The server then selects the protocol to be used in the
   session and includes this answer in the response.  RFC 3264 [RFC3264]
   describes a SDP based offer/answer model which is not proscriptive in
   terms of which party generates the offer, however in practice it is
   typically the client generating the offer and the server replying
   with the answer.  This permits the server to act as the definitive
   entity for selection of the application layer protocol.

   This draft proposes an alternative formulation of the NPN protocol
   which 1) brings the offer/answer negotiation into alignment with the
   majority of other application layer protocol negotiation standards,
Show full document text