[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                               Allan Rubens
Category: Experimental                        Merit Network, Incorporated
expires in six months                                      Pat R. Calhoun
                                                 US Robotics Access Corp.
                                                                June 1996

      Enhanced Remote Authentication Dial In User Service (RADIUS)
               Extensible Authentication Protocol Support
                 <draft-calhoun-enh-radius-eap-00.txt>


Status of this Memo

   Distribution of this memo is unlimited.

   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.''

   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 (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).



Abstract

   The RADIUS Protocol allows for authentication using existing
   PPP authentication protocols such as PAP and CHAP.  This
   document describes how the Enhanced RADIUS Protocol could
   also include the PPP Extensible Authentication Protocol, EAP.







Rubens                                                           [Page 1]


DRAFT        Extensible Authentication Protocol Support        June 1996

   1. Introduction

   The PPP extensions WG is considering a new authentication protocol
   for PPP called EAP - PPP Extensible Authentication Protocol.  EAP is
   described in [2].

   EAP is intended to provide support for authentication protocols which
   do not fit into the PAP or CHAP model using a standard mechanism.  The
   protocols include varieties of smart cards, S/key, Public Key and
   Kerberos.  EAP is designed to allow a RADIUS style helper to handle
   all authentication protocol support where the NAS acts as a transit
   mechanism for EAP packets.

   The following diagram gives an example of how an EAP authentication
   using S/key might be accomplished with Enhanced RADIUS.  This example
   may be extended to other EAP protocols easily, but this concrete
   example serves to make it a easier to understand the basic concept:


   PPP-Client            NAS (RADIUS-client)    RADIUS-server
   ----------            -------------------    -------------

   1)                <-- LCP EAP-Request

   2) LCP EAP ACK -->

   3)                    Start-EAP -->

   4)                                       <-- EAP/identity

   5)                <-- EAP/identity

   6) EAP-resp/myid -->

   7)                    EAP-resp/myid -->

   8)                                       <-- EAP/S-key:S-key challenge

   9)                <-- EAP/S-key:S-key challenge

  10) EAP-resp/myid:S-keypw -->

  11)                    EAP/myid:S-keypw -->

  12)                                      <-- EAP/Success

  13)               <-- EAP/Success

Rubens                                                           [Page 2]


DRAFT        Extensible Authentication Protocol Support        June 1996


   The following describes one way to make this work with RADIUS:

   a) Upon receiving an EAP-Response as the authentication protocol,
      the NAS sends a RADIUS-EAP-Request to the RADIUS-server.  The
      absence of an EAP-Packet attribute in this request indicates that
      this is a Start-EAP indication.

   b) The RADIUS-server responds by sending a RADIUS-EAP-ACK with an
      EAP-Packet attribute specifying the EAP packet to be issued to the
      NAS.  The EAP type of this packet will normally be "Identity", but
      it could be any other valid EAP type if the server does not need to
      know the user identity before beginning authentication.  The NAS
      forwards the EAP packet on to the PPP client.

   c) The PPP client responds by sending an EAP-Response packet, which
      the NAS forwards to the RADIUS-server in the EAP-Packet attribute
      of a RADIUS-EAP-Request.

   d) Based on the user's identity, the RADIUS-server determines if it
      is able to authenticate the user locally, otherwise it may proxy
      the request to a remote RADIUS server.

   e) The RADIUS-server decides whether the response is okay and sends
      a RADIUS-EAP-Ack or RADIUS-EAP-Reject with the appropriate EAP
      success/failure packet inside an EAP-MSG attribute.  The NAS
      forwards the EAP packet to the PPP client, and accepts or rejects
      the connection.


   The above scenario creates a situation in which the NAS never needs to
   touch an EAP packet.  An alternative which may be used by NAS vendors
   wanting to simplify things would be for the NAS to, 1) always send an
   EAP Identity request message to the client, and 2) to forward the
   response to the RADIUS-server in the EAP-Packet attribute of a
   RADIUS-EAP-Request.

   Unless the NAS interprets the EAP-Packet field of
   RADIUS-EAP-Requests, it will not see the user id supplied by the
   client.  Rather than doing this interpretation, it is suggested that a
   simple mechanism be defined for the RADIUS server to set the userid in
   the NAS with a special attribute.  It is important to have a userid
   for logging and accounting purposes.

   In the case where the RADIUS Server does not support the EAP
   Extension, the following scenario would occur:


Rubens                                                           [Page 3]


DRAFT        Extensible Authentication Protocol Support        June 1996

   PPP-Client            NAS (RADIUS-client)    RADIUS-server
   ----------            -------------------    -------------

   1)                <-- LCP EAP-Request

   2) LCP EAP ACK -->

   3)                    Start-EAP -->

   4)                                       <-- Command Unrecognized

   5)                <-- LCP CHAP Request

   In the case where the local RADIUS-server does support EAP, but the
   remote RADIUS-server does not, the following would occur:

   PPP-Client      NAS (RADIUS-client)    RADIUS-server     RADIUS-Server
   ----------      -------------------    -------------     -------------

   1)          <-- LCP EAP-Request

   2) LCP EAP ACK -->

   3)              Start-EAP -->

   4)                                 <-- EAP/identity

   5)          <-- EAP/identity

   6) EAP-resp/myid -->

   7)              EAP-resp/myid -->

   8)                                     EAP-resp/myid -->

   9)                                            <-- Command Unrecognized

  10)                                 <-- Command Unrecognized

  11)          <-- LCP CHAP Request








Rubens                                                           [Page 4]


DRAFT        Extensible Authentication Protocol Support        June 1996

   2. Command Name and Command Code

        Command Name: RADIUS-EAP-Request
        Command Code: 300

        Command Name: RADIUS-EAP-Response
        Command Code: 301

        Command Name: RADIUS-EAP-Ack
        Command Code: 302

        Command Name: RADIUS-EAP-Reject
        Command Code: 303

   3. Command Meanings

   3.1 RADIUS-EAP-Request

    Description

      RADIUS-EAP-Request packets are sent by the Radius Client to the
      Radius Server, and convey EAP-Responses from the client through the
      NAS and on to the Radius server.  RADIUS-EAP-Requests will normally
      include a single EAP-Packet attribute which contains the EAP packet.
      A RADIUS-EAP-Request sent from the NAS to the RADIUS server that
      does not contain an EAP-Packet attribute signals to the RADIUS
      server that it is to initiate EAP authentication with the client.

      Upon receipt of a RADIUS-EAP-Request, A RADIUS Server MUST
      issue a reply. The reply may be either: 1) a RADIUS-EAP-Response
      containing an EAP-Request in a single EAP-Packet attribute, 2) a
      RADIUS-EAP-Ack containing an EAP-Packet of type "success", or 3) a
      RADIUS-EAP-Reject containing an EAP-Packet of type "failure". A
      Command-Unrecognized packet is returned if the server does not
      support EAP.

      A summary of the RADIUS-EAP-Request packet format is shown
      below. The fields are transmitted from left to right.










Rubens                                                           [Page 5]


DRAFT        Extensible Authentication Protocol Support        June 1996

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Flags  | Ver |            Command            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Identifier           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         Authenticator                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Message Integrity Code                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-


    Code

      254 for Enhanced RADIUS.


    Flags

      The Flag field is used as defined in [1].

    Version

      MUST be set to 2

    Command

      300 for RADIUS-EAP-Request

    Identifier

      The Identifier field MUST be changed whenever the content of the
      Attributes field changes, and whenever a valid reply has been
      received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.




Rubens                                                           [Page 6]


DRAFT        Extensible Authentication Protocol Support        June 1996

    Length

      The total length of the message, including this header.

    Authenticator

      The Authenticator field is a random 16 octet value. If the
      Timestamp option is supported, the first four octets contain a
      timestamp of when the packet was sent from the peer.

    Message Integrity Code

      This field contains an MD5 hash of the following:

         MD5( packet | Shared Secret )

    Attributes

      The Attribute field is variable in length, and contains a list of
      zero or more Attributes.  It MAY contain zero or one EAP-Packet
      attributes.  If it does not contain an EAP-Packet attribute, it is
      an indication to the server that server that EAP should be
      initiated by the server.  If it contains one EAP-Packet attribute,
      this attribute contains the reply to the last EAP-Request issued by
      the server (or the reply to the EAP-Identity that can be issued by
      the NAS). The remainder of the attributes are those normally sent
      on an Access-Request by the NAS.


   3.2 RADIUS-EAP-Response

    Description

      RADIUS-EAP-Response packets are sent by the RADIUS-Server to the
      NAS. They contain the next EAP-Request packet to be passed to the
      client.

      The RADIUS-EAP-Response MUST contain a single EAP-Packet
      attribute.

      After issuing the included EAP-Request to the client, the NAS
      remains in a state where it awaits further EAP-Responses from the
      client.

      A summary of the RADIUS-EAP-Request packet format is shown
      below. The fields are transmitted from left to right.


Rubens                                                           [Page 7]


DRAFT        Extensible Authentication Protocol Support        June 1996

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Flags  | Ver |            Command            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Identifier           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         Authenticator                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Message Integrity Code                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-


    Code

      254 for Enhanced RADIUS.


    Flags

      The Flag field is used as defined in [1].

    Version

      MUST be set to 2

    Command

      301 for RADIUS-EAP-Response

    Identifier

      The Identifier field is a copy of the Identifier field of the
      RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent.

    Length

      The total length of the message, including this header.


Rubens                                                           [Page 8]


DRAFT        Extensible Authentication Protocol Support        June 1996

    Authenticator

      The Authenticator field is a random 16 octet value. If the
      Timestamp option is supported, the first four octets contain a
      timestamp of when the packet was sent from the peer.

    Message Integrity Code

      This field contains an MD5 hash of the following:

         MD5( packet | Shared Secret )

    Attributes

      The Attribute field MUST contains only a single EAP-Packet
      attribute which contains an EAP-Request packet.


   3.3 RADIUS-EAP-Ack

    Description

      RADIUS-EAP-Ack packets are sent by the RADIUS server to the NAS.
      They contain the next EAP-Request or EAP-Success packet to be
      passed to the client.

      The RADIUS-EAP-Ack packet MUST contain a single EAP-Packet
      attribute.

      After issuing the included EAP-Success packet to the client, the
      NAS should end the authentication phase with a positive response.

      A summary of the RADIUS-EAP-Ack packet format is shown below. The
      fields are transmitted from left to right.














Rubens                                                           [Page 9]


DRAFT        Extensible Authentication Protocol Support        June 1996


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Flags  | Ver |            Command            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Identifier           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         Authenticator                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Message Integrity Code                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-


    Code

      254 for Enhanced RADIUS.


    Flags

      The Flag field is used as defined in [1].

    Version

      MUST be set to 2

    Command

      302 for RADIUS-EAP-Ack

    Identifier

      The Identifier field is a copy of the Identifier field of the
      RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent.

    Length

      The total length of the message, including this header.

Rubens                                                          [Page 10]


DRAFT        Extensible Authentication Protocol Support        June 1996

    Authenticator

      The Authenticator field is a random 16 octet value. If the
      Timestamp option is supported, the first four octets contain a
      timestamp of when the packet was sent from the peer.

    Message Integrity Code

      This field contains an MD5 hash of the following:

         MD5( packet | Shared Secret )

    Attributes

      The Attribute field contains only a single EAP-Packet attribute
      which contains an EAP-Request packet.


   3.4 RADIUS-EAP-Reject

    Description

      RADIUS-EAP-Reject packets are sent by the RADIUS server to the NAS.
      They are sent in response to a RADIUS-EAP-Request that results in
      an authentication failure.  RADIUS-EAP-Reject packets contain a
      single EAP-Packet attribute containing an EAP failure packet.

      After issuing the included EAP failure packet to the client, the
      NAS should end the authentication phase with a negative result.

      A summary of the RADIUS-EAP-Reject packet format is shown below.
      The fields are transmitted from left to right.
















Rubens                                                          [Page 11]


DRAFT        Extensible Authentication Protocol Support        June 1996

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Flags  | Ver |            Command            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Identifier           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         Authenticator                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Message Integrity Code                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-


    Code

      254 for Enhanced RADIUS.


    Flags

      The Flag field is used as defined in [1].

    Version

      MUST be set to 2

    Command

      303 for RADIUS-EAP-Reject

    Identifier

      The Identifier field is a copy of the Identifier field of the
      RADIUS-EAP-Request which caused this RADIUS-EAP-Reject to be sent.

    Length

      The total length of the message, including this header.


Rubens                                                          [Page 12]


DRAFT        Extensible Authentication Protocol Support        June 1996


    Authenticator

      The Authenticator field is a random 16 octet value. If the
      Timestamp option is supported, the first four octets contain a
      timestamp of when the packet was sent from the peer.

    Message Integrity Code

      This field contains an MD5 hash of the following:

         MD5( packet | Shared Secret )

    Attributes

      The Attribute field contains only a single EAP-Packet attribute
      which contains an EAP-Request packet.  Other attributes valid
      on an Access-Reject message may also be present.


   4. Attribute Name and Attribute Code

        Attribute Name: EAP-Packet
        Attribute Code: 300

   5. Attribute Meanings

   5.1 EAP-Packet

    Description

      This attribute is used to contain the actual EAP-Requests to be
      sent from the Radius server to the client (RADIUS-EAP-Ack and
      RADIUS-EAP-Reject) and the EAP-Responses to be sent from the client
      to the Radius server (RADIUS-EAP-Requests).  These EAP-Requests and
      Responses are exactly as defined in [2].



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Attribute Type         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Flags     |   String ...  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Rubens                                                          [Page 13]


DRAFT        Extensible Authentication Protocol Support        June 1996

    Type

      300 for EAP-Packet

    Length

      >= 6


    Flags

      The Flags field MUST be set to 1 (The attribute MUST be supported
      by the receiving device). Of course, the attribute would only be
      supported if the implementation supported EAP.

    String

      The String field is the exact EAP packet data to be transported
      from client to server or server to client.  It is not Null
      terminated and may contain arbitrary binary values.


   6. Motivation

      The motivation for this extension to Enhanced RADIUS is to allow
      RADIUS, which is the most common Authentication protocol deployed
      today, to keep up with the new authentication protocols currently
      being worked on by the PPP Extensions WG.

      This extension allows the NAS' to support a variety of
      authentication protocols by delegating the task to the
      Authentication server. The NAS needs to simply forward packets from
      the PPP client to the local RADIUS Server. Note, however, that the
      same RADIUS Server must be used throughout the whole transaction
      process (see section 7 on dealing with proxy'ed requests). If the
      local RADIUS server becomes unavailable at any time during the
      authentication phase, the NAS will have to begin LCP negotiations
      again with the PPP client.

      Since the EAP messages are simply forwarded from/to the NAS and the
      RADIUS Server, the support of the Message Integrity Check in the
      Enhanced RADIUS header allows both parties to authenticate
      themselves.





Rubens                                                          [Page 14]


DRAFT        Extensible Authentication Protocol Support        June 1996

   7. Description (or Implementation Rules)

      Upon negotiating LCP EAP with the PPP client, the NAS must send a
      EAP Start message to the local RADIUS Server (note this should only
      be done if the NAS is aware that its local RADIUS Server is capable
      of the Enhanced RADIUS protocol [1]). The EAP-Start message is an
      EAP-Request with no EAP-Packet attribute present.

      If the RADIUS Server does not support this extension, a
      Command-Unrecognized message will be returned to the NAS. Upon
      receipt of this packet, the NAS will NAK the PPP client and request
      PAP or CHAP as the authentication protocol.

      For Proxied RADIUS requests there are two methods of processing,
      if the domain is determined based on the DNIS the RADIUS-server may
      proxy the initial EAP-Start request. In the case that the domain is
      determined based on the user id, the local RADIUS-server must
      issue the EAP-identity request. The response from the PPP user
      must be proxied to the final authentication server.

      If the RADIUS Server does support this extension, an EAP-Identity
      message is returned to the NAS. Upon receipt of this packet, the
      NAS will complete the LCP negotiation phase and will enter the EAP
      authentication phase. The NAS will then forward the packet which
      was contained in the EAP-Packet attribute of the EAP-Request-Ack to
      the PPP client.

      For proxied RADIUS requests, a Command-Unrecognized message may be
      received following the EAP-Identity response. This would occur
      if the messages was proxied to a RADIUS-server which does not
      support the EAP extension.

      Note that if at any point an EAP-Request-Reject message is received
      from the RADIUS Server, the NAS SHOULD issue an LCP Terminate
      Request to the PPP Client.

      At this point, the PPP Client will exchange a series of
      request/response messages with the RADIUS Server. This is done
      until either an EAP-Request-Reject is received (which will
      disconnect the user), or an EAP-Request-Success is received which
      the NAS would then successfully end the authentication phase.

      The RADIUS-server will always include the CLASS attribute in all
      messages to the NAS. The NAS MUST include this same attribute in
      the subsequent message to the RADIUS-server which includes the
      response from the PPP client. The CLASS attribute which is


Rubens                                                          [Page 15]


DRAFT        Extensible Authentication Protocol Support        June 1996

      associated with the EAP-Request-Success message from the
      RADIUS-server is the one which should be used by the NAS in
      all accounting messages for the authenticated user.

      The RADIUS-EAP-Ack issued by the server to the NAS will contain all
      of the attributes which are contained in an Access-Accept in
      addition to the EAP-Packet attribute.

      The Port number and NAS Identifier are included in the attributes
      issued by the NAS in the original RADIUS-EAP-Request message.

      The NAS is not responsible for the retransmission of any EAP
      messages. The PPP client and the RADIUS-server are responsible for
      for any retransmissions.


   References

      [1]   Calhoun, Rubens, "Enhanced RADIUS", Internet-Draft,
            draft-rfced-exp-calhoun-radius-enhanced-00.txt,
            US Robotics Access Corp., June 1996.

      [2]   Blunk, Volbretch, "PPP Extensible Authentication Protocol",
            Internet-Draft, draft-ietf-pppext-eap-auth-01.txt.,
            Merit Networks Inc., July 1995.























Rubens                                                          [Page 16]