Add.

1 files changed, 504 insertions, 0 deletions

diff --git a/doc/protocol/draft-badra-hajjeh-mtls-03.txt b/doc/protocol/draft-badra-hajjeh-mtls-03.txt
new file mode 100644
index 0000000000..a4b3fe5036
--- /dev/null
+++ b/doc/protocol/draft-badra-hajjeh-mtls-03.txt
@@ -0,0 +1,504 @@
+ 
+
+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