INTERNET-DRAFT M. VanHeyningen <draft-ietf-aft-socks-cram-00> Aventail Corporation Expires 20 September 1997 20 March 1997 Challenge-Response Authentication Method 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 a general Challenge-Response Authentication Method (CRAM) for use with SOCKS Version 5 [RFC 1928]. It is intended to support various challenge-response mechanisms, such as S/KEY and OTP [RFC 1938] as well as authentication tokens. Introduction The protocol specification for SOCKS Version 5 [RFC 1928] specifies a generalized framework for the use of arbitrary authentication protocols in the initial SOCKS connection setup. This document suggests a general framework for a Challenge-Response Authentication Method (CRAM) as it fits into the SOCKS Version 5 authentication "subnegotiation." Initial Negotiation During initial SOCKS V5 negotiation, the client and server negotiate the authenticiation method. The METHOD for this protocol shall be X'05'. VanHeyningen Expires 20 Sept 1997 [Page 1]
INTERNET-DRAFT Challenge-Response for SOCKS V5 20 March 1997 Challenge-Reponse Framework Subnegotiation begins after the client has selected the CRAM authentication method. Message Format In general, messages exchanged consist of a version identifier and a list 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 list of n assertions shall be represented as: ATT_1(VAL_1), ATT_2(VAL_2), ... ATT_n(VAL_n) Attributes The following attribute definitions apply to all messages: ATT Label Meaning ---------------------------------------------- X'00' STATUS 0 = success X'01' TEXT-MESSAGE Informational text X'02' USER-IDENTITY X'03' CHALLENGE X'04' RESPONSE X'05' CHARSET The TEXT-MESSAGE attribute may always be included in any message (except submethod negotiation.) Implementations should display its contents to the user if applicable; it should be used for advisory information (e.g. warnings of pending password expiration, explanations accompanying a failure.) If there is no user, VanHeyningen Expires 20 Sept 1997 [Page 2]
INTERNET-DRAFT Challenge-Response for SOCKS V5 20 March 1997 implementations may log its contents. The CHARSET attribute provides advisory infomration about the character set in use; it, too, may be present in any message. Implementations should use it to guide presentation of information to users. The semantics are identical to that of the charset parameter in MIME [RFC 1521]; if absent, a default of ISO-8859-1 should be assumed. Submethods may also define their own additional attributes, but must not redefine the above standard ones. Protocol Exchange Generic challenge-response simply authenticates the client's identity by sending a textual challenge from the server which the client displays to the user. The user somehow (e.g. by using an external application or a security token) computes the appropriate response and enters it. First, the client asserts its identity to the server: USER-IDENTITY(<username>) The server then responds with a textual challenge to be displayed to the user: CHALLENGE(<challenge>) The client displays this challenge, prompts for a response, and sends it: RESPONSE(<response>) The server may respond with a new challenge method, for which a new response is required. Arbitrarily many challenges may be issued. When the server finished issuing challenges, it sends a status message: STATUS(success|failure) and the subnegotiation terminates. If the authentication did not succeed, the server must drop the connection. Security Considerations Challenge-response protocols are generally designed to provide protection from passive attacks such as sniffing passwords. The security mechanisms here generally offer only limited protection from VanHeyningen Expires 20 Sept 1997 [Page 3]
INTERNET-DRAFT Challenge-Response for SOCKS V5 20 March 1997 real-time active attacks. In most 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. Acknowledgements Thanks to Dave Blob, Wei Lu, Craig Metz and William Perry for assistance with this document. References [RFC 1521] Borenstein, N, & Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies," September 1993. [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & Jones, L., "SOCKS Protocol V5," April 1996. [RFC 1938] Haller, N., & Metz, C., "A One-Time Password System," May 1996. [RFC 2058] Rigney, C., Rubens, A., Simpson, W. A., & Willens, S., "Remote Authentication Dial In User Service (RADIUS)", January 1997. 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]
