Subject: [eap] Issue XXX: Potential deadlock

From: [email-masked] (Lauri Tarkkala)
Date: Tue, 13 May 2003 08:50:43 +0300

Sorry about the late submission, but I have been buried in work.

Potential Deadlock

Submitter name: Lauri Tarkkala
Submitter email address: [email-masked]
Document: Rfc2284bis
Comment type: T
Priority: S

There exist a couple of deadlocks currently in the proposed EAP
protocol as used in e.g. PPP. I do not recall it being discussed
earlier.

Assume we have two PPP peers (A and B) negotating LCP, and both
desire to authenticate each other with EAP. A authenticates B
with EAP and B authenticates A with EAP.

Now assume that both EAP Success messages are "lost" after the
authentication rounds are completed, and since both parties
now have an EAP authentication pending, they will not
start negotiating a NCP (e.g. IPCP) for the link. The
system is effectively in deadlock.

There are some solutions:

1) Require that Success messages are ACK'd. 
  
2) Require authenticatee to retransmit last message untill it
   receives a final (Success/Failure) response from the client.

Neither of these is backwards compatible. Currently the only
sensible solution for a PPP implementation is to initiate
an NCP when it "guesses" that an EAP client has completed
(after a suitable timeout) to avoid the above deadlock. This
is of course against the current recommendation of this WG, but
that recommendation means very little if it causes a deadlock.

Note that the lack of an explicit ACK of success means that 
it is difficult in this case to distinguish between
"sequential authentication" where several methods are
applied after each other and a dropped EAP-Success.

I do not propose a fix in this submission, because this
interplays with other issues currently under discussion,
but I wanted a separate issue up on this, so it does
not get forgotten.

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/