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]