Presentation on theme: "EAP STATE Machine Proposal"— Presentation transcript:
1EAP STATE Machine Proposal John VollbrechtNick Petroni
2What is being proposedWork in progress - being worked on by ietf EAP dessign groupPrincipals are Nick Petroni and John VollbrechtFormat is same as 802.1x state machinesSome work is translated from other formsStill significant work to be doneWant feedback on this from 802.1x and othersWant to coordinate with 802.1x
3Issues with EAP and EAP methods No published IETF State machineIETF deals with “protocols” - not API to methodsEAP design group working on cleaning up EAP RFC, also looking at producing an EAP State MachineEAP State Machine is based on an EAP Switch ModelExperience with has shown issues withRetransmissionsDOS Attacks with random transmissionsSeems useful to coordinate 802.1x state machine and EAP state machine
4EAP Switch Model EAP Methods are negotiated by EAP Switch EAP Switch has a “policy” that supports sequences of MethodsMethods may require a sequence of EAP message exchangesEAP 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 isAuthenticator Sends a request for method=xPeer can accept and Reply to method=xOr - can NAK method=x and indicate its preferred method
6EAP 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 authenticatorThis 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
7Role of EAP IdentityIn 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 requiredThis 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 messageThere 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).
8EAP 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 AuthenticatorRADIUS doesn’t have a good way to deal with EAP mutual authentication initiated by supplicant802.1x assumes a “secure connection” - but doesn’t seem to have that802.1x auth state machine doesn’t deal with how to deal with multiple method sequences
9proposalCreate an “EAP Switch” state machine which has a defined interface withApplication requesting authentication (e.g x port authentication)EAP MethodsWhat is presented is a start at defining thatEAP Switch State Machine for authenticator and peerVariables and parameters defining interfaces between switch and application and switch and EAP methodsAllows applications to call EAP authentication without regard to EAP exchangesFor 802.1x this means EAP start/logoff/signal are control between supplicant and authenticatorAllows methods to be written without regard to underlying application or for other methods in sequence
10DOS attacks EAP over non secure media is vulnerable to DOS attacks EAPOL - logoffEAP FailureRandom EAP messages with valid id for applicationMan in middle attacks on methods vulnerable to themOther ?? (good to document as many as possible)
11Retransmission EAP is a half duplex protocol Authenticator sends Request with an IDPeer sends Response with same IDIf Authenticator does not get response in specified time frame, it resends the identical RequestIf Peer gets a duplicate Request after sending a Response, it resends the ResponseIf Peer gets a Request it does not understand or does not expect it silently discards the Request and does not ReplyIf 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
12Unexpected and not understood Unexpected requests and responses can detected by the EAP Switch. ExamplesResp with incorrect IDRequest with “old” IDReq/Resp with syntactic errorsNot understood requests are found by methods and are method specific checksMethod must indicate to Switch that message failed an integrity check.
15Future work EAP State machine for AP API for EAP Methods - as help for Method creators/implementorsAPI to interface - for access to 802.1x and other applications(where should this work be done?)Possible “PANA” interfaceState machine for “inbedded” methods