--- /dev/null
+
+
+TLS Working Group M. Badra
+Internet-Draft LIMOS Laboratory
+Intended status: Standards Track I. Hajjeh
+Expires: April 27, 2008 ESRGroups
+ October 25, 2007
+
+
+ MTLS: TLS Multiplexing
+ <draft-badra-hajjeh-mtls-03.txt>
+
+Status of this Memo
+
+ 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 April 27, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+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 April 2008 [Page 1] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+ several applications to protect their exchanges over a single TLS
+ session.
+
+1. Introduction
+
+ HTTP over TLS [HTTPTLS], POP over TLS and IMAP over TLS [POPTLS] are
+ examples of securing, respectively HTTP, POP and IMAP data exchanges
+ using the TLS protocol [TLS].
+
+ TLS ([TLS], [DTLS]) is the most deployed security protocol for
+ securing exchanges, for 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 April 2008 [Page 2] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+1.2. Requirements language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [KEYWORDS].
+
+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(TBA). It extends also TLS with a new extension type (TBA)
+ allowing the negotiation of data multiplexing features.
+
+2.1. Handshake
+
+ This document defines an extension of type "data_multiplexing". The
+ "extension_data" field of this extension is zero-length.
+
+ 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.
+
+ 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.
+
+2.1.1. Opening and closing connections
+
+ Once the Handshake is complete, both the client and the server 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
+ channel, the MTLS layer generates and sends the following request:
+
+
+
+
+
+Badra & Hajjeh Expires April 2008 [Page 3] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+ struct {
+ uint8 type;
+ opaque sender_channel_id[2];
+ 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];
+ } RequestEstablishmentChannel;
+
+ The field "type" specifies the MTLS packet type (types are
+ summarized below), the "max_packet_length" and the
+ "sender_channel_id" are used as described below. 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 sender initializes its "window_length" with the data length (in
+ octets), specifying how many bytes the receiver 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 initializes its "max_packet_length" with the data length
+ (in octets), specifying the maximal packet's length in octets the
+ receiver can send on the channel.
+
+ The "destination_address_machine" and "destination_port" specify the
+ TCP/IP host and port where the recipient should connect the channel.
+ The "destination_address_machine" MAY be either a domain name or a
+ numeric IP address.
+
+ The receiver decides whether it can open the channel, and replies
+ with one of the following messages:
+
+ struct {
+ uint8 type;
+ opaque sender_channel_id[2];
+ opaque receiver_channel_id[2];
+ uint32 receiver_window_length;
+ uint32 max_packet_length;
+ } RequestEstablishmentSuccess;
+
+ struct {
+ uint8 type;
+ opaque sender_channel_id[2];
+ opaque error<0..2^16>;
+ } RequestEchecChannel;
+
+
+Badra & Hajjeh Expires April 2008 [Page 4] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+ The field "error" conveys a description of the error.
+
+ If an error occurs at the MTLS layer, the established secure session
+ is still valid and no alert of any type is sent by the TLS Record.
+
+ Each MTLS channel has its identifier computed as:
+
+ channel_id = sender_channel_id" + "receiver_channel_id
+
+ Where "+" indicates concatenation.
+
+ 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;
+ opaque channel_id[4];
+ } CloseChannel;
+
+ struct {
+ uint8 type;
+ opaque channel_id[4];
+ } ConfirmationCloseChannel;
+
+2.2. MTLS sub-protocol
+
+ The structure of the MTLS packet is described below. The
+ "sender_channel_id" and "receiver_channel_id" are the same gererated
+ during the connection establishment. The length conveys the data
+ length of the current packet.
+
+ Each entity maintains its "max_packet_length" (that is originally
+ initialized during the connection establishment) 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.
+
+
+
+Badra & Hajjeh Expires April 2008 [Page 5] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+ 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;
+ opaque channel_id[4];
+ uint32 length;
+ opaque data[MTLSPlaintext.length];
+ } MTLSPlaintext;
+
+ struct {
+ uint8 type;
+ opaque channel_id[4];
+ uint32 free_space;
+ } Acknowledgment;
+
+ 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]. The type is set
+ to mtls(TBA).
+
+ 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.
+
+ enum {
+ change_cipher_spec(20), alert(21), handshake(22),
+ application_data(23), mtls(TBA), (255)
+ } ContentType;
+
+2.3. MTLS Message Types
+
+ Additional message types can be supported by MTLS.
+
+ RequestEstablishmentChannel 0x01
+ RequestEstablishmentSuccess 0x02
+ RequestEchecChannel 0x03
+ CloseChannel 0x04
+
+Badra & Hajjeh Expires April 2008 [Page 6] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+ ConfirmationCloseChannel 0x05
+ MTLSPlaintext 0x06
+ Acknowledgment 0x07
+
+3. Security Considerations
+
+ Security issues are discussed throughout this document, and in
+ [TLS], [DTLS] and [TLSEXT] documents.
+
+ If a fatal error related to any channel or a connection of an
+ arbitrary application occurs, the secure session MUST NOT be
+ resumed. This is logic since the Record protocol does not
+ distinguish between the MTLS channels. However, if an error occurs
+ at the MTLS layer, both parties immediately close the related
+ channels, but not the TLS session (no alert of any type is sent by
+ the TLS Record).
+
+4. 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.
+
+5. References
+
+5.1. Normative References
+
+ [TLS] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
+ RFC 4346, April 200P.
+
+ [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.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+5.2. Informative References
+
+ [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.
+
+
+Badra & Hajjeh Expires April 2008 [Page 7] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+Author's Addresses
+
+ Mohamad Badra
+ LIMOS Laboratory - UMR6158, CNRS
+ France Email: badra@isima.fr
+
+ Ibrahim Hajjeh
+ ESRGroups, Security WG
+ France Email: Ibrahim.Hajjeh@esrgroups.org
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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, THE
+ IETF TRUST 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.
+
+ Intellectual Property
+
+ 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 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 procedures with respect to rights in RFC 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.
+
+
+Badra & Hajjeh Expires April 2008 [Page 8] \f
+
+Internet-Draft TLS Multiplexing October 2007
+
+ Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Badra & Hajjeh Expires April 2008 [Page 9] \f
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
