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