INTERNET-DRAFT J. Michener, D. Fritch, M. Gayman
<draft-ietf-aft-socks-maf-01.txt> Novell, Inc.
Expires 9 February 2000 9 August 1999
Multi-Authentication Framework Method for SOCKS V5
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups MAY also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and MAY be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the
``lid abstracts.txt'' listing contained in the Internet-Drafts Shadow
directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
SOCKS V5 [RFC 1928] provides a means to select one from among a number
of authentication methods but does not provide any means for utilizing
multiple authentication methods to obtain certain desired authentication
properties.
MAF is a client-initiated but server-managed framework. MAF relies on a
trusted Authentication Management Server (AMS) to: 1) Select the
authentication methods to be invoked, 2) order the execution of methods
at the client, as appropriate, and 3) assign integrity grades to the
final, composite authentication after all methods that were invoked have
completed.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Please send comments on this document to the aft@socks.nec.com mailing
list.
1. Introduction
During an initial SOCKS V5 negotiation, the client and server negotiate
an authentication method.
The METHOD value to invoke this proposed multi authentication framework
(MAF) SHALL be X'08' (this value falls within the IANA assigned range
indicated in RFC 1928 and was assigned by IANA to this proposed method
in August 1998.)
128-bit (16-byte) UUIDs (Universally Unique Identifiers, as defined in
Michener, et al. Expires 9 February 2000 [Page 1]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
[1]) are one form of method identifier used in this protocol. GUIDs
(Globally Unique Identifiers), such as those generated by development
tools from Microsoft, Incorporated, are suitable as UUIDs.
Unless otherwise specified, all integer values larger than one byte will
appear in the protocol messages in most-significant byte first order,
i.e., network order.
2. Sub-negotiation
Sub-negotiation, as defined by the SOCKS V5 protocol, begins after the
client has selected the MAF method within the SOCKS protocol. All
aspects of sub-negotiation are conducted under the control of the
server.
The client sends an initial MAF version identifier and potential methods
list message to the server:
|-------+-----+-------+-----------+------------+---------+
| INSTR | VER | FLAGS | NCMETHODS | LENGTH OF | COMPACT |
| | | | (n) | METHOD IDS | METHODS |
|-------+-----+-------+-----------+------------+---------+
| 1 | 1 | 2 | 1 | 1 (4) | 4 x n |
|-------+-----+-------+-----------+------------+---------+
|
V
+------------------------------------------------------+
|
V
[ +-----------+------------+---------+ ] +---------|
[ | NLMETHODS | LENGTH OF | LONG | ] | END OF |
[ | (m) | METHOD IDS | METHODS | ] | METHODS |
[ +-----------+------------+---------+ ] . . . +---------|
[ | 1 | 1 (16) | 16 x m | ] | 1 (0) |
[ +-----------+------------+---------+ ] +---------|
The INSTR field is a byte that specifies the operation being performed.
The values defined at this time, and their colloquial names (in
parentheses, if established), and the direction of the message (client
to server, server to client, or either) are:
X'FF' Failure and disconnect (Failure), server to client
X'00' Success (Done), server to client
X'01' MAF methods supported (Can Do or List), client to server
X'02' Request additional MAF methods supported (Send More Can
Do), server to client
X'03' Do, server to client
X'04' What next, client to server
X'05' Process, either
X'06' Acknowledge, either
X'07' Process OEM specific (OEM), either
To start the sub-negotiation the INSTR field is set to ``MAF methods
supported'' (Can Do), X'01'.
Michener, et al. Expires 9 February 2000 [Page 2]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
The VER field is a byte and is set to the version of the MAF protocol.
At this time VER will be X'01'.
The FLAGS field is an unsigned 16-bit value. At this time it is set to
X'0000'. It provides for future tuning or extensions of the protocol.
The MAF method identifiers in this second version of the design have two
possible formats: A compact or short format consisting of well known 32
bit (4-byte) unsigned integer values and a long format consisting of 128
bit (16-byte) UUIDs. Compact MAF methods IDs are fixed and unalterable
after they have been registered (by the IANA or other authority). UUIDs
are fixed and unalterable after they have been generated and then
employed to identify a particular vendor's method. Consequentially, MAF
methods do not have any version identifications per se and many common
version incompatibilities are thus avoided. If a method is later found
to be inadequate, the revised compact method identifier SHOULD be
registered or a new UUID generated by the vendor and the replacement MAF
method module SHOULD be released. A bug found in a released method MAY
require a new identifier or MAY retain its former UUID or registered
identifier, depending on the nature of the bug and the distribution of
the method.
NCMETHODS is a byte containing the number of 32-bit compact method IDs
in the COMPACT METHODS field that follows the first LENGTH OF METHOD IDS
field, which has a fixed value of 4 above. NLMETHODS is the number of
16 byte UUIDs in the LONG METHODS field that follows the second LENGTH
OF METHOD IDS field, which has a fixed value of 16 above. A single byte
of 0 follows the last long format method ID. The 32-bit compact method
IDs are, as stated in the abstract section, in most-significant byte
first order and they are not necessarily aligned on 4-byte boundaries in
the packet. The byte values in the 16-byte UUIDs are in their standard
order as defined by the reference above to the OSF DCE document that
describes the algorithm for generating them.
If the client has more MAF method IDs, in either compact or long form,
that it can send to the server, the client includes the compact method
ID X'00000002' anywhere in the list of 32-bit values to notify the
server that more IDs are available.
It is the prerogative of the server whether or not to ask for the
additional method IDs by sending to the client a reply with a value of
X'02' in the INSTR field (Send More Can Do) with a value of X'01' in
VER.
The packet diagrammed above is a specific instance of the general design
for this message, which allows the method IDs to be any size from 1 to
255 bytes and allows from 1 to 255 methods of the same length to be
grouped together. The three fields bracketed by [ and ] constitute the
general structure that can be repeated as needed in the message, with
different values. The last byte of 0 (which would be the number of
methods in the next grouping) is always present after the last group of
method IDs. To simplify the logic of constructing this packet, all
method IDs of the same length SHOULD be sent together in the message.
In consideration of future method IDs of lengths other than 4 and 16, it
Michener, et al. Expires 9 February 2000 [Page 3]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
is likely that the length of a method ID will implicitly indicate the
identification space of the value, i.e., an ID that is 4 bytes long is a
registered compact format ID, an ID of 16 bytes is a long format UUID,
etc. Two IDs of the same value (disregarding more significant bytes of
zeroes or encoding differences) will likely not identify the same method
if they are of different lengths, e.g., a future one byte ID of 0x09
will not be the same as a four byte ID of 0x00000009.
Nothing SHOULD be imputed or inferred from the order of the method IDs
(either compact or long) in the data sent from the client to the server
in this packet. Thus it is allowed that the compact method IDs could
follow the UUIDs. Either format of IDs could also be absent from the
message.
The server MAY select one of the MAF methods identified in either
METHODS field (if none of the methods would meet the requirements of
authentication policies on the server and the client did not indicate
that more method IDs were available, the value of the method selected
would be Failure) and send a Do command:
|-------+-----+-------+------+--------|
| INSTR | VER | FLAGS | MLEN | METHOD |
|-------+-----+-------+------+--------|
| 1 | 1 | 2 | 1 | MLEN |
|-------+-----+-------+------+--------|
The INSTR field is set to ``Do'', X'03'. As above, the VER field is set
to the version of the MAF protocol. At this time VER is set to X'01'
and the FLAGS field is set to X'0000'. The MAF method ID to be
performed is entered in the METHOD field. The length of this field in
bytes is the value of the single byte MLEN, either 4 for a compact
method identifier or 16 for a long identifier.
If the server instructs the client to send more method IDs, via the
X'02' ``Request additional MAF methods supported'' instruction, the
server will use the FLAGS field to specify either a relative list (the
client is to send only methods IDs that have not already been sent) or
an absolute list (the client is to start sending the method IDs again as
the original list, starting with the first method ID it sent). The
FLAGS field will be X'0000' for a relative method ID list or X'0001' for
an absolute method ID list.
The client and the server protocol managers then call the appropriate
executable modules, or subroutines, to run the specified authentication
method. It is anticipated that each method would be a separate binary,
executable file. The mapping of method IDs, in either compact or long
form, to the names and paths of the files containing the executable code
is an implementation issue and is not addressed here. The exchange
between the selected client and server modules will use the following
data packet:
|-------+-----+-------+------+--------+--------+-------+--------|
| INSTR | VER | FLAGS | MLEN | METHOD | PAD | DLEN | DATA |
|-------+-----+-------+------+--------+--------+-------+--------|
Michener, et al. Expires 9 February 2000 [Page 4]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
| 1 | 1 | 2 | 1 | MLEN | 0 to 3 | 4 | DLEN |
|-------+-----+-------+------+--------+--------+-------+--------|
The INSTR field is set to ``Process'', X'05'. As above, the VER field is
set to the version of the MAF protocol. At this time VER is set to
X'01' and the FLAGS field is set to X'0000'. The ID of the MAF method
being performed is present in the METHOD field. The length of this
field in bytes is the value of the single byte MLEN, either 4 for a
compact method identifier or 16 for a long identifier. The particular
data being processed is sent to the client from server or from the
server to the client in the DATA field as a byte array, with the length
of the array specified in the DLEN field. The PAD field is 0 to 3 bytes
of unspecified values to align the DLEN field to a 4-byte boundary
relative to the beginning of the packet.
Exchange of data between the method on the client and the method on the
server, via ``Process'' packets, continues as long as the two need to
run during the particular authentication process.
The client and server methods return success or failure to their
respective client and server protocol manager modules. In either
outcome case, the client sends the following message to the server:
|-------+-----+-------|
| INSTR | VER | FLAGS |
|-------+-----+-------|
| 1 | 1 | 2 |
|-------+-----+-------|
The INSTR field is set to ``What next'', X'04'. At this time VER is set
to X'01' and the FLAGS field is set to X'0000'.
In the event of failure of an authentication method or of the
authentication process, the server MAY instruct the client to close
(disconnect) the connection.
If the method succeeded, or if it failed and the server does not need to
direct the client to close the connection, the server MAY instruct the
client to execute another MAF method module.
At the end of the process, as determined by policies and controls on the
server, the server will send the following in response to ``What next'':
|-------+-----+-------+------+--------|
| INSTR | VER | FLAGS | MLEN | METHOD |
|-------+-----+-------+------+--------|
| 1 | 1 | 2 | 1 | MLEN |
|-------+-----+-------+------+--------|
If the composite authentication process succeeded, the INSTR field will
be set to ``Success'', X'00', MLEN to 4, and METHOD to Success,
X'00000000'. If the authentication process failed, the INSTR field will
be set to ``Failure'', X'FF', MLEN to 4, and METHOD to Failure,
X'FFFFFFFF'. In either outcome case, VER is set to X'00' and FLAGS is
Michener, et al. Expires 9 February 2000 [Page 5]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
set to X'0000'.
Upon receipt of either the ``Success'' or ``Failure'' messages by the
client, the client will send an acknowledgement to the server. The
server will indicate reception of the acknowledge by replying with an
acknowledge message as well:
|-------+-----+-------|
| INSTR | VER | FLAGS |
|-------+-----+-------|
| 1 | 1 | 2 |
|-------+-----+-------|
The INSTR field is set to ``Acknowledge'', X'06'. At this time VER is
set to X'01' and the FLAGS field is set to X'0000'. The acknowledge
message serves to synchronize the MAF protocol client and the server.
3. Process OEM Specific
The ``Process OEM specific'' instruction, X'07', provides a mechanism
for the client and server MAF protocol managers to exchange data before
or after a method has been invoked (when a given method is running on
the client and server, the implementers are free to use the data field
of the ``Process'' message to implement any form of communication
between the client and the server modules.) The server can send an
``OEM'' message only in response to ``What next'', ``Can Do'', or
``OEM'' messages from the client.
The client can send an ``OEM'' message to the server before sending a
``Can Do'' or ``What next'' message or in response to a previous
``Process OEM specific'', ``Success'', or ``Failure'' message from the
server. When one end sends an ``OEM'' message the other end MUST respond
with an ``OEM'' message as an acknowledgment. The acknowledgment
message can contain no significant data, if desired. When the exchange
of ``OEM'' messages is complete, the protocol managers continue with the
standard aspects of MAF.
The ``Process OEM specific'' message is composed as follows:
|-------+-----+-------+----------+---------+--------+--------+
| INSTR | VER | FLAGS | RESERVED | OEM ID | OEM ID | PAD |
| | | | ZEROES | LEN (n) | | BYTES |
|-------+-----+-------+----------+---------+--------+--------+
| 1 | 1 | 2 | 3 | 1 | n | 0 to 3 |
|-------+-----+-------+----------+---------+--------+--------+
|
V
+------------------------------------------------------------+
|
V
+-------+------|
| DLEN | DATA |
| (m) | |
+-------+------|
Michener, et al. Expires 9 February 2000 [Page 6]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
| 4 | m |
+-------+------|
The INSTR field is set to ``OEM'', X'07'. As above, the VER field is set
to the version of the MAF protocol. At this time VER is set to X'01' and
the FLAGS field is set to X'0000'. The RESERVED ZEROES field is for
future use or features. The length in bytes of the OEM ID field is
entered into the OEM ID LEN field. In this version of MAF, the length
will be either 4 for compact OEM IDs or 16 for long OEM IDs that are
UUIDs. The particular data being processed is sent from one end to the
other in the DATA field as a byte array, with the length of the array
specified in the DLEN field. The PAD BYTES field is 0 to 3 bytes of
unspecified values to align the DLEN field to a 4-byte boundary relative
to the beginning of the packet (for the 4- or 16-byte OEM IDs proposed
here, this field is absent.) For an acknowledgment message, DLEN can be
zero.
If the client or server receives an ``OEM'' message with an OEM ID that
it does not recognize or support, it will reply with an ``OEM'' message
with the OEM ID set to X'FFFFFFFF' and DLEN set to 0 to so indicate.
3.1 Current Compact OEM IDs
X'FFFFFFFF' OEM ID not recognized or supported
X'00000000' Internal Test IDs
To
X'00000003'
X'00000004' Reserved
X'00000005'
To Reserved for proprietary IDs, assigned by
X'0000FFFF' Novell
X'00010000' and up General IDs, assigned by the IANA
3.2 Current Compact MAF Method IDs
X'FFFFFFFF' Failure
X'00000000' Success
X'00000001' Internal Test Method ID
X'00000002' More method IDs are available
X'00000003' Reserved
X'00000004' Reserved
X'00000005'
To Reserved for proprietary method IDs, assigned
X'0000FFFF' by Novell
Michener, et al. Expires 9 February 2000 [Page 7]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
X'00010000' and up General MAF authentication method IDs,
assigned by the IANA
4. Security Considerations
MAF enables the efficient combination of multiple authentication
mechanisms (allowing the combination of something the user holds,
something the user knows, and something the user is). This allows for
the reliable establishment of user identity during the authentication
session if the methods are appropriately chosen and appropriately
managed. The selection of methods and their management are not addressed
by MAF. Improper selection of methods and inappropriate management of
the authentication process can invalidate any authentication, including
that provided by MAF.
If critical data such as long-term passwords or biometric data are
exchanged between the client and the server, appropriate steps SHOULD be
taken to secure it at the client (so that an attacker cannot acquire
this data), to secure it over the communications channel (using
encryption), and to secure this data and its processing at the server.
Without appropriate security and integrity at each link in the
authentication process, the integrity of the authentication cannot be
assured.
5. References
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., &
Jones, L., ``SOCKS Protocol V5'', April 1996.
[1] Steven Miller, ``DEC/HP Network Computing Architecture Remote
Procedure Call RunTime Extension Specification Version OSF TX1.0.11'',
July 23, 1992.
6. Acknowledgements
We express our thanks to Tolga Acar, Fred Ghiradelli, Tammy Green, and
Hal Henderson for assistance in the development of this document.
7. Authors' Addresses
John Michener
Novell, Inc.
122 East 1700 South
Provo Utah, 84606-6194
Phone: +1 801 861-7000
Fax: +1 801 861-2522
Email: jmichener@novell.com
Dan Fritch
Novell, Inc.
122 East 1700 South
Provo Utah, 84606-6194
Phone: +1 801 861-7000
Michener, et al. Expires 9 February 2000 [Page 8]
INTERNET-DRAFT MAF for SOCKS V5 August 1999
Fax: +1 801 861-2522
Email: dfritch@novell.com
Mark Gayman
Novell, Inc.
122 East 1700 South
Provo Utah, 84606-6194
Phone: +1 801 861-7000
Fax: +1 801 861-2522
Email: mgayman@novell.com
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Michener, et al. Expires 9 February 2000 [Page 9]