State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator
RFC 4137
Document | Type | RFC - Informational (August 2005) | |
---|---|---|---|
Authors | Nick L. Petroni , John Vollbrecht , Yoshihiro Ohba , Pasi Eronen | ||
Last updated | 2018-12-20 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Margaret Cullen | |
Send notices to | (None) |
RFC 4137
5.3. Stand-Alone Authenticator State Machine Local Variables 5.3.1. Long-Term (Maintained between Packets) currentMethod (EAP type) EAP type, IDENTITY, or NOTIFICATION. currentId (integer) 0-255 or NONE. Usually updated in PROPOSE_METHOD state. Indicates the identifier value of the currently outstanding EAP request. methodState (enumeration) As described above. retransCount (integer) Reset in SEND_REQUEST state and updated in RETRANSMIT state. Current number of retransmissions. lastReqData (EAP packet) Set in SEND_REQUEST state. EAP packet containing the last sent request. methodTimeout (integer) Method-provided hint for suitable retransmission timeout, or NONE. 5.3.2. Short-Term (Not Maintained between Packets) rxResp (boolean) Set in RECEIVED state. Indicates that the current received packet is an EAP response. respId (integer) Set in RECEIVED state. The identifier from the current EAP response. respMethod (EAP type) Set in RECEIVED state. The method type of the current EAP response. Vollbrecht, et al. Informational [Page 21] RFC 4137 EAP State Machines August 2005 ignore (boolean) Set in METHOD state. Indicates whether the method has decided to drop the current packet. decision (enumeration) Set in SELECT_ACTION state. Temporarily stores the policy decision to succeed, fail, or continue. 5.4. EAP Stand-Alone Authenticator Procedures NOTE: For method procedures, the method uses its internal state in addition to the information provided by the EAP layer. The only arguments that are explicitly shown as inputs to the procedures are those provided to the method by EAP. Those inputs provided by the method's internal state remain implicit. calculateTimeout() Calculates the retransmission timeout, taking into account the retransmission count, round-trip time measurements, and method- specific timeout hint (see [RFC3748], Section 4.3). Returns an integer. parseEapResp() Determines the code, identifier value, and type of the current response. In the case of a parsing error (e.g., the length field is longer than the received packet), rxResp will be set to FALSE. The values of respId and respMethod may be undefined as a result. Returns a boolean, an integer, and an EAP type. buildSuccess() Creates an EAP Success Packet. Returns an EAP packet. buildFailure() Creates an EAP Failure Packet. Returns an EAP packet. nextId() Determines the next identifier value to use, based on the previous one. Returns an integer. Vollbrecht, et al. Informational [Page 22] RFC 4137 EAP State Machines August 2005 Policy.update() Updates all variables related to internal policy state. The return value is undefined. Policy.getNextMethod() Determines the method that should be used at this point in the conversation based on predefined policy. Policy.getNextMethod() MUST comply with [RFC3748] (Section 2.1), which forbids the use of sequences of authentication methods within an EAP conversation. Thus, if an authentication method has already been executed within an EAP dialog, Policy.getNextMethod() MUST NOT propose another authentication method within the same EAP dialog. Returns an EAP type. Policy.getDecision() Determines if the policy will allow SUCCESS, FAIL, or is yet to determine (CONTINUE). Returns a decision enumeration. m.check() Method-specific procedure to test for the validity of a message. Returns a boolean. m.process() Method procedure to parse and process a response for that method. The return value is undefined. m.init() Method procedure to initialize state just before use. The return value is undefined. m.reset() Method procedure to indicate that the method is ending in the middle of or before completion. The return value is undefined. m.isDone() Method procedure to check for method completion. Returns a boolean. Vollbrecht, et al. Informational [Page 23] RFC 4137 EAP State Machines August 2005 m.getTimeout() Method procedure to determine an appropriate timeout hint for that method. Returns an integer. m.getKey() Method procedure to obtain key material for use by EAP or lower layers. Returns an EAP key. m.buildReq() Method procedure to produce the next request. Returns an EAP packet. 5.5. EAP Stand-Alone Authenticator States DISABLED The authenticator is disabled until the port is enabled by the lower layer. INITIALIZE Initializes variables when the state machine is activated. IDLE The state machine spends most of its time here, waiting for something to happen. RECEIVED This state is entered when an EAP packet is received. The packet header is parsed here. INTEGRITY_CHECK A method state in which the integrity of the incoming packet from the peer is verified by the method. METHOD_RESPONSE A method state in which the incoming packet is processed. METHOD_REQUEST A method state in which a new request is formulated if necessary. Vollbrecht, et al. Informational [Page 24] RFC 4137 EAP State Machines August 2005 PROPOSE_METHOD A state in which the authenticator decides which method to try next in the authentication. SELECT_ACTION Between methods, the state machine re-evaluates whether its policy is satisfied and succeeds, fails, or remains undecided. SEND_REQUEST This state signals the lower layer that a request packet is ready to be sent. DISCARD This state signals the lower layer that the response was discarded, and no new request packet will be sent at this time. NAK This state processes Nak responses from the peer. RETRANSMIT Retransmits the previous request packet. SUCCESS A final state indicating success. FAILURE A final state indicating failure. TIMEOUT_FAILURE A final state indicating failure because no response has been received. Because no response was received, no new message (including failure) should be sent to the peer. Note that this is different from the FAILURE state, in which a message indicating failure is sent to the peer. Vollbrecht, et al. Informational [Page 25] RFC 4137 EAP State Machines August 2005 6. EAP Backend Authenticator When operating in pass-through mode, there are conceptually two parts to the authenticator: the part that passes packets through, and the backend that actually implements the EAP method. The following diagram shows a state machine for the backend part of this model when using a AAA server. Note that this diagram is identical to Figure 4 except that no retransmit is included in the IDLE state because with RADIUS, retransmit is handled by the NAS. Also, a PICK_UP_METHOD state and variable in INITIALIZE state are added to allow the Method to "pick up" a method started in a NAS. Included is an explanation of the primitives and procedures referenced in the diagram, many of which are the same as above. Note that the "lower layer" in this case is some AAA protocol (e.g., RADIUS). (see the .pdf version for missing diagram or refer to Appendix A.3 if reading the .txt version) Figure 5: EAP Backend Authenticator State Machine 6.1. Interface between Backend Authenticator State Machine and Lower Layer The lower layer presents messages to the EAP backend authenticator state machine by storing the packet in aaaEapRespData and setting the aaaEapResp signal to TRUE. When the EAP backend authenticator state machine has finished processing the message, it sets one of the signals aaaEapReq, aaaEapNoReq, aaaSuccess, and aaaFail. If it sets eapReq, eapSuccess, or eapFail, the corresponding request (or success/failure) packet is stored in aaaEapReqData. The lower layer is responsible for actually transmitting this message. 6.1.1. Variables (AAA Interface to Backend Authenticator) aaaEapResp (boolean) Set to TRUE in lower layer, FALSE in authenticator state machine. Usually indicates that an EAP response, stored in aaaEapRespData, is available for processing by the AAA server. If aaaEapRespData is set to NONE, it indicates that the AAA server should send the initial EAP request. aaaEapRespData (EAP packet) Set in lower layer when eapResp is set to TRUE. The EAP packet to be processed, or NONE. Vollbrecht, et al. Informational [Page 26] RFC 4137 EAP State Machines August 2005 backendEnabled (boolean) Indicates that there is a valid link to use for the communication. If at any point the port is not available, backendEnabled is set to FALSE, and the state machine transitions to DISABLED. 6.1.2. Variables (Backend Authenticator to AAA Interface) aaaEapReq (boolean) Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that a new EAP request is ready to be sent. aaaEapNoReq (boolean) Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the most recent response has been processed, but there is no new request to send. aaaSuccess (boolean) Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the SUCCESS state. aaaFail (boolean) Set to TRUE in authenticator state machine, FALSE in lower layer. Indicates that the state machine has reached the FAILURE state. aaaEapReqData (EAP packet) Set in authenticator state machine when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/failure). aaaEapKeyData (EAP key) Set in authenticator state machine when keying material becomes available. Set during the METHOD_RESPONSE state. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying]. aaaEapKeyAvailable (boolean) Set to TRUE in the SUCCESS state if keying material is available. The actual key is stored in aaaEapKeyData. Vollbrecht, et al. Informational [Page 27] RFC 4137 EAP State Machines August 2005 aaaMethodTimeout (integer) Method-provided hint for suitable retransmission timeout, or NONE. (Note that this hint is for the EAP retransmissions done by the pass-through authenticator, not for retransmissions of AAA packets.) 6.2. Interface between Backend Authenticator State Machine and Methods The backend method interface is almost the same as in stand-alone authenticator described in Section 5.2. The only difference is that some methods on the backend may support "picking up" a conversation started by the pass-through. That is, the EAP Request packet was sent by the pass-through, but the backend must process the corresponding EAP Response. Usually only the Identity method supports this, but others are possible. When "picking up" a conversation, m.initPickUp() is called instead of m.init(). Next, m.process() must examine eapRespData and update its own method-specific state to match what it would have been if it had actually sent the corresponding request. (Obviously, this only works for methods that can determine what the initial request contained; Identity and EAP-TLS are good examples.) After this, the processing continues as described in Section 5.2. 6.3. Backend Authenticator State Machine Local Variables For definitions of the variables used in the Backend Authenticator, see Section 5.3. 6.4. EAP Backend Authenticator Procedures Most of the procedures of the backend authenticator have already been defined in Section 5.4. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently. NOTE: For method procedures, the method uses its internal state in addition to the information provided by the EAP layer. The only arguments that are explicitly shown as inputs to the procedures are those provided to the method by EAP. Those inputs provided by the method's internal state remain implicit. Vollbrecht, et al. Informational [Page 28] RFC 4137 EAP State Machines August 2005 Policy.doPickUp() Notifies the policy that an already-chosen method is being picked up and will be completed. Returns a boolean. m.initPickUp() Method procedure to initialize state when continuing from an already-started method. The return value is undefined. 6.5. EAP Backend Authenticator States Most of the states of the backend authenticator have already been defined in Section 5.5. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently. PICK_UP_METHOD Sets an initial state for a method that is being continued and that was started elsewhere. 7. EAP Full Authenticator The following two diagrams show the state machine for a complete authenticator. The first diagram is identical to the stand-alone state machine, shown in Figure 4, with the exception that the SELECT_ACTION state has an added transition to PASSTHROUGH. The second diagram also keeps most of the logic, except the four method states, and it shows how the state machine works once it goes to pass-through mode. The first diagram is largely a reproduction of that found above, with the added hooks for a transition to PASSTHROUGH mode. (see the .pdf version for missing diagram or refer to Appendix A.4 if reading the .txt version) Figure 6: EAP Full Authenticator State Machine (Part 1) The second diagram describes the functionality necessary for an authenticator operating in pass-through mode. This section of the diagram is the counterpart of the backend diagram above. (see the .pdf version for missing diagram or refer to Appendix A.4 if reading the .txt version) Figure 7: EAP Full Authenticator State Machine (Part 2) Vollbrecht, et al. Informational [Page 29] RFC 4137 EAP State Machines August 2005 7.1. Interface between Full Authenticator State Machine and Lower Layers The full authenticator is unique in that it interfaces to multiple lower layers in order to support pass-through mode. The interface to the primary EAP transport layer is the same as described in Section 5. The following describes the interface to the second lower layer, which represents an interface to AAA. Note that there is not necessarily a direct interaction between the EAP layer and the AAA layer, as in the case of [1X-2004]. 7.1.1. Variables (AAA Interface to Full Authenticator) aaaEapReq (boolean) Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that a new EAP request is available from the AAA server. aaaEapNoReq (boolean) Set to TRUE in lower layer, FALSE in authenticator state machine. Indicates that the most recent response has been processed, but that there is no new request to send. aaaSuccess (boolean) Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the SUCCESS state. aaaFail (boolean) Set to TRUE in lower layer. Indicates that the AAA backend authenticator has reached the FAILURE state. aaaEapReqData (EAP packet) Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is set to TRUE. The actual EAP request to be sent (or success/ failure). aaaEapKeyData (EAP key) Set in lower layer when keying material becomes available from the AAA server. Note that this document does not define the structure of the type "EAP key". We expect that it will be defined in [Keying]. Vollbrecht, et al. Informational [Page 30] RFC 4137 EAP State Machines August 2005 aaaEapKeyAvailable (boolean) Set to TRUE in the lower layer if keying material is available. The actual key is stored in aaaEapKeyData. aaaMethodTimeout (integer) Method-provided hint for suitable retransmission timeout, or NONE. (Note that this hint is for the EAP retransmissions done by the pass-through authenticator, not for retransmissions of AAA packets.) 7.1.2. Variables (full authenticator to AAA interface) aaaEapResp (boolean) Set to TRUE in authenticator state machine, FALSE in the lower layer. Indicates that an EAP response is available for processing by the AAA server. aaaEapRespData (EAP packet) Set in authenticator state machine when eapResp is set to TRUE. The EAP packet to be processed. aaaIdentity (EAP packet) Set in authenticator state machine when an IDENTITY response is received. Makes that identity available to AAA lower layer. aaaTimeout (boolean) Set in AAA_IDLE if, after a configurable amount of time, there is no response from the AAA layer. The AAA layer in the NAS is itself alive and OK, but for some reason it has not received a valid Access-Accept/Reject indication from the backend. 7.1.3. Constants Same as Section 5. 7.2. Interface between Full Authenticator State Machine and Methods Same as stand-alone authenticator (Section 5.2). Vollbrecht, et al. Informational [Page 31] RFC 4137 EAP State Machines August 2005 7.3. Full Authenticator State Machine Local Variables Many of the variables of the full authenticator have already been defined in Section 5. This section contains definitions for those not existent in the stand-alone version, as well as those that are defined differently. 7.3.1. Short-Term (Not Maintained between Packets) decision (enumeration) Set in SELECT_ACTION state. Temporarily stores the policy decision to succeed, fail, continue with a local method, or continue in pass-through mode. 7.4. EAP Full Authenticator Procedures All the procedures defined in Section 5 exist in the full version. In addition, the following procedures are defined. getId() Determines the identifier value chosen by the AAA server for the current EAP request. The return value is an integer. 7.5. EAP Full Authenticator States All the states defined in Section 5 exist in the full version. In addition, the following states are defined. INITIALIZE_PASSTHROUGH Initializes variables when the pass-through portion of the state machine is activated. IDLE2 The state machine waits for a response from the primary lower layer, which transports EAP traffic from the peer. IDLE The state machine spends most of its time here, waiting for something to happen. Vollbrecht, et al. Informational [Page 32] RFC 4137 EAP State Machines August 2005 RECEIVED2 This state is entered when an EAP packet is received and the authenticator is in PASSTHROUGH mode. The packet header is parsed here. AAA_REQUEST The incoming EAP packet is parsed for sending to the AAA server. AAA_IDLE Idle state that tells the AAA layer that it has a response and then waits for a new request, a no-request signal, or success/failure. AAA_RESPONSE State in which the request from the AAA interface is processed into an EAP request. SEND_REQUEST2 This state signals the lower layer that a request packet is ready to be sent. DISCARD2 This state signals the lower layer that the response was discarded, and that no new request packet will be sent at this time. RETRANSMIT2 Retransmits the previous request packet. SUCCESS2 A final state indicating success. FAILURE2 A final state indicating failure. Vollbrecht, et al. Informational [Page 33] RFC 4137 EAP State Machines August 2005 TIMEOUT_FAILURE2 A final state indicating failure because no response has been received. Because no response was received, no new message (including failure) should be sent to the peer. Note that this is different from the FAILURE2 state, in which a message indicating failure is sent to the peer. 8. Implementation Considerations 8.1. Robustness In order to deal with erroneous cases that are not directly related to the protocol behavior, implementations may need additional considerations to provide robustness against errors. For example, an implementation of a state machine may spend a significant amount of time in a particular state performing the procedure defined for the state without returning a response. If such an implementation is made on a multithreading system, the procedure may be performed in a separate thread so that the implementation can perform appropriate action without blocking on the state for a long time (or forever if the procedure never completes due to, e.g., a non-responding user or a bug in an application callback function). The following states are identified as the possible places of blocking: o IDENTITY state in the peer state machine. It may take some time to process Identity request when a user input is needed for obtaining an identity from the user. The user may never input an identity. An implementation may define an additional state transition from IDENTITY state to FAILURE state so that authentication can fail if no identity is obtained from the user before ClientTimeout timer expires. o METHOD state in the peer state machine and in METHOD_RESPONSE state in the authenticator state machines. It may take some time to perform method-specific procedures in these states. An implementation may define an additional state transition from METHOD state and METHOD_RESPONSE state to FAILURE or TIMEOUT_FAILURE state so that authentication can fail if no method processing result is obtained from the method before methodTimeout timer expires. Vollbrecht, et al. Informational [Page 34] RFC 4137 EAP State Machines August 2005 8.2. Method/Method and Method/Lower-Layer Interfaces Implementations may define additional interfaces to pass method- specific information between methods and lower layers. These interfaces are beyond the scope of this document. 8.3. Peer State Machine Interoperability with Deployed Implementations Number of deployed EAP authenticator implementations, mainly in RADIUS authentication servers, have been observed to increment the Identifier field incorrectly when generating EAP Success and EAP Failure packets which is against the MUST requirement in RFC 3748 section 4.2. The peer state machine is based on RFC 3748, and as such it will discard such EAP Success and EAP Failure packets. As a workaround for the potential interoperability issue with existing implementations, conditions for peer state machine transitions from RECEIVED state to SUCCESS and FAILURE states MAY be changed from "(reqId == lastId)" to "((reqId == lastId) || (reqId == (lastId + 1) & 255))". However, because this behavior does not conform to RFC 3748, such a workaround is not recommended, and if included, it should be implemented as an optional workaround that can be disabled. 9. 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. An accurate state machine can help reduce implementation errors. Although [RFC3748] remains the normative protocol description, this state machine should help in this regard. As noted in [RFC3748], some security concerns arise because of the following EAP packets: 1. EAP-Request/Response Identity 2. EAP-Response/NAK 3. EAP-Success/Failure Because these packets are not cryptographically protected by themselves, an attacker can modify or insert them without immediate detection by the peer or authenticator. Following Figure 3 specification, an attacker may cause denial of service by: Vollbrecht, et al. Informational [Page 35] RFC 4137 EAP State Machines August 2005 o Sending an EAP-Failure to the peer before the peer has started an EAP authentication method. As long as the peer has not modified the methodState variable (initialized to NONE), the peer MUST accept an EAP-Failure. o Forcing the peer to engage in endless EAP-Request/Response Identity exchanges before it has started an EAP authentication method. As long as the peer has not modified the selectedMethod variable (initialized to NONE), the peer MUST accept an EAP- Request/Identity and respond to it with an EAP-Response/Identity. Following Figure 4 specification, an attacker may cause denial of service by: o Sending a NAK to the authenticator after the authenticator first proposes an EAP authentication method to the peer. When the methodState variable has the value PROPOSED, the authenticator is obliged to process a NAK that is received in response to its first packet of an EAP authentication method. There MAY be some cases when it is desired to prevent such attacks. This can be done by modifying initial values of some variables of the EAP state machines. However, such modifications are NOT RECOMMENDED. There is a trade-off between mitigating these denial-of-service attacks and being able to deal with EAP peers and authenticators in general. For instance, if a NAK is ignored when it is sent to the authenticator after it has just proposed an EAP authentication method to the peer, then a legitimate peer that is not able or willing to process the proposed EAP authentication method would fail without an opportunity to negotiate another EAP method. 10. Acknowledgements The work in this document was done as part of the EAP Design Team. It was done primarily by Nick Petroni, John Vollbrecht, Pasi Eronen, and Yoshihiro Ohba. Nick started this work with Bryan Payne and Chuk Seng at the University of Maryland. John Vollbrecht of Meetinghouse Data Communications started independently with help from Dave Spence at Interlink Networks. John and Nick collaborated to create a common document, and then were joined by Pasi Eronen of Nokia, who has made major contributions in creating coherent state machines, and by Yoshihiro Ohba of Toshiba, who insisted on including pass-through documentation and provided significant support for understanding implementation issues. Vollbrecht, et al. Informational [Page 36] RFC 4137 EAP State Machines August 2005 In addition, significant response and conversation has come from the design team, especially Jari Arkko of Ericsson and Bernard Aboba of Microsoft, as well as the rest of the team. It has also been reviewed by IEEE 802.1, and has had input from Jim Burns of Meetinghouse and Paul Congdon of Hewlett Packard. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 11.2. Informative References [Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz, H., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, July 2005. [1X-2004] Institute of Electrical and Electronics Engineers, "Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE 802.1X-2004, December 2004. Vollbrecht, et al. Informational [Page 37] RFC 4137 EAP State Machines August 2005 Appendix A. ASCII versions of state diagrams This appendix contains the state diagrams in ASCII format. Please use the PDF version whenever possible; it is much easier to understand. The notation is as follows: state name and pseudocode executed when entering it are shown on the left; outgoing transitions with their conditions are shown on the right. A.1. EAP Peer State Machine (Figure 3) --------------------------------------------------------------------- (global transitions) | !portEnabled | DISABLED |------------------------+-------------- | eapRestart && | INITIALIZE | portEnabled | -----------------------------+------------------------+-------------- DISABLED | portEnabled | INITIALIZE -----------------------------+------------------------+-------------- INITIALIZE | | | | selectedMethod = NONE | | methodState = NONE | | allowNotifications = TRUE | | decision = FAIL | UCT | IDLE idleWhile = ClientTimeout | | lastId = NONE | | eapSuccess = FALSE | | eapFail = FALSE | | eapKeyData = NONE | | eapKeyAvailable = FALSE | | eapRestart = FALSE | | -----------------------------+------------------------+-------------- IDLE | eapReq | RECEIVED |------------------------+-------------- | (altAccept && | | decision != FAIL) || | | (idleWhile == 0 && | SUCCESS | decision == | | UNCOND_SUCC) | |------------------------+-------------- Vollbrecht, et al. Informational [Page 38] RFC 4137 EAP State Machines August 2005 |------------------------+-------------- | altReject || | | (idleWhile == 0 && | | decision != | | UNCOND_SUCC) || | FAILURE | (altAccept && | | methodState != CONT && | | decision == FAIL) | -----------------------------+------------------------+-------------- RECEIVED | rxReq && | METHOD | (reqId != lastId) && | (rxReq,rxSuccess,rxFailure, | (reqMethod == | reqId,reqMethod) = | selectedMethod) && | parseEapReq(eapReqData) | (methodState != DONE) | |------------------------+-------------- | rxReq && | | (reqId != lastId) && | | (selectedMethod == | | NONE) && | GET_METHOD | (reqMethod != | | IDENTITY) && | | (reqMethod != | | NOTIFICATION) | |------------------------+-------------- | rxReq && | | (reqId != lastId) && | | (selectedMethod == | IDENTITY | NONE) && | | (reqMethod == | | IDENTITY) | |------------------------+-------------- | rxReq && | | (reqId != lastId) && | | (reqMethod == | NOTIFICATION | NOTIFICATION) && | | allowNotifications | |------------------------+-------------- | rxReq && | RETRANSMIT | (reqId == lastId) | |------------------------+-------------- | rxSuccess && | | (reqId == lastId) && | SUCCESS | (decision != FAIL) | |------------------------+-------------- Vollbrecht, et al. Informational [Page 39] RFC 4137 EAP State Machines August 2005 |------------------------+-------------- | (methodState!=CONT) && | | ((rxFailure && | | decision != | | UNCOND_SUCC) || | FAILURE | (rxSuccess && | | decision == FAIL)) && | | (reqId == lastId) | |------------------------+-------------- | else | DISCARD -----------------------------+------------------------+-------------- METHOD | | | | ignore = m.check(eapReqData) | ignore | DISCARD if (!ignore) { | | (methodState, decision, | | allowNotifications) = |------------------------+-------------- m.process(eapReqData) | | /* methodState is CONT, | | MAY_CONT, or DONE */ | (methodState==DONE) && | FAILURE /* decision is FAIL, | (decision == FAIL) | COND_SUCC, or | | UNCOND_SUCC */ | | eapRespData = |------------------------+-------------- m.buildResp(reqId) | | if (m.isKeyAvailable()) | else | SEND_RESPONSE eapKeyData = m.getKey() | | } | | -----------------------------+------------------------+-------------- GET_METHOD | | | selectedMethod == | if (allowMethod(reqMethod)) {| reqMethod | METHOD selectedMethod = reqMethod | | methodState = INIT | | } else { |------------------------+-------------- eapRespData = | | buildNak(reqId) | else | SEND_RESPONSE } | | -----------------------------+------------------------+-------------- IDENTITY | | | | processIdentity(eapReqData) | UCT | SEND_RESPONSE eapRespData = | | buildIdentity(reqId) | | -----------------------------+------------------------+-------------- Vollbrecht, et al. Informational [Page 40] RFC 4137 EAP State Machines August 2005 -----------------------------+------------------------+-------------- NOTIFICATION | | | | processNotify(eapReqData) | UCT | SEND_RESPONSE eapRespData = | | buildNotify(reqId) | | -----------------------------+------------------------+-------------- RETRANSMIT | | | UCT | SEND_RESPONSE eapRespData = lastRespData | | -----------------------------+------------------------+-------------- DISCARD | | | UCT | IDLE eapReq = FALSE | | eapNoResp = TRUE | | -----------------------------+------------------------+-------------- SEND_RESPONSE | | | | lastId = reqId | | lastRespData = eapRespData | UCT | IDLE eapReq = FALSE | | eapResp = TRUE | | idleWhile = ClientTimeout | | -----------------------------+------------------------+-------------- SUCCESS | | | | if (eapKeyData != NONE) | | eapKeyAvailable = TRUE | | eapSuccess = TRUE | | -----------------------------+------------------------+-------------- FAILURE | | | | eapFail = TRUE | | --------------------------------------------------------------------- Figure 8 A.2. EAP Stand-Alone Authenticator State Machine (Figure 4) --------------------------------------------------------------------- (global transitions) | !portEnabled | DISABLED |---------------------+---------------- | eapRestart && | INITIALIZE | portEnabled | ------------------------------+---------------------+---------------- DISABLED | portEnabled | INITIALIZE ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 41] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- INITIALIZE | | | | currentId = NONE | | eapSuccess = FALSE | | eapFail = FALSE | UCT | SELECT_ACTION eapTimeout = FALSE | | eapKeyData = NONE | | eapKeyAvailable = FALSE | | eapRestart = FALSE | | ------------------------------+---------------------+---------------- IDLE | | | retransWhile == 0 | RETRANSMIT retransWhile = | | calculateTimeout( |---------------------+---------------- retransCount, eapSRTT, | eapResp | RECEIVED eapRTTVAR, methodTimeout) | | ------------------------------+---------------------+---------------- RETRANSMIT | | | retransCount > | TIMEOUT_FAILURE retransCount++ | MaxRetrans | if (retransCount<=MaxRetrans){| | eapReqData = lastReqData |---------------------+---------------- eapReq = TRUE | else | IDLE } | | ------------------------------+---------------------+---------------- RECEIVED | rxResp && | | (respId == | (rxResp,respId,respMethod)= | currentId) && | parseEapResp(eapRespData) | (respMethod == NAK | | || | NAK | respMethod == | | EXPANDED_NAK) && | | (methodState == | | PROPOSED) | |---------------------+---------------- | rxResp && | | (respId == | | currentId) && | INTEGRITY_CHECK | (respMethod == | | currentMethod) | |---------------------+---------------- | else | DISCARD ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 42] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- NAK | | | UCT | SELECT_ACTION m.reset() | | Policy.update(<...>) | | ------------------------------+---------------------+---------------- SELECT_ACTION | decision == FAILURE | FAILURE | | decision = |---------------------+---------------- Policy.getDecision() | decision == SUCCESS | SUCCESS /* SUCCESS, FAILURE, or |---------------------+---------------- CONTINUE */ | else | PROPOSE_METHOD ------------------------------+---------------------+---------------- INTEGRITY_CHECK | ignore | DISCARD |---------------------+---------------- ignore = m.check(eapRespData) | !ignore | METHOD_RESPONSE ------------------------------+---------------------+---------------- METHOD_RESPONSE | | | methodState == END | SELECT_ACTION m.process(eapRespData) | | if (m.isDone()) { | | Policy.update(<...>) |---------------------+---------------- eapKeyData = m.getKey() | | methodState = END | else | METHOD_REQUEST } else | | methodState = CONTINUE | | ------------------------------+---------------------+---------------- PROPOSE_METHOD | | | | currentMethod = | | Policy.getNextMethod() | | m.init() | UCT | METHOD_REQUEST if (currentMethod==IDENTITY ||| | currentMethod==NOTIFICATION)| | methodState = CONTINUE | | else | | methodState = PROPOSED | | ------------------------------+---------------------+---------------- METHOD_REQUEST | | | | currentId = nextId(currentId) | UCT | SEND_REQUEST eapReqData = | | m.buildReq(currentId) | | methodTimeout = m.getTimeout()| | ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 43] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- DISCARD | | | UCT | IDLE eapResp = FALSE | | eapNoReq = TRUE | | ------------------------------+---------------------+---------------- SEND_REQUEST | | | | retransCount = 0 | UCT | IDLE lastReqData = eapReqData | | eapResp = FALSE | | eapReq = TRUE | | ------------------------------+---------------------+---------------- TIMEOUT_FAILURE | | | | eapTimeout = TRUE | | ------------------------------+---------------------+---------------- FAILURE | | | | eapReqData = | | buildFailure(currentId) | | eapFail = TRUE | | ------------------------------+---------------------+---------------- SUCCESS | | | | eapReqData = | | buildSuccess(currentId) | | if (eapKeyData != NONE) | | eapKeyAvailable = TRUE | | eapSuccess = TRUE | | --------------------------------------------------------------------- Figure 9 A.3. EAP Backend Authenticator State Machine (Figure 5) --------------------------------------------------------------------- (global transitions) | !backendEnabled | DISABLED ------------------------------+---------------------+---------------- DISABLED | backendEnabled && | INITIALIZE | aaaEapResp | ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 44] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- INITIALIZE | !rxResp | SELECT_ACTION |---------------------+---------------- currentMethod = NONE | rxResp && | (rxResp,respId,respMethod)= | (respMethod == NAK | parseEapResp(aaaEapRespData)| || | NAK if (rxResp) | respMethod == | currentId = respId | EXPANDED_NAK) | else |---------------------+---------------- currentId = NONE | else | PICK_UP_METHOD ------------------------------+---------------------+---------------- PICK_UP_METHOD | | | currentMethod == | SELECT_ACTION if (Policy.doPickUp( | NONE | respMethod)) { | | currentMethod = respMethod |---------------------+---------------- m.initPickUp() | else | METHOD_RESPONSE } | | ------------------------------+---------------------+---------------- IDLE | aaaEapResp | RECEIVED ------------------------------+---------------------+---------------- RECEIVED | rxResp && | | (respId == | (rxResp,respId,respMethod)= | currentId) && | parseEapResp(aaaEapRespData)| (respMethod == NAK | | || | NAK | respMethod == | | EXPANDED_NAK) && | | (methodState == | | PROPOSED) | |---------------------+---------------- | rxResp && | | (respId == | | currentId) && | INTEGRITY_CHECK | (respMethod == | | currentMethod) | |---------------------+---------------- | else | DISCARD ------------------------------+---------------------+---------------- NAK | | | UCT | SELECT_ACTION m.reset() | | Policy.update(<...>) | | ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 45] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- SELECT_ACTION | decision == FAILURE | FAILURE | | decision = |---------------------+---------------- Policy.getDecision() | decision == SUCCESS | SUCCESS /* SUCCESS, FAILURE, or |---------------------+---------------- CONTINUE */ | else | PROPOSE_METHOD ------------------------------+---------------------+---------------- INTEGRITY_CHECK | ignore | DISCARD | | ignore = |---------------------+---------------- m.check(aaaEapRespData) | !ignore | METHOD_RESPONSE ------------------------------+---------------------+---------------- METHOD_RESPONSE | | | methodState == END | SELECT_ACTION m.process(aaaEapRespData) | | if (m.isDone()) { | | Policy.update(<...>) |---------------------+---------------- aaaEapKeyData = m.getKey() | | methodState = END | else | METHOD_REQUEST } else | | methodState = CONTINUE | | ------------------------------+---------------------+---------------- PROPOSE_METHOD | | | | currentMethod = | | Policy.getNextMethod() | | m.init() | UCT | METHOD_REQUEST if (currentMethod==IDENTITY ||| | currentMethod==NOTIFICATION)| | methodState = CONTINUE | | else | | methodState = PROPOSED | | ------------------------------+---------------------+---------------- METHOD_REQUEST | | | | currentId = nextId(currentId) | | aaaEapReqData = | UCT | SEND_REQUEST m.buildReq(currentId) | | aaaMethodTimeout = | | m.getTimeout() | | ------------------------------+---------------------+---------------- DISCARD | | | UCT | IDLE aaaEapResp = FALSE | | aaaEapNoReq = TRUE | | ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 46] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- SEND_REQUEST | | | UCT | IDLE aaaEapResp = FALSE | | aaaEapReq = TRUE | | ------------------------------+---------------------+---------------- FAILURE | | | | aaaEapReqData = | | buildFailure(currentId) | | aaaEapFail = TRUE | | ------------------------------+---------------------+---------------- SUCCESS | | | | aaaEapReqData = | | buildSuccess(currentId) | | if (aaaEapKeyData != NONE) | | aaaEapKeyAvailable = TRUE | | aaaEapSuccess = TRUE | | --------------------------------------------------------------------- Figure 10 A.4. EAP Full Authenticator State Machine (Figures 6 and 7) This state machine contains all the states from EAP stand-alone authenticator state machine, except that SELECT_ACTION state is replaced with the following: --------------------------------------------------------------------- SELECT_ACTION | decision == FAILURE | FAILURE | | decision = |---------------------+---------------- Policy.getDecision() | decision == SUCCESS | SUCCESS /* SUCCESS, FAILURE, CONTINUE,|---------------------+---------------- or PASSTHROUGH */ | decision == | INITIALIZE_ | PASSTHROUGH | PASSTHROUGH |---------------------+---------------- | else | PROPOSE_METHOD --------------------------------------------------------------------- Figure 11 And the following new states are added: --------------------------------------------------------------------- INITIALIZE_PASSTHROUGH | currentId != NONE | AAA_REQUEST |---------------------+---------------- aaaEapRespData = NONE | currentId == NONE | AAA_IDLE ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 47] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- IDLE2 | | | retransWhile == 0 | RETRANSMIT2 retransWhile = | | calculateTimeout( |---------------------+---------------- retransCount, eapSRTT, | eapResp | RECEIVED2 eapRTTVAR, methodTimeout) | | ------------------------------+---------------------+---------------- RETRANSMIT2 | | | retransCount > | TIMEOUT_ retransCount++ | MaxRetrans | FAILURE2 if (retransCount<=MaxRetrans){| | eapReqData = lastReqData |---------------------+---------------- eapReq = TRUE | else | IDLE2 } | | ------------------------------+---------------------+---------------- RECEIVED2 | rxResp && | | (respId == | AAA_REQUEST (rxResp,respId,respMethod)= | currentId) | parseEapResp(eapRespData) |---------------------+---------------- | else | DISCARD2 ------------------------------+---------------------+---------------- AAA_REQUEST | | | | if (respMethod == IDENTITY) { | UCT | AAA_IDLE aaaIdentity = eapRespData | | aaaEapRespData = eapRespData | | ------------------------------+---------------------+---------------- AAA_IDLE | aaaEapNoReq | DISCARD2 |---------------------+---------------- aaaFail = FALSE | aaaEapReq | AAA_RESPONSE aaaSuccess = FALSE |---------------------+---------------- aaaEapReq = FALSE | aaaTimeout | TIMEOUT_ aaaEapNoReq = FALSE | | FAILURE2 aaaEapResp = TRUE |---------------------+---------------- | aaaFail | FAILURE2 |---------------------+---------------- | aaaSuccess | SUCCESS2 ------------------------------+---------------------+---------------- AAA_RESPONSE | | | | eapReqData = aaaEapReqData | UCT | SEND_REQUEST2 currentId = getId(eapReqData) | | methodTimeout = | | aaaMethodTimeout | | ------------------------------+---------------------+---------------- Vollbrecht, et al. Informational [Page 48] RFC 4137 EAP State Machines August 2005 ------------------------------+---------------------+---------------- DISCARD2 | | | UCT | IDLE2 eapResp = FALSE | | eapNoReq = TRUE | | ------------------------------+---------------------+---------------- SEND_REQUEST2 | | | | retransCount = 0 | UCT | IDLE2 lastReqData = eapReqData | | eapResp = FALSE | | eapReq = TRUE | | ------------------------------+---------------------+---------------- TIMEOUT_FAILURE2 | | | | eapTimeout = TRUE | | ------------------------------+---------------------+---------------- FAILURE2 | | | | eapReqData = aaaEapReqData | | eapFail = TRUE | | ------------------------------+---------------------+---------------- SUCCESS2 | | | | eapReqData = aaaEapReqData | | eapKeyData = aaaEapKeyData | | eapKeyAvailable = | | aaaEapKeyAvailable | | eapSuccess = TRUE | | --------------------------------------------------------------------- Figure 12 Vollbrecht, et al. Informational [Page 49] RFC 4137 EAP State Machines August 2005 Authors' Addresses John Vollbrecht Meetinghouse Data Communications 9682 Alice Hill Drive Dexter, MI 48130 USA EMail: jrv@mtghouse.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group, Finland EMail: pasi.eronen@nokia.com Nick L. Petroni, Jr. University of Maryland, College Park A.V. Williams Building College Park, MD 20742 USA EMail: npetroni@cs.umd.edu Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA EMail: yohba@tari.toshiba.com Vollbrecht, et al. Informational [Page 50] RFC 4137 EAP State Machines August 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vollbrecht, et al. Informational [Page 51]