path: root/doc/protocol/draft-badra-hajjeh-mtls-00.txt

Internet Engineering Task Force                                M. Badra 
INTERNET DRAFT                                               ENST Paris 
                                                              I. Hajjeh 
                                                              ESRGroups 
Expires: March 2006                                    October 10, 2005 
    
                             TLS Multiplexing  
                     <draft-badra-hajjeh-mtls-00.txt> 
    
    
Status 
    
   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 
   Drafts. 
    
   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 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html  
    
   This Internet-Draft will expire on March 10, 2006. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2005).  
    
Abstract 
    
   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 
   session. 
    
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 
   session. 
    
   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 
   TLS. 
    
   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 
   negotiation. 
    
   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 
   numbers. 
    
Acknowledgment 
    
   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. 
    
References 
    
   [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: Mohamad.Badra@enst.fr 
 
Badra & Hajjeh               Expires March 2006                [Page 5] 
INTERNET-DRAFT                TLS Multiplexing             October 2005 
 
    
   Ibrahim Hajjeh 
   ESRGroups, Security WG 
   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
    
   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 
   at http://www.ietf.org/ipr. 
    
   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-
   ipr@ietf.org. 
    
   Disclaimer of Validity 
    
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
   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. 
    
   Acknowledgment 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
Badra & Hajjeh               Expires March 2006                [Page 6]