idnits 2.17.1 draft-ietf-aft-socks-ssl-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-03-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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1929], [SOCKS-CHAP], [RFC1961]), 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 9861 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 150, but no explicit reference was found in the text == Unused Reference: 'SSL' is defined on line 163, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SOCKS-CHAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' Summary: 11 errors (**), 0 flaws (~~), 3 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 Secure Sockets Layer for SOCKS Version 5 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 ABSTRACT 23 This document specifies the use of SSL 3.0 and possible successor 24 protocols as an authentication method for SOCKS Version 5. The 25 design is similar to, and largely derived from, the integration of 26 GSS-API into SOCKS5 [RFC 1961]. A framework is provided for future 27 extensions, and the use of other "subauthentication" methods inside 28 SSL is supported. 30 SSL METHOD IDENTIFIER 32 During the initial SOCKS V5 negotiation, an authentication method is 33 negotiated. The identifier used in the SOCKS5 authentication 34 handshake for this method shall be X'86' (134 decimal.) 36 SSL RECORD FRAMING 38 The SSL data stream is wrapped for transport over the SOCKS5 data 39 stream as follows: 41 +-----+-------+-----+-------- 42 | VER | STATE | LEN | DATA 43 +-----+-------+-----+-------- 44 | 1 | 1 | 2 | 0 - 65535 45 +-----+-------+-----+-------- 47 The VER shall be X'01 for this revision. The STATE may have four 48 different values: 50 Initial handshake X'01' 51 Option negotiation X'02' 52 Data flow X'03' 53 Closing handshake X'04' 55 LEN specifies the number of bytes in the DATA, and shall be MSB-first. 57 SSL PROCEDURE 59 After the server selects SSL as its authentication method, an initial 60 handshake to establish an SSL-secured connection commences with STATE 61 of X'01'. 63 SSL specific options 65 After this handshake all subsequent data is secured via SSL, then in 66 the framing specified above. With STATE of X'02', the client sends a 67 list of SSL-specific options it can support: 69 +-----+---------- 70 | LEN | OPTIONS 71 +-----+---------- 72 | 1 | 0-255 73 +-----+---------- 75 The server responds with an identically formatted list of the subset 76 of options to be used for this connection. 78 At this time, only two options are defined: 80 Subauthentication X'01' 81 UDP-Naked X'10' 83 UDP-Naked 85 With SSL integration, the handling of UDP data is a tricky issue. 86 Unlike GSSAPI-based solutions, SSL is not designed to handle datagram 87 traffic. UDP-Naked specifies that SSL shall be used only to protect 88 the control connection of the UDP association, and UDP traffic will 89 receive no enhancements. 91 It is expected that other options for UDP processing will be defined; 92 in general it is expected that the server will choose one UDP method 93 from those offered by the client. 95 Subauthentication 97 Subauthentication provides a mechanism for embedding a simpler 98 authentication mechanism inside SSL. For example, some environments 99 may use SSL with server-side certificates to establish a secure 100 connection to a server, then use cleartext passwords [RFC 1929] inside 101 the encrypted connection. 103 If the server's option handshake specifies that subauthentication is 104 to be used, the client responds with a message specifying the 105 authentication methods it supports in this environment; the format is 106 identical to that of [RFC 1928, sec 3]. 108 After negotiating a subauthentication method, subauthentication 109 proceeds exactly as it would normally, but inside the SSL-secured data 110 stream. It is expected that only primitive authentication techniques, 111 such as cleartext passwords or CHAP [SOCKS-CHAP], will be used as 112 subauthentitcation methods. 114 Command processing 116 After option processing is complete, the authentication method 117 finishes. STATE is set to X'03', and the SOCKS command commences. 119 Orderly closure 121 Upon connection termination, the terminating side should change STATE 122 to X'04' and send an SSL closure handshake; the other side should also 123 change its STATE and respond appropriately. 125 SECURITY CONSIDERATIONS 127 As with any negotiation-based mechanism, SOCKS5 is subject to 128 downgrade attacks. Both clients and servers should operate only with 129 security parameters consistent with the given security policy. 131 The UDP-Naked option, as its name suggests, provides very minimal 132 security for UDP traffic. It allows subauthentication and initial 133 commands which may specifiy destination and other use restrictions on 134 a UDP association to be established securely, but it does nothing to 135 preserve the privacy or integrity of the bulk data. More secure 136 methods of proxying UDP traffic may be added as additional 137 SSL-specific options. 139 All SSL-based considerations, such as the importance of properly 140 seeding random generators used to generate keying information and 141 storing persistent keying information in secure ways, apply here. 143 SSL 2.0 has known weakness and limitations. Since there is no 144 existing base of software using this specification based on SSL 2.0, 145 applications may support SSL 3.0 (or later) only without compromising 146 interoperability. 148 REFERENCES 150 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & 151 Jones, L., "SOCKS Protocol V5," April 1996. 153 [RFC 1929] Leech, M., "Username/Password Authentication for SOCKS V5," 154 March 1996. 156 [RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS 157 Version 5," June 1996. 159 [SOCKS-CHAP] VanHeyningen, M., "Challenge-Handshake Authentication 160 Protocol for SOCKS V5," , March 1997, 161 work in progress. 163 [SSL] Freier, A., Karlton, P., Kocher, P., "The SSL Protocol: Version 164 3.0," , November 1996, work in 165 progress. 167 AUTHOR'S ADDRESS 169 Marc VanHeyningen 170 Aventail Corporation 171 117 S. Main Street, Suite 400 172 Seattle, WA 98104 174 Phone: +1 206 777-5600 175 Fax: +1 206 777-5656 176 Email: marcvh@aventail.com