AFT Working Group Pat Calhoun
INTERNET DRAFT Sun Microsystems, Inc.
Category: Standards Track Jeff Haag
Title: draft-ietf-aft-socks-eap-00.txt 3Com Corporation
Date: March 1998 Glen Zorn
Microsoft Corporation
EAP Authentication for SOCKS Version 5
Status of this Memo
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.
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts
as reference material or to cite them other than as a ``working
draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
This document defines how EAP [5] (Extensible Authentication Protocol)
can be used with the SOCKS V5 protocol. EAP was defined to allow any
authentication mechanism to be used without any modification to the
authentication protocol (i.e. CHAP, OTP).
Table of Contents
1.0 Introduction
1.1 Definitions
1.2 Terminology
2.0 Extensible Authentication Protocol (EAP)
2.1 SOCKS EAP Negotiation
2.2 EAP Packet Format
2.2.1 Request and Response
2.2.2 Success and Failure
3.0 Initial EAP Request/Response Types
3.1 Identity
Calhoun, Haag, Zorn expires September 1998 [Page 1]
INTERNET DRAFT March 1998
3.2 Notification
3.3 Nak
3.4 MD5-Challenge
3.5 One-Time Password (OTP)
3.6 Generic Token Card
4.0 Security Considerations
5.0 Acknowledgements
6.0 References
7.0 Contacts
1.0 Introduction
EAP defines a set of messages which are used for the authentication
protocol negotiation as well as a set of messages which are used to
transport the authentication protocol payloads from a client to a
server.
The RADIUS Working Group currently has a proposal [6] to encapsulate
EAP messages within a RADIUS message to allow a RADIUS server to
authenticate EAP messages. This powerful combination of EAP and RADIUS
allows a dial-up NAS supporting this extension to seamlessly support
any EAP defined authentication mechanism using a single server.
Today's firewalls typically support one or more proprietary token card
vendor's authentication protocol. This is done by integrating the
vendor's client software within the firewall to ensure that it can
communicate with the token card vendor's authentication server.
This document proposes a mechanism which permits EAP to be used within
the SOCKS V5 protocol for authentication firewall traversal. This
powerful combination of SOCKS and EAP would allow a firewall to take
advantage of all of the authentication extensions defined within EAP
as well as to make use of the existing authentication servers.
The SOCKS protocol between a client and a firewall is over the TCP
protocol. However, the protocol between the firewall and the RADIUS
Server is UDP based. Care must be taken to ensure that the proper
RADIUS retransmission scheme is used by the firewall.
Calhoun, Haag, Zorn expires September 1998 [Page 2]
INTERNET DRAFT March 1998
1.1 Definitions
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the
specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that
there may exist valid reasons in particular circumstances
to ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
1.2 Terminology
This document uses the following term:
displayable message
This is interpreted to be a human readable string of characters,
and MUST NOT affect operation of the protocol. The message
encoding MUST follow the UTF-8 transformation format [5].
2.0 Extensible Authentication Protocol (EAP)
The Extensible Authentication Protocol (EAP) is a general protocol for
user authentication which supports multiple authentication mechanisms.
EAP does not select a specific authentication mechanism at SOCKS
Authentication Method negotiation but rather postpones this until the
method-dependent sub-negotiation. This allows the SOCKS server to
request more information before determining the specific
authentication mechanism. This also permits the use of a "back-end"
server which actually implements the various mechanisms while the
SOCKS server merely passes through the authentication exchanges.
After the SOCKS Authentication Method has been negotiated, the SOCKS
server or RADIUS Server sends one or more Requests to authenticate the
Calhoun, Haag, Zorn expires September 1998 [Page 3]
INTERNET DRAFT March 1998
SOCKS Client. The Request has a TYPE field to indicate what is being
requested. Examples of Request types include Identity, MD5-Challenge,
One-Time Password, Generic Token Cards, etc [5]. The MD5-Challenge
type corresponds closely to the CHAP authentication protocol.
Typically, the SOCKS or RADIUS Server will send an initial Identity
Request followed by one or more Requests for authentication
information.
Additional EAP documents also propose other authentication types (i.e.
TLS, RSA, etc) [3][4].
The SOCKS client sends a Response packet in reply to each Request. As
with the Request packet, the Response packet contains a TYPE field
which corresponds to the TYPE field of the Request.
The SOCKS or RADIUS Server ends the authentication phase with a
Success or Failure packet.
Advantages
The EAP Protocol allows a firewall to support all of the defined
EAP authentication extensions without having to pre-negotiate a
specific one during the SOCKS V5 authentication method phase. This
allows the authentication server to determine the protocol based on
the user's identity.
SOCKS V5 Servers (e.g. firewall) do not need to support all EAP
authentication extensions as it can act as a pass-through agent for
a "back-end" server. The device only needs to look for the
success/failure code to terminate the authentication phase/TCP
session.
Disadvantages
EAP does require the addition of a new authentication type to SOCKS
and thus SOCKS implementations will need to be modified to use it.
2.1 SOCKS EAP Negotiation
Once the TCP session is established between a client and a SOCKS
server, the client sends a version identifier/method selection message
in the following format:
+-----+----------+----------+
| VER | NMETHODS | METHODS |
+-----+----------+----------+
| 1 | 1 | 1 to 255 |
+-----+----------+----------+
Calhoun, Haag, Zorn expires September 1998 [Page 4]
INTERNET DRAFT March 1998
The server selects from one of the methods given in METHODS, and sends
a METHOD selection message:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
The VER field is set to X'05' for this version of the protocol. The
NMETHODS field contains the number of method identifier octets that
appear in the METHODS field. The following value is used in the
METHODS field to indicate that EAP is to be used:
o (TDB) Extensible Authentication Protocol
2.2 EAP Packet Format
Exactly one EAP packet is transmitted at any time. A summary of the
EAP packet format is shown below. The fields are transmitted from left
to right.
+-----+------+----+--------+---------+
| VER | CODE | ID | LENGTH | DATA |
+-----+------+----+--------+---------+
| 1 | 1 | 1 | 2 | 0-65531 |
+-----+------+----+--------+---------+
VER contains the current version of the subnegotiation, which is
X'01'. CODE contains the EAP packet type as shown below. The ID field
is one octet and aids in matching responses with requests. The LENGTH
field is two octets and indicates the length of the EAP packet
including the CODE, ID, LENGTH and DATA fields. The DATA field
consists of one or more octets whose format is determined by the CODE
field.
Code Definitions
The following EAP message types apply to all messages:
ATT Label Meaning
-------------------------------------------------------
X'01' EAP-Request Request from Server to Client
X'02' EAP-Response Response from Client to Server
X'03' EAP-Success Server responds with Success
X'04' EAP-Failure Server responds with Failure
Calhoun, Haag, Zorn expires September 1998 [Page 5]
INTERNET DRAFT March 1998
2.2.1 Request and Response
The Request packet is sent by the SOCKS/RADIUS Server to the SOCKS
Client. Each Request has a TYPE field which serves to indicate what is
being requested. The SOCKS/RADIUS Server MUST transmit an EAP packet
with the CODE field set to X'01' (EAP-Request). The contents of the
DATA field is dependent on the Request type. The peer MUST send a
Response packet in reply to a Request packet. Responses MUST only be
sent in reply to a received Request. The ID field of the Response MUST
match that of the Request.
SOCKS/RADIUS Server Implementation Note: Because the authentication
process will often involve user input, some care must be taken when
deciding upon authentication timeouts.
A summary of the Request and Response packet format is shown below.
The fields are transmitted from left to right.
+-----+------+----+--------+------+-----------+
| VER | CODE | ID | LENGTH | TYPE | TYPE-DATA |
+-----+------+----+--------+------+-----------+
| 1 | 1 | 1 | 2 | 1 | 0-65530 |
+-----+------+----+--------+------+-----------+
VER contains the current version of the subnegotiation, which is
X'01'. CODE contains contains either X'01' (EAP-Request) or X'02'
(EAP-Response). The ID field is one octet and aids in matching
responses with requests. The LENGTH field is two octets and indicates
the length of the EAP packet including the CODE, ID, LENGTH, TYPE and
TYPE-DATA fields.
The TYPE field is one octet and indicates the type of Request or
Response. Only one type MUST be specified per EAP Request or
Response. Normally, the TYPE field of the Response will be the same
as the TYPE field of the Request. However, there is also a Nak
Response type for indicating that a Request type is unacceptable to
the peer. When sending a Nak in response to a Request, the peer MAY
indicate an alternative desired authentication type which it supports.
An initial specification of types follows in a later section of this
document.
The TYPE-DATA field varies with the type of Request and the associated
Response.
2.2.2 Success and Failure
The Success packet is sent by the SOCKS/RADIUS Server to the SOCKS
Client to acknowledge successful authentication. The SOCKS/RADIUS
Server MUST transmit an EAP packet with the Code field set to X'03'
Calhoun, Haag, Zorn expires September 1998 [Page 6]
INTERNET DRAFT March 1998
(Success).
If the SOCKS/RADIUS Server cannot authenticate the SOCKS Client
(unacceptable Responses to one or more Requests) then the
implementation MUST transmit an EAP packet with the Code field set to
X'04' (Failure). A SOCKS/RADIUS Server MAY wish to issue multiple
Requests before sending a Failure response in order to allow for human
typing mistakes.
A summary of the Success and Failure packet format is shown below.
The fields are transmitted from left to right.
+-----+------+----+--------+
| VER | CODE | ID | LENGTH |
+-----+------+----+--------+
| 1 | 1 | 1 | 2 |
+-----+------+----+--------+
VER contains the current version of the subnegotiation, which is
X'01'. CODE contains contains either X'03' (EAP-Success) or X'04'
(EAP-Failure). The ID field is one octet and aids in matching
responses with requests. The ID field MUST match the ID field of the
Response packet that it is sent in response to. The LENGTH field is
two octets and indicates the length of the EAP packet including the
CODE, ID and LENGTH fields.
3.0 Initial EAP Request/Response Types
This section will provide an overview of the initial set of EAP Types
as defined in [5] in order to provide the reader with a basic
understanding of the EAP messages. More types are defined in follow-on
documents.
The TYPE field is one octet and identifies the structure of an EAP
Request or Response packet. The first 3 types are considered special
types. The remaining types define authentication exchanges.
The following basic EAP types are defined in [5]:
X'01' Identity
X'02' Notification
X'03' Nak (Response only)
X'04' MD5-Challenge
X'05' One-Time Password (OTP) (RFC 1938)
X'06' Generic Token Card
The following EAP type MUST be supported by all SOCKS/EAP
implementations and is specified in [x]:
Calhoun, Haag, Zorn expires September 1998 [Page 7]
INTERNET DRAFT March 1998
TDB HMAC-MD5-Challenge
3.1 Identity
The Identity type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial Request.
An optional displayable message MAY be included to prompt the peer in
the case where there is expectation of interaction with a user. A
Response MUST be sent to this Request with a type of X'01' (Identity).
Implementation Note: The SOCKS Client MAY obtain the Identity via user
input. It is suggested that the SOCKS/RADIUS Server retry the Identity
Request in the case of an invalid Identity or authentication failure
to allow for potential typos on the part of the user.
It is suggested that the Identity Request be retried a minimum of 3
times before terminating the authentication phase with a Failure
reply. The Notification Request MAY be used to indicate an invalid
authentication attempt prior to transmitting a new Identity Request
(optionally, the failure MAY be indicated within the message of the
new Identity Request itself).
3.2 Notification
The Notification type is optionally used to convey a displayable
message from the SOCKS/RADIUS Server to the SOCKS Client. The client
SHOULD display this message to the user or log it if it cannot be
displayed. It is intended to provide an acknowledged notification of
some imperative nature. Examples include a password with an
expiration time that is about to expire, an OTP sequence integer which
is nearing 0, an authentication failure warning, etc. In most
circumstances, notification should not be required.
3.3 Nak
The Nak type is valid only in Response messages. It is sent in reply
to a Request where the desired authentication Type is unacceptable.
Authentication types are numbered 4 and above. The Response contains
the authentication type desired by the peer.
3.4 MD5-Challenge
The MD5-Challenge type is analogous to the PPP CHAP protocol [1] (with
MD5 as the specified algorithm). The PPP Challenge Handshake
Authentication Protocol RFC [1] should be referred to for further
implementation specifics. The Request contains a "challenge" message
Calhoun, Haag, Zorn expires September 1998 [Page 8]
INTERNET DRAFT March 1998
to the peer. A Response MUST be sent in reply to the Request. The
Response MAY be either of type X'04' (MD5-Challenge) or type X'03'
(Nak). The Nak reply indicates the peer's desired authentication
mechanism type. All EAP implementations MUST support the MD5-Challenge
mechanism.
3.5 One-Time Password (OTP)
The One-Time Password system is defined in "A One-Time Password
System" [2]. The Request contains a displayable message containing an
OTP challenge. A Response MUST be sent in reply to the Request. The
Response MUST be of Type X'05' (OTP) or Type X'03' (Nak). The Nak
reply indicates the peer's desired authentication mechanism Type.
3.6 Generic Token Card
The Generic Token Card type is defined for use with various Token Card
implementations which require user input. The Request contains an
ASCII text message and the Reply contains the Token Card information
necessary for authentication. Typically, this would be information
read by a user from the Token card device and entered as ASCII text.
3.7 HMAC-MD5-Challenge
The HMAC-MD5-Challenge MUST be supported by all SOCKS implementation
and MUST be the default authentication mechanism. The protocol is
defined in xxx [x]. A Response MUST be sent in reply to the Request.
The Response MAY be either of type TDB (HMAC-MD5-Challenge) or type
X'03' (Nak). The Nak reply indicates the peer's desired authentication
mechanism type.
4.0 Security Considerations
Security issues are the primary topic of this RFC.
The interaction of the authentication protocols within SOCKS are
highly implementation dependent.
There is no requirement that authentication be full duplex or that the
same protocol be used in both directions. It is perfectly acceptable
for different protocols to be used in each direction. This will, of
course, depend on the specific protocols negotiated.
In practice, within or associated with each firewall, it is not
anticipated that a particular named user would be authenticated by
multiple methods. This would make the user vulnerable to attacks
which negotiate the least secure method from among a set (such as OTP
Calhoun, Haag, Zorn expires September 1998 [Page 9]
INTERNET DRAFT March 1998
rather than RSA). Instead, for each named user there should be an
indication of exactly one method used to authenticate that user name.
If a user needs to make use of different authentication methods under
different circumstances, then distinct identities SHOULD be employed,
each of which identifies exactly one authentication method.
5.0 Acknowledgements
Much of this text was taken from [5] and the authors wish to recognize
L.J. Blunk and J.R. Vollbrecht for their original draft.
6.0 References
[1] W. Simpson, "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[2] N. Haller, and C. Metz, "A One-Time Password System", RFC 1938,
May 1996.
[3] Bernard Aboba, Dan Simon, "PPP EAP TLS Authentication Protocol",
Work in Progress, October 1997.
[4] William Whelan, "PPP EAP RSA Public Key Authentication Protocol",
Work in Progress, "February 1997.
[5] L.J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", Work in Progress, December 1997.
[6] P. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication
Protocol Support in RADIUS", Work in Progress, May 1997.
[7] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones,
"SOCKS Protocol V5", RFC 1928, April 1996.
7.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 847 548-9587
Fax: +1 650 786-6445
Calhoun, Haag, Zorn expires September 1998 [Page 10]
INTERNET DRAFT March 1998
E-mail: pcalhoun@toast.net
Jeff Haag
3Com Corporation
1800 W. Central Ave
Mount Prospect, Il 60031
Phone: +1 919 676-9971
E-Mail: jhaag@usr.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052
Phone: +1 425 703-1559
E-Mail: glennz@microsoft.com
Calhoun, Haag, Zorn expires September 1998 [Page 11]
