Internet Engineering Task Force                                M. Badra
INTERNET DRAFT                                               ENST Paris
                                                              I. Hajjeh
Expires: March 2006                                    October 10, 2005

                             TLS Multiplexing


   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   TLS is the famous protocol that provides authentication and data
   protection for communication between two entities. However, missing
   from the protocol is a way to multiplex application data over the
   same TLS session.

   This document defines a new TLS sub-protocol called MTLS running
   over TLS (or DTLS) Record protocol. The MTLS design provides
   application multiplexing over a single TLS session. Instead of
   associating a TLS connection with each application, MTLS allows

Badra & Hajjeh               Expires March 2006                [Page 1]

INTERNET-DRAFT                TLS Multiplexing             October 2005

   several applications to protect their exchanges over a single TLS

1 Introduction

   SMTP over TLS [SMTPTLS], HTTP over TLS [HTTPTLS], POP over TLS and
   IMAP over TLS [POPTLS] are examples of securing, respectively, SMTP,
   HTTP, POP and IMAP data exchanges using the TLS protocol [TLS].

   TLS ([TLS], [TLSv1.1]) is the most deployed security protocol for
   securing exchanges, authenticating entities and for generating and
   distributing cryptographic keys. However, what is missing from the
   protocol is the way to multiplex application data over the same TLS

   Actually, TLS (or DTLS [DTLS]) clients and servers MUST establish a
   TLS (or DTLS) session for each application they want to run over TCP
   (or UDP). However, some applications may agree or be configured to
   use the same security policies or parameters (f.g. authentication
   method and cipher_suite) and then to share one and only one TLS
   session to protect their exchanges. In this way, this document
   extends TLS to allow an application multiplexing functionality over

   The document motivations included:

   o   TLS is application protocol-independent. Higher-level protocol
       can operate on top of the TLS protocol transparently.

   o   TLS is a modular nature protocol. Since TLS is developed in four
       independent protocols, the approach defined in this document can
       be added by extending the TLS protocol and with a total
       reuse of pre-existing TLS infrastructures and implementations.

   o   It provides a secure VPN tunnel over a transport layer.

   o   Establishing a single session for a number of applications
       reduces resource consumption, latency and messages flow that are
       associated with executing simultaneous TLS sessions.

   o   TLS can not forbid an intruder to analyze the traffic and cannot
       protect data from inference. Thus, the intruder can know the
       type of application data transmitted through the TLS session.
       However, the extension defined in this document allows, by its
       design, data protection against inference.

1.2 Requirements language

   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
   are to be interpreted as described in RFC-2119.

Badra & Hajjeh               Expires March 2006                [Page 2]

INTERNET-DRAFT                TLS Multiplexing             October 2005

2 TLS multiplexing overview and considerations

   This document defines a new TLS sub-protocol called Multiplexing TLS
   (MTLS) to handle data multiplexing, and it specifies the content
   type mtls(26) for this sub-protocol.

   MTLS communication can take place over TCP or UDP. The default port
   is TBC, but other ports can be used.

2.1 Handshake

   Based on the TLS Extensions [TLSExt], a client and a server can, in
   an ordinary TLS handshake, negotiate the future use of MTLS. If the
   client does attempt to initiate a TLS connection using MTLS with a
   server that does not support it, it will be automatically alerted.
   For servers aware of MTLS but not wishing to use it, it will
   gracefully revert to an ordinary TLS handshake or stop the

   The negotiation starts usually with the client determining whether
   the server is capable of and willing to use MTLS or not. In order to
   allow a TLS client to negotiate the application multiplexing
   functionality, a new extension type SHOULD be added to the Extended
   Client and Extended Server Hello messages.

   This document defines an extension of type
   "application_layer_protocol". The "extension_data" field of this
   extension contains a "data_multiplexing", where:

       Struct {
              ApplicationLayerProtocol alp_list<0..2^20-1>;
           } data_multiplexing;

       struct {
              ApplicationpProtocolName apn;
              select (Version)
                 case { 3, 1 }:// TLS Version 1.0
                   TCPPort tcp_port;
                 case { 3, 2 }:// TLS Version 1.1
                   TCPPort tcp_port;
                 case { 254, 255 }:// Datagram TLS Version 1.0
                   UDPPort udp_port;
           } ApplicationLayerProtocol;

       opaque TCPPort[2];
       opaque UDPPort[2];
       Opaque ApplicationpProtocolName<1..16>;

   tcp_port (respectively udp_port) is the application port number at
   the server side. The client MUST use as destination ports, the TCP
   (respectively UDP) port numbers that are assigned by IANA.
Badra & Hajjeh               Expires March 2006                [Page 3]

INTERNET-DRAFT                TLS Multiplexing             October 2005

   Application layer running on unreliable links MUST be negotiated in
   a separate session using the DTLS Handshake [DTLS].

   Note: if the server agrees, the client SHOULD establish a single TLS
   (respectively DTLS) session for all applications it wishes to run
   over TCP (respectively UDP). In this case, the client SHOULD send a
   data multiplexing extension containing "ALL" as
   ApplicationpProtocolName value and "NULL" as TCPPort (or UDPPort)
   value. If the server is not able to negotiate such session, it
   replays with a list of applications (names and ports) it can accept
   to run through a single TLS session, falls back on an ordinary TLS
   handshake or stops the negotiation.

  2.1.1. Multi-connections during application session

   Once the establishment is complete, the client MAY open many
   connections related to an arbitrary application over the secure
   session. In this case, the application client MUST locally reserve a
   port number for each connection. Next, the client application sends
   its request to the MTLS client which is listening on the TBC port
   number. This latter will check if it has an established secure
   session with the requested hostname (the server). If then it checks
   if the application protocol name has been accepted to run over MTLS,
   before sends the request to the MTLS server.

2.2 MTLS sub-protocol

   The structure of MTLS packet is described below. The first 8 bytes
   of the packet represent the source and the destination ports of the
   connexion, and the length contains the length of the MTLS data.

   enum {
        change_cipher_spec(20), alert(21), handshake(22),
        application_data(23), mtls(26), (255)
     } ContentType;

   struct {
          uint32 SourcePort
          uint32 DestinationPort
          uint16 length;
          opaque data[MTLSPlaintext.length];
       } MTLSPlaintext;

   The TLS Record Layer receives data from MTLS, supposes it as
   uninterpreted data and applies the fragmentation and the
   cryptographic operations on it, as defined in [TLS].

   Note: multiple MTLS fragments MAY be coalesced into a single
   TLSPlaintext record.

Badra & Hajjeh               Expires March 2006                [Page 4]

INTERNET-DRAFT                TLS Multiplexing             October 2005

   Received data is decrypted, verified, decompressed, and reassembled,
   then delivered to MTLS sub-protocol. Next, the MTLS sends data to
   the appropriate application using the source and destination port
   numbers and the length value.

Security Considerations

   Security issues are discussed throughout this document, and in
   [TLS], [TLSv1.1], [DTLS] and [TLSEXT] documents.

   If a fatal error related to a connexion of an arbitrary application
   is occurred, the secure session MUST NOT be resumed.

IANA Considerations

   This document requires IANA to allocate the TBC TCP and UDP port


   This document defined TLS Multiplexing for applications running over
   IP. Beyond that definition, generic options may be added to future
   versions of the current document.


   [TLS]      Dierks, T., et. al., "The TLS Protocol Version 1.0", RFC
              2246, January 1999.

   [TLSExt]   Blake-Wilson, S., et. al., "Transport Layer Security
             (TLS) Extensions", RFC 3546, June 2003.

   [DTLS]     Rescorla, E., Modadugu, N., "Datagram Transport Layer
              Security", draft-rescorla-dtls-05.txt, June 2004.

   [TLSv1.1]  Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
              draft-ietf-tls-rfc2246-bis-13.txt, June 2005

   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              TLS", RFC 2487, January 1999.

   [HTTPTLS]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [POPTLS]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
              2595, June 1999.

Author's Addresses

   Mohamad Badra
   ENST Paris
   France                    Email:

Badra & Hajjeh               Expires March 2006                [Page 5]

INTERNET-DRAFT                TLS Multiplexing             October 2005

   Ibrahim Hajjeh
   ESRGroups, Security WG
   France                    Email:

   Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the IETF's procedures with respect to rights in IETF
   Documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-

   Disclaimer of Validity

   This document and the information contained herein are provided on

   Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.
Badra & Hajjeh               Expires March 2006                [Page 6]