idnits 2.17.1 draft-ietf-aft-socks-maf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 67 lines 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 document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([1], [RFC1928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (9 August 1999) is 9024 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 417 looks like a reference -- Missing reference section? '1' on line 420 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Michener, D. Fritch, M. Gayman 2 Novell, Inc. 3 Expires 9 February 2000 9 August 1999 5 Multi-Authentication Framework Method for SOCKS V5 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups MAY also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and MAY be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as ``work in progress.'' 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To view the entire list of current Internet-Drafts, please check the 29 ``lid abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 31 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 32 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 SOCKS V5 [RFC 1928] provides a means to select one from among a number 37 of authentication methods but does not provide any means for utilizing 38 multiple authentication methods to obtain certain desired authentication 39 properties. 41 MAF is a client-initiated but server-managed framework. MAF relies on a 42 trusted Authentication Management Server (AMS) to: 1) Select the 43 authentication methods to be invoked, 2) order the execution of methods 44 at the client, as appropriate, and 3) assign integrity grades to the 45 final, composite authentication after all methods that were invoked have 46 completed. 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119. 52 Please send comments on this document to the aft@socks.nec.com mailing 53 list. 55 1. Introduction 57 During an initial SOCKS V5 negotiation, the client and server negotiate 58 an authentication method. 60 The METHOD value to invoke this proposed multi authentication framework 61 (MAF) SHALL be X'08' (this value falls within the IANA assigned range 62 indicated in RFC 1928 and was assigned by IANA to this proposed method 63 in August 1998.) 65 128-bit (16-byte) UUIDs (Universally Unique Identifiers, as defined in 66 [1]) are one form of method identifier used in this protocol. GUIDs 67 (Globally Unique Identifiers), such as those generated by development 68 tools from Microsoft, Incorporated, are suitable as UUIDs. 70 Unless otherwise specified, all integer values larger than one byte will 71 appear in the protocol messages in most-significant byte first order, 72 i.e., network order. 74 2. Sub-negotiation 76 Sub-negotiation, as defined by the SOCKS V5 protocol, begins after the 77 client has selected the MAF method within the SOCKS protocol. All 78 aspects of sub-negotiation are conducted under the control of the 79 server. 81 The client sends an initial MAF version identifier and potential methods 82 list message to the server: 84 |-------+-----+-------+-----------+------------+---------+ 85 | INSTR | VER | FLAGS | NCMETHODS | LENGTH OF | COMPACT | 86 | | | | (n) | METHOD IDS | METHODS | 87 |-------+-----+-------+-----------+------------+---------+ 88 | 1 | 1 | 2 | 1 | 1 (4) | 4 x n | 89 |-------+-----+-------+-----------+------------+---------+ 90 | 91 V 92 +------------------------------------------------------+ 93 | 94 V 95 [ +-----------+------------+---------+ ] +---------| 96 [ | NLMETHODS | LENGTH OF | LONG | ] | END OF | 97 [ | (m) | METHOD IDS | METHODS | ] | METHODS | 98 [ +-----------+------------+---------+ ] . . . +---------| 99 [ | 1 | 1 (16) | 16 x m | ] | 1 (0) | 100 [ +-----------+------------+---------+ ] +---------| 102 The INSTR field is a byte that specifies the operation being performed. 103 The values defined at this time, and their colloquial names (in 104 parentheses, if established), and the direction of the message (client 105 to server, server to client, or either) are: 107 X'FF' Failure and disconnect (Failure), server to client 108 X'00' Success (Done), server to client 109 X'01' MAF methods supported (Can Do or List), client to server 110 X'02' Request additional MAF methods supported (Send More Can 111 Do), server to client 112 X'03' Do, server to client 113 X'04' What next, client to server 114 X'05' Process, either 115 X'06' Acknowledge, either 116 X'07' Process OEM specific (OEM), either 118 To start the sub-negotiation the INSTR field is set to ``MAF methods 119 supported'' (Can Do), X'01'. 121 The VER field is a byte and is set to the version of the MAF protocol. 122 At this time VER will be X'01'. 124 The FLAGS field is an unsigned 16-bit value. At this time it is set to 125 X'0000'. It provides for future tuning or extensions of the protocol. 127 The MAF method identifiers in this second version of the design have two 128 possible formats: A compact or short format consisting of well known 32 129 bit (4-byte) unsigned integer values and a long format consisting of 128 130 bit (16-byte) UUIDs. Compact MAF methods IDs are fixed and unalterable 131 after they have been registered (by the IANA or other authority). UUIDs 132 are fixed and unalterable after they have been generated and then 133 employed to identify a particular vendor's method. Consequentially, MAF 134 methods do not have any version identifications per se and many common 135 version incompatibilities are thus avoided. If a method is later found 136 to be inadequate, the revised compact method identifier SHOULD be 137 registered or a new UUID generated by the vendor and the replacement MAF 138 method module SHOULD be released. A bug found in a released method MAY 139 require a new identifier or MAY retain its former UUID or registered 140 identifier, depending on the nature of the bug and the distribution of 141 the method. 143 NCMETHODS is a byte containing the number of 32-bit compact method IDs 144 in the COMPACT METHODS field that follows the first LENGTH OF METHOD IDS 145 field, which has a fixed value of 4 above. NLMETHODS is the number of 146 16 byte UUIDs in the LONG METHODS field that follows the second LENGTH 147 OF METHOD IDS field, which has a fixed value of 16 above. A single byte 148 of 0 follows the last long format method ID. The 32-bit compact method 149 IDs are, as stated in the abstract section, in most-significant byte 150 first order and they are not necessarily aligned on 4-byte boundaries in 151 the packet. The byte values in the 16-byte UUIDs are in their standard 152 order as defined by the reference above to the OSF DCE document that 153 describes the algorithm for generating them. 155 If the client has more MAF method IDs, in either compact or long form, 156 that it can send to the server, the client includes the compact method 157 ID X'00000002' anywhere in the list of 32-bit values to notify the 158 server that more IDs are available. 160 It is the prerogative of the server whether or not to ask for the 161 additional method IDs by sending to the client a reply with a value of 162 X'02' in the INSTR field (Send More Can Do) with a value of X'01' in 163 VER. 165 The packet diagrammed above is a specific instance of the general design 166 for this message, which allows the method IDs to be any size from 1 to 167 255 bytes and allows from 1 to 255 methods of the same length to be 168 grouped together. The three fields bracketed by [ and ] constitute the 169 general structure that can be repeated as needed in the message, with 170 different values. The last byte of 0 (which would be the number of 171 methods in the next grouping) is always present after the last group of 172 method IDs. To simplify the logic of constructing this packet, all 173 method IDs of the same length SHOULD be sent together in the message. 174 In consideration of future method IDs of lengths other than 4 and 16, it 175 is likely that the length of a method ID will implicitly indicate the 176 identification space of the value, i.e., an ID that is 4 bytes long is a 177 registered compact format ID, an ID of 16 bytes is a long format UUID, 178 etc. Two IDs of the same value (disregarding more significant bytes of 179 zeroes or encoding differences) will likely not identify the same method 180 if they are of different lengths, e.g., a future one byte ID of 0x09 181 will not be the same as a four byte ID of 0x00000009. 183 Nothing SHOULD be imputed or inferred from the order of the method IDs 184 (either compact or long) in the data sent from the client to the server 185 in this packet. Thus it is allowed that the compact method IDs could 186 follow the UUIDs. Either format of IDs could also be absent from the 187 message. 189 The server MAY select one of the MAF methods identified in either 190 METHODS field (if none of the methods would meet the requirements of 191 authentication policies on the server and the client did not indicate 192 that more method IDs were available, the value of the method selected 193 would be Failure) and send a Do command: 195 |-------+-----+-------+------+--------| 196 | INSTR | VER | FLAGS | MLEN | METHOD | 197 |-------+-----+-------+------+--------| 198 | 1 | 1 | 2 | 1 | MLEN | 199 |-------+-----+-------+------+--------| 201 The INSTR field is set to ``Do'', X'03'. As above, the VER field is set 202 to the version of the MAF protocol. At this time VER is set to X'01' 203 and the FLAGS field is set to X'0000'. The MAF method ID to be 204 performed is entered in the METHOD field. The length of this field in 205 bytes is the value of the single byte MLEN, either 4 for a compact 206 method identifier or 16 for a long identifier. 208 If the server instructs the client to send more method IDs, via the 209 X'02' ``Request additional MAF methods supported'' instruction, the 210 server will use the FLAGS field to specify either a relative list (the 211 client is to send only methods IDs that have not already been sent) or 212 an absolute list (the client is to start sending the method IDs again as 213 the original list, starting with the first method ID it sent). The 214 FLAGS field will be X'0000' for a relative method ID list or X'0001' for 215 an absolute method ID list. 217 The client and the server protocol managers then call the appropriate 218 executable modules, or subroutines, to run the specified authentication 219 method. It is anticipated that each method would be a separate binary, 220 executable file. The mapping of method IDs, in either compact or long 221 form, to the names and paths of the files containing the executable code 222 is an implementation issue and is not addressed here. The exchange 223 between the selected client and server modules will use the following 224 data packet: 226 |-------+-----+-------+------+--------+--------+-------+--------| 227 | INSTR | VER | FLAGS | MLEN | METHOD | PAD | DLEN | DATA | 228 |-------+-----+-------+------+--------+--------+-------+--------| 229 | 1 | 1 | 2 | 1 | MLEN | 0 to 3 | 4 | DLEN | 230 |-------+-----+-------+------+--------+--------+-------+--------| 232 The INSTR field is set to ``Process'', X'05'. As above, the VER field is 233 set to the version of the MAF protocol. At this time VER is set to 234 X'01' and the FLAGS field is set to X'0000'. The ID of the MAF method 235 being performed is present in the METHOD field. The length of this 236 field in bytes is the value of the single byte MLEN, either 4 for a 237 compact method identifier or 16 for a long identifier. The particular 238 data being processed is sent to the client from server or from the 239 server to the client in the DATA field as a byte array, with the length 240 of the array specified in the DLEN field. The PAD field is 0 to 3 bytes 241 of unspecified values to align the DLEN field to a 4-byte boundary 242 relative to the beginning of the packet. 244 Exchange of data between the method on the client and the method on the 245 server, via ``Process'' packets, continues as long as the two need to 246 run during the particular authentication process. 248 The client and server methods return success or failure to their 249 respective client and server protocol manager modules. In either 250 outcome case, the client sends the following message to the server: 252 |-------+-----+-------| 253 | INSTR | VER | FLAGS | 254 |-------+-----+-------| 255 | 1 | 1 | 2 | 256 |-------+-----+-------| 258 The INSTR field is set to ``What next'', X'04'. At this time VER is set 259 to X'01' and the FLAGS field is set to X'0000'. 261 In the event of failure of an authentication method or of the 262 authentication process, the server MAY instruct the client to close 263 (disconnect) the connection. 265 If the method succeeded, or if it failed and the server does not need to 266 direct the client to close the connection, the server MAY instruct the 267 client to execute another MAF method module. 269 At the end of the process, as determined by policies and controls on the 270 server, the server will send the following in response to ``What next'': 272 |-------+-----+-------+------+--------| 273 | INSTR | VER | FLAGS | MLEN | METHOD | 274 |-------+-----+-------+------+--------| 275 | 1 | 1 | 2 | 1 | MLEN | 276 |-------+-----+-------+------+--------| 278 If the composite authentication process succeeded, the INSTR field will 279 be set to ``Success'', X'00', MLEN to 4, and METHOD to Success, 280 X'00000000'. If the authentication process failed, the INSTR field will 281 be set to ``Failure'', X'FF', MLEN to 4, and METHOD to Failure, 282 X'FFFFFFFF'. In either outcome case, VER is set to X'00' and FLAGS is 283 set to X'0000'. 285 Upon receipt of either the ``Success'' or ``Failure'' messages by the 286 client, the client will send an acknowledgement to the server. The 287 server will indicate reception of the acknowledge by replying with an 288 acknowledge message as well: 290 |-------+-----+-------| 291 | INSTR | VER | FLAGS | 292 |-------+-----+-------| 293 | 1 | 1 | 2 | 294 |-------+-----+-------| 296 The INSTR field is set to ``Acknowledge'', X'06'. At this time VER is 297 set to X'01' and the FLAGS field is set to X'0000'. The acknowledge 298 message serves to synchronize the MAF protocol client and the server. 300 3. Process OEM Specific 302 The ``Process OEM specific'' instruction, X'07', provides a mechanism 303 for the client and server MAF protocol managers to exchange data before 304 or after a method has been invoked (when a given method is running on 305 the client and server, the implementers are free to use the data field 306 of the ``Process'' message to implement any form of communication 307 between the client and the server modules.) The server can send an 308 ``OEM'' message only in response to ``What next'', ``Can Do'', or 309 ``OEM'' messages from the client. 311 The client can send an ``OEM'' message to the server before sending a 312 ``Can Do'' or ``What next'' message or in response to a previous 313 ``Process OEM specific'', ``Success'', or ``Failure'' message from the 314 server. When one end sends an ``OEM'' message the other end MUST respond 315 with an ``OEM'' message as an acknowledgment. The acknowledgment 316 message can contain no significant data, if desired. When the exchange 317 of ``OEM'' messages is complete, the protocol managers continue with the 318 standard aspects of MAF. 320 The ``Process OEM specific'' message is composed as follows: 322 |-------+-----+-------+----------+---------+--------+--------+ 323 | INSTR | VER | FLAGS | RESERVED | OEM ID | OEM ID | PAD | 324 | | | | ZEROES | LEN (n) | | BYTES | 325 |-------+-----+-------+----------+---------+--------+--------+ 326 | 1 | 1 | 2 | 3 | 1 | n | 0 to 3 | 327 |-------+-----+-------+----------+---------+--------+--------+ 328 | 329 V 330 +------------------------------------------------------------+ 331 | 332 V 333 +-------+------| 334 | DLEN | DATA | 335 | (m) | | 336 +-------+------| 337 | 4 | m | 338 +-------+------| 340 The INSTR field is set to ``OEM'', X'07'. As above, the VER field is set 341 to the version of the MAF protocol. At this time VER is set to X'01' and 342 the FLAGS field is set to X'0000'. The RESERVED ZEROES field is for 343 future use or features. The length in bytes of the OEM ID field is 344 entered into the OEM ID LEN field. In this version of MAF, the length 345 will be either 4 for compact OEM IDs or 16 for long OEM IDs that are 346 UUIDs. The particular data being processed is sent from one end to the 347 other in the DATA field as a byte array, with the length of the array 348 specified in the DLEN field. The PAD BYTES field is 0 to 3 bytes of 349 unspecified values to align the DLEN field to a 4-byte boundary relative 350 to the beginning of the packet (for the 4- or 16-byte OEM IDs proposed 351 here, this field is absent.) For an acknowledgment message, DLEN can be 352 zero. 354 If the client or server receives an ``OEM'' message with an OEM ID that 355 it does not recognize or support, it will reply with an ``OEM'' message 356 with the OEM ID set to X'FFFFFFFF' and DLEN set to 0 to so indicate. 358 3.1 Current Compact OEM IDs 360 X'FFFFFFFF' OEM ID not recognized or supported 362 X'00000000' Internal Test IDs 363 To 364 X'00000003' 366 X'00000004' Reserved 368 X'00000005' 369 To Reserved for proprietary IDs, assigned by 370 X'0000FFFF' Novell 372 X'00010000' and up General IDs, assigned by the IANA 374 3.2 Current Compact MAF Method IDs 376 X'FFFFFFFF' Failure 378 X'00000000' Success 380 X'00000001' Internal Test Method ID 382 X'00000002' More method IDs are available 384 X'00000003' Reserved 386 X'00000004' Reserved 388 X'00000005' 389 To Reserved for proprietary method IDs, assigned 390 X'0000FFFF' by Novell 391 X'00010000' and up General MAF authentication method IDs, 392 assigned by the IANA 394 4. Security Considerations 396 MAF enables the efficient combination of multiple authentication 397 mechanisms (allowing the combination of something the user holds, 398 something the user knows, and something the user is). This allows for 399 the reliable establishment of user identity during the authentication 400 session if the methods are appropriately chosen and appropriately 401 managed. The selection of methods and their management are not addressed 402 by MAF. Improper selection of methods and inappropriate management of 403 the authentication process can invalidate any authentication, including 404 that provided by MAF. 406 If critical data such as long-term passwords or biometric data are 407 exchanged between the client and the server, appropriate steps SHOULD be 408 taken to secure it at the client (so that an attacker cannot acquire 409 this data), to secure it over the communications channel (using 410 encryption), and to secure this data and its processing at the server. 411 Without appropriate security and integrity at each link in the 412 authentication process, the integrity of the authentication cannot be 413 assured. 415 5. References 417 [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., & 418 Jones, L., ``SOCKS Protocol V5'', April 1996. 420 [1] Steven Miller, ``DEC/HP Network Computing Architecture Remote 421 Procedure Call RunTime Extension Specification Version OSF TX1.0.11'', 422 July 23, 1992. 424 6. Acknowledgements 426 We express our thanks to Tolga Acar, Fred Ghiradelli, Tammy Green, and 427 Hal Henderson for assistance in the development of this document. 429 7. Authors' Addresses 431 John Michener 432 Novell, Inc. 433 122 East 1700 South 434 Provo Utah, 84606-6194 436 Phone: +1 801 861-7000 437 Fax: +1 801 861-2522 438 Email: jmichener@novell.com 440 Dan Fritch 441 Novell, Inc. 442 122 East 1700 South 443 Provo Utah, 84606-6194 444 Phone: +1 801 861-7000 445 Fax: +1 801 861-2522 446 Email: dfritch@novell.com 448 Mark Gayman 449 Novell, Inc. 450 122 East 1700 South 451 Provo Utah, 84606-6194 453 Phone: +1 801 861-7000 454 Fax: +1 801 861-2522 455 Email: mgayman@novell.com 457 8. Full Copyright Statement 459 Copyright (C) The Internet Society (1999). All Rights Reserved. 461 This document and translations of it may be copied and furnished to 462 others, and derivative works that comment on or otherwise explain it or 463 assist in its implmentation may be prepared, copied, published and 464 distributed, in whole or in part, without restriction of any kind, 465 provided that the above copyright notice and this paragraph are included 466 on all such copies and derivative works. However, this document itself 467 may not be modified in any way, such as by removing the copyright notice 468 or references to the Internet Society or other Internet organizations, 469 except as needed for the purpose of developing Internet standards in 470 which case the procedures for copyrights defined in the Internet 471 Standards process must be followed, or as required to translate it into 472 languages other than English. 474 The limited permissions granted above are perpetual and will not be 475 revoked by the Internet Society or its successors or assigns. 477 This document and the information contained herein is provided on an "AS 478 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 479 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 480 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 481 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 482 FITNESS FOR A PARTICULAR PURPOSE."