Drop experimental stuff.

[gnutls.git] / doc / protocol / draft-badra-hajjeh-mtls-01.txt

 

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