Internet Engineering Task Force M. Badra INTERNET DRAFT ENST Paris I. Hajjeh ESRGroups Expires: March 2006 October 10, 2005 TLS Multiplexing 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]