Internet DRAFT - draft-vanheyningen-socks-chap

draft-vanheyningen-socks-chap



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:01:13 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 09 Sep 1996 21:19:00 GMT
ETag: "3ddf01-2422-323489c4"
Accept-Ranges: bytes
Content-Length: 9250
Connection: close
Content-Type: text/plain


INTERNET-DRAFT                                           M. VanHeyningen
<draft-vanheyningen-socks-chap-00>                              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(<algorithms>)

   The server responds with another message of the same form containing
   the one algorithm to be used for this connection:

           ALGORITHMS(<algorithm>)

   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(<challenge>), IDENTIFIER(<ident>)

   The client sends an appropriate response:

           USER-IDENTITY(<username>), RESPONSE(<response>),
             IDENTIFIER(<ident>)

   And the server indicates success or failure:

           STATUS(success|failure), IDENTIFER(<ident>)

   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(<username>), RESPONSE(<response>),
             CHALLENGE(<challenge-2>), IDENTIFIER(<ident>)

   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(<ident>),
             RESPONSE(<response-2>)

   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]