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

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 802.11 has shown issues with
6. Retransmissions
7. DOS Attacks with random transmissions
8. 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 methodx
• Peer can accept and Reply to methodx
• Or - can NAK methodx 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

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
4. 802.1x assumes a secure connection - but
   802.11 doesnt seem to have that
5. 802.1x auth state machine doesnt 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
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
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 gt 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