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]