INTERNET-DRAFT M. VanHeyningen Aventail Corporation Expires 20 September 1997 20 March 1997 Secure Sockets Layer for SOCKS Version 5 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 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.'' ABSTRACT This document specifies the use of SSL 3.0 and possible successor protocols as an authentication method for SOCKS Version 5. The design is similar to, and largely derived from, the integration of GSS-API into SOCKS5 [RFC 1961]. A framework is provided for future extensions, and the use of other "subauthentication" methods inside SSL is supported. SSL METHOD IDENTIFIER During the initial SOCKS V5 negotiation, an authentication method is negotiated. The identifier used in the SOCKS5 authentication handshake for this method shall be X'86' (134 decimal.) SSL RECORD FRAMING The SSL data stream is wrapped for transport over the SOCKS5 data stream as follows: +-----+-------+-----+-------- | VER | STATE | LEN | DATA +-----+-------+-----+-------- | 1 | 1 | 2 | 0 - 65535 +-----+-------+-----+-------- The VER shall be X'01 for this revision. The STATE may have four different values: VanHeyningen Expires 20 Sept 1997 [Page 1] INTERNET-DRAFT SSL for SOCKS V5 20 March 1997 Initial handshake X'01' Option negotiation X'02' Data flow X'03' Closing handshake X'04' LEN specifies the number of bytes in the DATA, and shall be MSB-first. SSL PROCEDURE After the server selects SSL as its authentication method, an initial handshake to establish an SSL-secured connection commences with STATE of X'01'. SSL specific options After this handshake all subsequent data is secured via SSL, then in the framing specified above. With STATE of X'02', the client sends a list of SSL-specific options it can support: +-----+---------- | LEN | OPTIONS +-----+---------- | 1 | 0-255 +-----+---------- The server responds with an identically formatted list of the subset of options to be used for this connection. At this time, only two options are defined: Subauthentication X'01' UDP-Naked X'10' UDP-Naked With SSL integration, the handling of UDP data is a tricky issue. Unlike GSSAPI-based solutions, SSL is not designed to handle datagram traffic. UDP-Naked specifies that SSL shall be used only to protect the control connection of the UDP association, and UDP traffic will receive no enhancements. It is expected that other options for UDP processing will be defined; in general it is expected that the server will choose one UDP method from those offered by the client. Subauthentication Subauthentication provides a mechanism for embedding a simpler VanHeyningen Expires 20 Sept 1997 [Page 2] INTERNET-DRAFT SSL for SOCKS V5 20 March 1997 authentication mechanism inside SSL. For example, some environments may use SSL with server-side certificates to establish a secure connection to a server, then use cleartext passwords [RFC 1929] inside the encrypted connection. If the server's option handshake specifies that subauthentication is to be used, the client responds with a message specifying the authentication methods it supports in this environment; the format is identical to that of [RFC 1928, sec 3]. After negotiating a subauthentication method, subauthentication proceeds exactly as it would normally, but inside the SSL-secured data stream. It is expected that only primitive authentication techniques, such as cleartext passwords or CHAP [SOCKS-CHAP], will be used as subauthentitcation methods. Command processing After option processing is complete, the authentication method finishes. STATE is set to X'03', and the SOCKS command commences. Orderly closure Upon connection termination, the terminating side should change STATE to X'04' and send an SSL closure handshake; the other side should also change its STATE and respond appropriately. SECURITY CONSIDERATIONS As with any negotiation-based mechanism, SOCKS5 is subject to downgrade attacks. Both clients and servers should operate only with security parameters consistent with the given security policy. The UDP-Naked option, as its name suggests, provides very minimal security for UDP traffic. It allows subauthentication and initial commands which may specifiy destination and other use restrictions on a UDP association to be established securely, but it does nothing to preserve the privacy or integrity of the bulk data. More secure methods of proxying UDP traffic may be added as additional SSL-specific options. All SSL-based considerations, such as the importance of properly seeding random generators used to generate keying information and storing persistent keying information in secure ways, apply here. SSL 2.0 has known weakness and limitations. Since there is no existing base of software using this specification based on SSL 2.0, applications may support SSL 3.0 (or later) only without compromising VanHeyningen Expires 20 Sept 1997 [Page 3] INTERNET-DRAFT SSL for SOCKS V5 20 March 1997 interoperability. REFERENCES [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & Jones, L., "SOCKS Protocol V5," April 1996. [RFC 1929] Leech, M., "Username/Password Authentication for SOCKS V5," March 1996. [RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS Version 5," June 1996. [SOCKS-CHAP] VanHeyningen, M., "Challenge-Handshake Authentication Protocol for SOCKS V5," , March 1997, work in progress. [SSL] Freier, A., Karlton, P., Kocher, P., "The SSL Protocol: Version 3.0," , November 1996, work in progress. AUTHOR'S ADDRESS Marc VanHeyningen Aventail Corporation 117 S. Main Street, Suite 400 Seattle, WA 98104 Phone: +1 206 777-5600 Fax: +1 206 777-5656 Email: marcvh@aventail.com VanHeyningen Expires 20 Sept 1997 [Page 4]