diff options
Diffstat (limited to 'doc/protocol/draft-badra-hajjeh-mtls-03.txt')
| -rw-r--r-- | doc/protocol/draft-badra-hajjeh-mtls-03.txt | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/doc/protocol/draft-badra-hajjeh-mtls-03.txt b/doc/protocol/draft-badra-hajjeh-mtls-03.txt deleted file mode 100644 index a4b3fe5036..0000000000 --- a/doc/protocol/draft-badra-hajjeh-mtls-03.txt +++ /dev/null @@ -1,504 +0,0 @@ - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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]
\ No newline at end of file |