EAP STATE Machine Proposal John Vollbrecht Nick Petroni

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

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

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

Link Link EAP Switch EAP Switch EAP Method EAP Method EAP Method EAP Method

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

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).

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

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

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)

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

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.

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

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

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