Internet Draft
INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Microsystems, Inc.
Title: draft-calhoun-diameter-eap-03.txt                    Allan Rubens
Date: August 1999                                   Ascend Networks Inc.
                                                               Jeff Haag
                                                           Cisco Systems



                                DIAMETER
          Extensible Authentication Protocol (EAP) Extensions



Status of this Memo

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@ipass.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.


Abstract

   The Extensible Authentication Protocol (EAP) is a PPP extension that
   provides support for additional authentication methods within PPP.
   This document describes how EAP can be carried within the DIAMETER
   protocol to provide end to end authentication.



Calhoun, Rubens, Haag     expires January 2000                  [Page 1]





INTERNET DRAFT                                               August 1999


Table of Contents

      1.0  Introduction
            1.1  Copyright Statement
            1.2  Requirements language
            1.3  Changes in version -02
      2.0  Command Codes
            2.1  DIAMETER-EAP-Request
            2.2  DIAMETER-EAP-Answer
            2.3  DIAMETER-EAP-Ind
      3.0  DIAMETER AVPs
            3.1  EAP-Packet
      4.0  Protocol overview
            4.1  Retransmission and Timers
            4.2  Example of an OTP Authentication
                  4.2.1  Successful Authentication
                  4.2.2  NAS Initiated EAP Authentication
                  4.2.3  Server-Initiated Authentication
                  4.2.4  Example of failed EAP Authentication
                  4.2.5  Example of DIAMETER not supporting EAP
                  4.2.6  Example of DIAMETER Proxy not supporting EAP
                  4.2.7  Example of PPP Client not supporting EAP
            4.3  Feature Advertisement/Discovery
      5.0  Alternative uses
      6.0  IANA Considerations
      7.0  Acknowledgments
      8.0  References
      9.0  Authors' Addresses
      10.0 Full Copyright Statement


1.0  Introduction

   The Extensible Authentication Protocol (EAP), described in [1],
   provides 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, One Time Passwords, and others. In order
   to provide for support of EAP within DIAMETER, two new attributes,
   EAP-Message and Signature, were introduced as DIAMETER extensions in
   [5]. This document describes how these new attributes may be used for
   providing EAP support within DIAMETER.

   The scheme described here is similar to that proposed in [2], in that
   the DIAMETER server is used to shuttle DIAMETER-encapsulated EAP
   Packets between the NAS and a backend security server. While the
   conversation between the DIAMETER server and the backend security
   server will typically occur using a proprietary protocol developed by



Calhoun, Rubens, Haag     expires January 2000                  [Page 2]





INTERNET DRAFT                                               August 1999


   the backend security server vendor, it is also possible to use
   DIAMETER-encapsulated EAP via the EAP-Packet AVP. This has the
   advantage of allowing the DIAMETER server to support EAP without the
   need for authentication- specific code, which can instead reside on a
   backend security server.

   This proposal serves three purposes:

      1. It provides for end-to-end authentication, between the user and
      his/her home DIAMETER server. End-to-End authentication, as
      described in this specification, greatly reduces the possibility
      for fraudulent authentication, such as replay attacks.

      2. It allows for mutual (bi-directional) authentication. When PPP
      or CHAP are used as the PPP authentication mechanism, it is not
      possible to perform bi-directional authentication since the
      authenticator (e.g. the NAS) does not have access to the DIAMETER
      Server's authentication information.  Although it would be
      possible for the DIAMETER server to "download" the authentication
      information to the NAS, even encrypted, it would be quite unwise
      to do so in roaming environments where the NAS and the
      authenticating DIAMETER server are not owned by the same
      Administrative Domain.

      3. It allows for home DIAMETER server initiated authentication.
      Since the Home DIAMETER server may initially authenticate and
      authorize the user for a finite period, it may periodically send
      an authentication request to the user to ensure that the user is
      still active. Furthermore, this will allow the Home DIAMETER
      server to re-authorize the user for access for a finite amount of
      time. See [8] for more information.

      The Extension number for this draft is three (3). This value is
      used in the Extension-Id Attribute value Pair (AVP) as defined in
      [7].


1.1  Copyright Statement

   Copyright   (C) The Internet Society 1999.  All Rights Reserved.


1.2  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [6].




Calhoun, Rubens, Haag     expires January 2000                  [Page 3]





INTERNET DRAFT                                               August 1999


1.3  Changes in version -03

   The following changes were made in this revision of the document:

      - The document introduces the DIAMETER-EAP-Ind to allow the server
      to initiate an unsolicited authentication session with the PPP
      client as described in [8].

      - The AVP Header formats have changed since the last version of
      this draft.

      - IANA considerations were added, as well as many new useful
      references.

      - Well, to be honest, the list of changes are just too great list.
      This document needed a good re-write. Here it is.


2.0  Command Codes

   This section will define the Commands [1] for DIAMETER
   implementations supporting the Mobile IP extension.

      Command Name          Command Code
      -----------------------------------
      DIAMETER-EAP-Request      ???
      DIAMETER-EAP-Answer       ???
      DIAMETER-EAP-Ind          ???


2.1  DIAMETER-EAP-Request

   Description

      The DIAMETER-EAP-Request command is sent by a DIAMETER Client to a
      DIAMETER Server and conveys an EAP-Response [1] from the dial-up
      PPP Client. The DIAMETER-EAP-Request MUST contain one EAP-Packet
      AVP, which contains the actual EAP payload. A EAP-Packet AVP with
      no data MAY be sent to the DIAMETER Server to initiate an EAP
      authentication session.

      Upon receipt of a DIAMETER-EAP-Request, A DIAMETER Server MUST
      issue a reply. The reply may be either:

         1) a DIAMETER-EAP-Answer containing an EAP-Request in at lease
         one EAP-Packet attribute

         2) a DIAMETER-EAP-Answer containing an EAP-Packet of type



Calhoun, Rubens, Haag     expires January 2000                  [Page 4]





INTERNET DRAFT                                               August 1999


         "success" and a Result Code AVP indicating success

         3) a DIAMETER-EAP-Answer containing an EAP-Packet of type
         "failure" and a Result-Code AVP indicating failure.

         4) A Message-Reject-Ind packet is returned if the server does
         not support the EAP extensions.

   Message Format

       ::= 
                                 
                                 
                                 []
                                 
                                 
                                 
                                 
                                 { ||
                                   ::= 
                                
                                
                                



Calhoun, Rubens, Haag     expires January 2000                  [Page 6]





INTERNET DRAFT                                               August 1999


                                []
                                
                                
                                
                                
                                
                                { ||
                                  ::= 
                             
                             
                             []
                             
                             
                             
                             
                             { ||
                              
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/Start ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/Identity
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Success
                                                     (other attributes)
                            <- PPP EAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


4.2.2  NAS Initiated EAP Authentication

   In the case where the  NAS  sends  the  authenticating  peer  an



Calhoun, Rubens, Haag     expires January 2000                 [Page 15]





INTERNET DRAFT                                               August 1999


   EAP- Request/Identity  packet  without first sending an EAP-Start
   packet to the DIAMETER server, the conversation would appear as
   follows:

      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------


                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Success
                                                     (other attributes)
                            <- PPP EAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


  4.2.3  Server-Initiated Authentication

   As described in [8], when a server has successfully authenticated and
   authorized a user, it may include a timeout period to the



Calhoun, Rubens, Haag     expires January 2000                 [Page 16]





INTERNET DRAFT                                               August 1999


   authorization.  The server can later initiate an unsolicited re-
   authentication request to the user, through the NAS. This method has
   the advantage of reducing the number of round trips required for re-
   authentication/authorization.

      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                                                     <- DIAMETER-EAP-Ind/
                                                     EAP-Packet/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Success
                                                     (other attributes)
                            <- PPP EAP-Success


4.2.4  Example of failed EAP Authentication

   In  the  case  where  the  client  fails   EAP   authentication,
   the conversation would appear as follows:




















Calhoun, Rubens, Haag     expires January 2000                 [Page 17]





INTERNET DRAFT                                               August 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/Start ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/Identity
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/EAP-Failure
                            <- PPP EAP-Failure

                            <- LCP Terminate


4.2.5  Example of DIAMETER not supporting EAP

   In the case that the DIAMETER server or proxy does not support EAP
   extensions the conversation would appear as follows:




Calhoun, Rubens, Haag     expires January 2000                 [Page 18]





INTERNET DRAFT                                               August 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER
                            EAP-Request/
                            EAP-Packet/Start ->
                                                     <- DIAMETER
                                                     Command-Unrecognized
                            <- PPP LCP Request-CHAP
                            auth

      PPP LCP ACK-CHAP
      auth ->
                            <- PPP CHAP Challenge
      PPP CHAP Response ->
                            DIAMETER
                            AA-Request->
                                                     <- DIAMETER
                                                     AA-Answer
                            <- PPP LCP
                            CHAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


4.2.6  Example of DIAMETER Proxy not supporting EAP

   In the case where the local DIAMETER Server does support the EAP
   extensions but the remote DIAMETER Server does not, the conversation
   would appear as follows:
















Calhoun, Rubens, Haag     expires January 2000                 [Page 19]





INTERNET DRAFT                                               August 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/Start ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet/Identity
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity
      (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Packet/EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer
                                                     (proxied from remote
                                                     DIAMETER Server)
                            <- PPP LCP Request-CHAP
                            auth
      PPP LCP ACK-CHAP
      auth ->
                            <- PPP CHAP Challenge
      PPP CHAP Response ->
                            DIAMETER
                            AA-Request->
                                                     <- DIAMETER
                                                     AA-Answer
                                                     (proxied from remote
                                                     DIAMETER Server)
                            <- PPP LCP
                            CHAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


4.2.7  Example of PPP Client not supporting EAP

   In the case where the authenticating peer does not support EAP, but



Calhoun, Rubens, Haag     expires January 2000                 [Page 20]





INTERNET DRAFT                                               August 1999


   where EAP is required for that user, the conversation would appear as
   follows:

      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP NAK-EAP
      auth ->
                            <- PPP LCP Request-EAP
                            auth
      PPP LCP NAK-EAP
      auth ->
                            <- PPP LCP Request-CHAP
                            auth
      PPP LCP ACK-CHAP
      auth ->
                            <- PPP CHAP Challenge
      PPP CHAP Response ->

                            DIAMETER-
                            AA-Request/
                            User-Name,
                            CHAP-Password ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Packet
                            <- LCP Terminate Req


4.3  Feature Advertisement/Discovery

   As defined in [8], the Reboot-Ind and Device-Feature-Query messages
   can be used to inform a peer about locally supported DIAMETER
   Extensions. In order to advertise support of this extension, the
   Extension-Id AVP must be transmitted with a value of three (3).


5.0  Alternative uses

   Currently the conversation between the backend security server and
   the DIAMETER server is proprietary because of lack of
   standardization. In order to increase standardization and provide
   interoperability between DIAMETER vendors and backend security
   vendors, it is recommended that DIAMETER-encapsulated EAP be used for
   this conversation.




Calhoun, Rubens, Haag     expires January 2000                 [Page 21]





INTERNET DRAFT                                               August 1999


   This has the advantage of allowing the DIAMETER server to support EAP
   without the need for authentication-specific code within the DIAMETER
   server. Authentication-specific code can then reside on a backend
   security server instead.

   In the case where DIAMETER-encapsulated EAP is used in a conversation
   between a DIAMETER server and a backend security server, the Security
   Server will typically return an DIAMETER-EAP-Aanswer/EAP-Packet/EAP-
   Success message without inclusion of the expected attributes
   currently returned in a successful AA-Answer [2]. This means that the
   DIAMETER server MUST add these attributes prior to sending an
   DIAMETER-EAP- Answer/EAP-Packet/EAP-Success message to the NAS.


6.0  IANA Considerations

   The numbers for the Command Code AVPs (section 3) is taken from the
   numbering space defined for Command Codes in [2]. The numbers for the
   various AVPs defined in section 4 were taken from the AVP numbering
   space defined in [2].  The numbering for the AVP and Command Codes
   MUST NOT conflict with values specified in [2] and other DIAMETER
   related Internet Drafts.

   This document also introduces two new bits to the AVP Header, which
   MUST NOT conflict with the base protocol [2] and any other DIAMETER
   extension.


7.0  Acknowledgments

   Thanks for Bernard Aboba for his contribution to [9]. Much of the
   text found in this draft was taken directly from the said draft.


8.0  References

   [1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
       Protocol (EAP)." RFC 2284, March 1998.
   [2] P. R. Calhoun, "DIAMETER Authentication Extension",
       draft-calhoun-diameter-auth-06.txt, August 1999.
   [3] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
       Authentication Dial In User Service (RADIUS)." RFC 2138,
       April 1997.
   [4] C. Rigney, "RADIUS Accounting." RFC 2139,  April 1997.
   [5] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm",
       RFC 1321, April 1992
   [6] S. Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.



Calhoun, Rubens, Haag     expires January 2000                 [Page 22]





INTERNET DRAFT                                               August 1999


   [7] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
       draft-calhoun-diameter-08.txt, August 1999.
   [8] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming",
       draft-ietf-roamops-fraud-limit-00.txt, May 1999.
   [9] P. R. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication
       Protocol Support in RADIUS", draft-ietf-radius-eap-05.txt,
       Work in Progress, May 1998.
   [10] Narten, Alvestrand,"Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434,
        October 1998
   [11] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
        July 1994.
   [12] N Haller, C. Metz, P. Nesset, M. Straw, "A One-Time
        Password (OTP) System", RFC 2289, February 1998.
   [13] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions",
        draft-calhoun-diameter-proxy-02.txt, Work in Progress,
        August 1999.


9.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com


      Allan C. Rubens
      Ascend Communications
      1678 Broadway
      Ann Arbor, MI 48105-1812
      USA

       Phone:  1-734-761-6025
      E-Mail:  acr@del.com


      Jeff Haag
      Cisco Systems
      7025 Kit Creek Road



Calhoun, Rubens, Haag     expires January 2000                 [Page 23]





INTERNET DRAFT                                               August 1999


      PO Box 14987
      Research Triangle Park, NC 27709

       Phone:  1-919-392-2353
      E-Mail:  haag@cisco.com


10.0  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 docu- ment itself may not be modified in any
   way, such as  by  removing  the copyright notice or references to the
   Internet Society or other Inter- net 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 permis- sions 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  WAR- RANTY  THAT  THE  USE  OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS  FOR  A PARTICULAR PURPOSE."



















Calhoun, Rubens, Haag     expires January 2000                 [Page 24]