idnits 2.17.1 draft-ietf-aft-socks-chap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([MS-CHAP], [RFC1994], [HMAC-MD5], [RFC1521], [RFC1928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 March 1997) is 9892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1928' is defined on line 220, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC-MD5' -- Possible downref: Non-RFC (?) normative reference: ref. 'MS-CHAP' ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. VanHeyningen 3 Aventail Corporation 4 Expires 20 September 1997 20 March 1997 6 Challenge-Handshake Authentication Protocol for SOCKS V5 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as ``work 19 in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document specifies the integration of the Challenge-Handshake 30 Authenticaton Protocol (CHAP) [RFC 1994] into SOCKS Version 5 [RFC 31 1928]. It is intended to provide a simple, lightweight 32 authentication method which is more secure than cleartext passwords 33 but simpler than GSSAPI-based methods. This document describes the 34 message formats and protocol details of incorporating CHAP into the 35 SOCKS V5 authentication "subnegotiation." Support is included for 36 authentication of server to client as well as client to server. 38 CHAP Method Identifier 40 During initial SOCKS V5 negotiation, the client and server negotiate 41 the authenticiation method. The METHOD for this protocol shall be 42 X'03'. 44 Subnegotiation 46 Subnegotiation begins after the client has selected the CHAP 47 authentication method. 49 Message Format 51 In general, messages exchanged consist of a version identifier and a 52 set of attribute-value assertions, where attributes are single octets 53 and values are sequences of 0-255 octets. 55 +-----+-------+------+---------+------+------+--- 56 | VER | NAVAS | ATT1 | VAL1LEN | VAL1 | ATT2 | ... 57 +-----+-------+------+---------+------+------+--- 58 | 1 | 1 | 1 | 1 | 0-255| 1 | ... 59 +-----+-------+------+---------+------+------+--- 61 VER contains the current version of the subnegotiation, which is 62 X'01'. NAVAS contains the number of attribute-value assertions to 63 follow. Each AVA includes ATT_i, containing the attribute, VAL_iLEN, 64 containing the length of VAL_i, and VAL_i. In general, robust 65 implementations should ignore assertions with attributes they do not 66 understand. This provides a powerful and general mechanism for future 67 extensions while allowing backward compatibility. 69 Notationally, a single message with a set of n assertions shall be 70 represented as: 72 ATT_1(VAL_1), ATT_2(VAL_2), ... ATT_n(VAL_n) 74 Note that no ordering is assigned to the set of assertions: compliant 75 implementations must accept them in any order. 77 Attribute Definitions 79 The following attribute definitions apply to all messages: 81 ATT Label Meaning 82 ------------------------------------------------- 83 X'00' STATUS 0 = success 84 X'01' TEXT-MESSAGE Informational text 85 X'02' USER-IDENTITY Contains CHAP NAME 86 X'03' CHALLENGE 87 X'04' RESPONSE 88 X'05' CHARSET Optional character set 89 X'10' IDENTIFIER CHAP identifier 90 X'11' ALGORITHMS Supported CHAP algorithms 92 The TEXT-MESSAGE attribute may always be included in any message. 93 Implementations should display its value to the user if applicable; it 94 may be used for advisory information (e.g. warnings of pending 95 password expiration, explanations accompanying a failure.) If there is 96 no user, implementations may log its contents. 98 The CHARSET attribute provides advisory infomration about the 99 character set in use; it, too, may be present in any message. 100 Implementations should use it to guide presentation of information to 101 users. The semantics are identical to that of the charset parameter 102 in MIME [RFC 1521]; if absent, a default of ISO-8859-1 should be 103 assumed. 105 Algorithm Negotiation 107 The CHAP subnegotiation begins with the client sending a message 108 containing the CHAP algorithms it is willing to use (e.g. MD5, MS-CHAP 109 [MS-CHAP]): 111 ALGORITHMS() 113 The server responds with another message of the same form containing 114 the one algorithm to be used for this connection: 116 ALGORITHMS() 118 If the server is unable or unwilling to use any of the algorithms 119 specified by the client, it returns a message indicating failure: 121 STATUS(failure) 123 and closes the connection. 125 Challenge-Response Exchange 127 After the algorithm is negotiated, the server sends a challenge: 129 CHALLENGE(), IDENTIFIER() 131 The client sends an appropriate response: 133 USER-IDENTITY(), RESPONSE(), 134 IDENTIFIER() 136 And the server indicates success or failure: 138 STATUS(success|failure), IDENTIFER() 140 after which the subnegotiation terminates and, upon success, the client 141 should proceed with its request. Upon failure, the server must close 142 the connection. 144 Mutual Authentication 145 Optionally, a client may request mutual authentication by including 146 another CHALLENGE along with its response: 148 USER-IDENTITY(), RESPONSE(), 149 CHALLENGE(), IDENTIFIER() 151 The server should then 152 include a RESPONSE along with the STATUS message: 154 STATUS(success|failure), IDENTIFIER(), 155 RESPONSE() 157 Finally, the client 158 replies with a STATUS message of its own before the subnegotiation 159 terminates 161 STATUS(success|failure) 163 Note that both negotiations employ the same identifier. 164 Whether the same shared secret is used in both directions is outside 165 the scope of this specification, although use of a single secret 166 does not create the same security considerations with SOCKS5 as are present 167 in PPP. 168 Since servers unable or 169 unwilling to do mutual authentication will ignore the client's 170 CHALLENGE, clients should handle a lack of RESPONSE gracefully and 171 either continue or terminate in accordance with security policy. 173 Security Considerations 175 Challenge-response protocols are generally designed to provide 176 protection from passive attacks such as sniffing passwords. CHAP 177 offers limited protection from real-time active attacks. 179 CHAP's integration of hash functions is somewhat behind the current 180 state of the art in MAC design. Servers should change the identifier 181 field with each connection even though it is not required for matching 182 connections, preferably in an unpredictable fashion. Implementations 183 should refuse to respond to too-short challenges, particularly 184 challenges 0 bytes long, as they may give away information about the 185 secret useful to an attacker. Servers should refuse to respond to 186 challenges until verifying the correctness of the client's response. 187 Adding stronger MAC designs, such as HMAC [HMAC-MD5], to CHAP's 188 algorithm suite is a matter for further research. 190 As in all challenge-response security mechanisms, it is important that 191 challenges be produced in a fashion an adversary cannot predict or 192 duplicate. As with all negotiation-based security, implementations 193 may be vulnerable to downgrade attacks. Clients and servers should 194 refuse to operate with methods and algorithms considered 195 insufficiently secure. 197 In the context of a PPP connection, a CHAP challenge may be issued at 198 any time to reconfirm the authentication. This integration permits 199 challenges only during connection establishment and has no provision 200 for reconfirmation. 202 Acknowledgements 204 Thanks to Dave Blob, Wei Lu, Craig Metz, and William Perry for 205 assistance with this document. 207 References 209 [HMAC-MD5] Krawczyk, H., Bellare, M., & Canetti, R., "HMAC-MD5: 210 Keyed-MD5 for Message Authentication," Internet-Draft, work in 211 progress. 213 [MS-CHAP] Cobb, S., "Microsoft PPP CHAP Extensions," Informational 214 Memo, December 1995. 216 [RFC 1521] Borenstein, N, & Freed, N., "MIME (Multipurpose Internet 217 Mail Extensions) Part One: Mechanisms for Specifying and Describing 218 the Format of Internet Message Bodies," September 1993. 220 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & 221 Jones, L., "SOCKS Protocol V5," April 1996. 223 [RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol 224 (CHAP)," August 1996. 226 Author's Address 228 Marc VanHeyningen 229 Aventail Corporation 230 117 S. Main St, Suite 400 231 Seattle, WA 98104 233 Phone: +1 206 777-5600 234 Fax: +1 206 777-5656 235 Email: marcvh@aventail.com