Network Working Group J. Vollbrecht
Request for Comments: 4137 Meetinghouse Data Communications
Category: Informational P. Eronen
Nokia
N. Petroni
University of Maryland
Y. Ohba
TARI
August 2005
State Machines for Extensible Authentication Protocol (EAP)
Peer and Authenticator
Status of This Memo
This memo provides information for the Internet community.Itdoes not specify an Internet standard of any
kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer,EAP
stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication,
Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through).
This set of state machines shows howEAP can be implemented to support deployment in either a
peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator
machines are illustrative ofhow the EAP protocol defined in RFC 3748 may be implemented. The backend
and full/pass-through authenticators illustrate howEAP/AAA protocol support defined in RFC 3579 may be
implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.
The state machines are based on the EAP "Switch" model. This model includes events and actions for the
interaction between the EAP Switch and EAP methods. Abrief description of the EAP "Switch" model is
giveninthe Introduction section.
The state machine and associated model are informative only.Implementations may achieve the same results
using different methods.
Vo llbrecht, et al. Informational [Page 1]
RFC 4137 EAP State Machines August 2005
Table of Contents
1. Introduction: The EAP Switch Model...........................................................................................................3
2. Specification of Requirements.......................................................................................................................4
3. Notational Conventions Used in State Diagrams ......................................................................................... 4
3.1. Notational Specifics ............................................................................................................................. 4
3.2. State Machine Symbols ........................................................................................................................ 6
3.3. Document Authority ............................................................................................................................. 7
4. Peer State Machine ...................................................................................................................................... 8
4.1. Interface between Peer State Machine and Lower Layer ..................................................................... 9
4.2. Interface between Peer State Machine and Methods .......................................................................... 11
4.3. Peer State Machine Local Variables ................................................................................................... 12
4.4. Peer State Machine Procedures .......................................................................................................... 13
4.5. Peer State Machine States .................................................................................................................. 14
5. Stand-Alone Authenticator State Machine ................................................................................................ 16
5.1. Interface between Stand-Alone Authenticator State Machine and Lower Layer ............................... 17
5.2. Interface between Stand-Alone Authenticator State Machine and Methods ...................................... 19
5.3. Stand-Alone Authenticator State Machine Local Variables ............................................................... 20
5.4. EAP Stand-Alone Authenticator Procedures ..................................................................................... 21
5.5. EAP Stand-Alone Authenticator States .............................................................................................. 23
6. EAP Backend Authenticator ...................................................................................................................... 25
6.1. Interface between Backend Authenticator State Machine and Lower Layer ..................................... 27
6.2. Interface between Backend Authenticator State Machine .................................................................. 28
6.3. Backend Authenticator State Machine Local Variables ..................................................................... 28
6.4. EAP Backend Authenticator Procedures ............................................................................................ 29
6.5. EAP Backend Authenticator States .................................................................................................... 29
7. EAP Full Authenticator ............................................................................................................................. 30
7.1. Interface between Full Authenticator State Machine and Lower Layers ........................................... 31
7.2. Interface between Full Authenticator State Machine and Methods .....................................................33
7.3. Full Authenticator State Machine Local Variables ............................................................................. 33
7.4. EAP Full Authenticator Procedures ................................................................................................... 34
7.5. EAP Full Authenticator States ........................................................................................................... 34
8. Implementation Considerations ................................................................................................................. 36
8.1 Robustness ............................................................................................................................................ 36
8.2 Method/Method and Method/Lower-Layer Interfaces ......................................................................... 36
8.3 Peer State Machine Interoperability with Deployed Implementatios.....................................................36
9. Security Considerations ............................................................................................................................. 37
10. Acknowledgements .................................................................................................................................. 38
11. References ................................................................................................................................................ 38
11.1. Normative References ....................................................................................................................... 38
11.2. Informative References ...................................................................................................................... 38
Appendix. ASCII Versions of State Diagrams ............................................................................................... 39
A.1. EAP Peer State Machine (Figure 3) .................................................................................................. 39
A.2. EAP Stand-Alone Authenticator State Machine (Figure 4) .............................................................. 42
A.3. EAP Backend Authenticator State Machine (Figure 5)...................................................................... 45
A.4. EAP Full Authenticator State Machine (Figures 6 and 7).................................................................. 48
Vo llbrecht, et al. Informational [Page 2]
RFC 4137 EAP State Machines August 2005
1. Introduction: The EAP Switch Model
This document offers a proposed state machine for RFCs [RFC3748] and [RFC3579]. There are state
machines for the peer,the stand-alone authenticator,abackend authenticator,and a full/pass-through
authenticator.Accompanying each state machine diagram is a description of the variables, the functions, and
the states in the diagram. Wheneverpossible, the same notation has been used in each of the state machines.
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 methods exist. 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. The details of these are outside the scope of this paper.
Peer | Authenticator |Backend
|/Local |
|/Method |
Peer | Auth | Backend
EAP -|-----> EAP |--> EAP
Switch | Switch | /Server
|\ |/
|\pass-through |
||
Figure 2: EAP Pass-Through Model
The Full/Pass-Through state machine allows an NAS or edge device to pass EAP Response messages to a
backend server where the authentication method resides. This paper includes a state machine for the EAP
authenticator that supports both local and pass-through methods as well as a state machine for the backend
authenticator existing at the AAA server.Asimple stand-alone authenticator is also provided to showa
basic, non-pass-through authenticator’sbehavior.
Vo llbrecht, et al. Informational [Page 3]
RFC 4137 EAP State Machines August 2005
This document describes a set of state machines that can manage EAP authentication from the peer to an
EAP method on the authenticator or from the peer through the authenticator pass-through method to the EAP
method on the backend EAP server.
Some environments where EAP is used, such as PPP,may support peer-to-peer operation. That is, both
parties act as peers and authenticators at the same time, in twosimultaneous and independent EAP
conversations. In this case, the implementation at each node has to perform demultiplexing of incoming
EAP packets. EAP packets with code set to Response are delivered to the authenticator state machine, and
EAP packets with code set to Request, Success, or Failure are delivered to the peer state machine.
The state diagrams presented in this document have been coordinated with the diagrams in [1X-2004]. The
format of the diagrams is adapted from the format therein. The interface between the state machines defined
here and the IEEE 802.1X-2004 state machines is also explained in Appendix F of [1X-2004].
2. Specification of Requirements
In this document, several words are used to signify the requirements of the specification. These words are
often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in [RFC2119].
3. Notational Conventions Used in State Diagrams
3.1. Notational Specifics
The following state diagrams have been completed based on the conventions specified in [1X-2004], section
8.2.1. The complete text is reproduced here:
State diagrams are used to represent the operation of the protocol by a number of cooperating state
machines, each comprising a group of connected, mutually exclusive states. Only one state of each
machine can be active atany giv e ntime.
Each state is represented in the state diagram as a rectangular box, divided into twoparts by a
horizontal line. The upper part contains the state identifier,written in uppercase letters. The lower
part contains anyprocedures that are executed upon entry to the state.
All permissible transitions between states are represented by arrows, the arrowhead denoting the
direction of the possible transition. Labels attached to arrows denote the condition(s) that must be
met in order for the transition to takeplace. All conditions are expressions that evaluate to TRUE or
FALSE; if a condition evaluates to TRUE, then the condition is met. The label UCT denotes an
unconditional transition (i.e., UCT always evaluates to TRUE). A transition that is global in nature
(i.e., a transition that occurs from anyofthe possible states if the condition attached to the arrowis
met) is denoted by an open arrow; i.e., no specific state is identified as the origin of the transition.
When the condition associated with a global transition is met, it supersedes all other exit conditions
including UCT.The special global condition BEGIN supersedes all other global conditions, and once
asserted it remains asserted until all state blocks have executed to the point that variable assignments
and other consequences of their execution remain unchanged.
Vo llbrecht, et al. Informational [Page 4]
RFC 4137 EAP State Machines August 2005
On entry to a state, the procedures defined for the state (if any) are executed exactly once, in the order
that theyappear on the page. Each action is deemed to be atomic; i.e., execution of a procedure
completes before the next sequential procedure starts to execute. No procedures execute outside a
state block. The procedures in only one state block execute at a time, evenifthe conditions for
execution of state blocks in different state machines are satisfied, and all procedures in an executing
state block complete execution before the transition to and execution of anyother state block occurs.
That is, the execution of anystate block appears to be atomic with respect to the execution of any
other state block, and the transition condition to that state from the previous state is TRUE when
execution commences. The order of execution of state blocks in different state machines is undefined
except as constrained by their transition conditions. Avariable that is set to a particular value in a
state block retains this value until a subsequent state block executes a procedure that modifies the
value.
On completion of all the procedures within a state, all exit conditions for the state (including all
conditions associated with global transitions) are evaluated continuously until one of the conditions is
met. The label ELSE denotes a transition that occurs if none of the other conditions for transitions
from the state are met (i.e., ELSE evaluates to TRUE if all other possible exit conditions from the
state evaluate to FALSE). Where twoormore exit conditions with the same levelofprecedence
become TRUE simultaneously,the choice as to which exit condition causes the state transition to take
place is arbitrary.
Where it is necessary to split a state machine description across more than one diagram, a transition
between twostates that appear on different diagrams is represented by an exit arrowdrawn with
dashed lines, plus a reference to the diagram that contains the destination state. Similarly,dashed
arrows and a dashed state box are used on the destination diagram to showthe transition to the
destination state. In a state machine that has been split in this way,any global transitions that can
cause entry to states defined in one of the diagrams are deemed potential exit conditions for all the
states of the state machine, regardless of which diagram the state boxes appear in.
Should a conflict exist between the interpretation of a state diagram and either the corresponding
global transition tables or the textual description associated with the state machine, the state diagram
takes precedence. The interpretation of the special symbols and operators used in the state diagrams
is as defined in Section 3.2; these symbols and operators are derivedfrom the notation of the C++
programming language, ISO/IEC 14882. If a boolean variable is described in this clause as being set,
it has or is assigned the value TRUE; if it is described as being reset or clear,ithas the value FALSE.
In addition to the above notation, there are a couple of clarifications specific to this document. First, all
boolean variables are initialized to FALSE before the state machine execution begins. Second, the following
notational shorthand is specific to this document:
<variable> = <expression1> | <expression2> | ...
Execution of a statement of this form will result in <variable> having a value of exactly one of the
expressions. The logic for which of those expressions gets executed is outside of the state machine
and could be environmental, configurable, or based on another state machine, such as that of the
method.
Vo llbrecht, et al. Informational [Page 5]
