< draft-ietf-eap-statemachine		rfc4137.txt
	EAP Working Group J. Vollbrecht		Network Working Group J. Vollbrecht
	Internet-Draft Vollbrecht Consulting LLC		Request for Comments: 4137 Meetinghouse Data Communications
	Expires: June 23, 2005 P. Eronen		Category: Informational P. Eronen
	draft-ietf-eap-statemachine-06 Nokia		Nokia
	N. Petroni		N. Petroni
	University of Maryland		University of Maryland
	Y. Ohba		Y. Ohba
	TARI		TARI
	December 23, 2004		August 2005
	State Machines for Extensible Authentication Protocol (EAP)		State Machines for Extensible Authentication Protocol (EAP)
	Peer and Authenticator		Peer and Authenticator
	Status of this Memo		Status of This Memo
	By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,
	or will be disclosed, and any of which I become aware will be
	disclosed, in accordance with RFC 3668.
	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 a "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		This memo provides information for the Internet community. It does
	http://www.ietf.org/shadow.html		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes a set of state machines for Extensible		This document describes a set of state machines for Extensible
	Authentication Protocol (EAP) peer, EAP standalone authenticator		Authentication Protocol (EAP) peer, EAP stand-alone authenticator
	(non-pass-through), EAP backend authenticator (for use on		(non-pass-through), EAP backend authenticator (for use on
	Authentication, Authorization and Accounting (AAA) servers), and EAP		Authentication, Authorization, and Accounting (AAA) servers), and EAP
	full authenticator (for both local and pass-through). This set of		full authenticator (for both local and pass-through). This set of
	state machines shows how EAP can be implemented to support deployment		state machines shows how EAP can be implemented to support deployment
	in either a peer/authenticator or peer/authenticator/AAA Server		in either a peer/authenticator or peer/authenticator/AAA Server
	environment. The peer and standalone authenticator machines are		environment. The peer and stand-alone authenticator machines are
	illustrative of how the EAP protocol defined in RFC 3748 may be		illustrative of how the EAP protocol defined in RFC 3748 may be
	implemented. The backend and full/pass-through authenticators		implemented. The backend and full/pass-through authenticators
	illustrate how EAP/AAA protocol support defined in RFC 3579 may be		illustrate how EAP/AAA protocol support defined in RFC 3579 may be
	implemented. Where there are differences RFC 3748/RFC 3579 are		implemented. Where there are differences, RFC 3748 and RFC 3579 are
	authoritative.		authoritative.
	The state machines are based on the EAP "Switch" model. This model		The state machines are based on the EAP "Switch" model. This model
	includes events and actions for the interaction between the EAP		includes events and actions for the interaction between the EAP
	Switch and EAP methods. A brief description of the EAP "Switch"		Switch and EAP methods. A brief description of the EAP "Switch"
	model is given in the Introduction section.		model is given in the Introduction section.
	The state machine and associated model are informative only.		The state machine and associated model are informative only.
	Implementations may achieve the same results using different methods.		Implementations may achieve the same results using different methods.
	Table of Contents		Table of Contents
	1. Specification of Requirements . . . . . . . . . . . . . . . . 4		1. Introduction: The EAP Switch Model ..............................3
	2. The EAP Switch Model . . . . . . . . . . . . . . . . . . . . . 4		2. Specification of Requirements ...................................4
	3. Notational conventions used in state diagrams . . . . . . . . 5		3. Notational Conventions Used in State Diagrams ...................5
	3.1. Notational specifics . . . . . . . . . . . . . . . . . . 5		3.1. Notational Specifics .......................................5
	3.2. State Machine Symbols. . . . . . . . . . . . . . . . . . 8		3.2. State Machine Symbols ......................................7
	3.3. Document authority . . . . . . . . . . . . . . . . . . . 9		3.3. Document Authority .........................................8
	4. Peer State Machine . . . . . . . . . . . . . . . . . . . . . . 10		4. Peer State Machine ..............................................9
	4.1. Interface between peer state machine and lower layer . . 10		4.1. Interface between Peer State Machine and Lower Layer .......9
	4.2. Interface between peer state machine and methods . . . . 12		4.2. Interface between Peer State Machine and Methods ..........11
	4.3. Peer state machine local variables . . . . . . . . . . . 14		4.3. Peer State Machine Local Variables ........................13
	4.4. Peer state machine procedures. . . . . . . . . . . . . . 15		4.4. Peer State Machine Procedures .............................14
	4.5. Peer state machine states. . . . . . . . . . . . . . . . 16		4.5. Peer State Machine States .................................15
	5. Standalone Authenticator State Machine . . . . . . . . . . . . 18		5. Stand-Alone Authenticator State Machine ........................17
	5.1. Interface between standalone authenticator state machine		5.1. Interface between Stand-Alone Authenticator State
	and lower layer. . . . . . . . . . . . . . . . . . . . . 18		Machine and Lower Layer ...................................17
	5.2. Interface between standalone authenticator state machine		5.2. Interface between Stand-Alone Authenticator State
	and methods. . . . . . . . . . . . . . . . . . . . . . . 20		Machine and Methods .......................................19
	5.3. Standalone authenticator state machine local variables . 22		5.3. Stand-Alone Authenticator State Machine Local Variables ...21
	5.4. EAP standalone authenticator procedures. . . . . . . . . 23		5.4. EAP Stand-Alone Authenticator Procedures ..................22
	5.5. EAP standalone authenticator states. . . . . . . . . . . 25		5.5. EAP Stand-Alone Authenticator States ......................24
	6. EAP Backend Authenticator . . . . . . . . . . . . . . . . . . 27		6. EAP Backend Authenticator ......................................26
	6.1. Interface between backend authenticator state machine		6.1. Interface between Backend Authenticator State
	and lower layer. . . . . . . . . . . . . . . . . . . . . 27		Machine and Lower Layer ...................................26
	6.2. Interface between backend authenticator state machine		6.2. Interface between Backend Authenticator State
	and methods. . . . . . . . . . . . . . . . . . . . . . . 29		Machine and Methods .......................................28
	6.3. Backend authenticator state machine local variables. . . 29		6.3. Backend Authenticator State Machine Local Variables .......28
	6.4. EAP backend authenticator procedures . . . . . . . . . . 29		6.4. EAP Backend Authenticator Procedures ......................28
	6.5. EAP backend authenticator states . . . . . . . . . . . . 30		6.5. EAP Backend Authenticator States ..........................29
	7. EAP Full Authenticator . . . . . . . . . . . . . . . . . . . . 31		7. EAP Full Authenticator .........................................29
	7.1. Interface between full authenticator state machine and		7.1. Interface between Full Authenticator State Machine
	lower layers . . . . . . . . . . . . . . . . . . . . . . 31		and Lower Layer ...........................................30
	7.2. Interface between full authenticator state machine and		7.2. Interface between Full Authenticator State Machine
	methods . . . . . . . . . . . . . . . . . . . . . . . . 33		and Methods ...............................................31
	7.3. Full authenticator state machine local variables . . . . 33		7.3. Full Authenticator State Machine Local Variables ..........32
	7.4. EAP full authenticator procedures. . . . . . . . . . . . 34		7.4. EAP Full Authenticator Procedures .........................32
	7.5. EAP full authenticator states. . . . . . . . . . . . . . 34		7.5. EAP Full Authenticator States .............................32
	8. Implementation Considerations. . . . . . . . . . . . . . . . . 36		8. Implementation Considerations ..................................34
	8.1 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 36		8.1. Robustness ................................................34
	8.2 Method/Method and Method/Lower-Layer Interfaces. . . . . . 36		8.2. Method/Method and Method/Lower-Layer Interfaces ...........35
	8.3 Peer state machine interoperability with deployed		8.3. Peer State Machine Interoperability with Deployed
	implementations . . . . . . . . . . . . . . . . . . . . . 36		Implementations ...........................................35
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 37		9. Security Considerations ........................................35
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38		10. Acknowledgements ..............................................36
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39		11. References ....................................................37
	11.1. Normative References . . . . . . . . . . . . . . . . . . 39		11.1. Normative References ....................................37
	11.2. Informative References . . . . . . . . . . . . . . . . . 39		11.2. Informative References ..................................37
	Appendix. ASCII versions of state diagrams . . . . . . . . . . . . 40
	A.1. EAP Peer State Machine (Figure 3) . . . . . . . . . . . 40
	A.2. EAP Standalone Authenticator State Machine (Figure 4) . 43
	A.3. EAP Backend Authenticator State Machine (Figure 5) . . . 46
	A.4. EAP Full Authenticator State Machine (Figures 6 and 7) . 49
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
	1. Specification of Requirements
	In this document, several words are used to signify the requirements		Appendix. ASCII Versions of State Diagrams ........................38
	of the specification. These words are often capitalized. The key		A.1. EAP Peer State Machine (Figure 3) .......................38
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		A.2. EAP Stand-Alone Authenticator State Machine (Figure 4) ..41
	"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		A.3. EAP Backend Authenticator State Machine (Figure 5) ......44
	are to be interpreted as described in [RFC2119].		A.4. EAP Full Authenticator State Machine (Figures 6 and 7) ..47
	2. The EAP Switch Model		1. Introduction: The EAP Switch Model
	This document offers a proposed state machine for RFCs [RFC3748] and		This document offers a proposed state machine for RFCs [RFC3748] and
	[RFC3579]. There are state machines for the peer, the standalone		[RFC3579]. There are state machines for the peer, the stand-alone
	authenticator, a backend authenticator and a full/pass-through		authenticator, a backend authenticator, and a full/pass-through
	authenticator. Accompanying each state machine diagram is a		authenticator. Accompanying each state machine diagram is a
	description of the variables, the functions and the states in the		description of the variables, the functions, and the states in the
	diagram. Whenever possible, the same notation has been used in each		diagram. Whenever possible, the same notation has been used in each
	of the state machines.		of the state machines.
	An EAP authentication consists of one or more EAP methods in sequence		An EAP authentication consists of one or more EAP methods in sequence
	followed by an EAP Success or EAP Failure sent from the authenticator		followed by an EAP Success or EAP Failure sent from the authenticator
	to the peer. The EAP Switches control negotiation of EAP methods and		to the peer. The EAP switches control negotiation of EAP methods and
	sequences of methods.		sequences of methods.
	Peer Peer | Authenticator Auth		Peer Peer | Authenticator Auth
	Method | Method		Method | Method
	\ | /		\ | /
	\ | /		\ | /
	Peer | Auth		Peer | Auth
	EAP <-----|----------> EAP		EAP <-----|----------> EAP
	Switch | Switch		Switch | Switch
	Figure 1: EAP Switch Model		Figure 1: EAP Switch Model
	At both the peer and authenticator one or more EAP methods exist.		At both the peer and authenticator, one or more EAP methods exist.
	The EAP switches select which methods each is willing to use, and		The EAP switches select which methods each is willing to use, and
	negotiate between themselves to pick a method or sequence of methods.		negotiate between themselves to pick a method or sequence of methods.
	Note that the methods may also have state machines. The details of		Note that the methods may also have state machines. The details of
	these are outside the scope of this paper.		these are outside the scope of this paper.
	Peer | Authenticator | Backend		Peer | Authenticator | Backend
	| / Local |		| / Local |
	| / Method |		| / Method |
	Peer | Auth | Backend		Peer | Auth | Backend
	EAP --|-----> EAP | -> EAP		EAP -|-----> EAP | --> EAP
	Switch | Switch | / Server		Switch | Switch | / Server
	| \ | /		| \ | /
	| \ pass-through |		| \ pass-through |
	| |		| |
	Figure 2: EAP Pass-Through Model		Figure 2: EAP Pass-Through Model
	The Full/Pass-Through state machine allows a NAS or Edge Device to		The Full/Pass-Through state machine allows an NAS or edge device to
	pass EAP Response messages to a Backend Server where the		pass EAP Response messages to a backend server where the
	Authentication Method resides. This paper includes a state machine		authentication method resides. This paper includes a state machine
	for the EAP authenticator that supports both local and pass-through		for the EAP authenticator that supports both local and pass-through
	methods as well as a state machine for the backend authenticator		methods as well as a state machine for the backend authenticator
	existing at the AAA server. A simple "Standalone" authenticator is		existing at the AAA server. A simple stand-alone authenticator is
	also provided to show a basic, non-pass-through authenticator's		also provided to show a basic, non-pass-through authenticator's
	behavior.		behavior.
	This document describes a set of State Machines that can manage EAP		This document describes a set of state machines that can manage EAP
	authentication from the peer to an EAP method on the authenticator or		authentication from the peer to an EAP method on the authenticator or
	from the peer through the authenticator pass-through method to the		from the peer through the authenticator pass-through method to the
	EAP method on the Backend EAP server.		EAP method on the backend EAP server.
	Some environments where EAP is used, such as PPP, may support peer-		Some environments where EAP is used, such as PPP, may support peer-
	to-peer operation. That is, both parties act as peers and		to-peer operation. That is, both parties act as peers and
	authenticators at the same time, in two simultaneous and independent		authenticators at the same time, in two simultaneous and independent
	EAP conversations. In this case, the implementation at each node has		EAP conversations. In this case, the implementation at each node has
	to perform demultiplexing of incoming EAP packets. EAP packets with		to perform demultiplexing of incoming EAP packets. EAP packets with
	Code set to Response are delivered to the authenticator state machine		code set to Response are delivered to the authenticator state
	and EAP packets with Code set to Request, Success or Failure are		machine, and EAP packets with code set to Request, Success, or
	delivered to the peer state machine.		Failure are delivered to the peer state machine.
	The state diagrams presented in this document have been coordinated		The state diagrams presented in this document have been coordinated
	with the diagrams in [1X-REV]. The format of the diagrams is adapted		with the diagrams in [1X-2004]. The format of the diagrams is
	from the format therein. The interface between the state machines		adapted from the format therein. The interface between the state
	defined here and the IEEE-802-1X-REV state machines is also explained		machines defined here and the IEEE 802.1X-2004 state machines is also
	in Appendix F of [1X-REV].		explained in Appendix F of [1X-2004].
	3. Notational conventions used in state diagrams		2. Specification of Requirements
	3.1. Notational specifics		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		The following state diagrams have been completed based on the
	conventions specified in [1X-REV], section 8.2.1. The complete text		conventions specified in [1X-2004], section 8.2.1. The complete text
	is reproduced here:		is reproduced here:
	State diagrams are used to represent the operation of the protocol		State diagrams are used to represent the operation of the protocol
	by a number of cooperating state machines each comprising a group		by a number of cooperating state machines, each comprising a group
	of connected, mutually exclusive states. Only one state of each		of connected, mutually exclusive states. Only one state of each
	machine can be active at any given time.		machine can be active at any given time.
	Each state is represented in the state diagram as a rectangular		Each state is represented in the state diagram as a rectangular
	box, divided into two parts by a horizontal line. The upper part		box, divided into two parts by a horizontal line. The upper part
	contains the state identifier, written in upper case letters. The		contains the state identifier, written in uppercase letters. The
	lower part contains any procedures that are executed on entry to		lower part contains any procedures that are executed upon entry to
	the state.		the state.
	All permissible transitions between states are represented by		All permissible transitions between states are represented by
	arrows, the arrowhead denoting the direction of the possible		arrows, the arrowhead denoting the direction of the possible
	transition. Labels attached to arrows denote the condition(s)		transition. Labels attached to arrows denote the condition(s)
	that must be met in order for the transition to take place. All		that must be met in order for the transition to take place. All
	conditions are expressions that evaluate to TRUE or FALSE; if a		conditions are expressions that evaluate to TRUE or FALSE; if a
	condition evaluates to TRUE, then the condition is met. The label		condition evaluates to TRUE, then the condition is met. The label
	UCT denotes an unconditional transition (i.e., UCT always		UCT denotes an unconditional transition (i.e., UCT always
	evaluates to TRUE). A transition that is global in nature (i.e.,		evaluates to TRUE). A transition that is global in nature (i.e.,
	a transition that occurs from any of the possible states if the		a transition that occurs from any of the possible states if the
	condition attached to the arrow is met) is denoted by an open		condition attached to the arrow is met) is denoted by an open
	arrow; i.e., no specific state is identified as the origin of the		arrow; i.e., no specific state is identified as the origin of the
	transition. When the condition associated with a global		transition. When the condition associated with a global
	transition is met, it supersedes all other exit conditions		transition is met, it supersedes all other exit conditions
	including UCT. The special global condition BEGIN supersedes all		including UCT. The special global condition BEGIN supersedes all
	other global conditions, and once asserted remains asserted until		other global conditions, and once asserted it remains asserted
	all state blocks have executed to the point that variable		until all state blocks have executed to the point that variable
	assignments and other consequences of their execution remain		assignments and other consequences of their execution remain
	unchanged.		unchanged.
	On entry to a state, the procedures defined for the state (if any)		On entry to a state, the procedures defined for the state (if any)
	are executed exactly once, in the order that they appear on the		are executed exactly once, in the order that they appear on the
	page. Each action is deemed to be atomic; i.e., execution of a		page. Each action is deemed to be atomic; i.e., execution of a
	procedure completes before the next sequential procedure starts to		procedure completes before the next sequential procedure starts to
	execute. No procedures execute outside of a state block. The		execute. No procedures execute outside a state block. The
	procedures in only one state block execute at a time, even if the		procedures in only one state block execute at a time, even if the
	conditions for execution of state blocks in different state		conditions for execution of state blocks in different state
	machines are satisfied, and all procedures in an executing state		machines are satisfied, and all procedures in an executing state
	block complete execution before the transition to and execution of		block complete execution before the transition to and execution of
	any other state block occurs, i.e., the execution of any state		any other state block occurs. That is, the execution of any state
	block appears to be atomic with respect to the execution of any		block appears to be atomic with respect to the execution of any
	other state block and the transition condition to that state from		other state block, and the transition condition to that state from
	the previous state is TRUE when execution commences. The order of		the previous state is TRUE when execution commences. The order of
	execution of state blocks in different state machines is undefined		execution of state blocks in different state machines is undefined
	except as constrained by their transition conditions. A variable		except as constrained by their transition conditions. A variable
	that is set to a particular value in a state block retains this		that is set to a particular value in a state block retains this
	value until a subsequent state block executes a procedure that		value until a subsequent state block executes a procedure that
	modifies the value.		modifies the value.
	On completion of all of the procedures within a state, all exit		On completion of all the procedures within a state, all exit
	conditions for the state (including all conditions associated with		conditions for the state (including all conditions associated with
	global transitions) are evaluated continuously until one of the		global transitions) are evaluated continuously until one of the
	conditions is met. The label ELSE denotes a transition that		conditions is met. The label ELSE denotes a transition that
	occurs if none of the other conditions for transitions from the		occurs if none of the other conditions for transitions from the
	state are met (i.e., ELSE evaluates to TRUE if all other possible		state are met (i.e., ELSE evaluates to TRUE if all other possible
	exit conditions from the state evaluate to FALSE). Where two or		exit conditions from the state evaluate to FALSE). Where two or
	more exit conditions with the same level of precedence become TRUE		more exit conditions with the same level of precedence become TRUE
	simultaneously, the choice as to which exit condition causes the		simultaneously, the choice as to which exit condition causes the
	state transition to take place is arbitrary.		state transition to take place is arbitrary.
	Where it is necessary to split a state machine description across		Where it is necessary to split a state machine description across
	more than one diagram, a transition between two states that appear		more than one diagram, a transition between two states that appear
	on different diagrams is represented by an exit arrow drawn with		on different diagrams is represented by an exit arrow drawn with
	dashed lines, plus a reference to the diagram that contains the		dashed lines, plus a reference to the diagram that contains the
	destination state. Similarly, dashed arrows and a dashed state		destination state. Similarly, dashed arrows and a dashed state
	box are used on the destination diagram to show the transition to		box are used on the destination diagram to show the transition to
	the destination state. In a state machine that has been split in		the destination state. In a state machine that has been split in
	this way, any global transitions that can cause entry to states		this way, any global transitions that can cause entry to states
	defined in one of the diagrams are deemed to be potential exit		defined in one of the diagrams are deemed potential exit
	conditions for all of the states of the state machine, regardless		conditions for all the states of the state machine, regardless of
	of which diagram the state boxes appear in.		which diagram the state boxes appear in.
	Should a conflict exist between the interpretation of a state		Should a conflict exist between the interpretation of a state
	diagram and either the corresponding global transition tables or		diagram and either the corresponding global transition tables or
	the textual description associated with the state machine, the		the textual description associated with the state machine, the
	state diagram takes precedence. The interpretation of the special		state diagram takes precedence. The interpretation of the special
	symbols and operators used in the state diagrams is as defined in		symbols and operators used in the state diagrams is as defined in
	Section 3.2; these symbols and operators are derived from the		Section 3.2; these symbols and operators are derived from the
	notation of the C++ programming language, ISO/IEC 14882. If a		notation of the C++ programming language, ISO/IEC 14882. If a
	boolean variable is described in this clause as being set it has		boolean variable is described in this clause as being set, it has
	or is assigned the value TRUE, if reset or clear the value FALSE.		or is assigned the value TRUE; if it is described as being reset
			or clear, it has the value FALSE.
	In addition to the above notation, there are a couple of		In addition to the above notation, there are a couple of
	clarifications specific to this document. First, all boolean		clarifications specific to this document. First, all boolean
	variables are initialized to FALSE before the state machine execution		variables are initialized to FALSE before the state machine execution
	begins. Second, the following notational shorthand is specific to		begins. Second, the following notational shorthand is specific to
	this document:		this document:
	<variable> = <expression1> | <expression2> | ...		<variable> = <expression1> | <expression2> | ...
	Execution of a statement of this form will result in <variable>		Execution of a statement of this form will result in <variable>
	having a value of exactly one of the expressions. The logic for		having a value of exactly one of the expressions. The logic for
	which of those expressions gets executed is outside of the state		which of those expressions gets executed is outside of the state
	machine and could be environmental, configurable, or based on		machine and could be environmental, configurable, or based on
	another state machine such as that of the method.		another state machine, such as that of the method.
	3.2. State Machine Symbols		3.2. State Machine Symbols
	( )		( )
	Used to force the precedence of operators in Boolean expressions		Used to force the precedence of operators in Boolean expressions
	and to delimit the argument(s) of actions within state boxes.		and to delimit the argument(s) of actions within state boxes.
	;		;
	Used as a terminating delimiter for actions within state boxes.		Used as a terminating delimiter for actions within state boxes.
	Where a state box contains multiple actions, the order of		If a state box contains multiple actions, the order of execution
	execution follows the normal English language conventions for		follows the normal English language conventions for reading text.
	reading text.
	=		=
	Assignment action. The value of the expression to the right of		Assignment action. The value of the expression to the right of
	the operator is assigned to the variable to the left of the		the operator is assigned to the variable to the left of the
	operator. Where this operator is used to define multiple		operator. If this operator is used to define multiple assignments
	assignments, e.g., a = b = X the action causes the value of the		(e.g., a = b = X), the action causes the value of the expression
	expression following the right-most assignment operator to be		following the right-most assignment operator to be assigned to all
	assigned to all of the variables that appear to the left of the		the variables that appear to the left of the right-most assignment
	right-most assignment operator.		operator.
	!		!
	Logical NOT operator.		Logical NOT operator.
	&&		&&
	Logical AND operator.		Logical AND operator.
	||		||
	Logical OR operator.		Logical OR operator.
	if...then...		if...then...
	Conditional action. If the Boolean expression following the if		Conditional action. If the Boolean expression following the "if"
	evaluates to TRUE, then the action following the then is executed.		evaluates to TRUE, then the action following the "then" is
			executed.
	{ statement 1, ... statement N }		{ statement 1, ... statement N }
	Compound statement. Braces are used to group statements that are		Compound statement. Braces are used to group statements that are
	executed together as if they were a single statement.		executed together as if they were a single statement.
	!=		!=
	Inequality. Evaluates to TRUE if the expression to the left of		Inequality. Evaluates to TRUE if the expression to the left of
	the operator is not equal in value to the expression to the right.		the operator is not equal in value to the expression to the right.
	skipping to change at page 9, line 39 ¶		skipping to change at page 8, line 44 ¶
	Increment the preceding integer operator by 1.		Increment the preceding integer operator by 1.
	+		+
	Arithmetic addition operator.		Arithmetic addition operator.
	&		&
	Bitwise AND operator.		Bitwise AND operator.
	3.3. Document authority		3.3. Document Authority
	Should a conflict exist between the interpretation of a state diagram		Should a conflict exist between the interpretation of a state diagram
	and either the corresponding global transition tables or the textual		and either the corresponding global transition tables or the textual
	description associated with the state machine, the state diagram		description associated with the state machine, the state diagram
	takes precedence. When a discrepancy occurs between any part of this		takes precedence. When a discrepancy occurs between any part of this
	document (text or diagram) and any of the related documents		document (text or diagram) and any of the related documents
	([RFC3748], [RFC3579], etc.) the latter (the other document) is		([RFC3748], [RFC3579], etc.), the latter (the other document) is
	considered authoritative and takes precedence.		considered authoritative and takes precedence.
	4. Peer State Machine		4. Peer State Machine
	The following is a diagram of the EAP peer state machine. Also		The following is a diagram of the EAP peer state machine. Also
	included is an explanation of the primitives and procedures		included is an explanation of the primitives and procedures
	referenced in the diagram, as well as a clarification of notation.		referenced in the diagram, as well as a clarification of notation.
	(see the .pdf version for missing diagram or		(see the .pdf version for missing diagram or
	refer to Appendix A.1 if reading the .txt version)		refer to Appendix A.1 if reading the .txt version)
	Figure 3: EAP Peer State Machine		Figure 3: EAP Peer State Machine
	4.1. Interface between peer state machine and lower layer		4.1. Interface between Peer State Machine and Lower Layer
	The lower layer presents messages to the EAP peer state machine by		The lower layer presents messages to the EAP peer state machine by
	storing the packet in eapReqData and setting the eapReq signal to		storing the packet in eapReqData and setting the eapReq signal to
	TRUE. Note that despite the name of the signal, the lower layer does		TRUE. Note that despite the name of the signal, the lower layer does
	not actually inspect the contents of the EAP packet (it could be a		not actually inspect the contents of the EAP packet (it could be a
	Success or Failure message instead of a Request).		Success or Failure message instead of a Request).
	When the EAP peer state machine has finished processing the message		When the EAP peer state machine has finished processing the message,
	it sets either eapResp or eapNoResp. If it sets eapResp, the		it sets either eapResp or eapNoResp. If it sets eapResp, the
	corresponding response packet is stored in eapRespData. The lower		corresponding response packet is stored in eapRespData. The lower
	layer is responsible for actually transmitting this message. When		layer is responsible for actually transmitting this message. When
	the EAP peer state machine authentication is complete it will set		the EAP peer state machine authentication is complete, it will set
	eapSuccess or eapFailure to indicate to the lower layer that the		eapSuccess or eapFailure to indicate to the lower layer that the
	authentication has succeeded or failed.		authentication has succeeded or failed.
	4.1.1. Variables (lower layer to peer)		4.1.1. Variables (Lower Layer to Peer)
	eapReq (boolean)		eapReq (boolean)
	Set to TRUE in lower layer, FALSE in peer state machine.		Set to TRUE in lower layer, FALSE in peer state machine.
	Indicates there is a request available in the lower layer.		Indicates that a request is available in the lower layer.
	eapReqData (EAP packet)		eapReqData (EAP packet)
	Set in lower layer when eapReq is set to TRUE. The contents of		Set in lower layer when eapReq is set to TRUE. The contents of
	the available request.		the available request.
	portEnabled (boolean)		portEnabled (boolean)
	Indicates that the EAP peer state machine should be ready for		Indicates that the EAP peer state machine should be ready for
	communication. This is set to TRUE when the EAP conversation is		communication. This is set to TRUE when the EAP conversation is
	started by the lower layer. If at any point the communication		started by the lower layer. If at any point the communication
	port or session is not available, portEnabled is set to FALSE and		port or session is not available, portEnabled is set to FALSE, and
	the state machine transitions to DISABLED. To avoid unnecessary		the state machine transitions to DISABLED. To avoid unnecessary
	resets, the lower layer may dampen link down indications when it		resets, the lower layer may dampen link down indications when it
	believes that the link is only temporarily down and that it will		believes that the link is only temporarily down and that it will
	soon be back up (see [RFC3748], Section 7.12). In this case,		soon be back up (see [RFC3748], Section 7.12). In this case,
	portEnabled may not always be equal to the the "link up" flag of		portEnabled may not always be equal to the "link up" flag of the
	the lower layer.		lower layer.
	idleWhile (integer)		idleWhile (integer)
	Outside timer used to indicate how long remains before the peer		Outside timer used to indicate how much time remains before the
	will timeout while waiting for a valid request.		peer will time out while waiting for a valid request.
	eapRestart (boolean)		eapRestart (boolean)
	Indicates the lower layer would like to restart authentication		Indicates that the lower layer would like to restart
			authentication.
	altAccept (boolean)		altAccept (boolean)
	Alternate indication of success, as described in [RFC3748].		Alternate indication of success, as described in [RFC3748].
	altReject (boolean)		altReject (boolean)
	Alternate indication of failure, as described in [RFC3748].		Alternate indication of failure, as described in [RFC3748].
	4.1.2. Variables (peer to lower layer)		4.1.2. Variables (peer to lower layer)
	eapResp (boolean)		eapResp (boolean)
	Set to TRUE in peer state machine, FALSE in lower layer.		Set to TRUE in peer state machine, FALSE in lower layer.
	Indicates there is a response to be sent.		Indicates that a response is to be sent.
	eapNoResp (boolean)		eapNoResp (boolean)
	Set to TRUE in peer state machine, FALSE in lower layer.		Set to TRUE in peer state machine, FALSE in lower layer.
	Indicates the request has been processed, but there is no response		Indicates that the request has been processed, but that there is
	to send.		no response to send.
	eapSuccess (boolean)		eapSuccess (boolean)
	Set to TRUE in peer state machine, FALSE in lower layer.		Set to TRUE in peer state machine, FALSE in lower layer.
	Indicates the Peer has reached the SUCCESS state.		Indicates that the peer has reached the SUCCESS state.
	eapFail (boolean)		eapFail (boolean)
	Set to TRUE in peer state machine, FALSE in lower layer.		Set to TRUE in peer state machine, FALSE in lower layer.
	Indicates the Peer has reached the FAILURE state.		Indicates that the peer has reached the FAILURE state.
	eapRespData (EAP packet)		eapRespData (EAP packet)
	Set in peer state machine when eapResp is set to TRUE. The EAP		Set in peer state machine when eapResp is set to TRUE. The EAP
	packet which is the response to send.		packet that is the response to send.
	eapKeyData (EAP key)		eapKeyData (EAP key)
	Set in peer state machine when keying material becomes available.		Set in peer state machine when keying material becomes available.
	Set during the METHOD state. Note that this document does not yet		Set during the METHOD state. Note that this document does not
	define the structure of the type "EAP key". We expect it to be		define the structure of the type "EAP key". We expect that it
	defined in [Keying].		will be defined in [Keying].
	eapKeyAvailable (boolean)		eapKeyAvailable (boolean)
	Set to TRUE in the SUCCESS state if keying material is available.		Set to TRUE in the SUCCESS state if keying material is available.
	The actual key is stored in eapKeyData.		The actual key is stored in eapKeyData.
	4.1.3. Constants		4.1.3. Constants
	ClientTimeout (integer)		ClientTimeout (integer)
	Configurable amount of time to wait for a valid request before		Configurable amount of time to wait for a valid request before
	aborting, initialized by implementation-specific means (e.g., a		aborting, initialized by implementation-specific means (e.g., a
	configuration setting).		configuration setting).
	4.2. Interface between peer state machine and methods		4.2. Interface between Peer State Machine and Methods
	IN: eapReqData (includes reqId)		IN: eapReqData (includes reqId)
	OUT: ignore, eapRespData, allowNotifications, decision		OUT: ignore, eapRespData, allowNotifications, decision
	IN/OUT: methodState, (method-specific state)		IN/OUT: methodState, (method-specific state)
	The following describes the interaction between the state machine and		The following describes the interaction between the state machine and
	EAP methods.		EAP methods.
	If methodState==INIT, the method starts by initializing its own		If methodState==INIT, the method starts by initializing its own
	method-specific state.		method-specific state.
	Next, the method must decide whether to process the packet or		Next, the method must decide whether to process the packet or to
	silently discard it. If the packet appears to have been sent by		discard it silently. If the packet appears to have been sent by
	someone other than the legitimate authenticator (for instance,		someone other than the legitimate authenticator (for instance, if
	message integrity check fails) and the method is capable of treating		message integrity check fails) and the method is capable of treating
	such situations as non-fatal, the method can set ignore=TRUE. In		such situations as non-fatal, the method can set ignore=TRUE. In
	this case, the method should not modify any other variables.		this case, the method should not modify any other variables.
	If the method decides to process the packet, it behaves as follows.		If the method decides to process the packet, it behaves as follows.
	o Updates its own method-specific state.		o It updates its own method-specific state.
	o If the method has derived keying material it wants to export,		o If the method has derived keying material it wants to export, it
	stores the keying material to eapKeyData.		stores the keying material to eapKeyData.
	o Creates a response packet (with the same identifier as the		o It creates a response packet (with the same identifier as the
	request), and stores it to eapRespData.		request) and stores it to eapRespData.
	o Sets ignore=FALSE.		o It sets ignore=FALSE.
	Next, the method must update methodState and decision according to		Next, the method must update methodState and decision according to
	the following rules.		the following rules.
	methodState=CONT: The method always continues at this point (and the		methodState=CONT: The method always continues at this point (and the
	peer wants to continue it). The decision variable is always set		peer wants to continue it). The decision variable is always set
	to FAIL.		to FAIL.
	methodState=MAY_CONT: At this point, the authenticator can decide		methodState=MAY_CONT: At this point, the authenticator can decide
	either to continue the method or end the conversation. The		either to continue the method or to end the conversation. The
	decision variable tells us what to do in the case the conversation		decision variable tells us what to do if the conversation ends.
	ends. If the current situation does not satisfy the peer's		If the current situation does not satisfy the peer's security
	security policy (that is, if the authenticator now decides to		policy (that is, if the authenticator now decides to allow access,
	allow access, the peer will not use it), set decision=FAIL.		the peer will not use it), set decision=FAIL. Otherwise, set
	Otherwise, set decision=COND_SUCC.		decision=COND_SUCC.
	methodState=DONE: The method never continues at this point, (or the		methodState=DONE: The method never continues at this point (or the
	peer sees no point in continuing it).		peer sees no point in continuing it).
	If either (a) the authenticator has informed us that it will not		If either (a) the authenticator has informed us that it will not
	allow access, or (b) we're not willing to talk to this		allow access, or (b) we're not willing to talk to this
	authenticator (e.g., our security policy is not satisfied), set		authenticator (e.g., our security policy is not satisfied), set
	decision=FAIL. (Note that this state can occur even if the method		decision=FAIL. (Note that this state can occur even if the method
	still has additional messages left, if continuing it can not		still has additional messages left, if continuing it cannot change
	change the peer's decision to success).		the peer's decision to success).
	If both (a) the server has informed us that it will allow access		If both (a) the server has informed us that it will allow access,
	and the next packet will be EAP Success, and (b) we're willing to		and the next packet will be EAP Success, and (b) we're willing to
	use this access, set decision=UNCOND_SUCC.		use this access, set decision=UNCOND_SUCC.
	Otherwise, we do not know what the server's decision is, but are		Otherwise, we do not know what the server's decision is, but are
	willing to use the access if the server allows. In this case, set		willing to use the access if the server allows. In this case, set
	decision=COND_SUCC.		decision=COND_SUCC.
	Finally, the method must set the allowNotifications variable. If the		Finally, the method must set the allowNotifications variable. If the
	new methodState is either CONT or MAY_CONT, and the method		new methodState is either CONT or MAY_CONT, and if the method
	specification does not forbid the use of Notification messages, set		specification does not forbid the use of Notification messages, set
	allowNotifications=TRUE. Otherwise, set allowNotifications=FALSE.		allowNotifications=TRUE. Otherwise, set allowNotifications=FALSE.
	4.3. Peer state machine local variables		4.3. Peer State Machine Local Variables
	4.3.1. Long-term (maintained between packets)		4.3.1. Long-Term (Maintained between Packets)
	selectMethod (EAP type)		selectMethod (EAP type)
	Set in GET_METHOD state. The method the peer believes to be		Set in GET_METHOD state. The method that the peer believes is
	currently "in progress"		currently "in progress"
	methodState (enumeration)		methodState (enumeration)
	As described above.		As described above.
	lastId (integer)		lastId (integer)
	0-255 or NONE. Set in SEND_RESPONSE state. The EAP identifier		0-255 or NONE. Set in SEND_RESPONSE state. The EAP identifier
	value of the last request.		value of the last request.
	lastRespData (EAP packet)		lastRespData (EAP packet)
	Set in SEND_RESPONSE state. The EAP packet last sent from the		Set in SEND_RESPONSE state. The EAP packet last sent from the
	peer.		peer.
	decision (enumeration)		decision (enumeration)
	As described above		As described above.
	NOTE: EAP type can be normal type (0..253,255), or an extended type		NOTE: EAP type can be normal type (0..253,255), or an extended type
	consisting of type 254, Vendor-Id, and Vendor-Type.		consisting of type 254, Vendor-Id, and Vendor-Type.
	4.3.2. Short-term (not maintained between packets)		4.3.2. Short-Term (Not Maintained between Packets)
	rxReq (boolean)		rxReq (boolean)
	Set in RECEIVED state. Indicates the current received packet is		Set in RECEIVED state. Indicates that the current received packet
	an EAP request.		is an EAP request.
	rxSuccess (boolean)		rxSuccess (boolean)
	Set in RECEIVED state. Indicates the current received packet is		Set in RECEIVED state. Indicates that the current received packet
	an EAP Success.		is an EAP Success.
	rxFailure (boolean)		rxFailure (boolean)
	Set in RECEIVED state. Indicates the current received packet is		Set in RECEIVED state. Indicates that the current received packet
	an EAP Failure.		is an EAP Failure.
	reqId (integer)		reqId (integer)
	Set in RECEIVED state. The identifier value associated with the		Set in RECEIVED state. The identifier value associated with the
	current EAP request.		current EAP request.
	reqMethod (EAP type)		reqMethod (EAP type)
	Set in RECEIVED state. The method type of the current EAP request		Set in RECEIVED state. The method type of the current EAP
			request.
	ignore (boolean)		ignore (boolean)
	Set in METHOD state. Indicates whether the method has decided to		Set in METHOD state. Indicates whether the method has decided to
	drop the current packet.		drop the current packet.
	4.4. Peer state machine procedures		4.4. Peer State Machine Procedures
	NOTE: For method procedures, the method uses its internal state in		NOTE: For method procedures, the method uses its internal state in
	addition to the information provided by the EAP layer. The only		addition to the information provided by the EAP layer. The only
	arguments that are explicitly shown as inputs to the procedures are		arguments that are explicitly shown as inputs to the procedures are
	those provided to the method by EAP. Those inputs provided by the		those provided to the method by EAP. Those inputs provided by the
	method's internal state remain implicit.		method's internal state remain implicit.
	parseEapReq()		parseEapReq()
	Determine the code, identifier value, and type of the current		Determine the code, identifier value, and type of the current
	request. In case of a parsing error (e.g., the length field is		request. In the case of a parsing error (e.g., the length field
	longer than the received packet), rxReq, rxSuccess, and rxFailure		is longer than the received packet), rxReq, rxSuccess, and
	will all be set to FALSE. The values of reqId and reqMethod may		rxFailure will all be set to FALSE. The values of reqId and
	be undefined as a result. Returns three booleans, one integer,		reqMethod may be undefined as a result. Returns three booleans,
	and one EAP type.		one integer, and one EAP type.
	processNotify()		processNotify()
	Process the contents of Notification Request (for instance,		Process the contents of Notification Request (for instance,
	display it to the user or log it). Return value is undefined.		display it to the user or log it). The return value is undefined.
	buildNotify()		buildNotify()
	Create the appropriate notification response. Returns an EAP		Create the appropriate notification response. Returns an EAP
	packet.		packet.
	processIdentity()		processIdentity()
	Process the contents of Identity Request. Return value is		Process the contents of Identity Request. Return value is
	undefined.		undefined.
	skipping to change at page 16, line 35 ¶		skipping to change at page 15, line 30 ¶
	m.buildResp()		m.buildResp()
	Method procedure to create a response message. Returns an EAP		Method procedure to create a response message. Returns an EAP
	packet.		packet.
	m.getKey()		m.getKey()
	Method procedure to obtain key material for use by EAP or lower		Method procedure to obtain key material for use by EAP or lower
	layers. Returns an EAP key.		layers. Returns an EAP key.
	4.5. Peer state machine states		4.5. Peer State Machine States
	DISABLED		DISABLED
	This state is reached anytime service from the lower layer is		This state is reached whenever service from the lower layer is
	interrupted or unavailable. Immediate transition to INITIALIZE		interrupted or unavailable. Immediate transition to INITIALIZE
	occurs when the port becomes enabled.		occurs when the port becomes enabled.
	INITIALIZE		INITIALIZE
	Initializes variables when the state machine is activated.		Initializes variables when the state machine is activated.
	IDLE		IDLE
	The state machine spends most of its time here, waiting for		The state machine spends most of its time here, waiting for
	something to happen.		something to happen.
	RECEIVED		RECEIVED
	This state is entered when an EAP packet is received: the packet		This state is entered when an EAP packet is received. The packet
	header is parsed here.		header is parsed here.
	GET_METHOD		GET_METHOD
	This state is entered when a request for a new type comes in:		This state is entered when a request for a new type comes in.
	either the correct method is started, or a Nak response is built.		Either the correct method is started, or a Nak response is built.
	METHOD		METHOD
	The method processing happens here: the request from the		The method processing happens here. The request from the
	authenticator is processed, and an appropriate response packet is		authenticator is processed, and an appropriate response packet is
	built.		built.
	SEND_RESPONSE		SEND_RESPONSE
	This state signals the lower layer that a response packet is ready		This state signals the lower layer that a response packet is ready
	to be sent.		to be sent.
	DISCARD		DISCARD
	This state signals the lower layer that the request was discarded,		This state signals the lower layer that the request was discarded,
	and no response packet will be sent at this time.		and no response packet will be sent at this time.
	IDENTITY:		IDENTITY
	Handles requests for Identity method, and builds a response.		Handles requests for Identity method and builds a response.
	NOTIFICATION		NOTIFICATION
	Handles requests for Notification method, and builds a response.		Handles requests for Notification method and builds a response.
	RETRANSMIT		RETRANSMIT
	Retransmits the previous response packet.		Retransmits the previous response packet.
	SUCCESS		SUCCESS
	A final state indicating success.		A final state indicating success.
	FAILURE		FAILURE
	A final state indicating failure.		A final state indicating failure.
	5. Standalone Authenticator State Machine		5. Stand-Alone Authenticator State Machine
	The following is a diagram of the "Standalone" EAP authenticator		The following is a diagram of the stand-alone EAP authenticator state
	state machine. This diagram should be used for those interested in a		machine. This diagram should be used for those interested in a
	self-contained, or non-pass-through, authenticator. Included is an		self-contained, or non-pass-through, authenticator. Included is an
	explanation of the primitives and procedures referenced in the		explanation of the primitives and procedures referenced in the
	diagram, as well as a clarification of notation.		diagram, as well as a clarification of notation.
	(see the .pdf version for missing diagram or		(see the .pdf version for missing diagram or
	refer to Appendix A.2 if reading the .txt version)		refer to Appendix A.2 if reading the .txt version)
	Figure 4: EAP Standalone Authenticator State Machine		Figure 4: EAP Stand-Alone Authenticator State Machine
	5.1. Interface between standalone authenticator state machine and lower		5.1. Interface between Stand-Alone Authenticator State Machine and
	layer		Lower Layer
	The lower layer presents messages to the EAP authenticator state		The lower layer presents messages to the EAP authenticator state
	machine by storing the packet in eapRespData and setting the eapResp		machine by storing the packet in eapRespData and setting the eapResp
	signal to TRUE.		signal to TRUE.
	When the EAP authenticator state machine has finished processing the		When the EAP authenticator state machine has finished processing the
	message, it sets one of the signals eapReq, eapNoReq, eapSuccess, and		message, it sets one of the signals eapReq, eapNoReq, eapSuccess, and
	eapFail. If it sets eapReq, eapSuccess, or eapFail, the		eapFail. If it sets eapReq, eapSuccess, or eapFail, the
	corresponding request (or success/failure) packet is stored in		corresponding request (or success/failure) packet is stored in
	eapReqData. The lower layer is responsible for actually transmitting		eapReqData. The lower layer is responsible for actually transmitting
	this message.		this message.
	5.1.1. Variables (lower layer to standalone authenticator)		5.1.1. Variables (Lower Layer to Stand-Alone Authenticator)
	eapResp (boolean)		eapResp (boolean)
	Set to TRUE in lower layer, FALSE in authenticator state machine.		Set to TRUE in lower layer, FALSE in authenticator state machine.
	Indicates an EAP response is available for processing.		Indicates that an EAP response is available for processing.
	eapRespData (EAP packet)		eapRespData (EAP packet)
	Set in lower layer when eapResp is set to TRUE. The EAP packet to		Set in lower layer when eapResp is set to TRUE. The EAP packet to
	be processed.		be processed.
	portEnabled (boolean)		portEnabled (boolean)
	Indicates that the EAP authenticator state machine should be ready		Indicates that the EAP authenticator state machine should be ready
	for communication. This is set to TRUE when the EAP conversation		for communication. This is set to TRUE when the EAP conversation
	is started by the lower layer. If at any point the communication		is started by the lower layer. If at any point the communication
	port or session is not available, portEnabled is set to FALSE and		port or session is not available, portEnabled is set to FALSE, and
	the state machine transitions to DISABLED. To avoid unnecessary		the state machine transitions to DISABLED. To avoid unnecessary
	resets, the lower layer may dampen link down indications when it		resets, the lower layer may dampen link down indications when it
	believes that the link is only temporarily down and that it will		believes that the link is only temporarily down and that it will
	soon be back up (see [RFC3748], Section 7.12). In this case,		soon be back up (see [RFC3748], Section 7.12). In this case,
	portEnabled may not always be equal to the the "link up" flag of		portEnabled may not always be equal to the "link up" flag of the
	the lower layer.		lower layer.
	retransWhile (integer)		retransWhile (integer)
	Outside timer used to indicate how long the authenticator has		Outside timer used to indicate how long the authenticator has
	waited for a new (valid) response.		waited for a new (valid) response.
	eapRestart (boolean)		eapRestart (boolean)
	Indicates the lower layer would like to restart authentication		Indicates that the lower layer would like to restart
			authentication.
	eapSRTT (integer)		eapSRTT (integer)
	Smoothed round-trip time. (see [RFC3748], Section 4.3)		Smoothed round-trip time. (See [RFC3748], Section 4.3.)
	eapRTTVAR (integer)		eapRTTVAR (integer)
	Round-trip time variation. (see [RFC3748], Section 4.3)		Round-trip time variation. (See [RFC3748], Section 4.3.)
	5.1.2. Variables (standalone authenticator to lower layer)		5.1.2. Variables (Stand-Alone Authenticator To Lower Layer)
	eapReq (boolean)		eapReq (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates a new EAP request is ready to be sent.		Indicates that a new EAP request is ready to be sent.
	eapNoReq (boolean)		eapNoReq (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates the most recent response has been processed, but there		Indicates the most recent response has been processed, but there
	is no new request to send.		is no new request to send.
	eapSuccess (boolean)		eapSuccess (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates the state machine has reached the SUCCESS state.		Indicates that the state machine has reached the SUCCESS state.
	eapFail (boolean)		eapFail (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates the state machine has reached the FAILURE state.		Indicates that the state machine has reached the FAILURE state.
	eapTimeout (boolean)		eapTimeout (boolean)
	Set to TRUE in the TIMEOUT_FAILURE state if the authenticator has		Set to TRUE in the TIMEOUT_FAILURE state if the authenticator has
	reached its maximum number of retransmissions without receiving a		reached its maximum number of retransmissions without receiving a
	response.		response.
	eapReqData (EAP packet)		eapReqData (EAP packet)
	Set in authenticator state machine when eapReq, eapSuccess, or		Set in authenticator state machine when eapReq, eapSuccess, or
	eapFail is set to TRUE. The actual EAP request to be sent (or		eapFail is set to TRUE. The actual EAP request to be sent (or
	success/failure).		success/failure).
	eapKeyData (EAP key)		eapKeyData (EAP key)
	Set in authenticator state machine when keying material becomes		Set in authenticator state machine when keying material becomes
	available. Set during the METHOD state. Note that this document		available. Set during the METHOD state. Note that this document
	does not yet define the structure of the type "EAP key". We		does not define the structure of the type "EAP key". We expect
	expect it to be defined in [Keying].		that it will be defined in [Keying].
	eapKeyAvailable (boolean)		eapKeyAvailable (boolean)
	Set to TRUE in the SUCCESS state if keying material is available.		Set to TRUE in the SUCCESS state if keying material is available.
	The actual key is stored in eapKeyData.		The actual key is stored in eapKeyData.
	5.1.3. Constants		5.1.3. Constants
	MaxRetrans (integer)		MaxRetrans (integer)
	Configurable maximum for how many retransmissions should be		Configurable maximum for how many retransmissions should be
	attempted before aborting.		attempted before aborting.
	5.2. Interface between standalone authenticator state machine and		5.2. Interface between Stand-Alone Authenticator State Machine and
	methods		Methods
	IN: eapRespData, methodState		IN: eapRespData, methodState
	OUT: ignore, eapReqData		OUT: ignore, eapReqData
	IN/OUT: currentId, (method-specific state), (policy)		IN/OUT: currentId, (method-specific state), (policy)
	The following describes the interaction between the state machine and		The following describes the interaction between the state machine and
	EAP methods.		EAP methods.
	skipping to change at page 21, line 19 ¶		skipping to change at page 20, line 21 ¶
	identifier value, and updates its method-specific state accordingly.		identifier value, and updates its method-specific state accordingly.
	m.getTimeout (in: -, out: integer or NONE)		m.getTimeout (in: -, out: integer or NONE)
	The method can also provide a hint for retransmission timeout with		The method can also provide a hint for retransmission timeout with
	m.getTimeout.		m.getTimeout.
	m.check (in: EAP packet, out: boolean)		m.check (in: EAP packet, out: boolean)
	When a new EAP Response is received, the method must first decide		When a new EAP Response is received, the method must first decide
	whether to process the packet or silently discard it. If the packet		whether to process the packet or to discard it silently. If the
	looks like it was not sent by the legitimate peer (e.g., it has		packet looks like it was not sent by the legitimate peer (e.g., if it
	invalid MIC, and this case should never occur), the method can		has an invalid Message Integrity Check (MIC), which should never
	indicate this by returning FALSE. In this case, the method should		occur), the method can indicate this by returning FALSE. In this
	not modify its own method-specific state.		case, the method should not modify its own method-specific state.
	m.process (in: EAP packet, out: -)		m.process (in: EAP packet, out: -)
	m.isDone (in: -, out: boolean)		m.isDone (in: -, out: boolean)
	m.getKey (in: -, out: EAP key or NONE)		m.getKey (in: -, out: EAP key or NONE)
	Next, the method processes the EAP Response and updates its own		Next, the method processes the EAP Response and updates its own
	method-specific state. Now the options are to continue the		method-specific state. Now the options are to continue the
	conversation (send another request) or end this method.		conversation (send another request) or to end this method.
	If the method wants to end the conversation, it		If the method wants to end the conversation, it
	o Tells Policy about the outcome of the method, and possibly other		o Tells Policy about the outcome of the method and possibly other
	information.		information.
	o If the method has derived keying material it wants to export,		o If the method has derived keying material it wants to export,
	returns it from m.getKey().		returns it from m.getKey().
	o Indicates that the method wants to end by returning TRUE from		o Indicates that the method wants to end by returning TRUE from
	m.isDone().		m.isDone().
	Otherwise, the method continues by sending another request, as		Otherwise, the method continues by sending another request, as
	described earlier.		described earlier.
	5.3. Standalone authenticator state machine local variables		5.3. Stand-Alone Authenticator State Machine Local Variables
	5.3.1. Long-term (maintained between packets)		5.3.1. Long-Term (Maintained between Packets)
	currentMethod (EAP type)		currentMethod (EAP type)
	EAP type, IDENTITY, or NOTIFICATION.		EAP type, IDENTITY, or NOTIFICATION.
	currentId (integer)		currentId (integer)
	0-255 or NONE. Usually updated in PROPOSE_METHOD state.		0-255 or NONE. Usually updated in PROPOSE_METHOD state.
	Indicates the identifier value of the currently outstanding EAP		Indicates the identifier value of the currently outstanding EAP
	request.		request.
	skipping to change at page 22, line 37 ¶		skipping to change at page 21, line 37 ¶
	lastReqData (EAP packet)		lastReqData (EAP packet)
	Set in SEND_REQUEST state. EAP packet containing the last sent		Set in SEND_REQUEST state. EAP packet containing the last sent
	request.		request.
	methodTimeout (integer)		methodTimeout (integer)
	Method-provided hint for suitable retransmission timeout, or NONE.		Method-provided hint for suitable retransmission timeout, or NONE.
	5.3.2. Short-term (not maintained between packets)		5.3.2. Short-Term (Not Maintained between Packets)
	rxResp (boolean)		rxResp (boolean)
	Set in RECEIVED state. Indicates the current received packet is		Set in RECEIVED state. Indicates that the current received packet
	an EAP response.		is an EAP response.
	respId (integer)		respId (integer)
	Set in RECEIVED state. The identifier from the current EAP		Set in RECEIVED state. The identifier from the current EAP
	response.		response.
	respMethod (EAP type)		respMethod (EAP type)
	Set in RECEIVED state. The method type of the current EAP		Set in RECEIVED state. The method type of the current EAP
	response.		response.
	ignore (boolean)		ignore (boolean)
	Set in METHOD state. Indicates whether the method has decided to		Set in METHOD state. Indicates whether the method has decided to
	drop the current packet.		drop the current packet.
	decision (enumeration)		decision (enumeration)
	Set in SELECT_ACTION state. Temporarily store the policy decision		Set in SELECT_ACTION state. Temporarily stores the policy
	to succeed, fail, or continue.		decision to succeed, fail, or continue.
	5.4. EAP standalone authenticator procedures		5.4. EAP Stand-Alone Authenticator Procedures
	NOTE: For method procedures, the method uses its internal state in		NOTE: For method procedures, the method uses its internal state in
	addition to the information provided by the EAP layer. The only		addition to the information provided by the EAP layer. The only
	arguments that are explicitly shown as inputs to the procedures are		arguments that are explicitly shown as inputs to the procedures are
	those provided to the method by EAP. Those inputs provided by the		those provided to the method by EAP. Those inputs provided by the
	method's internal state remain implicit.		method's internal state remain implicit.
	calculateTimeout()		calculateTimeout()
	Calculates the retransmission timeout, taking into account the		Calculates the retransmission timeout, taking into account the
	retransmission count, round-trip time measurements, and method-		retransmission count, round-trip time measurements, and method-
	specific timeout hint (see [RFC3748], Section 4.3). Returns an		specific timeout hint (see [RFC3748], Section 4.3). Returns an
	integer.		integer.
	parseEapResp()		parseEapResp()
	Determine the code, identifier value, and type of the current		Determines the code, identifier value, and type of the current
	response. In case of a parsing error (e.g., the length field is		response. In the case of a parsing error (e.g., the length field
	longer than the received packet), rxResp will be set to FALSE.		is longer than the received packet), rxResp will be set to FALSE.
	The values of respId and respMethod may be undefined as a result.		The values of respId and respMethod may be undefined as a result.
	Returns a boolean, an integer, and an EAP type.		Returns a boolean, an integer, and an EAP type.
	buildSuccess()		buildSuccess()
	Create an EAP Success Packet. Returns an EAP packet.		Creates an EAP Success Packet. Returns an EAP packet.
	buildFailure()		buildFailure()
	Create an EAP Failure Packet. Returns an EAP packet.		Creates an EAP Failure Packet. Returns an EAP packet.
	nextId()		nextId()
	Determine the next identifier value to use, based on the previous		Determines the next identifier value to use, based on the previous
	one. Returns an integer.		one. Returns an integer.
	Policy.update()		Policy.update()
	Update all variables related to internal policy state. Return		Updates all variables related to internal policy state. The
	value is undefined.		return value is undefined.
	Policy.getNextMethod()		Policy.getNextMethod()
	Determine the method that should be used at this point in the		Determines the method that should be used at this point in the
	conversation based on pre-defined policy. Policy.getNextMethod()		conversation based on predefined policy. Policy.getNextMethod()
	MUST comply with [RFC3748] (Section 2.1), which forbids the use of		MUST comply with [RFC3748] (Section 2.1), which forbids the use of
	sequences of authentication methods within an EAP conversation.		sequences of authentication methods within an EAP conversation.
	Hence, if an authentication method has already been executed		Thus, if an authentication method has already been executed within
	within an EAP dialog, Policy.getNextMethod() MUST NOT propose		an EAP dialog, Policy.getNextMethod() MUST NOT propose another
	another authentication method within the same EAP dialog. Returns		authentication method within the same EAP dialog. Returns an EAP
	an EAP type.		type.
	Policy.getDecision()		Policy.getDecision()
	Determine if the policy will allow SUCCESS, FAIL, or is yet to		Determines if the policy will allow SUCCESS, FAIL, or is yet to
	determine (CONTINUE). Returns a decision enumeration.		determine (CONTINUE). Returns a decision enumeration.
	m.check()		m.check()
	Method-specific procedure to test for the validity of a message.		Method-specific procedure to test for the validity of a message.
	Returns a boolean.		Returns a boolean.
	m.process()		m.process()
	Method procedure to parse and process a response for that method.		Method procedure to parse and process a response for that method.
	Return value is undefined.		The return value is undefined.
	m.init()		m.init()
	Method procedure to initialize state just before use. Return		Method procedure to initialize state just before use. The return
	value is undefined.		value is undefined.
	m.reset()		m.reset()
	Method procedure to indicate the method is ending in the middle or		Method procedure to indicate that the method is ending in the
	before completion. Return value is undefined.		middle of or before completion. The return value is undefined.
	m.isDone()		m.isDone()
	Method procedure to check for method completion. Returns a		Method procedure to check for method completion. Returns a
	boolean.		boolean.
	m.getTimeout()		m.getTimeout()
	Method procedure to determine an appropriate timeout hint for that		Method procedure to determine an appropriate timeout hint for that
	method. Returns an integer.		method. Returns an integer.
	skipping to change at page 25, line 20 ¶		skipping to change at page 24, line 20 ¶
	m.getKey()		m.getKey()
	Method procedure to obtain key material for use by EAP or lower		Method procedure to obtain key material for use by EAP or lower
	layers. Returns an EAP key.		layers. Returns an EAP key.
	m.buildReq()		m.buildReq()
	Method procedure to produce the next request. Returns an EAP		Method procedure to produce the next request. Returns an EAP
	packet.		packet.
	5.5. EAP standalone authenticator states		5.5. EAP Stand-Alone Authenticator States
	DISABLED		DISABLED
	The authenticator is disabled until the port is enabled by the		The authenticator is disabled until the port is enabled by the
	lower layer.		lower layer.
	INITIALIZE		INITIALIZE
	Initializes variables when the state machine is activated.		Initializes variables when the state machine is activated.
	IDLE		IDLE
	The state machine spends most of its time here, waiting for		The state machine spends most of its time here, waiting for
	something to happen.		something to happen.
	RECEIVED		RECEIVED
	This state is entered when an EAP packet is received: the packet		This state is entered when an EAP packet is received. The packet
	header is parsed here.		header is parsed here.
	INTEGRITY_CHECK		INTEGRITY_CHECK
	A method state in which the integrity of the incoming packet from		A method state in which the integrity of the incoming packet from
	the peer is verified by the method.		the peer is verified by the method.
	METHOD_RESPONSE		METHOD_RESPONSE
	A method state in which the incoming packet is processed.		A method state in which the incoming packet is processed.
	skipping to change at page 26, line 12 ¶		skipping to change at page 25, line 12 ¶
	A method state in which a new request is formulated if necessary.		A method state in which a new request is formulated if necessary.
	PROPOSE_METHOD		PROPOSE_METHOD
	A state in which the authenticator decides which method to try		A state in which the authenticator decides which method to try
	next in the authentication.		next in the authentication.
	SELECT_ACTION		SELECT_ACTION
	In between methods, the state machine re-evaluates whether or not		Between methods, the state machine re-evaluates whether its policy
	its policy is satisfied and succeeds, fails, or remains undecided.		is satisfied and succeeds, fails, or remains undecided.
	SEND_REQUEST		SEND_REQUEST
	This state signals the lower layer that a request packet is ready		This state signals the lower layer that a request packet is ready
	to be sent.		to be sent.
	DISCARD		DISCARD
	This state signals the lower layer that the response was		This state signals the lower layer that the response was
	discarded, and no new request packet will be sent at this time.		discarded, and no new request packet will be sent at this time.
	skipping to change at page 26, line 46 ¶		skipping to change at page 25, line 46 ¶
	FAILURE		FAILURE
	A final state indicating failure.		A final state indicating failure.
	TIMEOUT_FAILURE		TIMEOUT_FAILURE
	A final state indicating failure because no response has been		A final state indicating failure because no response has been
	received. Because no response was received, no new message		received. Because no response was received, no new message
	(including failure) should be sent to the peer. Note that this is		(including failure) should be sent to the peer. Note that this is
	different from the FAILURE state, where a message indicating		different from the FAILURE state, in which a message indicating
	failure is sent to the peer.		failure is sent to the peer.
	6. EAP Backend Authenticator		6. EAP Backend Authenticator
	When operating in pass-through mode, there are conceptually two parts		When operating in pass-through mode, there are conceptually two parts
	to the authenticator - the part that passes packets through and the		to the authenticator: the part that passes packets through, and the
	backend that actually implements the EAP method. The following		backend that actually implements the EAP method. The following
	diagram shows a state machine for the backend part of this model when		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		using a AAA server. Note that this diagram is identical to Figure 4
	except no retransmit is included in the IDLE state because with		except that no retransmit is included in the IDLE state because with
	RADIUS retransmit is handled by the NAS, and a PICK_UP_METHOD state		RADIUS, retransmit is handled by the NAS. Also, a PICK_UP_METHOD
	and variable in INITIALIZE state are added to allow the Method to		state and variable in INITIALIZE state are added to allow the Method
	"pickup" a method started in a NAS. Included is an explanation of		to "pick up" a method started in a NAS. Included is an explanation
	the primitives and procedures referenced in the diagram, many of		of the primitives and procedures referenced in the diagram, many of
	which are the same as above. It should be noted that the "lower		which are the same as above. Note that the "lower layer" in this
	layer" in this case is some AAA protocol (e.g., RADIUS).		case is some AAA protocol (e.g., RADIUS).
	(see the .pdf version for missing diagram or		(see the .pdf version for missing diagram or
	refer to Appendix A.3 if reading the .txt version)		refer to Appendix A.3 if reading the .txt version)
	Figure 5: EAP Backend Authenticator State Machine		Figure 5: EAP Backend Authenticator State Machine
	6.1. Interface between backend authenticator state machine and lower		6.1. Interface between Backend Authenticator State Machine and Lower
	layer		Layer
	The lower layer presents messages to the EAP backend authenticator		The lower layer presents messages to the EAP backend authenticator
	state machine by storing the packet in aaaEapRespData and setting the		state machine by storing the packet in aaaEapRespData and setting the
	aaaEapResp signal to TRUE.		aaaEapResp signal to TRUE.
	When the EAP backend authenticator state machine has finished		When the EAP backend authenticator state machine has finished
	processing the message, it sets one of the signals aaaEapReq,		processing the message, it sets one of the signals aaaEapReq,
	aaaEapNoReq, aaaSuccess, and aaaFail. If it sets eapReq, eapSuccess,		aaaEapNoReq, aaaSuccess, and aaaFail. If it sets eapReq, eapSuccess,
	or eapFail, the corresponding request (or success/failure) packet is		or eapFail, the corresponding request (or success/failure) packet is
	stored in aaaEapReqData. The lower layer is responsible for actually		stored in aaaEapReqData. The lower layer is responsible for actually
	transmitting this message.		transmitting this message.
	6.1.1. Variables (AAA interface to backend authenticator)		6.1.1. Variables (AAA Interface to Backend Authenticator)
	aaaEapResp (boolean)		aaaEapResp (boolean)
	Set to TRUE in lower layer, FALSE in authenticator state machine.		Set to TRUE in lower layer, FALSE in authenticator state machine.
	Usually indicates that an EAP response, stored in aaaEapRespData,		Usually indicates that an EAP response, stored in aaaEapRespData,
	is available for processing by the AAA server. If aaaEapRespData		is available for processing by the AAA server. If aaaEapRespData
	is set to NONE, indicates that the AAA server should send the		is set to NONE, it indicates that the AAA server should send the
	initial EAP request.		initial EAP request.
	aaaEapRespData (EAP packet)		aaaEapRespData (EAP packet)
	Set in lower layer when eapResp is set to TRUE. The EAP packet to		Set in lower layer when eapResp is set to TRUE. The EAP packet to
	be processed or NONE.		be processed, or NONE.
	backendEnabled (boolean)		backendEnabled (boolean)
	Indicates that there is a valid link to use for the communication.		Indicates that there is a valid link to use for the communication.
	If at any point the port is not available, backendEnabled is set		If at any point the port is not available, backendEnabled is set
	to FALSE and the state machine transitions to DISABLED.		to FALSE, and the state machine transitions to DISABLED.
	6.1.2. Variables (backend authenticator to AAA interface)		6.1.2. Variables (Backend Authenticator to AAA Interface)
	aaaEapReq (boolean)		aaaEapReq (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates a new EAP request is ready to be sent.		Indicates that a new EAP request is ready to be sent.
	aaaEapNoReq (boolean)		aaaEapNoReq (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates the most recent response has been processed, but there		Indicates that the most recent response has been processed, but
	is no new request to send.		there is no new request to send.
	aaaSuccess (boolean)		aaaSuccess (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates the state machine has reached the SUCCESS state.		Indicates that the state machine has reached the SUCCESS state.
	aaaFail (boolean)		aaaFail (boolean)
	Set to TRUE in authenticator state machine, FALSE in lower layer.		Set to TRUE in authenticator state machine, FALSE in lower layer.
	Indicates the state machine has reached the FAILURE state.		Indicates that the state machine has reached the FAILURE state.
	aaaEapReqData (EAP packet)		aaaEapReqData (EAP packet)
	Set in authenticator state machine when aaaEapReq, aaaSuccess, or		Set in authenticator state machine when aaaEapReq, aaaSuccess, or
	aaaFail is set to TRUE. The actual EAP request to be sent (or		aaaFail is set to TRUE. The actual EAP request to be sent (or
	success/failure).		success/failure).
	aaaEapKeyData (EAP key)		aaaEapKeyData (EAP key)
	Set in authenticator state machine when keying material becomes		Set in authenticator state machine when keying material becomes
	available. Set during the METHOD_RESPONSE state. Note that this		available. Set during the METHOD_RESPONSE state. Note that this
	document does not yet define the structure of the type "EAP key".		document does not define the structure of the type "EAP key". We
	We expect it to be defined in [Keying].		expect that it will be defined in [Keying].
	aaaEapKeyAvailable (boolean)		aaaEapKeyAvailable (boolean)
	Set to TRUE in the SUCCESS state if keying material is available.		Set to TRUE in the SUCCESS state if keying material is available.
	The actual key is stored in aaaEapKeyData.		The actual key is stored in aaaEapKeyData.
	aaaMethodTimeout (integer)		aaaMethodTimeout (integer)
	Method-provided hint for suitable retransmission timeout, or NONE		Method-provided hint for suitable retransmission timeout, or NONE.
	(note that this hint is for the EAP retransmissions done by the		(Note that this hint is for the EAP retransmissions done by the
	pass-through authenticator, not retransmissions of AAA packets).		pass-through authenticator, not for retransmissions of AAA
			packets.)
	6.2. Interface between backend authenticator state machine and methods		6.2. Interface between Backend Authenticator State Machine and
			Methods
	The backend method interface is almost the same as in standalone		The backend method interface is almost the same as in stand-alone
	authenticator described in Section 5.2. The only difference is that		authenticator described in Section 5.2. The only difference is that
	some methods on the backend may support "picking up" a conversation		some methods on the backend may support "picking up" a conversation
	started by the pass-through. That is, the EAP Request packet was		started by the pass-through. That is, the EAP Request packet was
	sent by the pass-through, but the backend must process the		sent by the pass-through, but the backend must process the
	corresponding EAP Response. Usually only the Identity method		corresponding EAP Response. Usually only the Identity method
	supports this, but others are possible.		supports this, but others are possible.
	When "picking up" a conversation, m.initPickUp() is called instead of		When "picking up" a conversation, m.initPickUp() is called instead of
	m.init(). Next, m.process() must examine eapRespData and update its		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		own method-specific state to match what it would have been if it had
	skipping to change at page 29, line 29 ¶		skipping to change at page 28, line 26 ¶
	authenticator described in Section 5.2. The only difference is that		authenticator described in Section 5.2. The only difference is that
	some methods on the backend may support "picking up" a conversation		some methods on the backend may support "picking up" a conversation
	started by the pass-through. That is, the EAP Request packet was		started by the pass-through. That is, the EAP Request packet was
	sent by the pass-through, but the backend must process the		sent by the pass-through, but the backend must process the
	corresponding EAP Response. Usually only the Identity method		corresponding EAP Response. Usually only the Identity method
	supports this, but others are possible.		supports this, but others are possible.
	When "picking up" a conversation, m.initPickUp() is called instead of		When "picking up" a conversation, m.initPickUp() is called instead of
	m.init(). Next, m.process() must examine eapRespData and update its		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		own method-specific state to match what it would have been if it had
	actually sent the corresponding request. (Obviously, this only works		actually sent the corresponding request. (Obviously, this only works
	for methods that can determine what the initial request contained;		for methods that can determine what the initial request contained;
	Identity and EAP-TLS are good examples.)		Identity and EAP-TLS are good examples.)
	After this, the processing continues as described in Section 5.2.		After this, the processing continues as described in Section 5.2.
	6.3. Backend authenticator state machine local variables		6.3. Backend Authenticator State Machine Local Variables
	For definitions of the variables used in the Backend Authenticator,		For definitions of the variables used in the Backend Authenticator,
	see Section 5.3.		see Section 5.3.
	6.4. EAP backend authenticator procedures		6.4. EAP Backend Authenticator Procedures
	Most of the procedures of the backend authenticator have already been		Most of the procedures of the backend authenticator have already been
	defined in Section 5.4. This section contains definitions for those		defined in Section 5.4. This section contains definitions for those
	not existent in the standalone version, as well as those which are		not existent in the stand-alone version, as well as those that are
	defined differently.		defined differently.
	NOTE: For method procedures, the method uses its internal state in		NOTE: For method procedures, the method uses its internal state in
	addition to the information provided by the EAP layer. The only		addition to the information provided by the EAP layer. The only
	arguments that are explicitly shown as inputs to the procedures are		arguments that are explicitly shown as inputs to the procedures are
	those provided to the method by EAP. Those inputs provided by the		those provided to the method by EAP. Those inputs provided by the
	method's internal state remain implicit.		method's internal state remain implicit.
	Policy.doPickUp()		Policy.doPickUp()
	Notify the policy that an already-chosen method is being picked up		Notifies the policy that an already-chosen method is being picked
	and will be completed. Returns a boolean.		up and will be completed. Returns a boolean.
	m.initPickUp()		m.initPickUp()
	Method procedure to initialize state when continuing from an		Method procedure to initialize state when continuing from an
	already-started method. Return value is undefined.		already-started method. The return value is undefined.
	6.5. EAP backend authenticator states		6.5. EAP Backend Authenticator States
	Most of the states of the backend authenticator have already been		Most of the states of the backend authenticator have already been
	defined in Section 5.5. This section contains definitions for those		defined in Section 5.5. This section contains definitions for those
	not existent in the standalone version, as well as those which are		not existent in the stand-alone version, as well as those that are
	defined differently.		defined differently.
	PICK_UP_METHOD		PICK_UP_METHOD
	Set an initial state for a method that is being continued and was		Sets an initial state for a method that is being continued and
	started elsewhere.		that was started elsewhere.
	7. EAP Full Authenticator		7. EAP Full Authenticator
	The following two diagrams show the state machine for a complete		The following two diagrams show the state machine for a complete
	authenticator. The first diagram is identical to the Standalone		authenticator. The first diagram is identical to the stand-alone
	State Machine, shown in Figure 4, with the exception that the		state machine, shown in Figure 4, with the exception that the
	SELECT_ACTION state has an added transition to PASSTHROUGH. The		SELECT_ACTION state has an added transition to PASSTHROUGH. The
	second diagram also keeps most of the logic except the four method		second diagram also keeps most of the logic, except the four method
	states, and shows how the state machine works once it goes to Pass-		states, and it shows how the state machine works once it goes to
	Through Mode.		pass-through mode.
	The first diagram is largely a reproduction of that found above, with		The first diagram is largely a reproduction of that found above, with
	the added hooks for a transition to PASSTHROUGH mode.		the added hooks for a transition to PASSTHROUGH mode.
	(see the .pdf version for missing diagram or		(see the .pdf version for missing diagram or
	refer to Appendix A.4 if reading the .txt version)		refer to Appendix A.4 if reading the .txt version)
	Figure 6: EAP Full Authenticator State Machine (Part 1)		Figure 6: EAP Full Authenticator State Machine (Part 1)
	The second diagram describes the functionality necessary for an		The second diagram describes the functionality necessary for an
	authenticator operating in pass-through mode. This section of the		authenticator operating in pass-through mode. This section of the
	diagram is the counterpart of the backend diagram above.		diagram is the counterpart of the backend diagram above.
	(see the .pdf version for missing diagram or		(see the .pdf version for missing diagram or
	refer to Appendix A.4 if reading the .txt version)		refer to Appendix A.4 if reading the .txt version)
	Figure 7: EAP Full Authenticator State Machine (Part 2)		Figure 7: EAP Full Authenticator State Machine (Part 2)
	7.1. Interface between full authenticator state machine and lower		7.1. Interface between Full Authenticator State Machine and Lower
	layers		Layers
	The full authenticator is unique in that it interfaces to multiple		The full authenticator is unique in that it interfaces to multiple
	lower layers in order to support pass-through mode. The interface to		lower layers in order to support pass-through mode. The interface to
	the primary EAP transport layer is the same as described in Section		the primary EAP transport layer is the same as described in Section
	5. The following describes the interface to the second lower layer,		5. The following describes the interface to the second lower layer,
	which represents an interface to AAA. It should be noted that there		which represents an interface to AAA. Note that there is not
	is not necessarily a direct interaction between the EAP layer and the		necessarily a direct interaction between the EAP layer and the AAA
	AAA layer, as in the case of [1X-REV].		layer, as in the case of [1X-2004].
	7.1.1. Variables (AAA interface to full authenticator)		7.1.1. Variables (AAA Interface to Full Authenticator)
	aaaEapReq (boolean)		aaaEapReq (boolean)
	Set to TRUE in lower layer, FALSE in authenticator state machine.		Set to TRUE in lower layer, FALSE in authenticator state machine.
	Indicates a new EAP request is available from the AAA server.		Indicates that a new EAP request is available from the AAA server.
	aaaEapNoReq (boolean)		aaaEapNoReq (boolean)
	Set to TRUE in lower layer, FALSE in authenticator state machine.		Set to TRUE in lower layer, FALSE in authenticator state machine.
	Indicates the most recent response has been processed, but there		Indicates that the most recent response has been processed, but
	is no new request to send.		that there is no new request to send.
	aaaSuccess (boolean)		aaaSuccess (boolean)
	Set to TRUE in lower layer. Indicates the AAA backend		Set to TRUE in lower layer. Indicates that the AAA backend
	authenticator has reached the SUCCESS state.		authenticator has reached the SUCCESS state.
	aaaFail (boolean)		aaaFail (boolean)
	Set to TRUE in lower layer. Indicates the AAA backend		Set to TRUE in lower layer. Indicates that the AAA backend
	authenticator has reached the FAILURE state.		authenticator has reached the FAILURE state.
	aaaEapReqData (EAP packet)		aaaEapReqData (EAP packet)
	Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is		Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is
	set to TRUE. The actual EAP request to be sent (or success/		set to TRUE. The actual EAP request to be sent (or success/
	failure).		failure).
	aaaEapKeyData (EAP key)		aaaEapKeyData (EAP key)
	Set in lower layer when keying material becomes available from the		Set in lower layer when keying material becomes available from the
	AAA server. Note that this document does not yet define the		AAA server. Note that this document does not define the structure
	structure of the type "EAP key". We expect it to be defined in		of the type "EAP key". We expect that it will be defined in
	[Keying].		[Keying].
	aaaEapKeyAvailable (boolean)		aaaEapKeyAvailable (boolean)
	Set to TRUE in the lower layer if keying material is available.		Set to TRUE in the lower layer if keying material is available.
	The actual key is stored in aaaEapKeyData.		The actual key is stored in aaaEapKeyData.
	aaaMethodTimeout (integer)		aaaMethodTimeout (integer)
	Method-provided hint for suitable retransmission timeout, or NONE		Method-provided hint for suitable retransmission timeout, or NONE.
	(note that this hint is for the EAP retransmissions done by the		(Note that this hint is for the EAP retransmissions done by the
	pass-through authenticator, not retransmissions of AAA packets).		pass-through authenticator, not for retransmissions of AAA
			packets.)
	7.1.2. Variables (full authenticator to AAA interface)		7.1.2. Variables (full authenticator to AAA interface)
	aaaEapResp (boolean)		aaaEapResp (boolean)
	Set to TRUE in authenticator state machine, FALSE in the lower		Set to TRUE in authenticator state machine, FALSE in the lower
	layer. Indicates an EAP response is available for processing by		layer. Indicates that an EAP response is available for processing
	the AAA server.		by the AAA server.
	aaaEapRespData (EAP packet)		aaaEapRespData (EAP packet)
	Set in authenticator state machine when eapResp is set to TRUE.		Set in authenticator state machine when eapResp is set to TRUE.
	The EAP packet to be processed.		The EAP packet to be processed.
	aaaIdentity (EAP packet)		aaaIdentity (EAP packet)
	Set in authenticator state machine when an IDENTITY response is		Set in authenticator state machine when an IDENTITY response is
	received. Makes that identity available to AAA lower layer.		received. Makes that identity available to AAA lower layer.
	aaaTimeout (boolean)		aaaTimeout (boolean)
	Set in AAA_IDLE if after a configurable amount of time there is no		Set in AAA_IDLE if, after a configurable amount of time, there is
	response from the AAA layer. The AAA layer in the NAS is itself		no response from the AAA layer. The AAA layer in the NAS is
	alive and OK, but for some reason it has not received a valid		itself alive and OK, but for some reason it has not received a
	Access-Accept/Reject indication from the backend		valid Access-Accept/Reject indication from the backend.
	7.1.3. Constants		7.1.3. Constants
	Same as Section 5.		Same as Section 5.
	7.2. Interface between full authenticator state machine and methods		7.2. Interface between Full Authenticator State Machine and Methods
	Same as standalone authenticator (Section 5.2)		Same as stand-alone authenticator (Section 5.2).
	7.3. Full authenticator state machine local variables		7.3. Full Authenticator State Machine Local Variables
	Many of the variables of the full authenticator have already been		Many of the variables of the full authenticator have already been
	defined in Section 5. This section contains definitions for those		defined in Section 5. This section contains definitions for those
	not existent in the standalone version, as well as those which are		not existent in the stand-alone version, as well as those that are
	defined differently.		defined differently.
	7.3.1. Short-term (not maintained between packets)		7.3.1. Short-Term (Not Maintained between Packets)
	decision (enumeration)		decision (enumeration)
	Set in SELECT_ACTION state. Temporarily store the policy decision		Set in SELECT_ACTION state. Temporarily stores the policy
	to succeed, fail, continue with a local method, or continue in		decision to succeed, fail, continue with a local method, or
	pass-through mode.		continue in pass-through mode.
	7.4. EAP full authenticator procedures		7.4. EAP Full Authenticator Procedures
	All of the procedures defined in Section 5 exist in the full version.		All the procedures defined in Section 5 exist in the full version.
	In addition, the following procedures are defined.		In addition, the following procedures are defined.
	getId()		getId()
	Determine the identifier value chosen by the AAA server for the		Determines the identifier value chosen by the AAA server for the
	current EAP request. Return value is an integer.		current EAP request. The return value is an integer.
	7.5. EAP full authenticator states		7.5. EAP Full Authenticator States
	All of the states defined in Section 5 exist in the full version. In		All the states defined in Section 5 exist in the full version. In
	addition, the following states are defined.		addition, the following states are defined.
	INITIALIZE_PASSTHROUGH		INITIALIZE_PASSTHROUGH
	Initializes variables when the pass-through portion of the state		Initializes variables when the pass-through portion of the state
	machine is activated.		machine is activated.
	IDLE2		IDLE2
	The state machine waits for a response from the primary lower		The state machine waits for a response from the primary lower
	layer, which transports EAP traffic from the peer.		layer, which transports EAP traffic from the peer.
	IDLE		IDLE
	The state machine spends most of its time here, waiting for		The state machine spends most of its time here, waiting for
	something to happen.		something to happen.
	RECEIVED2		RECEIVED2
	This state is entered when an EAP packet is received and the		This state is entered when an EAP packet is received and the
	authenticator is in PASSTHROUGH mode: the packet header is parsed		authenticator is in PASSTHROUGH mode. The packet header is parsed
	here.		here.
	AAA_REQUEST		AAA_REQUEST
	The incoming EAP packet is parsed for sending to the AAA server.		The incoming EAP packet is parsed for sending to the AAA server.
	AAA_IDLE		AAA_IDLE
	Idle state which tells the AAA layer it has a response and then		Idle state that tells the AAA layer that it has a response and
	waits for a new request, a no-request signal, or success/failure.		then waits for a new request, a no-request signal, or
			success/failure.
	AAA_RESPONSE		AAA_RESPONSE
	State in which the request from the AAA interface is processed		State in which the request from the AAA interface is processed
	into an EAP request.		into an EAP request.
	SEND_REQUEST2		SEND_REQUEST2
	This state signals the lower layer that a request packet is ready		This state signals the lower layer that a request packet is ready
	to be sent.		to be sent.
	DISCARD2		DISCARD2
	This state signals the lower layer that the response was		This state signals the lower layer that the response was
	discarded, and no new request packet will be sent at this time.		discarded, and that no new request packet will be sent at this
			time.
	RETRANSMIT2		RETRANSMIT2
	Retransmits the previous request packet.		Retransmits the previous request packet.
	SUCCESS2		SUCCESS2
	A final state indicating success.		A final state indicating success.
	FAILURE2		FAILURE2
	A final state indicating failure.		A final state indicating failure.
	TIMEOUT_FAILURE2		TIMEOUT_FAILURE2
	A final state indicating failure because no response has been		A final state indicating failure because no response has been
	received. Because no response was received, no new message		received. Because no response was received, no new message
	(including failure) should be sent to the peer. Note that this is		(including failure) should be sent to the peer. Note that this is
	different from the FAILURE2 state, where a message indicating		different from the FAILURE2 state, in which a message indicating
	failure is sent to the peer.		failure is sent to the peer.
	8. Implementation Considerations		8. Implementation Considerations
	8.1. Robustness		8.1. Robustness
	In order to deal with erroneous cases that are not directly related		In order to deal with erroneous cases that are not directly related
	to the protocol behavior, implementations may need additional		to the protocol behavior, implementations may need additional
	considerations to provide robustness against errors.		considerations to provide robustness against errors.
	For example, an implementation of a state machine may spend a		For example, an implementation of a state machine may spend a
	significant amount of time in a particular state for performing the		significant amount of time in a particular state performing the
	procedure defined for the state without returning a response. If		procedure defined for the state without returning a response. If
	such an implementation is made on a multithreading system, the		such an implementation is made on a multithreading system, the
	procedure may be performed in a separate thread so that the		procedure may be performed in a separate thread so that the
	implementation can perform appropriate action to deal with the case		implementation can perform appropriate action without blocking on the
	without blocking on the state for a long time (or forever if the		state for a long time (or forever if the procedure never completes
	procedure never completes due to, e.g., a non-responding user or a		due to, e.g., a non-responding user or a bug in an application
	bug in an application callback function.)		callback function).
	The following states are identified as the possible places of		The following states are identified as the possible places of
	blocking:		blocking:
	o IDENTITY state in the peer state machine. It may take some time		o IDENTITY state in the peer state machine. It may take some time
	to process Identity request when a user input is needed for		to process Identity request when a user input is needed for
	obtaining an identity from the user. The user may never input an		obtaining an identity from the user. The user may never input an
	identity. An implementation may define an additional state		identity. An implementation may define an additional state
	transition from IDENTITY state to FAILURE state so that		transition from IDENTITY state to FAILURE state so that
	authentication can fail if no identity is obtained from the user		authentication can fail if no identity is obtained from the user
	skipping to change at page 36, line 49 ¶		skipping to change at page 35, line 11 ¶
	TIMEOUT_FAILURE state so that authentication can fail if no method		TIMEOUT_FAILURE state so that authentication can fail if no method
	processing result is obtained from the method before methodTimeout		processing result is obtained from the method before methodTimeout
	timer expires.		timer expires.
	8.2. Method/Method and Method/Lower-Layer Interfaces		8.2. Method/Method and Method/Lower-Layer Interfaces
	Implementations may define additional interfaces to pass method-		Implementations may define additional interfaces to pass method-
	specific information between methods and lower layers. These		specific information between methods and lower layers. These
	interfaces are beyond the scope of this document.		interfaces are beyond the scope of this document.
	8.3. Peer state machine interoperability with deployed implementations		8.3. Peer State Machine Interoperability with Deployed Implementations
	Number of deployed EAP authenticator implementations, mainly in		Number of deployed EAP authenticator implementations, mainly in
	RADIUS authentication servers, have been observed to incorrectly		RADIUS authentication servers, have been observed to increment the
	increments Identifier field when generating EAP Success and EAP		Identifier field incorrectly when generating EAP Success and EAP
	Failure packets which is against the MUST requirement in RFC 3748		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		section 4.2. The peer state machine is based on RFC 3748, and as
	it will discard such EAP Success and EAP Failure packets.		such it will discard such EAP Success and EAP Failure packets.
	As a workaround for the potential interoperability issue with		As a workaround for the potential interoperability issue with
	existing implementations, conditions for peer state machine		existing implementations, conditions for peer state machine
	transitions from RECEIVED state to SUCCESS and FAILURE states MAY be		transitions from RECEIVED state to SUCCESS and FAILURE states MAY be
	changed from "(reqId == lastId)" to "((reqId == lastId) || (reqId ==		changed from "(reqId == lastId)" to "((reqId == lastId) || (reqId ==
	(lastId + 1) & 255))". However, since this behavior does not conform		(lastId + 1) & 255))". However, because this behavior does not
	to RFC 3748, such a workaround is not recommended and if included, it		conform to RFC 3748, such a workaround is not recommended, and if
	should be implemented as an optional workaround that can be disabled.		included, it should be implemented as an optional workaround that can
			be disabled.
	9. Security Considerations		9. Security Considerations
	This document's intent is to describe the EAP state machine fully.		This document's intent is to describe the EAP state machine fully.
	To this end, any security concerns with this document are likely a		To this end, any security concerns with this document are likely a
	reflection of security concerns with EAP itself.		reflection of security concerns with EAP itself.
	An accurate state machine can help reduce implementation errors.		An accurate state machine can help reduce implementation errors.
	While [RFC3748] remains the normative protocol description, this		Although [RFC3748] remains the normative protocol description, this
	state machine should help in this regard.		state machine should help in this regard.
	As noted in [RFC3748], there are some security concerns that arise		As noted in [RFC3748], some security concerns arise because of the
	because of the following EAP packets:		following EAP packets:
	1. EAP-Request/Response Identity		1. EAP-Request/Response Identity
	2. EAP-Response/NAK		2. EAP-Response/NAK
	3. EAP-Success/Failure		3. EAP-Success/Failure
	Since these packets are not cryptographically protected by		Because these packets are not cryptographically protected by
	themselves, an attacker can modify or insert them without immediate		themselves, an attacker can modify or insert them without immediate
	detection by the peer or authenticator.		detection by the peer or authenticator.
	Following Figure 3 specification, an attacker may cause denial of		Following Figure 3 specification, an attacker may cause denial of
	service by:		service by:
	o Sending an EAP-Failure to the peer before the peer has started an		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		EAP authentication method. As long as the peer has not modified
	the methodState variable (initialized to NONE), the peer MUST		the methodState variable (initialized to NONE), the peer MUST
	accept an EAP-Failure.		accept an EAP-Failure.
	o Forcing the peer to engage in endless EAP-Request/Response		o Forcing the peer to engage in endless EAP-Request/Response
	Identity exchanges before it has started an EAP authentication		Identity exchanges before it has started an EAP authentication
	method. As long as the peer has not modified the selectedMethod		method. As long as the peer has not modified the selectedMethod
	variable (initialized to NONE), the peer MUST accept an EAP-		variable (initialized to NONE), the peer MUST accept an EAP-
	Request/Identity and respond to it with an EAP-Response/ Identity.		Request/Identity and respond to it with an EAP-Response/Identity.
	Following Figure 4 specification, an attacker may cause denial of		Following Figure 4 specification, an attacker may cause denial of
	service by:		service by:
	o Sending a NAK to the authenticator after the authenticator first		o Sending a NAK to the authenticator after the authenticator first
	proposes an EAP authentication method to the peer. When the		proposes an EAP authentication method to the peer. When the
	methodState variable has the value PROPOSED, the authenticator is		methodState variable has the value PROPOSED, the authenticator is
	obliged to process a NAK that is received in response to its first		obliged to process a NAK that is received in response to its first
	packet of an EAP authentication method.		packet of an EAP authentication method.
	There MAY be some cases when it is desired to prevent such attacks.		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		This can be done by modifying initial values of some variables of the
	EAP state machines. However, such modifications are NOT RECOMMENDED.		EAP state machines. However, such modifications are NOT RECOMMENDED.
	There is a trade-off between mitigating these denial of service		There is a trade-off between mitigating these denial-of-service
	attacks and being able to deal with EAP peers and authenticators in		attacks and being able to deal with EAP peers and authenticators in
	general. For instance, should the sending of a NAK to the		general. For instance, if a NAK is ignored when it is sent to the
	authenticator after it has just proposed an EAP authentication method		authenticator after it has just proposed an EAP authentication method
	to the peer be ignored, then a legitimate peer that is not able or		to the peer, then a legitimate peer that is not able or willing to
	willing to process the proposed EAP authentication method would fail		process the proposed EAP authentication method would fail without an
	without an opportunity to negotiate another EAP method.		opportunity to negotiate another EAP method.
	10. Acknowledgments		10. Acknowledgements
	The work in this document was done as part of the EAP Design Team.		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		It was done primarily by Nick Petroni, John Vollbrecht, Pasi Eronen,
	and Yoshihiro Ohba. Nick started this work with Bryan Payne and Chuk		and Yoshihiro Ohba. Nick started this work with Bryan Payne and Chuk
	Seng at the University of Maryland. John Vollbrecht, of Vollbrecht		Seng at the University of Maryland. John Vollbrecht of Meetinghouse
	Consulting, started independently with help from Dave Spence at		Data Communications started independently with help from Dave Spence
	Interlink Networks. John and Nick combined to create a common		at Interlink Networks. John and Nick collaborated to create a common
	document, and then were joined by Pasi Eronen of Nokia who has made		document, and then were joined by Pasi Eronen of Nokia, who has made
	major contributions in creating coherent state machines, and		major contributions in creating coherent state machines, and by
	Yoshihiro Ohba of Toshiba who insisted on including Pass-Through		Yoshihiro Ohba of Toshiba, who insisted on including pass-through
	documentation and provided significant support for understanding		documentation and provided significant support for understanding
	implementation issues.		implementation issues.
	In addition significant response and conversation has come from the		In addition, significant response and conversation has come from the
	design team, especially including Jari Arkko of Ericsson and Bernard		design team, especially Jari Arkko of Ericsson and Bernard Aboba of
	Aboba of Microsoft as well as the rest of the team. It has also been		Microsoft, as well as the rest of the team. It has also been
	passed through the 802.1aa group, and has had input from Jim Burns of		reviewed by IEEE 802.1, and has had input from Jim Burns of
	Meetinghouse and Paul Congdon of Hewlett Packard.		Meetinghouse and Paul Congdon of Hewlett Packard.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication		[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
	skipping to change at page 39, line 24 ¶		skipping to change at page 37, line 30 ¶
	Authentication Protocol (EAP)", RFC 3579, September 2003.		Authentication Protocol (EAP)", RFC 3579, September 2003.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, Ed., "Extensible Authentication Protocol		Levkowetz, Ed., "Extensible Authentication Protocol
	(EAP)", RFC 3748, June 2004.		(EAP)", RFC 3748, June 2004.
	11.2. Informative References		11.2. Informative References
	[Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz,		[Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz,
	H., "Extensible Authentication Protocol (EAP) Key		H., "Extensible Authentication Protocol (EAP) Key
	Management Framework", Work in Progress, July 2004.		Management Framework", Work in Progress, July 2005.
	[1X-REV] Institute of Electrical and Electronics Engineers, "DRAFT		[1X-2004] Institute of Electrical and Electronics Engineers,
	Standard for Local and Metropolitan Area Networks: Port-		"Standard for Local and Metropolitan Area Networks:
	Based Network Access Control (Revision)", IEEE 802-1X-		Port-Based Network Access Control", IEEE 802.1X-2004,
	REV/D11, July 2004.		December 2004.
	Appendix A. ASCII versions of state diagrams		Appendix A. ASCII versions of state diagrams
	This appendix contains the state diagrams in ASCII format. Please		This appendix contains the state diagrams in ASCII format. Please
	use the PDF version whenever possible: it is much easier to		use the PDF version whenever possible; it is much easier to
	understand.		understand.
	The notation is as follows: state name and pseudocode executed when		The notation is as follows: state name and pseudocode executed when
	entering it are shown on the left; outgoing transitions with their		entering it are shown on the left; outgoing transitions with their
	conditions are shown on the right.		conditions are shown on the right.
	A.1. EAP Peer State Machine (Figure 3)		A.1. EAP Peer State Machine (Figure 3)
	---------------------------------------------------------------------		---------------------------------------------------------------------
	(global transitions) | !portEnabled | DISABLED		(global transitions) | !portEnabled | DISABLED
	skipping to change at page 43, line 40 ¶		skipping to change at page 41, line 40 ¶
	if (eapKeyData != NONE) | |		if (eapKeyData != NONE) | |
	eapKeyAvailable = TRUE | |		eapKeyAvailable = TRUE | |
	eapSuccess = TRUE | |		eapSuccess = TRUE | |
	-----------------------------+------------------------+--------------		-----------------------------+------------------------+--------------
	FAILURE | |		FAILURE | |
	| |		| |
	eapFail = TRUE | |		eapFail = TRUE | |
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 8		Figure 8
	A.2. EAP Standalone Authenticator State Machine (Figure 4)		A.2. EAP Stand-Alone Authenticator State Machine (Figure 4)
	---------------------------------------------------------------------		---------------------------------------------------------------------
	(global transitions) | !portEnabled | DISABLED		(global transitions) | !portEnabled | DISABLED
	|---------------------+----------------		|---------------------+----------------
	| eapRestart && | INITIALIZE		| eapRestart && | INITIALIZE
	| portEnabled |		| portEnabled |
	------------------------------+---------------------+----------------		------------------------------+---------------------+----------------
	DISABLED | portEnabled | INITIALIZE		DISABLED | portEnabled | INITIALIZE
	------------------------------+---------------------+----------------		------------------------------+---------------------+----------------
	------------------------------+---------------------+----------------		------------------------------+---------------------+----------------
	skipping to change at page 49, line 28 ¶		skipping to change at page 47, line 28 ¶
	aaaEapReqData = | |		aaaEapReqData = | |
	buildSuccess(currentId) | |		buildSuccess(currentId) | |
	if (aaaEapKeyData != NONE) | |		if (aaaEapKeyData != NONE) | |
	aaaEapKeyAvailable = TRUE | |		aaaEapKeyAvailable = TRUE | |
	aaaEapSuccess = TRUE | |		aaaEapSuccess = TRUE | |
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 10		Figure 10
	A.4. EAP Full Authenticator State Machine (Figures 6 and 7)		A.4. EAP Full Authenticator State Machine (Figures 6 and 7)
	This state machine contains all the states from EAP Standalone		This state machine contains all the states from EAP stand-alone
	Authenticator State Machine, except that SELECT_ACTION state is		authenticator state machine, except that SELECT_ACTION state is
	replaced with the following:		replaced with the following:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	SELECT_ACTION | decision == FAILURE | FAILURE		SELECT_ACTION | decision == FAILURE | FAILURE
	| |		| |
	decision = |---------------------+----------------		decision = |---------------------+----------------
	Policy.getDecision() | decision == SUCCESS | SUCCESS		Policy.getDecision() | decision == SUCCESS | SUCCESS
	/* SUCCESS, FAILURE, CONTINUE,|---------------------+----------------		/* SUCCESS, FAILURE, CONTINUE,|---------------------+----------------
	or PASSTHROUGH */ | decision == | INITIALIZE_		or PASSTHROUGH */ | decision == | INITIALIZE_
	| PASSTHROUGH | PASSTHROUGH		| PASSTHROUGH | PASSTHROUGH
	skipping to change at page 52, line 7 ¶		skipping to change at page 50, line 7 ¶
	eapReqData = aaaEapReqData | |		eapReqData = aaaEapReqData | |
	eapKeyData = aaaEapKeyData | |		eapKeyData = aaaEapKeyData | |
	eapKeyAvailable = | |		eapKeyAvailable = | |
	aaaEapKeyAvailable | |		aaaEapKeyAvailable | |
	eapSuccess = TRUE | |		eapSuccess = TRUE | |
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 12		Figure 12
	Authors' Addresses		Authors' Addresses
	John R. Vollbrecht		John Vollbrecht
	Vollbrecht Consulting LLC		Meetinghouse Data Communications
	9682 Alice Hill Drive		9682 Alice Hill Drive
	Dexter, MI 48130		Dexter, MI 48130
	USA		USA
	EMail: jrv@umich.edu		EMail: jrv@mtghouse.com
	Pasi Eronen		Pasi Eronen
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 Nokia Group,		FIN-00045 Nokia Group,
	Finland		Finland
	EMail: pasi.eronen@nokia.com		EMail: pasi.eronen@nokia.com
	Nick L. Petroni, Jr.		Nick L. Petroni, Jr.
	skipping to change at page 53, line 7 ¶		skipping to change at page 51, line 7 ¶
	Yoshihiro Ohba		Yoshihiro Ohba
	Toshiba America Research, Inc.		Toshiba America Research, Inc.
	1 Telcordia Drive		1 Telcordia Drive
	Piscataway, NJ 08854		Piscataway, NJ 08854
	USA		USA
	EMail: yohba@tari.toshiba.com		EMail: yohba@tari.toshiba.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005).
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		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		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	skipping to change at page 53, line 40 ¶		skipping to change at page 51, line 42 ¶
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		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		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at ietf-
	ietf-ipr@ietf.org.		ipr@ietf.org.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 209 change blocks.
	418 lines changed or deleted		410 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/