INTERNET-DRAFT John Vollbrecht Category: Informational David Spence Interlink Networks, Inc. 22 Dec. 2002 State Machines for EAP Peer and Authenticators 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 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. 1. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 2. Abstract The specification for the Extensible Authentication Protocol (EAP) [2] does not include a state machine. The EAP working group would like to include a state machine for peer and authenticator. This might be a separate RFC describing the state machine, or it might be incorporated in a revised EAP RFC. There is at least one other Internet Draft that has been submitted that describes a state machine for EAP. This memo describes a state machine based on an EAP "Switch" model. This model includes an additional set of events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the model is given in the next section. The EAP design working group has discussed the EAP Switch model as a way to describe EAP protocol interactions. This document is based on a position paper discussed in the design group and discusions on conference calls about the paper. This document is still a work in progress. In particular the handling of integrity checks for the authenticator has not been worked out, and more discussion is needed to get consensus on retransmission support. There is still active discussion on how to mitigate potential Denial of Service Attacks which will need to be integrated. Finally, this does not support being able to send and receive Notify method in the middle of other methods, and this will be added in a future revision. 3. The EAP Switch Model This document offers a proposed state machine for RFC 2284bis (EAP). There is a state machine for the peer and one for the authenticator. Accompanying each state machine diagram is a description of the notation used. Whenever possible, the same notation has been used in both the peer and authenticator state machines. Vollbrecht Informational [Page 1] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 Figure 1 illustrates the EAP Switch Model. The EAP conversation is between the authenticator and a peer. The conversation consists of EAP Requests from the authenticator and EAP Replies from the peer. An EAP Method consists of a sequence of Requests and Replies implementing a particular algorithm. Both authenticator and peer must support a method for it to work. The authenticator always initiates methods. An EAP authentication consists of one or more EAP methods in sequence followed by an EAP Success or EAP Failure sent from the Authenticator to the peer. The EAP Switches control negotiation of EAP methods and sequences of methods, Peer Peer | Authenticator Auth Method | Method \ | / \ | / Peer | Auth EAP <-----|----------> EAP Switch | Switch Figure 1 - EAP Switch Model At both the peer and authenticator one or more EAP method exists. The EAP switches select which methods each is willing to use, and negotiate between themselves to pick a method or sequence of methods. Note that the methods may also have state machines, but the details of these are out of scope for this paper. This document describes State Machines for both the peer EAP switch and for the Auth EAP Switch. 3.1. 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 [1]. 4. State Machine overview 4.1 Mechanics In the following it is assumed that each Switch has some internal policy. The policy describes the required and allowed sequences of EAP methods. While this paper assumes policy, it does not describe how this policy is implemented - this is a topic for further discussion in the EAP Working Group, and may be implementation dependent. The state machines in the following sections are described as tables. Each table row includes the current state, event in that state causing a transition, next state, and actions taken before making the transition. A future version of this may convert the table to the state diagram format used by 802.1x. The 802.1x format is difficult to implement in Ascii text; for the sake of time I have not attempted to convert to it. Vollbrecht Informational [Page 2] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 4.2 Retransmission The authenticator state machine includes timer to trigger retransmissions. The peer state machine assumes it may get retransmissions. If a Request fails a Method's integrity check the Request is discarded and the next Request processed. When a Request passes Integrity Check and is processed to completion, any Requests queued are cleared before the Reponse is sent. Integrity checking of Requests is done by the Peer Method. 4.3 Sequences of EAP Methods Sequences of EAP methods are supported. The authenticator initiates each Method in the sequence. Sequences may be of any length and are controlled by policy in the Switches. A failed method MUST terminate a sequence. The authenticator initiates methods, and the peer may NAK any method. What is initiated and what is NAK'd is determined by policy. [To make interoperability simple, a suggested default action for peers is to have a set of methods which it accepts if offerred after an initial authentication method.] 4.4 EAP Method Requirements This State Machine assumes that Methods interact with the EAP Switch. The interface between Method and Switch has requirements which hopefully will be defined in an API. Requirements for interactions between Method and Switch are defined in the Events and Actions description in the following sections. 5. Peer EAP Switch State Machine 5.1 Peer EAP States The peer EAP switch has the following states: Abbreviation State Comment 1. inactive not being authenticated - waiting for "open" from application 2. wtng-auth waiting for authenticator - waiting for REQ/Success/Fail 3. wtng-mth waiting-method - waiting for response from method 4. mth=x method=x - waiting for next EAP request for method x 5. mth-mutual method did mutual - waiting for Success/REQ 6. actv/fail-mth active/failed method - waiting for Fail 7. inactv/auth inactive/authenticated - authenticated; reauth possible The typical sequence for a successful authentication is as follows. The peer application (e.g. level 2 access) signals the switch to "open" the EAP switch for this application. The Switch initializes policy for the application and goes to state 2, waiting for an EAP Request. The peer receives an EAP request from the authenticator for this Vollbrecht Informational [Page 3] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 applications, going to state 3 and forwarding the request to the appropriate method. It receives a response from the method, going to state 4 and sending the EAP response to the authenticator. It receivesthe next EAP Req for that method from the authenticator and goes to state 3, forwarding the Req to the method. It receives a "final" response from the method and goes to state 5 and sends the Response to the authenticator. It then receives an EAP Success from the authenticator and goes to state 7, authenticated. The peer state machine, as written, assumes that the peer methods will know when they have received the final request and have made the final response. This is important because it allows the method to report back to the Switch state machine whether the method succeeded. If a method is not satisfied with the contents of a request but expects further requests or if it will only be satisfied if it receives another request, then it needs to be able to signal whether it considers the conversation over with success, over with mutual authentication, over with failure, or ongoing. Peer methods must indicate with each response whether the conversation has concluded and, if so, how it concluded. 5.2 Peer EAP Events Events recognized by the peer EAP switch are listed below. Some Switch policy is implied in the events; e.g. EAP-Req/notok implies that the policy evaluated the Req as ok at this point. From Authenticator 1. EAP-req/notok - EAP request not acceptable to peer policy 2. EAP-req/mth=x - EAP request for method x 3. EAP-Success - EAP Success received 4. EAP-Fail - EAP Failure received From Method 5. Mth-resp.done.ok - response from method: good termination 6. Mth-resp.done.mut - response from method: mutual authentication 7. Mth-resp.done.fail - response from method: failure termination 8. Mth-resp-cont - response from method: more requests expected 9. Mth-IC.fail.c - request fails integrity check - continue mth 10.Mth-IC.fail.first - request fails integrity check - initial req From System 11.Timeout 5.3 Peer EAP Actions Actions initiated by the peer EAP switch are: To Authenticator 1. Send EAP-NAK 2. Send EAP-Resp - Send EAP-Response To Method 3. EAP-req to mth - Forward EAP-req to method 4. Terminate mth - Send a terminate signal to method To System 5. Signal accept - authentication accepted by both parties 6. Signal reject - authentication rejected by one or both parties 7. Clear receive q - clear messages being held Vollbrecht Informational [Page 4] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 Other 8. Silent Discard - Discard the message and take no action 5.4 EAP Peer Switch State Table State Event Next State Action 1 Action 2 inactive Appl-open wtng-auth Init policy wtng-auth EAP-req/ok wtng-mth EAP-req to mth EAP-req/notok wtng-auth Send EAP-NAK EAP-Success/ok inactv/auth Signal accept EAP-Success/notok wtng-auth Silent Discard EAP-Fail/ok wtng-auth Signal reject EAP-Fail/notok wtng-auth Silent Discard timeout wtng-auth Signal Reject * wtng-auth Silent Discard wtng-mth mth-rsp.done.ok wtng-auth Send EAP resp clr q mth-rsp.done.fail fail-mth Send EAP resp clr q mth-rsp-cont mth=x Send EAP resp clr q mth-rsp-done.mut mth-mutual Send EAP resp clr q mth-IC.fail.c mth=x do nothing mth-IC.fail.first wtng-auth do nothing timeout wtng-auth Terminate mth sgnl rej * wtng-mth Silent Discard mth=x EAP-req/mth=x wtng-mth EAP-req to mth EAP-req/not mth=x mth=x Silent Discard EAP-Success mth=x Silent Discard EAP-Fail mth=x Silent Discard timeout wtng-auth Signal Rej Term meth * mth=x Silent Discard mth-mutual EAP-req/ok mth=x EAP-req to mth EAP-req/notok mth-mutual Send EAP-NAK EAP-Success inactv/auth Signal accept EAP-Fail wtng-auth Silent Discard timeout wtng-auth Signal reject * mth-mutual Silent Discard fail-mth EAP-Fail wtng-auth Signal reject EAP-Success wtng-auth Silent Discard EAP-req actv/fail-mth Silent Discard timeout wtng-auth Signal reject * actv/fail-mth Silent Discard inactv/auth EAP-req/ok mth=x EAP-req to mth EAP-req/notok inactv/auth Send EAP-NAK * inactv/auth Silent Discard Vollbrecht Informational [Page 5] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 6. Authenticator EAP Switch State Machine 6.1 Authenticator EAP States The authenticator EAP switch has the following states: 1. inactive - waiting for start from system 2. active/method=x.1 - waiting for 1st reply method x 3. active/method=x.c - waiting for continue reply 4. active/method=x.a - waiting for return from method 5. active/no-method - waiting for more methods or success 6.2 Authenticator EAP Events The following events are defined for the authenticator EAP switch: From System 1. initiate EAP, meth=x - signal (e.g. from RADIUS) to start EAP 2. no more policy / success 3. no more policy / failure 4. more policy, meth=x 5. timeout, count=max From Peer 7. receive EAP-NAK 8. receive EAP-Resp.method.eq.x 9. receive EAP-Resp.method.ne.x From Method 10. receive EAP-req.1 from method 11. receive EAP-req.c from method 12. receive meth-Success or meth-Fail from method 6.3 Authenticator EAP Actions Actions initiated by the authenticator EAP switch are: To System 1. start method x 2. signal accept or reject to system 3. start/increment/clear timeout & retransmission counter 4. signal method success or failure 5. log error 6. signal NAK To Peer 7. forward EAP-Req 8. send EAP Success or Failure 9. resend EAP-Req To Method 10. terminate method 11. forward EAP response Vollbrecht Informational [Page 6] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 6.4 Authenticator EAP Switch State Table State Event Next State Action Action2 inactive initiate EAP actv/mth=x.a start mth x start tmot * inactive actv/mth=x.a rcv mth-rq.1 actv/mth=x.1 forw EAP-rq start tmot rcv mth-rq.c actv/mth=x.c forw EAP-rq rcv mth-Scess actv/no mth signal scess rcv mth-Fail actv/no mth signal fail tmout inactive log error * actv/mth=x.a log error actv/mth=x.1 rcv-NAK actv/no-mth signal NAK clr tmot-cnt rcv-EAP-rsp-x actv/mth=x.a forw to mth x clr tmot-cnt rcv-EAP-rsp<>x inactive term mth signal rej send Failure clr tmot-cnt tmot/cnt=max inactive term mth signal rej send Failure clr tmot-cnt * actv/mth=x.c rcv-NAK inactive term mth clr tmot-cnt signal rej send Failure rcv-EAP-rsp-x actv/mth=x.a forw to mth x clr tmot-cnt rcv-EAP-rsp<>x inactive term mth signal rej send Failure clr tmot-cnt tmout/cnt=max inactive term mth signal rej send Failure clr tmot-cnt * actv/no-mth no policy/succ inactive Send Sccs signal acpt no policy/fail inactive Send Failure signal rej more policy actv/mth=x.a start mth x Vollbrecht Informational [Page 7] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 7. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. 8. Security Considerations This document's intent is to describe the EAP state machine fully. To this end, any security concerns with this document are likely a reflection of security concerns with EAP itself. 9. IANA Considerations This draft does not create any new number spaces for IANA administration. 10. Acknowledgments Thanks to the members of the EAP working group who have discussed and commented on this document. 11. Authors' Addresses John R. Vollbrecht. 9682 Alice Hill Drive Dexter, Mi. 48130 Email: jrv@umich.com David Spence Interlink Networks, Inc. 5405 Data Court Ann Arbor, MI 48108 Email: dspence@interlinknetworks.com Vollbrecht Informational [Page 8] INTERNET-DRAFT State Machines for EAP 22 Dec 2002 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implementation 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 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet 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 permissions 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 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 14. Expiration Date This memo is filed as , and expires June 22, 2003. Vollbrecht Informational [Page 9]