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.
2.
3.
4.
5.
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
1.
2.
6.
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
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 doesn’t have a good way to deal with
EAP mutual authentication initiated by
supplicant
4. 802.1x assumes a “secure connection” - but
802.11 doesn’t seem to have that
5. 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.
METHOD
EAP Peer State Diagram
Vollbrecht, Petroni 2003
intCheck = doIntegrityCheck()
if (intCheck) {
buildMethodResp(currentId)
methodState = {CONT | CON_SUCC |
SUCC | FAIL }
}
!intCheck
allowMethod || currentMethod == 1
rxMethodReq &&
methodState == CONT
intCheck
METHOD INIT
allowMethod = Policy.allow(currentMethod)
if (allowMethod) {
methodState = INIT
}
ACTIVE
txMethodResp(currentId)
clearMethodReqQueue()
rxMethodReq &&
{methodState == SUCC ||
methodState == CON_SUCC}
UCT
DIALOG
INITIALIZE
methodState = SUCC
discCount = 0
UCT
timeout = FALSE
rxNotify = FALSE
rxMethodReq = FALSE
rxSuccess = FALSE
rxFailure = FALSE
successCondition
SUCCESS
return(SUCCESS)
UCT
else
UCT
!allowMethod &&
currentMethod != 1 (Identity)
NAK
txNak(currentMethod)
DISCARD
increment(discCount)
failureCondition
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
INITIALIZE
Vollbrecht, Petroni 2003
discCount = 0
currentId = InitialId
UCT
SUCCESS
txSuccess()
return(SUCCESS)
GET METHOD
policySat = Policy.isSatisfied()
!policySat &&
FAILURE
if (!policySat) {
currentMethod = NONE txFailure()
currentMethod = Policy.getNextMeth()
return(FAILURE)
methodState = INIT
}
policySat
else
intCheck && { methodState == SUCC ||
methodState == CON_SUCC}
UCT
METHOD
intCheck = doIntegrityCheck()
if (intCheck) {
methodState == FAIL
buildMethodReq(currentId)
methodState = { CONT | CON_SUCC |
FAIL | SUCC | FIRST }
}
retransCount >
MaxRetrans
else
intCheck &&
{ methodState == CONT ||
methodState == FIRST}
NAK
resetMethod(currentMethod)
DISCARD
increment(discCount)
rxNak &&
methodState == FIRST
else
UCT
ACTIVE
currentId++
retransCount = 1
txMethodReq(currentId)
clearMethodRespQueue()
UCT
DIALOG
rxMethodResp = FALSE
rxNak = FALSE
timeout = FALSE
rxMethodResp
timeout
else
RETRANSMIT
txMethodReq(currentId)
retransCount++
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