draft-ietf-aft-socks-chap-00.txt   draft-ietf-aft-socks-chap-01.txt 
INTERNET-DRAFT M. VanHeyningen INTERNET-DRAFT M. VanHeyningen
<draft-ietf-aft-socks-chap-00> Aventail Corporation <draft-ietf-aft-socks-chap-01> Aventail Corporation
Expires six months from --> 6 January 1998
Challenge-Handshake Authentication Protocol for SOCKS V5 Challenge-Handshake Authentication Protocol for SOCKS V5
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 28 skipping to change at page 1, line 30
in progress.'' in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document specifies the integration of the Challenge-Handshake This document specifies the integration of authentication based on
Authenticaton Protocol (CHAP) [RFC 1994] into SOCKS Version 5 [RFC Challenge-Handshake Authenticaton Protocol into SOCKS Version 5. The
1928]. It is intended to provide a simple, lightweight primary algorithm to be used is HMAC-MD5, although the framework is
authentication method which is more secure than cleartext passwords general enough to permit use of MD5 or other keyed hash algorithms.
but simpler than GSSAPI-based methods. This document describes the This document describes the message formats and protocol details of
message formats and protocol details of incorporating CHAP into the incorporating CHAP into the SOCKS V5 authentication ''subnegotiation.''
SOCKS V5 authentication "subnegotiation." Support is included for Support is included for authentication of server to client as well as
authentication of server to client as well as client to server. client to server.
CHAP Method Identifier CHAP Method Identifier
During initial SOCKS V5 negotiation, the client and server negotiate During initial SOCKS V5 negotiation, the client and server negotiate
the authenticiation method. The METHOD for this protocol shall be the authenticiation method. The METHOD for this protocol shall be
X'03'. X'03'.
Subnegotiation The HMAC-MD5 Algorithm
Subnegotiation begins after the client has selected the CHAP HMAC-MD5 is defined as a new CHAP algorithm with algorithm identifier
0x85. It uses the MD5 algorithm is defined in [RFC 1321] with the
HMAC construct defined in [RFC 2104] to generate responses to given
challenges; unlike in the standard MD5 CHAP, the identifier octet is
ignored. Compliant implementations MUST support the HMAC-MD5
algorithm, and MAY support others.
CHAP Exchange
Subnegotiation begins after the server has selected the CHAP
authentication method. authentication method.
Message Format Message Format
In general, messages exchanged consist of a version identifier and a In general, messages exchanged consist of a version identifier and a
set of attribute-value assertions, where attributes are single octets set of attribute-value assertions, where attributes are single octets
and values are sequences of 0-255 octets. and values are sequences of 0-255 octets.
+-----+-------+------+---------+------+------+--- +-----+-------+------+---------+------+------+---
| VER | NAVAS | ATT1 | VAL1LEN | VAL1 | ATT2 | ... | VER | NAVAS | ATT1 | VAL1LEN | VAL1 | ATT2 | ...
+-----+-------+------+---------+------+------+--- +-----+-------+------+---------+------+------+---
| 1 | 1 | 1 | 1 | 0-255| 1 | ... | 1 | 1 | 1 | 1 | 0-255| 1 | ...
+-----+-------+------+---------+------+------+--- +-----+-------+------+---------+------+------+---
VER contains the current version of the subnegotiation, which is VER contains the current version of the subnegotiation, which is
X'01'. NAVAS contains the number of attribute-value assertions to X'01'. NAVAS contains the number of attribute-value assertions to
follow. Each AVA includes ATT_i, containing the attribute, VAL_iLEN, follow. Each AVA includes ATT_i, containing the attribute, VAL_iLEN,
containing the length of VAL_i, and VAL_i. In general, robust containing the length of VAL_i, and VAL_i. In general, robust
implementations should ignore assertions with attributes they do not implementations should ignore assertions with attributes they do not
understand. This provides a powerful and general mechanism for future understand. This provides a powerful and general mechanism for
extensions while allowing backward compatibility. future extensions while allowing backward compatibility.
Notationally, a single message with a set of n assertions shall be Notationally, a single message with a set of n assertions shall be
represented as: represented as:
ATT_1(VAL_1), ATT_2(VAL_2), ... ATT_n(VAL_n) ATT_1(VAL_1), ATT_2(VAL_2), ... ATT_n(VAL_n)
Note that no ordering is assigned to the set of assertions: compliant Note that no ordering is assigned to the set of assertions: compliant
implementations must accept them in any order. implementations must accept them in any order.
Attribute Definitions Attribute Definitions
skipping to change at page 2, line 49 skipping to change at page 3, line 8
X'00' STATUS 0 = success X'00' STATUS 0 = success
X'01' TEXT-MESSAGE Informational text X'01' TEXT-MESSAGE Informational text
X'02' USER-IDENTITY Contains CHAP NAME X'02' USER-IDENTITY Contains CHAP NAME
X'03' CHALLENGE X'03' CHALLENGE
X'04' RESPONSE X'04' RESPONSE
X'05' CHARSET Optional character set X'05' CHARSET Optional character set
X'10' IDENTIFIER CHAP identifier X'10' IDENTIFIER CHAP identifier
X'11' ALGORITHMS Supported CHAP algorithms X'11' ALGORITHMS Supported CHAP algorithms
The TEXT-MESSAGE attribute may always be included in any message. The TEXT-MESSAGE attribute may always be included in any message.
Implementations should display its value to the user if applicable; it Implementations should display its value to the user if applicable;
may be used for advisory information (e.g. warnings of pending it may be used for advisory information (e.g. warnings of pending
password expiration, explanations accompanying a failure.) If there is password expiration, explanations accompanying a failure.) If
no user, implementations may log its contents. presenting the message to a user is not possible or not applicable,
implementations may log its contents.
The CHARSET attribute provides advisory infomration about the The CHARSET attribute provides advisory infomration about the
character set in use; it, too, may be present in any message. character set in use; it, too, may be present in any message.
Implementations should use it to guide presentation of information to Implementations may use it to guide prompting and presentation of
users. The semantics are identical to that of the charset parameter usernames, challenges, responses and text messages. The semantics
in MIME [RFC 1521]; if absent, a default of ISO-8859-1 should be are those defined for charset parameter in MIME [RFC 1521]; if
assumed. absent, a default of US-ASCII (or a superset) must be assumed.
The IDENTIFIER is used to transport the CHAP identifier when using
algorithms such as MD5 which require an identifier; it is included
with all messages after the algorithm negotiation when MD5 is
selected.
Algorithm Negotiation Algorithm Negotiation
The CHAP subnegotiation begins with the client sending a message The CHAP subnegotiation begins with the client sending a message
containing the CHAP algorithms it is willing to use (e.g. MD5, MS-CHAP containing the CHAP algorithms it is willing to use (e.g. HMAC-MD5,
[MS-CHAP]): MD5.) Note that compliant implementations MUST support HMAC-MD5.:
ALGORITHMS(<algorithms>) ALGORITHMS(<algorithms>)
The server responds with another message of the same form containing The server responds with another message of the same form containing
the one algorithm to be used for this connection: the one algorithm to be used for this connection:
ALGORITHMS(<algorithm>) ALGORITHMS(<algorithm>)
If the server is unable or unwilling to use any of the algorithms If the server is unable or unwilling to use any of the algorithms
specified by the client, it returns a message indicating failure: specified by the client, it returns a message indicating failure:
STATUS(failure) STATUS(failure)
and closes the connection. and closes the connection.
Challenge-Response Exchange Challenge-Response Exchange
After the algorithm is negotiated, the server sends a challenge: After the algorithm is negotiated, the server sends a challenge:
CHALLENGE(<challenge>), IDENTIFIER(<ident>) CHALLENGE(<challenge>)
The client sends an appropriate response: The client sends an appropriate response:
USER-IDENTITY(<username>), RESPONSE(<response>), USER-IDENTITY(<username>), RESPONSE(<response>)
IDENTIFIER(<ident>)
And the server indicates success or failure: And the server indicates success or failure:
STATUS(success|failure), IDENTIFER(<ident>) STATUS(success|failure)
after which the subnegotiation terminates and, upon success, the client after which the subnegotiation terminates and, upon success, the
should proceed with its request. Upon failure, the server must close client should proceed with its request. Upon failure, the server
the connection. must close the connection.
Mutual Authentication Mutual Authentication
Optionally, a client may request mutual authentication by including
Implementations MAY support mutual authentication of client and
server. A client may request mutual authentication by including
another CHALLENGE along with its response: another CHALLENGE along with its response:
USER-IDENTITY(<username>), RESPONSE(<response>), USER-IDENTITY(<username>), RESPONSE(<response>),
CHALLENGE(<challenge-2>), IDENTIFIER(<ident>) CHALLENGE(<challenge-2>)
The server should then The server should then include a RESPONSE along with the STATUS
include a RESPONSE along with the STATUS message: message:
STATUS(success|failure), IDENTIFIER(<ident>), STATUS(success|failure), RESPONSE(<response-2>)
RESPONSE(<response-2>)
Finally, the client Finally, the client replies with a STATUS message of its own before
replies with a STATUS message of its own before the subnegotiation the subnegotiation terminates
terminates
STATUS(success|failure) STATUS(success|failure)
Note that both negotiations employ the same identifier. Note that both negotiations employ the same identifier. Whether the
Whether the same shared secret is used in both directions is outside same shared secret is used in both directions is outside the scope of
the scope of this specification, although use of a single secret this specification, although use of a single secret does not create
does not create the same security considerations with SOCKS5 as are present the same security considerations with SOCKS5 as are present in PPP.
in PPP. Since servers unable or unwilling to do mutual authentication will
Since servers unable or ignore the client's CHALLENGE, clients should handle a lack of
unwilling to do mutual authentication will ignore the client's RESPONSE gracefully and either continue or terminate the connection
CHALLENGE, clients should handle a lack of RESPONSE gracefully and in accordance with their security policy.
either continue or terminate in accordance with security policy.
Security Considerations Security Considerations
Challenge-response protocols are generally designed to provide Challenge-response protocols are generally designed to provide
protection from passive attacks such as sniffing passwords. CHAP protection from passive attacks such as sniffing passwords. CHAP
offers limited protection from real-time active attacks. offers limited protection from real-time active attacks.
CHAP's integration of hash functions is somewhat behind the current Algorithms other than HMAC-MD5, such as MD5 as originally specified
state of the art in MAC design. Servers should change the identifier in [RFC 1994], were created without the benefit of much subsequent
field with each connection even though it is not required for matching research into the area of keyed hash construction. Their design is
connections, preferably in an unpredictable fashion. Implementations now considered weak. A variant of CHAP called MS-CHAP [MSCHAP] is
should refuse to respond to too-short challenges, particularly known to be particularly weak.
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 As in all challenge-response security mechanisms, it is important
challenges be produced in a fashion an adversary cannot predict or that challenges be produced in a fashion an adversary cannot predict
duplicate. As with all negotiation-based security, implementations or duplicate. As with all negotiation-based security,
may be vulnerable to downgrade attacks. Clients and servers should implementations may be vulnerable to downgrade attacks. Clients and
refuse to operate with methods and algorithms considered servers should refuse to operate with methods and algorithms
insufficiently secure. considere insufficiently secure
In the context of a PPP connection, a CHAP challenge may be issued at In the context of a PPP connection, a CHAP challenge may be issued at
any time to reconfirm the authentication. This integration permits any time to reconfirm the authentication. This integration permits
challenges only during connection establishment and has no provision challenges only during connection establishment and has no provision
for reconfirmation. for reconfirmation.
Acknowledgements Acknowledgements
Thanks to Dave Blob, Wei Lu, Craig Metz, and William Perry for Thanks to Dave Blob, Wei Lu, Craig Metz, and William Perry for
assistance with this document. assistance with this document.
References References
[HMAC-MD5] Krawczyk, H., Bellare, M., & Canetti, R., "HMAC-MD5: [MSCHAP] Cobb, S., "Microsoft PPP CHAP Extensions," Informational
Keyed-MD5 for Message Authentication," Internet-Draft, work in
progress.
[MS-CHAP] Cobb, S., "Microsoft PPP CHAP Extensions," Informational
Memo, December 1995. Memo, December 1995.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," April
1992.
[RFC 1521] Borenstein, N, & Freed, N., "MIME (Multipurpose Internet [RFC 1521] Borenstein, N, & Freed, N., "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and Describing Mail Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies," September 1993. the Format of Internet Message Bodies," September 1993.
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., &
Jones, L., "SOCKS Protocol V5," April 1996. Jones, L., "SOCKS Protocol V5," April 1996.
[RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol [RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication
(CHAP)," August 1996. Protocol (CHAP)," August 1996.
[RFC 2104] Krawczyk, H., Bellare, M., & Canetti, R., "HMAC: Keyed-
Hashing for Message Authentication," February 1997.
Author's Address Author's Address
Marc VanHeyningen Marc VanHeyningen
Aventail Corporation Aventail Corporation
117 S. Main St, Suite 400 117 S. Main St, Suite 400
Seattle, WA 98104 Seattle, WA 98104
Phone: +1 206 777-5600 Phone: +1 206 777-5600
Fax: +1 206 777-5656 Fax: +1 206 777-5656
 End of changes. 23 change blocks. 
72 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/