INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Laboratories, Inc. Title: draft-calhoun-diameter-eap-02.txt Allan Rubens Date: November 1998 Merit Networks Inc. Jeff Haag Cisco Systems DIAMETER Extensible Authentication Protocol Extensions Status of this Memo Comments should be submitted to the diameter@ipass.com mailing list. 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 view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This document describes how the EAP-Message and Signature attributes may be used for providing EAP support within DIAMETER. Table of Contents 1.0 Introduction 1.1 Definitions 2.0 Protocol overview 2.1 DIAMETER Initiated EAP Authentication 2.2 NAS Initiated EAP Authentication 2.3 Example of failed EAP Authentication 2.4 Example of DIAMETER not supporting EAP 2.5 Example of DIAMETER Proxy not supporting EAP 2.6 Example of PPP Client not supporting EAP 3.0 Alternative uses 4.0 Command Codes 4.1 DIAMETER-EAP-Request 4.2 DIAMETER-EAP-Answer 5.0 DIAMETER AVPs 5.1 EAP-Packet 6.0 Acknowledgments 7.0 References 8.0 Authors' Addresses 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 smart cards, Kerberos, Public Key, One Time Passwords, and others. In order to provide for support of EAP within DIAMETER, four new commands are introduced in this document. The scheme described here is similar to that proposed in [5], in that the DIAMETER server is used to shuttle DIAMETER-encapsulated EAP Packets between the NAS and a backend security server. However the proposal described here does not suffer from the fragmentation and lack of appropriate security mechanisms present in [5]. While the conversation between the DIAMETER server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use DIAMETER-encapsulated EAP via the EAP-Message attribute. 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. 1.1 Definitions In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2.0 Protocol overview The EAP conversation between the authenticating peer (dial-in user) and the NAS begins with the negotiation of EAP within LCP. Once EAP has been negotiated, the NAS MUST send an EAP-Request/Identity message to the authenticating peer, unless identity is determined via some other means such as Called-Station-Id or Calling-Stating-Id. The peer will then respond with the EAP-Response/Identity which the NAS will then forward to the DIAMETER server in the EAP-Packet AVP of the DIAMETER-EAP-Request command. The DIAMETER server will typically use the EAP-Response/Identity to determine which EAP type is to be applied to the user. In order to simplify any DIAMETER Proxies task, the NAS MUST copy the contents of the EAP-Response/Identity into the User-Name AVP and MUST include the EAP-Response/Identity in the User-Name AVP in every subsequent DIAMETER EAP messages. The DIAMETER Server MUST include the User-Name in all DIAMETER-EAP-Answer packets as well. The Host-IP-Address or Host-Name AVP SHOULD be present in all DIAMETER EAP messages. Without the User-Name AVP, accounting and billing becomes very difficult to manage. If identity is determined via another means such as Called-Station-Id or Calling-Station-Id, the NAS MUST include these identifying attributes in every DIAMETER-EAP-Request, and the DIAMETER Server MUST include them in every DIAMETER-EAP-Answer message. While this approach will save a round-trip, it cannot be universally employed. There are circumstances in which the user's identity may not be needed (such as when authentication and accounting is handled based on Called-Station-Id or Calling-Station-Id), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. In cases where an EAP-Request/Identity packet will not be sent, the NAS will send to the DIAMETER server a DIAMETER-EAP-Request packet containing an EAP-Packet attribute signifying EAP-Start. EAP-Start is indicated by sending an EAP-Packet attribute with a length of 2 (no data). However, it should be noted that since no User-Name attribute is included in the DIAMETER-EAP-Request, this approach cannot easily be applied in situations where proxies are deployed, such as roaming or shared use networks. If the DIAMETER server supports EAP, it MUST respond with a DIAMETER-EAP-Answer packet containing an EAP-Packet AVP. If the DIAMETER server does not support EAP, it MUST respond with a Message-Reject-Ind [2]. The EAP-Packet AVP includes an encapsulated EAP packet which is then passed on to the authenticating peer. In the case where the NAS does not initially send an EAP-Request/Identity message to the peer, the DIAMETER-EAP-Answer typically will contain an EAP-Packet AVP encapsulating an EAP-Request/Identity message, requesting the dial-in user to identify themself. The NAS will then respond with a DIAMETER-EAP-Request packet containing an EAP-Packet AVP encapsulating an EAP-Response. The conversation continues until a DIAMETER-EAP-Answer message is received with a Result-Code AVP indicating either success or failure. Reception of a DIAMETER-EAP-Answer packet with a Result-Code AVP that indicates a failure, with or without an EAP-Packet AVP encapsulating EAP-Failure, MUST result in the NAS issuing an LCP Terminate Request to the authenticating peer. A DIAMETER-EAP-Answer packet with a Result-Code AVP indicating success and an EAP-Packet AVP encapsulating EAP-Success successfully ends the authentication phase. The DIAMETER-EAP-Ack/EAP-Packet/EAP-Success packet MUST contain all of the expected AVPs which are currently required for the requested service. The above scenario creates a situation in which the NAS never needs to manipulate an EAP packet. An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer. For proxied DIAMETER requests there are two methods of processing. If the domain is determined based on the Called-Station-Id, the DIAMETER Server may proxy the initial DIAMETER-EAP-Request/EAP-Start. If the domain is determined based on the user's identity, the local DIAMETER Server MUST respond with a DIAMETER-EAP-Answer/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server. For proxied DIAMETER requests, the NAS may receive an Message-Reject-Ind packet in response to its DIAMETER-EAP-Request/EAP-Identity packet. This would occur if the message was proxied to a DIAMETER Server which does not support the EAP extension. On receiving an Message-Reject-Ind, the NAS MUST send an LCP Terminate Request to the authenticating peer, and disconnect. It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptography. In order to prevent attackers from subverting EAP by attacking DIAMETER/EAP, (for example, by modifying the EAP-Success or EAP-Failure packets) it is necessary that DIAMETER/EAP provide integrity protection at least as strong as those used in the EAP methods themselves. The following provides examples of EAP authentication using OTP under different conditions. 2.1 DIAMETER Initiated EAP Authentication The example below shows the conversation between the authenticating peer, NAS, and server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they would show somewhat different behavior. 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/ Result-Code OK/ EAP-Packet/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts 2.2 NAS Initiated EAP Authentication In the case where the NAS sends the authenticating peer an 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/ Result-Code OK/ EAP-Packet/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts 2.3 Example of failed EAP Authentication In the case where the client fails EAP authentication, the conversation would appear as follows: 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/ Result-Code ! OK/ EAP-Packet/EAP-Failure <- PPP EAP-Failure <- PPP LCP Terminate (User Disconnected) 2.4 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: Authenticating Peer NAS DIAMETER Server ------------------- --- --------------- <- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> DIAMETER EAP-Request/ EAP-Packet/Start -> <- DIAMETER Message-Reject-Ind <- PPP LCP Terminate (User Disconnected) 2.5 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: 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 Message-Reject-Ind <- PPP LCP Terminate (User Disconnected) 2.6 Example of PPP Client not supporting EAP In the case where the authenticating peer does not support EAP, but 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- Authentication-Request/ User-Name, CHAP-Password -> <- DIAMETER- EAP-Answer/ EAP-Packet <- LCP Terminate Req (User Disconnected) 3.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. 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-Answer/EAP-Packet/EAP- Success message without inclusion of the expected attributes currently returned in an Authentication-Success. 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. 4.0 Command Codes This document defines the following DIAMETER Commands. All DIAMETER implementations supporting this extension MUST support all of the following commands: Command Name Command Code ----------------------------------- EAP-Packet TBD DIAMETER-EAP-Request TBD DIAMETER-EAP-Answer TDB 4.1 DIAMETER-EAP-Request Description DIAMETER-EAP-Request command is sent by the DIAMETER Client to the DIAMETER Server, and convey EAP-Responses from the client through the NAS and on to the DIAMETER server. DIAMETER-EAP-Requests will normally include at least one EAP-Packet attribute which contains the EAP packets. 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 "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. The DIAMETER-EAP-Request message MUST include either the Integrity- Check-Vector or the Digital-Signature AVP depending upon the local policy. A DIAMETER Server MUST calculate the correct calue of the Signature and silently discard the packet if it does not match the value sent. A summary of the DIAMETER-EAP-Request packet format is shown below. The fields are transmitted from left to right. Message Format DIAMETER-EAP-Request ::= <DIAMETER Header> <DIAMETER-EAP-Request Command AVP> <Host-IP-Address AVP> [<Host-Name AVP>] <EAP-Packet AVP> <User-Name AVP> <Timestamp AVP> <Initialization-Vector AVP> {<Integrity-Check-Vector AVP> || <Digital-Signature AVP } in 3 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER-Command AVP Length The length of this attribute MUST be at exactly 12. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Command Code The Command Code field MUST be set to TBD (DIAMETER-EAP- Request). 4.2 DIAMETER-EAP-Answer Description DIAMETER-EAP-Answer packets are sent by the DIAMETER Server to the NAS. They contain the next EAP-Request packet to be passed to the client. The DIAMETER-EAP-Answer MUST contain at least one EAP-Packet AVP and MUST include either the Integrity-Check-Vector or the Digital-Signature AVP depending upon the local policy. A DIAMETER Server MUST calculate the correct value of the authentication AVP and silently discard the packet if it does not match the value sent. If the Result-Code AVP is present in the message it indicates that authentication is complete, Otherwise after issuing the included EAP-Request to the client, the NAS remains in a state where it awaits further EAP-Responses from the client. This message with a Result-Code AVP that indicates success MUST have an accompanying EAP-Success message within the EAP-Packet AVP. If the Result-Code AVP indicates failure, an accompanying EAP-Failure message SHOULD be present in the EAP-Packet AVP. A summary of the DIAMETER-EAP-Answer packet format is shown below. The fields are transmitted from left to right. Message Format DIAMETER-EAP-Answer ::= <DIAMETER Header> <DIAMETER-EAP-Answer Command AVP> <Result-Code AVP> <Host-IP-Address AVP> [<Host-Name AVP>] <EAP-Packet AVP> <User-Name AVP> <Timestamp AVP> <Initialization-Vector AVP> {<Integrity-Check-Vector AVP> || <Digital-Signature AVP } in 3 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER-Command AVP Length The length of this attribute MUST be at exactly 12. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Command Code The Command Code field MUST be set to TDB (DIAMETER-EAP- Answer). 5.0 DIAMETER AVPs This section will define the mandatory AVPs which MUST be supported by all DIAMETER implementations supporting this extension. The following AVPs are defined in this document: Attribute Name Attribute Code ----------------------------------- EAP-Packet TBD 5.1 EAP-Packet Description This attribute is used to contain the actual EAP-Requests to be sent from the DIAMETER server to the client (DIAMETER-EAP-Ack and DIAMETER-EAP-Reject) and the EAP-Responses to be sent from the client to the DIAMETER server (DIAMETER-EAP-Requests). These EAP- Requests and Responses are exactly as defined in [1]. AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code TBD EAP-Packet AVP Length The length of this attribute MUST be at least 24. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Data The String field is one or more octets, and should be unique to the DIAMETER host. The Host Name MUST follow the NAI [6] naming conventions. 6.0 Acknowledgments Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn Jeff Haag of 3Com for useful discussions. 7.0 References [1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)." RFC 2284, March 1998. [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-07.txt, Work in Progress, November 1998. [3] P. R. Calhoun, "DIAMETER Authentication Extension", draft-calhoun-diameter-auth-04.txt, Work in Progress, February 1998. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, August 1996. [5] P. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication Protocol Support in RADIUS", draft-ietf-radius-eap-05.txt, Work in Progress, May 1998. [6] B. Aboba. "The Network Access Identifier." draft-ietf-roamops-nai-11.txt, Work in Progress, July 1998. 8.0 Author's Address Questions about this memo can be directed to: Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-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 W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 Phone: 1-919-472-2353 E-Mail: haag@cisco.com