idnits 2.17.1 draft-ietf-eap-statemachine-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2316. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2284), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 23, 2004) is 7062 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3579 Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EAP Working Group J. Vollbrecht 2 Internet-Draft Vollbrecht Consulting LLC 3 Expires: June 23, 2005 P. Eronen 4 draft-ietf-eap-statemachine-06 Nokia 5 N. Petroni 6 University of Maryland 7 Y. Ohba 8 TARI 9 December 23, 2004 11 State Machines for Extensible Authentication Protocol (EAP) 12 Peer and Authenticator 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 or will be disclosed, and any of which I become aware will be 19 disclosed, in accordance with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than a "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document describes a set of state machines for Extensible 44 Authentication Protocol (EAP) peer, EAP standalone authenticator 45 (non-pass-through), EAP backend authenticator (for use on 46 Authentication, Authorization and Accounting (AAA) servers), and EAP 47 full authenticator (for both local and pass-through). This set of 48 state machines shows how EAP can be implemented to support deployment 49 in either a peer/authenticator or peer/authenticator/AAA Server 50 environment. The peer and standalone authenticator machines are 51 illustrative of how the EAP protocol defined in RFC 3748 may be 52 implemented. The backend and full/pass-through authenticators 53 illustrate how EAP/AAA protocol support defined in RFC 3579 may be 54 implemented. Where there are differences RFC 3748/RFC 3579 are 55 authoritative. 57 The state machines are based on the EAP "Switch" model. This model 58 includes events and actions for the interaction between the EAP 59 Switch and EAP methods. A brief description of the EAP "Switch" 60 model is given in the Introduction section. 62 The state machine and associated model are informative only. 63 Implementations may achieve the same results using different methods. 65 Table of Contents 67 1. Specification of Requirements . . . . . . . . . . . . . . . . 4 68 2. The EAP Switch Model . . . . . . . . . . . . . . . . . . . . . 4 69 3. Notational conventions used in state diagrams . . . . . . . . 5 70 3.1. Notational specifics . . . . . . . . . . . . . . . . . . 5 71 3.2. State Machine Symbols. . . . . . . . . . . . . . . . . . 8 72 3.3. Document authority . . . . . . . . . . . . . . . . . . . 9 73 4. Peer State Machine . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Interface between peer state machine and lower layer . . 10 75 4.2. Interface between peer state machine and methods . . . . 12 76 4.3. Peer state machine local variables . . . . . . . . . . . 14 77 4.4. Peer state machine procedures. . . . . . . . . . . . . . 15 78 4.5. Peer state machine states. . . . . . . . . . . . . . . . 16 79 5. Standalone Authenticator State Machine . . . . . . . . . . . . 18 80 5.1. Interface between standalone authenticator state machine 81 and lower layer. . . . . . . . . . . . . . . . . . . . . 18 82 5.2. Interface between standalone authenticator state machine 83 and methods. . . . . . . . . . . . . . . . . . . . . . . 20 84 5.3. Standalone authenticator state machine local variables . 22 85 5.4. EAP standalone authenticator procedures. . . . . . . . . 23 86 5.5. EAP standalone authenticator states. . . . . . . . . . . 25 87 6. EAP Backend Authenticator . . . . . . . . . . . . . . . . . . 27 88 6.1. Interface between backend authenticator state machine 89 and lower layer. . . . . . . . . . . . . . . . . . . . . 27 90 6.2. Interface between backend authenticator state machine 91 and methods. . . . . . . . . . . . . . . . . . . . . . . 29 92 6.3. Backend authenticator state machine local variables. . . 29 93 6.4. EAP backend authenticator procedures . . . . . . . . . . 29 94 6.5. EAP backend authenticator states . . . . . . . . . . . . 30 95 7. EAP Full Authenticator . . . . . . . . . . . . . . . . . . . . 31 96 7.1. Interface between full authenticator state machine and 97 lower layers . . . . . . . . . . . . . . . . . . . . . . 31 98 7.2. Interface between full authenticator state machine and 99 methods . . . . . . . . . . . . . . . . . . . . . . . . 33 100 7.3. Full authenticator state machine local variables . . . . 33 101 7.4. EAP full authenticator procedures. . . . . . . . . . . . 34 102 7.5. EAP full authenticator states. . . . . . . . . . . . . . 34 103 8. Implementation Considerations. . . . . . . . . . . . . . . . . 36 104 8.1 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 36 105 8.2 Method/Method and Method/Lower-Layer Interfaces. . . . . . 36 106 8.3 Peer state machine interoperability with deployed 107 implementations . . . . . . . . . . . . . . . . . . . . . 36 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 109 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 112 11.2. Informative References . . . . . . . . . . . . . . . . . 39 114 Appendix. ASCII versions of state diagrams . . . . . . . . . . . . 40 115 A.1. EAP Peer State Machine (Figure 3) . . . . . . . . . . . 40 116 A.2. EAP Standalone Authenticator State Machine (Figure 4) . 43 117 A.3. EAP Backend Authenticator State Machine (Figure 5) . . . 46 118 A.4. EAP Full Authenticator State Machine (Figures 6 and 7) . 49 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 120 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 122 1. Specification of Requirements 124 In this document, several words are used to signify the requirements 125 of the specification. These words are often capitalized. The key 126 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 127 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 128 are to be interpreted as described in [RFC2119]. 130 2. The EAP Switch Model 132 This document offers a proposed state machine for RFCs [RFC3748] and 133 [RFC3579]. There are state machines for the peer, the standalone 134 authenticator, a backend authenticator and a full/pass-through 135 authenticator. Accompanying each state machine diagram is a 136 description of the variables, the functions and the states in the 137 diagram. Whenever possible, the same notation has been used in each 138 of the state machines. 140 An EAP authentication consists of one or more EAP methods in sequence 141 followed by an EAP Success or EAP Failure sent from the authenticator 142 to the peer. The EAP Switches control negotiation of EAP methods and 143 sequences of methods. 145 Peer Peer | Authenticator Auth 146 Method | Method 147 \ | / 148 \ | / 149 Peer | Auth 150 EAP <-----|----------> EAP 151 Switch | Switch 153 Figure 1: EAP Switch Model 155 At both the peer and authenticator one or more EAP methods exist. 156 The EAP switches select which methods each is willing to use, and 157 negotiate between themselves to pick a method or sequence of methods. 159 Note that the methods may also have state machines. The details of 160 these are outside the scope of this paper. 162 Peer | Authenticator | Backend 163 | / Local | 164 | / Method | 165 Peer | Auth | Backend 166 EAP --|-----> EAP | -> EAP 167 Switch | Switch | / Server 168 | \ | / 169 | \ pass-through | 170 | | 172 Figure 2: EAP Pass-Through Model 174 The Full/Pass-Through state machine allows a NAS or Edge Device to 175 pass EAP Response messages to a Backend Server where the 176 Authentication Method resides. This paper includes a state machine 177 for the EAP authenticator that supports both local and pass-through 178 methods as well as a state machine for the backend authenticator 179 existing at the AAA server. A simple "Standalone" authenticator is 180 also provided to show a basic, non-pass-through authenticator's 181 behavior. 183 This document describes a set of State Machines that can manage EAP 184 authentication from the peer to an EAP method on the authenticator or 185 from the peer through the authenticator pass-through method to the 186 EAP method on the Backend EAP server. 188 Some environments where EAP is used, such as PPP, may support peer- 189 to-peer operation. That is, both parties act as peers and 190 authenticators at the same time, in two simultaneous and independent 191 EAP conversations. In this case, the implementation at each node has 192 to perform demultiplexing of incoming EAP packets. EAP packets with 193 Code set to Response are delivered to the authenticator state machine 194 and EAP packets with Code set to Request, Success or Failure are 195 delivered to the peer state machine. 197 The state diagrams presented in this document have been coordinated 198 with the diagrams in [1X-REV]. The format of the diagrams is adapted 199 from the format therein. The interface between the state machines 200 defined here and the IEEE-802-1X-REV state machines is also explained 201 in Appendix F of [1X-REV]. 203 3. Notational conventions used in state diagrams 205 3.1. Notational specifics 207 The following state diagrams have been completed based on the 208 conventions specified in [1X-REV], section 8.2.1. The complete text 209 is reproduced here: 211 State diagrams are used to represent the operation of the protocol 212 by a number of cooperating state machines each comprising a group 213 of connected, mutually exclusive states. Only one state of each 214 machine can be active at any given time. 216 Each state is represented in the state diagram as a rectangular 217 box, divided into two parts by a horizontal line. The upper part 218 contains the state identifier, written in upper case letters. The 219 lower part contains any procedures that are executed on entry to 220 the state. 222 All permissible transitions between states are represented by 223 arrows, the arrowhead denoting the direction of the possible 224 transition. Labels attached to arrows denote the condition(s) 225 that must be met in order for the transition to take place. All 226 conditions are expressions that evaluate to TRUE or FALSE; if a 227 condition evaluates to TRUE, then the condition is met. The label 228 UCT denotes an unconditional transition (i.e., UCT always 229 evaluates to TRUE). A transition that is global in nature (i.e., 230 a transition that occurs from any of the possible states if the 231 condition attached to the arrow is met) is denoted by an open 232 arrow; i.e., no specific state is identified as the origin of the 233 transition. When the condition associated with a global 234 transition is met, it supersedes all other exit conditions 235 including UCT. The special global condition BEGIN supersedes all 236 other global conditions, and once asserted remains asserted until 237 all state blocks have executed to the point that variable 238 assignments and other consequences of their execution remain 239 unchanged. 241 On entry to a state, the procedures defined for the state (if any) 242 are executed exactly once, in the order that they appear on the 243 page. Each action is deemed to be atomic; i.e., execution of a 244 procedure completes before the next sequential procedure starts to 245 execute. No procedures execute outside of a state block. The 246 procedures in only one state block execute at a time, even if the 247 conditions for execution of state blocks in different state 248 machines are satisfied, and all procedures in an executing state 249 block complete execution before the transition to and execution of 250 any other state block occurs, i.e., the execution of any state 251 block appears to be atomic with respect to the execution of any 252 other state block and the transition condition to that state from 253 the previous state is TRUE when execution commences. The order of 254 execution of state blocks in different state machines is undefined 255 except as constrained by their transition conditions. A variable 256 that is set to a particular value in a state block retains this 257 value until a subsequent state block executes a procedure that 258 modifies the value. 260 On completion of all of the procedures within a state, all exit 261 conditions for the state (including all conditions associated with 262 global transitions) are evaluated continuously until one of the 263 conditions is met. The label ELSE denotes a transition that 264 occurs if none of the other conditions for transitions from the 265 state are met (i.e., ELSE evaluates to TRUE if all other possible 266 exit conditions from the state evaluate to FALSE). Where two or 267 more exit conditions with the same level of precedence become TRUE 268 simultaneously, the choice as to which exit condition causes the 269 state transition to take place is arbitrary. 271 Where it is necessary to split a state machine description across 272 more than one diagram, a transition between two states that appear 273 on different diagrams is represented by an exit arrow drawn with 274 dashed lines, plus a reference to the diagram that contains the 275 destination state. Similarly, dashed arrows and a dashed state 276 box are used on the destination diagram to show the transition to 277 the destination state. In a state machine that has been split in 278 this way, any global transitions that can cause entry to states 279 defined in one of the diagrams are deemed to be potential exit 280 conditions for all of the states of the state machine, regardless 281 of which diagram the state boxes appear in. 283 Should a conflict exist between the interpretation of a state 284 diagram and either the corresponding global transition tables or 285 the textual description associated with the state machine, the 286 state diagram takes precedence. The interpretation of the special 287 symbols and operators used in the state diagrams is as defined in 288 Section 3.2; these symbols and operators are derived from the 289 notation of the C++ programming language, ISO/IEC 14882. If a 290 boolean variable is described in this clause as being set it has 291 or is assigned the value TRUE, if reset or clear the value FALSE. 293 In addition to the above notation, there are a couple of 294 clarifications specific to this document. First, all boolean 295 variables are initialized to FALSE before the state machine execution 296 begins. Second, the following notational shorthand is specific to 297 this document: 299 = | | ... 301 Execution of a statement of this form will result in 302 having a value of exactly one of the expressions. The logic for 303 which of those expressions gets executed is outside of the state 304 machine and could be environmental, configurable, or based on 305 another state machine such as that of the method. 307 3.2. State Machine Symbols 309 ( ) 311 Used to force the precedence of operators in Boolean expressions 312 and to delimit the argument(s) of actions within state boxes. 314 ; 316 Used as a terminating delimiter for actions within state boxes. 317 Where a state box contains multiple actions, the order of 318 execution follows the normal English language conventions for 319 reading text. 321 = 323 Assignment action. The value of the expression to the right of 324 the operator is assigned to the variable to the left of the 325 operator. Where this operator is used to define multiple 326 assignments, e.g., a = b = X the action causes the value of the 327 expression following the right-most assignment operator to be 328 assigned to all of the variables that appear to the left of the 329 right-most assignment operator. 331 ! 333 Logical NOT operator. 335 && 337 Logical AND operator. 339 || 341 Logical OR operator. 343 if...then... 345 Conditional action. If the Boolean expression following the if 346 evaluates to TRUE, then the action following the then is executed. 348 { statement 1, ... statement N } 350 Compound statement. Braces are used to group statements that are 351 executed together as if they were a single statement. 353 != 355 Inequality. Evaluates to TRUE if the expression to the left of 356 the operator is not equal in value to the expression to the right. 358 == 360 Equality. Evaluates to TRUE if the expression to the left of the 361 operator is equal in value to the expression to the right. 363 > 365 Greater than. Evaluates to TRUE if the value of the expression to 366 the left of the operator is greater than the value of the 367 expression to the right. 369 <= 371 Less than or equal to. Evaluates to TRUE if the value of the 372 expression to the left of the operator is either less than or 373 equal to the value of the expression to the right. 375 ++ 377 Increment the preceding integer operator by 1. 379 + 381 Arithmetic addition operator. 383 & 385 Bitwise AND operator. 387 3.3. Document authority 389 Should a conflict exist between the interpretation of a state diagram 390 and either the corresponding global transition tables or the textual 391 description associated with the state machine, the state diagram 392 takes precedence. When a discrepancy occurs between any part of this 393 document (text or diagram) and any of the related documents 394 ([RFC3748], [RFC3579], etc.) the latter (the other document) is 395 considered authoritative and takes precedence. 397 4. Peer State Machine 399 The following is a diagram of the EAP peer state machine. Also 400 included is an explanation of the primitives and procedures 401 referenced in the diagram, as well as a clarification of notation. 403 (see the .pdf version for missing diagram or 404 refer to Appendix A.1 if reading the .txt version) 406 Figure 3: EAP Peer State Machine 408 4.1. Interface between peer state machine and lower layer 410 The lower layer presents messages to the EAP peer state machine by 411 storing the packet in eapReqData and setting the eapReq signal to 412 TRUE. Note that despite the name of the signal, the lower layer does 413 not actually inspect the contents of the EAP packet (it could be a 414 Success or Failure message instead of a Request). 416 When the EAP peer state machine has finished processing the message 417 it sets either eapResp or eapNoResp. If it sets eapResp, the 418 corresponding response packet is stored in eapRespData. The lower 419 layer is responsible for actually transmitting this message. When 420 the EAP peer state machine authentication is complete it will set 421 eapSuccess or eapFailure to indicate to the lower layer that the 422 authentication has succeeded or failed. 424 4.1.1. Variables (lower layer to peer) 426 eapReq (boolean) 428 Set to TRUE in lower layer, FALSE in peer state machine. 429 Indicates there is a request available in the lower layer. 431 eapReqData (EAP packet) 433 Set in lower layer when eapReq is set to TRUE. The contents of 434 the available request. 436 portEnabled (boolean) 438 Indicates that the EAP peer state machine should be ready for 439 communication. This is set to TRUE when the EAP conversation is 440 started by the lower layer. If at any point the communication 441 port or session is not available, portEnabled is set to FALSE and 442 the state machine transitions to DISABLED. To avoid unnecessary 443 resets, the lower layer may dampen link down indications when it 444 believes that the link is only temporarily down and that it will 445 soon be back up (see [RFC3748], Section 7.12). In this case, 446 portEnabled may not always be equal to the the "link up" flag of 447 the lower layer. 449 idleWhile (integer) 451 Outside timer used to indicate how long remains before the peer 452 will timeout while waiting for a valid request. 454 eapRestart (boolean) 456 Indicates the lower layer would like to restart authentication 458 altAccept (boolean) 460 Alternate indication of success, as described in [RFC3748]. 462 altReject (boolean) 464 Alternate indication of failure, as described in [RFC3748]. 466 4.1.2. Variables (peer to lower layer) 468 eapResp (boolean) 470 Set to TRUE in peer state machine, FALSE in lower layer. 471 Indicates there is a response to be sent. 473 eapNoResp (boolean) 475 Set to TRUE in peer state machine, FALSE in lower layer. 476 Indicates the request has been processed, but there is no response 477 to send. 479 eapSuccess (boolean) 481 Set to TRUE in peer state machine, FALSE in lower layer. 482 Indicates the Peer has reached the SUCCESS state. 484 eapFail (boolean) 486 Set to TRUE in peer state machine, FALSE in lower layer. 487 Indicates the Peer has reached the FAILURE state. 489 eapRespData (EAP packet) 491 Set in peer state machine when eapResp is set to TRUE. The EAP 492 packet which is the response to send. 494 eapKeyData (EAP key) 496 Set in peer state machine when keying material becomes available. 497 Set during the METHOD state. Note that this document does not yet 498 define the structure of the type "EAP key". We expect it to be 499 defined in [Keying]. 501 eapKeyAvailable (boolean) 503 Set to TRUE in the SUCCESS state if keying material is available. 504 The actual key is stored in eapKeyData. 506 4.1.3. Constants 508 ClientTimeout (integer) 510 Configurable amount of time to wait for a valid request before 511 aborting, initialized by implementation-specific means (e.g., a 512 configuration setting). 514 4.2. Interface between peer state machine and methods 516 IN: eapReqData (includes reqId) 518 OUT: ignore, eapRespData, allowNotifications, decision 520 IN/OUT: methodState, (method-specific state) 522 The following describes the interaction between the state machine and 523 EAP methods. 525 If methodState==INIT, the method starts by initializing its own 526 method-specific state. 528 Next, the method must decide whether to process the packet or 529 silently discard it. If the packet appears to have been sent by 530 someone other than the legitimate authenticator (for instance, 531 message integrity check fails) and the method is capable of treating 532 such situations as non-fatal, the method can set ignore=TRUE. In 533 this case, the method should not modify any other variables. 535 If the method decides to process the packet, it behaves as follows. 537 o Updates its own method-specific state. 539 o If the method has derived keying material it wants to export, 540 stores the keying material to eapKeyData. 542 o Creates a response packet (with the same identifier as the 543 request), and stores it to eapRespData. 545 o Sets ignore=FALSE. 547 Next, the method must update methodState and decision according to 548 the following rules. 550 methodState=CONT: The method always continues at this point (and the 551 peer wants to continue it). The decision variable is always set 552 to FAIL. 554 methodState=MAY_CONT: At this point, the authenticator can decide 555 either to continue the method or end the conversation. The 556 decision variable tells us what to do in the case the conversation 557 ends. If the current situation does not satisfy the peer's 558 security policy (that is, if the authenticator now decides to 559 allow access, the peer will not use it), set decision=FAIL. 560 Otherwise, set decision=COND_SUCC. 562 methodState=DONE: The method never continues at this point, (or the 563 peer sees no point in continuing it). 565 If either (a) the authenticator has informed us that it will not 566 allow access, or (b) we're not willing to talk to this 567 authenticator (e.g., our security policy is not satisfied), set 568 decision=FAIL. (Note that this state can occur even if the method 569 still has additional messages left, if continuing it can not 570 change the peer's decision to success). 572 If both (a) the server has informed us that it will allow access 573 and the next packet will be EAP Success, and (b) we're willing to 574 use this access, set decision=UNCOND_SUCC. 576 Otherwise, we do not know what the server's decision is, but are 577 willing to use the access if the server allows. In this case, set 578 decision=COND_SUCC. 580 Finally, the method must set the allowNotifications variable. If the 581 new methodState is either CONT or MAY_CONT, and the method 582 specification does not forbid the use of Notification messages, set 583 allowNotifications=TRUE. Otherwise, set allowNotifications=FALSE. 585 4.3. Peer state machine local variables 587 4.3.1. Long-term (maintained between packets) 589 selectMethod (EAP type) 591 Set in GET_METHOD state. The method the peer believes to be 592 currently "in progress" 594 methodState (enumeration) 596 As described above. 598 lastId (integer) 600 0-255 or NONE. Set in SEND_RESPONSE state. The EAP identifier 601 value of the last request. 603 lastRespData (EAP packet) 605 Set in SEND_RESPONSE state. The EAP packet last sent from the 606 peer. 608 decision (enumeration) 610 As described above 612 NOTE: EAP type can be normal type (0..253,255), or an extended type 613 consisting of type 254, Vendor-Id, and Vendor-Type. 615 4.3.2. Short-term (not maintained between packets) 617 rxReq (boolean) 619 Set in RECEIVED state. Indicates the current received packet is 620 an EAP request. 622 rxSuccess (boolean) 624 Set in RECEIVED state. Indicates the current received packet is 625 an EAP Success. 627 rxFailure (boolean) 629 Set in RECEIVED state. Indicates the current received packet is 630 an EAP Failure. 632 reqId (integer) 634 Set in RECEIVED state. The identifier value associated with the 635 current EAP request. 637 reqMethod (EAP type) 639 Set in RECEIVED state. The method type of the current EAP request 641 ignore (boolean) 643 Set in METHOD state. Indicates whether the method has decided to 644 drop the current packet. 646 4.4. Peer state machine procedures 648 NOTE: For method procedures, the method uses its internal state in 649 addition to the information provided by the EAP layer. The only 650 arguments that are explicitly shown as inputs to the procedures are 651 those provided to the method by EAP. Those inputs provided by the 652 method's internal state remain implicit. 654 parseEapReq() 656 Determine the code, identifier value, and type of the current 657 request. In case of a parsing error (e.g., the length field is 658 longer than the received packet), rxReq, rxSuccess, and rxFailure 659 will all be set to FALSE. The values of reqId and reqMethod may 660 be undefined as a result. Returns three booleans, one integer, 661 and one EAP type. 663 processNotify() 665 Process the contents of Notification Request (for instance, 666 display it to the user or log it). Return value is undefined. 668 buildNotify() 670 Create the appropriate notification response. Returns an EAP 671 packet. 673 processIdentity() 675 Process the contents of Identity Request. Return value is 676 undefined. 678 buildIdentity() 680 Create the appropriate identity response. Returns an EAP packet. 682 m.check() 684 Method-specific procedure to test for the validity of a message. 685 Returns a boolean. 687 m.process() 689 Method procedure to parse and process a request for that method. 690 Returns a methodState enumeration, a decision enumeration, and a 691 boolean. 693 m.buildResp() 695 Method procedure to create a response message. Returns an EAP 696 packet. 698 m.getKey() 700 Method procedure to obtain key material for use by EAP or lower 701 layers. Returns an EAP key. 703 4.5. Peer state machine states 705 DISABLED 707 This state is reached anytime service from the lower layer is 708 interrupted or unavailable. Immediate transition to INITIALIZE 709 occurs when the port becomes enabled. 711 INITIALIZE 713 Initializes variables when the state machine is activated. 715 IDLE 717 The state machine spends most of its time here, waiting for 718 something to happen. 720 RECEIVED 722 This state is entered when an EAP packet is received: the packet 723 header is parsed here. 725 GET_METHOD 727 This state is entered when a request for a new type comes in: 728 either the correct method is started, or a Nak response is built. 730 METHOD 732 The method processing happens here: the request from the 733 authenticator is processed, and an appropriate response packet is 734 built. 736 SEND_RESPONSE 738 This state signals the lower layer that a response packet is ready 739 to be sent. 741 DISCARD 743 This state signals the lower layer that the request was discarded, 744 and no response packet will be sent at this time. 746 IDENTITY: 748 Handles requests for Identity method, and builds a response. 750 NOTIFICATION 752 Handles requests for Notification method, and builds a response. 754 RETRANSMIT 756 Retransmits the previous response packet. 758 SUCCESS 760 A final state indicating success. 762 FAILURE 764 A final state indicating failure. 766 5. Standalone Authenticator State Machine 768 The following is a diagram of the "Standalone" EAP authenticator 769 state machine. This diagram should be used for those interested in a 770 self-contained, or non-pass-through, authenticator. Included is an 771 explanation of the primitives and procedures referenced in the 772 diagram, as well as a clarification of notation. 774 (see the .pdf version for missing diagram or 775 refer to Appendix A.2 if reading the .txt version) 777 Figure 4: EAP Standalone Authenticator State Machine 779 5.1. Interface between standalone authenticator state machine and lower 780 layer 782 The lower layer presents messages to the EAP authenticator state 783 machine by storing the packet in eapRespData and setting the eapResp 784 signal to TRUE. 786 When the EAP authenticator state machine has finished processing the 787 message, it sets one of the signals eapReq, eapNoReq, eapSuccess, and 788 eapFail. If it sets eapReq, eapSuccess, or eapFail, the 789 corresponding request (or success/failure) packet is stored in 790 eapReqData. The lower layer is responsible for actually transmitting 791 this message. 793 5.1.1. Variables (lower layer to standalone authenticator) 795 eapResp (boolean) 797 Set to TRUE in lower layer, FALSE in authenticator state machine. 798 Indicates an EAP response is available for processing. 800 eapRespData (EAP packet) 802 Set in lower layer when eapResp is set to TRUE. The EAP packet to 803 be processed. 805 portEnabled (boolean) 807 Indicates that the EAP authenticator state machine should be ready 808 for communication. This is set to TRUE when the EAP conversation 809 is started by the lower layer. If at any point the communication 810 port or session is not available, portEnabled is set to FALSE and 811 the state machine transitions to DISABLED. To avoid unnecessary 812 resets, the lower layer may dampen link down indications when it 813 believes that the link is only temporarily down and that it will 814 soon be back up (see [RFC3748], Section 7.12). In this case, 815 portEnabled may not always be equal to the the "link up" flag of 816 the lower layer. 818 retransWhile (integer) 820 Outside timer used to indicate how long the authenticator has 821 waited for a new (valid) response. 823 eapRestart (boolean) 825 Indicates the lower layer would like to restart authentication 827 eapSRTT (integer) 829 Smoothed round-trip time. (see [RFC3748], Section 4.3) 831 eapRTTVAR (integer) 833 Round-trip time variation. (see [RFC3748], Section 4.3) 835 5.1.2. Variables (standalone authenticator to lower layer) 837 eapReq (boolean) 839 Set to TRUE in authenticator state machine, FALSE in lower layer. 840 Indicates a new EAP request is ready to be sent. 842 eapNoReq (boolean) 844 Set to TRUE in authenticator state machine, FALSE in lower layer. 845 Indicates the most recent response has been processed, but there 846 is no new request to send. 848 eapSuccess (boolean) 850 Set to TRUE in authenticator state machine, FALSE in lower layer. 851 Indicates the state machine has reached the SUCCESS state. 853 eapFail (boolean) 855 Set to TRUE in authenticator state machine, FALSE in lower layer. 856 Indicates the state machine has reached the FAILURE state. 858 eapTimeout (boolean) 860 Set to TRUE in the TIMEOUT_FAILURE state if the authenticator has 861 reached its maximum number of retransmissions without receiving a 862 response. 864 eapReqData (EAP packet) 866 Set in authenticator state machine when eapReq, eapSuccess, or 867 eapFail is set to TRUE. The actual EAP request to be sent (or 868 success/failure). 870 eapKeyData (EAP key) 872 Set in authenticator state machine when keying material becomes 873 available. Set during the METHOD state. Note that this document 874 does not yet define the structure of the type "EAP key". We 875 expect it to be defined in [Keying]. 877 eapKeyAvailable (boolean) 879 Set to TRUE in the SUCCESS state if keying material is available. 880 The actual key is stored in eapKeyData. 882 5.1.3. Constants 884 MaxRetrans (integer) 886 Configurable maximum for how many retransmissions should be 887 attempted before aborting. 889 5.2. Interface between standalone authenticator state machine and 890 methods 892 IN: eapRespData, methodState 894 OUT: ignore, eapReqData 896 IN/OUT: currentId, (method-specific state), (policy) 898 The following describes the interaction between the state machine and 899 EAP methods. 901 m.init (in: -, out: -) 903 When the method is first started, it must initialize its own method- 904 specific state, possibly using some information from Policy (e.g., 905 identity). 907 m.buildReq (in: integer, out: EAP packet) 909 Next, the method creates a new EAP Request packet, with the given 910 identifier value, and updates its method-specific state accordingly. 912 m.getTimeout (in: -, out: integer or NONE) 914 The method can also provide a hint for retransmission timeout with 915 m.getTimeout. 917 m.check (in: EAP packet, out: boolean) 919 When a new EAP Response is received, the method must first decide 920 whether to process the packet or silently discard it. If the packet 921 looks like it was not sent by the legitimate peer (e.g., it has 922 invalid MIC, and this case should never occur), the method can 923 indicate this by returning FALSE. In this case, the method should 924 not modify its own method-specific state. 926 m.process (in: EAP packet, out: -) 928 m.isDone (in: -, out: boolean) 930 m.getKey (in: -, out: EAP key or NONE) 932 Next, the method processes the EAP Response and updates its own 933 method-specific state. Now the options are to continue the 934 conversation (send another request) or end this method. 936 If the method wants to end the conversation, it 938 o Tells Policy about the outcome of the method, and possibly other 939 information. 941 o If the method has derived keying material it wants to export, 942 returns it from m.getKey(). 944 o Indicates that the method wants to end by returning TRUE from 945 m.isDone(). 947 Otherwise, the method continues by sending another request, as 948 described earlier. 950 5.3. Standalone authenticator state machine local variables 952 5.3.1. Long-term (maintained between packets) 954 currentMethod (EAP type) 956 EAP type, IDENTITY, or NOTIFICATION. 958 currentId (integer) 960 0-255 or NONE. Usually updated in PROPOSE_METHOD state. 961 Indicates the identifier value of the currently outstanding EAP 962 request. 964 methodState (enumeration) 966 As described above. 968 retransCount (integer) 970 Reset in SEND_REQUEST state and updated in RETRANSMIT state. 971 Current number of retransmissions. 973 lastReqData (EAP packet) 975 Set in SEND_REQUEST state. EAP packet containing the last sent 976 request. 978 methodTimeout (integer) 980 Method-provided hint for suitable retransmission timeout, or NONE. 982 5.3.2. Short-term (not maintained between packets) 984 rxResp (boolean) 986 Set in RECEIVED state. Indicates the current received packet is 987 an EAP response. 989 respId (integer) 991 Set in RECEIVED state. The identifier from the current EAP 992 response. 994 respMethod (EAP type) 996 Set in RECEIVED state. The method type of the current EAP 997 response. 999 ignore (boolean) 1001 Set in METHOD state. Indicates whether the method has decided to 1002 drop the current packet. 1004 decision (enumeration) 1006 Set in SELECT_ACTION state. Temporarily store the policy decision 1007 to succeed, fail, or continue. 1009 5.4. EAP standalone authenticator procedures 1011 NOTE: For method procedures, the method uses its internal state in 1012 addition to the information provided by the EAP layer. The only 1013 arguments that are explicitly shown as inputs to the procedures are 1014 those provided to the method by EAP. Those inputs provided by the 1015 method's internal state remain implicit. 1017 calculateTimeout() 1019 Calculates the retransmission timeout, taking into account the 1020 retransmission count, round-trip time measurements, and method- 1021 specific timeout hint (see [RFC3748], Section 4.3). Returns an 1022 integer. 1024 parseEapResp() 1026 Determine the code, identifier value, and type of the current 1027 response. In case of a parsing error (e.g., the length field is 1028 longer than the received packet), rxResp will be set to FALSE. 1029 The values of respId and respMethod may be undefined as a result. 1030 Returns a boolean, an integer, and an EAP type. 1032 buildSuccess() 1034 Create an EAP Success Packet. Returns an EAP packet. 1036 buildFailure() 1038 Create an EAP Failure Packet. Returns an EAP packet. 1040 nextId() 1042 Determine the next identifier value to use, based on the previous 1043 one. Returns an integer. 1045 Policy.update() 1047 Update all variables related to internal policy state. Return 1048 value is undefined. 1050 Policy.getNextMethod() 1052 Determine the method that should be used at this point in the 1053 conversation based on pre-defined policy. Policy.getNextMethod() 1054 MUST comply with [RFC3748] (Section 2.1), which forbids the use of 1055 sequences of authentication methods within an EAP conversation. 1056 Hence, if an authentication method has already been executed 1057 within an EAP dialog, Policy.getNextMethod() MUST NOT propose 1058 another authentication method within the same EAP dialog. Returns 1059 an EAP type. 1061 Policy.getDecision() 1063 Determine if the policy will allow SUCCESS, FAIL, or is yet to 1064 determine (CONTINUE). Returns a decision enumeration. 1066 m.check() 1068 Method-specific procedure to test for the validity of a message. 1069 Returns a boolean. 1071 m.process() 1073 Method procedure to parse and process a response for that method. 1074 Return value is undefined. 1076 m.init() 1078 Method procedure to initialize state just before use. Return 1079 value is undefined. 1081 m.reset() 1083 Method procedure to indicate the method is ending in the middle or 1084 before completion. Return value is undefined. 1086 m.isDone() 1088 Method procedure to check for method completion. Returns a 1089 boolean. 1091 m.getTimeout() 1093 Method procedure to determine an appropriate timeout hint for that 1094 method. Returns an integer. 1096 m.getKey() 1098 Method procedure to obtain key material for use by EAP or lower 1099 layers. Returns an EAP key. 1101 m.buildReq() 1103 Method procedure to produce the next request. Returns an EAP 1104 packet. 1106 5.5. EAP standalone authenticator states 1108 DISABLED 1110 The authenticator is disabled until the port is enabled by the 1111 lower layer. 1113 INITIALIZE 1115 Initializes variables when the state machine is activated. 1117 IDLE 1119 The state machine spends most of its time here, waiting for 1120 something to happen. 1122 RECEIVED 1124 This state is entered when an EAP packet is received: the packet 1125 header is parsed here. 1127 INTEGRITY_CHECK 1129 A method state in which the integrity of the incoming packet from 1130 the peer is verified by the method. 1132 METHOD_RESPONSE 1134 A method state in which the incoming packet is processed. 1136 METHOD_REQUEST 1138 A method state in which a new request is formulated if necessary. 1140 PROPOSE_METHOD 1142 A state in which the authenticator decides which method to try 1143 next in the authentication. 1145 SELECT_ACTION 1147 In between methods, the state machine re-evaluates whether or not 1148 its policy is satisfied and succeeds, fails, or remains undecided. 1150 SEND_REQUEST 1152 This state signals the lower layer that a request packet is ready 1153 to be sent. 1155 DISCARD 1157 This state signals the lower layer that the response was 1158 discarded, and no new request packet will be sent at this time. 1160 NAK 1162 This state processes Nak responses from the peer. 1164 RETRANSMIT 1166 Retransmits the previous request packet. 1168 SUCCESS 1170 A final state indicating success. 1172 FAILURE 1174 A final state indicating failure. 1176 TIMEOUT_FAILURE 1178 A final state indicating failure because no response has been 1179 received. Because no response was received, no new message 1180 (including failure) should be sent to the peer. Note that this is 1181 different from the FAILURE state, where a message indicating 1182 failure is sent to the peer. 1184 6. EAP Backend Authenticator 1186 When operating in pass-through mode, there are conceptually two parts 1187 to the authenticator - the part that passes packets through and the 1188 backend that actually implements the EAP method. The following 1189 diagram shows a state machine for the backend part of this model when 1190 using a AAA server. Note that this diagram is identical to Figure 4 1191 except no retransmit is included in the IDLE state because with 1192 RADIUS retransmit is handled by the NAS, and a PICK_UP_METHOD state 1193 and variable in INITIALIZE state are added to allow the Method to 1194 "pickup" a method started in a NAS. Included is an explanation of 1195 the primitives and procedures referenced in the diagram, many of 1196 which are the same as above. It should be noted that the "lower 1197 layer" in this case is some AAA protocol (e.g., RADIUS). 1199 (see the .pdf version for missing diagram or 1200 refer to Appendix A.3 if reading the .txt version) 1202 Figure 5: EAP Backend Authenticator State Machine 1204 6.1. Interface between backend authenticator state machine and lower 1205 layer 1207 The lower layer presents messages to the EAP backend authenticator 1208 state machine by storing the packet in aaaEapRespData and setting the 1209 aaaEapResp signal to TRUE. 1211 When the EAP backend authenticator state machine has finished 1212 processing the message, it sets one of the signals aaaEapReq, 1213 aaaEapNoReq, aaaSuccess, and aaaFail. If it sets eapReq, eapSuccess, 1214 or eapFail, the corresponding request (or success/failure) packet is 1215 stored in aaaEapReqData. The lower layer is responsible for actually 1216 transmitting this message. 1218 6.1.1. Variables (AAA interface to backend authenticator) 1220 aaaEapResp (boolean) 1222 Set to TRUE in lower layer, FALSE in authenticator state machine. 1223 Usually indicates that an EAP response, stored in aaaEapRespData, 1224 is available for processing by the AAA server. If aaaEapRespData 1225 is set to NONE, indicates that the AAA server should send the 1226 initial EAP request. 1228 aaaEapRespData (EAP packet) 1230 Set in lower layer when eapResp is set to TRUE. The EAP packet to 1231 be processed or NONE. 1233 backendEnabled (boolean) 1235 Indicates that there is a valid link to use for the communication. 1236 If at any point the port is not available, backendEnabled is set 1237 to FALSE and the state machine transitions to DISABLED. 1239 6.1.2. Variables (backend authenticator to AAA interface) 1241 aaaEapReq (boolean) 1243 Set to TRUE in authenticator state machine, FALSE in lower layer. 1244 Indicates a new EAP request is ready to be sent. 1246 aaaEapNoReq (boolean) 1248 Set to TRUE in authenticator state machine, FALSE in lower layer. 1249 Indicates the most recent response has been processed, but there 1250 is no new request to send. 1252 aaaSuccess (boolean) 1254 Set to TRUE in authenticator state machine, FALSE in lower layer. 1255 Indicates the state machine has reached the SUCCESS state. 1257 aaaFail (boolean) 1259 Set to TRUE in authenticator state machine, FALSE in lower layer. 1260 Indicates the state machine has reached the FAILURE state. 1262 aaaEapReqData (EAP packet) 1264 Set in authenticator state machine when aaaEapReq, aaaSuccess, or 1265 aaaFail is set to TRUE. The actual EAP request to be sent (or 1266 success/failure). 1268 aaaEapKeyData (EAP key) 1270 Set in authenticator state machine when keying material becomes 1271 available. Set during the METHOD_RESPONSE state. Note that this 1272 document does not yet define the structure of the type "EAP key". 1273 We expect it to be defined in [Keying]. 1275 aaaEapKeyAvailable (boolean) 1277 Set to TRUE in the SUCCESS state if keying material is available. 1278 The actual key is stored in aaaEapKeyData. 1280 aaaMethodTimeout (integer) 1282 Method-provided hint for suitable retransmission timeout, or NONE 1283 (note that this hint is for the EAP retransmissions done by the 1284 pass-through authenticator, not retransmissions of AAA packets). 1286 6.2. Interface between backend authenticator state machine and methods 1288 The backend method interface is almost the same as in standalone 1289 authenticator described in Section 5.2. The only difference is that 1290 some methods on the backend may support "picking up" a conversation 1291 started by the pass-through. That is, the EAP Request packet was 1292 sent by the pass-through, but the backend must process the 1293 corresponding EAP Response. Usually only the Identity method 1294 supports this, but others are possible. 1296 When "picking up" a conversation, m.initPickUp() is called instead of 1297 m.init(). Next, m.process() must examine eapRespData and update its 1298 own method-specific state to match what it would have been if it had 1300 actually sent the corresponding request. (Obviously, this only works 1301 for methods that can determine what the initial request contained; 1302 Identity and EAP-TLS are good examples.) 1304 After this, the processing continues as described in Section 5.2. 1306 6.3. Backend authenticator state machine local variables 1308 For definitions of the variables used in the Backend Authenticator, 1309 see Section 5.3. 1311 6.4. EAP backend authenticator procedures 1313 Most of the procedures of the backend authenticator have already been 1314 defined in Section 5.4. This section contains definitions for those 1315 not existent in the standalone version, as well as those which are 1316 defined differently. 1318 NOTE: For method procedures, the method uses its internal state in 1319 addition to the information provided by the EAP layer. The only 1320 arguments that are explicitly shown as inputs to the procedures are 1321 those provided to the method by EAP. Those inputs provided by the 1322 method's internal state remain implicit. 1324 Policy.doPickUp() 1326 Notify the policy that an already-chosen method is being picked up 1327 and will be completed. Returns a boolean. 1329 m.initPickUp() 1331 Method procedure to initialize state when continuing from an 1332 already-started method. Return value is undefined. 1334 6.5. EAP backend authenticator states 1336 Most of the states of the backend authenticator have already been 1337 defined in Section 5.5. This section contains definitions for those 1338 not existent in the standalone version, as well as those which are 1339 defined differently. 1341 PICK_UP_METHOD 1343 Set an initial state for a method that is being continued and was 1344 started elsewhere. 1346 7. EAP Full Authenticator 1348 The following two diagrams show the state machine for a complete 1349 authenticator. The first diagram is identical to the Standalone 1350 State Machine, shown in Figure 4, with the exception that the 1351 SELECT_ACTION state has an added transition to PASSTHROUGH. The 1352 second diagram also keeps most of the logic except the four method 1353 states, and shows how the state machine works once it goes to Pass- 1354 Through Mode. 1356 The first diagram is largely a reproduction of that found above, with 1357 the added hooks for a transition to PASSTHROUGH mode. 1359 (see the .pdf version for missing diagram or 1360 refer to Appendix A.4 if reading the .txt version) 1362 Figure 6: EAP Full Authenticator State Machine (Part 1) 1364 The second diagram describes the functionality necessary for an 1365 authenticator operating in pass-through mode. This section of the 1366 diagram is the counterpart of the backend diagram above. 1368 (see the .pdf version for missing diagram or 1369 refer to Appendix A.4 if reading the .txt version) 1371 Figure 7: EAP Full Authenticator State Machine (Part 2) 1373 7.1. Interface between full authenticator state machine and lower 1374 layers 1376 The full authenticator is unique in that it interfaces to multiple 1377 lower layers in order to support pass-through mode. The interface to 1378 the primary EAP transport layer is the same as described in Section 1379 5. The following describes the interface to the second lower layer, 1380 which represents an interface to AAA. It should be noted that there 1381 is not necessarily a direct interaction between the EAP layer and the 1382 AAA layer, as in the case of [1X-REV]. 1384 7.1.1. Variables (AAA interface to full authenticator) 1386 aaaEapReq (boolean) 1388 Set to TRUE in lower layer, FALSE in authenticator state machine. 1389 Indicates a new EAP request is available from the AAA server. 1391 aaaEapNoReq (boolean) 1393 Set to TRUE in lower layer, FALSE in authenticator state machine. 1394 Indicates the most recent response has been processed, but there 1395 is no new request to send. 1397 aaaSuccess (boolean) 1399 Set to TRUE in lower layer. Indicates the AAA backend 1400 authenticator has reached the SUCCESS state. 1402 aaaFail (boolean) 1404 Set to TRUE in lower layer. Indicates the AAA backend 1405 authenticator has reached the FAILURE state. 1407 aaaEapReqData (EAP packet) 1409 Set in the lower layer when aaaEapReq, aaaSuccess, or aaaFail is 1410 set to TRUE. The actual EAP request to be sent (or success/ 1411 failure). 1413 aaaEapKeyData (EAP key) 1415 Set in lower layer when keying material becomes available from the 1416 AAA server. Note that this document does not yet define the 1417 structure of the type "EAP key". We expect it to be defined in 1418 [Keying]. 1420 aaaEapKeyAvailable (boolean) 1422 Set to TRUE in the lower layer if keying material is available. 1423 The actual key is stored in aaaEapKeyData. 1425 aaaMethodTimeout (integer) 1427 Method-provided hint for suitable retransmission timeout, or NONE 1428 (note that this hint is for the EAP retransmissions done by the 1429 pass-through authenticator, not retransmissions of AAA packets). 1431 7.1.2. Variables (full authenticator to AAA interface) 1433 aaaEapResp (boolean) 1435 Set to TRUE in authenticator state machine, FALSE in the lower 1436 layer. Indicates an EAP response is available for processing by 1437 the AAA server. 1439 aaaEapRespData (EAP packet) 1441 Set in authenticator state machine when eapResp is set to TRUE. 1442 The EAP packet to be processed. 1444 aaaIdentity (EAP packet) 1446 Set in authenticator state machine when an IDENTITY response is 1447 received. Makes that identity available to AAA lower layer. 1449 aaaTimeout (boolean) 1451 Set in AAA_IDLE if after a configurable amount of time there is no 1452 response from the AAA layer. The AAA layer in the NAS is itself 1453 alive and OK, but for some reason it has not received a valid 1454 Access-Accept/Reject indication from the backend 1456 7.1.3. Constants 1458 Same as Section 5. 1460 7.2. Interface between full authenticator state machine and methods 1462 Same as standalone authenticator (Section 5.2) 1464 7.3. Full authenticator state machine local variables 1466 Many of the variables of the full authenticator have already been 1467 defined in Section 5. This section contains definitions for those 1468 not existent in the standalone version, as well as those which are 1469 defined differently. 1471 7.3.1. Short-term (not maintained between packets) 1473 decision (enumeration) 1475 Set in SELECT_ACTION state. Temporarily store the policy decision 1476 to succeed, fail, continue with a local method, or continue in 1477 pass-through mode. 1479 7.4. EAP full authenticator procedures 1481 All of the procedures defined in Section 5 exist in the full version. 1482 In addition, the following procedures are defined. 1484 getId() 1486 Determine the identifier value chosen by the AAA server for the 1487 current EAP request. Return value is an integer. 1489 7.5. EAP full authenticator states 1491 All of the states defined in Section 5 exist in the full version. In 1492 addition, the following states are defined. 1494 INITIALIZE_PASSTHROUGH 1496 Initializes variables when the pass-through portion of the state 1497 machine is activated. 1499 IDLE2 1501 The state machine waits for a response from the primary lower 1502 layer, which transports EAP traffic from the peer. 1504 IDLE 1506 The state machine spends most of its time here, waiting for 1507 something to happen. 1509 RECEIVED2 1511 This state is entered when an EAP packet is received and the 1512 authenticator is in PASSTHROUGH mode: the packet header is parsed 1513 here. 1515 AAA_REQUEST 1517 The incoming EAP packet is parsed for sending to the AAA server. 1519 AAA_IDLE 1521 Idle state which tells the AAA layer it has a response and then 1522 waits for a new request, a no-request signal, or success/failure. 1524 AAA_RESPONSE 1526 State in which the request from the AAA interface is processed 1527 into an EAP request. 1529 SEND_REQUEST2 1531 This state signals the lower layer that a request packet is ready 1532 to be sent. 1534 DISCARD2 1536 This state signals the lower layer that the response was 1537 discarded, and no new request packet will be sent at this time. 1539 RETRANSMIT2 1541 Retransmits the previous request packet. 1543 SUCCESS2 1545 A final state indicating success. 1547 FAILURE2 1549 A final state indicating failure. 1551 TIMEOUT_FAILURE2 1553 A final state indicating failure because no response has been 1554 received. Because no response was received, no new message 1555 (including failure) should be sent to the peer. Note that this is 1556 different from the FAILURE2 state, where a message indicating 1557 failure is sent to the peer. 1559 8. Implementation Considerations 1561 8.1. Robustness 1563 In order to deal with erroneous cases that are not directly related 1564 to the protocol behavior, implementations may need additional 1565 considerations to provide robustness against errors. 1567 For example, an implementation of a state machine may spend a 1568 significant amount of time in a particular state for performing the 1569 procedure defined for the state without returning a response. If 1570 such an implementation is made on a multithreading system, the 1571 procedure may be performed in a separate thread so that the 1572 implementation can perform appropriate action to deal with the case 1573 without blocking on the state for a long time (or forever if the 1574 procedure never completes due to, e.g., a non-responding user or a 1575 bug in an application callback function.) 1577 The following states are identified as the possible places of 1578 blocking: 1580 o IDENTITY state in the peer state machine. It may take some time 1581 to process Identity request when a user input is needed for 1582 obtaining an identity from the user. The user may never input an 1583 identity. An implementation may define an additional state 1584 transition from IDENTITY state to FAILURE state so that 1585 authentication can fail if no identity is obtained from the user 1586 before ClientTimeout timer expires. 1588 o METHOD state in the peer state machine and in METHOD_RESPONSE 1589 state in the authenticator state machines. It may take some time 1590 to perform method-specific procedures in these states. An 1591 implementation may define an additional state transition from 1592 METHOD state and METHOD_RESPONSE state to FAILURE or 1593 TIMEOUT_FAILURE state so that authentication can fail if no method 1594 processing result is obtained from the method before methodTimeout 1595 timer expires. 1597 8.2. Method/Method and Method/Lower-Layer Interfaces 1599 Implementations may define additional interfaces to pass method- 1600 specific information between methods and lower layers. These 1601 interfaces are beyond the scope of this document. 1603 8.3. Peer state machine interoperability with deployed implementations 1605 Number of deployed EAP authenticator implementations, mainly in 1606 RADIUS authentication servers, have been observed to incorrectly 1607 increments Identifier field when generating EAP Success and EAP 1608 Failure packets which is against the MUST requirement in RFC 3748 1609 section 4.2. The peer state machine is based on RFC 3748 and as such 1610 it will discard such EAP Success and EAP Failure packets. 1612 As a workaround for the potential interoperability issue with 1613 existing implementations, conditions for peer state machine 1614 transitions from RECEIVED state to SUCCESS and FAILURE states MAY be 1615 changed from "(reqId == lastId)" to "((reqId == lastId) || (reqId == 1616 (lastId + 1) & 255))". However, since this behavior does not conform 1617 to RFC 3748, such a workaround is not recommended and if included, it 1618 should be implemented as an optional workaround that can be disabled. 1620 9. Security Considerations 1622 This document's intent is to describe the EAP state machine fully. 1623 To this end, any security concerns with this document are likely a 1624 reflection of security concerns with EAP itself. 1626 An accurate state machine can help reduce implementation errors. 1627 While [RFC3748] remains the normative protocol description, this 1628 state machine should help in this regard. 1630 As noted in [RFC3748], there are some security concerns that arise 1631 because of the following EAP packets: 1633 1. EAP-Request/Response Identity 1634 2. EAP-Response/NAK 1635 3. EAP-Success/Failure 1637 Since these packets are not cryptographically protected by 1638 themselves, an attacker can modify or insert them without immediate 1639 detection by the peer or authenticator. 1641 Following Figure 3 specification, an attacker may cause denial of 1642 service by: 1644 o Sending an EAP-Failure to the peer before the peer has started an 1645 EAP authentication method. As long as the peer has not modified 1646 the methodState variable (initialized to NONE), the peer MUST 1647 accept an EAP-Failure. 1649 o Forcing the peer to engage in endless EAP-Request/Response 1650 Identity exchanges before it has started an EAP authentication 1651 method. As long as the peer has not modified the selectedMethod 1652 variable (initialized to NONE), the peer MUST accept an EAP- 1653 Request/Identity and respond to it with an EAP-Response/ Identity. 1655 Following Figure 4 specification, an attacker may cause denial of 1656 service by: 1658 o Sending a NAK to the authenticator after the authenticator first 1659 proposes an EAP authentication method to the peer. When the 1660 methodState variable has the value PROPOSED, the authenticator is 1661 obliged to process a NAK that is received in response to its first 1662 packet of an EAP authentication method. 1664 There MAY be some cases when it is desired to prevent such attacks. 1665 This can be done by modifying initial values of some variables of the 1666 EAP state machines. However, such modifications are NOT RECOMMENDED. 1668 There is a trade-off between mitigating these denial of service 1669 attacks and being able to deal with EAP peers and authenticators in 1670 general. For instance, should the sending of a NAK to the 1671 authenticator after it has just proposed an EAP authentication method 1672 to the peer be ignored, then a legitimate peer that is not able or 1673 willing to process the proposed EAP authentication method would fail 1674 without an opportunity to negotiate another EAP method. 1676 10. Acknowledgments 1678 The work in this document was done as part of the EAP Design Team. 1679 It was done primarily by Nick Petroni, John Vollbrecht, Pasi Eronen 1680 and Yoshihiro Ohba. Nick started this work with Bryan Payne and Chuk 1681 Seng at the University of Maryland. John Vollbrecht, of Vollbrecht 1682 Consulting, started independently with help from Dave Spence at 1683 Interlink Networks. John and Nick combined to create a common 1684 document, and then were joined by Pasi Eronen of Nokia who has made 1685 major contributions in creating coherent state machines, and 1686 Yoshihiro Ohba of Toshiba who insisted on including Pass-Through 1687 documentation and provided significant support for understanding 1688 implementation issues. 1690 In addition significant response and conversation has come from the 1691 design team, especially including Jari Arkko of Ericsson and Bernard 1692 Aboba of Microsoft as well as the rest of the team. It has also been 1693 passed through the 802.1aa group, and has had input from Jim Burns of 1694 Meetinghouse and Paul Congdon of Hewlett Packard. 1696 11. References 1698 11.1. Normative References 1700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1701 Requirement Levels", BCP 14, RFC 2119, March 1997. 1703 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1704 Dial In User Service) Support For Extensible 1705 Authentication Protocol (EAP)", RFC 3579, September 2003. 1707 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1708 Levkowetz, Ed., "Extensible Authentication Protocol 1709 (EAP)", RFC 3748, June 2004. 1711 11.2. Informative References 1713 [Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., Levkowetz, 1714 H., "Extensible Authentication Protocol (EAP) Key 1715 Management Framework", Work in Progress, July 2004. 1717 [1X-REV] Institute of Electrical and Electronics Engineers, "DRAFT 1718 Standard for Local and Metropolitan Area Networks: Port- 1719 Based Network Access Control (Revision)", IEEE 802-1X- 1720 REV/D11, July 2004. 1722 Appendix A. ASCII versions of state diagrams 1724 This appendix contains the state diagrams in ASCII format. Please 1725 use the PDF version whenever possible: it is much easier to 1726 understand. 1728 The notation is as follows: state name and pseudocode executed when 1729 entering it are shown on the left; outgoing transitions with their 1730 conditions are shown on the right. 1732 A.1. EAP Peer State Machine (Figure 3) 1734 --------------------------------------------------------------------- 1735 (global transitions) | !portEnabled | DISABLED 1736 |------------------------+-------------- 1737 | eapRestart && | INITIALIZE 1738 | portEnabled | 1739 -----------------------------+------------------------+-------------- 1740 DISABLED | portEnabled | INITIALIZE 1741 -----------------------------+------------------------+-------------- 1742 INITIALIZE | | 1743 | | 1744 selectedMethod = NONE | | 1745 methodState = NONE | | 1746 allowNotifications = TRUE | | 1747 decision = FAIL | UCT | IDLE 1748 idleWhile = ClientTimeout | | 1749 lastId = NONE | | 1750 eapSuccess = FALSE | | 1751 eapFail = FALSE | | 1752 eapKeyData = NONE | | 1753 eapKeyAvailable = FALSE | | 1754 eapRestart = FALSE | | 1755 -----------------------------+------------------------+-------------- 1756 IDLE | eapReq | RECEIVED 1757 |------------------------+-------------- 1758 | (altAccept && | 1759 | decision != FAIL) || | 1760 | (idleWhile == 0 && | SUCCESS 1761 | decision == | 1762 | UNCOND_SUCC) | 1763 |------------------------+-------------- 1764 |------------------------+-------------- 1765 | altReject || | 1766 | (idleWhile == 0 && | 1767 | decision != | 1768 | UNCOND_SUCC) || | FAILURE 1769 | (altAccept && | 1770 | methodState != CONT && | 1771 | decision == FAIL) | 1772 -----------------------------+------------------------+-------------- 1773 RECEIVED | rxReq && | METHOD 1774 | (reqId != lastId) && | 1775 (rxReq,rxSuccess,rxFailure, | (reqMethod == | 1776 reqId,reqMethod) = | selectedMethod) && | 1777 parseEapReq(eapReqData) | (methodState != DONE) | 1778 |------------------------+-------------- 1779 | rxReq && | 1780 | (reqId != lastId) && | 1781 | (selectedMethod == | 1782 | NONE) && | GET_METHOD 1783 | (reqMethod != | 1784 | IDENTITY) && | 1785 | (reqMethod != | 1786 | NOTIFICATION) | 1787 |------------------------+-------------- 1788 | rxReq && | 1789 | (reqId != lastId) && | 1790 | (selectedMethod == | IDENTITY 1791 | NONE) && | 1792 | (reqMethod == | 1793 | IDENTITY) | 1794 |------------------------+-------------- 1795 | rxReq && | 1796 | (reqId != lastId) && | 1797 | (reqMethod == | NOTIFICATION 1798 | NOTIFICATION) && | 1799 | allowNotifications | 1800 |------------------------+-------------- 1801 | rxReq && | RETRANSMIT 1802 | (reqId == lastId) | 1803 |------------------------+-------------- 1804 | rxSuccess && | 1805 | (reqId == lastId) && | SUCCESS 1806 | (decision != FAIL) | 1807 |------------------------+-------------- 1808 |------------------------+-------------- 1809 | (methodState!=CONT) && | 1810 | ((rxFailure && | 1811 | decision != | 1812 | UNCOND_SUCC) || | FAILURE 1813 | (rxSuccess && | 1814 | decision == FAIL)) && | 1815 | (reqId == lastId) | 1816 |------------------------+-------------- 1817 | else | DISCARD 1818 -----------------------------+------------------------+-------------- 1819 METHOD | | 1820 | | 1821 ignore = m.check(eapReqData) | ignore | DISCARD 1822 if (!ignore) { | | 1823 (methodState, decision, | | 1824 allowNotifications) = |------------------------+-------------- 1825 m.process(eapReqData) | | 1826 /* methodState is CONT, | | 1827 MAY_CONT, or DONE */ | (methodState==DONE) && | FAILURE 1828 /* decision is FAIL, | (decision == FAIL) | 1829 COND_SUCC, or | | 1830 UNCOND_SUCC */ | | 1831 eapRespData = |------------------------+-------------- 1832 m.buildResp(reqId) | | 1833 if (m.isKeyAvailable()) | else | SEND_RESPONSE 1834 eapKeyData = m.getKey() | | 1835 } | | 1836 -----------------------------+------------------------+-------------- 1837 GET_METHOD | | 1838 | selectedMethod == | 1839 if (allowMethod(reqMethod)) {| reqMethod | METHOD 1840 selectedMethod = reqMethod | | 1841 methodState = INIT | | 1842 } else { |------------------------+-------------- 1843 eapRespData = | | 1844 buildNak(reqId) | else | SEND_RESPONSE 1845 } | | 1846 -----------------------------+------------------------+-------------- 1847 IDENTITY | | 1848 | | 1849 processIdentity(eapReqData) | UCT | SEND_RESPONSE 1850 eapRespData = | | 1851 buildIdentity(reqId) | | 1852 -----------------------------+------------------------+-------------- 1853 -----------------------------+------------------------+-------------- 1854 NOTIFICATION | | 1855 | | 1856 processNotify(eapReqData) | UCT | SEND_RESPONSE 1857 eapRespData = | | 1858 buildNotify(reqId) | | 1859 -----------------------------+------------------------+-------------- 1860 RETRANSMIT | | 1861 | UCT | SEND_RESPONSE 1862 eapRespData = lastRespData | | 1863 -----------------------------+------------------------+-------------- 1864 DISCARD | | 1865 | UCT | IDLE 1866 eapReq = FALSE | | 1867 eapNoResp = TRUE | | 1868 -----------------------------+------------------------+-------------- 1869 SEND_RESPONSE | | 1870 | | 1871 lastId = reqId | | 1872 lastRespData = eapRespData | UCT | IDLE 1873 eapReq = FALSE | | 1874 eapResp = TRUE | | 1875 idleWhile = ClientTimeout | | 1876 -----------------------------+------------------------+-------------- 1877 SUCCESS | | 1878 | | 1879 if (eapKeyData != NONE) | | 1880 eapKeyAvailable = TRUE | | 1881 eapSuccess = TRUE | | 1882 -----------------------------+------------------------+-------------- 1883 FAILURE | | 1884 | | 1885 eapFail = TRUE | | 1886 --------------------------------------------------------------------- 1887 Figure 8 1889 A.2. EAP Standalone Authenticator State Machine (Figure 4) 1891 --------------------------------------------------------------------- 1892 (global transitions) | !portEnabled | DISABLED 1893 |---------------------+---------------- 1894 | eapRestart && | INITIALIZE 1895 | portEnabled | 1896 ------------------------------+---------------------+---------------- 1897 DISABLED | portEnabled | INITIALIZE 1898 ------------------------------+---------------------+---------------- 1899 ------------------------------+---------------------+---------------- 1900 INITIALIZE | | 1901 | | 1902 currentId = NONE | | 1903 eapSuccess = FALSE | | 1904 eapFail = FALSE | UCT | SELECT_ACTION 1905 eapTimeout = FALSE | | 1906 eapKeyData = NONE | | 1907 eapKeyAvailable = FALSE | | 1908 eapRestart = FALSE | | 1909 ------------------------------+---------------------+---------------- 1910 IDLE | | 1911 | retransWhile == 0 | RETRANSMIT 1912 retransWhile = | | 1913 calculateTimeout( |---------------------+---------------- 1914 retransCount, eapSRTT, | eapResp | RECEIVED 1915 eapRTTVAR, methodTimeout) | | 1916 ------------------------------+---------------------+---------------- 1917 RETRANSMIT | | 1918 | retransCount > | TIMEOUT_FAILURE 1919 retransCount++ | MaxRetrans | 1920 if (retransCount<=MaxRetrans){| | 1921 eapReqData = lastReqData |---------------------+---------------- 1922 eapReq = TRUE | else | IDLE 1923 } | | 1924 ------------------------------+---------------------+---------------- 1925 RECEIVED | rxResp && | 1926 | (respId == | 1927 (rxResp,respId,respMethod)= | currentId) && | 1928 parseEapResp(eapRespData) | (respMethod == NAK | 1929 | || | NAK 1930 | respMethod == | 1931 | EXPANDED_NAK) && | 1932 | (methodState == | 1933 | PROPOSED) | 1934 |---------------------+---------------- 1935 | rxResp && | 1936 | (respId == | 1937 | currentId) && | INTEGRITY_CHECK 1938 | (respMethod == | 1939 | currentMethod) | 1940 |---------------------+---------------- 1941 | else | DISCARD 1942 ------------------------------+---------------------+---------------- 1943 ------------------------------+---------------------+---------------- 1944 NAK | | 1945 | UCT | SELECT_ACTION 1946 m.reset() | | 1947 Policy.update(<...>) | | 1948 ------------------------------+---------------------+---------------- 1949 SELECT_ACTION | decision == FAILURE | FAILURE 1950 | | 1951 decision = |---------------------+---------------- 1952 Policy.getDecision() | decision == SUCCESS | SUCCESS 1953 /* SUCCESS, FAILURE, or |---------------------+---------------- 1954 CONTINUE */ | else | PROPOSE_METHOD 1955 ------------------------------+---------------------+---------------- 1956 INTEGRITY_CHECK | ignore | DISCARD 1957 |---------------------+---------------- 1958 ignore = m.check(eapRespData) | !ignore | METHOD_RESPONSE 1959 ------------------------------+---------------------+---------------- 1960 METHOD_RESPONSE | | 1961 | methodState == END | SELECT_ACTION 1962 m.process(eapRespData) | | 1963 if (m.isDone()) { | | 1964 Policy.update(<...>) |---------------------+---------------- 1965 eapKeyData = m.getKey() | | 1966 methodState = END | else | METHOD_REQUEST 1967 } else | | 1968 methodState = CONTINUE | | 1969 ------------------------------+---------------------+---------------- 1970 PROPOSE_METHOD | | 1971 | | 1972 currentMethod = | | 1973 Policy.getNextMethod() | | 1974 m.init() | UCT | METHOD_REQUEST 1975 if (currentMethod==IDENTITY ||| | 1976 currentMethod==NOTIFICATION)| | 1977 methodState = CONTINUE | | 1978 else | | 1979 methodState = PROPOSED | | 1980 ------------------------------+---------------------+---------------- 1981 METHOD_REQUEST | | 1982 | | 1983 currentId = nextId(currentId) | UCT | SEND_REQUEST 1984 eapReqData = | | 1985 m.buildReq(currentId) | | 1986 methodTimeout = m.getTimeout()| | 1987 ------------------------------+---------------------+---------------- 1988 ------------------------------+---------------------+---------------- 1989 DISCARD | | 1990 | UCT | IDLE 1991 eapResp = FALSE | | 1992 eapNoReq = TRUE | | 1993 ------------------------------+---------------------+---------------- 1994 SEND_REQUEST | | 1995 | | 1996 retransCount = 0 | UCT | IDLE 1997 lastReqData = eapReqData | | 1998 eapResp = FALSE | | 1999 eapReq = TRUE | | 2000 ------------------------------+---------------------+---------------- 2001 TIMEOUT_FAILURE | | 2002 | | 2003 eapTimeout = TRUE | | 2004 ------------------------------+---------------------+---------------- 2005 FAILURE | | 2006 | | 2007 eapReqData = | | 2008 buildFailure(currentId) | | 2009 eapFail = TRUE | | 2010 ------------------------------+---------------------+---------------- 2011 SUCCESS | | 2012 | | 2013 eapReqData = | | 2014 buildSuccess(currentId) | | 2015 if (eapKeyData != NONE) | | 2016 eapKeyAvailable = TRUE | | 2017 eapSuccess = TRUE | | 2018 --------------------------------------------------------------------- 2019 Figure 9 2021 A.3. EAP Backend Authenticator State Machine (Figure 5) 2023 --------------------------------------------------------------------- 2024 (global transitions) | !backendEnabled | DISABLED 2025 ------------------------------+---------------------+---------------- 2026 DISABLED | backendEnabled && | INITIALIZE 2027 | aaaEapResp | 2028 ------------------------------+---------------------+---------------- 2029 ------------------------------+---------------------+---------------- 2030 INITIALIZE | !rxResp | SELECT_ACTION 2031 |---------------------+---------------- 2032 currentMethod = NONE | rxResp && | 2033 (rxResp,respId,respMethod)= | (respMethod == NAK | 2034 parseEapResp(aaaEapRespData)| || | NAK 2035 if (rxResp) | respMethod == | 2036 currentId = respId | EXPANDED_NAK) | 2037 else |---------------------+---------------- 2038 currentId = NONE | else | PICK_UP_METHOD 2039 ------------------------------+---------------------+---------------- 2040 PICK_UP_METHOD | | 2041 | currentMethod == | SELECT_ACTION 2042 if (Policy.doPickUp( | NONE | 2043 respMethod)) { | | 2044 currentMethod = respMethod |---------------------+---------------- 2045 m.initPickUp() | else | METHOD_RESPONSE 2046 } | | 2047 ------------------------------+---------------------+---------------- 2048 IDLE | aaaEapResp | RECEIVED 2049 ------------------------------+---------------------+---------------- 2050 RECEIVED | rxResp && | 2051 | (respId == | 2052 (rxResp,respId,respMethod)= | currentId) && | 2053 parseEapResp(aaaEapRespData)| (respMethod == NAK | 2054 | || | NAK 2055 | respMethod == | 2056 | EXPANDED_NAK) && | 2057 | (methodState == | 2058 | PROPOSED) | 2059 |---------------------+---------------- 2060 | rxResp && | 2061 | (respId == | 2062 | currentId) && | INTEGRITY_CHECK 2063 | (respMethod == | 2064 | currentMethod) | 2065 |---------------------+---------------- 2066 | else | DISCARD 2067 ------------------------------+---------------------+---------------- 2068 NAK | | 2069 | UCT | SELECT_ACTION 2070 m.reset() | | 2071 Policy.update(<...>) | | 2072 ------------------------------+---------------------+---------------- 2073 ------------------------------+---------------------+---------------- 2074 SELECT_ACTION | decision == FAILURE | FAILURE 2075 | | 2076 decision = |---------------------+---------------- 2077 Policy.getDecision() | decision == SUCCESS | SUCCESS 2078 /* SUCCESS, FAILURE, or |---------------------+---------------- 2079 CONTINUE */ | else | PROPOSE_METHOD 2080 ------------------------------+---------------------+---------------- 2081 INTEGRITY_CHECK | ignore | DISCARD 2082 | | 2083 ignore = |---------------------+---------------- 2084 m.check(aaaEapRespData) | !ignore | METHOD_RESPONSE 2085 ------------------------------+---------------------+---------------- 2086 METHOD_RESPONSE | | 2087 | methodState == END | SELECT_ACTION 2088 m.process(aaaEapRespData) | | 2089 if (m.isDone()) { | | 2090 Policy.update(<...>) |---------------------+---------------- 2091 aaaEapKeyData = m.getKey() | | 2092 methodState = END | else | METHOD_REQUEST 2093 } else | | 2094 methodState = CONTINUE | | 2095 ------------------------------+---------------------+---------------- 2096 PROPOSE_METHOD | | 2097 | | 2098 currentMethod = | | 2099 Policy.getNextMethod() | | 2100 m.init() | UCT | METHOD_REQUEST 2101 if (currentMethod==IDENTITY ||| | 2102 currentMethod==NOTIFICATION)| | 2103 methodState = CONTINUE | | 2104 else | | 2105 methodState = PROPOSED | | 2106 ------------------------------+---------------------+---------------- 2107 METHOD_REQUEST | | 2108 | | 2109 currentId = nextId(currentId) | | 2110 aaaEapReqData = | UCT | SEND_REQUEST 2111 m.buildReq(currentId) | | 2112 aaaMethodTimeout = | | 2113 m.getTimeout() | | 2114 ------------------------------+---------------------+---------------- 2115 DISCARD | | 2116 | UCT | IDLE 2117 aaaEapResp = FALSE | | 2118 aaaEapNoReq = TRUE | | 2119 ------------------------------+---------------------+---------------- 2120 ------------------------------+---------------------+---------------- 2121 SEND_REQUEST | | 2122 | UCT | IDLE 2123 aaaEapResp = FALSE | | 2124 aaaEapReq = TRUE | | 2125 ------------------------------+---------------------+---------------- 2126 FAILURE | | 2127 | | 2128 aaaEapReqData = | | 2129 buildFailure(currentId) | | 2130 aaaEapFail = TRUE | | 2131 ------------------------------+---------------------+---------------- 2132 SUCCESS | | 2133 | | 2134 aaaEapReqData = | | 2135 buildSuccess(currentId) | | 2136 if (aaaEapKeyData != NONE) | | 2137 aaaEapKeyAvailable = TRUE | | 2138 aaaEapSuccess = TRUE | | 2139 --------------------------------------------------------------------- 2140 Figure 10 2142 A.4. EAP Full Authenticator State Machine (Figures 6 and 7) 2144 This state machine contains all the states from EAP Standalone 2145 Authenticator State Machine, except that SELECT_ACTION state is 2146 replaced with the following: 2148 --------------------------------------------------------------------- 2149 SELECT_ACTION | decision == FAILURE | FAILURE 2150 | | 2151 decision = |---------------------+---------------- 2152 Policy.getDecision() | decision == SUCCESS | SUCCESS 2153 /* SUCCESS, FAILURE, CONTINUE,|---------------------+---------------- 2154 or PASSTHROUGH */ | decision == | INITIALIZE_ 2155 | PASSTHROUGH | PASSTHROUGH 2156 |---------------------+---------------- 2157 | else | PROPOSE_METHOD 2158 --------------------------------------------------------------------- 2159 Figure 11 2161 And the following new states are added: 2163 --------------------------------------------------------------------- 2164 INITIALIZE_PASSTHROUGH | currentId != NONE | AAA_REQUEST 2165 |---------------------+---------------- 2166 aaaEapRespData = NONE | currentId == NONE | AAA_IDLE 2167 ------------------------------+---------------------+---------------- 2168 ------------------------------+---------------------+---------------- 2169 IDLE2 | | 2170 | retransWhile == 0 | RETRANSMIT2 2171 retransWhile = | | 2172 calculateTimeout( |---------------------+---------------- 2173 retransCount, eapSRTT, | eapResp | RECEIVED2 2174 eapRTTVAR, methodTimeout) | | 2175 ------------------------------+---------------------+---------------- 2176 RETRANSMIT2 | | 2177 | retransCount > | TIMEOUT_ 2178 retransCount++ | MaxRetrans | FAILURE2 2179 if (retransCount<=MaxRetrans){| | 2180 eapReqData = lastReqData |---------------------+---------------- 2181 eapReq = TRUE | else | IDLE2 2182 } | | 2183 ------------------------------+---------------------+---------------- 2184 RECEIVED2 | rxResp && | 2185 | (respId == | AAA_REQUEST 2186 (rxResp,respId,respMethod)= | currentId) | 2187 parseEapResp(eapRespData) |---------------------+---------------- 2188 | else | DISCARD2 2189 ------------------------------+---------------------+---------------- 2190 AAA_REQUEST | | 2191 | | 2192 if (respMethod == IDENTITY) { | UCT | AAA_IDLE 2193 aaaIdentity = eapRespData | | 2194 aaaEapRespData = eapRespData | | 2195 ------------------------------+---------------------+---------------- 2196 AAA_IDLE | aaaEapNoReq | DISCARD2 2197 |---------------------+---------------- 2198 aaaFail = FALSE | aaaEapReq | AAA_RESPONSE 2199 aaaSuccess = FALSE |---------------------+---------------- 2200 aaaEapReq = FALSE | aaaTimeout | TIMEOUT_ 2201 aaaEapNoReq = FALSE | | FAILURE2 2202 aaaEapResp = TRUE |---------------------+---------------- 2203 | aaaFail | FAILURE2 2204 |---------------------+---------------- 2205 | aaaSuccess | SUCCESS2 2206 ------------------------------+---------------------+---------------- 2207 AAA_RESPONSE | | 2208 | | 2209 eapReqData = aaaEapReqData | UCT | SEND_REQUEST2 2210 currentId = getId(eapReqData) | | 2211 methodTimeout = | | 2212 aaaMethodTimeout | | 2213 ------------------------------+---------------------+---------------- 2214 ------------------------------+---------------------+---------------- 2215 DISCARD2 | | 2216 | UCT | IDLE2 2217 eapResp = FALSE | | 2218 eapNoReq = TRUE | | 2219 ------------------------------+---------------------+---------------- 2220 SEND_REQUEST2 | | 2221 | | 2222 retransCount = 0 | UCT | IDLE2 2223 lastReqData = eapReqData | | 2224 eapResp = FALSE | | 2225 eapReq = TRUE | | 2226 ------------------------------+---------------------+---------------- 2227 TIMEOUT_FAILURE2 | | 2228 | | 2229 eapTimeout = TRUE | | 2230 ------------------------------+---------------------+---------------- 2231 FAILURE2 | | 2232 | | 2233 eapReqData = aaaEapReqData | | 2234 eapFail = TRUE | | 2235 ------------------------------+---------------------+---------------- 2236 SUCCESS2 | | 2237 | | 2238 eapReqData = aaaEapReqData | | 2239 eapKeyData = aaaEapKeyData | | 2240 eapKeyAvailable = | | 2241 aaaEapKeyAvailable | | 2242 eapSuccess = TRUE | | 2243 --------------------------------------------------------------------- 2244 Figure 12 2246 Authors' Addresses 2248 John R. Vollbrecht 2249 Vollbrecht Consulting LLC 2250 9682 Alice Hill Drive 2251 Dexter, MI 48130 2252 USA 2254 EMail: jrv@umich.edu 2256 Pasi Eronen 2257 Nokia Research Center 2258 P.O. Box 407 2259 FIN-00045 Nokia Group, 2260 Finland 2262 EMail: pasi.eronen@nokia.com 2264 Nick L. Petroni, Jr. 2265 University of Maryland, College Park 2266 A.V. Williams Building 2267 College Park, MD 20742 2268 USA 2270 EMail: npetroni@cs.umd.edu 2272 Yoshihiro Ohba 2273 Toshiba America Research, Inc. 2274 1 Telcordia Drive 2275 Piscataway, NJ 08854 2276 USA 2278 EMail: yohba@tari.toshiba.com 2280 Full Copyright Statement 2282 Copyright (C) The Internet Society (2004). This document is subject 2283 to the rights, licenses and restrictions contained in BCP 78, and 2284 except as set forth therein, the authors retain all their rights. 2286 This document and the information contained herein are provided on an 2287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2289 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2290 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2291 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2294 Intellectual Property 2296 The IETF takes no position regarding the validity or scope of any 2297 Intellectual Property Rights or other rights that might be claimed to 2298 pertain to the implementation or use of the technology described in 2299 this document or the extent to which any license under such rights 2300 might or might not be available; nor does it represent that it has 2301 made any independent effort to identify any such rights. Information 2302 on the procedures with respect to rights in RFC documents can be 2303 found in BCP 78 and BCP 79. 2305 Copies of IPR disclosures made to the IETF Secretariat and any 2306 assurances of licenses to be made available, or the result of an 2307 attempt made to obtain a general license or permission for the use of 2308 such proprietary rights by implementers or users of this 2309 specification can be obtained from the IETF on-line IPR repository at 2310 http://www.ietf.org/ipr. 2312 The IETF invites any interested party to bring to its attention any 2313 copyrights, patents or patent applications, or other proprietary 2314 rights that may cover technology that may be required to implement 2315 this standard. Please address the information to the IETF at 2316 ietf-ipr@ietf.org. 2318 Acknowledgement 2320 Funding for the RFC Editor function is currently provided by the 2321 Internet Society.