--- /dev/null
+
+
+
+Internet Engineering Task Force M. Badra
+INTERNET DRAFT ENST Paris
+ I. Hajjeh
+ ESRGroups
+Expires: December 2006 June 15, 2006
+
+ MTLS: TLS Multiplexing
+ <draft-badra-hajjeh-mtls-01.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 November 20, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006). 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 December 2006 [Page 1] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+ 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 December 2006 [Page 2] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+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 max_packet_length;
+ ApplicationpProtocolName apn;
+ } ApplicationLayerProtocol;
+
+ opaque SenderChannelID [2];
+ opaque ReceiverChannelID [2];
+ Opaque ApplicationpProtocolName<1..2^4>;
+
+ 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
+
+Badra & Hajjeh Expires December 2006 [Page 3] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+ 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
+ max_packet_length with the data length (in octets), specifying how
+ many bytes the receiver (respectively the sender) can maximally send
+ on the channel. Each end of the channel establishes a 'receive
+ buffer' and a 'send buffer'.
+
+ 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.
+
+ 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.
+
+
+
+
+Badra & Hajjeh Expires December 2006 [Page 4] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+ 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;
+ uint32 max_packet_length;// of the sender of this packet
+ 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 receiver decides whether it can open the channel, and replies
+ with one of the following messages:
+
+ struct {
+ uint8 type;
+ SenderChannelID sender_channel_id;
+ ReceiverChannelID receiver_channel_id;
+ uint32 max_packet_length;
+ } RequestEstablishmentSuccess;
+
+ struct {
+ uint8 type;
+ SenderChannelID sender_channel_id;
+ 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;
+ } CloseChannel;
+
+
+
+
+
+Badra & Hajjeh Expires December 2006 [Page 5] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+ struct {
+ uint8 type;
+ SenderChannelID sender_channel_id;
+ ReceiverChannelID receiver_channel_id;
+ } 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
+ (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 using either data or
+ Acknowledgment packets. In the first case, the entity MUST set the
+ max_packet_length_changed to 1 and extra_length set to the extra
+ free space. In the second case, the entity only needs to send the
+ length of the extra free space.
+
+ If the length of the 'receive buffer' does not change,
+ Acknowledgment packet will never be sent. However, the entity MAY
+ send data packet but in this case, it MUST set the
+ max_packet_length_changed to 0 and MUST consequently remove the
+ extra_length field from the packet header.
+
+ In the case where the 'receive buffer' of an entity fills up, the
+ other entity MUST wait for an Acknowledgment or a data packet with
+ packet_length_changed set to 1, before sending any more
+ MTLSPlaintext packets.
+
+
+
+
+
+
+
+Badra & Hajjeh Expires December 2006 [Page 6] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+ struct {
+ uint8 type;
+ uint16 channel_id;
+ uint8 max_packet_length_changed;
+ uint32 extra_length; // omitted if the value of the
+ // max_packet_length_changed is 0
+ uint32 length;
+ opaque data[MTLSPlaintext.length];
+ } MTLSPlaintext;
+
+ struct {
+ uint8 type;
+ uint16 channel_id; // of the receiver of that packet
+ uint32 extra_length;
+ } 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].
+
+ 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.
+
+
+
+
+
+Badra & Hajjeh Expires December 2006 [Page 7] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+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.
+
+
+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
+ ENST Paris
+ France Email: Mohamad.Badra@enst.fr
+
+ Ibrahim Hajjeh
+ ESRGroups, Security WG
+ France Email: Ibrahim.Hajjeh@esrgroups.org
+
+
+
+
+
+
+
+
+Badra & Hajjeh Expires December 2006 [Page 8] \f
+
+Internet-Draft TLS Multiplexing June 2006
+
+
+ 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 (2006). 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 December 2006 [Page 9] \f
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
