Subject: [eap] Proposed resolution of Issue 130: Reject

From: [email-masked] (Bernard Aboba)
Date: Tue, 13 May 2003 05:53:49 -0700 (PDT)

The text of Issue 130 (and subsequent discussion) is given below.
It appears that there is no true deadlock and so I would recommend that
this issue be rejected.

Any objections?
--------------------------------------------------------
Issue 130: Potential Deadlock
Submitter name: Lauri Tarkkala
Submitter email address: [email-masked]
Date first submitted: May 13, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

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

[Pasi Eronen]:

Lauri Tarkkala wrote:

> 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.

I think this situation is not any different from the one-way
case. 2284bis already mentions that Success and Failure packets
are not acknowledged, and thus timeouts are possible if the link
has high error rate.

Consider a single EAP conversation where the Success packet is
lost. This results in a timeout for the peer. If the peer is
happy with the overall situation (e.g. it would enable the link
if it received a Success packet), it may enable the link anyway
(initiate NCP in case of PPP).

In case of two simultaneous EAP conversations, the PPP
connection will succeed if both parties follow this
behavior. Also, the party that has longer timeout may consider
a NCP packet as "lower layer success indication", and process
it appropriately (if we allow lower layer success indications,
as I proposed in my previous message).

(The EAP implementations are not in a true deadlock, because
on both parties, one of the EAP conversations has already
ended, and the conversation instance that is "dangling" is
not waiting for anything from the other "dangling" instance).

[Jari Arkko]:

[email-masked] wrote:

> I think this situation is not any different from the one-way
> case. 2284bis already mentions that Success and Failure packets
> are not acknowledged, and thus timeouts are possible if the link
> has high error rate.
...
> (The EAP implementations are not in a true deadlock, because
> on both parties, one of the EAP conversations has already
> ended, and the conversation instance that is "dangling" is
> not waiting for anything from the other "dangling" instance).

Yes, I think that is right.

Lauri Tarkkala wrote:

> 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.

That's right, but we've discouraged the use of sequences.
So I don't think this is an issue.

---

From: [email-masked] (Lauri Tarkkala)
Date: Fri, 16 May 2003 20:05:59 +0300

> It appears that there is no true deadlock and so I would recommend that

IMHO this issue can be rejected, under the condition, that the use
of lower-layer indications is specified under the following conditions:

- EAP transmissions are unreliable, and lower layer indications are
  unreliable.
  
- EAP transmissios are unreliable, but lower layer indications
  are reliable.

- Both positive and negative indications are specified.

These have been discussed in this thread, and in other threads. One
suggested proposal for the wording (regarding positive indications)
was given by me earlier on in the Issue 130 thread, and by others
in other threads.

Lauri

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