Presentation on theme: "EAP STATE Machine Proposal John Vollbrecht Nick Petroni."— Presentation transcript:
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 1.No published IETF State machine 2.IETF deals with protocols - not API to methods 3.EAP design group working on cleaning up EAP RFC, also looking at producing an EAP State Machine 4.EAP State Machine is based on an EAP Switch Model 5.Experience with has shown issues with 1.Retransmissions 2.DOS Attacks with random transmissions 6.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 EAP Switch Link EAP Switch 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 1.EAP is multi-directional 2.EAP does requires Success/Failure between AS and supplicant but also uses EAP Success/failure to signal between Supplicant and Authenticator 3.RADIUS doesnt have a good way to deal with EAP mutual authentication initiated by supplicant x assumes a secure connection - but doesnt seem to have that x auth state machine doesnt 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 x 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.
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