INTERNET-DRAFT M. VanHeyningen Aventail Expires March 14, 1997 14 September 1996 Challenge-Handshake Authentication Protocol for SOCKS V5 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.'' 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.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document specifies the integration of the Challenge-Handshake Authenticaton Protocol (CHAP) [RFC 1334] into SOCKS Version 5 [RFC 1928]. It is intended to provide a simple, lightweight authentication method which is more secure than cleartext passwords but simpler than GSSAPI-based methods. This document describes the message formats and protocol details of incorporating CHAP into the SOCKS V5 authentication "subnegotiation." Support is included for authentication of server to client as well as client to server. CHAP Method Identifier During initial SOCKS V5 negotiation, the client and server negotiate the authenticiation method. The METHOD for this protocol shall be X'03'. Subnegotiation Subnegotiation begins after the client has selected the CHAP authentication method. VanHeyningen Expires March 14, 1997 [Page 1] INTERNET-DRAFT CHAP for SOCKS V5 9 September 1996 Message Format In general, messages exchanged consist of a version identifier and a set of attribute-value assertions, where attributes are single octets and values are sequences of 0-255 octets. +-----+-------+------+---------+------+------+--- | VER | NAVAS | ATT1 | VAL1LEN | VAL1 | ATT2 | ... +-----+-------+------+---------+------+------+--- | 1 | 1 | 1 | 1 | 0-255| 1 | ... +-----+-------+------+---------+------+------+--- VER contains the current version of the subnegotiation, which is X'01'. NAVAS contains the number of attribute-value assertions to follow. Each AVA includes ATT_i, containing the attribute, VAL_iLEN, containing the length of VAL_i, and VAL_i. In general, robust implementations should ignore assertions with attributes they do not understand. This provides a powerful and general mechanism for future extensions while allowing backward compatibility. Notationally, a single message with a set of n assertions shall be represented as: ATT_1(VAL_1), ATT_2(VAL_2), ... ATT_n(VAL_n) Note that no ordering is assigned to the set of assertions: compliant implementations must accept them in any order. Attribute Definitions The following attribute definitions apply to all messages: ATT Label Meaning ------------------------------------------------- X'00' STATUS 0 = success, 1 = failure X'01' TEXT-MESSAGE Informational text X'02' USER-IDENTITY Contains CHAP NAME X'03' CHALLENGE X'04' RESPONSE X'10' IDENTIFIER CHAP identifier X'11' ALGORITHMS Supported CHAP algorithms The TEXT-MESSAGE attribute may always be included in any message. Implementations should display its value to the user if applicable; it may be used for advisory information (e.g. warnings of pending password expiration, explanations accompanying a failure.) If there is no user, implementations may log its contents. VanHeyningen Expires March 14, 1997 [Page 2] INTERNET-DRAFT CHAP for SOCKS V5 9 September 1996 Algorithm Negotiation The CHAP subnegotiation begins with the client sending a message containing the CHAP algorithms it is willing to use (e.g. MD5, MS-CHAP [MS-CHAP]): ALGORITHMS() The server responds with another message of the same form containing the one algorithm to be used for this connection: ALGORITHMS() If the server is unable or unwilling to use any of the algorithms specified by the client, it returns a message indicating failure: STATUS(failure) and closes the connection. Challenge-Response Exchange After the algorithm is negotiated, the server sends a challenge: CHALLENGE(), IDENTIFIER() The client sends an appropriate response: USER-IDENTITY(), RESPONSE(), IDENTIFIER() And the server indicates success or failure: STATUS(success|failure), IDENTIFER() after which the subnegotiation terminates and, upon success, the client should proceed with its request. Upon failure, the server must close the connection. Mutual Authentication Optionally, a client may request mutual authentication by including another CHALLENGE along with its response: USER-IDENTITY(), RESPONSE(), CHALLENGE(), IDENTIFIER() The server should then VanHeyningen Expires March 14, 1997 [Page 3] INTERNET-DRAFT CHAP for SOCKS V5 9 September 1996 include a RESPONSE along with the STATUS message: STATUS(success|failure), IDENTIFIER(), RESPONSE() Finally, the client replies with a STATUS message of its own before the subnegotiation terminates STATUS(success|failure) Note that both negotiations employ the same identifier and are computed with the same shared secret. Since servers unable or unwilling to do mutual authentication will ignore the client's CHALLENGE, clients should handle a lack of RESPONSE gracefully and either continue or terminate in accordance with security policy. Security Considerations Challenge-response protocols are generally designed to provide protection from passive attacks such as sniffing passwords. CHAP offers limited protection from real-time active attacks. CHAP's integration of hash functions is somewhat behind the current state of the art in MAC design. Servers should change the identifier field with each connection even though it is not required for matching connections, preferably in an unpredictable fashion. Implementations should refuse to respond to too-short challenges, particularly challenges 0 bytes long, as they may give away information about the secret useful to an attacker. Servers should refuse to respond to challenges until verifying the correctness of the client's response. Adding stronger MAC designs, such as HMAC [HMAC-MD5], to CHAP's algorithm suite is a matter for further research. As in all challenge-response security mechanisms, it is important that challenges be produced in a fashion an adversary cannot predict or duplicate. As with all negotiation-based security, implementations may be vulnerable to downgrade attacks. Clients and servers should refuse to operate with methods and algorithms considered insufficiently secure. In the context of a PPP connection, a CHAP challenge may be issued at any time to reconfirm the authentication. This integration permits challenges only during connection establishment and has no provision for reconfirmation. VanHeyningen Expires March 14, 1997 [Page 4] INTERNET-DRAFT CHAP for SOCKS V5 9 September 1996 Acknowledgements Thanks to Dave Blob, Wei Lu, Craig Metz, and William Perry for assistance with this document. References [HMAC-MD5] Krawczyk, H., Bellare, M., & Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication," Internet-Draft, work in progress. [MS-CHAP] Cobb, S., "Microsoft PPP CHAP Extensions," Informational Memo, December 1995. [RFC 1344] Lloyd, B. & Simpson, W., "PPP Authentication Protocols," October 1992. [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & Jones, L., "SOCKS Protocol V5," April 1996. Author's Address Marc VanHeyningen Aventail Corporation 401 Second Avenue South, Suite 501 Seattle, WA 98104 Phone: +1 206 777-5613 Fax: +1 206 777-5656 Email: marcvh@aventail.com VanHeyningen Expires March 14, 1997 [Page 5]