idnits 2.17.1 draft-ietf-aft-socks-maf-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-26) 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. == There are 4 instances of lines with non-ascii characters in the document. == 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 a Security Considerations 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 abstract seems to contain references ([RFC1928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 143 has weird spacing: '...llowing messa...' == Line 171 has weird spacing: '... to success ...' -- 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 (13 March 1998) is 9541 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) -- Missing reference section? 'RFC 1928' on line 197 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Michener & D. Fritch 3 Novell, Inc. 4 Expires 13 September 1998 13 March 1998 6 Multi-Authentication Framework Method 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 areas, 12 and its working groups. Note that other groups may also distribute 13 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-Drafts 18 as reference material or to cite them other than as ``work in 19 progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 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 SOCKS V5 [RFC 1928] provides a means to select one from among a number 30 of authentication methods, but does not provide any means for 31 utilizing multiple authentication methods to obtain desired 32 authentication properties. This document specifies the Multi- 33 Authentication Framework Method (MAF) which is a method extension to 34 SOCKS Version 5 to support the efficient management of composite 35 authentication protocols composed of more than one authentication 36 methods. MAF is a client-initiated but server managed framework. MAF 37 relies upon a trusted Authentication Management Server (AMS) to select 38 the authentication methods to be invoked, order them as appropriate, 39 and assign integrity grades to the final authentication after all 40 methods invoked have been completed. 42 MAF SOCKS V5 Identifier 44 During initial SOCKS V5 negotiation, the client and server negotiate 45 the authentication method. The METHOD ID to invoke the MAF shall be 46 X'??'. 48 Subnegotiation 50 Subnegotiation begins after the client has selected MAF. 51 Subnegotiation is conducted under the control of the server. 53 The client sends an initial version identifier/method selection 54 message: 56 +-------+-----+-------+----------+-----------+ 57 | INSTR | VER | FLAGS | NMETHODS | METHODS | 58 +-------+-----+-------+----------+-----------+ 59 | 1 | 1 | 2 | 4 | 4 to 1020 | 60 +-------+-----+-------+----------+-----------+ 62 The INSTR field is an octet that specifies the operation being 63 performed. Defined values at this time are: 65 X'FF' failure 66 X'00' success 67 X'01' MAF sub-methods supported 68 X'02' request additional MAF sub-methods supported 69 X'03' do 70 X'04' what next? 71 X'05' process 72 X�06' Acknowledge 74 To start the subnegotiation the INSTR field is set to MAF sub-methods 75 supported", X'01'. 77 The VER field is an octet and is set to the version of the MAF 78 framework. At this time VER is set to X'00'. 80 The FLAGS field is a uint16 value. At this time it is set to X'0000'. 81 It provides future tunability for higher versions and serves to word 82 align the data. 84 The NMETHODS field is an octet that contains the number of MAF 85 sub-method identifiers that appear in the METHODS field (1 to 255). If 86 the client has another block of potential sub-methods that it can send 87 to the server, it includes the MORE_METHODS_AVAILABLE method ID as the 88 last method in the list to notify the server to request the next block 89 of methods, if necessary. 91 The METHOD identifiers are 32 bit unsigned int values in network byte 92 order. MAF methods are fixed and inalterable after they have been 93 registered. Consequentially, MAF methods do not have version 94 identification and version incompatibilities are avoided. If a method 95 is found to be inadequate, the revised method should be registered and 96 a new MAF method ID should be issued. 98 The server may select one of the MAF sub-methods given in METHODS (if 99 none of the methods meets the AMS requirements and the client did not 100 note that it had more methods available, the method selected would be 101 FAILURE) and send a DO METHOD command: 103 +-------+-----+-------+--------+-------+--------+ 104 | INSTR | VER | FLAGS | METHOD | LEN | DATA | 105 +-------+-----+-------+--------+-------+--------+ 106 | 1 | 1 | 2 | 4 | 4 | LEN | 107 +-------+-----+-------+--------+-------+--------+ 109 The INSTR field is set to "do", X'03'. As above, the VER field is set 110 to version of the MAF parent method. At this time VER is set to X'00' 111 and the FLAGS field is set to X'0000'. The MAF sub-method ID being 112 performed is entered into the METHOD field. Data being transported 113 between the client and server modules is sent in the DATA section as a 114 (void) array, with the length of the array specified in the LEN field. 116 If the server instructs the client to send more methods, via the X'02' 117 request additional MAF sub-methods supported command , the server 118 will use the FLAGS field to specify a relative method download 119 (instructing the cleint to send only methods that have not already 120 been sent) or an absolute method download (instructing the client to 121 start again with the method list). The FLAGS field will be X�0000' 122 for a relative method download and X�0001' for an absolute method 123 download. 125 The client and the server then call the appropriate modules to execute 126 the specified function. The exchange between the selected client and 127 server modules will utilize the following data structure. 129 +-------+-----+-------+--------+-------+--------+ 130 | INSTR | VER | FLAGS | METHOD | LEN | DATA | 131 +-------+-----+-------+--------+-------+--------+ 132 | 1 | 1 | 2 | 4 | 4 | LEN | 133 +-------+-----+-------+--------+-------+--------+ 135 The INSTR field is set to "process", X'05'. At this time VER is set 136 to X'00'and the FLAGS field is set to X'0000'. The MAF sub-method ID 137 is specified by the METHOD variable. If any data or parameters are to 138 be sent to the method, they are sent in the DATA section as a (void) 139 array, with the length of the array specified in the LEN field. 141 The client and server method modules return success or failure to both 142 the client and server, respectively. In all cases, the client sends 143 the following message to the server. 145 +-------+-----+-------+ 146 | INSTR | VER | FLAGS | 147 +-------+-----+-------+ 148 | 1 | 1 | 2 | 149 +-------+-----+-------+ 151 The INSTR field is set to "what next?", X'04'. At this time VER is 152 set to X'00' and the FLAGS field is set to X'0000'. 154 In event of failure of an authentication method or of the 155 authentication process, the server may instruct the client to close 156 the connection. If the sub-method was successful or if the sub-method 157 failed and the server did not instruct the client to close the 158 connection, the server may instruct the client to execute another MAF 159 sub-method module. 161 At the end of the process, as determined by the server, the server 162 will send back: 164 +-------+-----+-------+--------+-------+--------+ 165 | INSTR | VER | FLAGS | METHOD | LEN | DATA | 166 +-------+-----+-------+--------+-------+--------+ 167 | 1 | 1 | 2 | 4 | 4 | LEN | 168 +-------+-----+-------+--------+-------+--------+ 170 If the authentication process succeeded, the INSTR field will be set 171 to success , X'00' and the method ID is set to SUCCESS, X'00000000'. 172 If the authentication process failed, the INSTR field will be set to 173 failure , X'FF' and the method ID is set to FAILURE, X'FFFFFFFF'. In 174 either case, at this time VER is set to X'00' and the FLAGS field is 175 set to X'0000'. If any data or parameters are to be sent to the 176 process to be run upon successful authentication, they are sent in the 177 DATA section as a (void) array, with the length of the array specified 178 in the LEN field. 180 Current MAF Sub-Methods: 182 X'FFFFFFFF' FAILURE 183 X'00000000' SUCCESS 184 X'00000001' Internal Test Method 185 X'00000002' MORE_METHODS_AVAILABLE 186 X'00000003' 187 To 188 X�0000FFFF� Reserved for proprietary methods 189 X'00010000'up MAF general authentication method numbers 191 Acknowledgements 193 Thanks to Russel Weiser for assistance with this document. 195 References 197 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & 198 Jones, L., "SOCKS Protocol V5," April 1996. 200 Author's Address 202 John Michener 203 Novell, Inc. 204 122 East 1700 South 205 Provo Utah, 84606-6194 207 Phone: +1 801 861-5478 208 Fax: +1 801 861-2522 209 Email: jmichener@novell.com 211 Dan Fritch 212 Novell, Inc. 213 122 East 1700 South 214 Provo Utah, 84606-6194 216 Phone: +1 801 861-5136 217 Fax: +1 801 861-2522 218 Email: dfritch@novell.com