Internet Engineering Task Force M. Badra
INTERNET DRAFT LIMOS Laboratory
I. Hajjeh
ESRGroups
Expires: July 2007 January 24, 2007
MTLS: TLS Multiplexing
<draft-badra-hajjeh-mtls-02.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 July 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007). All Rights Reserved.
Abstract
The Transport Layer Security (TLS) standard provides connection
security with mutual authentication, data confidentiality and
integrity, key generation and distribution, and security parameters
negotiation. However, missing from the protocol is a way to
multiplex application data over a single TLS session.
This document defines MTLS, a new TLS sub-protocol running over TLS
(or DTLS) Record protocol. The MTLS design provides application
multiplexing over a single TLS (or DTLS) session. Therefore, instead
of associating a TLS connection with each application, MTLS allows
Badra & Hajjeh Expires July 2007 [Page 1]
Internet-Draft TLS Multiplexing January 2007
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] and [DTLS]) 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) clients and servers MUST establish a TLS (or
DTLS) session for each application they want to run over a transport
layer. However, some applications may agree or be configured to use
the same security policies or parameters (e.g. authentication method
and cipher_suite) and then to share a single TLS session to protect
their exchanges. In this way, this document extends TLS to allow
application multiplexing 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 protocol of a modular nature. 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. Unlike
"ssh-connection" [SSHCON], MTLS can run over unreliable
transport protocols, such as UDP.
o Establishing a single session for a number of applications
-instead of establishing a session per application- 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.
Badra & Hajjeh Expires July 2007 [Page 2]
Internet-Draft TLS Multiplexing January 2007
1.2 Requirements language
The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
are to be interpreted as described in RFC-2119.
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(TBD). It extends also TLS with a new extension type
allowing the negotiation of data multiplexing features.
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 usually starts 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^22-1>;
} data_multiplexing;
struct {
SenderChannelID sender_channel_id;
ReceiverChannelID receiver_channel_id;
uint32 sender_window_length;
uint32 sender_max_packet_length;
uint32 max_packet_length;
ApplicationpProtocolName apn;
} ApplicationLayerProtocol;
opaque SenderChannelID [2];
opaque ReceiverChannelID [2];
Opaque ApplicationpProtocolName<1..2^4>;
Badra & Hajjeh Expires July 2007 [Page 3]
Internet-Draft TLS Multiplexing January 2007
Each channel has its identifier, which is composed of two parts
(sender_channel_id and receiver_channel_id) generated respectively
by the sender and the receiver. During the Handshake phase, the
sender generates the sender_channel_id's value and initializes the
receiver_channel_id to empty field, in which the receiver replies
with a generated receiver_channel_id.
The sender (respectively the receiver) initializes its window_length
with the data length (in octets), specifying how many bytes the
receiver (respectively the sender) can maximally send on the channel
before receiving a new window length (available free space). Each
end of the channel establishes a 'receive buffer' and a 'send
buffer'.
The sender (respectively the receiver) initializes its
max_packet_length with the data length (in octets), specifying the
maximal packet's length in octets the receiver (respectively the
sender) can send on the channel.
How the negotiation of options within an extension is handled is up
to the definition of that extension. Implementations of this
document MAY allow the server to respond with the intersection
between what the client and the server support. However, the server
MAY reply with all the applications it supports, but in this case
the server MUST support at least one application requested by the
client. The sender_channel_id, receiver_channel_id and the
max_packet_size MUST be omitted from the server response for each
application not requested by the client.
Note: if the server (receiver) agrees, the client (sender) SHOULD
establish a single TLS (respectively DTLS) session for all
applications it wishes to run over a single TLS session. In this
case, the sender SHOULD send a data multiplexing extension
containing "ALL" as ApplicationpProtocolName value. The
sender_channel_id, the receiver_channel_id and the max_packet_length
fields SHOULD be omitted. If the receiver is able to negotiate such
a session, it will reply with a list of applications it can accept
to run through a single TLS session. The receiver_channel_id, the
sender_channel_id and the max_packet_length fields SHOULD be
omitted.
However, the client MAY indicate to the server its support of the
data multiplexing extension without determining the application
types it wishes to multiplex. In this case, the client sends an
empty data multiplexing extension. If the server is able of and
willing to use the data multiplexing extension, it MUST reply with
an empty extension of the same type. Once the Handshake is complete,
the client and the server SHOULD establish and manage many
application channels using the requests/responses defined below.
Badra & Hajjeh Expires July 2007 [Page 4]
Internet-Draft TLS Multiplexing January 2007
2.1.1. Opening and closing connections
Once the Handshake is complete, the two entities can start data
multiplexing using a set of requests/responses defined below. All
requests/requests will pass through MTLS layer and are formatted
into MTLS packets, depending on each request/response.
The sender MAY request the opening of many channels. For each
request, the MTLS layer MUST generate and send the following
request:
struct {
uint8 type;
SenderChannelID sender_channel_id;
uint8 identifier;
uint32 sender_window_length;
uint32 sender_max_packet_length;
opaque source_address_machine<4..7>;
opaque source_port[2];
opaque destination_address_machine<4..7>;
opaque destination_port[2];
ApplicationpProtocolName apn;
} RequestEstablishmentChannel;
The field "type" specifies the MTLS packet type (types are
summarized below), max_packet_length and the sender_channel_id are
used as previously described. The "source_address_machine" MAY carry
either the numeric IP address or the domain name of the host from
where the application originates the data multiplexing request and
the "port" is the port on the host from where the connection
originated.
The "destination_address_machine" specify the TCP/IP host and port
where the recipient should connect the channel.
The "identifier" is a unique value generated locally by the sender
of the request. It is used to maintain a mapping between the
originator of the request (the application host) and the data to be
received/sent through MTLS channel.
Implementation note: the term "identifier" is used to don't send for
every MTLSPlaintext the "source_address_machine",
"destination_address_machine", source_port and destination_port. For
receiver who receives a RequestEstablishmentChannel it will
associate this identifier to the TCP/IP host and port from where it
connects to the destination application.
The receiver decides whether it can open the channel, and replies
with one of the following messages:
Badra & Hajjeh Expires July 2007 [Page 5]
Internet-Draft TLS Multiplexing January 2007
struct {
uint8 type;
SenderChannelID sender_channel_id;
ReceiverChannelID receiver_channel_id;
uint8 identifier;
uint32 receiver_window_length;
uint32 max_packet_length;
} RequestEstablishmentSuccess;
The "identifier" field contains the same value sent in the
RequestEstablishmentChannel.
The "identifier" field is omitted from ApplicationLayerProtocol and
in this case, it is equal to 1.
struct {
uint8 type;
SenderChannelID sender_channel_id;
uint8 identifier;
opaque error<0..2^16>;
} RequestEchecChannel;
The field "error" conveys a description of the error.
The following packet MAY be sent to notify the receiver that the
sender will not send any more data on this channel and that any data
received after a closure request will be ignored. The sender of the
closure request MAY close its 'receive buffer' without waiting for
the receiver's response. However, the receiver MUST respond with a
confirmation of the closure and close down the channel immediately,
discarding any pending writes.
struct {
uint8 type;
SenderChannelID sender_channel_id;
ReceiverChannelID receiver_channel_id;
uint8 identifier;
} CloseChannel;
struct {
uint8 type;
SenderChannelID sender_channel_id;
ReceiverChannelID receiver_channel_id;
uint8 identifier;
} ConfirmationCloseChannel;
2.2 MTLS sub-protocol
The structure of the MTLS packet is described below. The channel_id
value depends on the originator of the packet; for received
Badra & Hajjeh Expires July 2007 [Page 6]
Internet-Draft TLS Multiplexing January 2007
(respectively submitted) packets, it conveys the sender_channel_id
(respectively receiver_channel_id). The length conveys the data
length of the current packet.
Each entity maintains its max_packet_length that is originally
initialized (during the channel establishment or during the
handshake phase) to a value not bigger than the maximum size of this
entity's 'receive buffer'. For each received packet, the entity MUST
subtract the packet's length from the max_packet_length. The result
is always positive since the packet's length is always less than or
equal to the current max_packet_length.
The free space of the 'receive buffer' MAY increase in length.
Consequently, the entity MUST inform the other end about this
increase, allowing the other entity to send packet with length
bigger than the old max_packet_length but smaller or equal than the
new value.
The entity MAY indicate this increase by sending an Acknowledgment
packet. The Acknowledgment packet carries the available free space
(free_space field in octets) the receiver of that packet can send on
the channel before receiving a new window length.
If the length of the 'receive buffer' does not change,
Acknowledgment packet will never be sent.
In the case where the 'receive buffer' of an entity fills up, the
other entity MUST wait for an Acknowledgment packet before sending
any more MTLSPlaintext packets.
struct {
uint8 type;
uint16 channel_id;
uint8 identifier;
uint32 length;
opaque data[MTLSPlaintext.length];
} MTLSPlaintext;
struct {
uint8 type;
uint16 channel_id; // of the receiver of that packet
uint32 free_space;
} Acknowledgment;
Implementation note: as cited before, for MTLS entity who receives a
RequestEstablishmentChannel it will maintain a mapping between the
"identifier", "source_address_machine",
"destination_address_machine", source_port and destination_port, and
the host address and port from where the host connects to the
destination application. Thus, for each data received on the (e.g.
Badra & Hajjeh Expires July 2007 [Page 7]
Internet-Draft TLS Multiplexing January 2007
TCP/IP) host and port from where the receiver connects to the
destination application, the receiver will resolve the mapping to
find the "identifier". Upon finding the "identifier", the receiver
will format an MTLSPlaintext and then send the data through the
secure session, using all required parameters returned during the
mapping resolution. Upon reception, the MTLS entity will repeat the
same resolution procedure to identify the host and port of the
request generator.
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.
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 channel identifier and the
length value.
2.3 MTLS Message Types
RequestEstablishmentChannel 0x01
RequestEstablishmentSuccess 0x02
RequestEchecChannel 0x03
CloseChannel 0x04
ConfirmationCloseChannel 0x05
MTLSPlaintext 0x06
Acknowledgment 0x07
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 channel or a connection of an
arbitrary application occurs, the secure session MUST NOT be
resumed.
IANA Considerations
This section provides guidance to the IANA regarding registration of
values related to the TLS protocol.
There are name spaces that require registration: the mtls content
type, the data_multiplexing extension, and the MTLS message types.
Badra & Hajjeh Expires July 2007 [Page 8]
Internet-Draft TLS Multiplexing January 2007
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 4346, April 2006.
[DTLS] Rescorla, E., Modadugu, N., "Datagram Transport Layer
Security", RFC 4347, April 2006.
[TLSv1.1] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
RFC 4346, April 200P.
[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.
[SSHCON] Lonvick, C., "SSH Connection Protocol", RFC 4254, January
2005.
Author's Addresses
Mohamad Badra
LIMOS Laboratory - UMR (6158), CNRS
France Email: badra@isima.fr
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
Badra & Hajjeh Expires July 2007 [Page 9]
Internet-Draft TLS Multiplexing January 2007
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 (2007). 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 July 2007 [Page 10]