EAP STATE Machine Proposal

1. EAP STATE Machine Proposal John Vollbrecht Nick Petroni

2. What is being proposed • Work in progress - being worked on by ietf EAP dessign group • Principals are Nick Petroni and John Vollbrecht • Format is same as 802.1x state machines • Some work is translated from other forms • Still significant work to be done • Want feedback on this from 802.1x and others • Want to coordinate with 802.1x

3. Issues with EAP and EAP methods • No published IETF State machine • IETF deals with “protocols” - not API to methods • EAP design group working on cleaning up EAP RFC, also looking at producing an EAP State Machine • EAP State Machine is based on an EAP Switch Model • Experience with 802.11 has shown issues with • Retransmissions • DOS Attacks with random transmissions • Seems useful to coordinate 802.1x state machine and EAP state machine

4. EAP Switch Model • EAP Methods are negotiated by EAP Switch • EAP Switch has a “policy” that supports sequences of Methods • Methods may require a sequence of EAP message exchanges • EAP switches talk over a pre-established one to one path setup by the underlying application. This path is not required to be “secure”. • The negotiation method is • Authenticator Sends a request for method=x • Peer can accept and Reply to method=x • Or - can NAK method=x and indicate its preferred method

5. Link Link EAP Switch EAP Switch EAP Method EAP Method EAP Method EAP Method

6. EAP Switch -(2) • Authenticator can try any sequence of methods and peer can refuse or accept each. • If a method is accepted by the peer and “fails” the sequence “SHOULD” be terminated with failure by the authenticator • This implies that cannot try one authentication method and if it fails try another. • This does allow each side to agree on a method or methods they believe should succeed if access is to be allowed

7. Role of EAP Identity • In much of 802.1x and RADIUS extensions it is assumed that an identity Request will be initiated by an Edge Device and used to determine what credentials are required • This assumption is challenged by several EAP methods which do not send id or credentials in the clear. TLS and SRP and some Kerberos proposals are examples. • It might be good in 802.1x to allow the supplicant to send an EAP Request as the initial message • There are plans in AAA wg to allow initial AAA (RADIUS or Diameter) request to include an EAP Request, thus allowing the Client to be the EAP method initiator (I.e. the authenticator).

8. EAP and 802.1x • EAP is multi-directional • EAP does requires Success/Failure between AS and supplicant but also uses EAP Success/failure to signal between Supplicant and Authenticator • RADIUS doesn’t have a good way to deal with EAP mutual authentication initiated by supplicant • 802.1x assumes a “secure connection” - but 802.11 doesn’t seem to have that • 802.1x auth state machine doesn’t deal with how to deal with multiple method sequences

9. proposal • Create an “EAP Switch” state machine which has a defined interface with • Application requesting authentication (e.g. 802.1x port authentication) • EAP Methods • What is presented is a start at defining that • EAP Switch State Machine for authenticator and peer • Variables and parameters defining interfaces between switch and application and switch and EAP methods • Allows applications to call EAP authentication without regard to EAP exchanges • For 802.1x this means EAP start/logoff/signal are control between supplicant and authenticator • Allows methods to be written without regard to underlying application or for other methods in sequence

10. DOS attacks • EAP over non secure media is vulnerable to DOS attacks • EAPOL - logoff • EAP Failure • Random EAP messages with valid id for application • Man in middle attacks on methods vulnerable to them • Other ?? (good to document as many as possible)

11. Retransmission • EAP is a half duplex protocol • Authenticator sends Request with an ID • Peer sends Response with same ID • If Authenticator does not get response in specified time frame, it resends the identical Request • If Peer gets a duplicate Request after sending a Response, it resends the Response • If Peer gets a Request it does not understand or does not expect it silently discards the Request and does not Reply • If Authenticator gets a Response it does not understand or does not expect it silently discards the Response and behaves as if no Response had been received. • If the Peer gets a request while processing a different Request it finishes processing the current request before processing the next. Implementations SHOULD allow such queuing. • Peer “MAY” discard queued requests when sending a Request

12. Unexpected and not understood • Unexpected requests and responses can detected by the EAP Switch. Examples • Resp with incorrect ID • Request with “old” ID • Req/Resp with syntactic errors • Not understood requests are found by methods and are method specific checks • Method must indicate to Switch that message failed an integrity check.

13. METHOD intCheck = doIntegrityCheck() if (intCheck) { buildMethodResp(currentId) methodState = {CONT | CON_SUCC | SUCC | FAIL } } ACTIVE INITIALIZE txMethodResp(currentId) clearMethodReqQueue() METHOD INIT methodState = SUCC discCount = 0 DIALOG allowMethod = Policy.allow(currentMethod) if (allowMethod) { methodState = INIT } else timeout = FALSE rxNotify = FALSE rxMethodReq = FALSE rxSuccess = FALSE rxFailure = FALSE DISCARD UCT increment(discCount) SUCCESS NAK FAILURE return(SUCCESS) txNak(currentMethod) return(FAILURE) EAP Peer State Diagram Vollbrecht, Petroni 2003 allowMethod || currentMethod == 1 rxMethodReq && methodState == CONT !intCheck intCheck rxMethodReq && {methodState == SUCC || methodState == CON_SUCC} UCT !allowMethod && currentMethod != 1 (Identity) UCT UCT successCondition failureCondition successCondition = Policy.isSatisfied() && {{rxSuccess && methodState == CON_SUCC } || {rxSuccess && methodState == SUCC } || {timeout && methodState == CON_SUCC}} failureCondition = { rxFailure && methodState == FAIL } || { rxFailure && methodState == SUCC} || { timeout && methodState != CON_SUCC }

14. UCT ACTIVE currentId++ retransCount = 1 txMethodReq(currentId) clearMethodRespQueue() METHOD intCheck = doIntegrityCheck() if (intCheck) { buildMethodReq(currentId) methodState = { CONT | CON_SUCC | FAIL | SUCC | FIRST } } SUCCESS txSuccess() return(SUCCESS) DISCARD NAK increment(discCount) resetMethod(currentMethod) DIALOG RETRANSMIT FAILURE txMethodReq(currentId) retransCount++ rxMethodResp = FALSE rxNak = FALSE timeout = FALSE txFailure() return(FAILURE) EAP Authenticator State Diagram Vollbrecht, Petroni 2003 INITIALIZE discCount = 0 currentId = InitialId GET METHOD policySat = Policy.isSatisfied() if (!policySat) { currentMethod = Policy.getNextMeth() methodState = INIT } !policySat && currentMethod = NONE policySat else intCheck && { methodState == SUCC || methodState == CON_SUCC} UCT methodState == FAIL retransCount > MaxRetrans else intCheck && { methodState == CONT || methodState == FIRST} rxMethodResp rxNak && methodState == FIRST UCT timeout else else UCT

15. Future work • EAP State machine for AP • API for EAP Methods - as help for Method creators/implementors • API to interface - for access to 802.1x and other applications • (where should this work be done?) • Possible “PANA” interface • State machine for “inbedded” methods