INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-eap-01.txt Allan Rubens Date: March 1998 Merit Networks Inc. Bernard Aboba Microsoft Corporation DIAMETER Extensible Authentication Protocol Extensions Status of this Memo 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``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, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. 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 Example of an OTP 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 Calhoun, Rubens, Aboba expires September 1998 [Page 1] INTERNET DRAFT March 1998 2.6 Example of PPP Client not supporting EAP 3.0 Alternative uses 4.0 Command Name and Command Code 5.0 Command Meanings 5.1 DIAMETER-EAP-Request 5.2 DIAMETER-EAP-Response 5.3 DIAMETER-EAP-Ack 5.4 DIAMETER-EAP-Reject 6.0 Attribute Name and Attribute Code 7.0 Attribute Meanings 7.1 EAP-Packet 8.0 Acknowledgments 9.0 References 10.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 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 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. This original document was named Enhanced RADIUS and was changed at the request of the WG since this protocol is different from the former. This document describes a management protocol used between Network Access Servers and DIAMETER Servers for authentication, authorization, and accounting of dial-up users. A considerable amount of effort was put into the design of this protocol to ensure that an implementation could support both DIAMETER and RADIUS at the same time. Calhoun, Rubens, Aboba expires September 1998 [Page 2] INTERNET DRAFT March 1998 Calhoun, Rubens, Aboba expires September 1998 [Page 3] INTERNET DRAFT March 1998 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 and the NAS begins with the negotiation of EAP within LCP. Once EAP has been negotiated, the NAS will typically send to the DIAMETER server a DIAMETER Message packet containing the DIAMETER-EAP-Request Command signifying an EAP-Start. EAP-Start is indicated by sending an DIAMETER-EAP-Request Command with an EAP-Packet attribute with a length of 7 (no data). The Port number and NAS Identifier MUST be included in the attributes issued by the NAS in the DIAMETER-EAP- Request packet. If the DIAMETER server supports EAP, it MUST respond with an DIAMETER- EAP-Response packet containing an EAP-Packet attribute. The EAP-Packet attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. The DIAMETER-EAP-Response typically will contain an EAP-Packet attribute encapsulating an EAP-Request/Identity message, requesting the authenticating peer to identify itself. The NAS will then respond with a DIAMETER-EAP-Request packet containing an EAP-Packet attribute encapsulating an EAP-Response, etc. The conversation continues until either a DIAMETER-EAP-Reject packet is received (with an EAP-Packet attribute encapsulating EAP-Failure) which results in the NAS disconnecting the user, or a DIAMETER-EAP-Ack packet is received (with an EAP-Packet attribute encapsulating EAP- Success) successfully ending the authentication phase. Note that if a Calhoun, Rubens, Aboba expires September 1998 [Page 4] INTERNET DRAFT March 1998 DIAMETER-EAP-Reject packet with an EAP-Packet attribute encapsulating EAP-Failure is received from the DIAMETER Server, the NAS SHOULD issue an LCP Terminate Request to the authenticating peer. 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. This involves having the NAS send an EAP- Request/Identity message to the authenticating peer, and forwarding the EAP-Response/Identity packet to the DIAMETER server in the EAP- Packet attribute of a DIAMETER-EAP-Request packet. 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 the calling or called phone number), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. Unless the NAS interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user's identity. Therefore, the DIAMETER Server SHOULD return the user's identity by inserting it in the User-Name attribute of subsequent DIAMETER-EAP-Response and DIAMETER-EAP-Ack packets. Without the user's identity, accounting and billing becomes very difficult to manage. In cases where a backup DIAMETER servers is available, were the primary server to fail at any time during the EAP conversation, it would be desirable for the NAS to be able to redirect the conversation to an alternate DIAMETER server. However, for the backup server to be able to pick up the conversation, it must be provided with the state of the EAP conversation prior to the interruption. This can be accomplished by having the DIAMETER-EAP-Request include the series of EAP-Packet attributes representing the previous history of the EAP conversation. Similarly, the DIAMETER-EAP-Response returned by the DIAMETER server must also include all previous EAP-Packet attributes. The sequence number field in the EAP-Packet attribute MUST be used in order to determine which attribute is to be processed. The attribute with the highest sequence number is the most recent attribute. The DIAMETER-EAP-Ack/EAP-Packet/EAP-Success packet MUST contain all of the expected attributes which are currently returned in a DIAMETER Authentication-Success packet. For proxied DIAMETER requests there are two methods of processing. If the domain is determined based on the DNIS 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-Response/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final Calhoun, Rubens, Aboba expires September 1998 [Page 5] INTERNET DRAFT March 1998 authentication server. For proxied DIAMETER requests, the NAS may receive an Command Unrecongnized 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 DIAMETER EAP extensions. At this point, the NAS MUST re-open LCP with the authenticating peer and request either CHAP or PAP as the authentication protocol. If the NAS is unable to negotiate EAP with the authenticating peer, what happens next is a matter of policy. In circumstances where EAP is required of all users accessing the NAS, the NAS MUST disconnect the user. However, in circumstances where EAP is mandatory for some users, and optional or not required for others, the decision cannot be made until the user's identity is ascertained. In this case, the NAS will negotiate another authentication method, such as CHAP, and will pass the User-Name and CHAP-Password attributes to the DIAMETER Server in an Authentication-Request message. If the user is not required to use EAP, then the DIAMETER Server will respond with an Authentication- Success or Authentication-Failure packet as appropriate. However, should the user require EAP, then the DIAMETER Server will respond with an DIAMETER-EAP-Response packet containing an EAP-Packet attribute. The EAP-Packet attribute will either encapsulate an EAP- Request/Identity packet, or if the DIAMETER Server makes use of the User-Name attribute in the Authentication-Request, it may encapsulate an EAP challenge. On receiving the EAP-Packet attribute, the NAS will either attempt to negotiate EAP if it had not done so previously, or if negotiation had previously been attempted and failed, it MUST disconnect the user. The NAS is not responsible for the retransmission of any EAP messages. The authenticating peer and the DIAMETER Server are responsible for any retransmissions. 2.1 Example of an OTP 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. For brevity, the history of previous EAP messages (which will be transmitted in each DIAMETER-EAP- Request and DIAMETER-EAP-Response packet) has been left out. Authenticating Peer NAS DIAMETER Server ------------------- --- --------------- <- PPP LCP Request-EAP auth Calhoun, Rubens, Aboba expires September 1998 [Page 6] INTERNET DRAFT March 1998 PPP LCP ACK-EAP auth -> DIAMETER- EAP-Request/ EAP-Packet/Start -> <- DIAMETER- EAP-Response/ EAP-Packet/Identity <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> DIAMETER- EAP-Request/ EAP-Packet/ EAP-Response/ (MyID) -> <- DIAMETER- EAP-Response/ 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-Ack/ 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 Calhoun, Rubens, Aboba expires September 1998 [Page 7] INTERNET DRAFT March 1998 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-Response/ 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-Ack/ 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- Calhoun, Rubens, Aboba expires September 1998 [Page 8] INTERNET DRAFT March 1998 EAP-Response/ EAP-Packet/Identity <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> DIAMETER- EAP-Request/ EAP-Packet/ EAP-Response/ (MyID) -> <- DIAMETER- EAP-Response/ 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-Reject/ EAP-Packet/EAP-Failure <- PPP EAP-Failure <- LCP Terminate 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 Command-Unrecognized <- PPP LCP Request-CHAP Calhoun, Rubens, Aboba expires September 1998 [Page 9] INTERNET DRAFT March 1998 auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> DIAMETER Authentication-Request-> <- DIAMETER Authentication-Success <- PPP LCP CHAP-Success PPP Authentication Phase complete, NCP Phase starts 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-Response/ EAP-Packet/Identity <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> DIAMETER- EAP-Request/ EAP-Packet/EAP-Response/ (MyID) -> <- DIAMETER- EAP-Reject (proxied from remote DIAMETER Server) <- PPP LCP Request-CHAP Calhoun, Rubens, Aboba expires September 1998 [Page 10] INTERNET DRAFT March 1998 auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> DIAMETER Authentication-Request-> <- DIAMETER Authentication-Success (proxied from remote DIAMETER Server) <- PPP LCP CHAP-Success PPP Authentication Phase complete, NCP Phase starts 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-Response/ EAP-Packet <- LCP Terminate Req Calhoun, Rubens, Aboba expires September 1998 [Page 11] INTERNET DRAFT March 1998 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-Ack/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- Ack/EAP-Packet/EAP-Success message to the NAS. 4.0 Command Name and Command Code Command Name: DIAMETER-EAP-Request Command Code: 18 Command Name: DIAMETER-EAP-Response Command Code: 19 Command Name: DIAMETER-EAP-Ack Command Code: 20 Command Name: DIAMETER-EAP-Reject Command Code: 21 5.0 Command Meanings 5.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. A DIAMETER-EAP-Request sent from the NAS to the DIAMETER Server that does not contain an EAP-Packet attribute signals to the DIAMETER Server that it is to initiate EAP Calhoun, Rubens, Aboba expires September 1998 [Page 12] INTERNET DRAFT March 1998 authentication with the client. Upon receipt of a DIAMETER-EAP-Request, A DIAMETER Server MUST issue a reply. The reply may be either: 1) a DIAMETER-EAP-Response containing an EAP-Request in at lease one EAP-Packet attribute, 2) a DIAMETER-EAP-Ack containing an EAP-Packet of type "success", or 3) a DIAMETER-EAP-Reject containing an EAP-Packet of type "failure". A Command-Unrecognized packet is returned if the server does not support the EAP extensions. The DIAMETER-EAP-Request message MUST include either the Signature or the Digital-Signature attribute 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. 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 | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 256 DIAMETER Command Length The length of this attribute MUST be 9. Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 18 (DIAMETER-EAP-Request). 5.2 DIAMETER-EAP-Response Description Calhoun, Rubens, Aboba expires September 1998 [Page 13] INTERNET DRAFT March 1998 DIAMETER-EAP-Response 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-Response MUST contain at least one EAP-Packet attribute and MUST include either the Signature or the Digital- Signature attribute 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. 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 DIAMETER-EAP-Response packet format is shown below. The fields are transmitted from left to right. 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 | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 256 DIAMETER Command Length The length of this attribute MUST be 9. Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 19 (DIAMETER-EAP-Response). 5.3 DIAMETER-EAP-Ack Description DIAMETER-EAP-Ack packets are sent by the DIAMETER Server to the Calhoun, Rubens, Aboba expires September 1998 [Page 14] INTERNET DRAFT March 1998 NAS. They contain the next EAP-Request or EAP-Success packet to be passed to the client. The DIAMETER-EAP-Ack packet MUST contain at least one EAP-Packet attribute and MUST include either the Signature or the Digital- Signature attribute 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. 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 DIAMETER-EAP-Ack packet format is shown below. The fields are transmitted from left to right. 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 | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 256 DIAMETER Command Length The length of this attribute MUST be 9. Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 20 (DIAMETER-EAP-Ack). 5.4 DIAMETER-EAP-Reject Description DIAMETER-EAP-Reject packets are sent by the DIAMETER Server to the NAS. They are sent in response to a DIAMETER-EAP-Request that results in an authentication failure. DIAMETER-EAP-Reject packets Calhoun, Rubens, Aboba expires September 1998 [Page 15] INTERNET DRAFT March 1998 contain at least one 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. The DIAMETER-EAP-Reject message MUST include either the Signature or the Digital-Signature attribute 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-Reject packet format is shown below. The fields are transmitted from left to right. 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 | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 256 DIAMETER Command Length The length of this attribute MUST be 9. Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 21 (DIAMETER-EAP-Reject). 6.0 Attribute Name and Attribute Code Attribute Name: EAP-Packet Attribute Code: 277 7.0 Attribute Meanings Calhoun, Rubens, Aboba expires September 1998 [Page 16] INTERNET DRAFT March 1998 7.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]. 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 | Sequence Number | String ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 277 for EAP-Packet Length >= 7 Flags The flag field MUST have bit 1 (Mandatory Support) set. Sequence Number The Sequence Number field is used in order to build a "history" of the transaction. The EAP-Packet attribute with the highest Sequence Number represents the current packet to process. The history is passed along in each request/responses in order in order to support the concept of DIAMETER backup servers, as described earlier. 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. Calhoun, Rubens, Aboba expires September 1998 [Page 17] INTERNET DRAFT March 1998 8.0 Acknowledgments Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn and Narendra Gidwani of Microsoft and Jeff Haag of 3Com for useful discussions of this problem space. 9.0 References [1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, June, 1996. [2] P. R. Calhoun, "DIAMETER Authentication Extension", draft-calhoun-diameter-auth-00.txt, February 1998. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)." RFC 2058, January, 1997. [4] C. Rigney, "RADIUS Accounting." RFC 2059, January 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." draft-bradner-key-words-02.txt, August 1996. [7] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-00.txt, February 1998. 10.0 Authors' Addresses 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-847-548-9587 Fax: 1-650-786-6445 E-mail: pcalhoun@toast.net Allan C. Rubens Merit Network, Inc. 4251 Plymouth Rd. Calhoun, Rubens, Aboba expires September 1998 [Page 18] INTERNET DRAFT March 1998 Ann Arbor, MI 48105-2785 Phone: 1-313-647-0417 E-Mail: acr@merit.edu Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 1-425-936-6605 E-Mail: bernarda@microsoft.com Calhoun, Rubens, Aboba expires September 1998 [Page 19]