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

Versions: 00 draft-ietf-radius-eap

     Network Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-aboba-radius-eap-00.txt>                              Glen Zorn
     17 January 1997                                  Microsoft Corporation
     
     
              Extensible Authentication Protocol Support in RADIUS
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing 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  mate-
     rial 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).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     aboba-radius-eap-00.txt>, and  expires July 1, 1997. Please send  com-
     ments to the authors.
     
     
     2.  Abstract
     
     The  Enhanced  Authentication  Protocol  (EAP) is a PPP extension that
     provides support for additional  authentication  methods  within  PPP.
     Currently,  the RADIUS protocol only supports conventional PPP authen-
     tication methods such as PAP and CHAP. This document describes two new
     attributes, EAP-Authentication-Type and EAP-Authentication-Server-End-
     point, and how they may be  used  for  providing  EAP  support  within
     RADIUS.
     
     
     3.  Introduction
     
     The  Extensible  Authentication Protocol (EAP), described in [1], pro-
     vides a standard mechanism for support  of  additional  authentication
     methods  within  PPP.  Through the use of EAP, support for a number of
     authentication schemes may be added, including token cards,  Kerberos,
     Public Key, S/Key, and others. However, the RADIUS protocol, described
     in [4], currently only supports CHAP and PAP authentication. This doc-
     ument  describes two new attributes, EAP-Authentication-Type, and EAP-
     Authentication-Server-Endpoint, and how they may be used for providing
     EAP support within RADIUS.
     
     
     
     
     Aboba & Zorn                                                  [Page 1]


     INTERNET-DRAFT                                         17 January 1997
     
     
     The  scheme  described here differs from that proposed in [2], in that
     rather than shuttling RADIUS-encapsulated EAP Packets between the  NAS
     and  a  backend security server, the RADIUS server instead returns the
     type of EAP authentication desired, and the address and  port  of  the
     backend  authentication  server  to  be contacted. The NAS device then
     uses this information to contact the backend security server directly.
     
     Due to the 253 octet limitation in the size of a RADIUS attribute, the
     scheme described in [2] could not be easily  implemented  on  existing
     RADIUS servers, and was dependent on deployment of an expanded version
     of the RADIUS protocol. Since  the  scheme  described  here  does  not
     encapsulate EAP packets in RADIUS, it may be implemented within RADIUS
     as described in [3] and [4].
     
     While the conversation between the NAS  and  backend  security  server
     will  typically  occur  using  a proprietary protocol developed by the
     backend security server vendor, it is also possible to encapsulate EAP
     in  UDP  or TCP. This has the advantage of allowing the NAS to support
     EAP without the  need  for  authentication-specific  code,  which  can
     instead reside on a backend security server.
     
     
     4.  Protocol overview
     
     The  EAP  conversation  between  the  authenticating  peer and the NAS
     begins with the negotiation of EAP within LCP. Once EAP has been nego-
     tiated, if the NAS is set up for RADIUS authentication, it will initi-
     ate an EAP-identity request. While use of the identity request is  not
     required  by  EAP, without knowledge of the identity, RADIUS would not
     be capable of returning user-specific connection setup attributes,  or
     accounting  for  resource  usage. Since these are the main benefits of
     the RADIUS protocol, if an identity request were not required, the NAS
     should  be  set  up  to operate with a local profile rather than using
     RADIUS.
     
     Since the purpose of EAP is to authenticate the user, prior to sending
     the Access-Request the RADIUS client has obtained the user's identity,
     but no authentication can be assumed to have  taken  place.  Therefore
     with  EAP it is typically not possible to include a conventional User-
     Password or CHAP-Password attribute within the Access-Request.
     
     Instead, after obtaining the user's identity, the RADIUS client gener-
     ates  an Access-request containing the following attributes: User-Name
     (filled  in  with  the  identity),  EAP-Authentication-Server-Endpoint
     (with  an address of 0.0.0.0, and port of 0x0000), EAP-Authentication-
     Type (with type 0) and a User-Password attribute which contains an MD5
     hash  of  the Access-Request concatenated with the shared secret (i.e.
     User-Password=MD5(Code+ID+Length+RequestAuth+Attributes+Secret)). This
     amounts  to  a  null password, but authenticates that the request came
     from a known NAS. The user's connection is only  set  up  by  the  NAS
     should the EAP authentication succeed.
     
     It  is  also  possible  for the NAS to carry out an MD5 authentication
     prior to sending the  Access-Request.  In  this  case,  the  NAS  will
     
     
     
     Aboba & Zorn                                                  [Page 2]


     INTERNET-DRAFT                                         17 January 1997
     
     
     include  a  CHAP-Password  attribute in the Access-Request, along with
     the null  EAP-Authentication-Server-Endpoint  and  EAP-Authentication-
     Type  attributes, and as a result, the RADIUS server is able to verify
     the user password. However, use of multiple authentications may not be
     desirable in many applications.
     
     On receiving the Access-Request, the RADIUS server checks the validity
     of the User-Password or CHAP-Password attributes, and if this check is
     successful, the RADIUS server returns connection-related attributes in
     the Access-Reply, along  with  the  EAP-Authentication-Type  and  EAP-
     Authentication-Server-Endpoint  attributes.  Although  use of multiple
     EAP authentications is typically not desirable, it is possible for the
     RADIUS  server  to return more than one set of EAP-Authentication-Type
     and EAP-Authentication-Server-Endpoint attributes; in  this  case  the
     NAS will carry out the authentications in the indicated order.
     
     If the authenticating peer is successful in completing the EAP authen-
     tication, then the NAS grants access  to  the  network,  and  sends  a
     RADIUS Accounting-Request/START packet to the RADIUS server, including
     the  EAP-Authentication-Type  and   EAP-Authentication-Server-Endpoint
     attributes. The RADIUS server replies with an Accounting-Reply packet.
     Similarly, when the connection is terminated, the NAS sends  a  RADIUS
     Accounting-Request/STOP  packet  to  the  RADIUS server, including the
     EAP-Authentication-Type     and     EAP-Authentication-Server-Endpoint
     attributes,  and  the  RADIUS  server replies with an Accounting-Reply
     packet.
     
     The conversation between the  authenticating  peer,  NAS,  and  RADIUS
     server is summarized below:
     
     Authenticating Peer        NAS                         RADIUS Server
     -------------------        ---                         -------------
                                <- LCP EAP-Request
     LCP EAP ACK ->
                                <- PPP EAP-Request/Identity
     PPP EAP-Response/Identity
     (MyID) ->
                                RADIUS Access-Request
                                Username (MyID),
                                User-Password,
                                EAP-Authentication-Type(0)
                                EAP-Authentication-Server-
                                Endpoint (0) ->
                                                           <-RADIUS Access-Accept
                                                           (Referral)
                                                           EAP-Authentication-Type:S-Key,
                                                           EAP-Authentication-Server-Endpoint,
                                                           (Other attributes)
                                <- PPP EAP-Request/S-Key
                                S-Key Challenge
     PPP EAP-Response/S-Key,
     S-Keypw ->
                                EAP-Request/S-Key
                                S-Keypw (to security server)
     
     
     
     Aboba & Zorn                                                  [Page 3]


     INTERNET-DRAFT                                         17 January 1997
     
     
                                EAP-Success
                                (from security server)
     
                                <- PPP EAP-Success
     IPCP phase starts
     IPCP phase completes
                                RADIUS Accounting-Request
                                with Acct-Status-Type=Start,
                                EAP-Authentication-Server-Endpoint
                                EAP-Authentication-Type ->
                                                           <- RADIUS Accounting-Reply
     
                                RADIUS Accounting-Request
                                with Acct-Status-Type=Stop,
                                EAP-Authentication-Server-Endpoint
                                EAP-Authentication-Type ->
                                                           <- RADIUS Accounting-Reply
     
     
     
     
     4.1.  Backward compatibility
     
     It  is conceivable that the RADIUS server to which the initial Access-
     Reqest is directed will not support EAP. In this case, the  User-Pass-
     word attribute will not match, and the RADIUS server will respond with
     a RADIUS Access-Reject. The NAS will then NAK the Authenticating Peer,
     and will request CHAP or PAP authentication.
     
     
     5.  Attributes
     
     
     5.1.  EAP-Authentication-Type
     
     Description
     
        When  included  in  an  Access-Request message, this attribute MUST
        contain a value of 0, used to indicate a request for an EAP authen-
        tication type.
     
        When returned in an Access-Accept message, this attribute indicates
        the authentication protocol to be used. A NAS is  not  required  to
        implement all of these authentication types, and MUST treat unknown
        or unsupported EAP-Authentication-Types as though an  Access-Reject
        had been received instead.
     
        A  summary of the EAP-Authentication-Type Attribute format is shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2
        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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     | Value         |
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                         17 January 1997
     
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     Type
     
        69 for EAP-Authentication-Type
     
     Length
     
        3
     
     Value
     
        The Value field is a single octet.
     
        0      Request for EAP redirection (Access-Request only)
        1      Identity
        2      Notification
        3      Nak (Response only)
        4      MD5-Challenge
        5      S/Key (RFC 1760)
        6      Generic Token Card
     
     
     5.2.  EAP-Authentication-Server-Endpoint
     
     Description
     
        When included in an Access-Request  message,  this  attribute  MUST
        contain a value of 0, used to indicate a request for an EAP authen-
        tication server endpoint address and port. If this attribute is not
        included  in  the  Access-Request,  it  When returned in an Access-
        Reply/Accept message, this Attribute indicates the address  of  the
        backend security server.
     
        A summary of the Authentication-Server-Endpoint Attribute format is
        shown below.  The fields are transmitted from left to right.
     
        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |     Type      |    Length     |  String ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     
     
     Type
     
        70 for EAP-Authentication-Server-Endpoint.
     
     Length
     
        =8 for IPv4, 20 for IPv6
     
     String
     
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                         17 January 1997
     
     
        The structure of the string field is as follows:
     
        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 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Port               |    Address ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Address  ...              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        The string field consists of a two-octet port field, as well as  an
        address field.  The length of the address depends on whether we are
        using IPv4 or IPv6. In IPv4, the attribute is 8 octets  in  length,
        and in IPv6, it is 20 octets in length.  length.
     
     
     
     6.  Security Issues
     
     This specification raises two major security issues: the use of a mod-
     ified User-Password attribute in the Access-Request, and the use of an
     EAP encapsulation over the Internet.
     
     In a conventional RADIUS conversation, user attributes are sent by the
     RADIUS server to the NAS only after the user password has  been  veri-
     fied.  In  the protocol specified in this document, the attributes are
     sent on verification of the secret shared  between  the  NAS  and  the
     RADIUS  server. While the User-Password scheme described here protects
     against modification of the  Access-Request  message,  which  standard
     RADIUS  does  not,  it makes it more likely that an attacker obtaining
     the shared secret would then also be able  to  obtain  user  attribute
     information. The most important such information is the knowledge that
     an account exists for a given userID, although other attributes  (such
     as the user's IP address or framing) may also be of interest.
     
     While  this  risk  can be mitigated by requiring an MD5 authentication
     prior to release of the connection setup  information,  and  including
     the  CHAP-Password  attribute  in  the Access-Request, use of multiple
     authentications may not be desirable in many applications.
     
     The scheme described in this document results in the NAS entering to a
     direct  conversation  with  a  backend  security  server, while in the
     scheme described in [2], the RADIUS server shuttles EAP  packets  back
     and forth between the NAS and the backend security server. In the sit-
     uation where the RADIUS server is located close to the  backend  secu-
     rity  server,  the  conversation  between the NAS and RADIUS server or
     backend security server will typically occur over the Internet,  while
     a  conversation  between  a  RADIUS server and backend security server
     will typically occur over a local LAN or other private network.
     
     Since the security of an EAP authentication is only  as  good  as  the
     weakest  link,  it  is  worthwhile  to examine the security aspects of
     these conversations. In the conversation between the NAS and the back-
     end  security  server  or  RADIUS  server,  it is desirable for mutual
     
     
     
     Aboba & Zorn                                                  [Page 6]


     INTERNET-DRAFT                                         17 January 1997
     
     
     authentication to be provided. However, typically  encryption  of  the
     EAP  conversation  is not required, since EAP authentication protocols
     have already taken the possibility of snooping into account.
     
     In the scheme described here, the conversation  between  the  NAS  and
     backend  security  server can either occur via a proprietary protocol,
     or via an EAP encapsulation. Assuming that the  EAP  encapsulation  is
     secured  (via  SSL  or IP Sec), then mutual authentication can be pro-
     vided, as well as encryption. As described earlier, the use of a modi-
     fied  User-Password  attribute provides assurance to the RADIUS server
     that the Access-Request comes from a legitimate NAS  device,  and  the
     Authenticator  provided  in the Access-Reply provides assurance to the
     RADIUS client that the reply comes from a legitimate RADIUS server.
     
     The scheme described in [2] provides for mutual authentication between
     the  NAS  and  RADIUS  server. This is handled via a message integrity
     check (MIC) included within the Access-Request. As a result,  expanded
     RADIUS  provides  assurance  of the authenticity and integrity of both
     EAP requests and responses.
     
     While [2] does not describe the communication mechanisms  between  the
     RADIUS server and backend security server, it can be assumed that this
     also occurs either via a proprietary protocol, or via an EAP  encapsu-
     lation.  However, since the conversation between the RADIUS server and
     backend security server is likely to occur over a LAN or private  net-
     work, security concerns are typically not as severe.
     
     
     7.  Acknowledgements
     
     Thanks  to  Gurdeep  Singh  Pall,  Peter Ford, and Narendra Gidwani of
     Microsoft for useful discussions of this problem space.
     
     
     8.  References
     
     [1] L. J. Blunk, J. R.  Vollbrecht.   "PPP  Extensible  Authentication
     Protocol  (EAP)."  draft-ietf-pppext-eap-auth-02.txt,  Merit  Network,
     Inc., June, 1996.
     
     [2] A. Rubens, P.R. Calhoun.  "Enhanced Remote Authentication Dial  In
     User  Service  (RADIUS)  Extensible  Authentication Protocol Support."
     draft-calhoun-enh-radius-eap-00.txt, Merit Network, Inc., US  Robotics
     Access Crop., June, 1996.
     
     [3]  C. Rigney, A. Rubens, W. A. Simpson, S. Willens.  "Remote Authen-
     tication  Dial   In   User   Service   (RADIUS)."   draft-ietf-radius-
     radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
     
     [4]    C.  Rigney.   "RADIUS  Accounting."  draft-ietf-radius-account-
     ing-05.txt, Livingston, July 1996.
     
     
     
     
     
     
     Aboba & Zorn                                                  [Page 7]


     INTERNET-DRAFT                                         17 January 1997
     
     
     9.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     
     
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                  [Page 8]
     

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