[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/