diff options
Diffstat (limited to 'doc/protocol/draft-badra-hajjeh-mtls-00.txt')
| -rw-r--r-- | doc/protocol/draft-badra-hajjeh-mtls-00.txt | 325 |
1 files changed, 0 insertions, 325 deletions
diff --git a/doc/protocol/draft-badra-hajjeh-mtls-00.txt b/doc/protocol/draft-badra-hajjeh-mtls-00.txt deleted file mode 100644 index 27dc30e944..0000000000 --- a/doc/protocol/draft-badra-hajjeh-mtls-00.txt +++ /dev/null @@ -1,325 +0,0 @@ - -Internet Engineering Task Force M. Badra -INTERNET DRAFT ENST Paris - I. Hajjeh - ESRGroups -Expires: March 2006 October 10, 2005 - - TLS Multiplexing - <draft-badra-hajjeh-mtls-00.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 March 10, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - TLS is the famous protocol that provides authentication and data - protection for communication between two entities. However, missing - from the protocol is a way to multiplex application data over the - same TLS session. - - This document defines a new TLS sub-protocol called MTLS running - over TLS (or DTLS) Record protocol. The MTLS design provides - application multiplexing over a single TLS session. Instead of - associating a TLS connection with each application, MTLS allows - -Badra & Hajjeh Expires March 2006 [Page 1] -INTERNET-DRAFT TLS Multiplexing October 2005 - - - 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]) 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 [DTLS]) clients and servers MUST establish a - TLS (or DTLS) session for each application they want to run over TCP - (or UDP). However, some applications may agree or be configured to - use the same security policies or parameters (f.g. authentication - method and cipher_suite) and then to share one and only one TLS - session to protect their exchanges. In this way, this document - extends TLS to allow an application multiplexing functionality 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 modular nature protocol. 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. - - o Establishing a single session for a number of applications - 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. - -1.2 Requirements language - - The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document - are to be interpreted as described in RFC-2119. - -Badra & Hajjeh Expires March 2006 [Page 2] -INTERNET-DRAFT TLS Multiplexing October 2005 - - -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(26) for this sub-protocol. - - MTLS communication can take place over TCP or UDP. The default port - is TBC, but other ports can be used. - -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 starts usually 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^20-1>; - } data_multiplexing; - - struct { - ApplicationpProtocolName apn; - select (Version) - case { 3, 1 }:// TLS Version 1.0 - TCPPort tcp_port; - case { 3, 2 }:// TLS Version 1.1 - TCPPort tcp_port; - case { 254, 255 }:// Datagram TLS Version 1.0 - UDPPort udp_port; - } ApplicationLayerProtocol; - - opaque TCPPort[2]; - opaque UDPPort[2]; - Opaque ApplicationpProtocolName<1..16>; - - tcp_port (respectively udp_port) is the application port number at - the server side. The client MUST use as destination ports, the TCP - (respectively UDP) port numbers that are assigned by IANA. -Badra & Hajjeh Expires March 2006 [Page 3] -INTERNET-DRAFT TLS Multiplexing October 2005 - - - Application layer running on unreliable links MUST be negotiated in - a separate session using the DTLS Handshake [DTLS]. - - Note: if the server agrees, the client SHOULD establish a single TLS - (respectively DTLS) session for all applications it wishes to run - over TCP (respectively UDP). In this case, the client SHOULD send a - data multiplexing extension containing "ALL" as - ApplicationpProtocolName value and "NULL" as TCPPort (or UDPPort) - value. If the server is not able to negotiate such session, it - replays with a list of applications (names and ports) it can accept - to run through a single TLS session, falls back on an ordinary TLS - handshake or stops the negotiation. - - 2.1.1. Multi-connections during application session - - Once the establishment is complete, the client MAY open many - connections related to an arbitrary application over the secure - session. In this case, the application client MUST locally reserve a - port number for each connection. Next, the client application sends - its request to the MTLS client which is listening on the TBC port - number. This latter will check if it has an established secure - session with the requested hostname (the server). If then it checks - if the application protocol name has been accepted to run over MTLS, - before sends the request to the MTLS server. - -2.2 MTLS sub-protocol - - The structure of MTLS packet is described below. The first 8 bytes - of the packet represent the source and the destination ports of the - connexion, and the length contains the length of the MTLS data. - - enum { - change_cipher_spec(20), alert(21), handshake(22), - application_data(23), mtls(26), (255) - } ContentType; - - struct { - uint32 SourcePort - uint32 DestinationPort - uint16 length; - opaque data[MTLSPlaintext.length]; - } MTLSPlaintext; - - 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. - -Badra & Hajjeh Expires March 2006 [Page 4] -INTERNET-DRAFT TLS Multiplexing October 2005 - - - 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 source and destination port - numbers and the length value. - -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 connexion of an arbitrary application - is occurred, the secure session MUST NOT be resumed. - -IANA Considerations - - This document requires IANA to allocate the TBC TCP and UDP port - numbers. - -Acknowledgment - - This document defined TLS Multiplexing for applications running over - IP. Beyond that definition, generic options may be added to future - versions of the current document. - -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 3546, June 2003. - - [DTLS] Rescorla, E., Modadugu, N., "Datagram Transport Layer - Security", draft-rescorla-dtls-05.txt, June 2004. - - [TLSv1.1] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", - draft-ietf-tls-rfc2246-bis-13.txt, June 2005 - - [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. - -Author's Addresses - - Mohamad Badra - ENST Paris - France Email: Mohamad.Badra@enst.fr - -Badra & Hajjeh Expires March 2006 [Page 5] -INTERNET-DRAFT TLS Multiplexing October 2005 - - - Ibrahim Hajjeh - ESRGroups, Security WG - France Email: Ibrahim.Hajjeh@esrgroups.org - - 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 (2004). 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 March 2006 [Page 6]
\ No newline at end of file |