INTERNET-DRAFT C. Wong Expires six months from --> 20 November 1998 TLSMUX - Multiplexed TLS for uniform encrypted access to local services Status of this Memo This document is an Internet-Draft. 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 made obsolete 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. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Abstract This document describes a multiplexing protocol that allows remote machines to access local services in a secure manner. All clients must connect to the multiplexer using TLS, allowing encrypted network communications to normally cleartext protocols. TLSMUX is an application level protocol that does not require a kernel upgrade or extensions to existing protocols in order to operate. By offering a TLS connection to a multiplexer, current servers and protocols do not need to be modified to benefit from the encryption features of TLSMUX. Some clients may need to be updated to support TLSMUX, although it is possible for some clients to use a TLSMUX proxy without modification. 2. Introduction This document describes a protocol designed to provide uniform access to cleartext protocols using an encrypted connection to a multiplexing service. This protocol, called TLSMUX, uses [TLS] for encryption and SOCKS [RFC 1928] for multiplexing. The multiplexing service, unlike regular SOCKS servers, can only connect to services on the local machine that it is running on. Consider TCPMUX [RFC 1078], where a client connects to a TCPMUX server, specifies a service that it wishes to talk to, and receives a response from the server indicating if the multiplexed connection is allowed. If it is allowed, the protocol requested immediately follows the TCPMUX transaction. In acknowledging that the Internet is more than just TCP/IP, SOCKS Wong Expires April 1999 [Page 1] INTERNET-DRAFT TLSMUX 20 November 1998 is chosen as the multiplexing protocol due to it's support for both TCP and UDP. Unlike a regular SOCKS server, where the client is allowed to use the SOCKS server as a proxy to connect to third-party machines, the SOCKS server in TLSMUX is only allowed to connect to local services on the machine on which it is running. It is also mandatory that the SOCKS server in TLSMUX allow anonymous access to its service without the use of authentication, although authentication can be used but is out of the scope of this document. A client connects to TLSMUX using a standard TCP connection on a well known port. The client and server go through a TLS handshake. Given a successful TLS handshake, the client sends a SOCKS request for a resource local to the TLSMUX server. After a successful SOCKS transaction, the client is allowed to communicate to the requested service directly. While the TLSMUX client and TLSMUX server both speak TLS to each other, the destination service is unaware of this. Although existing protocols and servers do not need to be modified to support TLSMUX, clients will need to be TLSMUX aware in the same sense that they are currently SOCKS aware. 3. Proxy servers It is possible for some clients to transparently use TLSMUX without modification through the use of TLSMUX proxy servers. For example, it is possible for a mail client to send outgoing messages via TLSMUX by connecting to a TLSMUX service on the local machine that accepts cleartext SMTP [RFC 821] messages and relays the message to the destination server via TLSMUX. This works well in situations where there is some form of relay server already set up for a particular protocol. Example protocols that are relay friendly are finger [RFC 1288], SMTP, and HTTP [rfc 2068]. 4. Alternative Approaches 4.1 IPSEC The IP Security Protocol [IPSEC] is a network layer solution that involves changes to an operating system's IP stack, which would involve kernel or shared library updates. While IPSEC and TLSMUX both provide a means for machines to communicate to each other using encryption, it appears that widespread support of IPSEC will not appear in the near future. Many computers connected to the Internet today are legacy systems running operating systems that are no longer supported by the OS vendor. In some cases, the original vendor does not exist and kernel/stack upgrades for IPSEC will be difficult and costly, if not impossible. Unlike IPSEC, TLSMUX is an application level gateway that does not require modifications to an operating system's kernel. Since TLSMUX is an application level gateway, it is possible to run TLSMUX clients and servers on operating systems that are no Wong Expires April 1999 [Page 2] INTERNET-DRAFT TLSMUX 20 November 1998 longer supported by their vendors. 4.2 Protocol Specific Extensions Another alternative is to extend popular protocols with security extensions. One example is [SMTPTLS], where a new SMTP verb, "STARTTLS", would trigger a TLS handshake and the client and server would continue its SMTP interaction inside a TLS session. Application protocol level changes of this nature do not require kernel/stack changes as in the case of [IPSEC], but require modifications in both the client and server of a particular protocol. Using this method, TLS communication for various services would be protocol specific and require detailed knowledge of how each protocol has been extended to initiate a TLS session. Some one-way protocols may not give the client an option to start a TLS handshake and would require an out-of-band means to communicate a prerequisite for a TLS handshake. TLSMUX does not require protocol specific extensions to enable TLS and it does not require the application server to be rewritten. It provides uniform access to all of the machine's listening services, giving even proprietary, simple, or obsolete protocols and servers the benefit of over-the-wire encryption without modification. 4.3 Duplicate Servers An earlier approach to adding encryption to a protocol is to run the protocol on another port and add an SSL handshake. An example of this is HTTPS, normally on port 443, which is the same as regular HTTP (port 80) except with SSL handshaking before any HTTP transactions have taken place. This approach duplicates the number of listening services on a given machine, and could pollute the port number assignments by pairing up combinations of various encryption schemes with cleartext protocols. TLSMUX listens at a well known port and does not duplicate the number of listening ports on a given machine. 5. References [RFC 1078] - M. Lottor, "TCP Port Service Multiplexer (TCPMUX)," Nov. 1988. [RFC 1928] - M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones, "SOCKS Protocol Version 5," Mar. 1996. [TLS] - T. Dierks, C. Allen, "The TLS Protocol Version 1.0," draft-ietf-tls-protocol-05.txt, Nov. 1997. [RFC 1288] - D. Zimmerman, "The Finger User Information Protocol," Center for Discrete Mathematics and Theoretical Wong Expires April 1999 [Page 3] INTERNET-DRAFT TLSMUX 20 November 1998 Computer Science, December 1991. [RFC 821] - J. Postel, "Simple Mail Transfer Protocol," USC/Information Sciences Institute, August 1982. [RFC 2068] - R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", U.C. Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997 [IPSEC] http://www.ietf.org/html.charters/ipsec-charter.html [SMTPTLS] - P. Hoffman, "SMTP Service Extension for Secure SMTP over TLS," draft-hoffman-smtp-ssl-10.txt, Nov. 1998. 6. Author's Contact Information Clinton Wong clintdw@netcom.com Wong Expires April 1999 [Page 4]